From nobody Mon Jun 2 08:32:47 2014 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7712E1A0385 for ; Mon, 2 Jun 2014 08:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Voau4WEKUhYG for ; Mon, 2 Jun 2014 08:32:37 -0700 (PDT) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 620251A0371 for ; Mon, 2 Jun 2014 08:32:37 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id uz6so4679976obc.5 for ; Mon, 02 Jun 2014 08:32:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1EPZl3kseo4XnPZ4MwluKAt6GcWP0r3/Uet08Q2BnxQ=; b=MV81ZlasmjlKdA79taxFM7rbwZhG0B8HccUW9WCoKDyjWS/h2gIPEg9EuO7H1aTxYO QA9S2aRF65yxcTIt+L14dNArliy4+kX5oILqtwEOCBd6ZKubGbxFHA/vW497/UmylGx7 knxPabBhGCZOEUhXY61bLWIBh8M0S1x8/qSjlKTPO1XyTJ6dVljwqsmQsAaw/CLIctQz A50FoQFdu7eMo7OAkN+WVBSOPXGi2WVIc/lO43xHJ7iiT9JUJ91jHN5OdWRS8rdp7FBl UQYz5tsXvHRv4O+TetC+g5O4byD2RF9o9xjCh+c8ly7wQn++LvO5P5PzIBvPoekVxUKX lG8g== X-Gm-Message-State: ALoCoQmeKLMPodzc3mKomNWjwZrFu1FZgaQ6ixuyh+dMTDwvuMDQEROuUYAMWbXzQQKzYF4K/jeV MIME-Version: 1.0 X-Received: by 10.182.60.65 with SMTP id f1mr3763698obr.78.1401723151824; Mon, 02 Jun 2014 08:32:31 -0700 (PDT) Received: by 10.182.176.5 with HTTP; Mon, 2 Jun 2014 08:32:31 -0700 (PDT) In-Reply-To: References: <329D879C76FDD04AAAE84BB1D89B3970094FBF9EAA@aplesfreedom.dom1.jhuapl.edu> <94CFB3711B4CAE4DBFC5BEB3374BF0C60D1835@NDMSMBX404.ndc.nasa.gov> Date: Mon, 2 Jun 2014 11:32:31 -0400 Message-ID: From: Amy Alford To: "Burleigh, Scott C (312G)" Content-Type: multipart/alternative; boundary=089e01538ad889cda804fadc1a1f Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/zNRuvfnTBRMdWkE1esSfGH3_M_o Cc: "dtn-security@irtf.org" Subject: Re: [dtn-security] Updated SBSP Document X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 15:32:41 -0000 --089e01538ad889cda804fadc1a1f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm also responding inline. On Fri, May 30, 2014 at 3:17 PM, Burleigh, Scott C (312G) < scott.c.burleigh@jpl.nasa.gov> wrote: > A couple of remarks on David=E2=80=99s comments, in-line below. > > > > Scott > > > > *From:* dtn-security [mailto:dtn-security-bounces@irtf.org] *On Behalf Of > *Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] > *Sent:* Thursday, May 29, 2014 12:09 PM > *To:* Birrane, Edward J.; dtn-security@irtf.org > *Subject:* Re: [dtn-security] Updated SBSP Document > > > > Ed, > > Good work - the SBSP spec continues to evolve nicely. I=E2=80=99ll kick o= ff the > discussions with my comments below. > > Cheers, > > DZ > > > > > > > > *[Page 12] 2.4 Bundle Authentication Block* > > The security-target MUST be the entire bundle, which MUST be > > represented by a of <0x00><0x00>. > > =C2=B7 Per 3.4 Bundle Fragmentation and Reassembly, bundle > authentication may be applied to bundle fragments as well as non-fragment= ed > bundles. > > =C2=B7 If a bundle fragment is received that has a BAB, there is = no > way to determine if the BAB applies to the bundle fragment or if it appli= es > to an entire bundle that was later fragmented by a non-security-aware BA. > > o I propose that a of <0x00> frag length> indicate that the BAB applies to a bundle fragment > > =C2=B7 If such a bundle fragment is further fragmented by a > non-security-aware BA then the can be used to > determine that the original fragmented bundle must be reassembled before > authentication is checked because it will not match the length field in t= he > payload block. > > o Some discussion may be desirable in section 3.4 as well as 2.4 if > accepted > > =C3=98 When a BAB is attached to a bundle that is a fragment, the bundle= that > it applies to is always that fragment, never the bundle that carried the > original payload (of which the current bundle=E2=80=99s payload is a frag= ment). > Since BABs are not end-to-end, the BAB for an original un-fragmented bund= le > will never be carried forward in any fragments generated from that bundle > (see the last paragraph of 3.3.1), so there=E2=80=99s no ambiguity. But = this does > bring up an important point: the block processing control flags of the BA= B > must always have the =E2=80=9Creplicate in every fragment=E2=80=9D flag s= et to 0. > > > Maybe I'm misunderstanding here, but fragmentation can happen between a BAB source and a BAB dest if a non-security aware node is between the two. Requiring the "DO_NOT_FRAGMENT" flag solves this. > > > *[Page 14] 2.6 Block Confidentiality Block* > > The block processing control flags value can be set to whatever > > values are required by local policy, except that a Lone BCB or > > First BCB MUST have the "replicate in every fragment" flag set. > > This indicates to a receiving node that the payload portion in > > each fragment represents cipher-text. > > =C2=B7 The intent here is only if the target of the Lone BCB or F= irst > BCB is the payload block which would need to be added if this is kept as = a > requirement. > > =C2=B7 I think this requirement should be removed or at least red= uced > to a "MAY" > > 1. It assumes that the Lone or First BCB must be prior to the > payload block which is not a specific requirement and is not necessary in > any case for SBSP > > 2. A BCB block could be quite large and add a lot of bandwidth > overhead if included in every fragment > > 3. I do not see a benefit gained by including the block in every > fragment > > i. Even the destination > node likely cannot decrypt any individual fragment except the first one > and it probably would only decrypt a partial bundle as a last resort or > forensic function if the entire bundle was not received before expiration > > ii. Intermediate nodes > shouldn't generally be poking around in bundle payloads anyway and no nee= d > to provide additional clues as to whether a fragment payload is encrypted > or a bunch of binary values =E2=80=93 keep the bad guys guessing and wast= ing CPU > cycles if possible > > iii. BSP includes this > requirement - have any of the implementations found a need or benefit for > this and would it still apply in context of the SBSP? > > =C3=98 I think this a good point. Since all decryption should only happ= en at > the bundle destination, which is where all the fragments are going to hav= e > to end up, why not forward all BCBs (for all blocks that have them) only > with the fragment whose offset is zero? > Is there a possibility of an intermediate node adding a BIB to the fragment, unaware that there's already a BCB on the whole payload? I really hate the interaction between fragmentation and BSP. I feel like tightly locking down how the two of them combine avoids a lot of pitfalls and ambiguity. > > > > > > *[Page 24] 3.1.2.3 Extension Block Canonicalization* > > The block-length is canonicalized as its unpacked SDNV value. If the > > data to be canonicalized is less than the complete, original block > > data, this field contains the size of the data being canonicalized > > (the "effective block") rather than the actual size of the block. > > =C2=B7 Section 3.1.2.1 (Primary Block Canonicalization) details t= he > length fields as 4 byte values and effectively reserves the term "unpacke= d > SDNV value" to mean the 8 byte value. I recommend using the same conventi= on > here. > > o Personally, I would specify all SDNV values canonicalized as 8 byte > values and be done with it > > =C2=B7 Add a statement to the effect: > > o The entirety or portion(s) of the block body data are canonicalized > as is. > > =C3=98 I agree about canonicalizing all SDNVs as 8-byte values. FWIW, I > think the canonicalization in bundle security protocol is a major pain in > the neck. Is the mutability of blocks =E2=80=93 the need to exclude muta= ble fields > from hash computations =E2=80=93 the main reason for it? Is there no way= to > simplify? > > > I think the major issue is the dictionary, since it can be modified even if the actual eid's in the block are stable. The flags are straightforward. In BSP, there's also a big issue with tail chasing when a PIB block is required to include chunks of itself in it's own hash. IIRC, SBSP avoids that entirely. --089e01538ad889cda804fadc1a1f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm also responding inline.
=

On Fri, May 30, 2014 at 3:17 PM, Burleig= h, Scott C (312G) <scott.c.burleigh@jpl.nasa.gov> wrote:

A couple of remarks on= David=E2=80=99s comments, in-line below.

=C2=A0

Scott

=C2=A0

From: dtn-secu= rity [mailto:dtn-security-bounces@irtf.org] On Behalf Of Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] Sent: Thursday, May 29, 2014 12:09 PM
To: Birrane, Edward J.; dtn-security@irtf.org
Subject: Re: [dtn-security] Updated SBSP Document

=C2=A0

Ed,

Good work - the SBSP spec continues to evolve nicely. I=E2=80=99ll kick = off the discussions with my comments below.

Cheers,

DZ

=C2=A0

=C2=A0

=C2=A0

[Page 12] 2.4 Bundle Authentication Block<= /u>

= The security-target MUST be the entire bundle, which MUST be<= /span>

= represented by a <block type><occurrence number> of <0x00>= ;<0x00>.

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Per 3.4 Bundle Fr= agmentation and Reassembly, bundle authentication may be applied to bundle = fragments as well as non-fragmented bundles.

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If a bundle fragm= ent is received that has a BAB, there is no way to determine if the BAB app= lies to the bundle fragment or if it applies to an entire bundle that was l= ater fragmented by a non-security-aware BA.

oI propose that a = <block type><occurrence number> of <0x00><payload frag= length> indicate that the BAB applies to a bundle fragment

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If such a bundle = fragment is further fragmented by a non-security-aware BA then the <payl= oad frag length> can be used to determine that the original fragmented b= undle must be reassembled before authentication is checked because it will not match the length field in the payload block= .

oSome discussion m= ay be desirable in section 3.4 as well as 2.4 if accepted

= =C3=98=C2=A0 When a BAB is att= ached to a bundle that is a fragment, the bundle that it applies to is alwa= ys that fragment, never the bundle that carried the original payload (of wh= ich the current bundle=E2=80=99s payload is a fragment).=C2=A0 Since BABs are not end-to-end, the BAB for an origin= al un-fragmented bundle will never be carried forward in any fragments gene= rated from that bundle (see the last paragraph of 3.3.1), so there=E2=80=99= s no ambiguity.=C2=A0 But this does bring up an important point: the block processing control flags of the BAB must always have the = =E2=80=9Creplicate in every fragment=E2=80=9D flag set to 0.<= u>

=C2=A0

Maybe = I'm misunderstanding here, but fragmentation can happen between a BAB s= ource and a BAB dest if a non-security aware node is between the two. =C2= =A0Requiring the "DO_NOT_FRAGMENT" flag solves this. =C2=A0
=C2=A0

=

=C2=A0

[Page 14] 2.6 Block Confidentiality Block<= /u>

= The block processing control flags value can be set to whatever

= values are required by local policy, except that a Lone BCB or

= First BCB MUST have the "replicate in every fragment" flag set.

= This indicates to a receiving node that the payload portion in

= each fragment represents cipher-text.

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The intent here i= s only if the target of the Lone BCB or First BCB is the payload block whic= h would need to be added if this is kept as a requirement.

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I think this requ= irement should be removed or at least reduced to a "MAY"

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 It assumes that t= he Lone or First BCB must be prior to the payload block which is not a spec= ific requirement and is not necessary in any case for SBSP

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A BCB block could= be quite large and add a lot of bandwidth overhead if included in every fr= agment

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I do not see a be= nefit gained by including the block in every fragment

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 i.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Even the destination node likely c= annot decrypt any individual fragment except the first one and=C2=A0 it pro= bably would only decrypt a partial bundle as a last resort or forensic function if the entire bundle was not = received before expiration

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 ii.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Intermediate nodes shouldn't g= enerally be poking around in bundle payloads anyway and no need to provide = additional clues as to whether a fragment payload is encrypted or a bunch of binary values =E2=80=93 keep= the bad guys guessing and wasting CPU cycles if possible

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 iii.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BSP includes this requirement - ha= ve any of the implementations found a need or benefit for this and would it= still apply in context of the SBSP?

=C3=98=C2=A0 I think this a go= od point.=C2=A0 Since all decryption should only happen at the bundle desti= nation, which is where all the fragments are going to have to end up, why n= ot forward all BCBs (for all blocks that have them) only with the fragment whose offset is zero?=C2=A0 =C2=A0<= /span>

Is there a possibility of an interm= ediate node adding a BIB to the fragment, unaware that there's already = a BCB on the whole payload? =C2=A0I really hate the interaction between fra= gmentation and BSP. =C2=A0I feel like tightly locking down how the two of t= hem combine avoids a lot of pitfalls and ambiguity.
=C2=A0

=C2=A0

=C2=A0


[Page 24] 3.1.2.3 Extension Block Canonicalizatio= n

= The block-length is canonicalized as its unpacked SDNV value.=C2=A0 If the<= u>

= data to be canonicalized is less than the complete, original block

= data, this field contains the size of the data being canonicalized

= (the "effective block") rather than the actual size of the block.=

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 3.1.2.1 (= Primary Block Canonicalization) details the length fields as 4 byte values = and effectively reserves the term "unpacked SDNV value" to mean t= he 8 byte value. I recommend using the same convention here.=

oPersonally, I wou= ld specify all SDNV values canonicalized as 8 byte values and be done with = it

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Add a statement t= o the effect:

oThe entirety or p= ortion(s) of the block body data are canonicalized as is.

=C3=98=C2=A0 I agree about can= onicalizing all SDNVs as 8-byte values.=C2=A0 FWIW, I think the canonicaliz= ation in bundle security protocol is a major pain in the neck.=C2=A0 Is the= mutability of blocks =E2=80=93 the need to exclude mutable fields from hash computations =E2=80=93 the main reason for it?=C2= =A0 Is there no way to simplify?

=C2=A0

I think the maj= or issue is the dictionary, since it can be modified even if the actual eid= 's in the block are stable. =C2=A0The flags are straightforward. =C2=A0= In BSP, there's also a big issue with tail chasing when a PIB block is = required to include chunks of itself in it's own hash. =C2=A0IIRC, SBSP= avoids that entirely. =C2=A0=C2=A0
=C2=A0
--089e01538ad889cda804fadc1a1f-- From nobody Mon Jun 2 08:55:41 2014 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B931A035B for ; Mon, 2 Jun 2014 08:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UU6zyWjVrfG5 for ; Mon, 2 Jun 2014 08:55:34 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27E371A0340 for ; Mon, 2 Jun 2014 08:55:34 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp02.jpl.nasa.gov [128.149.137.149]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s52FtPox026695 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 2 Jun 2014 08:55:26 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.156]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.03.0174.001; Mon, 2 Jun 2014 08:55:14 -0700 From: "Burleigh, Scott C (312G)" To: Amy Alford Thread-Topic: [dtn-security] Updated SBSP Document Thread-Index: Ac96egHBtIlHfqjpRHK8eG5est6OOQA736HgADK/lpAAn4L4gAAOWA2A Date: Mon, 2 Jun 2014 15:55:13 +0000 Message-ID: References: <329D879C76FDD04AAAE84BB1D89B3970094FBF9EAA@aplesfreedom.dom1.jhuapl.edu> <94CFB3711B4CAE4DBFC5BEB3374BF0C60D1835@NDMSMBX404.ndc.nasa.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: multipart/alternative; boundary="_000_A5BEAD028815CB40A32A5669CF737C3B423B4F0Fapembxsp40RESAD_" MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/RdOioI1Sf4MI8BrWCm_U0Mov5Ms Cc: "dtn-security@irtf.org" Subject: Re: [dtn-security] Updated SBSP Document X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 15:55:37 -0000 --_000_A5BEAD028815CB40A32A5669CF737C3B423B4F0Fapembxsp40RESAD_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R29vZCBwb2ludHMsIEFteS4gIE15IHRob3VnaHRzIGxpa2V3aXNlIGluLWxpbmUuDQoNClNjb3R0 DQoNCkZyb206IEFteSBBbGZvcmQgW21haWx0bzphbG9vbWlzQHNhcm4ub3JnXQ0KU2VudDogTW9u ZGF5LCBKdW5lIDAyLCAyMDE0IDg6MzMgQU0NClRvOiBCdXJsZWlnaCwgU2NvdHQgQyAoMzEyRykN CkNjOiBab2xsZXIsIERhdmlkIEEuIChNU0ZDLUVPNTApW0hPU0MgU0VSVklDRVMgQ09OVFJBQ1Rd OyBCaXJyYW5lLCBFZHdhcmQgSi47IGR0bi1zZWN1cml0eUBpcnRmLm9yZw0KU3ViamVjdDogUmU6 IFtkdG4tc2VjdXJpdHldIFVwZGF0ZWQgU0JTUCBEb2N1bWVudA0KDQpJJ20gYWxzbyByZXNwb25k aW5nIGlubGluZS4NCg0KT24gRnJpLCBNYXkgMzAsIDIwMTQgYXQgMzoxNyBQTSwgQnVybGVpZ2gs IFNjb3R0IEMgKDMxMkcpIDxzY290dC5jLmJ1cmxlaWdoQGpwbC5uYXNhLmdvdjxtYWlsdG86c2Nv dHQuYy5idXJsZWlnaEBqcGwubmFzYS5nb3Y+PiB3cm90ZToNCkEgY291cGxlIG9mIHJlbWFya3Mg b24gRGF2aWTigJlzIGNvbW1lbnRzLCBpbi1saW5lIGJlbG93Lg0KU2NvdHQNCkZyb206IGR0bi1z ZWN1cml0eSBbbWFpbHRvOmR0bi1zZWN1cml0eS1ib3VuY2VzQGlydGYub3JnPG1haWx0bzpkdG4t c2VjdXJpdHktYm91bmNlc0BpcnRmLm9yZz5dIE9uIEJlaGFsZiBPZiBab2xsZXIsIERhdmlkIEEu IChNU0ZDLUVPNTApW0hPU0MgU0VSVklDRVMgQ09OVFJBQ1RdDQpTZW50OiBUaHVyc2RheSwgTWF5 IDI5LCAyMDE0IDEyOjA5IFBNDQpUbzogQmlycmFuZSwgRWR3YXJkIEouOyBkdG4tc2VjdXJpdHlA aXJ0Zi5vcmc8bWFpbHRvOmR0bi1zZWN1cml0eUBpcnRmLm9yZz4NClN1YmplY3Q6IFJlOiBbZHRu LXNlY3VyaXR5XSBVcGRhdGVkIFNCU1AgRG9jdW1lbnQNCg0KRWQsDQoNCkdvb2Qgd29yayAtIHRo ZSBTQlNQIHNwZWMgY29udGludWVzIHRvIGV2b2x2ZSBuaWNlbHkuIEnigJlsbCBraWNrIG9mZiB0 aGUgZGlzY3Vzc2lvbnMgd2l0aCBteSBjb21tZW50cyBiZWxvdy4NCg0KQ2hlZXJzLA0KDQpEWg0K W1BhZ2UgMTJdIDIuNCBCdW5kbGUgQXV0aGVudGljYXRpb24gQmxvY2sNClRoZSBzZWN1cml0eS10 YXJnZXQgTVVTVCBiZSB0aGUgZW50aXJlIGJ1bmRsZSwgd2hpY2ggTVVTVCBiZQ0KcmVwcmVzZW50 ZWQgYnkgYSA8YmxvY2sgdHlwZT48b2NjdXJyZW5jZSBudW1iZXI+IG9mIDwweDAwPjwweDAwPi4N CuKAoiAgICAgICAgIFBlciAzLjQgQnVuZGxlIEZyYWdtZW50YXRpb24gYW5kIFJlYXNzZW1ibHks IGJ1bmRsZSBhdXRoZW50aWNhdGlvbiBtYXkgYmUgYXBwbGllZCB0byBidW5kbGUgZnJhZ21lbnRz IGFzIHdlbGwgYXMgbm9uLWZyYWdtZW50ZWQgYnVuZGxlcy4NCuKAoiAgICAgICAgIElmIGEgYnVu ZGxlIGZyYWdtZW50IGlzIHJlY2VpdmVkIHRoYXQgaGFzIGEgQkFCLCB0aGVyZSBpcyBubyB3YXkg dG8gZGV0ZXJtaW5lIGlmIHRoZSBCQUIgYXBwbGllcyB0byB0aGUgYnVuZGxlIGZyYWdtZW50IG9y IGlmIGl0IGFwcGxpZXMgdG8gYW4gZW50aXJlIGJ1bmRsZSB0aGF0IHdhcyBsYXRlciBmcmFnbWVu dGVkIGJ5IGEgbm9uLXNlY3VyaXR5LWF3YXJlIEJBLg0KbyAgICBJIHByb3Bvc2UgdGhhdCBhIDxi bG9jayB0eXBlPjxvY2N1cnJlbmNlIG51bWJlcj4gb2YgPDB4MDA+PHBheWxvYWQgZnJhZyBsZW5n dGg+IGluZGljYXRlIHRoYXQgdGhlIEJBQiBhcHBsaWVzIHRvIGEgYnVuZGxlIGZyYWdtZW50DQri gKIgICAgICAgICBJZiBzdWNoIGEgYnVuZGxlIGZyYWdtZW50IGlzIGZ1cnRoZXIgZnJhZ21lbnRl ZCBieSBhIG5vbi1zZWN1cml0eS1hd2FyZSBCQSB0aGVuIHRoZSA8cGF5bG9hZCBmcmFnIGxlbmd0 aD4gY2FuIGJlIHVzZWQgdG8gZGV0ZXJtaW5lIHRoYXQgdGhlIG9yaWdpbmFsIGZyYWdtZW50ZWQg YnVuZGxlIG11c3QgYmUgcmVhc3NlbWJsZWQgYmVmb3JlIGF1dGhlbnRpY2F0aW9uIGlzIGNoZWNr ZWQgYmVjYXVzZSBpdCB3aWxsIG5vdCBtYXRjaCB0aGUgbGVuZ3RoIGZpZWxkIGluIHRoZSBwYXls b2FkIGJsb2NrLg0KbyAgICBTb21lIGRpc2N1c3Npb24gbWF5IGJlIGRlc2lyYWJsZSBpbiBzZWN0 aW9uIDMuNCBhcyB3ZWxsIGFzIDIuNCBpZiBhY2NlcHRlZA0KDQo+ICBXaGVuIGEgQkFCIGlzIGF0 dGFjaGVkIHRvIGEgYnVuZGxlIHRoYXQgaXMgYSBmcmFnbWVudCwgdGhlIGJ1bmRsZSB0aGF0IGl0 IGFwcGxpZXMgdG8gaXMgYWx3YXlzIHRoYXQgZnJhZ21lbnQsIG5ldmVyIHRoZSBidW5kbGUgdGhh dCBjYXJyaWVkIHRoZSBvcmlnaW5hbCBwYXlsb2FkIChvZiB3aGljaCB0aGUgY3VycmVudCBidW5k bGXigJlzIHBheWxvYWQgaXMgYSBmcmFnbWVudCkuICBTaW5jZSBCQUJzIGFyZSBub3QgZW5kLXRv LWVuZCwgdGhlIEJBQiBmb3IgYW4gb3JpZ2luYWwgdW4tZnJhZ21lbnRlZCBidW5kbGUgd2lsbCBu ZXZlciBiZSBjYXJyaWVkIGZvcndhcmQgaW4gYW55IGZyYWdtZW50cyBnZW5lcmF0ZWQgZnJvbSB0 aGF0IGJ1bmRsZSAoc2VlIHRoZSBsYXN0IHBhcmFncmFwaCBvZiAzLjMuMSksIHNvIHRoZXJl4oCZ cyBubyBhbWJpZ3VpdHkuICBCdXQgdGhpcyBkb2VzIGJyaW5nIHVwIGFuIGltcG9ydGFudCBwb2lu dDogdGhlIGJsb2NrIHByb2Nlc3NpbmcgY29udHJvbCBmbGFncyBvZiB0aGUgQkFCIG11c3QgYWx3 YXlzIGhhdmUgdGhlIOKAnHJlcGxpY2F0ZSBpbiBldmVyeSBmcmFnbWVudOKAnSBmbGFnIHNldCB0 byAwLg0KTWF5YmUgSSdtIG1pc3VuZGVyc3RhbmRpbmcgaGVyZSwgYnV0IGZyYWdtZW50YXRpb24g Y2FuIGhhcHBlbiBiZXR3ZWVuIGEgQkFCIHNvdXJjZSBhbmQgYSBCQUIgZGVzdCBpZiBhIG5vbi1z ZWN1cml0eSBhd2FyZSBub2RlIGlzIGJldHdlZW4gdGhlIHR3by4gIFJlcXVpcmluZyB0aGUgIkRP X05PVF9GUkFHTUVOVCIgZmxhZyBzb2x2ZXMgdGhpcy4NCg0KPj4gICAgICAgICAgIEkgc2VlIHdo YXQgeW914oCZcmUgc2F5aW5nLCBhbmQgSSB0aGluayBpdCBnb2VzIHRvIHRoZSBsYW1lbnQgaW4g eW91ciBuZXh0IGNvbW1lbnQ6IHRoZSBpbnRlcmFjdGlvbiBiZXR3ZWVuIGZyYWdtZW50YXRpb24g YW5kIEJTUCByZWFsbHkgaXMgYSBtZXNzLiAgQnV0IEkgdGhvdWdodCBTQlNQIHNpbXBsaWZpZWQg dGhpbmdzIHNvbWV3aGF0IGJ5IG5vdCBhbGxvd2luZyBhbnkgbm9uLXNlY3VyaXR5LWF3YXJlIG5v ZGVzIGJldHdlZW4gdGhlIEJBQiBzb3VyY2UgYW5kIEJBQiBkZXN0aW5hdGlvbi4gIEF0IGxlYXN0 LCB0aGF04oCZcyB3aGF0IEkgaG9wZWQgd2Ugd2VyZSBkb2luZywgYW5kIGl04oCZcyBob3cgSSBp bnRlcnByZXQg4oCcQkFCcyBvcGVyYXRlIGJldHdlZW4gdG9wb2xvZ2ljYWxseSBhZGphY2VudCBu b2Rlc+KAnSBvbiBwYWdlIDYuICBJZiB0aGF04oCZcyBub3QgdGhlIGNhc2UgdGhlbiBJIHRoaW5r IHRoZXJlIGFyZSBhZGRpdGlvbmFsIHByb2JsZW1zIHRvIHJlc29sdmUuDQoNCiBbUGFnZSAxNF0g Mi42IEJsb2NrIENvbmZpZGVudGlhbGl0eSBCbG9jaw0KVGhlIGJsb2NrIHByb2Nlc3NpbmcgY29u dHJvbCBmbGFncyB2YWx1ZSBjYW4gYmUgc2V0IHRvIHdoYXRldmVyDQp2YWx1ZXMgYXJlIHJlcXVp cmVkIGJ5IGxvY2FsIHBvbGljeSwgZXhjZXB0IHRoYXQgYSBMb25lIEJDQiBvcg0KRmlyc3QgQkNC IE1VU1QgaGF2ZSB0aGUgInJlcGxpY2F0ZSBpbiBldmVyeSBmcmFnbWVudCIgZmxhZyBzZXQuDQpU aGlzIGluZGljYXRlcyB0byBhIHJlY2VpdmluZyBub2RlIHRoYXQgdGhlIHBheWxvYWQgcG9ydGlv biBpbg0KZWFjaCBmcmFnbWVudCByZXByZXNlbnRzIGNpcGhlci10ZXh0Lg0K4oCiICAgICAgICAg VGhlIGludGVudCBoZXJlIGlzIG9ubHkgaWYgdGhlIHRhcmdldCBvZiB0aGUgTG9uZSBCQ0Igb3Ig Rmlyc3QgQkNCIGlzIHRoZSBwYXlsb2FkIGJsb2NrIHdoaWNoIHdvdWxkIG5lZWQgdG8gYmUgYWRk ZWQgaWYgdGhpcyBpcyBrZXB0IGFzIGEgcmVxdWlyZW1lbnQuDQrigKIgICAgICAgICBJIHRoaW5r IHRoaXMgcmVxdWlyZW1lbnQgc2hvdWxkIGJlIHJlbW92ZWQgb3IgYXQgbGVhc3QgcmVkdWNlZCB0 byBhICJNQVkiDQoxLiAgICAgICBJdCBhc3N1bWVzIHRoYXQgdGhlIExvbmUgb3IgRmlyc3QgQkNC IG11c3QgYmUgcHJpb3IgdG8gdGhlIHBheWxvYWQgYmxvY2sgd2hpY2ggaXMgbm90IGEgc3BlY2lm aWMgcmVxdWlyZW1lbnQgYW5kIGlzIG5vdCBuZWNlc3NhcnkgaW4gYW55IGNhc2UgZm9yIFNCU1AN CjIuICAgICAgIEEgQkNCIGJsb2NrIGNvdWxkIGJlIHF1aXRlIGxhcmdlIGFuZCBhZGQgYSBsb3Qg b2YgYmFuZHdpZHRoIG92ZXJoZWFkIGlmIGluY2x1ZGVkIGluIGV2ZXJ5IGZyYWdtZW50DQozLiAg ICAgICBJIGRvIG5vdCBzZWUgYSBiZW5lZml0IGdhaW5lZCBieSBpbmNsdWRpbmcgdGhlIGJsb2Nr IGluIGV2ZXJ5IGZyYWdtZW50DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBpLiAgICAgICAgICAgIEV2ZW4gdGhlIGRlc3RpbmF0aW9uIG5vZGUgbGlrZWx5IGNhbm5vdCBk ZWNyeXB0IGFueSBpbmRpdmlkdWFsIGZyYWdtZW50IGV4Y2VwdCB0aGUgZmlyc3Qgb25lIGFuZCAg aXQgcHJvYmFibHkgd291bGQgb25seSBkZWNyeXB0IGEgcGFydGlhbCBidW5kbGUgYXMgYSBsYXN0 IHJlc29ydCBvciBmb3JlbnNpYyBmdW5jdGlvbiBpZiB0aGUgZW50aXJlIGJ1bmRsZSB3YXMgbm90 IHJlY2VpdmVkIGJlZm9yZSBleHBpcmF0aW9uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgaWkuICAgICAgICAgICAgSW50ZXJtZWRpYXRlIG5vZGVzIHNob3VsZG4ndCBnZW5l cmFsbHkgYmUgcG9raW5nIGFyb3VuZCBpbiBidW5kbGUgcGF5bG9hZHMgYW55d2F5IGFuZCBubyBu ZWVkIHRvIHByb3ZpZGUgYWRkaXRpb25hbCBjbHVlcyBhcyB0byB3aGV0aGVyIGEgZnJhZ21lbnQg cGF5bG9hZCBpcyBlbmNyeXB0ZWQgb3IgYSBidW5jaCBvZiBiaW5hcnkgdmFsdWVzIOKAkyBrZWVw IHRoZSBiYWQgZ3V5cyBndWVzc2luZyBhbmQgd2FzdGluZyBDUFUgY3ljbGVzIGlmIHBvc3NpYmxl DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpaWkuICAgICAgICAgICAgQlNQ IGluY2x1ZGVzIHRoaXMgcmVxdWlyZW1lbnQgLSBoYXZlIGFueSBvZiB0aGUgaW1wbGVtZW50YXRp b25zIGZvdW5kIGEgbmVlZCBvciBiZW5lZml0IGZvciB0aGlzIGFuZCB3b3VsZCBpdCBzdGlsbCBh cHBseSBpbiBjb250ZXh0IG9mIHRoZSBTQlNQPw0KDQo+ICBJIHRoaW5rIHRoaXMgYSBnb29kIHBv aW50LiAgU2luY2UgYWxsIGRlY3J5cHRpb24gc2hvdWxkIG9ubHkgaGFwcGVuIGF0IHRoZSBidW5k bGUgZGVzdGluYXRpb24sIHdoaWNoIGlzIHdoZXJlIGFsbCB0aGUgZnJhZ21lbnRzIGFyZSBnb2lu ZyB0byBoYXZlIHRvIGVuZCB1cCwgd2h5IG5vdCBmb3J3YXJkIGFsbCBCQ0JzIChmb3IgYWxsIGJs b2NrcyB0aGF0IGhhdmUgdGhlbSkgb25seSB3aXRoIHRoZSBmcmFnbWVudCB3aG9zZSBvZmZzZXQg aXMgemVybz8NCklzIHRoZXJlIGEgcG9zc2liaWxpdHkgb2YgYW4gaW50ZXJtZWRpYXRlIG5vZGUg YWRkaW5nIGEgQklCIHRvIHRoZSBmcmFnbWVudCwgdW5hd2FyZSB0aGF0IHRoZXJlJ3MgYWxyZWFk eSBhIEJDQiBvbiB0aGUgd2hvbGUgcGF5bG9hZD8gIEkgcmVhbGx5IGhhdGUgdGhlIGludGVyYWN0 aW9uIGJldHdlZW4gZnJhZ21lbnRhdGlvbiBhbmQgQlNQLiAgSSBmZWVsIGxpa2UgdGlnaHRseSBs b2NraW5nIGRvd24gaG93IHRoZSB0d28gb2YgdGhlbSBjb21iaW5lIGF2b2lkcyBhIGxvdCBvZiBw aXRmYWxscyBhbmQgYW1iaWd1aXR5Lg0KDQo+PiAgICAgICAgICAgSXMgdGhlcmUgYW55IHJlYWwg bmVlZCB0byBhbGxvdyBwYXlsb2FkIEJJQnMgYW5kIEJDQnMgdG8gYmUgYWRkZWQgaW4gYnVuZGxl cyB0aGF0IGFyZSBmcmFnbWVudHM/ICBXaHkgbm90IGp1c3QgcHJvaGliaXQgdGhhdD8gIElmIGl0 4oCZcyBhYnNvbHV0ZWx5IG5lY2Vzc2FyeSBmb3Igc29tZSB1bmZhdGhvbWFibGUgcmVhc29uLCB1 c2UgYnVuZGxlLWluLWJ1bmRsZSBlbmNhcHN1bGF0aW9uIHRvIGVuY2Fwc3VsYXRlIHRoZSBmcmFn bWVudGFyeSBidW5kbGUgYXMgdGhlIHBheWxvYWQgb2YgYSBuZXcgYnVuZGxlIGFuZCBhdHRhY2gg dGhlIEJJQiBvciBCQ0IgdG8gdGhlIGVuY2Fwc3VsYXRpbmcgYnVuZGxlLg0KDQpbUGFnZSAyNF0g My4xLjIuMyBFeHRlbnNpb24gQmxvY2sgQ2Fub25pY2FsaXphdGlvbg0KVGhlIGJsb2NrLWxlbmd0 aCBpcyBjYW5vbmljYWxpemVkIGFzIGl0cyB1bnBhY2tlZCBTRE5WIHZhbHVlLiAgSWYgdGhlDQpk YXRhIHRvIGJlIGNhbm9uaWNhbGl6ZWQgaXMgbGVzcyB0aGFuIHRoZSBjb21wbGV0ZSwgb3JpZ2lu YWwgYmxvY2sNCmRhdGEsIHRoaXMgZmllbGQgY29udGFpbnMgdGhlIHNpemUgb2YgdGhlIGRhdGEg YmVpbmcgY2Fub25pY2FsaXplZA0KKHRoZSAiZWZmZWN0aXZlIGJsb2NrIikgcmF0aGVyIHRoYW4g dGhlIGFjdHVhbCBzaXplIG9mIHRoZSBibG9jay4NCuKAoiAgICAgICAgIFNlY3Rpb24gMy4xLjIu MSAoUHJpbWFyeSBCbG9jayBDYW5vbmljYWxpemF0aW9uKSBkZXRhaWxzIHRoZSBsZW5ndGggZmll bGRzIGFzIDQgYnl0ZSB2YWx1ZXMgYW5kIGVmZmVjdGl2ZWx5IHJlc2VydmVzIHRoZSB0ZXJtICJ1 bnBhY2tlZCBTRE5WIHZhbHVlIiB0byBtZWFuIHRoZSA4IGJ5dGUgdmFsdWUuIEkgcmVjb21tZW5k IHVzaW5nIHRoZSBzYW1lIGNvbnZlbnRpb24gaGVyZS4NCm8gICAgUGVyc29uYWxseSwgSSB3b3Vs ZCBzcGVjaWZ5IGFsbCBTRE5WIHZhbHVlcyBjYW5vbmljYWxpemVkIGFzIDggYnl0ZSB2YWx1ZXMg YW5kIGJlIGRvbmUgd2l0aCBpdA0K4oCiICAgICAgICAgQWRkIGEgc3RhdGVtZW50IHRvIHRoZSBl ZmZlY3Q6DQpvICAgIFRoZSBlbnRpcmV0eSBvciBwb3J0aW9uKHMpIG9mIHRoZSBibG9jayBib2R5 IGRhdGEgYXJlIGNhbm9uaWNhbGl6ZWQgYXMgaXMuDQoNCj4gIEkgYWdyZWUgYWJvdXQgY2Fub25p Y2FsaXppbmcgYWxsIFNETlZzIGFzIDgtYnl0ZSB2YWx1ZXMuICBGV0lXLCBJIHRoaW5rIHRoZSBj YW5vbmljYWxpemF0aW9uIGluIGJ1bmRsZSBzZWN1cml0eSBwcm90b2NvbCBpcyBhIG1ham9yIHBh aW4gaW4gdGhlIG5lY2suICBJcyB0aGUgbXV0YWJpbGl0eSBvZiBibG9ja3Mg4oCTIHRoZSBuZWVk IHRvIGV4Y2x1ZGUgbXV0YWJsZSBmaWVsZHMgZnJvbSBoYXNoIGNvbXB1dGF0aW9ucyDigJMgdGhl IG1haW4gcmVhc29uIGZvciBpdD8gIElzIHRoZXJlIG5vIHdheSB0byBzaW1wbGlmeT8NCkkgdGhp bmsgdGhlIG1ham9yIGlzc3VlIGlzIHRoZSBkaWN0aW9uYXJ5LCBzaW5jZSBpdCBjYW4gYmUgbW9k aWZpZWQgZXZlbiBpZiB0aGUgYWN0dWFsIGVpZCdzIGluIHRoZSBibG9jayBhcmUgc3RhYmxlLiAg VGhlIGZsYWdzIGFyZSBzdHJhaWdodGZvcndhcmQuICBJbiBCU1AsIHRoZXJlJ3MgYWxzbyBhIGJp ZyBpc3N1ZSB3aXRoIHRhaWwgY2hhc2luZyB3aGVuIGEgUElCIGJsb2NrIGlzIHJlcXVpcmVkIHRv IGluY2x1ZGUgY2h1bmtzIG9mIGl0c2VsZiBpbiBpdCdzIG93biBoYXNoLiAgSUlSQywgU0JTUCBh dm9pZHMgdGhhdCBlbnRpcmVseS4NCg0KPj4gICAgICAgICAgIFdoaWNoIGlzIGEgbWFqb3IgcmVh c29uIHRoYXQgSSB3YW50IHRvIGdldCByaWQgb2YgdGhlIGRpY3Rpb25hcnkgYWx0b2dldGhlciBp biDigJxSRkM1MDUwYmlz4oCdLg0KDQo= --_000_A5BEAD028815CB40A32A5669CF737C3B423B4F0Fapembxsp40RESAD_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAw IDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3Nl LTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhv bWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4t dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRh dGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24g VGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJh bGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4u RW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkdvb2QgcG9pbnRzLCBBbXkuJm5ic3A7IE15IHRob3VnaHRzIGxpa2V3aXNlIGluLWxpbmUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5TY290dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gQW15IEFsZm9yZCBbbWFpbHRvOmFsb29taXNAc2Fybi5vcmddDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gTW9uZGF5LCBKdW5lIDAyLCAyMDE0IDg6MzMgQU08YnI+DQo8Yj5Ubzo8L2I+IEJ1cmxlaWdo LCBTY290dCBDICgzMTJHKTxicj4NCjxiPkNjOjwvYj4gWm9sbGVyLCBEYXZpZCBBLiAoTVNGQy1F TzUwKVtIT1NDIFNFUlZJQ0VTIENPTlRSQUNUXTsgQmlycmFuZSwgRWR3YXJkIEouOyBkdG4tc2Vj dXJpdHlAaXJ0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtkdG4tc2VjdXJpdHldIFVw ZGF0ZWQgU0JTUCBEb2N1bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkknbSBhbHNvIHJlc3BvbmRpbmcgaW5saW5lLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBNYXkgMzAsIDIw MTQgYXQgMzoxNyBQTSwgQnVybGVpZ2gsIFNjb3R0IEMgKDMxMkcpICZsdDs8YSBocmVmPSJtYWls dG86c2NvdHQuYy5idXJsZWlnaEBqcGwubmFzYS5nb3YiIHRhcmdldD0iX2JsYW5rIj5zY290dC5j LmJ1cmxlaWdoQGpwbC5uYXNhLmdvdjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5BIGNvdXBsZSBvZiByZW1hcmtzIG9uIERhdmlk4oCZcyBjb21tZW50cywgaW4tbGluZSBi ZWxvdy48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PlNjb3R0PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gZHRuLXNlY3VyaXR5IFttYWlsdG86PGEgaHJlZj0i bWFpbHRvOmR0bi1zZWN1cml0eS1ib3VuY2VzQGlydGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZHRu LXNlY3VyaXR5LWJvdW5jZXNAaXJ0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5ab2xs ZXIsIERhdmlkIEEuIChNU0ZDLUVPNTApW0hPU0MgU0VSVklDRVMgQ09OVFJBQ1RdPGJyPg0KPGI+ U2VudDo8L2I+IFRodXJzZGF5LCBNYXkgMjksIDIwMTQgMTI6MDkgUE08YnI+DQo8Yj5Ubzo8L2I+ IEJpcnJhbmUsIEVkd2FyZCBKLjsgPGEgaHJlZj0ibWFpbHRvOmR0bi1zZWN1cml0eUBpcnRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHRuLXNlY3VyaXR5QGlydGYub3JnPC9hPjxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW2R0bi1zZWN1cml0eV0gVXBkYXRlZCBTQlNQIERvY3VtZW50PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwPkVkLDxvOnA+PC9vOnA+PC9wPg0KPHA+R29vZCB3b3JrIC0g dGhlIFNCU1Agc3BlYyBjb250aW51ZXMgdG8gZXZvbHZlIG5pY2VseS4gSeKAmWxsIGtpY2sgb2Zm IHRoZSBkaXNjdXNzaW9ucyB3aXRoIG15IGNvbW1lbnRzIGJlbG93LjxvOnA+PC9vOnA+PC9wPg0K PHA+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPHA+RFo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5bUGFn ZSAxMl0gMi40IEJ1bmRsZSBBdXRoZW50aWNhdGlvbiBCbG9jazwvYj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5UaGUgc2VjdXJpdHktdGFyZ2V0IE1VU1QgYmUgdGhlIGVudGlyZSBi dW5kbGUsIHdoaWNoIE1VU1QgYmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+cmVwcmVzZW50ZWQgYnkgYSAmbHQ7YmxvY2sgdHlwZSZndDsmbHQ7b2NjdXJyZW5jZSBudW1i ZXImZ3Q7IG9mICZsdDsweDAwJmd0OyZsdDsweDAwJmd0Oy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MjcuMHB0O3ZlcnRpY2FsLWFsaWdu Om1pZGRsZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1i b2w7Y29sb3I6IzAwQjA1MCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtj b2xvcjojMDBCMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+UGVyIDMuNCBCdW5kbGUg RnJhZ21lbnRhdGlvbiBhbmQgUmVhc3NlbWJseSwgYnVuZGxlIGF1dGhlbnRpY2F0aW9uIG1heSBi ZSBhcHBsaWVkIHRvIGJ1bmRsZSBmcmFnbWVudHMgYXMgd2VsbCBhcyBub24tZnJhZ21lbnRlZCBi dW5kbGVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDoyNy4wcHQ7dmVydGljYWwtYWxpZ246bWlkZGxlIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMDBCMDUwIj7Ctzwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMwMEIwNTAiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjojMDBCMDUwIj5JZiBhIGJ1bmRsZSBmcmFnbWVudCBpcyByZWNlaXZlZCB0aGF0IGhhcyBh IEJBQiwgdGhlcmUgaXMgbm8gd2F5IHRvIGRldGVybWluZSBpZiB0aGUgQkFCIGFwcGxpZXMgdG8g dGhlIGJ1bmRsZSBmcmFnbWVudCBvciBpZiBpdCBhcHBsaWVzIHRvIGFuIGVudGlyZSBidW5kbGUg dGhhdCB3YXMgbGF0ZXIgZnJhZ21lbnRlZCBieSBhIG5vbi1zZWN1cml0eS1hd2FyZSBCQS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6Ljc1 aW47dmVydGljYWwtYWxpZ246bWlkZGxlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMwMEIwNTAiPm88L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMDBCMDUwIj4mbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+SSBwcm9wb3NlIHRo YXQgYSAmbHQ7YmxvY2sgdHlwZSZndDsmbHQ7b2NjdXJyZW5jZSBudW1iZXImZ3Q7IG9mICZsdDsw eDAwJmd0OyZsdDtwYXlsb2FkIGZyYWcgbGVuZ3RoJmd0OyBpbmRpY2F0ZSB0aGF0IHRoZSBCQUIg YXBwbGllcyB0byBhIGJ1bmRsZSBmcmFnbWVudDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo4MS4wcHQ7dmVydGljYWwtYWxpZ246bWlkZGxl Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xv cjojMDBCMDUwIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMw MEIwNTAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5JZiBzdWNoIGEgYnVuZGxlIGZyYWdt ZW50IGlzIGZ1cnRoZXIgZnJhZ21lbnRlZCBieSBhIG5vbi1zZWN1cml0eS1hd2FyZSBCQSB0aGVu IHRoZSAmbHQ7cGF5bG9hZCBmcmFnIGxlbmd0aCZndDsgY2FuIGJlIHVzZWQgdG8gZGV0ZXJtaW5l IHRoYXQgdGhlIG9yaWdpbmFsIGZyYWdtZW50ZWQgYnVuZGxlIG11c3QgYmUgcmVhc3NlbWJsZWQg YmVmb3JlIGF1dGhlbnRpY2F0aW9uIGlzIGNoZWNrZWQgYmVjYXVzZQ0KIGl0IHdpbGwgbm90IG1h dGNoIHRoZSBsZW5ndGggZmllbGQgaW4gdGhlIHBheWxvYWQgYmxvY2suPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi43NWluO3ZlcnRpY2Fs LWFsaWduOm1pZGRsZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMDBCMDUwIj5vPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzAwQjA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPlNvbWUgZGlzY3Vzc2lvbiBtYXkgYmUg ZGVzaXJhYmxlIGluIHNlY3Rpb24gMy40IGFzIHdlbGwgYXMgMi40IGlmIGFjY2VwdGVkPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2lu Z2RpbmdzO2NvbG9yOiMxRjQ5N0QiPsOYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4w cHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPldoZW4gYSBCQUIgaXMgYXR0YWNoZWQgdG8gYSBidW5kbGUgdGhhdCBpcyBhIGZyYWdtZW50 LCB0aGUgYnVuZGxlIHRoYXQgaXQgYXBwbGllcyB0byBpcyBhbHdheXMgdGhhdCBmcmFnbWVudCwg bmV2ZXIgdGhlIGJ1bmRsZSB0aGF0IGNhcnJpZWQgdGhlIG9yaWdpbmFsIHBheWxvYWQgKG9mIHdo aWNoIHRoZSBjdXJyZW50IGJ1bmRsZeKAmXMgcGF5bG9hZCBpcyBhIGZyYWdtZW50KS4mbmJzcDsg U2luY2UNCiBCQUJzIGFyZSBub3QgZW5kLXRvLWVuZCwgdGhlIEJBQiBmb3IgYW4gb3JpZ2luYWwg dW4tZnJhZ21lbnRlZCBidW5kbGUgd2lsbCBuZXZlciBiZSBjYXJyaWVkIGZvcndhcmQgaW4gYW55 IGZyYWdtZW50cyBnZW5lcmF0ZWQgZnJvbSB0aGF0IGJ1bmRsZSAoc2VlIHRoZSBsYXN0IHBhcmFn cmFwaCBvZiAzLjMuMSksIHNvIHRoZXJl4oCZcyBubyBhbWJpZ3VpdHkuJm5ic3A7IEJ1dCB0aGlz IGRvZXMgYnJpbmcgdXAgYW4gaW1wb3J0YW50IHBvaW50OiB0aGUgYmxvY2sNCiBwcm9jZXNzaW5n IGNvbnRyb2wgZmxhZ3Mgb2YgdGhlIEJBQiBtdXN0IGFsd2F5cyBoYXZlIHRoZSDigJxyZXBsaWNh dGUgaW4gZXZlcnkgZnJhZ21lbnTigJ0gZmxhZyBzZXQgdG8gMC48L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWF5YmUgSSdtIG1pc3VuZGVyc3RhbmRpbmcgaGVy ZSwgYnV0IGZyYWdtZW50YXRpb24gY2FuIGhhcHBlbiBiZXR3ZWVuIGEgQkFCIHNvdXJjZSBhbmQg YSBCQUIgZGVzdCBpZiBhIG5vbi1zZWN1cml0eSBhd2FyZSBub2RlIGlzIGJldHdlZW4gdGhlIHR3 by4gJm5ic3A7UmVxdWlyaW5nIHRoZSAmcXVvdDtET19OT1RfRlJBR01FTlQmcXVvdDsgZmxhZyBz b2x2ZXMgdGhpcy48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBJIHNlZSB3aGF0IHlvdeKAmXJlIHNheWluZywgYW5kIEkgdGhpbmsgaXQgZ29lcyB0byB0 aGUgbGFtZW50IGluIHlvdXIgbmV4dCBjb21tZW50OiB0aGUgaW50ZXJhY3Rpb24gYmV0d2VlbiBm cmFnbWVudGF0aW9uIGFuZCBCU1AgcmVhbGx5IGlzIGEgbWVzcy4mbmJzcDsNCiBCdXQgSSB0aG91 Z2h0IFNCU1Agc2ltcGxpZmllZCB0aGluZ3Mgc29tZXdoYXQgYnkgbm90IGFsbG93aW5nIGFueSBu b24tc2VjdXJpdHktYXdhcmUgbm9kZXMgYmV0d2VlbiB0aGUgQkFCIHNvdXJjZSBhbmQgQkFCIGRl c3RpbmF0aW9uLiZuYnNwOyBBdCBsZWFzdCwgdGhhdOKAmXMgd2hhdCBJIGhvcGVkIHdlIHdlcmUg ZG9pbmcsIGFuZCBpdOKAmXMgaG93IEkgaW50ZXJwcmV0IOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj5CQUJzDQogb3BlcmF0ZSBiZXR3 ZWVuIHRvcG9sb2dpY2FsbHkgYWRqYWNlbnQgbm9kZXM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnSBvbiBwYWdlIDYuJm5ic3A7IElmIHRoYXTigJlz IG5vdCB0aGUgY2FzZSB0aGVuIEkgdGhpbmsgdGhlcmUgYXJlIGFkZGl0aW9uYWwgcHJvYmxlbXMg dG8gcmVzb2x2ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PGI+W1Bh Z2UgMTRdIDIuNiBCbG9jayBDb25maWRlbnRpYWxpdHkgQmxvY2s8L2I+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+VGhlIGJsb2NrIHByb2Nlc3NpbmcgY29udHJvbCBmbGFncyB2YWx1 ZSBjYW4gYmUgc2V0IHRvIHdoYXRldmVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPnZhbHVlcyBhcmUgcmVxdWlyZWQgYnkgbG9jYWwgcG9saWN5LCBleGNlcHQgdGhhdCBh IExvbmUgQkNCIG9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZpcnN0 IEJDQiBNVVNUIGhhdmUgdGhlICZxdW90O3JlcGxpY2F0ZSBpbiBldmVyeSBmcmFnbWVudCZxdW90 OyBmbGFnIHNldC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhpcyBp bmRpY2F0ZXMgdG8gYSByZWNlaXZpbmcgbm9kZSB0aGF0IHRoZSBwYXlsb2FkIHBvcnRpb24gaW48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ZWFjaCBmcmFnbWVudCByZXBy ZXNlbnRzIGNpcGhlci10ZXh0Lg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjI3LjBwdDt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMwMEIw NTAiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzAwQjA1MCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPlRoZSBpbnRlbnQgaGVyZSBpcyBvbmx5IGlmIHRo ZSB0YXJnZXQgb2YgdGhlIExvbmUgQkNCIG9yIEZpcnN0IEJDQiBpcyB0aGUgcGF5bG9hZCBibG9j ayB3aGljaCB3b3VsZCBuZWVkIHRvIGJlIGFkZGVkIGlmIHRoaXMgaXMga2VwdCBhcyBhIHJlcXVp cmVtZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDoyNy4wcHQ7dmVydGljYWwtYWxpZ246bWlkZGxlIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMDBCMDUwIj7Ctzwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMwMEIwNTAiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjojMDBCMDUwIj5JIHRoaW5rIHRoaXMgcmVxdWlyZW1lbnQgc2hvdWxkIGJlIHJlbW92ZWQg b3IgYXQgbGVhc3QgcmVkdWNlZCB0byBhICZxdW90O01BWSZxdW90Ozwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNzVpbjt2ZXJ0aWNhbC1h bGlnbjptaWRkbGUiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPjEuPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzAwQjA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPkl0 IGFzc3VtZXMgdGhhdCB0aGUgTG9uZSBvciBGaXJzdCBCQ0IgbXVzdCBiZSBwcmlvciB0byB0aGUg cGF5bG9hZCBibG9jayB3aGljaCBpcyBub3QgYSBzcGVjaWZpYyByZXF1aXJlbWVudCBhbmQgaXMg bm90IG5lY2Vzc2FyeSBpbiBhbnkgY2FzZSBmb3IgU0JTUDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNzVpbjt2ZXJ0aWNhbC1hbGlnbjpt aWRkbGUiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPjIuPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzAwQjA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPkEgQkNCIGJs b2NrIGNvdWxkIGJlIHF1aXRlIGxhcmdlIGFuZCBhZGQgYSBsb3Qgb2YgYmFuZHdpZHRoIG92ZXJo ZWFkIGlmIGluY2x1ZGVkIGluIGV2ZXJ5IGZyYWdtZW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi43NWluO3ZlcnRpY2FsLWFsaWduOm1p ZGRsZSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+My48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMDBCMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+SSBkbyBub3Qg c2VlIGEgYmVuZWZpdCBnYWluZWQgYnkgaW5jbHVkaW5nIHRoZSBibG9jayBpbiBldmVyeSBmcmFn bWVudA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjgxLjBwdDt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtjb2xvcjojMDBCMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzAw QjA1MCI+aS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMDBCMDUw Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+RXZlbiB0aGUg ZGVzdGluYXRpb24gbm9kZSBsaWtlbHkgY2Fubm90IGRlY3J5cHQgYW55IGluZGl2aWR1YWwgZnJh Z21lbnQgZXhjZXB0IHRoZSBmaXJzdCBvbmUgYW5kJm5ic3A7IGl0IHByb2JhYmx5IHdvdWxkIG9u bHkgZGVjcnlwdCBhIHBhcnRpYWwgYnVuZGxlIGFzIGEgbGFzdCByZXNvcnQgb3IgZm9yZW5zaWMg ZnVuY3Rpb24gaWYgdGhlIGVudGlyZSBidW5kbGUgd2FzIG5vdCByZWNlaXZlZA0KIGJlZm9yZSBl eHBpcmF0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjgxLjBwdDt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdDtjb2xvcjojMDBCMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPmlp Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMwMEIwNTAiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5JbnRlcm1lZGlhdGUgbm9k ZXMgc2hvdWxkbid0IGdlbmVyYWxseSBiZSBwb2tpbmcgYXJvdW5kIGluIGJ1bmRsZSBwYXlsb2Fk cyBhbnl3YXkgYW5kIG5vIG5lZWQgdG8gcHJvdmlkZSBhZGRpdGlvbmFsIGNsdWVzIGFzIHRvIHdo ZXRoZXIgYSBmcmFnbWVudCBwYXlsb2FkIGlzIGVuY3J5cHRlZCBvciBhIGJ1bmNoIG9mIGJpbmFy eSB2YWx1ZXMg4oCTIGtlZXAgdGhlIGJhZCBndXlzIGd1ZXNzaW5nDQogYW5kIHdhc3RpbmcgQ1BV IGN5Y2xlcyBpZiBwb3NzaWJsZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDo4MS4wcHQ7dmVydGljYWwtYWxpZ246bWlkZGxlIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzAwQjA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUw Ij5paWkuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzAwQjA1MCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPkJTUCBpbmNsdWRl cyB0aGlzIHJlcXVpcmVtZW50IC0gaGF2ZSBhbnkgb2YgdGhlIGltcGxlbWVudGF0aW9ucyBmb3Vu ZCBhIG5lZWQgb3IgYmVuZWZpdCBmb3IgdGhpcyBhbmQgd291bGQgaXQgc3RpbGwgYXBwbHkgaW4g Y29udGV4dCBvZiB0aGUgU0JTUD88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIHN0 eWxlPSJ2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5n ZGluZ3M7Y29sb3I6IzFGNDk3RCI+w5g8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dDtjb2xvcjojMUY0OTdEIj4mbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+SSB0aGluayB0aGlzIGEgZ29vZCBwb2ludC4mbmJzcDsgU2luY2UgYWxsIGRlY3J5cHRpb24g c2hvdWxkIG9ubHkgaGFwcGVuIGF0IHRoZSBidW5kbGUgZGVzdGluYXRpb24sIHdoaWNoIGlzIHdo ZXJlIGFsbCB0aGUgZnJhZ21lbnRzIGFyZSBnb2luZyB0byBoYXZlIHRvIGVuZCB1cCwgd2h5IG5v dCBmb3J3YXJkIGFsbCBCQ0JzIChmb3IgYWxsIGJsb2NrcyB0aGF0IGhhdmUgdGhlbSkgb25seSB3 aXRoDQogdGhlIGZyYWdtZW50IHdob3NlIG9mZnNldCBpcyB6ZXJvPyZuYnNwOyAmbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIHRoZXJlIGEgcG9zc2liaWxpdHkgb2YgYW4gaW50ZXJt ZWRpYXRlIG5vZGUgYWRkaW5nIGEgQklCIHRvIHRoZSBmcmFnbWVudCwgdW5hd2FyZSB0aGF0IHRo ZXJlJ3MgYWxyZWFkeSBhIEJDQiBvbiB0aGUgd2hvbGUgcGF5bG9hZD8gJm5ic3A7SSByZWFsbHkg aGF0ZSB0aGUgaW50ZXJhY3Rpb24gYmV0d2VlbiBmcmFnbWVudGF0aW9uIGFuZCBCU1AuICZuYnNw O0kgZmVlbCBsaWtlIHRpZ2h0bHkgbG9ja2luZyBkb3duIGhvdyB0aGUNCiB0d28gb2YgdGhlbSBj b21iaW5lIGF2b2lkcyBhIGxvdCBvZiBwaXRmYWxscyBhbmQgYW1iaWd1aXR5LjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBJcyB0aGVyZSBhbnkgcmVhbCBuZWVkIHRvIGFsbG93IHBheWxvYWQgQklCcyBhbmQgQkNC cyB0byBiZSBhZGRlZCBpbiBidW5kbGVzIHRoYXQgYXJlIGZyYWdtZW50cz8mbmJzcDsgV2h5IG5v dCBqdXN0IHByb2hpYml0IHRoYXQ/Jm5ic3A7IElmIGl04oCZcyBhYnNvbHV0ZWx5DQogbmVjZXNz YXJ5IGZvciBzb21lIHVuZmF0aG9tYWJsZSByZWFzb24sIHVzZSBidW5kbGUtaW4tYnVuZGxlIGVu Y2Fwc3VsYXRpb24gdG8gZW5jYXBzdWxhdGUgdGhlIGZyYWdtZW50YXJ5IGJ1bmRsZSBhcyB0aGUg cGF5bG9hZCBvZiBhIG5ldyBidW5kbGUgYW5kIGF0dGFjaCB0aGUgQklCIG9yIEJDQiB0byB0aGUg ZW5jYXBzdWxhdGluZyBidW5kbGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PltQYWdlIDI0XSAzLjEuMi4zIEV4dGVuc2lvbiBCbG9jayBDYW5vbmljYWxpemF0aW9uPC9iPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoZSBibG9jay1sZW5ndGggaXMgY2Fub25p Y2FsaXplZCBhcyBpdHMgdW5wYWNrZWQgU0ROViB2YWx1ZS4mbmJzcDsgSWYgdGhlPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmRhdGEgdG8gYmUgY2Fub25pY2FsaXplZCBp cyBsZXNzIHRoYW4gdGhlIGNvbXBsZXRlLCBvcmlnaW5hbCBibG9jazwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5kYXRhLCB0aGlzIGZpZWxkIGNvbnRhaW5zIHRoZSBzaXpl IG9mIHRoZSBkYXRhIGJlaW5nIGNhbm9uaWNhbGl6ZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+KHRoZSAmcXVvdDtlZmZlY3RpdmUgYmxvY2smcXVvdDspIHJhdGhlciB0 aGFuIHRoZSBhY3R1YWwgc2l6ZSBvZiB0aGUgYmxvY2suPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjI3LjBwdDt2ZXJ0aWNhbC1hbGlnbjpt aWRkbGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9s O2NvbG9yOiMwMEIwNTAiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29s b3I6IzAwQjA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPlNlY3Rpb24gMy4xLjIuMSAo UHJpbWFyeSBCbG9jayBDYW5vbmljYWxpemF0aW9uKSBkZXRhaWxzIHRoZSBsZW5ndGggZmllbGRz IGFzIDQgYnl0ZSB2YWx1ZXMgYW5kIGVmZmVjdGl2ZWx5IHJlc2VydmVzIHRoZSB0ZXJtICZxdW90 O3VucGFja2VkIFNETlYgdmFsdWUmcXVvdDsgdG8gbWVhbiB0aGUgOCBieXRlIHZhbHVlLiBJIHJl Y29tbWVuZCB1c2luZyB0aGUgc2FtZSBjb252ZW50aW9uIGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi43NWluO3ZlcnRpY2FsLWFs aWduOm1pZGRsZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMDBCMDUwIj5vPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzAwQjA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPlBlcnNvbmFsbHksIEkgd291bGQgc3BlY2lm eSBhbGwgU0ROViB2YWx1ZXMgY2Fub25pY2FsaXplZCBhcyA4IGJ5dGUgdmFsdWVzIGFuZCBiZSBk b25lIHdpdGggaXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MjcuMHB0O3ZlcnRpY2FsLWFsaWduOm1pZGRsZSI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzAwQjA1MCI+wrc8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMDBCMDUwIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6IzAwQjA1MCI+QWRkIGEgc3RhdGVtZW50IHRvIHRoZSBlZmZlY3Q6PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi43NWluO3Zl cnRpY2FsLWFsaWduOm1pZGRsZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMDBCMDUwIj5vPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzAwQjA1MCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPlRoZSBlbnRpcmV0eSBvciBw b3J0aW9uKHMpIG9mIHRoZSBibG9jayBib2R5IGRhdGEgYXJlIGNhbm9uaWNhbGl6ZWQgYXMgaXMu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBzdHlsZT0idmVydGljYWwtYWxpZ246 bWlkZGxlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0Qi PsOYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgYWJvdXQgY2Fu b25pY2FsaXppbmcgYWxsIFNETlZzIGFzIDgtYnl0ZSB2YWx1ZXMuJm5ic3A7IEZXSVcsIEkgdGhp bmsgdGhlIGNhbm9uaWNhbGl6YXRpb24gaW4gYnVuZGxlIHNlY3VyaXR5IHByb3RvY29sIGlzIGEg bWFqb3IgcGFpbiBpbiB0aGUgbmVjay4mbmJzcDsgSXMgdGhlIG11dGFiaWxpdHkgb2YgYmxvY2tz IOKAkyB0aGUgbmVlZCB0byBleGNsdWRlIG11dGFibGUgZmllbGRzIGZyb20gaGFzaA0KIGNvbXB1 dGF0aW9ucyDigJMgdGhlIG1haW4gcmVhc29uIGZvciBpdD8mbmJzcDsgSXMgdGhlcmUgbm8gd2F5 IHRvIHNpbXBsaWZ5Pzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgdGhpbmsgdGhlIG1ham9yIGlzc3VlIGlzIHRoZSBkaWN0aW9uYXJ5LCBzaW5jZSBpdCBjYW4g YmUgbW9kaWZpZWQgZXZlbiBpZiB0aGUgYWN0dWFsIGVpZCdzIGluIHRoZSBibG9jayBhcmUgc3Rh YmxlLiAmbmJzcDtUaGUgZmxhZ3MgYXJlIHN0cmFpZ2h0Zm9yd2FyZC4gJm5ic3A7SW4gQlNQLCB0 aGVyZSdzIGFsc28gYSBiaWcgaXNzdWUgd2l0aCB0YWlsIGNoYXNpbmcgd2hlbiBhIFBJQiBibG9j ayBpcyByZXF1aXJlZCB0byBpbmNsdWRlDQogY2h1bmtzIG9mIGl0c2VsZiBpbiBpdCdzIG93biBo YXNoLiAmbmJzcDtJSVJDLCBTQlNQIGF2b2lkcyB0aGF0IGVudGlyZWx5LjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBXaGljaCBpcyBhIG1ham9yIHJlYXNvbiB0aGF0IEkgd2FudCB0byBnZXQgcmlkIG9mIHRoZSBk aWN0aW9uYXJ5IGFsdG9nZXRoZXIgaW4g4oCcUkZDNTA1MGJpc+KAnS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_A5BEAD028815CB40A32A5669CF737C3B423B4F0Fapembxsp40RESAD_-- From nobody Mon Jun 2 09:27:24 2014 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9981A037C for ; Mon, 2 Jun 2014 09:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJh7cFMOyljJ for ; Mon, 2 Jun 2014 09:27:20 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id F08461A0234 for ; Mon, 2 Jun 2014 09:27:19 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 596BB1F0674; Mon, 2 Jun 2014 12:27:14 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 461851F069C; Mon, 2 Jun 2014 12:27:14 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.73]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Mon, 2 Jun 2014 12:27:14 -0400 From: "Scott, Keith L." To: Amy Alford , "Burleigh, Scott C (312G)" Thread-Topic: [dtn-security] Updated SBSP Document Thread-Index: Ac96egHBtIlHfqjpRHK8eG5est6OOQA736HgADK/lpAAmTmlgAAHdBcA Date: Mon, 2 Jun 2014 16:27:13 +0000 Message-ID: <5EE81C5C4CFFF4418C5EAD12F49D64EE4C2219F2@IMCMBX01.MITRE.ORG> References: <329D879C76FDD04AAAE84BB1D89B3970094FBF9EAA@aplesfreedom.dom1.jhuapl.edu> <94CFB3711B4CAE4DBFC5BEB3374BF0C60D1835@NDMSMBX404.ndc.nasa.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.140.19.249] Content-Type: multipart/alternative; boundary="_000_5EE81C5C4CFFF4418C5EAD12F49D64EE4C2219F2IMCMBX01MITREOR_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/DRhUZ_R5twzwBzVUs2gaTEtI8rQ Cc: "dtn-security@irtf.org" Subject: Re: [dtn-security] Updated SBSP Document X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 16:27:23 -0000 --_000_5EE81C5C4CFFF4418C5EAD12F49D64EE4C2219F2IMCMBX01MITREOR_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29tZSBjb21tZW50cyBpbi1saW5lIGJlbG93Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAt LWtlaXRoDQoNCkZyb206IGR0bi1zZWN1cml0eSBbbWFpbHRvOmR0bi1zZWN1cml0eS1ib3VuY2Vz QGlydGYub3JnXSBPbiBCZWhhbGYgT2YgQW15IEFsZm9yZA0KU2VudDogTW9uZGF5LCBKdW5lIDAy LCAyMDE0IDExOjMzIEFNDQpUbzogQnVybGVpZ2gsIFNjb3R0IEMgKDMxMkcpDQpDYzogZHRuLXNl Y3VyaXR5QGlydGYub3JnDQpTdWJqZWN0OiBSZTogW2R0bi1zZWN1cml0eV0gVXBkYXRlZCBTQlNQ IERvY3VtZW50DQoNCkknbSBhbHNvIHJlc3BvbmRpbmcgaW5saW5lLg0KDQpPbiBGcmksIE1heSAz MCwgMjAxNCBhdCAzOjE3IFBNLCBCdXJsZWlnaCwgU2NvdHQgQyAoMzEyRykgPHNjb3R0LmMuYnVy bGVpZ2hAanBsLm5hc2EuZ292PG1haWx0bzpzY290dC5jLmJ1cmxlaWdoQGpwbC5uYXNhLmdvdj4+ IHdyb3RlOg0KQSBjb3VwbGUgb2YgcmVtYXJrcyBvbiBEYXZpZOKAmXMgY29tbWVudHMsIGluLWxp bmUgYmVsb3cuDQoNClNjb3R0DQoNCkZyb206IGR0bi1zZWN1cml0eSBbbWFpbHRvOmR0bi1zZWN1 cml0eS1ib3VuY2VzQGlydGYub3JnPG1haWx0bzpkdG4tc2VjdXJpdHktYm91bmNlc0BpcnRmLm9y Zz5dIE9uIEJlaGFsZiBPZiBab2xsZXIsIERhdmlkIEEuIChNU0ZDLUVPNTApW0hPU0MgU0VSVklD RVMgQ09OVFJBQ1RdDQpTZW50OiBUaHVyc2RheSwgTWF5IDI5LCAyMDE0IDEyOjA5IFBNDQpUbzog QmlycmFuZSwgRWR3YXJkIEouOyBkdG4tc2VjdXJpdHlAaXJ0Zi5vcmc8bWFpbHRvOmR0bi1zZWN1 cml0eUBpcnRmLm9yZz4NClN1YmplY3Q6IFJlOiBbZHRuLXNlY3VyaXR5XSBVcGRhdGVkIFNCU1Ag RG9jdW1lbnQNCg0KDQpFZCwNCg0KR29vZCB3b3JrIC0gdGhlIFNCU1Agc3BlYyBjb250aW51ZXMg dG8gZXZvbHZlIG5pY2VseS4gSeKAmWxsIGtpY2sgb2ZmIHRoZSBkaXNjdXNzaW9ucyB3aXRoIG15 IGNvbW1lbnRzIGJlbG93Lg0KDQpDaGVlcnMsDQoNCkRaDQoNCg0KDQoNCg0KDQpbUGFnZSAxMl0g Mi40IEJ1bmRsZSBBdXRoZW50aWNhdGlvbiBCbG9jaw0KVGhlIHNlY3VyaXR5LXRhcmdldCBNVVNU IGJlIHRoZSBlbnRpcmUgYnVuZGxlLCB3aGljaCBNVVNUIGJlDQpyZXByZXNlbnRlZCBieSBhIDxi bG9jayB0eXBlPjxvY2N1cnJlbmNlIG51bWJlcj4gb2YgPDB4MDA+PDB4MDA+Lg0K4oCiICAgICAg ICAgUGVyIDMuNCBCdW5kbGUgRnJhZ21lbnRhdGlvbiBhbmQgUmVhc3NlbWJseSwgYnVuZGxlIGF1 dGhlbnRpY2F0aW9uIG1heSBiZSBhcHBsaWVkIHRvIGJ1bmRsZSBmcmFnbWVudHMgYXMgd2VsbCBh cyBub24tZnJhZ21lbnRlZCBidW5kbGVzLg0K4oCiICAgICAgICAgSWYgYSBidW5kbGUgZnJhZ21l bnQgaXMgcmVjZWl2ZWQgdGhhdCBoYXMgYSBCQUIsIHRoZXJlIGlzIG5vIHdheSB0byBkZXRlcm1p bmUgaWYgdGhlIEJBQiBhcHBsaWVzIHRvIHRoZSBidW5kbGUgZnJhZ21lbnQgb3IgaWYgaXQgYXBw bGllcyB0byBhbiBlbnRpcmUgYnVuZGxlIHRoYXQgd2FzIGxhdGVyIGZyYWdtZW50ZWQgYnkgYSBu b24tc2VjdXJpdHktYXdhcmUgQkEuDQpvICAgIEkgcHJvcG9zZSB0aGF0IGEgPGJsb2NrIHR5cGU+ PG9jY3VycmVuY2UgbnVtYmVyPiBvZiA8MHgwMD48cGF5bG9hZCBmcmFnIGxlbmd0aD4gaW5kaWNh dGUgdGhhdCB0aGUgQkFCIGFwcGxpZXMgdG8gYSBidW5kbGUgZnJhZ21lbnQNCuKAoiAgICAgICAg IElmIHN1Y2ggYSBidW5kbGUgZnJhZ21lbnQgaXMgZnVydGhlciBmcmFnbWVudGVkIGJ5IGEgbm9u LXNlY3VyaXR5LWF3YXJlIEJBIHRoZW4gdGhlIDxwYXlsb2FkIGZyYWcgbGVuZ3RoPiBjYW4gYmUg dXNlZCB0byBkZXRlcm1pbmUgdGhhdCB0aGUgb3JpZ2luYWwgZnJhZ21lbnRlZCBidW5kbGUgbXVz dCBiZSByZWFzc2VtYmxlZCBiZWZvcmUgYXV0aGVudGljYXRpb24gaXMgY2hlY2tlZCBiZWNhdXNl IGl0IHdpbGwgbm90IG1hdGNoIHRoZSBsZW5ndGggZmllbGQgaW4gdGhlIHBheWxvYWQgYmxvY2su DQpvICAgIFNvbWUgZGlzY3Vzc2lvbiBtYXkgYmUgZGVzaXJhYmxlIGluIHNlY3Rpb24gMy40IGFz IHdlbGwgYXMgMi40IGlmIGFjY2VwdGVkDQoNCj4gIFdoZW4gYSBCQUIgaXMgYXR0YWNoZWQgdG8g YSBidW5kbGUgdGhhdCBpcyBhIGZyYWdtZW50LCB0aGUgYnVuZGxlIHRoYXQgaXQgYXBwbGllcyB0 byBpcyBhbHdheXMgdGhhdCBmcmFnbWVudCwgbmV2ZXIgdGhlIGJ1bmRsZSB0aGF0IGNhcnJpZWQg dGhlIG9yaWdpbmFsIHBheWxvYWQgKG9mIHdoaWNoIHRoZSBjdXJyZW50IGJ1bmRsZeKAmXMgcGF5 bG9hZCBpcyBhIGZyYWdtZW50KS4gIFNpbmNlIEJBQnMgYXJlIG5vdCBlbmQtdG8tZW5kLCB0aGUg QkFCIGZvciBhbiBvcmlnaW5hbCB1bi1mcmFnbWVudGVkIGJ1bmRsZSB3aWxsIG5ldmVyIGJlIGNh cnJpZWQgZm9yd2FyZCBpbiBhbnkgZnJhZ21lbnRzIGdlbmVyYXRlZCBmcm9tIHRoYXQgYnVuZGxl IChzZWUgdGhlIGxhc3QgcGFyYWdyYXBoIG9mIDMuMy4xKSwgc28gdGhlcmXigJlzIG5vIGFtYmln dWl0eS4gIEJ1dCB0aGlzIGRvZXMgYnJpbmcgdXAgYW4gaW1wb3J0YW50IHBvaW50OiB0aGUgYmxv Y2sgcHJvY2Vzc2luZyBjb250cm9sIGZsYWdzIG9mIHRoZSBCQUIgbXVzdCBhbHdheXMgaGF2ZSB0 aGUg4oCccmVwbGljYXRlIGluIGV2ZXJ5IGZyYWdtZW504oCdIGZsYWcgc2V0IHRvIDAuDQoNCk1h eWJlIEknbSBtaXN1bmRlcnN0YW5kaW5nIGhlcmUsIGJ1dCBmcmFnbWVudGF0aW9uIGNhbiBoYXBw ZW4gYmV0d2VlbiBhIEJBQiBzb3VyY2UgYW5kIGEgQkFCIGRlc3QgaWYgYSBub24tc2VjdXJpdHkg YXdhcmUgbm9kZSBpcyBiZXR3ZWVuIHRoZSB0d28uICBSZXF1aXJpbmcgdGhlICJET19OT1RfRlJB R01FTlQiIGZsYWcgc29sdmVzIHRoaXMuDQoNCkJBQnMgc2hvdWxkIGJlIGFwcGxpZWQg4oCYcG9p bnQtdG8tcG9pbnTigJkgYmV0d2VlbiBidW5kbGUgYWdlbnRzOyB0aGVyZSBzaG91bGRu4oCZdCBi ZSBhbiBvcHBvcnR1bml0eSBmb3IgYSBub24tc2VjdXJpdHktYXdhcmUgbm9kZSB0byBmcmFnbWVu dCBhIGJ1bmRsZSB3aXRoIGEgQkFCIG9uIGl0LiAgSeKAmWxsIGhhdmUgdG8gY2hlY2sgdGhlIGNy b3NzLXByb2R1Y3QgYmV0d2VlbiBlbmNhcHN1bGF0aW9uIGFuZCBCQUIgKGkuZS4gd2hldGhlciB5 b3UgY2FuIGVuY2Fwc3VsYXRlIGEgYnVuZGxlIHdpdGggYSBCQUIgb24gaXQgKGFuZCB0aGVuIHBv c3NpYmx5IGZyYWdtZW50IHRoZSBlbmNhcHN1bGF0aW5nIGJ1bmRsZSkgb3Igbm90KS4gIEkgc3Vz cGVjdCB0aGF0IHRoZSBhbnN3ZXIgaXMg4oCYbm/igJkgKGkuZS4geW91IGNoZWNrIC8gcmVtb3Zl IHRoZSBCQUIgaW1tZWRpYXRlbHkgb24gcmVjZWlwdCBhbmQgYmVmb3JlIHlvdSBlbmNhcHN1bGF0 ZSBhbmQvb3IgZnJhZ21lbnQgZm9yIHRyYW5zbWlzc2lvbikuDQoNCg0KDQpbUGFnZSAxNF0gMi42 IEJsb2NrIENvbmZpZGVudGlhbGl0eSBCbG9jaw0KVGhlIGJsb2NrIHByb2Nlc3NpbmcgY29udHJv bCBmbGFncyB2YWx1ZSBjYW4gYmUgc2V0IHRvIHdoYXRldmVyDQp2YWx1ZXMgYXJlIHJlcXVpcmVk IGJ5IGxvY2FsIHBvbGljeSwgZXhjZXB0IHRoYXQgYSBMb25lIEJDQiBvcg0KRmlyc3QgQkNCIE1V U1QgaGF2ZSB0aGUgInJlcGxpY2F0ZSBpbiBldmVyeSBmcmFnbWVudCIgZmxhZyBzZXQuDQpUaGlz IGluZGljYXRlcyB0byBhIHJlY2VpdmluZyBub2RlIHRoYXQgdGhlIHBheWxvYWQgcG9ydGlvbiBp bg0KZWFjaCBmcmFnbWVudCByZXByZXNlbnRzIGNpcGhlci10ZXh0Lg0K4oCiICAgICAgICAgVGhl IGludGVudCBoZXJlIGlzIG9ubHkgaWYgdGhlIHRhcmdldCBvZiB0aGUgTG9uZSBCQ0Igb3IgRmly c3QgQkNCIGlzIHRoZSBwYXlsb2FkIGJsb2NrIHdoaWNoIHdvdWxkIG5lZWQgdG8gYmUgYWRkZWQg aWYgdGhpcyBpcyBrZXB0IGFzIGEgcmVxdWlyZW1lbnQuDQrigKIgICAgICAgICBJIHRoaW5rIHRo aXMgcmVxdWlyZW1lbnQgc2hvdWxkIGJlIHJlbW92ZWQgb3IgYXQgbGVhc3QgcmVkdWNlZCB0byBh ICJNQVkiDQoxLiAgICAgICBJdCBhc3N1bWVzIHRoYXQgdGhlIExvbmUgb3IgRmlyc3QgQkNCIG11 c3QgYmUgcHJpb3IgdG8gdGhlIHBheWxvYWQgYmxvY2sgd2hpY2ggaXMgbm90IGEgc3BlY2lmaWMg cmVxdWlyZW1lbnQgYW5kIGlzIG5vdCBuZWNlc3NhcnkgaW4gYW55IGNhc2UgZm9yIFNCU1ANCjIu ICAgICAgIEEgQkNCIGJsb2NrIGNvdWxkIGJlIHF1aXRlIGxhcmdlIGFuZCBhZGQgYSBsb3Qgb2Yg YmFuZHdpZHRoIG92ZXJoZWFkIGlmIGluY2x1ZGVkIGluIGV2ZXJ5IGZyYWdtZW50DQozLiAgICAg ICBJIGRvIG5vdCBzZWUgYSBiZW5lZml0IGdhaW5lZCBieSBpbmNsdWRpbmcgdGhlIGJsb2NrIGlu IGV2ZXJ5IGZyYWdtZW50DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBp LiAgICAgICAgICAgIEV2ZW4gdGhlIGRlc3RpbmF0aW9uIG5vZGUgbGlrZWx5IGNhbm5vdCBkZWNy eXB0IGFueSBpbmRpdmlkdWFsIGZyYWdtZW50IGV4Y2VwdCB0aGUgZmlyc3Qgb25lIGFuZCAgaXQg cHJvYmFibHkgd291bGQgb25seSBkZWNyeXB0IGEgcGFydGlhbCBidW5kbGUgYXMgYSBsYXN0IHJl c29ydCBvciBmb3JlbnNpYyBmdW5jdGlvbiBpZiB0aGUgZW50aXJlIGJ1bmRsZSB3YXMgbm90IHJl Y2VpdmVkIGJlZm9yZSBleHBpcmF0aW9uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgaWkuICAgICAgICAgICAgSW50ZXJtZWRpYXRlIG5vZGVzIHNob3VsZG4ndCBnZW5lcmFs bHkgYmUgcG9raW5nIGFyb3VuZCBpbiBidW5kbGUgcGF5bG9hZHMgYW55d2F5IGFuZCBubyBuZWVk IHRvIHByb3ZpZGUgYWRkaXRpb25hbCBjbHVlcyBhcyB0byB3aGV0aGVyIGEgZnJhZ21lbnQgcGF5 bG9hZCBpcyBlbmNyeXB0ZWQgb3IgYSBidW5jaCBvZiBiaW5hcnkgdmFsdWVzIOKAkyBrZWVwIHRo ZSBiYWQgZ3V5cyBndWVzc2luZyBhbmQgd2FzdGluZyBDUFUgY3ljbGVzIGlmIHBvc3NpYmxlDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpaWkuICAgICAgICAgICAgQlNQIGlu Y2x1ZGVzIHRoaXMgcmVxdWlyZW1lbnQgLSBoYXZlIGFueSBvZiB0aGUgaW1wbGVtZW50YXRpb25z IGZvdW5kIGEgbmVlZCBvciBiZW5lZml0IGZvciB0aGlzIGFuZCB3b3VsZCBpdCBzdGlsbCBhcHBs eSBpbiBjb250ZXh0IG9mIHRoZSBTQlNQPw0KDQo+ICBJIHRoaW5rIHRoaXMgYSBnb29kIHBvaW50 LiAgU2luY2UgYWxsIGRlY3J5cHRpb24gc2hvdWxkIG9ubHkgaGFwcGVuIGF0IHRoZSBidW5kbGUg ZGVzdGluYXRpb24sIHdoaWNoIGlzIHdoZXJlIGFsbCB0aGUgZnJhZ21lbnRzIGFyZSBnb2luZyB0 byBoYXZlIHRvIGVuZCB1cCwgd2h5IG5vdCBmb3J3YXJkIGFsbCBCQ0JzIChmb3IgYWxsIGJsb2Nr cyB0aGF0IGhhdmUgdGhlbSkgb25seSB3aXRoIHRoZSBmcmFnbWVudCB3aG9zZSBvZmZzZXQgaXMg emVybz8NCklzIHRoZXJlIGEgcG9zc2liaWxpdHkgb2YgYW4gaW50ZXJtZWRpYXRlIG5vZGUgYWRk aW5nIGEgQklCIHRvIHRoZSBmcmFnbWVudCwgdW5hd2FyZSB0aGF0IHRoZXJlJ3MgYWxyZWFkeSBh IEJDQiBvbiB0aGUgd2hvbGUgcGF5bG9hZD8gIEkgcmVhbGx5IGhhdGUgdGhlIGludGVyYWN0aW9u IGJldHdlZW4gZnJhZ21lbnRhdGlvbiBhbmQgQlNQLiAgSSBmZWVsIGxpa2UgdGlnaHRseSBsb2Nr aW5nIGRvd24gaG93IHRoZSB0d28gb2YgdGhlbSBjb21iaW5lIGF2b2lkcyBhIGxvdCBvZiBwaXRm YWxscyBhbmQgYW1iaWd1aXR5Lg0KDQpNeSBub3Rpb24gaXMgdGhhdCB0aGUgQkNCIHNob3VsZCBh cHBseSB0byB0aGUgZW50aXJlICh1bmZyYWdtZW50ZWQpIHBheWxvYWQuICBJZiBpdOKAmXMgcG9z c2libGUgdG8gYXBwbHkgYSBCQ0IgdG8gYSBmcmFnbWVudCAoaW4gdGhlIG1pZGRsZSBvZiBhIHBh dGggYW5kIGNvbm5lY3Rpb24pIHRoZW4gdGhlIEJDQiBpdHNlbGYgaGFkIGJldHRlciBzdGF0ZSB0 byB3aGljaCBieXRlcyBvZiB0aGUgcGF5bG9hZCBpdCBhcHBsaWVzLCBvciBpdOKAmXMgZ29pbmcg dG8gYmUgcmVhbGx5IGhhcmQgdG8gc29ydCBpdCBvdXQgbGF0ZXIuDQoNCldoYXTigJlzIHRoZSBy YXRpb25hbGUgZm9yIHJlcGxpY2F0aW9uPyAgVGhlIGRlc3RpbmF0aW9uIGlzIHRoZSBvbmx5IG5v ZGUgdGhhdOKAmXMgZ29pbmcgdG8gaGF2ZSB0byBkZWFsIHdpdGggZGVjcnlwdGlvbiwgc28gd2hh dCBpcyB0aGlzIGRvaW5nPyAgSXMgdGhlIG5vdGlvbiB0aGF0IHRoZSByZWNlaXZlciBtaWdodCBw YXNzIHBhcnRzIG9mIHRoZSBub3QteWV0LWZ1bGx5LXJlY2VpdmVkIGJ1bmRsZSB0byB0aGUgYXBw bGljYXRpb24/ICBUaGF0IHdvdWxkIGJlLCBJIHRoaW5rLCB3cm9uZy4NCg0KDQoNCg0KW1BhZ2Ug MjRdIDMuMS4yLjMgRXh0ZW5zaW9uIEJsb2NrIENhbm9uaWNhbGl6YXRpb24NClRoZSBibG9jay1s ZW5ndGggaXMgY2Fub25pY2FsaXplZCBhcyBpdHMgdW5wYWNrZWQgU0ROViB2YWx1ZS4gIElmIHRo ZQ0KZGF0YSB0byBiZSBjYW5vbmljYWxpemVkIGlzIGxlc3MgdGhhbiB0aGUgY29tcGxldGUsIG9y aWdpbmFsIGJsb2NrDQpkYXRhLCB0aGlzIGZpZWxkIGNvbnRhaW5zIHRoZSBzaXplIG9mIHRoZSBk YXRhIGJlaW5nIGNhbm9uaWNhbGl6ZWQNCih0aGUgImVmZmVjdGl2ZSBibG9jayIpIHJhdGhlciB0 aGFuIHRoZSBhY3R1YWwgc2l6ZSBvZiB0aGUgYmxvY2suDQrigKIgICAgICAgICBTZWN0aW9uIDMu MS4yLjEgKFByaW1hcnkgQmxvY2sgQ2Fub25pY2FsaXphdGlvbikgZGV0YWlscyB0aGUgbGVuZ3Ro IGZpZWxkcyBhcyA0IGJ5dGUgdmFsdWVzIGFuZCBlZmZlY3RpdmVseSByZXNlcnZlcyB0aGUgdGVy bSAidW5wYWNrZWQgU0ROViB2YWx1ZSIgdG8gbWVhbiB0aGUgOCBieXRlIHZhbHVlLiBJIHJlY29t bWVuZCB1c2luZyB0aGUgc2FtZSBjb252ZW50aW9uIGhlcmUuDQpvICAgIFBlcnNvbmFsbHksIEkg d291bGQgc3BlY2lmeSBhbGwgU0ROViB2YWx1ZXMgY2Fub25pY2FsaXplZCBhcyA4IGJ5dGUgdmFs dWVzIGFuZCBiZSBkb25lIHdpdGggaXQNCuKAoiAgICAgICAgIEFkZCBhIHN0YXRlbWVudCB0byB0 aGUgZWZmZWN0Og0KbyAgICBUaGUgZW50aXJldHkgb3IgcG9ydGlvbihzKSBvZiB0aGUgYmxvY2sg Ym9keSBkYXRhIGFyZSBjYW5vbmljYWxpemVkIGFzIGlzLg0KDQo+ICBJIGFncmVlIGFib3V0IGNh bm9uaWNhbGl6aW5nIGFsbCBTRE5WcyBhcyA4LWJ5dGUgdmFsdWVzLiAgRldJVywgSSB0aGluayB0 aGUgY2Fub25pY2FsaXphdGlvbiBpbiBidW5kbGUgc2VjdXJpdHkgcHJvdG9jb2wgaXMgYSBtYWpv ciBwYWluIGluIHRoZSBuZWNrLiAgSXMgdGhlIG11dGFiaWxpdHkgb2YgYmxvY2tzIOKAkyB0aGUg bmVlZCB0byBleGNsdWRlIG11dGFibGUgZmllbGRzIGZyb20gaGFzaCBjb21wdXRhdGlvbnMg4oCT IHRoZSBtYWluIHJlYXNvbiBmb3IgaXQ/ICBJcyB0aGVyZSBubyB3YXkgdG8gc2ltcGxpZnk/DQoN CkkgdGhpbmsgdGhlIG1ham9yIGlzc3VlIGlzIHRoZSBkaWN0aW9uYXJ5LCBzaW5jZSBpdCBjYW4g YmUgbW9kaWZpZWQgZXZlbiBpZiB0aGUgYWN0dWFsIGVpZCdzIGluIHRoZSBibG9jayBhcmUgc3Rh YmxlLiAgVGhlIGZsYWdzIGFyZSBzdHJhaWdodGZvcndhcmQuICBJbiBCU1AsIHRoZXJlJ3MgYWxz byBhIGJpZyBpc3N1ZSB3aXRoIHRhaWwgY2hhc2luZyB3aGVuIGEgUElCIGJsb2NrIGlzIHJlcXVp cmVkIHRvIGluY2x1ZGUgY2h1bmtzIG9mIGl0c2VsZiBpbiBpdCdzIG93biBoYXNoLiAgSUlSQywg U0JTUCBhdm9pZHMgdGhhdCBlbnRpcmVseS4NCg0K --_000_5EE81C5C4CFFF4418C5EAD12F49D64EE4C2219F2IMCMBX01MITREOR_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzQ0NTQ2QTsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3Jt YWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPlNvbWUgY29t bWVudHMgaW4tbGluZSBiZWxvdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAt LWtlaXRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBkdG4tc2VjdXJpdHkgW21haWx0bzpkdG4tc2VjdXJpdHktYm91 bmNlc0BpcnRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW15IEFsZm9yZDxicj4NCjxiPlNl bnQ6PC9iPiBNb25kYXksIEp1bmUgMDIsIDIwMTQgMTE6MzMgQU08YnI+DQo8Yj5Ubzo8L2I+IEJ1 cmxlaWdoLCBTY290dCBDICgzMTJHKTxicj4NCjxiPkNjOjwvYj4gZHRuLXNlY3VyaXR5QGlydGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbZHRuLXNlY3VyaXR5XSBVcGRhdGVkIFNCU1Ag RG9jdW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkknbSBhbHNvIHJlc3BvbmRp bmcgaW5saW5lLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bToxMi4wcHQ7bWFyZ2luLWxlZnQ6LjVpbiI+DQo8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T24gRnJpLCBN YXkgMzAsIDIwMTQgYXQgMzoxNyBQTSwgQnVybGVpZ2gsIFNjb3R0IEMgKDMxMkcpICZsdDs8YSBo cmVmPSJtYWlsdG86c2NvdHQuYy5idXJsZWlnaEBqcGwubmFzYS5nb3YiIHRhcmdldD0iX2JsYW5r Ij5zY290dC5jLmJ1cmxlaWdoQGpwbC5uYXNhLmdvdjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkEgY291cGxlIG9m IHJlbWFya3Mgb24gRGF2aWTigJlzIGNvbW1lbnRzLCBpbi1saW5lIGJlbG93Ljwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+U2NvdHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBkdG4tc2VjdXJpdHkgW21haWx0bzo8YSBocmVmPSJtYWlsdG86ZHRuLXNlY3VyaXR5 LWJvdW5jZXNAaXJ0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kdG4tc2VjdXJpdHktYm91bmNlc0Bp cnRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlpvbGxlciwgRGF2aWQgQS4gKE1TRkMt RU81MClbSE9TQyBTRVJWSUNFUyBDT05UUkFDVF08YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXks IE1heSAyOSwgMjAxNCAxMjowOSBQTTxicj4NCjxiPlRvOjwvYj4gQmlycmFuZSwgRWR3YXJkIEou OyA8YSBocmVmPSJtYWlsdG86ZHRuLXNlY3VyaXR5QGlydGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ DQpkdG4tc2VjdXJpdHlAaXJ0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbZHRu LXNlY3VyaXR5XSBVcGRhdGVkIFNCU1AgRG9jdW1lbnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDou NWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PkVkLDxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkdvb2Qgd29y ayAtIHRoZSBTQlNQIHNwZWMgY29udGludWVzIHRvIGV2b2x2ZSBuaWNlbHkuIEnigJlsbCBraWNr IG9mZiB0aGUgZGlzY3Vzc2lvbnMgd2l0aCBteSBjb21tZW50cyBiZWxvdy48bzpwPjwvbzpwPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+RFo8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDouNWluIj4NCjxiPltQYWdlIDEyXSAyLjQgQnVuZGxlIEF1dGhlbnRpY2F0aW9uIEJsb2Nr PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41 aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5U aGUgc2VjdXJpdHktdGFyZ2V0IE1VU1QgYmUgdGhlIGVudGlyZSBidW5kbGUsIHdoaWNoIE1VU1Qg YmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPnJlcHJlc2VudGVkIGJ5IGEgJmx0O2Jsb2NrIHR5cGUmZ3Q7Jmx0O29jY3VycmVuY2UgbnVt YmVyJmd0OyBvZiAmbHQ7MHgwMCZndDsmbHQ7MHgwMCZndDsuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjYzLjBwdDt2ZXJ0aWNhbC1hbGln bjptaWRkbGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3lt Ym9sO2NvbG9yOiMwMEIwNTAiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7 Y29sb3I6IzAwQjA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPlBlciAzLjQgQnVuZGxl IEZyYWdtZW50YXRpb24gYW5kIFJlYXNzZW1ibHksIGJ1bmRsZSBhdXRoZW50aWNhdGlvbiBtYXkg YmUgYXBwbGllZCB0byBidW5kbGUgZnJhZ21lbnRzIGFzIHdlbGwgYXMgbm9uLWZyYWdtZW50ZWQg YnVuZGxlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6NjMuMHB0O3ZlcnRpY2FsLWFsaWduOm1pZGRsZSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzAwQjA1MCI+wrc8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMDBCMDUwIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwQjA1MCI+SWYgYSBidW5kbGUgZnJhZ21lbnQgaXMgcmVjZWl2ZWQgdGhhdCBoYXMg YSBCQUIsIHRoZXJlIGlzIG5vIHdheSB0byBkZXRlcm1pbmUgaWYgdGhlIEJBQiBhcHBsaWVzIHRv IHRoZSBidW5kbGUgZnJhZ21lbnQgb3IgaWYgaXQgYXBwbGllcyB0byBhbiBlbnRpcmUgYnVuZGxl IHRoYXQgd2FzIGxhdGVyIGZyYWdtZW50ZWQgYnkgYSBub24tc2VjdXJpdHktYXdhcmUgQkEuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEu MjVpbjt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzAwQjA1MCI+bzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMwMEIwNTAiPiZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5JIHByb3Bvc2Ug dGhhdCBhICZsdDtibG9jayB0eXBlJmd0OyZsdDtvY2N1cnJlbmNlIG51bWJlciZndDsgb2YgJmx0 OzB4MDAmZ3Q7Jmx0O3BheWxvYWQgZnJhZyBsZW5ndGgmZ3Q7IGluZGljYXRlIHRoYXQgdGhlIEJB QiBhcHBsaWVzIHRvIGEgYnVuZGxlIGZyYWdtZW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjExNy4wcHQ7dmVydGljYWwtYWxpZ246bWlk ZGxlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtj b2xvcjojMDBCMDUwIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9y OiMwMEIwNTAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5JZiBzdWNoIGEgYnVuZGxlIGZy YWdtZW50IGlzIGZ1cnRoZXIgZnJhZ21lbnRlZCBieSBhIG5vbi1zZWN1cml0eS1hd2FyZSBCQSB0 aGVuIHRoZSAmbHQ7cGF5bG9hZCBmcmFnIGxlbmd0aCZndDsgY2FuIGJlIHVzZWQgdG8gZGV0ZXJt aW5lIHRoYXQgdGhlIG9yaWdpbmFsIGZyYWdtZW50ZWQgYnVuZGxlIG11c3QgYmUgcmVhc3NlbWJs ZWQgYmVmb3JlIGF1dGhlbnRpY2F0aW9uIGlzIGNoZWNrZWQgYmVjYXVzZQ0KIGl0IHdpbGwgbm90 IG1hdGNoIHRoZSBsZW5ndGggZmllbGQgaW4gdGhlIHBheWxvYWQgYmxvY2suPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMjVpbjt2ZXJ0 aWNhbC1hbGlnbjptaWRkbGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzAwQjA1MCI+bzwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMwMEIwNTAiPiZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5Tb21lIGRpc2N1c3Npb24gbWF5 IGJlIGRlc2lyYWJsZSBpbiBzZWN0aW9uIDMuNCBhcyB3ZWxsIGFzIDIuNCBpZiBhY2NlcHRlZDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+w5g8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsNCjwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+V2hlbiBhIEJBQiBpcyBhdHRhY2hlZCB0 byBhIGJ1bmRsZSB0aGF0IGlzIGEgZnJhZ21lbnQsIHRoZSBidW5kbGUgdGhhdCBpdCBhcHBsaWVz IHRvIGlzIGFsd2F5cyB0aGF0IGZyYWdtZW50LCBuZXZlciB0aGUgYnVuZGxlIHRoYXQgY2Fycmll ZCB0aGUgb3JpZ2luYWwgcGF5bG9hZCAob2Ygd2hpY2ggdGhlIGN1cnJlbnQgYnVuZGxl4oCZcyBw YXlsb2FkIGlzIGEgZnJhZ21lbnQpLiZuYnNwOyBTaW5jZQ0KIEJBQnMgYXJlIG5vdCBlbmQtdG8t ZW5kLCB0aGUgQkFCIGZvciBhbiBvcmlnaW5hbCB1bi1mcmFnbWVudGVkIGJ1bmRsZSB3aWxsIG5l dmVyIGJlIGNhcnJpZWQgZm9yd2FyZCBpbiBhbnkgZnJhZ21lbnRzIGdlbmVyYXRlZCBmcm9tIHRo YXQgYnVuZGxlIChzZWUgdGhlIGxhc3QgcGFyYWdyYXBoIG9mIDMuMy4xKSwgc28gdGhlcmXigJlz IG5vIGFtYmlndWl0eS4mbmJzcDsgQnV0IHRoaXMgZG9lcyBicmluZyB1cCBhbiBpbXBvcnRhbnQg cG9pbnQ6IHRoZSBibG9jaw0KIHByb2Nlc3NpbmcgY29udHJvbCBmbGFncyBvZiB0aGUgQkFCIG11 c3QgYWx3YXlzIGhhdmUgdGhlIOKAnHJlcGxpY2F0ZSBpbiBldmVyeSBmcmFnbWVudOKAnSBmbGFn IHNldCB0byAwLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+TWF5YmUgSSdtIG1pc3VuZGVyc3RhbmRpbmcgaGVy ZSwgYnV0IGZyYWdtZW50YXRpb24gY2FuIGhhcHBlbiBiZXR3ZWVuIGEgQkFCIHNvdXJjZSBhbmQg YSBCQUIgZGVzdCBpZiBhIG5vbi1zZWN1cml0eSBhd2FyZSBub2RlIGlzIGJldHdlZW4gdGhlIHR3 by4gJm5ic3A7UmVxdWlyaW5nIHRoZSAmcXVvdDtET19OT1RfRlJBR01FTlQmcXVvdDsgZmxhZyBz b2x2ZXMgdGhpcy4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzQ0NTQ2QSI+QkFCcyBzaG91bGQgYmUgYXBwbGllZCDigJhwb2ludC10by1wb2ludOKAmSBi ZXR3ZWVuIGJ1bmRsZSBhZ2VudHM7IHRoZXJlIHNob3VsZG7igJl0IGJlIGFuIG9wcG9ydHVuaXR5 IGZvciBhIG5vbi1zZWN1cml0eS1hd2FyZSBub2RlIHRvIGZyYWdtZW50IGEgYnVuZGxlIHdpdGgg YSBCQUINCiBvbiBpdC4mbmJzcDsgSeKAmWxsIGhhdmUgdG8gY2hlY2sgdGhlIGNyb3NzLXByb2R1 Y3QgYmV0d2VlbiBlbmNhcHN1bGF0aW9uIGFuZCBCQUIgKGkuZS4gd2hldGhlciB5b3UgY2FuIGVu Y2Fwc3VsYXRlIGEgYnVuZGxlIHdpdGggYSBCQUIgb24gaXQgKGFuZCB0aGVuIHBvc3NpYmx5IGZy YWdtZW50IHRoZSBlbmNhcHN1bGF0aW5nIGJ1bmRsZSkgb3Igbm90KS4mbmJzcDsgSSBzdXNwZWN0 IHRoYXQgdGhlIGFuc3dlciBpcyDigJhub+KAmSAoaS5lLiB5b3UgY2hlY2sgLyByZW1vdmUNCiB0 aGUgQkFCIGltbWVkaWF0ZWx5IG9uIHJlY2VpcHQgYW5kIGJlZm9yZSB5b3UgZW5jYXBzdWxhdGUg YW5kL29yIGZyYWdtZW50IGZvciB0cmFuc21pc3Npb24pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj NDQ1NDZBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KJm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8Yj5b UGFnZSAxNF0gMi42IEJsb2NrIENvbmZpZGVudGlhbGl0eSBCbG9jazwvYj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlIGJsb2NrIHByb2Nlc3Np bmcgY29udHJvbCBmbGFncyB2YWx1ZSBjYW4gYmUgc2V0IHRvIHdoYXRldmVyPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij52YWx1ZXMgYXJl IHJlcXVpcmVkIGJ5IGxvY2FsIHBvbGljeSwgZXhjZXB0IHRoYXQgYSBMb25lIEJDQiBvcjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWlu Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Rmly c3QgQkNCIE1VU1QgaGF2ZSB0aGUgJnF1b3Q7cmVwbGljYXRlIGluIGV2ZXJ5IGZyYWdtZW50JnF1 b3Q7IGZsYWcgc2V0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+VGhpcyBpbmRpY2F0ZXMgdG8gYSByZWNlaXZpbmcgbm9kZSB0aGF0IHRo ZSBwYXlsb2FkIHBvcnRpb24gaW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPmVhY2ggZnJhZ21lbnQgcmVwcmVzZW50cyBjaXBoZXItdGV4 dC4gPC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6NjMuMHB0O3ZlcnRpY2FsLWFsaWduOm1pZGRsZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzAwQjA1MCI+wrc8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMDBCMDUwIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6IzAwQjA1MCI+VGhlIGludGVudCBoZXJlIGlzIG9ubHkgaWYgdGhlIHRhcmdldCBvZiB0aGUg TG9uZSBCQ0Igb3IgRmlyc3QgQkNCIGlzIHRoZSBwYXlsb2FkIGJsb2NrIHdoaWNoIHdvdWxkIG5l ZWQgdG8gYmUgYWRkZWQgaWYgdGhpcyBpcyBrZXB0IGFzIGEgcmVxdWlyZW1lbnQuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjYzLjBwdDt2 ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMwMEIwNTAiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny4wcHQ7Y29sb3I6IzAwQjA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPkkg dGhpbmsgdGhpcyByZXF1aXJlbWVudCBzaG91bGQgYmUgcmVtb3ZlZCBvciBhdCBsZWFzdCByZWR1 Y2VkIHRvIGEgJnF1b3Q7TUFZJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMjVpbjt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPg0K PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPjEuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny4wcHQ7Y29sb3I6IzAwQjA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPkl0IGFzc3VtZXMgdGhhdCB0 aGUgTG9uZSBvciBGaXJzdCBCQ0IgbXVzdCBiZSBwcmlvciB0byB0aGUgcGF5bG9hZCBibG9jayB3 aGljaCBpcyBub3QgYSBzcGVjaWZpYyByZXF1aXJlbWVudCBhbmQgaXMgbm90IG5lY2Vzc2FyeSBp biBhbnkgY2FzZSBmb3IgU0JTUDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDoxLjI1aW47dmVydGljYWwtYWxpZ246bWlkZGxlIj4NCjxzcGFu IHN0eWxlPSJjb2xvcjojMDBCMDUwIj4yLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0O2NvbG9yOiMwMEIwNTAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5BIEJDQiBibG9jayBjb3VsZCBiZSBx dWl0ZSBsYXJnZSBhbmQgYWRkIGEgbG90IG9mIGJhbmR3aWR0aCBvdmVyaGVhZCBpZiBpbmNsdWRl ZCBpbiBldmVyeSBmcmFnbWVudDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDoxLjI1aW47dmVydGljYWwtYWxpZ246bWlkZGxlIj4NCjxzcGFu IHN0eWxlPSJjb2xvcjojMDBCMDUwIj4zLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0O2NvbG9yOiMwMEIwNTAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5JIGRvIG5vdCBzZWUgYSBiZW5lZml0 IGdhaW5lZCBieSBpbmNsdWRpbmcgdGhlIGJsb2NrIGluIGV2ZXJ5IGZyYWdtZW50DQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MTE3LjBw dDt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtj b2xvcjojMDBCMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+aS48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMDBCMDUwIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+RXZlbiB0aGUgZGVzdGluYXRpb24g bm9kZSBsaWtlbHkgY2Fubm90IGRlY3J5cHQgYW55IGluZGl2aWR1YWwgZnJhZ21lbnQgZXhjZXB0 IHRoZSBmaXJzdCBvbmUgYW5kJm5ic3A7IGl0IHByb2JhYmx5IHdvdWxkIG9ubHkgZGVjcnlwdCBh IHBhcnRpYWwgYnVuZGxlIGFzIGEgbGFzdCByZXNvcnQgb3IgZm9yZW5zaWMgZnVuY3Rpb24gaWYg dGhlIGVudGlyZSBidW5kbGUgd2FzIG5vdCByZWNlaXZlZA0KIGJlZm9yZSBleHBpcmF0aW9uPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEx Ny4wcHQ7dmVydGljYWwtYWxpZ246bWlkZGxlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4w cHQ7Y29sb3I6IzAwQjA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDwvc3Bhbj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5paS48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMDBCMDUwIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+SW50ZXJtZWRpYXRlIG5vZGVzIHNob3VsZG4n dCBnZW5lcmFsbHkgYmUgcG9raW5nIGFyb3VuZCBpbiBidW5kbGUgcGF5bG9hZHMgYW55d2F5IGFu ZCBubyBuZWVkIHRvIHByb3ZpZGUgYWRkaXRpb25hbCBjbHVlcyBhcyB0byB3aGV0aGVyIGEgZnJh Z21lbnQgcGF5bG9hZCBpcyBlbmNyeXB0ZWQgb3IgYSBidW5jaCBvZiBiaW5hcnkgdmFsdWVzIOKA kyBrZWVwIHRoZSBiYWQgZ3V5cyBndWVzc2luZw0KIGFuZCB3YXN0aW5nIENQVSBjeWNsZXMgaWYg cG9zc2libGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6MTE3LjBwdDt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdDtjb2xvcjojMDBCMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPC9zcGFuPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPmlpaS48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMDBCMDUwIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+QlNQIGluY2x1ZGVzIHRoaXMgcmVx dWlyZW1lbnQgLSBoYXZlIGFueSBvZiB0aGUgaW1wbGVtZW50YXRpb25zIGZvdW5kIGEgbmVlZCBv ciBiZW5lZml0IGZvciB0aGlzIGFuZCB3b3VsZCBpdCBzdGlsbCBhcHBseSBpbiBjb250ZXh0IG9m IHRoZSBTQlNQPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW47dmVydGljYWwtYWxpZ246bWlkZGxlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPsOYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPkkgdGhpbmsgdGhpcyBhIGdvb2QgcG9pbnQuJm5ic3A7IFNpbmNlIGFsbCBkZWNy eXB0aW9uIHNob3VsZCBvbmx5IGhhcHBlbiBhdCB0aGUgYnVuZGxlIGRlc3RpbmF0aW9uLCB3aGlj aCBpcyB3aGVyZSBhbGwgdGhlIGZyYWdtZW50cyBhcmUgZ29pbmcgdG8gaGF2ZSB0byBlbmQgdXAs IHdoeSBub3QgZm9yd2FyZCBhbGwgQkNCcyAoZm9yIGFsbCBibG9ja3MgdGhhdCBoYXZlIHRoZW0p IG9ubHkgd2l0aA0KIHRoZSBmcmFnbWVudCB3aG9zZSBvZmZzZXQgaXMgemVybz8mbmJzcDsgJm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SXMg dGhlcmUgYSBwb3NzaWJpbGl0eSBvZiBhbiBpbnRlcm1lZGlhdGUgbm9kZSBhZGRpbmcgYSBCSUIg dG8gdGhlIGZyYWdtZW50LCB1bmF3YXJlIHRoYXQgdGhlcmUncyBhbHJlYWR5IGEgQkNCIG9uIHRo ZSB3aG9sZSBwYXlsb2FkPyAmbmJzcDtJIHJlYWxseSBoYXRlIHRoZSBpbnRlcmFjdGlvbiBiZXR3 ZWVuIGZyYWdtZW50YXRpb24gYW5kIEJTUC4gJm5ic3A7SSBmZWVsIGxpa2UgdGlnaHRseQ0KIGxv Y2tpbmcgZG93biBob3cgdGhlIHR3byBvZiB0aGVtIGNvbWJpbmUgYXZvaWRzIGEgbG90IG9mIHBp dGZhbGxzIGFuZCBhbWJpZ3VpdHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzQ0NTQ2QSI+TXkgbm90aW9uIGlzIHRoYXQgdGhlIEJDQiBzaG91bGQgYXBwbHkgdG8g dGhlIGVudGlyZSAodW5mcmFnbWVudGVkKSBwYXlsb2FkLiZuYnNwOyBJZiBpdOKAmXMgcG9zc2li bGUgdG8gYXBwbHkgYSBCQ0IgdG8gYSBmcmFnbWVudCAoaW4gdGhlIG1pZGRsZSBvZiBhIHBhdGgg YW5kIGNvbm5lY3Rpb24pDQogdGhlbiB0aGUgQkNCIGl0c2VsZiBoYWQgYmV0dGVyIHN0YXRlIHRv IHdoaWNoIGJ5dGVzIG9mIHRoZSBwYXlsb2FkIGl0IGFwcGxpZXMsIG9yIGl04oCZcyBnb2luZyB0 byBiZSByZWFsbHkgaGFyZCB0byBzb3J0IGl0IG91dCBsYXRlci48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzQ0NTQ2QSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPldoYXTigJlz IHRoZSByYXRpb25hbGUgZm9yIHJlcGxpY2F0aW9uPyZuYnNwOyBUaGUgZGVzdGluYXRpb24gaXMg dGhlIG9ubHkgbm9kZSB0aGF04oCZcyBnb2luZyB0byBoYXZlIHRvIGRlYWwgd2l0aCBkZWNyeXB0 aW9uLCBzbyB3aGF0IGlzIHRoaXMgZG9pbmc/Jm5ic3A7IElzIHRoZSBub3Rpb24NCiB0aGF0IHRo ZSByZWNlaXZlciBtaWdodCBwYXNzIHBhcnRzIG9mIHRoZSBub3QteWV0LWZ1bGx5LXJlY2VpdmVk IGJ1bmRsZSB0byB0aGUgYXBwbGljYXRpb24/Jm5ic3A7IFRoYXQgd291bGQgYmUsIEkgdGhpbmss IHdyb25nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDQ1NDZBIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4yNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xv cjojMDBCMDUwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6MS4yNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+ DQo8Yj5bUGFnZSAyNF0gMy4xLjIuMyBFeHRlbnNpb24gQmxvY2sgQ2Fub25pY2FsaXphdGlvbjwv Yj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWlu Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhl IGJsb2NrLWxlbmd0aCBpcyBjYW5vbmljYWxpemVkIGFzIGl0cyB1bnBhY2tlZCBTRE5WIHZhbHVl LiZuYnNwOyBJZiB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPmRhdGEgdG8gYmUgY2Fub25pY2FsaXplZCBpcyBsZXNzIHRoYW4gdGhl IGNvbXBsZXRlLCBvcmlnaW5hbCBibG9jazwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ZGF0YSwgdGhpcyBmaWVsZCBjb250YWlucyB0aGUg c2l6ZSBvZiB0aGUgZGF0YSBiZWluZyBjYW5vbmljYWxpemVkPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4odGhlICZxdW90O2VmZmVjdGl2 ZSBibG9jayZxdW90OykgcmF0aGVyIHRoYW4gdGhlIGFjdHVhbCBzaXplIG9mIHRoZSBibG9jay48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 NjMuMHB0O3ZlcnRpY2FsLWFsaWduOm1pZGRsZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzAwQjA1MCI+wrc8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMDBCMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzAw QjA1MCI+U2VjdGlvbiAzLjEuMi4xIChQcmltYXJ5IEJsb2NrIENhbm9uaWNhbGl6YXRpb24pIGRl dGFpbHMgdGhlIGxlbmd0aCBmaWVsZHMgYXMgNCBieXRlIHZhbHVlcyBhbmQgZWZmZWN0aXZlbHkg cmVzZXJ2ZXMgdGhlIHRlcm0gJnF1b3Q7dW5wYWNrZWQgU0ROViB2YWx1ZSZxdW90OyB0byBtZWFu IHRoZSA4IGJ5dGUgdmFsdWUuIEkgcmVjb21tZW5kIHVzaW5nIHRoZSBzYW1lIGNvbnZlbnRpb24g aGVyZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6MS4yNWluO3ZlcnRpY2FsLWFsaWduOm1pZGRsZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMDBC MDUwIj5vPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzAwQjA1MCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPlBl cnNvbmFsbHksIEkgd291bGQgc3BlY2lmeSBhbGwgU0ROViB2YWx1ZXMgY2Fub25pY2FsaXplZCBh cyA4IGJ5dGUgdmFsdWVzIGFuZCBiZSBkb25lIHdpdGggaXQ8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NjMuMHB0O3ZlcnRpY2FsLWFsaWdu Om1pZGRsZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1i b2w7Y29sb3I6IzAwQjA1MCI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtj b2xvcjojMDBCMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+QWRkIGEgc3RhdGVtZW50 IHRvIHRoZSBlZmZlY3Q6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjEuMjVpbjt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6IzAwQjA1MCI+bzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9y OiMwMEIwNTAiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDBCMDUwIj5UaGUgZW50aXJldHkgb3IgcG9ydGlvbihzKSBvZiB0aGUgYmxvY2sgYm9keSBkYXRh IGFyZSBjYW5vbmljYWxpemVkIGFzIGlzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dmVydGljYWwtYWxpZ246bWlkZGxlIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPsOYPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7DQo8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgYWJvdXQgY2Fub25pY2FsaXppbmcgYWxs IFNETlZzIGFzIDgtYnl0ZSB2YWx1ZXMuJm5ic3A7IEZXSVcsIEkgdGhpbmsgdGhlIGNhbm9uaWNh bGl6YXRpb24gaW4gYnVuZGxlIHNlY3VyaXR5IHByb3RvY29sIGlzIGEgbWFqb3IgcGFpbiBpbiB0 aGUgbmVjay4mbmJzcDsgSXMgdGhlIG11dGFiaWxpdHkgb2YgYmxvY2tzIOKAkyB0aGUgbmVlZCB0 byBleGNsdWRlIG11dGFibGUgZmllbGRzIGZyb20gaGFzaA0KIGNvbXB1dGF0aW9ucyDigJMgdGhl IG1haW4gcmVhc29uIGZvciBpdD8mbmJzcDsgSXMgdGhlcmUgbm8gd2F5IHRvIHNpbXBsaWZ5Pzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6NjMuMHB0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkkgdGhp bmsgdGhlIG1ham9yIGlzc3VlIGlzIHRoZSBkaWN0aW9uYXJ5LCBzaW5jZSBpdCBjYW4gYmUgbW9k aWZpZWQgZXZlbiBpZiB0aGUgYWN0dWFsIGVpZCdzIGluIHRoZSBibG9jayBhcmUgc3RhYmxlLiAm bmJzcDtUaGUgZmxhZ3MgYXJlIHN0cmFpZ2h0Zm9yd2FyZC4gJm5ic3A7SW4gQlNQLCB0aGVyZSdz IGFsc28gYSBiaWcgaXNzdWUgd2l0aCB0YWlsIGNoYXNpbmcgd2hlbiBhIFBJQg0KIGJsb2NrIGlz IHJlcXVpcmVkIHRvIGluY2x1ZGUgY2h1bmtzIG9mIGl0c2VsZiBpbiBpdCdzIG93biBoYXNoLiAm bmJzcDtJSVJDLCBTQlNQIGF2b2lkcyB0aGF0IGVudGlyZWx5LiAmbmJzcDsmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5EE81C5C4CFFF4418C5EAD12F49D64EE4C2219F2IMCMBX01MITREOR_-- From nobody Mon Jun 2 09:53:54 2014 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672DF1A03C1 for ; Mon, 2 Jun 2014 09:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4ksRjwtE4AZ for ; Mon, 2 Jun 2014 09:53:51 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23DD11A0360 for ; Mon, 2 Jun 2014 09:53:51 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp02.jpl.nasa.gov [128.149.137.149]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s52GriP8031678 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 2 Jun 2014 09:53:45 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.156]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.03.0174.001; Mon, 2 Jun 2014 09:53:44 -0700 From: "Burleigh, Scott C (312G)" To: "Scott, Keith L." , Amy Alford Thread-Topic: [dtn-security] Updated SBSP Document Thread-Index: Ac96egHBtIlHfqjpRHK8eG5est6OOQA736HgADK/lpAAn4L4gAAB6Q+AAA47H4A= Date: Mon, 2 Jun 2014 16:53:44 +0000 Message-ID: References: <329D879C76FDD04AAAE84BB1D89B3970094FBF9EAA@aplesfreedom.dom1.jhuapl.edu> <94CFB3711B4CAE4DBFC5BEB3374BF0C60D1835@NDMSMBX404.ndc.nasa.gov> <5EE81C5C4CFFF4418C5EAD12F49D64EE4C2219F2@IMCMBX01.MITRE.ORG> In-Reply-To: <5EE81C5C4CFFF4418C5EAD12F49D64EE4C2219F2@IMCMBX01.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: multipart/alternative; boundary="_000_A5BEAD028815CB40A32A5669CF737C3B423B4FCBapembxsp40RESAD_" MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/xlswC2nvclyH1_HUjf_17G1q268 Cc: "dtn-security@irtf.org" Subject: Re: [dtn-security] Updated SBSP Document X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 16:53:53 -0000 --_000_A5BEAD028815CB40A32A5669CF737C3B423B4FCBapembxsp40RESAD_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIG1vcmUgY29tbWVudCBvbiBvbmUgb2YgdGhlc2UgdG9waWNzLCBhbHNvIGluLWxpbmUuDQoN CkZyb206IFNjb3R0LCBLZWl0aCBMLiBbbWFpbHRvOmtzY290dEBtaXRyZS5vcmddDQpTZW50OiBN b25kYXksIEp1bmUgMDIsIDIwMTQgOToyNyBBTQ0KVG86IEFteSBBbGZvcmQ7IEJ1cmxlaWdoLCBT Y290dCBDICgzMTJHKQ0KQ2M6IGR0bi1zZWN1cml0eUBpcnRmLm9yZw0KU3ViamVjdDogUkU6IFtk dG4tc2VjdXJpdHldIFVwZGF0ZWQgU0JTUCBEb2N1bWVudA0KDQpTb21lIGNvbW1lbnRzIGluLWxp bmUgYmVsb3cuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgIC0ta2VpdGgNCg0KRnJvbTogZHRu LXNlY3VyaXR5IFttYWlsdG86ZHRuLXNlY3VyaXR5LWJvdW5jZXNAaXJ0Zi5vcmddIE9uIEJlaGFs ZiBPZiBBbXkgQWxmb3JkDQpTZW50OiBNb25kYXksIEp1bmUgMDIsIDIwMTQgMTE6MzMgQU0NClRv OiBCdXJsZWlnaCwgU2NvdHQgQyAoMzEyRykNCkNjOiBkdG4tc2VjdXJpdHlAaXJ0Zi5vcmc8bWFp bHRvOmR0bi1zZWN1cml0eUBpcnRmLm9yZz4NClN1YmplY3Q6IFJlOiBbZHRuLXNlY3VyaXR5XSBV cGRhdGVkIFNCU1AgRG9jdW1lbnQNCg0KSSdtIGFsc28gcmVzcG9uZGluZyBpbmxpbmUuDQoNCk9u IEZyaSwgTWF5IDMwLCAyMDE0IGF0IDM6MTcgUE0sIEJ1cmxlaWdoLCBTY290dCBDICgzMTJHKSA8 c2NvdHQuYy5idXJsZWlnaEBqcGwubmFzYS5nb3Y8bWFpbHRvOnNjb3R0LmMuYnVybGVpZ2hAanBs Lm5hc2EuZ292Pj4gd3JvdGU6DQpBIGNvdXBsZSBvZiByZW1hcmtzIG9uIERhdmlk4oCZcyBjb21t ZW50cywgaW4tbGluZSBiZWxvdy4NClNjb3R0DQpGcm9tOiBkdG4tc2VjdXJpdHkgW21haWx0bzpk dG4tc2VjdXJpdHktYm91bmNlc0BpcnRmLm9yZzxtYWlsdG86ZHRuLXNlY3VyaXR5LWJvdW5jZXNA aXJ0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgWm9sbGVyLCBEYXZpZCBBLiAoTVNGQy1FTzUwKVtIT1ND IFNFUlZJQ0VTIENPTlRSQUNUXQ0KU2VudDogVGh1cnNkYXksIE1heSAyOSwgMjAxNCAxMjowOSBQ TQ0KVG86IEJpcnJhbmUsIEVkd2FyZCBKLjsgZHRuLXNlY3VyaXR5QGlydGYub3JnPG1haWx0bzpk dG4tc2VjdXJpdHlAaXJ0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2R0bi1zZWN1cml0eV0gVXBkYXRl ZCBTQlNQIERvY3VtZW50DQoNCkVkLA0KDQpHb29kIHdvcmsgLSB0aGUgU0JTUCBzcGVjIGNvbnRp bnVlcyB0byBldm9sdmUgbmljZWx5LiBJ4oCZbGwga2ljayBvZmYgdGhlIGRpc2N1c3Npb25zIHdp dGggbXkgY29tbWVudHMgYmVsb3cuDQoNCkNoZWVycywNCg0KRFoNCltQYWdlIDEyXSAyLjQgQnVu ZGxlIEF1dGhlbnRpY2F0aW9uIEJsb2NrDQpUaGUgc2VjdXJpdHktdGFyZ2V0IE1VU1QgYmUgdGhl IGVudGlyZSBidW5kbGUsIHdoaWNoIE1VU1QgYmUNCnJlcHJlc2VudGVkIGJ5IGEgPGJsb2NrIHR5 cGU+PG9jY3VycmVuY2UgbnVtYmVyPiBvZiA8MHgwMD48MHgwMD4uDQrigKIgICAgICAgICBQZXIg My40IEJ1bmRsZSBGcmFnbWVudGF0aW9uIGFuZCBSZWFzc2VtYmx5LCBidW5kbGUgYXV0aGVudGlj YXRpb24gbWF5IGJlIGFwcGxpZWQgdG8gYnVuZGxlIGZyYWdtZW50cyBhcyB3ZWxsIGFzIG5vbi1m cmFnbWVudGVkIGJ1bmRsZXMuDQrigKIgICAgICAgICBJZiBhIGJ1bmRsZSBmcmFnbWVudCBpcyBy ZWNlaXZlZCB0aGF0IGhhcyBhIEJBQiwgdGhlcmUgaXMgbm8gd2F5IHRvIGRldGVybWluZSBpZiB0 aGUgQkFCIGFwcGxpZXMgdG8gdGhlIGJ1bmRsZSBmcmFnbWVudCBvciBpZiBpdCBhcHBsaWVzIHRv IGFuIGVudGlyZSBidW5kbGUgdGhhdCB3YXMgbGF0ZXIgZnJhZ21lbnRlZCBieSBhIG5vbi1zZWN1 cml0eS1hd2FyZSBCQS4NCm8gICAgSSBwcm9wb3NlIHRoYXQgYSA8YmxvY2sgdHlwZT48b2NjdXJy ZW5jZSBudW1iZXI+IG9mIDwweDAwPjxwYXlsb2FkIGZyYWcgbGVuZ3RoPiBpbmRpY2F0ZSB0aGF0 IHRoZSBCQUIgYXBwbGllcyB0byBhIGJ1bmRsZSBmcmFnbWVudA0K4oCiICAgICAgICAgSWYgc3Vj aCBhIGJ1bmRsZSBmcmFnbWVudCBpcyBmdXJ0aGVyIGZyYWdtZW50ZWQgYnkgYSBub24tc2VjdXJp dHktYXdhcmUgQkEgdGhlbiB0aGUgPHBheWxvYWQgZnJhZyBsZW5ndGg+IGNhbiBiZSB1c2VkIHRv IGRldGVybWluZSB0aGF0IHRoZSBvcmlnaW5hbCBmcmFnbWVudGVkIGJ1bmRsZSBtdXN0IGJlIHJl YXNzZW1ibGVkIGJlZm9yZSBhdXRoZW50aWNhdGlvbiBpcyBjaGVja2VkIGJlY2F1c2UgaXQgd2ls bCBub3QgbWF0Y2ggdGhlIGxlbmd0aCBmaWVsZCBpbiB0aGUgcGF5bG9hZCBibG9jay4NCm8gICAg U29tZSBkaXNjdXNzaW9uIG1heSBiZSBkZXNpcmFibGUgaW4gc2VjdGlvbiAzLjQgYXMgd2VsbCBh cyAyLjQgaWYgYWNjZXB0ZWQNCg0KPiAgV2hlbiBhIEJBQiBpcyBhdHRhY2hlZCB0byBhIGJ1bmRs ZSB0aGF0IGlzIGEgZnJhZ21lbnQsIHRoZSBidW5kbGUgdGhhdCBpdCBhcHBsaWVzIHRvIGlzIGFs d2F5cyB0aGF0IGZyYWdtZW50LCBuZXZlciB0aGUgYnVuZGxlIHRoYXQgY2FycmllZCB0aGUgb3Jp Z2luYWwgcGF5bG9hZCAob2Ygd2hpY2ggdGhlIGN1cnJlbnQgYnVuZGxl4oCZcyBwYXlsb2FkIGlz IGEgZnJhZ21lbnQpLiAgU2luY2UgQkFCcyBhcmUgbm90IGVuZC10by1lbmQsIHRoZSBCQUIgZm9y IGFuIG9yaWdpbmFsIHVuLWZyYWdtZW50ZWQgYnVuZGxlIHdpbGwgbmV2ZXIgYmUgY2FycmllZCBm b3J3YXJkIGluIGFueSBmcmFnbWVudHMgZ2VuZXJhdGVkIGZyb20gdGhhdCBidW5kbGUgKHNlZSB0 aGUgbGFzdCBwYXJhZ3JhcGggb2YgMy4zLjEpLCBzbyB0aGVyZeKAmXMgbm8gYW1iaWd1aXR5LiAg QnV0IHRoaXMgZG9lcyBicmluZyB1cCBhbiBpbXBvcnRhbnQgcG9pbnQ6IHRoZSBibG9jayBwcm9j ZXNzaW5nIGNvbnRyb2wgZmxhZ3Mgb2YgdGhlIEJBQiBtdXN0IGFsd2F5cyBoYXZlIHRoZSDigJxy ZXBsaWNhdGUgaW4gZXZlcnkgZnJhZ21lbnTigJ0gZmxhZyBzZXQgdG8gMC4NCk1heWJlIEknbSBt aXN1bmRlcnN0YW5kaW5nIGhlcmUsIGJ1dCBmcmFnbWVudGF0aW9uIGNhbiBoYXBwZW4gYmV0d2Vl biBhIEJBQiBzb3VyY2UgYW5kIGEgQkFCIGRlc3QgaWYgYSBub24tc2VjdXJpdHkgYXdhcmUgbm9k ZSBpcyBiZXR3ZWVuIHRoZSB0d28uICBSZXF1aXJpbmcgdGhlICJET19OT1RfRlJBR01FTlQiIGZs YWcgc29sdmVzIHRoaXMuDQoNCkJBQnMgc2hvdWxkIGJlIGFwcGxpZWQg4oCYcG9pbnQtdG8tcG9p bnTigJkgYmV0d2VlbiBidW5kbGUgYWdlbnRzOyB0aGVyZSBzaG91bGRu4oCZdCBiZSBhbiBvcHBv cnR1bml0eSBmb3IgYSBub24tc2VjdXJpdHktYXdhcmUgbm9kZSB0byBmcmFnbWVudCBhIGJ1bmRs ZSB3aXRoIGEgQkFCIG9uIGl0LiAgSeKAmWxsIGhhdmUgdG8gY2hlY2sgdGhlIGNyb3NzLXByb2R1 Y3QgYmV0d2VlbiBlbmNhcHN1bGF0aW9uIGFuZCBCQUIgKGkuZS4gd2hldGhlciB5b3UgY2FuIGVu Y2Fwc3VsYXRlIGEgYnVuZGxlIHdpdGggYSBCQUIgb24gaXQgKGFuZCB0aGVuIHBvc3NpYmx5IGZy YWdtZW50IHRoZSBlbmNhcHN1bGF0aW5nIGJ1bmRsZSkgb3Igbm90KS4gIEkgc3VzcGVjdCB0aGF0 IHRoZSBhbnN3ZXIgaXMg4oCYbm/igJkgKGkuZS4geW91IGNoZWNrIC8gcmVtb3ZlIHRoZSBCQUIg aW1tZWRpYXRlbHkgb24gcmVjZWlwdCBhbmQgYmVmb3JlIHlvdSBlbmNhcHN1bGF0ZSBhbmQvb3Ig ZnJhZ21lbnQgZm9yIHRyYW5zbWlzc2lvbikuDQoNCg0Kw5ggVGhlcmUgaXNu4oCZdCByZWFsbHkg YW55IGFjY2VwdGVkIHNwZWMgdG8gY29uc3VsdCBvbiBlbmNhcHN1bGF0aW9uLCBidXQgd2l0aGlu IHRoZSBjb25jZXB0IHRoYXQgSeKAmXZlIGJlZW4gd29ya2luZyB3aXRoIChodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pcnRmLWJ1cmxlaWdoLWJpYmUvKSB0aGUgZW5jYXBz dWxhdGlvbiBwcm90b2NvbCBpcyBhIGNvbnZlcmdlbmNlLWxheWVyIGFkYXB0ZXIuICBJbiB0aGF0 IGNhc2UsIHRoZSBlbnRpcmUsIGNvbXBsZXRlIG91dGJvdW5kIGJ1bmRsZSDigJMgaW5jbHVkaW5n IGFueSBCQUIgdGhhdCB3YXMgYXR0YWNoZWQgYXQgdGhlIGxhc3QgbW9tZW50IGJlZm9yZSBzZXJp YWxpemF0aW9uIGZvciB0aGUgQ0xBIOKAkyB3b3VsZCBiZWNvbWUgdGhlIHBheWxvYWQgb2YgdGhl IG5ldyBlbmNhcHN1bGF0aW5nIGJ1bmRsZS4gIFRoZSBlbmNhcHN1bGF0aW5nIGJ1bmRsZSBtaWdo dCBvciBtaWdodCBub3QgYmUgc2VjdXJpdHktYXdhcmUsIGJ1dCB0aGF0IGRvZXNu4oCZdCBtYXR0 ZXIuICBUaGUgZGVzdGluYXRpb24gb2YgdGhlIGVuY2Fwc3VsYXRpbmcgYnVuZGxlIHdvdWxkIGV4 dHJhY3QgdGhlIGVuY2Fwc3VsYXRlZCBidW5kbGUgKHRoZSDigJxvdXRlcuKAnSBidW5kbGXigJlz IHBheWxvYWQpIGFuZCBzaW11bGF0ZSByZWNlcHRpb24gb2YgdGhhdCBidW5kbGUsIHdoaWNoIHdv dWxkIHN0aWxsIGhhdmUgaXRzIEJBQi4gIFRoYXQgYnVuZGxlIHdvdWxkLCBpbiBlZmZlY3QsIGhh dmUgdHJhdmVyc2VkIG9ubHkgYSBzaW5nbGUgaG9wIChkaXJlY3QgdHJhbnNtaXNzaW9uIGJldHdl ZW4gc2VuZGVyIGFuZCByZWNlaXZlciBhdCB0aGUgY29udmVyZ2VuY2UgbGF5ZXIpLCBzbyB0aGVy ZSB3YXMgbm8gaW50ZXJ2ZW5pbmcgbm9uLXNlY3VyaXR5LWF3YXJlIGZvcndhcmRpbmcgbm9kZSBi ZXR3ZWVuIHRoZSBzZW5kaW5nIG5vZGUgdGhhdCBhdHRhY2hlZCB0aGUgQkFCIGFuZCB0aGUgcmVj ZWl2aW5nIG5vZGUgdGhhdCB3b3VsZCB2YWxpZGF0ZSBpdC4gIFNvIG5vIG9wcG9ydHVuaXR5IGZv ciBmcmFnbWVudGF0aW9uLCBubyBwcm9ibGVtLg0KDQo= --_000_A5BEAD028815CB40A32A5669CF737C3B423B4FCBapembxsp40RESAD_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5N c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojNDQ1NDZBOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0 ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUt bmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDAN Cgl7bXNvLWxpc3QtaWQ6MTgxNDc1ODI1ODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6MTYzNzc2NTk3MCAtMTkxMDUwOTgyIDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30N CkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFt aWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9uZSBtb3JlIGNvbW1lbnQgb24gb25l IG9mIHRoZXNlIHRvcGljcywgYWxzbyBpbi1saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFNjb3R0 LCBLZWl0aCBMLiBbbWFpbHRvOmtzY290dEBtaXRyZS5vcmddDQo8YnI+DQo8Yj5TZW50OjwvYj4g TW9uZGF5LCBKdW5lIDAyLCAyMDE0IDk6MjcgQU08YnI+DQo8Yj5Ubzo8L2I+IEFteSBBbGZvcmQ7 IEJ1cmxlaWdoLCBTY290dCBDICgzMTJHKTxicj4NCjxiPkNjOjwvYj4gZHRuLXNlY3VyaXR5QGly dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbZHRuLXNlY3VyaXR5XSBVcGRhdGVkIFNC U1AgRG9jdW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+U29tZSBjb21tZW50 cyBpbi1saW5lIGJlbG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDQ1NDZBIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0ta2Vp dGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IGR0bi1zZWN1cml0eSBbPGEgaHJlZj0ibWFpbHRvOmR0bi1zZWN1cml0 eS1ib3VuY2VzQGlydGYub3JnIj5tYWlsdG86ZHRuLXNlY3VyaXR5LWJvdW5jZXNAaXJ0Zi5vcmc8 L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbXkgQWxmb3JkPGJyPg0KPGI+U2VudDo8L2I+IE1v bmRheSwgSnVuZSAwMiwgMjAxNCAxMTozMyBBTTxicj4NCjxiPlRvOjwvYj4gQnVybGVpZ2gsIFNj b3R0IEMgKDMxMkcpPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86ZHRuLXNlY3VyaXR5 QGlydGYub3JnIj5kdG4tc2VjdXJpdHlAaXJ0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbZHRuLXNlY3VyaXR5XSBVcGRhdGVkIFNCU1AgRG9jdW1lbnQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPkknbSBhbHNvIHJlc3BvbmRpbmcgaW5saW5lLjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6LjVp biI+DQo8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T24gRnJpLCBNYXkgMzAsIDIwMTQgYXQgMzoxNyBQTSwg QnVybGVpZ2gsIFNjb3R0IEMgKDMxMkcpICZsdDs8YSBocmVmPSJtYWlsdG86c2NvdHQuYy5idXJs ZWlnaEBqcGwubmFzYS5nb3YiIHRhcmdldD0iX2JsYW5rIj5zY290dC5jLmJ1cmxlaWdoQGpwbC5u YXNhLmdvdjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo0Ny41NXB0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5BIGNvdXBsZSBvZiByZW1hcmtzIG9uIERhdmlk4oCZcyBjb21tZW50cywgaW4tbGluZSBi ZWxvdy48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo0Ny41NXB0Ij4NCjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TY290dDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo0Ny41NXB0Ij4NCjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBkdG4tc2VjdXJpdHkgW21haWx0bzo8YSBocmVmPSJtYWlsdG86ZHRuLXNl Y3VyaXR5LWJvdW5jZXNAaXJ0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kdG4tc2VjdXJpdHktYm91 bmNlc0BpcnRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlpvbGxlciwgRGF2aWQgQS4g KE1TRkMtRU81MClbSE9TQyBTRVJWSUNFUyBDT05UUkFDVF08YnI+DQo8Yj5TZW50OjwvYj4gVGh1 cnNkYXksIE1heSAyOSwgMjAxNCAxMjowOSBQTTxicj4NCjxiPlRvOjwvYj4gQmlycmFuZSwgRWR3 YXJkIEouOyA8YSBocmVmPSJtYWlsdG86ZHRuLXNlY3VyaXR5QGlydGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+DQpkdG4tc2VjdXJpdHlAaXJ0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbZHRuLXNlY3VyaXR5XSBVcGRhdGVkIFNCU1AgRG9jdW1lbnQ8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkVkLDxvOnA+PC9vOnA+PC9wPg0KPHAg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkdvb2Qgd29yayAtIHRoZSBTQlNQIHNwZWMgY29udGlu dWVzIHRvIGV2b2x2ZSBuaWNlbHkuIEnigJlsbCBraWNrIG9mZiB0aGUgZGlzY3Vzc2lvbnMgd2l0 aCBteSBjb21tZW50cyBiZWxvdy48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6NDcu NTVwdCI+RFo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPGI+W1BhZ2UgMTJd IDIuNCBCdW5kbGUgQXV0aGVudGljYXRpb24gQmxvY2s8L2I+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoZSBzZWN1cml0eS10YXJnZXQgTVVTVCBi ZSB0aGUgZW50aXJlIGJ1bmRsZSwgd2hpY2ggTVVTVCBiZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+cmVwcmVzZW50ZWQgYnkgYSAmbHQ7 YmxvY2sgdHlwZSZndDsmbHQ7b2NjdXJyZW5jZSBudW1iZXImZ3Q7IG9mICZsdDsweDAwJmd0OyZs dDsweDAwJmd0Oy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6NjMuMHB0O3ZlcnRpY2FsLWFsaWduOm1pZGRsZSI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzAwQjA1MCI+wrc8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMDBCMDUwIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6IzAwQjA1MCI+UGVyIDMuNCBCdW5kbGUgRnJhZ21lbnRhdGlvbiBhbmQgUmVhc3Nl bWJseSwgYnVuZGxlIGF1dGhlbnRpY2F0aW9uIG1heSBiZSBhcHBsaWVkIHRvIGJ1bmRsZSBmcmFn bWVudHMgYXMgd2VsbCBhcyBub24tZnJhZ21lbnRlZCBidW5kbGVzLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo2My4wcHQ7dmVydGljYWwt YWxpZ246bWlkZGxlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OlN5bWJvbDtjb2xvcjojMDBCMDUwIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0O2NvbG9yOiMwMEIwNTAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5JZiBhIGJ1bmRs ZSBmcmFnbWVudCBpcyByZWNlaXZlZCB0aGF0IGhhcyBhIEJBQiwgdGhlcmUgaXMgbm8gd2F5IHRv IGRldGVybWluZSBpZiB0aGUgQkFCIGFwcGxpZXMgdG8gdGhlIGJ1bmRsZSBmcmFnbWVudCBvciBp ZiBpdCBhcHBsaWVzIHRvIGFuIGVudGlyZSBidW5kbGUgdGhhdCB3YXMgbGF0ZXIgZnJhZ21lbnRl ZCBieSBhIG5vbi1zZWN1cml0eS1hd2FyZSBCQS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4yNWluO3ZlcnRpY2FsLWFsaWduOm1pZGRs ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMDBCMDUwIj5vPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny4wcHQ7Y29sb3I6IzAwQjA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMEIwNTAiPkkgcHJvcG9zZSB0aGF0IGEgJmx0O2Jsb2NrIHR5cGUmZ3Q7 Jmx0O29jY3VycmVuY2UgbnVtYmVyJmd0OyBvZiAmbHQ7MHgwMCZndDsmbHQ7cGF5bG9hZCBmcmFn IGxlbmd0aCZndDsgaW5kaWNhdGUgdGhhdCB0aGUgQkFCIGFwcGxpZXMgdG8gYSBidW5kbGUgZnJh Z21lbnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6MTE3LjBwdDt2ZXJ0aWNhbC1hbGlnbjptaWRkbGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMwMEIwNTAiPsK3PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzAwQjA1MCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMEIwNTAiPklmIHN1Y2ggYSBidW5kbGUgZnJhZ21lbnQgaXMgZnVydGhlciBmcmFnbWVu dGVkIGJ5IGEgbm9uLXNlY3VyaXR5LWF3YXJlIEJBIHRoZW4gdGhlICZsdDtwYXlsb2FkIGZyYWcg bGVuZ3RoJmd0OyBjYW4gYmUgdXNlZCB0byBkZXRlcm1pbmUgdGhhdCB0aGUgb3JpZ2luYWwgZnJh Z21lbnRlZCBidW5kbGUgbXVzdCBiZSByZWFzc2VtYmxlZCBiZWZvcmUgYXV0aGVudGljYXRpb24g aXMgY2hlY2tlZCBiZWNhdXNlDQogaXQgd2lsbCBub3QgbWF0Y2ggdGhlIGxlbmd0aCBmaWVsZCBp biB0aGUgcGF5bG9hZCBibG9jay48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4yNWluO3ZlcnRpY2FsLWFsaWduOm1pZGRsZSI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojMDBCMDUwIj5vPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7 Y29sb3I6IzAwQjA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMEIwNTAiPlNvbWUgZGlzY3Vzc2lvbiBtYXkgYmUgZGVzaXJhYmxlIGluIHNlY3Rpb24g My40IGFzIHdlbGwgYXMgMi40IGlmIGFjY2VwdGVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6NDcuNTVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj7DmDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5XaGVuIGEgQkFCIGlzIGF0dGFjaGVkIHRvIGEgYnVuZGxlIHRoYXQgaXMgYSBm cmFnbWVudCwgdGhlIGJ1bmRsZSB0aGF0IGl0IGFwcGxpZXMgdG8gaXMgYWx3YXlzIHRoYXQgZnJh Z21lbnQsIG5ldmVyIHRoZSBidW5kbGUgdGhhdCBjYXJyaWVkIHRoZSBvcmlnaW5hbCBwYXlsb2Fk IChvZiB3aGljaCB0aGUgY3VycmVudCBidW5kbGXigJlzIHBheWxvYWQgaXMgYSBmcmFnbWVudCku Jm5ic3A7IFNpbmNlDQogQkFCcyBhcmUgbm90IGVuZC10by1lbmQsIHRoZSBCQUIgZm9yIGFuIG9y aWdpbmFsIHVuLWZyYWdtZW50ZWQgYnVuZGxlIHdpbGwgbmV2ZXIgYmUgY2FycmllZCBmb3J3YXJk IGluIGFueSBmcmFnbWVudHMgZ2VuZXJhdGVkIGZyb20gdGhhdCBidW5kbGUgKHNlZSB0aGUgbGFz dCBwYXJhZ3JhcGggb2YgMy4zLjEpLCBzbyB0aGVyZeKAmXMgbm8gYW1iaWd1aXR5LiZuYnNwOyBC dXQgdGhpcyBkb2VzIGJyaW5nIHVwIGFuIGltcG9ydGFudCBwb2ludDogdGhlIGJsb2NrDQogcHJv Y2Vzc2luZyBjb250cm9sIGZsYWdzIG9mIHRoZSBCQUIgbXVzdCBhbHdheXMgaGF2ZSB0aGUg4oCc cmVwbGljYXRlIGluIGV2ZXJ5IGZyYWdtZW504oCdIGZsYWcgc2V0IHRvIDAuPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj5NYXliZSBJJ20gbWlzdW5kZXJzdGFuZGluZyBoZXJlLCBidXQgZnJh Z21lbnRhdGlvbiBjYW4gaGFwcGVuIGJldHdlZW4gYSBCQUIgc291cmNlIGFuZCBhIEJBQiBkZXN0 IGlmIGEgbm9uLXNlY3VyaXR5IGF3YXJlIG5vZGUgaXMgYmV0d2VlbiB0aGUgdHdvLiAmbmJzcDtS ZXF1aXJpbmcgdGhlICZxdW90O0RPX05PVF9GUkFHTUVOVCZxdW90OyBmbGFnIHNvbHZlcyB0aGlz LiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDQ1NDZB Ij5CQUJzIHNob3VsZCBiZSBhcHBsaWVkIOKAmHBvaW50LXRvLXBvaW504oCZIGJldHdlZW4gYnVu ZGxlIGFnZW50czsgdGhlcmUgc2hvdWxkbuKAmXQgYmUgYW4gb3Bwb3J0dW5pdHkgZm9yIGEgbm9u LXNlY3VyaXR5LWF3YXJlIG5vZGUgdG8gZnJhZ21lbnQgYSBidW5kbGUgd2l0aCBhIEJBQg0KIG9u IGl0LiZuYnNwOyBJ4oCZbGwgaGF2ZSB0byBjaGVjayB0aGUgY3Jvc3MtcHJvZHVjdCBiZXR3ZWVu IGVuY2Fwc3VsYXRpb24gYW5kIEJBQiAoaS5lLiB3aGV0aGVyIHlvdSBjYW4gZW5jYXBzdWxhdGUg YSBidW5kbGUgd2l0aCBhIEJBQiBvbiBpdCAoYW5kIHRoZW4gcG9zc2libHkgZnJhZ21lbnQgdGhl IGVuY2Fwc3VsYXRpbmcgYnVuZGxlKSBvciBub3QpLiZuYnNwOyBJIHN1c3BlY3QgdGhhdCB0aGUg YW5zd2VyIGlzIOKAmG5v4oCZIChpLmUuIHlvdSBjaGVjayAvIHJlbW92ZQ0KIHRoZSBCQUIgaW1t ZWRpYXRlbHkgb24gcmVjZWlwdCBhbmQgYmVmb3JlIHlvdSBlbmNhcHN1bGF0ZSBhbmQvb3IgZnJh Z21lbnQgZm9yIHRyYW5zbWlzc2lvbikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTpX aW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPg0KPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5UaGVyZSBpc27igJl0IHJlYWxseSBhbnkgYWNjZXB0ZWQgc3BlYyB0byBj b25zdWx0IG9uIGVuY2Fwc3VsYXRpb24sIGJ1dCB3aXRoaW4gdGhlIGNvbmNlcHQgdGhhdCBJ4oCZ dmUgYmVlbiB3b3JraW5nIHdpdGggKDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlydGYtYnVybGVpZ2gtYmliZS8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlydGYtYnVybGVpZ2gtYmliZS88L2E+KQ0KIHRoZSBlbmNhcHN1bGF0 aW9uIHByb3RvY29sIGlzIGEgY29udmVyZ2VuY2UtbGF5ZXIgYWRhcHRlci4mbmJzcDsgSW4gdGhh dCBjYXNlLCB0aGUgZW50aXJlLCBjb21wbGV0ZSBvdXRib3VuZCBidW5kbGUg4oCTIGluY2x1ZGlu ZyBhbnkgQkFCIHRoYXQgd2FzIGF0dGFjaGVkIGF0IHRoZSBsYXN0IG1vbWVudCBiZWZvcmUgc2Vy aWFsaXphdGlvbiBmb3IgdGhlIENMQSDigJMgd291bGQgYmVjb21lIHRoZSBwYXlsb2FkIG9mIHRo ZSBuZXcgZW5jYXBzdWxhdGluZyBidW5kbGUuJm5ic3A7DQogVGhlIGVuY2Fwc3VsYXRpbmcgYnVu ZGxlIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBzZWN1cml0eS1hd2FyZSwgYnV0IHRoYXQgZG9lc27i gJl0IG1hdHRlci4mbmJzcDsgVGhlIGRlc3RpbmF0aW9uIG9mIHRoZSBlbmNhcHN1bGF0aW5nIGJ1 bmRsZSB3b3VsZCBleHRyYWN0IHRoZSBlbmNhcHN1bGF0ZWQgYnVuZGxlICh0aGUg4oCcb3V0ZXLi gJ0gYnVuZGxl4oCZcyBwYXlsb2FkKSBhbmQgc2ltdWxhdGUgcmVjZXB0aW9uIG9mIHRoYXQgYnVu ZGxlLCB3aGljaCB3b3VsZCBzdGlsbA0KIGhhdmUgaXRzIEJBQi4mbmJzcDsgVGhhdCBidW5kbGUg d291bGQsIGluIGVmZmVjdCwgaGF2ZSB0cmF2ZXJzZWQgb25seSBhIHNpbmdsZSBob3AgKGRpcmVj dCB0cmFuc21pc3Npb24gYmV0d2VlbiBzZW5kZXIgYW5kIHJlY2VpdmVyIGF0IHRoZSBjb252ZXJn ZW5jZSBsYXllciksIHNvIHRoZXJlIHdhcyBubyBpbnRlcnZlbmluZyBub24tc2VjdXJpdHktYXdh cmUgZm9yd2FyZGluZyBub2RlIGJldHdlZW4gdGhlIHNlbmRpbmcgbm9kZSB0aGF0IGF0dGFjaGVk DQogdGhlIEJBQiBhbmQgdGhlIHJlY2VpdmluZyBub2RlIHRoYXQgd291bGQgdmFsaWRhdGUgaXQu Jm5ic3A7IFNvIG5vIG9wcG9ydHVuaXR5IGZvciBmcmFnbWVudGF0aW9uLCBubyBwcm9ibGVtLjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_A5BEAD028815CB40A32A5669CF737C3B423B4FCBapembxsp40RESAD_-- From nobody Mon Jun 2 10:07:14 2014 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485821A021F for ; Mon, 2 Jun 2014 10:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8MOFmC6H1wm for ; Mon, 2 Jun 2014 10:07:06 -0700 (PDT) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [IPv6:2001:4d0:a302:1100::102]) by ietfa.amsl.com (Postfix) with ESMTP id 408881A01ED for ; Mon, 2 Jun 2014 10:07:06 -0700 (PDT) Received: from ndmsppt102.ndc.nasa.gov (ndmsppt102.ndc.nasa.gov [198.117.0.67]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 728ECA80B2; Mon, 2 Jun 2014 12:07:00 -0500 (CDT) Received: from NDMSCHT116.ndc.nasa.gov (ndmscht116-pub.ndc.nasa.gov [198.117.0.216]) by ndmsppt102.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id s52H70q9031876; Mon, 2 Jun 2014 12:07:00 -0500 Received: from NDMSMBX404.ndc.nasa.gov ([169.254.4.107]) by NDMSCHT116.ndc.nasa.gov ([198.117.0.216]) with mapi id 14.03.0174.001; Mon, 2 Jun 2014 12:07:00 -0500 From: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" To: "Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]" , "Birrane, Edward J." , "dtn-security@irtf.org" Thread-Topic: Updated SBSP Document - BAB Thread-Index: Ac9+bH1OvS/DGr4rQCGazJjgMCXvZg== Date: Mon, 2 Jun 2014 17:06:59 +0000 Message-ID: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E29@NDMSMBX404.ndc.nasa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.119.225.34] Content-Type: multipart/alternative; boundary="_000_94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E29NDMSMBX404ndcnasa_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-02_02:2014-06-02,2014-06-02,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/r7WsStYzWxTC8_H3qq3ZnESj32s Subject: Re: [dtn-security] Updated SBSP Document - BAB X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 17:07:11 -0000 --_000_94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E29NDMSMBX404ndcnasa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Page 12] 2.4 Bundle Authentication Block The security-target MUST be the entire bundle, which MUST be represented by a of <0x00><0x00>. =B7 Per 3.4 Bundle Fragmentation and Reassembly, bundle authenticat= ion may be applied to bundle fragments as well as non-fragmented bundles. =B7 If a bundle fragment is received that has a BAB, there is no wa= y to determine if the BAB applies to the bundle fragment or if it applies t= o an entire bundle that was later fragmented by a non-security-aware BA. o I propose that a of <0x00> indicate that the BAB applies to a bundle fragment =B7 If such a bundle fragment is further fragmented by a non-securi= ty-aware BA then the can be used to determine that th= e original fragmented bundle must be reassembled before authentication is c= hecked because it will not match the length field in the payload block. o Some discussion may be desirable in section 3.4 as well as 2.4 if acce= pted =D8 When a BAB is attached to a bundle that is a fragment, the bundle that= it applies to is always that fragment, never the bundle that carried the o= riginal payload (of which the current bundle's payload is a fragment). Sin= ce BABs are not end-to-end, the BAB for an original un-fragmented bundle wi= ll never be carried forward in any fragments generated from that bundle (se= e the last paragraph of 3.3.1), so there's no ambiguity. But this does bri= ng up an important point: the block processing control flags of the BAB mus= t always have the "replicate in every fragment" flag set to 0. Maybe I'm misunderstanding here, but fragmentation can happen between a BAB= source and a BAB dest if a non-security aware node is between the two. Re= quiring the "DO_NOT_FRAGMENT" flag solves this. >> I see what you're saying, and I think it goes to the lament in= your next comment: the interaction between fragmentation and BSP really is= a mess. But I thought SBSP simplified things somewhat by not allowing any= non-security-aware nodes between the BAB source and BAB destination. At l= east, that's what I hoped we were doing, and it's how I interpret "BABs ope= rate between topologically adjacent nodes" on page 6. If that's not the ca= se then I think there are additional problems to resolve. BABs should be applied 'point-to-point' between bundle agents; there should= n't be an opportunity for a non-security-aware node to fragment a bundle wi= th a BAB on it. I'll have to check the cross-product between encapsulation= and BAB (i.e. whether you can encapsulate a bundle with a BAB on it (and t= hen possibly fragment the encapsulating bundle) or not). I suspect that th= e answer is 'no' (i.e. you check / remove the BAB immediately on receipt an= d before you encapsulate and/or fragment for transmission). =D8 There isn't really any accepted spec to consult on encapsulation, but w= ithin the concept that I've been working with (https://datatracker.ietf.org= /doc/draft-irtf-burleigh-bibe/) the encapsulation protocol is a convergence= -layer adapter. In that case, the entire, complete outbound bundle - inclu= ding any BAB that was attached at the last moment before serialization for = the CLA - would become the payload of the new encapsulating bundle. The en= capsulating bundle might or might not be security-aware, but that doesn't m= atter. The destination of the encapsulating bundle would extract the encap= sulated bundle (the "outer" bundle's payload) and simulate reception of tha= t bundle, which would still have its BAB. That bundle would, in effect, ha= ve traversed only a single hop (direct transmission between sender and rece= iver at the convergence layer), so there was no intervening non-security-aw= are forwarding node between the sending node that attached the BAB and the = receiving node that would validate it. So no opportunity for fragmentation= , no problem. Having outgoing email issues so some of this is now late and could be later= by the time it gets through - if it gets there. o This is true when all traversed nodes are SBSP compliant and we probabl= y do not want to overly complicate SBSP trying to anticipate and handle all= possible off-nominal scenarios. One of the off-nominal scenarios that I wo= uld not be surprised to see with the Space Station is the case where our ga= teway nodes are running pre-SBSP software and a payload developer installs = a cutting edge SBSP implementation. In this scenario, if the payload node a= pplies a BAB to a large bundle [or fragment] then there is the possibility = that the pre-SBSP gateway node will fragment [or further fragment] the bund= le and not remove the BAB resulting in its misinterpretation when it makes = to the end node that is SBSP compliant. o I am okay with not specifically handling this scenario as we can recomm= end not using the BAB until the gateway nodes are updated to SBSP complianc= e or that their local policy set the 'Discard block if it can't be processe= d' flag on the BAB. =A7 Amy mentioned the DO_NOT_FRAGMENT" flag as another possible option bef= ore I could send this reply due to system and email issues (and maybe I am = a slow typist)... =B7 What happens if there is a conflict between DO_NOT_FRAGMENT and= "must fragment if bigger than x"? Is the bundle sent whole, trapped, or de= leted? =A7 And now - the suggested BIBE is another good approach o If this particular scenario might impact other folks as well and the co= nsensus is to handle it then a refinement would be to use the = to hold the fragment offset so that a further fragmented fragment could be = more reliably reconstituted and BAB verified. I "think" this would make the= BAB "SBSP_hop - to - SBSP_hop" regardless of the compliance of any interve= ning nodes. --_000_94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E29NDMSMBX404ndcnasa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

<DZ>

[Page 12] 2.4 Bundle Authentication Block

= The security-target MUST be the entire bundle, which MUST be

= represented by a <block type><occurrence number> of <0x00>= ;<0x00>.

=B7         Per 3.4 Bundle= Fragmentation and Reassembly, bundle authentication may be applied to bund= le fragments as well as non-fragmented bundles.

=B7         If a bundle fr= agment is received that has a BAB, there is no way to determine if the BAB = applies to the bundle fragment or if it applies to an entire bundle that wa= s later fragmented by a non-security-aware BA.

o    I propose that= a <block type><occurrence number> of <0x00><payload f= rag length> indicate that the BAB applies to a bundle fragment

=B7         If such a bund= le fragment is further fragmented by a non-security-aware BA then the <p= ayload frag length> can be used to determine that the original fragmente= d bundle must be reassembled before authentication is checked because it will not match the length field in the payload block= .

o    Some discussio= n may be desirable in section 3.4 as well as 2.4 if accepted

<SB>

=D8  When a BAB is = attached to a bundle that is a fragment, the bundle that it applies to is a= lways that fragment, never the bundle that carried the original payload (of= which the current bundle’s payload is a fragment).  Since BABs are not end-to-end, the BAB for an origin= al un-fragmented bundle will never be carried forward in any fragments gene= rated from that bundle (see the last paragraph of 3.3.1), so there’s = no ambiguity.  But this does bring up an important point: the block processing control flags of the BAB must always have the = “replicate in every fragment” flag set to 0.<= /p>

 

<AA>

Maybe I'm misunderstanding here, but fragmentation c= an happen between a BAB source and a BAB dest if a non-security aware node = is between the two.  Requiring the "DO_NOT_FRAGMENT" flag so= lves this.  

 

<SB>

>>  &n= bsp;        I see what you’re sayi= ng, and I think it goes to the lament in your next comment: the interaction= between fragmentation and BSP really is a mess.  But I thought SBSP s= implified things somewhat by not allowing any non-security-aware nodes between the BAB source and BAB d= estination.  At least, that’s what I hoped we were doing, and it= ’s how I interpret “BABs operate between topologically adjacent nodes” on page 6.  If that= ’s not the case then I think there are additional problems to resolve= .

 

<KS>

BABs = should be applied ‘point-to-point’ between bundle agents; there= shouldn’t be an opportunity for a non-security-aware node to fragmen= t a bundle with a BAB on it.  I’ll have to check the cross-produ= ct between encapsulation and BAB (i.e. whether you can encapsulate a bundle w= ith a BAB on it (and then possibly fragment the encapsulating bundle) or no= t).  I suspect that the answer is ‘no’ (i.e. you check / r= emove the BAB immediately on receipt and before you encapsulate and/or fragment for transmission).

 

<SB>

=D8 There isn’t really any accepted spec to consult on encapsulation, = but within the concept that I’ve been working with (https://datatracker.i= etf.org/doc/draft-irtf-burleigh-bibe/) the encapsulation protocol is a convergence-layer adapter.  In that c= ase, the entire, complete outbound bundle – including any BAB that wa= s attached at the last moment before serialization for the CLA – woul= d become the payload of the new encapsulating bundle.  The encapsulating bundle might or might not be security-aware, but that do= esn’t matter.  The destination of the encapsulating bundle would= extract the encapsulated bundle (the “outer” bundle’s pa= yload) and simulate reception of that bundle, which would still have its BAB.  That bundle would, in effect, have traversed only a si= ngle hop (direct transmission between sender and receiver at the convergenc= e layer), so there was no intervening non-security-aware forwarding node be= tween the sending node that attached the BAB and the receiving node that would validate it.  So no opportu= nity for fragmentation, no problem.

&nbs= p;

 

<DZ>

Having outgoing email = issues so some of this is now late and could be later by the time it gets t= hrough – if it gets there.

o   This is true w= hen all traversed nodes are SBSP compliant and we probably do not want to o= verly complicate SBSP trying to anticipate and handle all possible off-nomi= nal scenarios. One of the off-nominal scenarios that I would not be surprised to see with the Space Station is t= he case where our gateway nodes are running pre-SBSP software and a payload= developer installs a cutting edge SBSP implementation. In this scenario, i= f the payload node applies a BAB to a large bundle [or fragment] then there is the possibility that the pre= -SBSP gateway node will fragment [or further fragment] the bundle and not r= emove the BAB resulting in its misinterpretation when it makes to the end n= ode that is SBSP compliant.

o   I am okay with= not specifically handling this scenario as we can recommend not using the = BAB until the gateway nodes are updated to SBSP compliance or that their lo= cal policy set the ‘Discard block if it can’t be processed’ flag on the BAB.

=A7  Amy mentioned = the DO_NOT_FRAGMENT” flag as another possible option before I could s= end this reply due to system and email issues (and maybe I am a slow typist= )…

=B7         What happens i= f there is a conflict between DO_NOT_FRAGMENT and “must fragment if b= igger than x”? Is the bundle sent whole, trapped, or deleted?

=A7  And now - the = suggested BIBE is another good approach

o   If this partic= ular scenario might impact other folks as well and the consensus is to hand= le it then a refinement would be to use the <block type> to hold the = fragment offset so that a further fragmented fragment could be more reliably reconstituted and BAB verified. I “t= hink” this would make the BAB “SBSP_hop - to - SBSP_hop” = regardless of the compliance of any intervening nodes.

 

 

 

--_000_94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E29NDMSMBX404ndcnasa_-- From nobody Mon Jun 2 10:20:51 2014 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346F11A024D for ; Mon, 2 Jun 2014 10:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rarQOC1HkDho for ; Mon, 2 Jun 2014 10:20:47 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [IPv6:2001:4d0:a302:1100::101]) by ietfa.amsl.com (Postfix) with ESMTP id AC3A31A01ED for ; Mon, 2 Jun 2014 10:20:46 -0700 (PDT) Received: from ndmsppt104.ndc.nasa.gov (ndmsppt104.ndc.nasa.gov [198.117.0.69]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 66AA8D051E; Mon, 2 Jun 2014 12:15:02 -0500 (CDT) Received: from NDMSCHT109.ndc.nasa.gov (ndmscht109-pub.ndc.nasa.gov [198.117.0.209]) by ndmsppt104.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id s52HKeen008379; Mon, 2 Jun 2014 12:20:40 -0500 Received: from NDMSMBX404.ndc.nasa.gov ([169.254.4.107]) by NDMSCHT109.ndc.nasa.gov ([198.117.0.209]) with mapi id 14.03.0174.001; Mon, 2 Jun 2014 12:20:40 -0500 From: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" To: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" , "Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]" , "Birrane, Edward J." , "dtn-security@irtf.org" Thread-Topic: Updated SBSP Document - BCB and BIB Thread-Index: Ac9+hoOpmbVxZkqoRbuTayxesOBSNw== Date: Mon, 2 Jun 2014 17:20:40 +0000 Message-ID: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E56@NDMSMBX404.ndc.nasa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.119.225.34] Content-Type: multipart/alternative; boundary="_000_94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E56NDMSMBX404ndcnasa_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-02_02:2014-06-02,2014-06-02,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/OVJ_YYAIrP76RyfF_SdoS4o6pq8 Subject: Re: [dtn-security] Updated SBSP Document - BCB and BIB X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 17:20:49 -0000 --_000_94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E56NDMSMBX404ndcnasa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Page 14] 2.6 Block Confidentiality Block The block processing control flags value can be set to whatever values are required by local policy, except that a Lone BCB or First BCB MUST have the "replicate in every fragment" flag set. This indicates to a receiving node that the payload portion in each fragment represents cipher-text. =B7 The intent here is only if the target of the Lone BCB or First = BCB is the payload block which would need to be added if this is kept as a = requirement. =B7 I think this requirement should be removed or at least reduced = to a "MAY" 1. It assumes that the Lone or First BCB must be prior to the payload= block which is not a specific requirement and is not necessary in any case= for SBSP 2. A BCB block could be quite large and add a lot of bandwidth overhe= ad if included in every fragment 3. I do not see a benefit gained by including the block in every frag= ment i. Even the destination n= ode likely cannot decrypt any individual fragment except the first one and = it probably would only decrypt a partial bundle as a last resort or forens= ic function if the entire bundle was not received before expiration ii. Intermediate nodes shou= ldn't generally be poking around in bundle payloads anyway and no need to p= rovide additional clues as to whether a fragment payload is encrypted or a = bunch of binary values - keep the bad guys guessing and wasting CPU cycles = if possible iii. BSP includes this requi= rement - have any of the implementations found a need or benefit for this a= nd would it still apply in context of the SBSP? =D8 I think this a good point. Since all decryption should only happen at= the bundle destination, which is where all the fragments are going to have= to end up, why not forward all BCBs (for all blocks that have them) only w= ith the fragment whose offset is zero? Is there a possibility of an intermediate node adding a BIB to the fragment= , unaware that there's already a BCB on the whole payload? I really hate t= he interaction between fragmentation and BSP. I feel like tightly locking = down how the two of them combine avoids a lot of pitfalls and ambiguity. My notion is that the BCB should apply to the entire (unfragmented) payload= . If it's possible to apply a BCB to a fragment (in the middle of a path a= nd connection) then the BCB itself had better state to which bytes of the p= ayload it applies, or it's going to be really hard to sort it out later. What's the rationale for replication? The destination is the only node tha= t's going to have to deal with decryption, so what is this doing? Is the n= otion that the receiver might pass parts of the not-yet-fully-received bund= le to the application? That would be, I think, wrong. Fortunately, section 3.4 does prevent adding a BCB or a BIB to a fragment. --_000_94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E56NDMSMBX404ndcnasa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

<DZ>

[Page 14] 2.6 Block Confidentiality Block

= The block processing control flags value can be set to whatever<= /span>

= values are required by local policy, except that a Lone BCB or

= First BCB MUST have the "replicate in every fragment" flag set.

= This indicates to a receiving node that the payload portion in

= each fragment represents cipher-text.

=B7         The intent her= e is only if the target of the Lone BCB or First BCB is the payload block w= hich would need to be added if this is kept as a requirement.

=B7         I think this r= equirement should be removed or at least reduced to a "MAY"

1. &nbs= p;     It assumes tha= t the Lone or First BCB must be prior to the payload block which is not a s= pecific requirement and is not necessary in any case for SBSP

2. &nbs= p;     A BCB block co= uld be quite large and add a lot of bandwidth overhead if included in every= fragment

3. &nbs= p;     I do not see a= benefit gained by including the block in every fragment

  =             &nb= sp;            =             i.  = ;          Even the destination node likely = cannot decrypt any individual fragment except the first one and  it pr= obably would only decrypt a partial bundle as a last resort or forensic function if the entire bundle was not = received before expiration

  =             &nb= sp;            =           ii. &nbs= p;          Intermediate nodes shouldn't gen= erally be poking around in bundle payloads anyway and no need to provide ad= ditional clues as to whether a fragment payload is encrypted or a bunch of binary values – keep t= he bad guys guessing and wasting CPU cycles if possible

  =             &nb= sp;            =          iii. &nb= sp;          BSP includes this requirement -= have any of the implementations found a need or benefit for this and would= it still apply in context of the SBSP?

 

<SB>

=D8  I think this a= good point.  Since all decryption should only happen at the bundle de= stination, which is where all the fragments are going to have to end up, wh= y not forward all BCBs (for all blocks that have them) only with the fragment whose offset is zero?   <= /span>

 

<AA> 

Is there a possibility of an intermediate node addin= g a BIB to the fragment, unaware that there's already a BCB on the whole pa= yload?  I really hate the interaction between fragmentation and BSP. &= nbsp;I feel like tightly locking down how the two of them combine avoids a lot of pitfalls and ambiguity.

 

 

&l= t;KS>

My no= tion is that the BCB should apply to the entire (unfragmented) payload.&nbs= p; If it’s possible to apply a BCB to a fragment (in the middle of a = path and connection) then the BCB itself had better state to which bytes of the payload it applies, or it’s going to be = really hard to sort it out later.

=  

What&= #8217;s the rationale for replication?  The destination is the only no= de that’s going to have to deal with decryption, so what is this doin= g?  Is the notion that the receiver might pass parts of the not-yet-fully-received bundle to the application?  That would = be, I think, wrong.

 

<D= Z>

Fortu= nately, section 3.4 does prevent adding a BCB or a BIB to a fragment.

--_000_94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E56NDMSMBX404ndcnasa_-- From nobody Mon Jun 2 11:01:21 2014 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425DA1A0260 for ; Mon, 2 Jun 2014 11:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lbp2JpHsEpGO for ; Mon, 2 Jun 2014 11:01:15 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [IPv6:2001:4d0:a302:1100::101]) by ietfa.amsl.com (Postfix) with ESMTP id 2D26D1A025B for ; Mon, 2 Jun 2014 11:01:15 -0700 (PDT) Received: from ndmsppt103.ndc.nasa.gov (ndmsppt103.ndc.nasa.gov [198.117.0.68]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id A8402D0503; Mon, 2 Jun 2014 12:55:28 -0500 (CDT) Received: from NDMSCHT104.ndc.nasa.gov (ndmscht104-pub.ndc.nasa.gov [198.117.0.204]) by ndmsppt103.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id s52I17Fs008774; Mon, 2 Jun 2014 13:01:07 -0500 Received: from NDMSMBX404.ndc.nasa.gov ([169.254.4.107]) by NDMSCHT104.ndc.nasa.gov ([198.117.0.204]) with mapi id 14.03.0174.001; Mon, 2 Jun 2014 13:01:07 -0500 From: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" To: "Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]" , "Birrane, Edward J." , "dtn-security@irtf.org" Thread-Topic: Updated SBSP Document - Canonicalization of Extension Blocks Thread-Index: Ac9+iuEjMG+dNHBvSEOuNdHOvLFJHg== Date: Mon, 2 Jun 2014 18:01:06 +0000 Message-ID: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E85@NDMSMBX404.ndc.nasa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.119.225.34] Content-Type: multipart/alternative; boundary="_000_94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E85NDMSMBX404ndcnasa_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-02_02:2014-06-02,2014-06-02,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/gH_-pkTduMNubgr99FqEUr_pZAU Subject: Re: [dtn-security] Updated SBSP Document - Canonicalization of Extension Blocks X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 18:01:19 -0000 --_000_94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E85NDMSMBX404ndcnasa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Page 24] 3.1.2.3 Extension Block Canonicalization Endpoint ID references in blocks are canonicalized using the de- referenced text form in place of the reference pair. The reference count is not included, nor is the length of the endpoint ID text. The EID reference is, therefore, canonicalized as :, which includes the ":" character. =B7 Need to include a statement to the effect: o Artificial EIDs as defined in this document (ssp reference is 0x00) mu= st be skipped and are not included in the canonicalization. =D8 Right, the AEID's offsets don't reference text in the dictionary. Goo= d catch! [Page 24] 3.1.2.3 Extension Block Canonicalization The block-length is canonicalized as its unpacked SDNV value. If the data to be canonicalized is less than the complete, original block data, this field contains the size of the data being canonicalized (the "effective block") rather than the actual size of the block. =B7 Section 3.1.2.1 (Primary Block Canonicalization) details the le= ngth fields as 4 byte values and effectively reserves the term "unpacked SD= NV value" to mean the 8 byte value. I recommend using the same convention h= ere. o Personally, I would specify all SDNV values canonicalized as 8 byte va= lues and be done with it =B7 Add a statement to the effect: o The entirety or portion(s) of the block body data are canonicalized as= is. =D8 I agree about canonicalizing all SDNVs as 8-byte values. FWIW, I thin= k the canonicalization in bundle security protocol is a major pain in the n= eck. Is the mutability of blocks - the need to exclude mutable fields from= hash computations - the main reason for it? Is there no way to simplify? [Page 23] 3.1.2.2 Payload Block Canonicalization When canonicalizing the payload block, the block processing control flags value used for canonicalization is the unpacked SDNV value with reserved and mutable bits masked to zero. The unpacked value is ANDed with mask 0x0000 0000 0000 0077 to zero reserved bits and the "last block" bit. The "last block" bit is ignored because BABs and other security blocks MAY be added for some parts of the journey but not others, so the setting of this bit might change from hop to hop. Payload blocks are canonicalized as-is, with the exception that, in some instances, only a portion of the payload data is to be protected. In such a case, only those bytes are included in the canonical form, and additional cipher suite parameters are required to specify which part of the payload is protected, as discussed further below. =B7 The processing control flags are pulled out and masked so the P= ayload block can no longer be considered canonicalized "as-is". =B7 A Payload Block is the same underlying format as an Extension B= lock with the restriction that the 'block contains an EID-reference field' = is never set and it should follow the same canonicalization methodology as = that of the Extension Block o I propose a single "Non-Primary Block Canonicalization" section based = on the finalized version of the Extension Block Canonicalization =D8 Again I complain about canonicalization. I think the major issue is the dictionary, since it can be modified even if= the actual eid's in the block are stable. The flags are straightforward. = In BSP, there's also a big issue with tail chasing when a PIB block is req= uired to include chunks of itself in it's own hash. IIRC, SBSP avoids that= entirely. >> Which is a major reason that I want to get rid of the dictiona= ry altogether in "RFC5050bis". =B7 Could the processing flags be ignored? Ultimately, either the b= lock makes it to the destination or it does not. If a changed flag did not = prevent it getting there then would you want to discard the block or bundle= if that truly was the only change? =B7 The length field could be left out as a change in it should be = detected in the hash of the block data =B7 I don't see a simplification of the dictionary issue as-is eith= er; although, the separating semicolons are not really needed. --_000_94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E85NDMSMBX404ndcnasa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

<DZ>

[Page 24] 3.1.2.3 Extension Block Canonicalizatio= n

= Endpoint ID references in blocks are canonicalized using the de-=

= referenced text form in place of the reference pair.  The reference

= count is not included, nor is the length of the endpoint ID text.

= The EID reference is, therefore, canonicalized as <scheme>:<SSP>= ;,

= which includes the ":" character.

=B7         Need to includ= e a statement to the effect:

o    Artificial EID= s as defined in this document (ssp reference is 0x00) must be skipped and a= re not included in the canonicalization.<SB>

=D8  Right, the AEI= D’s offsets don’t reference text in the dictionary.  Good = catch!

 

 

 [Page 24] 3.1.2.3 Extension Block Canonical= ization

= The block-length is canonicalized as its unpacked SDNV value.  If the<= o:p>

= data to be canonicalized is less than the complete, original block

= data, this field contains the size of the data being canonicalized

= (the "effective block") rather than the actual size of the block.=

=B7         Section 3.1.2.= 1 (Primary Block Canonicalization) details the length fields as 4 byte valu= es and effectively reserves the term "unpacked SDNV value" to mea= n the 8 byte value. I recommend using the same convention here.

o    Personally, I = would specify all SDNV values canonicalized as 8 byte values and be done wi= th it

=B7         Add a statemen= t to the effect:

o    The entirety o= r portion(s) of the block body data are canonicalized as is.

=D8  I agree about = canonicalizing all SDNVs as 8-byte values.  FWIW, I think the canonica= lization in bundle security protocol is a major pain in the neck.  Is = the mutability of blocks – the need to exclude mutable fields from hash computations – the main reason for it? = ; Is there no way to simplify?

 

 

[Page 23] 3.1.2.2 Payload Block Canonicalization<= /b>

= When canonicalizing the payload block, the block processing control

= flags value used for canonicalization is the unpacked SDNV value with<= /o:p>

= reserved and mutable bits masked to zero.  The unpacked value is<= /o:p>

= ANDed with mask 0x0000 0000 0000 0077 to zero reserved bits and the

= "last block" bit.  The "last block" bit is ignored= because BABs and

= other security blocks MAY be added for some parts of the journey but

= not others, so the setting of this bit might change from hop to hop.

=  

= Payload blocks are canonicalized as-is, with the exception that, in

= some instances, only a portion of the payload data is to be

= protected.  In such a case, only those bytes are included in the<= /o:p>

= canonical form, and additional cipher suite parameters are required

= to specify which part of the payload is protected, as discussed<= /span>

= further below.

=B7         The processing= control flags are pulled out and masked so the Payload block can no longer= be considered canonicalized "as-is".

=B7         A Payload Bloc= k is the same underlying format as an Extension Block with the restriction = that the 'block contains an EID-reference field' is never set and it should= follow the same canonicalization methodology as that of the Extension Block

o    I propose a si= ngle "Non-Primary Block Canonicalization" section based on the fi= nalized version of the Extension Block Canonicalization

=D8  Again I compla= in about canonicalization.<= /span>

 

 

 

 

<AA>

I think the major issue is the dictionary, since it = can be modified even if the actual eid's in the block are stable.  The= flags are straightforward.  In BSP, there's also a big issue with tai= l chasing when a PIB block is required to include chunks of itself in it's own hash.  IIRC, SBSP avoids that entirely. =   

 

<SB>

>>  &n= bsp;        Which is a major reason that= I want to get rid of the dictionary altogether in “RFC5050bis”= .

 

 

<DZ>

=B7      &nb= sp;  Could the proc= essing flags be ignored? Ultimately, either the block makes it to the desti= nation or it does not. If a changed flag did not prevent it getting there t= hen would you want to discard the block or bundle if that truly was the only change?

=B7      &nb= sp;  The length fie= ld could be left out as a change in it should be detected in the hash of th= e block data

=B7      &nb= sp;  I don’t = see a simplification of the dictionary issue as-is either; although, the se= parating semicolons are not really needed.

--_000_94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E85NDMSMBX404ndcnasa_-- From nobody Mon Jun 2 17:53:16 2014 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CCD1A0004 for ; Mon, 2 Jun 2014 17:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5SQFZsyaGAM for ; Mon, 2 Jun 2014 17:53:12 -0700 (PDT) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BADAB1A0002 for ; Mon, 2 Jun 2014 17:53:12 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id n16so5450553oag.38 for ; Mon, 02 Jun 2014 17:53:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=J52FXJP9STYP0s4heGCu8PrCReMMVzss8gnXuscZGDs=; b=N3lETupxfT2FHUw2erQqpw9ytp3Wb49UGtizWh46TYnYrMBZ5dRtpcmnMZvZp9ZrBh UfaIAy1l+Vy58yXvpmYRRb7uL/5pWB7T8NEr5Ryu5fbQTka0yJqwA03dbP40gFUu7mfh xxi8j3lD7zeZZZ2IOzsyWb5fGO44XHduPsNmnuNvEhQCy1wKw2D5kk341F5ZxKP8esuV 4EqPtYtfY3Ry9TFIj7aOkMYCYmIe6FZtE9yDMa4rTmocyp/UGe/3yT1SdzI7a/SnUxG2 7wgvBzdsf6PkX9PIKH09W3b0dWLDEqk0hTjdksJWqIKlLpxjRYrnbcGqDzcDqcH5+LrK SF2g== X-Gm-Message-State: ALoCoQnCL5/IiL9r/IFDT1YBLP6ykpKvy8vCYx1LFv3tjVQA+g45hs9YrWsBnJu9U4UAy7yW6En7 MIME-Version: 1.0 X-Received: by 10.182.163.45 with SMTP id yf13mr8058698obb.66.1401756786459; Mon, 02 Jun 2014 17:53:06 -0700 (PDT) Received: by 10.182.176.5 with HTTP; Mon, 2 Jun 2014 17:53:06 -0700 (PDT) In-Reply-To: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E85@NDMSMBX404.ndc.nasa.gov> References: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E85@NDMSMBX404.ndc.nasa.gov> Date: Mon, 2 Jun 2014 20:53:06 -0400 Message-ID: From: Amy Alford To: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" Content-Type: multipart/alternative; boundary=e89a8f503b5c5198fd04fae3efad Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/kXNaMBy8rv5L8xQEczOeF_wcR_M Cc: "Burleigh, Scott C \(JPL-312G\)\[Jet Propulsion Laboratory\]" , "dtn-security@irtf.org" Subject: Re: [dtn-security] Updated SBSP Document - Canonicalization of Extension Blocks X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 00:53:15 -0000 --e89a8f503b5c5198fd04fae3efad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 2, 2014 at 2:01 PM, Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] wrote: > > =C2=B7 I don=E2=80=99t see a simplification of the dictionary iss= ue as-is > either; although, the separating semicolons are not really needed. > We discussed this when brainstorming the draft, and I was concerned that the uri "dtn:foo" and the uri "dtnf:oo" hash to the same thing if you cannonicalize without the colon. Similarly, if there's no delimiter between dictionary entries, there's ambiguity. I don't see anything nefarious you can do with this, but it's undesirable that two different bundles have the same hash, even if one of them is nonsense. --e89a8f503b5c5198fd04fae3efad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jun 2, 2014 at 2:01 PM, Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONT= RACT] <david.a.zoller@nasa.gov> wrote:


=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I don=E2=80=99t s= ee a simplification of the dictionary issue as-is either; although, the sep= arating semicolons are not really needed.

We discussed this when brainstorming the draft, and I wa= s concerned that the uri "dtn:foo" and the uri "dtnf:oo"= ; hash to the same thing if you cannonicalize without the colon. =C2=A0Simi= larly, if there's no delimiter between dictionary entries, there's = ambiguity. =C2=A0I don't see anything nefarious you can do with this, b= ut it's undesirable that two different bundles have the same hash, even= if one of them is nonsense.

--e89a8f503b5c5198fd04fae3efad-- From nobody Tue Jun 3 05:49:50 2014 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028301A01F3 for ; Tue, 3 Jun 2014 05:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3p1o7K0XH25m for ; Tue, 3 Jun 2014 05:49:43 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [IPv6:2001:4d0:a302:1100::101]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD9A1A01D9 for ; Tue, 3 Jun 2014 05:49:43 -0700 (PDT) Received: from ndmsppt104.ndc.nasa.gov (ndmsppt104.ndc.nasa.gov [198.117.0.69]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 5A6D5D0581; Tue, 3 Jun 2014 07:43:55 -0500 (CDT) Received: from NDMSCHT113.ndc.nasa.gov (ndmscht113-pub.ndc.nasa.gov [198.117.0.213]) by ndmsppt104.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id s53CnaNV025835; Tue, 3 Jun 2014 07:49:37 -0500 Received: from NDMSMBX404.ndc.nasa.gov ([169.254.4.107]) by NDMSCHT113.ndc.nasa.gov ([198.117.0.213]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 07:49:36 -0500 From: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" To: Amy Alford Thread-Topic: [dtn-security] Updated SBSP Document - Canonicalization of Extension Blocks Thread-Index: Ac9+iuEjMG+dNHBvSEOuNdHOvLFJHgAZTXYAAAwxBOA= Date: Tue, 3 Jun 2014 12:49:36 +0000 Message-ID: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D9006@NDMSMBX404.ndc.nasa.gov> References: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E85@NDMSMBX404.ndc.nasa.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.119.225.34] Content-Type: multipart/alternative; boundary="_000_94CFB3711B4CAE4DBFC5BEB3374BF0C60D9006NDMSMBX404ndcnasa_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-02_03:2014-06-02,2014-06-02,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/adTO6B8lzq0_rzocee_MRgHUpxM Cc: "Burleigh, Scott C \(JPL-312G\)\[Jet Propulsion Laboratory\]" , "dtn-security@irtf.org" Subject: Re: [dtn-security] Updated SBSP Document - Canonicalization of Extension Blocks X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 12:49:48 -0000 --_000_94CFB3711B4CAE4DBFC5BEB3374BF0C60D9006NDMSMBX404ndcnasa_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnksIEkgc2hvdWxkIGhhdmUgZG91YmxlIGNoZWNrZWQgdGhlIHNwZWMgaW5zdGVhZCBvZiBy ZWx5aW5nIG9uIG1lbW9yeS4gSSB3YXMgcmVmZXJyaW5nIHRvIHRoZSBkZWxpbWl0ZXIgYmV0d2Vl biB0aGUgZW50cmllcyB3aGljaCBpcyBhIGNvbW1hIHJhdGhlciB0aGFuIGEgc2VtaWNvbG9uIGJ1 dCB5b3UgY292ZXJlZCBib3RoIHBvc3NpYmlsaXRpZXMuIEJhc2ljYWxseSwgdGhlIGRpY3Rpb25h cnkgYW5kIHRoZSBibG9jayBFSUQgcmVmZXJlbmNlcyBjYW4gYmUgbWFuaXB1bGF0ZWQgdG8gaW5j bHVkZSBhbmQgcG9pbnQgdG8gYSBib2d1cyBVUkkgdGhhdCBjYW5vbmljYWxpemVzIHRvIHRoZSBz YW1lIHN0cmluZyBhcyB0aGUgb3JpZ2luYWwgYmxvY2sgRUlEcyBzbyB0aGF0IGl0IHdvdWxkIHBh c3MgdGhlIGludGVncml0eSBjaGVjayBidXQgY2F1c2UgaXNzdWVzIHRyeWluZyB0byB1c2UgdGhl IGJvZ3VzIFVSSS4gRXZlbiB1c2luZyBhIHNlcGFyYXRvciBkZWxpbWl0ZXIsIGl0IGlzIHBvc3Np YmxlIHRvIHJlcGxhY2UgdHdvIG9yIG1vcmUgVVJJcyB3aXRoIGEgc2luZ2xlIGJvZ3VzIFVSSSBi eSBpbmNsdWRpbmcgdGhlIHNlcGFyYXRvciBkZWxpbWl0ZXIocykgYW5kIGl0IHdvdWxkIGJlIGEg dmFsaWQgVVJJIHRvIGJvb3QgLS0gcmVwbGFjZSB0aGUgdHdvIEVJRHMg4oCcZHRuOmZvb+KAnSzi gJ1kdG46YmFy4oCdIHdpdGggdGhlIHNpbmdsZSBFSUQg4oCcZHRuOmZvbyxkdG46YmFy4oCdLg0K DQpJIGhhZCBub3QgdGhvdWdodCBvZiB0aGF0IHNvcnQgb2YgZGV2aW91c25lc3MgYW5kIEkgdGhp bmsgaXQgaGVscHMgYm9sc3RlciBTY290dOKAmXMgY2FzZSB0byBnZXQgcmlkIG9mIHRoZSBkaWN0 aW9uYXJ5IGluIHRoZSDigJxSRkM1MDUwYmlz4oCdLg0KDQpEYXZpZCBab2xsZXINCkNPTFNBIENv cnBvcmF0aW9uDQpNU0ZDL0hPU0MgLSBDMTA3DQrigKJPZmZpY2U6ICgyNTYpIDU0NC0xODIwDQri gKJFTWFpbDogZGF2aWQuYS56b2xsZXJAbmFzYS5nb3Y8bWFpbHRvOmRhdmlkLmEuem9sbGVyQG5h c2EuZ292Pg0KDQpGcm9tOiBBbXkgQWxmb3JkIFttYWlsdG86YWxvb21pc0BzYXJuLm9yZ10NClNl bnQ6IE1vbmRheSwgSnVuZSAwMiwgMjAxNCA3OjUzIFBNDQpUbzogWm9sbGVyLCBEYXZpZCBBLiAo TVNGQy1FTzUwKVtIT1NDIFNFUlZJQ0VTIENPTlRSQUNUXQ0KQ2M6IEJ1cmxlaWdoLCBTY290dCBD IChKUEwtMzEyRylbSmV0IFByb3B1bHNpb24gTGFib3JhdG9yeV07IEJpcnJhbmUsIEVkd2FyZCBK LjsgZHRuLXNlY3VyaXR5QGlydGYub3JnDQpTdWJqZWN0OiBSZTogW2R0bi1zZWN1cml0eV0gVXBk YXRlZCBTQlNQIERvY3VtZW50IC0gQ2Fub25pY2FsaXphdGlvbiBvZiBFeHRlbnNpb24gQmxvY2tz DQoNCk9uIE1vbiwgSnVuIDIsIDIwMTQgYXQgMjowMSBQTSwgWm9sbGVyLCBEYXZpZCBBLiAoTVNG Qy1FTzUwKVtIT1NDIFNFUlZJQ0VTIENPTlRSQUNUXSA8ZGF2aWQuYS56b2xsZXJAbmFzYS5nb3Y8 bWFpbHRvOmRhdmlkLmEuem9sbGVyQG5hc2EuZ292Pj4gd3JvdGU6DQoNCg0K4oCiICAgICAgICAg SSBkb27igJl0IHNlZSBhIHNpbXBsaWZpY2F0aW9uIG9mIHRoZSBkaWN0aW9uYXJ5IGlzc3VlIGFz LWlzIGVpdGhlcjsgYWx0aG91Z2gsIHRoZSBzZXBhcmF0aW5nIHNlbWljb2xvbnMgYXJlIG5vdCBy ZWFsbHkgbmVlZGVkLg0KV2UgZGlzY3Vzc2VkIHRoaXMgd2hlbiBicmFpbnN0b3JtaW5nIHRoZSBk cmFmdCwgYW5kIEkgd2FzIGNvbmNlcm5lZCB0aGF0IHRoZSB1cmkgImR0bjpmb28iIGFuZCB0aGUg dXJpICJkdG5mOm9vIiBoYXNoIHRvIHRoZSBzYW1lIHRoaW5nIGlmIHlvdSBjYW5ub25pY2FsaXpl IHdpdGhvdXQgdGhlIGNvbG9uLiAgU2ltaWxhcmx5LCBpZiB0aGVyZSdzIG5vIGRlbGltaXRlciBi ZXR3ZWVuIGRpY3Rpb25hcnkgZW50cmllcywgdGhlcmUncyBhbWJpZ3VpdHkuICBJIGRvbid0IHNl ZSBhbnl0aGluZyBuZWZhcmlvdXMgeW91IGNhbiBkbyB3aXRoIHRoaXMsIGJ1dCBpdCdzIHVuZGVz aXJhYmxlIHRoYXQgdHdvIGRpZmZlcmVudCBidW5kbGVzIGhhdmUgdGhlIHNhbWUgaGFzaCwgZXZl biBpZiBvbmUgb2YgdGhlbSBpcyBub25zZW5zZS4NCg0K --_000_94CFB3711B4CAE4DBFC5BEB3374BF0C60D9006NDMSMBX404ndcnasa_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Tb3JyeSwgSSBzaG91bGQgaGF2ZSBkb3VibGUg Y2hlY2tlZCB0aGUgc3BlYyBpbnN0ZWFkIG9mIHJlbHlpbmcgb24gbWVtb3J5LiBJIHdhcyByZWZl cnJpbmcgdG8gdGhlIGRlbGltaXRlciBiZXR3ZWVuIHRoZSBlbnRyaWVzIHdoaWNoIGlzIGEgY29t bWEgcmF0aGVyIHRoYW4NCiBhIHNlbWljb2xvbiBidXQgeW91IGNvdmVyZWQgYm90aCBwb3NzaWJp bGl0aWVzLiBCYXNpY2FsbHksIHRoZSBkaWN0aW9uYXJ5IGFuZCB0aGUgYmxvY2sgRUlEIHJlZmVy ZW5jZXMgY2FuIGJlIG1hbmlwdWxhdGVkIHRvIGluY2x1ZGUgYW5kIHBvaW50IHRvIGEgYm9ndXMg VVJJIHRoYXQgY2Fub25pY2FsaXplcyB0byB0aGUgc2FtZSBzdHJpbmcgYXMgdGhlIG9yaWdpbmFs IGJsb2NrIEVJRHMgc28gdGhhdCBpdCB3b3VsZCBwYXNzIHRoZSBpbnRlZ3JpdHkNCiBjaGVjayBi dXQgY2F1c2UgaXNzdWVzIHRyeWluZyB0byB1c2UgdGhlIGJvZ3VzIFVSSS4gRXZlbiB1c2luZyBh IHNlcGFyYXRvciBkZWxpbWl0ZXIsIGl0IGlzIHBvc3NpYmxlIHRvIHJlcGxhY2UgdHdvIG9yIG1v cmUgVVJJcyB3aXRoIGEgc2luZ2xlIGJvZ3VzIFVSSSBieSBpbmNsdWRpbmcgdGhlIHNlcGFyYXRv ciBkZWxpbWl0ZXIocykgYW5kIGl0IHdvdWxkIGJlIGEgdmFsaWQgVVJJIHRvIGJvb3QgLS0gcmVw bGFjZSB0aGUgdHdvIEVJRHMg4oCcZHRuOmZvb+KAnSzigJ1kdG46YmFy4oCdDQogd2l0aCB0aGUg c2luZ2xlIEVJRCDigJxkdG46Zm9vLGR0bjpiYXLigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGhhZCBub3QgdGhv dWdodCBvZiB0aGF0IHNvcnQgb2YgZGV2aW91c25lc3MgYW5kIEkgdGhpbmsgaXQgaGVscHMgYm9s c3RlciBTY290dOKAmXMgY2FzZSB0byBnZXQgcmlkIG9mIHRoZSBkaWN0aW9uYXJ5IGluIHRoZSDi gJxSRkM1MDUwYmlz4oCdLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGF2aWQgWm9sbGVyPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNPTFNBIENvcnBv cmF0aW9uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1TRkMvSE9TQyAtIEMxMDcmbmJzcDsNCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiM5OTAwMDAiPig8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PZmZpY2U6PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPigyNTYpJm5ic3A7NTQ0LTE4MjA8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpuYXZ5Ij48YnI+DQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMzMzY2RkYi Pio8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RU1haWw6DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpuYXZ5Ij48YSBocmVmPSJtYWls dG86ZGF2aWQuYS56b2xsZXJAbmFzYS5nb3YiPmRhdmlkLmEuem9sbGVyQG5hc2EuZ292PC9hPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBbXkgQWxmb3JkIFttYWlsdG86YWxv b21pc0BzYXJuLm9yZ10NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bmUgMDIsIDIwMTQg Nzo1MyBQTTxicj4NCjxiPlRvOjwvYj4gWm9sbGVyLCBEYXZpZCBBLiAoTVNGQy1FTzUwKVtIT1ND IFNFUlZJQ0VTIENPTlRSQUNUXTxicj4NCjxiPkNjOjwvYj4gQnVybGVpZ2gsIFNjb3R0IEMgKEpQ TC0zMTJHKVtKZXQgUHJvcHVsc2lvbiBMYWJvcmF0b3J5XTsgQmlycmFuZSwgRWR3YXJkIEouOyBk dG4tc2VjdXJpdHlAaXJ0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtkdG4tc2VjdXJp dHldIFVwZGF0ZWQgU0JTUCBEb2N1bWVudCAtIENhbm9uaWNhbGl6YXRpb24gb2YgRXh0ZW5zaW9u IEJsb2NrczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gTW9uLCBKdW4gMiwgMjAxNCBhdCAyOjAxIFBNLCBab2xsZXIsIERhdmlkIEEuIChNU0ZD LUVPNTApW0hPU0MgU0VSVklDRVMgQ09OVFJBQ1RdICZsdDs8YSBocmVmPSJtYWlsdG86ZGF2aWQu YS56b2xsZXJAbmFzYS5nb3YiIHRhcmdldD0iX2JsYW5rIj5kYXZpZC5hLnpvbGxlckBuYXNhLmdv djwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMwMEIwNTAiPsK3PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzAwQjA1MCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMEIwNTAiPkkgZG9u4oCZdCBzZWUgYSBzaW1wbGlmaWNhdGlvbiBvZiB0aGUgZGljdGlv bmFyeSBpc3N1ZSBhcy1pcyBlaXRoZXI7IGFsdGhvdWdoLCB0aGUgc2VwYXJhdGluZyBzZW1pY29s b25zIGFyZSBub3QgcmVhbGx5IG5lZWRlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBkaXNjdXNzZWQgdGhpcyB3 aGVuIGJyYWluc3Rvcm1pbmcgdGhlIGRyYWZ0LCBhbmQgSSB3YXMgY29uY2VybmVkIHRoYXQgdGhl IHVyaSAmcXVvdDtkdG46Zm9vJnF1b3Q7IGFuZCB0aGUgdXJpICZxdW90O2R0bmY6b28mcXVvdDsg aGFzaCB0byB0aGUgc2FtZSB0aGluZyBpZiB5b3UgY2Fubm9uaWNhbGl6ZSB3aXRob3V0IHRoZSBj b2xvbi4gJm5ic3A7U2ltaWxhcmx5LCBpZiB0aGVyZSdzIG5vIGRlbGltaXRlciBiZXR3ZWVuIGRp Y3Rpb25hcnkgZW50cmllcywNCiB0aGVyZSdzIGFtYmlndWl0eS4gJm5ic3A7SSBkb24ndCBzZWUg YW55dGhpbmcgbmVmYXJpb3VzIHlvdSBjYW4gZG8gd2l0aCB0aGlzLCBidXQgaXQncyB1bmRlc2ly YWJsZSB0aGF0IHR3byBkaWZmZXJlbnQgYnVuZGxlcyBoYXZlIHRoZSBzYW1lIGhhc2gsIGV2ZW4g aWYgb25lIG9mIHRoZW0gaXMgbm9uc2Vuc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_94CFB3711B4CAE4DBFC5BEB3374BF0C60D9006NDMSMBX404ndcnasa_-- From nobody Tue Jun 3 06:09:19 2014 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907301A0268 for ; Tue, 3 Jun 2014 06:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3EQxP1DA1oF for ; Tue, 3 Jun 2014 06:08:53 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A83761A01F6 for ; Tue, 3 Jun 2014 06:08:53 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E51891F0751; Tue, 3 Jun 2014 09:08:47 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id CB4571F0372; Tue, 3 Jun 2014 09:08:47 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.73]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 09:08:47 -0400 From: "Scott, Keith L." To: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" , Amy Alford Thread-Topic: [dtn-security] Updated SBSP Document - Canonicalization of Extension Blocks Thread-Index: AQHPfsYy11Xpp8zu6kiwkU4hBh/bXptfmg4A///BktA= Date: Tue, 3 Jun 2014 13:08:47 +0000 Message-ID: <5EE81C5C4CFFF4418C5EAD12F49D64EE4C221E9E@IMCMBX01.MITRE.ORG> References: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E85@NDMSMBX404.ndc.nasa.gov> <94CFB3711B4CAE4DBFC5BEB3374BF0C60D9006@NDMSMBX404.ndc.nasa.gov> In-Reply-To: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D9006@NDMSMBX404.ndc.nasa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.140.19.249] Content-Type: multipart/alternative; boundary="_000_5EE81C5C4CFFF4418C5EAD12F49D64EE4C221E9EIMCMBX01MITREOR_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/ns0RhBg1cfzKE_OyrS_Fn-AO_xk Cc: "Burleigh, Scott C \(JPL-312G\)\[Jet Propulsion Laboratory\]" , "dtn-security@irtf.org" Subject: Re: [dtn-security] Updated SBSP Document - Canonicalization of Extension Blocks X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 13:08:58 -0000 --_000_5EE81C5C4CFFF4418C5EAD12F49D64EE4C221E9EIMCMBX01MITREOR_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBnZXR0aW5nIHJpZCBvZiB0aGUgZmxleGliaWxpdHkgb2Ygc3VwcG9ydGluZyBkaWZm ZXJlbnQgbmFtaW5nIHNjaGVtZXMgKGUuZy4gdGhlIGlwbiBhbmQgZHRuIHNjaGVtZXMsIGFtb25n IG90aGVycykgd291bGQgYmUgYSBiYWQgdGhpbmcuICBLZWVwaW5nIHRoYXQgZmxleGliaWxpdHkg d2hpbGUgZGl0Y2hpbmcgdGhlIGRpY3Rpb25hcnkgd291bGQgcHJvYmFibHkgaW52b2x2ZSBzb21l IGV4dHJhIG92ZXJoZWFkIGZvciBub24taXBuLXNjaGVtZSBuYW1lcywgYnV0IHRoYXQgbWlnaHQg YmUgYWNjZXB0YWJsZSBnaXZlbiB0aGUgc2VjdXJpdHkgYW5kIGNvbXBsZXhpdHkgaXNzdWVzLg0K DQogICAgICAgICAgICAgICAgICAgICAgICAtLWtlaXRoDQoNCkZyb206IGR0bi1zZWN1cml0eSBb bWFpbHRvOmR0bi1zZWN1cml0eS1ib3VuY2VzQGlydGYub3JnXSBPbiBCZWhhbGYgT2YgWm9sbGVy LCBEYXZpZCBBLiAoTVNGQy1FTzUwKVtIT1NDIFNFUlZJQ0VTIENPTlRSQUNUXQ0KU2VudDogVHVl c2RheSwgSnVuZSAwMywgMjAxNCA4OjUwIEFNDQpUbzogQW15IEFsZm9yZA0KQ2M6IEJ1cmxlaWdo LCBTY290dCBDIChKUEwtMzEyRylbSmV0IFByb3B1bHNpb24gTGFib3JhdG9yeV07IGR0bi1zZWN1 cml0eUBpcnRmLm9yZw0KU3ViamVjdDogUmU6IFtkdG4tc2VjdXJpdHldIFVwZGF0ZWQgU0JTUCBE b2N1bWVudCAtIENhbm9uaWNhbGl6YXRpb24gb2YgRXh0ZW5zaW9uIEJsb2Nrcw0KDQpTb3JyeSwg SSBzaG91bGQgaGF2ZSBkb3VibGUgY2hlY2tlZCB0aGUgc3BlYyBpbnN0ZWFkIG9mIHJlbHlpbmcg b24gbWVtb3J5LiBJIHdhcyByZWZlcnJpbmcgdG8gdGhlIGRlbGltaXRlciBiZXR3ZWVuIHRoZSBl bnRyaWVzIHdoaWNoIGlzIGEgY29tbWEgcmF0aGVyIHRoYW4gYSBzZW1pY29sb24gYnV0IHlvdSBj b3ZlcmVkIGJvdGggcG9zc2liaWxpdGllcy4gQmFzaWNhbGx5LCB0aGUgZGljdGlvbmFyeSBhbmQg dGhlIGJsb2NrIEVJRCByZWZlcmVuY2VzIGNhbiBiZSBtYW5pcHVsYXRlZCB0byBpbmNsdWRlIGFu ZCBwb2ludCB0byBhIGJvZ3VzIFVSSSB0aGF0IGNhbm9uaWNhbGl6ZXMgdG8gdGhlIHNhbWUgc3Ry aW5nIGFzIHRoZSBvcmlnaW5hbCBibG9jayBFSURzIHNvIHRoYXQgaXQgd291bGQgcGFzcyB0aGUg aW50ZWdyaXR5IGNoZWNrIGJ1dCBjYXVzZSBpc3N1ZXMgdHJ5aW5nIHRvIHVzZSB0aGUgYm9ndXMg VVJJLiBFdmVuIHVzaW5nIGEgc2VwYXJhdG9yIGRlbGltaXRlciwgaXQgaXMgcG9zc2libGUgdG8g cmVwbGFjZSB0d28gb3IgbW9yZSBVUklzIHdpdGggYSBzaW5nbGUgYm9ndXMgVVJJIGJ5IGluY2x1 ZGluZyB0aGUgc2VwYXJhdG9yIGRlbGltaXRlcihzKSBhbmQgaXQgd291bGQgYmUgYSB2YWxpZCBV UkkgdG8gYm9vdCAtLSByZXBsYWNlIHRoZSB0d28gRUlEcyDigJxkdG46Zm9v4oCdLOKAnWR0bjpi YXLigJ0gd2l0aCB0aGUgc2luZ2xlIEVJRCDigJxkdG46Zm9vLGR0bjpiYXLigJ0uDQoNCkkgaGFk IG5vdCB0aG91Z2h0IG9mIHRoYXQgc29ydCBvZiBkZXZpb3VzbmVzcyBhbmQgSSB0aGluayBpdCBo ZWxwcyBib2xzdGVyIFNjb3R04oCZcyBjYXNlIHRvIGdldCByaWQgb2YgdGhlIGRpY3Rpb25hcnkg aW4gdGhlIOKAnFJGQzUwNTBiaXPigJ0uDQoNCkRhdmlkIFpvbGxlcg0KQ09MU0EgQ29ycG9yYXRp b24NCk1TRkMvSE9TQyAtIEMxMDcNCuKAok9mZmljZTogKDI1NikgNTQ0LTE4MjANCuKAokVNYWls OiBkYXZpZC5hLnpvbGxlckBuYXNhLmdvdjxtYWlsdG86ZGF2aWQuYS56b2xsZXJAbmFzYS5nb3Y+ DQoNCkZyb206IEFteSBBbGZvcmQgW21haWx0bzphbG9vbWlzQHNhcm4ub3JnXQ0KU2VudDogTW9u ZGF5LCBKdW5lIDAyLCAyMDE0IDc6NTMgUE0NClRvOiBab2xsZXIsIERhdmlkIEEuIChNU0ZDLUVP NTApW0hPU0MgU0VSVklDRVMgQ09OVFJBQ1RdDQpDYzogQnVybGVpZ2gsIFNjb3R0IEMgKEpQTC0z MTJHKVtKZXQgUHJvcHVsc2lvbiBMYWJvcmF0b3J5XTsgQmlycmFuZSwgRWR3YXJkIEouOyBkdG4t c2VjdXJpdHlAaXJ0Zi5vcmc8bWFpbHRvOmR0bi1zZWN1cml0eUBpcnRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbZHRuLXNlY3VyaXR5XSBVcGRhdGVkIFNCU1AgRG9jdW1lbnQgLSBDYW5vbmljYWxpemF0 aW9uIG9mIEV4dGVuc2lvbiBCbG9ja3MNCg0KT24gTW9uLCBKdW4gMiwgMjAxNCBhdCAyOjAxIFBN LCBab2xsZXIsIERhdmlkIEEuIChNU0ZDLUVPNTApW0hPU0MgU0VSVklDRVMgQ09OVFJBQ1RdIDxk YXZpZC5hLnpvbGxlckBuYXNhLmdvdjxtYWlsdG86ZGF2aWQuYS56b2xsZXJAbmFzYS5nb3Y+PiB3 cm90ZToNCg0KDQrigKIgICAgICAgICBJIGRvbuKAmXQgc2VlIGEgc2ltcGxpZmljYXRpb24gb2Yg dGhlIGRpY3Rpb25hcnkgaXNzdWUgYXMtaXMgZWl0aGVyOyBhbHRob3VnaCwgdGhlIHNlcGFyYXRp bmcgc2VtaWNvbG9ucyBhcmUgbm90IHJlYWxseSBuZWVkZWQuDQpXZSBkaXNjdXNzZWQgdGhpcyB3 aGVuIGJyYWluc3Rvcm1pbmcgdGhlIGRyYWZ0LCBhbmQgSSB3YXMgY29uY2VybmVkIHRoYXQgdGhl IHVyaSAiZHRuOmZvbyIgYW5kIHRoZSB1cmkgImR0bmY6b28iIGhhc2ggdG8gdGhlIHNhbWUgdGhp bmcgaWYgeW91IGNhbm5vbmljYWxpemUgd2l0aG91dCB0aGUgY29sb24uICBTaW1pbGFybHksIGlm IHRoZXJlJ3Mgbm8gZGVsaW1pdGVyIGJldHdlZW4gZGljdGlvbmFyeSBlbnRyaWVzLCB0aGVyZSdz IGFtYmlndWl0eS4gIEkgZG9uJ3Qgc2VlIGFueXRoaW5nIG5lZmFyaW91cyB5b3UgY2FuIGRvIHdp dGggdGhpcywgYnV0IGl0J3MgdW5kZXNpcmFibGUgdGhhdCB0d28gZGlmZmVyZW50IGJ1bmRsZXMg aGF2ZSB0aGUgc2FtZSBoYXNoLCBldmVuIGlmIG9uZSBvZiB0aGVtIGlzIG5vbnNlbnNlLg0KDQo= --_000_5EE81C5C4CFFF4418C5EAD12F49D64EE4C221E9EIMCMBX01MITREOR_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiM0 NDU0NkE7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQt ZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojNDQ1NDZBIj5JIHRoaW5rIGdldHRpbmcgcmlkIG9mIHRoZSBmbGV4aWJpbGl0 eSBvZiBzdXBwb3J0aW5nIGRpZmZlcmVudCBuYW1pbmcgc2NoZW1lcyAoZS5nLiB0aGUgaXBuIGFu ZCBkdG4gc2NoZW1lcywgYW1vbmcgb3RoZXJzKSB3b3VsZCBiZSBhIGJhZCB0aGluZy4mbmJzcDsg S2VlcGluZyB0aGF0DQogZmxleGliaWxpdHkgd2hpbGUgZGl0Y2hpbmcgdGhlIGRpY3Rpb25hcnkg d291bGQgcHJvYmFibHkgaW52b2x2ZSBzb21lIGV4dHJhIG92ZXJoZWFkIGZvciBub24taXBuLXNj aGVtZSBuYW1lcywgYnV0IHRoYXQgbWlnaHQgYmUgYWNjZXB0YWJsZSBnaXZlbiB0aGUgc2VjdXJp dHkgYW5kIGNvbXBsZXhpdHkgaXNzdWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDQ1NDZBIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC0ta2VpdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBkdG4tc2VjdXJpdHkgW21haWx0bzpkdG4tc2VjdXJpdHktYm91bmNlc0BpcnRmLm9yZ10NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+Wm9sbGVyLCBEYXZpZCBBLiAoTVNGQy1FTzUwKVtIT1NDIFNFUlZJ Q0VTIENPTlRSQUNUXTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDAzLCAyMDE0IDg6 NTAgQU08YnI+DQo8Yj5Ubzo8L2I+IEFteSBBbGZvcmQ8YnI+DQo8Yj5DYzo8L2I+IEJ1cmxlaWdo LCBTY290dCBDIChKUEwtMzEyRylbSmV0IFByb3B1bHNpb24gTGFib3JhdG9yeV07IGR0bi1zZWN1 cml0eUBpcnRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2R0bi1zZWN1cml0eV0gVXBk YXRlZCBTQlNQIERvY3VtZW50IC0gQ2Fub25pY2FsaXphdGlvbiBvZiBFeHRlbnNpb24gQmxvY2tz PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U29ycnksIEkgc2hvdWxkIGhhdmUgZG91YmxlIGNo ZWNrZWQgdGhlIHNwZWMgaW5zdGVhZCBvZiByZWx5aW5nIG9uIG1lbW9yeS4gSSB3YXMgcmVmZXJy aW5nIHRvIHRoZSBkZWxpbWl0ZXIgYmV0d2VlbiB0aGUgZW50cmllcyB3aGljaA0KIGlzIGEgY29t bWEgcmF0aGVyIHRoYW4gYSBzZW1pY29sb24gYnV0IHlvdSBjb3ZlcmVkIGJvdGggcG9zc2liaWxp dGllcy4gQmFzaWNhbGx5LCB0aGUgZGljdGlvbmFyeSBhbmQgdGhlIGJsb2NrIEVJRCByZWZlcmVu Y2VzIGNhbiBiZSBtYW5pcHVsYXRlZCB0byBpbmNsdWRlIGFuZCBwb2ludCB0byBhIGJvZ3VzIFVS SSB0aGF0IGNhbm9uaWNhbGl6ZXMgdG8gdGhlIHNhbWUgc3RyaW5nIGFzIHRoZSBvcmlnaW5hbCBi bG9jayBFSURzIHNvIHRoYXQgaXQNCiB3b3VsZCBwYXNzIHRoZSBpbnRlZ3JpdHkgY2hlY2sgYnV0 IGNhdXNlIGlzc3VlcyB0cnlpbmcgdG8gdXNlIHRoZSBib2d1cyBVUkkuIEV2ZW4gdXNpbmcgYSBz ZXBhcmF0b3IgZGVsaW1pdGVyLCBpdCBpcyBwb3NzaWJsZSB0byByZXBsYWNlIHR3byBvciBtb3Jl IFVSSXMgd2l0aCBhIHNpbmdsZSBib2d1cyBVUkkgYnkgaW5jbHVkaW5nIHRoZSBzZXBhcmF0b3Ig ZGVsaW1pdGVyKHMpIGFuZCBpdCB3b3VsZCBiZSBhIHZhbGlkIFVSSSB0byBib290IC0tDQogcmVw bGFjZSB0aGUgdHdvIEVJRHMg4oCcZHRuOmZvb+KAnSzigJ1kdG46YmFy4oCdIHdpdGggdGhlIHNp bmdsZSBFSUQg4oCcZHRuOmZvbyxkdG46YmFy4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGhhZCBub3QgdGhvdWdodCBvZiB0 aGF0IHNvcnQgb2YgZGV2aW91c25lc3MgYW5kIEkgdGhpbmsgaXQgaGVscHMgYm9sc3RlciBTY290 dOKAmXMgY2FzZSB0byBnZXQgcmlkIG9mIHRoZSBkaWN0aW9uYXJ5IGluIHRoZSDigJxSRkM1MDUw Ymlz4oCdLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5EYXZpZCBab2xsZXI8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNP TFNBIENvcnBvcmF0aW9uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5NU0ZDL0hPU0MgLSBDMTA3Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6Izk5MDAwMCI+KDwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9mZmljZTo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KDI1NikmbmJzcDs1NDQtMTgyMDwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPjxicj4NCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzMzNjZG RiI+Kjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5FTWFpbDoN Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPjxhIGhyZWY9Im1h aWx0bzpkYXZpZC5hLnpvbGxlckBuYXNhLmdvdiI+ZGF2aWQuYS56b2xsZXJAbmFzYS5nb3Y8L2E+ PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQW15IEFsZm9yZCBbPGEgaHJlZj0ibWFpbHRv OmFsb29taXNAc2Fybi5vcmciPm1haWx0bzphbG9vbWlzQHNhcm4ub3JnPC9hPl0NCjxicj4NCjxi PlNlbnQ6PC9iPiBNb25kYXksIEp1bmUgMDIsIDIwMTQgNzo1MyBQTTxicj4NCjxiPlRvOjwvYj4g Wm9sbGVyLCBEYXZpZCBBLiAoTVNGQy1FTzUwKVtIT1NDIFNFUlZJQ0VTIENPTlRSQUNUXTxicj4N CjxiPkNjOjwvYj4gQnVybGVpZ2gsIFNjb3R0IEMgKEpQTC0zMTJHKVtKZXQgUHJvcHVsc2lvbiBM YWJvcmF0b3J5XTsgQmlycmFuZSwgRWR3YXJkIEouOw0KPGEgaHJlZj0ibWFpbHRvOmR0bi1zZWN1 cml0eUBpcnRmLm9yZyI+ZHRuLXNlY3VyaXR5QGlydGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW2R0bi1zZWN1cml0eV0gVXBkYXRlZCBTQlNQIERvY3VtZW50IC0gQ2Fub25pY2Fs aXphdGlvbiBvZiBFeHRlbnNpb24gQmxvY2tzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPk9uIE1vbiwgSnVuIDIsIDIwMTQgYXQgMjowMSBQTSwgWm9sbGVyLCBE YXZpZCBBLiAoTVNGQy1FTzUwKVtIT1NDIFNFUlZJQ0VTIENPTlRSQUNUXSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmRhdmlkLmEuem9sbGVyQG5hc2EuZ292IiB0YXJnZXQ9Il9ibGFuayI+ZGF2aWQuYS56 b2xsZXJAbmFzYS5nb3Y8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMwMEIwNTAiPsK3PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzAwQjA1MCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMEIwNTAiPkkgZG9u4oCZdCBzZWUgYSBzaW1wbGlmaWNhdGlvbiBvZiB0aGUgZGljdGlv bmFyeSBpc3N1ZSBhcy1pcyBlaXRoZXI7IGFsdGhvdWdoLCB0aGUgc2VwYXJhdGluZyBzZW1pY29s b25zIGFyZSBub3QgcmVhbGx5IG5lZWRlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+V2UgZGlzY3Vzc2VkIHRoaXMgd2hlbiBicmFpbnN0b3JtaW5nIHRoZSBkcmFmdCwgYW5k IEkgd2FzIGNvbmNlcm5lZCB0aGF0IHRoZSB1cmkgJnF1b3Q7ZHRuOmZvbyZxdW90OyBhbmQgdGhl IHVyaSAmcXVvdDtkdG5mOm9vJnF1b3Q7IGhhc2ggdG8gdGhlIHNhbWUgdGhpbmcgaWYgeW91IGNh bm5vbmljYWxpemUgd2l0aG91dCB0aGUgY29sb24uICZuYnNwO1NpbWlsYXJseSwgaWYgdGhlcmUn cyBubyBkZWxpbWl0ZXINCiBiZXR3ZWVuIGRpY3Rpb25hcnkgZW50cmllcywgdGhlcmUncyBhbWJp Z3VpdHkuICZuYnNwO0kgZG9uJ3Qgc2VlIGFueXRoaW5nIG5lZmFyaW91cyB5b3UgY2FuIGRvIHdp dGggdGhpcywgYnV0IGl0J3MgdW5kZXNpcmFibGUgdGhhdCB0d28gZGlmZmVyZW50IGJ1bmRsZXMg aGF2ZSB0aGUgc2FtZSBoYXNoLCBldmVuIGlmIG9uZSBvZiB0aGVtIGlzIG5vbnNlbnNlLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5EE81C5C4CFFF4418C5EAD12F49D64EE4C221E9EIMCMBX01MITREOR_-- From nobody Tue Jun 3 07:13:55 2014 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4C41A019C for ; Tue, 3 Jun 2014 07:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qj8ejCrSy9e for ; Tue, 3 Jun 2014 07:13:52 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DA591A0170 for ; Tue, 3 Jun 2014 07:13:52 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s53EDjsg014212 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Tue, 3 Jun 2014 07:13:45 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.156]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.182]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 07:13:45 -0700 From: "Burleigh, Scott C (312G)" To: "Scott, Keith L." , "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" , Amy Alford Thread-Topic: [dtn-security] Updated SBSP Document - Canonicalization of Extension Blocks Thread-Index: Ac9+iuEjMG+dNHBvSEOuNdHOvLFJHgAdflgAABkGAwAAAKuDgP//nH1D Date: Tue, 3 Jun 2014 14:13:44 +0000 Message-ID: References: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E85@NDMSMBX404.ndc.nasa.gov> <94CFB3711B4CAE4DBFC5BEB3374BF0C60D9006@NDMSMBX404.ndc.nasa.gov>, <5EE81C5C4CFFF4418C5EAD12F49D64EE4C221E9E@IMCMBX01.MITRE.ORG> In-Reply-To: <5EE81C5C4CFFF4418C5EAD12F49D64EE4C221E9E@IMCMBX01.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.114] Content-Type: multipart/alternative; boundary="_000_A5BEAD028815CB40A32A5669CF737C3B423B5CA3apembxsp40RESAD_" MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/zzBxJfJbZkG2gakFhV6VfmvbihU Cc: "dtn-security@irtf.org" Subject: Re: [dtn-security] Updated SBSP Document - Canonicalization of Extension Blocks X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 14:13:54 -0000 --_000_A5BEAD028815CB40A32A5669CF737C3B423B5CA3apembxsp40RESAD_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think that is exactly the right approach. Scott ________________________________ From: Scott, Keith L. [kscott@mitre.org] Sent: Tuesday, June 03, 2014 6:08 AM To: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]; Amy Alford Cc: Burleigh, Scott C (312G); dtn-security@irtf.org Subject: RE: [dtn-security] Updated SBSP Document - Canonicalization of Ext= ension Blocks I think getting rid of the flexibility of supporting different naming schem= es (e.g. the ipn and dtn schemes, among others) would be a bad thing. Keep= ing that flexibility while ditching the dictionary would probably involve s= ome extra overhead for non-ipn-scheme names, but that might be acceptable g= iven the security and complexity issues. --keith From: dtn-security [mailto:dtn-security-bounces@irtf.org] On Behalf Of Zoll= er, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] Sent: Tuesday, June 03, 2014 8:50 AM To: Amy Alford Cc: Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]; dtn-security@i= rtf.org Subject: Re: [dtn-security] Updated SBSP Document - Canonicalization of Ext= ension Blocks Sorry, I should have double checked the spec instead of relying on memory. = I was referring to the delimiter between the entries which is a comma rathe= r than a semicolon but you covered both possibilities. Basically, the dicti= onary and the block EID references can be manipulated to include and point = to a bogus URI that canonicalizes to the same string as the original block = EIDs so that it would pass the integrity check but cause issues trying to u= se the bogus URI. Even using a separator delimiter, it is possible to repla= ce two or more URIs with a single bogus URI by including the separator deli= miter(s) and it would be a valid URI to boot -- replace the two EIDs =93dtn= :foo=94,=94dtn:bar=94 with the single EID =93dtn:foo,dtn:bar=94. I had not thought of that sort of deviousness and I think it helps bolster = Scott=92s case to get rid of the dictionary in the =93RFC5050bis=94. David Zoller COLSA Corporation MSFC/HOSC - C107 =95Office: (256) 544-1820 =95EMail: david.a.zoller@nasa.gov From: Amy Alford [mailto:aloomis@sarn.org] Sent: Monday, June 02, 2014 7:53 PM To: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] Cc: Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]; Birrane, Edwar= d J.; dtn-security@irtf.org Subject: Re: [dtn-security] Updated SBSP Document - Canonicalization of Ext= ension Blocks On Mon, Jun 2, 2014 at 2:01 PM, Zoller, David A. (MSFC-EO50)[HOSC SERVICES = CONTRACT] > wrote: =95 I don=92t see a simplification of the dictionary issue as-is ei= ther; although, the separating semicolons are not really needed. We discussed this when brainstorming the draft, and I was concerned that th= e uri "dtn:foo" and the uri "dtnf:oo" hash to the same thing if you cannoni= calize without the colon. Similarly, if there's no delimiter between dicti= onary entries, there's ambiguity. I don't see anything nefarious you can d= o with this, but it's undesirable that two different bundles have the same = hash, even if one of them is nonsense. --_000_A5BEAD028815CB40A32A5669CF737C3B423B5CA3apembxsp40RESAD_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I think that is exactly the right approach.

Scott
From: Scott, Keith L. [kscott@mitre.org]<= br> Sent: Tuesday, June 03, 2014 6:08 AM
To: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]; Amy Alford=
Cc: Burleigh, Scott C (312G); dtn-security@irtf.org
Subject: RE: [dtn-security] Updated SBSP Document - Canonicalization= of Extension Blocks

I think gett= ing rid of the flexibility of supporting different naming schemes (e.g. the= ipn and dtn schemes, among others) would be a bad thing.  Keeping that flexibility while ditching the dictionary would probably invo= lve some extra overhead for non-ipn-scheme names, but that might be accepta= ble given the security and complexity issues.

 

  =             &nb= sp;         --keith

 

From= : dtn-security [mailto:dtn-security-bounces@irtf.= org] On Behalf Of Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] Sent: Tuesday, June 03, 2014 8:50 AM
To: Amy Alford
Cc: Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]; dtn-sec= urity@irtf.org
Subject: Re: [dtn-security] Updated SBSP Document - Canonicalization= of Extension Blocks

 

Sorry, I should have double checked the spec instead of r= elying on memory. I was referring to the delimiter between the entries which is a comma rather than a semicolon but you covered both = possibilities. Basically, the dictionary and the block EID references can b= e manipulated to include and point to a bogus URI that canonicalizes to the= same string as the original block EIDs so that it would pass the integrity check but cause issues trying to = use the bogus URI. Even using a separator delimiter, it is possible to repl= ace two or more URIs with a single bogus URI by including the separator del= imiter(s) and it would be a valid URI to boot -- replace the two EIDs =93dtn:foo=94,=94dtn:bar=94 with the s= ingle EID =93dtn:foo,dtn:bar=94.

 

I had not thought of that sort of deviousness and I think= it helps bolster Scott=92s case to get rid of the dictionary in the =93RFC5050bis=94.

 

David Zoller

COLSA Corporation

MSFC/HOSC - C107 

(Office: (256) 544-1820
*EMail: david.a.zoller@nasa.gov

 

From:= Amy Alford [mailto:aloomis@sarn.org]
Sent: Monday, June 02, 2014 7:53 PM
To: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]
Cc: Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]; Birrane= , Edward J.; dtn-security@irt= f.org
Subject: Re: [dtn-security] Updated SBSP Document - Canonicalization= of Extension Blocks

 

On Mon, Jun 2, 2014 at= 2:01 PM, Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] <david.a.zoller@nasa.g= ov> wrote:

 

=B7         I don=92t see a simplificati= on of the dictionary issue as-is either; although, the separating semicolon= s are not really needed.

We discussed this when= brainstorming the draft, and I was concerned that the uri "dtn:foo&qu= ot; and the uri "dtnf:oo" hash to the same thing if you cannonica= lize without the colon.  Similarly, if there's no delimiter between dictionary entries, there's ambiguity.  I don't see anything = nefarious you can do with this, but it's undesirable that two different bun= dles have the same hash, even if one of them is nonsense.

 

--_000_A5BEAD028815CB40A32A5669CF737C3B423B5CA3apembxsp40RESAD_-- From nobody Tue Jun 3 12:24:08 2014 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B691A0344 for ; Tue, 3 Jun 2014 12:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVCsa7WIkzkN for ; Tue, 3 Jun 2014 12:23:55 -0700 (PDT) Received: from pilot.jhuapl.edu (pilot.jhuapl.edu [128.244.251.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 901461A0349 for ; Tue, 3 Jun 2014 12:23:54 -0700 (PDT) Received: from aplexcas2.dom1.jhuapl.edu (aplexcas2.dom1.jhuapl.edu [128.244.198.91]) by pilot.jhuapl.edu with smtp (TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 0802_dafa_10dfec1c_b011_4085_9c40_b9934d82d0fa; Tue, 03 Jun 2014 15:23:47 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Tue, 3 Jun 2014 15:23:46 -0400 From: "Birrane, Edward J." To: "dtn-security@irtf.org" Date: Tue, 3 Jun 2014 15:23:45 -0400 Thread-Topic: Updated SBSP Document - BAB Thread-Index: Ac9+bH1OvS/DGr4rQCGazJjgMCXvZgA7MfsQ Message-ID: <329D879C76FDD04AAAE84BB1D89B3970094FBFAAC8@aplesfreedom.dom1.jhuapl.edu> References: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E29@NDMSMBX404.ndc.nasa.gov> In-Reply-To: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E29@NDMSMBX404.ndc.nasa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_329D879C76FDD04AAAE84BB1D89B3970094FBFAAC8aplesfreedomd_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/XSGcZsa2qi_xNCOLqNu_3m3_P6E Subject: Re: [dtn-security] Updated SBSP Document - BAB X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 19:24:04 -0000 --_000_329D879C76FDD04AAAE84BB1D89B3970094FBFAAC8aplesfreedomd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dave, Thank you for fragmenting the discussion into separate threads; it is muc= h easier to parse this way. I recommend the following: - It is the intention that when adding a BAB, the next BP hop for the bundl= e is a security-aware node, but this cannot be guaranteed (e.g., there may = be a misconfiguration in the network). The language in the spec should be u= pdated to reflect this. We should do one (not both) of the following: A: When adding a BAB to a bundle, ensure that the bundle's "Bundle must not= be fragmented" field is set. This will result in a delivery failure if the= next BP-hop is unable to deliver the bundle as-is, but also ensures there = is no payload surgery between BP-hops that require BAB authentication. B: Use the content range for the ciphersuite parameters to identify the off= set,length of the bundle being protected. Then, require BPAs to wait until = all fragments of a bundle are received, and then do the authentication chec= k. My preference is to do "A". It is simple and strict when requiring authenti= cation, as should be the case with authentication. My concern regarding approach "B" is that we have to use up memory and othe= r resources for partial bundles. Part of the job of authentication is to pr= event some types of resource attacks on the network, and "B" seems to re-en= able some of those attacks. -Ed --- Ed Birrane Principal Professional Staff, Space Department Johns Hopkins Applied Physics Laboratory (W) 443-778-7423 / (F) 443-228-3839 From: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] [mailto:david.a.= zoller@nasa.gov] Sent: Monday, June 02, 2014 1:07 PM To: Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]; Birrane, Edwar= d J.; dtn-security@irtf.org Subject: RE: Updated SBSP Document - BAB [Page 12] 2.4 Bundle Authentication Block The security-target MUST be the entire bundle, which MUST be represented by a of <0x00><0x00>. =B7 Per 3.4 Bundle Fragmentation and Reassembly, bundle authenticat= ion may be applied to bundle fragments as well as non-fragmented bundles. =B7 If a bundle fragment is received that has a BAB, there is no wa= y to determine if the BAB applies to the bundle fragment or if it applies t= o an entire bundle that was later fragmented by a non-security-aware BA. o I propose that a of <0x00> indicate that the BAB applies to a bundle fragment =B7 If such a bundle fragment is further fragmented by a non-securi= ty-aware BA then the can be used to determine that th= e original fragmented bundle must be reassembled before authentication is c= hecked because it will not match the length field in the payload block. o Some discussion may be desirable in section 3.4 as well as 2.4 if acce= pted =D8 When a BAB is attached to a bundle that is a fragment, the bundle that= it applies to is always that fragment, never the bundle that carried the o= riginal payload (of which the current bundle's payload is a fragment). Sin= ce BABs are not end-to-end, the BAB for an original un-fragmented bundle wi= ll never be carried forward in any fragments generated from that bundle (se= e the last paragraph of 3.3.1), so there's no ambiguity. But this does bri= ng up an important point: the block processing control flags of the BAB mus= t always have the "replicate in every fragment" flag set to 0. Maybe I'm misunderstanding here, but fragmentation can happen between a BAB= source and a BAB dest if a non-security aware node is between the two. Re= quiring the "DO_NOT_FRAGMENT" flag solves this. >> I see what you're saying, and I think it goes to the lament in= your next comment: the interaction between fragmentation and BSP really is= a mess. But I thought SBSP simplified things somewhat by not allowing any= non-security-aware nodes between the BAB source and BAB destination. At l= east, that's what I hoped we were doing, and it's how I interpret "BABs ope= rate between topologically adjacent nodes" on page 6. If that's not the ca= se then I think there are additional problems to resolve. BABs should be applied 'point-to-point' between bundle agents; there should= n't be an opportunity for a non-security-aware node to fragment a bundle wi= th a BAB on it. I'll have to check the cross-product between encapsulation= and BAB (i.e. whether you can encapsulate a bundle with a BAB on it (and t= hen possibly fragment the encapsulating bundle) or not). I suspect that th= e answer is 'no' (i.e. you check / remove the BAB immediately on receipt an= d before you encapsulate and/or fragment for transmission). =D8 There isn't really any accepted spec to consult on encapsulation, but w= ithin the concept that I've been working with (https://datatracker.ietf.org= /doc/draft-irtf-burleigh-bibe/) the encapsulation protocol is a convergence= -layer adapter. In that case, the entire, complete outbound bundle - inclu= ding any BAB that was attached at the last moment before serialization for = the CLA - would become the payload of the new encapsulating bundle. The en= capsulating bundle might or might not be security-aware, but that doesn't m= atter. The destination of the encapsulating bundle would extract the encap= sulated bundle (the "outer" bundle's payload) and simulate reception of tha= t bundle, which would still have its BAB. That bundle would, in effect, ha= ve traversed only a single hop (direct transmission between sender and rece= iver at the convergence layer), so there was no intervening non-security-aw= are forwarding node between the sending node that attached the BAB and the = receiving node that would validate it. So no opportunity for fragmentation= , no problem. Having outgoing email issues so some of this is now late and could be later= by the time it gets through - if it gets there. o This is true when all traversed nodes are SBSP compliant and we probabl= y do not want to overly complicate SBSP trying to anticipate and handle all= possible off-nominal scenarios. One of the off-nominal scenarios that I wo= uld not be surprised to see with the Space Station is the case where our ga= teway nodes are running pre-SBSP software and a payload developer installs = a cutting edge SBSP implementation. In this scenario, if the payload node a= pplies a BAB to a large bundle [or fragment] then there is the possibility = that the pre-SBSP gateway node will fragment [or further fragment] the bund= le and not remove the BAB resulting in its misinterpretation when it makes = to the end node that is SBSP compliant. o I am okay with not specifically handling this scenario as we can recomm= end not using the BAB until the gateway nodes are updated to SBSP complianc= e or that their local policy set the 'Discard block if it can't be processe= d' flag on the BAB. =A7 Amy mentioned the DO_NOT_FRAGMENT" flag as another possible option bef= ore I could send this reply due to system and email issues (and maybe I am = a slow typist)... =B7 What happens if there is a conflict between DO_NOT_FRAGMENT and= "must fragment if bigger than x"? Is the bundle sent whole, trapped, or de= leted? =A7 And now - the suggested BIBE is another good approach o If this particular scenario might impact other folks as well and the co= nsensus is to handle it then a refinement would be to use the = to hold the fragment offset so that a further fragmented fragment could be = more reliably reconstituted and BAB verified. I "think" this would make the= BAB "SBSP_hop - to - SBSP_hop" regardless of the compliance of any interve= ning nodes. --_000_329D879C76FDD04AAAE84BB1D89B3970094FBFAAC8aplesfreedomd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dave,

 

=A0 Thank you for fragmenting the discussion into se= parate threads; it is much easier to parse this way.=A0 <= /p>

 

I recommend the f= ollowing:

 

- It is the intention that when adding a BAB, the next BP hop fo= r the bundle is a security-aware node, but this cannot be guaranteed (e.g.,= there may be a misconfiguration in the network). The language in the spec = should be updated to reflect this.

 

We should do one (not both) of the foll= owing:

 

A: When adding a BAB to a bundle, ensure that the bundle’s &#= 8220;Bundle must not be fragmented” field is set. This will result in= a delivery failure if the next BP-hop is unable to deliver the bundle as-i= s, but also ensures there is no payload surgery between BP-hops that requir= e BAB authentication.

 

B: Use the content range for the ciphersuite paramet= ers to identify the offset,length of the bundle being protected. Then, requ= ire BPAs to wait until all fragments of a bundle are received, and then do = the authentication check.

 

My preference is to do “A”. It is s= imple and strict when requiring authentication, as should be the case with = authentication.

 

My concern regarding approach “B” is that we= have to use up memory and other resources for partial bundles. Part of the= job of authentication is to prevent some types of resource attacks on the = network, and “B” seems to re-enable some of those attacks.=

&n= bsp;

-Ed=

 

---
Ed Birrane

Principal Professio= nal Staff, Space Department
Johns Hopkins Applied Physics Laboratory
= (W) 443-778-7423 / (F) 443-228-3839
 

 

From: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] [mailto:dav= id.a.zoller@nasa.gov]
Sent: Monday, June 02, 2014 1:07 PM
= To: Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]; Birrane, E= dward J.; dtn-security@irtf.org
Subject: RE: Updated SBSP Documen= t - BAB

 

<DZ>

[Page 12] 2.4 Bundle Authentication Block

The security-targ= et MUST be the entire bundle, which MUST be

represented by a <= ;block type><occurrence number> of <0x00><0x00>.<= /o:p>

=B7&n= bsp;        Per 3.4 Bundle Fragmentation and Reassembl= y, bundle authentication may be applied to bundle fragments as well as non-= fragmented bundles.

=B7      = ;   = If a bundle fragment is received that has a BAB, there is no way to determi= ne if the BAB applies to the bundle fragment or if it applies to an entire = bundle that was later fragmented by a non-security-aware BA.o    I propose that a <block type><occurrence number>= of <0x00><payload frag length> indicate that the BAB applies t= o a bundle fragment

=B7      = ;   = If such a bundle fragment is further fragmented by a non-security-aware BA = then the <payload frag length> can be used to determine that the orig= inal fragmented bundle must be reassembled before authentication is checked= because it will not match the length field in the payload block.

o    Some discussion may be desirable in section 3.4 as well= as 2.4 if accepted

<SB= >

=D8  When a BAB is attac= hed to a bundle that is a fragment, the bundle that it applies to is always= that fragment, never the bundle that carried the original payload (of whic= h the current bundle’s payload is a fragment).  Since BABs are n= ot end-to-end, the BAB for an original un-fragmented bundle will never be c= arried forward in any fragments generated from that bundle (see the last pa= ragraph of 3.3.1), so there’s no ambiguity.  But this does bring= up an important point: the block processing control flags of the BAB must = always have the “replicate in every fragment” flag set to 0.

=  

<AA>

Maybe I'm misunderstanding here, but fragmentation ca= n happen between a BAB source and a BAB dest if a non-security aware node i= s between the two.  Requiring the "DO_NOT_FRAGMENT" flag sol= ves this.  

 

<SB>

>>       = ;    I see what you’re saying, and I think it goes to = the lament in your next comment: the interaction between fragmentation and = BSP really is a mess.  But I thought SBSP simplified things somewhat b= y not allowing any non-security-aware nodes between the BAB source and BAB = destination.  At least, that’s what I hoped we were doing, and i= t’s how I interpret “BABs operate between topologically adjacent nodes<= span style=3D'color:#1F497D'>” on page 6.  If that’s not t= he case then I think there are additional problems to resolve.

 

<KS&g= t;

BABs should be applied ‘point-to-point’ be= tween bundle agents; there shouldn’t be an opportunity for a non-secu= rity-aware node to fragment a bundle with a BAB on it.  I’ll hav= e to check the cross-product between encapsulation and BAB (i.e. whether yo= u can encapsulate a bundle with a BAB on it (and then possibly fragment the= encapsulating bundle) or not).  I suspect that the answer is ‘n= o’ (i.e. you check / remove the BAB immediately on receipt and before= you encapsulate and/or fragment for transmission).

 

<SB>

=D8 = There isn’t really any= accepted spec to consult on encapsulation, but within the concept that I&#= 8217;ve been working with (https://datatracker.ietf.org/doc/draft-irtf-burleigh= -bibe/) the encapsulation protocol is a convergence-layer adapter. = ; In that case, the entire, complete outbound bundle – including any = BAB that was attached at the last moment before serialization for the CLA &= #8211; would become the payload of the new encapsulating bundle.  The = encapsulating bundle might or might not be security-aware, but that doesn&#= 8217;t matter.  The destination of the encapsulating bundle would extr= act the encapsulated bundle (the “outer” bundle’s payload= ) and simulate reception of that bundle, which would still have its BAB.&nb= sp; That bundle would, in effect, have traversed only a single hop (direct = transmission between sender and receiver at the convergence layer), so ther= e was no intervening non-security-aware forwarding node between the sending= node that attached the BAB and the receiving node that would validate it.&= nbsp; So no opportunity for fragmentation, no problem.

 

 

<DZ>

Having outgoing email issues= so some of this is now late and could be later by the time it gets through= – if it gets there.

<= span style=3D'mso-list:Ignore'>oThis is true when all traversed nodes are SBSP compliant and we probably d= o not want to overly complicate SBSP trying to anticipate and handle all po= ssible off-nominal scenarios. One of the off-nominal scenarios that I would= not be surprised to see with the Space Station is the case where our gatew= ay nodes are running pre-SBSP software and a payload developer installs a c= utting edge SBSP implementation. In this scenario, if the payload node appl= ies a BAB to a large bundle [or fragment] then there is the possibility tha= t the pre-SBSP gateway node will fragment [or further fragment] the bundle = and not remove the BAB resulting in its misinterpretation when it makes to = the end node that is SBSP compliant.

o   I am okay with not specifically handling this scenario as we can= recommend not using the BAB until the gateway nodes are updated to SBSP co= mpliance or that their local policy set the ‘Discard block if it can&= #8217;t be processed’ flag on the BAB.

=A7  Amy mentioned the DO_NOT_FRAGMENT” flag as another possib= le option before I could send this reply due to system and email issues (an= d maybe I am a slow typist)…

= =B7         = What happens if there is a conflict= between DO_NOT_FRAGMENT and “must fragment if bigger than x”? = Is the bundle sent whole, trapped, or deleted?

=A7  And now - the suggested BIBE is another good approach

o   If this particular scenario might = impact other folks as well and the consensus is to handle it then a refinem= ent would be to use the <block type> to hold the fragment offset so t= hat a further fragmented fragment could be more reliably reconstituted and = BAB verified. I “think” this would make the BAB “SBSP_hop= - to - SBSP_hop” regardless of the compliance of any intervening nod= es.

 

 

 

= --_000_329D879C76FDD04AAAE84BB1D89B3970094FBFAAC8aplesfreedomd_-- From nobody Tue Jun 3 12:35:56 2014 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADAA41A0309 for ; Tue, 3 Jun 2014 12:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bH6F5o4yNTD5 for ; Tue, 3 Jun 2014 12:35:44 -0700 (PDT) Received: from piper.jhuapl.edu (piper.jhuapl.edu [128.244.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8131A033E for ; Tue, 3 Jun 2014 12:35:43 -0700 (PDT) Received: from aplexcas2.dom1.jhuapl.edu (aplexcas2.dom1.jhuapl.edu [128.244.198.91]) by piper.jhuapl.edu with smtp (TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 3989_9091_a6937462_efe6_4ece_be22_4d6fb91fbfee; Tue, 03 Jun 2014 15:35:36 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Tue, 3 Jun 2014 15:35:32 -0400 From: "Birrane, Edward J." To: "dtn-security@irtf.org" Date: Tue, 3 Jun 2014 15:35:31 -0400 Thread-Topic: Updated SBSP Document - BCB and BIB Thread-Index: Ac9+hoOpmbVxZkqoRbuTayxesOBSNwA209wg Message-ID: <329D879C76FDD04AAAE84BB1D89B3970094FBFAAD9@aplesfreedom.dom1.jhuapl.edu> References: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E56@NDMSMBX404.ndc.nasa.gov> In-Reply-To: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E56@NDMSMBX404.ndc.nasa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_329D879C76FDD04AAAE84BB1D89B3970094FBFAAD9aplesfreedomd_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/Co0ViwaUPdp2iDv9vYPUy6Al3WY Subject: Re: [dtn-security] Updated SBSP Document - BCB and BIB X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 19:35:52 -0000 --_000_329D879C76FDD04AAAE84BB1D89B3970094FBFAAD9aplesfreedomd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable - The ciphersuite parameters for the BCB can list an (offset,length) 2-tupl= e to identify what parts of the security-target are encrypted. When omitted= , the implication is that the entire data portion of the security-target is= encrypted. Otherwise, it is just the offset-length portion. - Inspection of the "Bundle is a fragment" flag will let any arbitrary BPA = understand whether a BCB or BIB can be added. Adding BCBs and BIBs to a fra= gment can result in a challenging re-assembly scenario involving duplicate = security-targets which we should just completely avoid. - I agree that the BCB should only be present in one of the fragments. We s= hould update the spec to reflect this. -Ed --- Ed Birrane Principal Professional Staff, Space Department Johns Hopkins Applied Physics Laboratory (W) 443-778-7423 / (F) 443-228-3839 From: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] [mailto:david.a.= zoller@nasa.gov] Sent: Monday, June 02, 2014 1:21 PM To: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]; Burleigh, Scott C= (JPL-312G)[Jet Propulsion Laboratory]; Birrane, Edward J.; dtn-security@ir= tf.org Subject: RE: Updated SBSP Document - BCB and BIB [Page 14] 2.6 Block Confidentiality Block The block processing control flags value can be set to whatever values are required by local policy, except that a Lone BCB or First BCB MUST have the "replicate in every fragment" flag set. This indicates to a receiving node that the payload portion in each fragment represents cipher-text. =B7 The intent here is only if the target of the Lone BCB or First = BCB is the payload block which would need to be added if this is kept as a = requirement. =B7 I think this requirement should be removed or at least reduced = to a "MAY" 1. It assumes that the Lone or First BCB must be prior to the payload= block which is not a specific requirement and is not necessary in any case= for SBSP 2. A BCB block could be quite large and add a lot of bandwidth overhe= ad if included in every fragment 3. I do not see a benefit gained by including the block in every frag= ment i. Even the destinatio= n node likely cannot decrypt any individual fragment except the first one a= nd it probably would only decrypt a partial bundle as a last resort or for= ensic function if the entire bundle was not received before expiration ii. Intermediate nodes = shouldn't generally be poking around in bundle payloads anyway and no need = to provide additional clues as to whether a fragment payload is encrypted o= r a bunch of binary values - keep the bad guys guessing and wasting CPU cyc= les if possible iii. BSP includes this re= quirement - have any of the implementations found a need or benefit for thi= s and would it still apply in context of the SBSP? =D8 I think this a good point. Since all decryption should only happen at= the bundle destination, which is where all the fragments are going to have= to end up, why not forward all BCBs (for all blocks that have them) only w= ith the fragment whose offset is zero? Is there a possibility of an intermediate node adding a BIB to the fragment= , unaware that there's already a BCB on the whole payload? I really hate t= he interaction between fragmentation and BSP. I feel like tightly locking = down how the two of them combine avoids a lot of pitfalls and ambiguity. My notion is that the BCB should apply to the entire (unfragmented) payload= . If it's possible to apply a BCB to a fragment (in the middle of a path a= nd connection) then the BCB itself had better state to which bytes of the p= ayload it applies, or it's going to be really hard to sort it out later. What's the rationale for replication? The destination is the only node tha= t's going to have to deal with decryption, so what is this doing? Is the n= otion that the receiver might pass parts of the not-yet-fully-received bund= le to the application? That would be, I think, wrong. Fortunately, section 3.4 does prevent adding a BCB or a BIB to a fragment. --_000_329D879C76FDD04AAAE84BB1D89B3970094FBFAAD9aplesfreedomd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

- The ciphersuite parameters for the BCB can list an (offset,= length) 2-tuple to identify what parts of the security-target are encrypted= . When omitted, the implication is that the entire data portion of the secu= rity-target is encrypted.=A0 Otherwise, it is just the offset-length portio= n.

=  

- Inspection of the “Bundle is a fragment” flag will let an= y arbitrary BPA understand whether a BCB or BIB can be added. Adding BCBs a= nd BIBs to a fragment can result in a challenging re-assembly scenario invo= lving duplicate security-targets which we should just completely avoid.

&= nbsp;

- = I agree that the BCB should only be present in one of the fragments. We sho= uld update the spec to reflect this.

 

-Ed

 

 

 

=

--= -
Ed Birrane

Principal Professional Staff, Space Departmen= t
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443= -228-3839
  =

 

From: Zoller, David A= . (MSFC-EO50)[HOSC SERVICES CONTRACT] [mailto:david.a.zoller@nasa.gov]
= Sent: Monday, June 02, 2014 1:21 PM
To: Zoller, David A. (= MSFC-EO50)[HOSC SERVICES CONTRACT]; Burleigh, Scott C (JPL-312G)[Jet Propul= sion Laboratory]; Birrane, Edward J.; dtn-security@irtf.org
Subject:<= /b> RE: Updated SBSP Document - BCB and BIB

 

<DZ&= gt;

[Page 14] 2.6 Block Confident= iality Block

The block processing control flags value can be set to w= hatever

values are required by local policy, except that a Lone BC= B or

First BCB MUST have the "replicate in every fragment&quo= t; flag set.

This indicates to a receiving node that the payload p= ortion in

each fragment represents cipher-text. =

= =B7    &nb= sp;    The intent here is only if the target of the Lone BCB or First BCB = is the payload block which would need to be added if this is kept as a requ= irement.

=B7&n= bsp;        I think this requirement should be removed= or at least reduced to a "MAY"

1.    = ;   It assu= mes that the Lone or First BCB must be prior to the payload block which is = not a specific requirement and is not necessary in any case for SBSP=

= 2.       A BCB block could be quite large and add a lot of bandw= idth overhead if included in every fragment

3.   &= nbsp;   I d= o not see a benefit gained by including the block in every fragment =

       &n= bsp;            = ;            &n= bsp;         i.       = ;     Even the destination node likely cannot decrypt any individual fragmen= t except the first one and  it probably would only decrypt a partial b= undle as a last resort or forensic function if the entire bundle was not re= ceived before expiration

  &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; ii.   = ;         <= span style=3D'color:#00B050'>Intermediate nodes shouldn't generally be poki= ng around in bundle payloads anyway and no need to provide additional clues= as to whether a fragment payload is encrypted or a bunch of binary values = – keep the bad guys guessing and wasting CPU cycles if possible

       = ;            &n= bsp;            = ;       iii.         &n= bsp;  BSP includ= es this requirement - have any of the implementations found a need or benef= it for this and would it still apply in context of the SBSP?

 

<SB>=

= =D8  I think this a good point.  S= ince all decryption should only happen at the bundle destination, which is = where all the fragments are going to have to end up, why not forward all BC= Bs (for all blocks that have them) only with the fragment whose offset is z= ero?   

 

<AA> 

Is there a possibility of an intermediate node adding a BIB to= the fragment, unaware that there's already a BCB on the whole payload? &nb= sp;I really hate the interaction between fragmentation and BSP.  I fee= l like tightly locking down how the two of them combine avoids a lot of pit= falls and ambiguity.

 

 

<KS>

=

My noti= on is that the BCB should apply to the entire (unfragmented) payload. = If it’s possible to apply a BCB to a fragment (in the middle of a pa= th and connection) then the BCB itself had better state to which bytes of t= he payload it applies, or it’s going to be really hard to sort it out= later.

 

What’s the rationale for r= eplication?  The destination is the only node that’s going to ha= ve to deal with decryption, so what is this doing?  Is the notion that= the receiver might pass parts of the not-yet-fully-received bundle to the = application?  That would be, I think, wrong.

 

=

<DZ&= gt;

Fortunately, section 3.4 does prevent adding a BCB or a B= IB to a fragment.

= --_000_329D879C76FDD04AAAE84BB1D89B3970094FBFAAD9aplesfreedomd_-- From nobody Tue Jun 3 12:37:54 2014 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0774A1A034A for ; Tue, 3 Jun 2014 12:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.25 X-Spam-Level: X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1Dk_gX4dwrJ for ; Tue, 3 Jun 2014 12:37:49 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00DCE1A0309 for ; Tue, 3 Jun 2014 12:37:48 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s53Jbg4q017394 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Tue, 3 Jun 2014 12:37:42 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.156]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.182]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 12:37:41 -0700 From: "Burleigh, Scott C (312G)" To: "Birrane, Edward J." , "dtn-security@irtf.org" Thread-Topic: Updated SBSP Document - BAB Thread-Index: Ac9+bH1OvS/DGr4rQCGazJjgMCXvZgA7MfsQAAI18LA= Date: Tue, 3 Jun 2014 19:37:40 +0000 Message-ID: References: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E29@NDMSMBX404.ndc.nasa.gov> <329D879C76FDD04AAAE84BB1D89B3970094FBFAAC8@aplesfreedom.dom1.jhuapl.edu> In-Reply-To: <329D879C76FDD04AAAE84BB1D89B3970094FBFAAC8@aplesfreedom.dom1.jhuapl.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.113] Content-Type: multipart/alternative; boundary="_000_A5BEAD028815CB40A32A5669CF737C3B423B6637apembxsp40RESAD_" MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/iBHSqLsx2sCFh1ihNgF7XJuTPgI Subject: Re: [dtn-security] Updated SBSP Document - BAB X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 19:37:53 -0000 --_000_A5BEAD028815CB40A32A5669CF737C3B423B6637apembxsp40RESAD_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ed, I like (A) but I think there's a possible problem. Because the flag wa= s set to protect the BAB operation, it really ought to be re-set to its ori= ginal value upon reception by the next BAB-aware node. But we don't have a= ny way of knowing what value to reset it to - that is, the flag might have = already been set by another node for some other reason (in which case it sh= ouldn't be set to zero now), or it might not have been (in which case it sh= ould). How about instead always setting the "Delete bundle if block can't be proce= ssed" flag in the BAB, to drive out the network misconfigurations? Scott From: dtn-security [mailto:dtn-security-bounces@irtf.org] On Behalf Of Birr= ane, Edward J. Sent: Tuesday, June 03, 2014 12:24 PM To: dtn-security@irtf.org Subject: Re: [dtn-security] Updated SBSP Document - BAB Dave, Thank you for fragmenting the discussion into separate threads; it is muc= h easier to parse this way. I recommend the following: - It is the intention that when adding a BAB, the next BP hop for the bundl= e is a security-aware node, but this cannot be guaranteed (e.g., there may = be a misconfiguration in the network). The language in the spec should be u= pdated to reflect this. We should do one (not both) of the following: A: When adding a BAB to a bundle, ensure that the bundle's "Bundle must not= be fragmented" field is set. This will result in a delivery failure if the= next BP-hop is unable to deliver the bundle as-is, but also ensures there = is no payload surgery between BP-hops that require BAB authentication. B: Use the content range for the ciphersuite parameters to identify the off= set,length of the bundle being protected. Then, require BPAs to wait until = all fragments of a bundle are received, and then do the authentication chec= k. My preference is to do "A". It is simple and strict when requiring authenti= cation, as should be the case with authentication. My concern regarding approach "B" is that we have to use up memory and othe= r resources for partial bundles. Part of the job of authentication is to pr= event some types of resource attacks on the network, and "B" seems to re-en= able some of those attacks. -Ed --- Ed Birrane Principal Professional Staff, Space Department Johns Hopkins Applied Physics Laboratory (W) 443-778-7423 / (F) 443-228-3839 From: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] [mailto:david.a.= zoller@nasa.gov] Sent: Monday, June 02, 2014 1:07 PM To: Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]; Birrane, Edwar= d J.; dtn-security@irtf.org Subject: RE: Updated SBSP Document - BAB [Page 12] 2.4 Bundle Authentication Block The security-target MUST be the entire bundle, which MUST be represented by a of <0x00><0x00>. =B7 Per 3.4 Bundle Fragmentation and Reassembly, bundle authenticat= ion may be applied to bundle fragments as well as non-fragmented bundles. =B7 If a bundle fragment is received that has a BAB, there is no wa= y to determine if the BAB applies to the bundle fragment or if it applies t= o an entire bundle that was later fragmented by a non-security-aware BA. o I propose that a of <0x00> indicate that the BAB applies to a bundle fragment =B7 If such a bundle fragment is further fragmented by a non-securi= ty-aware BA then the can be used to determine that th= e original fragmented bundle must be reassembled before authentication is c= hecked because it will not match the length field in the payload block. o Some discussion may be desirable in section 3.4 as well as 2.4 if acce= pted =D8 When a BAB is attached to a bundle that is a fragment, the bundle that= it applies to is always that fragment, never the bundle that carried the o= riginal payload (of which the current bundle's payload is a fragment). Sin= ce BABs are not end-to-end, the BAB for an original un-fragmented bundle wi= ll never be carried forward in any fragments generated from that bundle (se= e the last paragraph of 3.3.1), so there's no ambiguity. But this does bri= ng up an important point: the block processing control flags of the BAB mus= t always have the "replicate in every fragment" flag set to 0. Maybe I'm misunderstanding here, but fragmentation can happen between a BAB= source and a BAB dest if a non-security aware node is between the two. Re= quiring the "DO_NOT_FRAGMENT" flag solves this. >> I see what you're saying, and I think it goes to the lament in= your next comment: the interaction between fragmentation and BSP really is= a mess. But I thought SBSP simplified things somewhat by not allowing any= non-security-aware nodes between the BAB source and BAB destination. At l= east, that's what I hoped we were doing, and it's how I interpret "BABs ope= rate between topologically adjacent nodes" on page 6. If that's not the ca= se then I think there are additional problems to resolve. BABs should be applied 'point-to-point' between bundle agents; there should= n't be an opportunity for a non-security-aware node to fragment a bundle wi= th a BAB on it. I'll have to check the cross-product between encapsulation= and BAB (i.e. whether you can encapsulate a bundle with a BAB on it (and t= hen possibly fragment the encapsulating bundle) or not). I suspect that th= e answer is 'no' (i.e. you check / remove the BAB immediately on receipt an= d before you encapsulate and/or fragment for transmission). =D8 There isn't really any accepted spec to consult on encapsulation, but w= ithin the concept that I've been working with (https://datatracker.ietf.org= /doc/draft-irtf-burleigh-bibe/) the encapsulation protocol is a convergence= -layer adapter. In that case, the entire, complete outbound bundle - inclu= ding any BAB that was attached at the last moment before serialization for = the CLA - would become the payload of the new encapsulating bundle. The en= capsulating bundle might or might not be security-aware, but that doesn't m= atter. The destination of the encapsulating bundle would extract the encap= sulated bundle (the "outer" bundle's payload) and simulate reception of tha= t bundle, which would still have its BAB. That bundle would, in effect, ha= ve traversed only a single hop (direct transmission between sender and rece= iver at the convergence layer), so there was no intervening non-security-aw= are forwarding node between the sending node that attached the BAB and the = receiving node that would validate it. So no opportunity for fragmentation= , no problem. Having outgoing email issues so some of this is now late and could be later= by the time it gets through - if it gets there. o This is true when all traversed nodes are SBSP compliant and we probabl= y do not want to overly complicate SBSP trying to anticipate and handle all= possible off-nominal scenarios. One of the off-nominal scenarios that I wo= uld not be surprised to see with the Space Station is the case where our ga= teway nodes are running pre-SBSP software and a payload developer installs = a cutting edge SBSP implementation. In this scenario, if the payload node a= pplies a BAB to a large bundle [or fragment] then there is the possibility = that the pre-SBSP gateway node will fragment [or further fragment] the bund= le and not remove the BAB resulting in its misinterpretation when it makes = to the end node that is SBSP compliant. o I am okay with not specifically handling this scenario as we can recomm= end not using the BAB until the gateway nodes are updated to SBSP complianc= e or that their local policy set the 'Discard block if it can't be processe= d' flag on the BAB. =A7 Amy mentioned the DO_NOT_FRAGMENT" flag as another possible option bef= ore I could send this reply due to system and email issues (and maybe I am = a slow typist)... =B7 What happens if there is a conflict between DO_NOT_FRAGMENT and= "must fragment if bigger than x"? Is the bundle sent whole, trapped, or de= leted? =A7 And now - the suggested BIBE is another good approach o If this particular scenario might impact other folks as well and the co= nsensus is to handle it then a refinement would be to use the = to hold the fragment offset so that a further fragmented fragment could be = more reliably reconstituted and BAB verified. I "think" this would make the= BAB "SBSP_hop - to - SBSP_hop" regardless of the compliance of any interve= ning nodes. --_000_A5BEAD028815CB40A32A5669CF737C3B423B6637apembxsp40RESAD_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ed, I like (A) but I t= hink there’s a possible problem.  Because the flag was set to pr= otect the BAB operation, it really ought to be re-set to its original value= upon reception by the next BAB-aware node.  But we don’t have any way of knowing what value to reset it to – t= hat is, the flag might have already been set by another node for some other= reason (in which case it shouldn’t be set to zero now), or it might = not have been (in which case it should).

 

How about instead alwa= ys setting the “Delete bundle if block can’t be processed”= ; flag in the BAB, to drive out the network misconfigurations?

 

Scott

 

From: dtn-secu= rity [mailto:dtn-security-bounces@irtf.org] On Behalf Of Birrane, Edward J.
Sent: Tuesday, June 03, 2014 12:24 PM
To: dtn-security@irtf.org
Subject: Re: [dtn-security] Updated SBSP Document - BAB

 

Dave,

 

  Thank you for f= ragmenting the discussion into separate threads; it is much easier to parse= this way. 

 

I recommend the follow= ing:

 

- It is the intention = that when adding a BAB, the next BP hop for the bundle is a security-aware = node, but this cannot be guaranteed (e.g., there may be a misconfiguration = in the network). The language in the spec should be updated to reflect this.

 

We should do one (not = both) of the following:

 

A: When adding a BAB t= o a bundle, ensure that the bundle’s “Bundle must not be fragme= nted” field is set. This will result in a delivery failure if the nex= t BP-hop is unable to deliver the bundle as-is, but also ensures there is no payload surgery between BP-hops that require BAB authe= ntication.

 

B: Use the content ran= ge for the ciphersuite parameters to identify the offset,length of the bund= le being protected. Then, require BPAs to wait until all fragments of a bun= dle are received, and then do the authentication check.

 

My preference is to do= “A”. It is simple and strict when requiring authentication, as= should be the case with authentication.

 

My concern regarding a= pproach “B” is that we have to use up memory and other resource= s for partial bundles. Part of the job of authentication is to prevent some= types of resource attacks on the network, and “B” seems to re-enable some of those attacks.

 

-Ed<= /p>

 

--- Ed Birrane

Princ= ipal Professional Staff, Space Department
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839
 

 

From: Zoller, = David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] [mailto:david.a.zoller@nasa.gov]
Sent: Monday, June 02, 2014 1:07 PM
To: Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]; Birrane= , Edward J.; dtn-security@irtf.org
Subject: RE: Updated SBSP Document - BAB

 

<DZ>

[Page 12] 2.4 Bundle Authentication Block

= The security-target MUST be the entire bundle, which MUST be

= represented by a <block type><occurrence number> of <0x00>= ;<0x00>.

=B7         Per 3.4 Bundle= Fragmentation and Reassembly, bundle authentication may be applied to bund= le fragments as well as non-fragmented bundles.

=B7         If a bundle fr= agment is received that has a BAB, there is no way to determine if the BAB = applies to the bundle fragment or if it applies to an entire bundle that wa= s later fragmented by a non-security-aware BA.

o    I propose that= a <block type><occurrence number> of <0x00><payload f= rag length> indicate that the BAB applies to a bundle fragment

=B7         If such a bund= le fragment is further fragmented by a non-security-aware BA then the <p= ayload frag length> can be used to determine that the original fragmente= d bundle must be reassembled before authentication is checked because it will not match the length field in the payload block= .

o    Some discussio= n may be desirable in section 3.4 as well as 2.4 if accepted

<SB>

=D8  When a BAB is = attached to a bundle that is a fragment, the bundle that it applies to is a= lways that fragment, never the bundle that carried the original payload (of= which the current bundle’s payload is a fragment).  Since BABs are not end-to-end, the BAB for an origin= al un-fragmented bundle will never be carried forward in any fragments gene= rated from that bundle (see the last paragraph of 3.3.1), so there’s = no ambiguity.  But this does bring up an important point: the block processing control flags of the BAB must always have the = “replicate in every fragment” flag set to 0.<= /p>

 

<AA>

Maybe I'm misunderstanding here, but fragmentation c= an happen between a BAB source and a BAB dest if a non-security aware node = is between the two.  Requiring the "DO_NOT_FRAGMENT" flag so= lves this.  

 

<SB>

>>  &n= bsp;        I see what you’re sayi= ng, and I think it goes to the lament in your next comment: the interaction= between fragmentation and BSP really is a mess.  But I thought SBSP s= implified things somewhat by not allowing any non-security-aware nodes between the BAB source and BAB d= estination.  At least, that’s what I hoped we were doing, and it= ’s how I interpret “BABs operate between topologically adjacent nodes” on page 6.  If that= ’s not the case then I think there are additional problems to resolve= .

 

<KS>

BABs = should be applied ‘point-to-point’ between bundle agents; there= shouldn’t be an opportunity for a non-security-aware node to fragmen= t a bundle with a BAB on it.  I’ll have to check the cross-produ= ct between encapsulation and BAB (i.e. whether you can encapsulate a bundle w= ith a BAB on it (and then possibly fragment the encapsulating bundle) or no= t).  I suspect that the answer is ‘no’ (i.e. you check / r= emove the BAB immediately on receipt and before you encapsulate and/or fragment for transmission).

 

<SB>

=D8 There isn’t really any accepted spec to consult on encapsulation, = but within the concept that I’ve been working with (https://datatracker.i= etf.org/doc/draft-irtf-burleigh-bibe/) the encapsulation protocol is a convergence-layer adapter.  In that c= ase, the entire, complete outbound bundle – including any BAB that wa= s attached at the last moment before serialization for the CLA – woul= d become the payload of the new encapsulating bundle.  The encapsulating bundle might or might not be security-aware, but that do= esn’t matter.  The destination of the encapsulating bundle would= extract the encapsulated bundle (the “outer” bundle’s pa= yload) and simulate reception of that bundle, which would still have its BAB.  That bundle would, in effect, have traversed only a si= ngle hop (direct transmission between sender and receiver at the convergenc= e layer), so there was no intervening non-security-aware forwarding node be= tween the sending node that attached the BAB and the receiving node that would validate it.  So no opportu= nity for fragmentation, no problem.

&nbs= p;

 

<DZ>

Having outgoing email = issues so some of this is now late and could be later by the time it gets t= hrough – if it gets there.

o   This is true w= hen all traversed nodes are SBSP compliant and we probably do not want to o= verly complicate SBSP trying to anticipate and handle all possible off-nomi= nal scenarios. One of the off-nominal scenarios that I would not be surprised to see with the Space Station is t= he case where our gateway nodes are running pre-SBSP software and a payload= developer installs a cutting edge SBSP implementation. In this scenario, i= f the payload node applies a BAB to a large bundle [or fragment] then there is the possibility that the pre= -SBSP gateway node will fragment [or further fragment] the bundle and not r= emove the BAB resulting in its misinterpretation when it makes to the end n= ode that is SBSP compliant.

o   I am okay with= not specifically handling this scenario as we can recommend not using the = BAB until the gateway nodes are updated to SBSP compliance or that their lo= cal policy set the ‘Discard block if it can’t be processed’ flag on the BAB.

=A7  Amy mentioned = the DO_NOT_FRAGMENT” flag as another possible option before I could s= end this reply due to system and email issues (and maybe I am a slow typist= )…

=B7         What happens i= f there is a conflict between DO_NOT_FRAGMENT and “must fragment if b= igger than x”? Is the bundle sent whole, trapped, or deleted?

=A7  And now - the = suggested BIBE is another good approach

o   If this partic= ular scenario might impact other folks as well and the consensus is to hand= le it then a refinement would be to use the <block type> to hold the = fragment offset so that a further fragmented fragment could be more reliably reconstituted and BAB verified. I “t= hink” this would make the BAB “SBSP_hop - to - SBSP_hop” = regardless of the compliance of any intervening nodes.

 

 

 

--_000_A5BEAD028815CB40A32A5669CF737C3B423B6637apembxsp40RESAD_-- From nobody Tue Jun 3 13:03:19 2014 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590DB1A02F0 for ; Tue, 3 Jun 2014 13:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.25 X-Spam-Level: X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vz7MPrb7WLJ6 for ; Tue, 3 Jun 2014 13:03:08 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 160CF1A035B for ; Tue, 3 Jun 2014 13:03:08 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4CD701F04E1; Tue, 3 Jun 2014 16:03:02 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 3170D1F0361; Tue, 3 Jun 2014 16:03:02 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.73]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 16:03:01 -0400 From: "Scott, Keith L." To: "Burleigh, Scott C (312G)" , "Birrane, Edward J." , "dtn-security@irtf.org" Thread-Topic: Updated SBSP Document - BAB Thread-Index: Ac9+bH1OvS/DGr4rQCGazJjgMCXvZgA7MfsQAAI18LAAAJ4NUA== Date: Tue, 3 Jun 2014 20:03:01 +0000 Message-ID: <5EE81C5C4CFFF4418C5EAD12F49D64EE4C222364@IMCMBX01.MITRE.ORG> References: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E29@NDMSMBX404.ndc.nasa.gov> <329D879C76FDD04AAAE84BB1D89B3970094FBFAAC8@aplesfreedom.dom1.jhuapl.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.140.19.249] Content-Type: multipart/alternative; boundary="_000_5EE81C5C4CFFF4418C5EAD12F49D64EE4C222364IMCMBX01MITREOR_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/XzrWBtjMdzYBNFVsWWsft1vTEPs Subject: Re: [dtn-security] Updated SBSP Document - BAB X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 20:03:17 -0000 --_000_5EE81C5C4CFFF4418C5EAD12F49D64EE4C222364IMCMBX01MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Scott. I don't think setting the don't fragment bit is a good= solution as it might be used / wanted / needed for other purposes. If the question is: "what to do when a bundle with a BAB arrives at a node = that doesn't know how to process BABs" then I think we just have to decide = what behavior we want (based on the bundle processing control flags): 0) Transmit status report if block can't be processed (bpcf 0x02) 1) Drop the bundle (bpcf 0x04) 2) Drop the BAB, pass the bundle (bpcf 0x10) 3) Forward the bundle WITH the BAB, noting that we didn't know what to d= o with it (bpcf 0x20) Realistically I think 1) is the right answer. BABs are supposed to protect= the network from bad traffic getting in. Once traffic is 'in' then the on= ly thing we have protecting against things like denial-of-service attacks w= ould be the bptables capability, and I don't think that's mature enough to = be a good solution. --keith From: dtn-security [mailto:dtn-security-bounces@irtf.org] On Behalf Of Burl= eigh, Scott C (312G) Sent: Tuesday, June 03, 2014 3:38 PM To: Birrane, Edward J.; dtn-security@irtf.org Subject: Re: [dtn-security] Updated SBSP Document - BAB Ed, I like (A) but I think there's a possible problem. Because the flag wa= s set to protect the BAB operation, it really ought to be re-set to its ori= ginal value upon reception by the next BAB-aware node. But we don't have a= ny way of knowing what value to reset it to - that is, the flag might have = already been set by another node for some other reason (in which case it sh= ouldn't be set to zero now), or it might not have been (in which case it sh= ould). How about instead always setting the "Delete bundle if block can't be proce= ssed" flag in the BAB, to drive out the network misconfigurations? Scott From: dtn-security [mailto:dtn-security-bounces@irtf.org] On Behalf Of Birr= ane, Edward J. Sent: Tuesday, June 03, 2014 12:24 PM To: dtn-security@irtf.org Subject: Re: [dtn-security] Updated SBSP Document - BAB Dave, Thank you for fragmenting the discussion into separate threads; it is muc= h easier to parse this way. I recommend the following: - It is the intention that when adding a BAB, the next BP hop for the bundl= e is a security-aware node, but this cannot be guaranteed (e.g., there may = be a misconfiguration in the network). The language in the spec should be u= pdated to reflect this. We should do one (not both) of the following: A: When adding a BAB to a bundle, ensure that the bundle's "Bundle must not= be fragmented" field is set. This will result in a delivery failure if the= next BP-hop is unable to deliver the bundle as-is, but also ensures there = is no payload surgery between BP-hops that require BAB authentication. B: Use the content range for the ciphersuite parameters to identify the off= set,length of the bundle being protected. Then, require BPAs to wait until = all fragments of a bundle are received, and then do the authentication chec= k. My preference is to do "A". It is simple and strict when requiring authenti= cation, as should be the case with authentication. My concern regarding approach "B" is that we have to use up memory and othe= r resources for partial bundles. Part of the job of authentication is to pr= event some types of resource attacks on the network, and "B" seems to re-en= able some of those attacks. -Ed --- Ed Birrane Principal Professional Staff, Space Department Johns Hopkins Applied Physics Laboratory (W) 443-778-7423 / (F) 443-228-3839 From: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] [mailto:david.a.= zoller@nasa.gov] Sent: Monday, June 02, 2014 1:07 PM To: Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]; Birrane, Edwar= d J.; dtn-security@irtf.org Subject: RE: Updated SBSP Document - BAB [Page 12] 2.4 Bundle Authentication Block The security-target MUST be the entire bundle, which MUST be represented by a of <0x00><0x00>. * Per 3.4 Bundle Fragmentation and Reassembly, bundle authentication= may be applied to bundle fragments as well as non-fragmented bundles. * If a bundle fragment is received that has a BAB, there is no way t= o determine if the BAB applies to the bundle fragment or if it applies to a= n entire bundle that was later fragmented by a non-security-aware BA. o I propose that a of <0x00> indicate that the BAB applies to a bundle fragment * If such a bundle fragment is further fragmented by a non-security-= aware BA then the can be used to determine that the o= riginal fragmented bundle must be reassembled before authentication is chec= ked because it will not match the length field in the payload block. o Some discussion may be desirable in section 3.4 as well as 2.4 if accep= ted ? When a BAB is attached to a bundle that is a fragment, the bundle that i= t applies to is always that fragment, never the bundle that carried the ori= ginal payload (of which the current bundle's payload is a fragment). Since= BABs are not end-to-end, the BAB for an original un-fragmented bundle will= never be carried forward in any fragments generated from that bundle (see = the last paragraph of 3.3.1), so there's no ambiguity. But this does bring= up an important point: the block processing control flags of the BAB must = always have the "replicate in every fragment" flag set to 0. Maybe I'm misunderstanding here, but fragmentation can happen between a BAB= source and a BAB dest if a non-security aware node is between the two. Re= quiring the "DO_NOT_FRAGMENT" flag solves this. >> I see what you're saying, and I think it goes to the lament in= your next comment: the interaction between fragmentation and BSP really is= a mess. But I thought SBSP simplified things somewhat by not allowing any= non-security-aware nodes between the BAB source and BAB destination. At l= east, that's what I hoped we were doing, and it's how I interpret "BABs ope= rate between topologically adjacent nodes" on page 6. If that's not the ca= se then I think there are additional problems to resolve. BABs should be applied 'point-to-point' between bundle agents; there should= n't be an opportunity for a non-security-aware node to fragment a bundle wi= th a BAB on it. I'll have to check the cross-product between encapsulation= and BAB (i.e. whether you can encapsulate a bundle with a BAB on it (and t= hen possibly fragment the encapsulating bundle) or not). I suspect that th= e answer is 'no' (i.e. you check / remove the BAB immediately on receipt an= d before you encapsulate and/or fragment for transmission). ? There isn't really any accepted spec to consult on encapsulation, but wit= hin the concept that I've been working with (https://datatracker.ietf.org/d= oc/draft-irtf-burleigh-bibe/) the encapsulation protocol is a convergence-l= ayer adapter. In that case, the entire, complete outbound bundle - includi= ng any BAB that was attached at the last moment before serialization for th= e CLA - would become the payload of the new encapsulating bundle. The enca= psulating bundle might or might not be security-aware, but that doesn't mat= ter. The destination of the encapsulating bundle would extract the encapsu= lated bundle (the "outer" bundle's payload) and simulate reception of that = bundle, which would still have its BAB. That bundle would, in effect, have= traversed only a single hop (direct transmission between sender and receiv= er at the convergence layer), so there was no intervening non-security-awar= e forwarding node between the sending node that attached the BAB and the re= ceiving node that would validate it. So no opportunity for fragmentation, = no problem. Having outgoing email issues so some of this is now late and could be later= by the time it gets through - if it gets there. o This is true when all traversed nodes are SBSP compliant and we probabl= y do not want to overly complicate SBSP trying to anticipate and handle all= possible off-nominal scenarios. One of the off-nominal scenarios that I wo= uld not be surprised to see with the Space Station is the case where our ga= teway nodes are running pre-SBSP software and a payload developer installs = a cutting edge SBSP implementation. In this scenario, if the payload node a= pplies a BAB to a large bundle [or fragment] then there is the possibility = that the pre-SBSP gateway node will fragment [or further fragment] the bund= le and not remove the BAB resulting in its misinterpretation when it makes = to the end node that is SBSP compliant. o I am okay with not specifically handling this scenario as we can recomm= end not using the BAB until the gateway nodes are updated to SBSP complianc= e or that their local policy set the 'Discard block if it can't be processe= d' flag on the BAB. ? Amy mentioned the DO_NOT_FRAGMENT" flag as another possible option befor= e I could send this reply due to system and email issues (and maybe I am a = slow typist)... * What happens if there is a conflict between DO_NOT_FRAGMENT and "m= ust fragment if bigger than x"? Is the bundle sent whole, trapped, or delet= ed? ? And now - the suggested BIBE is another good approach o If this particular scenario might impact other folks as well and the co= nsensus is to handle it then a refinement would be to use the = to hold the fragment offset so that a further fragmented fragment could be = more reliably reconstituted and BAB verified. I "think" this would make the= BAB "SBSP_hop - to - SBSP_hop" regardless of the compliance of any interve= ning nodes. --_000_5EE81C5C4CFFF4418C5EAD12F49D64EE4C222364IMCMBX01MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agr= ee with Scott.  I don’t think setting the don’t fragment b= it is a good solution as it might be used / wanted / needed for other purpo= ses.

=  

If th= e question is: “what to do when a bundle with a BAB arrives at a node= that doesn’t know how to process BABs” then I think we just ha= ve to decide what behavior we want (based on the bundle processing control flags):

0)    Transmit status report if block can’t be processed (bpcf 0x02)

1)    Drop the bundle (bpcf 0x04)

2)    Drop the BAB, pass the bundle (bpcf 0x10)

3)    Forward the bundle WITH the BAB, noting that we didn’t know what t= o do with it (bpcf 0x20)

=  

Reali= stically I think 1) is the right answer.  BABs are supposed to protect= the network from bad traffic getting in.  Once traffic is ‘in&#= 8217; then the only thing we have protecting against things like denial-of-service attacks would be the bptables capability, and I don= ’t think that’s mature enough to be a good solution.=

=  

 = ;            &n= bsp;          --keith

=  

From: dtn-security= [mailto:dtn-security-bounces@irtf.org] On Behalf Of Burleigh, Scott C (312G)
Sent: Tuesday, June 03, 2014 3:38 PM
To: Birrane, Edward J.; dtn-security@irtf.org
Subject: Re: [dtn-security] Updated SBSP Document - BAB

 

Ed, I like (A) but I think there’s a possible problem.  Bec= ause the flag was set to protect the BAB operation, it really ought to be r= e-set to its original value upon reception by the next BAB-aware node.  But we don’t have any way of knowing what= value to reset it to – that is, the flag might have already been set= by another node for some other reason (in which case it shouldn’t be= set to zero now), or it might not have been (in which case it should).

 

How about instead always setting the “Delete bundle if block can= ’t be processed” flag in the BAB, to drive out the network misc= onfigurations?

 

Scott

 

From: dtn-security [mailto:dtn-security-bounces@irtf.org] On Behalf Of Birrane, Edward J.
Sent: Tuesday, June 03, 2014 12:24 PM
To: dtn-security@irtf.org
Subject: Re: [dtn-security] Updated SBSP Document - BAB

 

Dave,

 

  Thank you for fragmenting the discussion into separate threads;= it is much easier to parse this way. 

 

I recommend the following:

 

- It is the intention that when adding a BAB, the next BP hop for the = bundle is a security-aware node, but this cannot be guaranteed (e.g., there= may be a misconfiguration in the network). The language in the spec should be updated to reflect this.

 

We should do one (not both) of the following:

 

A: When adding a BAB to a bundle, ensure that the bundle’s ̶= 0;Bundle must not be fragmented” field is set. This will result in a = delivery failure if the next BP-hop is unable to deliver the bundle as-is, but also ensures there is no payload surgery between BP-= hops that require BAB authentication.

 

B: Use the content range for the ciphersuite parameters to identify th= e offset,length of the bundle being protected. Then, require BPAs to wait u= ntil all fragments of a bundle are received, and then do the authentication check.

 

My preference is to do “A”. It is simple and strict when r= equiring authentication, as should be the case with authentication.

 

My concern regarding approach “B” is that we have to use u= p memory and other resources for partial bundles. Part of the job of authen= tication is to prevent some types of resource attacks on the network, and “B” seems to re-enable some of those attac= ks.

 

-Ed

 

---
Ed Birrane

Principal Professional Staff, Space Department
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839
 

 

From: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] [mailto:david.a.zoller@nasa.gov= ]
Sent: Monday, June 02, 2014 1:07 PM
To: Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]; Birrane= , Edward J.; dtn-security@irtf.org
Subject: RE: Updated SBSP Document - BAB

 

<DZ><= /b>

[Page 12] 2.4 Bundle A= uthentication Block

The security-target MUST be the entire bundle, w= hich MUST be

represented by a <block type><occurrenc= e number> of <0x00><0x00>.

·        Per 3.4 Bundle= Fragmentation and Reassembly, bundle authentication may be applied to bund= le fragments as well as non-fragmented bundles.

·        If a bundle fr= agment is received that has a BAB, there is no way to determine if the BAB = applies to the bundle fragment or if it applies to an entire bundle that wa= s later fragmented by a non-security-aware BA.

o   I propose that= a <block type><occurrence number> of <0x00><payload f= rag length> indicate that the BAB applies to a bundle fragment

·        If such a bund= le fragment is further fragmented by a non-security-aware BA then the <p= ayload frag length> can be used to determine that the original fragmente= d bundle must be reassembled before authentication is checked because it will not match the length field in the payload block= .

o   Some discussio= n may be desirable in section 3.4 as well as 2.4 if accepted

= <SB>

Ø  When a BAB is = attached to a bundle that is a fragment, the bundle that it applies to is a= lways that fragment, never the bundle that carried the original payload (of= which the current bundle’s payload is a fragment).  Since BABs are not end-to-end, the BAB for an origin= al un-fragmented bundle will never be carried forward in any fragments gene= rated from that bundle (see the last paragraph of 3.3.1), so there’s = no ambiguity.  But this does bring up an important point: the block processing control flags of the BAB must always have the = “replicate in every fragment” flag set to 0.<= /p>

 

<AA><= /b>

Maybe I'm misunderstandin= g here, but fragmentation can happen between a BAB source and a BAB dest if= a non-security aware node is between the two.  Requiring the "DO= _NOT_FRAGMENT" flag solves this.  

 

<SB>

>>           I= see what you’re saying, and I think it goes to the lament in your ne= xt comment: the interaction between fragmentation and BSP really is a mess.=   But I thought SBSP simplified things somewhat by not allowing any non-security-aware nodes between the B= AB source and BAB destination.  At least, that’s what I hoped we= were doing, and it’s how I interpret “BABs operate between topologically adjacent nodes” o= n page 6.  If that’s not the case then I think there are additio= nal problems to resolve.

 

<KS>

BABs should be applied ‘point-to-point’ b= etween bundle agents; there shouldn’t be an opportunity for a non-sec= urity-aware node to fragment a bundle with a BAB on it.  I’ll have to check the cross-product between encapsulation and BAB (= i.e. whether you can encapsulate a bundle with a BAB on it (and then possib= ly fragment the encapsulating bundle) or not).  I suspect that the ans= wer is ‘no’ (i.e. you check / remove the BAB immediately on receipt and before you encapsulate and/or fragment for tran= smission).

 

<SB>

Ø There isn’t really any accepted spec to consult on encapsulation, = but within the concept that I’ve been working with (https://datatracker.i= etf.org/doc/draft-irtf-burleigh-bibe/) the encapsulation protocol is a convergence-layer adapter.  In that c= ase, the entire, complete outbound bundle – including any BAB that wa= s attached at the last moment before serialization for the CLA – woul= d become the payload of the new encapsulating bundle.  The encapsulating bundle might or might not be security-aware, but that do= esn’t matter.  The destination of the encapsulating bundle would= extract the encapsulated bundle (the “outer” bundle’s pa= yload) and simulate reception of that bundle, which would still have its BAB.  That bundle would, in effect, have traversed only a si= ngle hop (direct transmission between sender and receiver at the convergenc= e layer), so there was no intervening non-security-aware forwarding node be= tween the sending node that attached the BAB and the receiving node that would validate it.  So no opportu= nity for fragmentation, no problem.

&nb= sp;

 

<DZ>

Having outgoing email issues so some of this is now late and could be = later by the time it gets through – if it gets there.

o   This is true w= hen all traversed nodes are SBSP compliant and we probably do not want to o= verly complicate SBSP trying to anticipate and handle all possible off-nomi= nal scenarios. One of the off-nominal scenarios that I would not be surprised to see with the Space Station is t= he case where our gateway nodes are running pre-SBSP software and a payload= developer installs a cutting edge SBSP implementation. In this scenario, i= f the payload node applies a BAB to a large bundle [or fragment] then there is the possibility that the pre= -SBSP gateway node will fragment [or further fragment] the bundle and not r= emove the BAB resulting in its misinterpretation when it makes to the end n= ode that is SBSP compliant.

o   I am okay with= not specifically handling this scenario as we can recommend not using the = BAB until the gateway nodes are updated to SBSP compliance or that their lo= cal policy set the ‘Discard block if it can’t be processed’ flag on the BAB.

§  Amy mentioned = the DO_NOT_FRAGMENT” flag as another possible option before I could s= end this reply due to system and email issues (and maybe I am a slow typist= )…

·        What happens i= f there is a conflict between DO_NOT_FRAGMENT and “must fragment if b= igger than x”? Is the bundle sent whole, trapped, or deleted?

§  And now - the = suggested BIBE is another good approach

o   If this partic= ular scenario might impact other folks as well and the consensus is to hand= le it then a refinement would be to use the <block type> to hold the = fragment offset so that a further fragmented fragment could be more reliably reconstituted and BAB verified. I “t= hink” this would make the BAB “SBSP_hop - to - SBSP_hop” = regardless of the compliance of any intervening nodes.

 

 

 

--_000_5EE81C5C4CFFF4418C5EAD12F49D64EE4C222364IMCMBX01MITREOR_-- From nobody Tue Jun 3 13:05:10 2014 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A80E1A0363 for ; Tue, 3 Jun 2014 13:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqmsCI7tB56w for ; Tue, 3 Jun 2014 13:05:02 -0700 (PDT) Received: from piper.jhuapl.edu (piper.jhuapl.edu [128.244.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48F0D1A026B for ; Tue, 3 Jun 2014 13:05:01 -0700 (PDT) Received: from aplexcas1.dom1.jhuapl.edu (unknown [128.244.198.90]) by piper.jhuapl.edu with smtp (TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 39ad_1653_21d0fb60_9f52_4929_9636_efbad0a4fb69; Tue, 03 Jun 2014 16:04:54 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas1.dom1.jhuapl.edu ([128.244.198.90]) with mapi; Tue, 3 Jun 2014 16:04:55 -0400 From: "Birrane, Edward J." To: "dtn-security@irtf.org" Date: Tue, 3 Jun 2014 16:04:53 -0400 Thread-Topic: Updated SBSP Document - BAB Thread-Index: Ac9+bH1OvS/DGr4rQCGazJjgMCXvZgA7MfsQAAI18LAAASfjYA== Message-ID: <329D879C76FDD04AAAE84BB1D89B3970094FFC4BD5@aplesfreedom.dom1.jhuapl.edu> References: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E29@NDMSMBX404.ndc.nasa.gov> <329D879C76FDD04AAAE84BB1D89B3970094FBFAAC8@aplesfreedom.dom1.jhuapl.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_329D879C76FDD04AAAE84BB1D89B3970094FFC4BD5aplesfreedomd_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/RUDYW0Lv5LOHoGPLSwD9nrA94ZQ Subject: Re: [dtn-security] Updated SBSP Document - BAB X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 20:05:09 -0000 --_000_329D879C76FDD04AAAE84BB1D89B3970094FFC4BD5aplesfreedomd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Scott, Excellent point. I had forgotten that there was such a flag, and I think = that this captures the desired behavior nicely. The BAB is defined between= two BP nodes, and if there is a non-security-aware BP node between two sec= urity-aware-nodes, that breaks the single-bp-hop nature of the BAB, and a B= IB should be used instead. Policy should then generate necessary reporting messages. -Ed --- Ed Birrane Principal Professional Staff, Space Department Johns Hopkins Applied Physics Laboratory (W) 443-778-7423 / (F) 443-228-3839 From: Burleigh, Scott C (312G) [mailto:scott.c.burleigh@jpl.nasa.gov] Sent: Tuesday, June 03, 2014 3:38 PM To: Birrane, Edward J.; dtn-security@irtf.org Subject: RE: Updated SBSP Document - BAB Ed, I like (A) but I think there's a possible problem. Because the flag wa= s set to protect the BAB operation, it really ought to be re-set to its ori= ginal value upon reception by the next BAB-aware node. But we don't have a= ny way of knowing what value to reset it to - that is, the flag might have = already been set by another node for some other reason (in which case it sh= ouldn't be set to zero now), or it might not have been (in which case it sh= ould). How about instead always setting the "Delete bundle if block can't be proce= ssed" flag in the BAB, to drive out the network misconfigurations? Scott From: dtn-security [mailto:dtn-security-bounces@irtf.org] On Behalf Of Birr= ane, Edward J. Sent: Tuesday, June 03, 2014 12:24 PM To: dtn-security@irtf.org Subject: Re: [dtn-security] Updated SBSP Document - BAB Dave, Thank you for fragmenting the discussion into separate threads; it is muc= h easier to parse this way. I recommend the following: - It is the intention that when adding a BAB, the next BP hop for the bundl= e is a security-aware node, but this cannot be guaranteed (e.g., there may = be a misconfiguration in the network). The language in the spec should be u= pdated to reflect this. We should do one (not both) of the following: A: When adding a BAB to a bundle, ensure that the bundle's "Bundle must not= be fragmented" field is set. This will result in a delivery failure if the= next BP-hop is unable to deliver the bundle as-is, but also ensures there = is no payload surgery between BP-hops that require BAB authentication. B: Use the content range for the ciphersuite parameters to identify the off= set,length of the bundle being protected. Then, require BPAs to wait until = all fragments of a bundle are received, and then do the authentication chec= k. My preference is to do "A". It is simple and strict when requiring authenti= cation, as should be the case with authentication. My concern regarding approach "B" is that we have to use up memory and othe= r resources for partial bundles. Part of the job of authentication is to pr= event some types of resource attacks on the network, and "B" seems to re-en= able some of those attacks. -Ed --- Ed Birrane Principal Professional Staff, Space Department Johns Hopkins Applied Physics Laboratory (W) 443-778-7423 / (F) 443-228-3839 From: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] [mailto:david.a.= zoller@nasa.gov] Sent: Monday, June 02, 2014 1:07 PM To: Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]; Birrane, Edwar= d J.; dtn-security@irtf.org Subject: RE: Updated SBSP Document - BAB [Page 12] 2.4 Bundle Authentication Block The security-target MUST be the entire bundle, which MUST be represented by a of <0x00><0x00>. =B7 Per 3.4 Bundle Fragmentation and Reassembly, bundle authenticati= on may be applied to bundle fragments as well as non-fragmented bundles. =B7 If a bundle fragment is received that has a BAB, there is no way= to determine if the BAB applies to the bundle fragment or if it applies to= an entire bundle that was later fragmented by a non-security-aware BA. o I propose that a of <0x00> indicate that the BAB applies to a bundle fragment =B7 If such a bundle fragment is further fragmented by a non-securi= ty-aware BA then the can be used to determine that th= e original fragmented bundle must be reassembled before authentication is c= hecked because it will not match the length field in the payload block. o Some discussion may be desirable in section 3.4 as well as 2.4 if acce= pted =D8 When a BAB is attached to a bundle that is a fragment, the bundle that= it applies to is always that fragment, never the bundle that carried the o= riginal payload (of which the current bundle's payload is a fragment). Sin= ce BABs are not end-to-end, the BAB for an original un-fragmented bundle wi= ll never be carried forward in any fragments generated from that bundle (se= e the last paragraph of 3.3.1), so there's no ambiguity. But this does bri= ng up an important point: the block processing control flags of the BAB mus= t always have the "replicate in every fragment" flag set to 0. Maybe I'm misunderstanding here, but fragmentation can happen between a BAB= source and a BAB dest if a non-security aware node is between the two. Re= quiring the "DO_NOT_FRAGMENT" flag solves this. >> I see what you're saying, and I think it goes to the lament in= your next comment: the interaction between fragmentation and BSP really is= a mess. But I thought SBSP simplified things somewhat by not allowing any= non-security-aware nodes between the BAB source and BAB destination. At l= east, that's what I hoped we were doing, and it's how I interpret "BABs ope= rate between topologically adjacent nodes" on page 6. If that's not the ca= se then I think there are additional problems to resolve. BABs should be applied 'point-to-point' between bundle agents; there should= n't be an opportunity for a non-security-aware node to fragment a bundle wi= th a BAB on it. I'll have to check the cross-product between encapsulation= and BAB (i.e. whether you can encapsulate a bundle with a BAB on it (and t= hen possibly fragment the encapsulating bundle) or not). I suspect that th= e answer is 'no' (i.e. you check / remove the BAB immediately on receipt an= d before you encapsulate and/or fragment for transmission). =D8 There isn't really any accepted spec to consult on encapsulation, but w= ithin the concept that I've been working with (https://datatracker.ietf.org= /doc/draft-irtf-burleigh-bibe/) the encapsulation protocol is a convergence= -layer adapter. In that case, the entire, complete outbound bundle - inclu= ding any BAB that was attached at the last moment before serialization for = the CLA - would become the payload of the new encapsulating bundle. The en= capsulating bundle might or might not be security-aware, but that doesn't m= atter. The destination of the encapsulating bundle would extract the encap= sulated bundle (the "outer" bundle's payload) and simulate reception of tha= t bundle, which would still have its BAB. That bundle would, in effect, ha= ve traversed only a single hop (direct transmission between sender and rece= iver at the convergence layer), so there was no intervening non-security-aw= are forwarding node between the sending node that attached the BAB and the = receiving node that would validate it. So no opportunity for fragmentation= , no problem. Having outgoing email issues so some of this is now late and could be later= by the time it gets through - if it gets there. o This is true when all traversed nodes are SBSP compliant and we probabl= y do not want to overly complicate SBSP trying to anticipate and handle all= possible off-nominal scenarios. One of the off-nominal scenarios that I wo= uld not be surprised to see with the Space Station is the case where our ga= teway nodes are running pre-SBSP software and a payload developer installs = a cutting edge SBSP implementation. In this scenario, if the payload node a= pplies a BAB to a large bundle [or fragment] then there is the possibility = that the pre-SBSP gateway node will fragment [or further fragment] the bund= le and not remove the BAB resulting in its misinterpretation when it makes = to the end node that is SBSP compliant. o I am okay with not specifically handling this scenario as we can recomm= end not using the BAB until the gateway nodes are updated to SBSP complianc= e or that their local policy set the 'Discard block if it can't be processe= d' flag on the BAB. =A7 Amy mentioned the DO_NOT_FRAGMENT" flag as another possible option bef= ore I could send this reply due to system and email issues (and maybe I am = a slow typist)... =B7 What happens if there is a conflict between DO_NOT_FRAGMENT and= "must fragment if bigger than x"? Is the bundle sent whole, trapped, or de= leted? =A7 And now - the suggested BIBE is another good approach o If this particular scenario might impact other folks as well and the co= nsensus is to handle it then a refinement would be to use the = to hold the fragment offset so that a further fragmented fragment could be = more reliably reconstituted and BAB verified. I "think" this would make the= BAB "SBSP_hop - to - SBSP_hop" regardless of the compliance of any interve= ning nodes. --_000_329D879C76FDD04AAAE84BB1D89B3970094FFC4BD5aplesfreedomd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Scott,

 

=A0 Excellent point. I had forgotten that there was = such a flag, and I think that this captures the desired behavior nicely.=A0= The BAB is defined between two BP nodes, and if there is a non-security-aw= are BP node between two security-aware-nodes, that breaks the single-bp-hop= nature of the BAB, and a BIB should=A0 be used instead.<= /p>

 

=A0 Policy should= then generate necessary reporting messages.

 

-Ed

 

-= --
Ed Birrane

Principal Professional Staff, Space Departme= nt
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 44= 3-228-3839
 

 

From: Burleigh, Scot= t C (312G) [mailto:scott.c.burleigh@jpl.nasa.gov]
Sent: Tuesday,= June 03, 2014 3:38 PM
To: Birrane, Edward J.; dtn-security@irtf.= org
Subject: RE: Updated SBSP Document - BAB

 

Ed, I like (A) but I think there’s a p= ossible problem.  Because the flag was set to protect the BAB operatio= n, it really ought to be re-set to its original value upon reception by the= next BAB-aware node.  But we don’t have any way of knowing what= value to reset it to – that is, the flag might have already been set= by another node for some other reason (in which case it shouldn’t be= set to zero now), or it might not have been (in which case it should).

&= nbsp;

Ho= w about instead always setting the “Delete bundle if block can’= t be processed” flag in the BAB, to drive out the network misconfigur= ations?

 

Scott

 

= From:= dtn-security [mailto:d= tn-security-bounces@irtf.org] On Behalf Of Birrane, Edward J.Sent: Tuesday, June 03, 2014 12:24 PM
To: dtn-security@irtf.org
Subject: Re: = [dtn-security] Updated SBSP Document - BAB

 

Dave,

 

  Thank you for fragmenting the discussion i= nto separate threads; it is much easier to parse this way. 

 <= /o:p>

I recomm= end the following:

 

- It is the intention that when adding a BAB, the next = BP hop for the bundle is a security-aware node, but this cannot be guarante= ed (e.g., there may be a misconfiguration in the network). The language in = the spec should be updated to reflect this.

 

We should do one (not both) = of the following:

 

A: When adding a BAB to a bundle, ensure that the bundle= ’s “Bundle must not be fragmented” field is set. This wil= l result in a delivery failure if the next BP-hop is unable to deliver the = bundle as-is, but also ensures there is no payload surgery between BP-hops = that require BAB authentication.

=  

B: Use the content range for the ciphersu= ite parameters to identify the offset,length of the bundle being protected.= Then, require BPAs to wait until all fragments of a bundle are received, a= nd then do the authentication check.

 

My preference is to do “A̶= 1;. It is simple and strict when requiring authentication, as should be the= case with authentication.

 

My concern regarding approach “B” i= s that we have to use up memory and other resources for partial bundles. Pa= rt of the job of authentication is to prevent some types of resource attack= s on the network, and “B” seems to re-enable some of those atta= cks.

 

-Ed

 

---
Ed Birrane

Principal = Professional Staff, Space Department
Johns Hopkins Applied Physics Labor= atory
(W) 443-778-7423 / (F) 443-228-3839
 

 

From: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] [<= a href=3D"mailto:david.a.zoller@nasa.gov">mailto:david.a.zoller@nasa.gov]
Sent: Monday, June 02, 2014 1:07 PM
To: Burleigh, S= cott C (JPL-312G)[Jet Propulsion Laboratory]; Birrane, Edward J.; dtn-security@irtf.org
Subject:<= /b> RE: Updated SBSP Document - BAB

 

<DZ>=

[Page 12] 2.4 Bundle Authentication B= lock

The security-target MUST be the entire bundle, which MUST be

represented by a <block type><occurrence number> of <0= x00><0x00>.

=B7        <= /span>Per 3.4 Bundle Fragmen= tation and Reassembly, bundle authentication may be applied to bundle fragm= ents as well as non-fragmented bundles.<= /p>

=B7  &nb= sp;     If a bundle fragment is received that has a BAB, there is no = way to determine if the BAB applies to the bundle fragment or if it applies= to an entire bundle that was later fragmented by a non-security-aware BA.<= /span>

o    <= span style=3D'color:#00B050'>I propose that a <block type><occurre= nce number> of <0x00><payload frag length> indicate that the= BAB applies to a bundle fragment

=B7   &nb= sp;     If such a bundle fragment is further fragmented by a non-secu= rity-aware BA then the <payload frag length> can be used to determine= that the original fragmented bundle must be reassembled before authenticat= ion is checked because it will not match the length field in the payload bl= ock.

o    Some discussion may be desirable in secti= on 3.4 as well as 2.4 if accepted

<SB>

<= ![if !supportLists]>=D8When = a BAB is attached to a bundle that is a fragment, the bundle that it applie= s to is always that fragment, never the bundle that carried the original pa= yload (of which the current bundle’s payload is a fragment).  Si= nce BABs are not end-to-end, the BAB for an original un-fragmented bundle w= ill never be carried forward in any fragments generated from that bundle (s= ee the last paragraph of 3.3.1), so there’s no ambiguity.  But t= his does bring up an important point: the block processing control flags of= the BAB must always have the “replicate in every fragment” fla= g set to 0.

 

<AA>

Maybe I'm misunderstanding here, but fr= agmentation can happen between a BAB source and a BAB dest if a non-securit= y aware node is between the two.  Requiring the "DO_NOT_FRAGMENT&= quot; flag solves this.  

 

<SB>

>>    &nb= sp;      I see what you’re saying, and I thi= nk it goes to the lament in your next comment: the interaction between frag= mentation and BSP really is a mess.  But I thought SBSP simplified thi= ngs somewhat by not allowing any non-security-aware nodes between the BAB s= ource and BAB destination.  At least, that’s what I hoped we wer= e doing, and it’s how I interpret “BABs operate between topologically adjacent= nodes” on page 6.  If that= ’s not the case then I think there are additional problems to resolve= .

<= o:p> 

<KS>

BABs should be applied ‘point-to-= point’ between bundle agents; there shouldn’t be an opportunity= for a non-security-aware node to fragment a bundle with a BAB on it. = I’ll have to check the cross-product between encapsulation and BAB (= i.e. whether you can encapsulate a bundle with a BAB on it (and then possib= ly fragment the encapsulating bundle) or not).  I suspect that the ans= wer is ‘no’ (i.e. you check / remove the BAB immediately on rec= eipt and before you encapsulate and/or fragment for transmission).

 =

<= SB>

=D8 There isnR= 17;t really any accepted spec to consult on encapsulation, but within the c= oncept that I’ve been working with (https://datatracker.ietf.org/doc/draf= t-irtf-burleigh-bibe/) the encapsulation protocol is a convergence-laye= r adapter.  In that case, the entire, complete outbound bundle –= including any BAB that was attached at the last moment before serializatio= n for the CLA – would become the payload of the new encapsulating bun= dle.  The encapsulating bundle might or might not be security-aware, b= ut that doesn’t matter.  The destination of the encapsulating bu= ndle would extract the encapsulated bundle (the “outer” bundle&= #8217;s payload) and simulate reception of that bundle, which would still h= ave its BAB.  That bundle would, in effect, have traversed only a sing= le hop (direct transmission between sender and receiver at the convergence = layer), so there was no intervening non-security-aware forwarding node betw= een the sending node that attached the BAB and the receiving node that woul= d validate it.  So no opportunity for fragmentation, no problem.

 

 

<DZ>

Having outgoi= ng email issues so some of this is now late and could be later by the time = it gets through – if it gets there.

o   This is true when all traversed nodes are SBSP compliant an= d we probably do not want to overly complicate SBSP trying to anticipate an= d handle all possible off-nominal scenarios. One of the off-nominal scenari= os that I would not be surprised to see with the Space Station is the case = where our gateway nodes are running pre-SBSP software and a payload develop= er installs a cutting edge SBSP implementation. In this scenario, if the pa= yload node applies a BAB to a large bundle [or fragment] then there is the = possibility that the pre-SBSP gateway node will fragment [or further fragme= nt] the bundle and not remove the BAB resulting in its misinterpretation wh= en it makes to the end node that is SBSP compliant.

o   I am okay with not specifically handling this sce= nario as we can recommend not using the BAB until the gateway nodes are upd= ated to SBSP compliance or that their local policy set the ‘Discard b= lock if it can’t be processed’ flag on the BAB.

=A7  Amy mentioned the DO_NOT_FRAGMENT” flag as= another possible option before I could send this reply due to system and e= mail issues (and maybe I am a slow typist)…

=B7         What happens if ther= e is a conflict between DO_NOT_FRAGMENT and “must fragment if bigger = than x”? Is the bundle sent whole, trapped, or deleted?

=A7  And now - the suggested BIBE is another good ap= proach

o   If this particular = scenario might impact other folks as well and the consensus is to handle it= then a refinement would be to use the <block type> to hold the fragm= ent offset so that a further fragmented fragment could be more reliably rec= onstituted and BAB verified. I “think” this would make the BAB = “SBSP_hop - to - SBSP_hop” regardless of the compliance of any = intervening nodes.

 

 <= /span>

 

= --_000_329D879C76FDD04AAAE84BB1D89B3970094FFC4BD5aplesfreedomd_-- From nobody Tue Jun 3 13:06:11 2014 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4771A026B for ; Tue, 3 Jun 2014 13:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.25 X-Spam-Level: X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVx65RGmpQML for ; Tue, 3 Jun 2014 13:06:03 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 615111A008D for ; Tue, 3 Jun 2014 13:06:03 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B456B1F0361; Tue, 3 Jun 2014 16:05:57 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 91CBF1F0525; Tue, 3 Jun 2014 16:05:57 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.73]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 16:05:57 -0400 From: "Scott, Keith L." To: "Birrane, Edward J." , "dtn-security@irtf.org" Thread-Topic: Updated SBSP Document - BAB Thread-Index: Ac9+bH1OvS/DGr4rQCGazJjgMCXvZgA7MfsQAAI18LAAASfjYAAAHqyw Date: Tue, 3 Jun 2014 20:05:57 +0000 Message-ID: <5EE81C5C4CFFF4418C5EAD12F49D64EE4C222384@IMCMBX01.MITRE.ORG> References: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D8E29@NDMSMBX404.ndc.nasa.gov> <329D879C76FDD04AAAE84BB1D89B3970094FBFAAC8@aplesfreedom.dom1.jhuapl.edu> <329D879C76FDD04AAAE84BB1D89B3970094FFC4BD5@aplesfreedom.dom1.jhuapl.edu> In-Reply-To: <329D879C76FDD04AAAE84BB1D89B3970094FFC4BD5@aplesfreedom.dom1.jhuapl.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.140.19.249] Content-Type: multipart/alternative; boundary="_000_5EE81C5C4CFFF4418C5EAD12F49D64EE4C222384IMCMBX01MITREOR_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/Ogh_RKhtd75UBG5tHqg3Ehl2nAU Subject: Re: [dtn-security] Updated SBSP Document - BAB X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 20:06:09 -0000 --_000_5EE81C5C4CFFF4418C5EAD12F49D64EE4C222384IMCMBX01MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable yup From: dtn-security [mailto:dtn-security-bounces@irtf.org] On Behalf Of Birr= ane, Edward J. Sent: Tuesday, June 03, 2014 4:05 PM To: dtn-security@irtf.org Subject: Re: [dtn-security] Updated SBSP Document - BAB Scott, Excellent point. I had forgotten that there was such a flag, and I think = that this captures the desired behavior nicely. The BAB is defined between= two BP nodes, and if there is a non-security-aware BP node between two sec= urity-aware-nodes, that breaks the single-bp-hop nature of the BAB, and a B= IB should be used instead. Policy should then generate necessary reporting messages. -Ed --- Ed Birrane Principal Professional Staff, Space Department Johns Hopkins Applied Physics Laboratory (W) 443-778-7423 / (F) 443-228-3839 From: Burleigh, Scott C (312G) [mailto:scott.c.burleigh@jpl.nasa.gov] Sent: Tuesday, June 03, 2014 3:38 PM To: Birrane, Edward J.; dtn-security@irtf.org Subject: RE: Updated SBSP Document - BAB Ed, I like (A) but I think there's a possible problem. Because the flag wa= s set to protect the BAB operation, it really ought to be re-set to its ori= ginal value upon reception by the next BAB-aware node. But we don't have a= ny way of knowing what value to reset it to - that is, the flag might have = already been set by another node for some other reason (in which case it sh= ouldn't be set to zero now), or it might not have been (in which case it sh= ould). How about instead always setting the "Delete bundle if block can't be proce= ssed" flag in the BAB, to drive out the network misconfigurations? Scott From: dtn-security [mailto:dtn-security-bounces@irtf.org] On Behalf Of Birr= ane, Edward J. Sent: Tuesday, June 03, 2014 12:24 PM To: dtn-security@irtf.org Subject: Re: [dtn-security] Updated SBSP Document - BAB Dave, Thank you for fragmenting the discussion into separate threads; it is muc= h easier to parse this way. I recommend the following: - It is the intention that when adding a BAB, the next BP hop for the bundl= e is a security-aware node, but this cannot be guaranteed (e.g., there may = be a misconfiguration in the network). The language in the spec should be u= pdated to reflect this. We should do one (not both) of the following: A: When adding a BAB to a bundle, ensure that the bundle's "Bundle must not= be fragmented" field is set. This will result in a delivery failure if the= next BP-hop is unable to deliver the bundle as-is, but also ensures there = is no payload surgery between BP-hops that require BAB authentication. B: Use the content range for the ciphersuite parameters to identify the off= set,length of the bundle being protected. Then, require BPAs to wait until = all fragments of a bundle are received, and then do the authentication chec= k. My preference is to do "A". It is simple and strict when requiring authenti= cation, as should be the case with authentication. My concern regarding approach "B" is that we have to use up memory and othe= r resources for partial bundles. Part of the job of authentication is to pr= event some types of resource attacks on the network, and "B" seems to re-en= able some of those attacks. -Ed --- Ed Birrane Principal Professional Staff, Space Department Johns Hopkins Applied Physics Laboratory (W) 443-778-7423 / (F) 443-228-3839 From: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] [mailto:david.a.= zoller@nasa.gov] Sent: Monday, June 02, 2014 1:07 PM To: Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]; Birrane, Edwar= d J.; dtn-security@irtf.org Subject: RE: Updated SBSP Document - BAB [Page 12] 2.4 Bundle Authentication Block The security-target MUST be the entire bundle, which MUST be represented by a of <0x00><0x00>. * Per 3.4 Bundle Fragmentation and Reassembly, bundle authentication = may be applied to bundle fragments as well as non-fragmented bundles. * If a bundle fragment is received that has a BAB, there is no way to= determine if the BAB applies to the bundle fragment or if it applies to an= entire bundle that was later fragmented by a non-security-aware BA. o I propose that a of <0x00> indicate that the BAB applies to a bundle fragment * If such a bundle fragment is further fragmented by a non-security-= aware BA then the can be used to determine that the o= riginal fragmented bundle must be reassembled before authentication is chec= ked because it will not match the length field in the payload block. o Some discussion may be desirable in section 3.4 as well as 2.4 if accep= ted ? When a BAB is attached to a bundle that is a fragment, the bundle that i= t applies to is always that fragment, never the bundle that carried the ori= ginal payload (of which the current bundle's payload is a fragment). Since= BABs are not end-to-end, the BAB for an original un-fragmented bundle will= never be carried forward in any fragments generated from that bundle (see = the last paragraph of 3.3.1), so there's no ambiguity. But this does bring= up an important point: the block processing control flags of the BAB must = always have the "replicate in every fragment" flag set to 0. Maybe I'm misunderstanding here, but fragmentation can happen between a BAB= source and a BAB dest if a non-security aware node is between the two. Re= quiring the "DO_NOT_FRAGMENT" flag solves this. >> I see what you're saying, and I think it goes to the lament in= your next comment: the interaction between fragmentation and BSP really is= a mess. But I thought SBSP simplified things somewhat by not allowing any= non-security-aware nodes between the BAB source and BAB destination. At l= east, that's what I hoped we were doing, and it's how I interpret "BABs ope= rate between topologically adjacent nodes" on page 6. If that's not the ca= se then I think there are additional problems to resolve. BABs should be applied 'point-to-point' between bundle agents; there should= n't be an opportunity for a non-security-aware node to fragment a bundle wi= th a BAB on it. I'll have to check the cross-product between encapsulation= and BAB (i.e. whether you can encapsulate a bundle with a BAB on it (and t= hen possibly fragment the encapsulating bundle) or not). I suspect that th= e answer is 'no' (i.e. you check / remove the BAB immediately on receipt an= d before you encapsulate and/or fragment for transmission). ? There isn't really any accepted spec to consult on encapsulation, but wit= hin the concept that I've been working with (https://datatracker.ietf.org/d= oc/draft-irtf-burleigh-bibe/) the encapsulation protocol is a convergence-l= ayer adapter. In that case, the entire, complete outbound bundle - includi= ng any BAB that was attached at the last moment before serialization for th= e CLA - would become the payload of the new encapsulating bundle. The enca= psulating bundle might or might not be security-aware, but that doesn't mat= ter. The destination of the encapsulating bundle would extract the encapsu= lated bundle (the "outer" bundle's payload) and simulate reception of that = bundle, which would still have its BAB. That bundle would, in effect, have= traversed only a single hop (direct transmission between sender and receiv= er at the convergence layer), so there was no intervening non-security-awar= e forwarding node between the sending node that attached the BAB and the re= ceiving node that would validate it. So no opportunity for fragmentation, = no problem. Having outgoing email issues so some of this is now late and could be later= by the time it gets through - if it gets there. o This is true when all traversed nodes are SBSP compliant and we probabl= y do not want to overly complicate SBSP trying to anticipate and handle all= possible off-nominal scenarios. One of the off-nominal scenarios that I wo= uld not be surprised to see with the Space Station is the case where our ga= teway nodes are running pre-SBSP software and a payload developer installs = a cutting edge SBSP implementation. In this scenario, if the payload node a= pplies a BAB to a large bundle [or fragment] then there is the possibility = that the pre-SBSP gateway node will fragment [or further fragment] the bund= le and not remove the BAB resulting in its misinterpretation when it makes = to the end node that is SBSP compliant. o I am okay with not specifically handling this scenario as we can recomm= end not using the BAB until the gateway nodes are updated to SBSP complianc= e or that their local policy set the 'Discard block if it can't be processe= d' flag on the BAB. ? Amy mentioned the DO_NOT_FRAGMENT" flag as another possible option befor= e I could send this reply due to system and email issues (and maybe I am a = slow typist)... * What happens if there is a conflict between DO_NOT_FRAGMENT and "m= ust fragment if bigger than x"? Is the bundle sent whole, trapped, or delet= ed? ? And now - the suggested BIBE is another good approach o If this particular scenario might impact other folks as well and the co= nsensus is to handle it then a refinement would be to use the = to hold the fragment offset so that a further fragmented fragment could be = more reliably reconstituted and BAB verified. I "think" this would make the= BAB "SBSP_hop - to - SBSP_hop" regardless of the compliance of any interve= ning nodes. --_000_5EE81C5C4CFFF4418C5EAD12F49D64EE4C222384IMCMBX01MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

yup

=  

From: dtn-security= [mailto:dtn-security-bounces@irtf.org] On Behalf Of Birrane, Edward J.
Sent: Tuesday, June 03, 2014 4:05 PM
To: dtn-security@irtf.org
Subject: Re: [dtn-security] Updated SBSP Document - BAB

 

Scott,

 

  Excellent point. I had forgotten that there was such a flag, an= d I think that this captures the desired behavior nicely.  The BAB is = defined between two BP nodes, and if there is a non-security-aware BP node between two security-aware-nodes, that breaks t= he single-bp-hop nature of the BAB, and a BIB should  be used instead.=

 

  Policy should then generate necessary reporting messages.<= /o:p>

 

-Ed

 

---
Ed Birrane

Principal Professional Staff, Space Department
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839
 

 

From: Burleigh, Scott C (312G) [mailto:scott.c.burleigh@jpl.nasa.gov]
Sent: Tuesday, June 03, 2014 3:38 PM
To: Birrane, Edward J.; dtn= -security@irtf.org
Subject: RE: Updated SBSP Document - BAB

 

Ed, I like (A) but I think there’s a possible problem.  Bec= ause the flag was set to protect the BAB operation, it really ought to be r= e-set to its original value upon reception by the next BAB-aware node.  But we don’t have any way of knowing what= value to reset it to – that is, the flag might have already been set= by another node for some other reason (in which case it shouldn’t be= set to zero now), or it might not have been (in which case it should).

 

How about instead always setting the “Delete bundle if block can= ’t be processed” flag in the BAB, to drive out the network misc= onfigurations?

 

Scott

 

From: dtn-security [mailto:dtn-security-bounces@irtf.org] On Behalf Of Birrane, Edward J.
Sent: Tuesday, June 03, 2014 12:24 PM
To: dtn-security@irtf.org
Subject: Re: [dtn-security] Updated SBSP Document - BAB

 

Dave,

 

  Thank you for fragmenting the discussion into separate threads;= it is much easier to parse this way. 

 

I recommend the following:

 

- It is the intention that when adding a BAB, the next BP hop for the = bundle is a security-aware node, but this cannot be guaranteed (e.g., there= may be a misconfiguration in the network). The language in the spec should be updated to reflect this.

 

We should do one (not both) of the following:

 

A: When adding a BAB to a bundle, ensure that the bundle’s ̶= 0;Bundle must not be fragmented” field is set. This will result in a = delivery failure if the next BP-hop is unable to deliver the bundle as-is, but also ensures there is no payload surgery between BP-= hops that require BAB authentication.

 

B: Use the content range for the ciphersuite parameters to identify th= e offset,length of the bundle being protected. Then, require BPAs to wait u= ntil all fragments of a bundle are received, and then do the authentication check.

 

My preference is to do “A”. It is simple and strict when r= equiring authentication, as should be the case with authentication.

 

My concern regarding approach “B” is that we have to use u= p memory and other resources for partial bundles. Part of the job of authen= tication is to prevent some types of resource attacks on the network, and “B” seems to re-enable some of those attac= ks.

 

-Ed

 

---
Ed Birrane

Principal Professional Staff, Space Department
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839
 

 

From: Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] [mailto:david.a.zoller@nasa.gov= ]
Sent: Monday, June 02, 2014 1:07 PM
To: Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]; Birrane= , Edward J.; dtn-security@irtf.org
Subject: RE: Updated SBSP Document - BAB

 

<DZ><= /b>

[Page 12] 2.4 Bundle A= uthentication Block

The security-target MUST be the entire bundle, w= hich MUST be

represented by a <block type><occurrenc= e number> of <0x00><0x00>.

·       Per 3.4 Bundle= Fragmentation and Reassembly, bundle authentication may be applied to bund= le fragments as well as non-fragmented bundles.

·       If a bundle fr= agment is received that has a BAB, there is no way to determine if the BAB = applies to the bundle fragment or if it applies to an entire bundle that wa= s later fragmented by a non-security-aware BA.

o   I propose that= a <block type><occurrence number> of <0x00><payload f= rag length> indicate that the BAB applies to a bundle fragment

·        If such a bund= le fragment is further fragmented by a non-security-aware BA then the <p= ayload frag length> can be used to determine that the original fragmente= d bundle must be reassembled before authentication is checked because it will not match the length field in the payload block= .

o   Some discussio= n may be desirable in section 3.4 as well as 2.4 if accepted

= <SB>

Ø  When a BAB is = attached to a bundle that is a fragment, the bundle that it applies to is a= lways that fragment, never the bundle that carried the original payload (of= which the current bundle’s payload is a fragment).  Since BABs are not end-to-end, the BAB for an origin= al un-fragmented bundle will never be carried forward in any fragments gene= rated from that bundle (see the last paragraph of 3.3.1), so there’s = no ambiguity.  But this does bring up an important point: the block processing control flags of the BAB must always have the = “replicate in every fragment” flag set to 0.<= /p>

 

<AA><= /b>

Maybe I'm misunderstandin= g here, but fragmentation can happen between a BAB source and a BAB dest if= a non-security aware node is between the two.  Requiring the "DO= _NOT_FRAGMENT" flag solves this.  

 

<SB>

>>           I= see what you’re saying, and I think it goes to the lament in your ne= xt comment: the interaction between fragmentation and BSP really is a mess.=   But I thought SBSP simplified things somewhat by not allowing any non-security-aware nodes between the B= AB source and BAB destination.  At least, that’s what I hoped we= were doing, and it’s how I interpret “BABs operate between topologically adjacent nodes” o= n page 6.  If that’s not the case then I think there are additio= nal problems to resolve.

 

<KS>

BABs should be applied ‘point-to-point’ b= etween bundle agents; there shouldn’t be an opportunity for a non-sec= urity-aware node to fragment a bundle with a BAB on it.  I’ll have to check the cross-product between encapsulation and BAB (= i.e. whether you can encapsulate a bundle with a BAB on it (and then possib= ly fragment the encapsulating bundle) or not).  I suspect that the ans= wer is ‘no’ (i.e. you check / remove the BAB immediately on receipt and before you encapsulate and/or fragment for tran= smission).

 

<SB>

Ø There isn’t really any accepted spec to consult on encapsulation, = but within the concept that I’ve been working with (https://datatracker.i= etf.org/doc/draft-irtf-burleigh-bibe/) the encapsulation protocol is a convergence-layer adapter.  In that c= ase, the entire, complete outbound bundle – including any BAB that wa= s attached at the last moment before serialization for the CLA – woul= d become the payload of the new encapsulating bundle.  The encapsulating bundle might or might not be security-aware, but that do= esn’t matter.  The destination of the encapsulating bundle would= extract the encapsulated bundle (the “outer” bundle’s pa= yload) and simulate reception of that bundle, which would still have its BAB.  That bundle would, in effect, have traversed only a si= ngle hop (direct transmission between sender and receiver at the convergenc= e layer), so there was no intervening non-security-aware forwarding node be= tween the sending node that attached the BAB and the receiving node that would validate it.  So no opportu= nity for fragmentation, no problem.

&nb= sp;

 

<DZ>

Having outgoing email issues so some of this is now late and could be = later by the time it gets through – if it gets there.

o   This is true w= hen all traversed nodes are SBSP compliant and we probably do not want to o= verly complicate SBSP trying to anticipate and handle all possible off-nomi= nal scenarios. One of the off-nominal scenarios that I would not be surprised to see with the Space Station is t= he case where our gateway nodes are running pre-SBSP software and a payload= developer installs a cutting edge SBSP implementation. In this scenario, i= f the payload node applies a BAB to a large bundle [or fragment] then there is the possibility that the pre= -SBSP gateway node will fragment [or further fragment] the bundle and not r= emove the BAB resulting in its misinterpretation when it makes to the end n= ode that is SBSP compliant.

o   I am okay with= not specifically handling this scenario as we can recommend not using the = BAB until the gateway nodes are updated to SBSP compliance or that their lo= cal policy set the ‘Discard block if it can’t be processed’ flag on the BAB.

§  Amy mentioned = the DO_NOT_FRAGMENT” flag as another possible option before I could s= end this reply due to system and email issues (and maybe I am a slow typist= )…

·        What happens i= f there is a conflict between DO_NOT_FRAGMENT and “must fragment if b= igger than x”? Is the bundle sent whole, trapped, or deleted?

§  And now - the = suggested BIBE is another good approach

o   If this partic= ular scenario might impact other folks as well and the consensus is to hand= le it then a refinement would be to use the <block type> to hold the = fragment offset so that a further fragmented fragment could be more reliably reconstituted and BAB verified. I “t= hink” this would make the BAB “SBSP_hop - to - SBSP_hop” = regardless of the compliance of any intervening nodes.

 

 

 

--_000_5EE81C5C4CFFF4418C5EAD12F49D64EE4C222384IMCMBX01MITREOR_--