From nobody Sun Nov 1 22:02:54 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4473A0DCF for ; Sun, 1 Nov 2020 22:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5VuW0cDzyLo for ; Sun, 1 Nov 2020 22:02:41 -0800 (PST) Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 483773A0DDC for ; Sun, 1 Nov 2020 22:02:41 -0800 (PST) Received: by mail-qk1-x743.google.com with SMTP id a64so7274124qkc.5 for ; Sun, 01 Nov 2020 22:02:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pf74MjAF4rxypfS2bsxzUgARUpPF+ZliKzRx7ucAhJ4=; b=LIhZBE1sQoM28JSxDn8OpHJdke058FfE34jLgsMlZ1jK8Dn4azx99mNQ2YzEcjMWfC 1ekGKaKkZpdlstxQvyJUbj0e3DeklOeWcxaX4er77f/F/jlFJshHXGf4DBRm1LersrGp nulhkXFhwFCAN+900tgkG9hDXSa/86204+sEqVtjuUgWfbP7ytKRilyE0WOopRpqAwL4 DEohvBm4PL0k+tQtrmjxLg3W3dQup1KEuh0N5m/H/nixWsJkRAa4Wzl5voySfzUOs++0 aJpMKYCdl6AdxOlZ3yCRULZNMEVkYYjAV/arOwa113TuWw6avaNGGMTQMt4bZ9X863bz tzhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pf74MjAF4rxypfS2bsxzUgARUpPF+ZliKzRx7ucAhJ4=; b=jk07UcJglCw8Zfgcr+vO8am8PgBhs0CQqBWXPLrNbpAnvotl59eNgI3WBYZIDqU0Zh UxuS/HCOQvGzZo7dlh61iI4W3pHK/yptlqSHsOXJKAA7N874m04lypO753k5k0GIvqCF tlNA2x2JbrP5Tr3F9wZYgbKEPmiDzF2uDsm655qQ5neFIxwf6Sg2DHbTB/SrYFcKh8Oq XLEDFoY5x9GeMogv36G7UTQaT6zPtxyBQzKrYYBKaEnB1KdasMNGmIiK3QEEG9LOx6v0 ixbJzZJsvu/elURijLI7qUYLLh+eWAc96b01JjsMyzAdPTydbeNtk+MFUJNVgGTSNPV9 TPKw== X-Gm-Message-State: AOAM531UNlBEYGBTcSNzrvxfjluU+uEHYY5qIHJphkgZuhRvEcBwCwQ1 A+fN0EA3c0TAiCQH7bTKemYp37ejF/qWI4i97x98/g== X-Google-Smtp-Source: ABdhPJxJCBQToA7IRN99XpqLKmQX6uCnQUN/4JF0DMGw9BJRkgxQ/m3GQ/y+A4edO1j1Vkb8LiVa+Oet242Z3f+Ewtg= X-Received: by 2002:a37:76c7:: with SMTP id r190mr13080871qkc.416.1604296960184; Sun, 01 Nov 2020 22:02:40 -0800 (PST) MIME-Version: 1.0 References: <160381954432.30121.9559007698502161410@ietfa.amsl.com> In-Reply-To: From: Joseph Salowey Date: Sun, 1 Nov 2020 22:02:29 -0800 Message-ID: To: Brian E Carpenter , secdir Cc: last-call@ietf.org, anima@ietf.org, draft-ietf-anima-grasp-api.all@ietf.org Content-Type: multipart/alternative; boundary="0000000000006d27f005b3197ecd" Archived-At: Subject: [secdir] Fwd: Secdir last call review of draft-ietf-anima-grasp-api-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 06:02:52 -0000 --0000000000006d27f005b3197ecd Content-Type: text/plain; charset="UTF-8" (Forwarding my response to the rest of the audience) Hi Brian, Thanks for the quick response, additional questions and comments inline below: On Tue, Oct 27, 2020 at 6:58 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Hi Joseph, > > Thanks for the review. Comments in line... > > On 28-Oct-20 06:25, Joseph Salowey via Datatracker wrote: > > Reviewer: Joseph Salowey > > Review result: Has Issues > > > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs should treat > > these comments just like any other last call comments. > > > > The summary of the review is Has issues. The document does needs a bit > more > > discussion of the security implications. > > > > 1. Authorization > > > > In the security considerations section the document says that > authorization is > > left for future work. I would expect that the section should at least > describe > > what the implications of no authorizations are. > > This isn't really an issue for the API itself, but for the underlying > protocol > and for the ANIMA ecosystem. It's an issue that the WG explicitly deferred > (and it's now a chartered work item). Let me quote here what the GRASP spec > says in its security considerations: > > >> - Authorization and Roles > >> > >> The GRASP protocol is agnostic about the roles and capabilities of > >> individual ASAs and about which objectives a particular ASA is > >> authorized to support. An implementation might support > >> precautions such as allowing only one ASA in a given node to > >> modify a given objective, but this may not be appropriate in all > >> cases. For example, it might be operationally useful to allow an > >> old and a new version of the same ASA to run simultaneously during > >> an overlap period. These questions are out of scope for the > >> present specification. > > and what draft-carpenter-anima-asa-guidelines says: > > >> Authorization of ASAs is a subject for future study. At present, ASAs > are trusted by virtue of being installed on a node that has successfully > joined the ACP. In the general case, a node may have mutltiple roles and a > role may use multiple ASAs, each using multiple GRASP objectives. > Additional mechanisms for the authorization of nodes and ASAs to manipulate > specific GRASP objectives could be designed. > > That draft is on the verge of WG adoption. The point is that the current > trust model is that we trust any node that has successfully joined the ACP, > and therefore we trust any ASA in such a node. We should state that clearly > in the text. > > IMHO it would be out of scope for the API to say more but we should add a > reference to the GRASP Security Considerations. > What risks are not being > > mitigated? What modes of operations should not be used? > > Those are good questions for the WG to look at. > > [Joe] These are the sort of things I would expect to be described in the security considerations. I'm trying to get my bearing in what the current model is here. In particular it seems that any security is applied at the "ACP". What is the relationship of an ASA to an ACP node? Does the ACP provide a security guarantee that it will send a message to the correct ASA running on the correct system? Does it ensure that a message received was sent by the correct system? I couldn't find these answers in the security considerations of ACP, GRASP or GRASP API. > > In general leaving > > security items out suggests that the work is not ready for wide > deployment. > > Perhaps this is OK because the work is informational, but the document > should > > probably say this. > > > Personally I don't think we have left a hole here, because there's a > well-defined > trust boundary, but we should indeed state that as well as citing the > GRASP spec's > security considerations. > > [Joe] Yes please, defining the trust model would help. > > > > 2. Authentication > > > > Section 2.3.1.4 discusses the ASA_locator. How is is the entity > accessed by > > the locator authenticated? How does the caller of the API know they are > > talking to the right entity? I don't see any discussion of this in this > > document and there is very little in draft-ietf-anima-grasp-15 on this. > Is > > there a section in one of these documents I should be looking for? > > No, you're not missing anything. The trust boundary is the ACP, and that > takes > us back to the previous point. If we do decide that we need a fine-grained > trust model inside the ACP, we'll presumably need to extend GRASP itself > to add some form of authentication option beyond what GRASP over TLS can > provide. > > [Joe] From my understanding the ASA_locator is referencing a remote system that the caller of the API is going to interact with. If this is true then there must be some way for the local system to make sure that the identity of the remote system is indeed the same entity they reference in the API. I would expect somewhere in one of the specifications that there needs to be some mapping between the name specified API and the name authenticated in TLS (typically in the subjectAlternativeName in a certificate), but it could be established in other ways. > > > > 3. ASA_Nonce > > > > The ASA nonce is described as a security mechanism. It is only 4 bytes > long. > > This seems short, making the ASA_Nonce vulnerable to collisions. Why is > this > > not a problem? > > This isn't used on the wire, just locally within the GRASP instance, > so collisions can be excluded. > > [Joe] OK, thanks. > > How long is the ASA nonce supposed to be valid? How often does > registration > > happen? > > At the moment, there is no sensible answer to those questions. When we > develop > the authorization model, we'd definitely have to answer those questions > and maybe > the nonce would have to be replaced by a crypto object. > > [Joe] OK. > > > > 4. Session Nonce > > > > Are there security implications of revealing the session nonce to the > caller as > > suggested in section 2.3.1.7? Could it allow for the ASA to bypass > > authorization if it knows this value? Perhaps forming the nonce from > the > > underlying session ID is not the best guidance? Also it seems the > underlying > > protocol session ID is only 4 bytes and collisions are likely and may be > a > > problem for the protocol. > > No, the collision risk is avoided because the session nonce includes the > ACP IPv6 address of the session originator. We should explain that > more clearly. > > [Joe] I still have the question of whether the nonce should be revealed to the API caller or left internal to the implementation. > > > > 5. Error Codes > > > > In general, the list of API codes in the appendix is not described in > the API. > > It seems they should be. Some of the error codes seem related to > > authorization, which is out of scope? > > Our hope was the the WG could move faster on that topic, but the > incredible delays on BRSKI and the ACP made that impossible. > Our idea is certainly that register_asa() and register_objective() > should include authorization in the longer term. > > [Joe] I think it would be helpful for the API spec to list the valid error codes for each call. > > It seems that some of the error code could lead to disclosure of > information, > > for example: > > > > notYourASA 7 "ASA registered but not by you" might reveal a valid > nonce > > from an invalid nonce > > Hmm... I don't think so. Let me glance at the code... > > The only place where I found that error code useful was in deregister_asa() > and that doesn't return anything else. It could be used in an exhaustive > search attack to deregister an ASA, but in the current trust model that > doesn't seem like a significant risk. > > > > > 6. Denial of service > > > > are there protections in the underlying protocol for denial of service > with > > respect to Flood(), Synchronize() or any other method? > > There are recommendations about rate throttling for relaying GRASP Flood > and > Discover multicasts, which should confine any multicast abuse to a single > link-layer segment. That's one good reason for using link-layer multicast > only. > We also have recommendations for exponential backoff in the GRASP spec, but > of course a malicious sender could ignore those. In any case we can put a > specific pointer to that subsection of the GRASP Security Considerations. > > DoS against the Negotiate or Synchronize parts of GRASP seems to be like > any other client/server protocol. I'm not sure what we can say in the > API spec about that. In my implementation (which is not intended to be > production quality) I've simply put finite queues for all the request > handlers, with silent discard if the queue overflows. > > We'll collate updates to all reviews after the LC expires. > > [Joe] OK thanks. > Thanks again > Brian > > > > --0000000000006d27f005b3197ecd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Forwarding my response=C2=A0to the rest of the audience)<= div class=3D"gmail_quote">
Hi Brian,=C2=A0

Thanks for the quick response,=C2=A0 additional questions= and comments inline below:

On Tue, Oct 27, 2020 at 6:58 PM Brian E Carpente= r <bria= n.e.carpenter@gmail.com> wrote:
Hi Joseph,

Thanks for the review. Comments in line...

On 28-Oct-20 06:25, Joseph Salowey via Datatracker wrote:
> Reviewer: Joseph Salowey
> Review result: Has Issues
>
> I have reviewed this document as part of the security directorate'= s
> ongoing effort to review all IETF documents being processed by the
> IESG.=C2=A0 These comments were written primarily for the benefit of t= he
> security area directors.=C2=A0 Document editors and WG chairs should t= reat
> these comments just like any other last call comments.
>
> The summary of the review is Has issues.=C2=A0 The document does needs= a bit more
> discussion of the security implications.
>
> 1. Authorization
>
> In the security considerations section the document says that authoriz= ation is
> left for future work.=C2=A0 I would expect that the section should at = least describe
> what the implications of no authorizations are.

This isn't really an issue for the API itself, but for the underlying p= rotocol
and for the ANIMA ecosystem. It's an issue that the WG explicitly defer= red
(and it's now a chartered work item). Let me quote here what the GRASP = spec
says in its security considerations:

>>=C2=A0 =C2=A0 - Authorization and Roles
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0The GRASP protocol is agnostic about the= roles and capabilities of
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0individual ASAs and about which objectiv= es a particular ASA is
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0authorized to support.=C2=A0 An implemen= tation might support
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0precautions such as allowing only one AS= A in a given node to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0modify a given objective, but this may n= ot be appropriate in all
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0cases.=C2=A0 For example, it might be op= erationally useful to allow an
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0old and a new version of the same ASA to= run simultaneously during
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0an overlap period.=C2=A0 These questions= are out of scope for the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0present specification.

and what draft-carpenter-anima-asa-guidelines says:

>> Authorization of ASAs is a subject for future study. At present, A= SAs are trusted by virtue of being installed on a node that has successfull= y joined the ACP. In the general case, a node may have mutltiple roles and = a role may use multiple ASAs, each using multiple GRASP objectives. Additio= nal mechanisms for the authorization of nodes and ASAs to manipulate specif= ic GRASP objectives could be designed.

That draft is on the verge of WG adoption. The point is that the current trust model is that we trust any node that has successfully joined the ACP,=
and therefore we trust any ASA in such a node. We should state that clearly=
in the text.

IMHO it would be out of scope for the API to say more but we should add a reference to the GRASP Security Considerations.=C2=A0
> What risks are not being
> mitigated?=C2=A0 =C2=A0What modes of operations should not be used?
Those are good questions for the WG to look at.


[Joe] These are the sort of things I w= ould expect to be described in the security considerations.=C2=A0=C2=A0

I'm trying to get my bearing in what the current = model is here.=C2=A0 In particular=C2=A0it seems that any security is appli= ed at the "ACP".=C2=A0 What is the relationship of an ASA to an A= CP node?=C2=A0 =C2=A0

Does the ACP provide a secur= ity guarantee=C2=A0that it will send a message to the correct ASA running o= n the correct system?=C2=A0 Does it ensure that a message received was sent= by the correct system?=C2=A0 I couldn't find these answers in the secu= rity considerations of ACP, GRASP or GRASP API.=C2=A0=C2=A0
=C2= =A0
> In general leaving
> security items out suggests that the work is not ready for wide deploy= ment.
> Perhaps this is OK because the work is informational, but the document= should
> probably say this.


Personally I don't think we have left a hole here, because there's = a well-defined
trust boundary, but we should indeed state that as well as citing the GRASP= spec's
security considerations.

[Joe] Yes please,=C2=A0 defining the trust model woul= d help.=C2=A0=C2=A0
=C2=A0
>
> 2. Authentication
>
> Section 2.3.1.4 discusses the ASA_locator.=C2=A0 How is is the entity = accessed by
> the locator authenticated?=C2=A0 How does the caller of the API know t= hey are
> talking to the right entity?=C2=A0 I don't see any discussion of t= his in this
> document and there is very little in draft-ietf-anima-grasp-15 on this= .=C2=A0 =C2=A0 Is
> there a section in one of these documents I should be looking for?

No, you're not missing anything. The trust boundary is the ACP, and tha= t takes
us back to the previous point. If we do decide that we need a fine-grained<= br> trust model inside the ACP, we'll presumably need to extend GRASP itsel= f
to add some form of authentication option beyond what GRASP over TLS can provide.

[Joe] From my understanding the ASA_locator is refere= ncing a remote system that the caller of the API is going to interact with.= If this is true then there must be some way for the local system to make s= ure that the identity of the remote system is indeed the same entity they r= eference in the API.=C2=A0 I would expect somewhere in one of the specifica= tions that there needs to be some mapping between the name specified API an= d the name authenticated in TLS (typically in the subjectAlternativeName in= a certificate), but it could be established in other ways.=C2=A0=C2=A0
=C2=A0
>
> 3. ASA_Nonce
>
> The ASA nonce is described as a security mechanism.=C2=A0 It is only 4= bytes long.
> This seems short, making the ASA_Nonce vulnerable to collisions.=C2=A0= Why is this
> not a problem?

This isn't used on the wire, just locally within the GRASP instance, so collisions can be excluded.

[Joe] OK, thanks.
=C2=A0
> How long is the ASA nonce supposed to be valid?=C2=A0 How often does r= egistration
> happen?

At the moment, there is no sensible answer to those questions. When we deve= lop
the authorization model, we'd definitely have to answer those questions= and maybe
the nonce would have to be replaced by a crypto object.

[Joe] OK.

=C2=A0
>
> 4. Session Nonce
>
> Are there security implications of revealing the session nonce to the = caller as
> suggested in section 2.3.1.7?=C2=A0 Could it allow for the ASA to bypa= ss
> authorization if it knows this value?=C2=A0 =C2=A0Perhaps forming the = nonce from the
> underlying session ID is not the best guidance?=C2=A0 Also it seems th= e underlying
> protocol session ID is only 4 bytes and collisions are likely and may = be a
> problem for the protocol.

No, the collision risk is avoided because the session nonce includes the ACP IPv6 address of the session originator. We should explain that
more clearly.

[Joe]=C2=A0 I still have the question of whether the = nonce should be revealed to the API caller or left internal to the implemen= tation.=C2=A0=C2=A0

=C2=A0
>
> 5. Error Codes
>
> In general, the list of API codes in the appendix is not described in = the API.
> It seems they should be.=C2=A0 Some of the error codes seem related to=
> authorization, which is out of scope?

Our hope was the the WG could move faster on that topic, but the
incredible delays on BRSKI and the ACP made that impossible.
Our idea is certainly that register_asa() and register_objective()
should include authorization in the longer term.


[Joe]=C2=A0 I think it would be helpfu= l for the API spec to list the valid error codes for each call.=C2=A0
=
=C2=A0
> It seems that some of the error code could lead to disclosure of infor= mation,
> for example:
>
> notYourASA=C2=A0 =C2=A0 =C2=A0 =C2=A07 "ASA registered but not by= you"=C2=A0 might reveal a valid nonce
> from an invalid nonce

Hmm... I don't think so. Let me glance at the code...

The only place where I found that error code useful was in deregister_asa()=
and that doesn't return anything else. It could be used in an exhaustiv= e
search attack to deregister an ASA, but in the current trust model that
doesn't seem like a significant risk.

>
> 6. Denial of service
>
> are there protections in the underlying protocol for denial of service= with
> respect to Flood(), Synchronize() or any other method?

There are recommendations about rate throttling for relaying GRASP Flood an= d
Discover multicasts, which should confine any multicast abuse to a single link-layer segment. That's one good reason for using link-layer multica= st only.
We also have recommendations for exponential backoff in the GRASP spec, but=
of course a malicious sender could ignore those. In any case we can put a specific pointer to that subsection of the GRASP Security Considerations.
DoS against the Negotiate or Synchronize parts of GRASP seems to be like any other client/server protocol. I'm not sure what we can say in the API spec about that. In my implementation (which is not intended to be
production quality) I've simply put finite queues for all the request handlers, with silent discard if the queue overflows.

We'll collate updates to all reviews after the LC expires.


[Joe] OK thanks.=C2=A0
=C2= =A0
Thanks again
=C2=A0 =C2=A0 Brian



--0000000000006d27f005b3197ecd-- From nobody Sun Nov 1 23:12:06 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDAF3A010D; Sun, 1 Nov 2020 23:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEeVJiCNZPIi; Sun, 1 Nov 2020 23:11:59 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AE903A011B; Sun, 1 Nov 2020 23:11:52 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 4CPkcR0pJCzyrJ; Mon, 2 Nov 2020 08:11:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1604301111; bh=0s3nb0msGoH23B6NkpLRfzCu+1a1prxcrPckyh2vjHo=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=N0WhyYL+8pqwyP2f4EGwAS/pIQNNBB3cBz7UAJUbfOhmIXe0a9FNIMi9PrRTDBfub 9Yyl0AxQvPY93dg546yYMYMYxdrNQpSV29fpRbqyKKheqESvHwaWf1Wob96AkvrBq2 A3HHEjpGD6C57UQAzpf+aAf9z/JJpCYOfNzWStEpS4GG8lJ5KJG/SmzlkDTAtgPnQq OdFzyt14V2IzENisnMaSy5nxIL+3l8WbzxBywCeIjWzQMXimNJHEtEU3FzJEi9GozT kNaLNGGOVMek1XnUtLOiR6xGWAYMbRFUFJiRY5eYHS+7ibz8D0HeU2ItKkNR0nV+5B 7UyLu0VFVS8zw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 4CPkcQ6Yzfz1xp6; Mon, 2 Nov 2020 08:11:50 +0100 (CET) From: To: Radia Perlman , "secdir@ietf.org" , The IESG , "draft-ietf-dots-signal-call-home.all@ietf.org" CC: "dots@ietf.org" Thread-Topic: secdir review of draft-ietf-dots-signal-call-home-11 Thread-Index: AQHWsAs2zOL8aGOcxU2IwIflkcf7vqm0bfwg Date: Mon, 2 Nov 2020 07:11:50 +0000 Message-ID: <17270_1604301110_5F9FB136_17270_253_1_787AE7BB302AE849A7480A190F8B93303156D1FE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303156D1FEOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-dots-signal-call-home-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 07:12:01 -0000 --_000_787AE7BB302AE849A7480A190F8B93303156D1FEOPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmFkaWEsDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJldmlldy4NCg0KRml4ZWQgdGhlIG5pdCBp biBteSBsb2NhbCBjb3B5Lg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBSYWRpYSBQZXJsbWFuIFtt YWlsdG86cmFkaWFwZXJsbWFuQGdtYWlsLmNvbV0NCkVudm95w6kgOiBkaW1hbmNoZSAxIG5vdmVt YnJlIDIwMjAgMDU6NTUNCsOAIDogc2VjZGlyQGlldGYub3JnOyBUaGUgSUVTRyA8aWVzZ0BpZXRm Lm9yZz47IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC1ob21lLmFsbEBpZXRmLm9yZw0KT2Jq ZXQgOiBzZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2FsbC1ob21lLTEx DQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5 IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50 cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0 ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3Rv cnMuICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNv bW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpJIGRpZG4n dCBmaW5kIGFueXRoaW5nIG9iamVjdGlvbmFibGUgZnJvbSBhIHNlY3VyaXR5IHBvaW50LW9mLXZp ZXcgaW4gdGhpcyBJLUQuDQoNCkRPVFMgaXMgYSBwcm90b2NvbCBmb3IgcmVwb3J0aW5nIGRlbmlh bCBvZiBzZXJ2aWNlIGF0dGFja3MgdG8gc29tZW9uZSBjbG9zZXIgdG8gdGhlIHNvdXJjZSB0aGFu IHlvdSBhcmUgaW4gaG9wZXMgdGhleSBjYW4gYmxvY2sgc3VjaCBhdHRhY2tzIGJlZm9yZSB0aGV5 IGhhdmUgd2FzdGVkIG1vcmUgbmV0d29yayBiYW5kd2lkdGguIFRoZSBhZ2VudCByZXBvcnRpbmcg dGhlIERvUyBpcyB0aGUgRE9UUyBjbGllbnQgYW5kIHRoZSBhZ2VudCByZWNlaXZpbmcgdGhlIHJl cG9ydCBpcyB0aGUgRE9UUyBzZXJ2ZXIuIFRoZSBET1RTIHByb3RvY29sIGlzIGRlc2NyaWJlZCBp biBvdGhlciBkb2N1bWVudHMuDQoNClRoZXJlIGlzIGEgc3BlY2lhbCBjYXNlIHdoZXJlIGEgRE9U UyBzZXJ2ZXIgaXMgcnVubmluZyBpbiBhICJob21lIiBuZXR3b3JrIHdoZXJlIGl0IGlzIGNhcGFi bGUgb2YgaW5pdGlhdGluZyBjb25uZWN0aW9ucyBidXQgbm90IHJlY2VpdmluZyBpbmNvbWluZyBv bmVzIGJlY2F1c2Ugb2YgTkFUIG9yIGZpcmV3YWxsLiBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSB2 YXJpYXRpb24gb2YgdGhlIERPVFMgcHJvdG9jb2wgZm9yIHN1Y2ggc2NlbmFyaW9zIHdoZXJlIHRo ZSBET1RTIHNlcnZlciBpbml0aWF0ZXMgdGhlIGNvbm5lY3Rpb24gdG8gdGhlIERPVFMgY2xpZW50 IGluIG9yZGVyIHRvIHJlY2VpdmUgbm90aWZpY2F0aW9ucyBvZiBEb1MgdHJhZmZpYyBvcmlnaW5h dGluZyBpbnNpZGUgdGhlIGZpcmV3YWxsZWQgbmV0d29yay4gU2luY2UgYXV0aGVudGljYXRpb24g dXNlcyBjbGllbnQgYW5kIHNlcnZlciBjZXJ0aWZpY2F0ZXMgd2l0aCBUTFMgb3IgRFRMUywgbGl0 dGxlIG5lZWRzIHRvIGJlIGNoYW5nZWQgdG8gc3VwcG9ydCB0aGlzIHJvbGUgcmV2ZXJzYWwuDQoN CkZvdW5kIG9uZSB0eXBvOg0KDQpTZWN0aW9uIDUuMy4yOiBkZXBpY3RlcyAtPiBkZXBpY3RzDQoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5p ciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUg ZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMg YXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZl dWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1 ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1 c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmls aXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJj aS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91 dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxp YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs c2lmaWVkLgpUaGFuayB5b3UuCgo= --_000_787AE7BB302AE849A7480A190F8B93303156D1FEOPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHls ZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44 NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBSYWRpYSwNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rIHlvdSBmb3IgdGhlIHJldmll dy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5GaXhl ZCB0aGUgbml0IGluIG15IGxvY2FsIGNvcHkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+TWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiBSYWRpYSBQZXJsbWFuIFttYWlsdG86cmFkaWFwZXJsbWFuQGdtYWlsLmNv bV0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBkaW1hbmNoZSAxIG5vdmVtYnJlIDIwMjAg MDU6NTU8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IHNlY2RpckBpZXRmLm9yZzsgVGhlIElFU0cgJmx0 O2llc2dAaWV0Zi5vcmcmZ3Q7OyBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNhbGwtaG9tZS5hbGxA aWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IHNlY2RpciByZXZpZXcgb2YgZHJhZnQt aWV0Zi1kb3RzLXNpZ25hbC1jYWxsLWhvbWUtMTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIGhhdmUgcmV2aWV3 ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9u Z29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2Vk IGJ5IHRoZSBJRVNHLiZuYnNwOyBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5 DQogZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4mbmJzcDsg RG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50 cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ SSBkaWRuJ3QgZmluZCBhbnl0aGluZyBvYmplY3Rpb25hYmxlIGZyb20gYSBzZWN1cml0eSBwb2lu dC1vZi12aWV3IGluIHRoaXMgSS1ELjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5ET1RTIGlzIGEgcHJvdG9jb2wg Zm9yIHJlcG9ydGluZyBkZW5pYWwgb2Ygc2VydmljZSBhdHRhY2tzIHRvIHNvbWVvbmUgY2xvc2Vy IHRvIHRoZSBzb3VyY2UgdGhhbiB5b3UgYXJlIGluIGhvcGVzIHRoZXkgY2FuIGJsb2NrIHN1Y2gg YXR0YWNrcyBiZWZvcmUgdGhleSBoYXZlIHdhc3RlZCBtb3JlIG5ldHdvcmsNCiBiYW5kd2lkdGgu IFRoZSBhZ2VudCByZXBvcnRpbmcgdGhlIERvUyBpcyB0aGUgRE9UUyBjbGllbnQgYW5kIHRoZSBh Z2VudCByZWNlaXZpbmcgdGhlIHJlcG9ydCBpcyB0aGUgRE9UUyBzZXJ2ZXIuIFRoZSBET1RTIHBy b3RvY29sIGlzIGRlc2NyaWJlZCBpbiBvdGhlciBkb2N1bWVudHMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRo ZXJlIGlzIGEgc3BlY2lhbCBjYXNlIHdoZXJlIGEgRE9UUyBzZXJ2ZXIgaXMgcnVubmluZyBpbiBh ICZxdW90O2hvbWUmcXVvdDsgbmV0d29yayB3aGVyZSBpdCBpcyBjYXBhYmxlIG9mIGluaXRpYXRp bmcgY29ubmVjdGlvbnMgYnV0IG5vdCByZWNlaXZpbmcgaW5jb21pbmcgb25lcyBiZWNhdXNlIG9m IE5BVCBvciBmaXJld2FsbC4NCiBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSB2YXJpYXRpb24gb2Yg dGhlIERPVFMgcHJvdG9jb2wgZm9yIHN1Y2ggc2NlbmFyaW9zIHdoZXJlIHRoZSBET1RTIHNlcnZl ciBpbml0aWF0ZXMgdGhlIGNvbm5lY3Rpb24gdG8gdGhlIERPVFMgY2xpZW50IGluIG9yZGVyIHRv IHJlY2VpdmUgbm90aWZpY2F0aW9ucyBvZiBEb1MgdHJhZmZpYyBvcmlnaW5hdGluZyBpbnNpZGUg dGhlIGZpcmV3YWxsZWQgbmV0d29yay4gU2luY2UgYXV0aGVudGljYXRpb24gdXNlcw0KIGNsaWVu dCBhbmQgc2VydmVyIGNlcnRpZmljYXRlcyB3aXRoIFRMUyBvciBEVExTLCBsaXR0bGUgbmVlZHMg dG8gYmUgY2hhbmdlZCB0byBzdXBwb3J0IHRoaXMgcm9sZSByZXZlcnNhbC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Rm91bmQgb25lIHR5cG86PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNlY3Rpb24gNS4zLjI6IGRlcGljdGVz IC0mZ3Q7IGRlcGljdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8UFJFPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZl bnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdp ZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNv cGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIg ZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWly ZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVl cyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSBy ZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxz aWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90 ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29w aWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jhbmdl IGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFu Z2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B93303156D1FEOPEXCAUBMA2corp_-- From nobody Sun Nov 1 23:42:32 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3463A0420; Sun, 1 Nov 2020 23:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org 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 16Xt0a_JgQcC; Sun, 1 Nov 2020 23:42:24 -0800 (PST) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD23F3A03F4; Sun, 1 Nov 2020 23:42:23 -0800 (PST) Received: from [IPv6:2a00:ac00:4000:400:e94b:bd9b:203d:fefb] (unknown [IPv6:2a00:ac00:4000:400:e94b:bd9b:203d:fefb]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 975856108BF; Mon, 2 Nov 2020 09:42:13 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1604302933; bh=4vCohUIleFQ4jAGxnZB0iQyb+vhyVBBQ7It7knzsTVw=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=iQbtJcF1dpxRWZcHTKOCYf5lMCMQ+ytLfmGhtGy3hq3DOuo2py5xvjLC9n8AlIoxb ZNOdJHhCjAI8GCI+ePYYb7CMlGt2l8No2UYASXPpSq9XZf7l428XZglz5TZOhEhtmy LtdptnQQDov4gebjbRHW20P50zQ2koucj5AfsMqI= From: Lars Eggert Message-Id: <91D914EE-0205-47E4-9A38-3978DD9E18F1@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_AA0E888B-B8E9-4154-A226-0FF6BC4E96C6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 2 Nov 2020 09:42:13 +0200 In-Reply-To: Cc: secdir@ietf.org, The IESG , draft-ietf-quic-tls.all@ietf.org, IETF QUIC WG To: Radia Perlman References: X-MailScanner-ID: 975856108BF.A1EAB X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-quic-tls-48 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 07:42:26 -0000 --Apple-Mail=_AA0E888B-B8E9-4154-A226-0FF6BC4E96C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Radia, thank you for the review. I've opened a GitHub issue for any discussion = related to this review: = https://github.com/quicwg/base-drafts/issues/4323 There is also a milestone at = https://github.com/quicwg/base-drafts/milestone/7. Thanks, Lars > On 2020-11-1, at 4:40, Radia Perlman wrote: >=20 > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >=20 > This document specifies the cryptographic exchanges and formats = associated with the QUIC protocol, which in turn is an ambitious = protocol that could over time replace TCP. quic-transport, quic-tls, and = quic-recovery represent a triple of I-Ds that are always used together = and could be combined into a single spec, though the length of the = existing specs is already daunting. In many cases, it is impossible to = evaluate them independently. >=20 > As an interested outsider, I see these protocols as exceptionally well = designed and the specs exceptionally well written. I could not find even = any nits in a very long spec. >=20 > It is misleading to regard this as a specification of running QUIC = over TLS. It is related to TLS in the same way that DTLS is related to = TLS: it imports much of the syntax, but there are many differences and = its security must be evaluated largely independently. My initial = reaction to this spec was to wonder why it did not simply run QUIC over = DTLS . I believe the answer is that careful integration improves the = performance and is necessary for some of the address agility/transition = design. >=20 > Given its potential importance, this deserves a thorough review by our = best security people. Fortunately, from the acknowledgements list, it = appears it has gotten that. >=20 > There are a few aspects of the design that might raise eyebrows. For = example: >=20 > 1) TLS exchanges start out in cleartext until a key can be negotiated. = QUIC data is always encrypted. The initial packets are encrypted with = fixed keys whose derivation is specified in the I-D until fresh keys are = negotiated. This isn't a security problem...it will just surprise = people. >=20 > 2) Applications using TLS can usually be configured to run over TCP in = contexts where cryptographic protection is not needed. (e.g., use HTTP = instead of HTTPS). Applications using QUIC cannot. That is likely to = mean in practice that it will more frequently be the case that = applications using QUIC will need to connect to servers without = certificates signed by a CA trusted by the client (because that's the = substitute when connecting to a server without a certificate). It's not = clear what the spec should say about that, but perhaps the problem = should be acknowledged. >=20 > Radia >=20 --Apple-Mail=_AA0E888B-B8E9-4154-A226-0FF6BC4E96C6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl+fuFUACgkQVLXDCb9w wVemFw//QJPyrTIXXu2s5bbpMJSL4Gnw342Ew8mpn8ZI9n35MFA8JKlYyhZagdJz Vp5j9yOO4Uma/JUihRWtzAtcEXy4qTU8/X/VDPSVOd0TUh7xyCel6/PeTUOcqDrC Bfc4K7IHXBYnDs7pPZCsrLrXBm83RSsmCqeQG90RXBEMbFeQkDlb31S6cpQbAh9i sjOAaKLw7EAPocb6CpUnDJ6FaF8z5sXXUfwj5I7CgPAAG6IDa0XcqBtGyfHhhwBx kZriuPnu0GHLE0sVAQAHqobVSPo23I9M4S/sJo1AzjeHYwIVevpNtiqtWA/rWAVg hQ84zx76ngJ/Q3sJU4H9Lgjq9ZFu7qvzxIVlTLX7YS1QvtoF1TRX8ABvAJ9paVGM HbtGvokbjY1Kxb/gLGoUzlFPnf7vHh3wjApZ5V/Uoxv35P6srf9bQtpQOdJzY4Lb ZFRPEY8ysBYy0J5CH5WQsttzJC2XiydwoUkfICGsAIiPpAx+FdTAX/M3+jDJDCHw 0v4XMvasyHx/mbfVICRTN16xDRopDE6Z4oMz+3SdsMBx7DQVw5ESELghEChNWi+k ohQA9bwwAJbxir4dIssn0KGk/QSQD9z3HNJ1eQ0sLzpeTHFdMkFnqe7MMq+E5IHz p9Ym6OXpJ63z+IAr7m4qQvKGpWrKEZDdh0lrE88dxVJjte5rIPY= =v2kA -----END PGP SIGNATURE----- --Apple-Mail=_AA0E888B-B8E9-4154-A226-0FF6BC4E96C6-- From nobody Mon Nov 2 00:05:51 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC25E3A0AA7 for ; Sat, 31 Oct 2020 06:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nat-consulting.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LusrBLYBop7X for ; Sat, 31 Oct 2020 06:14:13 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885D03A0AE3 for ; Sat, 31 Oct 2020 06:13:50 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id c9so3663620wml.5 for ; Sat, 31 Oct 2020 06:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nat-consulting.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=oLsijETixkqRmx/2mBPjCimHb2/Y97x6GJZeLRHKsVY=; b=FtqPVE2al2KLDS/7tQ3lbY9809Uq4hR7UDiK0juFNIvRTx1Mgagun2nlCW4axnYQEs 5M+tfbku2q8jl/7qLoo/2xTccW6Pz0ZaeR8WOzMkL5oqyOjfFT6eg9nTu9oeyrdhnne4 xIQp32oKdW/WmmnUio50ceEKPoNwyIg2DFk7zTv1Sqj+I+YVtq2K1DtIsr6mg9uWarP9 tp21E4EJzje8hfPZs7EfcNdXZm9kMw+IeL/YXXSZVYZkzWk1RVpRXB5JrrBGPECWFXFU O6JQpDE9zA8MlonQ0mahvUB779zyJjEX8PD7oxHXX5J5D8d8T6/egBf3y9ZKEIlAnrB4 LhQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=oLsijETixkqRmx/2mBPjCimHb2/Y97x6GJZeLRHKsVY=; b=OLG47M+pbb3eO3i3ZipiilQGLBhOcerrGfIrzc35koP42eBNBHem1ZSKm7EkE3zaKQ YcAyjgSWVNuxF7j5WHgE7+AGdkrdog13Ab8KDk7rYX039Q9uKGWeX0kQPA6/wIf3bRZk TUYx/FivY12QPbuDIWZVeI1vwvMLE7NxophsuodDRZFy9HNajWrntQH90HzR9hBJ1YFd PhPyEOSQRZwMItoQnJ7FcD/gFnDGsEIUUyULS51k3ydOAFyrU5DjLm+a0CSecU2qVJaz KlX4rU0IjvP4lAJp7/ox48Lb2AHGUeX5qXYnawykIo/inDi5EyScp7FIR/eanIuBnuhk Asbg== X-Gm-Message-State: AOAM533sRIEbq+TpilcCXgiwlcN+a1itIVH9WOvPoF2ekDEFKYJFPewe SsamAbqbOI/51CKLKzyiK7v4K6As3MqKz6DlSF2z5Q== X-Google-Smtp-Source: ABdhPJyCqetP57O/TxMPaVaUrVUruYrjFWMdJSt/aBt5a4IsnDnfAKzLCysyVnZzDYZCTJxY7y3d2E+6aY6cp5xPikw= X-Received: by 2002:a7b:cb13:: with SMTP id u19mr8283754wmj.89.1604150028452; Sat, 31 Oct 2020 06:13:48 -0700 (PDT) MIME-Version: 1.0 References: <160108120392.5893.18114957198518376382@ietfa.amsl.com> In-Reply-To: <160108120392.5893.18114957198518376382@ietfa.amsl.com> From: Nat Sakimura Date: Sat, 31 Oct 2020 22:13:37 +0900 Message-ID: To: Watson Ladd Cc: secdir@ietf.org, IETF oauth WG , last-call@ietf.org, draft-ietf-oauth-jwsreq.all@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Mon, 02 Nov 2020 00:05:50 -0800 Subject: Re: [secdir] Secdir last call review of draft-ietf-oauth-jwsreq-30 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2020 13:14:16 -0000 Hi Watson, Thanks very much for the review. I thought I have sent my response earlier, which I actually did not. It was sitting in my draft box. I apologize for it. My responses inline: On Sat, Sep 26, 2020 at 9:46 AM Watson Ladd via Datatracker wrote: > > Reviewer: Watson Ladd > Review result: Serious Issues > > I generated this review of this document as part of the security director= ate's > ongoing effort to review all IETF documents being processed by the IESG. = These > comments were written with the intent of improving security requirements = and > considerations in IETF drafts. Comments not addressed in last call may b= e > included in AD reviews during the IESG review. Document editors and WG c= hairs > should treat these comments just like any other last call comments. > > Two minor issues: On page 4, "This offers an additional degree of privacy > protection." should be reworded. I don't think it makes sense in context,= where > authenticity was discussed. In the course of the edit, explanation about two distinct privacy benefits was collated in one sentence and has become very difficult to parse. What it is trying to express as privacy benefits are the following. 1) The authorization request content is sent to the AS in the backchannel so it will not be exposed through the browser to the eyes of an active or passive outsider observing what is going on in the browser. In the RFC6749 framework case, the authorization request goes through the browser redirect and it could leak to the adversary via WPAD/PAC Attack, referrer, browser history, etc. Also, if the browser was infected by an adversary controlled malware, the content can be sniffed by the adversary. In the case of JAR, it does not happen. This is one privacy benefit it is trying to explain. 2) The location that the authorization request is getting pushed to does not have to be the AS. A trusted third party that examines the content for the conformance to the collection minimization principle may act as the party that accepts the authorization request and issues the request_uri. AS can then just evaluate the domain part of request_uri to evaluate that the authorization request is conformant to this principle. This is another privacy benefit from the point of view of the individual user. > It took me a while to understand what the by reference method is: maybe t= he > intro should say via URL instead of by reference. request_uri can be URL or a handle such as URN. That is why the "by reference" word is being used, per the suggestion of the WG. > > > And now for the thorny issues with this draft. Signatures and encryption = are > different. And encrypting a signed blob doesn't mean the signer encrypted= it. > Then there are a plethora of methods specified in the draft to authentic= ate > the blob, which will give different results in maliciously constructed > examples. The security considerations section should discuss what the enc= rypted > vs signed choices give in the way of security, and it doesn't. This makes= me > worry. We don=E2=80=99t expect the encryption to ensure authenticity, that=E2=80= =99s what the signatures are used for. Note; All JWE encryption suites are AEAD. So, if only confidentiality with integrity protection is sought, that would suffice. However, it does not prove that it did not get tampered before it was encrypted nor prove that it really came from the issuer. Thus, just encrypting the authorization request does not fulfil the security property that we want. That is why it is presenting two modes: (a) JWS Signed; and (b) JWS Signed and encrypted. If what is sought is only the source authentication, integrity protection and non-repudiation, (a) suffices. On the other hand, if the request object that includes some sensitive data is being sent to the AS via redirect, one may want to further encrypt it so (b) is also provided. I didn't quite get what is meant by "plethora of methods specified in the draft to authenticate the blob ... " There is a bit of text about authenticating the source (=3Dclient) but not much on the blob itself. The discussion around the signature and/or encryption is covered in RFC7519 (JWT), the format that the request object assumes. This is required reading when implementing this spec, so WG thought it is not worth repeating here. Attacks etc. on the signature and encryption are covered in RFC7515 and RFC7516 respectively. > > Looking at the cited reference for attacks, I see the fix is to include > information about which IPD was used by the RP. But the draft before us d= oesn't > mandate that. It's not clear than how the cited attack is prevented by th= e > draft. Saying that the communication through the user-agent is subject to The mention of mix-up attack was introduced after the Last call by one of the comment. It just added it in the sentence with a reference. I am ok to remove it. Having said that, the heart of mix-up attack is that the combination of the client believes that it is communicating with the attacker-controlled AS (AAS) while it in-fact is talking to Honest AS (HAS), AND HAS unable to find out that the client is thinking that it is talking to AAS not him. OAuth JAR seems to mitigate it in two ways: a) Use request_uri which is hosted by the AS. Then, if the client is thinking that it is talking to the AAS, then it will push it to AAS and when the user is redirected to HAS, HAS will find out that the request_uri is not created by herself and return an error, making the mix-up attack fail. b) Include `aud` in the request. Then, when the HAS will find that the request was minted to AAS and not her. So, it will result in an error, making the mix-up attack fail. So, I added mix-up attack to the sentence thinking the commenter's request to add it is fine, but I am fine with removing it. > manipulation, and this prevents it, ignores that the attacker in that pos= ition > sees a lot more. The user-agent as resource owner modifying the requested > resources is a very funny sort of attack: can't they do what they want wi= th the > resources since they control the access? If the client is in the browser, yes. But in the mainstream case, the client is not in the browser but the web-server that the browser is communicating with and the resource access happens without being mediated by the browser. > > > Key management is ignored. This is a very important issue, especially A lot of ground is covered by RFC 7515, 7516, 7517, 7518, 7519, 7591, and 8414 so this document is not specifically restating them. > > considering the potential problems with the reuse of JWT. I'd like to see= a Are you talking about the reuse of the request object by an adversary trying to act as an honest client? Even if it happens, the malicious client does not have the proper client credential so it cannot redeem the code it obtained with the token. It is no different than RFC6749 code grant. Protocols that extend it, such as OpenID Connect, have introduced nonce to prevent the reuse and used JAR (it is called request object there) to further protect tampering and achieve client authentication even in the front channel. > recommendation that keys be separated by intended uses, rather than limit= ing > particular fields in an ad-hoc manner. Could you kindly elaborate on the "ad-hoc manner" part so that I can understand it more fully? > > > Then we have section 11. What section 11 introduces is an entire new dram= atis > personae, the Trust Framework Provider, with no prior discussion of what = it is > or a reference to where it is defined and a good number of statements abo= ut how > it works that aren't really clear what they mean from the document to me= . Trust Framework Provider first appears in 5.2.1. At the time of writing the related text, it was a pretty well-known concept. In the United State, it was part of its National Strategy (NSTIC) and internationally, it was even taken up at WEF Davos meeting. It is quite surprising that such a mainstream concept faded into obscurity so quickly. The reason for introducing it was to a) justify request_uri as some WG members wanted it to be removed, b) justify that requst_uri to be served from a different domain. Now that people appreciate it, e.g., it can be seen from PAR, the justification for a) probably is no longer required. A full explanation for b) would probably be a much longer text but I doubt if it belongs to this document. I am fine with removing the reference to Trust framework etc. as long as the capability to push the authorization request to a place other than the client or the authorization server is not removed. > > My biggest concern is that these issues are signs that the problem this d= raft > is trying to solve and the mechanisms to solve it haven't been analyzed a= s > thoroughly as they should have been. Without that sort of thorough analys= is > it's not certain that the mechanisms actually solve the problem and it's = not > clear what the recommendations to implementers have to be to preserve tho= se > properties. OAuth JAR, as the name "The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)" suggests, is a framework and not a house itself. One such example is FAPI [1] which was formally verified [2]. [1] https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md [2] https://arxiv.org/abs/1901.11520 > > Obviously this draft has had a long and tortured history with multiple re= views, > and what I'm suggesting needs to happen is a lot of work. But it's essen= tial > in any security protocol to do this analysis and be clear about what is, = and > what is not, protected by the protocol. OAuth JAR is nothing but just another binding to OAuth 2.0. Where RFC6749 binds it to form encoding, it provides two additional bindings: 1) binding to JWT, and 2) binding to the pushed authorization request that is referenced by a = URI. It is this simple. As such, it would also inherit some of the shortcomings in RFC6749. However, it is not this document to address them. It should be done by other documents so that the result can be encoded using the mechanisms provided in this document. It is quite surprising that this fact is not getting appreciated and is taking such a long time to complete. Maybe I should delete all the explanation text and leave it with just the core text. Explanation and justification text for defining additional bindings probably are just distractions now as it is now appreciated and used all over the world unlike when the project was started. > > Sincerely, > Watson Ladd > Thanks again for your detailed comments. Best wishes, -- Nat Sakimura NAT.Consulting LLC From nobody Mon Nov 2 12:20:49 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E023A11EA; Mon, 2 Nov 2020 12:20:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Derrell Piper via Datatracker To: Cc: last-call@ietf.org, draft-ietf-quic-recovery.all@ietf.org, quic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160434842876.26069.16673628080135964837@ietfa.amsl.com> Reply-To: Derrell Piper Date: Mon, 02 Nov 2020 12:20:28 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-quic-recovery-32 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 20:20:29 -0000 Reviewer: Derrell Piper Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is: Ready, with an optional nit. This document is QUIC's Loss Detection and Congestion Control and is part of QUIC Last Call. Pp. 7, "after the epoch starts is acknowledged" should maybe be singular, unless the intent is literal and I'm missing what a "starts" is. There's no explicit security going on here, other than in the larger picture of QUIC itself, namely that in QUIC-TLS and QUIC-TRANSPORT; this is only its congestion control. However, Security Considerations correctly highlights some of the major traffic analysis concerns with QUIC and congestion control in general, and there are some, but these are not unique to QUIC, nor would they likely be addressed inside of congestion control, so this is okay. It seems well written and based on a practical understanding of existing TCP congestion control along with current academic research on this topic. Derrell From nobody Mon Nov 2 13:07:39 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4EC3A0E5A; Mon, 2 Nov 2020 13:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lQUh1_Au-mr; Mon, 2 Nov 2020 13:07:15 -0800 (PST) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1582C3A0C98; Mon, 2 Nov 2020 13:07:12 -0800 (PST) Received: by mail-ej1-x634.google.com with SMTP id o9so18721749ejg.1; Mon, 02 Nov 2020 13:07:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qN/IdIkus/RRbGeQuoYaR7sRVAgw/Zh3m7oqKKL8FyY=; b=AEQBJqW3DgnUvTy/99nlLyR7WxRqnPjzOLwktf8WqpfyHEDjxS6Wc9st4EObzitwUb qbPJM/pAMzzvKf02hSt6mcsjjP7fnXbm1NASWlhr24W1xuZxbhII+iFdCH+eH8cyZGct EOpWktf0GNhvSdSRquauPZBWCDHD97/MCUQ+Oi9CBJrtM/J0gOGRZOphFUWfdXCV42PZ gtGDr2zuC6SnYfpk1zgZvp7rj6l2zQFsF6eZ2BVi4rpqBvghjmkVbCMLFR5CZh7WuddM 523J/WfTxR1J0yt22T/iInNgsxm3pC0roPb2W5078Egsu8pHlkBEAYet2upjHRFdKEfw Bhbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qN/IdIkus/RRbGeQuoYaR7sRVAgw/Zh3m7oqKKL8FyY=; b=ky1Mb7UPNCj2DpTLKYOoUApDqy7nZ4NLtveF7ibV3vfqH7gSiS0n+ibcLWvtwoUJ0j rTAtuOeJE2MhqMhZJRkCH/CTxcFJ+cHbDCNbFoOg7RuK7lvAhNfpn1hsTYEz6YxeROES E2FBB0H+coUAxpN5gxEYn97I8MGb9hm7wwJ6w1BBSQ0YOmxCJL3Enm9hR0K9kjn/H+L4 tTKD7Ke5NUEbLBHekeS8GnbWuSHDawr5aa8r8ab5lf9iFwgPswpo1MyLQ/845zfv8fM+ CvCS9MwY65MYhKQGBknU6OTvi6LjSd6pLDRE2TFVmZDeFlRYWBnaSVdD+eSVD9Xt6YbA Zn0g== X-Gm-Message-State: AOAM530NthcuPeu/0rWqnqilzQpGmuG2/lmXYEwkLo8Dka4JyW/wJGSo LrWy1btmB0Hq84rLyI6rOcue6+jXsHrUSzyF2xiXwSXnwcs= X-Google-Smtp-Source: ABdhPJxc/hHWE0LvGBffQqyWgLv6JNmXw8OJBSrZIc3nBqG3Xo2XiG0MOdqn4Fry6+SVXV7Je7x+bIh1ScIrPZwKNyU= X-Received: by 2002:a17:906:b084:: with SMTP id x4mr17736633ejy.374.1604351230585; Mon, 02 Nov 2020 13:07:10 -0800 (PST) MIME-Version: 1.0 References: <160434842876.26069.16673628080135964837@ietfa.amsl.com> In-Reply-To: <160434842876.26069.16673628080135964837@ietfa.amsl.com> From: Lucas Pardue Date: Mon, 2 Nov 2020 21:06:58 +0000 Message-ID: To: Derrell Piper Cc: secdir@ietf.org, last-call@ietf.org, draft-ietf-quic-recovery.all@ietf.org, QUIC WG Content-Type: multipart/alternative; boundary="00000000000031b06a05b32621e2" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-quic-recovery-32 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 21:07:17 -0000 --00000000000031b06a05b32621e2 Content-Type: text/plain; charset="UTF-8" Hi Derrell, Thank you for the review. I've opened a GitHub issue for any discussion related to this review: https://github.com/quicwg/base-drafts/issues/4324 There is also a milestone at https://github.com/quicwg/base-drafts/milestone/8. Thanks, Lucas On Mon, Nov 2, 2020 at 8:20 PM Derrell Piper via Datatracker < noreply@ietf.org> wrote: > Reviewer: Derrell Piper > Review result: Ready > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > The summary of the review is: Ready, with an optional nit. > > This document is QUIC's Loss Detection and Congestion Control and is part > of > QUIC Last Call. > > Pp. 7, "after the epoch starts is acknowledged" should maybe be singular, > unless the intent is literal and I'm missing what a "starts" is. > > There's no explicit security going on here, other than in the larger > picture > of QUIC itself, namely that in QUIC-TLS and QUIC-TRANSPORT; this is only > its > congestion control. However, Security Considerations correctly highlights > some of the major traffic analysis concerns with QUIC and congestion > control > in general, and there are some, but these are not unique to QUIC, nor would > they likely be addressed inside of congestion control, so this is okay. It > seems well written and based on a practical understanding of existing TCP > congestion control along with current academic research on this topic. > > Derrell > > > --00000000000031b06a05b32621e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Derrell,

Thank you for the review. I've opened a GitHub issue for any discussion= related to this review: https://github.com/quicwg/= base-drafts/issues/4324

There is also a milestone at https://github.com/qui= cwg/base-drafts/milestone/8.

Thanks,
Lucas

On Mon, Nov 2, 2020 at 8:20 PM Derrell Piper via Datatracke= r <noreply@ietf.org> wrote:
Reviewer: Derrell= Piper
Review result: Ready

I have reviewed this document as part of the security directorate's ong= oing
effort to review all IETF documents being processed by the IESG.=C2=A0 Thes= e
comments were written primarily for the benefit of the security area
directors.=C2=A0 Document editors and WG chairs should treat these comments= just
like any other last call comments.

The summary of the review is: Ready, with an optional nit.

This document is QUIC's Loss Detection and Congestion Control and is pa= rt of
QUIC Last Call.

Pp. 7, "after the epoch starts is acknowledged" should maybe be s= ingular,
unless the intent is literal and I'm missing what a "starts" = is.

There's no explicit security going on here, other than in the larger pi= cture
of QUIC itself, namely that in QUIC-TLS and QUIC-TRANSPORT; this is only it= s
congestion control.=C2=A0 However, Security Considerations correctly highli= ghts
some of the major traffic analysis concerns with QUIC and congestion contro= l
in general, and there are some, but these are not unique to QUIC, nor would=
they likely be addressed inside of congestion control, so this is okay.=C2= =A0 It
seems well written and based on a practical understanding of existing TCP congestion control along with current academic research on this topic.

Derrell


--00000000000031b06a05b32621e2-- From nobody Mon Nov 2 17:27:26 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C642C3A131F for ; Mon, 2 Nov 2020 17:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbDwZii3crIo for ; Mon, 2 Nov 2020 17:27:22 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 740323A131D for ; Mon, 2 Nov 2020 17:27:21 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0A31REjF030449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 2 Nov 2020 20:27:19 -0500 Date: Mon, 2 Nov 2020 17:27:14 -0800 From: Benjamin Kaduk To: Valery Smyslov Cc: secdir@ietf.org Message-ID: <20201103012714.GB39170@kduck.mit.edu> References: <160372407981.20077.17795340180313190981@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <160372407981.20077.17795340180313190981@ietfa.amsl.com> Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-babel-information-model-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 01:27:25 -0000 Hi Valery, Thanks for this review -- a lot of good points raised. I filed a Discuss ballot to continue to discuss several of them, especially to make sure that we are clear and precise about what cryptographic operations are performed (for the "operation"s), and to discuss a few places (such as key lengths) where the information model seems to be imposing restrictions not present in the core protocol without providing a justification for the divergence. -Ben On Mon, Oct 26, 2020 at 07:54:39AM -0700, Valery Smyslov via Datatracker wrote: > Reviewer: Valery Smyslov > Review result: Has Issues > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area directors. > Document editors and WG chairs should treat these comments just like any other > last call comments. > > The document defines an informational model for Babel routing protocol. This > informational model can be used as a basis for creating various data models > (e.g. YANG). The document is properly structured and well written, however I > think that it has some issues concerned with security. > > Issues. > > 1. Section 3.1: > > babel-mac-algorithms: List of supported MAC computation algorithms. > Possible values include "HMAC-SHA256", "BLAKE2s". > > BLAKE2s can produce MACs of different sizes from 1 to 32 bytes and the desired > size of the MAC is a parameter for it. Where the size of MAC is specified? For > HMAC with SHA256 I can at least imagine that full 256 bits output is used as a > MAC... > > 2. Section 3.9: > > babel-cert-test: An operation that allows a hash of the provided > input string to be created using the certificate public key and > the SHA-256 hash algorithm. Input to this operation is a binary > string. The output of this operation is the resulting hash, as a > binary string. > > I failed to understand what this operation should do. Literally reading it is > intended to produce SHA2-256 hash of public key and some arbitrary string > (concatenated? in what order?). But then I failed to understand the purpose of > this test. I would have understood if this operation provides signing of the > arbitrary string using private key and SHA2-256 as a hash function (similarly > to babel-mac-key-test), but it in not what is written... > > 3. Section 5 (Security Considerations): > > I think that text about keys (their length and properties) needs some > expansion. First, there are no any RFC2119 words discouraging using short and > weak keys (there is some text, but without RFC2119 words and with no references > it's just hand waving). Note, that draft-ietf-babel-hmac-12 has some text about > the properties of the keys, so I believe at least it must be referenced here. I > also suspect that explicitly allowing zero-length and short keys will lead to > situations when some network operators will use them (because they are not > prohibited), thus subverting security properties of MAC... > > Nits. > > 1. Section 1 (Introduction): > > [I-D.ietf-babel-hmac] defines a > security mechanism that allows Babel packets to be cryptographically > authenticated, and [I-D.ietf-babel-dtls] defines a security mechanism > that allows Babel packets to be encrypted. > > DTLS provides both confidentiality and authentication of data, so to be > formally correct, please add "both authenticated and" before "encrypted". > > 2. Section 2 (Overview) at the very end: > > Note that this overview is intended simply to be informative and is > not normative. If there is any discrepancy between this overview and > the detailed information model definitions in subsequent sections, > the error is in this overview. > > This phrase makes me puzzled. The tree-like description of the information > model in the Overview is very useful, however this phrase seems to discourage > using it, because authors are not sure it is correct. I think it would be > better for readers if authors double check that no discrepancy exists between > the overview and the subsequent detailed description and remove this phrase. > > 3. Section 3.3: > > babel-mac-verify A Boolean flag indicating whether MAC hashes in > incoming Babel packets are required to be present and are > verified. If this parameter is "true", incoming packets are > required to have a valid MAC hash. An implementation MAY choose > to expose this parameter as read-only ("ro"). > > "MAC hashes" is strange wording, "MAC values" or just "MACs" are better in my > opinion. > > 4. Section 3.8: > > babel-mac-key-use-sign: Indicates whether this key value is used to > sign sent Babel packets. Sent packets are signed using this key > if the value is "true". If the value is "false", this key is not > used to sign sent Babel packets. An implementation MAY choose to > expose this parameter as read-only ("ro"). > > "Sign" is not a good word when you describe symmetric key operations (which > computing MAC belongs to). Although it is often used informally, I think that > RFC should be more meticulous in selecting words. I'd rather replace it with > "compute MAC" and rename the entry to babel-mac-key-use-compute or > babel-mac-key-use-mac (if it is possible). Note, that using "verify MAC" is OK. > > 5. Section 3.8: > > babel-mac-key-value: > ... > This value is of a length suitable for the associated babel-mac-key- > algorithm. If the algorithm is based on the HMAC construction > [RFC2104], the length MUST be between 0 and the block size of the > underlying hash inclusive (where "HMAC-SHA256" block size is 64 > bytes as described in [RFC4868]). If the algorithm is "BLAKE2s", > the length MUST be between 0 and 32 bytes inclusive, as described > in [RFC7693]. > > I wonder of the rationale for imposing the above restrictions on HMAC key > length. HMAC can use keys of any length, but if the key is greater than block > size of underlying hash function, then it's first hashed (small performance > penalty). So I imagine that the rationale is to avoid this penalty. However, as > RFC2104 states, key sizes greater than output length of the underlying hash > function (32 bytes in case of SHA2-256) would not significantly increase the > function strength, so it's just a waste of space. See also Issue 3 above. > > 6. Section 3.8: > > babel-mac-key-test: An operation that allows the MAC key and hash > algorithm to be tested to see if they produce an expected outcome. > Input to this operation is a binary string. The implementation is > expected to create a hash of this string using the babel-mac-key- > value and the babel-mac-key-algorithm. The output of this > operation is the resulting hash, as a binary string. > > The text mixes up words "hash" and "MAC". MAC is not a hash (even if MAC > algorithm is often based on hash function). As with my previous grunt, I'd like > RFC to be more meticulous in selecting words. Please, avoid using "hash" here. > > 7. Section 5 (Security Considerations): > > ... This model requires that private keys never be > exposed. The Babel security mechanisms that make use of these > credentials (e.g., [I-D.ietf-babel-dtls], [I-D.ietf-babel-hmac]) > identify what credentials can be used with those mechanisms. > > Please add "and MAC keys" after "private keys" since formally private keys are > only defined for public key cryptography. > > 8. Section 5 (Security Considerations): > > MAC keys are allowed to be as short as zero-length. This is useful > for testing. > > I wonder what's benefit of allowing zero-length keys for testing purposes. What > is intended to be tested in this case? Implementation of MAC? Is it really > needed outside test lab? Am I missing something? > > 9. Section 5 (Security Considerations): > > Short (and zero-length) keys and > keys that make use of only alphanumeric characters are highly > susceptible to brute force attacks. > > Formally, brute force attack with zero-length keys is not defined, since there > is no key to find and all is in clear. > > Comments. > > 1. The document contains an entry in the Informational model defining which > hash functions can be used with HMAC authentication. However, there is no > corresponding entry of which ciphersuites can be used with DTLS. Is it up to > DTLS library to select ciphersuites? > > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Mon Nov 2 22:10:41 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 562BE3A14AF; Mon, 2 Nov 2020 22:10:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Takeshi Takahashi via Datatracker To: Cc: draft-ietf-idr-flow-spec-v6.all@ietf.org, idr@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160438382127.25127.15298196716431193428@ietfa.amsl.com> Reply-To: Takeshi Takahashi Date: Mon, 02 Nov 2020 22:10:21 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-idr-flow-spec-v6-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 06:10:22 -0000 Reviewer: Takeshi Takahashi Review result: Ready This draft extends internet-draft-ietf-idr-rfc5575bis to cope with IPv6. As mentioned in the Security Consideration section, no new security issues are added to the GBP protocol. Note that, as mentioned in the security consideration section of the 5575bis draft, any relaxation of the validation procedure may allow unwanted Flow Specifications to be propagated, but this draft does not incur any such relaxation because the validation procedure remains the same. Very minor editorial comment: [Section 3.2] the same as in Section 3.1 -> the same as in Section 3.1. From nobody Tue Nov 3 09:23:07 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA26C3A0DFF; Tue, 3 Nov 2020 09:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFiboYpStJcd; Tue, 3 Nov 2020 09:23:02 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF343A0DD5; Tue, 3 Nov 2020 09:22:44 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 464644082E; Tue, 3 Nov 2020 18:22:42 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 3E762AB; Tue, 3 Nov 2020 18:22:41 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:be1b:33a0:9df5:4f6f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 0394C34; Tue, 3 Nov 2020 18:22:41 +0100 (CET) Received: (nullmailer pid 52607 invoked by uid 1000); Tue, 03 Nov 2020 17:22:40 -0000 Date: Tue, 3 Nov 2020 18:22:40 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Valery Smyslov Cc: secdir@ietf.org, draft-ietf-core-resource-directory.all@ietf.org, core@ietf.org, last-call@ietf.org Message-ID: <20201103172240.GC45088@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="E13BgyNx05feLLmH" Content-Disposition: inline In-Reply-To: <159704204394.11310.18005109400419971010@ietfa.amsl.com> <20201103170958.GA45088@hephaistos.amsuess.com> Archived-At: Subject: Re: [secdir] [core] Secdir telechat review of draft-ietf-core-resource-directory-25 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 17:23:05 -0000 --E13BgyNx05feLLmH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable (This is one of the point-to-point follow-up mails on the RD -25 reviews; for the preface, please see the preceding mail on "The various positions on draft-ietf-core-resource-directory-25" at ). > The -24 version of this draft was reviewed by Adam Montville. I looked ov= er > his review and I think that the issue he raised about possible mitigatio= n of > DDoS amplification attacks has been addressed in this version. I personal= ly > think that sentences describing how DNS and NTP are vulnerable to > amplification attacks are redundant in this document, but that's a matter= of > taste and doesn't hurt. response: We've taken the comment as an opportunity to cut back on the history lesson (change in https://github.com/core-wg/resource-directory/pull/249). > It is my impression, that Security Considerations were mostly written hav= ing > in mind that (D)TLS is always used, however it is only "SHOULD" in this d= raft > (or even "MAY" if we look at RFC6690 which Security Considerations this d= raft > refers to). I think that adding a few words describing which consequences= for > security not using (D)TLS would have and in which cases it is allowed will > make the Security Considerations more consistent.=20 response: Which level of protection is adaequate depends on the security policies. The text you refer to was missed in updates, and now reflects that some security mechanism ((D)TLS or OSCORE) SHOULD be used where the policies in place indicate sensitive data. (See https://github.com/core-wg/resource-directory/pull/250 for the full change). --E13BgyNx05feLLmH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl+hkeAACgkQOY0REtOk veELWg/+I5PZ1v8JiR/qDGtogDM7EcUEtm+4fGFSwGHNVUwp7BvJxPnxUtpruQaY OHUP12eKwLp4gjfFXXhv+ZwIf1V6uQF8AATA8bT4esDKER2382/NCstzVaoUOIkd WnXfSQmWvj5Db+exyrK3SP3VB//KSIa6bs8vkyAUoVwAkB7pHN/bz3gltC/4OD7O P7DhM4mWr1051tFdPV2deFQClF9GzR3avFYhNcHtbancUTbRojDmiG+tL/Yl+W1r 0gdw7YpCvTxNlqiGx4Tm1/Uag+GkHD3m1Z2hgcqj6rHRVCcyUvkOGLfqgVIkGC11 yiHGa2MMiZWSLAzaYxzY+qmxEV5u8Pom1mwvWr3KxUvh6+el9ynDagF+ISxl9Ach PxXJhKJw6gMXYjuU3ZI9I0dlmhK7J+LXBpvKZkE+3SF/ra258tK6+3WgQD1CHYAR Vwf4F2G/2lAZJv285fb4Y1j4+XS0YIrX2nuvkW9Q05DeqwOPyJPzpp8EXhcaPyB3 /oPbImdG6m/womqmgFAzDPIPiyBD4LQI2TJbhTYF92zAFXEvO0F2Haj3Ooswq+ky bUael9T3pWfKwhtbxxTgvZFvpWjXSBrnRXCxDqYaZsbIMOPWBkj3gJxyQMX1RuJA VF+C9I03Njs8/Bw2FDnW0RrGx5eIj8VGTbsp4dB8P560drpSIrk= =VeO4 -----END PGP SIGNATURE----- --E13BgyNx05feLLmH-- From nobody Wed Nov 4 15:34:23 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9DE93A1163; Wed, 4 Nov 2020 15:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRfwBsSflBLJ; Wed, 4 Nov 2020 15:34:15 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3D8A3A1162; Wed, 4 Nov 2020 15:34:15 -0800 (PST) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 0A4NYCMR013055; Wed, 4 Nov 2020 18:34:15 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 34ke5bgs36-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 04 Nov 2020 18:34:14 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A4NYD7O025242; Wed, 4 Nov 2020 18:34:13 -0500 Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [135.66.87.47]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A4NY878025163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Nov 2020 18:34:08 -0500 Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [127.0.0.1]) by zlp27126.vci.att.com (Service) with ESMTP id 04FA4403072D; Wed, 4 Nov 2020 23:34:08 +0000 (GMT) Received: from MISOUT7MSGED1DB.ITServices.sbc.com (unknown [135.66.184.185]) by zlp27126.vci.att.com (Service) with ESMTPS id CA7E2403072B; Wed, 4 Nov 2020 23:34:07 +0000 (GMT) Received: from MISOUT7MSGED1AC.ITServices.sbc.com (135.66.184.173) by MISOUT7MSGED1DB.ITServices.sbc.com (135.66.184.185) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Wed, 4 Nov 2020 18:34:07 -0500 Received: from MISOUT7MSGETA02.tmg.ad.att.com (144.160.12.220) by MISOUT7MSGED1AC.ITServices.sbc.com (135.66.184.173) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4 via Frontend Transport; Wed, 4 Nov 2020 18:34:07 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.168) by edgeso2.exch.att.com (144.160.12.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2044.4; Wed, 4 Nov 2020 18:34:06 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fy2kka+oD3KGOgBUAPuSjqRrZwfktN26DaHIyknNiu4ZOQTHoMmaZVwcyL6LXuc4/ZKVIV1GmHAU3wgloEtSGswptAKLWjT5mlYKXUgso0xcc8KQWfbgzZwNj7h1tUsjwtN9PDPgSNyUOVDrF7mzGLQQGkHA4659/qEFhR26OnCqoLeYcNZJxtd3b51gQV9d458AlN0PuIOeTbhYLPA2x8SetFp118K6wqlne+4YzF6yf4FbibPn/lNIEcS/arKs4w2BTZKMxzy7FinTILyGzZOjePguyAXvvauZumhiEIxLbB2OWaTH3o6+WGLNJ1BoNNZA10oBzpItvWym61hNhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dsMXCoS3BR6le2MGkHwqYOdVqJuG/HIVtAYe+uYKokQ=; b=mzlmc80e1P1ihW5BALol9oYLDoRE1ue+ux5+azwQgHj7kt4S09Y8Pl4Xj+XJxAxqXZUDjtu/Lo/MlnaszoU4pkMNPj1d8cYSSE5gdb4X9PWNMqeJdOrh00/sog3w9oY4wg7OQJRD5LR3BN2gWQbHbV/FeKRvF4L8hKgML03/+vAOhCj43R10j8/Nhfs4vmdm9sOTHtE+2oyDlXLFth5bb59wSLlHjuCCtS+p8Fqb/+sqOBPT0eH+0BI7SQanUO3+BpZEHjsq3Oat7kPteZVuQanfyXnAKnRmqucbWezDZaqvDTlAzJmQlocEVCz8SMHUiWxV8V6MAwxWdfy1UfDI9A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dsMXCoS3BR6le2MGkHwqYOdVqJuG/HIVtAYe+uYKokQ=; b=WUg58/GsSYj10E86OmXHZ19OGiiYmt76pVCKmkaEdOS1mWB5EhyYAK0VsQ+5i8HWhQ+o1TCY0xBbF1+tNHRg/CfNz7n47WTzoLJUCcraE0E8B1RyRKEY3GO0ImkmpJWpRR2YRvx2s+MhpR6K5HJEelGixx5g+/PjKhwnXPLemVU= Received: from SN6PR02MB4512.namprd02.prod.outlook.com (2603:10b6:805:a4::13) by SN6PR02MB5471.namprd02.prod.outlook.com (2603:10b6:805:df::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Wed, 4 Nov 2020 23:34:04 +0000 Received: from SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::dc3c:5ad:4df8:f8af]) by SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::dc3c:5ad:4df8:f8af%7]) with mapi id 15.20.3499.032; Wed, 4 Nov 2020 23:34:04 +0000 From: "STARK, BARBARA H" To: "'Valery Smyslov'" , "'secdir@ietf.org'" CC: "'last-call@ietf.org'" , "'babel@ietf.org'" , "'draft-ietf-babel-information-model.all@ietf.org'" Thread-Topic: Secdir last call review of draft-ietf-babel-information-model-11 Thread-Index: AQHWq6fzcO41VWb3pEKu2D6snc0rJ6m1Uycw Date: Wed, 4 Nov 2020 23:34:04 +0000 Message-ID: References: <160372407981.20077.17795340180313190981@ietfa.amsl.com> In-Reply-To: <160372407981.20077.17795340180313190981@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: smyslov.net; dkim=none (message not signed) header.d=none;smyslov.net; dmarc=none action=none header.from=att.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [144.160.96.109] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 84d45a03-f794-4b61-ec3d-08d8811a1dd7 x-ms-traffictypediagnostic: SN6PR02MB5471: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ts2wsHl29zdpSLeoe/T24647hNkQ2HbRCUxZkAn3Kp9UIhJH0EdzFOgmtRQZJgkX64O7ggQEf948y+CGmiTlqRSj1cjTvBM3ZzY/xgrV/5haaLJVrDQncBPnRFNDnOVqjg/JAy2XqPaBkU7ZSkdgbPCQ8/DOTizTQoNxPRh3PeDWStSxWJ2iANJ6U8p7PR7R3/t6tELwfnETXzB86fWBWmF8YW9wWYcXu3TQ2eWLyCSFthYe71aytZT2J4SqE8mEOyIyrbaU4DGDFNBiSCbLx70O5+gO7DySNzKxZSYgX7/i4KGg2DngAYYoB74z9fDHx1G/OEGg4KuXyE0W+o8IAChZcaPnOQKa83MdI/5JMIXqOYubo0+J+cgBIb0EF/tF x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR02MB4512.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(39860400002)(396003)(346002)(136003)(376002)(26005)(186003)(54906003)(478600001)(7696005)(110136005)(83380400001)(8936002)(6506007)(55016002)(64756008)(66446008)(33656002)(82202003)(4326008)(2906002)(8676002)(66556008)(66476007)(71200400001)(30864003)(76116006)(9686003)(86362001)(5660300002)(52536014)(316002)(66946007)(491001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: JPlj+GCqsLt/nUqzoNtnNTc1sFiWJ4zLuVQ192oqiBQZsZSaREr8FVOEE99H7w93+4aLaDtHmXv4XV+sa8v1Uba+hIBWSi2SUfbT0Rh9pwH3RH0VqVRpUzN0bPZAmcNMcntmA01HLJQeb6yAM7nkCTQ8Jucs9DBATSs/ixst005YABMxy9j0aU01GNVBLLQ050JPsss3q+0LhEVgmgJ5WDFYFpDftHmqSj6OAnr1HvxM8dDnDHLJXC6/6nRyQswq9eqkqOredBgPjWVzgUVrM/LvcLsXd9rJ3W3nRGbGdHzU+bYvmCDGRzzRkpaKa7M+Y8St8dKM/MoJm/WnZjcelRwub+GYymeUEcSkwvQmku0DwnRZMa39DljPe6CPLP/Aefymo7TBazG5M3IRgmIF1RqiO0NiFGiq4gy5mgUEDT12JxZSZ7P7rRQeLhsZEMBskUmhawBTU7yf5r7qZusG+bN3e5IaIvGLOSIG3YQ7enBAmYGOaEcyGFlEdf6wKc5TaqB6rNw9Vr5rm4E3Bx9syHq/PH87zdU3bTFzhskMzOke/FNbVp2G7mVdklJ43dkK8/bMhcc8oIc3eNrODJAnp7A6onzlQkTX+DIv0WEI6YXdz9vr+rrV3/eexKoMRfcwTpbEaVu5XtSNXHFuOA8KwA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4512.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 84d45a03-f794-4b61-ec3d-08d8811a1dd7 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2020 23:34:04.1388 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jMrt3QpZY8ngt+E61ZmOPl4mHcmCdRhEWlSRW5FGHd+vmQdSIx3PzlZ+WmoRO0+U X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR02MB5471 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: 8387F2C5F1336A4A2ED0D865C29BAF259D599D1CF0D878C5129CC7EA680A1E852 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-04_17:2020-11-04, 2020-11-04 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 malwarescore=0 bulkscore=0 suspectscore=0 impostorscore=0 mlxlogscore=999 spamscore=0 adultscore=0 phishscore=0 lowpriorityscore=0 clxscore=1011 priorityscore=1501 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011040168 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-babel-information-model-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 23:34:18 -0000 SGkgVmFsZXJ5LA0KVGhhbmtzIGZvciB5b3VyIHJldmlldy4gVGFraW5nIGludG8gYWNjb3VudCBK dWxpdXN6JyByZXNwb25zZSB0byB5b3VyIGVtYWlsLCBJJ20gcHJvcG9zaW5nIHRoZSBmb2xsb3dp bmcgcmVzb2x1dGlvbnMuIEZvciB0aGUgZmlyc3QgaXNzdWUgcmFpc2VkLCBJJ20gZGlzYWdyZWVp bmcgc2xpZ2h0bHkgd2l0aCBKdWxpdXN6LCBzbyB0aGF0IG1heSBuZWVkIGZ1cnRoZXIgZGlzY3Vz c2lvbi4gUGxlYXNlIGxldCBtZSBrbm93IGlmIHlvdSBkaXNhZ3JlZS4gSSd2ZSBjb3BpZWQgSnVs aXVzeicgcmVzcG9uc2VzIGhlcmUsIHNvIEkgY2FuIGluY2x1ZGUgbXkgcmVzcG9uc2VzIHRvIHlv dXIgY29tcGxldGUgZmVlZGJhY2sgYW5kIGhpcyBpbiBvbmUgZW1haWwuDQpSb21hbiBzcGVjaWZp Y2FsbHkgbWVudGlvbmVkIGhlIGFncmVlZCB3aXRoIHlvdXIgInJlY29tbWVuZGF0aW9ucyBhYm91 dCBwcmVjaXNlIGxhbmd1YWdlIGFyb3VuZCB0aGUgbmFtZXMgb2YgdGhlIHBhcmFtZXRlcnMiLiBJ IHRoaW5rIHBlcmhhcHMgdGhpcyB3YXMgaW4gcmVmZXJlbmNlIHRvIGl0ZW0gNCB1bmRlciBuaXRz PyBJIGRpZG4ndCBjb21wbGV0ZWx5IGFncmVlIHdpdGggeW91ciByZWNvbW1lbmRhdGlvbiwgc28g SSdkIGFwcHJlY2lhdGUgc29tZSBhZGRpdGlvbmFsIGRpc2N1c3Npb24gb24gdGhhdC4NClRoeCwN CkJhcmJhcmENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiANCj4gUmV2aWV3ZXI6 IFZhbGVyeSBTbXlzbG92DQo+IFJldmlldyByZXN1bHQ6IEhhcyBJc3N1ZXMNCj4gDQo+IEkgaGF2 ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9y YXRlJ3Mgb25nb2luZw0KPiBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWlu ZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZQ0KPiBjb21tZW50cyB3ZXJlIHdyaXR0ZW4g cHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYQ0KPiBkaXJlY3Rv cnMuDQo+IERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2Ug Y29tbWVudHMganVzdCBsaWtlIGFueQ0KPiBvdGhlcg0KPiBsYXN0IGNhbGwgY29tbWVudHMuDQo+ IA0KPiBUaGUgZG9jdW1lbnQgZGVmaW5lcyBhbiBpbmZvcm1hdGlvbmFsIG1vZGVsIGZvciBCYWJl bCByb3V0aW5nIHByb3RvY29sLg0KPiBUaGlzDQo+IGluZm9ybWF0aW9uYWwgbW9kZWwgY2FuIGJl IHVzZWQgYXMgYSBiYXNpcyBmb3IgY3JlYXRpbmcgdmFyaW91cyBkYXRhIG1vZGVscw0KPiAoZS5n LiBZQU5HKS4gVGhlIGRvY3VtZW50IGlzIHByb3Blcmx5IHN0cnVjdHVyZWQgYW5kIHdlbGwgd3Jp dHRlbiwgaG93ZXZlcg0KPiBJIHRoaW5rIHRoYXQgaXQgaGFzIHNvbWUgaXNzdWVzIGNvbmNlcm5l ZCB3aXRoIHNlY3VyaXR5Lg0KPiANCj4gSXNzdWVzLg0KPiANCj4gMS4gU2VjdGlvbiAzLjE6DQo+ IA0KPiAgICBiYWJlbC1tYWMtYWxnb3JpdGhtczogIExpc3Qgb2Ygc3VwcG9ydGVkIE1BQyBjb21w dXRhdGlvbiBhbGdvcml0aG1zLg0KPiAgICAgICBQb3NzaWJsZSB2YWx1ZXMgaW5jbHVkZSAiSE1B Qy1TSEEyNTYiLCAiQkxBS0UycyIuDQo+IA0KPiBCTEFLRTJzIGNhbiBwcm9kdWNlIE1BQ3Mgb2Yg ZGlmZmVyZW50IHNpemVzIGZyb20gMSB0byAzMiBieXRlcyBhbmQgdGhlDQo+IGRlc2lyZWQNCj4g c2l6ZSBvZiB0aGUgTUFDIGlzIGEgcGFyYW1ldGVyIGZvciBpdC4gV2hlcmUgdGhlIHNpemUgb2Yg TUFDIGlzIHNwZWNpZmllZD8gRm9yDQo+IEhNQUMgd2l0aCBTSEEyNTYgSSBjYW4gYXQgbGVhc3Qg aW1hZ2luZSB0aGF0IGZ1bGwgMjU2IGJpdHMgb3V0cHV0IGlzIHVzZWQgYXMgYQ0KPiBNQUMuLi4N Cg0KSnVsaXVzeiBzYWlkOg0KPiBSaWdodC4gIFRoZSBpbnRlbnQgaXMgdGhhdCBCbGFrZTJzIGlz IHVzZWQgd2l0aCAzMi1vY3RldCBrZXlzIGFuZCAxNi1vY3RldA0KPiBoYXNoZXMgKGNvbGxpc2lv bi1yZXNpc3RhbmNlIGlzIG5vdCBhIGNvbmNlcm4gZm9yIEJhYmVsLU1BQyB3aGlsZQ0KPiBkaWN0 aW9uYXJ5IGF0dGFja3MgYXJlKS4gIEJhcmJhcmEsIEkgdGhpbmsgdGhhdCB5b3Ugc2hvdWxkIGV4 cGxpY2l0bHkNCj4gc3RhdGUgdGhhdCBCbGFrZTJzIGltcGxpZXMgMTI4LWJpdCBoYXNoZXMuICAo WW91IG1heSBhbHNvIGNvbnNpZGVyDQo+IHJlbmFtaW5nIEJMQUtFMnMgdG8gQkxBS0Uycy0xMjgu KQ0KDQpUaGUgZGVmaW5lZCB2YWx1ZXMgZm9yIGJhYmVsLW1hYy1hbGdvcml0aG1zIGNvbWUgZGly ZWN0bHkgZnJvbSBkcmFmdC1pZXRmLWJhYmVsLWhtYWMuIFRoZSBkZWZpbmVkIHZhbHVlIG5hbWVz IHNob3VsZCBtYXAgY2xvc2VseSB0byB0aGUgbmFtZXMgdXNlZCBmb3IgdGhlIGFsZ29yaXRobXMg aW4gaW4gdGhhdCBkcmFmdCAtLSB3aGljaCB0aGV5IGN1cnJlbnRseSBkby4gDQoNCklmIGl0IG5l ZWRzIHRvIGJlIGV4cGxpY2l0bHkgc3RhdGVkIHNvbWV3aGVyZSB0aGF0IGFuIGltcGxlbWVudGF0 aW9uIG9mIGRyYWZ0LWlldGYtYmFiZWwtaG1hYyB3aXRoIEJMQUtFMnMgb3V0cHV0cyAxMjgtYml0 IE1BQ3MsIHRoZW4gZHJhZnQtaWV0Zi1iYWJlbC1obWFjICh3aGljaCB3YXMgYWxyZWFkeSBzdWJt aXR0ZWQgZm9yIHB1YmxpY2F0aW9uKSB3b3VsZCBiZSB0aGUgY29ycmVjdCBwbGFjZSB0byBzYXkg dGhhdC4gVGhlIGluZm9ybWF0aW9uIG1vZGVsIGlzIG5vdCB0aGUgcmlnaHQgcGxhY2UsIHVubGVz cyB0aGVyZSdzIHNvbWUgZXhwZWN0YXRpb24gZm9yIHRoZSBzaXplIHRvIGJlIGNvbmZpZ3VyYWJs ZSBvciByZXBvcnRhYmxlLiBJJ20gbm90IHNlZWluZyBhbnkgcmVxdWVzdCBmb3IgdGhlIE1BQyBz aXplIHRvIGJlIGNvbmZpZ3VyZWQgb3IgcmVwb3J0ZWQgdmlhIHRoZSBpbmZvcm1hdGlvbiBtb2Rl bC4gDQoNCkknbSBwcm9wb3Npbmcgbm8gY2hhbmdlIHRvIHRoZSBkZWZpbmVkIHZhbHVlcyBvZiBi YWJlbC1tYWMtYWxnb3JpdGhtcyBpbiBvcmRlciB0byBtYWludGFpbiBjb21wbGV0ZSBjb25zaXN0 ZW5jeSB3aXRoIHRoZSBuYW1lcyB1c2VkIGluIGRyYWZ0LWlldGYtYmFiZWwtaG1hYy0xMi4NCg0K PiAyLiBTZWN0aW9uIDMuOToNCj4gDQo+ICAgIGJhYmVsLWNlcnQtdGVzdDogIEFuIG9wZXJhdGlv biB0aGF0IGFsbG93cyBhIGhhc2ggb2YgdGhlIHByb3ZpZGVkDQo+ICAgICAgIGlucHV0IHN0cmlu ZyB0byBiZSBjcmVhdGVkIHVzaW5nIHRoZSBjZXJ0aWZpY2F0ZSBwdWJsaWMga2V5IGFuZA0KPiAg ICAgICB0aGUgU0hBLTI1NiBoYXNoIGFsZ29yaXRobS4gIElucHV0IHRvIHRoaXMgb3BlcmF0aW9u IGlzIGEgYmluYXJ5DQo+ICAgICAgIHN0cmluZy4gIFRoZSBvdXRwdXQgb2YgdGhpcyBvcGVyYXRp b24gaXMgdGhlIHJlc3VsdGluZyBoYXNoLCBhcyBhDQo+ICAgICAgIGJpbmFyeSBzdHJpbmcuDQo+ IA0KPiBJIGZhaWxlZCB0byB1bmRlcnN0YW5kIHdoYXQgdGhpcyBvcGVyYXRpb24gc2hvdWxkIGRv LiBMaXRlcmFsbHkgcmVhZGluZyBpdCBpcw0KPiBpbnRlbmRlZCB0byBwcm9kdWNlIFNIQTItMjU2 IGhhc2ggb2YgcHVibGljIGtleSBhbmQgc29tZSBhcmJpdHJhcnkgc3RyaW5nDQo+IChjb25jYXRl bmF0ZWQ/IGluIHdoYXQgb3JkZXI/KS4gQnV0IHRoZW4gSSBmYWlsZWQgdG8gdW5kZXJzdGFuZCB0 aGUgcHVycG9zZQ0KPiBvZg0KPiB0aGlzIHRlc3QuIEkgd291bGQgaGF2ZSB1bmRlcnN0b29kIGlm IHRoaXMgb3BlcmF0aW9uIHByb3ZpZGVzIHNpZ25pbmcgb2YgdGhlDQo+IGFyYml0cmFyeSBzdHJp bmcgdXNpbmcgcHJpdmF0ZSBrZXkgYW5kIFNIQTItMjU2IGFzIGEgaGFzaCBmdW5jdGlvbiAoc2lt aWxhcmx5DQo+IHRvIGJhYmVsLW1hYy1rZXktdGVzdCksIGJ1dCBpdCBpbiBub3Qgd2hhdCBpcyB3 cml0dGVuLi4uDQoNCk9uZSBvZiB0aGUgbW9zdCBjb21tb24gcHJvYmxlbXMgaW4gY29uZmlndXJp bmcgc2VjdXJpdHkgbWVjaGFuaXNtcyBpcyBpbiB0aGUgZm9ybWF0IG9mIHRoZSBpbnB1dCBrZXkg KGhleCwgQVNDSUksIGJhc2U2NCwgaGFzaGluZyB0aGF0IG9jY3VycyB0byBjcmVhdGUgImFjdHVh bCBrZXkiLCBldGMuKS4gV2hlbiBhIHNlY3VyaXR5IG1lY2hhbmlzbSBmYWlscyB0byB3b3JrLCBp dCBpcyBpbXBvcnRhbnQgZm9yIHVzZXJzIG9yIGRldmljZSBtYW5hZ2VycyB0byBiZSBhYmxlIHRv IHRyb3VibGUtc2hvb3QgdGhpcyBzcGVjaWZpYyBwb2ludCBvZiBmYWlsdXJlLiBUaGlzIHRlc3Qg YWxsb3dzIHRoZSB1c2VyL21hbmFnZXIgdG8gc2VlIGlmIHdoYXQgdGhpcyBkZXZpY2UgdGhpbmtz IHRoZSBNQUMgc2hvdWxkIGJlIGlzIHRoZSBzYW1lIGFzIHdoYXQgYW5vdGhlciBkZXZpY2UgdGhp bmtzIHRoZSBNQUMgc2hvdWxkIGJlIG9yIGlzIHRoZSBzYW1lIGFzIHRoZSBNQUMgYmVpbmcgc2Vu dCBvbiB0aGUgd2lyZS4gTWFueSBJU1BzIGhhdmUgYnVpbHQgYSB0ZXN0IGxpa2UgdGhpcyBpbnRv IHRoZWlyIElTUC1zdXBwbGllZCBDRSByb3V0ZXJzIChpbnZva2VkIHVzaW5nIHRoZSBUUi0wNjkg cHJvdG9jb2wgYW5kIFRSLTE4MSBkYXRhIG1vZGVsKSB0byB0ZXN0IHZhcmlvdXMgc3RvcmVkIGtl eSB2YWx1ZXMuIEl0IGhhcyBwcm92ZW4gdXNlZnVsLg0KDQo+IDMuIFNlY3Rpb24gNSAoU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMpOg0KPiANCj4gSSB0aGluayB0aGF0IHRleHQgYWJvdXQga2V5cyAo dGhlaXIgbGVuZ3RoIGFuZCBwcm9wZXJ0aWVzKSBuZWVkcyBzb21lDQo+IGV4cGFuc2lvbi4gRmly c3QsIHRoZXJlIGFyZSBubyBhbnkgUkZDMjExOSB3b3JkcyBkaXNjb3VyYWdpbmcgdXNpbmcgc2hv cnQNCj4gYW5kDQo+IHdlYWsga2V5cyAodGhlcmUgaXMgc29tZSB0ZXh0LCBidXQgd2l0aG91dCBS RkMyMTE5IHdvcmRzIGFuZCB3aXRoIG5vDQo+IHJlZmVyZW5jZXMNCj4gaXQncyBqdXN0IGhhbmQg d2F2aW5nKS4gTm90ZSwgdGhhdCBkcmFmdC1pZXRmLWJhYmVsLWhtYWMtMTIgaGFzIHNvbWUgdGV4 dA0KPiBhYm91dA0KPiB0aGUgcHJvcGVydGllcyBvZiB0aGUga2V5cywgc28gSSBiZWxpZXZlIGF0 IGxlYXN0IGl0IG11c3QgYmUgcmVmZXJlbmNlZCBoZXJlLiBJDQo+IGFsc28gc3VzcGVjdCB0aGF0 IGV4cGxpY2l0bHkgYWxsb3dpbmcgemVyby1sZW5ndGggYW5kIHNob3J0IGtleXMgd2lsbCBsZWFk IHRvDQo+IHNpdHVhdGlvbnMgd2hlbiBzb21lIG5ldHdvcmsgb3BlcmF0b3JzIHdpbGwgdXNlIHRo ZW0gKGJlY2F1c2UgdGhleSBhcmUNCj4gbm90DQo+IHByb2hpYml0ZWQpLCB0aHVzIHN1YnZlcnRp bmcgc2VjdXJpdHkgcHJvcGVydGllcyBvZiBNQUMuLi4NCg0KVGhhbmtzLiBJJ2xsIGFkZCBhIHJl ZmVyZW5jZSB0byBkcmFmdC1pZXRmLWJhYmVsLWhtYWMgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMu DQoNClplcm8gbGVuZ3RoIGFuZCBzaG9ydCBrZXlzIHdlcmUgZGlzY3Vzc2VkIG9uIHRoZSBtYWls aW5nIGxpc3QuIFRoZSBncm91cCBjb25zaWRlcmVkIGl0IGFwcHJvcHJpYXRlIHRvDQphbGxvdyBj b25maWd1cmF0aW9uIG9mIHplcm8tbGVuZ3RoIGtleXMgZm9yIHRlc3RpbmcgYnV0IHRvIGFkdmlz ZSBwZW9wbGUgdG8gZm9sbG93IGJlc3QNCmN1cnJlbnQgcHJhY3RpY2VzLiBJIGZpbmQgdGhlIHVz ZSBvZiBub3JtYXRpdmUgbGFuZ3VhZ2UgdG8gYXR0ZW1wdCB0byBjb250cm9sIHRoZSBiZWhhdmlv ciBvZiANCmEgaG9tZSBuZXR3b3JrIG93bmVyIChmb3IgZXhhbXBsZSkgb3Igc29tZW9uZSBzZXR0 aW5nIHVwIGFuIGluZm9ybWFsIGFkIGhvYyBtZXNoDQpuZXR3b3JrIChmb3IgZXhhbXBsZSkgdG8g YmUgb2RkLiBJTU8sIHRoZSBJRVRGIHNob3VsZCBub3Qgc2VlayB0byBjb250cm9sDQp0aGUgY2hv aWNlcyBvZiBwZW9wbGUgcHV0dGluZyB0b2dldGhlciBzdWNoIHJlbGF0aXZlbHkgc21hbGwtc2Nh bGUgbmV0d29ya3MgdGhyb3VnaCANCnRoZSB1c2Ugb2Ygc3Ryb25nIG5vcm1hdGl2ZSBsYW5ndWFn ZSBpbiBhbiBpbmZvcm1hdGlvbiBtb2RlbCBzcGVjaWZpY2F0aW9uLiBJdCdzIA0KaW1wb3NzaWJs ZSB0byBlbmZvcmNlIGFuZCBzdWNoIHBlb3BsZSBwcmV0dHkgbXVjaCBuZXZlciByZWFkIFJGQ3Mu DQoNCklmIHRoZXJlIGlzIGEgc3Ryb25nIGRlc2lyZSBmb3Igc29tZSBzb3J0IG9mIG5vcm1hdGl2 ZSBsYW5ndWFnZSwgdGhlbiBJIGNvdWxkIHN1Z2dlc3QNCk9MRA0KICAgTUFDIGtleXMgYXJlIGFs bG93ZWQgdG8gYmUgYXMgc2hvcnQgYXMgemVyby1sZW5ndGguICBUaGlzIGlzIHVzZWZ1bA0KICAg Zm9yIHRlc3RpbmcuICBOZXR3b3JrIG9wZXJhdG9ycyBhcmUgYWR2aXNlZCB0byBmb2xsb3cgY3Vy cmVudCBiZXN0DQogICBwcmFjdGljZXMgZm9yIGtleSBsZW5ndGggYW5kIGdlbmVyYXRpb24gb2Yg a2V5cyByZWxhdGVkIHRvIHRoZSBNQUMNCiAgIGFsZ29yaXRobSBhc3NvY2lhdGVkIHdpdGggdGhl IGtleS4gIFNob3J0IChhbmQgemVyby1sZW5ndGgpIGtleXMgYW5kDQogICBrZXlzIHRoYXQgbWFr ZSB1c2Ugb2Ygb25seSBhbHBoYW51bWVyaWMgY2hhcmFjdGVycyBhcmUgaGlnaGx5DQogICBzdXNj ZXB0aWJsZSB0byBicnV0ZSBmb3JjZSBhdHRhY2tzLg0KTkVXDQogICBNQUMga2V5cyBhcmUgYWxs b3dlZCB0byBiZSBhcyBzaG9ydCBhcyB6ZXJvLWxlbmd0aC4gIFRoaXMgaXMgdXNlZnVsDQogICBm b3IgdGVzdGluZy4gIE5ldHdvcmsgb3BlcmF0b3JzIGFyZSBSRUNPTU1FTkRFRCB0byBmb2xsb3cg Y3VycmVudCBiZXN0DQogICBwcmFjdGljZXMgZm9yIGtleSBsZW5ndGggYW5kIGdlbmVyYXRpb24g b2Yga2V5cyByZWxhdGVkIHRvIHRoZSBNQUMNCiAgIGFsZ29yaXRobSBhc3NvY2lhdGVkIHdpdGgg dGhlIGtleS4gIFNob3J0IChhbmQgemVyby1sZW5ndGgpIGtleXMgYW5kDQogICBrZXlzIHRoYXQg bWFrZSB1c2Ugb2Ygb25seSBhbHBoYW51bWVyaWMgY2hhcmFjdGVycyBhcmUgaGlnaGx5DQogICBz dXNjZXB0aWJsZSB0byBicnV0ZSBmb3JjZSBhdHRhY2tzLiBTZWUgdGhlIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zDQogIHNlY3Rpb24gb2YgW0lELmRyYWZ0LWlldGYtYmFiZWwtaG1hY10gZm9yIGFk ZGl0aW9uYWwgY29uc2lkZXJhdGlvbnMgDQogIHJlbGF0ZWQgdG8gTUFDIGtleXMuDQoNCj4gTml0 cy4NCj4gDQo+IDEuIFNlY3Rpb24gMSAoSW50cm9kdWN0aW9uKToNCj4gDQo+ICAgIFtJLUQuaWV0 Zi1iYWJlbC1obWFjXSBkZWZpbmVzIGENCj4gICAgc2VjdXJpdHkgbWVjaGFuaXNtIHRoYXQgYWxs b3dzIEJhYmVsIHBhY2tldHMgdG8gYmUgY3J5cHRvZ3JhcGhpY2FsbHkNCj4gICAgYXV0aGVudGlj YXRlZCwgYW5kIFtJLUQuaWV0Zi1iYWJlbC1kdGxzXSBkZWZpbmVzIGEgc2VjdXJpdHkgbWVjaGFu aXNtDQo+ICAgIHRoYXQgYWxsb3dzIEJhYmVsIHBhY2tldHMgdG8gYmUgZW5jcnlwdGVkLg0KPiAN Cj4gRFRMUyBwcm92aWRlcyBib3RoIGNvbmZpZGVudGlhbGl0eSBhbmQgYXV0aGVudGljYXRpb24g b2YgZGF0YSwgc28gdG8gYmUNCj4gZm9ybWFsbHkgY29ycmVjdCwgcGxlYXNlIGFkZCAiYm90aCBh dXRoZW50aWNhdGVkIGFuZCIgYmVmb3JlICJlbmNyeXB0ZWQiLg0KDQpUaGFuayB5b3UuIEkgd2ls bCBtYWtlIHRoaXMgY2hhbmdlLg0KIA0KPiAyLiBTZWN0aW9uIDIgKE92ZXJ2aWV3KSBhdCB0aGUg dmVyeSBlbmQ6DQo+IA0KPiAgICBOb3RlIHRoYXQgdGhpcyBvdmVydmlldyBpcyBpbnRlbmRlZCBz aW1wbHkgdG8gYmUgaW5mb3JtYXRpdmUgYW5kIGlzDQo+ICAgIG5vdCBub3JtYXRpdmUuICBJZiB0 aGVyZSBpcyBhbnkgZGlzY3JlcGFuY3kgYmV0d2VlbiB0aGlzIG92ZXJ2aWV3IGFuZA0KPiAgICB0 aGUgZGV0YWlsZWQgaW5mb3JtYXRpb24gbW9kZWwgZGVmaW5pdGlvbnMgaW4gc3Vic2VxdWVudCBz ZWN0aW9ucywNCj4gICAgdGhlIGVycm9yIGlzIGluIHRoaXMgb3ZlcnZpZXcuDQo+IA0KPiBUaGlz IHBocmFzZSBtYWtlcyBtZSBwdXp6bGVkLiBUaGUgdHJlZS1saWtlIGRlc2NyaXB0aW9uIG9mIHRo ZSBpbmZvcm1hdGlvbg0KPiBtb2RlbCBpbiB0aGUgT3ZlcnZpZXcgaXMgdmVyeSB1c2VmdWwsIGhv d2V2ZXIgdGhpcyBwaHJhc2Ugc2VlbXMgdG8NCj4gZGlzY291cmFnZQ0KPiB1c2luZyBpdCwgYmVj YXVzZSBhdXRob3JzIGFyZSBub3Qgc3VyZSBpdCBpcyBjb3JyZWN0LiBJIHRoaW5rIGl0IHdvdWxk IGJlDQo+IGJldHRlciBmb3IgcmVhZGVycyBpZiBhdXRob3JzIGRvdWJsZSBjaGVjayB0aGF0IG5v IGRpc2NyZXBhbmN5IGV4aXN0cw0KPiBiZXR3ZWVuDQo+IHRoZSBvdmVydmlldyBhbmQgdGhlIHN1 YnNlcXVlbnQgZGV0YWlsZWQgZGVzY3JpcHRpb24gYW5kIHJlbW92ZSB0aGlzDQo+IHBocmFzZS4N Cg0KVGhlIGF1dGhvcnMgaGF2ZSBkb3VibGUtIGFuZCB0cmlwbGUtY2hlY2tlZCwgYnV0IGh1bWFu IGVycm9yIGlzIHN0aWxsIHBvc3NpYmxlLCBzaW5jZSB0aGVzZSB3ZXJlIG5vdCBhdXRvLWdlbmVy YXRlZCAobGlrZSBZQU5HIGRvZXMpLiBXaGVuZXZlciByZWR1bmRhbnQgaW5mb3JtYXRpb24gaXMg cHJlc2VudGVkLCBpdCBpcyBjcml0aWNhbCB0aGF0IGl0IGJlIG5vcm1hdGl2ZSBpbiBvbmx5IG9u ZSBwbGFjZS4gVGhpcyBsYW5ndWFnZSBtYWtlcyBpdCBjbGVhciB3aGljaCBpcyBub3JtYXRpdmUg YW5kIHdoYXQgdG8gZG8gaW4gdGhlIGNhc2Ugb2YgZGlzY3JlcGFuY2llcy4gSSBwcm9wb3NlIG5v IGNoYW5nZS4gSWYgdGhlcmUgaXMgYSBzdHJvbmcgcHVzaCB0byByZW1vdmUgdGhpcyBsYW5ndWFn ZSwgdGhlbiBJIGJlbGlldmUgdGhlIGNvcnJlY3QgYXBwcm9hY2ggd291bGQgYmUgdG8gcmVtb3Zl IHRoZSBlbnRpcmUgc2VjdGlvbiAocmVtb3ZlIHRoZSByZWR1bmRhbmN5KSByYXRoZXIgdGhhbiB0 byBhbGxvdyBjb25mdXNpb24gaWYgdGhlcmUgaXMgYW4gZXJyb3IuIEJ1dCBwZW9wbGUgaGF2ZSBm b3VuZCB0aGlzIHNlY3Rpb24gdXNlZnVsLCBzbyBJIHdvdWxkIHByZWZlciB0byBsZWF2ZSBpdCBh cyBpcy4NCiANCj4gMy4gU2VjdGlvbiAzLjM6DQo+IA0KPiAgICBiYWJlbC1tYWMtdmVyaWZ5ICBB IEJvb2xlYW4gZmxhZyBpbmRpY2F0aW5nIHdoZXRoZXIgTUFDIGhhc2hlcyBpbg0KPiAgICAgICBp bmNvbWluZyBCYWJlbCBwYWNrZXRzIGFyZSByZXF1aXJlZCB0byBiZSBwcmVzZW50IGFuZCBhcmUN Cj4gICAgICAgdmVyaWZpZWQuICBJZiB0aGlzIHBhcmFtZXRlciBpcyAidHJ1ZSIsIGluY29taW5n IHBhY2tldHMgYXJlDQo+ICAgICAgIHJlcXVpcmVkIHRvIGhhdmUgYSB2YWxpZCBNQUMgaGFzaC4g IEFuIGltcGxlbWVudGF0aW9uIE1BWSBjaG9vc2UNCj4gICAgICAgdG8gZXhwb3NlIHRoaXMgcGFy YW1ldGVyIGFzIHJlYWQtb25seSAoInJvIikuDQo+IA0KPiAiTUFDIGhhc2hlcyIgaXMgc3RyYW5n ZSB3b3JkaW5nLCAiTUFDIHZhbHVlcyIgb3IganVzdCAiTUFDcyIgYXJlIGJldHRlciBpbg0KPiBt eQ0KPiBvcGluaW9uLg0KDQpUaGFuayB5b3UuIEknbGwgY2hhbmdlIGl0IHRvIE1BQy4NCg0KPiA0 LiBTZWN0aW9uIDMuODoNCj4gDQo+ICAgIGJhYmVsLW1hYy1rZXktdXNlLXNpZ246ICBJbmRpY2F0 ZXMgd2hldGhlciB0aGlzIGtleSB2YWx1ZSBpcyB1c2VkIHRvDQo+ICAgICAgIHNpZ24gc2VudCBC YWJlbCBwYWNrZXRzLiAgU2VudCBwYWNrZXRzIGFyZSBzaWduZWQgdXNpbmcgdGhpcyBrZXkNCj4g ICAgICAgaWYgdGhlIHZhbHVlIGlzICJ0cnVlIi4gIElmIHRoZSB2YWx1ZSBpcyAiZmFsc2UiLCB0 aGlzIGtleSBpcyBub3QNCj4gICAgICAgdXNlZCB0byBzaWduIHNlbnQgQmFiZWwgcGFja2V0cy4g IEFuIGltcGxlbWVudGF0aW9uIE1BWSBjaG9vc2UgdG8NCj4gICAgICAgZXhwb3NlIHRoaXMgcGFy YW1ldGVyIGFzIHJlYWQtb25seSAoInJvIikuDQo+IA0KPiAiU2lnbiIgaXMgbm90IGEgZ29vZCB3 b3JkIHdoZW4geW91IGRlc2NyaWJlIHN5bW1ldHJpYyBrZXkgb3BlcmF0aW9ucw0KPiAod2hpY2gN Cj4gY29tcHV0aW5nIE1BQyBiZWxvbmdzIHRvKS4gQWx0aG91Z2ggaXQgaXMgb2Z0ZW4gdXNlZCBp bmZvcm1hbGx5LCBJIHRoaW5rIHRoYXQNCj4gUkZDIHNob3VsZCBiZSBtb3JlIG1ldGljdWxvdXMg aW4gc2VsZWN0aW5nIHdvcmRzLiBJJ2QgcmF0aGVyIHJlcGxhY2UgaXQgd2l0aA0KPiAiY29tcHV0 ZSBNQUMiIGFuZCByZW5hbWUgdGhlIGVudHJ5IHRvIGJhYmVsLW1hYy1rZXktdXNlLWNvbXB1dGUg b3INCj4gYmFiZWwtbWFjLWtleS11c2UtbWFjIChpZiBpdCBpcyBwb3NzaWJsZSkuIE5vdGUsIHRo YXQgdXNpbmcgInZlcmlmeSBNQUMiIGlzIE9LLg0KDQpJJ3ZlIGJlZW4gdGhpbmtpbmcgdGhyb3Vn aCB0aGlzLiBJIGNhbid0IHNwZWFrIHRvIHRoZSBpbmZvcm1hbCBuYXR1cmUgb2YgInNpZ24iLCBi dXQgSSBjYW4gc2F5IHRoYXQgc2ltcGx5IHJlcGxhY2luZyAic2lnbiIgd2l0aCAiY29tcHV0ZSIg b3IgIm1hYyIgd291bGRuJ3QgY29udmV5IGNvcnJlY3RseSB3aGF0IHRoaXMgcGFyYW1ldGVyIGlz IGFib3V0LiBUaGlzIHBhcmFtZXRlciBpcyBwcmltYXJpbHkgY29uY2VybmVkIHdpdGggd2hldGhl ciBvciBub3QgYSBNQUMgaXMgaW5jbHVkZWQgaW4gdGhlIHNlbnQgcGFja2V0LiBUaGUgc2VuZGlu ZyBpcyB0aGUgY3JpdGljYWwgcGllY2UsIGFuZCBub3QgdGhlIGNvbXB1dGluZyAoaXQncyBwb3Nz aWJsZSB0byBjb21wdXRlIHRoZSBNQUMgd2l0aG91dCBzZW5kaW5nIGl0OyBhIE1BQyBpbiBhIHNl bnQgcGFja2V0IGlzIGFzc3VtZWQgdG8gaGF2ZSBiZWVuIGNvbXB1dGVkKS4gSSBjb3VsZCBjaGFu Z2UgdGhlIGRlc2NyaXB0aW9uIHRvOg0KICAgICAgIEluZGljYXRlcyB3aGV0aGVyIHRoaXMga2V5 IHZhbHVlIGlzIHVzZWQgdG8gY29tcHV0ZSBhIE1BQyBhbmQgaW5jbHVkZSB0aGF0IE1BQyBpbiB0 aGUNCiAgICAgICBzZW50IEJhYmVsIHBhY2tldC4gIEEgTUFDIGZvciBzZW50IHBhY2tldHMgaXMg Y29tcHV0ZWQgdXNpbmcgdGhpcyBrZXkNCiAgICAgICBpZiB0aGUgdmFsdWUgaXMgInRydWUiLiAg SWYgdGhlIHZhbHVlIGlzICJmYWxzZSIsIHRoaXMga2V5IGlzIG5vdA0KICAgICAgIHVzZWQgdG8g Y29tcHV0ZSBhIE1BQyB0byBpbmNsdWRlIGluIHNlbnQgQmFiZWwgcGFja2V0cy4gIEFuIGltcGxl bWVudGF0aW9uIE1BWSBjaG9vc2UgdG8NCiAgICAgICBleHBvc2UgdGhpcyBwYXJhbWV0ZXIgYXMg cmVhZC1vbmx5ICgicm8iKQ0KDQpCdXQgSSBzdHJ1Z2dsZSB3aXRoIHRoZSBwcm9wb3NlZCBwYXJh bWV0ZXIgcmVuYW1pbmcuIEkgc3Ryb25nbHkgYmVsaWV2ZSB0aGUgbmFtZSBzaG91bGQgY29uY2lz ZWx5IGRlc2NyaWJlIHRoYXQgdGhlIEJvb2xlYW4gdmFsdWUgaW5kaWNhdGVzIHdoZXRoZXIgb3Ig bm90IHRvIGluY2x1ZGUgYSBNQUMgaW4gdGhlIHNlbnQgcGFja2V0LiBUaGUgdGVybSAic2lnbiIg aXMgb25lIEkndmUgY29tbW9ubHkgc2VlbiB0byBpbmRpY2F0ZSB0aGF0IGEgTUFDIGlzIGluY2x1 ZGVkIGluIHRoZSBzZW50IHBhY2tldC4gSSdtIG5vdCBhd2FyZSBvZiBhIGRpZmZlcmVudCwgc2lt aWxhcmx5IHNob3J0IHdvcmQuICJDb21wdXRlIiBhbmQgIm1hYyIgZG8gbm90IGNvbnZleSB0aGUg c2VuZGluZyBhc3BlY3QuIEFuZCBzZW5kaW5nIGlzIHZlcnkgYXN5bW1ldHJpYy4NCiANCj4gNS4g U2VjdGlvbiAzLjg6DQo+IA0KPiAgICBiYWJlbC1tYWMta2V5LXZhbHVlOg0KPiAgICAgICAgLi4u DQo+ICAgICAgIFRoaXMgdmFsdWUgaXMgb2YgYSBsZW5ndGggc3VpdGFibGUgZm9yIHRoZSBhc3Nv Y2lhdGVkIGJhYmVsLW1hYy1rZXktDQo+ICAgICAgIGFsZ29yaXRobS4gIElmIHRoZSBhbGdvcml0 aG0gaXMgYmFzZWQgb24gdGhlIEhNQUMgY29uc3RydWN0aW9uDQo+ICAgICAgIFtSRkMyMTA0XSwg dGhlIGxlbmd0aCBNVVNUIGJlIGJldHdlZW4gMCBhbmQgdGhlIGJsb2NrIHNpemUgb2YgdGhlDQo+ ICAgICAgIHVuZGVybHlpbmcgaGFzaCBpbmNsdXNpdmUgKHdoZXJlICJITUFDLVNIQTI1NiIgYmxv Y2sgc2l6ZSBpcyA2NA0KPiAgICAgICBieXRlcyBhcyBkZXNjcmliZWQgaW4gW1JGQzQ4NjhdKS4g IElmIHRoZSBhbGdvcml0aG0gaXMgIkJMQUtFMnMiLA0KPiAgICAgICB0aGUgbGVuZ3RoIE1VU1Qg YmUgYmV0d2VlbiAwIGFuZCAzMiBieXRlcyBpbmNsdXNpdmUsIGFzIGRlc2NyaWJlZA0KPiAgICAg ICBpbiBbUkZDNzY5M10uDQo+IA0KPiBJIHdvbmRlciBvZiB0aGUgcmF0aW9uYWxlIGZvciBpbXBv c2luZyB0aGUgYWJvdmUgcmVzdHJpY3Rpb25zIG9uIEhNQUMga2V5DQo+IGxlbmd0aC4gSE1BQyBj YW4gdXNlIGtleXMgb2YgYW55IGxlbmd0aCwgYnV0IGlmIHRoZSBrZXkgaXMgZ3JlYXRlciB0aGFu IGJsb2NrDQo+IHNpemUgb2YgdW5kZXJseWluZyBoYXNoIGZ1bmN0aW9uLCB0aGVuIGl0J3MgZmly c3QgaGFzaGVkIChzbWFsbCBwZXJmb3JtYW5jZQ0KPiBwZW5hbHR5KS4gU28gSSBpbWFnaW5lIHRo YXQgdGhlIHJhdGlvbmFsZSBpcyB0byBhdm9pZCB0aGlzIHBlbmFsdHkuIEhvd2V2ZXIsIGFzDQo+ IFJGQzIxMDQgc3RhdGVzLCBrZXkgc2l6ZXMgZ3JlYXRlciB0aGFuIG91dHB1dCBsZW5ndGggb2Yg dGhlIHVuZGVybHlpbmcgaGFzaA0KPiBmdW5jdGlvbiAoMzIgYnl0ZXMgaW4gY2FzZSBvZiBTSEEy LTI1Nikgd291bGQgbm90IHNpZ25pZmljYW50bHkgaW5jcmVhc2UgdGhlDQo+IGZ1bmN0aW9uIHN0 cmVuZ3RoLCBzbyBpdCdzIGp1c3QgYSB3YXN0ZSBvZiBzcGFjZS4gU2VlIGFsc28gSXNzdWUgMyBh Ym92ZS4NCg0KSnVsaXVzeiBzYWlkOg0KPiBUaGlzIHdhcyBkaXNjdXNzZWQgYXQgbGVuZ3RoIG9u IHRoZSBtYWlsaW5nIGxpc3QuICBJdCdzIG5vdCBhYm91dA0KPiBwZXJmb3JtYW5jZSwgaXQncyBh Ym91dCBtYWtpbmcgaXQgbW9yZSBkaWZmaWN1bHQgdG8gdXNlIGFuIHVuc2FmZQ0KPiBwcm9jZWR1 cmUgZm9yIGdlbmVyYXRpbmcga2V5cy4NCj4gDQo+IFNpbmNlIEJhYmVsLU1BQyBpcyB2dWxuZXJh YmxlIHRvIGRpY3Rpb25hcnkgYXR0YWNrcywgdGhlIGtleSBtdXN0IGVpdGhlcg0KPiBiZSBkcmF3 biByYW5kb21seSBvciBnZW5lcmF0ZWQgdXNpbmcgYSBwcm9jZWR1cmUgdGhhdCBpcyBoYXJkZW5l ZCBhZ2FpbnN0DQo+IHN1Y2ggYXR0YWNrcyAoc2NyeXB0LCBldGMuKS4gIEFwcGx5aW5nIHRoZSBw cm9jZWR1cmUgZGVzY3JpYmVkIGluIFJGQyAyMTA0DQo+IHRvIGEgdXNlci1wcm92aWRlZCBwYXNz cGhyYXNlIGlzIG5vdCBzYWZlLCBhbmQgdGhlcmVmb3JlIHdlIHRyeSB0byBtYWtlIGl0DQo+IGRp ZmZpY3VsdCBmb3IgYSBuYWl2ZSB1c2VyIHRvIGRvIHNvLg0KPiANCj4gSSBhbSBvcHBvc2VkIHRv IHB1dHRpbmcgdGhlIFJGQyAyMTA0IGhhc2hpbmcgcHJvY2VkdXJlIGluIHRoZSBpbmZvcm1hdGlv bg0KPiBtb2RlbC4gIERvaW5nIHNvIHdvdWxkIGJlIGEgZGlzc2VydmljZSB0byBvdXIgdXNlcnMu DQoNCkluIGFkZGl0aW9uIHRvIHRoZSByYXRpb25hbGUgSnVsaXVzeiBtZW50aW9uZWQsIHdlIChi YWJlbCBXRykgYWxzbyBub3RlZCB0aGF0IGltcGxlbWVudGVycw0Kb2YgdGhlIGJhYmVsIE1BQyBm dW5jdGlvbiB3ZXJlIHVzaW5nIGV4aXN0aW5nIGxpYnJhcmllcyBmb3IgdGhlIEhNQUMtU0hBMjU2 IGFsZ29yaXRobS4NClRoZSB1c2VyIGludGVyZmFjZSAoVUkpIHRoYXQgYWNjZXB0ZWQgbWFudWFs IGtleSBlbnRyeSB3YXMgYWxzbyBmcm9tIGFuIGV4aXN0aW5nIGxpYnJhcnkuIFdoZW4NCnRoZSBz YW1lIGxvbmdlciBzdHJpbmdzIHdlcmUgZW50ZXJlZCBpbnRvIGRpZmZlcmVudCBVSXMgb2YgdGhl IGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMsIHRoZXNlDQpzdHJpbmdzIHdlcmUgdHJlYXRlZCBk aWZmZXJlbnRseSBhbmQgcmVzdWx0ZWQgaW4gbm9uLWludGVyb3BlcmFiaWxpdHkuIFRoZSAiYWN0 dWFsIGtleSIgKHVzaW5nDQpSRkMgMjEwNCB3b3JkcykgZW5kZWQgdXAgZGlmZmVyZW50LiBSZXF1 aXJpbmcgZW50ZXJlZCBrZXlzIHRvIGJlIGRpcmVjdGx5IHVzYWJsZSBhcyAiYWN0dWFsDQprZXlz IiBzb2x2ZWQgdGhpcyBwcm9ibGVtLiBCVFcsIEkgaGF2ZSBjb25zaWRlcmVkIFVJcyBmb3IgZGly ZWN0IG1hbmFnZW1lbnQgYW5kIGNvbmZpZ3VyYXRpb24NCnRvIGVmZmVjdGl2ZWx5IGJlIGltcGxl bWVudGF0aW9ucyBvZiB0aGUgaW5mb3JtYXRpb24gbW9kZWwuIA0KDQpJIHJlY29tbWVuZCBubyBj aGFuZ2VzIHRvIHRoaXMgdGV4dC4NCiANCj4gNi4gICAgU2VjdGlvbiAzLjg6DQo+IA0KPiAgICBi YWJlbC1tYWMta2V5LXRlc3Q6ICBBbiBvcGVyYXRpb24gdGhhdCBhbGxvd3MgdGhlIE1BQyBrZXkg YW5kIGhhc2gNCj4gICAgICAgYWxnb3JpdGhtIHRvIGJlIHRlc3RlZCB0byBzZWUgaWYgdGhleSBw cm9kdWNlIGFuIGV4cGVjdGVkIG91dGNvbWUuDQo+ICAgICAgIElucHV0IHRvIHRoaXMgb3BlcmF0 aW9uIGlzIGEgYmluYXJ5IHN0cmluZy4gIFRoZSBpbXBsZW1lbnRhdGlvbiBpcw0KPiAgICAgICBl eHBlY3RlZCB0byBjcmVhdGUgYSBoYXNoIG9mIHRoaXMgc3RyaW5nIHVzaW5nIHRoZSBiYWJlbC1t YWMta2V5LQ0KPiAgICAgICB2YWx1ZSBhbmQgdGhlIGJhYmVsLW1hYy1rZXktYWxnb3JpdGhtLiAg VGhlIG91dHB1dCBvZiB0aGlzDQo+ICAgICAgIG9wZXJhdGlvbiBpcyB0aGUgcmVzdWx0aW5nIGhh c2gsIGFzIGEgYmluYXJ5IHN0cmluZy4NCj4gDQo+IFRoZSB0ZXh0IG1peGVzIHVwIHdvcmRzICJo YXNoIiBhbmQgIk1BQyIuIE1BQyBpcyBub3QgYSBoYXNoIChldmVuIGlmIE1BQw0KPiBhbGdvcml0 aG0gaXMgb2Z0ZW4gYmFzZWQgb24gaGFzaCBmdW5jdGlvbikuIEFzIHdpdGggbXkgcHJldmlvdXMg Z3J1bnQsIEknZCBsaWtlDQo+IFJGQyB0byBiZSBtb3JlIG1ldGljdWxvdXMgaW4gc2VsZWN0aW5n IHdvcmRzLiBQbGVhc2UsIGF2b2lkIHVzaW5nICJoYXNoIg0KPiBoZXJlLg0KDQpJZiBJIHVuZGVy c3RhbmQsIHRoZSBzdWdnZXN0aW9uIGlzIHRvIHJld29yZCBhczoNCiAgIGJhYmVsLW1hYy1rZXkt dGVzdDogIEFuIG9wZXJhdGlvbiB0aGF0IGFsbG93cyB0aGUgTUFDIGtleSBhbmQgTUFDDQogICAg ICBhbGdvcml0aG0gdG8gYmUgdGVzdGVkIHRvIHNlZSBpZiB0aGV5IHByb2R1Y2UgYW4gZXhwZWN0 ZWQgb3V0Y29tZS4NCiAgICAgIElucHV0IHRvIHRoaXMgb3BlcmF0aW9uIGlzIGEgYmluYXJ5IHN0 cmluZy4gIFRoZSBpbXBsZW1lbnRhdGlvbiBpcw0KICAgICAgZXhwZWN0ZWQgdG8gY3JlYXRlIGEg TUFDIG9mIHRoaXMgc3RyaW5nIHVzaW5nIHRoZSBiYWJlbC1tYWMta2V5LQ0KICAgICAgdmFsdWUg YW5kIHRoZSBiYWJlbC1tYWMta2V5LWFsZ29yaXRobS4gIFRoZSBvdXRwdXQgb2YgdGhpcw0KICAg ICAgb3BlcmF0aW9uIGlzIHRoZSByZXN1bHRpbmcgTUFDLCBhcyBhIGJpbmFyeSBzdHJpbmcuDQoN CklmIHRoaXMgaXMgcmlnaHQsIEknbGwgbWFrZSB0aGF0IGNoYW5nZS4NCg0KPiA3LiBTZWN0aW9u IDUgKFNlY3VyaXR5IENvbnNpZGVyYXRpb25zKToNCj4gDQo+ICAgIC4uLiBUaGlzIG1vZGVsIHJl cXVpcmVzIHRoYXQgcHJpdmF0ZSBrZXlzIG5ldmVyIGJlDQo+ICAgIGV4cG9zZWQuICBUaGUgQmFi ZWwgc2VjdXJpdHkgbWVjaGFuaXNtcyB0aGF0IG1ha2UgdXNlIG9mIHRoZXNlDQo+ICAgIGNyZWRl bnRpYWxzIChlLmcuLCBbSS1ELmlldGYtYmFiZWwtZHRsc10sIFtJLUQuaWV0Zi1iYWJlbC1obWFj XSkNCj4gICAgaWRlbnRpZnkgd2hhdCBjcmVkZW50aWFscyBjYW4gYmUgdXNlZCB3aXRoIHRob3Nl IG1lY2hhbmlzbXMuDQo+IA0KPiBQbGVhc2UgYWRkICJhbmQgTUFDIGtleXMiIGFmdGVyICJwcml2 YXRlIGtleXMiIHNpbmNlIGZvcm1hbGx5IHByaXZhdGUga2V5cw0KPiBhcmUNCj4gb25seSBkZWZp bmVkIGZvciBwdWJsaWMga2V5IGNyeXB0b2dyYXBoeS4NCg0KVGhhbmsgeW91LiBJJ2xsIG1ha2Ug dGhpcyBjaGFuZ2UuDQogDQo+IDguIFNlY3Rpb24gNSAoU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMp Og0KPiANCj4gICAgTUFDIGtleXMgYXJlIGFsbG93ZWQgdG8gYmUgYXMgc2hvcnQgYXMgemVyby1s ZW5ndGguICBUaGlzIGlzIHVzZWZ1bA0KPiAgICBmb3IgdGVzdGluZy4NCj4gDQo+IEkgd29uZGVy IHdoYXQncyBiZW5lZml0IG9mIGFsbG93aW5nIHplcm8tbGVuZ3RoIGtleXMgZm9yIHRlc3Rpbmcg cHVycG9zZXMuDQo+IFdoYXQNCj4gaXMgaW50ZW5kZWQgdG8gYmUgdGVzdGVkIGluIHRoaXMgY2Fz ZT8gSW1wbGVtZW50YXRpb24gb2YgTUFDPyBJcyBpdCByZWFsbHkNCj4gbmVlZGVkIG91dHNpZGUg dGVzdCBsYWI/IEFtIEkgbWlzc2luZyBzb21ldGhpbmc/DQoNCkFzIHdpdGggdGhlIC10ZXN0IGFj dGlvbnMsIHRoaXMgYWxsb3dzIHNvbWVvbmUgdG8gZGlhZ25vc2Ugd2hldGhlciBhIHByb2JsZW0g dGhleSBhcmUgaGF2aW5nIGlzIHdpdGggdGhlIGZvcm1hdHRpbmcgDQpvZiB0aGUgaW5wdXQga2V5 IChoZXgsIHBhZGRlZCwgQVNDSUksIGJhc2U2NCwgZXRjLikuIFRoaXMgaXMgYnkgZmFyIG9uZSBv ZiB0aGUgbW9zdCBjb21tb24gcHJvYmxlbXMgd2hlbiBhdHRlbXB0aW5nIHRvDQpnZXQgZGlmZmVy ZW50IGltcGxlbWVudGF0aW9ucyB0byBpbnRlcm9wZXJhdGUuDQoNCj4gOS4gU2VjdGlvbiA1IChT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyk6DQo+IA0KPiAgICAgU2hvcnQgKGFuZCB6ZXJvLWxlbmd0 aCkga2V5cyBhbmQNCj4gICAga2V5cyB0aGF0IG1ha2UgdXNlIG9mIG9ubHkgYWxwaGFudW1lcmlj IGNoYXJhY3RlcnMgYXJlIGhpZ2hseQ0KPiAgICBzdXNjZXB0aWJsZSB0byBicnV0ZSBmb3JjZSBh dHRhY2tzLg0KPiANCj4gRm9ybWFsbHksIGJydXRlIGZvcmNlIGF0dGFjayB3aXRoIHplcm8tbGVu Z3RoIGtleXMgaXMgbm90IGRlZmluZWQsIHNpbmNlIHRoZXJlDQo+IGlzIG5vIGtleSB0byBmaW5k IGFuZCBhbGwgaXMgaW4gY2xlYXIuDQoNCkp1bGl1c3ogc2FpZDoNCj4gVGhlIGtleSBsZW5ndGgg aXMgbm90IGNhcnJpZWQgaW4gdGhlIGNsZWFyIGJ5IHRoZSBwcm90b2NvbC4gIEd1ZXNzaW5nIHRo ZQ0KPiBrZXkgbGVuZ3RoIHJlcXVpcmVzIGEgYnJ1dGUtZm9yY2UgYXR0YWNrLCBldmVuIHdoZW4g aXQgaXMgemVyby4NCg0KSSBwcm9wb3NlIG5vIGNoYW5nZS4gDQoNCj4gQ29tbWVudHMuDQo+IA0K PiAxLiBUaGUgZG9jdW1lbnQgY29udGFpbnMgYW4gZW50cnkgaW4gdGhlIEluZm9ybWF0aW9uYWwg bW9kZWwgZGVmaW5pbmcgd2hpY2gNCj4gaGFzaCBmdW5jdGlvbnMgY2FuIGJlIHVzZWQgd2l0aCBI TUFDIGF1dGhlbnRpY2F0aW9uLiBIb3dldmVyLCB0aGVyZSBpcyBubw0KPiBjb3JyZXNwb25kaW5n IGVudHJ5IG9mIHdoaWNoIGNpcGhlcnN1aXRlcyBjYW4gYmUgdXNlZCB3aXRoIERUTFMuIElzIGl0 IHVwIHRvDQo+IERUTFMgbGlicmFyeSB0byBzZWxlY3QgY2lwaGVyc3VpdGVzPw0KDQpKdWxpdXN6 IHNhaWQ6DQo+IFllcy4gIEJhYmVsLURUTFMgaXMgaW50ZW5kZWQgdG8gaW5oZXJpdCB0aGUgc2Vj dXJpdHkgcHJvcGVydGllcyBvZiB0aGUNCj4gc3lzdGVtJ3MgRFRMUyBsaWJyYXJ5LiAgSWYgdGhl IERUTFMgbGlicmFyeSBpcyB1bnNhZmUsIHRoZW4gQmFiZWwtRFRMUw0KPiBtdXN0IG5vdCBiZSB1 c2VkIHVudGlsIHRoZSBsaWJyYXJ5IGlzIGZpeGVkLg0K From nobody Thu Nov 5 00:31:20 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFE93A0CED; Thu, 5 Nov 2020 00:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smyslov.net 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 ZjB8NjI-AlW4; Thu, 5 Nov 2020 00:31:10 -0800 (PST) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE383A0D7A; Thu, 5 Nov 2020 00:31:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:In-Reply-To:References:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=smyp4gkeyr/QM4VbvelMhjEzUww+uXapWogK8oE8R7A=; b=HDpyQF2mLvcKHeyjbl9ta4f0d3 MDvIrKrQMvHMJTBIjGsq/Tl8e1XK7kBuH06OAgn+g4hoj7vjBKBim4zvyJU6OqmEkf8PEQD0PN8rn YZFXUiT+FxJ2K4Vgd1XKTAesGLzejU9N1TFNrG3jcZup35qg8xthJYpRjPt+9QW+8kc4ohYWobz9b 6mUIylQga+1H5jR0gngYA/ShjzO7ucqOSDUAFaOBoPdhGgbm3nj6u0eYrdmgMmhMBLl/rfs+qV3Q9 zEkv0AKPmBLQheNmteZvFpFzRKMpcNt6NoTMw8gJyrrSQkrG9IZ0aTir8BI8NDqFf2k/8DSNrKT8b znD4/iyQ==; Received: from [93.188.44.203] (port=52799 helo=buildpc) by direct.host-care.com with esmtpsa (TLS1.2) tls TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kaafh-0004KO-0N; Thu, 05 Nov 2020 03:31:06 -0500 From: "Valery Smyslov" To: "'STARK, BARBARA H'" , Cc: , , References: <160372407981.20077.17795340180313190981@ietfa.amsl.com> In-Reply-To: Date: Thu, 5 Nov 2020 11:30:50 +0300 Message-ID: <000c01d6b34d$fc3bf5d0$f4b3e170$@smyslov.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQLzl3GE/vg7EqYbxZxh9fZc9poL0gGkJUa0p3IwJ7A= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-babel-information-model-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 08:31:13 -0000 Hi Barbara, > Hi Valery, > Thanks for your review. Taking into account Juliusz' response to your email, I'm proposing the following > resolutions. For the first issue raised, I'm disagreeing slightly with Juliusz, so that may need further discussion. > Please let me know if you disagree. I've copied Juliusz' responses here, so I can include my responses to your > complete feedback and his in one email. > Roman specifically mentioned he agreed with your "recommendations about precise language around the > names of the parameters". I think perhaps this was in reference to item 4 under nits? I didn't completely agree > with your recommendation, so I'd appreciate some additional discussion on that. > Thx, > Barbara > > > -----Original Message----- > > > > Reviewer: Valery Smyslov > > Review result: Has Issues > > > > I have reviewed this document as part of the security directorate's ongoing > > effort to review all IETF documents being processed by the IESG. These > > comments were written primarily for the benefit of the security area > > directors. > > Document editors and WG chairs should treat these comments just like any > > other > > last call comments. > > > > The document defines an informational model for Babel routing protocol. > > This > > informational model can be used as a basis for creating various data models > > (e.g. YANG). The document is properly structured and well written, however > > I think that it has some issues concerned with security. > > > > Issues. > > > > 1. Section 3.1: > > > > babel-mac-algorithms: List of supported MAC computation algorithms. > > Possible values include "HMAC-SHA256", "BLAKE2s". > > > > BLAKE2s can produce MACs of different sizes from 1 to 32 bytes and the > > desired > > size of the MAC is a parameter for it. Where the size of MAC is specified? For > > HMAC with SHA256 I can at least imagine that full 256 bits output is used as a > > MAC... > > Juliusz said: > > Right. The intent is that Blake2s is used with 32-octet keys and 16-octet > > hashes (collision-resistance is not a concern for Babel-MAC while > > dictionary attacks are). Barbara, I think that you should explicitly > > state that Blake2s implies 128-bit hashes. (You may also consider > > renaming BLAKE2s to BLAKE2s-128.) > > The defined values for babel-mac-algorithms come directly from draft-ietf-babel-hmac. The defined value > names should map closely to the names used for the algorithms in in that draft -- which they currently do. > > If it needs to be explicitly stated somewhere that an implementation of draft-ietf-babel-hmac with BLAKE2s > outputs 128-bit MACs, then draft-ietf-babel-hmac (which was already submitted for publication) would be the > correct place to say that. The information model is not the right place, unless there's some expectation for the > size to be configurable or reportable. I'm not seeing any request for the MAC size to be configured or reported > via the information model. > > I'm proposing no change to the defined values of babel-mac-algorithms in order to maintain complete > consistency with the names used in draft-ietf-babel-hmac-12. My point was that the intent Juliusz mentioned (that Blake2s is used with 32-octet keys and 16-octet hashes) must be documented somewhere. If you think it must be in the draft-ietf-babel-hmac, I'm fine with this, but currently I cannot find any such requirement anywhere. > > 2. Section 3.9: > > > > babel-cert-test: An operation that allows a hash of the provided > > input string to be created using the certificate public key and > > the SHA-256 hash algorithm. Input to this operation is a binary > > string. The output of this operation is the resulting hash, as a > > binary string. > > > > I failed to understand what this operation should do. Literally reading it is > > intended to produce SHA2-256 hash of public key and some arbitrary string > > (concatenated? in what order?). But then I failed to understand the purpose > > of > > this test. I would have understood if this operation provides signing of the > > arbitrary string using private key and SHA2-256 as a hash function (similarly > > to babel-mac-key-test), but it in not what is written... > > One of the most common problems in configuring security mechanisms is in the format of the input key (hex, > ASCII, base64, hashing that occurs to create "actual key", etc.). When a security mechanism fails to work, it is > important for users or device managers to be able to trouble-shoot this specific point of failure. This test > allows the user/manager to see if what this device thinks the MAC should be is the same as what another > device thinks the MAC should be or is the same as the MAC being sent on the wire. Many ISPs have built a test > like this into their ISP-supplied CE routers (invoked using the TR-069 protocol and TR-181 data model) to test > various stored key values. It has proven useful. I'm still confused. Are we talking about MACs or about certificates for DTLS? I have no problems with text describing test for MAC keys. The text I'm having problem with is about testing certificates for DTLS. The test it describes is not clear for me: it suggests to perform SHA2-256 hash of an input string "using the certificate public key". It is unclear for me how you would use the certificate public key to produce a hash of some input string. So I believe the test should be clarified. > > 3. Section 5 (Security Considerations): > > > > I think that text about keys (their length and properties) needs some > > expansion. First, there are no any RFC2119 words discouraging using short > > and > > weak keys (there is some text, but without RFC2119 words and with no > > references > > it's just hand waving). Note, that draft-ietf-babel-hmac-12 has some text > > about > > the properties of the keys, so I believe at least it must be referenced here. I > > also suspect that explicitly allowing zero-length and short keys will lead to > > situations when some network operators will use them (because they are > > not > > prohibited), thus subverting security properties of MAC... > > Thanks. I'll add a reference to draft-ietf-babel-hmac Security Considerations. > > Zero length and short keys were discussed on the mailing list. The group considered it appropriate to > allow configuration of zero-length keys for testing but to advise people to follow best > current practices. I find the use of normative language to attempt to control the behavior of > a home network owner (for example) or someone setting up an informal ad hoc mesh > network (for example) to be odd. IMO, the IETF should not seek to control > the choices of people putting together such relatively small-scale networks through > the use of strong normative language in an information model specification. It's > impossible to enforce and such people pretty much never read RFCs. > > If there is a strong desire for some sort of normative language, then I could suggest > OLD > MAC keys are allowed to be as short as zero-length. This is useful > for testing. Network operators are advised to follow current best > practices for key length and generation of keys related to the MAC > algorithm associated with the key. Short (and zero-length) keys and > keys that make use of only alphanumeric characters are highly > susceptible to brute force attacks. > NEW > MAC keys are allowed to be as short as zero-length. This is useful > for testing. Network operators are RECOMMENDED to follow current best > practices for key length and generation of keys related to the MAC > algorithm associated with the key. Short (and zero-length) keys and > keys that make use of only alphanumeric characters are highly > susceptible to brute force attacks. See the Security Considerations > section of [ID.draft-ietf-babel-hmac] for additional considerations > related to MAC keys. I would suggest additionally using "SHOULD NOT" for weak keys. How about the following new text: MAC keys are allowed to be as short as zero-length. This is useful for testing. Network operators are RECOMMENDED to follow current best practices for key length and generation of keys related to the MAC algorithm associated with the key. Short (and zero-length) keys and keys that make use of only alphanumeric characters are highly susceptible to brute force attacks and thus SHOULD NOT be used. See the Security Considerations section of [ID.draft-ietf-babel-hmac] for additional considerations related to MAC keys. (note that "SHOULD NOT" still allows people to shoot in their feet if they want to). > > Nits. > > > > 1. Section 1 (Introduction): > > > > [I-D.ietf-babel-hmac] defines a > > security mechanism that allows Babel packets to be cryptographically > > authenticated, and [I-D.ietf-babel-dtls] defines a security mechanism > > that allows Babel packets to be encrypted. > > > > DTLS provides both confidentiality and authentication of data, so to be > > formally correct, please add "both authenticated and" before "encrypted". > > Thank you. I will make this change. Thank you. > > 2. Section 2 (Overview) at the very end: > > > > Note that this overview is intended simply to be informative and is > > not normative. If there is any discrepancy between this overview and > > the detailed information model definitions in subsequent sections, > > the error is in this overview. > > > > This phrase makes me puzzled. The tree-like description of the information > > model in the Overview is very useful, however this phrase seems to > > discourage > > using it, because authors are not sure it is correct. I think it would be > > better for readers if authors double check that no discrepancy exists > > between > > the overview and the subsequent detailed description and remove this > > phrase. > > The authors have double- and triple-checked, but human error is still possible, since these were not auto- > generated (like YANG does). Whenever redundant information is presented, it is critical that it be normative in > only one place. This language makes it clear which is normative and what to do in the case of discrepancies. I > propose no change. If there is a strong push to remove this language, then I believe the correct approach > would be to remove the entire section (remove the redundancy) rather than to allow confusion if there is an > error. But people have found this section useful, so I would prefer to leave it as is. OK. > > 3. Section 3.3: > > > > babel-mac-verify A Boolean flag indicating whether MAC hashes in > > incoming Babel packets are required to be present and are > > verified. If this parameter is "true", incoming packets are > > required to have a valid MAC hash. An implementation MAY choose > > to expose this parameter as read-only ("ro"). > > > > "MAC hashes" is strange wording, "MAC values" or just "MACs" are better in > > my > > opinion. > > Thank you. I'll change it to MAC. Thanks. > > 4. Section 3.8: > > > > babel-mac-key-use-sign: Indicates whether this key value is used to > > sign sent Babel packets. Sent packets are signed using this key > > if the value is "true". If the value is "false", this key is not > > used to sign sent Babel packets. An implementation MAY choose to > > expose this parameter as read-only ("ro"). > > > > "Sign" is not a good word when you describe symmetric key operations > > (which > > computing MAC belongs to). Although it is often used informally, I think that > > RFC should be more meticulous in selecting words. I'd rather replace it with > > "compute MAC" and rename the entry to babel-mac-key-use-compute or > > babel-mac-key-use-mac (if it is possible). Note, that using "verify MAC" is OK. > > I've been thinking through this. I can't speak to the informal nature of "sign", but I can say that simply > replacing "sign" with "compute" or "mac" wouldn't convey correctly what this parameter is about. This > parameter is primarily concerned with whether or not a MAC is included in the sent packet. The sending is the > critical piece, and not the computing (it's possible to compute the MAC without sending it; a MAC in a sent > packet is assumed to have been computed). I could change the description to: > Indicates whether this key value is used to compute a MAC and include that MAC in the > sent Babel packet. A MAC for sent packets is computed using this key > if the value is "true". If the value is "false", this key is not > used to compute a MAC to include in sent Babel packets. An implementation MAY choose to > expose this parameter as read-only ("ro") I'm fine with this. > But I struggle with the proposed parameter renaming. I strongly believe the name should concisely describe > that the Boolean value indicates whether or not to include a MAC in the sent packet. The term "sign" is one > I've commonly seen to indicate that a MAC is included in the sent packet. I'm not aware of a different, > similarly short word. "Compute" and "mac" do not convey the sending aspect. And sending is very > asymmetric. How about "use"? > > 5. Section 3.8: > > > > babel-mac-key-value: > > ... > > This value is of a length suitable for the associated babel-mac-key- > > algorithm. If the algorithm is based on the HMAC construction > > [RFC2104], the length MUST be between 0 and the block size of the > > underlying hash inclusive (where "HMAC-SHA256" block size is 64 > > bytes as described in [RFC4868]). If the algorithm is "BLAKE2s", > > the length MUST be between 0 and 32 bytes inclusive, as described > > in [RFC7693]. > > > > I wonder of the rationale for imposing the above restrictions on HMAC key > > length. HMAC can use keys of any length, but if the key is greater than block > > size of underlying hash function, then it's first hashed (small performance > > penalty). So I imagine that the rationale is to avoid this penalty. However, as > > RFC2104 states, key sizes greater than output length of the underlying hash > > function (32 bytes in case of SHA2-256) would not significantly increase the > > function strength, so it's just a waste of space. See also Issue 3 above. > > Juliusz said: > > This was discussed at length on the mailing list. It's not about > > performance, it's about making it more difficult to use an unsafe > > procedure for generating keys. > > > > Since Babel-MAC is vulnerable to dictionary attacks, the key must either > > be drawn randomly or generated using a procedure that is hardened against > > such attacks (scrypt, etc.). Applying the procedure described in RFC 2104 > > to a user-provided passphrase is not safe, and therefore we try to make it > > difficult for a naive user to do so. > > > > I am opposed to putting the RFC 2104 hashing procedure in the information > > model. Doing so would be a disservice to our users. > > In addition to the rationale Juliusz mentioned, we (babel WG) also noted that implementers > of the babel MAC function were using existing libraries for the HMAC-SHA256 algorithm. > The user interface (UI) that accepted manual key entry was also from an existing library. When > the same longer strings were entered into different UIs of the different implementations, these > strings were treated differently and resulted in non-interoperability. The "actual key" (using > RFC 2104 words) ended up different. Requiring entered keys to be directly usable as "actual > keys" solved this problem. BTW, I have considered UIs for direct management and configuration > to effectively be implementations of the information model. > > I recommend no changes to this text. I can live with this if you add "SHOULD NOT" for zero-length keys in the Security Consideration (as I suggested above). > > 6. Section 3.8: > > > > babel-mac-key-test: An operation that allows the MAC key and hash > > algorithm to be tested to see if they produce an expected outcome. > > Input to this operation is a binary string. The implementation is > > expected to create a hash of this string using the babel-mac-key- > > value and the babel-mac-key-algorithm. The output of this > > operation is the resulting hash, as a binary string. > > > > The text mixes up words "hash" and "MAC". MAC is not a hash (even if MAC > > algorithm is often based on hash function). As with my previous grunt, I'd like > > RFC to be more meticulous in selecting words. Please, avoid using "hash" > > here. > > If I understand, the suggestion is to reword as: > babel-mac-key-test: An operation that allows the MAC key and MAC > algorithm to be tested to see if they produce an expected outcome. > Input to this operation is a binary string. The implementation is > expected to create a MAC of this string using the babel-mac-key- > value and the babel-mac-key-algorithm. The output of this > operation is the resulting MAC, as a binary string. > > If this is right, I'll make that change. Great, thank you. > > 7. Section 5 (Security Considerations): > > > > ... This model requires that private keys never be > > exposed. The Babel security mechanisms that make use of these > > credentials (e.g., [I-D.ietf-babel-dtls], [I-D.ietf-babel-hmac]) > > identify what credentials can be used with those mechanisms. > > > > Please add "and MAC keys" after "private keys" since formally private keys > > are > > only defined for public key cryptography. > > Thank you. I'll make this change. Thanks. > > 8. Section 5 (Security Considerations): > > > > MAC keys are allowed to be as short as zero-length. This is useful > > for testing. > > > > I wonder what's benefit of allowing zero-length keys for testing purposes. > > What > > is intended to be tested in this case? Implementation of MAC? Is it really > > needed outside test lab? Am I missing something? > > As with the -test actions, this allows someone to diagnose whether a problem they are having is with the > formatting > of the input key (hex, padded, ASCII, base64, etc.). This is by far one of the most common problems when > attempting to > get different implementations to interoperate. OK, but I'd rather still add "SHOULD NOT" for using them as I suggested above. > > 9. Section 5 (Security Considerations): > > > > Short (and zero-length) keys and > > keys that make use of only alphanumeric characters are highly > > susceptible to brute force attacks. > > > > Formally, brute force attack with zero-length keys is not defined, since there > > is no key to find and all is in clear. > > Juliusz said: > > The key length is not carried in the clear by the protocol. Guessing the > > key length requires a brute-force attack, even when it is zero. > > I propose no change. OK. > > Comments. > > > > 1. The document contains an entry in the Informational model defining which > > hash functions can be used with HMAC authentication. However, there is no > > corresponding entry of which ciphersuites can be used with DTLS. Is it up to > > DTLS library to select ciphersuites? > > Juliusz said: > > Yes. Babel-DTLS is intended to inherit the security properties of the > > system's DTLS library. If the DTLS library is unsafe, then Babel-DTLS > > must not be used until the library is fixed. Regards, Valery. From nobody Thu Nov 5 06:21:37 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 230673A1234; Thu, 5 Nov 2020 06:21:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer via Datatracker To: Cc: last-call@ietf.org, detnet@ietf.org, draft-ietf-detnet-security.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160458609008.18764.7738961429715355351@ietfa.amsl.com> Reply-To: Yaron Sheffer Date: Thu, 05 Nov 2020 06:21:30 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-detnet-security-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 14:21:31 -0000 Reviewer: Yaron Sheffer Review result: Has Issues Comments: draft-ietf-detnet-security-12 The name says it all: this document is all about Deterministic Networking (DetNet) security. To summarize my perspective on this document: you chose to publish this document as Informational and to not include any normative text. I understand the motivation, presumably all normative text should be included in the base documents. But it makes the document a lot less useful: network architects would be guided much better if you made specific recommendations (specifically, in Sec. 7, "Mitigation") and graded these recommendations as MAY/SHOULD/MUST. I think deployers and architects would expect much more specific treatment of security technologies and how they can/should be applied to DetNet rather than an open-ended discussion that they may be able to apply to their own network, but only after they have themselves gone through a deep dive into the technical options. One way you may want to improve the "usability" of the document is by adding references from Sec. 7 ("mitigations") to the specific mitigations proposed in the various technology-specific documents: for IP, MPLS, Ethernet etc. That would make the discussion much more concrete. It would also allow users (as well as WG participants) to understand more clearly which security areas are addressed well and which are not. * 1. "These DetNet technologies have not previously been deployed together on a wide area IP-based network". Referring to the previous paragraph, I think you mean to say, "DetNet technologies have not previously been deployed together with a wide area IP-based network" * "primarily concerned with denial-of service prevention" - this paragraph seems to assume orthogonality/composability of architectural elements that appears somewhat naive. Can we ensure basic security concerns (confidentiality, integrity) on DetNet networks using standard mechanisms, such as TLS/DTLS or IPsec while retaining the "deterministic" properties? Even if this is the case, it needs to be mentioned explicitly. For example, throttling or retry mechanisms might well interact badly between security protocols and the underlying transport. * 3.3 "integrity of the values in any header" - please provide a reference to a recommendation on how to protect these values. * 3.4: we punt the response of the network in the face of malicious actions (e.g., a replayed, out-of-time-window packet) to admin configuration. DetNet specifies (or at least refers to) queuing and shaping algorithms in RFC 8655, Sec. 4.5. I would expect a similar reference to attack-resistant algorithms, instead of having the admin choose from a menu of choices that appear to be simplistic - drop the packet or shut down the link. * 4: Sec. 7.1 of the DiffServ RFC has a different threat model in mind. The introductory sections to the current document make it clear that we care about mixed IT/OT networks ("insider threat") whereas DiffServ assumes a secure network that can be policed on the perimeter, in boundary nodes. I think the reference to "internal link[s] that cannot be adequately secured against modification of DSCP values" is awkward - in a campus network, this would be *any* link, because there is no perimeter. * 5.2.2: as well as simple elimination of packets from the flow. * 5.3 (table): an Internal, on-path attacker can inject some signaling packets. Also, isn't a DDoS attack from the outside potentially an "inter-segment attack" by an External attacker? * 7.2: the section on sequence number integrity appears to assume that this protection is achieved by using encryption. This is not necessarily true, protocols such as ESP-null (or the deprecated AH) integrity-protect packets without encrypting them. Similar solutions are available in MACsec. * 7.4: if dummy packet insertion is presented as a mitigation against reconnaissance (e.g. now my flow doesn't look like VoIP any more), I would appreciate a reference to a proposed algorithm and a demonstration that this really works. Personally I am skeptical of that. * 7.5.1: I suggest to add to the end of the paragraph "However, if secret symmetrical keys are used": Group key management protocols can be used to automate management of such symmetric keys, see [draft-ietf-ipsecme-g-ikev2-01] for an example in the context of IPsec. * 7.6: and if we are worried about recon, then signaling needs to be encrypted, not just integrity-protected. * 8.1.3: this is phrased in a negative way, essentially saying, "the network should accommodate insecure packet flows". A more positive way to address the same issue would be "deployments should allow for dynamic and secure registration of new devices, and possibly manual deregistration of retired devices." * 8.1.4: this short section is totally opaque. What is the threat? What are deployers supposed to do about it? The same in fact applies to 8.1.5. * 8.1.8: I would have liked to see treatment of the more complicated issues, such as IT packets that need to "cross the line" into OT. Are there application-level dependencies on the IT network? For example, does the OT network need to use the IT network for DNS or OAM services? If such dependencies exist, how are malicious packet flows handled? * 8.1.11: this begs the question: are there unambiguous specifications of the DetNet security mechanisms, so as to enable interoperability? * 8.1.21: This section ends on a pessimistic note. It doesn't have to be that way... One way to deal with your conclusions is for network designers to adopt a standard risk-based approach, where only those attacks are mitigated whose potential cost is higher than the cost of mitigation. * Sec. 9, when discussing IPsec, again omits to mention that packet integrity protection *without* encryption is an option. From nobody Thu Nov 5 06:59:52 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C36813A12FA; Thu, 5 Nov 2020 06:59:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer via Datatracker To: Cc: last-call@ietf.org, draft-ietf-tls-exported-authenticator.all@ietf.org, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160458838575.14807.16400082227129460453@ietfa.amsl.com> Reply-To: Yaron Sheffer Date: Thu, 05 Nov 2020 06:59:45 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-tls-exported-authenticator-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 14:59:46 -0000 Reviewer: Yaron Sheffer Review result: Has Nits It's been a long time... My mail here [1] mentions two remaining open issues: a mention of QUIC and the code point. The first (small) issue seems to have been forgotten. I believe the second issue has been addressed by the WG, with the introduction of a new message type. [1] https://mailarchive.ietf.org/arch/msg/secdir/n54wuiSwCx9VqgSrrWvX_9FCoW0/ From nobody Thu Nov 5 11:54:12 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9AB3A19F2 for ; Thu, 5 Nov 2020 11:54:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <160460605129.1135.15666164010177760435@ietfa.amsl.com> Date: Thu, 05 Nov 2020 11:54:11 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 19:54:11 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-11-05 Reviewer LC end Draft Derek Atkins R2020-09-04 draft-ietf-i2nsf-sdn-ipsec-flow-protection-12 Leif Johansson 2020-10-02 draft-ietf-lpwan-schc-over-lorawan-13 Aanchal Malhotra 2020-10-12 draft-ietf-dots-server-discovery-14 Hilarie Orman R2020-07-09 draft-ietf-acme-email-smime-10 Rich Salz R2020-08-14 draft-ietf-suit-architecture-14 For telechat 2020-12-03 Reviewer LC end Draft Daniel Gillmor 2020-09-30 draft-ietf-ccamp-layer0-types-08 Steve Hanna 2020-09-30 draft-ietf-ccamp-wson-yang-27 Christopher Wood R2019-11-06 draft-ietf-dtn-tcpclv4-22 Last calls: Reviewer LC end Draft Derek Atkins R2020-09-04 draft-ietf-i2nsf-sdn-ipsec-flow-protection-12 Daniel Franke 2020-09-18 draft-ietf-jmap-mdn-15 Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-10 Daniel Gillmor 2020-09-30 draft-ietf-ccamp-layer0-types-08 Phillip Hallam-Baker 2020-09-30 draft-ietf-lwig-tcp-constrained-node-networks-13 Steve Hanna 2020-09-30 draft-ietf-ccamp-wson-yang-27 Dan Harkins None draft-ietf-rtgwg-policy-model-03 Leif Johansson 2020-10-02 draft-ietf-lpwan-schc-over-lorawan-13 Scott Kelly 2020-10-01 draft-ietf-idr-tunnel-encaps-19 Aanchal Malhotra 2020-10-12 draft-ietf-dots-server-discovery-14 Catherine Meadows 2020-10-21 draft-ietf-6lo-blemesh-08 Kathleen Moriarty 2020-07-20 draft-ietf-ace-oscore-profile-13 Russ Mundy 2020-07-20 draft-ietf-ace-dtls-authorize-14 Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer-05 Magnus Nystrom 2020-11-16 draft-ietf-quic-qpack-19 Hilarie Orman 2020-11-16 draft-ietf-quic-http-32 Hilarie Orman R2020-07-09 draft-ietf-acme-email-smime-10 Radia Perlman 2020-11-16 draft-ietf-quic-tls-32 Radia Perlman 2020-11-12 draft-ietf-dots-signal-call-home-11 Derrell Piper 2020-11-11 draft-ietf-suit-information-model-08 Tirumaleswar Reddy.K 2020-11-16 draft-ietf-quic-transport-32 Rich Salz R2020-08-14 draft-ietf-suit-architecture-14 Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth-09 Christopher Wood 2020-09-23 draft-ietf-6man-rfc4941bis-12 Christopher Wood R2019-11-06 draft-ietf-dtn-tcpclv4-22 Paul Wouters 2020-09-08 draft-ietf-i2nsf-capability-data-model-13 Next in the reviewer rotation: Francesca Palombini Radia Perlman Derrell Piper Tirumaleswar Reddy.K Vincent Roca Kyle Rose Joseph Salowey Rich Salz Stefan Santesson Yaron Sheffer From nobody Thu Nov 5 14:54:24 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D953A010A; Thu, 5 Nov 2020 14:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ldeaNc_Y2QT; Thu, 5 Nov 2020 14:54:22 -0800 (PST) Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78F83A0100; Thu, 5 Nov 2020 14:54:21 -0800 (PST) Received: from in01.mta.xmission.com ([166.70.13.51]) by out01.mta.xmission.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kao96-00B8jT-II; Thu, 05 Nov 2020 15:54:20 -0700 Received: from [166.70.232.207] (helo=rumpleteazer.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1kao95-0003sD-SL; Thu, 05 Nov 2020 15:54:20 -0700 Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 0A5MpL0J029186; Thu, 5 Nov 2020 15:51:21 -0700 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id 0A5MpKUR029185; Thu, 5 Nov 2020 15:51:20 -0700 Date: Thu, 5 Nov 2020 15:51:20 -0700 Message-Id: <202011052251.0A5MpKUR029185@rumpleteazer.rhmr.com> From: "Hilarie Orman" Reply-To: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org Cc: draft-ietf-acme-email-smime.all@ietf.org X-XM-SPF: eid=1kao95-0003sD-SL; ; ; mid=<202011052251.0A5MpKUR029185@rumpleteazer.rhmr.com>; ; ; hst=in01.mta.xmission.com; ; ; ip=166.70.232.207; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-AID: U2FsdGVkX1/HIK1GzhHhQryZ5q/XHsl2 X-SA-Exim-Connect-IP: 166.70.232.207 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ******;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 436 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 11 (2.5%), b_tie_ro: 9 (2.2%), parse: 0.69 (0.2%), extract_message_metadata: 16 (3.6%), get_uri_detail_list: 0.78 (0.2%), tests_pri_-1000: 6 (1.4%), tests_pri_-950: 1.89 (0.4%), tests_pri_-900: 1.48 (0.3%), tests_pri_-90: 107 (24.6%), check_bayes: 104 (23.9%), b_tokenize: 9 (2.0%), b_tok_get_all: 8 (1.9%), b_comp_prob: 2.1 (0.5%), b_tok_touch_all: 78 (17.9%), b_finish: 1.98 (0.5%), tests_pri_0: 274 (62.8%), check_dkim_signature: 1.70 (0.4%), check_dkim_adsp: 34 (7.8%), poll_dns_idle: 22 (5.0%), tests_pri_10: 2.1 (0.5%), tests_pri_500: 13 (2.9%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Archived-At: Subject: [secdir] Security review of draft-ietf-acme-email-smime-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 22:54:23 -0000 Security review of Extensions to Automatic Certificate Management Environment for end-user S/MIME certificates draft-ietf-acme-email-smime-10 Do not be alarmed. I generated this review of this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This is much improved over the -8 version, and it is, in my opinion, READY. Hilarie From nobody Sat Nov 7 16:28:22 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCC43A0E10; Sat, 7 Nov 2020 16:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBnYJSLrXuWP; Sat, 7 Nov 2020 16:28:10 -0800 (PST) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AF403A0E0F; Sat, 7 Nov 2020 16:28:10 -0800 (PST) Received: by mail-pg1-x536.google.com with SMTP id f38so3934927pgm.2; Sat, 07 Nov 2020 16:28:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KYjuBeI4MQJF73Y9Rh94FIL1XQGNkuqxanGzB3UpdBY=; b=CGtPRSXrizsnd2jsyzFnLe0koecAVvll6IUryuUNmdtWGAPF0eHs5fRo32YrTO4hJE yIRe47DDosRvnX2GODEBUxTYUWbeQ2Ra9pdvt9DXkejQgdGyonhNbFL3s95DLlP5R40I gNwj1yBen9Kg4PYQsLc33Iy+x6m7Ux71SsCTdnO3pOkDrBCKkuXe60GfwgXHnJLLB7MN vomD3AstR9nS6HWOpLF34itAObKNy2z5+QXlo8XlTvLsx/cyvGP+ClaBhR97HOxfY3EG y/v6MsZazF6EGpve+r2OjoKr+8Oecj0xLXMtUes6s3ZpeBfhP5vnAnRQztJ2e0uJYSyF 8QIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KYjuBeI4MQJF73Y9Rh94FIL1XQGNkuqxanGzB3UpdBY=; b=lUEURUEbH94xCxQu0iuA3ZC9Iv9kPQ91ujHixHUpm1eeKf0y6Of1ikW34NAHjytyOb CDsN9VKbeHEsAhH+gktCIyStg1O+1ZM4sbVbxS+qyfDPA9+nvgTALi4Xc02la02wub3z SqxEZfwaTjAS4gvT30zBWQV7tvNnYC+HG5zTAWg+S10Dp47HEmUQ9Ux2g8HLjt8gv/3a yybYmfPHilbpLRjEnxf14fHpD80q0R2/yPZjFn6dc8NvDvn+mfcGbQuo5mvYlBv0noVZ mfz7o3OuWCgzUt26USUbeserzI7OuZ6XBuSkDusqJk1fl6CERW+krekqTni/z1K32a3j fmBw== X-Gm-Message-State: AOAM530M1LvemLpaYhh5xyeflu0an6X0DBPgAxckSRqSNvFBAJLP2OkD W1ob1nfT56bQr3JRdtzjYyVA34bW6dpYng== X-Google-Smtp-Source: ABdhPJwnZUf1+bnNgr+z6AHr6nKZcBwvhsfp0tjHW4kpB0tcZu22RSRBvjZduRg3WwbCJjtDovXGug== X-Received: by 2002:a63:fc5f:: with SMTP id r31mr7365839pgk.90.1604795289143; Sat, 07 Nov 2020 16:28:09 -0800 (PST) Received: from [192.168.178.20] ([151.210.130.0]) by smtp.gmail.com with ESMTPSA id s18sm7056084pfc.5.2020.11.07.16.28.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Nov 2020 16:28:08 -0800 (PST) To: Joseph Salowey , secdir Cc: last-call@ietf.org, anima@ietf.org, draft-ietf-anima-grasp-api.all@ietf.org References: <160381954432.30121.9559007698502161410@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <6106292a-f2c6-d4f3-9cbc-aafda045cf84@gmail.com> Date: Sun, 8 Nov 2020 13:28:03 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] Fwd: Secdir last call review of draft-ietf-anima-grasp-api-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2020 00:28:12 -0000 Joe, A few more comments in line: On 02-Nov-20 19:02, Joseph Salowey wrote: > (Forwarding my response=C2=A0to the rest of the audience) >=20 > Hi Brian,=C2=A0 >=20 > Thanks for the quick response,=C2=A0 additional questions and comments = inline below: >=20 > On Tue, Oct 27, 2020 at 6:58 PM Brian E Carpenter > wrote: >=20 > Hi Joseph, >=20 > Thanks for the review. Comments in line... >=20 > On 28-Oct-20 06:25, Joseph Salowey via Datatracker wrote: > > Reviewer: Joseph Salowey > > Review result: Has Issues > > > > I have reviewed this document as part of the security directorate= 's > > ongoing effort to review all IETF documents being processed by th= e > > IESG.=C2=A0 These comments were written primarily for the benefit= of the > > security area directors.=C2=A0 Document editors and WG chairs sho= uld treat > > these comments just like any other last call comments. > > > > The summary of the review is Has issues.=C2=A0 The document does = needs a bit more > > discussion of the security implications. > > > > 1. Authorization > > > > In the security considerations section the document says that aut= horization is > > left for future work.=C2=A0 I would expect that the section shoul= d at least describe > > what the implications of no authorizations are. >=20 > This isn't really an issue for the API itself, but for the underlyi= ng protocol > and for the ANIMA ecosystem. It's an issue that the WG explicitly d= eferred > (and it's now a chartered work item). Let me quote here what the GR= ASP spec > says in its security considerations: >=20 > >>=C2=A0 =C2=A0 - Authorization and Roles > >> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0The GRASP protocol is agnostic about t= he roles and capabilities of > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0individual ASAs and about which object= ives a particular ASA is > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0authorized to support.=C2=A0 An implem= entation might support > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0precautions such as allowing only one = ASA in a given node to > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0modify a given objective, but this may= not be appropriate in all > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0cases.=C2=A0 For example, it might be = operationally useful to allow an > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0old and a new version of the same ASA = to run simultaneously during > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0an overlap period.=C2=A0 These questio= ns are out of scope for the > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0present specification. >=20 > and what draft-carpenter-anima-asa-guidelines says: >=20 > >> Authorization of ASAs is a subject for future study. At present,= ASAs are trusted by virtue of being installed on a node that has success= fully joined the ACP. In the general case, a node may have mutltiple role= s and a role may use multiple ASAs, each using multiple GRASP objectives.= Additional mechanisms for the authorization of nodes and ASAs to manipul= ate specific GRASP objectives could be designed. >=20 > That draft is on the verge of WG adoption. The point is that the cu= rrent > trust model is that we trust any node that has successfully joined = the ACP, > and therefore we trust any ASA in such a node. We should state that= clearly > in the text. >=20 > IMHO it would be out of scope for the API to say more but we should= add a > reference to the GRASP Security Considerations.=C2=A0 >=20 > > What risks are not being > > mitigated?=C2=A0 =C2=A0What modes of operations should not be use= d? >=20 > Those are good questions for the WG to look at. >=20 >=20 > [Joe] These are the sort of things I would expect to be described in th= e security considerations. I meant "good questions to look at when investigating possible ASA authorization models." >=20 > I'm trying to get my bearing in what the current model is here.=C2=A0 I= n particular=C2=A0it seems that any security is applied at the "ACP". Exactly. > What is the relationship of an ASA to an ACP node? We'll try to clarify that in the next version. An ASA runs in an ACP node= and therefore inherits all the security properties of an ACP node (i.e. = message integrity, message confidentiality and the fact that unauthorized= nodes cannot join the ACP). =C2=A0 =C2=A0 >=20 > Does the ACP provide a security guarantee=C2=A0that it will send a mess= age to the correct ASA running on the correct system?=C2=A0 Does it ensur= e that a message received was sent by the correct system?=C2=A0 I couldn'= t find these answers in the security considerations of ACP, GRASP or GRAS= P API.=C2=A0=20 The ACP is agnostic about indivdual ASAs, but the ACP is built in such a = way that messages can't miscarry since there is no way for a node to usurp an= other node's IP address. The GRASP Session ID ensures that messages are deliver= ed to the appropriate peer. > > In general leaving > > security items out suggests that the work is not ready for wide d= eployment. > > Perhaps this is OK because the work is informational, but the doc= ument should > > probably say this.>=20 >=20 > Personally I don't think we have left a hole here, because there's = a well-defined > trust boundary, but we should indeed state that as well as citing t= he GRASP spec's > security considerations. >=20 > [Joe] Yes please,=C2=A0 defining the trust model would help.=20 Ack. > =C2=A0 >=20 > > > > 2. Authentication > > > > Section 2.3.1.4 discusses the ASA_locator.=C2=A0 How is is the en= tity accessed by > > the locator authenticated?=C2=A0 How does the caller of the API k= now they are > > talking to the right entity?=C2=A0 I don't see any discussion of = this in this > > document and there is very little in draft-ietf-anima-grasp-15 on= this.=C2=A0 =C2=A0 Is > > there a section in one of these documents I should be looking for= ? >=20 > No, you're not missing anything. The trust boundary is the ACP, and= that takes > us back to the previous point. If we do decide that we need a fine-= grained > trust model inside the ACP, we'll presumably need to extend GRASP i= tself > to add some form of authentication option beyond what GRASP over TL= S can > provide. >=20 > [Joe] From my understanding the ASA_locator is referencing a remote sys= tem that the caller of the API is going to interact with. If this is true= then there must be some way for the local system to make sure that the i= dentity of the remote system is indeed the same entity they reference in = the API.=C2=A0 I would expect somewhere in one of the specifications that= there needs to be some mapping between the name specified API and the na= me authenticated in TLS (typically in the subjectAlternativeName in a cer= tificate), but it could be established in other ways.=C2=A0=20 No, the GRASP discovery process operates over the ACP so is protected by = that (e.g. by TLS in a TLS-based ACP, but that's not the only way it coul= d be). The discovery process returns a locator and as noted above, that c= an't be usurped, so we're done. This wouldn't be safe on the open Internet, but we aren't on the open Int= ernet. (It wasn't by chance that we developed RFC8799 while working on AN= IMA.) =C2=A0 >=20 > > > > 3. ASA_Nonce > > > > The ASA nonce is described as a security mechanism.=C2=A0 It is o= nly 4 bytes long. > > This seems short, making the ASA_Nonce vulnerable to collisions.=C2= =A0 Why is this > > not a problem? >=20 > This isn't used on the wire, just locally within the GRASP instance= , > so collisions can be excluded. >=20 > [Joe] OK, thanks. > =C2=A0 >=20 > > How long is the ASA nonce supposed to be valid?=C2=A0 How often d= oes registration > > happen? >=20 > At the moment, there is no sensible answer to those questions. When= we develop > the authorization model, we'd definitely have to answer those quest= ions and maybe > the nonce would have to be replaced by a crypto object. >=20 > [Joe] OK. >=20 > =C2=A0 >=20 > > > > 4. Session Nonce > > > > Are there security implications of revealing the session nonce to= the caller as > > suggested in section 2.3.1.7?=C2=A0 Could it allow for the ASA to= bypass > > authorization if it knows this value?=C2=A0 =C2=A0Perhaps forming= the nonce from the > > underlying session ID is not the best guidance?=C2=A0 Also it see= ms the underlying > > protocol session ID is only 4 bytes and collisions are likely and= may be a > > problem for the protocol. >=20 > No, the collision risk is avoided because the session nonce include= s the > ACP IPv6 address of the session originator. We should explain that > more clearly. >=20 > [Joe]=C2=A0 I still have the question of whether the nonce should be re= vealed to the API caller or left internal to the implementation. If a caller is running multiple parallel sessions, there needs to be *som= ething* in the API; it's exactly the same as a socket in that respect (in= fact, in an implementation, it must map 1:1 to a socket). An ASA can't usurp itself. The only risk I can see is that one ASA usurps= another one in the same node by somehow stealing a session nonce. Given the trust= model, is that really a concern? (An implementation of GRASP could choose to use= a process ID as an extra check, I suppose.) >=20 > =C2=A0 >=20 > > > > 5. Error Codes > > > > In general, the list of API codes in the appendix is not describe= d in the API. > > It seems they should be.=C2=A0 Some of the error codes seem relat= ed to > > authorization, which is out of scope? >=20 > Our hope was the the WG could move faster on that topic, but the > incredible delays on BRSKI and the ACP made that impossible. > Our idea is certainly that register_asa() and register_objective() > should include authorization in the longer term. >=20 >=20 > [Joe]=C2=A0 I think it would be helpful for the API spec to list the va= lid error codes for each call.=20 We can annotate the error code list and get the same effect with less clu= tter. Regards Brian > =C2=A0 >=20 > > It seems that some of the error code could lead to disclosure of = information, > > for example: > > > > notYourASA=C2=A0 =C2=A0 =C2=A0 =C2=A07 "ASA registered but not by= you"=C2=A0 might reveal a valid nonce > > from an invalid nonce >=20 > Hmm... I don't think so. Let me glance at the code... >=20 > The only place where I found that error code useful was in deregist= er_asa() > and that doesn't return anything else. It could be used in an exhau= stive > search attack to deregister an ASA, but in the current trust model = that > doesn't seem like a significant risk. >=20 > > > > 6. Denial of service > > > > are there protections in the underlying protocol for denial of se= rvice with > > respect to Flood(), Synchronize() or any other method? >=20 > There are recommendations about rate throttling for relaying GRASP = Flood and > Discover multicasts, which should confine any multicast abuse to a = single > link-layer segment. That's one good reason for using link-layer mul= ticast only. > We also have recommendations for exponential backoff in the GRASP s= pec, but > of course a malicious sender could ignore those. In any case we can= put a > specific pointer to that subsection of the GRASP Security Considera= tions. >=20 > DoS against the Negotiate or Synchronize parts of GRASP seems to be= like > any other client/server protocol. I'm not sure what we can say in t= he > API spec about that. In my implementation (which is not intended to= be > production quality) I've simply put finite queues for all the reque= st > handlers, with silent discard if the queue overflows. >=20 > We'll collate updates to all reviews after the LC expires. >=20 >=20 > [Joe] OK thanks.=C2=A0 > =C2=A0 >=20 > Thanks again > =C2=A0 =C2=A0 Brian >=20 >=20 >=20 From nobody Sun Nov 8 21:25:31 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881D93A11F1 for ; Sun, 8 Nov 2020 21:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMtJIhmJ7CwT for ; Sun, 8 Nov 2020 21:25:23 -0800 (PST) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2409E3A11F3 for ; Sun, 8 Nov 2020 21:25:22 -0800 (PST) Received: by mail-qk1-x741.google.com with SMTP id h15so6935872qkl.13 for ; Sun, 08 Nov 2020 21:25:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7XjywJ00xJKcTumc9slLzJ/QuDaHQ8E1Ff2UWgQ5K9c=; b=Z3VBQty7l8gZFOq4zlQyHEOrHVaCZOs1ANlc0P3yH1C5Xwxez1K20hVbs8sbnoLauA /qITLPIJH0Apd6ud3QgzXGWVRw1VlfVnhavtlGOFSUccaebipgUHS7NDV6KiiqUuyoTZ QdBZJ+o5MVkYvbNk4fB5Ibl/pVZTLOppDfq8Af6DUnmrc4d5l1+Sdy1jTFnnKrUgz1dC ldJTse5Uu4RvxGsIwV5YXHvIznYIUqrpX+gpYAsSQrVKuM+eDj13jawgqHm52RUnN/N9 22ltH1IxrY+wNhU/n5dIQNijrQHhjnHkw9+7c2GwMKIv0jM0fo2vmNV7NfGdVRGYmdEb N7Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7XjywJ00xJKcTumc9slLzJ/QuDaHQ8E1Ff2UWgQ5K9c=; b=r2Q/HSUa1B9VM98EY8YjGPzgEAXTmlwlqgcGA7fB1m17/XEWc5k1LbhyKOoc8xe5Qu lk/xdmgfOwQNY2xbxlvuZNtB55d5MjFLjLDeoAHl63J2NhfsUe4Kp26PugKL3sosvYoz wMrzRDrP4h3uc1ZVYsmRcCrx8sxzbapJ2W2WgT4hc0lwVlIJU0UlfPsq5uePSIbYDguk i4A21U4R2v/swwpgjspCfYdBaaP4I/tKHNrLPdILDsx9N/IL7fUCkCmF/TBiZtMzDulu yi7uX3jEz2wQr5U45HlXvZwSUOwSfHiye1iR/SruLRnbU1jkRQjo2bkKt6NyZcM5x/4g juOg== X-Gm-Message-State: AOAM531zfievNmNuntFx4ZlaQVT8u2RkC+rdHMvDHo26Q7EdGt0IJ1zs XYFw805QGcZZs0sqfSAL7IhlRiQ+wQD6dS/o1HH9cA== X-Google-Smtp-Source: ABdhPJxuT1vPmoQtCl3G8GQWw/32B+fgX/dEQnHI+yPpEKtDA4gjBRL1w17vJ7Kqg0zDwdpVVK9WAcIW/lnHEYc9IaM= X-Received: by 2002:a37:4948:: with SMTP id w69mr12081542qka.472.1604899521865; Sun, 08 Nov 2020 21:25:21 -0800 (PST) MIME-Version: 1.0 References: <160381954432.30121.9559007698502161410@ietfa.amsl.com> <6106292a-f2c6-d4f3-9cbc-aafda045cf84@gmail.com> In-Reply-To: <6106292a-f2c6-d4f3-9cbc-aafda045cf84@gmail.com> From: Joseph Salowey Date: Sun, 8 Nov 2020 21:25:11 -0800 Message-ID: To: Brian E Carpenter Cc: secdir , last-call@ietf.org, anima@ietf.org, draft-ietf-anima-grasp-api.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000e6c43305b3a5c967" Archived-At: Subject: Re: [secdir] Fwd: Secdir last call review of draft-ietf-anima-grasp-api-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2020 05:25:26 -0000 --000000000000e6c43305b3a5c967 Content-Type: text/plain; charset="UTF-8" Thanks Brain, Explicitly defining the trust model will address most of the comments, and I think you have dealt with any other outstanding ones below. I think you may find it would be better to have a mechanism to establish trust in individual participants, however I understand that the group has pushed this to future work. Cheers, Joe On Sat, Nov 7, 2020 at 4:28 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Joe, > > A few more comments in line: > > On 02-Nov-20 19:02, Joseph Salowey wrote: > > (Forwarding my response to the rest of the audience) > > > > Hi Brian, > > > > Thanks for the quick response, additional questions and comments inline > below: > > > > On Tue, Oct 27, 2020 at 6:58 PM Brian E Carpenter < > brian.e.carpenter@gmail.com > wrote: > > > > Hi Joseph, > > > > Thanks for the review. Comments in line... > > > > On 28-Oct-20 06:25, Joseph Salowey via Datatracker wrote: > > > Reviewer: Joseph Salowey > > > Review result: Has Issues > > > > > > I have reviewed this document as part of the security directorate's > > > ongoing effort to review all IETF documents being processed by the > > > IESG. These comments were written primarily for the benefit of the > > > security area directors. Document editors and WG chairs should > treat > > > these comments just like any other last call comments. > > > > > > The summary of the review is Has issues. The document does needs > a bit more > > > discussion of the security implications. > > > > > > 1. Authorization > > > > > > In the security considerations section the document says that > authorization is > > > left for future work. I would expect that the section should at > least describe > > > what the implications of no authorizations are. > > > > This isn't really an issue for the API itself, but for the > underlying protocol > > and for the ANIMA ecosystem. It's an issue that the WG explicitly > deferred > > (and it's now a chartered work item). Let me quote here what the > GRASP spec > > says in its security considerations: > > > > >> - Authorization and Roles > > >> > > >> The GRASP protocol is agnostic about the roles and > capabilities of > > >> individual ASAs and about which objectives a particular ASA > is > > >> authorized to support. An implementation might support > > >> precautions such as allowing only one ASA in a given node to > > >> modify a given objective, but this may not be appropriate > in all > > >> cases. For example, it might be operationally useful to > allow an > > >> old and a new version of the same ASA to run simultaneously > during > > >> an overlap period. These questions are out of scope for the > > >> present specification. > > > > and what draft-carpenter-anima-asa-guidelines says: > > > > >> Authorization of ASAs is a subject for future study. At present, > ASAs are trusted by virtue of being installed on a node that has > successfully joined the ACP. In the general case, a node may have mutltiple > roles and a role may use multiple ASAs, each using multiple GRASP > objectives. Additional mechanisms for the authorization of nodes and ASAs > to manipulate specific GRASP objectives could be designed. > > > > That draft is on the verge of WG adoption. The point is that the > current > > trust model is that we trust any node that has successfully joined > the ACP, > > and therefore we trust any ASA in such a node. We should state that > clearly > > in the text. > > > > IMHO it would be out of scope for the API to say more but we should > add a > > reference to the GRASP Security Considerations. > > > > > What risks are not being > > > mitigated? What modes of operations should not be used? > > > > Those are good questions for the WG to look at. > > > > > > [Joe] These are the sort of things I would expect to be described in the > security considerations. > > I meant "good questions to look at when investigating possible > ASA authorization models." > > > > I'm trying to get my bearing in what the current model is here. In > particular it seems that any security is applied at the "ACP". > > Exactly. > > > What is the relationship of an ASA to an ACP node? > > We'll try to clarify that in the next version. An ASA runs in an ACP node > and therefore inherits all the security properties of an ACP node (i.e. > message integrity, message confidentiality and the fact that unauthorized > nodes cannot join the ACP). > > > > > Does the ACP provide a security guarantee that it will send a message to > the correct ASA running on the correct system? Does it ensure that a > message received was sent by the correct system? I couldn't find these > answers in the security considerations of ACP, GRASP or GRASP API. > > The ACP is agnostic about indivdual ASAs, but the ACP is built in such a > way > that messages can't miscarry since there is no way for a node to usurp > another > node's IP address. The GRASP Session ID ensures that messages are delivered > to the appropriate peer. > > > > In general leaving > > > security items out suggests that the work is not ready for wide > deployment. > > > Perhaps this is OK because the work is informational, but the > document should > > > probably say this.> > > > > Personally I don't think we have left a hole here, because there's a > well-defined > > trust boundary, but we should indeed state that as well as citing > the GRASP spec's > > security considerations. > > > > [Joe] Yes please, defining the trust model would help. > > Ack. > > > > > > > > > > > 2. Authentication > > > > > > Section 2.3.1.4 discusses the ASA_locator. How is is the entity > accessed by > > > the locator authenticated? How does the caller of the API know > they are > > > talking to the right entity? I don't see any discussion of this > in this > > > document and there is very little in draft-ietf-anima-grasp-15 on > this. Is > > > there a section in one of these documents I should be looking for? > > > > No, you're not missing anything. The trust boundary is the ACP, and > that takes > > us back to the previous point. If we do decide that we need a > fine-grained > > trust model inside the ACP, we'll presumably need to extend GRASP > itself > > to add some form of authentication option beyond what GRASP over TLS > can > > provide. > > > > [Joe] From my understanding the ASA_locator is referencing a remote > system that the caller of the API is going to interact with. If this is > true then there must be some way for the local system to make sure that the > identity of the remote system is indeed the same entity they reference in > the API. I would expect somewhere in one of the specifications that there > needs to be some mapping between the name specified API and the name > authenticated in TLS (typically in the subjectAlternativeName in a > certificate), but it could be established in other ways. > > No, the GRASP discovery process operates over the ACP so is protected by > that (e.g. by TLS in a TLS-based ACP, but that's not the only way it could > be). The discovery process returns a locator and as noted above, that can't > be usurped, so we're done. > > This wouldn't be safe on the open Internet, but we aren't on the open > Internet. (It wasn't by chance that we developed RFC8799 while working on > ANIMA.) > > > > > > > > > 3. ASA_Nonce > > > > > > The ASA nonce is described as a security mechanism. It is only 4 > bytes long. > > > This seems short, making the ASA_Nonce vulnerable to collisions. > Why is this > > > not a problem? > > > > This isn't used on the wire, just locally within the GRASP instance, > > so collisions can be excluded. > > > > [Joe] OK, thanks. > > > > > > > How long is the ASA nonce supposed to be valid? How often does > registration > > > happen? > > > > At the moment, there is no sensible answer to those questions. When > we develop > > the authorization model, we'd definitely have to answer those > questions and maybe > > the nonce would have to be replaced by a crypto object. > > > > [Joe] OK. > > > > > > > > > > > > 4. Session Nonce > > > > > > Are there security implications of revealing the session nonce to > the caller as > > > suggested in section 2.3.1.7? Could it allow for the ASA to bypass > > > authorization if it knows this value? Perhaps forming the nonce > from the > > > underlying session ID is not the best guidance? Also it seems the > underlying > > > protocol session ID is only 4 bytes and collisions are likely and > may be a > > > problem for the protocol. > > > > No, the collision risk is avoided because the session nonce includes > the > > ACP IPv6 address of the session originator. We should explain that > > more clearly. > > > > [Joe] I still have the question of whether the nonce should be revealed > to the API caller or left internal to the implementation. > > If a caller is running multiple parallel sessions, there needs to be > *something* in the API; it's exactly the same as a socket in that respect > (in fact, in an implementation, it must map 1:1 to a socket). > > An ASA can't usurp itself. The only risk I can see is that one ASA usurps > another > one in the same node by somehow stealing a session nonce. Given the trust > model, > is that really a concern? (An implementation of GRASP could choose to use > a process ID as an extra check, I suppose.) > > > > > > > > > > > > > 5. Error Codes > > > > > > In general, the list of API codes in the appendix is not described > in the API. > > > It seems they should be. Some of the error codes seem related to > > > authorization, which is out of scope? > > > > Our hope was the the WG could move faster on that topic, but the > > incredible delays on BRSKI and the ACP made that impossible. > > Our idea is certainly that register_asa() and register_objective() > > should include authorization in the longer term. > > > > > > [Joe] I think it would be helpful for the API spec to list the valid > error codes for each call. > > We can annotate the error code list and get the same effect with less > clutter. > > Regards > Brian > > > > > > > > It seems that some of the error code could lead to disclosure of > information, > > > for example: > > > > > > notYourASA 7 "ASA registered but not by you" might reveal a > valid nonce > > > from an invalid nonce > > > > Hmm... I don't think so. Let me glance at the code... > > > > The only place where I found that error code useful was in > deregister_asa() > > and that doesn't return anything else. It could be used in an > exhaustive > > search attack to deregister an ASA, but in the current trust model > that > > doesn't seem like a significant risk. > > > > > > > > 6. Denial of service > > > > > > are there protections in the underlying protocol for denial of > service with > > > respect to Flood(), Synchronize() or any other method? > > > > There are recommendations about rate throttling for relaying GRASP > Flood and > > Discover multicasts, which should confine any multicast abuse to a > single > > link-layer segment. That's one good reason for using link-layer > multicast only. > > We also have recommendations for exponential backoff in the GRASP > spec, but > > of course a malicious sender could ignore those. In any case we can > put a > > specific pointer to that subsection of the GRASP Security > Considerations. > > > > DoS against the Negotiate or Synchronize parts of GRASP seems to be > like > > any other client/server protocol. I'm not sure what we can say in the > > API spec about that. In my implementation (which is not intended to > be > > production quality) I've simply put finite queues for all the request > > handlers, with silent discard if the queue overflows. > > > > We'll collate updates to all reviews after the LC expires. > > > > > > [Joe] OK thanks. > > > > > > Thanks again > > Brian > > > > > > > > --000000000000e6c43305b3a5c967 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks=C2=A0Brain,=C2=A0

Exp= licitly defining the trust model will address most=C2=A0of the comments,=C2= =A0and I think you have dealt with any other outstanding=C2=A0ones below.= =C2=A0 I think you may find it would be better to have a mechanism to estab= lish trust in individual participants, however I understand that the group = has pushed this to future work.=C2=A0=C2=A0

Cheers= ,

Joe

On Sat, Nov 7, 2020 at 4:28 PM Brian E Carpen= ter <brian.e.carpenter@gm= ail.com> wrote:
Joe,

A few more comments in line:

On 02-Nov-20 19:02, Joseph Salowey wrote:
> (Forwarding my response=C2=A0to the rest of the audience)
>
> Hi Brian,=C2=A0
>
> Thanks for the quick response,=C2=A0 additional questions and comments= inline below:
>
> On Tue, Oct 27, 2020 at 6:58 PM Brian E Carpenter <brian.e.carpenter@gmail.co= m <mailto:brian.e.carpenter@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Joseph,
>
>=C2=A0 =C2=A0 =C2=A0Thanks for the review. Comments in line...
>
>=C2=A0 =C2=A0 =C2=A0On 28-Oct-20 06:25, Joseph Salowey via Datatracker = wrote:
>=C2=A0 =C2=A0 =C2=A0> Reviewer: Joseph Salowey
>=C2=A0 =C2=A0 =C2=A0> Review result: Has Issues
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I have reviewed this document as part of the s= ecurity directorate's
>=C2=A0 =C2=A0 =C2=A0> ongoing effort to review all IETF documents be= ing processed by the
>=C2=A0 =C2=A0 =C2=A0> IESG.=C2=A0 These comments were written primar= ily for the benefit of the
>=C2=A0 =C2=A0 =C2=A0> security area directors.=C2=A0 Document editor= s and WG chairs should treat
>=C2=A0 =C2=A0 =C2=A0> these comments just like any other last call c= omments.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The summary of the review is Has issues.=C2=A0= The document does needs a bit more
>=C2=A0 =C2=A0 =C2=A0> discussion of the security implications.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> 1. Authorization
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> In the security considerations section the doc= ument says that authorization is
>=C2=A0 =C2=A0 =C2=A0> left for future work.=C2=A0 I would expect tha= t the section should at least describe
>=C2=A0 =C2=A0 =C2=A0> what the implications of no authorizations are= .
>
>=C2=A0 =C2=A0 =C2=A0This isn't really an issue for the API itself, = but for the underlying protocol
>=C2=A0 =C2=A0 =C2=A0and for the ANIMA ecosystem. It's an issue that= the WG explicitly deferred
>=C2=A0 =C2=A0 =C2=A0(and it's now a chartered work item). Let me qu= ote here what the GRASP spec
>=C2=A0 =C2=A0 =C2=A0says in its security considerations:
>
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 - Authorization and Roles
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0The GRASP protoc= ol is agnostic about the roles and capabilities of
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0individual ASAs = and about which objectives a particular ASA is
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0authorized to su= pport.=C2=A0 An implementation might support
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0precautions such= as allowing only one ASA in a given node to
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0modify a given o= bjective, but this may not be appropriate in all
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0cases.=C2=A0 For= example, it might be operationally useful to allow an
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0old and a new ve= rsion of the same ASA to run simultaneously during
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0an overlap perio= d.=C2=A0 These questions are out of scope for the
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0present specific= ation.
>
>=C2=A0 =C2=A0 =C2=A0and what draft-carpenter-anima-asa-guidelines says:=
>
>=C2=A0 =C2=A0 =C2=A0>> Authorization of ASAs is a subject for fut= ure study. At present, ASAs are trusted by virtue of being installed on a n= ode that has successfully joined the ACP. In the general case, a node may h= ave mutltiple roles and a role may use multiple ASAs, each using multiple G= RASP objectives. Additional mechanisms for the authorization of nodes and A= SAs to manipulate specific GRASP objectives could be designed.
>
>=C2=A0 =C2=A0 =C2=A0That draft is on the verge of WG adoption. The poin= t is that the current
>=C2=A0 =C2=A0 =C2=A0trust model is that we trust any node that has succ= essfully joined the ACP,
>=C2=A0 =C2=A0 =C2=A0and therefore we trust any ASA in such a node. We s= hould state that clearly
>=C2=A0 =C2=A0 =C2=A0in the text.
>
>=C2=A0 =C2=A0 =C2=A0IMHO it would be out of scope for the API to say mo= re but we should add a
>=C2=A0 =C2=A0 =C2=A0reference to the GRASP Security Considerations.=C2= =A0
>
>=C2=A0 =C2=A0 =C2=A0> What risks are not being
>=C2=A0 =C2=A0 =C2=A0> mitigated?=C2=A0 =C2=A0What modes of operation= s should not be used?
>
>=C2=A0 =C2=A0 =C2=A0Those are good questions for the WG to look at.
>
>
> [Joe] These are the sort of things I would expect to be described in t= he security considerations.

I meant "good questions to look at when investigating possible
ASA authorization models."
>
> I'm trying to get my bearing in what the current model is here.=C2= =A0 In particular=C2=A0it seems that any security is applied at the "A= CP".

Exactly.

> What is the relationship of an ASA to an ACP node?

We'll try to clarify that in the next version. An ASA runs in an ACP no= de and therefore inherits all the security properties of an ACP node (i.e. = message integrity, message confidentiality and the fact that unauthorized n= odes cannot join the ACP).
=C2=A0 =C2=A0
>
> Does the ACP provide a security guarantee=C2=A0that it will send a mes= sage to the correct ASA running on the correct system?=C2=A0 Does it ensure= that a message received was sent by the correct system?=C2=A0 I couldn'= ;t find these answers in the security considerations of ACP, GRASP or GRASP= API.=C2=A0

The ACP is agnostic about indivdual ASAs, but the ACP is built in such a wa= y
that messages can't miscarry since there is no way for a node to usurp = another
node's IP address. The GRASP Session ID ensures that messages are deliv= ered
to the appropriate peer.

>=C2=A0 =C2=A0 =C2=A0> In general leaving
>=C2=A0 =C2=A0 =C2=A0> security items out suggests that the work is n= ot ready for wide deployment.
>=C2=A0 =C2=A0 =C2=A0> Perhaps this is OK because the work is informa= tional, but the document should
>=C2=A0 =C2=A0 =C2=A0> probably say this.>
>
>=C2=A0 =C2=A0 =C2=A0Personally I don't think we have left a hole he= re, because there's a well-defined
>=C2=A0 =C2=A0 =C2=A0trust boundary, but we should indeed state that as = well as citing the GRASP spec's
>=C2=A0 =C2=A0 =C2=A0security considerations.
>
> [Joe] Yes please,=C2=A0 defining the trust model would help.

Ack.

> =C2=A0
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> 2. Authentication
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Section 2.3.1.4 discusses the ASA_locator.=C2= =A0 How is is the entity accessed by
>=C2=A0 =C2=A0 =C2=A0> the locator authenticated?=C2=A0 How does the = caller of the API know they are
>=C2=A0 =C2=A0 =C2=A0> talking to the right entity?=C2=A0 I don't= see any discussion of this in this
>=C2=A0 =C2=A0 =C2=A0> document and there is very little in draft-iet= f-anima-grasp-15 on this.=C2=A0 =C2=A0 Is
>=C2=A0 =C2=A0 =C2=A0> there a section in one of these documents I sh= ould be looking for?
>
>=C2=A0 =C2=A0 =C2=A0No, you're not missing anything. The trust boun= dary is the ACP, and that takes
>=C2=A0 =C2=A0 =C2=A0us back to the previous point. If we do decide that= we need a fine-grained
>=C2=A0 =C2=A0 =C2=A0trust model inside the ACP, we'll presumably ne= ed to extend GRASP itself
>=C2=A0 =C2=A0 =C2=A0to add some form of authentication option beyond wh= at GRASP over TLS can
>=C2=A0 =C2=A0 =C2=A0provide.
>
> [Joe] From my understanding the ASA_locator is referencing a remote sy= stem that the caller of the API is going to interact with. If this is true = then there must be some way for the local system to make sure that the iden= tity of the remote system is indeed the same entity they reference in the A= PI.=C2=A0 I would expect somewhere in one of the specifications that there = needs to be some mapping between the name specified API and the name authen= ticated in TLS (typically in the subjectAlternativeName in a certificate), = but it could be established in other ways.=C2=A0

No, the GRASP discovery process operates over the ACP so is protected by th= at (e.g. by TLS in a TLS-based ACP, but that's not the only way it coul= d be). The discovery process returns a locator and as noted above, that can= 't be usurped, so we're done.

This wouldn't be safe on the open Internet, but we aren't on the op= en Internet. (It wasn't by chance that we developed RFC8799 while worki= ng on ANIMA.)
=C2=A0
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> 3. ASA_Nonce
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The ASA nonce is described as a security mecha= nism.=C2=A0 It is only 4 bytes long.
>=C2=A0 =C2=A0 =C2=A0> This seems short, making the ASA_Nonce vulnera= ble to collisions.=C2=A0 Why is this
>=C2=A0 =C2=A0 =C2=A0> not a problem?
>
>=C2=A0 =C2=A0 =C2=A0This isn't used on the wire, just locally withi= n the GRASP instance,
>=C2=A0 =C2=A0 =C2=A0so collisions can be excluded.
>
> [Joe] OK, thanks.
> =C2=A0
>
>=C2=A0 =C2=A0 =C2=A0> How long is the ASA nonce supposed to be valid= ?=C2=A0 How often does registration
>=C2=A0 =C2=A0 =C2=A0> happen?
>
>=C2=A0 =C2=A0 =C2=A0At the moment, there is no sensible answer to those= questions. When we develop
>=C2=A0 =C2=A0 =C2=A0the authorization model, we'd definitely have t= o answer those questions and maybe
>=C2=A0 =C2=A0 =C2=A0the nonce would have to be replaced by a crypto obj= ect.
>
> [Joe] OK.
>
> =C2=A0
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> 4. Session Nonce
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Are there security implications of revealing t= he session nonce to the caller as
>=C2=A0 =C2=A0 =C2=A0> suggested in section 2.3.1.7?=C2=A0 Could it a= llow for the ASA to bypass
>=C2=A0 =C2=A0 =C2=A0> authorization if it knows this value?=C2=A0 = =C2=A0Perhaps forming the nonce from the
>=C2=A0 =C2=A0 =C2=A0> underlying session ID is not the best guidance= ?=C2=A0 Also it seems the underlying
>=C2=A0 =C2=A0 =C2=A0> protocol session ID is only 4 bytes and collis= ions are likely and may be a
>=C2=A0 =C2=A0 =C2=A0> problem for the protocol.
>
>=C2=A0 =C2=A0 =C2=A0No, the collision risk is avoided because the sessi= on nonce includes the
>=C2=A0 =C2=A0 =C2=A0ACP IPv6 address of the session originator. We shou= ld explain that
>=C2=A0 =C2=A0 =C2=A0more clearly.
>
> [Joe]=C2=A0 I still have the question of whether the nonce should be r= evealed to the API caller or left internal to the implementation.

If a caller is running multiple parallel sessions, there needs to be *somet= hing* in the API; it's exactly the same as a socket in that respect (in= fact, in an implementation, it must map 1:1 to a socket).

An ASA can't usurp itself. The only risk I can see is that one ASA usur= ps another
one in the same node by somehow stealing a session nonce. Given the trust m= odel,
is that really a concern? (An implementation of GRASP could choose to use a process ID as an extra check, I suppose.)

>
> =C2=A0
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> 5. Error Codes
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> In general, the list of API codes in the appen= dix is not described in the API.
>=C2=A0 =C2=A0 =C2=A0> It seems they should be.=C2=A0 Some of the err= or codes seem related to
>=C2=A0 =C2=A0 =C2=A0> authorization, which is out of scope?
>
>=C2=A0 =C2=A0 =C2=A0Our hope was the the WG could move faster on that t= opic, but the
>=C2=A0 =C2=A0 =C2=A0incredible delays on BRSKI and the ACP made that im= possible.
>=C2=A0 =C2=A0 =C2=A0Our idea is certainly that register_asa() and regis= ter_objective()
>=C2=A0 =C2=A0 =C2=A0should include authorization in the longer term. >
>
> [Joe]=C2=A0 I think it would be helpful for the API spec to list the v= alid error codes for each call.

We can annotate the error code list and get the same effect with less clutt= er.

Regards
=C2=A0 =C2=A0 Brian

> =C2=A0
>
>=C2=A0 =C2=A0 =C2=A0> It seems that some of the error code could lea= d to disclosure of information,
>=C2=A0 =C2=A0 =C2=A0> for example:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> notYourASA=C2=A0 =C2=A0 =C2=A0 =C2=A07 "A= SA registered but not by you"=C2=A0 might reveal a valid nonce
>=C2=A0 =C2=A0 =C2=A0> from an invalid nonce
>
>=C2=A0 =C2=A0 =C2=A0Hmm... I don't think so. Let me glance at the c= ode...
>
>=C2=A0 =C2=A0 =C2=A0The only place where I found that error code useful= was in deregister_asa()
>=C2=A0 =C2=A0 =C2=A0and that doesn't return anything else. It could= be used in an exhaustive
>=C2=A0 =C2=A0 =C2=A0search attack to deregister an ASA, but in the curr= ent trust model that
>=C2=A0 =C2=A0 =C2=A0doesn't seem like a significant risk.
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> 6. Denial of service
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> are there protections in the underlying protoc= ol for denial of service with
>=C2=A0 =C2=A0 =C2=A0> respect to Flood(), Synchronize() or any other= method?
>
>=C2=A0 =C2=A0 =C2=A0There are recommendations about rate throttling for= relaying GRASP Flood and
>=C2=A0 =C2=A0 =C2=A0Discover multicasts, which should confine any multi= cast abuse to a single
>=C2=A0 =C2=A0 =C2=A0link-layer segment. That's one good reason for = using link-layer multicast only.
>=C2=A0 =C2=A0 =C2=A0We also have recommendations for exponential backof= f in the GRASP spec, but
>=C2=A0 =C2=A0 =C2=A0of course a malicious sender could ignore those. In= any case we can put a
>=C2=A0 =C2=A0 =C2=A0specific pointer to that subsection of the GRASP Se= curity Considerations.
>
>=C2=A0 =C2=A0 =C2=A0DoS against the Negotiate or Synchronize parts of G= RASP seems to be like
>=C2=A0 =C2=A0 =C2=A0any other client/server protocol. I'm not sure = what we can say in the
>=C2=A0 =C2=A0 =C2=A0API spec about that. In my implementation (which is= not intended to be
>=C2=A0 =C2=A0 =C2=A0production quality) I've simply put finite queu= es for all the request
>=C2=A0 =C2=A0 =C2=A0handlers, with silent discard if the queue overflow= s.
>
>=C2=A0 =C2=A0 =C2=A0We'll collate updates to all reviews after the = LC expires.
>
>
> [Joe] OK thanks.=C2=A0
> =C2=A0
>
>=C2=A0 =C2=A0 =C2=A0Thanks again
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 Brian
>
>
>

--000000000000e6c43305b3a5c967-- From nobody Tue Nov 10 18:14:11 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1980B3A106D; Tue, 10 Nov 2020 18:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.696 X-Spam-Level: X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgzQPgK2w9dH; Tue, 10 Nov 2020 18:13:58 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B963A12E8; Tue, 10 Nov 2020 18:13:57 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id d17so1006296lfq.10; Tue, 10 Nov 2020 18:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TBke/hQVVT1+2vEHyCjRrLwg4rr597f2gn/TFqE0OG0=; b=WH0cuH/MJ9tWWEAFcqxj7U1LuQ6Tt0Hmc7oMO8I+sy8XzhUtPu3wR9QoEmuoOJdtOB J8EUEFTvGL4wTlE0y8ZBwxpD/i89PT/x28ykBOuHEYFFzQl26YRXOFlsXw4kNcDv2RNi LeJC9i2fnJtXqMMI/g+PXu331EEskBU0afKmsMVVoJnvXuXaZs+RYeYvN/mGpSSBfv10 kUYKjoOyB9HZZunXKYNVOVE2G2Ju9jKvmevzfO6wnXoawUUrYEMzoKaMdtg2MTXlt5Rg /vxSolUnQ1G4Q3ac8aWx6zOJoDcUJ6AZ9Eii8NM19rgD4Ceqb1lG5jbHdNWCa39GAHJ+ 7Kqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TBke/hQVVT1+2vEHyCjRrLwg4rr597f2gn/TFqE0OG0=; b=m3MJknBLlc7IqgIOey2cVJGkaSswXbigbUiTNicjhAhi3K+EBBLAFG3mTbWdV4jrae EExuUAHwTQ52zNyIAsVGU65/DcsNT0uy7uvriUiXQC/nqiDT6F5HhqhVA4ZDNa660064 a5CSL7F/IKUF+CMEyn3dQC5AFB72bY2JYAChhj+6HjmniB/7ZXtzk5fMT9FNdqIvX4og xJKLNqQhy8t5nmzNhJbK/ZdNurBPtNQuRRLpJN+9I7cwknf0XPuVTQKiOSmeCfU8q/H2 Swbue2D+K0C7IvPAZlEkg0Ft0z09cd0JR9rKHQpT+5haX8H7qqGv4uLWt1xz1awkwS5+ L0BQ== X-Gm-Message-State: AOAM532/sG4f+EUYGwkoBS7pZUKi+98puRcmEr29PuIV0fXDTcNxI3sB qfBlq9athURmoO8qkmaIRQd5JwEb0nAUARsQ6SU= X-Google-Smtp-Source: ABdhPJyPePa22qjdLoLTzpVFoGRkZeI4wgQen6wGWiJg/ZiedRu1X8AvyJOnldDZI+q1iMfEZx3Qjyr8fPJbh1CGa5E= X-Received: by 2002:ac2:46cc:: with SMTP id p12mr6168385lfo.56.1605060835238; Tue, 10 Nov 2020 18:13:55 -0800 (PST) MIME-Version: 1.0 References: <160345656094.22100.7057001737682109381@ietfa.amsl.com> In-Reply-To: <160345656094.22100.7057001737682109381@ietfa.amsl.com> From: Greg Mirsky Date: Tue, 10 Nov 2020 18:13:43 -0800 Message-ID: To: Daniel Migault Cc: secdir@ietf.org, BESS , last-call@ietf.org, draft-ietf-bess-mvpn-fast-failover.all@ietf.org Content-Type: multipart/mixed; boundary="000000000000ed8d2405b3cb5875" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-bess-mvpn-fast-failover-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 02:14:04 -0000 --000000000000ed8d2405b3cb5875 Content-Type: multipart/alternative; boundary="000000000000ed8d2105b3cb5873" --000000000000ed8d2105b3cb5873 Content-Type: text/plain; charset="UTF-8" Hi Daniel, many thanks for the review, thoughtful comments, and questions, all are much appreciated. Also, my apologies for the long delay to respond to your comments. Please find my answers and notes in-line below tagged by GIM>>. Attached are the new working version and the diff to -12. Regards, Greg On Fri, Oct 23, 2020 at 5:36 AM Daniel Migault via Datatracker < noreply@ietf.org> wrote: > Reviewer: Daniel Migault > Review result: Has Nits > > Hi, > > > I reviewed this document as part of the Security Directorate's ongoing > effort to > review all IETF documents being processed by the IESG. These comments were > written primarily for the benefit of the Security Area Directors. Document > authors, document editors, and WG chairs should treat these comments just > like > any other IETF Last Call comments. Please note also that my expertise in > BGP is > limited, so feel free to take these comments with a pitch of salt. > > Review Results: Has Nits > > Please find my comments below. > > Yours, > Daniel > > > Multicast VPN Fast Upstream Failover > draft-ietf-bess-mvpn-fast-failover-11 > > Abstract > > This document defines multicast VPN extensions and procedures that > allow fast failover for upstream failures, by allowing downstream PEs > to take into account the status of Provider-Tunnels (P-tunnels) when > selecting the Upstream PE for a VPN multicast flow, and extending BGP > MVPN routing so that a C-multicast route can be advertised toward a > Standby Upstream PE. > > > Though it might be just a nit, if MVPN > designates multicast VPN, it might be > clarifying to specify the acronym in the > first sentence. This would later make > the correlation with BGP MVPN clearer. > > > GIM>> I've updated s/BGP MVPN/BGP multicast VPN/. Also, s/mVPN/MVPN/ throughout the document. > > > 1. Introduction > > In the context of multicast in BGP/MPLS VPNs, it is desirable to > provide mechanisms allowing fast recovery of connectivity on > different types of failures. This document addresses failures of > elements in the provider network that are upstream of PEs connected > to VPN sites with receivers. > > > Well I am not familiar with neither BGP > nor MPLS. It seems that BGP/MLPS IP VPNS > and MPLS/BGP IP VPNs are both used. I am > wondering if there is a distinction > between the two and a preferred way to > designate these VPNs. My understanding > is that the VPN-IPv4 characterizes the > VPN while MPLS is used by the backbone > for the transport. Since the PE are > connected to the backbone the VPN-IPv4 > needs to be labeled. > > > GIM>> I understand that this document often sends the reader to check RFC 6513 and/or RFC 6514. BGP/MPLS MVPN identifies the case of providing a multicast service over an IP VPN that is overlayed on the MPLS data plane using the BGP control plane. > > Section 3 describes local procedures allowing an egress PE (a PE > connected to a receiver site) to take into account the status of > P-tunnels to determine the Upstream Multicast Hop (UMH) for a given > (C-S, C-G). This method does not provide a "fast failover" solution > > I understand the limitation is due to > BGP convergence. > > > GIM>> Yes, a dynamic routing protocol, BGP in this case, provides the service restoration functionality but the restoration time is significant and affects the experience of a client. when used alone, but can be used together with the mechanism > described in Section 4 for a "fast failover" solution. > > Section 4 describes protocol extensions that can speed up failover by > not requiring any multicast VPN routing message exchange at recovery > time. > > Moreover, section 5 describes a "hot leaf standby" mechanism, that > uses a combination of these two mechanisms. This approach has > similarities with the solution described in [RFC7431] to improve > failover times when PIM routing is used in a network given some > topology and metric constraints. > > > [...] > > 3.1.1. mVPN Tunnel Root Tracking > > A condition to consider that the status of a P-tunnel is up is that > the root of the tunnel, as determined in the x-PMSI Tunnel attribute, > is reachable through unicast routing tables. In this case, the > downstream PE can immediately update its UMH when the reachability > condition changes. > > That is similar to BGP next-hop tracking for VPN routes, except that > the address considered is not the BGP next-hop address, but the root > address in the x-PMSI Tunnel attribute. > > If BGP next-hop tracking is done for VPN routes and the root address > of a given tunnel happens to be the same as the next-hop address in > the BGP A-D Route advertising the tunnel, then checking, in unicast > routing tables, whether the tunnel root is reachable, will be > unnecessary duplication and thus will not bring any specific benefit. > > > It seems to me that x-PMSI address > designates a different interface than > the one used by the Tunnel itself. If > that is correct, such mechanisms seems > to assume that one equipment up on one > interface will be up on the other > interfaces. I have the impression that a > configuration change in a PE may end up > in the P-tunnel being down, while the PE > still being reachable though the x-PMSI > Tunnel attribute. If that is a possible > scenario, the current mechanisms may not > provide more efficient mechanism than > then those of the standard BGP. > GIM>> That is a very interesting angle, thank you. Yes, in OAM, and in the Fault Management (FM) OAM in particular, we have to make some assumptions about the state of the remote system based on a single event or change of state. Usually, AFAIK, operators use not a physical interface but a loopback to associate with a tunnel. With a fast IGP convergence, a loopback interface is reachable as long as there's a path through the network between two nodes. > > Similarly, it is assumed the tunnel is > either up or down and the determination > of not being up if being down. I am not > convinced that the two only states. > Typically services under DDoS may be > down for a small amount of time. While > this affects the network, there is not > always a clear cut between the PE being > up or down. > > GIM>> In defect detection a system often has some hysteresis, i.e., time that the system has to wait to change its state. For example, BFD changes state from Up to Down after the system does not receive N consecutive packets (usually 3). As a result, in some cases, the system can be tuned to detect relatively short outages while in others be slower and miss short-lived outages. > > > [...] > > 3.1.6. BFD Discriminator Attribute > > P-tunnel status may be derived from the status of a multipoint BFD > session [RFC8562] whose discriminator is advertised along with an > x-PMSI A-D Route. > > This document defines the format and ways of using a new BGP > attribute called the "BFD Discriminator". It is an optional > transitive BGP attribute. In Section 7.2, IANA is requested to > allocate the codepoint value (TBA2). The format of this attribute is > shown in Figure 1. > > > I feel that the sentence "In Section ... > TBA2)." should be removed. > > > GIM>> We use this to mark where to note the allocated value. Usually, this text is replaced by the RFC Editor to read In Section 7.2 IANA allocated codepoint XXX. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BFD Mode | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BFD Discriminator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Optional TLVs ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 1: Format of the BFD Discriminator Attribute > > Where: > > BFD Mode field is the one octet long. This specification defines > the P2MP BFD Session as value 1 Section 7.2. > > Reserved field is three octets long, and the value MUST be zeroed > on transmission and ignored on receipt. > > BFD Discriminator field is four octets long. > > > > > > Morin, et al. Expires April 5, 2021 [Page 7] > > Internet-Draft mVPN Fast Upstream Failover October 2020 > > > Optional TLVs is the optional variable-length field that MAY be > used in the BFD Discriminator attribute for future extensions. > TLVs MAY be included in a sequential or nested manner. To allow > for TLV nesting, it is advised to define a new TLV as a variable- > length object. Figure 2 presents the Optional TLV format TLV that > consists of: > > * one octet-long field of TLV 's Type value (Section 7.3) > > * one octet-long field of the length of the Value field in octets > > * variable length Value field. > > The length of a TLV MUST be multiple of four octets. > > I am wondering why the constraint on the > length is not mentioned in the paragraph > associated to the field - as opposed to > a separate paragraph. > > > GIM>> There might be a slight confusion due to the use of Length and length. Capitalized - the name of the field which value is the length of the Value field. The last sentence refers to the overall length of a TLV, including lengths of Type, Length and Value fields. > > [..] > > 8. Security Considerations > > This document describes procedures based on [RFC6513] and [RFC6514] > and hence shares the security considerations respectively represented > in these specifications. > > This document uses p2mp BFD, as defined in [RFC8562], which, in turn, > is based on [RFC5880]. Security considerations relevant to each > protocol are discussed in the respective protocol specifications. An > implementation that supports this specification MUST use a mechanism > to control the maximum number of p2mp BFD sessions that can be active > at the same time. > > > At a high level view - or at least my > interpretation of it - the document > proposes a mechanism based on BFD to > detect fault in the path. Upon a fault > detection a fail-over operation is > instructed using BGP. This rocedure is > expected to perform a faster fail-over > than traditional BGP convergence on > maintaining routing tables. Once the > fail over has been performed, BFD is > confirms the new path is "legitimate" > and works. > > It seems correct to me that the current > protocol relies on BGP / BFD security. > That said, having BFD authentication > based on MD5 or SHA1 may suggest that > stronger primitives be recommended. > While this does not concerns the current > document, it seems to me that the > information might be relayed to routing > ADs. > > What remains unclear to me - and I > assume this might be due to my lake or > expertise in routing area - is the impact > associated to performing a fail-over > both on 1) the data plane and 2) the > standard BGP way to establish routing > tables. > > Regarding the data plane, I am wondering > if fail-over results in a lost of > packets for example - I suppose for > example that at least the packets in the > process of being forwarded might be > lost. I believe that providing details > on this may be good. > GIM>> You bring up a very topic for the discussion, thank you. With network failure detection in place, the fail-over can be viewed as the reaction to a network failure. If that is the case, then packet loss experienced by service due to the fail-over is the result of the network failure. Would you agree with that view? A shorter failure detection interval and faster fail-over should minimize the packet loss and, as a result, the negative impact on the service itself. > > If there are any impacts I would like to > understand also in which cases the > decision to perform a failover operation > may result in more harm than the event > that has been over-interpreted. An > hypothetical scenario could be that the > non reception of a BFD packet is > interpreted as a PE being down while it > may not be correct and the PE might have > been simply under stress. A "too fast" fail-over > may over interpreted it and perform a > fail-over. If such things could happen, > an attacker could leverage a micro event > to perform network operation that are > not negligible. Another way to see that > is that an attacker might not have > direct access to the control plan, but > could use the data plan to generate a > stress and sort of control the fail > over. It seems to me that some text > might be welcome to prevent such cases > to happen. This could be guidance for > declaring a tunnel down for example. > GIM>> I agree with your scenario. Over-short detection interval may produce a false-negative transition to the Down state in BFD and thus triggering the fail-over. I think that that is more an operational issue, something that an operator will consider when deploying the mechanism specified in this draft. Resulting from addressing RtgDir review the draft was updated to provide more guidance: In many cases, it is not practical to use both protection methods at the same time because uncorrelated timers might cause unnecessary switchovers and destabilize the network. Though the text above might not be general, I think that it also applies to the scenario you've presented. > > Similarly, it would be good to add some > text regarding the interferences with > the non-fast forwarding fail over when > performed by the standard BGP. > Typically, my impression is that the > fast fail-over mechanism is a local > decision versus the BGP convergence that > is more global. As a result, even with > more time this two mechanisms may come > with different outcomes. One such > example to illustrate my purpose could > be the following. Note that this is only > illustrative of my purpose, and I let > you find and pick on ethat is more > appropriated. I am thinking of a case > where a standby PE is be shared among > multiple PEs - supposing this situation > could occur. Typically, if PE_1, PE_2 > are shared by PE_a, ..., PE_z. In case > PE_a and PE_b are down, we expect PE_a > to switch to PE_1 and PE_b to switch to > PE_2. It seems to me that BGP would end > up in such situation while a local > decision may end up in PE_a and PE_a to > switch to PE_1. > > > GIM>> Thank you for the scenario that is very common in deploying protection based on the shared redundant resources. Such schemes, referred to as M:N protection, in addition to using mechanism detecting a network failure, e.g., BFD, require a protocol to coordinate the switchover. This specification applies to a more special deployment scenario where one working PE is protected by one or more standby PEs, i.e., 1:N protection. --000000000000ed8d2105b3cb5873 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Daniel,
many thanks for the review= , thoughtful comments, and questions, all are much appreciated. Also, my ap= ologies for the long delay to respond to your comments. Please find my answ= ers and notes in-line below tagged by GIM>>. Attached are the new wor= king version and the diff to -12.

Regards,
Greg

On Fri, Oct 23, 2020 at 5:36 AM Daniel Migault via Datatracker= <noreply@ietf.org> wrote:
Reviewer: Daniel M= igault
Review result: Has Nits

Hi,


I reviewed this document as part of the Security Directorate's ongoing = effort to
review all IETF documents being processed by the IESG.=C2=A0 These comments= were
written primarily for the benefit of the Security Area Directors.=C2=A0 Doc= ument
authors, document editors, and WG chairs should treat these comments just l= ike
any other IETF Last Call comments.=C2=A0 Please note also that my expertise= in BGP is
limited, so feel free to take these comments with a pitch of salt.=C2=A0
Review Results: Has Nits

Please find my comments below.

Yours,
Daniel


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Multicast VP= N Fast Upstream Failover
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-be= ss-mvpn-fast-failover-11

Abstract

=C2=A0 =C2=A0This document defines multicast VPN extensions and procedures = that
=C2=A0 =C2=A0allow fast failover for upstream failures, by allowing downstr= eam PEs
=C2=A0 =C2=A0to take into account the status of Provider-Tunnels (P-tunnels= ) when
=C2=A0 =C2=A0selecting the Upstream PE for a VPN multicast flow, and extend= ing BGP
=C2=A0 =C2=A0MVPN routing so that a C-multicast route can be advertised tow= ard a
=C2=A0 =C2=A0Standby Upstream PE.

<mglt>
Though it might be just a nit, if MVPN
designates multicast VPN, it might be
clarifying to specify the acronym in the
first sentence. This would later make
the correlation with BGP MVPN clearer.

</mglt>
GIM>> I've updated s/BGP MVPN/= BGP multicast VPN/. Also, s/mVPN/MVPN/ throughout the document.


1.=C2=A0 Introduction

=C2=A0 =C2=A0In the context of multicast in BGP/MPLS VPNs, it is desirable = to
=C2=A0 =C2=A0provide mechanisms allowing fast recovery of connectivity on =C2=A0 =C2=A0different types of failures.=C2=A0 This document addresses fai= lures of
=C2=A0 =C2=A0elements in the provider network that are upstream of PEs conn= ected
=C2=A0 =C2=A0to VPN sites with receivers.

<mglt>
Well I am not familiar with neither BGP
nor MPLS. It seems that BGP/MLPS IP VPNS
and MPLS/BGP IP VPNs are both used. I am
wondering if there is a distinction
between the two and a preferred way to
designate these VPNs.=C2=A0 My understanding
is that the VPN-IPv4 characterizes the
VPN while MPLS is used by the backbone
for the transport.=C2=A0 Since the PE are
connected to the backbone the VPN-IPv4
needs to be labeled.

</mglt>
GIM>> I understand that this docum= ent often sends the reader to check RFC 6513 and/or RFC 6514. BGP/MPLS MVPN= identifies the case of providing a multicast service over an IP VPN that i= s overlayed=C2=A0on the MPLS data plane using the BGP control plane.
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
=C2=A0 =C2=A0Section 3 describes local procedures allowing an egress PE (a = PE
=C2=A0 =C2=A0connected to a receiver site) to take into account the status = of
=C2=A0 =C2=A0P-tunnels to determine the Upstream Multicast Hop (UMH) for a = given
=C2=A0 =C2=A0(C-S, C-G).=C2=A0 This method does not provide a "fast fa= ilover" solution
<mglt>
I understand the limitation is due to
BGP convergence.

</mglt>
GIM>> Yes, a dynamic routing proto= col, BGP in this case, provides the service restoration functionality but t= he restoration time is significant and affects the experience of a client.<= /div>

=C2=A0 =C2=A0when used alone, but can be used together with the mechanism =C2=A0 =C2=A0described in Section 4 for a "fast failover" solutio= n.

=C2=A0 =C2=A0Section 4 describes protocol extensions that can speed up fail= over by
=C2=A0 =C2=A0not requiring any multicast VPN routing message exchange at re= covery
=C2=A0 =C2=A0time.

=C2=A0 =C2=A0Moreover, section 5 describes a "hot leaf standby" m= echanism, that
=C2=A0 =C2=A0uses a combination of these two mechanisms.=C2=A0 This approac= h has
=C2=A0 =C2=A0similarities with the solution described in [RFC7431] to impro= ve
=C2=A0 =C2=A0failover times when PIM routing is used in a network given som= e
=C2=A0 =C2=A0topology and metric constraints.


[...]

3.1.1.=C2=A0 mVPN Tunnel Root Tracking

=C2=A0 =C2=A0A condition to consider that the status of a P-tunnel is up is= that
=C2=A0 =C2=A0the root of the tunnel, as determined in the x-PMSI Tunnel att= ribute,
=C2=A0 =C2=A0is reachable through unicast routing tables.=C2=A0 In this cas= e, the
=C2=A0 =C2=A0downstream PE can immediately update its UMH when the reachabi= lity
=C2=A0 =C2=A0condition changes.

=C2=A0 =C2=A0That is similar to BGP next-hop tracking for VPN routes, excep= t that
=C2=A0 =C2=A0the address considered is not the BGP next-hop address, but th= e root
=C2=A0 =C2=A0address in the x-PMSI Tunnel attribute.

=C2=A0 =C2=A0If BGP next-hop tracking is done for VPN routes and the root a= ddress
=C2=A0 =C2=A0of a given tunnel happens to be the same as the next-hop addre= ss in
=C2=A0 =C2=A0the BGP A-D Route advertising the tunnel, then checking, in un= icast
=C2=A0 =C2=A0routing tables, whether the tunnel root is reachable, will be<= br> =C2=A0 =C2=A0unnecessary duplication and thus will not bring any specific b= enefit.

<mglt>
It seems to me that x-PMSI address
designates a different interface than
the one used by the Tunnel itself. If
that is correct, such mechanisms seems
to assume that one equipment up on one
interface will be up on the other
interfaces. I have the impression that a
configuration change in a PE may end up
in the P-tunnel being down, while the PE
still being reachable though the x-PMSI
Tunnel attribute. If that is a possible
scenario, the current mechanisms may not
provide more efficient mechanism than
then those of the standard BGP.
GIM>> That is a = very interesting angle, thank you. Yes, in OAM, and in the Fault Management= (FM) OAM in particular, we have to make some assumptions=C2=A0about the st= ate of the remote system based on a single event or change of state. Usuall= y, AFAIK, operators use not a physical interface but a loopback to associat= e with a tunnel. With a fast IGP convergence, a loopback interface is reach= able as long as there's a path through the network between two nodes.

Similarly, it is assumed the tunnel is
either up or down and the determination
of not being up if being down.=C2=A0 I am not
convinced that the two only states.
Typically services under DDoS may be
down for a small amount of time. While
this affects the network, there is not
always a clear cut between the PE being
up or down.
</mglt>
GIM>>=C2=A0 In defect detection a = system often has some hysteresis, i.e., time that the system has to wait to= change its state. For example, BFD changes state from Up to Down after the= system does not receive N consecutive packets (usually 3). As a result, in= some cases, the system can be tuned to detect relatively short outages whi= le in others be slower and miss short-lived outages.


[...]

3.1.6.=C2=A0 BFD Discriminator Attribute

=C2=A0 =C2=A0P-tunnel status may be derived from the status of a multipoint= BFD
=C2=A0 =C2=A0session [RFC8562] whose discriminator is advertised along with= an
=C2=A0 =C2=A0x-PMSI A-D Route.

=C2=A0 =C2=A0This document defines the format and ways of using a new BGP =C2=A0 =C2=A0attribute called the "BFD Discriminator".=C2=A0 It i= s an optional
=C2=A0 =C2=A0transitive BGP attribute.=C2=A0 In Section 7.2, IANA is reques= ted to
=C2=A0 =C2=A0allocate the codepoint value (TBA2).=C2=A0 The format of this = attribute is
=C2=A0 =C2=A0shown in Figure 1.

<mglt>
I feel that the sentence "In Section ...
TBA2)." should be removed.

</mglt>
GIM>> We use this to mark where to= note the allocated value. Usually, this text is replaced by the RFC Editor= to read=C2=A0
In Section 7.2 IANA allocate= d codepoint XXX.



=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A03
=C2=A0 =C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1
=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 BFD Mode=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Reserved=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=A0BFD Discriminator=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=A0Optional TLVs=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 Figure 1: Format of the BFD Discr= iminator Attribute

=C2=A0 =C2=A0Where:

=C2=A0 =C2=A0 =C2=A0 BFD Mode field is the one octet long.=C2=A0 This speci= fication defines
=C2=A0 =C2=A0 =C2=A0 the P2MP BFD Session as value 1 Section 7.2.

=C2=A0 =C2=A0 =C2=A0 Reserved field is three octets long, and the value MUS= T be zeroed
=C2=A0 =C2=A0 =C2=A0 on transmission and ignored on receipt.

=C2=A0 =C2=A0 =C2=A0 BFD Discriminator field is four octets long.





Morin, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires April = 5, 2021=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page = 7]

Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mVPN Fast Upstream Failover= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 October 2020


=C2=A0 =C2=A0 =C2=A0 Optional TLVs is the optional variable-length field th= at MAY be
=C2=A0 =C2=A0 =C2=A0 used in the BFD Discriminator attribute for future ext= ensions.
=C2=A0 =C2=A0 =C2=A0 TLVs MAY be included in a sequential or nested manner.= =C2=A0 To allow
=C2=A0 =C2=A0 =C2=A0 for TLV nesting, it is advised to define a new TLV as = a variable-
=C2=A0 =C2=A0 =C2=A0 length object.=C2=A0 Figure 2 presents the Optional TL= V format TLV that
=C2=A0 =C2=A0 =C2=A0 consists of:

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 one octet-long field of TLV 's Type value = (Section 7.3)

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 one octet-long field of the length of the Valu= e field in octets

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 variable length Value field.

=C2=A0 =C2=A0 =C2=A0 The length of a TLV MUST be multiple of four octets. <mglt>
I am wondering why the constraint on the
length is not mentioned in the paragraph
associated to the field - as opposed to
a=C2=A0 separate paragraph.

</mglt>
GIM>> There might be a slight conf= usion due to the use of Length and length. Capitalized - the name of the fi= eld which value is the length of the Value field. The last sentence refers = to the overall length of a TLV, including lengths of Type, Length and Value= fields.

[..]

8.=C2=A0 Security Considerations

=C2=A0 =C2=A0This document describes procedures based on [RFC6513] and [RFC= 6514]
=C2=A0 =C2=A0and hence shares the security considerations respectively repr= esented
=C2=A0 =C2=A0in these specifications.

=C2=A0 =C2=A0This document uses p2mp BFD, as defined in [RFC8562], which, i= n turn,
=C2=A0 =C2=A0is based on [RFC5880].=C2=A0 Security considerations relevant = to each
=C2=A0 =C2=A0protocol are discussed in the respective protocol specificatio= ns.=C2=A0 An
=C2=A0 =C2=A0implementation that supports this specification MUST use a mec= hanism
=C2=A0 =C2=A0to control the maximum number of p2mp BFD sessions that can be= active
=C2=A0 =C2=A0at the same time.

<mglt>
At a high level view - or at least my
interpretation of it - the document
proposes a mechanism based on BFD to
detect fault in the path.=C2=A0 Upon a fault
detection a fail-over operation is
instructed using BGP. This rocedure is
expected to perform a faster fail-over
than traditional BGP convergence on
maintaining routing tables. Once the
fail over has been performed, BFD is
confirms the new path is "legitimate"
and works.

It seems correct to me that the current
protocol relies on BGP / BFD security.
That said, having BFD authentication
based on MD5 or SHA1 may suggest that
stronger primitives be recommended.
While this does not concerns the current
document, it seems to me that the
information might be relayed to routing
ADs.

What remains unclear to me - and I
assume this might be due to my lake or
expertise in routing area - is the impact
associated to performing a fail-over
both on 1) the data plane and 2) the
standard BGP way to establish routing
tables.

Regarding the data plane, I am wondering
if fail-over results in a lost of
packets for example - I suppose for
example that at least the packets in the
process of being forwarded might be
lost. I believe that providing details
on this may be good.
GIM>> You bring up a very = topic for the discussion, thank you. With network failure detection in plac= e, the fail-over can be viewed as the reaction to a network failure.=C2=A0 = If that is the case, then packet loss experienced by service due to the fai= l-over is the result of the network failure. Would you agree with that view= ? A shorter failure detection interval=C2=A0and faster fail-over should min= imize the packet loss and, as a result, the negative impact on the service = itself.

If there are any impacts I would like to
understand also in which cases the
decision to perform a failover operation
may result in more harm than the event
that has been over-interpreted. An
hypothetical scenario could be that the
non reception of a BFD packet is
interpreted as a PE being down while it
may not be correct and the PE might have
been simply under stress. A "too fast" fail-over
may over interpreted it and perform a
fail-over. If such things could happen,
an attacker could leverage a micro event
to perform network operation that are
not negligible. Another way to see that
is that an attacker might not have
direct access to the control plan, but
could use the data plan to generate a
stress and sort of control the fail
over. It seems to me that some text
might be welcome to prevent such cases
to happen. This could be guidance for
declaring a tunnel down for example.
GIM>> I ag= ree with your scenario. Over-short detection interval may produce a false-n= egative transition to the Down state in BFD and thus triggering the fail-ov= er. I think that that is more an operational issue, something that an opera= tor will consider when deploying the mechanism specified in this draft. Res= ulting from addressing RtgDir review the draft was updated to provide more = guidance:
=C2=A0 =C2=A0In many cases, it is not practical to use = both protection
=C2=A0 =C2=A0methods at the same time because uncorrelat= ed timers might cause
=C2=A0 =C2=A0unnecessary switchovers and destabili= ze the network.
Though the text above might not be general, I= think that it also applies to the scenario you've presented.

Similarly, it would be good to add some
text regarding the interferences with
the non-fast forwarding fail over when
performed by the standard BGP.
Typically, my impression is that the
fast fail-over mechanism is a local
decision versus the BGP convergence that
is more global. As a result, even with
more time this two mechanisms may come
with different outcomes. One such
example to illustrate my purpose could
be the following. Note that this is only
illustrative of my purpose, and I let
you find and pick on ethat is more
appropriated.=C2=A0 =C2=A0I am thinking of a case
where a standby PE is be shared among
multiple PEs - supposing this situation
could occur.=C2=A0 Typically, if PE_1, PE_2
are shared by PE_a, ..., PE_z. In case
PE_a and PE_b are down, we expect PE_a
to switch to PE_1 and PE_b to switch to
PE_2. It seems to me that BGP would end
up in such situation while a local
decision may end up in PE_a and PE_a to
switch to PE_1.

</mglt>
GIM>> Thank you for the scenario t= hat is very common in deploying protection based on the shared redundant re= sources. Such schemes, referred to as M:N protection, in addition to using = mechanism detecting a network failure, e.g., BFD, require a protocol to coo= rdinate the switchover. This specification applies to a more special deploy= ment scenario where one working PE is protected by one or more standby PEs,= i.e., 1:N protection.
--000000000000ed8d2105b3cb5873-- --000000000000ed8d2405b3cb5875 Content-Type: text/plain; charset="US-ASCII"; name="draft-ietf-bess-mvpn-fast-failover-13.txt" Content-Disposition: attachment; filename="draft-ietf-bess-mvpn-fast-failover-13.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_khcrrebo0 CgoKCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgVC4gTW9yaW4sIEVkLgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPcmFuZ2UKSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgIFIuIEtlYmxlciwgRWQuCkV4cGly ZXM6IE1heSAxNCwgMjAyMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSnVuaXBl ciBOZXR3b3JrcwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgRy4gTWlyc2t5LCBFZC4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWlRFIENvcnAuCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOb3ZlbWJlciAxMCwgMjAy MAoKCiAgICAgICAgICAgICAgICAgIE11bHRpY2FzdCBWUE4gRmFzdCBVcHN0cmVhbSBGYWlsb3Zl cgogICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtYmVzcy1tdnBuLWZhc3QtZmFpbG92ZXItMTMK CkFic3RyYWN0CgogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgbXVsdGljYXN0IFZQTiBleHRlbnNp b25zIGFuZCBwcm9jZWR1cmVzIHRoYXQKICAgYWxsb3cgZmFzdCBmYWlsb3ZlciBmb3IgdXBzdHJl YW0gZmFpbHVyZXMgYnkgYWxsb3dpbmcgZG93bnN0cmVhbSBQRXMKICAgdG8gY29uc2lkZXIgdGhl IHN0YXR1cyBvZiBQcm92aWRlci1UdW5uZWxzIChQLXR1bm5lbHMpIHdoZW4gc2VsZWN0aW5nCiAg IHRoZSB1cHN0cmVhbSBQRSBmb3IgYSBWUE4gbXVsdGljYXN0IGZsb3cuICBUaGUgZmFzdCBmYWls b3ZlciBpcwogICBlbmFibGVkIGJ5IHVzaW5nIFJGQyA4NTYyIEJGRCBmb3IgTXVsdGlwb2ludCBO ZXR3b3JrcyBhbmQgdGhlIG5ldyBCR1AKICAgQXR0cmlidXRlIC0gQkZEIERpc2NyaW1pbmF0b3Iu ICBBbHNvLCB0aGUgZG9jdW1lbnQgaW50cm9kdWNlcyBhIG5ldwogICBCR1AgQ29tbXVuaXR5LCBT dGFuZGJ5IFBFLCBleHRlbmRpbmcgQkdQIE11bHRpY2FzdCBWUE4gcm91dGluZyBzbwogICB0aGF0 IGEgQy1tdWx0aWNhc3Qgcm91dGUgY2FuIGJlIGFkdmVydGlzZWQgdG93YXJkIGEgU3RhbmRieSBV cHN0cmVhbQogICBQRS4KClN0YXR1cyBvZiBUaGlzIE1lbW8KCiAgIFRoaXMgSW50ZXJuZXQtRHJh ZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUKICAgcHJvdmlzaW9u cyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBk b2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYp LiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlCiAgIHdvcmtpbmcg ZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJu ZXQtCiAgIERyYWZ0cyBpcyBhdCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9j dXJyZW50Ly4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZv ciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2Vk LCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMg aW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRl cmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgog ICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE1heSAxNCwgMjAyMS4KCkNvcHly aWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoYykgMjAyMCBJRVRGIFRydXN0IGFuZCB0aGUgcGVy c29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyBy ZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJ RVRGIFRydXN0J3MgTGVnYWwKICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50 cwoKCgpNb3JpbiwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDE0LCAyMDIxICAgICAg ICAgICAgICAgICAgW1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIE1WUE4gRmFzdCBV cHN0cmVhbSBGYWlsb3ZlciAgICAgICAgIE5vdmVtYmVyIDIwMjAKCgogICAoaHR0cHM6Ly90cnVz dGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1 YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50 cwogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0 aW9ucyB3aXRoIHJlc3BlY3QKICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBl eHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QKICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJT RCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mCiAgIHRoZSBUcnVz dCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcwog ICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuCgpUYWJsZSBvZiBDb250 ZW50cwoKICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gICAzCiAgIDIuICBDb252ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9j dW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMwogICAgIDIuMS4gIFJlcXVpcmVt ZW50cyBMYW5ndWFnZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMKICAg ICAyLjIuICBUZXJtaW5vbG9neSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICA0CiAgICAgMi4zLiAgQWNyb255bXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAogICAzLiAgVU1IIFNlbGVjdGlvbiBCYXNlZCBv biBUdW5uZWwgU3RhdHVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAgICAzLjEuICBE ZXRlcm1pbmluZyB0aGUgU3RhdHVzIG9mIGEgVHVubmVsICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICA2CiAgICAgICAzLjEuMS4gIE1WUE4gVHVubmVsIFJvb3QgVHJhY2tpbmcgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgNgogICAgICAgMy4xLjIuICBQRS1QIFVwc3RyZWFtIExpbmsgU3Rh dHVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcKICAgICAgIDMuMS4zLiAgUDJNUCBS U1ZQLVRFIFR1bm5lbHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3CiAgICAg ICAzLjEuNC4gIExlYWYtaW5pdGlhdGVkIFAtdHVubmVscyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgOAogICAgICAgMy4xLjUuICAoQy1TLCBDLUcpIENvdW50ZXIgSW5mb3JtYXRpb24g IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgKICAgICAgIDMuMS42LiAgQkZEIERpc2NyaW1pbmF0 b3IgQXR0cmlidXRlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4CiAgICAgICAzLjEuNy4g IFBlciBQRS1DRSBMaW5rIEJGRCBEaXNjcmltaW5hdG9yICAuIC4gLiAuIC4gLiAuIC4gLiAuICAx MgogICA0LiAgU3RhbmRieSBDLW11bHRpY2FzdCBSb3V0ZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMTIKICAgICA0LjEuICBEb3duc3RyZWFtIFBFIEJlaGF2aW9yICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEzCiAgICAgNC4yLiAgVXBzdHJlYW0gUEUg QmVoYXZpb3IgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNAogICAgIDQu My4gIFJlYWNoYWJpbGl0eSBEZXRlcm1pbmF0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMTUKICAgICA0LjQuICBJbnRlci1BUyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE1CiAgICAgICA0LjQuMS4gIEludGVyLUFTIFByb2NlZHVy ZXMgZm9yIGRvd25zdHJlYW0gUEVzLCBBU0JSIEZhc3QKICAgICAgICAgICAgICAgRmFpbG92ZXIg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE2CiAgICAgICA0 LjQuMi4gIEludGVyLUFTIFByb2NlZHVyZXMgZm9yIEFTQlJzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAxNgogICA1LiAgSG90IFJvb3QgU3RhbmRieSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgMTYKICAgNi4gIER1cGxpY2F0ZSBQYWNrZXRzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE3CiAgIDcuICBJQU5BIENvbnNp ZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxOAog ICAgIDcuMS4gIFN0YW5kYnkgUEUgQ29tbXVuaXR5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgMTgKICAgICA3LjIuICBCRkQgRGlzY3JpbWluYXRvciAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE4CiAgICAgNy4zLiAgQkZEIERpc2NyaW1pbmF0 b3IgT3B0aW9uYWwgU3ViLVRMViBUeXBlIC4gLiAuIC4gLiAuIC4gLiAuICAxOQogICA4LiAgU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMTkKICAgOS4gIEFja25vd2xlZGdtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDIwCiAgIDEwLiBDb250cmlidXRvciBBZGRyZXNzZXMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMAogICAxMS4gUmVmZXJlbmNlcyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjIKICAg ICAxMS4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDIyCiAgICAgMTEuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMwogICBBdXRob3JzJyBBZGRyZXNzZXMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjMKCgoKCgoKTW9yaW4s IGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1heSAxNCwgMjAyMSAgICAgICAgICAgICAgICAg IFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBNVlBOIEZhc3QgVXBzdHJlYW0gRmFp bG92ZXIgICAgICAgICBOb3ZlbWJlciAyMDIwCgoKMS4gIEludHJvZHVjdGlvbgoKICAgSXQgaXMg YXNzdW1lZCB0aGF0IHRoZSByZWFkZXIgaXMgZmFtaWxpYXIgd2l0aCB0aGUgd29ya2luZ3Mgb2YK ICAgbXVsdGljYXN0IE1QTFMvQkdQIElQIFZQTnMgYXMgZGVzY3JpYmVkIGluIFtSRkM2NTEzXSBh bmQgW1JGQzY1MTRdLgoKICAgSW4gdGhlIGNvbnRleHQgb2YgbXVsdGljYXN0IGluIEJHUC9NUExT IFZQTnMgW1JGQzY1MTNdLCBpdCBpcwogICBkZXNpcmFibGUgdG8gcHJvdmlkZSBtZWNoYW5pc21z IGFsbG93aW5nIGZhc3QgcmVjb3Zlcnkgb2YKICAgY29ubmVjdGl2aXR5IG9uIGRpZmZlcmVudCB0 eXBlcyBvZiBmYWlsdXJlcy4gIFRoaXMgZG9jdW1lbnQgYWRkcmVzc2VzCiAgIGZhaWx1cmVzIG9m IGVsZW1lbnRzIGluIHRoZSBwcm92aWRlciBuZXR3b3JrIHRoYXQgYXJlIHVwc3RyZWFtIG9mIFBF cwogICBjb25uZWN0ZWQgdG8gVlBOIHNpdGVzIHdpdGggcmVjZWl2ZXJzLgoKICAgU2VjdGlvbiAz IGRlc2NyaWJlcyBsb2NhbCBwcm9jZWR1cmVzIGFsbG93aW5nIGFuIGVncmVzcyBQRSAoYSBQRQog ICBjb25uZWN0ZWQgdG8gYSByZWNlaXZlciBzaXRlKSB0byB0YWtlIGludG8gYWNjb3VudCB0aGUg c3RhdHVzIG9mCiAgIFAtdHVubmVscyB0byBkZXRlcm1pbmUgdGhlIFVwc3RyZWFtIE11bHRpY2Fz dCBIb3AgKFVNSCkgZm9yIGEgZ2l2ZW4KICAgKEMtUywgQy1HKS4gIE9uZSBvZiB0aGUgb3B0aW9u YWwgbWV0aG9kcyB1c2VzIFtSRkM4NTYyXSBhbmQgdGhlIG5ldwogICBCR1AgQXR0cmlidXRlIC0g QkZEIERpc2NyaW1pbmF0b3IuICBOb25lIG9mIHRoZXNlIG1ldGhvZHMgcHJvdmlkZSBhCiAgICJm YXN0IGZhaWxvdmVyIiBzb2x1dGlvbiB3aGVuIHVzZWQgYWxvbmUsIGJ1dCBjYW4gYmUgdXNlZCB0 b2dldGhlcgogICB3aXRoIHRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluIFNlY3Rpb24gNCBmb3Ig YSAiZmFzdCBmYWlsb3ZlciIKICAgc29sdXRpb24uCgogICBTZWN0aW9uIDQgZGVzY3JpYmVzIGFu IG9wdGlvbmFsIEJHUCBleHRlbnNpb24sIGEgbmV3IFN0YW5kYnkgUEUKICAgQ29tbXVuaXR5LiB0 aGF0IGNhbiBzcGVlZCB1cCBmYWlsb3ZlciBieSBub3QgcmVxdWlyaW5nIGFueSBtdWx0aWNhc3QK ICAgVlBOIChNVlBOKSByb3V0aW5nIG1lc3NhZ2UgZXhjaGFuZ2UgYXQgcmVjb3ZlcnkgdGltZS4K CiAgIFNlY3Rpb24gNSBkZXNjcmliZXMgYSAiaG90IGxlYWYgc3RhbmRieSIgbWVjaGFuaXNtIHRo YXQgY2FuIGJlIHVzZWQKICAgdG8gaW1wcm92ZSBmYWlsb3ZlciB0aW1lIGluIE1WUE4uICBUaGUg YXBwcm9hY2ggY29tYmluZXMgbWVjaGFuaXNtcwogICBkZWZpbmVkIGluIFNlY3Rpb24gMyBhbmQg U2VjdGlvbiA0IGhhcyBzaW1pbGFyaXRpZXMgd2l0aCB0aGUgc29sdXRpb24KICAgZGVzY3JpYmVk IGluIFtSRkM3NDMxXSB0byBpbXByb3ZlIGZhaWxvdmVyIHRpbWVzIHdoZW4gUElNIHJvdXRpbmcg aXMKICAgdXNlZCBpbiBhIG5ldHdvcmsgZ2l2ZW4gc29tZSB0b3BvbG9neSBhbmQgbWV0cmljIGNv bnN0cmFpbnRzLgoKICAgVGhlIHByb2NlZHVyZXMgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQg YXJlIG9wdGlvbmFsIHRvIGVuYWJsZSBhbgogICBvcGVyYXRvciB0byBwcm92aWRlIHByb3RlY3Rp b24gZm9yIG11bHRpY2FzdCBzZXJ2aWNlcyBpbiBCR1AvTVBMUyBJUAogICBWUE5zLiAgQW4gb3Bl cmF0b3Igd291bGQgZW5hYmxlIHRoZXNlIG1lY2hhbmlzbXMgdXNpbmcgYSBtZXRob2QKICAgZGlz Y3Vzc2VkIGluIFNlY3Rpb24gMyBpbiBjb21iaW5hdGlvbiB3aXRoIHRoZSByZWR1bmRhbmN5IHBy b3ZpZGVkIGJ5CiAgIGEgc3RhbmRieSBQRSBjb25uZWN0ZWQgdG8gdGhlIHNvdXJjZSBvZiB0aGUg bXVsdGljYXN0IGZsb3csIGFuZCBpdCBpcwogICBhc3N1bWVkIHRoYXQgYWxsIFBFcyBpbiB0aGUg bmV0d29yayB3b3VsZCBzdXBwb3J0IHRoZXNlIG1lY2hhbmlzbXMKICAgZm9yIHRoZSBwcm9jZWR1 cmVzIHRvIHdvcmsuICBJbiB0aGUgY2FzZSB0aGF0IGEgQkdQIGltcGxlbWVudGF0aW9uCiAgIGRv ZXMgbm90IHJlY29nbml6ZSBvciBpcyBjb25maWd1cmVkIHRvIG5vdCBzdXBwb3J0IHRoZSBleHRl bnNpb25zCiAgIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCwgaXQgd2lsbCBjb250aW51ZSB0byBw cm92aWRlIHRoZSBtdWx0aWNhc3QKICAgc2VydmljZSwgYXMgZGVzY3JpYmVkIGluIFtSRkM2NTEz XS4KCjIuICBDb252ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9jdW1lbnQKCjIuMS4gIFJlcXVpcmVt ZW50cyBMYW5ndWFnZQoKICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFV SVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAi UkVDT01NRU5ERUQiLCAiTk9UIFJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZAogICAiT1BUSU9OQUwi IGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBC Q1AKCgoKTW9yaW4sIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1heSAxNCwgMjAyMSAgICAg ICAgICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBNVlBOIEZhc3Qg VXBzdHJlYW0gRmFpbG92ZXIgICAgICAgICBOb3ZlbWJlciAyMDIwCgoKICAgMTQgW1JGQzIxMTld IFtSRkM4MTc0XSB3aGVuLCBhbmQgb25seSB3aGVuLCB0aGV5IGFwcGVhciBpbiBhbGwKICAgY2Fw aXRhbHMsIGFzIHNob3duIGhlcmUuCgoyLjIuICBUZXJtaW5vbG9neQoKICAgVGhlIHRlcm1pbm9s b2d5IHVzZWQgaW4gdGhpcyBkb2N1bWVudCBpcyB0aGUgdGVybWlub2xvZ3kgZGVmaW5lZCBpbgog ICBbUkZDNjUxM10gYW5kIFtSRkM2NTE0XS4KCiAgIFRoZSB0ZXJtICd1cHN0cmVhbScgKGxvd2Vy IGNhc2UpIHRocm91Z2hvdXQgdGhpcyBkb2N1bWVudCByZWZlcnMgdG8KICAgbGlua3MgYW5kIG5v ZGVzIHRoYXQgYXJlIHVwc3RyZWFtIHRvIGEgUEUgY29ubmVjdGVkIHRvIFZQTiBzaXRlcyB3aXRo CiAgIHJlY2VpdmVycyBvZiBhIG11bHRpY2FzdCBmbG93LgoKICAgVGhlIHRlcm0gJ1Vwc3RyZWFt JyAoY2FwaXRhbGl6ZWQpIHRocm91Z2hvdXQgdGhpcyBkb2N1bWVudCByZWZlcnMgdG8KICAgYSBQ RSBvciBhbiBBdXRvbm9tb3VzIFN5c3RlbSBCb3JkZXIgUm91dGVyIChBU0JSKSBhdCB3aGljaCAo UyxHKSBvcgogICAoKixHKSBkYXRhIHBhY2tldHMgZW50ZXIgdGhlIFZQTiBiYWNrYm9uZSBvciB0 aGUgbG9jYWwgQVMgd2hlbgogICB0cmF2ZWxpbmcgdGhyb3VnaCB0aGUgVlBOIGJhY2tib25lLgoK Mi4zLiAgQWNyb255bXMKCiAgIFBNU0k6IFAtTXVsdGljYXN0IFNlcnZpY2UgSW50ZXJmYWNlCgog ICBJLVBNU0k6IEluY2x1c2l2ZSBQTVNJCgogICBTLVBNU0k6IFNlbGVjdGl2ZSBQTVNJCgogICB4 LVBNU0k6IEVpdGhlciBhbiBJLVBNU0kgb3IgYW4gUy1QTVNJCgogICBQLXR1bm5lbDogUHJvdmlk ZXItVHVubmVscwoKICAgVU1IOiBVcHN0cmVhbSBNdWx0aWNhc3QgSG9wCgogICBWUE46IFZpcnR1 YWwgUHJpdmF0ZSBOZXR3b3JrCgogICBNVlBOOiBNdWx0aWNhc3QgVlBOCgogICBSRDogUm91dGUg RGlzdGluZ3Vpc2hlcgoKICAgUlA6IFJlbmRlenZvdXMgUG9pbnQKCiAgIE5MUkk6IE5ldHdvcmsg TGF5ZXIgUmVhY2hhYmlsaXR5IEluZm9ybWF0aW9uCgogICBWUkY6IFZQTiBSb3V0aW5nIGFuZCBG b3J3YXJkaW5nIFRhYmxlCgogICBNRUQ6IE11bHRpLUV4aXQgRGlzY3JpbWluYXRvcgoKICAgUDJN UDogUG9pbnQtdG8tTXVsdGlwb2ludAoKCgoKCk1vcmluLCBldCBhbC4gICAgICAgICAgICAgRXhw aXJlcyBNYXkgMTQsIDIwMjEgICAgICAgICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURy YWZ0ICAgICAgICAgTVZQTiBGYXN0IFVwc3RyZWFtIEZhaWxvdmVyICAgICAgICAgTm92ZW1iZXIg MjAyMAoKCjMuICBVTUggU2VsZWN0aW9uIEJhc2VkIG9uIFR1bm5lbCBTdGF0dXMKCiAgIFNlY3Rp b24gNS4xIG9mIFtSRkM2NTEzXSBkZXNjcmliZXMgcHJvY2VkdXJlcyB1c2VkIGJ5IGEgbXVsdGlj YXN0IFZQTgogICBkb3duc3RyZWFtIFBFIHRvIGRldGVybWluZSB0aGUgVXBzdHJlYW0gTXVsdGlj YXN0IEhvcCAoVU1IKSBmb3IgYQogICBnaXZlbiAoQy1TLCBDLUcpLgoKICAgRm9yIGEgZ2l2ZW4g ZG93bnN0cmVhbSBQRSBhbmQgYSBnaXZlbiBWUkYsIHRoZSBQLXR1bm5lbCBjb3JyZXNwb25kaW5n CiAgIHRvIGEgZ2l2ZW4gVXBzdHJlYW0gUEUgZm9yIGEgZ2l2ZW4gKEMtUywgQy1HKSBzdGF0ZSBp cyB0aGUgUy1QTVNJCiAgIHR1bm5lbCBhZHZlcnRpc2VkIGJ5IHRoYXQgVXBzdHJlYW0gUEUgZm9y IHRoaXMgKEMtUywgQy1HKSBhbmQKICAgaW1wb3J0ZWQgaW50byB0aGF0IFZSRiwgb3IgaWYgdGhl cmUgaXNuJ3QgYW55IHN1Y2ggUy1QTVNJLCB0aGUgSS1QTVNJCiAgIHR1bm5lbCBhZHZlcnRpc2Vk IGJ5IHRoYXQgUEUgYW5kIGltcG9ydGVkIGludG8gdGhhdCBWUkYuCgogICBUaGUgcHJvY2VkdXJl IGRlc2NyaWJlZCBoZXJlIGlzIGFuIE9QVElPTkFMIHByb2NlZHVyZSB0aGF0IGlzIGJhc2VkCiAg IG9uIGEgZG93bnN0cmVhbSBQRSB0YWtpbmcgaW50byBhY2NvdW50IHRoZSBzdGF0dXMgb2YgUC10 dW5uZWxzIHJvb3RlZAogICBhdCBlYWNoIHBvc3NpYmxlIFVwc3RyZWFtIFBFLCBmb3IgaW5jbHVk aW5nIG9yIG5vdCBpbmNsdWRpbmcgZWFjaAogICBnaXZlbiBQRSBpbiB0aGUgbGlzdCBvZiBjYW5k aWRhdGUgVU1IcyBmb3IgYSBnaXZlbiAoQy1TLCBDLUcpIHN0YXRlLgogICBJZiBpdCBpcyBub3Qg cG9zc2libGUgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgYSBQLXR1bm5lbCdzIGN1cnJlbnQKICAgc3Rh dHVzIGlzIFVwLCB0aGUgc3RhdGUgc2hhbGwgYmUgY29uc2lkZXJlZCAibm90IGtub3duIHRvIGJl IERvd24iLAogICBhbmQgaXQgbWF5IGJlIHRyZWF0ZWQgYXMgaWYgaXQgaXMgVXAgc28gdGhhdCBh dHRlbXB0cyB0byB1c2UgdGhlCiAgIHR1bm5lbCBhcmUgYWNjZXB0YWJsZS4gIFRoZSByZXN1bHQg aXMgdGhhdCwgaWYgYSBQLXR1bm5lbCBpcyBEb3duCiAgIChzZWUgU2VjdGlvbiAzLjEpLCB0aGUg UEUgdGhhdCBpcyB0aGUgcm9vdCBvZiB0aGUgUC10dW5uZWwgd2lsbCBub3QKICAgYmUgY29uc2lk ZXJlZCBmb3IgVU1IIHNlbGVjdGlvbi4gIFRoaXMgd2lsbCByZXN1bHQgaW4gdGhlIGRvd25zdHJl YW0KICAgUEUgZmFpbGluZyBvdmVyIHRvIHVzZSB0aGUgbmV4dCBVcHN0cmVhbSBQRSBpbiB0aGUg bGlzdCBvZgogICBjYW5kaWRhdGVzLiAgU29tZSBkb3duc3RyZWFtIFBFcyBjb3VsZCBhcnJpdmUg YXQgYSBkaWZmZXJlbnQKICAgY29uY2x1c2lvbiByZWdhcmRpbmcgdGhlIHR1bm5lbCdzIHN0YXRl IGJlY2F1c2UgdGhlIGZhaWx1cmUgaW1wYWN0cwogICBvbmx5IGEgc3Vic2V0IG9mIGJyYW5jaGVz LiAgQmVjYXVzZSBvZiB0aGF0LCB0aGUgcHJvY2VkdXJlcyBvZgogICBTZWN0aW9uIDkuMS4xIG9m IFtSRkM2NTEzXSBhcmUgYXBwbGljYWJsZSB3aGVuIHVzaW5nIEktUE1TSQogICBQLXR1bm5lbHMu ICBUaGF0IGRvY3VtZW50IGlzIGEgZm91bmRhdGlvbiBmb3IgdGhpcyBkb2N1bWVudCwgYW5kIGl0 cwogICBwcm9jZXNzZXMgYWxsIGFwcGx5IGhlcmUuICBTZWN0aW9uIDkuMS4xIG1hbmRhdGVzIHRo ZSB1c2Ugb2Ygc3BlY2lmaWMKICAgcHJvY2VkdXJlcyBmb3Igc2VuZGluZyBpbnRyYS1BUyBJLVBN U0kgQS1EIFJvdXRlcy4KCiAgIFRoZXJlIGFyZSB0aHJlZSBvcHRpb25zIHNwZWNpZmllZCBpbiBT ZWN0aW9uIDUuMSBvZiBbUkZDNjUxM10gZm9yIGEKICAgZG93bnN0cmVhbSBQRSB0byBzZWxlY3Qg YW4gVXBzdHJlYW0gUEUuCgogICBvICBUaGUgZmlyc3QgdHdvIG9wdGlvbnMgc2VsZWN0IHRoZSBV cHN0cmVhbSBQRSBmcm9tIGEgY2FuZGlkYXRlIFBFCiAgICAgIHNldCBlaXRoZXIgYmFzZWQgb24g YW4gSVAgYWRkcmVzcyBvciBhIGhhc2hpbmcgYWxnb3JpdGhtLiAgV2hlbgogICAgICB1c2VkIHRv Z2V0aGVyIHdpdGggdGhlIG9wdGlvbmFsIHByb2NlZHVyZSBvZiBjb25zaWRlcmluZyB0aGUKICAg ICAgUC10dW5uZWwgc3RhdHVzIGFzIGluIHRoaXMgZG9jdW1lbnQsIGEgY2FuZGlkYXRlIFVwc3Ry ZWFtIFBFIGlzCiAgICAgIGluY2x1ZGVkIGluIHRoZSBzZXQgaWYgaXQgZWl0aGVyOgoKICAgICAg QS4gIGFkdmVydGlzZXMgYW4geC1QTVNJIGJvdW5kIHRvIGEgdHVubmVsLCB3aGVyZSB0aGUgc3Bl Y2lmaWVkCiAgICAgICAgICB0dW5uZWwncyBzdGF0ZSBpcyBub3Qga25vd24gdG8gYmUgRG93biwg b3IsCgogICAgICBCLiAgZG9lcyBub3QgYWR2ZXJ0aXNlIGFueSB4LVBNU0kgYXBwbGljYWJsZSB0 byB0aGUgZ2l2ZW4gKEMtUywKICAgICAgICAgIEMtRykgYnV0IGhhcyBhc3NvY2lhdGVkIGEgVlJG IFJvdXRlIEltcG9ydCBCR1AgYXR0cmlidXRlIHRvCiAgICAgICAgICB0aGUgdW5pY2FzdCBWUE4g cm91dGUgZm9yIFMuICBUaGF0IGlzIG5lY2Vzc2FyeSB0byBhdm9pZAogICAgICAgICAgaW5jb3Jy ZWN0bHkgaW52YWxpZGF0aW5nIGEgVU1IIFBFIHRoYXQgd291bGQgdXNlIGEgcG9saWN5CiAgICAg ICAgICB3aGVyZSBubyBJLVBNU0kgaXMgYWR2ZXJ0aXNlZCBmb3IgYSBnaXZlbiBWUkYgYW5kIHdo ZXJlIG9ubHkKCgoKTW9yaW4sIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1heSAxNCwgMjAy MSAgICAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBNVlBO IEZhc3QgVXBzdHJlYW0gRmFpbG92ZXIgICAgICAgICBOb3ZlbWJlciAyMDIwCgoKICAgICAgICAg IFMtUE1TSSBhcmUgdXNlZC4gIFRoZSBTLVBNU0kgY2FuIGJlIGFkdmVydGlzZWQgb25seSBhZnRl ciB0aGUKICAgICAgICAgIFVwc3RyZWFtIFBFIHJlY2VpdmVzIGEgQy1tdWx0aWNhc3Qgcm91dGUg Zm9yIChDLVMsIEMtRykvKEMtKiwKICAgICAgICAgIEMtRykgdG8gYmUgY2FycmllZCBvdmVyIHRo ZSBhZHZlcnRpc2VkIFMtUE1TSS4KCiAgICAgIElmIHRoZSByZXN1bHRpbmcgY2FuZGlkYXRlIHNl dCBpcyBlbXB0eSwgdGhlbiB0aGUgcHJvY2VkdXJlIGlzCiAgICAgIHJlcGVhdGVkIHdpdGhvdXQg Y29uc2lkZXJpbmcgdGhlIFAtdHVubmVsIHN0YXR1cy4KCiAgIG8gIFRoZSB0aGlyZCBvcHRpb24g dXNlcyB0aGUgaW5zdGFsbGVkIFVNSCBSb3V0ZSAoaS5lLiwgdGhlICJiZXN0IgogICAgICByb3V0 ZSB0b3dhcmRzIHRoZSBDLXJvb3QpIGFzIHRoZSBTZWxlY3RlZCBVTUggUm91dGUsIGFuZCBpdHMK ICAgICAgb3JpZ2luYXRpbmcgUEUgaXMgdGhlIHNlbGVjdGVkIFVwc3RyZWFtIFBFLiAgV2l0aCB0 aGUgb3B0aW9uYWwKICAgICAgcHJvY2VkdXJlIG9mIGNvbnNpZGVyaW5nIFAtdHVubmVsIHN0YXR1 cyBhcyBpbiB0aGlzIGRvY3VtZW50LCB0aGUKICAgICAgU2VsZWN0ZWQgVU1IIFJvdXRlIGlzIHRo ZSBiZXN0IG9uZSBhbW9uZyB0aG9zZSB3aG9zZSBvcmlnaW5hdGluZwogICAgICBQRSdzIFAtdHVu bmVsIGlzIG5vdCAiZG93biIuICBJZiB0aGF0IGRvZXMgbm90IGV4aXN0LCB0aGUKICAgICAgaW5z dGFsbGVkIFVNSCBSb3V0ZSBpcyBzZWxlY3RlZCByZWdhcmRsZXNzIG9mIHRoZSBQLXR1bm5lbCBz dGF0dXMuCgozLjEuICBEZXRlcm1pbmluZyB0aGUgU3RhdHVzIG9mIGEgVHVubmVsCgogICBEaWZm ZXJlbnQgZmFjdG9ycyBjYW4gYmUgY29uc2lkZXJlZCB0byBkZXRlcm1pbmUgdGhlICJzdGF0dXMi IG9mIGEKICAgUC10dW5uZWwgYW5kIGFyZSBkZXNjcmliZWQgaW4gdGhlIGZvbGxvd2luZyBzdWIt c2VjdGlvbnMuICBUaGUKICAgb3B0aW9uYWwgcHJvY2VkdXJlcyBkZXNjcmliZWQgaW4gdGhpcyBz ZWN0aW9uIGFsc28gaGFuZGxlIHRoZSBjYXNlCiAgIHRoZSBkb3duc3RyZWFtIFBFcyBkbyBub3Qg YWxsIGFwcGx5IHRoZSBzYW1lIHJ1bGVzIHRvIGRlZmluZSB3aGF0IHRoZQogICBzdGF0dXMgb2Yg YSBQLXR1bm5lbCBpcyAocGxlYXNlIHNlZSBTZWN0aW9uIDYpLCBhbmQgc29tZSBvZiB0aGVtIHdp bGwKICAgcHJvZHVjZSBhIHJlc3VsdCB0aGF0IG1heSBiZSBkaWZmZXJlbnQgZm9yIGRpZmZlcmVu dCBkb3duc3RyZWFtIFBFcy4KICAgVGh1cywgdGhlICJzdGF0dXMiIG9mIGEgUC10dW5uZWwgaW4g dGhpcyBzZWN0aW9uIGlzIG5vdCBhCiAgIGNoYXJhY3RlcmlzdGljIG9mIHRoZSB0dW5uZWwgaW4g aXRzZWxmLCBidXQgaXMgdGhlIHR1bm5lbCBzdGF0dXMsIGFzCiAgIHNlZW4gZnJvbSBhIHBhcnRp Y3VsYXIgZG93bnN0cmVhbSBQRS4gIEFkZGl0aW9uYWxseSwgc29tZSBvZiB0aGUKICAgZm9sbG93 aW5nIG1ldGhvZHMgZGV0ZXJtaW5lIHRoZSBhYmlsaXR5IG9mIGEgZG93bnN0cmVhbSBQRSB0byBy ZWNlaXZlCiAgIHRyYWZmaWMgb24gdGhlIFAtdHVubmVsIGFuZCBub3Qgc3BlY2lmaWNhbGx5IG9u IHRoZSBzdGF0dXMgb2YgdGhlCiAgIFAtdHVubmVsIGl0c2VsZi4gIFRoYXQgY291bGQgYmUgcmVm ZXJyZWQgdG8gYXMgIlAtdHVubmVsIHJlY2VwdGlvbgogICBzdGF0dXMiLCBidXQgZm9yIHNpbXBs aWNpdHksIHdlIHdpbGwgdXNlIHRoZSB0ZXJtaW5vbG9neSBvZiBQLXR1bm5lbAogICAic3RhdHVz IiBmb3IgYWxsIG9mIHRoZXNlIG1ldGhvZHMuCgogICBEZXBlbmRpbmcgb24gdGhlIGNyaXRlcmlh IHVzZWQgdG8gZGV0ZXJtaW5lIHRoZSBzdGF0dXMgb2YgYSBQLXR1bm5lbCwKICAgdGhlcmUgbWF5 IGJlIGFuIGludGVyYWN0aW9uIHdpdGggYW5vdGhlciByZXNpbGllbmN5IG1lY2hhbmlzbSB1c2Vk CiAgIGZvciB0aGUgUC10dW5uZWwgaXRzZWxmLCBhbmQgdGhlIFVNSCB1cGRhdGUgbWF5IGhhcHBl biBpbW1lZGlhdGVseSBvcgogICBtYXkgbmVlZCB0byBiZSBkZWxheWVkLiAgRWFjaCBwYXJ0aWN1 bGFyIGNhc2UgaXMgY292ZXJlZCBpbiBlYWNoCiAgIHNlcGFyYXRlIHN1Yi1zZWN0aW9uIGJlbG93 LgoKICAgQW4gaW1wbGVtZW50YXRpb24gbWF5IHN1cHBvcnQgYW55IGNvbWJpbmF0aW9uIG9mIHRo ZSBtZXRob2RzCiAgIGRlc2NyaWJlZCBpbiB0aGlzIHNlY3Rpb24gYW5kIHByb3ZpZGUgYSBuZXR3 b3JrIG9wZXJhdG9yIHdpdGggY29udHJvbAogICB0byBjaG9vc2Ugd2hpY2ggb25lIHRvIHVzZSBp biB0aGUgcGFydGljdWxhciBkZXBsb3ltZW50LgoKMy4xLjEuICBNVlBOIFR1bm5lbCBSb290IFRy YWNraW5nCgogICBBIGNvbmRpdGlvbiB0byBjb25zaWRlciB0aGF0IHRoZSBzdGF0dXMgb2YgYSBQ LXR1bm5lbCBpcyBVcCBpcyB0aGF0CiAgIHRoZSByb290IG9mIHRoZSB0dW5uZWwsIGFzIGRldGVy bWluZWQgaW4gdGhlIHgtUE1TSSBUdW5uZWwgYXR0cmlidXRlLAogICBpcyByZWFjaGFibGUgdGhy b3VnaCB1bmljYXN0IHJvdXRpbmcgdGFibGVzLiAgSW4gdGhpcyBjYXNlLCB0aGUKCgoKCk1vcmlu LCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBNYXkgMTQsIDIwMjEgICAgICAgICAgICAgICAg ICBbUGFnZSA2XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgTVZQTiBGYXN0IFVwc3RyZWFtIEZh aWxvdmVyICAgICAgICAgTm92ZW1iZXIgMjAyMAoKCiAgIGRvd25zdHJlYW0gUEUgY2FuIGltbWVk aWF0ZWx5IHVwZGF0ZSBpdHMgVU1IIHdoZW4gdGhlIHJlYWNoYWJpbGl0eQogICBjb25kaXRpb24g Y2hhbmdlcy4KCiAgIFRoYXQgaXMgc2ltaWxhciB0byBCR1AgbmV4dC1ob3AgdHJhY2tpbmcgZm9y IFZQTiByb3V0ZXMsIGV4Y2VwdCB0aGF0CiAgIHRoZSBhZGRyZXNzIGNvbnNpZGVyZWQgaXMgbm90 IHRoZSBCR1AgbmV4dC1ob3AgYWRkcmVzcywgYnV0IHRoZSByb290CiAgIGFkZHJlc3MgaW4gdGhl IHgtUE1TSSBUdW5uZWwgYXR0cmlidXRlLgoKICAgSWYgQkdQIG5leHQtaG9wIHRyYWNraW5nIGlz IGRvbmUgZm9yIFZQTiByb3V0ZXMgYW5kIHRoZSByb290IGFkZHJlc3MKICAgb2YgYSBnaXZlbiB0 dW5uZWwgaGFwcGVucyB0byBiZSB0aGUgc2FtZSBhcyB0aGUgbmV4dC1ob3AgYWRkcmVzcyBpbgog ICB0aGUgQkdQIEEtRCBSb3V0ZSBhZHZlcnRpc2luZyB0aGUgdHVubmVsLCB0aGVuIGNoZWNraW5n LCBpbiB1bmljYXN0CiAgIHJvdXRpbmcgdGFibGVzLCB3aGV0aGVyIHRoZSB0dW5uZWwgcm9vdCBp cyByZWFjaGFibGUsIHdpbGwgYmUKICAgdW5uZWNlc3NhcnkgZHVwbGljYXRpb24gYW5kIHRodXMg d2lsbCBub3QgYnJpbmcgYW55IHNwZWNpZmljIGJlbmVmaXQuCgozLjEuMi4gIFBFLVAgVXBzdHJl YW0gTGluayBTdGF0dXMKCiAgIEEgY29uZGl0aW9uIHRvIGNvbnNpZGVyIGEgdHVubmVsIHN0YXR1 cyBhcyBVcCBjYW4gYmUgdGhhdCB0aGUgbGFzdC0KICAgaG9wIGxpbmsgb2YgdGhlIFAtdHVubmVs IGlzIFVwLiAgQ29udmVyc2VseSwgaWYgdGhlIGxhc3QtaG9wIGxpbmsgb2YKICAgdGhlIFAtdHVu bmVsIGlzIERvd24gdGhlbiB0aGlzIGNhbiBiZSB0YWtlbiBhcyBhbiBpbmRpY2F0aW9uIHRoYXQg dGhlCiAgIFAtdHVubmVsIGlzIERvd24uCgogICBVc2luZyB0aGlzIG1ldGhvZCB3aGVuIGEgZmFz dCByZXN0b3JhdGlvbiBtZWNoYW5pc20gKHN1Y2ggYXMgTVBMUyBGUlIKICAgW1JGQzQwOTBdKSBp cyBpbiBwbGFjZSBmb3IgdGhlIGxpbmsgcmVxdWlyZXMgY2FyZWZ1bCBjb25zaWRlcmF0aW9uCiAg IGFuZCBjb29yZGluYXRpb24gb2YgZGVmZWN0IGRldGVjdGlvbiBpbnRlcnZhbHMgZm9yIHRoZSBs aW5rIGFuZCB0aGUKICAgdHVubmVsLiAgSW4gbWFueSBjYXNlcywgaXQgaXMgbm90IHByYWN0aWNh bCB0byB1c2UgYm90aCBwcm90ZWN0aW9uCiAgIG1ldGhvZHMgYXQgdGhlIHNhbWUgdGltZSBiZWNh dXNlIHVuY29ycmVsYXRlZCB0aW1lcnMgbWlnaHQgY2F1c2UKICAgdW5uZWNlc3Nhcnkgc3dpdGNo b3ZlcnMgYW5kIGRlc3RhYmlsaXplIHRoZSBuZXR3b3JrLgoKMy4xLjMuICBQMk1QIFJTVlAtVEUg VHVubmVscwoKICAgRm9yIFAtdHVubmVscyBvZiB0eXBlIFAyTVAgTVBMUy1URSwgdGhlIHN0YXR1 cyBvZiB0aGUgUC10dW5uZWwgaXMKICAgY29uc2lkZXJlZCBVcCBpZiB0aGUgc3ViLUxTUCB0byB0 aGlzIGRvd25zdHJlYW0gUEUgaXMgaW4gdGhlIFVwCiAgIHN0YXRlLiAgVGhlIGRldGVybWluYXRp b24gb2Ygd2hldGhlciBhIFAyTVAgUlNWUC1URSBMU1AgaXMgaW4gdGhlIFVwCiAgIHN0YXRlIHJl cXVpcmVzIFBhdGggYW5kIFJlc3Ygc3RhdGUgZm9yIHRoZSBMU1AgYW5kIGlzIGJhc2VkIG9uCiAg IHByb2NlZHVyZXMgc3BlY2lmaWVkIGluIFtSRkM0ODc1XS4gIEFzIGEgcmVzdWx0LCB0aGUgZG93 bnN0cmVhbSBQRQogICBjYW4gaW1tZWRpYXRlbHkgdXBkYXRlIGl0cyBVTUggd2hlbiB0aGUgcmVh Y2hhYmlsaXR5IGNvbmRpdGlvbgogICBjaGFuZ2VzLgoKICAgV2hlbiB1c2luZyB0aGlzIG1ldGhv ZCBhbmQgaWYgdGhlIHNpZ25hbGluZyBzdGF0ZSBmb3IgYSBQMk1QIFRFIExTUAogICBpcyByZW1v dmVkIChlLmcuLCBpZiB0aGUgaW5ncmVzcyBvZiB0aGUgUDJNUCBURSBMU1Agc2VuZHMgYSBQYXRo VGVhcgogICBtZXNzYWdlKSBvciB0aGUgUDJNUCBURSBMU1AgY2hhbmdlcyBzdGF0ZSBmcm9tIFVw IHRvIERvd24gYXMKICAgZGV0ZXJtaW5lZCBieSBwcm9jZWR1cmVzIGluIFtSRkM0ODc1XSwgdGhl IHN0YXR1cyBvZiB0aGUKICAgY29ycmVzcG9uZGluZyBQLXR1bm5lbCBNVVNUIGJlIHJlLWV2YWx1 YXRlZC4gIElmIHRoZSBQLXR1bm5lbAogICB0cmFuc2l0aW9ucyBmcm9tIFVwIHRvIERvd24gc3Rh dGUsIHRoZSBVcHN0cmVhbSBQRSB0aGF0IGlzIHRoZQogICBpbmdyZXNzIG9mIHRoZSBQLXR1bm5l bCBNVVNUIE5PVCBiZSBjb25zaWRlcmVkIGEgdmFsaWQgVU1ILgoKCgoKCgoKTW9yaW4sIGV0IGFs LiAgICAgICAgICAgICBFeHBpcmVzIE1heSAxNCwgMjAyMSAgICAgICAgICAgICAgICAgIFtQYWdl IDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBNVlBOIEZhc3QgVXBzdHJlYW0gRmFpbG92ZXIg ICAgICAgICBOb3ZlbWJlciAyMDIwCgoKMy4xLjQuICBMZWFmLWluaXRpYXRlZCBQLXR1bm5lbHMK CiAgIEFuIFVwc3RyZWFtIFBFIFNIT1VMRCBiZSByZW1vdmVkIGZyb20gdGhlIFVNSCBjYW5kaWRh dGUgbGlzdCBmb3IgYQogICBnaXZlbiAoQy1TLCBDLUcpIGlmIHRoZSBQLXR1bm5lbCAoSS1QTVNJ IG9yIFMtUE1TSSkgZm9yIHRoaXMgKFMsIEcpCiAgIGlzIGxlYWYtdHJpZ2dlcmVkIChQSU0sIG1M RFApLCBidXQgZm9yIHNvbWUgcmVhc29uLCBpbnRlcm5hbCB0byB0aGUKICAgcHJvdG9jb2wsIHRo ZSB1cHN0cmVhbSBvbmUtaG9wIGJyYW5jaCBvZiB0aGUgdHVubmVsIGZyb20gUCB0byBQRQogICBj YW5ub3QgYmUgYnVpbHQuICBBcyBhIHJlc3VsdCwgdGhlIGRvd25zdHJlYW0gUEUgY2FuIGltbWVk aWF0ZWx5CiAgIHVwZGF0ZSBpdHMgVU1IIHdoZW4gdGhlIHJlYWNoYWJpbGl0eSBjb25kaXRpb24g Y2hhbmdlcy4KCjMuMS41LiAgKEMtUywgQy1HKSBDb3VudGVyIEluZm9ybWF0aW9uCgogICBJbiBj YXNlcywgd2hlcmUgdGhlIGRvd25zdHJlYW0gbm9kZSBjYW4gYmUgY29uZmlndXJlZCBzbyB0aGF0 IHRoZQogICBtYXhpbXVtIGludGVyLXBhY2tldCB0aW1lIGlzIGtub3duIGZvciBhbGwgdGhlIG11 bHRpY2FzdCBmbG93cyBtYXBwZWQKICAgb24gYSBQLXR1bm5lbCwgdGhlIGxvY2FsIHBlci0oQy1T LCBDLUcpIHRyYWZmaWMgY291bnRlciBpbmZvcm1hdGlvbgogICBmb3IgdHJhZmZpYyByZWNlaXZl ZCBvbiB0aGlzIFAtdHVubmVsIGNhbiBiZSB1c2VkIHRvIGRldGVybWluZSB0aGUKICAgc3RhdHVz IG9mIHRoZSBQLXR1bm5lbC4KCiAgIFdoZW4gc3VjaCBhIHByb2NlZHVyZSBpcyB1c2VkLCBpbiB0 aGUgY29udGV4dCB3aGVyZSBmYXN0IHJlc3RvcmF0aW9uCiAgIG1lY2hhbmlzbXMgYXJlIHVzZWQg Zm9yIHRoZSBQLXR1bm5lbHMsIGEgY29uZmlndXJhYmxlIHRpbWVyIE1VU1QgYmUKICAgc2V0IG9u IHRoZSBkb3duc3RyZWFtIFBFIHRvIHdhaXQgYmVmb3JlIHVwZGF0aW5nIHRoZSBVTUgsIHRvIGxl dCB0aGUKICAgUC10dW5uZWwgcmVzdG9yYXRpb24gbWVjaGFuaXNtIHRvIGV4ZWN1dGUgaXRzIGFj dGlvbnMuICBBbgogICBpbXBsZW1lbnRhdGlvbiBTSE9VTEQgdXNlIHRocmVlIHNlY29uZHMgYXMg dGhlIGRlZmF1bHQgdmFsdWUgZm9yIHRoaXMKICAgdGltZXIuCgogICBJbiBjYXNlcyB3aGVyZSB0 aGlzIG1lY2hhbmlzbSBpcyB1c2VkIGluIGNvbmp1bmN0aW9uIHdpdGggdGhlIG1ldGhvZAogICBk ZXNjcmliZWQgaW4gU2VjdGlvbiA1LCBubyBwcmlvciBrbm93bGVkZ2Ugb2YgdGhlIHJhdGUgb2Yg dGhlCiAgIG11bHRpY2FzdCBzdHJlYW1zIGlzIHJlcXVpcmVkOyBkb3duc3RyZWFtIFBFcyBjYW4g Y29tcGFyZSByZWNlcHRpb24KICAgb24gdGhlIHR3byBQLXR1bm5lbHMgdG8gZGV0ZXJtaW5lIHdo ZW4gb25lIG9mIHRoZW0gaXMgZG93bi4KCjMuMS42LiAgQkZEIERpc2NyaW1pbmF0b3IgQXR0cmli dXRlCgogICBQLXR1bm5lbCBzdGF0dXMgbWF5IGJlIGRlcml2ZWQgZnJvbSB0aGUgc3RhdHVzIG9m IGEgbXVsdGlwb2ludCBCRkQKICAgc2Vzc2lvbiBbUkZDODU2Ml0gd2hvc2UgZGlzY3JpbWluYXRv ciBpcyBhZHZlcnRpc2VkIGFsb25nIHdpdGggYW4KICAgeC1QTVNJIEEtRCBSb3V0ZS4KCiAgIFRo aXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgZm9ybWF0IGFuZCB3YXlzIG9mIHVzaW5nIGEgbmV3IEJH UAogICBhdHRyaWJ1dGUgY2FsbGVkIHRoZSAiQkZEIERpc2NyaW1pbmF0b3IiLiAgSXQgaXMgYW4g b3B0aW9uYWwKICAgdHJhbnNpdGl2ZSBCR1AgYXR0cmlidXRlLiAgQW4gaW1wbGVtZW50YXRpb24g dGhhdCBkb2VzIG5vdCByZWNvZ25pemUKICAgb3IgaXMgY29uZmlndXJlZCBub3QgdG8gc3VwcG9y dCB0aGlzIGF0dHJpYnV0ZSBNVVNUIGZvbGxvdyBwcm9jZWR1cmVzCiAgIGRlZmluZWQgZm9yIG9w dGlvbmFsIHRyYW5zaXRpdmUgcGF0aCBhdHRyaWJ1dGVzIGluIFNlY3Rpb24gNSBvZgogICBbUkZD NDI3MV0uICBJbiBTZWN0aW9uIDcuMiwgSUFOQSBpcyByZXF1ZXN0ZWQgdG8gYWxsb2NhdGUgdGhl CiAgIGNvZGVwb2ludCB2YWx1ZSAoVEJBMikuICBUaGUgZm9ybWF0IG9mIHRoaXMgYXR0cmlidXRl IGlzIHNob3duIGluCiAgIEZpZ3VyZSAxLgoKCgoKCgoKCk1vcmluLCBldCBhbC4gICAgICAgICAg ICAgRXhwaXJlcyBNYXkgMTQsIDIwMjEgICAgICAgICAgICAgICAgICBbUGFnZSA4XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgTVZQTiBGYXN0IFVwc3RyZWFtIEZhaWxvdmVyICAgICAgICAgTm92 ZW1iZXIgMjAyMAoKCiAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAg ICAgMiAgICAgICAgICAgICAgICAgICAzCiAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEKICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAg ICAgfCAgICBCRkQgTW9kZSAgIHwgICAgICAgICAgICAgICAgICBSZXNlcnZlZCAgICAgICAgICAg ICAgICAgICAgIHwKICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg QkZEIERpc2NyaW1pbmF0b3IgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsK ICAgICAgfiAgICAgICAgICAgICAgICAgICAgICAgICBPcHRpb25hbCBUTFZzICAgICAgICAgICAg ICAgICAgICAgICAgIH4KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKCgogICAgICAgICAgICBGaWd1cmUgMTogRm9y bWF0IG9mIHRoZSBCRkQgRGlzY3JpbWluYXRvciBBdHRyaWJ1dGUKCiAgIFdoZXJlOgoKICAgICAg QkZEIE1vZGUgZmllbGQgaXMgdGhlIG9uZSBvY3RldCBsb25nLiAgVGhpcyBzcGVjaWZpY2F0aW9u IGRlZmluZXMKICAgICAgdGhlIFAyTVAgQkZEIFNlc3Npb24gYXMgdmFsdWUgMSBTZWN0aW9uIDcu Mi4KCiAgICAgIFJlc2VydmVkIGZpZWxkIGlzIHRocmVlIG9jdGV0cyBsb25nLCBhbmQgdGhlIHZh bHVlIE1VU1QgYmUgemVyb2VkCiAgICAgIG9uIHRyYW5zbWlzc2lvbiBhbmQgaWdub3JlZCBvbiBy ZWNlaXB0LgoKICAgICAgQkZEIERpc2NyaW1pbmF0b3IgZmllbGQgaXMgZm91ciBvY3RldHMgbG9u Zy4KCiAgICAgIE9wdGlvbmFsIFRMVnMgaXMgdGhlIG9wdGlvbmFsIHZhcmlhYmxlLWxlbmd0aCBm aWVsZCB0aGF0IE1BWSBiZQogICAgICB1c2VkIGluIHRoZSBCRkQgRGlzY3JpbWluYXRvciBhdHRy aWJ1dGUgZm9yIGZ1dHVyZSBleHRlbnNpb25zLgogICAgICBUTFZzIE1BWSBiZSBpbmNsdWRlZCBp biBhIHNlcXVlbnRpYWwgb3IgbmVzdGVkIG1hbm5lci4gIFRvIGFsbG93CiAgICAgIGZvciBUTFYg bmVzdGluZywgaXQgaXMgYWR2aXNlZCB0byBkZWZpbmUgYSBuZXcgVExWIGFzIGEgdmFyaWFibGUt CiAgICAgIGxlbmd0aCBvYmplY3QuICBGaWd1cmUgMiBwcmVzZW50cyB0aGUgT3B0aW9uYWwgVExW IGZvcm1hdCBUTFYgdGhhdAogICAgICBjb25zaXN0cyBvZjoKCiAgICAgICogIG9uZSBvY3RldC1s b25nIGZpZWxkIG9mIFRMVidzIFR5cGUgdmFsdWUgKFNlY3Rpb24gNy4zKQoKICAgICAgKiAgb25l IG9jdGV0LWxvbmcgZmllbGQgb2YgdGhlIGxlbmd0aCBvZiB0aGUgVmFsdWUgZmllbGQgaW4gb2N0 ZXRzCgogICAgICAqICB2YXJpYWJsZSBsZW5ndGggVmFsdWUgZmllbGQuCgogICAgICBUaGUgbGVu Z3RoIG9mIGEgVExWIE1VU1QgYmUgbXVsdGlwbGUgb2YgZm91ciBvY3RldHMuCgoKCiAgICAgICAw ICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAg ICAzCiAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIg MyA0IDUgNiA3IDggOSAwIDEKICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgfCAgICAgIFR5cGUgICAgIHwg ICAgIExlbmd0aCAgICB8ICAgICAgICAgICBWYWx1ZSAgICAgICAgICAgICAuLi4KICAgICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsKCgogICAgICAgICAgICAgICAgICAgRmlndXJlIDI6IEZvcm1hdCBvZiB0aGUgT3B0aW9u YWwgVExWCgoKCk1vcmluLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBNYXkgMTQsIDIwMjEg ICAgICAgICAgICAgICAgICBbUGFnZSA5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgTVZQTiBG YXN0IFVwc3RyZWFtIEZhaWxvdmVyICAgICAgICAgTm92ZW1iZXIgMjAyMAoKCiAgIFRoZSBCRkQg RGlzY3JpbWluYXRvciBhdHRyaWJ1dGUgTVVTVCBiZSBjb25zaWRlcmVkIG1hbGZvcm1lZCBpZiBp dHMKICAgbGVuZ3RoIGlzIG5vdCBhIG5vbi16ZXJvIG11bHRpcGxlIG9mIGZvdXIuICBJZiB0aGUg YXR0cmlidXRlCiAgIGNvbnNpZGVyZWQgbWFsZm9ybWVkLCB0aGUgVVBEQVRFIG1lc3NhZ2UgU0hB TEwgYmUgaGFuZGxlZCB1c2luZyB0aGUKICAgYXBwcm9hY2ggb2YgQXR0cmlidXRlIERpc2NhcmQg cGVyIFtSRkM3NjA2XS4KCjMuMS42LjEuICBVcHN0cmVhbSBQRSBQcm9jZWR1cmVzCgogICBUbyBl bmFibGUgZG93bnN0cmVhbSBQRXMgdG8gdHJhY2sgdGhlIFAtdHVubmVsIHN0YXR1cyB1c2luZyBh IHBvaW50LQogICB0by1tdWx0aXBvaW50IChQMk1QKSBCRkQgc2Vzc2lvbiB0aGUgVXBzdHJlYW0g UEU6CgogICBvICBNVVNUIGluaXRpYXRlIHRoZSBCRkQgc2Vzc2lvbiBhbmQgc2V0IGJmZC5TZXNz aW9uVHlwZSA9CiAgICAgIE11bHRpcG9pbnRIZWFkIGFzIGRlc2NyaWJlZCBpbiBbUkZDODU2Ml07 CgogICBvICBNVVNUIHNldCB0aGUgSVAgZGVzdGluYXRpb24gYWRkcmVzcyBvZiB0aGUgaW5uZXIg SVAgaGVhZGVyIHRvIG9uZQogICAgICBvZiB0aGUgaW50ZXJuYWwgbG9vcGJhY2sgYWRkcmVzc2Vz IGZyb20gMTI3LzggcmFuZ2UgZm9yIElQdjQgb3IKICAgICAgb25lIG9mIElQdjQtbWFwcGVkIElQ djYgYWRkcmVzc2VzIGZyb20gOjpmZmZmOjEyNy4wLjAuMC8xMDQgcmFuZ2UKICAgICAgZm9yIElQ djYgd2hlbiB0cmFuc21pdHRpbmcgQkZEIENvbnRyb2wgcGFja2V0czsKCiAgIG8gIE1VU1QgdXNl IGl0cyBJUCBhZGRyZXNzIGFzIHRoZSBzb3VyY2UgSVAgYWRkcmVzcyB3aGVuIHRyYW5zbWl0dGlu ZwogICAgICBCRkQgQ29udHJvbCBwYWNrZXRzOwoKICAgbyAgTVVTVCBpbmNsdWRlIHRoZSBCRkQg RGlzY3JpbWluYXRvciBhdHRyaWJ1dGUgaW4gdGhlIHgtUE1TSSBBLUQKICAgICAgUm91dGUgd2l0 aCB0aGUgdmFsdWUgc2V0IHRvIE15IERpc2NyaW1pbmF0b3IgdmFsdWU7CgogICBvICBNVVNUIHBl cmlvZGljYWxseSB0cmFuc21pdCBCRkQgQ29udHJvbCBwYWNrZXRzIG92ZXIgdGhlIHgtUE1TSQog ICAgICBQLXR1bm5lbCBhZnRlciB0aGUgUC10dW5uZWwgaXMgY29uc2lkZXJlZCBlc3RhYmxpc2hl ZC4gIE5vdGUgdGhhdAogICAgICB0aGUgbWV0aG9kcyB0byBkZWNsYXJlIGEgUC10dW5uZWwgaGFz IGJlZW4gZXN0YWJsaXNoZWQgYXJlIG91dHNpZGUKICAgICAgdGhlIHNjb3BlIG9mIHRoaXMgc3Bl Y2lmaWNhdGlvbi4KCiAgIElmIHRoZSB0cmFja2luZyBvZiB0aGUgUC10dW5uZWwgYnkgdXNpbmcg YSBQMk1QIEJGRCBzZXNzaW9uIGlzCiAgIGVuYWJsZWQgYWZ0ZXIgdGhlIHgtUE1TSSBBLUQgUm91 dGUgaGFzIGJlZW4gYWxyZWFkeSBhZHZlcnRpc2VkLCB0aGUKICAgeC1QTVNJIEEtRCBSb3V0ZSBN VVNUIGJlIHJlLXNlbnQgd2l0aCBwcmVjaXNlbHkgdGhlIHNhbWUgYXR0cmlidXRlcwogICBhcyBi ZWZvcmUgYW5kIHRoZSBCRkQgRGlzY3JpbWluYXRvciBhdHRyaWJ1dGUgaW5jbHVkZWQuCgogICBJ ZiB0aGUgeC1QTVNJIEEtRCBSb3V0ZSBpcyBhZHZlcnRpc2VkIHdpdGggUC10dW5uZWwgc3RhdHVz IHRyYWNrZWQKICAgdXNpbmcgdGhlIFAyTVAgQkZEIHNlc3Npb24gYW5kIGl0IGlzIGRlc2lyZWQg dG8gc3RvcCB0cmFja2luZwogICBQLXR1bm5lbCBzdGF0dXMgdXNpbmcgQkZELCB0aGVuOgoKICAg byAgeC1QTVNJIEEtRCBSb3V0ZSBNVVNUIGJlIHJlLXNlbnQgd2l0aCBwcmVjaXNlbHkgdGhlIHNh bWUKICAgICAgYXR0cmlidXRlcyBhcyBiZWZvcmUsIGJ1dCB0aGUgQkZEIERpc2NyaW1pbmF0b3Ig YXR0cmlidXRlIE1VU1QgYmUKICAgICAgZXhjbHVkZWQ7CgogICBvICB0aGUgUDJNUCBCRkQgc2Vz c2lvbiBTSE9VTEQgYmUgZGVsZXRlZC4KCgoKCgoKCgpNb3JpbiwgZXQgYWwuICAgICAgICAgICAg IEV4cGlyZXMgTWF5IDE0LCAyMDIxICAgICAgICAgICAgICAgICBbUGFnZSAxMF0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgIE1WUE4gRmFzdCBVcHN0cmVhbSBGYWlsb3ZlciAgICAgICAgIE5vdmVt YmVyIDIwMjAKCgozLjEuNi4yLiAgRG93bnN0cmVhbSBQRSBQcm9jZWR1cmVzCgogICBVcG9uIHJl Y2VpdmluZyB0aGUgQkZEIERpc2NyaW1pbmF0b3IgYXR0cmlidXRlIGluIHRoZSB4LVBNU0kgQS1E CiAgIFJvdXRlLCB0aGUgZG93bnN0cmVhbSBQRToKCiAgIG8gIE1VU1QgYXNzb2NpYXRlIHRoZSBy ZWNlaXZlZCBCRkQgRGlzY3JpbWluYXRvciB2YWx1ZSB3aXRoIHRoZQogICAgICBQLXR1bm5lbCBv cmlnaW5hdGluZyBmcm9tIHRoZSBVcHN0cmVhbSBQRSBhbmQgdGhlIElQIGFkZHJlc3Mgb2YKICAg ICAgdGhlIFVwc3RyZWFtIFBFOwoKICAgbyAgTVVTVCBjcmVhdGUgYSBQMk1QIEJGRCBzZXNzaW9u IGFuZCBzZXQgYmZkLlNlc3Npb25UeXBlID0KICAgICAgTXVsdGlwb2ludFRhaWwgYXMgZGVzY3Jp YmVkIGluIFtSRkM4NTYyXTsKCiAgIG8gIE1VU1QgdXNlIHRoZSBzb3VyY2UgSVAgYWRkcmVzcyBv ZiB0aGUgQkZEIENvbnRyb2wgcGFja2V0LCB0aGUKICAgICAgdmFsdWUgb2YgdGhlIEJGRCBEaXNj cmltaW5hdG9yIGZpZWxkLCBhbmQgdGhlIHgtUE1TSSBUdW5uZWwKICAgICAgSWRlbnRpZmllciBb UkZDNjUxNF0gdGhlIEJGRCBDb250cm9sIHBhY2tldCB3YXMgcmVjZWl2ZWQgdG8KICAgICAgcHJv cGVybHkgZGVtdWx0aXBsZXggQkZEIHNlc3Npb25zLgoKICAgQWZ0ZXIgdGhlIHN0YXRlIG9mIHRo ZSBQMk1QIEJGRCBzZXNzaW9uIGlzIHVwLCBpLmUuLCBiZmQuU2Vzc2lvblN0YXRlCiAgID09IFVw LCB0aGUgc2Vzc2lvbiBzdGF0ZSB3aWxsIHRoZW4gYmUgdXNlZCB0byB0cmFjayB0aGUgaGVhbHRo IG9mIHRoZQogICBQLXR1bm5lbC4KCiAgIEFjY29yZGluZyB0byBbUkZDODU2Ml0sIGlmIHRoZSBk b3duc3RyZWFtIFBFIHJlY2VpdmVzIERvd24gb3IKICAgQWRtaW5Eb3duIGluIHRoZSBTdGF0ZSBm aWVsZCBvZiB0aGUgQkZEIENvbnRyb2wgcGFja2V0IG9yIGFzc29jaWF0ZWQKICAgd2l0aCB0aGUg QkZEIHNlc3Npb24gRGV0ZWN0aW9uIFRpbWVyIGV4cGlyZXMsIHRoZSBCRkQgc2Vzc2lvbiBpcwog ICBkb3duLCBpLmUuLCBiZmQuU2Vzc2lvblN0YXRlID09IERvd24uICBXaGVuIHRoZSBCRkQgc2Vz c2lvbiBzdGF0ZSBpcwogICBEb3duLCB0aGVuIHRoZSBQLXR1bm5lbCBhc3NvY2lhdGVkIHdpdGgg dGhlIEJGRCBzZXNzaW9uIE1VU1QgYmUKICAgY29uc2lkZXJlZCBkb3duLiAgSWYgdGhlIHNpdGUg dGhhdCBjb250YWlucyBDLVMgaXMgY29ubmVjdGVkIHRvIHR3bwogICBvciBtb3JlIFBFcywgYSBk b3duc3RyZWFtIFBFIHdpbGwgc2VsZWN0IG9uZSBhcyBpdHMgUHJpbWFyeSBVcHN0cmVhbQogICBQ RSwgd2hpbGUgb3RoZXJzIGFyZSBjb25zaWRlcmVkIGFzIFN0YW5kYnkgVXBzdHJlYW0gUEVzLiAg SW4gc3VjaCBhCiAgIHNjZW5hcmlvLCB3aGVuIHRoZSBQLXR1bm5lbCBpcyBjb25zaWRlcmVkIGRv d24sIHRoZSBkb3duc3RyZWFtIFBFIE1BWQogICBpbml0aWF0ZSBhIHN3aXRjaG92ZXIgb2YgdGhl IHRyYWZmaWMgZnJvbSB0aGUgUHJpbWFyeSBVcHN0cmVhbSBQRSB0bwogICB0aGUgU3RhbmRieSBV cHN0cmVhbSBQRSBvbmx5IGlmIHRoZSBTdGFuZGJ5IFVwc3RyZWFtIFBFIGlzIGRlZW1lZAogICBh dmFpbGFibGUuCgogICBJZiB0aGUgZG93bnN0cmVhbSBQRSdzIFAtdHVubmVsIGlzIGFscmVhZHkg ZXN0YWJsaXNoZWQgd2hlbiB0aGUKICAgZG93bnN0cmVhbSBQRSByZWNlaXZlcyB0aGUgbmV3IHgt UE1TSSBBLUQgUm91dGUgd2l0aCBCRkQKICAgRGlzY3JpbWluYXRvciBhdHRyaWJ1dGUsIHRoZSBk b3duc3RyZWFtIFBFIE1VU1QgYXNzb2NpYXRlIHRoZSB2YWx1ZQogICBvZiBCRkQgRGlzY3JpbWlu YXRvciBmaWVsZCB3aXRoIHRoZSBQLXR1bm5lbCBhbmQgZm9sbG93IHByb2NlZHVyZXMKICAgbGlz dGVkIGFib3ZlIGluIHRoaXMgc2VjdGlvbiBpZiBhbmQgb25seSBpZiB0aGUgeC1QTVNJIEEtRCBS b3V0ZSB3YXMKICAgcHJvcGVybHkgcHJvY2Vzc2VkIGFzIHBlciBbUkZDNjUxNF0sIGFuZCB0aGUg QkZEIERpc2NyaW1pbmF0b3IKICAgYXR0cmlidXRlIHdhcyB2YWxpZGF0ZWQuCgogICBJZiB0aGUg ZG93bnN0cmVhbSBQRSdzIFAtdHVubmVsIGlzIGFscmVhZHkgZXN0YWJsaXNoZWQsIGl0cyBzdGF0 ZQogICBiZWluZyBtb25pdG9yZWQgYnkgdGhlIFAyTVAgQkZEIHNlc3Npb24sIGFuZCB0aGUgZG93 bnN0cmVhbSBQRQogICByZWNlaXZlcyB0aGUgbmV3IHgtUE1TSSBBLUQgUm91dGUgd2l0aG91dCB0 aGUgQkZEIERpc2NyaW1pbmF0b3IKICAgYXR0cmlidXRlLCBhbmQgdGhlIHgtUE1TSSBBLUQgUm91 dGUgd2FzIHByb2Nlc3NlZCB3aXRob3V0IGFueSBlcnJvcgogICBhcyBwZXIgdGhlIHJlbGV2YW50 IHNwZWNpZmljYXRpb25zLCB0aGUgZG93bnN0cmVhbSBQRToKCgoKCk1vcmluLCBldCBhbC4gICAg ICAgICAgICAgRXhwaXJlcyBNYXkgMTQsIDIwMjEgICAgICAgICAgICAgICAgIFtQYWdlIDExXQoM CkludGVybmV0LURyYWZ0ICAgICAgICAgTVZQTiBGYXN0IFVwc3RyZWFtIEZhaWxvdmVyICAgICAg ICAgTm92ZW1iZXIgMjAyMAoKCiAgIG8gIE1VU1Qgc3RvcCBwcm9jZXNzaW5nIEJGRCBDb250cm9s IHBhY2tldHMgZm9yIHRoaXMgUDJNUCBCRkQKICAgICAgc2Vzc2lvbjsKCiAgIG8gIFNIT1VMRCBk ZWxldGUgdGhlIFAyTVAgQkZEIHNlc3Npb24gYXNzb2NpYXRlZCB3aXRoIHRoZSBQLXR1bm5lbDsK CiAgIG8gIFNIT1VMRCBOT1Qgc3dpdGNoIHRoZSB0cmFmZmljIHRvIHRoZSBTdGFuZGJ5IFVwc3Ry ZWFtIFBFLgoKMy4xLjcuICBQZXIgUEUtQ0UgTGluayBCRkQgRGlzY3JpbWluYXRvcgoKICAgVGhl IGZvbGxvd2luZyBhcHByb2FjaCBpcyBkZWZpbmVkIGluIHJlc3BvbnNlIHRvIHRoZSBkZXRlY3Rp b24gYnkgdGhlCiAgIFVwc3RyZWFtIFBFIG9mIGEgUEUtQ0UgbGluayBmYWlsdXJlLiAgRXZlbiB0 aG91Z2ggdGhlIHByb3ZpZGVyIHR1bm5lbAogICBpcyBzdGlsbCB1cCwgaXQgaXMgZGVzaXJlZCBm b3IgdGhlIGRvd25zdHJlYW0gUEVzIHRvIHN3aXRjaCB0byBhCiAgIGJhY2t1cCBVcHN0cmVhbSBQ RS4gIFRvIGFjaGlldmUgdGhhdCwgaWYgdGhlIFVwc3RyZWFtIFBFIGRldGVjdHMgdGhhdAogICBp dHMgUEUtQ0UgbGluayBmYWlscywgaXQgU0hPVUxEIHNldCB0aGUgYmZkLkxvY2FsRGlhZyBvZiB0 aGUgUDJNUCBCRkQKICAgc2Vzc2lvbiB0byBDb25jYXRlbmF0ZWQgUGF0aCBEb3duIGFuZC9vciBS ZXZlcnNlIENvbmNhdGVuYXRlZCBQYXRoCiAgIERvd24gKHBlciBTZWN0aW9uIDYuOC4xNyBbUkZD NTg4MF0pLCB1bmxlc3MgaXQgc3dpdGNoZXMgdG8gYSBuZXcgUEUtCiAgIENFIGxpbmsgd2l0aGlu IHRoZSB0aW1lIG9mIGJmZC5EZXNpcmVkTWluVHhJbnRlcnZhbCBmb3IgdGhlIFAyTVAgQkZECiAg IHNlc3Npb24gKGluIHRoYXQgY2FzZSwgdGhlIFVwc3RyZWFtIFBFIHdpbGwgc3RhcnQgdHJhY2tp bmcgdGhlIHN0YXR1cwogICBvZiB0aGUgbmV3IFBFLUNFIGxpbmspLiAgV2hlbiBhIGRvd25zdHJl YW0gUEUgcmVjZWl2ZXMgdGhhdAogICBiZmQuTG9jYWxEaWFnIGNvZGUsIGl0IHRyZWF0cyBpdCBh cyBpZiB0aGUgdHVubmVsIGl0c2VsZiBmYWlsZWQgYW5kCiAgIHRyaWVzIHRvIHN3aXRjaCB0byBh IGJhY2t1cCBQRS4KCjQuICBTdGFuZGJ5IEMtbXVsdGljYXN0IFJvdXRlCgogICBUaGUgcHJvY2Vk dXJlcyBkZXNjcmliZWQgYmVsb3cgYXJlIGxpbWl0ZWQgdG8gdGhlIGNhc2Ugd2hlcmUgdGhlIHNp dGUKICAgdGhhdCBjb250YWlucyBDLVMgaXMgY29ubmVjdGVkIHRvIHR3byBvciBtb3JlIFBFcyB0 aG91Z2gsIHRvIHNpbXBsaWZ5CiAgIHRoZSBkZXNjcmlwdGlvbiwgdGhlIGNhc2Ugb2YgZHVhbC1o b21pbmcgaXMgZGVzY3JpYmVkLiAgVGhlCiAgIHByb2NlZHVyZXMgcmVxdWlyZSBhbGwgdGhlIFBF cyBvZiB0aGF0IE1WUE4gdG8gZm9sbG93IHRoZSBzYW1lIFVNSAogICBzZWxlY3Rpb24gcHJvY2Vk dXJlLCBhcyBzcGVjaWZpZWQgaW4gW1JGQzY1MTNdLCB3aGV0aGVyIHRoZSBQRQogICBzZWxlY3Rl ZCBiYXNlZCBvbiBpdHMgSVAgYWRkcmVzcywgaGFzaGluZyBhbGdvcml0aG0gZGVzY3JpYmVkIGlu CiAgIHNlY3Rpb24gNS4xLjMgb2YgW1JGQzY1MTNdLCBvciBJbnN0YWxsZWQgVU1IIFJvdXRlLiAg VGhlIHByb2NlZHVyZXMKICAgYXNzdW1lIHRoYXQgaWYgYSBzaXRlIG9mIGEgZ2l2ZW4gTVZQTiB0 aGF0IGNvbnRhaW5zIEMtUyBpcyBkdWFsLWhvbWVkCiAgIHRvIHR3byBQRXMsIHRoZW4gYWxsIHRo ZSBvdGhlciBzaXRlcyBvZiB0aGF0IE1WUE4gd291bGQgaGF2ZSB0d28KICAgdW5pY2FzdCBWUE4g cm91dGVzIChWUE4tSVB2NCBvciBWUE4tSVB2NikgdG8gQy1TLCBlYWNoIHdpdGggaXRzIFJELgoK ICAgQXMgbG9uZyBhcyBDLVMgaXMgcmVhY2hhYmxlIHZpYSBib3RoIFBFcywgYSBnaXZlbiBkb3du c3RyZWFtIFBFIHdpbGwKICAgc2VsZWN0IG9uZSBvZiB0aGUgUEVzIGNvbm5lY3RlZCB0byBDLVMg YXMgaXRzIFVwc3RyZWFtIFBFIGZvciBDLVMuCiAgIFdlIHdpbGwgcmVmZXIgdG8gdGhlIG90aGVy IFBFIGNvbm5lY3RlZCB0byBDLVMgYXMgdGhlICJTdGFuZGJ5CiAgIFVwc3RyZWFtIFBFIi4gIE5v dGUgdGhhdCBpZiB0aGUgY29ubmVjdGl2aXR5IHRvIEMtUyB0aHJvdWdoIHRoZQogICBQcmltYXJ5 IFVwc3RyZWFtIFBFIGJlY29tZXMgdW5hdmFpbGFibGUsIHRoZW4gdGhlIFBFIHdpbGwgc2VsZWN0 IHRoZQogICBTdGFuZGJ5IFVwc3RyZWFtIFBFIGFzIGl0cyBVcHN0cmVhbSBQRSBmb3IgQy1TLiAg V2hlbiB0aGUgUHJpbWFyeSBQRQogICBsYXRlciBiZWNvbWVzIGF2YWlsYWJsZSwgdGhlbiB0aGUg UEUgd2lsbCBzZWxlY3QgdGhlIFByaW1hcnkgVXBzdHJlYW0KICAgUEUgYWdhaW4gYXMgaXRzIFVw c3RyZWFtIFBFLiAgU3VjaCBiZWhhdmlvciBpcyByZWZlcnJlZCB0byBhcwogICAicmV2ZXJ0aXZl IiBiZWhhdmlvciBhbmQgTVVTVCBiZSBzdXBwb3J0ZWQuICBOb24tcmV2ZXJ0aXZlIGJlaGF2aW9y CiAgIHJlZmVycyB0byB0aGUgYmVoYXZpb3Igb2YgY29udGludWluZyB0byBzZWxlY3QgdGhlIGJh Y2t1cCBQRSBhcyB0aGUKICAgVU1IIGV2ZW4gYWZ0ZXIgdGhlIFByaW1hcnkgaGFzIGNvbWUgdXAu ICBUaGlzIG5vbi1yZXZlcnRpdmUgYmVoYXZpb3IKICAgTUFZIGFsc28gYmUgc3VwcG9ydGVkIGJ5 IGFuIGltcGxlbWVudGF0aW9uIGFuZCB3b3VsZCBiZSBlbmFibGVkCiAgIHRocm91Z2ggc29tZSBj b25maWd1cmF0aW9uLgoKCgpNb3JpbiwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDE0 LCAyMDIxICAgICAgICAgICAgICAgICBbUGFnZSAxMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg IE1WUE4gRmFzdCBVcHN0cmVhbSBGYWlsb3ZlciAgICAgICAgIE5vdmVtYmVyIDIwMjAKCgogICBG b3IgcmVhZGFiaWxpdHksIGluIHRoZSBmb2xsb3dpbmcgc3ViLXNlY3Rpb25zLCB0aGUgcHJvY2Vk dXJlcyBhcmUKICAgZGVzY3JpYmVkIGZvciBCR1AgQy1tdWx0aWNhc3QgU291cmNlIFRyZWUgSm9p biByb3V0ZXMsIGJ1dCB0aGV5IGFwcGx5CiAgIGVxdWFsbHkgdG8gQkdQIEMtbXVsdGljYXN0IFNo YXJlZCBUcmVlIEpvaW4gcm91dGVzIGZvciB0aGUgY2FzZSB3aGVyZQogICB0aGUgY3VzdG9tZXIg UlAgaXMgZHVhbC1ob21lZCAoc3Vic3RpdHV0ZSAiQy1SUCIgdG8gIkMtUyIpLgoKNC4xLiAgRG93 bnN0cmVhbSBQRSBCZWhhdmlvcgoKICAgV2hlbiBhIChkb3duc3RyZWFtKSBQRSBjb25uZWN0ZWQg dG8gc29tZSBzaXRlIG9mIGFuIE1WUE4gbmVlZHMgdG8KICAgc2VuZCBhIEMtbXVsdGljYXN0IHJv dXRlIChDLVMsIEMtRyksIHRoZW4gZm9sbG93aW5nIHRoZSBwcm9jZWR1cmVzCiAgIHNwZWNpZmll ZCBpbiBTZWN0aW9uIDExLjEgb2YgW1JGQzY1MTRdLCB0aGUgUEUgc2VuZHMgdGhlIEMtbXVsdGlj YXN0CiAgIHJvdXRlIHdpdGggYW4gUlQgdGhhdCBpZGVudGlmaWVzIHRoZSBVcHN0cmVhbSBQRSBz ZWxlY3RlZCBieSB0aGUgUEUKICAgb3JpZ2luYXRpbmcgdGhlIHJvdXRlLiAgQXMgbG9uZyBhcyBD LVMgaXMgcmVhY2hhYmxlIHZpYSB0aGUgUHJpbWFyeQogICBVcHN0cmVhbSBQRSwgdGhlIFVwc3Ry ZWFtIFBFIGlzIHRoZSBQcmltYXJ5IFVwc3RyZWFtIFBFLiAgSWYgQy1TIGlzCiAgIHJlYWNoYWJs ZSBvbmx5IHZpYSB0aGUgU3RhbmRieSBVcHN0cmVhbSBQRSwgdGhlbiB0aGUgVXBzdHJlYW0gUEUg aXMKICAgdGhlIFN0YW5kYnkgVXBzdHJlYW0gUEUuCgogICBJZiBDLVMgaXMgcmVhY2hhYmxlIHZp YSBib3RoIHRoZSBQcmltYXJ5IGFuZCB0aGUgU3RhbmRieSBVcHN0cmVhbSBQRSwKICAgdGhlbiBp biBhZGRpdGlvbiB0byBzZW5kaW5nIHRoZSBDLW11bHRpY2FzdCByb3V0ZSB3aXRoIGFuIFJUIHRo YXQKICAgaWRlbnRpZmllcyB0aGUgUHJpbWFyeSBVcHN0cmVhbSBQRSwgdGhlIGRvd25zdHJlYW0g UEUgYWxzbyBvcmlnaW5hdGVzCiAgIGFuZCBzZW5kcyBhIEMtbXVsdGljYXN0IHJvdXRlIHdpdGgg YW4gUlQgdGhhdCBpZGVudGlmaWVzIHRoZSBTdGFuZGJ5CiAgIFVwc3RyZWFtIFBFLiAgVGhlIHJv dXRlIHRoYXQgaGFzIHRoZSBzZW1hbnRpY3Mgb2YgYmVpbmcgYSAic3RhbmRieSIKICAgQy1tdWx0 aWNhc3Qgcm91dGUgaXMgZnVydGhlciBjYWxsZWQgYSAiU3RhbmRieSBCR1AgQy1tdWx0aWNhc3QK ICAgcm91dGUiLCBhbmQgaXMgY29uc3RydWN0ZWQgYXMgZm9sbG93czoKCiAgIG8gIHRoZSBOTFJJ IGlzIGNvbnN0cnVjdGVkIGFzIHRoZSBDLW11bHRpY2FzdCByb3V0ZSB3aXRoIGFuIFJUIHRoYXQK ICAgICAgaWRlbnRpZmllcyB0aGUgUHJpbWFyeSBVcHN0cmVhbSBQRSwgZXhjZXB0IHRoYXQgdGhl IFJEIGlzIHRoZSBzYW1lCiAgICAgIGFzIGlmIHRoZSBDLW11bHRpY2FzdCByb3V0ZSB3YXMgYnVp bHQgdXNpbmcgdGhlIFN0YW5kYnkgVXBzdHJlYW0KICAgICAgUEUgYXMgdGhlIFVNSCAoaXQgd2ls bCBjYXJyeSB0aGUgUkQgYXNzb2NpYXRlZCB0byB0aGUgdW5pY2FzdCBWUE4KICAgICAgcm91dGUg YWR2ZXJ0aXNlZCBieSB0aGUgU3RhbmRieSBVcHN0cmVhbSBQRSBmb3IgUyBhbmQgYSBSb3V0ZQog ICAgICBUYXJnZXQgZGVyaXZlZCBmcm9tIHRoZSBTdGFuZGJ5IFVwc3RyZWFtIFBFJ3MgVU1IIHJv dXRlJ3MgVlJGIFJUCiAgICAgIEltcG9ydCBFQyk7CgogICBvICBNVVNUIGNhcnJ5IHRoZSAiU3Rh bmRieSBQRSIgQkdQIENvbW11bml0eSAodGhpcyBpcyBhIG5ldyBCR1AKICAgICAgQ29tbXVuaXR5 LiAgU2VjdGlvbiA3LjEgcmVxdWVzdGVkIElBTkEgdG8gYWxsb2NhdGUgdmFsdWUgVEJBMSkuCgog ICBUaGUgTG9jYWwgUHJlZmVyZW5jZSBhdHRyaWJ1dGUgb2YgdGhlIG5vcm1hbCBhbmQgdGhlIHN0 YW5kYnkKICAgQy1tdWx0aWNhc3Qgcm91dGUgbmVlZHMgdG8gYmUgYWRqdXN0ZWQuIHNvIHRoYXQs IGlmIGEgQkdQIHBlZXIKICAgcmVjZWl2ZXMgdHdvIEMtbXVsdGljYXN0IHJvdXRlcyB3aXRoIHRo ZSBzYW1lIE5MUkksIG9uZSBjYXJyeWluZyB0aGUKICAgIlN0YW5kYnkgUEUiIGNvbW11bml0eSBh bmQgdGhlIG90aGVyIG9uZSBub3QgY2FycnlpbmcgdGhlICJTdGFuZGJ5CiAgIFBFIiBjb21tdW5p dHksIHRoZW4gcHJlZmVyZW5jZSBpcyBnaXZlbiB0byB0aGUgb25lIG5vdCBjYXJyeWluZyB0aGUK ICAgIlN0YW5kYnkgUEUiIGNvbW11bml0eS4gIFN1Y2ggYSBzaXR1YXRpb24gY2FuIGhhcHBlbiB3 aGVuLCBmb3IKICAgaW5zdGFuY2UsIGR1ZSB0byB0cmFuc2llbnQgdW5pY2FzdCByb3V0aW5nIGlu Y29uc2lzdGVuY2llcyBvciBsYWNrIG9mCiAgIHN1cHBvcnQgb2YgdGhlIFN0YW5kYnkgUEUgY29t bXVuaXR5LCB0d28gZGlmZmVyZW50IGRvd25zdHJlYW0gUEVzCiAgIGNvbnNpZGVyIGRpZmZlcmVu dCBVcHN0cmVhbSBQRXMgdG8gYmUgdGhlIHByaW1hcnkgb25lLiAgSW4gdGhhdCBjYXNlLAogICB3 aXRob3V0IGFueSBwcmVjYXV0aW9uIHRha2VuLCBib3RoIFVwc3RyZWFtIFBFcyB3b3VsZCBwcm9j ZXNzIGEKICAgc3RhbmRieSBDLW11bHRpY2FzdCByb3V0ZSBhbmQgcG9zc2libHkgc3RvcCBmb3J3 YXJkaW5nIGF0IHRoZSBzYW1lCiAgIHRpbWUuICBGb3IgdGhpcyBwdXJwb3NlLCByb3V0ZXMgdGhh dCBjYXJyeSB0aGUgIlN0YW5kYnkgUEUiIEJHUAogICBDb21tdW5pdHkgTVVTVCBoYXZlIHRoZSBM T0NBTF9QUkVGIGF0dHJpYnV0ZSBzZXQgdG8gemVyby4KCgoKTW9yaW4sIGV0IGFsLiAgICAgICAg ICAgICBFeHBpcmVzIE1heSAxNCwgMjAyMSAgICAgICAgICAgICAgICAgW1BhZ2UgMTNdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICBNVlBOIEZhc3QgVXBzdHJlYW0gRmFpbG92ZXIgICAgICAgICBO b3ZlbWJlciAyMDIwCgoKICAgTm90ZSB0aGF0LCB3aGVuIGEgUEUgYWR2ZXJ0aXNlcyBzdWNoIGEg U3RhbmRieSBDLW11bHRpY2FzdCBqb2luIGZvciBhCiAgIChDLVMsIEMtRykgaXQgTVVTVCBqb2lu IHRoZSBjb3JyZXNwb25kaW5nIFAtdHVubmVsLgoKICAgSWYgYXQgc29tZSBsYXRlciBwb2ludCwg dGhlIFBFIGRldGVybWluZXMgdGhhdCBDLVMgaXMgbm8gbG9uZ2VyCiAgIHJlYWNoYWJsZSB0aHJv dWdoIHRoZSBQcmltYXJ5IFVwc3RyZWFtIFBFLCB0aGUgU3RhbmRieSBVcHN0cmVhbSBQRQogICBi ZWNvbWVzIHRoZSBVcHN0cmVhbSBQRSwgYW5kIHRoZSBQRSByZS1zZW5kcyB0aGUgQy1tdWx0aWNh c3Qgcm91dGUKICAgd2l0aCBSVCB0aGF0IGlkZW50aWZpZXMgdGhlIFN0YW5kYnkgVXBzdHJlYW0g UEUsIGV4Y2VwdCB0aGF0IG5vdyB0aGUKICAgcm91dGUgZG9lcyBub3QgY2FycnkgdGhlIFN0YW5k YnkgUEUgQkdQIENvbW11bml0eSAod2hpY2ggcmVzdWx0cyBpbgogICByZXBsYWNpbmcgdGhlIG9s ZCByb3V0ZSB3aXRoIGEgbmV3IHJvdXRlLCB3aXRoIHRoZSBvbmx5IGRpZmZlcmVuY2UKICAgYmV0 d2VlbiB0aGVzZSByb3V0ZXMgYmVpbmcgdGhlIHByZXNlbmNlL2Fic2VuY2Ugb2YgdGhlIFN0YW5k YnkgUEUgQkdQCiAgIENvbW11bml0eSkuICBUaGUgTE9DQUxfUFJFRiBhdHRyaWJ1dGUgTVVTVCBi ZSBzZXQgdG8gemVyby4KCjQuMi4gIFVwc3RyZWFtIFBFIEJlaGF2aW9yCgogICBXaGVuIGEgUEUg cmVjZWl2ZXMgYSBDLW11bHRpY2FzdCByb3V0ZSBmb3IgYSBwYXJ0aWN1bGFyIChDLVMsIEMtRyks CiAgIGFuZCB0aGUgUlQgY2FycmllZCBpbiB0aGUgcm91dGUgcmVzdWx0cyBpbiBpbXBvcnRpbmcg dGhlIHJvdXRlIGludG8gYQogICBwYXJ0aWN1bGFyIFZSRiBvbiB0aGUgUEUsIGlmIHRoZSByb3V0 ZSBjYXJyaWVzIHRoZSBTdGFuZGJ5IFBFIEJHUAogICBDb21tdW5pdHksIHRoZW4gdGhlIFBFIHBl cmZvcm1zIGFzIGZvbGxvd3M6CgogICAgICB3aGVuIHRoZSBQRSBkZXRlcm1pbmVzICh0aGUgdXNl IG9mIHRoZSBwYXJ0aWN1bGFyIG1ldGhvZCB0byBkZXRlY3QKICAgICAgdGhlIGZhaWx1cmUgaXMg b3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudCkgdGhhdCBDLVMgaXMgbm90CiAgICAg IHJlYWNoYWJsZSB0aHJvdWdoIHNvbWUgb3RoZXIgUEUsIHRoZSBQRSBTSE9VTEQgaW5zdGFsbCBW UkYgUElNCiAgICAgIHN0YXRlIGNvcnJlc3BvbmRpbmcgdG8gdGhpcyBTdGFuZGJ5IEJHUCBDLW11 bHRpY2FzdCByb3V0ZSAodGhlCiAgICAgIHJlc3VsdCB3aWxsIGJlIHRoYXQgYSBQSU0gSm9pbiBt ZXNzYWdlIHdpbGwgYmUgc2VudCB0byB0aGUgQ0UKICAgICAgdG93YXJkcyBDLVMsIGFuZCB0aGF0 IHRoZSBQRSB3aWxsIHJlY2VpdmUgKEMtUywgQy1HKSB0cmFmZmljKSwgYW5kCiAgICAgIHRoZSBQ RSBTSE9VTEQgZm9yd2FyZCAoQy1TLCBDLUcpIHRyYWZmaWMgcmVjZWl2ZWQgYnkgdGhlIFBFIHRv CiAgICAgIG90aGVyIFBFcyB0aHJvdWdoIGEgUC10dW5uZWwgcm9vdGVkIGF0IHRoZSBQRS4KCiAg IEZ1cnRoZXJtb3JlLCBpcnJlc3BlY3RpdmUgb2Ygd2hldGhlciBDLVMgY2FycmllZCBpbiB0aGF0 IHJvdXRlIGlzCiAgIHJlYWNoYWJsZSB0aHJvdWdoIHNvbWUgb3RoZXIgUEU6CgogICBhKSBiYXNl ZCBvbiBsb2NhbCBwb2xpY3ksIGFzIHNvb24gYXMgdGhlIFBFIHJlY2VpdmVzIHRoaXMgU3RhbmRi eSBCR1AKICAgICAgQy1tdWx0aWNhc3Qgcm91dGUsIHRoZSBQRSBNQVkgaW5zdGFsbCBWUkYgUElN IHN0YXRlIGNvcnJlc3BvbmRpbmcKICAgICAgdG8gdGhpcyBCR1AgU291cmNlIFRyZWUgSm9pbiBy b3V0ZSAodGhlIHJlc3VsdCB3aWxsIGJlIHRoYXQgSm9pbgogICAgICBtZXNzYWdlcyB3aWxsIGJl IHNlbnQgdG8gdGhlIENFIHRvd2FyZCBDLVMsIGFuZCB0aGF0IHRoZSBQRSB3aWxsCiAgICAgIHJl Y2VpdmUgKEMtUywgQy1HKSB0cmFmZmljKQoKICAgYikgYmFzZWQgb24gbG9jYWwgcG9saWN5LCBh cyBzb29uIGFzIHRoZSBQRSByZWNlaXZlcyB0aGlzIFN0YW5kYnkgQkdQCiAgICAgIEMtbXVsdGlj YXN0IHJvdXRlLCB0aGUgUEUgTUFZIGZvcndhcmQgKEMtUywgQy1HKSB0cmFmZmljIHRvIG90aGVy CiAgICAgIFBFcyB0aHJvdWdoIGEgUC10dW5uZWwgaW5kZXBlbmRlbnRseSBvZiB0aGUgcmVhY2hh YmlsaXR5IG9mIEMtUwogICAgICB0aHJvdWdoIHNvbWUgb3RoZXIgUEUuIFtub3RlIHRoYXQgdGhp cyBpbXBsaWVzIGFsc28gZG9pbmcgYSldCgogICBEb2luZyBuZWl0aGVyIGEpIG9yIGIpIGZvciBh IGdpdmVuIChDLVMsIEMtRykgaXMgY2FsbGVkICJjb2xkIHJvb3QKICAgc3RhbmRieSIuCgogICBE b2luZyBhKSBidXQgbm90IGIpIGZvciBhIGdpdmVuIChDLVMsIEMtRykgaXMgY2FsbGVkICJ3YXJt IHJvb3QKICAgc3RhbmRieSIuCgoKCgpNb3JpbiwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMg TWF5IDE0LCAyMDIxICAgICAgICAgICAgICAgICBbUGFnZSAxNF0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgIE1WUE4gRmFzdCBVcHN0cmVhbSBGYWlsb3ZlciAgICAgICAgIE5vdmVtYmVyIDIwMjAK CgogICBEb2luZyBiKSAod2hpY2ggaW1wbGllcyBhbHNvIGRvaW5nIGEpKSBmb3IgYSBnaXZlbiAo Qy1TLCBDLUcpIGlzCiAgIGNhbGxlZCAiaG90IHJvb3Qgc3RhbmRieSIuCgogICBOb3RlIHRoYXQs IGlmIGFuIFVwc3RyZWFtIFBFIHVzZXMgYW4gUy1QTVNJIG9ubHkgcG9saWN5LCBpdCBzaGFsbAog ICBhZHZlcnRpc2UgYW4gUy1QTVNJIGZvciBhIChDLVMsIEMtRykgYXMgc29vbiBhcyBpdCByZWNl aXZlcyBhCiAgIEMtbXVsdGljYXN0IHJvdXRlIGZvciAoQy1TLCBDLUcpLCBub3JtYWwgb3IgU3Rh bmRieTsgaS5lLiwgaXQgc2hhbGwKICAgbm90IHdhaXQgZm9yIHJlY2VpdmluZyBhIG5vbi1TdGFu ZGJ5IEMtbXVsdGljYXN0IHJvdXRlIGJlZm9yZQogICBhZHZlcnRpc2luZyB0aGUgY29ycmVzcG9u ZGluZyBTLVBNU0kuCgogICBTZWN0aW9uIDkuMy4yIG9mIFtSRkM2NTE0XSwgZGVzY3JpYmVzIHRo ZSBwcm9jZWR1cmVzIG9mIHNlbmRpbmcgYQogICBTb3VyY2UtQWN0aXZlIEEtRCBSb3V0ZSBhcyBh IHJlc3VsdCBvZiByZWNlaXZpbmcgdGhlIEMtbXVsdGljYXN0CiAgIHJvdXRlLiAgVGhlc2UgcHJv Y2VkdXJlcyBNVVNUIGJlIGZvbGxvd2VkIGZvciBib3RoIHRoZSBub3JtYWwgYW5kCiAgIFN0YW5k YnkgQy1tdWx0aWNhc3Qgcm91dGVzLgoKNC4zLiAgUmVhY2hhYmlsaXR5IERldGVybWluYXRpb24K CiAgIFRoZSBTdGFuZGJ5IFVwc3RyZWFtIFBFIGNhbiB1c2UgdGhlIGZvbGxvd2luZyBpbmZvcm1h dGlvbiB0bwogICBkZXRlcm1pbmUgdGhhdCBDLVMgY2FuIG9yIGNhbm5vdCBiZSByZWFjaGVkIHRo cm91Z2ggdGhlIFByaW1hcnkKICAgVXBzdHJlYW0gUEU6CgogICBvICBwcmVzZW5jZS9hYnNlbmNl IG9mIGEgdW5pY2FzdCBWUE4gcm91dGUgdG93YXJkIEMtUwoKICAgbyAgc3VwcG9zaW5nIHRoYXQg dGhlIFN0YW5kYnkgVXBzdHJlYW0gUEUgaXMgdGhlIGVncmVzcyBvZiB0aGUgdHVubmVsCiAgICAg IHJvb3RlZCBhdCB0aGUgUHJpbWFyeSBVcHN0cmVhbSBQRSwgdGhlIFN0YW5kYnkgVXBzdHJlYW0g UEUgY2FuCiAgICAgIGRldGVybWluZSB0aGUgcmVhY2hhYmlsaXR5IG9mIEMtUyB0aHJvdWdoIHRo ZSBQcmltYXJ5IFVwc3RyZWFtIFBFCiAgICAgIGJhc2VkIG9uIHRoZSBzdGF0dXMgb2YgdGhpcyB0 dW5uZWwsIGRldGVybWluZWQgdGhhbmtzIHRvIHRoZSBzYW1lCiAgICAgIGNyaXRlcmlhIGFzIHRo ZSBvbmVzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMSAod2l0aG91dCB1c2luZyB0aGUKICAgICAg VU1IIHNlbGVjdGlvbiBwcm9jZWR1cmVzIG9mIFNlY3Rpb24gMyk7CgogICBvICBvdGhlciBtZWNo YW5pc21zIE1BWSBiZSB1c2VkLgoKNC40LiAgSW50ZXItQVMKCiAgIElmIHRoZSBub24tc2VnbWVu dGVkIGludGVyLUFTIGFwcHJvYWNoIGlzIHVzZWQsIHRoZSBwcm9jZWR1cmVzCiAgIGRlc2NyaWJl ZCBpbiBTZWN0aW9uIDQuMSB0aHJvdWdoIFNlY3Rpb24gNC4zIGNhbiBiZSBhcHBsaWVkLgoKICAg V2hlbiBtdWx0aWNhc3QgVlBOcyBhcmUgdXNlZCBpbiBhbiBpbnRlci1BUyBjb250ZXh0IHdpdGgg dGhlCiAgIHNlZ21lbnRlZCBpbnRlci1BUyBhcHByb2FjaCBkZXNjcmliZWQgaW4gU2VjdGlvbiA5 LjIgb2YgW1JGQzY1MTRdLAogICB0aGUgcHJvY2VkdXJlcyBpbiB0aGlzIHNlY3Rpb24gY2FuIGJl IGFwcGxpZWQuCgogICBBIHByZS1yZXF1aXNpdGUgZm9yIHRoZSBwcm9jZWR1cmVzIGRlc2NyaWJl ZCBiZWxvdyB0byBiZSBhcHBsaWVkIGZvcgogICBhIHNvdXJjZSBvZiBhIGdpdmVuIE1WUE4gaXM6 CgogICBvICB0aGF0IGFueSBQRSBvZiB0aGlzIE1WUE4gcmVjZWl2ZXMgdHdvIG9yIG1vcmUgSW50 ZXItQVMgSS1QTVNJIEEtRAogICAgICBSb3V0ZXMgYWR2ZXJ0aXNlZCBieSB0aGUgQVMgb2YgdGhl IHNvdXJjZQoKCgoKCgpNb3JpbiwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDE0LCAy MDIxICAgICAgICAgICAgICAgICBbUGFnZSAxNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIE1W UE4gRmFzdCBVcHN0cmVhbSBGYWlsb3ZlciAgICAgICAgIE5vdmVtYmVyIDIwMjAKCgogICBvICB0 aGF0IHRoZXNlIEludGVyLUFTIEktUE1TSSBBLUQgUm91dGVzIGhhdmUgZGlzdGluY3QgUm91dGUK ICAgICAgRGlzdGluZ3Vpc2hlcnMgKGFzIGRlc2NyaWJlZCBpbiBpdGVtICIoMikiIG9mIHNlY3Rp b24gOS4yIG9mCiAgICAgIFtSRkM2NTE0XSkuCgogICBBcyBhbiBleGFtcGxlLCB0aGVzZSBjb25k aXRpb25zIHdpbGwgYmUgc2F0aXNmaWVkIHdoZW4gdGhlIHNvdXJjZSBpcwogICBkdWFsLWhvbWVk IHRvIGFuIEFTIHRoYXQgY29ubmVjdHMgdG8gdGhlIHJlY2VpdmVyIEFTIHRocm91Z2ggdHdvIEFT QlIKICAgdXNpbmcgYXV0by1jb25maWd1cmVkIFJEcy4KCjQuNC4xLiAgSW50ZXItQVMgUHJvY2Vk dXJlcyBmb3IgZG93bnN0cmVhbSBQRXMsIEFTQlIgRmFzdCBGYWlsb3ZlcgoKICAgVGhlIGZvbGxv d2luZyBwcm9jZWR1cmUgaXMgYXBwbGllZCBieSBkb3duc3RyZWFtIFBFcyBvZiBhbiBBUywgZm9y IGEKICAgc291cmNlIFMgaW4gYSByZW1vdGUgQVMuCgogICBBZGRpdGlvbmFsbHkgdG8gY2hvb3Np bmcgYW4gSW50ZXItQVMgSS1QTVNJIEEtRCBSb3V0ZSBhZHZlcnRpc2VkIGZyb20KICAgdGhlIEFT IG9mIHRoZSBzb3VyY2UgdG8gY29uc3RydWN0IGEgQy1tdWx0aWNhc3Qgcm91dGUsIGFzIGRlc2Ny aWJlZAogICBpbiBzZWN0aW9uIDExLjEuMyBbUkZDNjUxNF0sIGEgZG93bnN0cmVhbSBQRSB3aWxs IGNob29zZSBhIHNlY29uZAogICBJbnRlci1BUyBJLVBNU0kgQS1EIFJvdXRlIGFkdmVydGlzZWQg ZnJvbSB0aGUgQVMgb2YgdGhlIHNvdXJjZSBhbmQKICAgdXNlIHRoaXMgcm91dGUgdG8gY29uc3Ry dWN0IGFuZCBhZHZlcnRpc2UgYSBTdGFuZGJ5IEMtbXVsdGljYXN0IHJvdXRlCiAgIChDLW11bHRp Y2FzdCByb3V0ZSBjYXJyeWluZyB0aGUgU3RhbmRieSBleHRlbmRlZCBjb21tdW5pdHkpLCBhcwog ICBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LjEuCgo0LjQuMi4gIEludGVyLUFTIFByb2NlZHVyZXMg Zm9yIEFTQlJzCgogICBXaGVuIGFuIFVwc3RyZWFtIEFTQlIgcmVjZWl2ZXMgYSBDLW11bHRpY2Fz dCByb3V0ZSwgYW5kIGF0IGxlYXN0IG9uZQogICBvZiB0aGUgUlRzIG9mIHRoZSByb3V0ZSBtYXRj aGVzIG9uZSBvZiB0aGUgQVNCUiBJbXBvcnQgUlQsIHRoZSBBU0JSLAogICB0aGF0IHN1cHBvcnRz IHRoaXMgc3BlY2lmaWNhdGlvbiwgTVVTVCB0cnkgdG8gbG9jYXRlIGFuIEludGVyLUFTCiAgIEkt UE1TSSBBLUQgUm91dGUgd2hvc2UgUkQgYW5kIFNvdXJjZSBBUyByZXNwZWN0aXZlbHkgbWF0Y2gg dGhlIFJEIGFuZAogICBTb3VyY2UgQVMgY2FycmllZCBpbiB0aGUgQy1tdWx0aWNhc3Qgcm91dGUu ICBJZiB0aGUgbWF0Y2ggaXMgZm91bmQsCiAgIGFuZCB0aGUgQy1tdWx0aWNhc3Qgcm91dGUgY2Fy cmllcyB0aGUgU3RhbmRieSBQRSBCR1AgQ29tbXVuaXR5LCB0aGVuCiAgIHRoZSBBU0JSIE1VU1Qg cGVyZm9ybSBhcyBmb2xsb3dzOgoKICAgbyAgaWYgdGhlIHJvdXRlIHdhcyByZWNlaXZlZCBvdmVy IGlCR1AgYW5kIGl0cyBMT0NBTF9QUkVGIGF0dHJpYnV0ZQogICAgICBpcyBzZXQgdG8gemVybywg dGhlbiBpdCBNVVNUIGJlIHJlLWFkdmVydGlzZWQgaW4gZUJHUCB3aXRoIGEgTUVECiAgICAgIGF0 dHJpYnV0ZSAoTVVMVElfRVhJVF9ESVNDKSBzZXQgdG8gdGhlIGhpZ2hlc3QgcG9zc2libGUgdmFs dWUKICAgICAgKDB4ZmZmZikKCiAgIG8gIGlmIHRoZSByb3V0ZSB3YXMgcmVjZWl2ZWQgb3ZlciBl QkdQIGFuZCBpdHMgTUVEIGF0dHJpYnV0ZSBzZXQgdG8KICAgICAgMHhmZmZmLCB0aGVuIGl0IE1V U1QgYmUgcmUtYWR2ZXJ0aXNlZCBpbiBpQkdQIHdpdGggYSBMT0NBTF9QUkVGCiAgICAgIGF0dHJp YnV0ZSBzZXQgdG8gemVybwoKICAgT3RoZXIgQVNCUiBwcm9jZWR1cmVzIGFyZSBhcHBsaWVkIHdp dGhvdXQgbW9kaWZpY2F0aW9uLgoKNS4gIEhvdCBSb290IFN0YW5kYnkKCiAgIFRoZSBtZWNoYW5p c21zIGRlZmluZWQgaW4gU2VjdGlvbiA0IGFuZCBTZWN0aW9uIDMgY2FuIGJlIHVzZWQKICAgdG9n ZXRoZXIgYXMgZm9sbG93cy4KCgoKCgpNb3JpbiwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMg TWF5IDE0LCAyMDIxICAgICAgICAgICAgICAgICBbUGFnZSAxNl0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgIE1WUE4gRmFzdCBVcHN0cmVhbSBGYWlsb3ZlciAgICAgICAgIE5vdmVtYmVyIDIwMjAK CgogICBUaGUgcHJpbmNpcGxlIGlzIHRoYXQsIGZvciBhIGdpdmVuIFZSRiAob3IgcG9zc2libHkg b25seSBmb3IgYSBnaXZlbgogICAoQy1TLCBDLUcpOgoKICAgbyAgZG93bnN0cmVhbSBQRXMgYWR2 ZXJ0aXNlIGEgU3RhbmRieSBCR1AgQy1tdWx0aWNhc3Qgcm91dGUgKGJhc2VkIG9uCiAgICAgIFNl Y3Rpb24gNCkKCiAgIG8gIFVwc3RyZWFtIFBFcyB1c2UgdGhlICJob3Qgc3RhbmRieSIgb3B0aW9u YWwgYmVoYXZpb3IgYW5kIHRodXMgd2lsbAogICAgICBmb3J3YXJkIHRyYWZmaWMgZm9yIGEgZ2l2 ZW4gbXVsdGljYXN0IHN0YXRlIGFzIHNvb24gYXMgdGhleSBoYXZlCiAgICAgIHdoZXRoZXIgYSAo cHJpbWFyeSkgQkdQIEMtbXVsdGljYXN0IHJvdXRlIG9yIGEgU3RhbmRieSBCR1AKICAgICAgQy1t dWx0aWNhc3Qgcm91dGUgZm9yIHRoYXQgc3RhdGUgKG9yIGJvdGgpCgogICBvICBkb3duc3RyZWFt IFBFcyBhY2NlcHQgdHJhZmZpYyBmcm9tIHRoZSBwcmltYXJ5IG9yIHN0YW5kYnkgdHVubmVsLAog ICAgICBiYXNlZCBvbiB0aGUgc3RhdHVzIG9mIHRoZSB0dW5uZWwgKGJhc2VkIG9uIFNlY3Rpb24g MykKCiAgIE90aGVyIGNvbWJpbmF0aW9ucyBvZiB0aGUgbWVjaGFuaXNtcyBwcm9wb3NlZCBpbiBT ZWN0aW9uIDQgYW5kCiAgIFNlY3Rpb24gMyBhcmUgZm9yIGZ1cnRoZXIgc3R1ZHkuCgogICBOb3Rl IHRoYXQgdGhlIHNhbWUgbGV2ZWwgb2YgcHJvdGVjdGlvbiB3b3VsZCBiZSBhY2hpZXZhYmxlIHdp dGggYQogICBzaW1wbGUgQy1tdWx0aWNhc3QgU291cmNlIFRyZWUgSm9pbiByb3V0ZSBhZHZlcnRp c2VkIHRvIGJvdGggdGhlCiAgIHByaW1hcnkgYW5kIHNlY29uZGFyeSBVcHN0cmVhbSBQRXMgKGNh cnJ5aW5nIGFzIFJvdXRlIFRhcmdldCBleHRlbmRlZAogICBjb21tdW5pdGllcywgdGhlIHZhbHVl cyBvZiB0aGUgVlJGIFJvdXRlIEltcG9ydCBhdHRyaWJ1dGUgb2YgZWFjaCBWUE4KICAgcm91dGUg ZnJvbSBlYWNoIFVwc3RyZWFtIFBFcykuICBUaGUgYWR2YW50YWdlIG9mIHVzaW5nIHRoZSBTdGFu ZGJ5CiAgIHNlbWFudGljIGlzIHRoYXQsIHN1cHBvc2luZyB0aGF0IGRvd25zdHJlYW0gUEVzIGFs d2F5cyBhZHZlcnRpc2UgYQogICBTdGFuZGJ5IEMtbXVsdGljYXN0IHJvdXRlIHRvIHRoZSBzZWNv bmRhcnkgVXBzdHJlYW0gUEUsIGl0IGFsbG93cyB0bwogICBjaG9vc2UgdGhlIHByb3RlY3Rpb24g bGV2ZWwgdGhyb3VnaCBhIGNoYW5nZSBvZiBjb25maWd1cmF0aW9uIG9uIHRoZQogICBzZWNvbmRh cnkgVXBzdHJlYW0gUEUsIHdpdGhvdXQgcmVxdWlyaW5nIGFueSByZWNvbmZpZ3VyYXRpb24gb2Yg YWxsCiAgIHRoZSBkb3duc3RyZWFtIFBFcy4KCjYuICBEdXBsaWNhdGUgUGFja2V0cwoKICAgTXVs dGljYXN0IFZQTiBzcGVjaWZpY2F0aW9ucyBbUkZDNjUxM10gaW1wb3NlIHRoYXQgYSBQRSBvbmx5 IGZvcndhcmRzCiAgIHRvIENFcyB0aGUgcGFja2V0cyBjb21pbmcgZnJvbSB0aGUgZXhwZWN0ZWQg VXBzdHJlYW0gUEUgKFNlY3Rpb24gOS4xCiAgIG9mIFtSRkM2NTEzXSkuCgogICBXZSBkcmF3IHRo ZSByZWFkZXIncyBhdHRlbnRpb24gdG8gdGhlIGZhY3QgdGhhdCB0aGUgcmVzcGVjdCBvZiB0aGlz CiAgIHBhcnQgb2YgbXVsdGljYXN0IFZQTiBzcGVjaWZpY2F0aW9ucyBpcyBlc3BlY2lhbGx5IGlt cG9ydGFudCB3aGVuIHR3bwogICBkaXN0aW5jdCBVcHN0cmVhbSBQRXMgYXJlIHN1c2NlcHRpYmxl IHRvIGZvcndhcmQgdGhlIHNhbWUgdHJhZmZpYyBvbgogICBQLXR1bm5lbHMgYXQgdGhlIHNhbWUg dGltZSBpbiB0aGUgc3RlYWR5IHN0YXRlLiAgVGhhdCB3aWxsIGJlIHRoZQogICBjYXNlIHdoZW4g ImhvdCByb290IHN0YW5kYnkiIG1vZGUgaXMgdXNlZCAoU2VjdGlvbiA0KSwgYW5kIHdoaWNoIGNh bgogICBhbHNvIGJlIHRoZSBjYXNlIGlmIHByb2NlZHVyZXMgb2YgU2VjdGlvbiAzIGFyZSB1c2Vk IGFuZCBhKSB0aGUgcnVsZXMKICAgZGV0ZXJtaW5pbmcgdGhlIHN0YXR1cyBvZiBhIHRyZWUgYXJl IG5vdCB0aGUgc2FtZSBvbiB0d28gZGlzdGluY3QKICAgZG93bnN0cmVhbSBQRXMgb3IgYikgdGhl IHJ1bGUgZGV0ZXJtaW5pbmcgdGhlIHN0YXR1cyBvZiBhIHRyZWUKICAgZGVwZW5kcyBvbiBjb25k aXRpb25zIGxvY2FsIHRvIGEgUEUgKGUuZy4sIHRoZSBQRS1QIHVwc3RyZWFtIGxpbmsKICAgYmVp bmcgdXApLgoKCgoKCgoKTW9yaW4sIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1heSAxNCwg MjAyMSAgICAgICAgICAgICAgICAgW1BhZ2UgMTddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBN VlBOIEZhc3QgVXBzdHJlYW0gRmFpbG92ZXIgICAgICAgICBOb3ZlbWJlciAyMDIwCgoKNy4gIElB TkEgQ29uc2lkZXJhdGlvbnMKCjcuMS4gIFN0YW5kYnkgUEUgQ29tbXVuaXR5CgogICBJQU5BIGlz IHJlcXVlc3RlZCB0byBhbGxvY2F0ZSB0aGUgQkdQICJTdGFuZGJ5IFBFIiBjb21tdW5pdHkgdmFs dWUKICAgKFRCQTEpIGZyb20gdGhlIEJvcmRlciBHYXRld2F5IFByb3RvY29sIChCR1ApIFdlbGwt a25vd24gQ29tbXVuaXRpZXMKICAgcmVnaXN0cnkgdXNpbmcgdGhlIEZpcnN0IENvbWUgRmlyc3Qg U2VydmVkIHJlZ2lzdHJhdGlvbiBwb2xpY3kuCgo3LjIuICBCRkQgRGlzY3JpbWluYXRvcgoKICAg VGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IEJHUCBvcHRpb25hbCB0cmFuc2l0aXZlIGF0dHJp YnV0ZSwgY2FsbGVkCiAgICJCRkQgRGlzY3JpbWluYXRvciIuICBJQU5BIGlzIHJlcXVlc3RlZCB0 byBhbGxvY2F0ZSBhIGNvZGVwb2ludAogICAoVEJBMikgaW4gdGhlICJCR1AgUGF0aCBBdHRyaWJ1 dGVzIiByZWdpc3RyeSB0byB0aGUgQkZEIERpc2NyaW1pbmF0b3IKICAgYXR0cmlidXRlLgoKICAg SUFOQSBpcyByZXF1ZXN0ZWQgdG8gY3JlYXRlIGEgbmV3IEJGRCBNb2RlIHN1Yi1yZWdpc3RyeSBp biB0aGUgQm9yZGVyCiAgIEdhdGV3YXkgUHJvdG9jb2wgKEJHUCkgUGFyYW1ldGVycyByZWdpc3Ry eS4gIFRoZSByZWdpc3RyYXRpb24KICAgcG9saWNpZXMsIHBlciBbUkZDODEyNl0sIGZvciB0aGlz IHN1Yi1yZWdpc3RyeSBhcmUgYWNjb3JkaW5nIHRvCiAgIFRhYmxlIDEuCgogICAgICAgICAgICAg ICAgICArLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAg ICAgICAgfCBWYWx1ZSAgICAgfCAgICAgICAgICBQb2xpY3kgICAgICAgICB8CiAgICAgICAgICAg ICAgICAgICstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAg ICAgICAgICB8IDAtIDE3NSAgICB8ICAgICAgIElFVEYgUmV2aWV3ICAgICAgIHwKICAgICAgICAg ICAgICAgICAgfCAxNzYgLSAyNDkgfCBGaXJzdCBDb21lIEZpcnN0IFNlcnZlZCB8CiAgICAgICAg ICAgICAgICAgIHwgMjUwIC0gMjU0IHwgICAgIEV4cGVyaW1lbnRhbCBVc2UgICAgfAogICAgICAg ICAgICAgICAgICB8IDI1NSAgICAgICB8ICAgICAgIElFVEYgUmV2aWV3ICAgICAgIHwKICAgICAg ICAgICAgICAgICAgKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCgogICAg ICAgICAgIFRhYmxlIDE6IEJGRCBNb2RlIFN1Yi1yZWdpc3RyeSBSZWdpc3RyYXRpb24gUG9saWNp ZXMKCiAgIElBTkEgaXMgcmVxdWVzdGVkIHRvIG1ha2UgaW5pdGlhbCBhc3NpZ25tZW50cyBhY2Nv cmRpbmcgdG8gVGFibGUgMi4KCiAgICAgICAgICAgICArLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgIHwgVmFsdWUgICAgIHwgICBEZXNj cmlwdGlvbiAgICB8IFJlZmVyZW5jZSAgICAgfAogICAgICAgICAgICAgKy0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICB8IDAgICAgICAg ICB8ICAgICBSZXNlcnZlZCAgICAgfCBUaGlzIGRvY3VtZW50IHwKICAgICAgICAgICAgIHwgMSAg ICAgICAgIHwgUDJNUCBCRkQgU2Vzc2lvbiB8IFRoaXMgZG9jdW1lbnQgfAogICAgICAgICAgICAg fCAyLSAxNzUgICAgfCAgICBVbmFzc2lnbmVkICAgIHwgVGhpcyBkb2N1bWVudCB8CiAgICAgICAg ICAgICB8IDE3NiAtIDI0OSB8ICAgIFVuYXNzaWduZWQgICAgfCBUaGlzIGRvY3VtZW50IHwKICAg ICAgICAgICAgIHwgMjUwIC0gMjU0IHwgRXhwZXJpbWVudGFsIFVzZSB8IFRoaXMgZG9jdW1lbnQg fAogICAgICAgICAgICAgfCAyNTUgICAgICAgfCAgICAgUmVzZXJ2ZWQgICAgIHwgVGhpcyBkb2N1 bWVudCB8CiAgICAgICAgICAgICArLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLSsKCiAgICAgICAgICAgICAgICAgICAgICBUYWJsZSAyOiBCRkQgTW9kZSBTdWIt cmVnaXN0cnkKCgoKCgoKTW9yaW4sIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1heSAxNCwg MjAyMSAgICAgICAgICAgICAgICAgW1BhZ2UgMThdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBN VlBOIEZhc3QgVXBzdHJlYW0gRmFpbG92ZXIgICAgICAgICBOb3ZlbWJlciAyMDIwCgoKNy4zLiAg QkZEIERpc2NyaW1pbmF0b3IgT3B0aW9uYWwgU3ViLVRMViBUeXBlCgogICBJQU5BIGlzIHJlcXVl c3RlZCB0byBjcmVhdGUgYSBuZXcgQkZEIERpc2NyaW1pbmF0b3IgT3B0aW9uYWwgc3ViLVRMVgog ICBUeXBlIHN1Yi1yZWdpc3RyeSBpbiBCb3JkZXIgR2F0ZXdheSBQcm90b2NvbCAoQkdQKS4gIFRo ZSByZWdpc3RyYXRpb24KICAgcG9saWNpZXMsIHBlciBbUkZDODEyNl0sIGZvciB0aGlzIHN1Yi1y ZWdpc3RyeSBhcmUgYWNjb3JkaW5nIHRvCiAgIFRhYmxlIDMuCgogICAgICAgICAgICAgICAgICAr LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAg fCBWYWx1ZSAgICAgfCAgICAgICAgICBQb2xpY3kgICAgICAgICB8CiAgICAgICAgICAgICAgICAg ICstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAg ICB8IDAtIDE3NSAgICB8ICAgICAgIElFVEYgUmV2aWV3ICAgICAgIHwKICAgICAgICAgICAgICAg ICAgfCAxNzYgLSAyNDkgfCBGaXJzdCBDb21lIEZpcnN0IFNlcnZlZCB8CiAgICAgICAgICAgICAg ICAgIHwgMjUwIC0gMjU0IHwgICAgIEV4cGVyaW1lbnRhbCBVc2UgICAgfAogICAgICAgICAgICAg ICAgICB8IDI1NSAgICAgICB8ICAgICAgIElFVEYgUmV2aWV3ICAgICAgIHwKICAgICAgICAgICAg ICAgICAgKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCgogICAgICAgVGFi bGUgMzogQkZEIERpc2NyaW1pbmF0b3IgT3B0aW9uYWwgU3ViLVRMViBUeXBlIFN1Yi1yZWdpc3Ry eQogICAgICAgICAgICAgICAgICAgICAgICAgICBSZWdpc3RyYXRpb24gUG9saWNpZXMKCiAgIElB TkEgaXMgcmVxdWVzdGVkIHRvIG1ha2UgaW5pdGlhbCBhc3NpZ25tZW50cyBhY2NvcmRpbmcgdG8g VGFibGUgNC4KCiAgICAgICAgICAgICArLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgIHwgVmFsdWUgICAgIHwgICBEZXNjcmlwdGlvbiAg ICB8IFJlZmVyZW5jZSAgICAgfAogICAgICAgICAgICAgKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICB8IDAgICAgICAgICB8ICAgICBS ZXNlcnZlZCAgICAgfCBUaGlzIGRvY3VtZW50IHwKICAgICAgICAgICAgIHwgMS0gMTc1ICAgIHwg ICAgVW5hc3NpZ25lZCAgICB8IFRoaXMgZG9jdW1lbnQgfAogICAgICAgICAgICAgfCAxNzYgLSAy NDkgfCAgICBVbmFzc2lnbmVkICAgIHwgVGhpcyBkb2N1bWVudCB8CiAgICAgICAgICAgICB8IDI1 MCAtIDI1NCB8IEV4cGVyaW1lbnRhbCBVc2UgfCBUaGlzIGRvY3VtZW50IHwKICAgICAgICAgICAg IHwgMjU1ICAgICAgIHwgICAgIFJlc2VydmVkICAgICB8IFRoaXMgZG9jdW1lbnQgfAogICAgICAg ICAgICAgKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rCgog ICAgICAgVGFibGUgNDogQkZEIERpc2NyaW1pbmF0b3IgT3B0aW9uYWwgU3ViLVRMViBUeXBlIFN1 Yi1yZWdpc3RyeQoKOC4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCgogICBUaGlzIGRvY3VtZW50 IGRlc2NyaWJlcyBwcm9jZWR1cmVzIGJhc2VkIG9uIFtSRkM2NTEzXSBhbmQgW1JGQzY1MTRdCiAg IGFuZCBoZW5jZSBzaGFyZXMgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHJlc3BlY3RpdmVs eSByZXByZXNlbnRlZAogICBpbiB0aGVzZSBzcGVjaWZpY2F0aW9ucy4KCiAgIFRoaXMgZG9jdW1l bnQgdXNlcyBQMk1QIEJGRCwgYXMgZGVmaW5lZCBpbiBbUkZDODU2Ml0sIHdoaWNoLCBpbiB0dXJu LAogICBpcyBiYXNlZCBvbiBbUkZDNTg4MF0uICBTZWN1cml0eSBjb25zaWRlcmF0aW9ucyByZWxl dmFudCB0byBlYWNoCiAgIHByb3RvY29sIGFyZSBkaXNjdXNzZWQgaW4gdGhlIHJlc3BlY3RpdmUg cHJvdG9jb2wgc3BlY2lmaWNhdGlvbnMuICBBbgogICBpbXBsZW1lbnRhdGlvbiB0aGF0IHN1cHBv cnRzIHRoaXMgc3BlY2lmaWNhdGlvbiBNVVNUIHVzZSBhIG1lY2hhbmlzbQogICB0byBjb250cm9s IHRoZSBtYXhpbXVtIG51bWJlciBvZiBQMk1QIEJGRCBzZXNzaW9ucyB0aGF0IGNhbiBiZSBhY3Rp dmUKICAgYXQgdGhlIHNhbWUgdGltZS4KCgoKCgoKTW9yaW4sIGV0IGFsLiAgICAgICAgICAgICBF eHBpcmVzIE1heSAxNCwgMjAyMSAgICAgICAgICAgICAgICAgW1BhZ2UgMTldCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICBNVlBOIEZhc3QgVXBzdHJlYW0gRmFpbG92ZXIgICAgICAgICBOb3ZlbWJl ciAyMDIwCgoKOS4gIEFja25vd2xlZGdtZW50cwoKICAgVGhlIGF1dGhvcnMgd2FudCB0byB0aGFu ayBHcmVnIFJlYXVtZSwgRXJpYyBSb3NlbiwgSmVmZnJleSBaaGFuZywKICAgTWFydGluIFZpZ291 cmV1eCwgQWRyaWFuIEZhcnJlbCwgYW5kIFpoZW5nIChTYW5keSkgWmhhbmcgZm9yIHRoZWlyCiAg IHJldmlld3MsIHVzZWZ1bCBjb21tZW50cywgYW5kIGhlbHBmdWwgc3VnZ2VzdGlvbnMuCgoxMC4g IENvbnRyaWJ1dG9yIEFkZHJlc3NlcwoKICAgQmVsb3cgaXMgYSBsaXN0IG9mIG90aGVyIGNvbnRy aWJ1dGluZyBhdXRob3JzIGluIGFscGhhYmV0aWNhbCBvcmRlcjoKCiAgICAgIFJhaHVsIEFnZ2Fy d2FsCiAgICAgIEFya3RhbgoKICAgICAgRW1haWw6IHJhZ2dhcndhXzFAeWFob28uY29tCgoKCiAg ICAgIE5laGFsIEJoYXUKICAgICAgQ2lzY28KCiAgICAgIEVtYWlsOiBOQmhhdUBjaXNjby5jb20K CgoKICAgICAgQ2xheXRvbiBIYXNzZW4KICAgICAgQmVsbCBDYW5hZGEKICAgICAgMjk1NSBWaXJ0 dWFsIFdheQogICAgICBWYW5jb3V2ZXIKICAgICAgQ0FOQURBCgogICAgICBFbWFpbDogQ2xheXRv bi5IYXNzZW5AYmVsbC5jYQoKCgogICAgICBXaW0gSGVuZGVyaWNreAogICAgICBOb2tpYQogICAg ICBDb3Blcm5pY3VzbGFhbiA1MAogICAgICBBbnR3ZXJwICAyMDE4CiAgICAgIEJlbGdpdW0KCiAg ICAgIEVtYWlsOiB3aW0uaGVuZGVyaWNreEBub2tpYS5jb20KCgoKICAgICAgUHJhZGVlcCBKYWlu CiAgICAgIE5va2lhCiAgICAgIDcwMSBFIE1pZGRsZWZpZWxkIFJkCiAgICAgIE1vdW50YWluIFZp ZXcsIENBICA5NDA0MwoKCgpNb3JpbiwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDE0 LCAyMDIxICAgICAgICAgICAgICAgICBbUGFnZSAyMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg IE1WUE4gRmFzdCBVcHN0cmVhbSBGYWlsb3ZlciAgICAgICAgIE5vdmVtYmVyIDIwMjAKCgogICAg ICBVU0EKCiAgICAgIEVtYWlsOiBwcmFkZWVwLmphaW5Abm9raWEuY29tCgoKCiAgICAgIEpheWFu dCBLb3RhbHdhcgogICAgICBOb2tpYQogICAgICA3MDEgRSBNaWRkbGVmaWVsZCBSZAogICAgICBN b3VudGFpbiBWaWV3LCBDQSAgOTQwNDMKICAgICAgVVNBCgogICAgICBFbWFpbDogSmF5YW50Lktv dGFsd2FyQG5va2lhLmNvbQoKCiAgICAgIFByYXZlZW4gTXVsZXkKICAgICAgTm9raWEKICAgICAg NzAxIEVhc3QgTWlkZGxlZmllbGQgUmQKICAgICAgTW91bnRhaW4gVmlldywgQ0EgIDk0MDQzCiAg ICAgIFUuUy5BLgoKICAgICAgRW1haWw6IHByYXZlZW4ubXVsZXlAbm9raWEuY29tCgoKCiAgICAg IFJheSAoTGVpKSBRaXUKICAgICAgSnVuaXBlciBOZXR3b3JrcwogICAgICAxMTk0IE5vcnRoIE1h dGhpbGRhIEF2ZS4KICAgICAgU3Vubnl2YWxlLCBDQSAgOTQwODkKICAgICAgVS5TLkEuCgogICAg ICBFbWFpbDogcnFpdUBqdW5pcGVyLm5ldAoKCgogICAgICBZYWtvdiBSZWtodGVyCiAgICAgIEp1 bmlwZXIgTmV0d29ya3MKICAgICAgMTE5NCBOb3J0aCBNYXRoaWxkYSBBdmUuCiAgICAgIFN1bm55 dmFsZSwgQ0EgIDk0MDg5CiAgICAgIFUuUy5BLgoKICAgICAgRW1haWw6IHlha292QGp1bmlwZXIu bmV0CgoKCiAgICAgIEthbndhciBTaW5naAogICAgICBOb2tpYQogICAgICA3MDEgRSBNaWRkbGVm aWVsZCBSZAoKCgpNb3JpbiwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDE0LCAyMDIx ICAgICAgICAgICAgICAgICBbUGFnZSAyMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIE1WUE4g RmFzdCBVcHN0cmVhbSBGYWlsb3ZlciAgICAgICAgIE5vdmVtYmVyIDIwMjAKCgogICAgICBNb3Vu dGFpbiBWaWV3LCBDQSAgOTQwNDMKICAgICAgVVNBCgogICAgICBFbWFpbDoga2Fud2FyLnNpbmdo QG5va2lhLmNvbQoKCgoxMS4gIFJlZmVyZW5jZXMKCjExLjEuICBOb3JtYXRpdmUgUmVmZXJlbmNl cwoKICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3Mg dG8gSW5kaWNhdGUKICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJG QyAyMTE5LAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkMyMTE5LCBNYXJjaCAxOTk3LAog ICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzIxMTk+LgoK ICAgW1JGQzQyNzFdICBSZWtodGVyLCBZLiwgRWQuLCBMaSwgVC4sIEVkLiwgYW5kIFMuIEhhcmVz LCBFZC4sICJBCiAgICAgICAgICAgICAgQm9yZGVyIEdhdGV3YXkgUHJvdG9jb2wgNCAoQkdQLTQp IiwgUkZDIDQyNzEsCiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzQyNzEsIEphbnVhcnkg MjAwNiwKICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM0 MjcxPi4KCiAgIFtSRkM0ODc1XSAgQWdnYXJ3YWwsIFIuLCBFZC4sIFBhcGFkaW1pdHJpb3UsIEQu LCBFZC4sIGFuZCBTLgogICAgICAgICAgICAgIFlhc3VrYXdhLCBFZC4sICJFeHRlbnNpb25zIHRv IFJlc291cmNlIFJlc2VydmF0aW9uCiAgICAgICAgICAgICAgUHJvdG9jb2wgLSBUcmFmZmljIEVu Z2luZWVyaW5nIChSU1ZQLVRFKSBmb3IgUG9pbnQtdG8tCiAgICAgICAgICAgICAgTXVsdGlwb2lu dCBURSBMYWJlbCBTd2l0Y2hlZCBQYXRocyAoTFNQcykiLCBSRkMgNDg3NSwKICAgICAgICAgICAg ICBET0kgMTAuMTc0ODcvUkZDNDg3NSwgTWF5IDIwMDcsCiAgICAgICAgICAgICAgPGh0dHBzOi8v d3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNDg3NT4uCgogICBbUkZDNTg4MF0gIEthdHosIEQu IGFuZCBELiBXYXJkLCAiQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbgogICAgICAg ICAgICAgIChCRkQpIiwgUkZDIDU4ODAsIERPSSAxMC4xNzQ4Ny9SRkM1ODgwLCBKdW5lIDIwMTAs CiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNTg4MD4u CgogICBbUkZDNjUxM10gIFJvc2VuLCBFLiwgRWQuIGFuZCBSLiBBZ2dhcndhbCwgRWQuLCAiTXVs dGljYXN0IGluIE1QTFMvCiAgICAgICAgICAgICAgQkdQIElQIFZQTnMiLCBSRkMgNjUxMywgRE9J IDEwLjE3NDg3L1JGQzY1MTMsIEZlYnJ1YXJ5CiAgICAgICAgICAgICAgMjAxMiwgPGh0dHBzOi8v d3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNjUxMz4uCgogICBbUkZDNjUxNF0gIEFnZ2Fyd2Fs LCBSLiwgUm9zZW4sIEUuLCBNb3JpbiwgVC4sIGFuZCBZLiBSZWtodGVyLCAiQkdQCiAgICAgICAg ICAgICAgRW5jb2RpbmdzIGFuZCBQcm9jZWR1cmVzIGZvciBNdWx0aWNhc3QgaW4gTVBMUy9CR1Ag SVAKICAgICAgICAgICAgICBWUE5zIiwgUkZDIDY1MTQsIERPSSAxMC4xNzQ4Ny9SRkM2NTE0LCBG ZWJydWFyeSAyMDEyLAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9p bmZvL3JmYzY1MTQ+LgoKICAgW1JGQzc2MDZdICBDaGVuLCBFLiwgRWQuLCBTY3VkZGVyLCBKLiwg RWQuLCBNb2hhcGF0cmEsIFAuLCBhbmQgSy4KICAgICAgICAgICAgICBQYXRlbCwgIlJldmlzZWQg RXJyb3IgSGFuZGxpbmcgZm9yIEJHUCBVUERBVEUgTWVzc2FnZXMiLAogICAgICAgICAgICAgIFJG QyA3NjA2LCBET0kgMTAuMTc0ODcvUkZDNzYwNiwgQXVndXN0IDIwMTUsCiAgICAgICAgICAgICAg PGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzYwNj4uCgoKCgoKCk1vcmluLCBl dCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBNYXkgMTQsIDIwMjEgICAgICAgICAgICAgICAgIFtQ YWdlIDIyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgTVZQTiBGYXN0IFVwc3RyZWFtIEZhaWxv dmVyICAgICAgICAgTm92ZW1iZXIgMjAyMAoKCiAgIFtSRkM4MTI2XSAgQ290dG9uLCBNLiwgTGVp YmEsIEIuLCBhbmQgVC4gTmFydGVuLCAiR3VpZGVsaW5lcyBmb3IKICAgICAgICAgICAgICBXcml0 aW5nIGFuIElBTkEgQ29uc2lkZXJhdGlvbnMgU2VjdGlvbiBpbiBSRkNzIiwgQkNQIDI2LAogICAg ICAgICAgICAgIFJGQyA4MTI2LCBET0kgMTAuMTc0ODcvUkZDODEyNiwgSnVuZSAyMDE3LAogICAg ICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzgxMjY+LgoKICAg W1JGQzgxNzRdICBMZWliYSwgQi4sICJBbWJpZ3VpdHkgb2YgVXBwZXJjYXNlIHZzIExvd2VyY2Fz ZSBpbiBSRkMKICAgICAgICAgICAgICAyMTE5IEtleSBXb3JkcyIsIEJDUCAxNCwgUkZDIDgxNzQs IERPSSAxMC4xNzQ4Ny9SRkM4MTc0LAogICAgICAgICAgICAgIE1heSAyMDE3LCA8aHR0cHM6Ly93 d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM4MTc0Pi4KCiAgIFtSRkM4NTYyXSAgS2F0eiwgRC4s IFdhcmQsIEQuLCBQYWxsYWdhdHRpLCBTLiwgRWQuLCBhbmQgRy4gTWlyc2t5LAogICAgICAgICAg ICAgIEVkLiwgIkJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgZm9yCiAg ICAgICAgICAgICAgTXVsdGlwb2ludCBOZXR3b3JrcyIsIFJGQyA4NTYyLCBET0kgMTAuMTc0ODcv UkZDODU2MiwKICAgICAgICAgICAgICBBcHJpbCAyMDE5LCA8aHR0cHM6Ly93d3cucmZjLWVkaXRv ci5vcmcvaW5mby9yZmM4NTYyPi4KCjExLjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBb UkZDNDA5MF0gIFBhbiwgUC4sIEVkLiwgU3dhbGxvdywgRy4sIEVkLiwgYW5kIEEuIEF0bGFzLCBF ZC4sICJGYXN0CiAgICAgICAgICAgICAgUmVyb3V0ZSBFeHRlbnNpb25zIHRvIFJTVlAtVEUgZm9y IExTUCBUdW5uZWxzIiwgUkZDIDQwOTAsCiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzQw OTAsIE1heSAyMDA1LAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9p bmZvL3JmYzQwOTA+LgoKICAgW1JGQzc0MzFdICBLYXJhbiwgQS4sIEZpbHNmaWxzLCBDLiwgV2lq bmFuZHMsIElKLiwgRWQuLCBhbmQgQi4KICAgICAgICAgICAgICBEZWNyYWVuZSwgIk11bHRpY2Fz dC1Pbmx5IEZhc3QgUmVyb3V0ZSIsIFJGQyA3NDMxLAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4 Ny9SRkM3NDMxLCBBdWd1c3QgMjAxNSwKICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVk aXRvci5vcmcvaW5mby9yZmM3NDMxPi4KCkF1dGhvcnMnIEFkZHJlc3NlcwoKICAgVGhvbWFzIE1v cmluIChlZGl0b3IpCiAgIE9yYW5nZQogICAyLCBhdmVudWUgUGllcnJlIE1hcnppbgogICBMYW5u aW9uICAyMjMwNwogICBGcmFuY2UKCiAgIEVtYWlsOiB0aG9tYXMubW9yaW5Ab3JhbmdlLWZ0Z3Jv dXAuY29tCgoKICAgUm9iZXJ0IEtlYmxlciAoZWRpdG9yKQogICBKdW5pcGVyIE5ldHdvcmtzCiAg IDExOTQgTm9ydGggTWF0aGlsZGEgQXZlLgogICBTdW5ueXZhbGUsIENBICA5NDA4OQogICBVLlMu QS4KCiAgIEVtYWlsOiBya2VibGVyQGp1bmlwZXIubmV0CgoKCgoKCgpNb3JpbiwgZXQgYWwuICAg ICAgICAgICAgIEV4cGlyZXMgTWF5IDE0LCAyMDIxICAgICAgICAgICAgICAgICBbUGFnZSAyM10K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgIE1WUE4gRmFzdCBVcHN0cmVhbSBGYWlsb3ZlciAgICAg ICAgIE5vdmVtYmVyIDIwMjAKCgogICBHcmVnIE1pcnNreSAoZWRpdG9yKQogICBaVEUgQ29ycC4K CiAgIEVtYWlsOiBncmVnaW1pcnNreUBnbWFpbC5jb20KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpNb3JpbiwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMg TWF5IDE0LCAyMDIxICAgICAgICAgICAgICAgICBbUGFnZSAyNF0K --000000000000ed8d2405b3cb5875 Content-Type: text/html; charset="UTF-8"; name="Diff_ draft-ietf-bess-mvpn-fast-failover-12.txt - draft-ietf-bess-mvpn-fast-failover-13.txt.html" Content-Disposition: attachment; filename="Diff_ draft-ietf-bess-mvpn-fast-failover-12.txt - draft-ietf-bess-mvpn-fast-failover-13.txt.html" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_khcrrnu91 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPgo8IS0tIHNhdmVkIGZyb20gdXJsPSgwMDQyKWh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9y ZmNkaWZmL3JmY2RpZmYucHlodCAtLT4KPGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5 OTkveGh0bWwiPjxoZWFkPjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PVVURi04Ij4gCiAgIAogIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRl bnQtU3R5bGUtVHlwZSIgY29udGVudD0idGV4dC9jc3MiPiAKICA8dGl0bGU+RGlmZjogZHJhZnQt aWV0Zi1iZXNzLW12cG4tZmFzdC1mYWlsb3Zlci0xMi50eHQgLSBkcmFmdC1pZXRmLWJlc3MtbXZw bi1mYXN0LWZhaWxvdmVyLTEzLnR4dDwvdGl0bGU+IAogIDxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+ IAogICAgYm9keSAgICB7IG1hcmdpbjogMC40ZXg7IG1hcmdpbi1yaWdodDogYXV0bzsgfSAKICAg IHRyICAgICAgeyB9IAogICAgdGQgICAgICB7IHdoaXRlLXNwYWNlOiBwcmU7IGZvbnQtZmFtaWx5 OiBtb25vc3BhY2U7IHZlcnRpY2FsLWFsaWduOiB0b3A7IGZvbnQtc2l6ZTogMC44NmVtO30gCiAg ICB0aCAgICAgIHsgZm9udC1zaXplOiAwLjg2ZW07IH0gCiAgICAuc21hbGwgIHsgZm9udC1zaXpl OiAwLjZlbTsgZm9udC1zdHlsZTogaXRhbGljOyBmb250LWZhbWlseTogVmVyZGFuYSwgSGVsdmV0 aWNhLCBzYW5zLXNlcmlmOyB9IAogICAgLmxlZnQgICB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7 IH0gCiAgICAucmlnaHQgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgfSAKICAgIC5kaWZmICAg eyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NGOyB9IAogICAgLmxibG9jayB7IGJhY2tncm91bmQtY29s b3I6ICNCRkI7IH0gCiAgICAucmJsb2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGODsgfSAKICAg IC5pbnNlcnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOEZGOyB9IAogICAgLmRlbGV0ZSB7IGJhY2tn cm91bmQtY29sb3I6ICNBQ0Y7IH0gCiAgICAudm9pZCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZG QjsgfSAKICAgIC5jb250ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxpbmVi ciB7IGJhY2tncm91bmQtY29sb3I6ICNBQUE7IH0gCiAgICAubGluZW5vIHsgY29sb3I6IHJlZDsg YmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgZm9udC1zaXplOiAwLjdlbTsgdGV4dC1hbGlnbjogcmln aHQ7IHBhZGRpbmc6IDAgMnB4OyB9IAogICAgLmVsaXBzaXN7IGJhY2tncm91bmQtY29sb3I6ICNB QUE7IH0gCiAgICAubGVmdCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICNEREQ7IH0gCiAgICAu cmlnaHQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxibG9jayAuY29u dCB7IGJhY2tncm91bmQtY29sb3I6ICM5RDk7IH0gCiAgICAucmJsb2NrIC5jb250IHsgYmFja2dy b3VuZC1jb2xvcjogI0RENjsgfSAKICAgIC5pbnNlcnQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9y OiAjMEREOyB9IAogICAgLmRlbGV0ZSAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICM4QUQ7IH0g CiAgICAuc3RhdHMsIC5zdGF0cyB0ZCwgLnN0YXRzIHRoIHsgYmFja2dyb3VuZC1jb2xvcjogI0VF RTsgcGFkZGluZzogMnB4IDA7IH0gCiAgICBzcGFuLmhpZGUgeyBkaXNwbGF5OiBub25lOyBjb2xv cjogI2FhYTt9ICAgIGE6aG92ZXIgc3BhbiB7IGRpc3BsYXk6IGlubGluZTsgfSAgICB0ci5jaGFu Z2UgeyBiYWNrZ3JvdW5kLWNvbG9yOiBncmF5OyB9IAogICAgdHIuY2hhbmdlIGEgeyB0ZXh0LWRl Y29yYXRpb246IG5vbmU7IGNvbG9yOiBibGFjayB9IAogIDwvc3R5bGU+IAogICAgIDxzY3JpcHQ+ CnZhciBjaHVua19pbmRleCA9IDA7CnZhciBvbGRfY2h1bmsgPSBudWxsOwoKZnVuY3Rpb24gZm9y bWF0X2NodW5rKGluZGV4KSB7CiAgICB2YXIgcHJlZml4ID0gImRpZmYiOwogICAgdmFyIHN0ciA9 IGluZGV4LnRvU3RyaW5nKCk7CiAgICBmb3IgKHg9MDsgeDwoNC1zdHIubGVuZ3RoKTsgKyt4KSB7 CiAgICAgICAgcHJlZml4Kz0nMCc7CiAgICB9CiAgICByZXR1cm4gcHJlZml4ICsgc3RyOwp9Cgpm dW5jdGlvbiBmaW5kX2NodW5rKG4pewogICAgcmV0dXJuIGRvY3VtZW50LnF1ZXJ5U2VsZWN0b3Io J3RyW2lkJD0iJyArIG4gKyAnIl0nKTsKfQoKZnVuY3Rpb24gY2hhbmdlX2NodW5rKG9mZnNldCkg ewogICAgdmFyIGluZGV4ID0gY2h1bmtfaW5kZXggKyBvZmZzZXQ7CiAgICB2YXIgbmV3X3N0cjsK ICAgIHZhciBuZXdfY2h1bms7CgogICAgbmV3X3N0ciA9IGZvcm1hdF9jaHVuayhpbmRleCk7CiAg ICBuZXdfY2h1bmsgPSBmaW5kX2NodW5rKG5ld19zdHIpOwogICAgaWYgKCFuZXdfY2h1bmspIHsK ICAgICAgICByZXR1cm47CiAgICB9CiAgICBpZiAob2xkX2NodW5rKSB7CiAgICAgICAgb2xkX2No dW5rLnN0eWxlLm91dGxpbmUgPSAiIjsKICAgIH0KICAgIG9sZF9jaHVuayA9IG5ld19jaHVuazsK ICAgIG9sZF9jaHVuay5zdHlsZS5vdXRsaW5lID0gIjFweCBzb2xpZCByZWQiOwogICAgd2luZG93 LmxvY2F0aW9uLmhhc2ggPSAiIyIgKyBuZXdfc3RyOwogICAgd2luZG93LnNjcm9sbEJ5KDAsLTEw MCk7CiAgICBjaHVua19pbmRleCA9IGluZGV4Owp9Cgpkb2N1bWVudC5vbmtleWRvd24gPSBmdW5j dGlvbihlKSB7CiAgICBzd2l0Y2ggKGUua2V5Q29kZSkgewogICAgY2FzZSA3ODoKICAgICAgICBj aGFuZ2VfY2h1bmsoMSk7CiAgICAgICAgYnJlYWs7CiAgICBjYXNlIDgwOgogICAgICAgIGNoYW5n ZV9jaHVuaygtMSk7CiAgICAgICAgYnJlYWs7CiAgICB9Cn07CiAgIDwvc2NyaXB0PiAKPC9oZWFk PiAKPGJvZHkgZGF0YS1uZXctZ3ItYy1zLWNoZWNrLWxvYWRlZD0iMTQuOTgzLjAiPiAKICA8dGFi bGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPiAKICA8dGJvZHk+ PHRyIGlkPSJwYXJ0LTEiIGJnY29sb3I9Im9yYW5nZSI+PHRoPjwvdGg+PHRoPjxhIGhyZWY9Imh0 dHBzOi8vd3d3Ni5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1iZXNzLW12cG4tZmFz dC1mYWlsb3Zlci0xMi50eHQiIHN0eWxlPSJjb2xvcjojMDA4OyB0ZXh0LWRlY29yYXRpb246bm9u ZTsiPiZsdDs8L2E+Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtYmVzcy1tdnBuLWZhc3QtZmFpbG92ZXItMTIudHh0IiBzdHlsZT0iY29sb3I6IzAw OCI+ZHJhZnQtaWV0Zi1iZXNzLW12cG4tZmFzdC1mYWlsb3Zlci0xMi50eHQ8L2E+Jm5ic3A7PC90 aD48dGg+IDwvdGg+PHRoPiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWJlc3MtbXZwbi1mYXN0LWZhaWxvdmVyLTEzLnR4dCIgc3R5bGU9ImNvbG9y OiMwMDgiPmRyYWZ0LWlldGYtYmVzcy1tdnBuLWZhc3QtZmFpbG92ZXItMTMudHh0PC9hPiZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi1i ZXNzLW12cG4tZmFzdC1mYWlsb3Zlci0xMy50eHQiIHN0eWxlPSJjb2xvcjojMDA4OyB0ZXh0LWRl Y29yYXRpb246bm9uZTsiPiZndDs8L2E+PC90aD48dGg+PC90aD48L3RyPiAKICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5OZXR3b3JrIFdvcmtp bmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFQuIE1vcmluLCBF ZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5OZXR3b3JrIFdvcmtpbmcgR3JvdXAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFQuIE1vcmluLCBFZC48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9yYW5nZTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIE9yYW5nZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ SW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAg IFIuIEtlYmxlciwgRWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+SW50ZW5kZWQg c3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgIFIuIEtlYmxl ciwgRWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRp ZmYwMDAxIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPkV4cGlyZXM6IE1heSAxPHNwYW4gY2xhc3M9ImRlbGV0ZSI+LCAy MDIxIDwvc3Bhbj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmlwZXIgTmV0 d29ya3M8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+RXhwaXJlczogTWF5IDE8c3Bh biBjbGFzcz0iaW5zZXJ0Ij40LCAyMDIxPC9zcGFuPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgSnVuaXBlciBOZXR3b3JrczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEcu IE1pcnNreSwgRWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEcuIE1pcnNreSwg RWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBaVEUgQ29ycC48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBaVEUgQ29ycC48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDIiPjx0ZD48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzcGFuIGNs YXNzPSJkZWxldGUiPiBPY3RvYmVyIDI4PC9zcGFuPiwgMjAyMDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPHNwYW4gY2xhc3M9Imluc2VydCI+Tm92ZW1iZXIgMTA8L3NwYW4+LCAyMDIw PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgIE11bHRp Y2FzdCBWUE4gRmFzdCBVcHN0cmVhbSBGYWlsb3ZlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgICAgICAgICAgICAgICAgIE11bHRpY2FzdCBWUE4gRmFzdCBVcHN0cmVhbSBGYWls b3ZlcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZm MDAwMyI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtYmVzcy1tdnBuLWZh c3QtZmFpbG92ZXItMTxzcGFuIGNsYXNzPSJkZWxldGUiPjI8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1iZXNzLW12cG4t ZmFzdC1mYWlsb3Zlci0xPHNwYW4gY2xhc3M9Imluc2VydCI+Mzwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+QWJzdHJhY3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij5BYnN0cmFjdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIGRv Y3VtZW50IGRlZmluZXMgbXVsdGljYXN0IFZQTiBleHRlbnNpb25zIGFuZCBwcm9jZWR1cmVzIHRo YXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGRvY3VtZW50IGRlZmlu ZXMgbXVsdGljYXN0IFZQTiBleHRlbnNpb25zIGFuZCBwcm9jZWR1cmVzIHRoYXQ8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFsbG93IGZhc3QgZmFpbG92ZXIgZm9yIHVwc3RyZWFtIGZh aWx1cmVzIGJ5IGFsbG93aW5nIGRvd25zdHJlYW0gUEVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgYWxsb3cgZmFzdCBmYWlsb3ZlciBmb3IgdXBzdHJlYW0gZmFpbHVyZXMgYnkg YWxsb3dpbmcgZG93bnN0cmVhbSBQRXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRv IGNvbnNpZGVyIHRoZSBzdGF0dXMgb2YgUHJvdmlkZXItVHVubmVscyAoUC10dW5uZWxzKSB3aGVu IHNlbGVjdGluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRvIGNvbnNpZGVy IHRoZSBzdGF0dXMgb2YgUHJvdmlkZXItVHVubmVscyAoUC10dW5uZWxzKSB3aGVuIHNlbGVjdGlu ZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIHVwc3RyZWFtIFBFIGZvciBhIFZQ TiBtdWx0aWNhc3QgZmxvdy4gIFRoZSBmYXN0IGZhaWxvdmVyIGlzPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgdGhlIHVwc3RyZWFtIFBFIGZvciBhIFZQTiBtdWx0aWNhc3QgZmxv dy4gIFRoZSBmYXN0IGZhaWxvdmVyIGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBl bmFibGVkIGJ5IHVzaW5nIFJGQyA4NTYyIEJGRCBmb3IgTXVsdGlwb2ludCBOZXR3b3JrcyBhbmQg dGhlIG5ldyBCR1A8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBlbmFibGVkIGJ5 IHVzaW5nIFJGQyA4NTYyIEJGRCBmb3IgTXVsdGlwb2ludCBOZXR3b3JrcyBhbmQgdGhlIG5ldyBC R1A8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEF0dHJpYnV0ZSAtIEJGRCBEaXNjcmlt aW5hdG9yLiAgQWxzbywgdGhlIGRvY3VtZW50IGludHJvZHVjZXMgYSBuZXc8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBdHRyaWJ1dGUgLSBCRkQgRGlzY3JpbWluYXRvci4gIEFs c28sIHRoZSBkb2N1bWVudCBpbnRyb2R1Y2VzIGEgbmV3PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA0Ij48dGQ+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIEJHUCBDb21t dW5pdHksIFN0YW5kYnkgUEUsIGV4dGVuZGluZyBCR1AgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+TVZQ Tjwvc3Bhbj4gcm91dGluZyBzbyB0aGF0IGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgQkdQIENvbW11bml0eSwgU3RhbmRieSBQRSwgZXh0ZW5kaW5nIEJHUCA8c3BhbiBjbGFz cz0iaW5zZXJ0Ij5NdWx0aWNhc3QgVlBOPC9zcGFuPiByb3V0aW5nIHNvPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgIEMtbXVsdGljYXN0IHJvdXRlIGNhbiBiZSBhZHZlcnRpc2VkIHRv d2FyZCBhIFN0YW5kYnkgVXBzdHJlYW0gUEUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgIHRoYXQgYSBDLW11bHRpY2FzdCByb3V0ZSBjYW4gYmUgYWR2ZXJ0aXNlZCB0b3dhcmQg YSBTdGFuZGJ5IFVwc3RyZWFtPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBQRS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+U3RhdHVzIG9mIFRoaXMgTWVtbzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPlN0YXR1cyBvZiBUaGlzIE1lbW88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3 aXRoIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgSW50ZXJuZXQt RHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGU8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5k IEJDUCA3OS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJuZXQtRHJh ZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtp bmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZzwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBz IG1heSBhbHNvIGRpc3RyaWJ1dGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBU YXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJp YnV0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgd29ya2luZyBkb2N1bWVudHMgYXMg SW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC08L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1E cmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgRHJhZnRzIGlzIGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJh ZnRzL2N1cnJlbnQvLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIERyYWZ0cyBp cyBhdCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBk b2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMg dmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3Ro ZXIgZG9jdW1lbnRzIGF0IGFueTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFu ZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVu dHMgYXQgYW55PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aW1lLiAgSXQgaXMgaW5h cHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVz ZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9n cmVzcy4iPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbWF0ZXJpYWwgb3IgdG8g Y2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA1Ij48dGQ+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gTWF5IDEsIDIwMjEuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2ls bCBleHBpcmUgb24gTWF5IDE8c3BhbiBjbGFzcz0iaW5zZXJ0Ij40PC9zcGFuPiwgMjAyMS48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Q29weXJpZ2h0IE5vdGljZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkNvcHlyaWdodCBOb3RpY2U8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgQ29weXJpZ2h0IChjKSAyMDIwIElFVEYgVHJ1c3QgYW5kIHRoZSBw ZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgQ29weXJpZ2h0IChjKSAyMDIwIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZp ZWQgYXMgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkb2N1bWVudCBhdXRob3Jz LiAgQWxsIHJpZ2h0cyByZXNlcnZlZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBh bmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0 J3MgTGVnYWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFByb3Zpc2lvbnMgUmVsYXRp bmcgdG8gSUVURiBEb2N1bWVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQ cm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAoaHR0cHM6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZm ZWN0IG9uIHRoZSBkYXRlIG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKGh0 dHBzOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0 ZSBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcHVibGljYXRpb24gb2YgdGhpcyBk b2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSBy ZXZpZXcgdGhlc2UgZG9jdW1lbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0ciBpZD0icGFydC0yIiBjbGFzcz0iY2hhbmdlIj48dGQ+PC90ZD48dGg+PHNt YWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3c2Lmll dGYub3JnL3JmY2RpZmYvcmZjZGlmZi5weWh0I3BhcnQtMiI+PGVtPiBwYWdlIDIsIGxpbmUgMjA8 c3BhbiBjbGFzcz0iaGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48 c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dzYu aWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC0yIj48ZW0+IHBhZ2UgMiwgbGluZSAy MTxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PlRhYmxlIG9mIENvbnRlbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+VGFibGUg b2YgQ29udGVudHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMS4gIEludHJv ZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICAzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgMS4gIEludHJvZHVjdGlvbiAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAyLiAgQ29udmVudGlvbnMgdXNlZCBpbiB0aGlzIGRv Y3VtZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDM8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAyLiAgQ29udmVudGlvbnMgdXNlZCBpbiB0aGlzIGRvY3VtZW50IC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgMi4xLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgMzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgMi4x LiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAgMzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAyLjIuICBUZXJtaW5vbG9n eSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAyLjIuICBUZXJtaW5vbG9neSAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgIDIuMy4gIEFjcm9ueW1zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgIDIuMy4gIEFjcm9ueW1zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgIDQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDMuICBV TUggU2VsZWN0aW9uIEJhc2VkIG9uIFR1bm5lbCBTdGF0dXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAgNTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDMuICBVTUggU2VsZWN0 aW9uIEJhc2VkIG9uIFR1bm5lbCBTdGF0dXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAzLjEuICBEZXRlcm1pbmluZyB0aGUgU3Rh dHVzIG9mIGEgVHVubmVsICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAzLjEuICBEZXRlcm1pbmluZyB0aGUgU3RhdHVzIG9mIGEg VHVubmVsICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA2Ij48dGQ+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAzLjEu MS4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPm08L3NwYW4+VlBOIFR1bm5lbCBSb290IFRyYWNraW5n IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDY8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgICAgIDMuMS4xLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+TTwvc3Bhbj5WUE4g VHVubmVsIFJvb3QgVHJhY2tpbmcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIDMuMS4yLiAgUEUtUCBVcHN0cmVhbSBMaW5r IFN0YXR1cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgIDMuMS4yLiAgUEUtUCBVcHN0cmVhbSBMaW5rIFN0YXR1cyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgICAgMy4xLjMuICBQMk1QIFJTVlAtVEUgVHVubmVscyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgIDc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAg My4xLjMuICBQMk1QIFJTVlAtVEUgVHVubmVscyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgIDc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAzLjEuNC4gIExlYWYt aW5pdGlhdGVkIFAtdHVubmVscyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgODwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAzLjEuNC4gIExlYWYtaW5pdGlhdGVk IFAtdHVubmVscyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgODwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgICAgIDMuMS41LiAgKEMtUywgQy1HKSBDb3VudGVyIEluZm9ybWF0 aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgIDMuMS41LiAgKEMtUywgQy1HKSBDb3VudGVyIEluZm9ybWF0aW9uICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gICA4PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAg My4xLjYuICBCRkQgRGlzY3JpbWluYXRvciBBdHRyaWJ1dGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgIDg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgMy4xLjYuICBC RkQgRGlzY3JpbWluYXRvciBBdHRyaWJ1dGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDg8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAzLjEuNy4gIFBlciBQRS1DRSBMaW5r IEJGRCBEaXNjcmltaW5hdG9yICAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAzLjEuNy4gIFBlciBQRS1DRSBMaW5rIEJGRCBEaXNj cmltaW5hdG9yICAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgNC4gIFN0YW5kYnkgQy1tdWx0aWNhc3QgUm91dGUgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDEyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg NC4gIFN0YW5kYnkgQy1tdWx0aWNhc3QgUm91dGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDEyPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDQuMS4gIERvd25z dHJlYW0gUEUgQmVoYXZpb3IgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTM8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDQuMS4gIERvd25zdHJlYW0gUEUg QmVoYXZpb3IgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgNC4yLiAgVXBzdHJlYW0gUEUgQmVoYXZpb3IgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgNC4yLiAgVXBzdHJlYW0gUEUgQmVoYXZpb3IgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICA0LjMuICBSZWFjaGFiaWxpdHkgRGV0ZXJtaW5hdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDE1PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICA0LjMuICBS ZWFjaGFiaWxpdHkgRGV0ZXJtaW5hdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDE1PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0i cGFydC0zIiBjbGFzcz0iY2hhbmdlIj48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNo YW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3c2LmlldGYub3JnL3JmY2RpZmYvcmZj ZGlmZi5weWh0I3BhcnQtMyI+PGVtPiBwYWdlIDMsIGxpbmUgMjc8c3BhbiBjbGFzcz0iaGlkZSI+ IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48c21hbGw+c2tpcHBpbmcgdG8g Y2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dzYuaWV0Zi5vcmcvcmZjZGlmZi9y ZmNkaWZmLnB5aHQjcGFydC0zIj48ZW0+IHBhZ2UgMywgbGluZSAyNzxzcGFuIGNsYXNzPSJoaWRl Ij4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjb25uZWN0ZWQgdG8gYSByZWNl aXZlciBzaXRlKSB0byB0YWtlIGludG8gYWNjb3VudCB0aGUgc3RhdHVzIG9mPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY29ubmVjdGVkIHRvIGEgcmVjZWl2ZXIgc2l0ZSkgdG8g dGFrZSBpbnRvIGFjY291bnQgdGhlIHN0YXR1cyBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgUC10dW5uZWxzIHRvIGRldGVybWluZSB0aGUgVXBzdHJlYW0gTXVsdGljYXN0IEhvcCAo VU1IKSBmb3IgYSBnaXZlbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFAtdHVu bmVscyB0byBkZXRlcm1pbmUgdGhlIFVwc3RyZWFtIE11bHRpY2FzdCBIb3AgKFVNSCkgZm9yIGEg Z2l2ZW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIChDLVMsIEMtRykuICBPbmUgb2Yg dGhlIG9wdGlvbmFsIG1ldGhvZHMgdXNlcyBbUkZDODU2Ml0gYW5kIHRoZSBuZXc8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAoQy1TLCBDLUcpLiAgT25lIG9mIHRoZSBvcHRpb25h bCBtZXRob2RzIHVzZXMgW1JGQzg1NjJdIGFuZCB0aGUgbmV3PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBCR1AgQXR0cmlidXRlIC0gQkZEIERpc2NyaW1pbmF0b3IuICBOb25lIG9mIHRo ZXNlIG1ldGhvZHMgcHJvdmlkZSBhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg QkdQIEF0dHJpYnV0ZSAtIEJGRCBEaXNjcmltaW5hdG9yLiAgTm9uZSBvZiB0aGVzZSBtZXRob2Rz IHByb3ZpZGUgYTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgImZhc3QgZmFpbG92ZXIi IHNvbHV0aW9uIHdoZW4gdXNlZCBhbG9uZSwgYnV0IGNhbiBiZSB1c2VkIHRvZ2V0aGVyPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgImZhc3QgZmFpbG92ZXIiIHNvbHV0aW9uIHdo ZW4gdXNlZCBhbG9uZSwgYnV0IGNhbiBiZSB1c2VkIHRvZ2V0aGVyPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICB3aXRoIHRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluIFNlY3Rpb24gNCBm b3IgYSAiZmFzdCBmYWlsb3ZlciI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB3 aXRoIHRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluIFNlY3Rpb24gNCBmb3IgYSAiZmFzdCBmYWls b3ZlciI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNvbHV0aW9uLjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHNvbHV0aW9uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBTZWN0aW9uIDQgZGVzY3JpYmVzIGFuIG9wdGlvbmFsIEJHUCBleHRlbnNp b24sIGEgbmV3IFN0YW5kYnkgUEU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBT ZWN0aW9uIDQgZGVzY3JpYmVzIGFuIG9wdGlvbmFsIEJHUCBleHRlbnNpb24sIGEgbmV3IFN0YW5k YnkgUEU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIENvbW11bml0eS4gdGhhdCBjYW4g c3BlZWQgdXAgZmFpbG92ZXIgYnkgbm90IHJlcXVpcmluZyBhbnkgbXVsdGljYXN0PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQ29tbXVuaXR5LiB0aGF0IGNhbiBzcGVlZCB1cCBm YWlsb3ZlciBieSBub3QgcmVxdWlyaW5nIGFueSBtdWx0aWNhc3Q8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDciPjx0ZD48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgVlBO IHJvdXRpbmcgbWVzc2FnZSBleGNoYW5nZSBhdCByZWNvdmVyeSB0aW1lLjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICBWUE4gPHNwYW4gY2xhc3M9Imluc2VydCI+KE1WUE4pIDwv c3Bhbj5yb3V0aW5nIG1lc3NhZ2UgZXhjaGFuZ2UgYXQgcmVjb3ZlcnkgdGltZS48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgU2VjdGlvbiA1IGRlc2NyaWJlcyBhICJob3QgbGVh ZiBzdGFuZGJ5IiBtZWNoYW5pc20gdGhhdCBjYW4gYmUgdXNlZDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIFNlY3Rpb24gNSBkZXNjcmliZXMgYSAiaG90IGxlYWYgc3RhbmRieSIg bWVjaGFuaXNtIHRoYXQgY2FuIGJlIHVzZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IHRvIGltcHJvdmUgZmFpbG92ZXIgdGltZSBpbiBNVlBOLiAgVGhlIGFwcHJvYWNoIGNvbWJpbmVz IG1lY2hhbmlzbXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0byBpbXByb3Zl IGZhaWxvdmVyIHRpbWUgaW4gTVZQTi4gIFRoZSBhcHByb2FjaCBjb21iaW5lcyBtZWNoYW5pc21z PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkZWZpbmVkIGluIFNlY3Rpb24gMyBhbmQg U2VjdGlvbiA0IGhhcyBzaW1pbGFyaXRpZXMgd2l0aCB0aGUgc29sdXRpb248L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkZWZpbmVkIGluIFNlY3Rpb24gMyBhbmQgU2VjdGlvbiA0 IGhhcyBzaW1pbGFyaXRpZXMgd2l0aCB0aGUgc29sdXRpb248L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIGRlc2NyaWJlZCBpbiBbUkZDNzQzMV0gdG8gaW1wcm92ZSBmYWlsb3ZlciB0aW1l cyB3aGVuIFBJTSByb3V0aW5nIGlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ZGVzY3JpYmVkIGluIFtSRkM3NDMxXSB0byBpbXByb3ZlIGZhaWxvdmVyIHRpbWVzIHdoZW4gUElN IHJvdXRpbmcgaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHVzZWQgaW4gYSBuZXR3 b3JrIGdpdmVuIHNvbWUgdG9wb2xvZ3kgYW5kIG1ldHJpYyBjb25zdHJhaW50cy48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB1c2VkIGluIGEgbmV0d29yayBnaXZlbiBzb21lIHRv cG9sb2d5IGFuZCBtZXRyaWMgY29uc3RyYWludHMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIFRoZSBwcm9jZWR1cmVzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGFyZSBv cHRpb25hbCB0byBlbmFibGUgYW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBU aGUgcHJvY2VkdXJlcyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBhcmUgb3B0aW9uYWwgdG8g ZW5hYmxlIGFuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvcGVyYXRvciB0byBwcm92 aWRlIHByb3RlY3Rpb24gZm9yIG11bHRpY2FzdCBzZXJ2aWNlcyBpbiBCR1AvTVBMUyBJUDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9wZXJhdG9yIHRvIHByb3ZpZGUgcHJvdGVj dGlvbiBmb3IgbXVsdGljYXN0IHNlcnZpY2VzIGluIEJHUC9NUExTIElQPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBWUE5zLiAgQW4gb3BlcmF0b3Igd291bGQgZW5hYmxlIHRoZXNlIG1l Y2hhbmlzbXMgdXNpbmcgYSBtZXRob2Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBWUE5zLiAgQW4gb3BlcmF0b3Igd291bGQgZW5hYmxlIHRoZXNlIG1lY2hhbmlzbXMgdXNpbmcg YSBtZXRob2Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy IGlkPSJwYXJ0LTQiIGNsYXNzPSJjaGFuZ2UiPjx0ZD48L3RkPjx0aD48c21hbGw+c2tpcHBpbmcg dG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dzYuaWV0Zi5vcmcvcmZjZGlm Zi9yZmNkaWZmLnB5aHQjcGFydC00Ij48ZW0+IHBhZ2UgNiwgbGluZSA0NjxzcGFuIGNsYXNzPSJo aWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGlu ZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9yZmNk aWZmL3JmY2RpZmYucHlodCNwYXJ0LTQiPjxlbT4gcGFnZSA2LCBsaW5lIDQ2PHNwYW4gY2xhc3M9 ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIERlcGVuZGluZyBvbiB0 aGUgY3JpdGVyaWEgdXNlZCB0byBkZXRlcm1pbmUgdGhlIHN0YXR1cyBvZiBhIFAtdHVubmVsLDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIERlcGVuZGluZyBvbiB0aGUgY3JpdGVy aWEgdXNlZCB0byBkZXRlcm1pbmUgdGhlIHN0YXR1cyBvZiBhIFAtdHVubmVsLDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlcmUgbWF5IGJlIGFuIGludGVyYWN0aW9uIHdpdGggYW5v dGhlciByZXNpbGllbmN5IG1lY2hhbmlzbSB1c2VkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgdGhlcmUgbWF5IGJlIGFuIGludGVyYWN0aW9uIHdpdGggYW5vdGhlciByZXNpbGll bmN5IG1lY2hhbmlzbSB1c2VkPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBmb3IgdGhl IFAtdHVubmVsIGl0c2VsZiwgYW5kIHRoZSBVTUggdXBkYXRlIG1heSBoYXBwZW4gaW1tZWRpYXRl bHkgb3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBmb3IgdGhlIFAtdHVubmVs IGl0c2VsZiwgYW5kIHRoZSBVTUggdXBkYXRlIG1heSBoYXBwZW4gaW1tZWRpYXRlbHkgb3I8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG1heSBuZWVkIHRvIGJlIGRlbGF5ZWQuICBFYWNo IHBhcnRpY3VsYXIgY2FzZSBpcyBjb3ZlcmVkIGluIGVhY2g8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBtYXkgbmVlZCB0byBiZSBkZWxheWVkLiAgRWFjaCBwYXJ0aWN1bGFyIGNh c2UgaXMgY292ZXJlZCBpbiBlYWNoPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzZXBh cmF0ZSBzdWItc2VjdGlvbiBiZWxvdy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBzZXBhcmF0ZSBzdWItc2VjdGlvbiBiZWxvdy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgQW4gaW1wbGVtZW50YXRpb24gbWF5IHN1cHBvcnQgYW55IGNvbWJpbmF0aW9uIG9m IHRoZSBtZXRob2RzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQW4gaW1wbGVt ZW50YXRpb24gbWF5IHN1cHBvcnQgYW55IGNvbWJpbmF0aW9uIG9mIHRoZSBtZXRob2RzPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkZXNjcmliZWQgaW4gdGhpcyBzZWN0aW9uIGFuZCBw cm92aWRlIGEgbmV0d29yayBvcGVyYXRvciB3aXRoIGNvbnRyb2w8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBkZXNjcmliZWQgaW4gdGhpcyBzZWN0aW9uIGFuZCBwcm92aWRlIGEg bmV0d29yayBvcGVyYXRvciB3aXRoIGNvbnRyb2w8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIHRvIGNob29zZSB3aGljaCBvbmUgdG8gdXNlIGluIHRoZSBwYXJ0aWN1bGFyIGRlcGxveW1l bnQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdG8gY2hvb3NlIHdoaWNoIG9u ZSB0byB1c2UgaW4gdGhlIHBhcnRpY3VsYXIgZGVwbG95bWVudC48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwOCI+PHRkPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4z LjEuMS4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPm08L3NwYW4+VlBOIFR1bm5lbCBSb290IFRyYWNr aW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjMuMS4xLiAgPHNwYW4gY2xhc3M9 Imluc2VydCI+TTwvc3Bhbj5WUE4gVHVubmVsIFJvb3QgVHJhY2tpbmc8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgQSBjb25kaXRpb24gdG8gY29uc2lkZXIgdGhhdCB0aGUgc3Rh dHVzIG9mIGEgUC10dW5uZWwgaXMgVXAgaXMgdGhhdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIEEgY29uZGl0aW9uIHRvIGNvbnNpZGVyIHRoYXQgdGhlIHN0YXR1cyBvZiBhIFAt dHVubmVsIGlzIFVwIGlzIHRoYXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoZSBy b290IG9mIHRoZSB0dW5uZWwsIGFzIGRldGVybWluZWQgaW4gdGhlIHgtUE1TSSBUdW5uZWwgYXR0 cmlidXRlLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZSByb290IG9mIHRo ZSB0dW5uZWwsIGFzIGRldGVybWluZWQgaW4gdGhlIHgtUE1TSSBUdW5uZWwgYXR0cmlidXRlLDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaXMgcmVhY2hhYmxlIHRocm91Z2ggdW5pY2Fz dCByb3V0aW5nIHRhYmxlcy4gIEluIHRoaXMgY2FzZSwgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgaXMgcmVhY2hhYmxlIHRocm91Z2ggdW5pY2FzdCByb3V0aW5nIHRhYmxl cy4gIEluIHRoaXMgY2FzZSwgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkb3du c3RyZWFtIFBFIGNhbiBpbW1lZGlhdGVseSB1cGRhdGUgaXRzIFVNSCB3aGVuIHRoZSByZWFjaGFi aWxpdHk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkb3duc3RyZWFtIFBFIGNh biBpbW1lZGlhdGVseSB1cGRhdGUgaXRzIFVNSCB3aGVuIHRoZSByZWFjaGFiaWxpdHk8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNvbmRpdGlvbiBjaGFuZ2VzLjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNvbmRpdGlvbiBjaGFuZ2VzLjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGF0IGlzIHNpbWlsYXIgdG8gQkdQIG5leHQtaG9wIHRyYWNr aW5nIGZvciBWUE4gcm91dGVzLCBleGNlcHQgdGhhdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIFRoYXQgaXMgc2ltaWxhciB0byBCR1AgbmV4dC1ob3AgdHJhY2tpbmcgZm9yIFZQ TiByb3V0ZXMsIGV4Y2VwdCB0aGF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGUg YWRkcmVzcyBjb25zaWRlcmVkIGlzIG5vdCB0aGUgQkdQIG5leHQtaG9wIGFkZHJlc3MsIGJ1dCB0 aGUgcm9vdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZSBhZGRyZXNzIGNv bnNpZGVyZWQgaXMgbm90IHRoZSBCR1AgbmV4dC1ob3AgYWRkcmVzcywgYnV0IHRoZSByb290PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhZGRyZXNzIGluIHRoZSB4LVBNU0kgVHVubmVs IGF0dHJpYnV0ZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhZGRyZXNzIGlu IHRoZSB4LVBNU0kgVHVubmVsIGF0dHJpYnV0ZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CgogICAgIDx0cj48dGQ+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkPjwvdGQ+PC90cj4KICAgICA8dHIgaWQ9ImVuZCIg Ymdjb2xvcj0iZ3JheSI+PHRoIGNvbHNwYW49IjUiIGFsaWduPSJjZW50ZXIiPiZuYnNwO0VuZCBv ZiBjaGFuZ2VzLiA4IGNoYW5nZSBibG9ja3MuJm5ic3A7PC90aD48L3RyPgogICAgIDx0ciBjbGFz cz0ic3RhdHMiPjx0ZD48L3RkPjx0aD48aT45IGxpbmVzIGNoYW5nZWQgb3IgZGVsZXRlZDwvaT48 L3RoPjx0aD48aT4gPC9pPjwvdGg+PHRoPjxpPjEwIGxpbmVzIGNoYW5nZWQgb3IgYWRkZWQ8L2k+ PC90aD48dGQ+PC90ZD48L3RyPgogICAgIDx0cj48dGQgY29sc3Bhbj0iNSIgYWxpZ249ImNlbnRl ciIgY2xhc3M9InNtYWxsIj48YnI+VGhpcyBodG1sIGRpZmYgd2FzIHByb2R1Y2VkIGJ5IHJmY2Rp ZmYgMS40OC4gVGhlIGxhdGVzdCB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBmcm9tIDxhIGhyZWY9Imh0 dHA6Ly93d3cudG9vbHMuaWV0Zi5vcmcvdG9vbHMvcmZjZGlmZi8iPmh0dHA6Ly90b29scy5pZXRm Lm9yZy90b29scy9yZmNkaWZmLzwvYT4gPC90ZD48L3RyPgogICA8L3Rib2R5PjwvdGFibGU+CiAg IAogICAKPC9ib2R5PjwvaHRtbD4= --000000000000ed8d2405b3cb5875-- From nobody Wed Nov 11 08:48:33 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFC33A11F7; Wed, 11 Nov 2020 08:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZav8pfwRdwS; Wed, 11 Nov 2020 08:48:19 -0800 (PST) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2046.outbound.protection.outlook.com [40.107.244.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39EEE3A1158; Wed, 11 Nov 2020 08:48:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F2KqBTZJ8eLmGlC+WCsnJIsjWNzjncXII8+SJaUR9nxhcYFctmC2NFZVpsu8PeIwV6tOqF3BWTZjncMgPxF0dOa2/P3pYAwlbMWXbFcHnfDj4NoQKrB++QEErLbk5fUqdtxcih6opBXhvx/BysEHLcA/JwhhU0uQcvVZiGho5KpFbpB9a2lkTwIW4bgyteooYHdmYuiz1SAMBcv/xLmQ6b/5gQNxqSYXagHFsrDhWiDO8gy1CtWo6sRDZCD7KWfboNhfQbkRtyKPeC76P14gjSh8i4zzwFMzbSDHCWt5ktvCiCJzg0ncEZPOx9KA77KgxObCMGv9sf5DyOfZQs5+Jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DCN2lDS8qB2lh3VNbj30+tVFuHiZo+Ewf7i0U8ZjCSg=; b=jrjHOqeH9+ByGkH6xDLXQ2jKAPovYKL6aOuRX8pDfrcpGHAQG+l0BAXBzXE87cyeSI702EiYPn5LkGB3W6/t/TAQyrFSbltV/0Gwyx0utDNCVyoECdysZ4/rxprgGe1x/3c3AeH8ZFVPMVvDUKIXcV5G1AsrB/89E4vUazGaG54WupeyW5axLigQN4I2Oz4i0wF27f/DfhF1ljE+NuUjJ7r5XXiwhqzSDlKBoyqw8regKwhZ/B2uN38eWBOy6UHZcTr3qi7okOvbITTTvr6npltA85YAr+boI5N0K99ym0qXuvO/eGFjnGaspjddFxBlVgfTikmnLGF9Z242K/D5aA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DCN2lDS8qB2lh3VNbj30+tVFuHiZo+Ewf7i0U8ZjCSg=; b=nlWgTQqH8UTiVCYfsGiWVvdIYVUvW+lFVSG3wc2J6eVClIUKIfydtZQa21g84QBagZPHTFpVRBXbN4D9vyVmIBfmnal+glTOwJ935rezz4Gq6WdgUMFKNwvOxCGP7xiN+Co5UcJVyTRVmBJo3MSxMa77tW8bN2cIVnnndk/58sg= Received: from DM6PR15MB2379.namprd15.prod.outlook.com (2603:10b6:5:8a::16) by DM6PR15MB2827.namprd15.prod.outlook.com (2603:10b6:5:1ac::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.23; Wed, 11 Nov 2020 16:48:15 +0000 Received: from DM6PR15MB2379.namprd15.prod.outlook.com ([fe80::28b4:8429:419b:15b0]) by DM6PR15MB2379.namprd15.prod.outlook.com ([fe80::28b4:8429:419b:15b0%3]) with mapi id 15.20.3541.025; Wed, 11 Nov 2020 16:48:15 +0000 From: Daniel Migault To: Greg Mirsky CC: "secdir@ietf.org" , BESS , "last-call@ietf.org" , "draft-ietf-bess-mvpn-fast-failover.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-bess-mvpn-fast-failover-11 Thread-Index: AQHWt9C5emGUONFgKUKxrX3Gy2SfzqnDA2lu Date: Wed, 11 Nov 2020 16:48:15 +0000 Message-ID: References: <160345656094.22100.7057001737682109381@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [96.22.11.129] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5ff40e05-20aa-4775-d3a7-08d8866195e8 x-ms-traffictypediagnostic: DM6PR15MB2827: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oos6S0BeYtPSzZjzUi10NxPAcmqjcb20Krk4QKHDGIYAfPE4Tr7VxEfdLox1cbH34pascEbTKtq+KsJBISvdYZmnttIeN7XDkwDReAZ3rp1nSt/MHEhnumTKPaXZ+M5GVM3vTr7scT+4lrYwTCqlwCmSvb7Lhi3MUcINdHdZs7LPzPlB4F4XuA3oGb4YXF52lQFSJgqvTkP5jLA9mDF7seppuuMtRpW7zYVW8VbF12B5H9WLpXd6ruIALoRnNSROYhb4wWUmDi/srpDW/NoL4VIstPO5ouL3eakXVHn29NB6G6hBGi4OmxLNaLAaQ1vLmalaYQWKb4GdliRw1/PCOh8by74eRsK7DdVBG7O/FI9YUB5FZxlrvkNIVhu5/TK1 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR15MB2379.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(376002)(39860400002)(136003)(396003)(83380400001)(316002)(9686003)(33656002)(6916009)(66574015)(6506007)(53546011)(54906003)(44832011)(4326008)(55016002)(52536014)(71200400001)(7696005)(5660300002)(26005)(86362001)(186003)(91956017)(30864003)(76116006)(19627405001)(66446008)(8676002)(478600001)(2906002)(8936002)(64756008)(66476007)(66946007)(66556008)(21314003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: PHJnaGda/yJjBWW8Cd1VfgIMtV4mPCEfpRlV2Xw6WzjS80igwEe+uF8Tg2npsRSgzzAkIkhwttlLXhNaAZMKoOTbAf+MilgwXlDzFGhN3SvJHQ6BocqIchReZYNn7gymh+maIZxf9nkfqq4L12cZ2y1k2uiPQCSNpW3wGv6RANCT/sZvY4aRwLqE/5SyrhQ94Os3Cn8UMal1b5bSsjthlN9Oc9wlmGKstzUwe+NOrlbDp0JoDcrAXRkJCgii8i1mlvX6p7dqd9XSQvZeTK/2/IAb4CVNeMgB+nf3UzkluPlDG4CH3DWVdIflT8TCGqqPSFz0ULrc2CqOgZAYU+7ipRVaR82+DzmUhr247oYrTWGvctfsScyiis4rAjp0s64InjuYIjktZlP5nurviCHXC2tTEvTAqIoIYnhC73vsmycvjlhaiYYYA6Vcm19MGMBVJ3An8+AMYTelw9otzfmJ3QqUb1ttmbR4wfKPn5D0wc/cxMcBkHZhvFCoeLaqjC2ixjFyBBMIBVoWjCKy+Kk1FvTXgCVeBwu7tiHxGEXsC48jYjFvrpwU48ySsIhKsPvr7CY9EFZZ1YVpWmFIzZghmNTZl2ofcol4aeGKE2kTTzns0bO//eONNsyr2k1WKoKSm5k3Ozb75WLbOfEfOcw9Rw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR15MB237965003540C4F0679A45DEE3E80DM6PR15MB2379namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR15MB2379.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5ff40e05-20aa-4775-d3a7-08d8866195e8 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2020 16:48:15.6979 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: I4p28V7rHkr/LrnqlL/j1qRUVoUvswvFNs7Z8hfik1w+tJehoDccx0l1WyXEEZMNoz3jseGX4E3gee3BzqJSOBYqH4Bnp30QF4KLfvfi/04= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB2827 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-bess-mvpn-fast-failover-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:48:27 -0000 --_000_DM6PR15MB237965003540C4F0679A45DEE3E80DM6PR15MB2379namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Greg, Thanks for the response and clarifications. Most of my comments have been a= ddressed/answered. However, it seems to me that some additional text might = be added to the security consideration section document the impact on the n= etwork of a fast-failover operation. The knowledge of these impact might be= useful for an operator to determine when the trigger can be done. Please see more comments inline. Yours, Daniel ________________________________ From: Greg Mirsky Sent: Tuesday, November 10, 2020 9:13 PM To: Daniel Migault Cc: secdir@ietf.org ; BESS ; last-call@ietf= .org ; draft-ietf-bess-mvpn-fast-failover.all@ietf.org = Subject: Re: Secdir last call review of draft-ietf-bess-mvpn-fast-failover-= 11 Hi Daniel, many thanks for the review, thoughtful comments, and questions, all are muc= h appreciated. Also, my apologies for the long delay to respond to your com= ments. Please find my answers and notes in-line below tagged by GIM>>. Atta= ched are the new working version and the diff to -12. Regards, Greg On Fri, Oct 23, 2020 at 5:36 AM Daniel Migault via Datatracker > wrote: Reviewer: Daniel Migault Review result: Has Nits Hi, I reviewed this document as part of the Security Directorate's ongoing effo= rt to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors, document editors, and WG chairs should treat these comments just l= ike any other IETF Last Call comments. Please note also that my expertise in B= GP is limited, so feel free to take these comments with a pitch of salt. Review Results: Has Nits Please find my comments below. Yours, Daniel Multicast VPN Fast Upstream Failover draft-ietf-bess-mvpn-fast-failover-11 Abstract This document defines multicast VPN extensions and procedures that allow fast failover for upstream failures, by allowing downstream PEs to take into account the status of Provider-Tunnels (P-tunnels) when selecting the Upstream PE for a VPN multicast flow, and extending BGP MVPN routing so that a C-multicast route can be advertised toward a Standby Upstream PE. Though it might be just a nit, if MVPN designates multicast VPN, it might be clarifying to specify the acronym in the first sentence. This would later make the correlation with BGP MVPN clearer. GIM>> I've updated s/BGP MVPN/BGP multicast VPN/. Also, s/mVPN/MVPN/ throug= hout the document. 1. Introduction In the context of multicast in BGP/MPLS VPNs, it is desirable to provide mechanisms allowing fast recovery of connectivity on different types of failures. This document addresses failures of elements in the provider network that are upstream of PEs connected to VPN sites with receivers. Well I am not familiar with neither BGP nor MPLS. It seems that BGP/MLPS IP VPNS and MPLS/BGP IP VPNs are both used. I am wondering if there is a distinction between the two and a preferred way to designate these VPNs. My understanding is that the VPN-IPv4 characterizes the VPN while MPLS is used by the backbone for the transport. Since the PE are connected to the backbone the VPN-IPv4 needs to be labeled. GIM>> I understand that this document often sends the reader to check RFC 6= 513 and/or RFC 6514. BGP/MPLS MVPN identifies the case of providing a multi= cast service over an IP VPN that is overlayed on the MPLS data plane using = the BGP control plane. Section 3 describes local procedures allowing an egress PE (a PE connected to a receiver site) to take into account the status of P-tunnels to determine the Upstream Multicast Hop (UMH) for a given (C-S, C-G). This method does not provide a "fast failover" solution I understand the limitation is due to BGP convergence. GIM>> Yes, a dynamic routing protocol, BGP in this case, provides the servi= ce restoration functionality but the restoration time is significant and af= fects the experience of a client. when used alone, but can be used together with the mechanism described in Section 4 for a "fast failover" solution. Section 4 describes protocol extensions that can speed up failover by not requiring any multicast VPN routing message exchange at recovery time. Moreover, section 5 describes a "hot leaf standby" mechanism, that uses a combination of these two mechanisms. This approach has similarities with the solution described in [RFC7431] to improve failover times when PIM routing is used in a network given some topology and metric constraints. [...] 3.1.1. mVPN Tunnel Root Tracking A condition to consider that the status of a P-tunnel is up is that the root of the tunnel, as determined in the x-PMSI Tunnel attribute, is reachable through unicast routing tables. In this case, the downstream PE can immediately update its UMH when the reachability condition changes. That is similar to BGP next-hop tracking for VPN routes, except that the address considered is not the BGP next-hop address, but the root address in the x-PMSI Tunnel attribute. If BGP next-hop tracking is done for VPN routes and the root address of a given tunnel happens to be the same as the next-hop address in the BGP A-D Route advertising the tunnel, then checking, in unicast routing tables, whether the tunnel root is reachable, will be unnecessary duplication and thus will not bring any specific benefit. It seems to me that x-PMSI address designates a different interface than the one used by the Tunnel itself. If that is correct, such mechanisms seems to assume that one equipment up on one interface will be up on the other interfaces. I have the impression that a configuration change in a PE may end up in the P-tunnel being down, while the PE still being reachable though the x-PMSI Tunnel attribute. If that is a possible scenario, the current mechanisms may not provide more efficient mechanism than then those of the standard BGP. GIM>> That is a very interesting angle, thank you. Yes, in OAM, and in the = Fault Management (FM) OAM in particular, we have to make some assumptions a= bout the state of the remote system based on a single event or change of st= ate. Usually, AFAIK, operators use not a physical interface but a loopback = to associate with a tunnel. With a fast IGP convergence, a loopback interfa= ce is reachable as long as there's a path through the network between two n= odes. Thanks for the clarification Similarly, it is assumed the tunnel is either up or down and the determination of not being up if being down. I am not convinced that the two only states. Typically services under DDoS may be down for a small amount of time. While this affects the network, there is not always a clear cut between the PE being up or down. GIM>> In defect detection a system often has some hysteresis, i.e., time t= hat the system has to wait to change its state. For example, BFD changes st= ate from Up to Down after the system does not receive N consecutive packets= (usually 3). As a result, in some cases, the system can be tuned to detect= relatively short outages while in others be slower and miss short-lived ou= tages. [...] 3.1.6. BFD Discriminator Attribute P-tunnel status may be derived from the status of a multipoint BFD session [RFC8562] whose discriminator is advertised along with an x-PMSI A-D Route. This document defines the format and ways of using a new BGP attribute called the "BFD Discriminator". It is an optional transitive BGP attribute. In Section 7.2, IANA is requested to allocate the codepoint value (TBA2). The format of this attribute is shown in Figure 1. I feel that the sentence "In Section ... TBA2)." should be removed. GIM>> We use this to mark where to note the allocated value. Usually, this = text is replaced by the RFC Editor to read In Section 7.2 IANA allocated codepoint XXX. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFD Mode | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFD Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Optional TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Format of the BFD Discriminator Attribute Where: BFD Mode field is the one octet long. This specification defines the P2MP BFD Session as value 1 Section 7.2. Reserved field is three octets long, and the value MUST be zeroed on transmission and ignored on receipt. BFD Discriminator field is four octets long. Morin, et al. Expires April 5, 2021 [Page 7] Internet-Draft mVPN Fast Upstream Failover October 2020 Optional TLVs is the optional variable-length field that MAY be used in the BFD Discriminator attribute for future extensions. TLVs MAY be included in a sequential or nested manner. To allow for TLV nesting, it is advised to define a new TLV as a variable- length object. Figure 2 presents the Optional TLV format TLV that consists of: * one octet-long field of TLV 's Type value (Section 7.3) * one octet-long field of the length of the Value field in octets * variable length Value field. The length of a TLV MUST be multiple of four octets. I am wondering why the constraint on the length is not mentioned in the paragraph associated to the field - as opposed to a separate paragraph. GIM>> There might be a slight confusion due to the use of Length and length= . Capitalized - the name of the field which value is the length of the Valu= e field. The last sentence refers to the overall length of a TLV, including= lengths of Type, Length and Value fields. you are correct that might have confused me. [..] 8. Security Considerations This document describes procedures based on [RFC6513] and [RFC6514] and hence shares the security considerations respectively represented in these specifications. This document uses p2mp BFD, as defined in [RFC8562], which, in turn, is based on [RFC5880]. Security considerations relevant to each protocol are discussed in the respective protocol specifications. An implementation that supports this specification MUST use a mechanism to control the maximum number of p2mp BFD sessions that can be active at the same time. At a high level view - or at least my interpretation of it - the document proposes a mechanism based on BFD to detect fault in the path. Upon a fault detection a fail-over operation is instructed using BGP. This rocedure is expected to perform a faster fail-over than traditional BGP convergence on maintaining routing tables. Once the fail over has been performed, BFD is confirms the new path is "legitimate" and works. It seems correct to me that the current protocol relies on BGP / BFD security. That said, having BFD authentication based on MD5 or SHA1 may suggest that stronger primitives be recommended. While this does not concerns the current document, it seems to me that the information might be relayed to routing ADs. What remains unclear to me - and I assume this might be due to my lake or expertise in routing area - is the impact associated to performing a fail-over both on 1) the data plane and 2) the standard BGP way to establish routing tables. Regarding the data plane, I am wondering if fail-over results in a lost of packets for example - I suppose for example that at least the packets in the process of being forwarded might be lost. I believe that providing details on this may be good. GIM>> You bring up a very topic for the discussion, thank you. With network= failure detection in place, the fail-over can be viewed as the reaction to= a network failure. If that is the case, then packet loss experienced by s= ervice due to the fail-over is the result of the network failure. Would you= agree with that view? A shorter failure detection interval and faster fail= -over should minimize the packet loss and, as a result, the negative impact= on the service itself. sure. If you know the network is down, then fast fail-over is definitively = a plus. What I think could be useful is to evaluate the cost associated to = a fast-fail-over without any network failure. This would be useful for an = operator to evaluate whether it should spend more time in diagnosing a netw= ork failure versus performing a fast-fail-over. Typically, if a fast failover comes a no cost at all, one operator would ma= ybe use one exchange to test the liveness of a node rather than 3. At that point, it seems to me that additional text coudl be added to charac= terize the impact. These could be high level and indicative, but it seems t= o me that knowing these impacts presents some value to the operators. If there are any impacts I would like to understand also in which cases the decision to perform a failover operation may result in more harm than the event that has been over-interpreted. An hypothetical scenario could be that the non reception of a BFD packet is interpreted as a PE being down while it may not be correct and the PE might have been simply under stress. A "too fast" fail-over may over interpreted it and perform a fail-over. If such things could happen, an attacker could leverage a micro event to perform network operation that are not negligible. Another way to see that is that an attacker might not have direct access to the control plan, but could use the data plan to generate a stress and sort of control the fail over. It seems to me that some text might be welcome to prevent such cases to happen. This could be guidance for declaring a tunnel down for example. GIM>> I agree with your scenario. Over-short detection interval may produce= a false-negative transition to the Down state in BFD and thus triggering t= he fail-over. I think that that is more an operational issue, something tha= t an operator will consider when deploying the mechanism specified in this = draft. Resulting from addressing RtgDir review the draft was updated to pro= vide more guidance: In many cases, it is not practical to use both protection methods at the same time because uncorrelated timers might cause unnecessary switchovers and destabilize the network. Thanks for the feed back, It seems to me important to mention it is not rec= ommended these two mechanism co-exist. How to avoid false negative transition might be out of scope of the draft I= agree, but it seems to me worth being mentioned especially in relation to = the impacts associated to a fail-over. In case the fast-failover comes wit= h no impact this becomes less of a problem for operator deploying it. Though the text above might not be general, I think that it also applies to= the scenario you've presented. Similarly, it would be good to add some text regarding the interferences with the non-fast forwarding fail over when performed by the standard BGP. Typically, my impression is that the fast fail-over mechanism is a local decision versus the BGP convergence that is more global. As a result, even with more time this two mechanisms may come with different outcomes. One such example to illustrate my purpose could be the following. Note that this is only illustrative of my purpose, and I let you find and pick on ethat is more appropriated. I am thinking of a case where a standby PE is be shared among multiple PEs - supposing this situation could occur. Typically, if PE_1, PE_2 are shared by PE_a, ..., PE_z. In case PE_a and PE_b are down, we expect PE_a to switch to PE_1 and PE_b to switch to PE_2. It seems to me that BGP would end up in such situation while a local decision may end up in PE_a and PE_a to switch to PE_1. GIM>> Thank you for the scenario that is very common in deploying protectio= n based on the shared redundant resources. Such schemes, referred to as M:N= protection, in addition to using mechanism detecting a network failure, e.= g., BFD, require a protocol to coordinate the switchover. This specificatio= n applies to a more special deployment scenario where one working PE is pro= tected by one or more standby PEs, i.e., 1:N protection. I understand the document is addressing a 1:N scenario. That said, if M:N s= cenario leverage from 1:N protection it seems to me worth raising the issue= . --_000_DM6PR15MB237965003540C4F0679A45DEE3E80DM6PR15MB2379namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Greg, 

Thanks for the response and clarifications. Most of my comments have been a= ddressed/answered. However, it seems to me that some additional text might = be added to the security consideration section document the impact on the n= etwork of a fast-failover operation. The knowledge of these impact might be useful for an operator to determine= when the trigger can be done. 

Please see more comments inline. 

Yours, 
Daniel 

From: Greg Mirsky <gregi= mirsky@gmail.com>
Sent: Tuesday, November 10, 2020 9:13 PM
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: secdir@ietf.org <secdir@ietf.org>; BESS <bess@ietf.org&= gt;; last-call@ietf.org <last-call@ietf.org>; draft-ietf-bess-mvpn-fa= st-failover.all@ietf.org <draft-ietf-bess-mvpn-fast-failover.all@ietf.or= g>
Subject: Re: Secdir last call review of draft-ietf-bess-mvpn-fast-fa= ilover-11
 
Hi Daniel,
many thanks for the review, thoughtful comments, and questions, all ar= e much appreciated. Also, my apologies for the long delay to respond to you= r comments. Please find my answers and notes in-line below tagged by GIM>= ;>. Attached are the new working version and the diff to -12.

Regards,
Greg

On Fri, Oct 23, 2020 at 5:36 AM Dan= iel Migault via Datatracker <noreply= @ietf.org> wrote:
Reviewer: Daniel Migault
Review result: Has Nits

Hi,


I reviewed this document as part of the Security Directorate's ongoing effo= rt to
review all IETF documents being processed by the IESG.  These comments= were
written primarily for the benefit of the Security Area Directors.  Doc= ument
authors, document editors, and WG chairs should treat these comments just l= ike
any other IETF Last Call comments.  Please note also that my expertise= in BGP is
limited, so feel free to take these comments with a pitch of salt. 
Review Results: Has Nits

Please find my comments below.

Yours,
Daniel


                  Multicast VP= N Fast Upstream Failover
                 draft-ietf-be= ss-mvpn-fast-failover-11

Abstract

   This document defines multicast VPN extensions and procedures = that
   allow fast failover for upstream failures, by allowing downstr= eam PEs
   to take into account the status of Provider-Tunnels (P-tunnels= ) when
   selecting the Upstream PE for a VPN multicast flow, and extend= ing BGP
   MVPN routing so that a C-multicast route can be advertised tow= ard a
   Standby Upstream PE.

<mglt>
Though it might be just a nit, if MVPN
designates multicast VPN, it might be
clarifying to specify the acronym in the
first sentence. This would later make
the correlation with BGP MVPN clearer.

</mglt>
GIM>> I've updated s/BGP MVPN/BGP multicast VPN/. Also, s/mVPN/M= VPN/ throughout the document.


1.  Introduction

   In the context of multicast in BGP/MPLS VPNs, it is desirable = to
   provide mechanisms allowing fast recovery of connectivity on    different types of failures.  This document addresses fai= lures of
   elements in the provider network that are upstream of PEs conn= ected
   to VPN sites with receivers.

<mglt>
Well I am not familiar with neither BGP
nor MPLS. It seems that BGP/MLPS IP VPNS
and MPLS/BGP IP VPNs are both used. I am
wondering if there is a distinction
between the two and a preferred way to
designate these VPNs.  My understanding
is that the VPN-IPv4 characterizes the
VPN while MPLS is used by the backbone
for the transport.  Since the PE are
connected to the backbone the VPN-IPv4
needs to be labeled.

</mglt>
GIM>> I understand that this document often sends the reader to = check RFC 6513 and/or RFC 6514. BGP/MPLS MVPN identifies the case of provid= ing a multicast service over an IP VPN that is overlayed on the MPLS d= ata plane using the BGP control plane.

   Section 3 describes local procedures allowing an egress PE (a = PE
   connected to a receiver site) to take into account the status = of
   P-tunnels to determine the Upstream Multicast Hop (UMH) for a = given
   (C-S, C-G).  This method does not provide a "fast fa= ilover" solution
<mglt>
I understand the limitation is due to
BGP convergence.

</mglt>
GIM>> Yes, a dynamic routing protocol, BGP in this case, provide= s the service restoration functionality but the restoration time is signifi= cant and affects the experience of a client.

   when used alone, but can be used together with the mechanism    described in Section 4 for a "fast failover" solutio= n.

   Section 4 describes protocol extensions that can speed up fail= over by
   not requiring any multicast VPN routing message exchange at re= covery
   time.

   Moreover, section 5 describes a "hot leaf standby" m= echanism, that
   uses a combination of these two mechanisms.  This approac= h has
   similarities with the solution described in [RFC7431] to impro= ve
   failover times when PIM routing is used in a network given som= e
   topology and metric constraints.


[...]

3.1.1.  mVPN Tunnel Root Tracking

   A condition to consider that the status of a P-tunnel is up is= that
   the root of the tunnel, as determined in the x-PMSI Tunnel att= ribute,
   is reachable through unicast routing tables.  In this cas= e, the
   downstream PE can immediately update its UMH when the reachabi= lity
   condition changes.

   That is similar to BGP next-hop tracking for VPN routes, excep= t that
   the address considered is not the BGP next-hop address, but th= e root
   address in the x-PMSI Tunnel attribute.

   If BGP next-hop tracking is done for VPN routes and the root a= ddress
   of a given tunnel happens to be the same as the next-hop addre= ss in
   the BGP A-D Route advertising the tunnel, then checking, in un= icast
   routing tables, whether the tunnel root is reachable, will be<= br>    unnecessary duplication and thus will not bring any specific b= enefit.

<mglt>
It seems to me that x-PMSI address
designates a different interface than
the one used by the Tunnel itself. If
that is correct, such mechanisms seems
to assume that one equipment up on one
interface will be up on the other
interfaces. I have the impression that a
configuration change in a PE may end up
in the P-tunnel being down, while the PE
still being reachable though the x-PMSI
Tunnel attribute. If that is a possible
scenario, the current mechanisms may not
provide more efficient mechanism than
then those of the standard BGP.
GIM>> That is a very interesting angle, thank you. Yes, in OAM, = and in the Fault Management (FM) OAM in particular, we have to make some as= sumptions about the state of the remote system based on a single event= or change of state. Usually, AFAIK, operators use not a physical interface but a loopback to associate with a tunnel. Wi= th a fast IGP convergence, a loopback interface is reachable as long as the= re's a path through the network between two nodes.
<mglt>
Thanks for the clarification
</mglt>

Similarly, it is assumed the tunnel is
either up or down and the determination
of not being up if being down.  I am not
convinced that the two only states.
Typically services under DDoS may be
down for a small amount of time. While
this affects the network, there is not
always a clear cut between the PE being
up or down.
</mglt>
GIM>>  In defect detection a system often has some hysteres= is, i.e., time that the system has to wait to change its state. For example= , BFD changes state from Up to Down after the system does not receive N con= secutive packets (usually 3). As a result, in some cases, the system can be tuned to detect relatively short outages = while in others be slower and miss short-lived outages.


[...]

3.1.6.  BFD Discriminator Attribute

   P-tunnel status may be derived from the status of a multipoint= BFD
   session [RFC8562] whose discriminator is advertised along with= an
   x-PMSI A-D Route.

   This document defines the format and ways of using a new BGP    attribute called the "BFD Discriminator".  It i= s an optional
   transitive BGP attribute.  In Section 7.2, IANA is reques= ted to
   allocate the codepoint value (TBA2).  The format of this = attribute is
   shown in Figure 1.

<mglt>
I feel that the sentence "In Section ...
TBA2)." should be removed.

</mglt>
GIM>> We use this to mark where to note the allocated value. Usu= ally, this text is replaced by the RFC Editor to read 
In Section 7.2 IANA allocated codepoint XXX.



       0             = ;      1              &nb= sp;    2                &= nbsp;  3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
      |    BFD Mode   |    &nb= sp;             Reserved      =                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
      |              &nbs= p;        BFD Discriminator        =                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
      ~              &nbs= p;          Optional TLVs      &nbs= p;                  ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+


            Figure 1: Format of the BFD Discr= iminator Attribute

   Where:

      BFD Mode field is the one octet long.  This speci= fication defines
      the P2MP BFD Session as value 1 Section 7.2.

      Reserved field is three octets long, and the value MUS= T be zeroed
      on transmission and ignored on receipt.

      BFD Discriminator field is four octets long.





Morin, et al.             Expires April = 5, 2021                 [Page = 7]

Internet-Draft         mVPN Fast Upstream Failover=           October 2020


      Optional TLVs is the optional variable-length field th= at MAY be
      used in the BFD Discriminator attribute for future ext= ensions.
      TLVs MAY be included in a sequential or nested manner.=   To allow
      for TLV nesting, it is advised to define a new TLV as = a variable-
      length object.  Figure 2 presents the Optional TL= V format TLV that
      consists of:

      *  one octet-long field of TLV 's Type value (Sec= tion 7.3)

      *  one octet-long field of the length of the Valu= e field in octets

      *  variable length Value field.

      The length of a TLV MUST be multiple of four octets. <mglt>
I am wondering why the constraint on the
length is not mentioned in the paragraph
associated to the field - as opposed to
a  separate paragraph.

</mglt>
GIM>> There might be a slight confusion due to the use of Length= and length. Capitalized - the name of the field which value is the length = of the Value field. The last sentence refers to the overall length of a TLV= , including lengths of Type, Length and Value fields.

<mglt>
you are correct that might have confused me. 
</mglt>

[..]

8.  Security Considerations

   This document describes procedures based on [RFC6513] and [RFC= 6514]
   and hence shares the security considerations respectively repr= esented
   in these specifications.

   This document uses p2mp BFD, as defined in [RFC8562], which, i= n turn,
   is based on [RFC5880].  Security considerations relevant = to each
   protocol are discussed in the respective protocol specificatio= ns.  An
   implementation that supports this specification MUST use a mec= hanism
   to control the maximum number of p2mp BFD sessions that can be= active
   at the same time.

<mglt>
At a high level view - or at least my
interpretation of it - the document
proposes a mechanism based on BFD to
detect fault in the path.  Upon a fault
detection a fail-over operation is
instructed using BGP. This rocedure is
expected to perform a faster fail-over
than traditional BGP convergence on
maintaining routing tables. Once the
fail over has been performed, BFD is
confirms the new path is "legitimate"
and works.

It seems correct to me that the current
protocol relies on BGP / BFD security.
That said, having BFD authentication
based on MD5 or SHA1 may suggest that
stronger primitives be recommended.
While this does not concerns the current
document, it seems to me that the
information might be relayed to routing
ADs.

What remains unclear to me - and I
assume this might be due to my lake or
expertise in routing area - is the impact
associated to performing a fail-over
both on 1) the data plane and 2) the
standard BGP way to establish routing
tables.

Regarding the data plane, I am wondering
if fail-over results in a lost of
packets for example - I suppose for
example that at least the packets in the
process of being forwarded might be
lost. I believe that providing details
on this may be good.
GIM>> You bring up a very topic for the discussion, thank you. W= ith network failure detection in place, the fail-over can be viewed as the = reaction to a network failure.  If that is the case, then packet loss = experienced by service due to the fail-over is the result of the network failure. Would you agree with that view? A sh= orter failure detection interval and faster fail-over should minimize = the packet loss and, as a result, the negative impact on the service itself= .

<mglt>
sure. If you know the network is down, then fast fail-over is definiti= vely a plus. What I think could be useful is to evaluate the cost associate= d to a fast-fail-over without any network failure.  This would be usef= ul for an operator to evaluate whether it should spend more time in diagnosing a network failure versus performin= g a fast-fail-over. 
Typically, if a fast failover comes a no cost at all, one operator wou= ld maybe use one exchange to test the liveness of a node rather than 3.&nbs= p;     

At that point, it seems to me that additional text coudl be added to c= haracterize the impact. These could be high level and indicative, but it se= ems to me that knowing these impacts presents some value to the operators.&= nbsp;     
</mglt>

If there are any impacts I would like to
understand also in which cases the
decision to perform a failover operation
may result in more harm than the event
that has been over-interpreted. An
hypothetical scenario could be that the
non reception of a BFD packet is
interpreted as a PE being down while it
may not be correct and the PE might have
been simply under stress. A "too fast" fail-over
may over interpreted it and perform a
fail-over. If such things could happen,
an attacker could leverage a micro event
to perform network operation that are
not negligible. Another way to see that
is that an attacker might not have
direct access to the control plan, but
could use the data plan to generate a
stress and sort of control the fail
over. It seems to me that some text
might be welcome to prevent such cases
to happen. This could be guidance for
declaring a tunnel down for example.
GIM>> I agree with your scenario. Over-short detection interval = may produce a false-negative transition to the Down state in BFD and thus t= riggering the fail-over. I think that that is more an operational issue, so= mething that an operator will consider when deploying the mechanism specified in this draft. Resulting from addre= ssing RtgDir review the draft was updated to provide more guidance:
   In many cases, it is not practical to use both protection=
   methods at the same time because uncorrelated timers might cau= se
   unnecessary switchovers and destabilize the network.
<mglt>
Thanks for the feed back, It seems to me important to mention it is no= t recommended these two mechanism co-exist. 
How to avoid false negative transition might be out of scope of the dr= aft I agree, but it seems to me worth being mentioned especially in relatio= n to the impacts associated to a fail-over.  In case the fast-failover= comes with no impact this becomes less of a problem for operator deploying it.
 
</mglt>
Though the text above might not be general, I think that it also appli= es to the scenario you've presented.

Similarly, it would be good to add some
text regarding the interferences with
the non-fast forwarding fail over when
performed by the standard BGP.
Typically, my impression is that the
fast fail-over mechanism is a local
decision versus the BGP convergence that
is more global. As a result, even with
more time this two mechanisms may come
with different outcomes. One such
example to illustrate my purpose could
be the following. Note that this is only
illustrative of my purpose, and I let
you find and pick on ethat is more
appropriated.   I am thinking of a case
where a standby PE is be shared among
multiple PEs - supposing this situation
could occur.  Typically, if PE_1, PE_2
are shared by PE_a, ..., PE_z. In case
PE_a and PE_b are down, we expect PE_a
to switch to PE_1 and PE_b to switch to
PE_2. It seems to me that BGP would end
up in such situation while a local
decision may end up in PE_a and PE_a to
switch to PE_1.

</mglt>
GIM>> Thank you for the scenario that is very common in deployin= g protection based on the shared redundant resources. Such schemes, referre= d to as M:N protection, in addition to using mechanism detecting a network = failure, e.g., BFD, require a protocol to coordinate the switchover. This specification applies to a more special= deployment scenario where one working PE is protected by one or more stand= by PEs, i.e., 1:N protection.

<mglt>
I understand the document is addressing a 1:N scenario. That said, if = M:N scenario leverage from 1:N protection it seems to me worth raising the = issue. 
</mglt>
--_000_DM6PR15MB237965003540C4F0679A45DEE3E80DM6PR15MB2379namp_-- From nobody Wed Nov 11 12:20:45 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6205A3A105A; Wed, 11 Nov 2020 12:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saS-YVGQJAjQ; Wed, 11 Nov 2020 12:20:42 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42EB83A1060; Wed, 11 Nov 2020 12:20:41 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0ABKKQG5000829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Nov 2020 15:20:40 -0500 Date: Wed, 11 Nov 2020 12:20:26 -0800 From: Benjamin Kaduk To: secdir@ietf.org, sec-chairs@ietf.org Message-ID: <20201111202026.GB39170@kduck.mit.edu> References: <20201111201834.GA39170@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201111201834.GA39170@kduck.mit.edu> Archived-At: Subject: [secdir] Fwd: Webex meeting: Pre-IETF 109 Security Area Office Hours X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 20:20:44 -0000 For this reduced audience I'll note that our office hours are often under-attended. Even if you don't have a specific question, please feel free to pop in and say 'hi'; we can treat it as a social hour while there are no technical questions being brought up. -Ben On Wed, Nov 11, 2020 at 12:18:34PM -0800, Benjamin Kaduk wrote: > Hi all, > > I wanted to call out that (though it's been on the IETF 109 Agenda for a > week or so), the SEC ADs will be holding office hours tomorrow at 1600h > US-Eastern (so, 0400h Friday ICT). Hopefully having them the week before > IETF 109 will allow things to be a bit more relaxed, even if everyone's > effective local time zone is in flux. > > -Ben > > > Date: Tue, 10 Nov 2020 19:57:31 +0000 > > > > Pre-IETF 109 Security Area Office Hours > > Friday, November 13, 2020 > > 4:00 pm | (UTC-05:00) Eastern Time (US & Canada) | 1 hr > > Meeting number (access code): 178 969 3859 > > Meeting password: Zhma27WPTC7 > > > > > > > > When it's time, join the meeting. > > https://ietf.webex.com/ietf/j.php?MTID=m4767cee616bb06a365e084c6f8f09717 > > > > Add to Calendar > > https://ietf.webex.com/ietf/j.php?MTID=m06a44ebd4568dfec86698ed98dd6c749 > > > > > > > > > > TAP TO JOIN FROM A MOBILE DEVICE (ATTENDEES ONLY) > > +1-650-479-3208,,1789693859## tel:%2B1-650-479-3208,,*01*1789693859%23%23*01* Call-in toll number (US/Canada) > > > > > > JOIN BY PHONE > > 1-650-479-3208 Call-in toll number (US/Canada) > > > > Global call-in numbers > > https://ietf.webex.com/ietf/globalcallin.php?MTID=m5b1fdcc27604d4fa23405ace3b685116 > > > > > > JOIN FROM A VIDEO SYSTEM OR APPLICATION > > Dial sip:1789693859@ietf.webex.com > > You can also dial 173.243.2.68 and enter your meeting number. > > > > > > Join using Microsoft Lync or Microsoft Skype for Business > > Dial sip:1789693859.ietf@lync.webex.com > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Thu Nov 12 05:51:24 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 628FC3A0EC3 for ; Thu, 12 Nov 2020 05:51:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.22.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <160518908196.19188.3717770335029547378@ietfa.amsl.com> Date: Thu, 12 Nov 2020 05:51:22 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 13:51:22 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-12-03 Reviewer LC end Draft Daniel Gillmor 2020-09-30 draft-ietf-ccamp-layer0-types-08 Steve Hanna 2020-09-30 draft-ietf-ccamp-wson-yang-27 Christopher Wood R2019-11-06 draft-ietf-dtn-tcpclv4-22 Last calls: Reviewer LC end Draft Derek Atkins R2020-09-04 draft-ietf-i2nsf-sdn-ipsec-flow-protection-12 Daniel Franke 2020-09-18 draft-ietf-jmap-mdn-15 Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-10 Daniel Gillmor 2020-09-30 draft-ietf-ccamp-layer0-types-08 Phillip Hallam-Baker 2020-09-30 draft-ietf-lwig-tcp-constrained-node-networks-13 Steve Hanna 2020-09-30 draft-ietf-ccamp-wson-yang-27 Dan Harkins None draft-ietf-rtgwg-policy-model-03 Leif Johansson 2020-10-02 draft-ietf-lpwan-schc-over-lorawan-13 Scott Kelly 2020-10-01 draft-ietf-idr-tunnel-encaps-20 Aanchal Malhotra 2020-10-12 draft-ietf-dots-server-discovery-14 Catherine Meadows 2020-10-21 draft-ietf-6lo-blemesh-08 Adam Montville 2020-11-30 draft-ietf-tls-oldversions-deprecate-09 Kathleen Moriarty 2020-07-20 draft-ietf-ace-oscore-profile-13 Russ Mundy 2020-07-20 draft-ietf-ace-dtls-authorize-14 Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer-05 Magnus Nystrom 2020-11-16 draft-ietf-quic-qpack-19 Hilarie Orman 2020-11-16 draft-ietf-quic-http-32 Derrell Piper 2020-11-11 draft-ietf-suit-information-model-08 Tirumaleswar Reddy.K 2020-11-16 draft-ietf-quic-transport-32 Rich Salz R2020-08-14 draft-ietf-suit-architecture-14 Sean Turner 2020-12-01 draft-ietf-ipsecme-ipv6-ipv4-codes-05 Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth-09 Christopher Wood 2020-09-23 draft-ietf-6man-rfc4941bis-12 Christopher Wood R2019-11-06 draft-ietf-dtn-tcpclv4-22 Paul Wouters 2020-09-08 draft-ietf-i2nsf-capability-data-model-13 Next in the reviewer rotation: Mališa Vučinić Carl Wallace Samuel Weiler Brian Weis Klaas Wierenga Christopher Wood Paul Wouters Liang Xia Dacheng Zhang Derek Atkins From nobody Thu Nov 12 07:47:36 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519723A135F; Thu, 12 Nov 2020 07:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.696 X-Spam-Level: X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8kTVige5Kun; Thu, 12 Nov 2020 07:47:27 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4134D3A135D; Thu, 12 Nov 2020 07:47:26 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id l10so6687169lji.4; Thu, 12 Nov 2020 07:47:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dmDFIiz5GhKFG8a+7ERmaMz3uPKo6Ufol2n7fK78dhY=; b=EP96fMhSsXk1NC5qWQ79UET5NOw6SqGsirOE4ozTGT5Yv+ZGGhOau63SbMOU/lxTrM jUV0CgFfeW116cgbambIUJ5LSb0vs3Qwm3AH5bsTcBU/9479v/sfB8xM2NlnPh3DI3Mg jgoDcjyg80eagotHC0GLSEQvg7fCsAqcgZf+SSCCSufDguo22KKyujwxOmVHbkjR+qMn RoPW88f31725rBtYzCfX8FixflRpPuNai55EPIJPwygBTaWWPa8BJmmLyZC4+pt7caR7 Q5+W8TdouaoBaxTf321UPgrKg2AueyTrDEWOyITjstUUW+5jIZDX9a1wjXDjPL12/VrY 27KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dmDFIiz5GhKFG8a+7ERmaMz3uPKo6Ufol2n7fK78dhY=; b=B6v8amZYoQx81iH/cXKwUgNHNcWuV3zqaxvL2Xw/z4fMKRtOkSeJls9TcPJXdDEDZa yuMP2Q3KiUqsCg8pLOhDrfQzI5J++X7FmpjtWdjogE/XXju/UhKpfYsYsIdjtubf8DzD vE/xh2T6PKkxIzDHwZQQPzdlX53akmJ0uPESXwK4C4kFwO8813fzdDeCiYILKBM+U7W9 EM/5W/8sCR1uELy34nehJyf1Pgo0xV0qYIXOlafsz/zyCDXe9aeBlDY2uyvRUE3Hwax1 5WOEQDdcg/3LKXwfdglqqPDyQ8cbZ+PrWHOuSjHxrg0BXmv7R7saxZ1xoOWQNbtHJ7+H O46Q== X-Gm-Message-State: AOAM532anyH7WwfuUdSeWBgVkZai6vr8FjE37fUvR+cpd9sKix0gYri9 bfe29Y9YVsi8PgrN1uDRY+CpBIqVUnqt+2o1cPM= X-Google-Smtp-Source: ABdhPJycF/D40Ic64Ig1VLmpKQ7gMPF4FPx03vOiWLNsDwEA1IMHThU+N+SeBzrMSUYmha1HaNsGX+bbsk1FVV64Ff4= X-Received: by 2002:a2e:85c6:: with SMTP id h6mr25426ljj.110.1605196044135; Thu, 12 Nov 2020 07:47:24 -0800 (PST) MIME-Version: 1.0 References: <160345656094.22100.7057001737682109381@ietfa.amsl.com> In-Reply-To: From: Greg Mirsky Date: Thu, 12 Nov 2020 07:47:11 -0800 Message-ID: To: Daniel Migault Cc: "secdir@ietf.org" , BESS , "last-call@ietf.org" , "draft-ietf-bess-mvpn-fast-failover.all@ietf.org" Content-Type: multipart/mixed; boundary="00000000000001992105b3ead4c4" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-bess-mvpn-fast-failover-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 15:47:34 -0000 --00000000000001992105b3ead4c4 Content-Type: multipart/alternative; boundary="00000000000001992005b3ead4c2" --00000000000001992005b3ead4c2 Content-Type: text/plain; charset="UTF-8" Hi Daniel, thank you for your kind consideration of my notes. I've top-copied what appeared to me as the remaining open issues. I hope I've not missed any of your questions. Please find my notes in-line below tagged GIM>>. Attached are the updated working version and the new diff. Regards, Greg sure. If you know the network is down, then fast fail-over is definitively a plus. What I think could be useful is to evaluate the cost associated to a fast-fail-over without any network failure. This would be useful for an operator to evaluate whether it should spend more time in diagnosing a network failure versus performing a fast-fail-over. Typically, if a fast failover comes a no cost at all, one operator would maybe use one exchange to test the liveness of a node rather than 3. At that point, it seems to me that additional text coudl be added to characterize the impact. These could be high level and indicative, but it seems to me that knowing these impacts presents some value to the operators. GIM>> I would like to add a new paragraph in Section 3.1: NEW TEXT: All methods described in this section may produce false-negative state changes that can be the trigger for an unnecessary failover negatively impacting the multicast service provided by the VPN. An operator expected to consider the network environment and use available controls of the mechanism used to determine the status of a P-tunnel. Would the new text be helpful? Thanks for the feed back, It seems to me important to mention it is not recommended these two mechanism co-exist. How to avoid false negative transition might be out of scope of the draft I agree, but it seems to me worth being mentioned especially in relation to the impacts associated to a fail-over. In case the fast-failover comes with no impact this becomes less of a problem for operator deploying it. GIM>> I hope that the new text presented above addresses this concern. I understand the document is addressing a 1:N scenario. That said, if M:N scenario leverage from 1:N protection it seems to me worth raising the issue. GIM>> I propose adding the clarification of the use of the Sandby PE in Section 4: OLD TEXT: The procedures described below are limited to the case where the site that contains C-S is connected to two or more PEs, though, to simplify the description, the case of dual-homing is described. NEW TEXT: The procedures described below are limited to the case where the site that contains C-S is connected to two or more PEs, though, to simplify the description, the case of dual-homing is described. Such a redundancy protection scheme, referred to as 1:N protection, is the special case of M:N protection, where M working instances are sharing protection of the N standby instances. In addition to a network failure detection mechanism, the latter scheme requires using a mechanism to coordinate the failover among working instances. For that reason, M:N protection is outside the scope of this specification. On Wed, Nov 11, 2020 at 8:48 AM Daniel Migault wrote: > Hi Greg, > > Thanks for the response and clarifications. Most of my comments have been > addressed/answered. However, it seems to me that some additional text might > be added to the security consideration section document the impact on the > network of a fast-failover operation. The knowledge of these impact might > be useful for an operator to determine when the trigger can be done. > > Please see more comments inline. > > Yours, > Daniel > > ------------------------------ > *From:* Greg Mirsky > *Sent:* Tuesday, November 10, 2020 9:13 PM > *To:* Daniel Migault > *Cc:* secdir@ietf.org ; BESS ; > last-call@ietf.org ; > draft-ietf-bess-mvpn-fast-failover.all@ietf.org < > draft-ietf-bess-mvpn-fast-failover.all@ietf.org> > *Subject:* Re: Secdir last call review of > draft-ietf-bess-mvpn-fast-failover-11 > > Hi Daniel, > many thanks for the review, thoughtful comments, and questions, all are > much appreciated. Also, my apologies for the long delay to respond to your > comments. Please find my answers and notes in-line below tagged by GIM>>. > Attached are the new working version and the diff to -12. > > Regards, > Greg > > On Fri, Oct 23, 2020 at 5:36 AM Daniel Migault via Datatracker < > noreply@ietf.org> wrote: > > Reviewer: Daniel Migault > Review result: Has Nits > > Hi, > > > I reviewed this document as part of the Security Directorate's ongoing > effort to > review all IETF documents being processed by the IESG. These comments were > written primarily for the benefit of the Security Area Directors. Document > authors, document editors, and WG chairs should treat these comments just > like > any other IETF Last Call comments. Please note also that my expertise in > BGP is > limited, so feel free to take these comments with a pitch of salt. > > Review Results: Has Nits > > Please find my comments below. > > Yours, > Daniel > > > Multicast VPN Fast Upstream Failover > draft-ietf-bess-mvpn-fast-failover-11 > > Abstract > > This document defines multicast VPN extensions and procedures that > allow fast failover for upstream failures, by allowing downstream PEs > to take into account the status of Provider-Tunnels (P-tunnels) when > selecting the Upstream PE for a VPN multicast flow, and extending BGP > MVPN routing so that a C-multicast route can be advertised toward a > Standby Upstream PE. > > > Though it might be just a nit, if MVPN > designates multicast VPN, it might be > clarifying to specify the acronym in the > first sentence. This would later make > the correlation with BGP MVPN clearer. > > > > GIM>> I've updated s/BGP MVPN/BGP multicast VPN/. Also, s/mVPN/MVPN/ > throughout the document. > > > > 1. Introduction > > In the context of multicast in BGP/MPLS VPNs, it is desirable to > provide mechanisms allowing fast recovery of connectivity on > different types of failures. This document addresses failures of > elements in the provider network that are upstream of PEs connected > to VPN sites with receivers. > > > Well I am not familiar with neither BGP > nor MPLS. It seems that BGP/MLPS IP VPNS > and MPLS/BGP IP VPNs are both used. I am > wondering if there is a distinction > between the two and a preferred way to > designate these VPNs. My understanding > is that the VPN-IPv4 characterizes the > VPN while MPLS is used by the backbone > for the transport. Since the PE are > connected to the backbone the VPN-IPv4 > needs to be labeled. > > > > GIM>> I understand that this document often sends the reader to check RFC > 6513 and/or RFC 6514. BGP/MPLS MVPN identifies the case of providing a > multicast service over an IP VPN that is overlayed on the MPLS data plane > using the BGP control plane. > > > Section 3 describes local procedures allowing an egress PE (a PE > connected to a receiver site) to take into account the status of > P-tunnels to determine the Upstream Multicast Hop (UMH) for a given > (C-S, C-G). This method does not provide a "fast failover" solution > > I understand the limitation is due to > BGP convergence. > > > > GIM>> Yes, a dynamic routing protocol, BGP in this case, provides the > service restoration functionality but the restoration time is significant > and affects the experience of a client. > > when used alone, but can be used together with the mechanism > described in Section 4 for a "fast failover" solution. > > Section 4 describes protocol extensions that can speed up failover by > not requiring any multicast VPN routing message exchange at recovery > time. > > Moreover, section 5 describes a "hot leaf standby" mechanism, that > uses a combination of these two mechanisms. This approach has > similarities with the solution described in [RFC7431] to improve > failover times when PIM routing is used in a network given some > topology and metric constraints. > > > [...] > > 3.1.1. mVPN Tunnel Root Tracking > > A condition to consider that the status of a P-tunnel is up is that > the root of the tunnel, as determined in the x-PMSI Tunnel attribute, > is reachable through unicast routing tables. In this case, the > downstream PE can immediately update its UMH when the reachability > condition changes. > > That is similar to BGP next-hop tracking for VPN routes, except that > the address considered is not the BGP next-hop address, but the root > address in the x-PMSI Tunnel attribute. > > If BGP next-hop tracking is done for VPN routes and the root address > of a given tunnel happens to be the same as the next-hop address in > the BGP A-D Route advertising the tunnel, then checking, in unicast > routing tables, whether the tunnel root is reachable, will be > unnecessary duplication and thus will not bring any specific benefit. > > > It seems to me that x-PMSI address > designates a different interface than > the one used by the Tunnel itself. If > that is correct, such mechanisms seems > to assume that one equipment up on one > interface will be up on the other > interfaces. I have the impression that a > configuration change in a PE may end up > in the P-tunnel being down, while the PE > still being reachable though the x-PMSI > Tunnel attribute. If that is a possible > scenario, the current mechanisms may not > provide more efficient mechanism than > then those of the standard BGP. > > GIM>> That is a very interesting angle, thank you. Yes, in OAM, and in the > Fault Management (FM) OAM in particular, we have to make some > assumptions about the state of the remote system based on a single event or > change of state. Usually, AFAIK, operators use not a physical interface but > a loopback to associate with a tunnel. With a fast IGP convergence, a > loopback interface is reachable as long as there's a path through the > network between two nodes. > > Thanks for the clarification > > > > Similarly, it is assumed the tunnel is > either up or down and the determination > of not being up if being down. I am not > convinced that the two only states. > Typically services under DDoS may be > down for a small amount of time. While > this affects the network, there is not > always a clear cut between the PE being > up or down. > > > GIM>> In defect detection a system often has some hysteresis, i.e., time > that the system has to wait to change its state. For example, BFD changes > state from Up to Down after the system does not receive N consecutive > packets (usually 3). As a result, in some cases, the system can be tuned to > detect relatively short outages while in others be slower and miss > short-lived outages. > > > > [...] > > 3.1.6. BFD Discriminator Attribute > > P-tunnel status may be derived from the status of a multipoint BFD > session [RFC8562] whose discriminator is advertised along with an > x-PMSI A-D Route. > > This document defines the format and ways of using a new BGP > attribute called the "BFD Discriminator". It is an optional > transitive BGP attribute. In Section 7.2, IANA is requested to > allocate the codepoint value (TBA2). The format of this attribute is > shown in Figure 1. > > > I feel that the sentence "In Section ... > TBA2)." should be removed. > > > > GIM>> We use this to mark where to note the allocated value. Usually, this > text is replaced by the RFC Editor to read > > In Section 7.2 IANA allocated codepoint XXX. > > > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BFD Mode | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BFD Discriminator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Optional TLVs ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 1: Format of the BFD Discriminator Attribute > > Where: > > BFD Mode field is the one octet long. This specification defines > the P2MP BFD Session as value 1 Section 7.2. > > Reserved field is three octets long, and the value MUST be zeroed > on transmission and ignored on receipt. > > BFD Discriminator field is four octets long. > > > > > > Morin, et al. Expires April 5, 2021 [Page 7] > > Internet-Draft mVPN Fast Upstream Failover October 2020 > > > Optional TLVs is the optional variable-length field that MAY be > used in the BFD Discriminator attribute for future extensions. > TLVs MAY be included in a sequential or nested manner. To allow > for TLV nesting, it is advised to define a new TLV as a variable- > length object. Figure 2 presents the Optional TLV format TLV that > consists of: > > * one octet-long field of TLV 's Type value (Section 7.3) > > * one octet-long field of the length of the Value field in octets > > * variable length Value field. > > The length of a TLV MUST be multiple of four octets. > > I am wondering why the constraint on the > length is not mentioned in the paragraph > associated to the field - as opposed to > a separate paragraph. > > > > GIM>> There might be a slight confusion due to the use of Length and > length. Capitalized - the name of the field which value is the length of > the Value field. The last sentence refers to the overall length of a TLV, > including lengths of Type, Length and Value fields. > > > you are correct that might have confused me. > > > > [..] > > 8. Security Considerations > > This document describes procedures based on [RFC6513] and [RFC6514] > and hence shares the security considerations respectively represented > in these specifications. > > This document uses p2mp BFD, as defined in [RFC8562], which, in turn, > is based on [RFC5880]. Security considerations relevant to each > protocol are discussed in the respective protocol specifications. An > implementation that supports this specification MUST use a mechanism > to control the maximum number of p2mp BFD sessions that can be active > at the same time. > > > At a high level view - or at least my > interpretation of it - the document > proposes a mechanism based on BFD to > detect fault in the path. Upon a fault > detection a fail-over operation is > instructed using BGP. This rocedure is > expected to perform a faster fail-over > than traditional BGP convergence on > maintaining routing tables. Once the > fail over has been performed, BFD is > confirms the new path is "legitimate" > and works. > > It seems correct to me that the current > protocol relies on BGP / BFD security. > That said, having BFD authentication > based on MD5 or SHA1 may suggest that > stronger primitives be recommended. > While this does not concerns the current > document, it seems to me that the > information might be relayed to routing > ADs. > > What remains unclear to me - and I > assume this might be due to my lake or > expertise in routing area - is the impact > associated to performing a fail-over > both on 1) the data plane and 2) the > standard BGP way to establish routing > tables. > > Regarding the data plane, I am wondering > if fail-over results in a lost of > packets for example - I suppose for > example that at least the packets in the > process of being forwarded might be > lost. I believe that providing details > on this may be good. > > GIM>> You bring up a very topic for the discussion, thank you. With > network failure detection in place, the fail-over can be viewed as the > reaction to a network failure. If that is the case, then packet loss > experienced by service due to the fail-over is the result of the network > failure. Would you agree with that view? A shorter failure detection > interval and faster fail-over should minimize the packet loss and, as a > result, the negative impact on the service itself. > > > sure. If you know the network is down, then fast fail-over is definitively > a plus. What I think could be useful is to evaluate the cost associated to > a fast-fail-over without any network failure. This would be useful for an > operator to evaluate whether it should spend more time in diagnosing a > network failure versus performing a fast-fail-over. > Typically, if a fast failover comes a no cost at all, one operator would > maybe use one exchange to test the liveness of a node rather than 3. > > At that point, it seems to me that additional text coudl be added to > characterize the impact. These could be high level and indicative, but it > seems to me that knowing these impacts presents some value to the > operators. > > > If there are any impacts I would like to > understand also in which cases the > decision to perform a failover operation > may result in more harm than the event > that has been over-interpreted. An > hypothetical scenario could be that the > non reception of a BFD packet is > interpreted as a PE being down while it > may not be correct and the PE might have > been simply under stress. A "too fast" fail-over > may over interpreted it and perform a > fail-over. If such things could happen, > an attacker could leverage a micro event > to perform network operation that are > not negligible. Another way to see that > is that an attacker might not have > direct access to the control plan, but > could use the data plan to generate a > stress and sort of control the fail > over. It seems to me that some text > might be welcome to prevent such cases > to happen. This could be guidance for > declaring a tunnel down for example. > > GIM>> I agree with your scenario. Over-short detection interval may > produce a false-negative transition to the Down state in BFD and thus > triggering the fail-over. I think that that is more an operational issue, > something that an operator will consider when deploying the mechanism > specified in this draft. Resulting from addressing RtgDir review the draft > was updated to provide more guidance: > In many cases, it is not practical to use both protection > methods at the same time because uncorrelated timers might cause > unnecessary switchovers and destabilize the network. > > Thanks for the feed back, It seems to me important to mention it is not > recommended these two mechanism co-exist. > How to avoid false negative transition might be out of scope of the draft > I agree, but it seems to me worth being mentioned especially in relation to > the impacts associated to a fail-over. In case the fast-failover comes > with no impact this becomes less of a problem for operator deploying it. > > > Though the text above might not be general, I think that it also applies > to the scenario you've presented. > > > Similarly, it would be good to add some > text regarding the interferences with > the non-fast forwarding fail over when > performed by the standard BGP. > Typically, my impression is that the > fast fail-over mechanism is a local > decision versus the BGP convergence that > is more global. As a result, even with > more time this two mechanisms may come > with different outcomes. One such > example to illustrate my purpose could > be the following. Note that this is only > illustrative of my purpose, and I let > you find and pick on ethat is more > appropriated. I am thinking of a case > where a standby PE is be shared among > multiple PEs - supposing this situation > could occur. Typically, if PE_1, PE_2 > are shared by PE_a, ..., PE_z. In case > PE_a and PE_b are down, we expect PE_a > to switch to PE_1 and PE_b to switch to > PE_2. It seems to me that BGP would end > up in such situation while a local > decision may end up in PE_a and PE_a to > switch to PE_1. > > > > GIM>> Thank you for the scenario that is very common in deploying > protection based on the shared redundant resources. Such schemes, referred > to as M:N protection, in addition to using mechanism detecting a network > failure, e.g., BFD, require a protocol to coordinate the switchover. This > specification applies to a more special deployment scenario where one > working PE is protected by one or more standby PEs, i.e., 1:N protection. > > > I understand the document is addressing a 1:N scenario. That said, if M:N > scenario leverage from 1:N protection it seems to me worth raising the > issue. > > --00000000000001992005b3ead4c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Daniel,
thank you for your kind consideration of my= notes. I've top-copied what appeared to me as the remaining open issue= s. I hope I've not=C2=A0missed=C2=A0any of your questions. Please find = my notes in-line below tagged GIM>>. Attached are the updated working= version and the new diff.

Regards,
Greg=

<mglt>
sure. If you know the network is = down, then fast fail-over is definitively a plus. What I think could be use= ful is to evaluate the cost associated to a fast-fail-over without any netw= ork failure.=C2=A0 This would be useful for an operator to evaluate whether= it should spend more time in diagnosing a network failure versus performin= g a fast-fail-over.
Typically, if a fast failover comes a no cost at al= l, one operator would maybe use one exchange to test the liveness of a node= rather than 3. =C2=A0 =C2=A0 =C2=A0

At that point, it seems to me t= hat additional text coudl be added to characterize the impact. These could = be high level and indicative, but it seems to me that knowing these impacts= presents some value to the operators. =C2=A0 =C2=A0 =C2=A0
</mglt>= ;
GIM>> I would like to add a new paragraph in Section = 3.1:
NEW TEXT:
=C2=A0 =C2=A0All methods described in th= is section may produce false-negative
=C2=A0 =C2=A0state changes that ca= n be the trigger for an unnecessary failover
=C2=A0 =C2=A0negatively imp= acting the multicast service provided by the VPN.=C2=A0 An
=C2=A0 =C2=A0= operator expected to consider the network environment and use
=C2=A0 =C2= =A0available controls of the mechanism used to determine the status of a=C2=A0 =C2=A0P-tunnel.

Would the new text be = helpful?

<mglt>
Thanks for the feed back,= It seems to me important to mention it is not recommended these two mechan= ism co-exist.
How to avoid false negative transition might be out of sc= ope of the draft I agree, but it seems to me worth being mentioned especial= ly in relation to the impacts associated to a fail-over.=C2=A0 In case the = fast-failover comes with no impact this becomes less of a problem for opera= tor deploying it.
=C2=A0
</mglt>
GIM>> I ho= pe that the new text presented above addresses this concern.

=
<mglt>
I understand the document is addressing a 1:N sc= enario. That said, if M:N scenario leverage from 1:N protection it seems to= me worth raising the issue.
</mglt>
GIM>> I = propose adding the clarification of the use of the Sandby PE in Section 4:<= /div>
OLD TEXT:
=C2=A0 =C2=A0The procedures described below a= re limited to the case where the site
=C2=A0 =C2=A0that contains C-S is = connected to two or more PEs, though, to
=C2=A0 =C2=A0simplify the descr= iption, the case of dual-homing is described.
NEW TEXT:
=
=C2=A0 =C2=A0The procedures described below are limited to the case wh= ere the site
=C2=A0 =C2=A0that contains C-S is connected to two or more = PEs, though, to
=C2=A0 =C2=A0simplify the description, the case of dual-= homing is described.=C2=A0 Such
=C2=A0 =C2=A0a redundancy protection sch= eme, referred to as 1:N protection, is the
=C2=A0 =C2=A0special case of = M:N protection, where M working instances are sharing
=C2=A0 =C2=A0prote= ction of the N standby instances.=C2=A0 In addition to a network
=C2=A0 = =C2=A0failure detection mechanism, the latter scheme requires using a
= =C2=A0 =C2=A0mechanism to coordinate the failover among working instances.= =C2=A0 For
=C2=A0 =C2=A0that reason, M:N protection is outside the scope= of this
=C2=A0 =C2=A0specification.=C2=A0

On Wed, Nov 11, 2020= at 8:48 AM Daniel Migault <daniel.migault@ericsson.com> wrote:
Hi Greg,=C2=A0

Thanks for the response and clarifications. Most of my comments have been a= ddressed/answered. However, it seems to me that some additional text might = be added to the security consideration section document the impact on the n= etwork of a fast-failover operation. The knowledge of these impact might be useful for an operator to determine= when the trigger can be done.=C2=A0

Please see more comments inline.=C2=A0

Yours,=C2=A0
Daniel=C2=A0

Fro= m: Greg Mirsky <gregimirsky@gmail.com>
Sent: Tuesday, November 10, 2020 9:13 PM
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: secdir@ietf= .org <secdir@ie= tf.org>; BESS <bess@ietf.org>; last-call@ietf.org <last-call@ietf.org>; draft-ietf-bess-mvpn-fas= t-failover.all@ietf.org <draft-ietf-bess-mvpn-fast-failove= r.all@ietf.org>
Subject: Re: Secdir last call review of draft-ietf-bess-mvpn-fast-fa= ilover-11
=C2=A0
Hi Daniel,
many thanks for the review, thoughtful comments, and questions, all ar= e much appreciated. Also, my apologies for the long delay to respond to you= r comments. Please find my answers and notes in-line below tagged by GIM>= ;>. Attached are the new working version and the diff to -12.

Regards,
Greg

On Fri, Oct 23, 2020 at 5:36 AM Daniel Migault via Datatra= cker <noreply@ietf= .org> wrote:
Reviewer: Daniel Migault
Review result: Has Nits

Hi,


I reviewed this document as part of the Security Directorate's ongoing = effort to
review all IETF documents being processed by the IESG.=C2=A0 These comments= were
written primarily for the benefit of the Security Area Directors.=C2=A0 Doc= ument
authors, document editors, and WG chairs should treat these comments just l= ike
any other IETF Last Call comments.=C2=A0 Please note also that my expertise= in BGP is
limited, so feel free to take these comments with a pitch of salt.=C2=A0
Review Results: Has Nits

Please find my comments below.

Yours,
Daniel


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Multicast VP= N Fast Upstream Failover
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-be= ss-mvpn-fast-failover-11

Abstract

=C2=A0 =C2=A0This document defines multicast VPN extensions and procedures = that
=C2=A0 =C2=A0allow fast failover for upstream failures, by allowing downstr= eam PEs
=C2=A0 =C2=A0to take into account the status of Provider-Tunnels (P-tunnels= ) when
=C2=A0 =C2=A0selecting the Upstream PE for a VPN multicast flow, and extend= ing BGP
=C2=A0 =C2=A0MVPN routing so that a C-multicast route can be advertised tow= ard a
=C2=A0 =C2=A0Standby Upstream PE.

<mglt>
Though it might be just a nit, if MVPN
designates multicast VPN, it might be
clarifying to specify the acronym in the
first sentence. This would later make
the correlation with BGP MVPN clearer.

</mglt>
GIM>> I've updated s/BGP MVPN/BGP multicast VPN/. Also, s/mV= PN/MVPN/ throughout the document.


1.=C2=A0 Introduction

=C2=A0 =C2=A0In the context of multicast in BGP/MPLS VPNs, it is desirable = to
=C2=A0 =C2=A0provide mechanisms allowing fast recovery of connectivity on =C2=A0 =C2=A0different types of failures.=C2=A0 This document addresses fai= lures of
=C2=A0 =C2=A0elements in the provider network that are upstream of PEs conn= ected
=C2=A0 =C2=A0to VPN sites with receivers.

<mglt>
Well I am not familiar with neither BGP
nor MPLS. It seems that BGP/MLPS IP VPNS
and MPLS/BGP IP VPNs are both used. I am
wondering if there is a distinction
between the two and a preferred way to
designate these VPNs.=C2=A0 My understanding
is that the VPN-IPv4 characterizes the
VPN while MPLS is used by the backbone
for the transport.=C2=A0 Since the PE are
connected to the backbone the VPN-IPv4
needs to be labeled.

</mglt>
GIM>> I understand that this document often sends the reader to = check RFC 6513 and/or RFC 6514. BGP/MPLS MVPN identifies the case of provid= ing a multicast service over an IP VPN that is overlayed=C2=A0on the MPLS d= ata plane using the BGP control plane.

=C2=A0 =C2=A0Section 3 describes local procedures allowing an egress PE (a = PE
=C2=A0 =C2=A0connected to a receiver site) to take into account the status = of
=C2=A0 =C2=A0P-tunnels to determine the Upstream Multicast Hop (UMH) for a = given
=C2=A0 =C2=A0(C-S, C-G).=C2=A0 This method does not provide a "fast fa= ilover" solution
<mglt>
I understand the limitation is due to
BGP convergence.

</mglt>
GIM>> Yes, a dynamic routing protocol, BGP in this case, provide= s the service restoration functionality but the restoration time is signifi= cant and affects the experience of a client.

=C2=A0 =C2=A0when used alone, but can be used together with the mechanism =C2=A0 =C2=A0described in Section 4 for a "fast failover" solutio= n.

=C2=A0 =C2=A0Section 4 describes protocol extensions that can speed up fail= over by
=C2=A0 =C2=A0not requiring any multicast VPN routing message exchange at re= covery
=C2=A0 =C2=A0time.

=C2=A0 =C2=A0Moreover, section 5 describes a "hot leaf standby" m= echanism, that
=C2=A0 =C2=A0uses a combination of these two mechanisms.=C2=A0 This approac= h has
=C2=A0 =C2=A0similarities with the solution described in [RFC7431] to impro= ve
=C2=A0 =C2=A0failover times when PIM routing is used in a network given som= e
=C2=A0 =C2=A0topology and metric constraints.


[...]

3.1.1.=C2=A0 mVPN Tunnel Root Tracking

=C2=A0 =C2=A0A condition to consider that the status of a P-tunnel is up is= that
=C2=A0 =C2=A0the root of the tunnel, as determined in the x-PMSI Tunnel att= ribute,
=C2=A0 =C2=A0is reachable through unicast routing tables.=C2=A0 In this cas= e, the
=C2=A0 =C2=A0downstream PE can immediately update its UMH when the reachabi= lity
=C2=A0 =C2=A0condition changes.

=C2=A0 =C2=A0That is similar to BGP next-hop tracking for VPN routes, excep= t that
=C2=A0 =C2=A0the address considered is not the BGP next-hop address, but th= e root
=C2=A0 =C2=A0address in the x-PMSI Tunnel attribute.

=C2=A0 =C2=A0If BGP next-hop tracking is done for VPN routes and the root a= ddress
=C2=A0 =C2=A0of a given tunnel happens to be the same as the next-hop addre= ss in
=C2=A0 =C2=A0the BGP A-D Route advertising the tunnel, then checking, in un= icast
=C2=A0 =C2=A0routing tables, whether the tunnel root is reachable, will be<= br> =C2=A0 =C2=A0unnecessary duplication and thus will not bring any specific b= enefit.

<mglt>
It seems to me that x-PMSI address
designates a different interface than
the one used by the Tunnel itself. If
that is correct, such mechanisms seems
to assume that one equipment up on one
interface will be up on the other
interfaces. I have the impression that a
configuration change in a PE may end up
in the P-tunnel being down, while the PE
still being reachable though the x-PMSI
Tunnel attribute. If that is a possible
scenario, the current mechanisms may not
provide more efficient mechanism than
then those of the standard BGP.
GIM>> That is a very interesting angle, thank you. Yes, in OAM, = and in the Fault Management (FM) OAM in particular, we have to make some as= sumptions=C2=A0about the state of the remote system based on a single event= or change of state. Usually, AFAIK, operators use not a physical interface but a loopback to associate with a tunnel. Wi= th a fast IGP convergence, a loopback interface is reachable as long as the= re's a path through the network between two nodes.
<mglt>
Thanks for the clarification
</mglt>

Similarly, it is assumed the tunnel is
either up or down and the determination
of not being up if being down.=C2=A0 I am not
convinced that the two only states.
Typically services under DDoS may be
down for a small amount of time. While
this affects the network, there is not
always a clear cut between the PE being
up or down.
</mglt>
GIM>>=C2=A0 In defect detection a system often has some hysteres= is, i.e., time that the system has to wait to change its state. For example= , BFD changes state from Up to Down after the system does not receive N con= secutive packets (usually 3). As a result, in some cases, the system can be tuned to detect relatively short outages = while in others be slower and miss short-lived outages.


[...]

3.1.6.=C2=A0 BFD Discriminator Attribute

=C2=A0 =C2=A0P-tunnel status may be derived from the status of a multipoint= BFD
=C2=A0 =C2=A0session [RFC8562] whose discriminator is advertised along with= an
=C2=A0 =C2=A0x-PMSI A-D Route.

=C2=A0 =C2=A0This document defines the format and ways of using a new BGP =C2=A0 =C2=A0attribute called the "BFD Discriminator".=C2=A0 It i= s an optional
=C2=A0 =C2=A0transitive BGP attribute.=C2=A0 In Section 7.2, IANA is reques= ted to
=C2=A0 =C2=A0allocate the codepoint value (TBA2).=C2=A0 The format of this = attribute is
=C2=A0 =C2=A0shown in Figure 1.

<mglt>
I feel that the sentence "In Section ...
TBA2)." should be removed.

</mglt>
GIM>> We use this to mark where to note the allocated value. Usu= ally, this text is replaced by the RFC Editor to read=C2=A0
In Section 7.2 IANA allocated codepoint XXX.



=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A03
=C2=A0 =C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1
=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 BFD Mode=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Reserved=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=A0BFD Discriminator=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=A0Optional TLVs=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 Figure 1: Format of the BFD Discr= iminator Attribute

=C2=A0 =C2=A0Where:

=C2=A0 =C2=A0 =C2=A0 BFD Mode field is the one octet long.=C2=A0 This speci= fication defines
=C2=A0 =C2=A0 =C2=A0 the P2MP BFD Session as value 1 Section 7.2.

=C2=A0 =C2=A0 =C2=A0 Reserved field is three octets long, and the value MUS= T be zeroed
=C2=A0 =C2=A0 =C2=A0 on transmission and ignored on receipt.

=C2=A0 =C2=A0 =C2=A0 BFD Discriminator field is four octets long.





Morin, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires April = 5, 2021=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page = 7]

Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mVPN Fast Upstream Failover= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 October 2020


=C2=A0 =C2=A0 =C2=A0 Optional TLVs is the optional variable-length field th= at MAY be
=C2=A0 =C2=A0 =C2=A0 used in the BFD Discriminator attribute for future ext= ensions.
=C2=A0 =C2=A0 =C2=A0 TLVs MAY be included in a sequential or nested manner.= =C2=A0 To allow
=C2=A0 =C2=A0 =C2=A0 for TLV nesting, it is advised to define a new TLV as = a variable-
=C2=A0 =C2=A0 =C2=A0 length object.=C2=A0 Figure 2 presents the Optional TL= V format TLV that
=C2=A0 =C2=A0 =C2=A0 consists of:

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 one octet-long field of TLV 's Type value = (Section 7.3)

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 one octet-long field of the length of the Valu= e field in octets

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 variable length Value field.

=C2=A0 =C2=A0 =C2=A0 The length of a TLV MUST be multiple of four octets. <mglt>
I am wondering why the constraint on the
length is not mentioned in the paragraph
associated to the field - as opposed to
a=C2=A0 separate paragraph.

</mglt>
GIM>> There might be a slight confusion due to the use of Length= and length. Capitalized - the name of the field which value is the length = of the Value field. The last sentence refers to the overall length of a TLV= , including lengths of Type, Length and Value fields.

<mglt>
you are correct that might have confused me.=C2=A0
</mglt>

[..]

8.=C2=A0 Security Considerations

=C2=A0 =C2=A0This document describes procedures based on [RFC6513] and [RFC= 6514]
=C2=A0 =C2=A0and hence shares the security considerations respectively repr= esented
=C2=A0 =C2=A0in these specifications.

=C2=A0 =C2=A0This document uses p2mp BFD, as defined in [RFC8562], which, i= n turn,
=C2=A0 =C2=A0is based on [RFC5880].=C2=A0 Security considerations relevant = to each
=C2=A0 =C2=A0protocol are discussed in the respective protocol specificatio= ns.=C2=A0 An
=C2=A0 =C2=A0implementation that supports this specification MUST use a mec= hanism
=C2=A0 =C2=A0to control the maximum number of p2mp BFD sessions that can be= active
=C2=A0 =C2=A0at the same time.

<mglt>
At a high level view - or at least my
interpretation of it - the document
proposes a mechanism based on BFD to
detect fault in the path.=C2=A0 Upon a fault
detection a fail-over operation is
instructed using BGP. This rocedure is
expected to perform a faster fail-over
than traditional BGP convergence on
maintaining routing tables. Once the
fail over has been performed, BFD is
confirms the new path is "legitimate"
and works.

It seems correct to me that the current
protocol relies on BGP / BFD security.
That said, having BFD authentication
based on MD5 or SHA1 may suggest that
stronger primitives be recommended.
While this does not concerns the current
document, it seems to me that the
information might be relayed to routing
ADs.

What remains unclear to me - and I
assume this might be due to my lake or
expertise in routing area - is the impact
associated to performing a fail-over
both on 1) the data plane and 2) the
standard BGP way to establish routing
tables.

Regarding the data plane, I am wondering
if fail-over results in a lost of
packets for example - I suppose for
example that at least the packets in the
process of being forwarded might be
lost. I believe that providing details
on this may be good.
GIM>> You bring up a very topic for the discussion, thank you. W= ith network failure detection in place, the fail-over can be viewed as the = reaction to a network failure.=C2=A0 If that is the case, then packet loss = experienced by service due to the fail-over is the result of the network failure. Would you agree with that view? A sh= orter failure detection interval=C2=A0and faster fail-over should minimize = the packet loss and, as a result, the negative impact on the service itself= .

<mglt>
sure. If you know the network is down, then fast fail-over is definiti= vely a plus. What I think could be useful is to evaluate the cost associate= d to a fast-fail-over without any network failure.=C2=A0 This would be usef= ul for an operator to evaluate whether it should spend more time in diagnosing a network failure versus performin= g a fast-fail-over.=C2=A0
Typically, if a fast failover comes a no cost at all, one operator wou= ld maybe use one exchange to test the liveness of a node rather than 3.=C2= =A0 =C2=A0 =C2=A0=C2=A0

At that point, it seems to me that additional text coudl be added to c= haracterize the impact. These could be high level and indicative, but it se= ems to me that knowing these impacts presents some value to the operators.= =C2=A0 =C2=A0 =C2=A0=C2=A0
</mglt>

If there are any impacts I would like to
understand also in which cases the
decision to perform a failover operation
may result in more harm than the event
that has been over-interpreted. An
hypothetical scenario could be that the
non reception of a BFD packet is
interpreted as a PE being down while it
may not be correct and the PE might have
been simply under stress. A "too fast" fail-over
may over interpreted it and perform a
fail-over. If such things could happen,
an attacker could leverage a micro event
to perform network operation that are
not negligible. Another way to see that
is that an attacker might not have
direct access to the control plan, but
could use the data plan to generate a
stress and sort of control the fail
over. It seems to me that some text
might be welcome to prevent such cases
to happen. This could be guidance for
declaring a tunnel down for example.
GIM>> I agree with your scenario. Over-short detection interval = may produce a false-negative transition to the Down state in BFD and thus t= riggering the fail-over. I think that that is more an operational issue, so= mething that an operator will consider when deploying the mechanism specified in this draft. Resulting from addre= ssing RtgDir review the draft was updated to provide more guidance:
=C2=A0 =C2=A0In many cases, it is not practical to use both protection=
=C2=A0 =C2=A0methods at the same time because uncorrelated timers might cau= se
=C2=A0 =C2=A0unnecessary switchovers and destabilize the network.
<mglt>
Thanks for the feed back, It seems to me important to mention it is no= t recommended these two mechanism co-exist.=C2=A0
How to avoid false negative transition might be out of scope of the dr= aft I agree, but it seems to me worth being mentioned especially in relatio= n to the impacts associated to a fail-over.=C2=A0 In case the fast-failover= comes with no impact this becomes less of a problem for operator deploying it.
=C2=A0
</mglt>
Though the text above might not be general, I think that it also appli= es to the scenario you've presented.

Similarly, it would be good to add some
text regarding the interferences with
the non-fast forwarding fail over when
performed by the standard BGP.
Typically, my impression is that the
fast fail-over mechanism is a local
decision versus the BGP convergence that
is more global. As a result, even with
more time this two mechanisms may come
with different outcomes. One such
example to illustrate my purpose could
be the following. Note that this is only
illustrative of my purpose, and I let
you find and pick on ethat is more
appropriated.=C2=A0 =C2=A0I am thinking of a case
where a standby PE is be shared among
multiple PEs - supposing this situation
could occur.=C2=A0 Typically, if PE_1, PE_2
are shared by PE_a, ..., PE_z. In case
PE_a and PE_b are down, we expect PE_a
to switch to PE_1 and PE_b to switch to
PE_2. It seems to me that BGP would end
up in such situation while a local
decision may end up in PE_a and PE_a to
switch to PE_1.

</mglt>
GIM>> Thank you for the scenario that is very common in deployin= g protection based on the shared redundant resources. Such schemes, referre= d to as M:N protection, in addition to using mechanism detecting a network = failure, e.g., BFD, require a protocol to coordinate the switchover. This specification applies to a more special= deployment scenario where one working PE is protected by one or more stand= by PEs, i.e., 1:N protection.

<mglt>
I understand the document is addressing a 1:N scenario. That said, if = M:N scenario leverage from 1:N protection it seems to me worth raising the = issue.=C2=A0
</mglt>
--00000000000001992005b3ead4c2-- --00000000000001992105b3ead4c4 Content-Type: text/plain; charset="US-ASCII"; name="draft-ietf-bess-mvpn-fast-failover-13.txt" Content-Disposition: attachment; filename="draft-ietf-bess-mvpn-fast-failover-13.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_khf09eqt0 CgoKCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgVC4gTW9yaW4sIEVkLgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPcmFuZ2UKSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgIFIuIEtlYmxlciwgRWQuCkV4cGly ZXM6IE1heSAxNiwgMjAyMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSnVuaXBl ciBOZXR3b3JrcwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgRy4gTWlyc2t5LCBFZC4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWlRFIENvcnAuCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOb3ZlbWJlciAxMiwgMjAy MAoKCiAgICAgICAgICAgICAgICAgIE11bHRpY2FzdCBWUE4gRmFzdCBVcHN0cmVhbSBGYWlsb3Zl cgogICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtYmVzcy1tdnBuLWZhc3QtZmFpbG92ZXItMTMK CkFic3RyYWN0CgogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgbXVsdGljYXN0IFZQTiBleHRlbnNp b25zIGFuZCBwcm9jZWR1cmVzIHRoYXQKICAgYWxsb3cgZmFzdCBmYWlsb3ZlciBmb3IgdXBzdHJl YW0gZmFpbHVyZXMgYnkgYWxsb3dpbmcgZG93bnN0cmVhbSBQRXMKICAgdG8gY29uc2lkZXIgdGhl IHN0YXR1cyBvZiBQcm92aWRlci1UdW5uZWxzIChQLXR1bm5lbHMpIHdoZW4gc2VsZWN0aW5nCiAg IHRoZSB1cHN0cmVhbSBQRSBmb3IgYSBWUE4gbXVsdGljYXN0IGZsb3cuICBUaGUgZmFzdCBmYWls b3ZlciBpcwogICBlbmFibGVkIGJ5IHVzaW5nIFJGQyA4NTYyIEJGRCBmb3IgTXVsdGlwb2ludCBO ZXR3b3JrcyBhbmQgdGhlIG5ldyBCR1AKICAgQXR0cmlidXRlIC0gQkZEIERpc2NyaW1pbmF0b3Iu ICBBbHNvLCB0aGUgZG9jdW1lbnQgaW50cm9kdWNlcyBhIG5ldwogICBCR1AgQ29tbXVuaXR5LCBT dGFuZGJ5IFBFLCBleHRlbmRpbmcgQkdQIE11bHRpY2FzdCBWUE4gcm91dGluZyBzbwogICB0aGF0 IGEgQy1tdWx0aWNhc3Qgcm91dGUgY2FuIGJlIGFkdmVydGlzZWQgdG93YXJkIGEgU3RhbmRieSBV cHN0cmVhbQogICBQRS4KClN0YXR1cyBvZiBUaGlzIE1lbW8KCiAgIFRoaXMgSW50ZXJuZXQtRHJh ZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUKICAgcHJvdmlzaW9u cyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBk b2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYp LiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlCiAgIHdvcmtpbmcg ZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJu ZXQtCiAgIERyYWZ0cyBpcyBhdCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9j dXJyZW50Ly4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZv ciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2Vk LCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMg aW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRl cmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgog ICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE1heSAxNiwgMjAyMS4KCkNvcHly aWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoYykgMjAyMCBJRVRGIFRydXN0IGFuZCB0aGUgcGVy c29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyBy ZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJ RVRGIFRydXN0J3MgTGVnYWwKICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50 cwoKCgpNb3JpbiwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDE2LCAyMDIxICAgICAg ICAgICAgICAgICAgW1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIE1WUE4gRmFzdCBV cHN0cmVhbSBGYWlsb3ZlciAgICAgICAgIE5vdmVtYmVyIDIwMjAKCgogICAoaHR0cHM6Ly90cnVz dGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1 YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50 cwogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0 aW9ucyB3aXRoIHJlc3BlY3QKICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBl eHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QKICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJT RCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mCiAgIHRoZSBUcnVz dCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcwog ICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuCgpUYWJsZSBvZiBDb250 ZW50cwoKICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gICAzCiAgIDIuICBDb252ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9j dW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMwogICAgIDIuMS4gIFJlcXVpcmVt ZW50cyBMYW5ndWFnZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMKICAg ICAyLjIuICBUZXJtaW5vbG9neSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICA0CiAgICAgMi4zLiAgQWNyb255bXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAogICAzLiAgVU1IIFNlbGVjdGlvbiBCYXNlZCBv biBUdW5uZWwgU3RhdHVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAgICAzLjEuICBE ZXRlcm1pbmluZyB0aGUgU3RhdHVzIG9mIGEgVHVubmVsICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICA2CiAgICAgICAzLjEuMS4gIE1WUE4gVHVubmVsIFJvb3QgVHJhY2tpbmcgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgNwogICAgICAgMy4xLjIuICBQRS1QIFVwc3RyZWFtIExpbmsgU3Rh dHVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcKICAgICAgIDMuMS4zLiAgUDJNUCBS U1ZQLVRFIFR1bm5lbHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3CiAgICAg ICAzLjEuNC4gIExlYWYtaW5pdGlhdGVkIFAtdHVubmVscyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgOAogICAgICAgMy4xLjUuICAoQy1TLCBDLUcpIENvdW50ZXIgSW5mb3JtYXRpb24g IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgKICAgICAgIDMuMS42LiAgQkZEIERpc2NyaW1pbmF0 b3IgQXR0cmlidXRlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4CiAgICAgICAzLjEuNy4g IFBlciBQRS1DRSBMaW5rIEJGRCBEaXNjcmltaW5hdG9yICAuIC4gLiAuIC4gLiAuIC4gLiAuICAx MgogICA0LiAgU3RhbmRieSBDLW11bHRpY2FzdCBSb3V0ZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMTIKICAgICA0LjEuICBEb3duc3RyZWFtIFBFIEJlaGF2aW9yICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEzCiAgICAgNC4yLiAgVXBzdHJlYW0gUEUg QmVoYXZpb3IgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNAogICAgIDQu My4gIFJlYWNoYWJpbGl0eSBEZXRlcm1pbmF0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMTUKICAgICA0LjQuICBJbnRlci1BUyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE1CiAgICAgICA0LjQuMS4gIEludGVyLUFTIFByb2NlZHVy ZXMgZm9yIGRvd25zdHJlYW0gUEVzLCBBU0JSIEZhc3QKICAgICAgICAgICAgICAgRmFpbG92ZXIg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE2CiAgICAgICA0 LjQuMi4gIEludGVyLUFTIFByb2NlZHVyZXMgZm9yIEFTQlJzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAxNgogICA1LiAgSG90IFJvb3QgU3RhbmRieSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgMTcKICAgNi4gIER1cGxpY2F0ZSBQYWNrZXRzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE3CiAgIDcuICBJQU5BIENvbnNp ZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxOAog ICAgIDcuMS4gIFN0YW5kYnkgUEUgQ29tbXVuaXR5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgMTgKICAgICA3LjIuICBCRkQgRGlzY3JpbWluYXRvciAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE4CiAgICAgNy4zLiAgQkZEIERpc2NyaW1pbmF0 b3IgT3B0aW9uYWwgU3ViLVRMViBUeXBlIC4gLiAuIC4gLiAuIC4gLiAuICAxOQogICA4LiAgU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMjAKICAgOS4gIEFja25vd2xlZGdtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDIwCiAgIDEwLiBDb250cmlidXRvciBBZGRyZXNzZXMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMAogICAxMS4gUmVmZXJlbmNlcyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjIKICAg ICAxMS4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDIyCiAgICAgMTEuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMwogICBBdXRob3JzJyBBZGRyZXNzZXMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjMKCgoKCgoKTW9yaW4s IGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1heSAxNiwgMjAyMSAgICAgICAgICAgICAgICAg IFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBNVlBOIEZhc3QgVXBzdHJlYW0gRmFp bG92ZXIgICAgICAgICBOb3ZlbWJlciAyMDIwCgoKMS4gIEludHJvZHVjdGlvbgoKICAgSXQgaXMg YXNzdW1lZCB0aGF0IHRoZSByZWFkZXIgaXMgZmFtaWxpYXIgd2l0aCB0aGUgd29ya2luZ3Mgb2YK ICAgbXVsdGljYXN0IE1QTFMvQkdQIElQIFZQTnMgYXMgZGVzY3JpYmVkIGluIFtSRkM2NTEzXSBh bmQgW1JGQzY1MTRdLgoKICAgSW4gdGhlIGNvbnRleHQgb2YgbXVsdGljYXN0IGluIEJHUC9NUExT IFZQTnMgW1JGQzY1MTNdLCBpdCBpcwogICBkZXNpcmFibGUgdG8gcHJvdmlkZSBtZWNoYW5pc21z IGFsbG93aW5nIGZhc3QgcmVjb3Zlcnkgb2YKICAgY29ubmVjdGl2aXR5IG9uIGRpZmZlcmVudCB0 eXBlcyBvZiBmYWlsdXJlcy4gIFRoaXMgZG9jdW1lbnQgYWRkcmVzc2VzCiAgIGZhaWx1cmVzIG9m IGVsZW1lbnRzIGluIHRoZSBwcm92aWRlciBuZXR3b3JrIHRoYXQgYXJlIHVwc3RyZWFtIG9mIFBF cwogICBjb25uZWN0ZWQgdG8gVlBOIHNpdGVzIHdpdGggcmVjZWl2ZXJzLgoKICAgU2VjdGlvbiAz IGRlc2NyaWJlcyBsb2NhbCBwcm9jZWR1cmVzIGFsbG93aW5nIGFuIGVncmVzcyBQRSAoYSBQRQog ICBjb25uZWN0ZWQgdG8gYSByZWNlaXZlciBzaXRlKSB0byB0YWtlIGludG8gYWNjb3VudCB0aGUg c3RhdHVzIG9mCiAgIFAtdHVubmVscyB0byBkZXRlcm1pbmUgdGhlIFVwc3RyZWFtIE11bHRpY2Fz dCBIb3AgKFVNSCkgZm9yIGEgZ2l2ZW4KICAgKEMtUywgQy1HKS4gIE9uZSBvZiB0aGUgb3B0aW9u YWwgbWV0aG9kcyB1c2VzIFtSRkM4NTYyXSBhbmQgdGhlIG5ldwogICBCR1AgQXR0cmlidXRlIC0g QkZEIERpc2NyaW1pbmF0b3IuICBOb25lIG9mIHRoZXNlIG1ldGhvZHMgcHJvdmlkZSBhCiAgICJm YXN0IGZhaWxvdmVyIiBzb2x1dGlvbiB3aGVuIHVzZWQgYWxvbmUsIGJ1dCBjYW4gYmUgdXNlZCB0 b2dldGhlcgogICB3aXRoIHRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluIFNlY3Rpb24gNCBmb3Ig YSAiZmFzdCBmYWlsb3ZlciIKICAgc29sdXRpb24uCgogICBTZWN0aW9uIDQgZGVzY3JpYmVzIGFu IG9wdGlvbmFsIEJHUCBleHRlbnNpb24sIGEgbmV3IFN0YW5kYnkgUEUKICAgQ29tbXVuaXR5LiB0 aGF0IGNhbiBzcGVlZCB1cCBmYWlsb3ZlciBieSBub3QgcmVxdWlyaW5nIGFueSBtdWx0aWNhc3QK ICAgVlBOIChNVlBOKSByb3V0aW5nIG1lc3NhZ2UgZXhjaGFuZ2UgYXQgcmVjb3ZlcnkgdGltZS4K CiAgIFNlY3Rpb24gNSBkZXNjcmliZXMgYSAiaG90IGxlYWYgc3RhbmRieSIgbWVjaGFuaXNtIHRo YXQgY2FuIGJlIHVzZWQKICAgdG8gaW1wcm92ZSBmYWlsb3ZlciB0aW1lIGluIE1WUE4uICBUaGUg YXBwcm9hY2ggY29tYmluZXMgbWVjaGFuaXNtcwogICBkZWZpbmVkIGluIFNlY3Rpb24gMyBhbmQg U2VjdGlvbiA0IGhhcyBzaW1pbGFyaXRpZXMgd2l0aCB0aGUgc29sdXRpb24KICAgZGVzY3JpYmVk IGluIFtSRkM3NDMxXSB0byBpbXByb3ZlIGZhaWxvdmVyIHRpbWVzIHdoZW4gUElNIHJvdXRpbmcg aXMKICAgdXNlZCBpbiBhIG5ldHdvcmsgZ2l2ZW4gc29tZSB0b3BvbG9neSBhbmQgbWV0cmljIGNv bnN0cmFpbnRzLgoKICAgVGhlIHByb2NlZHVyZXMgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQg YXJlIG9wdGlvbmFsIHRvIGVuYWJsZSBhbgogICBvcGVyYXRvciB0byBwcm92aWRlIHByb3RlY3Rp b24gZm9yIG11bHRpY2FzdCBzZXJ2aWNlcyBpbiBCR1AvTVBMUyBJUAogICBWUE5zLiAgQW4gb3Bl cmF0b3Igd291bGQgZW5hYmxlIHRoZXNlIG1lY2hhbmlzbXMgdXNpbmcgYSBtZXRob2QKICAgZGlz Y3Vzc2VkIGluIFNlY3Rpb24gMyBpbiBjb21iaW5hdGlvbiB3aXRoIHRoZSByZWR1bmRhbmN5IHBy b3ZpZGVkIGJ5CiAgIGEgc3RhbmRieSBQRSBjb25uZWN0ZWQgdG8gdGhlIHNvdXJjZSBvZiB0aGUg bXVsdGljYXN0IGZsb3csIGFuZCBpdCBpcwogICBhc3N1bWVkIHRoYXQgYWxsIFBFcyBpbiB0aGUg bmV0d29yayB3b3VsZCBzdXBwb3J0IHRoZXNlIG1lY2hhbmlzbXMKICAgZm9yIHRoZSBwcm9jZWR1 cmVzIHRvIHdvcmsuICBJbiB0aGUgY2FzZSB0aGF0IGEgQkdQIGltcGxlbWVudGF0aW9uCiAgIGRv ZXMgbm90IHJlY29nbml6ZSBvciBpcyBjb25maWd1cmVkIHRvIG5vdCBzdXBwb3J0IHRoZSBleHRl bnNpb25zCiAgIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCwgaXQgd2lsbCBjb250aW51ZSB0byBw cm92aWRlIHRoZSBtdWx0aWNhc3QKICAgc2VydmljZSwgYXMgZGVzY3JpYmVkIGluIFtSRkM2NTEz XS4KCjIuICBDb252ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9jdW1lbnQKCjIuMS4gIFJlcXVpcmVt ZW50cyBMYW5ndWFnZQoKICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFV SVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAi UkVDT01NRU5ERUQiLCAiTk9UIFJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZAogICAiT1BUSU9OQUwi IGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBC Q1AKCgoKTW9yaW4sIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1heSAxNiwgMjAyMSAgICAg ICAgICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBNVlBOIEZhc3Qg VXBzdHJlYW0gRmFpbG92ZXIgICAgICAgICBOb3ZlbWJlciAyMDIwCgoKICAgMTQgW1JGQzIxMTld IFtSRkM4MTc0XSB3aGVuLCBhbmQgb25seSB3aGVuLCB0aGV5IGFwcGVhciBpbiBhbGwKICAgY2Fw aXRhbHMsIGFzIHNob3duIGhlcmUuCgoyLjIuICBUZXJtaW5vbG9neQoKICAgVGhlIHRlcm1pbm9s b2d5IHVzZWQgaW4gdGhpcyBkb2N1bWVudCBpcyB0aGUgdGVybWlub2xvZ3kgZGVmaW5lZCBpbgog ICBbUkZDNjUxM10gYW5kIFtSRkM2NTE0XS4KCiAgIFRoZSB0ZXJtICd1cHN0cmVhbScgKGxvd2Vy IGNhc2UpIHRocm91Z2hvdXQgdGhpcyBkb2N1bWVudCByZWZlcnMgdG8KICAgbGlua3MgYW5kIG5v ZGVzIHRoYXQgYXJlIHVwc3RyZWFtIHRvIGEgUEUgY29ubmVjdGVkIHRvIFZQTiBzaXRlcyB3aXRo CiAgIHJlY2VpdmVycyBvZiBhIG11bHRpY2FzdCBmbG93LgoKICAgVGhlIHRlcm0gJ1Vwc3RyZWFt JyAoY2FwaXRhbGl6ZWQpIHRocm91Z2hvdXQgdGhpcyBkb2N1bWVudCByZWZlcnMgdG8KICAgYSBQ RSBvciBhbiBBdXRvbm9tb3VzIFN5c3RlbSBCb3JkZXIgUm91dGVyIChBU0JSKSBhdCB3aGljaCAo UyxHKSBvcgogICAoKixHKSBkYXRhIHBhY2tldHMgZW50ZXIgdGhlIFZQTiBiYWNrYm9uZSBvciB0 aGUgbG9jYWwgQVMgd2hlbgogICB0cmF2ZWxpbmcgdGhyb3VnaCB0aGUgVlBOIGJhY2tib25lLgoK Mi4zLiAgQWNyb255bXMKCiAgIFBNU0k6IFAtTXVsdGljYXN0IFNlcnZpY2UgSW50ZXJmYWNlCgog ICBJLVBNU0k6IEluY2x1c2l2ZSBQTVNJCgogICBTLVBNU0k6IFNlbGVjdGl2ZSBQTVNJCgogICB4 LVBNU0k6IEVpdGhlciBhbiBJLVBNU0kgb3IgYW4gUy1QTVNJCgogICBQLXR1bm5lbDogUHJvdmlk ZXItVHVubmVscwoKICAgVU1IOiBVcHN0cmVhbSBNdWx0aWNhc3QgSG9wCgogICBWUE46IFZpcnR1 YWwgUHJpdmF0ZSBOZXR3b3JrCgogICBNVlBOOiBNdWx0aWNhc3QgVlBOCgogICBSRDogUm91dGUg RGlzdGluZ3Vpc2hlcgoKICAgUlA6IFJlbmRlenZvdXMgUG9pbnQKCiAgIE5MUkk6IE5ldHdvcmsg TGF5ZXIgUmVhY2hhYmlsaXR5IEluZm9ybWF0aW9uCgogICBWUkY6IFZQTiBSb3V0aW5nIGFuZCBG b3J3YXJkaW5nIFRhYmxlCgogICBNRUQ6IE11bHRpLUV4aXQgRGlzY3JpbWluYXRvcgoKICAgUDJN UDogUG9pbnQtdG8tTXVsdGlwb2ludAoKCgoKCk1vcmluLCBldCBhbC4gICAgICAgICAgICAgRXhw aXJlcyBNYXkgMTYsIDIwMjEgICAgICAgICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURy YWZ0ICAgICAgICAgTVZQTiBGYXN0IFVwc3RyZWFtIEZhaWxvdmVyICAgICAgICAgTm92ZW1iZXIg MjAyMAoKCjMuICBVTUggU2VsZWN0aW9uIEJhc2VkIG9uIFR1bm5lbCBTdGF0dXMKCiAgIFNlY3Rp b24gNS4xIG9mIFtSRkM2NTEzXSBkZXNjcmliZXMgcHJvY2VkdXJlcyB1c2VkIGJ5IGEgbXVsdGlj YXN0IFZQTgogICBkb3duc3RyZWFtIFBFIHRvIGRldGVybWluZSB0aGUgVXBzdHJlYW0gTXVsdGlj YXN0IEhvcCAoVU1IKSBmb3IgYQogICBnaXZlbiAoQy1TLCBDLUcpLgoKICAgRm9yIGEgZ2l2ZW4g ZG93bnN0cmVhbSBQRSBhbmQgYSBnaXZlbiBWUkYsIHRoZSBQLXR1bm5lbCBjb3JyZXNwb25kaW5n CiAgIHRvIGEgZ2l2ZW4gVXBzdHJlYW0gUEUgZm9yIGEgZ2l2ZW4gKEMtUywgQy1HKSBzdGF0ZSBp cyB0aGUgUy1QTVNJCiAgIHR1bm5lbCBhZHZlcnRpc2VkIGJ5IHRoYXQgVXBzdHJlYW0gUEUgZm9y IHRoaXMgKEMtUywgQy1HKSBhbmQKICAgaW1wb3J0ZWQgaW50byB0aGF0IFZSRiwgb3IgaWYgdGhl cmUgaXNuJ3QgYW55IHN1Y2ggUy1QTVNJLCB0aGUgSS1QTVNJCiAgIHR1bm5lbCBhZHZlcnRpc2Vk IGJ5IHRoYXQgUEUgYW5kIGltcG9ydGVkIGludG8gdGhhdCBWUkYuCgogICBUaGUgcHJvY2VkdXJl IGRlc2NyaWJlZCBoZXJlIGlzIGFuIE9QVElPTkFMIHByb2NlZHVyZSB0aGF0IGlzIGJhc2VkCiAg IG9uIGEgZG93bnN0cmVhbSBQRSB0YWtpbmcgaW50byBhY2NvdW50IHRoZSBzdGF0dXMgb2YgUC10 dW5uZWxzIHJvb3RlZAogICBhdCBlYWNoIHBvc3NpYmxlIFVwc3RyZWFtIFBFLCBmb3IgaW5jbHVk aW5nIG9yIG5vdCBpbmNsdWRpbmcgZWFjaAogICBnaXZlbiBQRSBpbiB0aGUgbGlzdCBvZiBjYW5k aWRhdGUgVU1IcyBmb3IgYSBnaXZlbiAoQy1TLCBDLUcpIHN0YXRlLgogICBJZiBpdCBpcyBub3Qg cG9zc2libGUgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgYSBQLXR1bm5lbCdzIGN1cnJlbnQKICAgc3Rh dHVzIGlzIFVwLCB0aGUgc3RhdGUgc2hhbGwgYmUgY29uc2lkZXJlZCAibm90IGtub3duIHRvIGJl IERvd24iLAogICBhbmQgaXQgbWF5IGJlIHRyZWF0ZWQgYXMgaWYgaXQgaXMgVXAgc28gdGhhdCBh dHRlbXB0cyB0byB1c2UgdGhlCiAgIHR1bm5lbCBhcmUgYWNjZXB0YWJsZS4gIFRoZSByZXN1bHQg aXMgdGhhdCwgaWYgYSBQLXR1bm5lbCBpcyBEb3duCiAgIChzZWUgU2VjdGlvbiAzLjEpLCB0aGUg UEUgdGhhdCBpcyB0aGUgcm9vdCBvZiB0aGUgUC10dW5uZWwgd2lsbCBub3QKICAgYmUgY29uc2lk ZXJlZCBmb3IgVU1IIHNlbGVjdGlvbi4gIFRoaXMgd2lsbCByZXN1bHQgaW4gdGhlIGRvd25zdHJl YW0KICAgUEUgZmFpbGluZyBvdmVyIHRvIHVzZSB0aGUgbmV4dCBVcHN0cmVhbSBQRSBpbiB0aGUg bGlzdCBvZgogICBjYW5kaWRhdGVzLiAgU29tZSBkb3duc3RyZWFtIFBFcyBjb3VsZCBhcnJpdmUg YXQgYSBkaWZmZXJlbnQKICAgY29uY2x1c2lvbiByZWdhcmRpbmcgdGhlIHR1bm5lbCdzIHN0YXRl IGJlY2F1c2UgdGhlIGZhaWx1cmUgaW1wYWN0cwogICBvbmx5IGEgc3Vic2V0IG9mIGJyYW5jaGVz LiAgQmVjYXVzZSBvZiB0aGF0LCB0aGUgcHJvY2VkdXJlcyBvZgogICBTZWN0aW9uIDkuMS4xIG9m IFtSRkM2NTEzXSBhcmUgYXBwbGljYWJsZSB3aGVuIHVzaW5nIEktUE1TSQogICBQLXR1bm5lbHMu ICBUaGF0IGRvY3VtZW50IGlzIGEgZm91bmRhdGlvbiBmb3IgdGhpcyBkb2N1bWVudCwgYW5kIGl0 cwogICBwcm9jZXNzZXMgYWxsIGFwcGx5IGhlcmUuICBTZWN0aW9uIDkuMS4xIG1hbmRhdGVzIHRo ZSB1c2Ugb2Ygc3BlY2lmaWMKICAgcHJvY2VkdXJlcyBmb3Igc2VuZGluZyBpbnRyYS1BUyBJLVBN U0kgQS1EIFJvdXRlcy4KCiAgIFRoZXJlIGFyZSB0aHJlZSBvcHRpb25zIHNwZWNpZmllZCBpbiBT ZWN0aW9uIDUuMSBvZiBbUkZDNjUxM10gZm9yIGEKICAgZG93bnN0cmVhbSBQRSB0byBzZWxlY3Qg YW4gVXBzdHJlYW0gUEUuCgogICBvICBUaGUgZmlyc3QgdHdvIG9wdGlvbnMgc2VsZWN0IHRoZSBV cHN0cmVhbSBQRSBmcm9tIGEgY2FuZGlkYXRlIFBFCiAgICAgIHNldCBlaXRoZXIgYmFzZWQgb24g YW4gSVAgYWRkcmVzcyBvciBhIGhhc2hpbmcgYWxnb3JpdGhtLiAgV2hlbgogICAgICB1c2VkIHRv Z2V0aGVyIHdpdGggdGhlIG9wdGlvbmFsIHByb2NlZHVyZSBvZiBjb25zaWRlcmluZyB0aGUKICAg ICAgUC10dW5uZWwgc3RhdHVzIGFzIGluIHRoaXMgZG9jdW1lbnQsIGEgY2FuZGlkYXRlIFVwc3Ry ZWFtIFBFIGlzCiAgICAgIGluY2x1ZGVkIGluIHRoZSBzZXQgaWYgaXQgZWl0aGVyOgoKICAgICAg QS4gIGFkdmVydGlzZXMgYW4geC1QTVNJIGJvdW5kIHRvIGEgdHVubmVsLCB3aGVyZSB0aGUgc3Bl Y2lmaWVkCiAgICAgICAgICB0dW5uZWwncyBzdGF0ZSBpcyBub3Qga25vd24gdG8gYmUgRG93biwg b3IsCgogICAgICBCLiAgZG9lcyBub3QgYWR2ZXJ0aXNlIGFueSB4LVBNU0kgYXBwbGljYWJsZSB0 byB0aGUgZ2l2ZW4gKEMtUywKICAgICAgICAgIEMtRykgYnV0IGhhcyBhc3NvY2lhdGVkIGEgVlJG IFJvdXRlIEltcG9ydCBCR1AgYXR0cmlidXRlIHRvCiAgICAgICAgICB0aGUgdW5pY2FzdCBWUE4g cm91dGUgZm9yIFMuICBUaGF0IGlzIG5lY2Vzc2FyeSB0byBhdm9pZAogICAgICAgICAgaW5jb3Jy ZWN0bHkgaW52YWxpZGF0aW5nIGEgVU1IIFBFIHRoYXQgd291bGQgdXNlIGEgcG9saWN5CiAgICAg ICAgICB3aGVyZSBubyBJLVBNU0kgaXMgYWR2ZXJ0aXNlZCBmb3IgYSBnaXZlbiBWUkYgYW5kIHdo ZXJlIG9ubHkKCgoKTW9yaW4sIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1heSAxNiwgMjAy MSAgICAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBNVlBO IEZhc3QgVXBzdHJlYW0gRmFpbG92ZXIgICAgICAgICBOb3ZlbWJlciAyMDIwCgoKICAgICAgICAg IFMtUE1TSSBhcmUgdXNlZC4gIFRoZSBTLVBNU0kgY2FuIGJlIGFkdmVydGlzZWQgb25seSBhZnRl ciB0aGUKICAgICAgICAgIFVwc3RyZWFtIFBFIHJlY2VpdmVzIGEgQy1tdWx0aWNhc3Qgcm91dGUg Zm9yIChDLVMsIEMtRykvKEMtKiwKICAgICAgICAgIEMtRykgdG8gYmUgY2FycmllZCBvdmVyIHRo ZSBhZHZlcnRpc2VkIFMtUE1TSS4KCiAgICAgIElmIHRoZSByZXN1bHRpbmcgY2FuZGlkYXRlIHNl dCBpcyBlbXB0eSwgdGhlbiB0aGUgcHJvY2VkdXJlIGlzCiAgICAgIHJlcGVhdGVkIHdpdGhvdXQg Y29uc2lkZXJpbmcgdGhlIFAtdHVubmVsIHN0YXR1cy4KCiAgIG8gIFRoZSB0aGlyZCBvcHRpb24g dXNlcyB0aGUgaW5zdGFsbGVkIFVNSCBSb3V0ZSAoaS5lLiwgdGhlICJiZXN0IgogICAgICByb3V0 ZSB0b3dhcmRzIHRoZSBDLXJvb3QpIGFzIHRoZSBTZWxlY3RlZCBVTUggUm91dGUsIGFuZCBpdHMK ICAgICAgb3JpZ2luYXRpbmcgUEUgaXMgdGhlIHNlbGVjdGVkIFVwc3RyZWFtIFBFLiAgV2l0aCB0 aGUgb3B0aW9uYWwKICAgICAgcHJvY2VkdXJlIG9mIGNvbnNpZGVyaW5nIFAtdHVubmVsIHN0YXR1 cyBhcyBpbiB0aGlzIGRvY3VtZW50LCB0aGUKICAgICAgU2VsZWN0ZWQgVU1IIFJvdXRlIGlzIHRo ZSBiZXN0IG9uZSBhbW9uZyB0aG9zZSB3aG9zZSBvcmlnaW5hdGluZwogICAgICBQRSdzIFAtdHVu bmVsIGlzIG5vdCAiZG93biIuICBJZiB0aGF0IGRvZXMgbm90IGV4aXN0LCB0aGUKICAgICAgaW5z dGFsbGVkIFVNSCBSb3V0ZSBpcyBzZWxlY3RlZCByZWdhcmRsZXNzIG9mIHRoZSBQLXR1bm5lbCBz dGF0dXMuCgozLjEuICBEZXRlcm1pbmluZyB0aGUgU3RhdHVzIG9mIGEgVHVubmVsCgogICBEaWZm ZXJlbnQgZmFjdG9ycyBjYW4gYmUgY29uc2lkZXJlZCB0byBkZXRlcm1pbmUgdGhlICJzdGF0dXMi IG9mIGEKICAgUC10dW5uZWwgYW5kIGFyZSBkZXNjcmliZWQgaW4gdGhlIGZvbGxvd2luZyBzdWIt c2VjdGlvbnMuICBUaGUKICAgb3B0aW9uYWwgcHJvY2VkdXJlcyBkZXNjcmliZWQgaW4gdGhpcyBz ZWN0aW9uIGFsc28gaGFuZGxlIHRoZSBjYXNlCiAgIHRoZSBkb3duc3RyZWFtIFBFcyBkbyBub3Qg YWxsIGFwcGx5IHRoZSBzYW1lIHJ1bGVzIHRvIGRlZmluZSB3aGF0IHRoZQogICBzdGF0dXMgb2Yg YSBQLXR1bm5lbCBpcyAocGxlYXNlIHNlZSBTZWN0aW9uIDYpLCBhbmQgc29tZSBvZiB0aGVtIHdp bGwKICAgcHJvZHVjZSBhIHJlc3VsdCB0aGF0IG1heSBiZSBkaWZmZXJlbnQgZm9yIGRpZmZlcmVu dCBkb3duc3RyZWFtIFBFcy4KICAgVGh1cywgdGhlICJzdGF0dXMiIG9mIGEgUC10dW5uZWwgaW4g dGhpcyBzZWN0aW9uIGlzIG5vdCBhCiAgIGNoYXJhY3RlcmlzdGljIG9mIHRoZSB0dW5uZWwgaW4g aXRzZWxmLCBidXQgaXMgdGhlIHR1bm5lbCBzdGF0dXMsIGFzCiAgIHNlZW4gZnJvbSBhIHBhcnRp Y3VsYXIgZG93bnN0cmVhbSBQRS4gIEFkZGl0aW9uYWxseSwgc29tZSBvZiB0aGUKICAgZm9sbG93 aW5nIG1ldGhvZHMgZGV0ZXJtaW5lIHRoZSBhYmlsaXR5IG9mIGEgZG93bnN0cmVhbSBQRSB0byBy ZWNlaXZlCiAgIHRyYWZmaWMgb24gdGhlIFAtdHVubmVsIGFuZCBub3Qgc3BlY2lmaWNhbGx5IG9u IHRoZSBzdGF0dXMgb2YgdGhlCiAgIFAtdHVubmVsIGl0c2VsZi4gIFRoYXQgY291bGQgYmUgcmVm ZXJyZWQgdG8gYXMgIlAtdHVubmVsIHJlY2VwdGlvbgogICBzdGF0dXMiLCBidXQgZm9yIHNpbXBs aWNpdHksIHdlIHdpbGwgdXNlIHRoZSB0ZXJtaW5vbG9neSBvZiBQLXR1bm5lbAogICAic3RhdHVz IiBmb3IgYWxsIG9mIHRoZXNlIG1ldGhvZHMuCgogICBEZXBlbmRpbmcgb24gdGhlIGNyaXRlcmlh IHVzZWQgdG8gZGV0ZXJtaW5lIHRoZSBzdGF0dXMgb2YgYSBQLXR1bm5lbCwKICAgdGhlcmUgbWF5 IGJlIGFuIGludGVyYWN0aW9uIHdpdGggYW5vdGhlciByZXNpbGllbmN5IG1lY2hhbmlzbSB1c2Vk CiAgIGZvciB0aGUgUC10dW5uZWwgaXRzZWxmLCBhbmQgdGhlIFVNSCB1cGRhdGUgbWF5IGhhcHBl biBpbW1lZGlhdGVseSBvcgogICBtYXkgbmVlZCB0byBiZSBkZWxheWVkLiAgRWFjaCBwYXJ0aWN1 bGFyIGNhc2UgaXMgY292ZXJlZCBpbiBlYWNoCiAgIHNlcGFyYXRlIHN1Yi1zZWN0aW9uIGJlbG93 LgoKICAgQWxsIG1ldGhvZHMgZGVzY3JpYmVkIGluIHRoaXMgc2VjdGlvbiBtYXkgcHJvZHVjZSBm YWxzZS1uZWdhdGl2ZQogICBzdGF0ZSBjaGFuZ2VzIHRoYXQgY2FuIGJlIHRoZSB0cmlnZ2VyIGZv ciBhbiB1bm5lY2Vzc2FyeSBmYWlsb3ZlcgogICBuZWdhdGl2ZWx5IGltcGFjdGluZyB0aGUgbXVs dGljYXN0IHNlcnZpY2UgcHJvdmlkZWQgYnkgdGhlIFZQTi4gIEFuCiAgIG9wZXJhdG9yIGV4cGVj dGVkIHRvIGNvbnNpZGVyIHRoZSBuZXR3b3JrIGVudmlyb25tZW50IGFuZCB1c2UKICAgYXZhaWxh YmxlIGNvbnRyb2xzIG9mIHRoZSBtZWNoYW5pc20gdXNlZCB0byBkZXRlcm1pbmUgdGhlIHN0YXR1 cyBvZiBhCiAgIFAtdHVubmVsLgoKICAgQW4gaW1wbGVtZW50YXRpb24gbWF5IHN1cHBvcnQgYW55 IGNvbWJpbmF0aW9uIG9mIHRoZSBtZXRob2RzCiAgIGRlc2NyaWJlZCBpbiB0aGlzIHNlY3Rpb24g YW5kIHByb3ZpZGUgYSBuZXR3b3JrIG9wZXJhdG9yIHdpdGggY29udHJvbAogICB0byBjaG9vc2Ug d2hpY2ggb25lIHRvIHVzZSBpbiB0aGUgcGFydGljdWxhciBkZXBsb3ltZW50LgoKCgpNb3Jpbiwg ZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDE2LCAyMDIxICAgICAgICAgICAgICAgICAg W1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIE1WUE4gRmFzdCBVcHN0cmVhbSBGYWls b3ZlciAgICAgICAgIE5vdmVtYmVyIDIwMjAKCgozLjEuMS4gIE1WUE4gVHVubmVsIFJvb3QgVHJh Y2tpbmcKCiAgIEEgY29uZGl0aW9uIHRvIGNvbnNpZGVyIHRoYXQgdGhlIHN0YXR1cyBvZiBhIFAt dHVubmVsIGlzIFVwIGlzIHRoYXQKICAgdGhlIHJvb3Qgb2YgdGhlIHR1bm5lbCwgYXMgZGV0ZXJt aW5lZCBpbiB0aGUgeC1QTVNJIFR1bm5lbCBhdHRyaWJ1dGUsCiAgIGlzIHJlYWNoYWJsZSB0aHJv dWdoIHVuaWNhc3Qgcm91dGluZyB0YWJsZXMuICBJbiB0aGlzIGNhc2UsIHRoZQogICBkb3duc3Ry ZWFtIFBFIGNhbiBpbW1lZGlhdGVseSB1cGRhdGUgaXRzIFVNSCB3aGVuIHRoZSByZWFjaGFiaWxp dHkKICAgY29uZGl0aW9uIGNoYW5nZXMuCgogICBUaGF0IGlzIHNpbWlsYXIgdG8gQkdQIG5leHQt aG9wIHRyYWNraW5nIGZvciBWUE4gcm91dGVzLCBleGNlcHQgdGhhdAogICB0aGUgYWRkcmVzcyBj b25zaWRlcmVkIGlzIG5vdCB0aGUgQkdQIG5leHQtaG9wIGFkZHJlc3MsIGJ1dCB0aGUgcm9vdAog ICBhZGRyZXNzIGluIHRoZSB4LVBNU0kgVHVubmVsIGF0dHJpYnV0ZS4KCiAgIElmIEJHUCBuZXh0 LWhvcCB0cmFja2luZyBpcyBkb25lIGZvciBWUE4gcm91dGVzIGFuZCB0aGUgcm9vdCBhZGRyZXNz CiAgIG9mIGEgZ2l2ZW4gdHVubmVsIGhhcHBlbnMgdG8gYmUgdGhlIHNhbWUgYXMgdGhlIG5leHQt aG9wIGFkZHJlc3MgaW4KICAgdGhlIEJHUCBBLUQgUm91dGUgYWR2ZXJ0aXNpbmcgdGhlIHR1bm5l bCwgdGhlbiBjaGVja2luZywgaW4gdW5pY2FzdAogICByb3V0aW5nIHRhYmxlcywgd2hldGhlciB0 aGUgdHVubmVsIHJvb3QgaXMgcmVhY2hhYmxlLCB3aWxsIGJlCiAgIHVubmVjZXNzYXJ5IGR1cGxp Y2F0aW9uIGFuZCB0aHVzIHdpbGwgbm90IGJyaW5nIGFueSBzcGVjaWZpYyBiZW5lZml0LgoKMy4x LjIuICBQRS1QIFVwc3RyZWFtIExpbmsgU3RhdHVzCgogICBBIGNvbmRpdGlvbiB0byBjb25zaWRl ciBhIHR1bm5lbCBzdGF0dXMgYXMgVXAgY2FuIGJlIHRoYXQgdGhlIGxhc3QtCiAgIGhvcCBsaW5r IG9mIHRoZSBQLXR1bm5lbCBpcyBVcC4gIENvbnZlcnNlbHksIGlmIHRoZSBsYXN0LWhvcCBsaW5r IG9mCiAgIHRoZSBQLXR1bm5lbCBpcyBEb3duIHRoZW4gdGhpcyBjYW4gYmUgdGFrZW4gYXMgYW4g aW5kaWNhdGlvbiB0aGF0IHRoZQogICBQLXR1bm5lbCBpcyBEb3duLgoKICAgVXNpbmcgdGhpcyBt ZXRob2Qgd2hlbiBhIGZhc3QgcmVzdG9yYXRpb24gbWVjaGFuaXNtIChzdWNoIGFzIE1QTFMgRlJS CiAgIFtSRkM0MDkwXSkgaXMgaW4gcGxhY2UgZm9yIHRoZSBsaW5rIHJlcXVpcmVzIGNhcmVmdWwg Y29uc2lkZXJhdGlvbgogICBhbmQgY29vcmRpbmF0aW9uIG9mIGRlZmVjdCBkZXRlY3Rpb24gaW50 ZXJ2YWxzIGZvciB0aGUgbGluayBhbmQgdGhlCiAgIHR1bm5lbC4gIEluIG1hbnkgY2FzZXMsIGl0 IGlzIG5vdCBwcmFjdGljYWwgdG8gdXNlIGJvdGggcHJvdGVjdGlvbgogICBtZXRob2RzIGF0IHRo ZSBzYW1lIHRpbWUgYmVjYXVzZSB1bmNvcnJlbGF0ZWQgdGltZXJzIG1pZ2h0IGNhdXNlCiAgIHVu bmVjZXNzYXJ5IHN3aXRjaG92ZXJzIGFuZCBkZXN0YWJpbGl6ZSB0aGUgbmV0d29yay4KCjMuMS4z LiAgUDJNUCBSU1ZQLVRFIFR1bm5lbHMKCiAgIEZvciBQLXR1bm5lbHMgb2YgdHlwZSBQMk1QIE1Q TFMtVEUsIHRoZSBzdGF0dXMgb2YgdGhlIFAtdHVubmVsIGlzCiAgIGNvbnNpZGVyZWQgVXAgaWYg dGhlIHN1Yi1MU1AgdG8gdGhpcyBkb3duc3RyZWFtIFBFIGlzIGluIHRoZSBVcAogICBzdGF0ZS4g IFRoZSBkZXRlcm1pbmF0aW9uIG9mIHdoZXRoZXIgYSBQMk1QIFJTVlAtVEUgTFNQIGlzIGluIHRo ZSBVcAogICBzdGF0ZSByZXF1aXJlcyBQYXRoIGFuZCBSZXN2IHN0YXRlIGZvciB0aGUgTFNQIGFu ZCBpcyBiYXNlZCBvbgogICBwcm9jZWR1cmVzIHNwZWNpZmllZCBpbiBbUkZDNDg3NV0uICBBcyBh IHJlc3VsdCwgdGhlIGRvd25zdHJlYW0gUEUKICAgY2FuIGltbWVkaWF0ZWx5IHVwZGF0ZSBpdHMg VU1IIHdoZW4gdGhlIHJlYWNoYWJpbGl0eSBjb25kaXRpb24KICAgY2hhbmdlcy4KCiAgIFdoZW4g dXNpbmcgdGhpcyBtZXRob2QgYW5kIGlmIHRoZSBzaWduYWxpbmcgc3RhdGUgZm9yIGEgUDJNUCBU RSBMU1AKICAgaXMgcmVtb3ZlZCAoZS5nLiwgaWYgdGhlIGluZ3Jlc3Mgb2YgdGhlIFAyTVAgVEUg TFNQIHNlbmRzIGEgUGF0aFRlYXIKICAgbWVzc2FnZSkgb3IgdGhlIFAyTVAgVEUgTFNQIGNoYW5n ZXMgc3RhdGUgZnJvbSBVcCB0byBEb3duIGFzCiAgIGRldGVybWluZWQgYnkgcHJvY2VkdXJlcyBp biBbUkZDNDg3NV0sIHRoZSBzdGF0dXMgb2YgdGhlCiAgIGNvcnJlc3BvbmRpbmcgUC10dW5uZWwg TVVTVCBiZSByZS1ldmFsdWF0ZWQuICBJZiB0aGUgUC10dW5uZWwKCgoKCk1vcmluLCBldCBhbC4g ICAgICAgICAgICAgRXhwaXJlcyBNYXkgMTYsIDIwMjEgICAgICAgICAgICAgICAgICBbUGFnZSA3 XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgTVZQTiBGYXN0IFVwc3RyZWFtIEZhaWxvdmVyICAg ICAgICAgTm92ZW1iZXIgMjAyMAoKCiAgIHRyYW5zaXRpb25zIGZyb20gVXAgdG8gRG93biBzdGF0 ZSwgdGhlIFVwc3RyZWFtIFBFIHRoYXQgaXMgdGhlCiAgIGluZ3Jlc3Mgb2YgdGhlIFAtdHVubmVs IE1VU1QgTk9UIGJlIGNvbnNpZGVyZWQgYSB2YWxpZCBVTUguCgozLjEuNC4gIExlYWYtaW5pdGlh dGVkIFAtdHVubmVscwoKICAgQW4gVXBzdHJlYW0gUEUgU0hPVUxEIGJlIHJlbW92ZWQgZnJvbSB0 aGUgVU1IIGNhbmRpZGF0ZSBsaXN0IGZvciBhCiAgIGdpdmVuIChDLVMsIEMtRykgaWYgdGhlIFAt dHVubmVsIChJLVBNU0kgb3IgUy1QTVNJKSBmb3IgdGhpcyAoUywgRykKICAgaXMgbGVhZi10cmln Z2VyZWQgKFBJTSwgbUxEUCksIGJ1dCBmb3Igc29tZSByZWFzb24sIGludGVybmFsIHRvIHRoZQog ICBwcm90b2NvbCwgdGhlIHVwc3RyZWFtIG9uZS1ob3AgYnJhbmNoIG9mIHRoZSB0dW5uZWwgZnJv bSBQIHRvIFBFCiAgIGNhbm5vdCBiZSBidWlsdC4gIEFzIGEgcmVzdWx0LCB0aGUgZG93bnN0cmVh bSBQRSBjYW4gaW1tZWRpYXRlbHkKICAgdXBkYXRlIGl0cyBVTUggd2hlbiB0aGUgcmVhY2hhYmls aXR5IGNvbmRpdGlvbiBjaGFuZ2VzLgoKMy4xLjUuICAoQy1TLCBDLUcpIENvdW50ZXIgSW5mb3Jt YXRpb24KCiAgIEluIGNhc2VzLCB3aGVyZSB0aGUgZG93bnN0cmVhbSBub2RlIGNhbiBiZSBjb25m aWd1cmVkIHNvIHRoYXQgdGhlCiAgIG1heGltdW0gaW50ZXItcGFja2V0IHRpbWUgaXMga25vd24g Zm9yIGFsbCB0aGUgbXVsdGljYXN0IGZsb3dzIG1hcHBlZAogICBvbiBhIFAtdHVubmVsLCB0aGUg bG9jYWwgcGVyLShDLVMsIEMtRykgdHJhZmZpYyBjb3VudGVyIGluZm9ybWF0aW9uCiAgIGZvciB0 cmFmZmljIHJlY2VpdmVkIG9uIHRoaXMgUC10dW5uZWwgY2FuIGJlIHVzZWQgdG8gZGV0ZXJtaW5l IHRoZQogICBzdGF0dXMgb2YgdGhlIFAtdHVubmVsLgoKICAgV2hlbiBzdWNoIGEgcHJvY2VkdXJl IGlzIHVzZWQsIGluIHRoZSBjb250ZXh0IHdoZXJlIGZhc3QgcmVzdG9yYXRpb24KICAgbWVjaGFu aXNtcyBhcmUgdXNlZCBmb3IgdGhlIFAtdHVubmVscywgYSBjb25maWd1cmFibGUgdGltZXIgTVVT VCBiZQogICBzZXQgb24gdGhlIGRvd25zdHJlYW0gUEUgdG8gd2FpdCBiZWZvcmUgdXBkYXRpbmcg dGhlIFVNSCwgdG8gbGV0IHRoZQogICBQLXR1bm5lbCByZXN0b3JhdGlvbiBtZWNoYW5pc20gdG8g ZXhlY3V0ZSBpdHMgYWN0aW9ucy4gIEFuCiAgIGltcGxlbWVudGF0aW9uIFNIT1VMRCB1c2UgdGhy ZWUgc2Vjb25kcyBhcyB0aGUgZGVmYXVsdCB2YWx1ZSBmb3IgdGhpcwogICB0aW1lci4KCiAgIElu IGNhc2VzIHdoZXJlIHRoaXMgbWVjaGFuaXNtIGlzIHVzZWQgaW4gY29uanVuY3Rpb24gd2l0aCB0 aGUgbWV0aG9kCiAgIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUsIG5vIHByaW9yIGtub3dsZWRnZSBv ZiB0aGUgcmF0ZSBvZiB0aGUKICAgbXVsdGljYXN0IHN0cmVhbXMgaXMgcmVxdWlyZWQ7IGRvd25z dHJlYW0gUEVzIGNhbiBjb21wYXJlIHJlY2VwdGlvbgogICBvbiB0aGUgdHdvIFAtdHVubmVscyB0 byBkZXRlcm1pbmUgd2hlbiBvbmUgb2YgdGhlbSBpcyBkb3duLgoKMy4xLjYuICBCRkQgRGlzY3Jp bWluYXRvciBBdHRyaWJ1dGUKCiAgIFAtdHVubmVsIHN0YXR1cyBtYXkgYmUgZGVyaXZlZCBmcm9t IHRoZSBzdGF0dXMgb2YgYSBtdWx0aXBvaW50IEJGRAogICBzZXNzaW9uIFtSRkM4NTYyXSB3aG9z ZSBkaXNjcmltaW5hdG9yIGlzIGFkdmVydGlzZWQgYWxvbmcgd2l0aCBhbgogICB4LVBNU0kgQS1E IFJvdXRlLgoKICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBmb3JtYXQgYW5kIHdheXMgb2Yg dXNpbmcgYSBuZXcgQkdQCiAgIGF0dHJpYnV0ZSBjYWxsZWQgdGhlICJCRkQgRGlzY3JpbWluYXRv ciIuICBJdCBpcyBhbiBvcHRpb25hbAogICB0cmFuc2l0aXZlIEJHUCBhdHRyaWJ1dGUuICBBbiBp bXBsZW1lbnRhdGlvbiB0aGF0IGRvZXMgbm90IHJlY29nbml6ZQogICBvciBpcyBjb25maWd1cmVk IG5vdCB0byBzdXBwb3J0IHRoaXMgYXR0cmlidXRlIE1VU1QgZm9sbG93IHByb2NlZHVyZXMKICAg ZGVmaW5lZCBmb3Igb3B0aW9uYWwgdHJhbnNpdGl2ZSBwYXRoIGF0dHJpYnV0ZXMgaW4gU2VjdGlv biA1IG9mCiAgIFtSRkM0MjcxXS4gIEluIFNlY3Rpb24gNy4yLCBJQU5BIGlzIHJlcXVlc3RlZCB0 byBhbGxvY2F0ZSB0aGUKICAgY29kZXBvaW50IHZhbHVlIChUQkEyKS4gIFRoZSBmb3JtYXQgb2Yg dGhpcyBhdHRyaWJ1dGUgaXMgc2hvd24gaW4KICAgRmlndXJlIDEuCgoKCgoKTW9yaW4sIGV0IGFs LiAgICAgICAgICAgICBFeHBpcmVzIE1heSAxNiwgMjAyMSAgICAgICAgICAgICAgICAgIFtQYWdl IDhdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBNVlBOIEZhc3QgVXBzdHJlYW0gRmFpbG92ZXIg ICAgICAgICBOb3ZlbWJlciAyMDIwCgoKICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAg ICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMKICAgICAgIDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQogICAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKwogICAgICB8ICAgIEJGRCBNb2RlICAgfCAgICAgICAgICAgICAgICAgIFJlc2VydmVk ICAgICAgICAgICAgICAgICAgICAgfAogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICBCRkQgRGlzY3JpbWluYXRvciAgICAgICAgICAgICAgICAgICAgICAgfAogICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKwogICAgICB+ICAgICAgICAgICAgICAgICAgICAgICAgIE9wdGlvbmFsIFRMVnMg ICAgICAgICAgICAgICAgICAgICAgICAgfgogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwoKCiAgICAgICAgICAgIEZp Z3VyZSAxOiBGb3JtYXQgb2YgdGhlIEJGRCBEaXNjcmltaW5hdG9yIEF0dHJpYnV0ZQoKICAgV2hl cmU6CgogICAgICBCRkQgTW9kZSBmaWVsZCBpcyB0aGUgb25lIG9jdGV0IGxvbmcuICBUaGlzIHNw ZWNpZmljYXRpb24gZGVmaW5lcwogICAgICB0aGUgUDJNUCBCRkQgU2Vzc2lvbiBhcyB2YWx1ZSAx IFNlY3Rpb24gNy4yLgoKICAgICAgUmVzZXJ2ZWQgZmllbGQgaXMgdGhyZWUgb2N0ZXRzIGxvbmcs IGFuZCB0aGUgdmFsdWUgTVVTVCBiZSB6ZXJvZWQKICAgICAgb24gdHJhbnNtaXNzaW9uIGFuZCBp Z25vcmVkIG9uIHJlY2VpcHQuCgogICAgICBCRkQgRGlzY3JpbWluYXRvciBmaWVsZCBpcyBmb3Vy IG9jdGV0cyBsb25nLgoKICAgICAgT3B0aW9uYWwgVExWcyBpcyB0aGUgb3B0aW9uYWwgdmFyaWFi bGUtbGVuZ3RoIGZpZWxkIHRoYXQgTUFZIGJlCiAgICAgIHVzZWQgaW4gdGhlIEJGRCBEaXNjcmlt aW5hdG9yIGF0dHJpYnV0ZSBmb3IgZnV0dXJlIGV4dGVuc2lvbnMuCiAgICAgIFRMVnMgTUFZIGJl IGluY2x1ZGVkIGluIGEgc2VxdWVudGlhbCBvciBuZXN0ZWQgbWFubmVyLiAgVG8gYWxsb3cKICAg ICAgZm9yIFRMViBuZXN0aW5nLCBpdCBpcyBhZHZpc2VkIHRvIGRlZmluZSBhIG5ldyBUTFYgYXMg YSB2YXJpYWJsZS0KICAgICAgbGVuZ3RoIG9iamVjdC4gIEZpZ3VyZSAyIHByZXNlbnRzIHRoZSBP cHRpb25hbCBUTFYgZm9ybWF0IFRMViB0aGF0CiAgICAgIGNvbnNpc3RzIG9mOgoKICAgICAgKiAg b25lIG9jdGV0LWxvbmcgZmllbGQgb2YgVExWJ3MgVHlwZSB2YWx1ZSAoU2VjdGlvbiA3LjMpCgog ICAgICAqICBvbmUgb2N0ZXQtbG9uZyBmaWVsZCBvZiB0aGUgbGVuZ3RoIG9mIHRoZSBWYWx1ZSBm aWVsZCBpbiBvY3RldHMKCiAgICAgICogIHZhcmlhYmxlIGxlbmd0aCBWYWx1ZSBmaWVsZC4KCiAg ICAgIFRoZSBsZW5ndGggb2YgYSBUTFYgTVVTVCBiZSBtdWx0aXBsZSBvZiBmb3VyIG9jdGV0cy4K CgoKICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAg ICAgICAgICAgICAgIDMKICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICB8ICAgICAg VHlwZSAgICAgfCAgICAgTGVuZ3RoICAgIHwgICAgICAgICAgIFZhbHVlICAgICAgICAgICAgIC4u LgogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKwoKCiAgICAgICAgICAgICAgICAgICBGaWd1cmUgMjogRm9ybWF0IG9m IHRoZSBPcHRpb25hbCBUTFYKCgoKTW9yaW4sIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1h eSAxNiwgMjAyMSAgICAgICAgICAgICAgICAgIFtQYWdlIDldCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICBNVlBOIEZhc3QgVXBzdHJlYW0gRmFpbG92ZXIgICAgICAgICBOb3ZlbWJlciAyMDIwCgoK ICAgVGhlIEJGRCBEaXNjcmltaW5hdG9yIGF0dHJpYnV0ZSBNVVNUIGJlIGNvbnNpZGVyZWQgbWFs Zm9ybWVkIGlmIGl0cwogICBsZW5ndGggaXMgbm90IGEgbm9uLXplcm8gbXVsdGlwbGUgb2YgZm91 ci4gIElmIHRoZSBhdHRyaWJ1dGUKICAgY29uc2lkZXJlZCBtYWxmb3JtZWQsIHRoZSBVUERBVEUg bWVzc2FnZSBTSEFMTCBiZSBoYW5kbGVkIHVzaW5nIHRoZQogICBhcHByb2FjaCBvZiBBdHRyaWJ1 dGUgRGlzY2FyZCBwZXIgW1JGQzc2MDZdLgoKMy4xLjYuMS4gIFVwc3RyZWFtIFBFIFByb2NlZHVy ZXMKCiAgIFRvIGVuYWJsZSBkb3duc3RyZWFtIFBFcyB0byB0cmFjayB0aGUgUC10dW5uZWwgc3Rh dHVzIHVzaW5nIGEgcG9pbnQtCiAgIHRvLW11bHRpcG9pbnQgKFAyTVApIEJGRCBzZXNzaW9uIHRo ZSBVcHN0cmVhbSBQRToKCiAgIG8gIE1VU1QgaW5pdGlhdGUgdGhlIEJGRCBzZXNzaW9uIGFuZCBz ZXQgYmZkLlNlc3Npb25UeXBlID0KICAgICAgTXVsdGlwb2ludEhlYWQgYXMgZGVzY3JpYmVkIGlu IFtSRkM4NTYyXTsKCiAgIG8gIE1VU1Qgc2V0IHRoZSBJUCBkZXN0aW5hdGlvbiBhZGRyZXNzIG9m IHRoZSBpbm5lciBJUCBoZWFkZXIgdG8gb25lCiAgICAgIG9mIHRoZSBpbnRlcm5hbCBsb29wYmFj ayBhZGRyZXNzZXMgZnJvbSAxMjcvOCByYW5nZSBmb3IgSVB2NCBvcgogICAgICBvbmUgb2YgSVB2 NC1tYXBwZWQgSVB2NiBhZGRyZXNzZXMgZnJvbSA6OmZmZmY6MTI3LjAuMC4wLzEwNCByYW5nZQog ICAgICBmb3IgSVB2NiB3aGVuIHRyYW5zbWl0dGluZyBCRkQgQ29udHJvbCBwYWNrZXRzOwoKICAg byAgTVVTVCB1c2UgaXRzIElQIGFkZHJlc3MgYXMgdGhlIHNvdXJjZSBJUCBhZGRyZXNzIHdoZW4g dHJhbnNtaXR0aW5nCiAgICAgIEJGRCBDb250cm9sIHBhY2tldHM7CgogICBvICBNVVNUIGluY2x1 ZGUgdGhlIEJGRCBEaXNjcmltaW5hdG9yIGF0dHJpYnV0ZSBpbiB0aGUgeC1QTVNJIEEtRAogICAg ICBSb3V0ZSB3aXRoIHRoZSB2YWx1ZSBzZXQgdG8gTXkgRGlzY3JpbWluYXRvciB2YWx1ZTsKCiAg IG8gIE1VU1QgcGVyaW9kaWNhbGx5IHRyYW5zbWl0IEJGRCBDb250cm9sIHBhY2tldHMgb3ZlciB0 aGUgeC1QTVNJCiAgICAgIFAtdHVubmVsIGFmdGVyIHRoZSBQLXR1bm5lbCBpcyBjb25zaWRlcmVk IGVzdGFibGlzaGVkLiAgTm90ZSB0aGF0CiAgICAgIHRoZSBtZXRob2RzIHRvIGRlY2xhcmUgYSBQ LXR1bm5lbCBoYXMgYmVlbiBlc3RhYmxpc2hlZCBhcmUgb3V0c2lkZQogICAgICB0aGUgc2NvcGUg b2YgdGhpcyBzcGVjaWZpY2F0aW9uLgoKICAgSWYgdGhlIHRyYWNraW5nIG9mIHRoZSBQLXR1bm5l bCBieSB1c2luZyBhIFAyTVAgQkZEIHNlc3Npb24gaXMKICAgZW5hYmxlZCBhZnRlciB0aGUgeC1Q TVNJIEEtRCBSb3V0ZSBoYXMgYmVlbiBhbHJlYWR5IGFkdmVydGlzZWQsIHRoZQogICB4LVBNU0kg QS1EIFJvdXRlIE1VU1QgYmUgcmUtc2VudCB3aXRoIHByZWNpc2VseSB0aGUgc2FtZSBhdHRyaWJ1 dGVzCiAgIGFzIGJlZm9yZSBhbmQgdGhlIEJGRCBEaXNjcmltaW5hdG9yIGF0dHJpYnV0ZSBpbmNs dWRlZC4KCiAgIElmIHRoZSB4LVBNU0kgQS1EIFJvdXRlIGlzIGFkdmVydGlzZWQgd2l0aCBQLXR1 bm5lbCBzdGF0dXMgdHJhY2tlZAogICB1c2luZyB0aGUgUDJNUCBCRkQgc2Vzc2lvbiBhbmQgaXQg aXMgZGVzaXJlZCB0byBzdG9wIHRyYWNraW5nCiAgIFAtdHVubmVsIHN0YXR1cyB1c2luZyBCRkQs IHRoZW46CgogICBvICB4LVBNU0kgQS1EIFJvdXRlIE1VU1QgYmUgcmUtc2VudCB3aXRoIHByZWNp c2VseSB0aGUgc2FtZQogICAgICBhdHRyaWJ1dGVzIGFzIGJlZm9yZSwgYnV0IHRoZSBCRkQgRGlz Y3JpbWluYXRvciBhdHRyaWJ1dGUgTVVTVCBiZQogICAgICBleGNsdWRlZDsKCiAgIG8gIHRoZSBQ Mk1QIEJGRCBzZXNzaW9uIFNIT1VMRCBiZSBkZWxldGVkLgoKCgoKCgoKCk1vcmluLCBldCBhbC4g ICAgICAgICAgICAgRXhwaXJlcyBNYXkgMTYsIDIwMjEgICAgICAgICAgICAgICAgIFtQYWdlIDEw XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgTVZQTiBGYXN0IFVwc3RyZWFtIEZhaWxvdmVyICAg ICAgICAgTm92ZW1iZXIgMjAyMAoKCjMuMS42LjIuICBEb3duc3RyZWFtIFBFIFByb2NlZHVyZXMK CiAgIFVwb24gcmVjZWl2aW5nIHRoZSBCRkQgRGlzY3JpbWluYXRvciBhdHRyaWJ1dGUgaW4gdGhl IHgtUE1TSSBBLUQKICAgUm91dGUsIHRoZSBkb3duc3RyZWFtIFBFOgoKICAgbyAgTVVTVCBhc3Nv Y2lhdGUgdGhlIHJlY2VpdmVkIEJGRCBEaXNjcmltaW5hdG9yIHZhbHVlIHdpdGggdGhlCiAgICAg IFAtdHVubmVsIG9yaWdpbmF0aW5nIGZyb20gdGhlIFVwc3RyZWFtIFBFIGFuZCB0aGUgSVAgYWRk cmVzcyBvZgogICAgICB0aGUgVXBzdHJlYW0gUEU7CgogICBvICBNVVNUIGNyZWF0ZSBhIFAyTVAg QkZEIHNlc3Npb24gYW5kIHNldCBiZmQuU2Vzc2lvblR5cGUgPQogICAgICBNdWx0aXBvaW50VGFp bCBhcyBkZXNjcmliZWQgaW4gW1JGQzg1NjJdOwoKICAgbyAgTVVTVCB1c2UgdGhlIHNvdXJjZSBJ UCBhZGRyZXNzIG9mIHRoZSBCRkQgQ29udHJvbCBwYWNrZXQsIHRoZQogICAgICB2YWx1ZSBvZiB0 aGUgQkZEIERpc2NyaW1pbmF0b3IgZmllbGQsIGFuZCB0aGUgeC1QTVNJIFR1bm5lbAogICAgICBJ ZGVudGlmaWVyIFtSRkM2NTE0XSB0aGUgQkZEIENvbnRyb2wgcGFja2V0IHdhcyByZWNlaXZlZCB0 bwogICAgICBwcm9wZXJseSBkZW11bHRpcGxleCBCRkQgc2Vzc2lvbnMuCgogICBBZnRlciB0aGUg c3RhdGUgb2YgdGhlIFAyTVAgQkZEIHNlc3Npb24gaXMgdXAsIGkuZS4sIGJmZC5TZXNzaW9uU3Rh dGUKICAgPT0gVXAsIHRoZSBzZXNzaW9uIHN0YXRlIHdpbGwgdGhlbiBiZSB1c2VkIHRvIHRyYWNr IHRoZSBoZWFsdGggb2YgdGhlCiAgIFAtdHVubmVsLgoKICAgQWNjb3JkaW5nIHRvIFtSRkM4NTYy XSwgaWYgdGhlIGRvd25zdHJlYW0gUEUgcmVjZWl2ZXMgRG93biBvcgogICBBZG1pbkRvd24gaW4g dGhlIFN0YXRlIGZpZWxkIG9mIHRoZSBCRkQgQ29udHJvbCBwYWNrZXQgb3IgYXNzb2NpYXRlZAog ICB3aXRoIHRoZSBCRkQgc2Vzc2lvbiBEZXRlY3Rpb24gVGltZXIgZXhwaXJlcywgdGhlIEJGRCBz ZXNzaW9uIGlzCiAgIGRvd24sIGkuZS4sIGJmZC5TZXNzaW9uU3RhdGUgPT0gRG93bi4gIFdoZW4g dGhlIEJGRCBzZXNzaW9uIHN0YXRlIGlzCiAgIERvd24sIHRoZW4gdGhlIFAtdHVubmVsIGFzc29j aWF0ZWQgd2l0aCB0aGUgQkZEIHNlc3Npb24gTVVTVCBiZQogICBjb25zaWRlcmVkIGRvd24uICBJ ZiB0aGUgc2l0ZSB0aGF0IGNvbnRhaW5zIEMtUyBpcyBjb25uZWN0ZWQgdG8gdHdvCiAgIG9yIG1v cmUgUEVzLCBhIGRvd25zdHJlYW0gUEUgd2lsbCBzZWxlY3Qgb25lIGFzIGl0cyBQcmltYXJ5IFVw c3RyZWFtCiAgIFBFLCB3aGlsZSBvdGhlcnMgYXJlIGNvbnNpZGVyZWQgYXMgU3RhbmRieSBVcHN0 cmVhbSBQRXMuICBJbiBzdWNoIGEKICAgc2NlbmFyaW8sIHdoZW4gdGhlIFAtdHVubmVsIGlzIGNv bnNpZGVyZWQgZG93biwgdGhlIGRvd25zdHJlYW0gUEUgTUFZCiAgIGluaXRpYXRlIGEgc3dpdGNo b3ZlciBvZiB0aGUgdHJhZmZpYyBmcm9tIHRoZSBQcmltYXJ5IFVwc3RyZWFtIFBFIHRvCiAgIHRo ZSBTdGFuZGJ5IFVwc3RyZWFtIFBFIG9ubHkgaWYgdGhlIFN0YW5kYnkgVXBzdHJlYW0gUEUgaXMg ZGVlbWVkCiAgIGF2YWlsYWJsZS4KCiAgIElmIHRoZSBkb3duc3RyZWFtIFBFJ3MgUC10dW5uZWwg aXMgYWxyZWFkeSBlc3RhYmxpc2hlZCB3aGVuIHRoZQogICBkb3duc3RyZWFtIFBFIHJlY2VpdmVz IHRoZSBuZXcgeC1QTVNJIEEtRCBSb3V0ZSB3aXRoIEJGRAogICBEaXNjcmltaW5hdG9yIGF0dHJp YnV0ZSwgdGhlIGRvd25zdHJlYW0gUEUgTVVTVCBhc3NvY2lhdGUgdGhlIHZhbHVlCiAgIG9mIEJG RCBEaXNjcmltaW5hdG9yIGZpZWxkIHdpdGggdGhlIFAtdHVubmVsIGFuZCBmb2xsb3cgcHJvY2Vk dXJlcwogICBsaXN0ZWQgYWJvdmUgaW4gdGhpcyBzZWN0aW9uIGlmIGFuZCBvbmx5IGlmIHRoZSB4 LVBNU0kgQS1EIFJvdXRlIHdhcwogICBwcm9wZXJseSBwcm9jZXNzZWQgYXMgcGVyIFtSRkM2NTE0 XSwgYW5kIHRoZSBCRkQgRGlzY3JpbWluYXRvcgogICBhdHRyaWJ1dGUgd2FzIHZhbGlkYXRlZC4K CiAgIElmIHRoZSBkb3duc3RyZWFtIFBFJ3MgUC10dW5uZWwgaXMgYWxyZWFkeSBlc3RhYmxpc2hl ZCwgaXRzIHN0YXRlCiAgIGJlaW5nIG1vbml0b3JlZCBieSB0aGUgUDJNUCBCRkQgc2Vzc2lvbiwg YW5kIHRoZSBkb3duc3RyZWFtIFBFCiAgIHJlY2VpdmVzIHRoZSBuZXcgeC1QTVNJIEEtRCBSb3V0 ZSB3aXRob3V0IHRoZSBCRkQgRGlzY3JpbWluYXRvcgogICBhdHRyaWJ1dGUsIGFuZCB0aGUgeC1Q TVNJIEEtRCBSb3V0ZSB3YXMgcHJvY2Vzc2VkIHdpdGhvdXQgYW55IGVycm9yCiAgIGFzIHBlciB0 aGUgcmVsZXZhbnQgc3BlY2lmaWNhdGlvbnMsIHRoZSBkb3duc3RyZWFtIFBFOgoKCgoKTW9yaW4s IGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1heSAxNiwgMjAyMSAgICAgICAgICAgICAgICAg W1BhZ2UgMTFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBNVlBOIEZhc3QgVXBzdHJlYW0gRmFp bG92ZXIgICAgICAgICBOb3ZlbWJlciAyMDIwCgoKICAgbyAgTVVTVCBzdG9wIHByb2Nlc3Npbmcg QkZEIENvbnRyb2wgcGFja2V0cyBmb3IgdGhpcyBQMk1QIEJGRAogICAgICBzZXNzaW9uOwoKICAg byAgU0hPVUxEIGRlbGV0ZSB0aGUgUDJNUCBCRkQgc2Vzc2lvbiBhc3NvY2lhdGVkIHdpdGggdGhl IFAtdHVubmVsOwoKICAgbyAgU0hPVUxEIE5PVCBzd2l0Y2ggdGhlIHRyYWZmaWMgdG8gdGhlIFN0 YW5kYnkgVXBzdHJlYW0gUEUuCgozLjEuNy4gIFBlciBQRS1DRSBMaW5rIEJGRCBEaXNjcmltaW5h dG9yCgogICBUaGUgZm9sbG93aW5nIGFwcHJvYWNoIGlzIGRlZmluZWQgaW4gcmVzcG9uc2UgdG8g dGhlIGRldGVjdGlvbiBieSB0aGUKICAgVXBzdHJlYW0gUEUgb2YgYSBQRS1DRSBsaW5rIGZhaWx1 cmUuICBFdmVuIHRob3VnaCB0aGUgcHJvdmlkZXIgdHVubmVsCiAgIGlzIHN0aWxsIHVwLCBpdCBp cyBkZXNpcmVkIGZvciB0aGUgZG93bnN0cmVhbSBQRXMgdG8gc3dpdGNoIHRvIGEKICAgYmFja3Vw IFVwc3RyZWFtIFBFLiAgVG8gYWNoaWV2ZSB0aGF0LCBpZiB0aGUgVXBzdHJlYW0gUEUgZGV0ZWN0 cyB0aGF0CiAgIGl0cyBQRS1DRSBsaW5rIGZhaWxzLCBpdCBTSE9VTEQgc2V0IHRoZSBiZmQuTG9j YWxEaWFnIG9mIHRoZSBQMk1QIEJGRAogICBzZXNzaW9uIHRvIENvbmNhdGVuYXRlZCBQYXRoIERv d24gYW5kL29yIFJldmVyc2UgQ29uY2F0ZW5hdGVkIFBhdGgKICAgRG93biAocGVyIFNlY3Rpb24g Ni44LjE3IFtSRkM1ODgwXSksIHVubGVzcyBpdCBzd2l0Y2hlcyB0byBhIG5ldyBQRS0KICAgQ0Ug bGluayB3aXRoaW4gdGhlIHRpbWUgb2YgYmZkLkRlc2lyZWRNaW5UeEludGVydmFsIGZvciB0aGUg UDJNUCBCRkQKICAgc2Vzc2lvbiAoaW4gdGhhdCBjYXNlLCB0aGUgVXBzdHJlYW0gUEUgd2lsbCBz dGFydCB0cmFja2luZyB0aGUgc3RhdHVzCiAgIG9mIHRoZSBuZXcgUEUtQ0UgbGluaykuICBXaGVu IGEgZG93bnN0cmVhbSBQRSByZWNlaXZlcyB0aGF0CiAgIGJmZC5Mb2NhbERpYWcgY29kZSwgaXQg dHJlYXRzIGl0IGFzIGlmIHRoZSB0dW5uZWwgaXRzZWxmIGZhaWxlZCBhbmQKICAgdHJpZXMgdG8g c3dpdGNoIHRvIGEgYmFja3VwIFBFLgoKNC4gIFN0YW5kYnkgQy1tdWx0aWNhc3QgUm91dGUKCiAg IFRoZSBwcm9jZWR1cmVzIGRlc2NyaWJlZCBiZWxvdyBhcmUgbGltaXRlZCB0byB0aGUgY2FzZSB3 aGVyZSB0aGUgc2l0ZQogICB0aGF0IGNvbnRhaW5zIEMtUyBpcyBjb25uZWN0ZWQgdG8gdHdvIG9y IG1vcmUgUEVzLCB0aG91Z2gsIHRvCiAgIHNpbXBsaWZ5IHRoZSBkZXNjcmlwdGlvbiwgdGhlIGNh c2Ugb2YgZHVhbC1ob21pbmcgaXMgZGVzY3JpYmVkLiAgU3VjaAogICBhIHJlZHVuZGFuY3kgcHJv dGVjdGlvbiBzY2hlbWUsIHJlZmVycmVkIHRvIGFzIDE6TiBwcm90ZWN0aW9uLCBpcyB0aGUKICAg c3BlY2lhbCBjYXNlIG9mIE06TiBwcm90ZWN0aW9uLCB3aGVyZSBNIHdvcmtpbmcgaW5zdGFuY2Vz IGFyZSBzaGFyaW5nCiAgIHByb3RlY3Rpb24gb2YgdGhlIE4gc3RhbmRieSBpbnN0YW5jZXMuICBJ biBhZGRpdGlvbiB0byBhIG5ldHdvcmsKICAgZmFpbHVyZSBkZXRlY3Rpb24gbWVjaGFuaXNtLCB0 aGUgbGF0dGVyIHNjaGVtZSByZXF1aXJlcyB1c2luZyBhCiAgIG1lY2hhbmlzbSB0byBjb29yZGlu YXRlIHRoZSBmYWlsb3ZlciBhbW9uZyB3b3JraW5nIGluc3RhbmNlcy4gIEZvcgogICB0aGF0IHJl YXNvbiwgTTpOIHByb3RlY3Rpb24gaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcwogICBzcGVj aWZpY2F0aW9uLgoKICAgVGhlIHByb2NlZHVyZXMgZGVzY3JpYmVkIGluIHRoaXMgc2VjdGlvbiBy ZXF1aXJlIGFsbCB0aGUgUEVzIG9mIHRoYXQKICAgTVZQTiB0byBmb2xsb3cgdGhlIHNhbWUgVU1I IHNlbGVjdGlvbiBwcm9jZWR1cmUsIGFzIHNwZWNpZmllZCBpbgogICBbUkZDNjUxM10sIHdoZXRo ZXIgdGhlIFBFIHNlbGVjdGVkIGJhc2VkIG9uIGl0cyBJUCBhZGRyZXNzLCBoYXNoaW5nCiAgIGFs Z29yaXRobSBkZXNjcmliZWQgaW4gc2VjdGlvbiA1LjEuMyBvZiBbUkZDNjUxM10sIG9yIEluc3Rh bGxlZCBVTUgKICAgUm91dGUuICBUaGUgcHJvY2VkdXJlcyBhc3N1bWUgdGhhdCBpZiBhIHNpdGUg b2YgYSBnaXZlbiBNVlBOIHRoYXQKICAgY29udGFpbnMgQy1TIGlzIGR1YWwtaG9tZWQgdG8gdHdv IFBFcywgdGhlbiBhbGwgdGhlIG90aGVyIHNpdGVzIG9mCiAgIHRoYXQgTVZQTiB3b3VsZCBoYXZl IHR3byB1bmljYXN0IFZQTiByb3V0ZXMgKFZQTi1JUHY0IG9yIFZQTi1JUHY2KSB0bwogICBDLVMs IGVhY2ggd2l0aCBpdHMgUkQuCgogICBBcyBsb25nIGFzIEMtUyBpcyByZWFjaGFibGUgdmlhIGJv dGggUEVzLCBhIGdpdmVuIGRvd25zdHJlYW0gUEUgd2lsbAogICBzZWxlY3Qgb25lIG9mIHRoZSBQ RXMgY29ubmVjdGVkIHRvIEMtUyBhcyBpdHMgVXBzdHJlYW0gUEUgZm9yIEMtUy4KICAgV2Ugd2ls bCByZWZlciB0byB0aGUgb3RoZXIgUEUgY29ubmVjdGVkIHRvIEMtUyBhcyB0aGUgIlN0YW5kYnkK ICAgVXBzdHJlYW0gUEUiLiAgTm90ZSB0aGF0IGlmIHRoZSBjb25uZWN0aXZpdHkgdG8gQy1TIHRo cm91Z2ggdGhlCgoKCk1vcmluLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBNYXkgMTYsIDIw MjEgICAgICAgICAgICAgICAgIFtQYWdlIDEyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgTVZQ TiBGYXN0IFVwc3RyZWFtIEZhaWxvdmVyICAgICAgICAgTm92ZW1iZXIgMjAyMAoKCiAgIFByaW1h cnkgVXBzdHJlYW0gUEUgYmVjb21lcyB1bmF2YWlsYWJsZSwgdGhlbiB0aGUgUEUgd2lsbCBzZWxl Y3QgdGhlCiAgIFN0YW5kYnkgVXBzdHJlYW0gUEUgYXMgaXRzIFVwc3RyZWFtIFBFIGZvciBDLVMu ICBXaGVuIHRoZSBQcmltYXJ5IFBFCiAgIGxhdGVyIGJlY29tZXMgYXZhaWxhYmxlLCB0aGVuIHRo ZSBQRSB3aWxsIHNlbGVjdCB0aGUgUHJpbWFyeSBVcHN0cmVhbQogICBQRSBhZ2FpbiBhcyBpdHMg VXBzdHJlYW0gUEUuICBTdWNoIGJlaGF2aW9yIGlzIHJlZmVycmVkIHRvIGFzCiAgICJyZXZlcnRp dmUiIGJlaGF2aW9yIGFuZCBNVVNUIGJlIHN1cHBvcnRlZC4gIE5vbi1yZXZlcnRpdmUgYmVoYXZp b3IKICAgcmVmZXJzIHRvIHRoZSBiZWhhdmlvciBvZiBjb250aW51aW5nIHRvIHNlbGVjdCB0aGUg YmFja3VwIFBFIGFzIHRoZQogICBVTUggZXZlbiBhZnRlciB0aGUgUHJpbWFyeSBoYXMgY29tZSB1 cC4gIFRoaXMgbm9uLXJldmVydGl2ZSBiZWhhdmlvcgogICBNQVkgYWxzbyBiZSBzdXBwb3J0ZWQg YnkgYW4gaW1wbGVtZW50YXRpb24gYW5kIHdvdWxkIGJlIGVuYWJsZWQKICAgdGhyb3VnaCBzb21l IGNvbmZpZ3VyYXRpb24uCgogICBGb3IgcmVhZGFiaWxpdHksIGluIHRoZSBmb2xsb3dpbmcgc3Vi LXNlY3Rpb25zLCB0aGUgcHJvY2VkdXJlcyBhcmUKICAgZGVzY3JpYmVkIGZvciBCR1AgQy1tdWx0 aWNhc3QgU291cmNlIFRyZWUgSm9pbiByb3V0ZXMsIGJ1dCB0aGV5IGFwcGx5CiAgIGVxdWFsbHkg dG8gQkdQIEMtbXVsdGljYXN0IFNoYXJlZCBUcmVlIEpvaW4gcm91dGVzIGZvciB0aGUgY2FzZSB3 aGVyZQogICB0aGUgY3VzdG9tZXIgUlAgaXMgZHVhbC1ob21lZCAoc3Vic3RpdHV0ZSAiQy1SUCIg dG8gIkMtUyIpLgoKNC4xLiAgRG93bnN0cmVhbSBQRSBCZWhhdmlvcgoKICAgV2hlbiBhIChkb3du c3RyZWFtKSBQRSBjb25uZWN0ZWQgdG8gc29tZSBzaXRlIG9mIGFuIE1WUE4gbmVlZHMgdG8KICAg c2VuZCBhIEMtbXVsdGljYXN0IHJvdXRlIChDLVMsIEMtRyksIHRoZW4gZm9sbG93aW5nIHRoZSBw cm9jZWR1cmVzCiAgIHNwZWNpZmllZCBpbiBTZWN0aW9uIDExLjEgb2YgW1JGQzY1MTRdLCB0aGUg UEUgc2VuZHMgdGhlIEMtbXVsdGljYXN0CiAgIHJvdXRlIHdpdGggYW4gUlQgdGhhdCBpZGVudGlm aWVzIHRoZSBVcHN0cmVhbSBQRSBzZWxlY3RlZCBieSB0aGUgUEUKICAgb3JpZ2luYXRpbmcgdGhl IHJvdXRlLiAgQXMgbG9uZyBhcyBDLVMgaXMgcmVhY2hhYmxlIHZpYSB0aGUgUHJpbWFyeQogICBV cHN0cmVhbSBQRSwgdGhlIFVwc3RyZWFtIFBFIGlzIHRoZSBQcmltYXJ5IFVwc3RyZWFtIFBFLiAg SWYgQy1TIGlzCiAgIHJlYWNoYWJsZSBvbmx5IHZpYSB0aGUgU3RhbmRieSBVcHN0cmVhbSBQRSwg dGhlbiB0aGUgVXBzdHJlYW0gUEUgaXMKICAgdGhlIFN0YW5kYnkgVXBzdHJlYW0gUEUuCgogICBJ ZiBDLVMgaXMgcmVhY2hhYmxlIHZpYSBib3RoIHRoZSBQcmltYXJ5IGFuZCB0aGUgU3RhbmRieSBV cHN0cmVhbSBQRSwKICAgdGhlbiBpbiBhZGRpdGlvbiB0byBzZW5kaW5nIHRoZSBDLW11bHRpY2Fz dCByb3V0ZSB3aXRoIGFuIFJUIHRoYXQKICAgaWRlbnRpZmllcyB0aGUgUHJpbWFyeSBVcHN0cmVh bSBQRSwgdGhlIGRvd25zdHJlYW0gUEUgYWxzbyBvcmlnaW5hdGVzCiAgIGFuZCBzZW5kcyBhIEMt bXVsdGljYXN0IHJvdXRlIHdpdGggYW4gUlQgdGhhdCBpZGVudGlmaWVzIHRoZSBTdGFuZGJ5CiAg IFVwc3RyZWFtIFBFLiAgVGhlIHJvdXRlIHRoYXQgaGFzIHRoZSBzZW1hbnRpY3Mgb2YgYmVpbmcg YSAic3RhbmRieSIKICAgQy1tdWx0aWNhc3Qgcm91dGUgaXMgZnVydGhlciBjYWxsZWQgYSAiU3Rh bmRieSBCR1AgQy1tdWx0aWNhc3QKICAgcm91dGUiLCBhbmQgaXMgY29uc3RydWN0ZWQgYXMgZm9s bG93czoKCiAgIG8gIHRoZSBOTFJJIGlzIGNvbnN0cnVjdGVkIGFzIHRoZSBDLW11bHRpY2FzdCBy b3V0ZSB3aXRoIGFuIFJUIHRoYXQKICAgICAgaWRlbnRpZmllcyB0aGUgUHJpbWFyeSBVcHN0cmVh bSBQRSwgZXhjZXB0IHRoYXQgdGhlIFJEIGlzIHRoZSBzYW1lCiAgICAgIGFzIGlmIHRoZSBDLW11 bHRpY2FzdCByb3V0ZSB3YXMgYnVpbHQgdXNpbmcgdGhlIFN0YW5kYnkgVXBzdHJlYW0KICAgICAg UEUgYXMgdGhlIFVNSCAoaXQgd2lsbCBjYXJyeSB0aGUgUkQgYXNzb2NpYXRlZCB0byB0aGUgdW5p Y2FzdCBWUE4KICAgICAgcm91dGUgYWR2ZXJ0aXNlZCBieSB0aGUgU3RhbmRieSBVcHN0cmVhbSBQ RSBmb3IgUyBhbmQgYSBSb3V0ZQogICAgICBUYXJnZXQgZGVyaXZlZCBmcm9tIHRoZSBTdGFuZGJ5 IFVwc3RyZWFtIFBFJ3MgVU1IIHJvdXRlJ3MgVlJGIFJUCiAgICAgIEltcG9ydCBFQyk7CgogICBv ICBNVVNUIGNhcnJ5IHRoZSAiU3RhbmRieSBQRSIgQkdQIENvbW11bml0eSAodGhpcyBpcyBhIG5l dyBCR1AKICAgICAgQ29tbXVuaXR5LiAgU2VjdGlvbiA3LjEgcmVxdWVzdGVkIElBTkEgdG8gYWxs b2NhdGUgdmFsdWUgVEJBMSkuCgogICBUaGUgTG9jYWwgUHJlZmVyZW5jZSBhdHRyaWJ1dGUgb2Yg dGhlIG5vcm1hbCBhbmQgdGhlIHN0YW5kYnkKICAgQy1tdWx0aWNhc3Qgcm91dGUgbmVlZHMgdG8g YmUgYWRqdXN0ZWQuIHNvIHRoYXQsIGlmIGEgQkdQIHBlZXIKICAgcmVjZWl2ZXMgdHdvIEMtbXVs dGljYXN0IHJvdXRlcyB3aXRoIHRoZSBzYW1lIE5MUkksIG9uZSBjYXJyeWluZyB0aGUKCgoKTW9y aW4sIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1heSAxNiwgMjAyMSAgICAgICAgICAgICAg ICAgW1BhZ2UgMTNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBNVlBOIEZhc3QgVXBzdHJlYW0g RmFpbG92ZXIgICAgICAgICBOb3ZlbWJlciAyMDIwCgoKICAgIlN0YW5kYnkgUEUiIGNvbW11bml0 eSBhbmQgdGhlIG90aGVyIG9uZSBub3QgY2FycnlpbmcgdGhlICJTdGFuZGJ5CiAgIFBFIiBjb21t dW5pdHksIHRoZW4gcHJlZmVyZW5jZSBpcyBnaXZlbiB0byB0aGUgb25lIG5vdCBjYXJyeWluZyB0 aGUKICAgIlN0YW5kYnkgUEUiIGNvbW11bml0eS4gIFN1Y2ggYSBzaXR1YXRpb24gY2FuIGhhcHBl biB3aGVuLCBmb3IKICAgaW5zdGFuY2UsIGR1ZSB0byB0cmFuc2llbnQgdW5pY2FzdCByb3V0aW5n IGluY29uc2lzdGVuY2llcyBvciBsYWNrIG9mCiAgIHN1cHBvcnQgb2YgdGhlIFN0YW5kYnkgUEUg Y29tbXVuaXR5LCB0d28gZGlmZmVyZW50IGRvd25zdHJlYW0gUEVzCiAgIGNvbnNpZGVyIGRpZmZl cmVudCBVcHN0cmVhbSBQRXMgdG8gYmUgdGhlIHByaW1hcnkgb25lLiAgSW4gdGhhdCBjYXNlLAog ICB3aXRob3V0IGFueSBwcmVjYXV0aW9uIHRha2VuLCBib3RoIFVwc3RyZWFtIFBFcyB3b3VsZCBw cm9jZXNzIGEKICAgc3RhbmRieSBDLW11bHRpY2FzdCByb3V0ZSBhbmQgcG9zc2libHkgc3RvcCBm b3J3YXJkaW5nIGF0IHRoZSBzYW1lCiAgIHRpbWUuICBGb3IgdGhpcyBwdXJwb3NlLCByb3V0ZXMg dGhhdCBjYXJyeSB0aGUgIlN0YW5kYnkgUEUiIEJHUAogICBDb21tdW5pdHkgTVVTVCBoYXZlIHRo ZSBMT0NBTF9QUkVGIGF0dHJpYnV0ZSBzZXQgdG8gemVyby4KCiAgIE5vdGUgdGhhdCwgd2hlbiBh IFBFIGFkdmVydGlzZXMgc3VjaCBhIFN0YW5kYnkgQy1tdWx0aWNhc3Qgam9pbiBmb3IgYQogICAo Qy1TLCBDLUcpIGl0IE1VU1Qgam9pbiB0aGUgY29ycmVzcG9uZGluZyBQLXR1bm5lbC4KCiAgIElm IGF0IHNvbWUgbGF0ZXIgcG9pbnQsIHRoZSBQRSBkZXRlcm1pbmVzIHRoYXQgQy1TIGlzIG5vIGxv bmdlcgogICByZWFjaGFibGUgdGhyb3VnaCB0aGUgUHJpbWFyeSBVcHN0cmVhbSBQRSwgdGhlIFN0 YW5kYnkgVXBzdHJlYW0gUEUKICAgYmVjb21lcyB0aGUgVXBzdHJlYW0gUEUsIGFuZCB0aGUgUEUg cmUtc2VuZHMgdGhlIEMtbXVsdGljYXN0IHJvdXRlCiAgIHdpdGggUlQgdGhhdCBpZGVudGlmaWVz IHRoZSBTdGFuZGJ5IFVwc3RyZWFtIFBFLCBleGNlcHQgdGhhdCBub3cgdGhlCiAgIHJvdXRlIGRv ZXMgbm90IGNhcnJ5IHRoZSBTdGFuZGJ5IFBFIEJHUCBDb21tdW5pdHkgKHdoaWNoIHJlc3VsdHMg aW4KICAgcmVwbGFjaW5nIHRoZSBvbGQgcm91dGUgd2l0aCBhIG5ldyByb3V0ZSwgd2l0aCB0aGUg b25seSBkaWZmZXJlbmNlCiAgIGJldHdlZW4gdGhlc2Ugcm91dGVzIGJlaW5nIHRoZSBwcmVzZW5j ZS9hYnNlbmNlIG9mIHRoZSBTdGFuZGJ5IFBFIEJHUAogICBDb21tdW5pdHkpLiAgVGhlIExPQ0FM X1BSRUYgYXR0cmlidXRlIE1VU1QgYmUgc2V0IHRvIHplcm8uCgo0LjIuICBVcHN0cmVhbSBQRSBC ZWhhdmlvcgoKICAgV2hlbiBhIFBFIHJlY2VpdmVzIGEgQy1tdWx0aWNhc3Qgcm91dGUgZm9yIGEg cGFydGljdWxhciAoQy1TLCBDLUcpLAogICBhbmQgdGhlIFJUIGNhcnJpZWQgaW4gdGhlIHJvdXRl IHJlc3VsdHMgaW4gaW1wb3J0aW5nIHRoZSByb3V0ZSBpbnRvIGEKICAgcGFydGljdWxhciBWUkYg b24gdGhlIFBFLCBpZiB0aGUgcm91dGUgY2FycmllcyB0aGUgU3RhbmRieSBQRSBCR1AKICAgQ29t bXVuaXR5LCB0aGVuIHRoZSBQRSBwZXJmb3JtcyBhcyBmb2xsb3dzOgoKICAgICAgd2hlbiB0aGUg UEUgZGV0ZXJtaW5lcyAodGhlIHVzZSBvZiB0aGUgcGFydGljdWxhciBtZXRob2QgdG8gZGV0ZWN0 CiAgICAgIHRoZSBmYWlsdXJlIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQp IHRoYXQgQy1TIGlzIG5vdAogICAgICByZWFjaGFibGUgdGhyb3VnaCBzb21lIG90aGVyIFBFLCB0 aGUgUEUgU0hPVUxEIGluc3RhbGwgVlJGIFBJTQogICAgICBzdGF0ZSBjb3JyZXNwb25kaW5nIHRv IHRoaXMgU3RhbmRieSBCR1AgQy1tdWx0aWNhc3Qgcm91dGUgKHRoZQogICAgICByZXN1bHQgd2ls bCBiZSB0aGF0IGEgUElNIEpvaW4gbWVzc2FnZSB3aWxsIGJlIHNlbnQgdG8gdGhlIENFCiAgICAg IHRvd2FyZHMgQy1TLCBhbmQgdGhhdCB0aGUgUEUgd2lsbCByZWNlaXZlIChDLVMsIEMtRykgdHJh ZmZpYyksIGFuZAogICAgICB0aGUgUEUgU0hPVUxEIGZvcndhcmQgKEMtUywgQy1HKSB0cmFmZmlj IHJlY2VpdmVkIGJ5IHRoZSBQRSB0bwogICAgICBvdGhlciBQRXMgdGhyb3VnaCBhIFAtdHVubmVs IHJvb3RlZCBhdCB0aGUgUEUuCgogICBGdXJ0aGVybW9yZSwgaXJyZXNwZWN0aXZlIG9mIHdoZXRo ZXIgQy1TIGNhcnJpZWQgaW4gdGhhdCByb3V0ZSBpcwogICByZWFjaGFibGUgdGhyb3VnaCBzb21l IG90aGVyIFBFOgoKICAgYSkgYmFzZWQgb24gbG9jYWwgcG9saWN5LCBhcyBzb29uIGFzIHRoZSBQ RSByZWNlaXZlcyB0aGlzIFN0YW5kYnkgQkdQCiAgICAgIEMtbXVsdGljYXN0IHJvdXRlLCB0aGUg UEUgTUFZIGluc3RhbGwgVlJGIFBJTSBzdGF0ZSBjb3JyZXNwb25kaW5nCiAgICAgIHRvIHRoaXMg QkdQIFNvdXJjZSBUcmVlIEpvaW4gcm91dGUgKHRoZSByZXN1bHQgd2lsbCBiZSB0aGF0IEpvaW4K ICAgICAgbWVzc2FnZXMgd2lsbCBiZSBzZW50IHRvIHRoZSBDRSB0b3dhcmQgQy1TLCBhbmQgdGhh dCB0aGUgUEUgd2lsbAogICAgICByZWNlaXZlIChDLVMsIEMtRykgdHJhZmZpYykKCgoKCk1vcmlu LCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBNYXkgMTYsIDIwMjEgICAgICAgICAgICAgICAg IFtQYWdlIDE0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgTVZQTiBGYXN0IFVwc3RyZWFtIEZh aWxvdmVyICAgICAgICAgTm92ZW1iZXIgMjAyMAoKCiAgIGIpIGJhc2VkIG9uIGxvY2FsIHBvbGlj eSwgYXMgc29vbiBhcyB0aGUgUEUgcmVjZWl2ZXMgdGhpcyBTdGFuZGJ5IEJHUAogICAgICBDLW11 bHRpY2FzdCByb3V0ZSwgdGhlIFBFIE1BWSBmb3J3YXJkIChDLVMsIEMtRykgdHJhZmZpYyB0byBv dGhlcgogICAgICBQRXMgdGhyb3VnaCBhIFAtdHVubmVsIGluZGVwZW5kZW50bHkgb2YgdGhlIHJl YWNoYWJpbGl0eSBvZiBDLVMKICAgICAgdGhyb3VnaCBzb21lIG90aGVyIFBFLiBbbm90ZSB0aGF0 IHRoaXMgaW1wbGllcyBhbHNvIGRvaW5nIGEpXQoKICAgRG9pbmcgbmVpdGhlciBhKSBvciBiKSBm b3IgYSBnaXZlbiAoQy1TLCBDLUcpIGlzIGNhbGxlZCAiY29sZCByb290CiAgIHN0YW5kYnkiLgoK ICAgRG9pbmcgYSkgYnV0IG5vdCBiKSBmb3IgYSBnaXZlbiAoQy1TLCBDLUcpIGlzIGNhbGxlZCAi d2FybSByb290CiAgIHN0YW5kYnkiLgoKICAgRG9pbmcgYikgKHdoaWNoIGltcGxpZXMgYWxzbyBk b2luZyBhKSkgZm9yIGEgZ2l2ZW4gKEMtUywgQy1HKSBpcwogICBjYWxsZWQgImhvdCByb290IHN0 YW5kYnkiLgoKICAgTm90ZSB0aGF0LCBpZiBhbiBVcHN0cmVhbSBQRSB1c2VzIGFuIFMtUE1TSSBv bmx5IHBvbGljeSwgaXQgc2hhbGwKICAgYWR2ZXJ0aXNlIGFuIFMtUE1TSSBmb3IgYSAoQy1TLCBD LUcpIGFzIHNvb24gYXMgaXQgcmVjZWl2ZXMgYQogICBDLW11bHRpY2FzdCByb3V0ZSBmb3IgKEMt UywgQy1HKSwgbm9ybWFsIG9yIFN0YW5kYnk7IGkuZS4sIGl0IHNoYWxsCiAgIG5vdCB3YWl0IGZv ciByZWNlaXZpbmcgYSBub24tU3RhbmRieSBDLW11bHRpY2FzdCByb3V0ZSBiZWZvcmUKICAgYWR2 ZXJ0aXNpbmcgdGhlIGNvcnJlc3BvbmRpbmcgUy1QTVNJLgoKICAgU2VjdGlvbiA5LjMuMiBvZiBb UkZDNjUxNF0sIGRlc2NyaWJlcyB0aGUgcHJvY2VkdXJlcyBvZiBzZW5kaW5nIGEKICAgU291cmNl LUFjdGl2ZSBBLUQgUm91dGUgYXMgYSByZXN1bHQgb2YgcmVjZWl2aW5nIHRoZSBDLW11bHRpY2Fz dAogICByb3V0ZS4gIFRoZXNlIHByb2NlZHVyZXMgTVVTVCBiZSBmb2xsb3dlZCBmb3IgYm90aCB0 aGUgbm9ybWFsIGFuZAogICBTdGFuZGJ5IEMtbXVsdGljYXN0IHJvdXRlcy4KCjQuMy4gIFJlYWNo YWJpbGl0eSBEZXRlcm1pbmF0aW9uCgogICBUaGUgU3RhbmRieSBVcHN0cmVhbSBQRSBjYW4gdXNl IHRoZSBmb2xsb3dpbmcgaW5mb3JtYXRpb24gdG8KICAgZGV0ZXJtaW5lIHRoYXQgQy1TIGNhbiBv ciBjYW5ub3QgYmUgcmVhY2hlZCB0aHJvdWdoIHRoZSBQcmltYXJ5CiAgIFVwc3RyZWFtIFBFOgoK ICAgbyAgcHJlc2VuY2UvYWJzZW5jZSBvZiBhIHVuaWNhc3QgVlBOIHJvdXRlIHRvd2FyZCBDLVMK CiAgIG8gIHN1cHBvc2luZyB0aGF0IHRoZSBTdGFuZGJ5IFVwc3RyZWFtIFBFIGlzIHRoZSBlZ3Jl c3Mgb2YgdGhlIHR1bm5lbAogICAgICByb290ZWQgYXQgdGhlIFByaW1hcnkgVXBzdHJlYW0gUEUs IHRoZSBTdGFuZGJ5IFVwc3RyZWFtIFBFIGNhbgogICAgICBkZXRlcm1pbmUgdGhlIHJlYWNoYWJp bGl0eSBvZiBDLVMgdGhyb3VnaCB0aGUgUHJpbWFyeSBVcHN0cmVhbSBQRQogICAgICBiYXNlZCBv biB0aGUgc3RhdHVzIG9mIHRoaXMgdHVubmVsLCBkZXRlcm1pbmVkIHRoYW5rcyB0byB0aGUgc2Ft ZQogICAgICBjcml0ZXJpYSBhcyB0aGUgb25lcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjEgKHdp dGhvdXQgdXNpbmcgdGhlCiAgICAgIFVNSCBzZWxlY3Rpb24gcHJvY2VkdXJlcyBvZiBTZWN0aW9u IDMpOwoKICAgbyAgb3RoZXIgbWVjaGFuaXNtcyBNQVkgYmUgdXNlZC4KCjQuNC4gIEludGVyLUFT CgogICBJZiB0aGUgbm9uLXNlZ21lbnRlZCBpbnRlci1BUyBhcHByb2FjaCBpcyB1c2VkLCB0aGUg cHJvY2VkdXJlcwogICBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LjEgdGhyb3VnaCBTZWN0aW9uIDQu MyBjYW4gYmUgYXBwbGllZC4KCgoKCgpNb3JpbiwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMg TWF5IDE2LCAyMDIxICAgICAgICAgICAgICAgICBbUGFnZSAxNV0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgIE1WUE4gRmFzdCBVcHN0cmVhbSBGYWlsb3ZlciAgICAgICAgIE5vdmVtYmVyIDIwMjAK CgogICBXaGVuIG11bHRpY2FzdCBWUE5zIGFyZSB1c2VkIGluIGFuIGludGVyLUFTIGNvbnRleHQg d2l0aCB0aGUKICAgc2VnbWVudGVkIGludGVyLUFTIGFwcHJvYWNoIGRlc2NyaWJlZCBpbiBTZWN0 aW9uIDkuMiBvZiBbUkZDNjUxNF0sCiAgIHRoZSBwcm9jZWR1cmVzIGluIHRoaXMgc2VjdGlvbiBj YW4gYmUgYXBwbGllZC4KCiAgIEEgcHJlLXJlcXVpc2l0ZSBmb3IgdGhlIHByb2NlZHVyZXMgZGVz Y3JpYmVkIGJlbG93IHRvIGJlIGFwcGxpZWQgZm9yCiAgIGEgc291cmNlIG9mIGEgZ2l2ZW4gTVZQ TiBpczoKCiAgIG8gIHRoYXQgYW55IFBFIG9mIHRoaXMgTVZQTiByZWNlaXZlcyB0d28gb3IgbW9y ZSBJbnRlci1BUyBJLVBNU0kgQS1ECiAgICAgIFJvdXRlcyBhZHZlcnRpc2VkIGJ5IHRoZSBBUyBv ZiB0aGUgc291cmNlCgogICBvICB0aGF0IHRoZXNlIEludGVyLUFTIEktUE1TSSBBLUQgUm91dGVz IGhhdmUgZGlzdGluY3QgUm91dGUKICAgICAgRGlzdGluZ3Vpc2hlcnMgKGFzIGRlc2NyaWJlZCBp biBpdGVtICIoMikiIG9mIHNlY3Rpb24gOS4yIG9mCiAgICAgIFtSRkM2NTE0XSkuCgogICBBcyBh biBleGFtcGxlLCB0aGVzZSBjb25kaXRpb25zIHdpbGwgYmUgc2F0aXNmaWVkIHdoZW4gdGhlIHNv dXJjZSBpcwogICBkdWFsLWhvbWVkIHRvIGFuIEFTIHRoYXQgY29ubmVjdHMgdG8gdGhlIHJlY2Vp dmVyIEFTIHRocm91Z2ggdHdvIEFTQlIKICAgdXNpbmcgYXV0by1jb25maWd1cmVkIFJEcy4KCjQu NC4xLiAgSW50ZXItQVMgUHJvY2VkdXJlcyBmb3IgZG93bnN0cmVhbSBQRXMsIEFTQlIgRmFzdCBG YWlsb3ZlcgoKICAgVGhlIGZvbGxvd2luZyBwcm9jZWR1cmUgaXMgYXBwbGllZCBieSBkb3duc3Ry ZWFtIFBFcyBvZiBhbiBBUywgZm9yIGEKICAgc291cmNlIFMgaW4gYSByZW1vdGUgQVMuCgogICBB ZGRpdGlvbmFsbHkgdG8gY2hvb3NpbmcgYW4gSW50ZXItQVMgSS1QTVNJIEEtRCBSb3V0ZSBhZHZl cnRpc2VkIGZyb20KICAgdGhlIEFTIG9mIHRoZSBzb3VyY2UgdG8gY29uc3RydWN0IGEgQy1tdWx0 aWNhc3Qgcm91dGUsIGFzIGRlc2NyaWJlZAogICBpbiBzZWN0aW9uIDExLjEuMyBbUkZDNjUxNF0s IGEgZG93bnN0cmVhbSBQRSB3aWxsIGNob29zZSBhIHNlY29uZAogICBJbnRlci1BUyBJLVBNU0kg QS1EIFJvdXRlIGFkdmVydGlzZWQgZnJvbSB0aGUgQVMgb2YgdGhlIHNvdXJjZSBhbmQKICAgdXNl IHRoaXMgcm91dGUgdG8gY29uc3RydWN0IGFuZCBhZHZlcnRpc2UgYSBTdGFuZGJ5IEMtbXVsdGlj YXN0IHJvdXRlCiAgIChDLW11bHRpY2FzdCByb3V0ZSBjYXJyeWluZyB0aGUgU3RhbmRieSBleHRl bmRlZCBjb21tdW5pdHkpLCBhcwogICBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LjEuCgo0LjQuMi4g IEludGVyLUFTIFByb2NlZHVyZXMgZm9yIEFTQlJzCgogICBXaGVuIGFuIFVwc3RyZWFtIEFTQlIg cmVjZWl2ZXMgYSBDLW11bHRpY2FzdCByb3V0ZSwgYW5kIGF0IGxlYXN0IG9uZQogICBvZiB0aGUg UlRzIG9mIHRoZSByb3V0ZSBtYXRjaGVzIG9uZSBvZiB0aGUgQVNCUiBJbXBvcnQgUlQsIHRoZSBB U0JSLAogICB0aGF0IHN1cHBvcnRzIHRoaXMgc3BlY2lmaWNhdGlvbiwgTVVTVCB0cnkgdG8gbG9j YXRlIGFuIEludGVyLUFTCiAgIEktUE1TSSBBLUQgUm91dGUgd2hvc2UgUkQgYW5kIFNvdXJjZSBB UyByZXNwZWN0aXZlbHkgbWF0Y2ggdGhlIFJEIGFuZAogICBTb3VyY2UgQVMgY2FycmllZCBpbiB0 aGUgQy1tdWx0aWNhc3Qgcm91dGUuICBJZiB0aGUgbWF0Y2ggaXMgZm91bmQsCiAgIGFuZCB0aGUg Qy1tdWx0aWNhc3Qgcm91dGUgY2FycmllcyB0aGUgU3RhbmRieSBQRSBCR1AgQ29tbXVuaXR5LCB0 aGVuCiAgIHRoZSBBU0JSIE1VU1QgcGVyZm9ybSBhcyBmb2xsb3dzOgoKICAgbyAgaWYgdGhlIHJv dXRlIHdhcyByZWNlaXZlZCBvdmVyIGlCR1AgYW5kIGl0cyBMT0NBTF9QUkVGIGF0dHJpYnV0ZQog ICAgICBpcyBzZXQgdG8gemVybywgdGhlbiBpdCBNVVNUIGJlIHJlLWFkdmVydGlzZWQgaW4gZUJH UCB3aXRoIGEgTUVECiAgICAgIGF0dHJpYnV0ZSAoTVVMVElfRVhJVF9ESVNDKSBzZXQgdG8gdGhl IGhpZ2hlc3QgcG9zc2libGUgdmFsdWUKICAgICAgKDB4ZmZmZikKCgoKCgoKTW9yaW4sIGV0IGFs LiAgICAgICAgICAgICBFeHBpcmVzIE1heSAxNiwgMjAyMSAgICAgICAgICAgICAgICAgW1BhZ2Ug MTZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBNVlBOIEZhc3QgVXBzdHJlYW0gRmFpbG92ZXIg ICAgICAgICBOb3ZlbWJlciAyMDIwCgoKICAgbyAgaWYgdGhlIHJvdXRlIHdhcyByZWNlaXZlZCBv dmVyIGVCR1AgYW5kIGl0cyBNRUQgYXR0cmlidXRlIHNldCB0bwogICAgICAweGZmZmYsIHRoZW4g aXQgTVVTVCBiZSByZS1hZHZlcnRpc2VkIGluIGlCR1Agd2l0aCBhIExPQ0FMX1BSRUYKICAgICAg YXR0cmlidXRlIHNldCB0byB6ZXJvCgogICBPdGhlciBBU0JSIHByb2NlZHVyZXMgYXJlIGFwcGxp ZWQgd2l0aG91dCBtb2RpZmljYXRpb24uCgo1LiAgSG90IFJvb3QgU3RhbmRieQoKICAgVGhlIG1l Y2hhbmlzbXMgZGVmaW5lZCBpbiBTZWN0aW9uIDQgYW5kIFNlY3Rpb24gMyBjYW4gYmUgdXNlZAog ICB0b2dldGhlciBhcyBmb2xsb3dzLgoKICAgVGhlIHByaW5jaXBsZSBpcyB0aGF0LCBmb3IgYSBn aXZlbiBWUkYgKG9yIHBvc3NpYmx5IG9ubHkgZm9yIGEgZ2l2ZW4KICAgKEMtUywgQy1HKToKCiAg IG8gIGRvd25zdHJlYW0gUEVzIGFkdmVydGlzZSBhIFN0YW5kYnkgQkdQIEMtbXVsdGljYXN0IHJv dXRlIChiYXNlZCBvbgogICAgICBTZWN0aW9uIDQpCgogICBvICBVcHN0cmVhbSBQRXMgdXNlIHRo ZSAiaG90IHN0YW5kYnkiIG9wdGlvbmFsIGJlaGF2aW9yIGFuZCB0aHVzIHdpbGwKICAgICAgZm9y d2FyZCB0cmFmZmljIGZvciBhIGdpdmVuIG11bHRpY2FzdCBzdGF0ZSBhcyBzb29uIGFzIHRoZXkg aGF2ZQogICAgICB3aGV0aGVyIGEgKHByaW1hcnkpIEJHUCBDLW11bHRpY2FzdCByb3V0ZSBvciBh IFN0YW5kYnkgQkdQCiAgICAgIEMtbXVsdGljYXN0IHJvdXRlIGZvciB0aGF0IHN0YXRlIChvciBi b3RoKQoKICAgbyAgZG93bnN0cmVhbSBQRXMgYWNjZXB0IHRyYWZmaWMgZnJvbSB0aGUgcHJpbWFy eSBvciBzdGFuZGJ5IHR1bm5lbCwKICAgICAgYmFzZWQgb24gdGhlIHN0YXR1cyBvZiB0aGUgdHVu bmVsIChiYXNlZCBvbiBTZWN0aW9uIDMpCgogICBPdGhlciBjb21iaW5hdGlvbnMgb2YgdGhlIG1l Y2hhbmlzbXMgcHJvcG9zZWQgaW4gU2VjdGlvbiA0IGFuZAogICBTZWN0aW9uIDMgYXJlIGZvciBm dXJ0aGVyIHN0dWR5LgoKICAgTm90ZSB0aGF0IHRoZSBzYW1lIGxldmVsIG9mIHByb3RlY3Rpb24g d291bGQgYmUgYWNoaWV2YWJsZSB3aXRoIGEKICAgc2ltcGxlIEMtbXVsdGljYXN0IFNvdXJjZSBU cmVlIEpvaW4gcm91dGUgYWR2ZXJ0aXNlZCB0byBib3RoIHRoZQogICBwcmltYXJ5IGFuZCBzZWNv bmRhcnkgVXBzdHJlYW0gUEVzIChjYXJyeWluZyBhcyBSb3V0ZSBUYXJnZXQgZXh0ZW5kZWQKICAg Y29tbXVuaXRpZXMsIHRoZSB2YWx1ZXMgb2YgdGhlIFZSRiBSb3V0ZSBJbXBvcnQgYXR0cmlidXRl IG9mIGVhY2ggVlBOCiAgIHJvdXRlIGZyb20gZWFjaCBVcHN0cmVhbSBQRXMpLiAgVGhlIGFkdmFu dGFnZSBvZiB1c2luZyB0aGUgU3RhbmRieQogICBzZW1hbnRpYyBpcyB0aGF0LCBzdXBwb3Npbmcg dGhhdCBkb3duc3RyZWFtIFBFcyBhbHdheXMgYWR2ZXJ0aXNlIGEKICAgU3RhbmRieSBDLW11bHRp Y2FzdCByb3V0ZSB0byB0aGUgc2Vjb25kYXJ5IFVwc3RyZWFtIFBFLCBpdCBhbGxvd3MgdG8KICAg Y2hvb3NlIHRoZSBwcm90ZWN0aW9uIGxldmVsIHRocm91Z2ggYSBjaGFuZ2Ugb2YgY29uZmlndXJh dGlvbiBvbiB0aGUKICAgc2Vjb25kYXJ5IFVwc3RyZWFtIFBFLCB3aXRob3V0IHJlcXVpcmluZyBh bnkgcmVjb25maWd1cmF0aW9uIG9mIGFsbAogICB0aGUgZG93bnN0cmVhbSBQRXMuCgo2LiAgRHVw bGljYXRlIFBhY2tldHMKCiAgIE11bHRpY2FzdCBWUE4gc3BlY2lmaWNhdGlvbnMgW1JGQzY1MTNd IGltcG9zZSB0aGF0IGEgUEUgb25seSBmb3J3YXJkcwogICB0byBDRXMgdGhlIHBhY2tldHMgY29t aW5nIGZyb20gdGhlIGV4cGVjdGVkIFVwc3RyZWFtIFBFIChTZWN0aW9uIDkuMQogICBvZiBbUkZD NjUxM10pLgoKICAgV2UgZHJhdyB0aGUgcmVhZGVyJ3MgYXR0ZW50aW9uIHRvIHRoZSBmYWN0IHRo YXQgdGhlIHJlc3BlY3Qgb2YgdGhpcwogICBwYXJ0IG9mIG11bHRpY2FzdCBWUE4gc3BlY2lmaWNh dGlvbnMgaXMgZXNwZWNpYWxseSBpbXBvcnRhbnQgd2hlbiB0d28KICAgZGlzdGluY3QgVXBzdHJl YW0gUEVzIGFyZSBzdXNjZXB0aWJsZSB0byBmb3J3YXJkIHRoZSBzYW1lIHRyYWZmaWMgb24KCgoK TW9yaW4sIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1heSAxNiwgMjAyMSAgICAgICAgICAg ICAgICAgW1BhZ2UgMTddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBNVlBOIEZhc3QgVXBzdHJl YW0gRmFpbG92ZXIgICAgICAgICBOb3ZlbWJlciAyMDIwCgoKICAgUC10dW5uZWxzIGF0IHRoZSBz YW1lIHRpbWUgaW4gdGhlIHN0ZWFkeSBzdGF0ZS4gIFRoYXQgd2lsbCBiZSB0aGUKICAgY2FzZSB3 aGVuICJob3Qgcm9vdCBzdGFuZGJ5IiBtb2RlIGlzIHVzZWQgKFNlY3Rpb24gNCksIGFuZCB3aGlj aCBjYW4KICAgYWxzbyBiZSB0aGUgY2FzZSBpZiBwcm9jZWR1cmVzIG9mIFNlY3Rpb24gMyBhcmUg dXNlZCBhbmQgYSkgdGhlIHJ1bGVzCiAgIGRldGVybWluaW5nIHRoZSBzdGF0dXMgb2YgYSB0cmVl IGFyZSBub3QgdGhlIHNhbWUgb24gdHdvIGRpc3RpbmN0CiAgIGRvd25zdHJlYW0gUEVzIG9yIGIp IHRoZSBydWxlIGRldGVybWluaW5nIHRoZSBzdGF0dXMgb2YgYSB0cmVlCiAgIGRlcGVuZHMgb24g Y29uZGl0aW9ucyBsb2NhbCB0byBhIFBFIChlLmcuLCB0aGUgUEUtUCB1cHN0cmVhbSBsaW5rCiAg IGJlaW5nIHVwKS4KCjcuICBJQU5BIENvbnNpZGVyYXRpb25zCgo3LjEuICBTdGFuZGJ5IFBFIENv bW11bml0eQoKICAgSUFOQSBpcyByZXF1ZXN0ZWQgdG8gYWxsb2NhdGUgdGhlIEJHUCAiU3RhbmRi eSBQRSIgY29tbXVuaXR5IHZhbHVlCiAgIChUQkExKSBmcm9tIHRoZSBCb3JkZXIgR2F0ZXdheSBQ cm90b2NvbCAoQkdQKSBXZWxsLWtub3duIENvbW11bml0aWVzCiAgIHJlZ2lzdHJ5IHVzaW5nIHRo ZSBGaXJzdCBDb21lIEZpcnN0IFNlcnZlZCByZWdpc3RyYXRpb24gcG9saWN5LgoKNy4yLiAgQkZE IERpc2NyaW1pbmF0b3IKCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBCR1Agb3B0aW9u YWwgdHJhbnNpdGl2ZSBhdHRyaWJ1dGUsIGNhbGxlZAogICAiQkZEIERpc2NyaW1pbmF0b3IiLiAg SUFOQSBpcyByZXF1ZXN0ZWQgdG8gYWxsb2NhdGUgYSBjb2RlcG9pbnQKICAgKFRCQTIpIGluIHRo ZSAiQkdQIFBhdGggQXR0cmlidXRlcyIgcmVnaXN0cnkgdG8gdGhlIEJGRCBEaXNjcmltaW5hdG9y CiAgIGF0dHJpYnV0ZS4KCiAgIElBTkEgaXMgcmVxdWVzdGVkIHRvIGNyZWF0ZSBhIG5ldyBCRkQg TW9kZSBzdWItcmVnaXN0cnkgaW4gdGhlIEJvcmRlcgogICBHYXRld2F5IFByb3RvY29sIChCR1Ap IFBhcmFtZXRlcnMgcmVnaXN0cnkuICBUaGUgcmVnaXN0cmF0aW9uCiAgIHBvbGljaWVzLCBwZXIg W1JGQzgxMjZdLCBmb3IgdGhpcyBzdWItcmVnaXN0cnkgYXJlIGFjY29yZGluZyB0bwogICBUYWJs ZSAxLgoKICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rCiAgICAgICAgICAgICAgICAgIHwgVmFsdWUgICAgIHwgICAgICAgICAgUG9saWN5ICAg ICAgICAgfAogICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSsKICAgICAgICAgICAgICAgICAgfCAwLSAxNzUgICAgfCAgICAgICBJRVRGIFJldmll dyAgICAgICB8CiAgICAgICAgICAgICAgICAgIHwgMTc2IC0gMjQ5IHwgRmlyc3QgQ29tZSBGaXJz dCBTZXJ2ZWQgfAogICAgICAgICAgICAgICAgICB8IDI1MCAtIDI1NCB8ICAgICBFeHBlcmltZW50 YWwgVXNlICAgIHwKICAgICAgICAgICAgICAgICAgfCAyNTUgICAgICAgfCAgICAgICBJRVRGIFJl dmlldyAgICAgICB8CiAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKwoKICAgICAgICAgICBUYWJsZSAxOiBCRkQgTW9kZSBTdWItcmVnaXN0cnkg UmVnaXN0cmF0aW9uIFBvbGljaWVzCgogICBJQU5BIGlzIHJlcXVlc3RlZCB0byBtYWtlIGluaXRp YWwgYXNzaWdubWVudHMgYWNjb3JkaW5nIHRvIFRhYmxlIDIuCgoKCgoKCgoKCgoKTW9yaW4sIGV0 IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1heSAxNiwgMjAyMSAgICAgICAgICAgICAgICAgW1Bh Z2UgMThdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBNVlBOIEZhc3QgVXBzdHJlYW0gRmFpbG92 ZXIgICAgICAgICBOb3ZlbWJlciAyMDIwCgoKICAgICAgICAgICAgICstLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgfCBWYWx1ZSAgICAg fCAgIERlc2NyaXB0aW9uICAgIHwgUmVmZXJlbmNlICAgICB8CiAgICAgICAgICAgICArLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgIHwg MCAgICAgICAgIHwgICAgIFJlc2VydmVkICAgICB8IFRoaXMgZG9jdW1lbnQgfAogICAgICAgICAg ICAgfCAxICAgICAgICAgfCBQMk1QIEJGRCBTZXNzaW9uIHwgVGhpcyBkb2N1bWVudCB8CiAgICAg ICAgICAgICB8IDItIDE3NSAgICB8ICAgIFVuYXNzaWduZWQgICAgfCBUaGlzIGRvY3VtZW50IHwK ICAgICAgICAgICAgIHwgMTc2IC0gMjQ5IHwgICAgVW5hc3NpZ25lZCAgICB8IFRoaXMgZG9jdW1l bnQgfAogICAgICAgICAgICAgfCAyNTAgLSAyNTQgfCBFeHBlcmltZW50YWwgVXNlIHwgVGhpcyBk b2N1bWVudCB8CiAgICAgICAgICAgICB8IDI1NSAgICAgICB8ICAgICBSZXNlcnZlZCAgICAgfCBU aGlzIGRvY3VtZW50IHwKICAgICAgICAgICAgICstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tKwoKICAgICAgICAgICAgICAgICAgICAgIFRhYmxlIDI6IEJGRCBN b2RlIFN1Yi1yZWdpc3RyeQoKNy4zLiAgQkZEIERpc2NyaW1pbmF0b3IgT3B0aW9uYWwgU3ViLVRM ViBUeXBlCgogICBJQU5BIGlzIHJlcXVlc3RlZCB0byBjcmVhdGUgYSBuZXcgQkZEIERpc2NyaW1p bmF0b3IgT3B0aW9uYWwgc3ViLVRMVgogICBUeXBlIHN1Yi1yZWdpc3RyeSBpbiBCb3JkZXIgR2F0 ZXdheSBQcm90b2NvbCAoQkdQKS4gIFRoZSByZWdpc3RyYXRpb24KICAgcG9saWNpZXMsIHBlciBb UkZDODEyNl0sIGZvciB0aGlzIHN1Yi1yZWdpc3RyeSBhcmUgYWNjb3JkaW5nIHRvCiAgIFRhYmxl IDMuCgogICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSsKICAgICAgICAgICAgICAgICAgfCBWYWx1ZSAgICAgfCAgICAgICAgICBQb2xpY3kgICAg ICAgICB8CiAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKwogICAgICAgICAgICAgICAgICB8IDAtIDE3NSAgICB8ICAgICAgIElFVEYgUmV2aWV3 ICAgICAgIHwKICAgICAgICAgICAgICAgICAgfCAxNzYgLSAyNDkgfCBGaXJzdCBDb21lIEZpcnN0 IFNlcnZlZCB8CiAgICAgICAgICAgICAgICAgIHwgMjUwIC0gMjU0IHwgICAgIEV4cGVyaW1lbnRh bCBVc2UgICAgfAogICAgICAgICAgICAgICAgICB8IDI1NSAgICAgICB8ICAgICAgIElFVEYgUmV2 aWV3ICAgICAgIHwKICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rCgogICAgICAgVGFibGUgMzogQkZEIERpc2NyaW1pbmF0b3IgT3B0aW9uYWwg U3ViLVRMViBUeXBlIFN1Yi1yZWdpc3RyeQogICAgICAgICAgICAgICAgICAgICAgICAgICBSZWdp c3RyYXRpb24gUG9saWNpZXMKCiAgIElBTkEgaXMgcmVxdWVzdGVkIHRvIG1ha2UgaW5pdGlhbCBh c3NpZ25tZW50cyBhY2NvcmRpbmcgdG8gVGFibGUgNC4KCiAgICAgICAgICAgICArLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgIHwgVmFs dWUgICAgIHwgICBEZXNjcmlwdGlvbiAgICB8IFJlZmVyZW5jZSAgICAgfAogICAgICAgICAgICAg Ky0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rCiAgICAgICAg ICAgICB8IDAgICAgICAgICB8ICAgICBSZXNlcnZlZCAgICAgfCBUaGlzIGRvY3VtZW50IHwKICAg ICAgICAgICAgIHwgMS0gMTc1ICAgIHwgICAgVW5hc3NpZ25lZCAgICB8IFRoaXMgZG9jdW1lbnQg fAogICAgICAgICAgICAgfCAxNzYgLSAyNDkgfCAgICBVbmFzc2lnbmVkICAgIHwgVGhpcyBkb2N1 bWVudCB8CiAgICAgICAgICAgICB8IDI1MCAtIDI1NCB8IEV4cGVyaW1lbnRhbCBVc2UgfCBUaGlz IGRvY3VtZW50IHwKICAgICAgICAgICAgIHwgMjU1ICAgICAgIHwgICAgIFJlc2VydmVkICAgICB8 IFRoaXMgZG9jdW1lbnQgfAogICAgICAgICAgICAgKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0rCgogICAgICAgVGFibGUgNDogQkZEIERpc2NyaW1pbmF0b3Ig T3B0aW9uYWwgU3ViLVRMViBUeXBlIFN1Yi1yZWdpc3RyeQoKCgoKCgpNb3JpbiwgZXQgYWwuICAg ICAgICAgICAgIEV4cGlyZXMgTWF5IDE2LCAyMDIxICAgICAgICAgICAgICAgICBbUGFnZSAxOV0K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgIE1WUE4gRmFzdCBVcHN0cmVhbSBGYWlsb3ZlciAgICAg ICAgIE5vdmVtYmVyIDIwMjAKCgo4LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIFRoaXMg ZG9jdW1lbnQgZGVzY3JpYmVzIHByb2NlZHVyZXMgYmFzZWQgb24gW1JGQzY1MTNdIGFuZCBbUkZD NjUxNF0KICAgYW5kIGhlbmNlIHNoYXJlcyB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgcmVz cGVjdGl2ZWx5IHJlcHJlc2VudGVkCiAgIGluIHRoZXNlIHNwZWNpZmljYXRpb25zLgoKICAgVGhp cyBkb2N1bWVudCB1c2VzIFAyTVAgQkZELCBhcyBkZWZpbmVkIGluIFtSRkM4NTYyXSwgd2hpY2gs IGluIHR1cm4sCiAgIGlzIGJhc2VkIG9uIFtSRkM1ODgwXS4gIFNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIHJlbGV2YW50IHRvIGVhY2gKICAgcHJvdG9jb2wgYXJlIGRpc2N1c3NlZCBpbiB0aGUgcmVz cGVjdGl2ZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucy4gIEFuCiAgIGltcGxlbWVudGF0aW9uIHRo YXQgc3VwcG9ydHMgdGhpcyBzcGVjaWZpY2F0aW9uIE1VU1QgdXNlIGEgbWVjaGFuaXNtCiAgIHRv IGNvbnRyb2wgdGhlIG1heGltdW0gbnVtYmVyIG9mIFAyTVAgQkZEIHNlc3Npb25zIHRoYXQgY2Fu IGJlIGFjdGl2ZQogICBhdCB0aGUgc2FtZSB0aW1lLgoKOS4gIEFja25vd2xlZGdtZW50cwoKICAg VGhlIGF1dGhvcnMgd2FudCB0byB0aGFuayBHcmVnIFJlYXVtZSwgRXJpYyBSb3NlbiwgSmVmZnJl eSBaaGFuZywKICAgTWFydGluIFZpZ291cmV1eCwgQWRyaWFuIEZhcnJlbCwgYW5kIFpoZW5nIChT YW5keSkgWmhhbmcgZm9yIHRoZWlyCiAgIHJldmlld3MsIHVzZWZ1bCBjb21tZW50cywgYW5kIGhl bHBmdWwgc3VnZ2VzdGlvbnMuCgoxMC4gIENvbnRyaWJ1dG9yIEFkZHJlc3NlcwoKICAgQmVsb3cg aXMgYSBsaXN0IG9mIG90aGVyIGNvbnRyaWJ1dGluZyBhdXRob3JzIGluIGFscGhhYmV0aWNhbCBv cmRlcjoKCiAgICAgIFJhaHVsIEFnZ2Fyd2FsCiAgICAgIEFya3RhbgoKICAgICAgRW1haWw6IHJh Z2dhcndhXzFAeWFob28uY29tCgoKCiAgICAgIE5laGFsIEJoYXUKICAgICAgQ2lzY28KCiAgICAg IEVtYWlsOiBOQmhhdUBjaXNjby5jb20KCgoKICAgICAgQ2xheXRvbiBIYXNzZW4KICAgICAgQmVs bCBDYW5hZGEKICAgICAgMjk1NSBWaXJ0dWFsIFdheQogICAgICBWYW5jb3V2ZXIKICAgICAgQ0FO QURBCgogICAgICBFbWFpbDogQ2xheXRvbi5IYXNzZW5AYmVsbC5jYQoKCgogICAgICBXaW0gSGVu ZGVyaWNreAoKCgpNb3JpbiwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDE2LCAyMDIx ICAgICAgICAgICAgICAgICBbUGFnZSAyMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIE1WUE4g RmFzdCBVcHN0cmVhbSBGYWlsb3ZlciAgICAgICAgIE5vdmVtYmVyIDIwMjAKCgogICAgICBOb2tp YQogICAgICBDb3Blcm5pY3VzbGFhbiA1MAogICAgICBBbnR3ZXJwICAyMDE4CiAgICAgIEJlbGdp dW0KCiAgICAgIEVtYWlsOiB3aW0uaGVuZGVyaWNreEBub2tpYS5jb20KCgoKICAgICAgUHJhZGVl cCBKYWluCiAgICAgIE5va2lhCiAgICAgIDcwMSBFIE1pZGRsZWZpZWxkIFJkCiAgICAgIE1vdW50 YWluIFZpZXcsIENBICA5NDA0MwogICAgICBVU0EKCiAgICAgIEVtYWlsOiBwcmFkZWVwLmphaW5A bm9raWEuY29tCgoKCiAgICAgIEpheWFudCBLb3RhbHdhcgogICAgICBOb2tpYQogICAgICA3MDEg RSBNaWRkbGVmaWVsZCBSZAogICAgICBNb3VudGFpbiBWaWV3LCBDQSAgOTQwNDMKICAgICAgVVNB CgogICAgICBFbWFpbDogSmF5YW50LktvdGFsd2FyQG5va2lhLmNvbQoKCiAgICAgIFByYXZlZW4g TXVsZXkKICAgICAgTm9raWEKICAgICAgNzAxIEVhc3QgTWlkZGxlZmllbGQgUmQKICAgICAgTW91 bnRhaW4gVmlldywgQ0EgIDk0MDQzCiAgICAgIFUuUy5BLgoKICAgICAgRW1haWw6IHByYXZlZW4u bXVsZXlAbm9raWEuY29tCgoKCiAgICAgIFJheSAoTGVpKSBRaXUKICAgICAgSnVuaXBlciBOZXR3 b3JrcwogICAgICAxMTk0IE5vcnRoIE1hdGhpbGRhIEF2ZS4KICAgICAgU3Vubnl2YWxlLCBDQSAg OTQwODkKICAgICAgVS5TLkEuCgogICAgICBFbWFpbDogcnFpdUBqdW5pcGVyLm5ldAoKCgoKCgpN b3JpbiwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDE2LCAyMDIxICAgICAgICAgICAg ICAgICBbUGFnZSAyMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIE1WUE4gRmFzdCBVcHN0cmVh bSBGYWlsb3ZlciAgICAgICAgIE5vdmVtYmVyIDIwMjAKCgogICAgICBZYWtvdiBSZWtodGVyCiAg ICAgIEp1bmlwZXIgTmV0d29ya3MKICAgICAgMTE5NCBOb3J0aCBNYXRoaWxkYSBBdmUuCiAgICAg IFN1bm55dmFsZSwgQ0EgIDk0MDg5CiAgICAgIFUuUy5BLgoKICAgICAgRW1haWw6IHlha292QGp1 bmlwZXIubmV0CgoKCiAgICAgIEthbndhciBTaW5naAogICAgICBOb2tpYQogICAgICA3MDEgRSBN aWRkbGVmaWVsZCBSZAogICAgICBNb3VudGFpbiBWaWV3LCBDQSAgOTQwNDMKICAgICAgVVNBCgog ICAgICBFbWFpbDoga2Fud2FyLnNpbmdoQG5va2lhLmNvbQoKCgoxMS4gIFJlZmVyZW5jZXMKCjEx LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktl eSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUKICAgICAgICAgICAgICBSZXF1aXJl bWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4 Ny9SRkMyMTE5LCBNYXJjaCAxOTk3LAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRp dG9yLm9yZy9pbmZvL3JmYzIxMTk+LgoKICAgW1JGQzQyNzFdICBSZWtodGVyLCBZLiwgRWQuLCBM aSwgVC4sIEVkLiwgYW5kIFMuIEhhcmVzLCBFZC4sICJBCiAgICAgICAgICAgICAgQm9yZGVyIEdh dGV3YXkgUHJvdG9jb2wgNCAoQkdQLTQpIiwgUkZDIDQyNzEsCiAgICAgICAgICAgICAgRE9JIDEw LjE3NDg3L1JGQzQyNzEsIEphbnVhcnkgMjAwNiwKICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cu cmZjLWVkaXRvci5vcmcvaW5mby9yZmM0MjcxPi4KCiAgIFtSRkM0ODc1XSAgQWdnYXJ3YWwsIFIu LCBFZC4sIFBhcGFkaW1pdHJpb3UsIEQuLCBFZC4sIGFuZCBTLgogICAgICAgICAgICAgIFlhc3Vr YXdhLCBFZC4sICJFeHRlbnNpb25zIHRvIFJlc291cmNlIFJlc2VydmF0aW9uCiAgICAgICAgICAg ICAgUHJvdG9jb2wgLSBUcmFmZmljIEVuZ2luZWVyaW5nIChSU1ZQLVRFKSBmb3IgUG9pbnQtdG8t CiAgICAgICAgICAgICAgTXVsdGlwb2ludCBURSBMYWJlbCBTd2l0Y2hlZCBQYXRocyAoTFNQcyki LCBSRkMgNDg3NSwKICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDNDg3NSwgTWF5IDIwMDcs CiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNDg3NT4u CgogICBbUkZDNTg4MF0gIEthdHosIEQuIGFuZCBELiBXYXJkLCAiQmlkaXJlY3Rpb25hbCBGb3J3 YXJkaW5nIERldGVjdGlvbgogICAgICAgICAgICAgIChCRkQpIiwgUkZDIDU4ODAsIERPSSAxMC4x NzQ4Ny9SRkM1ODgwLCBKdW5lIDIwMTAsCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1l ZGl0b3Iub3JnL2luZm8vcmZjNTg4MD4uCgogICBbUkZDNjUxM10gIFJvc2VuLCBFLiwgRWQuIGFu ZCBSLiBBZ2dhcndhbCwgRWQuLCAiTXVsdGljYXN0IGluIE1QTFMvCiAgICAgICAgICAgICAgQkdQ IElQIFZQTnMiLCBSRkMgNjUxMywgRE9JIDEwLjE3NDg3L1JGQzY1MTMsIEZlYnJ1YXJ5CiAgICAg ICAgICAgICAgMjAxMiwgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNjUxMz4u CgoKCk1vcmluLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBNYXkgMTYsIDIwMjEgICAgICAg ICAgICAgICAgIFtQYWdlIDIyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgTVZQTiBGYXN0IFVw c3RyZWFtIEZhaWxvdmVyICAgICAgICAgTm92ZW1iZXIgMjAyMAoKCiAgIFtSRkM2NTE0XSAgQWdn YXJ3YWwsIFIuLCBSb3NlbiwgRS4sIE1vcmluLCBULiwgYW5kIFkuIFJla2h0ZXIsICJCR1AKICAg ICAgICAgICAgICBFbmNvZGluZ3MgYW5kIFByb2NlZHVyZXMgZm9yIE11bHRpY2FzdCBpbiBNUExT L0JHUCBJUAogICAgICAgICAgICAgIFZQTnMiLCBSRkMgNjUxNCwgRE9JIDEwLjE3NDg3L1JGQzY1 MTQsIEZlYnJ1YXJ5IDIwMTIsCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iu b3JnL2luZm8vcmZjNjUxND4uCgogICBbUkZDNzYwNl0gIENoZW4sIEUuLCBFZC4sIFNjdWRkZXIs IEouLCBFZC4sIE1vaGFwYXRyYSwgUC4sIGFuZCBLLgogICAgICAgICAgICAgIFBhdGVsLCAiUmV2 aXNlZCBFcnJvciBIYW5kbGluZyBmb3IgQkdQIFVQREFURSBNZXNzYWdlcyIsCiAgICAgICAgICAg ICAgUkZDIDc2MDYsIERPSSAxMC4xNzQ4Ny9SRkM3NjA2LCBBdWd1c3QgMjAxNSwKICAgICAgICAg ICAgICA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3NjA2Pi4KCiAgIFtSRkM4 MTI2XSAgQ290dG9uLCBNLiwgTGVpYmEsIEIuLCBhbmQgVC4gTmFydGVuLCAiR3VpZGVsaW5lcyBm b3IKICAgICAgICAgICAgICBXcml0aW5nIGFuIElBTkEgQ29uc2lkZXJhdGlvbnMgU2VjdGlvbiBp biBSRkNzIiwgQkNQIDI2LAogICAgICAgICAgICAgIFJGQyA4MTI2LCBET0kgMTAuMTc0ODcvUkZD ODEyNiwgSnVuZSAyMDE3LAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9y Zy9pbmZvL3JmYzgxMjY+LgoKICAgW1JGQzgxNzRdICBMZWliYSwgQi4sICJBbWJpZ3VpdHkgb2Yg VXBwZXJjYXNlIHZzIExvd2VyY2FzZSBpbiBSRkMKICAgICAgICAgICAgICAyMTE5IEtleSBXb3Jk cyIsIEJDUCAxNCwgUkZDIDgxNzQsIERPSSAxMC4xNzQ4Ny9SRkM4MTc0LAogICAgICAgICAgICAg IE1heSAyMDE3LCA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM4MTc0Pi4KCiAg IFtSRkM4NTYyXSAgS2F0eiwgRC4sIFdhcmQsIEQuLCBQYWxsYWdhdHRpLCBTLiwgRWQuLCBhbmQg Ry4gTWlyc2t5LAogICAgICAgICAgICAgIEVkLiwgIkJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBE ZXRlY3Rpb24gKEJGRCkgZm9yCiAgICAgICAgICAgICAgTXVsdGlwb2ludCBOZXR3b3JrcyIsIFJG QyA4NTYyLCBET0kgMTAuMTc0ODcvUkZDODU2MiwKICAgICAgICAgICAgICBBcHJpbCAyMDE5LCA8 aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM4NTYyPi4KCjExLjIuICBJbmZvcm1h dGl2ZSBSZWZlcmVuY2VzCgogICBbUkZDNDA5MF0gIFBhbiwgUC4sIEVkLiwgU3dhbGxvdywgRy4s IEVkLiwgYW5kIEEuIEF0bGFzLCBFZC4sICJGYXN0CiAgICAgICAgICAgICAgUmVyb3V0ZSBFeHRl bnNpb25zIHRvIFJTVlAtVEUgZm9yIExTUCBUdW5uZWxzIiwgUkZDIDQwOTAsCiAgICAgICAgICAg ICAgRE9JIDEwLjE3NDg3L1JGQzQwOTAsIE1heSAyMDA1LAogICAgICAgICAgICAgIDxodHRwczov L3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzQwOTA+LgoKICAgW1JGQzc0MzFdICBLYXJhbiwg QS4sIEZpbHNmaWxzLCBDLiwgV2lqbmFuZHMsIElKLiwgRWQuLCBhbmQgQi4KICAgICAgICAgICAg ICBEZWNyYWVuZSwgIk11bHRpY2FzdC1Pbmx5IEZhc3QgUmVyb3V0ZSIsIFJGQyA3NDMxLAogICAg ICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM3NDMxLCBBdWd1c3QgMjAxNSwKICAgICAgICAgICAg ICA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3NDMxPi4KCkF1dGhvcnMnIEFk ZHJlc3NlcwoKICAgVGhvbWFzIE1vcmluIChlZGl0b3IpCiAgIE9yYW5nZQogICAyLCBhdmVudWUg UGllcnJlIE1hcnppbgogICBMYW5uaW9uICAyMjMwNwogICBGcmFuY2UKCiAgIEVtYWlsOiB0aG9t YXMubW9yaW5Ab3JhbmdlLWZ0Z3JvdXAuY29tCgoKCgoKCk1vcmluLCBldCBhbC4gICAgICAgICAg ICAgRXhwaXJlcyBNYXkgMTYsIDIwMjEgICAgICAgICAgICAgICAgIFtQYWdlIDIzXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgTVZQTiBGYXN0IFVwc3RyZWFtIEZhaWxvdmVyICAgICAgICAgTm92 ZW1iZXIgMjAyMAoKCiAgIFJvYmVydCBLZWJsZXIgKGVkaXRvcikKICAgSnVuaXBlciBOZXR3b3Jr cwogICAxMTk0IE5vcnRoIE1hdGhpbGRhIEF2ZS4KICAgU3Vubnl2YWxlLCBDQSAgOTQwODkKICAg VS5TLkEuCgogICBFbWFpbDogcmtlYmxlckBqdW5pcGVyLm5ldAoKCiAgIEdyZWcgTWlyc2t5IChl ZGl0b3IpCiAgIFpURSBDb3JwLgoKICAgRW1haWw6IGdyZWdpbWlyc2t5QGdtYWlsLmNvbQoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCk1vcmluLCBldCBhbC4gICAgICAgICAg ICAgRXhwaXJlcyBNYXkgMTYsIDIwMjEgICAgICAgICAgICAgICAgIFtQYWdlIDI0XQo= --00000000000001992105b3ead4c4 Content-Type: text/html; charset="UTF-8"; name="Diff_ draft-ietf-bess-mvpn-fast-failover-12.txt - draft-ietf-bess-mvpn-fast-failover-13.txt.html" Content-Disposition: attachment; filename="Diff_ draft-ietf-bess-mvpn-fast-failover-12.txt - draft-ietf-bess-mvpn-fast-failover-13.txt.html" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_khf09ped1 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPgo8IS0tIHNhdmVkIGZyb20gdXJsPSgwMDQyKWh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9y ZmNkaWZmL3JmY2RpZmYucHlodCAtLT4KPGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5 OTkveGh0bWwiPjxoZWFkPjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PVVURi04Ij4gCiAgIAogIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRl bnQtU3R5bGUtVHlwZSIgY29udGVudD0idGV4dC9jc3MiPiAKICA8dGl0bGU+RGlmZjogZHJhZnQt aWV0Zi1iZXNzLW12cG4tZmFzdC1mYWlsb3Zlci0xMi50eHQgLSBkcmFmdC1pZXRmLWJlc3MtbXZw bi1mYXN0LWZhaWxvdmVyLTEzLnR4dDwvdGl0bGU+IAogIDxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+ IAogICAgYm9keSAgICB7IG1hcmdpbjogMC40ZXg7IG1hcmdpbi1yaWdodDogYXV0bzsgfSAKICAg IHRyICAgICAgeyB9IAogICAgdGQgICAgICB7IHdoaXRlLXNwYWNlOiBwcmU7IGZvbnQtZmFtaWx5 OiBtb25vc3BhY2U7IHZlcnRpY2FsLWFsaWduOiB0b3A7IGZvbnQtc2l6ZTogMC44NmVtO30gCiAg ICB0aCAgICAgIHsgZm9udC1zaXplOiAwLjg2ZW07IH0gCiAgICAuc21hbGwgIHsgZm9udC1zaXpl OiAwLjZlbTsgZm9udC1zdHlsZTogaXRhbGljOyBmb250LWZhbWlseTogVmVyZGFuYSwgSGVsdmV0 aWNhLCBzYW5zLXNlcmlmOyB9IAogICAgLmxlZnQgICB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7 IH0gCiAgICAucmlnaHQgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgfSAKICAgIC5kaWZmICAg eyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NGOyB9IAogICAgLmxibG9jayB7IGJhY2tncm91bmQtY29s b3I6ICNCRkI7IH0gCiAgICAucmJsb2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGODsgfSAKICAg IC5pbnNlcnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOEZGOyB9IAogICAgLmRlbGV0ZSB7IGJhY2tn cm91bmQtY29sb3I6ICNBQ0Y7IH0gCiAgICAudm9pZCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZG QjsgfSAKICAgIC5jb250ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxpbmVi ciB7IGJhY2tncm91bmQtY29sb3I6ICNBQUE7IH0gCiAgICAubGluZW5vIHsgY29sb3I6IHJlZDsg YmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgZm9udC1zaXplOiAwLjdlbTsgdGV4dC1hbGlnbjogcmln aHQ7IHBhZGRpbmc6IDAgMnB4OyB9IAogICAgLmVsaXBzaXN7IGJhY2tncm91bmQtY29sb3I6ICNB QUE7IH0gCiAgICAubGVmdCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICNEREQ7IH0gCiAgICAu cmlnaHQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxibG9jayAuY29u dCB7IGJhY2tncm91bmQtY29sb3I6ICM5RDk7IH0gCiAgICAucmJsb2NrIC5jb250IHsgYmFja2dy b3VuZC1jb2xvcjogI0RENjsgfSAKICAgIC5pbnNlcnQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9y OiAjMEREOyB9IAogICAgLmRlbGV0ZSAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICM4QUQ7IH0g CiAgICAuc3RhdHMsIC5zdGF0cyB0ZCwgLnN0YXRzIHRoIHsgYmFja2dyb3VuZC1jb2xvcjogI0VF RTsgcGFkZGluZzogMnB4IDA7IH0gCiAgICBzcGFuLmhpZGUgeyBkaXNwbGF5OiBub25lOyBjb2xv cjogI2FhYTt9ICAgIGE6aG92ZXIgc3BhbiB7IGRpc3BsYXk6IGlubGluZTsgfSAgICB0ci5jaGFu Z2UgeyBiYWNrZ3JvdW5kLWNvbG9yOiBncmF5OyB9IAogICAgdHIuY2hhbmdlIGEgeyB0ZXh0LWRl Y29yYXRpb246IG5vbmU7IGNvbG9yOiBibGFjayB9IAogIDwvc3R5bGU+IAogICAgIDxzY3JpcHQ+ CnZhciBjaHVua19pbmRleCA9IDA7CnZhciBvbGRfY2h1bmsgPSBudWxsOwoKZnVuY3Rpb24gZm9y bWF0X2NodW5rKGluZGV4KSB7CiAgICB2YXIgcHJlZml4ID0gImRpZmYiOwogICAgdmFyIHN0ciA9 IGluZGV4LnRvU3RyaW5nKCk7CiAgICBmb3IgKHg9MDsgeDwoNC1zdHIubGVuZ3RoKTsgKyt4KSB7 CiAgICAgICAgcHJlZml4Kz0nMCc7CiAgICB9CiAgICByZXR1cm4gcHJlZml4ICsgc3RyOwp9Cgpm dW5jdGlvbiBmaW5kX2NodW5rKG4pewogICAgcmV0dXJuIGRvY3VtZW50LnF1ZXJ5U2VsZWN0b3Io J3RyW2lkJD0iJyArIG4gKyAnIl0nKTsKfQoKZnVuY3Rpb24gY2hhbmdlX2NodW5rKG9mZnNldCkg ewogICAgdmFyIGluZGV4ID0gY2h1bmtfaW5kZXggKyBvZmZzZXQ7CiAgICB2YXIgbmV3X3N0cjsK ICAgIHZhciBuZXdfY2h1bms7CgogICAgbmV3X3N0ciA9IGZvcm1hdF9jaHVuayhpbmRleCk7CiAg ICBuZXdfY2h1bmsgPSBmaW5kX2NodW5rKG5ld19zdHIpOwogICAgaWYgKCFuZXdfY2h1bmspIHsK ICAgICAgICByZXR1cm47CiAgICB9CiAgICBpZiAob2xkX2NodW5rKSB7CiAgICAgICAgb2xkX2No dW5rLnN0eWxlLm91dGxpbmUgPSAiIjsKICAgIH0KICAgIG9sZF9jaHVuayA9IG5ld19jaHVuazsK ICAgIG9sZF9jaHVuay5zdHlsZS5vdXRsaW5lID0gIjFweCBzb2xpZCByZWQiOwogICAgd2luZG93 LmxvY2F0aW9uLmhhc2ggPSAiIyIgKyBuZXdfc3RyOwogICAgd2luZG93LnNjcm9sbEJ5KDAsLTEw MCk7CiAgICBjaHVua19pbmRleCA9IGluZGV4Owp9Cgpkb2N1bWVudC5vbmtleWRvd24gPSBmdW5j dGlvbihlKSB7CiAgICBzd2l0Y2ggKGUua2V5Q29kZSkgewogICAgY2FzZSA3ODoKICAgICAgICBj aGFuZ2VfY2h1bmsoMSk7CiAgICAgICAgYnJlYWs7CiAgICBjYXNlIDgwOgogICAgICAgIGNoYW5n ZV9jaHVuaygtMSk7CiAgICAgICAgYnJlYWs7CiAgICB9Cn07CiAgIDwvc2NyaXB0PiAKPC9oZWFk PiAKPGJvZHkgZGF0YS1uZXctZ3ItYy1zLWNoZWNrLWxvYWRlZD0iMTQuOTgzLjAiPiAKICA8dGFi bGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPiAKICA8dGJvZHk+ PHRyIGlkPSJwYXJ0LTEiIGJnY29sb3I9Im9yYW5nZSI+PHRoPjwvdGg+PHRoPjxhIGhyZWY9Imh0 dHBzOi8vd3d3Ni5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1iZXNzLW12cG4tZmFz dC1mYWlsb3Zlci0xMi50eHQiIHN0eWxlPSJjb2xvcjojMDA4OyB0ZXh0LWRlY29yYXRpb246bm9u ZTsiPiZsdDs8L2E+Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtYmVzcy1tdnBuLWZhc3QtZmFpbG92ZXItMTIudHh0IiBzdHlsZT0iY29sb3I6IzAw OCI+ZHJhZnQtaWV0Zi1iZXNzLW12cG4tZmFzdC1mYWlsb3Zlci0xMi50eHQ8L2E+Jm5ic3A7PC90 aD48dGg+IDwvdGg+PHRoPiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWJlc3MtbXZwbi1mYXN0LWZhaWxvdmVyLTEzLnR4dCIgc3R5bGU9ImNvbG9y OiMwMDgiPmRyYWZ0LWlldGYtYmVzcy1tdnBuLWZhc3QtZmFpbG92ZXItMTMudHh0PC9hPiZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi1i ZXNzLW12cG4tZmFzdC1mYWlsb3Zlci0xMy50eHQiIHN0eWxlPSJjb2xvcjojMDA4OyB0ZXh0LWRl Y29yYXRpb246bm9uZTsiPiZndDs8L2E+PC90aD48dGg+PC90aD48L3RyPiAKICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5OZXR3b3JrIFdvcmtp bmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFQuIE1vcmluLCBF ZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5OZXR3b3JrIFdvcmtpbmcgR3JvdXAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFQuIE1vcmluLCBFZC48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9yYW5nZTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIE9yYW5nZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ SW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAg IFIuIEtlYmxlciwgRWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+SW50ZW5kZWQg c3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgIFIuIEtlYmxl ciwgRWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRp ZmYwMDAxIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPkV4cGlyZXM6IE1heSAxPHNwYW4gY2xhc3M9ImRlbGV0ZSI+LCAy MDIxIDwvc3Bhbj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmlwZXIgTmV0 d29ya3M8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+RXhwaXJlczogTWF5IDE8c3Bh biBjbGFzcz0iaW5zZXJ0Ij42LCAyMDIxPC9zcGFuPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgSnVuaXBlciBOZXR3b3JrczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEcu IE1pcnNreSwgRWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEcuIE1pcnNreSwg RWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBaVEUgQ29ycC48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBaVEUgQ29ycC48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDIiPjx0ZD48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzcGFuIGNs YXNzPSJkZWxldGUiPiBPY3RvYmVyIDI4PC9zcGFuPiwgMjAyMDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPHNwYW4gY2xhc3M9Imluc2VydCI+Tm92ZW1iZXIgMTI8L3NwYW4+LCAyMDIw PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgIE11bHRp Y2FzdCBWUE4gRmFzdCBVcHN0cmVhbSBGYWlsb3ZlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgICAgICAgICAgICAgICAgIE11bHRpY2FzdCBWUE4gRmFzdCBVcHN0cmVhbSBGYWls b3ZlcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZm MDAwMyI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtYmVzcy1tdnBuLWZh c3QtZmFpbG92ZXItMTxzcGFuIGNsYXNzPSJkZWxldGUiPjI8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1iZXNzLW12cG4t ZmFzdC1mYWlsb3Zlci0xPHNwYW4gY2xhc3M9Imluc2VydCI+Mzwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+QWJzdHJhY3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij5BYnN0cmFjdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIGRv Y3VtZW50IGRlZmluZXMgbXVsdGljYXN0IFZQTiBleHRlbnNpb25zIGFuZCBwcm9jZWR1cmVzIHRo YXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGRvY3VtZW50IGRlZmlu ZXMgbXVsdGljYXN0IFZQTiBleHRlbnNpb25zIGFuZCBwcm9jZWR1cmVzIHRoYXQ8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFsbG93IGZhc3QgZmFpbG92ZXIgZm9yIHVwc3RyZWFtIGZh aWx1cmVzIGJ5IGFsbG93aW5nIGRvd25zdHJlYW0gUEVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgYWxsb3cgZmFzdCBmYWlsb3ZlciBmb3IgdXBzdHJlYW0gZmFpbHVyZXMgYnkg YWxsb3dpbmcgZG93bnN0cmVhbSBQRXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRv IGNvbnNpZGVyIHRoZSBzdGF0dXMgb2YgUHJvdmlkZXItVHVubmVscyAoUC10dW5uZWxzKSB3aGVu IHNlbGVjdGluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRvIGNvbnNpZGVy IHRoZSBzdGF0dXMgb2YgUHJvdmlkZXItVHVubmVscyAoUC10dW5uZWxzKSB3aGVuIHNlbGVjdGlu ZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIHVwc3RyZWFtIFBFIGZvciBhIFZQ TiBtdWx0aWNhc3QgZmxvdy4gIFRoZSBmYXN0IGZhaWxvdmVyIGlzPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgdGhlIHVwc3RyZWFtIFBFIGZvciBhIFZQTiBtdWx0aWNhc3QgZmxv dy4gIFRoZSBmYXN0IGZhaWxvdmVyIGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBl bmFibGVkIGJ5IHVzaW5nIFJGQyA4NTYyIEJGRCBmb3IgTXVsdGlwb2ludCBOZXR3b3JrcyBhbmQg dGhlIG5ldyBCR1A8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBlbmFibGVkIGJ5 IHVzaW5nIFJGQyA4NTYyIEJGRCBmb3IgTXVsdGlwb2ludCBOZXR3b3JrcyBhbmQgdGhlIG5ldyBC R1A8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEF0dHJpYnV0ZSAtIEJGRCBEaXNjcmlt aW5hdG9yLiAgQWxzbywgdGhlIGRvY3VtZW50IGludHJvZHVjZXMgYSBuZXc8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBdHRyaWJ1dGUgLSBCRkQgRGlzY3JpbWluYXRvci4gIEFs c28sIHRoZSBkb2N1bWVudCBpbnRyb2R1Y2VzIGEgbmV3PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA0Ij48dGQ+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIEJHUCBDb21t dW5pdHksIFN0YW5kYnkgUEUsIGV4dGVuZGluZyBCR1AgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+TVZQ Tjwvc3Bhbj4gcm91dGluZyBzbyB0aGF0IGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgQkdQIENvbW11bml0eSwgU3RhbmRieSBQRSwgZXh0ZW5kaW5nIEJHUCA8c3BhbiBjbGFz cz0iaW5zZXJ0Ij5NdWx0aWNhc3QgVlBOPC9zcGFuPiByb3V0aW5nIHNvPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgIEMtbXVsdGljYXN0IHJvdXRlIGNhbiBiZSBhZHZlcnRpc2VkIHRv d2FyZCBhIFN0YW5kYnkgVXBzdHJlYW0gUEUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgIHRoYXQgYSBDLW11bHRpY2FzdCByb3V0ZSBjYW4gYmUgYWR2ZXJ0aXNlZCB0b3dhcmQg YSBTdGFuZGJ5IFVwc3RyZWFtPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBQRS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+U3RhdHVzIG9mIFRoaXMgTWVtbzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPlN0YXR1cyBvZiBUaGlzIE1lbW88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3 aXRoIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgSW50ZXJuZXQt RHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGU8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5k IEJDUCA3OS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJuZXQtRHJh ZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtp bmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZzwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBz IG1heSBhbHNvIGRpc3RyaWJ1dGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBU YXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJp YnV0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgd29ya2luZyBkb2N1bWVudHMgYXMg SW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC08L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1E cmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgRHJhZnRzIGlzIGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJh ZnRzL2N1cnJlbnQvLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIERyYWZ0cyBp cyBhdCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBk b2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMg dmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3Ro ZXIgZG9jdW1lbnRzIGF0IGFueTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFu ZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVu dHMgYXQgYW55PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aW1lLiAgSXQgaXMgaW5h cHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVz ZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9n cmVzcy4iPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbWF0ZXJpYWwgb3IgdG8g Y2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA1Ij48dGQ+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gTWF5IDEsIDIwMjEuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2ls bCBleHBpcmUgb24gTWF5IDE8c3BhbiBjbGFzcz0iaW5zZXJ0Ij42PC9zcGFuPiwgMjAyMS48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Q29weXJpZ2h0IE5vdGljZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkNvcHlyaWdodCBOb3RpY2U8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgQ29weXJpZ2h0IChjKSAyMDIwIElFVEYgVHJ1c3QgYW5kIHRoZSBw ZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgQ29weXJpZ2h0IChjKSAyMDIwIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZp ZWQgYXMgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkb2N1bWVudCBhdXRob3Jz LiAgQWxsIHJpZ2h0cyByZXNlcnZlZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBh bmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0 J3MgTGVnYWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFByb3Zpc2lvbnMgUmVsYXRp bmcgdG8gSUVURiBEb2N1bWVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQ cm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAoaHR0cHM6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZm ZWN0IG9uIHRoZSBkYXRlIG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKGh0 dHBzOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0 ZSBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcHVibGljYXRpb24gb2YgdGhpcyBk b2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSBy ZXZpZXcgdGhlc2UgZG9jdW1lbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0ciBpZD0icGFydC0yIiBjbGFzcz0iY2hhbmdlIj48dGQ+PC90ZD48dGg+PHNt YWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3c2Lmll dGYub3JnL3JmY2RpZmYvcmZjZGlmZi5weWh0I3BhcnQtMiI+PGVtPiBwYWdlIDIsIGxpbmUgMjA8 c3BhbiBjbGFzcz0iaGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48 c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dzYu aWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC0yIj48ZW0+IHBhZ2UgMiwgbGluZSAy MTxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PlRhYmxlIG9mIENvbnRlbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+VGFibGUg b2YgQ29udGVudHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMS4gIEludHJv ZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICAzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgMS4gIEludHJvZHVjdGlvbiAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAyLiAgQ29udmVudGlvbnMgdXNlZCBpbiB0aGlzIGRv Y3VtZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDM8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAyLiAgQ29udmVudGlvbnMgdXNlZCBpbiB0aGlzIGRvY3VtZW50IC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgMi4xLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgMzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgMi4x LiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAgMzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAyLjIuICBUZXJtaW5vbG9n eSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAyLjIuICBUZXJtaW5vbG9neSAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgIDIuMy4gIEFjcm9ueW1zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgIDIuMy4gIEFjcm9ueW1zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgIDQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDMuICBV TUggU2VsZWN0aW9uIEJhc2VkIG9uIFR1bm5lbCBTdGF0dXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAgNTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDMuICBVTUggU2VsZWN0 aW9uIEJhc2VkIG9uIFR1bm5lbCBTdGF0dXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAzLjEuICBEZXRlcm1pbmluZyB0aGUgU3Rh dHVzIG9mIGEgVHVubmVsICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAzLjEuICBEZXRlcm1pbmluZyB0aGUgU3RhdHVzIG9mIGEg VHVubmVsICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA2Ij48dGQ+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAzLjEu MS4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPm1WUE4gVHVubmVsIFJvb3QgVHJhY2tpbmcgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgICAgIDMuMS4xLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+TVZQTiBUdW5uZWwg Um9vdCBUcmFja2luZyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3PC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIDMuMS4yLiAgUEUtUCBVcHN0cmVhbSBMaW5r IFN0YXR1cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgIDMuMS4yLiAgUEUtUCBVcHN0cmVhbSBMaW5rIFN0YXR1cyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgICAgMy4xLjMuICBQMk1QIFJTVlAtVEUgVHVubmVscyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgIDc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAg My4xLjMuICBQMk1QIFJTVlAtVEUgVHVubmVscyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgIDc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAzLjEuNC4gIExlYWYt aW5pdGlhdGVkIFAtdHVubmVscyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgODwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAzLjEuNC4gIExlYWYtaW5pdGlhdGVk IFAtdHVubmVscyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgODwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgICAgIDMuMS41LiAgKEMtUywgQy1HKSBDb3VudGVyIEluZm9ybWF0 aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgIDMuMS41LiAgKEMtUywgQy1HKSBDb3VudGVyIEluZm9ybWF0aW9uICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gICA4PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAg My4xLjYuICBCRkQgRGlzY3JpbWluYXRvciBBdHRyaWJ1dGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgIDg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgMy4xLjYuICBC RkQgRGlzY3JpbWluYXRvciBBdHRyaWJ1dGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDg8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAzLjEuNy4gIFBlciBQRS1DRSBMaW5r IEJGRCBEaXNjcmltaW5hdG9yICAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAzLjEuNy4gIFBlciBQRS1DRSBMaW5rIEJGRCBEaXNj cmltaW5hdG9yICAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgNC4gIFN0YW5kYnkgQy1tdWx0aWNhc3QgUm91dGUgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDEyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg NC4gIFN0YW5kYnkgQy1tdWx0aWNhc3QgUm91dGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDEyPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDQuMS4gIERvd25z dHJlYW0gUEUgQmVoYXZpb3IgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTM8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDQuMS4gIERvd25zdHJlYW0gUEUg QmVoYXZpb3IgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgNC4yLiAgVXBzdHJlYW0gUEUgQmVoYXZpb3IgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgNC4yLiAgVXBzdHJlYW0gUEUgQmVoYXZpb3IgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICA0LjMuICBSZWFjaGFiaWxpdHkgRGV0ZXJtaW5hdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDE1PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICA0LjMuICBS ZWFjaGFiaWxpdHkgRGV0ZXJtaW5hdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDE1PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDQuNC4gIEludGVyLUFTICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTU8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDQuNC4gIEludGVyLUFTICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTU8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAgICA0LjQuMS4gIEludGVyLUFTIFByb2NlZHVyZXMgZm9yIGRvd25zdHJl YW0gUEVzLCBBU0JSIEZhc3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAg NC40LjEuICBJbnRlci1BUyBQcm9jZWR1cmVzIGZvciBkb3duc3RyZWFtIFBFcywgQVNCUiBGYXN0 PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICBGYWlsb3ZlciAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTY8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICBGYWlsb3ZlciAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTY8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgICA0LjQuMi4gIEludGVyLUFTIFByb2NlZHVyZXMgZm9yIEFTQlJzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAxNjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg ICAgICA0LjQuMi4gIEludGVyLUFTIFByb2NlZHVyZXMgZm9yIEFTQlJzIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAxNjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy IGlkPSJkaWZmMDAwNyI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA1LiAgSG90IFJvb3QgU3RhbmRieSAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTxzcGFuIGNsYXNzPSJkZWxl dGUiPjY8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDUuICBIb3Qg Um9vdCBTdGFuZGJ5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAxPHNwYW4gY2xhc3M9Imluc2VydCI+Nzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIDYuICBEdXBsaWNhdGUgUGFja2V0cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAxNzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDYu ICBEdXBsaWNhdGUgUGFja2V0cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAxNzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgNy4gIElBTkEgQ29uc2lk ZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE4PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgNy4gIElBTkEgQ29uc2lkZXJhdGlvbnMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE4PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDcuMS4gIFN0YW5kYnkgUEUgQ29tbXVuaXR5ICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgIDcuMS4gIFN0YW5kYnkgUEUgQ29tbXVuaXR5ICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgMTg8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg Ny4yLiAgQkZEIERpc2NyaW1pbmF0b3IgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAxODwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgNy4yLiAgQkZE IERpc2NyaW1pbmF0b3IgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAx ODwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICA3LjMuICBCRkQgRGlzY3JpbWluYXRv ciBPcHRpb25hbCBTdWItVExWIFR5cGUgLiAuIC4gLiAuIC4gLiAuIC4gIDE5PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICA3LjMuICBCRkQgRGlzY3JpbWluYXRvciBPcHRpb25h bCBTdWItVExWIFR5cGUgLiAuIC4gLiAuIC4gLiAuIC4gIDE5PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA4Ij48dGQ+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDguICBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA8c3BhbiBjbGFzcz0iZGVsZXRlIj4xOTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgOC4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjIwPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgOS4gIEFja25vd2xlZGdtZW50cyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDIwPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgOS4gIEFja25vd2xlZGdtZW50cyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDIwPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAxMC4gQ29udHJpYnV0b3IgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMjA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAx MC4gQ29udHJpYnV0b3IgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgMjA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDExLiBSZWZlcmVuY2Vz ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDExLiBSZWZlcmVuY2VzICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAxMS4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDIyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICAxMS4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDIyPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg IDExLjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgMjM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDExLjIuICBJ bmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg MjM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMzwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAyMzwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4xLiAgSW50cm9kdWN0aW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+MS4gIEludHJvZHVjdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBJdCBpcyBhc3N1bWVkIHRoYXQgdGhlIHJlYWRlciBpcyBmYW1pbGlhciB3aXRoIHRoZSB3b3Jr aW5ncyBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEl0IGlzIGFzc3VtZWQg dGhhdCB0aGUgcmVhZGVyIGlzIGZhbWlsaWFyIHdpdGggdGhlIHdvcmtpbmdzIG9mPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0icGFydC0zIiBjbGFz cz0iY2hhbmdlIj48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21h bGw+PGEgaHJlZj0iaHR0cHM6Ly93d3c2LmlldGYub3JnL3JmY2RpZmYvcmZjZGlmZi5weWh0I3Bh cnQtMyI+PGVtPiBwYWdlIDMsIGxpbmUgMjc8c3BhbiBjbGFzcz0iaGlkZSI+IMK2PC9zcGFuPjwv ZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9z bWFsbD48YSBocmVmPSJodHRwczovL3d3dzYuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQj cGFydC0zIj48ZW0+IHBhZ2UgMywgbGluZSAyNzxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+ PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjb25uZWN0ZWQgdG8gYSByZWNlaXZlciBzaXRlKSB0 byB0YWtlIGludG8gYWNjb3VudCB0aGUgc3RhdHVzIG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgY29ubmVjdGVkIHRvIGEgcmVjZWl2ZXIgc2l0ZSkgdG8gdGFrZSBpbnRvIGFj Y291bnQgdGhlIHN0YXR1cyBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUC10dW5u ZWxzIHRvIGRldGVybWluZSB0aGUgVXBzdHJlYW0gTXVsdGljYXN0IEhvcCAoVU1IKSBmb3IgYSBn aXZlbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFAtdHVubmVscyB0byBkZXRl cm1pbmUgdGhlIFVwc3RyZWFtIE11bHRpY2FzdCBIb3AgKFVNSCkgZm9yIGEgZ2l2ZW48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIChDLVMsIEMtRykuICBPbmUgb2YgdGhlIG9wdGlvbmFs IG1ldGhvZHMgdXNlcyBbUkZDODU2Ml0gYW5kIHRoZSBuZXc8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAoQy1TLCBDLUcpLiAgT25lIG9mIHRoZSBvcHRpb25hbCBtZXRob2RzIHVz ZXMgW1JGQzg1NjJdIGFuZCB0aGUgbmV3PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBC R1AgQXR0cmlidXRlIC0gQkZEIERpc2NyaW1pbmF0b3IuICBOb25lIG9mIHRoZXNlIG1ldGhvZHMg cHJvdmlkZSBhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQkdQIEF0dHJpYnV0 ZSAtIEJGRCBEaXNjcmltaW5hdG9yLiAgTm9uZSBvZiB0aGVzZSBtZXRob2RzIHByb3ZpZGUgYTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgImZhc3QgZmFpbG92ZXIiIHNvbHV0aW9uIHdo ZW4gdXNlZCBhbG9uZSwgYnV0IGNhbiBiZSB1c2VkIHRvZ2V0aGVyPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgImZhc3QgZmFpbG92ZXIiIHNvbHV0aW9uIHdoZW4gdXNlZCBhbG9u ZSwgYnV0IGNhbiBiZSB1c2VkIHRvZ2V0aGVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICB3aXRoIHRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluIFNlY3Rpb24gNCBmb3IgYSAiZmFzdCBm YWlsb3ZlciI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB3aXRoIHRoZSBtZWNo YW5pc20gZGVzY3JpYmVkIGluIFNlY3Rpb24gNCBmb3IgYSAiZmFzdCBmYWlsb3ZlciI8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNvbHV0aW9uLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIHNvbHV0aW9uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBTZWN0aW9uIDQgZGVzY3JpYmVzIGFuIG9wdGlvbmFsIEJHUCBleHRlbnNpb24sIGEgbmV3IFN0 YW5kYnkgUEU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBTZWN0aW9uIDQgZGVz Y3JpYmVzIGFuIG9wdGlvbmFsIEJHUCBleHRlbnNpb24sIGEgbmV3IFN0YW5kYnkgUEU8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIENvbW11bml0eS4gdGhhdCBjYW4gc3BlZWQgdXAgZmFp bG92ZXIgYnkgbm90IHJlcXVpcmluZyBhbnkgbXVsdGljYXN0PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgQ29tbXVuaXR5LiB0aGF0IGNhbiBzcGVlZCB1cCBmYWlsb3ZlciBieSBu b3QgcmVxdWlyaW5nIGFueSBtdWx0aWNhc3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDkiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgVlBOIHJvdXRpbmcgbWVz c2FnZSBleGNoYW5nZSBhdCByZWNvdmVyeSB0aW1lLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICBWUE4gPHNwYW4gY2xhc3M9Imluc2VydCI+KE1WUE4pIDwvc3Bhbj5yb3V0aW5n IG1lc3NhZ2UgZXhjaGFuZ2UgYXQgcmVjb3ZlcnkgdGltZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgU2VjdGlvbiA1IGRlc2NyaWJlcyBhICJob3QgbGVhZiBzdGFuZGJ5IiBt ZWNoYW5pc20gdGhhdCBjYW4gYmUgdXNlZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIFNlY3Rpb24gNSBkZXNjcmliZXMgYSAiaG90IGxlYWYgc3RhbmRieSIgbWVjaGFuaXNtIHRo YXQgY2FuIGJlIHVzZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRvIGltcHJvdmUg ZmFpbG92ZXIgdGltZSBpbiBNVlBOLiAgVGhlIGFwcHJvYWNoIGNvbWJpbmVzIG1lY2hhbmlzbXM8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0byBpbXByb3ZlIGZhaWxvdmVyIHRp bWUgaW4gTVZQTi4gIFRoZSBhcHByb2FjaCBjb21iaW5lcyBtZWNoYW5pc21zPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBkZWZpbmVkIGluIFNlY3Rpb24gMyBhbmQgU2VjdGlvbiA0IGhh cyBzaW1pbGFyaXRpZXMgd2l0aCB0aGUgc29sdXRpb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBkZWZpbmVkIGluIFNlY3Rpb24gMyBhbmQgU2VjdGlvbiA0IGhhcyBzaW1pbGFy aXRpZXMgd2l0aCB0aGUgc29sdXRpb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRl c2NyaWJlZCBpbiBbUkZDNzQzMV0gdG8gaW1wcm92ZSBmYWlsb3ZlciB0aW1lcyB3aGVuIFBJTSBy b3V0aW5nIGlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGVzY3JpYmVkIGlu IFtSRkM3NDMxXSB0byBpbXByb3ZlIGZhaWxvdmVyIHRpbWVzIHdoZW4gUElNIHJvdXRpbmcgaXM8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHVzZWQgaW4gYSBuZXR3b3JrIGdpdmVuIHNv bWUgdG9wb2xvZ3kgYW5kIG1ldHJpYyBjb25zdHJhaW50cy48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICB1c2VkIGluIGEgbmV0d29yayBnaXZlbiBzb21lIHRvcG9sb2d5IGFuZCBt ZXRyaWMgY29uc3RyYWludHMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRo ZSBwcm9jZWR1cmVzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGFyZSBvcHRpb25hbCB0byBl bmFibGUgYW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgcHJvY2VkdXJl cyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBhcmUgb3B0aW9uYWwgdG8gZW5hYmxlIGFuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvcGVyYXRvciB0byBwcm92aWRlIHByb3RlY3Rp b24gZm9yIG11bHRpY2FzdCBzZXJ2aWNlcyBpbiBCR1AvTVBMUyBJUDwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIG9wZXJhdG9yIHRvIHByb3ZpZGUgcHJvdGVjdGlvbiBmb3IgbXVs dGljYXN0IHNlcnZpY2VzIGluIEJHUC9NUExTIElQPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBWUE5zLiAgQW4gb3BlcmF0b3Igd291bGQgZW5hYmxlIHRoZXNlIG1lY2hhbmlzbXMgdXNp bmcgYSBtZXRob2Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBWUE5zLiAgQW4g b3BlcmF0b3Igd291bGQgZW5hYmxlIHRoZXNlIG1lY2hhbmlzbXMgdXNpbmcgYSBtZXRob2Q8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTQi IGNsYXNzPSJjaGFuZ2UiPjx0ZD48L3RkPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0 PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dzYuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5 aHQjcGFydC00Ij48ZW0+IHBhZ2UgNiwgbGluZSA0MjxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3Nw YW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2Ug YXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9yZmNkaWZmL3JmY2RpZmYu cHlodCNwYXJ0LTQiPjxlbT4gcGFnZSA2LCBsaW5lIDQyPHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwv c3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFAtdHVubmVsIGl0c2VsZi4gIFRoYXQgY291 bGQgYmUgcmVmZXJyZWQgdG8gYXMgIlAtdHVubmVsIHJlY2VwdGlvbjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIFAtdHVubmVsIGl0c2VsZi4gIFRoYXQgY291bGQgYmUgcmVmZXJy ZWQgdG8gYXMgIlAtdHVubmVsIHJlY2VwdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgc3RhdHVzIiwgYnV0IGZvciBzaW1wbGljaXR5LCB3ZSB3aWxsIHVzZSB0aGUgdGVybWlub2xv Z3kgb2YgUC10dW5uZWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzdGF0dXMi LCBidXQgZm9yIHNpbXBsaWNpdHksIHdlIHdpbGwgdXNlIHRoZSB0ZXJtaW5vbG9neSBvZiBQLXR1 bm5lbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgInN0YXR1cyIgZm9yIGFsbCBvZiB0 aGVzZSBtZXRob2RzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICJzdGF0dXMi IGZvciBhbGwgb2YgdGhlc2UgbWV0aG9kcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgRGVwZW5kaW5nIG9uIHRoZSBjcml0ZXJpYSB1c2VkIHRvIGRldGVybWluZSB0aGUgc3Rh dHVzIG9mIGEgUC10dW5uZWwsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRGVw ZW5kaW5nIG9uIHRoZSBjcml0ZXJpYSB1c2VkIHRvIGRldGVybWluZSB0aGUgc3RhdHVzIG9mIGEg UC10dW5uZWwsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGVyZSBtYXkgYmUgYW4g aW50ZXJhY3Rpb24gd2l0aCBhbm90aGVyIHJlc2lsaWVuY3kgbWVjaGFuaXNtIHVzZWQ8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aGVyZSBtYXkgYmUgYW4gaW50ZXJhY3Rpb24g d2l0aCBhbm90aGVyIHJlc2lsaWVuY3kgbWVjaGFuaXNtIHVzZWQ8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIGZvciB0aGUgUC10dW5uZWwgaXRzZWxmLCBhbmQgdGhlIFVNSCB1cGRhdGUg bWF5IGhhcHBlbiBpbW1lZGlhdGVseSBvcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIGZvciB0aGUgUC10dW5uZWwgaXRzZWxmLCBhbmQgdGhlIFVNSCB1cGRhdGUgbWF5IGhhcHBl biBpbW1lZGlhdGVseSBvcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbWF5IG5lZWQg dG8gYmUgZGVsYXllZC4gIEVhY2ggcGFydGljdWxhciBjYXNlIGlzIGNvdmVyZWQgaW4gZWFjaDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG1heSBuZWVkIHRvIGJlIGRlbGF5ZWQu ICBFYWNoIHBhcnRpY3VsYXIgY2FzZSBpcyBjb3ZlcmVkIGluIGVhY2g8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIHNlcGFyYXRlIHN1Yi1zZWN0aW9uIGJlbG93LjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIHNlcGFyYXRlIHN1Yi1zZWN0aW9uIGJlbG93LjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDEwIj48 dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFz cz0iaW5zZXJ0Ij5BbGwgbWV0aG9kcyBkZXNjcmliZWQgaW4gdGhpcyBzZWN0aW9uIG1heSBwcm9k dWNlIGZhbHNlLW5lZ2F0aXZlPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAg c3RhdGUgY2hhbmdlcyB0aGF0IGNhbiBiZSB0aGUgdHJpZ2dlciBmb3IgYW4gdW5uZWNlc3Nhcnkg ZmFpbG92ZXI8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBuZWdhdGl2ZWx5 IGltcGFjdGluZyB0aGUgbXVsdGljYXN0IHNlcnZpY2UgcHJvdmlkZWQgYnkgdGhlIFZQTi4gIEFu PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgb3BlcmF0b3IgZXhwZWN0ZWQg dG8gY29uc2lkZXIgdGhlIG5ldHdvcmsgZW52aXJvbm1lbnQgYW5kIHVzZTwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGF2YWlsYWJsZSBjb250cm9scyBvZiB0aGUgbWVjaGFu aXNtIHVzZWQgdG8gZGV0ZXJtaW5lIHRoZSBzdGF0dXMgb2YgYTwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFu IGNsYXNzPSJpbnNlcnQiPiAgIFAtdHVubmVsLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEFuIGltcGxlbWVudGF0aW9uIG1heSBz dXBwb3J0IGFueSBjb21iaW5hdGlvbiBvZiB0aGUgbWV0aG9kczwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIEFuIGltcGxlbWVudGF0aW9uIG1heSBzdXBwb3J0IGFueSBjb21iaW5h dGlvbiBvZiB0aGUgbWV0aG9kczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZGVzY3Jp YmVkIGluIHRoaXMgc2VjdGlvbiBhbmQgcHJvdmlkZSBhIG5ldHdvcmsgb3BlcmF0b3Igd2l0aCBj b250cm9sPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZGVzY3JpYmVkIGluIHRo aXMgc2VjdGlvbiBhbmQgcHJvdmlkZSBhIG5ldHdvcmsgb3BlcmF0b3Igd2l0aCBjb250cm9sPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0byBjaG9vc2Ugd2hpY2ggb25lIHRvIHVzZSBp biB0aGUgcGFydGljdWxhciBkZXBsb3ltZW50LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIHRvIGNob29zZSB3aGljaCBvbmUgdG8gdXNlIGluIHRoZSBwYXJ0aWN1bGFyIGRlcGxv eW1lbnQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBp ZD0iZGlmZjAwMTEiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+My4xLjEuICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5tPC9z cGFuPlZQTiBUdW5uZWwgUm9vdCBUcmFja2luZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4zLjEuMS4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPk08L3NwYW4+VlBOIFR1bm5lbCBSb290 IFRyYWNraW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEEgY29uZGl0aW9u IHRvIGNvbnNpZGVyIHRoYXQgdGhlIHN0YXR1cyBvZiBhIFAtdHVubmVsIGlzIFVwIGlzIHRoYXQ8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBIGNvbmRpdGlvbiB0byBjb25zaWRl ciB0aGF0IHRoZSBzdGF0dXMgb2YgYSBQLXR1bm5lbCBpcyBVcCBpcyB0aGF0PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGUgcm9vdCBvZiB0aGUgdHVubmVsLCBhcyBkZXRlcm1pbmVk IGluIHRoZSB4LVBNU0kgVHVubmVsIGF0dHJpYnV0ZSw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICB0aGUgcm9vdCBvZiB0aGUgdHVubmVsLCBhcyBkZXRlcm1pbmVkIGluIHRoZSB4 LVBNU0kgVHVubmVsIGF0dHJpYnV0ZSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGlz IHJlYWNoYWJsZSB0aHJvdWdoIHVuaWNhc3Qgcm91dGluZyB0YWJsZXMuICBJbiB0aGlzIGNhc2Us IHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGlzIHJlYWNoYWJsZSB0aHJv dWdoIHVuaWNhc3Qgcm91dGluZyB0YWJsZXMuICBJbiB0aGlzIGNhc2UsIHRoZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgZG93bnN0cmVhbSBQRSBjYW4gaW1tZWRpYXRlbHkgdXBkYXRl IGl0cyBVTUggd2hlbiB0aGUgcmVhY2hhYmlsaXR5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgZG93bnN0cmVhbSBQRSBjYW4gaW1tZWRpYXRlbHkgdXBkYXRlIGl0cyBVTUggd2hl biB0aGUgcmVhY2hhYmlsaXR5PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjb25kaXRp b24gY2hhbmdlcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBjb25kaXRpb24g Y2hhbmdlcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhhdCBpcyBzaW1p bGFyIHRvIEJHUCBuZXh0LWhvcCB0cmFja2luZyBmb3IgVlBOIHJvdXRlcywgZXhjZXB0IHRoYXQ8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGF0IGlzIHNpbWlsYXIgdG8gQkdQ IG5leHQtaG9wIHRyYWNraW5nIGZvciBWUE4gcm91dGVzLCBleGNlcHQgdGhhdDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIGFkZHJlc3MgY29uc2lkZXJlZCBpcyBub3QgdGhlIEJH UCBuZXh0LWhvcCBhZGRyZXNzLCBidXQgdGhlIHJvb3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICB0aGUgYWRkcmVzcyBjb25zaWRlcmVkIGlzIG5vdCB0aGUgQkdQIG5leHQtaG9w IGFkZHJlc3MsIGJ1dCB0aGUgcm9vdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYWRk cmVzcyBpbiB0aGUgeC1QTVNJIFR1bm5lbCBhdHRyaWJ1dGUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgYWRkcmVzcyBpbiB0aGUgeC1QTVNJIFR1bm5lbCBhdHRyaWJ1dGUuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0icGFydC01 IiBjbGFzcz0iY2hhbmdlIj48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBh dDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3c2LmlldGYub3JnL3JmY2RpZmYvcmZjZGlmZi5w eWh0I3BhcnQtNSI+PGVtPiBwYWdlIDEyLCBsaW5lIDMwPHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwv c3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5n ZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3c2LmlldGYub3JnL3JmY2RpZmYvcmZjZGlm Zi5weWh0I3BhcnQtNSI+PGVtPiBwYWdlIDEyLCBsaW5lIDMwPHNwYW4gY2xhc3M9ImhpZGUiPiDC tjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIERvd24gKHBlciBTZWN0aW9uIDYuOC4x NyBbUkZDNTg4MF0pLCB1bmxlc3MgaXQgc3dpdGNoZXMgdG8gYSBuZXcgUEUtPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRG93biAocGVyIFNlY3Rpb24gNi44LjE3IFtSRkM1ODgw XSksIHVubGVzcyBpdCBzd2l0Y2hlcyB0byBhIG5ldyBQRS08L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIENFIGxpbmsgd2l0aGluIHRoZSB0aW1lIG9mIGJmZC5EZXNpcmVkTWluVHhJbnRl cnZhbCBmb3IgdGhlIFAyTVAgQkZEPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg Q0UgbGluayB3aXRoaW4gdGhlIHRpbWUgb2YgYmZkLkRlc2lyZWRNaW5UeEludGVydmFsIGZvciB0 aGUgUDJNUCBCRkQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNlc3Npb24gKGluIHRo YXQgY2FzZSwgdGhlIFVwc3RyZWFtIFBFIHdpbGwgc3RhcnQgdHJhY2tpbmcgdGhlIHN0YXR1czwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHNlc3Npb24gKGluIHRoYXQgY2FzZSwg dGhlIFVwc3RyZWFtIFBFIHdpbGwgc3RhcnQgdHJhY2tpbmcgdGhlIHN0YXR1czwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgb2YgdGhlIG5ldyBQRS1DRSBsaW5rKS4gIFdoZW4gYSBkb3du c3RyZWFtIFBFIHJlY2VpdmVzIHRoYXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBvZiB0aGUgbmV3IFBFLUNFIGxpbmspLiAgV2hlbiBhIGRvd25zdHJlYW0gUEUgcmVjZWl2ZXMg dGhhdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYmZkLkxvY2FsRGlhZyBjb2RlLCBp dCB0cmVhdHMgaXQgYXMgaWYgdGhlIHR1bm5lbCBpdHNlbGYgZmFpbGVkIGFuZDwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGJmZC5Mb2NhbERpYWcgY29kZSwgaXQgdHJlYXRzIGl0 IGFzIGlmIHRoZSB0dW5uZWwgaXRzZWxmIGZhaWxlZCBhbmQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHRyaWVzIHRvIHN3aXRjaCB0byBhIGJhY2t1cCBQRS48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICB0cmllcyB0byBzd2l0Y2ggdG8gYSBiYWNrdXAgUEUuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjQuICBTdGFuZGJ5IEMtbXVsdGljYXN0IFJvdXRl PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+NC4gIFN0YW5kYnkgQy1tdWx0aWNhc3Qg Um91dGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIHByb2NlZHVyZXMg ZGVzY3JpYmVkIGJlbG93IGFyZSBsaW1pdGVkIHRvIHRoZSBjYXNlIHdoZXJlIHRoZSBzaXRlPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIHByb2NlZHVyZXMgZGVzY3JpYmVk IGJlbG93IGFyZSBsaW1pdGVkIHRvIHRoZSBjYXNlIHdoZXJlIHRoZSBzaXRlPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDEyIj48dGQ+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgIHRoYXQgY29udGFpbnMgQy1TIGlzIGNvbm5lY3RlZCB0byB0d28gb3IgbW9yZSA8c3BhbiBj bGFzcz0iZGVsZXRlIj5QRXM8L3NwYW4+IHRob3VnaCwgdG8gc2ltcGxpZnk8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgdGhhdCBjb250YWlucyBDLVMgaXMgY29ubmVjdGVkIHRv IHR3byBvciBtb3JlIDxzcGFuIGNsYXNzPSJpbnNlcnQiPlBFcyw8L3NwYW4+IHRob3VnaCwgdG88 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgdGhlIGRlc2NyaXB0aW9uLCB0aGUgY2Fz ZSBvZiBkdWFsLWhvbWluZyBpcyBkZXNjcmliZWQuICBUaGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgc2ltcGxpZnkgdGhlIGRlc2NyaXB0aW9uLCB0aGUgY2FzZSBvZiBkdWFs LWhvbWluZyBpcyBkZXNjcmliZWQuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5TdWNoPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBwcm9jZWR1cmVzIHJlcXVpcmUgYWxsIHRo ZSBQRXMgb2YgdGhhdCBNVlBOIHRvIGZvbGxvdyB0aGUgc2FtZSBVTUg8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgYSByZWR1bmRhbmN5IHBy b3RlY3Rpb24gc2NoZW1lLCByZWZlcnJlZCB0byBhcyAxOk4gcHJvdGVjdGlvbiwgaXMgdGhlPC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBzZWxlY3Rpb24gcHJvY2VkdXJl LCBhcyBzcGVjaWZpZWQgaW4gW1JGQzY1MTNdLCB3aGV0aGVyIHRoZSBQRTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBzcGVjaWFsIGNhc2Ug b2YgTTpOIHByb3RlY3Rpb24sIHdoZXJlIE0gd29ya2luZyBpbnN0YW5jZXMgYXJlIHNoYXJpbmc8 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHNlbGVjdGVkIGJhc2VkIG9u IGl0cyBJUCBhZGRyZXNzLCBoYXNoaW5nIGFsZ29yaXRobSBkZXNjcmliZWQgaW48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgcHJvdGVjdGlv biBvZiB0aGUgTiBzdGFuZGJ5IGluc3RhbmNlcy4gIEluIGFkZGl0aW9uIHRvIGEgbmV0d29yazwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgc2VjdGlvbiA1LjEuMyBvZiBb UkZDNjUxM10sIG9yIEluc3RhbGxlZCBVTUggUm91dGUuICBUaGUgcHJvY2VkdXJlczwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBmYWlsdXJl IGRldGVjdGlvbiBtZWNoYW5pc20sIHRoZSBsYXR0ZXIgc2NoZW1lIHJlcXVpcmVzIHVzaW5nIGE8 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGFzc3VtZSB0aGF0IGlmIGEg c2l0ZSBvZiBhIGdpdmVuIE1WUE4gdGhhdCBjb250YWlucyBDLVMgaXMgZHVhbC1ob21lZDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBtZWNo YW5pc20gdG8gY29vcmRpbmF0ZSB0aGUgZmFpbG92ZXIgYW1vbmcgd29ya2luZyBpbnN0YW5jZXMu ICBGb3I8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHRvIHR3byBQRXMs IHRoZW4gYWxsIHRoZSBvdGhlciBzaXRlcyBvZiB0aGF0IE1WUE4gd291bGQgaGF2ZSB0d288L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgdGhh dCByZWFzb24sIE06TiBwcm90ZWN0aW9uIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXM8L3Nw YW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHVuaWNhc3QgVlBOIHJvdXRlcyAo VlBOLUlQdjQgb3IgVlBOLUlQdjYpIHRvIEMtUywgZWFjaCB3aXRoIGl0cyBSRC48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgc3BlY2lmaWNh dGlvbi48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBUaGUgcHJvY2Vk dXJlcyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5kZXNjcmliZWQgaW4gdGhpcyBzZWN0aW9uPC9zcGFu PiByZXF1aXJlIGFsbCB0aGUgUEVzIG9mIHRoYXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIE1WUE4gdG8gZm9sbG93IHRo ZSBzYW1lIFVNSCBzZWxlY3Rpb24gcHJvY2VkdXJlLCBhcyBzcGVjaWZpZWQgaW48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg IFtSRkM2NTEzXSwgd2hldGhlciB0aGUgUEUgc2VsZWN0ZWQgYmFzZWQgb24gaXRzIElQIGFkZHJl c3MsIGhhc2hpbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPiAgIGFsZ29yaXRobSBkZXNjcmliZWQgaW4gc2VjdGlvbiA1LjEu MyBvZiBbUkZDNjUxM10sIG9yIEluc3RhbGxlZCBVTUg8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFJvdXRlLiAgVGhlIHBy b2NlZHVyZXMgYXNzdW1lIHRoYXQgaWYgYSBzaXRlIG9mIGEgZ2l2ZW4gTVZQTiB0aGF0PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICBjb250YWlucyBDLVMgaXMgZHVhbC1ob21lZCB0byB0d28gUEVzLCB0aGVuIGFsbCB0aGUg b3RoZXIgc2l0ZXMgb2Y8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHRoYXQgTVZQTiB3b3VsZCBoYXZlIHR3byB1bmljYXN0 IFZQTiByb3V0ZXMgKFZQTi1JUHY0IG9yIFZQTi1JUHY2KSB0bzwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgQy1TLCBlYWNo IHdpdGggaXRzIFJELjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBcyBsb25n IGFzIEMtUyBpcyByZWFjaGFibGUgdmlhIGJvdGggUEVzLCBhIGdpdmVuIGRvd25zdHJlYW0gUEUg d2lsbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEFzIGxvbmcgYXMgQy1TIGlz IHJlYWNoYWJsZSB2aWEgYm90aCBQRXMsIGEgZ2l2ZW4gZG93bnN0cmVhbSBQRSB3aWxsPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzZWxlY3Qgb25lIG9mIHRoZSBQRXMgY29ubmVjdGVk IHRvIEMtUyBhcyBpdHMgVXBzdHJlYW0gUEUgZm9yIEMtUy48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBzZWxlY3Qgb25lIG9mIHRoZSBQRXMgY29ubmVjdGVkIHRvIEMtUyBhcyBp dHMgVXBzdHJlYW0gUEUgZm9yIEMtUy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFdl IHdpbGwgcmVmZXIgdG8gdGhlIG90aGVyIFBFIGNvbm5lY3RlZCB0byBDLVMgYXMgdGhlICJTdGFu ZGJ5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgV2Ugd2lsbCByZWZlciB0byB0 aGUgb3RoZXIgUEUgY29ubmVjdGVkIHRvIEMtUyBhcyB0aGUgIlN0YW5kYnk8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIFVwc3RyZWFtIFBFIi4gIE5vdGUgdGhhdCBpZiB0aGUgY29ubmVj dGl2aXR5IHRvIEMtUyB0aHJvdWdoIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIFVwc3RyZWFtIFBFIi4gIE5vdGUgdGhhdCBpZiB0aGUgY29ubmVjdGl2aXR5IHRvIEMtUyB0 aHJvdWdoIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUHJpbWFyeSBVcHN0cmVh bSBQRSBiZWNvbWVzIHVuYXZhaWxhYmxlLCB0aGVuIHRoZSBQRSB3aWxsIHNlbGVjdCB0aGU8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQcmltYXJ5IFVwc3RyZWFtIFBFIGJlY29t ZXMgdW5hdmFpbGFibGUsIHRoZW4gdGhlIFBFIHdpbGwgc2VsZWN0IHRoZTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgU3RhbmRieSBVcHN0cmVhbSBQRSBhcyBpdHMgVXBzdHJlYW0gUEUg Zm9yIEMtUy4gIFdoZW4gdGhlIFByaW1hcnkgUEU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBTdGFuZGJ5IFVwc3RyZWFtIFBFIGFzIGl0cyBVcHN0cmVhbSBQRSBmb3IgQy1TLiAg V2hlbiB0aGUgUHJpbWFyeSBQRTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbGF0ZXIg YmVjb21lcyBhdmFpbGFibGUsIHRoZW4gdGhlIFBFIHdpbGwgc2VsZWN0IHRoZSBQcmltYXJ5IFVw c3RyZWFtPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbGF0ZXIgYmVjb21lcyBh dmFpbGFibGUsIHRoZW4gdGhlIFBFIHdpbGwgc2VsZWN0IHRoZSBQcmltYXJ5IFVwc3RyZWFtPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQRSBhZ2FpbiBhcyBpdHMgVXBzdHJlYW0gUEUu ICBTdWNoIGJlaGF2aW9yIGlzIHJlZmVycmVkIHRvIGFzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgUEUgYWdhaW4gYXMgaXRzIFVwc3RyZWFtIFBFLiAgU3VjaCBiZWhhdmlvciBp cyByZWZlcnJlZCB0byBhczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgInJldmVydGl2 ZSIgYmVoYXZpb3IgYW5kIE1VU1QgYmUgc3VwcG9ydGVkLiAgTm9uLXJldmVydGl2ZSBiZWhhdmlv cjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICJyZXZlcnRpdmUiIGJlaGF2aW9y IGFuZCBNVVNUIGJlIHN1cHBvcnRlZC4gIE5vbi1yZXZlcnRpdmUgYmVoYXZpb3I8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CgogICAgIDx0cj48dGQ+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkPjwvdGQ+PC90cj4K ICAgICA8dHIgaWQ9ImVuZCIgYmdjb2xvcj0iZ3JheSI+PHRoIGNvbHNwYW49IjUiIGFsaWduPSJj ZW50ZXIiPiZuYnNwO0VuZCBvZiBjaGFuZ2VzLiAxMiBjaGFuZ2UgYmxvY2tzLiZuYnNwOzwvdGg+ PC90cj4KICAgICA8dHIgY2xhc3M9InN0YXRzIj48dGQ+PC90ZD48dGg+PGk+MjAgbGluZXMgY2hh bmdlZCBvciBkZWxldGVkPC9pPjwvdGg+PHRoPjxpPiA8L2k+PC90aD48dGg+PGk+MzcgbGluZXMg Y2hhbmdlZCBvciBhZGRlZDwvaT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgPHRyPjx0ZCBjb2xz cGFuPSI1IiBhbGlnbj0iY2VudGVyIiBjbGFzcz0ic21hbGwiPjxicj5UaGlzIGh0bWwgZGlmZiB3 YXMgcHJvZHVjZWQgYnkgcmZjZGlmZiAxLjQ4LiBUaGUgbGF0ZXN0IHZlcnNpb24gaXMgYXZhaWxh YmxlIGZyb20gPGEgaHJlZj0iaHR0cDovL3d3dy50b29scy5pZXRmLm9yZy90b29scy9yZmNkaWZm LyI+aHR0cDovL3Rvb2xzLmlldGYub3JnL3Rvb2xzL3JmY2RpZmYvPC9hPiA8L3RkPjwvdHI+CiAg IDwvdGJvZHk+PC90YWJsZT4KICAgCiAgIAo8L2JvZHk+PC9odG1sPg== --00000000000001992105b3ead4c4-- From nobody Thu Nov 12 09:02:41 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BF83A1408; Thu, 12 Nov 2020 09:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2xRLnI_An23; Thu, 12 Nov 2020 09:02:35 -0800 (PST) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2073.outbound.protection.outlook.com [40.107.237.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97A893A1402; Thu, 12 Nov 2020 09:02:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KxEEIkIXU0aosQQxV3lxKCwG54LYLzos1jzkxQE/3aRlE9C+l+0gjP/PHQK3/bDCuvSvV8/Zx+Wggl6C3oA+1KxrA0E5ZFHJLVxO8kLSTW11LhgKA9V3U6c2O/3RUc01V3m1e7HkOJul4vCnFStNsk+Jffhk4mdbcnKksuMLXmpZbyhyoWaPiI1nyyDeTzMu5EoRlhzroq5S1u68BdzMH5TsEU/msKx7w2OLaIYHLdlqQjVsDPWjGAQObb1Z7JUS1hF/SEXas31zzS5l+z5HRhAKBwV1nsCgcGl9UZKJFS4qNFl4C1PHCDlq/4xSUmhok7P32m1EZpuDY2Q4fCQxLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CJhcJcsaeS+sNLjZBFGT5kGf/JRb+tqSbSv1ju7nM1s=; b=ksPVr1OI8nbBu0wd8ZVFY8ZG/07xioFl2aE2+Kl3dEQa+ir8tlf/xvoqKcEZX6INUUHF0gt7LhLhKgpMHR3qmwaBzVVeBRBphoSrLcinbWXrCdom5SVRt4vtB46x0Oq1v3GxbMqHHPBLbbhL3kCHV2W9NwgWM4FexzVJsVTzlMnYkwZ2JP2/4zn2U5sjDXMaYzkUz/aRduo9E9Zs8C/egA6TmGXPQMD3P0Q07w1LmonwlVjafQMx+JhDYexaJyCdsBIw8gpdm6DeZD9otGdDtoGg2b29agMis6JUYiN4Od8185Hy352TWCc/4IbNhGmfeV8ReqL6aRL/nFWqDijkag== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CJhcJcsaeS+sNLjZBFGT5kGf/JRb+tqSbSv1ju7nM1s=; b=WuPrZsm3dtbkI/+zvwJslEPJHb2/Dafla0Qb7CREmvbWmgF9YxnaUqxfzgozQ3fn3gkXKGBPC0LWxscukrTb3J8rXTir7PQBq/vHp/F0wmSwW7vWo3Boj+PlGo3PRKyxu9GLDzrzToT8/kMV9ETjVKDpoo1mjfeVE7fhIz/ZzKM= Received: from DM6PR15MB2379.namprd15.prod.outlook.com (2603:10b6:5:8a::16) by DM6PR15MB3943.namprd15.prod.outlook.com (2603:10b6:5:2bf::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Thu, 12 Nov 2020 17:02:26 +0000 Received: from DM6PR15MB2379.namprd15.prod.outlook.com ([fe80::28b4:8429:419b:15b0]) by DM6PR15MB2379.namprd15.prod.outlook.com ([fe80::28b4:8429:419b:15b0%3]) with mapi id 15.20.3541.025; Thu, 12 Nov 2020 17:02:26 +0000 From: Daniel Migault To: Greg Mirsky CC: "secdir@ietf.org" , BESS , "last-call@ietf.org" , "draft-ietf-bess-mvpn-fast-failover.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-bess-mvpn-fast-failover-11 Thread-Index: AQHWt9C5emGUONFgKUKxrX3Gy2SfzqnDA2lugAGjIICAAAkkmw== Date: Thu, 12 Nov 2020 17:02:26 +0000 Message-ID: References: <160345656094.22100.7057001737682109381@ietfa.amsl.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [96.22.11.129] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b65a4686-0d1b-4dd9-44e2-08d8872cbb59 x-ms-traffictypediagnostic: DM6PR15MB3943: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: B0UBjPEz+CQkhwKt3/WiLY6zbJz5k5DU5Y5HdpBMTrDRgEyd7+LjX6Ve+ANSmVERuh4F+R9s5xct/AK0jzY+IvQhaOgDdduKW2xFbD6TCxJtoJjbfJ+mvdpuej07KrMqaORz4psSUsyDRM/huuVHO88mcQJrRybuZ190EKW21s/1c5Qnnipuo2wWqu7aKn9l1o2mgPXCYejsShCLOP2UC1UmX9pfkvTimNuaA28iG70UGZbW8ejXygOg4a8Ka9aEU1C2k4tyG/tyz/4CO0J1qTuqof526x6HvjIDFV+fSisjDzhQ4J3KCiQYzO5THtqlZp8ZokaW5Bu2LBXLdBu+knBAPEDFqMVhKHx6aDy+/vYFqHt20a8PLptnK4dbqp2/ x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR15MB2379.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(39860400002)(346002)(376002)(366004)(396003)(44832011)(66476007)(52536014)(5660300002)(66556008)(66446008)(19627405001)(6916009)(76116006)(8936002)(66946007)(64756008)(91956017)(478600001)(71200400001)(86362001)(33656002)(55016002)(8676002)(186003)(4326008)(66574015)(7696005)(9686003)(53546011)(6506007)(83380400001)(2906002)(26005)(316002)(30864003)(54906003)(21314003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: eAPZBcUYbke8Li7hfekNgFLol0vaX3uYKP/sV9J2gxZhsyBYtmyxjWVDO0MUUC5Te9zlgdOIIorkT/HccZHR4ST+GYVfcuZdMLOjpvpwcQxq+ZWN8Qbl5ufROgNad7f0aI9935jt4QY8v/w8oEfgAiJV1pyxknD0NMqFmW0Vg6fQSaDkTS96YpNk5ynb8wFyYgl/6HFgUNwTnumL3eQwJxYTUJzL0UswFXyXJ0EL7yWGmeYkC+0i2yg5fCNri2y+UAx8bzNfOcagXifl6Vv6sc+Rkd2TXF1u6E2j5PTFTYNY3UkOwIZVGObiEmD69l6kO5mW1I9zum4h0AxC38O6j2pHpG3IzlO75xs0lvwmxK6BBE5qy1WuiXxKKAtvKuFsEiFGUA1tK+P3nEvHx8216D5cJ6Ie2O5ftdQ9iiY17qOp3PQbd7BpHomHuGsVTuMunjuC0ATqrXICTzc54V7wsneRq+nr/Hbj9HNLFY3nAKnCDkVCeSEup9zK8U3/ZmjpJhx7GYFVsQkpaTOV4eT+eykxJsH5DAFUFiegl6NNGjiJ/6ehYrCikYt4nz2rm2JLspjVraZxsfnlBqvcPuvrYpGVvtNRhQNzuGR2jGhBir0NiEoGlipQriArtfLXz825jtMF93rsD2YPe6wdLgMmXA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR15MB2379F1203196C3015C583ECBE3E70DM6PR15MB2379namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR15MB2379.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b65a4686-0d1b-4dd9-44e2-08d8872cbb59 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2020 17:02:26.3786 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: i6t2sBNgPPWfr53IsNwx1WQlzNFcmuPqJs64P9bN4K2BFurgHLSldVYTyXG9AqHgyIpqME3s6yVZ0yRHJzMqxd2sysZjTzAr+dve+MixvIY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB3943 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-bess-mvpn-fast-failover-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 17:02:39 -0000 --_000_DM6PR15MB2379F1203196C3015C583ECBE3E70DM6PR15MB2379namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Thanks for the response Greg. This seems to go in the right direction, but = I think it would be nice to detail a bit on the negative impact that may re= sult from the fast-fail over. """ unnecessary failover negatively impacting the multicast service """ I apology to appear being maybe a bit picky, but, at least to me, the secur= ity consideration section is the place to point on specific impacts that an= operator may not have thought of and the text appears to me a bit too vagu= e on what can impact negatively the multicast service. Let me dig a bit on what I mean and probably what information I would have = expected to find. Maybe that would have been useful I provided those earlie= r. Again, not being an expert in this area, please take my following recomm= endations with a pitch of salt. What I would like, for example, to understand is whether having a fast-fail= over between nodes that work properly results in a packet lost or not. I also envision that in some cases, this will result in packet re-ordering = which might result in packet being rejected by the end node. In IPsec vpns, we have specific counters, keys that make fail-over relative= ly complex as a context has to be maintained between the old and the new no= de to pass anti replay protection and enable appropriated encryption/decryp= tion. It would be good to clarify if any parameters need - or not - to be s= ynchronized between the two nodes as its transfer represents a risk of disr= upting the traffic, and thus may be mentioned. There probably other points I am missing due to my lack of expertise - espe= cially those due to operational practices. I believe that any information that you could think of that would encourage= you to double check/validate a network outage is present over performing t= he fast failover might be useful information. Similarly, it would be good to mention cases where an operator may choose n= ot to deploy such mechanism. Yours, Daniel ________________________________ From: Greg Mirsky Sent: Thursday, November 12, 2020 10:47 AM To: Daniel Migault Cc: secdir@ietf.org ; BESS ; last-call@ietf= .org ; draft-ietf-bess-mvpn-fast-failover.all@ietf.org = Subject: Re: Secdir last call review of draft-ietf-bess-mvpn-fast-failover-= 11 Hi Daniel, thank you for your kind consideration of my notes. I've top-copied what app= eared to me as the remaining open issues. I hope I've not missed any of you= r questions. Please find my notes in-line below tagged GIM>>. Attached are = the updated working version and the new diff. Regards, Greg sure. If you know the network is down, then fast fail-over is definitively = a plus. What I think could be useful is to evaluate the cost associated to = a fast-fail-over without any network failure. This would be useful for an = operator to evaluate whether it should spend more time in diagnosing a netw= ork failure versus performing a fast-fail-over. Typically, if a fast failover comes a no cost at all, one operator would ma= ybe use one exchange to test the liveness of a node rather than 3. At that point, it seems to me that additional text coudl be added to charac= terize the impact. These could be high level and indicative, but it seems t= o me that knowing these impacts presents some value to the operators. GIM>> I would like to add a new paragraph in Section 3.1: NEW TEXT: All methods described in this section may produce false-negative state changes that can be the trigger for an unnecessary failover negatively impacting the multicast service provided by the VPN. An operator expected to consider the network environment and use available controls of the mechanism used to determine the status of a P-tunnel. Would the new text be helpful? Thanks for the feed back, It seems to me important to mention it is not rec= ommended these two mechanism co-exist. How to avoid false negative transition might be out of scope of the draft I= agree, but it seems to me worth being mentioned especially in relation to = the impacts associated to a fail-over. In case the fast-failover comes wit= h no impact this becomes less of a problem for operator deploying it. GIM>> I hope that the new text presented above addresses this concern. I understand the document is addressing a 1:N scenario. That said, if M:N s= cenario leverage from 1:N protection it seems to me worth raising the issue= . GIM>> I propose adding the clarification of the use of the Sandby PE in Sec= tion 4: OLD TEXT: The procedures described below are limited to the case where the site that contains C-S is connected to two or more PEs, though, to simplify the description, the case of dual-homing is described. NEW TEXT: The procedures described below are limited to the case where the site that contains C-S is connected to two or more PEs, though, to simplify the description, the case of dual-homing is described. Such a redundancy protection scheme, referred to as 1:N protection, is the special case of M:N protection, where M working instances are sharing protection of the N standby instances. In addition to a network failure detection mechanism, the latter scheme requires using a mechanism to coordinate the failover among working instances. For that reason, M:N protection is outside the scope of this specification. On Wed, Nov 11, 2020 at 8:48 AM Daniel Migault > wrote: Hi Greg, Thanks for the response and clarifications. Most of my comments have been a= ddressed/answered. However, it seems to me that some additional text might = be added to the security consideration section document the impact on the n= etwork of a fast-failover operation. The knowledge of these impact might be= useful for an operator to determine when the trigger can be done. Please see more comments inline. Yours, Daniel ________________________________ From: Greg Mirsky > Sent: Tuesday, November 10, 2020 9:13 PM To: Daniel Migault > Cc: secdir@ietf.org >; BESS >; last-call@ietf.org<= mailto:last-call@ietf.org> >;= draft-ietf-bess-mvpn-fast-failover.all@ietf.org > Subject: Re: Secdir last call review of draft-ietf-bess-mvpn-fast-failover-= 11 Hi Daniel, many thanks for the review, thoughtful comments, and questions, all are muc= h appreciated. Also, my apologies for the long delay to respond to your com= ments. Please find my answers and notes in-line below tagged by GIM>>. Atta= ched are the new working version and the diff to -12. Regards, Greg On Fri, Oct 23, 2020 at 5:36 AM Daniel Migault via Datatracker > wrote: Reviewer: Daniel Migault Review result: Has Nits Hi, I reviewed this document as part of the Security Directorate's ongoing effo= rt to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors, document editors, and WG chairs should treat these comments just l= ike any other IETF Last Call comments. Please note also that my expertise in B= GP is limited, so feel free to take these comments with a pitch of salt. Review Results: Has Nits Please find my comments below. Yours, Daniel Multicast VPN Fast Upstream Failover draft-ietf-bess-mvpn-fast-failover-11 Abstract This document defines multicast VPN extensions and procedures that allow fast failover for upstream failures, by allowing downstream PEs to take into account the status of Provider-Tunnels (P-tunnels) when selecting the Upstream PE for a VPN multicast flow, and extending BGP MVPN routing so that a C-multicast route can be advertised toward a Standby Upstream PE. Though it might be just a nit, if MVPN designates multicast VPN, it might be clarifying to specify the acronym in the first sentence. This would later make the correlation with BGP MVPN clearer. GIM>> I've updated s/BGP MVPN/BGP multicast VPN/. Also, s/mVPN/MVPN/ throug= hout the document. 1. Introduction In the context of multicast in BGP/MPLS VPNs, it is desirable to provide mechanisms allowing fast recovery of connectivity on different types of failures. This document addresses failures of elements in the provider network that are upstream of PEs connected to VPN sites with receivers. Well I am not familiar with neither BGP nor MPLS. It seems that BGP/MLPS IP VPNS and MPLS/BGP IP VPNs are both used. I am wondering if there is a distinction between the two and a preferred way to designate these VPNs. My understanding is that the VPN-IPv4 characterizes the VPN while MPLS is used by the backbone for the transport. Since the PE are connected to the backbone the VPN-IPv4 needs to be labeled. GIM>> I understand that this document often sends the reader to check RFC 6= 513 and/or RFC 6514. BGP/MPLS MVPN identifies the case of providing a multi= cast service over an IP VPN that is overlayed on the MPLS data plane using = the BGP control plane. Section 3 describes local procedures allowing an egress PE (a PE connected to a receiver site) to take into account the status of P-tunnels to determine the Upstream Multicast Hop (UMH) for a given (C-S, C-G). This method does not provide a "fast failover" solution I understand the limitation is due to BGP convergence. GIM>> Yes, a dynamic routing protocol, BGP in this case, provides the servi= ce restoration functionality but the restoration time is significant and af= fects the experience of a client. when used alone, but can be used together with the mechanism described in Section 4 for a "fast failover" solution. Section 4 describes protocol extensions that can speed up failover by not requiring any multicast VPN routing message exchange at recovery time. Moreover, section 5 describes a "hot leaf standby" mechanism, that uses a combination of these two mechanisms. This approach has similarities with the solution described in [RFC7431] to improve failover times when PIM routing is used in a network given some topology and metric constraints. [...] 3.1.1. mVPN Tunnel Root Tracking A condition to consider that the status of a P-tunnel is up is that the root of the tunnel, as determined in the x-PMSI Tunnel attribute, is reachable through unicast routing tables. In this case, the downstream PE can immediately update its UMH when the reachability condition changes. That is similar to BGP next-hop tracking for VPN routes, except that the address considered is not the BGP next-hop address, but the root address in the x-PMSI Tunnel attribute. If BGP next-hop tracking is done for VPN routes and the root address of a given tunnel happens to be the same as the next-hop address in the BGP A-D Route advertising the tunnel, then checking, in unicast routing tables, whether the tunnel root is reachable, will be unnecessary duplication and thus will not bring any specific benefit. It seems to me that x-PMSI address designates a different interface than the one used by the Tunnel itself. If that is correct, such mechanisms seems to assume that one equipment up on one interface will be up on the other interfaces. I have the impression that a configuration change in a PE may end up in the P-tunnel being down, while the PE still being reachable though the x-PMSI Tunnel attribute. If that is a possible scenario, the current mechanisms may not provide more efficient mechanism than then those of the standard BGP. GIM>> That is a very interesting angle, thank you. Yes, in OAM, and in the = Fault Management (FM) OAM in particular, we have to make some assumptions a= bout the state of the remote system based on a single event or change of st= ate. Usually, AFAIK, operators use not a physical interface but a loopback = to associate with a tunnel. With a fast IGP convergence, a loopback interfa= ce is reachable as long as there's a path through the network between two n= odes. Thanks for the clarification Similarly, it is assumed the tunnel is either up or down and the determination of not being up if being down. I am not convinced that the two only states. Typically services under DDoS may be down for a small amount of time. While this affects the network, there is not always a clear cut between the PE being up or down. GIM>> In defect detection a system often has some hysteresis, i.e., time t= hat the system has to wait to change its state. For example, BFD changes st= ate from Up to Down after the system does not receive N consecutive packets= (usually 3). As a result, in some cases, the system can be tuned to detect= relatively short outages while in others be slower and miss short-lived ou= tages. [...] 3.1.6. BFD Discriminator Attribute P-tunnel status may be derived from the status of a multipoint BFD session [RFC8562] whose discriminator is advertised along with an x-PMSI A-D Route. This document defines the format and ways of using a new BGP attribute called the "BFD Discriminator". It is an optional transitive BGP attribute. In Section 7.2, IANA is requested to allocate the codepoint value (TBA2). The format of this attribute is shown in Figure 1. I feel that the sentence "In Section ... TBA2)." should be removed. GIM>> We use this to mark where to note the allocated value. Usually, this = text is replaced by the RFC Editor to read In Section 7.2 IANA allocated codepoint XXX. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFD Mode | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFD Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Optional TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Format of the BFD Discriminator Attribute Where: BFD Mode field is the one octet long. This specification defines the P2MP BFD Session as value 1 Section 7.2. Reserved field is three octets long, and the value MUST be zeroed on transmission and ignored on receipt. BFD Discriminator field is four octets long. Morin, et al. Expires April 5, 2021 [Page 7] Internet-Draft mVPN Fast Upstream Failover October 2020 Optional TLVs is the optional variable-length field that MAY be used in the BFD Discriminator attribute for future extensions. TLVs MAY be included in a sequential or nested manner. To allow for TLV nesting, it is advised to define a new TLV as a variable- length object. Figure 2 presents the Optional TLV format TLV that consists of: * one octet-long field of TLV 's Type value (Section 7.3) * one octet-long field of the length of the Value field in octets * variable length Value field. The length of a TLV MUST be multiple of four octets. I am wondering why the constraint on the length is not mentioned in the paragraph associated to the field - as opposed to a separate paragraph. GIM>> There might be a slight confusion due to the use of Length and length= . Capitalized - the name of the field which value is the length of the Valu= e field. The last sentence refers to the overall length of a TLV, including= lengths of Type, Length and Value fields. you are correct that might have confused me. [..] 8. Security Considerations This document describes procedures based on [RFC6513] and [RFC6514] and hence shares the security considerations respectively represented in these specifications. This document uses p2mp BFD, as defined in [RFC8562], which, in turn, is based on [RFC5880]. Security considerations relevant to each protocol are discussed in the respective protocol specifications. An implementation that supports this specification MUST use a mechanism to control the maximum number of p2mp BFD sessions that can be active at the same time. At a high level view - or at least my interpretation of it - the document proposes a mechanism based on BFD to detect fault in the path. Upon a fault detection a fail-over operation is instructed using BGP. This rocedure is expected to perform a faster fail-over than traditional BGP convergence on maintaining routing tables. Once the fail over has been performed, BFD is confirms the new path is "legitimate" and works. It seems correct to me that the current protocol relies on BGP / BFD security. That said, having BFD authentication based on MD5 or SHA1 may suggest that stronger primitives be recommended. While this does not concerns the current document, it seems to me that the information might be relayed to routing ADs. What remains unclear to me - and I assume this might be due to my lake or expertise in routing area - is the impact associated to performing a fail-over both on 1) the data plane and 2) the standard BGP way to establish routing tables. Regarding the data plane, I am wondering if fail-over results in a lost of packets for example - I suppose for example that at least the packets in the process of being forwarded might be lost. I believe that providing details on this may be good. GIM>> You bring up a very topic for the discussion, thank you. With network= failure detection in place, the fail-over can be viewed as the reaction to= a network failure. If that is the case, then packet loss experienced by s= ervice due to the fail-over is the result of the network failure. Would you= agree with that view? A shorter failure detection interval and faster fail= -over should minimize the packet loss and, as a result, the negative impact= on the service itself. sure. If you know the network is down, then fast fail-over is definitively = a plus. What I think could be useful is to evaluate the cost associated to = a fast-fail-over without any network failure. This would be useful for an = operator to evaluate whether it should spend more time in diagnosing a netw= ork failure versus performing a fast-fail-over. Typically, if a fast failover comes a no cost at all, one operator would ma= ybe use one exchange to test the liveness of a node rather than 3. At that point, it seems to me that additional text coudl be added to charac= terize the impact. These could be high level and indicative, but it seems t= o me that knowing these impacts presents some value to the operators. If there are any impacts I would like to understand also in which cases the decision to perform a failover operation may result in more harm than the event that has been over-interpreted. An hypothetical scenario could be that the non reception of a BFD packet is interpreted as a PE being down while it may not be correct and the PE might have been simply under stress. A "too fast" fail-over may over interpreted it and perform a fail-over. If such things could happen, an attacker could leverage a micro event to perform network operation that are not negligible. Another way to see that is that an attacker might not have direct access to the control plan, but could use the data plan to generate a stress and sort of control the fail over. It seems to me that some text might be welcome to prevent such cases to happen. This could be guidance for declaring a tunnel down for example. GIM>> I agree with your scenario. Over-short detection interval may produce= a false-negative transition to the Down state in BFD and thus triggering t= he fail-over. I think that that is more an operational issue, something tha= t an operator will consider when deploying the mechanism specified in this = draft. Resulting from addressing RtgDir review the draft was updated to pro= vide more guidance: In many cases, it is not practical to use both protection methods at the same time because uncorrelated timers might cause unnecessary switchovers and destabilize the network. Thanks for the feed back, It seems to me important to mention it is not rec= ommended these two mechanism co-exist. How to avoid false negative transition might be out of scope of the draft I= agree, but it seems to me worth being mentioned especially in relation to = the impacts associated to a fail-over. In case the fast-failover comes wit= h no impact this becomes less of a problem for operator deploying it. Though the text above might not be general, I think that it also applies to= the scenario you've presented. Similarly, it would be good to add some text regarding the interferences with the non-fast forwarding fail over when performed by the standard BGP. Typically, my impression is that the fast fail-over mechanism is a local decision versus the BGP convergence that is more global. As a result, even with more time this two mechanisms may come with different outcomes. One such example to illustrate my purpose could be the following. Note that this is only illustrative of my purpose, and I let you find and pick on ethat is more appropriated. I am thinking of a case where a standby PE is be shared among multiple PEs - supposing this situation could occur. Typically, if PE_1, PE_2 are shared by PE_a, ..., PE_z. In case PE_a and PE_b are down, we expect PE_a to switch to PE_1 and PE_b to switch to PE_2. It seems to me that BGP would end up in such situation while a local decision may end up in PE_a and PE_a to switch to PE_1. GIM>> Thank you for the scenario that is very common in deploying protectio= n based on the shared redundant resources. Such schemes, referred to as M:N= protection, in addition to using mechanism detecting a network failure, e.= g., BFD, require a protocol to coordinate the switchover. This specificatio= n applies to a more special deployment scenario where one working PE is pro= tected by one or more standby PEs, i.e., 1:N protection. I understand the document is addressing a 1:N scenario. That said, if M:N s= cenario leverage from 1:N protection it seems to me worth raising the issue= . --_000_DM6PR15MB2379F1203196C3015C583ECBE3E70DM6PR15MB2379namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Greg, 

Thanks for the response Greg. This seems to go in the right direction, but = I think it would be nice to detail a bit on the negative impact that may re= sult from the fast-fail over. 

"""
unnecessary failover negatively impacting the multicast service
"""

I apology to appear being maybe a bit picky, but, at least to me, the securi= ty consideration section is the place to point on specific impacts that an = operator may not have thought of and the text appears to me a bit too vague= on what can impact negatively the multicast service. 

Let me dig a bit on what I mean and probably what information I would have exp= ected to find. Maybe that would have been useful I provided those earlier.&= nbsp;Again, not being an expert in this area, please take my following recommendations= with a pitch of salt. 

What I would like, for example, to understand is whether having a fast-fail= over between nodes that work properly results in a packet lost or not. = ;
I also envision that in some cases, this will result in packet re-ordering = which might result in packet being rejected by the end node. 
In IPsec vpns, we have specific counters, keys that make fail-over relative= ly complex as a context has to be maintained between the old and the new no= de to pass anti replay protection and enable appropriated encryption/decryp= tion. It would be good to clarify if any parameters need - or not - to be synchronized between the two nodes= as its transfer represents a risk of disrupting the traffic, and thus may = be mentioned. 
There probably other points I am missing due to my lack of expertise - espe= cially those due to operational practices. 
I believe that any information that you could think of that would encourage= you to double check/validate a network outage is present over performing t= he fast failover might be useful information.    
Similarly, it would be good to mention cases where an operator may choose n= ot to deploy such mechanism.

Yours, 
Daniel

From: Greg Mirsky <gregi= mirsky@gmail.com>
Sent: Thursday, November 12, 2020 10:47 AM
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: secdir@ietf.org <secdir@ietf.org>; BESS <bess@ietf.org&= gt;; last-call@ietf.org <last-call@ietf.org>; draft-ietf-bess-mvpn-fa= st-failover.all@ietf.org <draft-ietf-bess-mvpn-fast-failover.all@ietf.or= g>
Subject: Re: Secdir last call review of draft-ietf-bess-mvpn-fast-fa= ilover-11
 
Hi Daniel,
thank you for your kind consideration of my notes. I've top-copied wha= t appeared to me as the remaining open issues. I hope I've not missed&= nbsp;any of your questions. Please find my notes in-line below tagged GIM&g= t;>. Attached are the updated working version and the new diff.

Regards,
Greg

<mglt>
sure. If you know the network is down, then fast fail-over is definitively = a plus. What I think could be useful is to evaluate the cost associated to = a fast-fail-over without any network failure.  This would be useful fo= r an operator to evaluate whether it should spend more time in diagnosing a network failure versus performing a= fast-fail-over.
Typically, if a fast failover comes a no cost at all, one operator would ma= ybe use one exchange to test the liveness of a node rather than 3.   &= nbsp;  

At that point, it seems to me that additional text coudl be added to charac= terize the impact. These could be high level and indicative, but it seems t= o me that knowing these impacts presents some value to the operators.  = ;    
</mglt>
GIM>> I would like to add a new paragraph in Section 3.1:
NEW TEXT:
   All methods described in this section may produce false-n= egative
   state changes that can be the trigger for an unnecessary failo= ver
   negatively impacting the multicast service provided by the VPN= .  An
   operator expected to consider the network environment and use<= br>    available controls of the mechanism used to determine the stat= us of a
   P-tunnel.

Would the new text be helpful?

<mglt>
Thanks for the feed back, It seems to me important to mention it is not rec= ommended these two mechanism co-exist.
How to avoid false negative transition might be out of scope of the draft I= agree, but it seems to me worth being mentioned especially in relation to = the impacts associated to a fail-over.  In case the fast-failover come= s with no impact this becomes less of a problem for operator deploying it.
 
</mglt>
GIM>> I hope that the new text presented above addresses this co= ncern.

<mglt>
I understand the document is addressing a 1:N scenario. That said, if M:N s= cenario leverage from 1:N protection it seems to me worth raising the issue= .
</mglt>
GIM>> I propose adding the clarification of the use of the Sandb= y PE in Section 4:
OLD TEXT:
   The procedures described below are limited to the case wh= ere the site
   that contains C-S is connected to two or more PEs, though, to<= br>    simplify the description, the case of dual-homing is described= .
NEW TEXT:
   The procedures described below are limited to the case wh= ere the site
   that contains C-S is connected to two or more PEs, though, to<= br>    simplify the description, the case of dual-homing is described= .  Such
   a redundancy protection scheme, referred to as 1:N protection,= is the
   special case of M:N protection, where M working instances are = sharing
   protection of the N standby instances.  In addition to a = network
   failure detection mechanism, the latter scheme requires using = a
   mechanism to coordinate the failover among working instances.&= nbsp; For
   that reason, M:N protection is outside the scope of this
   specification. 

On Wed, Nov 11, 2020 at 8:48 AM Dan= iel Migault <daniel.migau= lt@ericsson.com> wrote:
Hi Greg, 

Thanks for the response and clarifications. Most of my comments have been a= ddressed/answered. However, it seems to me that some additional text might = be added to the security consideration section document the impact on the n= etwork of a fast-failover operation. The knowledge of these impact might be useful for an operator to determine= when the trigger can be done. 

Please see more comments inline. 

Yours, 
Daniel 

F= rom: Greg Mirsky <gregimirsky@gmail.com>
Sent: Tuesday, November 10, 2020 9:13 PM
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: secdir@ietf= .org <secdir@ie= tf.org>; BESS <bess@ietf.org>; last-call@ietf.org<= /a> <last-call@i= etf.org>; draft-ietf-bess-mvpn-fast-failover.all@ietf.org <draft-iet= f-bess-mvpn-fast-failover.all@ietf.org>
Subject: Re: Secdir last call review of draft-ietf-bess-mvpn-fast-fa= ilover-11
 
Hi Daniel,
many thanks for the review, thoughtful comments, and questions, all ar= e much appreciated. Also, my apologies for the long delay to respond to you= r comments. Please find my answers and notes in-line below tagged by GIM>= ;>. Attached are the new working version and the diff to -12.

Regards,
Greg

On Fri, Oct 23, 2020 at 5:36 AM Daniel Migault via Datatra= cker <noreply@ietf= .org> wrote:
Reviewer: Daniel Migault
Review result: Has Nits

Hi,


I reviewed this document as part of the Security Directorate's ongoing effo= rt to
review all IETF documents being processed by the IESG.  These comments= were
written primarily for the benefit of the Security Area Directors.  Doc= ument
authors, document editors, and WG chairs should treat these comments just l= ike
any other IETF Last Call comments.  Please note also that my expertise= in BGP is
limited, so feel free to take these comments with a pitch of salt. 
Review Results: Has Nits

Please find my comments below.

Yours,
Daniel


                  Multicast VP= N Fast Upstream Failover
                 draft-ietf-be= ss-mvpn-fast-failover-11

Abstract

   This document defines multicast VPN extensions and procedures = that
   allow fast failover for upstream failures, by allowing downstr= eam PEs
   to take into account the status of Provider-Tunnels (P-tunnels= ) when
   selecting the Upstream PE for a VPN multicast flow, and extend= ing BGP
   MVPN routing so that a C-multicast route can be advertised tow= ard a
   Standby Upstream PE.

<mglt>
Though it might be just a nit, if MVPN
designates multicast VPN, it might be
clarifying to specify the acronym in the
first sentence. This would later make
the correlation with BGP MVPN clearer.

</mglt>
GIM>> I've updated s/BGP MVPN/BGP multicast VPN/. Also, s/mVPN/M= VPN/ throughout the document.


1.  Introduction

   In the context of multicast in BGP/MPLS VPNs, it is desirable = to
   provide mechanisms allowing fast recovery of connectivity on    different types of failures.  This document addresses fai= lures of
   elements in the provider network that are upstream of PEs conn= ected
   to VPN sites with receivers.

<mglt>
Well I am not familiar with neither BGP
nor MPLS. It seems that BGP/MLPS IP VPNS
and MPLS/BGP IP VPNs are both used. I am
wondering if there is a distinction
between the two and a preferred way to
designate these VPNs.  My understanding
is that the VPN-IPv4 characterizes the
VPN while MPLS is used by the backbone
for the transport.  Since the PE are
connected to the backbone the VPN-IPv4
needs to be labeled.

</mglt>
GIM>> I understand that this document often sends the reader to = check RFC 6513 and/or RFC 6514. BGP/MPLS MVPN identifies the case of provid= ing a multicast service over an IP VPN that is overlayed on the MPLS d= ata plane using the BGP control plane.

   Section 3 describes local procedures allowing an egress PE (a = PE
   connected to a receiver site) to take into account the status = of
   P-tunnels to determine the Upstream Multicast Hop (UMH) for a = given
   (C-S, C-G).  This method does not provide a "fast fa= ilover" solution
<mglt>
I understand the limitation is due to
BGP convergence.

</mglt>
GIM>> Yes, a dynamic routing protocol, BGP in this case, provide= s the service restoration functionality but the restoration time is signifi= cant and affects the experience of a client.

   when used alone, but can be used together with the mechanism    described in Section 4 for a "fast failover" solutio= n.

   Section 4 describes protocol extensions that can speed up fail= over by
   not requiring any multicast VPN routing message exchange at re= covery
   time.

   Moreover, section 5 describes a "hot leaf standby" m= echanism, that
   uses a combination of these two mechanisms.  This approac= h has
   similarities with the solution described in [RFC7431] to impro= ve
   failover times when PIM routing is used in a network given som= e
   topology and metric constraints.


[...]

3.1.1.  mVPN Tunnel Root Tracking

   A condition to consider that the status of a P-tunnel is up is= that
   the root of the tunnel, as determined in the x-PMSI Tunnel att= ribute,
   is reachable through unicast routing tables.  In this cas= e, the
   downstream PE can immediately update its UMH when the reachabi= lity
   condition changes.

   That is similar to BGP next-hop tracking for VPN routes, excep= t that
   the address considered is not the BGP next-hop address, but th= e root
   address in the x-PMSI Tunnel attribute.

   If BGP next-hop tracking is done for VPN routes and the root a= ddress
   of a given tunnel happens to be the same as the next-hop addre= ss in
   the BGP A-D Route advertising the tunnel, then checking, in un= icast
   routing tables, whether the tunnel root is reachable, will be<= br>    unnecessary duplication and thus will not bring any specific b= enefit.

<mglt>
It seems to me that x-PMSI address
designates a different interface than
the one used by the Tunnel itself. If
that is correct, such mechanisms seems
to assume that one equipment up on one
interface will be up on the other
interfaces. I have the impression that a
configuration change in a PE may end up
in the P-tunnel being down, while the PE
still being reachable though the x-PMSI
Tunnel attribute. If that is a possible
scenario, the current mechanisms may not
provide more efficient mechanism than
then those of the standard BGP.
GIM>> That is a very interesting angle, thank you. Yes, in OAM, = and in the Fault Management (FM) OAM in particular, we have to make some as= sumptions about the state of the remote system based on a single event= or change of state. Usually, AFAIK, operators use not a physical interface but a loopback to associate with a tunnel. Wi= th a fast IGP convergence, a loopback interface is reachable as long as the= re's a path through the network between two nodes.
<mglt>
Thanks for the clarification
</mglt>

Similarly, it is assumed the tunnel is
either up or down and the determination
of not being up if being down.  I am not
convinced that the two only states.
Typically services under DDoS may be
down for a small amount of time. While
this affects the network, there is not
always a clear cut between the PE being
up or down.
</mglt>
GIM>>  In defect detection a system often has some hysteres= is, i.e., time that the system has to wait to change its state. For example= , BFD changes state from Up to Down after the system does not receive N con= secutive packets (usually 3). As a result, in some cases, the system can be tuned to detect relatively short outages = while in others be slower and miss short-lived outages.


[...]

3.1.6.  BFD Discriminator Attribute

   P-tunnel status may be derived from the status of a multipoint= BFD
   session [RFC8562] whose discriminator is advertised along with= an
   x-PMSI A-D Route.

   This document defines the format and ways of using a new BGP    attribute called the "BFD Discriminator".  It i= s an optional
   transitive BGP attribute.  In Section 7.2, IANA is reques= ted to
   allocate the codepoint value (TBA2).  The format of this = attribute is
   shown in Figure 1.

<mglt>
I feel that the sentence "In Section ...
TBA2)." should be removed.

</mglt>
GIM>> We use this to mark where to note the allocated value. Usu= ally, this text is replaced by the RFC Editor to read 
In Section 7.2 IANA allocated codepoint XXX.



       0             = ;      1              &nb= sp;    2                &= nbsp;  3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
      |    BFD Mode   |    &nb= sp;             Reserved      =                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
      |              &nbs= p;        BFD Discriminator        =                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
      ~              &nbs= p;          Optional TLVs      &nbs= p;                  ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+


            Figure 1: Format of the BFD Discr= iminator Attribute

   Where:

      BFD Mode field is the one octet long.  This speci= fication defines
      the P2MP BFD Session as value 1 Section 7.2.

      Reserved field is three octets long, and the value MUS= T be zeroed
      on transmission and ignored on receipt.

      BFD Discriminator field is four octets long.





Morin, et al.             Expires April = 5, 2021                 [Page = 7]

Internet-Draft         mVPN Fast Upstream Failover=           October 2020


      Optional TLVs is the optional variable-length field th= at MAY be
      used in the BFD Discriminator attribute for future ext= ensions.
      TLVs MAY be included in a sequential or nested manner.=   To allow
      for TLV nesting, it is advised to define a new TLV as = a variable-
      length object.  Figure 2 presents the Optional TL= V format TLV that
      consists of:

      *  one octet-long field of TLV 's Type value (Sec= tion 7.3)

      *  one octet-long field of the length of the Valu= e field in octets

      *  variable length Value field.

      The length of a TLV MUST be multiple of four octets. <mglt>
I am wondering why the constraint on the
length is not mentioned in the paragraph
associated to the field - as opposed to
a  separate paragraph.

</mglt>
GIM>> There might be a slight confusion due to the use of Length= and length. Capitalized - the name of the field which value is the length = of the Value field. The last sentence refers to the overall length of a TLV= , including lengths of Type, Length and Value fields.

<mglt>
you are correct that might have confused me. 
</mglt>

[..]

8.  Security Considerations

   This document describes procedures based on [RFC6513] and [RFC= 6514]
   and hence shares the security considerations respectively repr= esented
   in these specifications.

   This document uses p2mp BFD, as defined in [RFC8562], which, i= n turn,
   is based on [RFC5880].  Security considerations relevant = to each
   protocol are discussed in the respective protocol specificatio= ns.  An
   implementation that supports this specification MUST use a mec= hanism
   to control the maximum number of p2mp BFD sessions that can be= active
   at the same time.

<mglt>
At a high level view - or at least my
interpretation of it - the document
proposes a mechanism based on BFD to
detect fault in the path.  Upon a fault
detection a fail-over operation is
instructed using BGP. This rocedure is
expected to perform a faster fail-over
than traditional BGP convergence on
maintaining routing tables. Once the
fail over has been performed, BFD is
confirms the new path is "legitimate"
and works.

It seems correct to me that the current
protocol relies on BGP / BFD security.
That said, having BFD authentication
based on MD5 or SHA1 may suggest that
stronger primitives be recommended.
While this does not concerns the current
document, it seems to me that the
information might be relayed to routing
ADs.

What remains unclear to me - and I
assume this might be due to my lake or
expertise in routing area - is the impact
associated to performing a fail-over
both on 1) the data plane and 2) the
standard BGP way to establish routing
tables.

Regarding the data plane, I am wondering
if fail-over results in a lost of
packets for example - I suppose for
example that at least the packets in the
process of being forwarded might be
lost. I believe that providing details
on this may be good.
GIM>> You bring up a very topic for the discussion, thank you. W= ith network failure detection in place, the fail-over can be viewed as the = reaction to a network failure.  If that is the case, then packet loss = experienced by service due to the fail-over is the result of the network failure. Would you agree with that view? A sh= orter failure detection interval and faster fail-over should minimize = the packet loss and, as a result, the negative impact on the service itself= .

<mglt>
sure. If you know the network is down, then fast fail-over is definiti= vely a plus. What I think could be useful is to evaluate the cost associate= d to a fast-fail-over without any network failure.  This would be usef= ul for an operator to evaluate whether it should spend more time in diagnosing a network failure versus performin= g a fast-fail-over. 
Typically, if a fast failover comes a no cost at all, one operator wou= ld maybe use one exchange to test the liveness of a node rather than 3.&nbs= p;     

At that point, it seems to me that additional text coudl be added to c= haracterize the impact. These could be high level and indicative, but it se= ems to me that knowing these impacts presents some value to the operators.&= nbsp;     
</mglt>

If there are any impacts I would like to
understand also in which cases the
decision to perform a failover operation
may result in more harm than the event
that has been over-interpreted. An
hypothetical scenario could be that the
non reception of a BFD packet is
interpreted as a PE being down while it
may not be correct and the PE might have
been simply under stress. A "too fast" fail-over
may over interpreted it and perform a
fail-over. If such things could happen,
an attacker could leverage a micro event
to perform network operation that are
not negligible. Another way to see that
is that an attacker might not have
direct access to the control plan, but
could use the data plan to generate a
stress and sort of control the fail
over. It seems to me that some text
might be welcome to prevent such cases
to happen. This could be guidance for
declaring a tunnel down for example.
GIM>> I agree with your scenario. Over-short detection interval = may produce a false-negative transition to the Down state in BFD and thus t= riggering the fail-over. I think that that is more an operational issue, so= mething that an operator will consider when deploying the mechanism specified in this draft. Resulting from addre= ssing RtgDir review the draft was updated to provide more guidance:
   In many cases, it is not practical to use both protection=
   methods at the same time because uncorrelated timers might cau= se
   unnecessary switchovers and destabilize the network.
<mglt>
Thanks for the feed back, It seems to me important to mention it is no= t recommended these two mechanism co-exist. 
How to avoid false negative transition might be out of scope of the dr= aft I agree, but it seems to me worth being mentioned especially in relatio= n to the impacts associated to a fail-over.  In case the fast-failover= comes with no impact this becomes less of a problem for operator deploying it.
 
</mglt>
Though the text above might not be general, I think that it also appli= es to the scenario you've presented.

Similarly, it would be good to add some
text regarding the interferences with
the non-fast forwarding fail over when
performed by the standard BGP.
Typically, my impression is that the
fast fail-over mechanism is a local
decision versus the BGP convergence that
is more global. As a result, even with
more time this two mechanisms may come
with different outcomes. One such
example to illustrate my purpose could
be the following. Note that this is only
illustrative of my purpose, and I let
you find and pick on ethat is more
appropriated.   I am thinking of a case
where a standby PE is be shared among
multiple PEs - supposing this situation
could occur.  Typically, if PE_1, PE_2
are shared by PE_a, ..., PE_z. In case
PE_a and PE_b are down, we expect PE_a
to switch to PE_1 and PE_b to switch to
PE_2. It seems to me that BGP would end
up in such situation while a local
decision may end up in PE_a and PE_a to
switch to PE_1.

</mglt>
GIM>> Thank you for the scenario that is very common in deployin= g protection based on the shared redundant resources. Such schemes, referre= d to as M:N protection, in addition to using mechanism detecting a network = failure, e.g., BFD, require a protocol to coordinate the switchover. This specification applies to a more special= deployment scenario where one working PE is protected by one or more stand= by PEs, i.e., 1:N protection.

<mglt>
I understand the document is addressing a 1:N scenario. That said, if = M:N scenario leverage from 1:N protection it seems to me worth raising the = issue. 
</mglt>
--_000_DM6PR15MB2379F1203196C3015C583ECBE3E70DM6PR15MB2379namp_-- From nobody Thu Nov 12 12:14:48 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E7E3A0639; Thu, 12 Nov 2020 12:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.696 X-Spam-Level: X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfUfUJjaQQ7x; Thu, 12 Nov 2020 12:14:33 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11C573A044A; Thu, 12 Nov 2020 12:14:32 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id 11so7767851ljf.2; Thu, 12 Nov 2020 12:14:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IzkOOhDXkMy7kn+N2iS10tqf1+0xl40WMka4ycnq7gc=; b=lwpL2/s2Kkn3nWtAHV8mZB8KAOF3ruGUuNAumY39rW44imsygaLgkzlIdQZOMeIRYZ Ou3AumCj9CSF/iPNdpa2k1V7hdTWBVnHrvDWmBVav1VhEtP8Y1u7PCpux26iX3SmL892 5q/Y/o7x/qsqgtQ2/k7o4zu4rxZZiukUdwq7vibFTeihJ1+rST546xgrLVLGXhe5rkNH YsLzh8LjD9PHfZBhtmOlMlqepLEYqzrV2lkA4ThGhWkJ88TZpWobM0CFlJSH9zH88E7e /sG1grI3DeQ1UIWqfa9bCus2ByErqerr8unQ72ZuHiIlYHJb9J884lcbsQhvZKZIad1y mlaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IzkOOhDXkMy7kn+N2iS10tqf1+0xl40WMka4ycnq7gc=; b=fE9BwdT5p5SLvgnMMMKPIl6HQWcv4sWd3AkaN2ziBiJ6GdLgxWpXy8c7ySEaUYud0N U/N9XCfKlFKTv5KxVaulJafL1QEv+qF4UawKwQJAHk0RDhFkcO6HhOsvT7ERPjPpytqc HWBYdWFBqZ8qK2DEsoiMNmqoCUWYi4Tc1FsmSFWu+0qy8zflQ4USh6Rf0d/rHZ+T0k1n wSItLG3v6L3xY7lkeLPWfwGL8K2zDg6RF1tzq8D9/uRoHyiqdnidtVySsAG4Oh6NWVqZ 1Lz7HsPnPea8vIlrwEOfE8Jw6sTG4DwqEH3+qcSvk/QfurVxBM+2pkdM5mUunCgp5CGT XKPQ== X-Gm-Message-State: AOAM531xL8OOIkVNTDHej3HTkQWO3j0CzdU8u2gEbbYcIDZsmUNGfRDo xJlQxqjMxGmkoQBR2GN8mpk+1UaVzWv1zVCiIWk= X-Google-Smtp-Source: ABdhPJzUKOMXI1nFv6W6hkCiaKTxZhz8YHGt4kFgoSU8J4DpAjQ5ZG6ALw9/yiPe/WG7RBZt1noTYJP+5xPK1IeDGcA= X-Received: by 2002:a2e:3314:: with SMTP id d20mr499817ljc.23.1605212070834; Thu, 12 Nov 2020 12:14:30 -0800 (PST) MIME-Version: 1.0 References: <160345656094.22100.7057001737682109381@ietfa.amsl.com> In-Reply-To: From: Greg Mirsky Date: Thu, 12 Nov 2020 12:14:19 -0800 Message-ID: To: Daniel Migault Cc: "secdir@ietf.org" , BESS , "last-call@ietf.org" , "draft-ietf-bess-mvpn-fast-failover.all@ietf.org" Content-Type: multipart/mixed; boundary="00000000000045a2ba05b3ee8fb1" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-bess-mvpn-fast-failover-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 20:14:39 -0000 --00000000000045a2ba05b3ee8fb1 Content-Type: multipart/alternative; boundary="00000000000045a2b805b3ee8faf" --00000000000045a2b805b3ee8faf Content-Type: text/plain; charset="UTF-8" Hi Daniel, thank you for the additional information. I understand your concerns and agree that it is helpful to provide implementors and operators with useful information about the potential impact the new functionality may demonstrate in the network and how to mitigate the risks. I believe it is important to recognize that this draft proposes mechanisms that expedite the failure detection in a P-tunnel from the perspective of a downstream PE. And the detection directly impacts the control plane, not the data plane. I believe that it is difficult to make any assumptions on how the convergence in the control plane may impact the forwarding plane and what effect that will have on a multicast flow. I think that very much depends on the implementation and the HW capabilities of the platform used. I've moved the new text from Section 3.1 into the Security Considerations section. Please let me know if you think that is a more appropriate place for that paragraph. Also, I've realized that the text I've proposed earlier that refers to 1:N and N:M protection might be the source of questions and arguments and would like to withdraw it. I hope you'll agree. I've attached the new diff reflecting the changes in the working version. Regards, Greg On Thu, Nov 12, 2020 at 9:02 AM Daniel Migault wrote: > Hi Greg, > > Thanks for the response Greg. This seems to go in the right direction, but > I think it would be nice to detail a bit on the negative impact that may > result from the fast-fail over. > > """ > unnecessary failover negatively impacting the multicast service > """ > > I apology to appear being maybe a bit picky, but, at least to me, the > security consideration section is the place to point on specific impacts > that an operator may not have thought of and the text appears to me a bit > too vague on what can impact negatively the multicast service. > > Let me dig a bit on what I mean and probably what information I would have > expected to find. Maybe that would have been useful I provided those > earlier. Again, not being an expert in this area, please take my > following recommendations with a pitch of salt. > > What I would like, for example, to understand is whether having a > fast-failover between nodes that work properly results in a packet lost or > not. > I also envision that in some cases, this will result in packet re-ordering > which might result in packet being rejected by the end node. > In IPsec vpns, we have specific counters, keys that make fail-over > relatively complex as a context has to be maintained between the old and > the new node to pass anti replay protection and enable appropriated > encryption/decryption. It would be good to clarify if any parameters need - > or not - to be synchronized between the two nodes as its transfer > represents a risk of disrupting the traffic, and thus may be mentioned. > There probably other points I am missing due to my lack of expertise - > especially those due to operational practices. > I believe that any information that you could think of that would > encourage you to double check/validate a network outage is present over > performing the fast failover might be useful information. > Similarly, it would be good to mention cases where an operator may choose > not to deploy such mechanism. > > Yours, > Daniel > > ------------------------------ > *From:* Greg Mirsky > *Sent:* Thursday, November 12, 2020 10:47 AM > *To:* Daniel Migault > *Cc:* secdir@ietf.org ; BESS ; > last-call@ietf.org ; > draft-ietf-bess-mvpn-fast-failover.all@ietf.org < > draft-ietf-bess-mvpn-fast-failover.all@ietf.org> > *Subject:* Re: Secdir last call review of > draft-ietf-bess-mvpn-fast-failover-11 > > Hi Daniel, > thank you for your kind consideration of my notes. I've top-copied what > appeared to me as the remaining open issues. I hope I've not missed any of > your questions. Please find my notes in-line below tagged GIM>>. Attached > are the updated working version and the new diff. > > Regards, > Greg > > > sure. If you know the network is down, then fast fail-over is definitively > a plus. What I think could be useful is to evaluate the cost associated to > a fast-fail-over without any network failure. This would be useful for an > operator to evaluate whether it should spend more time in diagnosing a > network failure versus performing a fast-fail-over. > Typically, if a fast failover comes a no cost at all, one operator would > maybe use one exchange to test the liveness of a node rather than 3. > > At that point, it seems to me that additional text coudl be added to > characterize the impact. These could be high level and indicative, but it > seems to me that knowing these impacts presents some value to the > operators. > > GIM>> I would like to add a new paragraph in Section 3.1: > NEW TEXT: > All methods described in this section may produce false-negative > state changes that can be the trigger for an unnecessary failover > negatively impacting the multicast service provided by the VPN. An > operator expected to consider the network environment and use > available controls of the mechanism used to determine the status of a > P-tunnel. > > Would the new text be helpful? > > > Thanks for the feed back, It seems to me important to mention it is not > recommended these two mechanism co-exist. > How to avoid false negative transition might be out of scope of the draft > I agree, but it seems to me worth being mentioned especially in relation to > the impacts associated to a fail-over. In case the fast-failover comes > with no impact this becomes less of a problem for operator deploying it. > > > GIM>> I hope that the new text presented above addresses this concern. > > > I understand the document is addressing a 1:N scenario. That said, if M:N > scenario leverage from 1:N protection it seems to me worth raising the > issue. > > GIM>> I propose adding the clarification of the use of the Sandby PE in > Section 4: > OLD TEXT: > The procedures described below are limited to the case where the site > that contains C-S is connected to two or more PEs, though, to > simplify the description, the case of dual-homing is described. > NEW TEXT: > The procedures described below are limited to the case where the site > that contains C-S is connected to two or more PEs, though, to > simplify the description, the case of dual-homing is described. Such > a redundancy protection scheme, referred to as 1:N protection, is the > special case of M:N protection, where M working instances are sharing > protection of the N standby instances. In addition to a network > failure detection mechanism, the latter scheme requires using a > mechanism to coordinate the failover among working instances. For > that reason, M:N protection is outside the scope of this > specification. > > On Wed, Nov 11, 2020 at 8:48 AM Daniel Migault < > daniel.migault@ericsson.com> wrote: > > Hi Greg, > > Thanks for the response and clarifications. Most of my comments have been > addressed/answered. However, it seems to me that some additional text might > be added to the security consideration section document the impact on the > network of a fast-failover operation. The knowledge of these impact might > be useful for an operator to determine when the trigger can be done. > > Please see more comments inline. > > Yours, > Daniel > > ------------------------------ > *From:* Greg Mirsky > *Sent:* Tuesday, November 10, 2020 9:13 PM > *To:* Daniel Migault > *Cc:* secdir@ietf.org ; BESS ; > last-call@ietf.org ; > draft-ietf-bess-mvpn-fast-failover.all@ietf.org < > draft-ietf-bess-mvpn-fast-failover.all@ietf.org> > *Subject:* Re: Secdir last call review of > draft-ietf-bess-mvpn-fast-failover-11 > > Hi Daniel, > many thanks for the review, thoughtful comments, and questions, all are > much appreciated. Also, my apologies for the long delay to respond to your > comments. Please find my answers and notes in-line below tagged by GIM>>. > Attached are the new working version and the diff to -12. > > Regards, > Greg > > On Fri, Oct 23, 2020 at 5:36 AM Daniel Migault via Datatracker < > noreply@ietf.org> wrote: > > Reviewer: Daniel Migault > Review result: Has Nits > > Hi, > > > I reviewed this document as part of the Security Directorate's ongoing > effort to > review all IETF documents being processed by the IESG. These comments were > written primarily for the benefit of the Security Area Directors. Document > authors, document editors, and WG chairs should treat these comments just > like > any other IETF Last Call comments. Please note also that my expertise in > BGP is > limited, so feel free to take these comments with a pitch of salt. > > Review Results: Has Nits > > Please find my comments below. > > Yours, > Daniel > > > Multicast VPN Fast Upstream Failover > draft-ietf-bess-mvpn-fast-failover-11 > > Abstract > > This document defines multicast VPN extensions and procedures that > allow fast failover for upstream failures, by allowing downstream PEs > to take into account the status of Provider-Tunnels (P-tunnels) when > selecting the Upstream PE for a VPN multicast flow, and extending BGP > MVPN routing so that a C-multicast route can be advertised toward a > Standby Upstream PE. > > > Though it might be just a nit, if MVPN > designates multicast VPN, it might be > clarifying to specify the acronym in the > first sentence. This would later make > the correlation with BGP MVPN clearer. > > > > GIM>> I've updated s/BGP MVPN/BGP multicast VPN/. Also, s/mVPN/MVPN/ > throughout the document. > > > > 1. Introduction > > In the context of multicast in BGP/MPLS VPNs, it is desirable to > provide mechanisms allowing fast recovery of connectivity on > different types of failures. This document addresses failures of > elements in the provider network that are upstream of PEs connected > to VPN sites with receivers. > > > Well I am not familiar with neither BGP > nor MPLS. It seems that BGP/MLPS IP VPNS > and MPLS/BGP IP VPNs are both used. I am > wondering if there is a distinction > between the two and a preferred way to > designate these VPNs. My understanding > is that the VPN-IPv4 characterizes the > VPN while MPLS is used by the backbone > for the transport. Since the PE are > connected to the backbone the VPN-IPv4 > needs to be labeled. > > > > GIM>> I understand that this document often sends the reader to check RFC > 6513 and/or RFC 6514. BGP/MPLS MVPN identifies the case of providing a > multicast service over an IP VPN that is overlayed on the MPLS data plane > using the BGP control plane. > > > Section 3 describes local procedures allowing an egress PE (a PE > connected to a receiver site) to take into account the status of > P-tunnels to determine the Upstream Multicast Hop (UMH) for a given > (C-S, C-G). This method does not provide a "fast failover" solution > > I understand the limitation is due to > BGP convergence. > > > > GIM>> Yes, a dynamic routing protocol, BGP in this case, provides the > service restoration functionality but the restoration time is significant > and affects the experience of a client. > > when used alone, but can be used together with the mechanism > described in Section 4 for a "fast failover" solution. > > Section 4 describes protocol extensions that can speed up failover by > not requiring any multicast VPN routing message exchange at recovery > time. > > Moreover, section 5 describes a "hot leaf standby" mechanism, that > uses a combination of these two mechanisms. This approach has > similarities with the solution described in [RFC7431] to improve > failover times when PIM routing is used in a network given some > topology and metric constraints. > > > [...] > > 3.1.1. mVPN Tunnel Root Tracking > > A condition to consider that the status of a P-tunnel is up is that > the root of the tunnel, as determined in the x-PMSI Tunnel attribute, > is reachable through unicast routing tables. In this case, the > downstream PE can immediately update its UMH when the reachability > condition changes. > > That is similar to BGP next-hop tracking for VPN routes, except that > the address considered is not the BGP next-hop address, but the root > address in the x-PMSI Tunnel attribute. > > If BGP next-hop tracking is done for VPN routes and the root address > of a given tunnel happens to be the same as the next-hop address in > the BGP A-D Route advertising the tunnel, then checking, in unicast > routing tables, whether the tunnel root is reachable, will be > unnecessary duplication and thus will not bring any specific benefit. > > > It seems to me that x-PMSI address > designates a different interface than > the one used by the Tunnel itself. If > that is correct, such mechanisms seems > to assume that one equipment up on one > interface will be up on the other > interfaces. I have the impression that a > configuration change in a PE may end up > in the P-tunnel being down, while the PE > still being reachable though the x-PMSI > Tunnel attribute. If that is a possible > scenario, the current mechanisms may not > provide more efficient mechanism than > then those of the standard BGP. > > GIM>> That is a very interesting angle, thank you. Yes, in OAM, and in the > Fault Management (FM) OAM in particular, we have to make some > assumptions about the state of the remote system based on a single event or > change of state. Usually, AFAIK, operators use not a physical interface but > a loopback to associate with a tunnel. With a fast IGP convergence, a > loopback interface is reachable as long as there's a path through the > network between two nodes. > > Thanks for the clarification > > > > Similarly, it is assumed the tunnel is > either up or down and the determination > of not being up if being down. I am not > convinced that the two only states. > Typically services under DDoS may be > down for a small amount of time. While > this affects the network, there is not > always a clear cut between the PE being > up or down. > > > GIM>> In defect detection a system often has some hysteresis, i.e., time > that the system has to wait to change its state. For example, BFD changes > state from Up to Down after the system does not receive N consecutive > packets (usually 3). As a result, in some cases, the system can be tuned to > detect relatively short outages while in others be slower and miss > short-lived outages. > > > > [...] > > 3.1.6. BFD Discriminator Attribute > > P-tunnel status may be derived from the status of a multipoint BFD > session [RFC8562] whose discriminator is advertised along with an > x-PMSI A-D Route. > > This document defines the format and ways of using a new BGP > attribute called the "BFD Discriminator". It is an optional > transitive BGP attribute. In Section 7.2, IANA is requested to > allocate the codepoint value (TBA2). The format of this attribute is > shown in Figure 1. > > > I feel that the sentence "In Section ... > TBA2)." should be removed. > > > > GIM>> We use this to mark where to note the allocated value. Usually, this > text is replaced by the RFC Editor to read > > In Section 7.2 IANA allocated codepoint XXX. > > > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BFD Mode | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BFD Discriminator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Optional TLVs ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 1: Format of the BFD Discriminator Attribute > > Where: > > BFD Mode field is the one octet long. This specification defines > the P2MP BFD Session as value 1 Section 7.2. > > Reserved field is three octets long, and the value MUST be zeroed > on transmission and ignored on receipt. > > BFD Discriminator field is four octets long. > > > > > > Morin, et al. Expires April 5, 2021 [Page 7] > > Internet-Draft mVPN Fast Upstream Failover October 2020 > > > Optional TLVs is the optional variable-length field that MAY be > used in the BFD Discriminator attribute for future extensions. > TLVs MAY be included in a sequential or nested manner. To allow > for TLV nesting, it is advised to define a new TLV as a variable- > length object. Figure 2 presents the Optional TLV format TLV that > consists of: > > * one octet-long field of TLV 's Type value (Section 7.3) > > * one octet-long field of the length of the Value field in octets > > * variable length Value field. > > The length of a TLV MUST be multiple of four octets. > > I am wondering why the constraint on the > length is not mentioned in the paragraph > associated to the field - as opposed to > a separate paragraph. > > > > GIM>> There might be a slight confusion due to the use of Length and > length. Capitalized - the name of the field which value is the length of > the Value field. The last sentence refers to the overall length of a TLV, > including lengths of Type, Length and Value fields. > > > you are correct that might have confused me. > > > > [..] > > 8. Security Considerations > > This document describes procedures based on [RFC6513] and [RFC6514] > and hence shares the security considerations respectively represented > in these specifications. > > This document uses p2mp BFD, as defined in [RFC8562], which, in turn, > is based on [RFC5880]. Security considerations relevant to each > protocol are discussed in the respective protocol specifications. An > implementation that supports this specification MUST use a mechanism > to control the maximum number of p2mp BFD sessions that can be active > at the same time. > > > At a high level view - or at least my > interpretation of it - the document > proposes a mechanism based on BFD to > detect fault in the path. Upon a fault > detection a fail-over operation is > instructed using BGP. This rocedure is > expected to perform a faster fail-over > than traditional BGP convergence on > maintaining routing tables. Once the > fail over has been performed, BFD is > confirms the new path is "legitimate" > and works. > > It seems correct to me that the current > protocol relies on BGP / BFD security. > That said, having BFD authentication > based on MD5 or SHA1 may suggest that > stronger primitives be recommended. > While this does not concerns the current > document, it seems to me that the > information might be relayed to routing > ADs. > > What remains unclear to me - and I > assume this might be due to my lake or > expertise in routing area - is the impact > associated to performing a fail-over > both on 1) the data plane and 2) the > standard BGP way to establish routing > tables. > > Regarding the data plane, I am wondering > if fail-over results in a lost of > packets for example - I suppose for > example that at least the packets in the > process of being forwarded might be > lost. I believe that providing details > on this may be good. > > GIM>> You bring up a very topic for the discussion, thank you. With > network failure detection in place, the fail-over can be viewed as the > reaction to a network failure. If that is the case, then packet loss > experienced by service due to the fail-over is the result of the network > failure. Would you agree with that view? A shorter failure detection > interval and faster fail-over should minimize the packet loss and, as a > result, the negative impact on the service itself. > > > sure. If you know the network is down, then fast fail-over is definitively > a plus. What I think could be useful is to evaluate the cost associated to > a fast-fail-over without any network failure. This would be useful for an > operator to evaluate whether it should spend more time in diagnosing a > network failure versus performing a fast-fail-over. > Typically, if a fast failover comes a no cost at all, one operator would > maybe use one exchange to test the liveness of a node rather than 3. > > At that point, it seems to me that additional text coudl be added to > characterize the impact. These could be high level and indicative, but it > seems to me that knowing these impacts presents some value to the > operators. > > > If there are any impacts I would like to > understand also in which cases the > decision to perform a failover operation > may result in more harm than the event > that has been over-interpreted. An > hypothetical scenario could be that the > non reception of a BFD packet is > interpreted as a PE being down while it > may not be correct and the PE might have > been simply under stress. A "too fast" fail-over > may over interpreted it and perform a > fail-over. If such things could happen, > an attacker could leverage a micro event > to perform network operation that are > not negligible. Another way to see that > is that an attacker might not have > direct access to the control plan, but > could use the data plan to generate a > stress and sort of control the fail > over. It seems to me that some text > might be welcome to prevent such cases > to happen. This could be guidance for > declaring a tunnel down for example. > > GIM>> I agree with your scenario. Over-short detection interval may > produce a false-negative transition to the Down state in BFD and thus > triggering the fail-over. I think that that is more an operational issue, > something that an operator will consider when deploying the mechanism > specified in this draft. Resulting from addressing RtgDir review the draft > was updated to provide more guidance: > In many cases, it is not practical to use both protection > methods at the same time because uncorrelated timers might cause > unnecessary switchovers and destabilize the network. > > Thanks for the feed back, It seems to me important to mention it is not > recommended these two mechanism co-exist. > How to avoid false negative transition might be out of scope of the draft > I agree, but it seems to me worth being mentioned especially in relation to > the impacts associated to a fail-over. In case the fast-failover comes > with no impact this becomes less of a problem for operator deploying it. > > > Though the text above might not be general, I think that it also applies > to the scenario you've presented. > > > Similarly, it would be good to add some > text regarding the interferences with > the non-fast forwarding fail over when > performed by the standard BGP. > Typically, my impression is that the > fast fail-over mechanism is a local > decision versus the BGP convergence that > is more global. As a result, even with > more time this two mechanisms may come > with different outcomes. One such > example to illustrate my purpose could > be the following. Note that this is only > illustrative of my purpose, and I let > you find and pick on ethat is more > appropriated. I am thinking of a case > where a standby PE is be shared among > multiple PEs - supposing this situation > could occur. Typically, if PE_1, PE_2 > are shared by PE_a, ..., PE_z. In case > PE_a and PE_b are down, we expect PE_a > to switch to PE_1 and PE_b to switch to > PE_2. It seems to me that BGP would end > up in such situation while a local > decision may end up in PE_a and PE_a to > switch to PE_1. > > > > GIM>> Thank you for the scenario that is very common in deploying > protection based on the shared redundant resources. Such schemes, referred > to as M:N protection, in addition to using mechanism detecting a network > failure, e.g., BFD, require a protocol to coordinate the switchover. This > specification applies to a more special deployment scenario where one > working PE is protected by one or more standby PEs, i.e., 1:N protection. > > > I understand the document is addressing a 1:N scenario. That said, if M:N > scenario leverage from 1:N protection it seems to me worth raising the > issue. > > > --00000000000045a2b805b3ee8faf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Daniel,
thank you for the additional information. I= understand your concerns=C2=A0and agree that it is helpful to provide impl= ementors and operators with useful information about the potential impact t= he new functionality may demonstrate in the network and how to mitigate the= risks. I believe it is important to recognize that this draft proposes mec= hanisms that expedite the failure detection in a P-tunnel from the perspect= ive of a downstream PE. And the detection directly impacts the control plan= e, not the data plane. I believe that it is difficult to make any assumptio= ns on how the convergence in the control plane may impact the forwarding pl= ane and what effect that will have on a multicast flow. I think that very m= uch depends on the implementation and the HW capabilities of the platform u= sed. I've moved=C2=A0the new text from Section 3.1 into the Security Co= nsiderations section. Please let me know if you think that is a more approp= riate place for that paragraph.
Also, I've realized that the = text I've proposed earlier that refers to 1:N and N:M protection might = be the source of questions and arguments and would like to withdraw it. I h= ope you'll agree.

I've attached the new di= ff reflecting the changes in the working version.

= Regards,
Greg


On Thu, Nov 12, 2020 at 9:02 AM= Daniel Migault <daniel.m= igault@ericsson.com> wrote:
Hi Greg,=C2=A0

Thanks for the response Greg. This seems to go in the right direction, but = I think it would be nice to detail a bit on the negative impact that may re= sult from the fast-fail over.=C2=A0

"""
unnecessary failover=C2=A0negatively impacting the multicast service
"""

I apology to appear being maybe a bit picky, but, at least to me, the securi= ty consideration section is the place to point on specific impacts that an = operator may not have thought of and the text appears to me a bit too vague= on what can impact negatively the multicast service.=C2=A0

Let me dig a bit on what I mean and probably what information I would have exp= ected to find. Maybe that would have been useful I provided those earlier.= =C2=A0Again, not being an expert in this area, please take my following recommendations= with a pitch of salt.=C2=A0

What I would like, for example, to understand is whether having a fast-fail= over between nodes that work properly results in a packet lost or not.=C2= =A0
I also envision that in some cases, this will result in packet re-ordering = which might result in packet being rejected by the end node.=C2=A0
In IPsec vpns, we have specific counters, keys that make fail-over relative= ly complex as a context has to be maintained between the old and the new no= de to pass anti replay protection and enable appropriated encryption/decryp= tion. It would be good to clarify if any parameters need - or not - to be synchronized between the two nodes= as its transfer represents a risk of disrupting the traffic, and thus may = be mentioned.=C2=A0
There probably other points I am missing due to my lack of expertise - espe= cially those due to operational practices.=C2=A0
I believe that any information that you could think of that would encourage= you to double check/validate a network outage is present over performing t= he fast failover might be useful information.=C2=A0 =C2=A0=C2=A0
Similarly, it would be good to mention cases where an operator may choose n= ot to deploy such mechanism.

Yours,=C2=A0
Daniel

From= : Greg Mirsky <gregimirsky@gmail.com>
Sent: Thursday, November 12, 2020 10:47 AM
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: secdir@ietf= .org <secdir@ie= tf.org>; BESS <bess@ietf.org>; last-call@ietf.org <last-call@ietf.org>; draft-ietf-bess-mvpn-fas= t-failover.all@ietf.org <draft-ietf-bess-mvpn-fast-failove= r.all@ietf.org>
Subject: Re: Secdir last call review of draft-ietf-bess-mvpn-fast-fa= ilover-11
=C2=A0
Hi Daniel,
thank you for your kind consideration of my notes. I've top-copied= what appeared to me as the remaining open issues. I hope I've not=C2= =A0missed=C2=A0any of your questions. Please find my notes in-line below ta= gged GIM>>. Attached are the updated working version and the new diff.

Regards,
Greg

<mglt>
sure. If you know the network is down, then fast fail-over is definitively = a plus. What I think could be useful is to evaluate the cost associated to = a fast-fail-over without any network failure.=C2=A0 This would be useful fo= r an operator to evaluate whether it should spend more time in diagnosing a network failure versus performing a= fast-fail-over.
Typically, if a fast failover comes a no cost at all, one operator would ma= ybe use one exchange to test the liveness of a node rather than 3. =C2=A0 = =C2=A0 =C2=A0

At that point, it seems to me that additional text coudl be added to charac= terize the impact. These could be high level and indicative, but it seems t= o me that knowing these impacts presents some value to the operators. =C2= =A0 =C2=A0 =C2=A0
</mglt>
GIM>> I would like to add a new paragraph in Section 3.1:
NEW TEXT:
=C2=A0 =C2=A0All methods described in this section may produce false-n= egative
=C2=A0 =C2=A0state changes that can be the trigger for an unnecessary failo= ver
=C2=A0 =C2=A0negatively impacting the multicast service provided by the VPN= .=C2=A0 An
=C2=A0 =C2=A0operator expected to consider the network environment and use<= br> =C2=A0 =C2=A0available controls of the mechanism used to determine the stat= us of a
=C2=A0 =C2=A0P-tunnel.

Would the new text be helpful?

<mglt>
Thanks for the feed back, It seems to me important to mention it is not rec= ommended these two mechanism co-exist.
How to avoid false negative transition might be out of scope of the draft I= agree, but it seems to me worth being mentioned especially in relation to = the impacts associated to a fail-over.=C2=A0 In case the fast-failover come= s with no impact this becomes less of a problem for operator deploying it.
=C2=A0
</mglt>
GIM>> I hope that the new text presented above addresses this co= ncern.

<mglt>
I understand the document is addressing a 1:N scenario. That said, if M:N s= cenario leverage from 1:N protection it seems to me worth raising the issue= .
</mglt>
GIM>> I propose adding the clarification of the use of the Sandb= y PE in Section 4:
OLD TEXT:
=C2=A0 =C2=A0The procedures described below are limited to the case wh= ere the site
=C2=A0 =C2=A0that contains C-S is connected to two or more PEs, though, to<= br> =C2=A0 =C2=A0simplify the description, the case of dual-homing is described= .
NEW TEXT:
=C2=A0 =C2=A0The procedures described below are limited to the case wh= ere the site
=C2=A0 =C2=A0that contains C-S is connected to two or more PEs, though, to<= br> =C2=A0 =C2=A0simplify the description, the case of dual-homing is described= .=C2=A0 Such
=C2=A0 =C2=A0a redundancy protection scheme, referred to as 1:N protection,= is the
=C2=A0 =C2=A0special case of M:N protection, where M working instances are = sharing
=C2=A0 =C2=A0protection of the N standby instances.=C2=A0 In addition to a = network
=C2=A0 =C2=A0failure detection mechanism, the latter scheme requires using = a
=C2=A0 =C2=A0mechanism to coordinate the failover among working instances.= =C2=A0 For
=C2=A0 =C2=A0that reason, M:N protection is outside the scope of this
=C2=A0 =C2=A0specification.=C2=A0

On Wed, Nov 11, 2020 at 8:48 AM Daniel Migault <daniel.migault@er= icsson.com> wrote:
Hi Greg,=C2=A0

Thanks for the response and clarifications. Most of my comments have been a= ddressed/answered. However, it seems to me that some additional text might = be added to the security consideration section document the impact on the n= etwork of a fast-failover operation. The knowledge of these impact might be useful for an operator to determine= when the trigger can be done.=C2=A0

Please see more comments inline.=C2=A0

Yours,=C2=A0
Daniel=C2=A0

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Tuesday, November 10, 2020 9:13 PM
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: secdir@ietf= .org <secdir@ie= tf.org>; BESS <bess@ietf.org>; last-call@ietf.org<= /a> <last-call@i= etf.org>; draft-ietf-bess-mvpn-fast-failover.all@ietf.org <draft-iet= f-bess-mvpn-fast-failover.all@ietf.org>
Subject: Re: Secdir last call review of draft-ietf-bess-mvpn-fast-fa= ilover-11
=C2=A0
Hi Daniel,
many thanks for the review, thoughtful comments, and questions, all ar= e much appreciated. Also, my apologies for the long delay to respond to you= r comments. Please find my answers and notes in-line below tagged by GIM>= ;>. Attached are the new working version and the diff to -12.

Regards,
Greg

On Fri, Oct 23, 2020 at 5:36 AM Daniel Migault via Datatra= cker <noreply@ietf= .org> wrote:
Reviewer: Daniel Migault
Review result: Has Nits

Hi,


I reviewed this document as part of the Security Directorate's ongoing = effort to
review all IETF documents being processed by the IESG.=C2=A0 These comments= were
written primarily for the benefit of the Security Area Directors.=C2=A0 Doc= ument
authors, document editors, and WG chairs should treat these comments just l= ike
any other IETF Last Call comments.=C2=A0 Please note also that my expertise= in BGP is
limited, so feel free to take these comments with a pitch of salt.=C2=A0
Review Results: Has Nits

Please find my comments below.

Yours,
Daniel


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Multicast VP= N Fast Upstream Failover
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-be= ss-mvpn-fast-failover-11

Abstract

=C2=A0 =C2=A0This document defines multicast VPN extensions and procedures = that
=C2=A0 =C2=A0allow fast failover for upstream failures, by allowing downstr= eam PEs
=C2=A0 =C2=A0to take into account the status of Provider-Tunnels (P-tunnels= ) when
=C2=A0 =C2=A0selecting the Upstream PE for a VPN multicast flow, and extend= ing BGP
=C2=A0 =C2=A0MVPN routing so that a C-multicast route can be advertised tow= ard a
=C2=A0 =C2=A0Standby Upstream PE.

<mglt>
Though it might be just a nit, if MVPN
designates multicast VPN, it might be
clarifying to specify the acronym in the
first sentence. This would later make
the correlation with BGP MVPN clearer.

</mglt>
GIM>> I've updated s/BGP MVPN/BGP multicast VPN/. Also, s/mV= PN/MVPN/ throughout the document.


1.=C2=A0 Introduction

=C2=A0 =C2=A0In the context of multicast in BGP/MPLS VPNs, it is desirable = to
=C2=A0 =C2=A0provide mechanisms allowing fast recovery of connectivity on =C2=A0 =C2=A0different types of failures.=C2=A0 This document addresses fai= lures of
=C2=A0 =C2=A0elements in the provider network that are upstream of PEs conn= ected
=C2=A0 =C2=A0to VPN sites with receivers.

<mglt>
Well I am not familiar with neither BGP
nor MPLS. It seems that BGP/MLPS IP VPNS
and MPLS/BGP IP VPNs are both used. I am
wondering if there is a distinction
between the two and a preferred way to
designate these VPNs.=C2=A0 My understanding
is that the VPN-IPv4 characterizes the
VPN while MPLS is used by the backbone
for the transport.=C2=A0 Since the PE are
connected to the backbone the VPN-IPv4
needs to be labeled.

</mglt>
GIM>> I understand that this document often sends the reader to = check RFC 6513 and/or RFC 6514. BGP/MPLS MVPN identifies the case of provid= ing a multicast service over an IP VPN that is overlayed=C2=A0on the MPLS d= ata plane using the BGP control plane.

=C2=A0 =C2=A0Section 3 describes local procedures allowing an egress PE (a = PE
=C2=A0 =C2=A0connected to a receiver site) to take into account the status = of
=C2=A0 =C2=A0P-tunnels to determine the Upstream Multicast Hop (UMH) for a = given
=C2=A0 =C2=A0(C-S, C-G).=C2=A0 This method does not provide a "fast fa= ilover" solution
<mglt>
I understand the limitation is due to
BGP convergence.

</mglt>
GIM>> Yes, a dynamic routing protocol, BGP in this case, provide= s the service restoration functionality but the restoration time is signifi= cant and affects the experience of a client.

=C2=A0 =C2=A0when used alone, but can be used together with the mechanism =C2=A0 =C2=A0described in Section 4 for a "fast failover" solutio= n.

=C2=A0 =C2=A0Section 4 describes protocol extensions that can speed up fail= over by
=C2=A0 =C2=A0not requiring any multicast VPN routing message exchange at re= covery
=C2=A0 =C2=A0time.

=C2=A0 =C2=A0Moreover, section 5 describes a "hot leaf standby" m= echanism, that
=C2=A0 =C2=A0uses a combination of these two mechanisms.=C2=A0 This approac= h has
=C2=A0 =C2=A0similarities with the solution described in [RFC7431] to impro= ve
=C2=A0 =C2=A0failover times when PIM routing is used in a network given som= e
=C2=A0 =C2=A0topology and metric constraints.


[...]

3.1.1.=C2=A0 mVPN Tunnel Root Tracking

=C2=A0 =C2=A0A condition to consider that the status of a P-tunnel is up is= that
=C2=A0 =C2=A0the root of the tunnel, as determined in the x-PMSI Tunnel att= ribute,
=C2=A0 =C2=A0is reachable through unicast routing tables.=C2=A0 In this cas= e, the
=C2=A0 =C2=A0downstream PE can immediately update its UMH when the reachabi= lity
=C2=A0 =C2=A0condition changes.

=C2=A0 =C2=A0That is similar to BGP next-hop tracking for VPN routes, excep= t that
=C2=A0 =C2=A0the address considered is not the BGP next-hop address, but th= e root
=C2=A0 =C2=A0address in the x-PMSI Tunnel attribute.

=C2=A0 =C2=A0If BGP next-hop tracking is done for VPN routes and the root a= ddress
=C2=A0 =C2=A0of a given tunnel happens to be the same as the next-hop addre= ss in
=C2=A0 =C2=A0the BGP A-D Route advertising the tunnel, then checking, in un= icast
=C2=A0 =C2=A0routing tables, whether the tunnel root is reachable, will be<= br> =C2=A0 =C2=A0unnecessary duplication and thus will not bring any specific b= enefit.

<mglt>
It seems to me that x-PMSI address
designates a different interface than
the one used by the Tunnel itself. If
that is correct, such mechanisms seems
to assume that one equipment up on one
interface will be up on the other
interfaces. I have the impression that a
configuration change in a PE may end up
in the P-tunnel being down, while the PE
still being reachable though the x-PMSI
Tunnel attribute. If that is a possible
scenario, the current mechanisms may not
provide more efficient mechanism than
then those of the standard BGP.
GIM>> That is a very interesting angle, thank you. Yes, in OAM, = and in the Fault Management (FM) OAM in particular, we have to make some as= sumptions=C2=A0about the state of the remote system based on a single event= or change of state. Usually, AFAIK, operators use not a physical interface but a loopback to associate with a tunnel. Wi= th a fast IGP convergence, a loopback interface is reachable as long as the= re's a path through the network between two nodes.
<mglt>
Thanks for the clarification
</mglt>

Similarly, it is assumed the tunnel is
either up or down and the determination
of not being up if being down.=C2=A0 I am not
convinced that the two only states.
Typically services under DDoS may be
down for a small amount of time. While
this affects the network, there is not
always a clear cut between the PE being
up or down.
</mglt>
GIM>>=C2=A0 In defect detection a system often has some hysteres= is, i.e., time that the system has to wait to change its state. For example= , BFD changes state from Up to Down after the system does not receive N con= secutive packets (usually 3). As a result, in some cases, the system can be tuned to detect relatively short outages = while in others be slower and miss short-lived outages.


[...]

3.1.6.=C2=A0 BFD Discriminator Attribute

=C2=A0 =C2=A0P-tunnel status may be derived from the status of a multipoint= BFD
=C2=A0 =C2=A0session [RFC8562] whose discriminator is advertised along with= an
=C2=A0 =C2=A0x-PMSI A-D Route.

=C2=A0 =C2=A0This document defines the format and ways of using a new BGP =C2=A0 =C2=A0attribute called the "BFD Discriminator".=C2=A0 It i= s an optional
=C2=A0 =C2=A0transitive BGP attribute.=C2=A0 In Section 7.2, IANA is reques= ted to
=C2=A0 =C2=A0allocate the codepoint value (TBA2).=C2=A0 The format of this = attribute is
=C2=A0 =C2=A0shown in Figure 1.

<mglt>
I feel that the sentence "In Section ...
TBA2)." should be removed.

</mglt>
GIM>> We use this to mark where to note the allocated value. Usu= ally, this text is replaced by the RFC Editor to read=C2=A0
In Section 7.2 IANA allocated codepoint XXX.



=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A03
=C2=A0 =C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1
=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 BFD Mode=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Reserved=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=A0BFD Discriminator=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=A0Optional TLVs=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 Figure 1: Format of the BFD Discr= iminator Attribute

=C2=A0 =C2=A0Where:

=C2=A0 =C2=A0 =C2=A0 BFD Mode field is the one octet long.=C2=A0 This speci= fication defines
=C2=A0 =C2=A0 =C2=A0 the P2MP BFD Session as value 1 Section 7.2.

=C2=A0 =C2=A0 =C2=A0 Reserved field is three octets long, and the value MUS= T be zeroed
=C2=A0 =C2=A0 =C2=A0 on transmission and ignored on receipt.

=C2=A0 =C2=A0 =C2=A0 BFD Discriminator field is four octets long.





Morin, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires April = 5, 2021=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page = 7]

Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mVPN Fast Upstream Failover= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 October 2020


=C2=A0 =C2=A0 =C2=A0 Optional TLVs is the optional variable-length field th= at MAY be
=C2=A0 =C2=A0 =C2=A0 used in the BFD Discriminator attribute for future ext= ensions.
=C2=A0 =C2=A0 =C2=A0 TLVs MAY be included in a sequential or nested manner.= =C2=A0 To allow
=C2=A0 =C2=A0 =C2=A0 for TLV nesting, it is advised to define a new TLV as = a variable-
=C2=A0 =C2=A0 =C2=A0 length object.=C2=A0 Figure 2 presents the Optional TL= V format TLV that
=C2=A0 =C2=A0 =C2=A0 consists of:

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 one octet-long field of TLV 's Type value = (Section 7.3)

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 one octet-long field of the length of the Valu= e field in octets

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 variable length Value field.

=C2=A0 =C2=A0 =C2=A0 The length of a TLV MUST be multiple of four octets. <mglt>
I am wondering why the constraint on the
length is not mentioned in the paragraph
associated to the field - as opposed to
a=C2=A0 separate paragraph.

</mglt>
GIM>> There might be a slight confusion due to the use of Length= and length. Capitalized - the name of the field which value is the length = of the Value field. The last sentence refers to the overall length of a TLV= , including lengths of Type, Length and Value fields.

<mglt>
you are correct that might have confused me.=C2=A0
</mglt>

[..]

8.=C2=A0 Security Considerations

=C2=A0 =C2=A0This document describes procedures based on [RFC6513] and [RFC= 6514]
=C2=A0 =C2=A0and hence shares the security considerations respectively repr= esented
=C2=A0 =C2=A0in these specifications.

=C2=A0 =C2=A0This document uses p2mp BFD, as defined in [RFC8562], which, i= n turn,
=C2=A0 =C2=A0is based on [RFC5880].=C2=A0 Security considerations relevant = to each
=C2=A0 =C2=A0protocol are discussed in the respective protocol specificatio= ns.=C2=A0 An
=C2=A0 =C2=A0implementation that supports this specification MUST use a mec= hanism
=C2=A0 =C2=A0to control the maximum number of p2mp BFD sessions that can be= active
=C2=A0 =C2=A0at the same time.

<mglt>
At a high level view - or at least my
interpretation of it - the document
proposes a mechanism based on BFD to
detect fault in the path.=C2=A0 Upon a fault
detection a fail-over operation is
instructed using BGP. This rocedure is
expected to perform a faster fail-over
than traditional BGP convergence on
maintaining routing tables. Once the
fail over has been performed, BFD is
confirms the new path is "legitimate"
and works.

It seems correct to me that the current
protocol relies on BGP / BFD security.
That said, having BFD authentication
based on MD5 or SHA1 may suggest that
stronger primitives be recommended.
While this does not concerns the current
document, it seems to me that the
information might be relayed to routing
ADs.

What remains unclear to me - and I
assume this might be due to my lake or
expertise in routing area - is the impact
associated to performing a fail-over
both on 1) the data plane and 2) the
standard BGP way to establish routing
tables.

Regarding the data plane, I am wondering
if fail-over results in a lost of
packets for example - I suppose for
example that at least the packets in the
process of being forwarded might be
lost. I believe that providing details
on this may be good.
GIM>> You bring up a very topic for the discussion, thank you. W= ith network failure detection in place, the fail-over can be viewed as the = reaction to a network failure.=C2=A0 If that is the case, then packet loss = experienced by service due to the fail-over is the result of the network failure. Would you agree with that view? A sh= orter failure detection interval=C2=A0and faster fail-over should minimize = the packet loss and, as a result, the negative impact on the service itself= .

<mglt>
sure. If you know the network is down, then fast fail-over is definiti= vely a plus. What I think could be useful is to evaluate the cost associate= d to a fast-fail-over without any network failure.=C2=A0 This would be usef= ul for an operator to evaluate whether it should spend more time in diagnosing a network failure versus performin= g a fast-fail-over.=C2=A0
Typically, if a fast failover comes a no cost at all, one operator wou= ld maybe use one exchange to test the liveness of a node rather than 3.=C2= =A0 =C2=A0 =C2=A0=C2=A0

At that point, it seems to me that additional text coudl be added to c= haracterize the impact. These could be high level and indicative, but it se= ems to me that knowing these impacts presents some value to the operators.= =C2=A0 =C2=A0 =C2=A0=C2=A0
</mglt>

If there are any impacts I would like to
understand also in which cases the
decision to perform a failover operation
may result in more harm than the event
that has been over-interpreted. An
hypothetical scenario could be that the
non reception of a BFD packet is
interpreted as a PE being down while it
may not be correct and the PE might have
been simply under stress. A "too fast" fail-over
may over interpreted it and perform a
fail-over. If such things could happen,
an attacker could leverage a micro event
to perform network operation that are
not negligible. Another way to see that
is that an attacker might not have
direct access to the control plan, but
could use the data plan to generate a
stress and sort of control the fail
over. It seems to me that some text
might be welcome to prevent such cases
to happen. This could be guidance for
declaring a tunnel down for example.
GIM>> I agree with your scenario. Over-short detection interval = may produce a false-negative transition to the Down state in BFD and thus t= riggering the fail-over. I think that that is more an operational issue, so= mething that an operator will consider when deploying the mechanism specified in this draft. Resulting from addre= ssing RtgDir review the draft was updated to provide more guidance:
=C2=A0 =C2=A0In many cases, it is not practical to use both protection=
=C2=A0 =C2=A0methods at the same time because uncorrelated timers might cau= se
=C2=A0 =C2=A0unnecessary switchovers and destabilize the network.
<mglt>
Thanks for the feed back, It seems to me important to mention it is no= t recommended these two mechanism co-exist.=C2=A0
How to avoid false negative transition might be out of scope of the dr= aft I agree, but it seems to me worth being mentioned especially in relatio= n to the impacts associated to a fail-over.=C2=A0 In case the fast-failover= comes with no impact this becomes less of a problem for operator deploying it.
=C2=A0
</mglt>
Though the text above might not be general, I think that it also appli= es to the scenario you've presented.

Similarly, it would be good to add some
text regarding the interferences with
the non-fast forwarding fail over when
performed by the standard BGP.
Typically, my impression is that the
fast fail-over mechanism is a local
decision versus the BGP convergence that
is more global. As a result, even with
more time this two mechanisms may come
with different outcomes. One such
example to illustrate my purpose could
be the following. Note that this is only
illustrative of my purpose, and I let
you find and pick on ethat is more
appropriated.=C2=A0 =C2=A0I am thinking of a case
where a standby PE is be shared among
multiple PEs - supposing this situation
could occur.=C2=A0 Typically, if PE_1, PE_2
are shared by PE_a, ..., PE_z. In case
PE_a and PE_b are down, we expect PE_a
to switch to PE_1 and PE_b to switch to
PE_2. It seems to me that BGP would end
up in such situation while a local
decision may end up in PE_a and PE_a to
switch to PE_1.

</mglt>
GIM>> Thank you for the scenario that is very common in deployin= g protection based on the shared redundant resources. Such schemes, referre= d to as M:N protection, in addition to using mechanism detecting a network = failure, e.g., BFD, require a protocol to coordinate the switchover. This specification applies to a more special= deployment scenario where one working PE is protected by one or more stand= by PEs, i.e., 1:N protection.

<mglt>
I understand the document is addressing a 1:N scenario. That said, if = M:N scenario leverage from 1:N protection it seems to me worth raising the = issue.=C2=A0
</mglt>
--00000000000045a2b805b3ee8faf-- --00000000000045a2ba05b3ee8fb1 Content-Type: text/html; charset="UTF-8"; name="Diff_ draft-ietf-bess-mvpn-fast-failover-12.txt - draft-ietf-bess-mvpn-fast-failover-13.txt.html" Content-Disposition: attachment; filename="Diff_ draft-ietf-bess-mvpn-fast-failover-12.txt - draft-ietf-bess-mvpn-fast-failover-13.txt.html" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_khf9ta7b0 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPgo8IS0tIHNhdmVkIGZyb20gdXJsPSgwMDQyKWh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9y ZmNkaWZmL3JmY2RpZmYucHlodCAtLT4KPGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5 OTkveGh0bWwiPjxoZWFkPjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PVVURi04Ij4gCiAgIAogIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRl bnQtU3R5bGUtVHlwZSIgY29udGVudD0idGV4dC9jc3MiPiAKICA8dGl0bGU+RGlmZjogZHJhZnQt aWV0Zi1iZXNzLW12cG4tZmFzdC1mYWlsb3Zlci0xMi50eHQgLSBkcmFmdC1pZXRmLWJlc3MtbXZw bi1mYXN0LWZhaWxvdmVyLTEzLnR4dDwvdGl0bGU+IAogIDxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+ IAogICAgYm9keSAgICB7IG1hcmdpbjogMC40ZXg7IG1hcmdpbi1yaWdodDogYXV0bzsgfSAKICAg IHRyICAgICAgeyB9IAogICAgdGQgICAgICB7IHdoaXRlLXNwYWNlOiBwcmU7IGZvbnQtZmFtaWx5 OiBtb25vc3BhY2U7IHZlcnRpY2FsLWFsaWduOiB0b3A7IGZvbnQtc2l6ZTogMC44NmVtO30gCiAg ICB0aCAgICAgIHsgZm9udC1zaXplOiAwLjg2ZW07IH0gCiAgICAuc21hbGwgIHsgZm9udC1zaXpl OiAwLjZlbTsgZm9udC1zdHlsZTogaXRhbGljOyBmb250LWZhbWlseTogVmVyZGFuYSwgSGVsdmV0 aWNhLCBzYW5zLXNlcmlmOyB9IAogICAgLmxlZnQgICB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7 IH0gCiAgICAucmlnaHQgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgfSAKICAgIC5kaWZmICAg eyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NGOyB9IAogICAgLmxibG9jayB7IGJhY2tncm91bmQtY29s b3I6ICNCRkI7IH0gCiAgICAucmJsb2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGODsgfSAKICAg IC5pbnNlcnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOEZGOyB9IAogICAgLmRlbGV0ZSB7IGJhY2tn cm91bmQtY29sb3I6ICNBQ0Y7IH0gCiAgICAudm9pZCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZG QjsgfSAKICAgIC5jb250ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxpbmVi ciB7IGJhY2tncm91bmQtY29sb3I6ICNBQUE7IH0gCiAgICAubGluZW5vIHsgY29sb3I6IHJlZDsg YmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgZm9udC1zaXplOiAwLjdlbTsgdGV4dC1hbGlnbjogcmln aHQ7IHBhZGRpbmc6IDAgMnB4OyB9IAogICAgLmVsaXBzaXN7IGJhY2tncm91bmQtY29sb3I6ICNB QUE7IH0gCiAgICAubGVmdCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICNEREQ7IH0gCiAgICAu cmlnaHQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxibG9jayAuY29u dCB7IGJhY2tncm91bmQtY29sb3I6ICM5RDk7IH0gCiAgICAucmJsb2NrIC5jb250IHsgYmFja2dy b3VuZC1jb2xvcjogI0RENjsgfSAKICAgIC5pbnNlcnQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9y OiAjMEREOyB9IAogICAgLmRlbGV0ZSAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICM4QUQ7IH0g CiAgICAuc3RhdHMsIC5zdGF0cyB0ZCwgLnN0YXRzIHRoIHsgYmFja2dyb3VuZC1jb2xvcjogI0VF RTsgcGFkZGluZzogMnB4IDA7IH0gCiAgICBzcGFuLmhpZGUgeyBkaXNwbGF5OiBub25lOyBjb2xv cjogI2FhYTt9ICAgIGE6aG92ZXIgc3BhbiB7IGRpc3BsYXk6IGlubGluZTsgfSAgICB0ci5jaGFu Z2UgeyBiYWNrZ3JvdW5kLWNvbG9yOiBncmF5OyB9IAogICAgdHIuY2hhbmdlIGEgeyB0ZXh0LWRl Y29yYXRpb246IG5vbmU7IGNvbG9yOiBibGFjayB9IAogIDwvc3R5bGU+IAogICAgIDxzY3JpcHQ+ CnZhciBjaHVua19pbmRleCA9IDA7CnZhciBvbGRfY2h1bmsgPSBudWxsOwoKZnVuY3Rpb24gZm9y bWF0X2NodW5rKGluZGV4KSB7CiAgICB2YXIgcHJlZml4ID0gImRpZmYiOwogICAgdmFyIHN0ciA9 IGluZGV4LnRvU3RyaW5nKCk7CiAgICBmb3IgKHg9MDsgeDwoNC1zdHIubGVuZ3RoKTsgKyt4KSB7 CiAgICAgICAgcHJlZml4Kz0nMCc7CiAgICB9CiAgICByZXR1cm4gcHJlZml4ICsgc3RyOwp9Cgpm dW5jdGlvbiBmaW5kX2NodW5rKG4pewogICAgcmV0dXJuIGRvY3VtZW50LnF1ZXJ5U2VsZWN0b3Io J3RyW2lkJD0iJyArIG4gKyAnIl0nKTsKfQoKZnVuY3Rpb24gY2hhbmdlX2NodW5rKG9mZnNldCkg ewogICAgdmFyIGluZGV4ID0gY2h1bmtfaW5kZXggKyBvZmZzZXQ7CiAgICB2YXIgbmV3X3N0cjsK ICAgIHZhciBuZXdfY2h1bms7CgogICAgbmV3X3N0ciA9IGZvcm1hdF9jaHVuayhpbmRleCk7CiAg ICBuZXdfY2h1bmsgPSBmaW5kX2NodW5rKG5ld19zdHIpOwogICAgaWYgKCFuZXdfY2h1bmspIHsK ICAgICAgICByZXR1cm47CiAgICB9CiAgICBpZiAob2xkX2NodW5rKSB7CiAgICAgICAgb2xkX2No dW5rLnN0eWxlLm91dGxpbmUgPSAiIjsKICAgIH0KICAgIG9sZF9jaHVuayA9IG5ld19jaHVuazsK ICAgIG9sZF9jaHVuay5zdHlsZS5vdXRsaW5lID0gIjFweCBzb2xpZCByZWQiOwogICAgd2luZG93 LmxvY2F0aW9uLmhhc2ggPSAiIyIgKyBuZXdfc3RyOwogICAgd2luZG93LnNjcm9sbEJ5KDAsLTEw MCk7CiAgICBjaHVua19pbmRleCA9IGluZGV4Owp9Cgpkb2N1bWVudC5vbmtleWRvd24gPSBmdW5j dGlvbihlKSB7CiAgICBzd2l0Y2ggKGUua2V5Q29kZSkgewogICAgY2FzZSA3ODoKICAgICAgICBj aGFuZ2VfY2h1bmsoMSk7CiAgICAgICAgYnJlYWs7CiAgICBjYXNlIDgwOgogICAgICAgIGNoYW5n ZV9jaHVuaygtMSk7CiAgICAgICAgYnJlYWs7CiAgICB9Cn07CiAgIDwvc2NyaXB0PiAKPC9oZWFk PiAKPGJvZHkgZGF0YS1uZXctZ3ItYy1zLWNoZWNrLWxvYWRlZD0iMTQuOTgzLjAiPiAKICA8dGFi bGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPiAKICA8dGJvZHk+ PHRyIGlkPSJwYXJ0LTEiIGJnY29sb3I9Im9yYW5nZSI+PHRoPjwvdGg+PHRoPjxhIGhyZWY9Imh0 dHBzOi8vd3d3Ni5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1iZXNzLW12cG4tZmFz dC1mYWlsb3Zlci0xMi50eHQiIHN0eWxlPSJjb2xvcjojMDA4OyB0ZXh0LWRlY29yYXRpb246bm9u ZTsiPiZsdDs8L2E+Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtYmVzcy1tdnBuLWZhc3QtZmFpbG92ZXItMTIudHh0IiBzdHlsZT0iY29sb3I6IzAw OCI+ZHJhZnQtaWV0Zi1iZXNzLW12cG4tZmFzdC1mYWlsb3Zlci0xMi50eHQ8L2E+Jm5ic3A7PC90 aD48dGg+IDwvdGg+PHRoPiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWJlc3MtbXZwbi1mYXN0LWZhaWxvdmVyLTEzLnR4dCIgc3R5bGU9ImNvbG9y OiMwMDgiPmRyYWZ0LWlldGYtYmVzcy1tdnBuLWZhc3QtZmFpbG92ZXItMTMudHh0PC9hPiZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi1i ZXNzLW12cG4tZmFzdC1mYWlsb3Zlci0xMy50eHQiIHN0eWxlPSJjb2xvcjojMDA4OyB0ZXh0LWRl Y29yYXRpb246bm9uZTsiPiZndDs8L2E+PC90aD48dGg+PC90aD48L3RyPiAKICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5OZXR3b3JrIFdvcmtp bmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFQuIE1vcmluLCBF ZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5OZXR3b3JrIFdvcmtpbmcgR3JvdXAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFQuIE1vcmluLCBFZC48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9yYW5nZTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIE9yYW5nZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ SW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAg IFIuIEtlYmxlciwgRWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+SW50ZW5kZWQg c3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgIFIuIEtlYmxl ciwgRWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRp ZmYwMDAxIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPkV4cGlyZXM6IE1heSAxPHNwYW4gY2xhc3M9ImRlbGV0ZSI+LCAy MDIxIDwvc3Bhbj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmlwZXIgTmV0 d29ya3M8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+RXhwaXJlczogTWF5IDE8c3Bh biBjbGFzcz0iaW5zZXJ0Ij42LCAyMDIxPC9zcGFuPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgSnVuaXBlciBOZXR3b3JrczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEcu IE1pcnNreSwgRWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEcuIE1pcnNreSwg RWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBaVEUgQ29ycC48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBaVEUgQ29ycC48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDIiPjx0ZD48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzcGFuIGNs YXNzPSJkZWxldGUiPiBPY3RvYmVyIDI4PC9zcGFuPiwgMjAyMDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPHNwYW4gY2xhc3M9Imluc2VydCI+Tm92ZW1iZXIgMTI8L3NwYW4+LCAyMDIw PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgIE11bHRp Y2FzdCBWUE4gRmFzdCBVcHN0cmVhbSBGYWlsb3ZlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgICAgICAgICAgICAgICAgIE11bHRpY2FzdCBWUE4gRmFzdCBVcHN0cmVhbSBGYWls b3ZlcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZm MDAwMyI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtYmVzcy1tdnBuLWZh c3QtZmFpbG92ZXItMTxzcGFuIGNsYXNzPSJkZWxldGUiPjI8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1iZXNzLW12cG4t ZmFzdC1mYWlsb3Zlci0xPHNwYW4gY2xhc3M9Imluc2VydCI+Mzwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+QWJzdHJhY3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij5BYnN0cmFjdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIGRv Y3VtZW50IGRlZmluZXMgbXVsdGljYXN0IFZQTiBleHRlbnNpb25zIGFuZCBwcm9jZWR1cmVzIHRo YXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGRvY3VtZW50IGRlZmlu ZXMgbXVsdGljYXN0IFZQTiBleHRlbnNpb25zIGFuZCBwcm9jZWR1cmVzIHRoYXQ8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFsbG93IGZhc3QgZmFpbG92ZXIgZm9yIHVwc3RyZWFtIGZh aWx1cmVzIGJ5IGFsbG93aW5nIGRvd25zdHJlYW0gUEVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgYWxsb3cgZmFzdCBmYWlsb3ZlciBmb3IgdXBzdHJlYW0gZmFpbHVyZXMgYnkg YWxsb3dpbmcgZG93bnN0cmVhbSBQRXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRv IGNvbnNpZGVyIHRoZSBzdGF0dXMgb2YgUHJvdmlkZXItVHVubmVscyAoUC10dW5uZWxzKSB3aGVu IHNlbGVjdGluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRvIGNvbnNpZGVy IHRoZSBzdGF0dXMgb2YgUHJvdmlkZXItVHVubmVscyAoUC10dW5uZWxzKSB3aGVuIHNlbGVjdGlu ZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIHVwc3RyZWFtIFBFIGZvciBhIFZQ TiBtdWx0aWNhc3QgZmxvdy4gIFRoZSBmYXN0IGZhaWxvdmVyIGlzPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgdGhlIHVwc3RyZWFtIFBFIGZvciBhIFZQTiBtdWx0aWNhc3QgZmxv dy4gIFRoZSBmYXN0IGZhaWxvdmVyIGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBl bmFibGVkIGJ5IHVzaW5nIFJGQyA4NTYyIEJGRCBmb3IgTXVsdGlwb2ludCBOZXR3b3JrcyBhbmQg dGhlIG5ldyBCR1A8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBlbmFibGVkIGJ5 IHVzaW5nIFJGQyA4NTYyIEJGRCBmb3IgTXVsdGlwb2ludCBOZXR3b3JrcyBhbmQgdGhlIG5ldyBC R1A8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEF0dHJpYnV0ZSAtIEJGRCBEaXNjcmlt aW5hdG9yLiAgQWxzbywgdGhlIGRvY3VtZW50IGludHJvZHVjZXMgYSBuZXc8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBdHRyaWJ1dGUgLSBCRkQgRGlzY3JpbWluYXRvci4gIEFs c28sIHRoZSBkb2N1bWVudCBpbnRyb2R1Y2VzIGEgbmV3PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA0Ij48dGQ+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIEJHUCBDb21t dW5pdHksIFN0YW5kYnkgUEUsIGV4dGVuZGluZyBCR1AgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+TVZQ Tjwvc3Bhbj4gcm91dGluZyBzbyB0aGF0IGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgQkdQIENvbW11bml0eSwgU3RhbmRieSBQRSwgZXh0ZW5kaW5nIEJHUCA8c3BhbiBjbGFz cz0iaW5zZXJ0Ij5NdWx0aWNhc3QgVlBOPC9zcGFuPiByb3V0aW5nIHNvPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgIEMtbXVsdGljYXN0IHJvdXRlIGNhbiBiZSBhZHZlcnRpc2VkIHRv d2FyZCBhIFN0YW5kYnkgVXBzdHJlYW0gUEUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgIHRoYXQgYSBDLW11bHRpY2FzdCByb3V0ZSBjYW4gYmUgYWR2ZXJ0aXNlZCB0b3dhcmQg YSBTdGFuZGJ5IFVwc3RyZWFtPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBQRS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+U3RhdHVzIG9mIFRoaXMgTWVtbzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPlN0YXR1cyBvZiBUaGlzIE1lbW88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3 aXRoIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgSW50ZXJuZXQt RHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGU8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5k IEJDUCA3OS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJuZXQtRHJh ZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtp bmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZzwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBz IG1heSBhbHNvIGRpc3RyaWJ1dGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBU YXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJp YnV0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgd29ya2luZyBkb2N1bWVudHMgYXMg SW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC08L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1E cmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgRHJhZnRzIGlzIGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJh ZnRzL2N1cnJlbnQvLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIERyYWZ0cyBp cyBhdCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBk b2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMg dmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3Ro ZXIgZG9jdW1lbnRzIGF0IGFueTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFu ZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVu dHMgYXQgYW55PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aW1lLiAgSXQgaXMgaW5h cHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVz ZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9n cmVzcy4iPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbWF0ZXJpYWwgb3IgdG8g Y2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA1Ij48dGQ+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gTWF5IDEsIDIwMjEuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2ls bCBleHBpcmUgb24gTWF5IDE8c3BhbiBjbGFzcz0iaW5zZXJ0Ij42PC9zcGFuPiwgMjAyMS48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Q29weXJpZ2h0IE5vdGljZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkNvcHlyaWdodCBOb3RpY2U8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgQ29weXJpZ2h0IChjKSAyMDIwIElFVEYgVHJ1c3QgYW5kIHRoZSBw ZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgQ29weXJpZ2h0IChjKSAyMDIwIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZp ZWQgYXMgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkb2N1bWVudCBhdXRob3Jz LiAgQWxsIHJpZ2h0cyByZXNlcnZlZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBh bmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0 J3MgTGVnYWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFByb3Zpc2lvbnMgUmVsYXRp bmcgdG8gSUVURiBEb2N1bWVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQ cm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAoaHR0cHM6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZm ZWN0IG9uIHRoZSBkYXRlIG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKGh0 dHBzOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0 ZSBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcHVibGljYXRpb24gb2YgdGhpcyBk b2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSBy ZXZpZXcgdGhlc2UgZG9jdW1lbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0ciBpZD0icGFydC0yIiBjbGFzcz0iY2hhbmdlIj48dGQ+PC90ZD48dGg+PHNt YWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3c2Lmll dGYub3JnL3JmY2RpZmYvcmZjZGlmZi5weWh0I3BhcnQtMiI+PGVtPiBwYWdlIDIsIGxpbmUgMjA8 c3BhbiBjbGFzcz0iaGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48 c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dzYu aWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC0yIj48ZW0+IHBhZ2UgMiwgbGluZSAy MTxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PlRhYmxlIG9mIENvbnRlbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+VGFibGUg b2YgQ29udGVudHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMS4gIEludHJv ZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICAzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgMS4gIEludHJvZHVjdGlvbiAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAyLiAgQ29udmVudGlvbnMgdXNlZCBpbiB0aGlzIGRv Y3VtZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDM8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAyLiAgQ29udmVudGlvbnMgdXNlZCBpbiB0aGlzIGRvY3VtZW50IC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgMi4xLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgMzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgMi4x LiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAgMzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAyLjIuICBUZXJtaW5vbG9n eSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAyLjIuICBUZXJtaW5vbG9neSAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgIDIuMy4gIEFjcm9ueW1zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgIDIuMy4gIEFjcm9ueW1zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgIDQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDMuICBV TUggU2VsZWN0aW9uIEJhc2VkIG9uIFR1bm5lbCBTdGF0dXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAgNTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDMuICBVTUggU2VsZWN0 aW9uIEJhc2VkIG9uIFR1bm5lbCBTdGF0dXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAzLjEuICBEZXRlcm1pbmluZyB0aGUgU3Rh dHVzIG9mIGEgVHVubmVsICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAzLjEuICBEZXRlcm1pbmluZyB0aGUgU3RhdHVzIG9mIGEg VHVubmVsICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA2Ij48dGQ+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAzLjEu MS4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPm08L3NwYW4+VlBOIFR1bm5lbCBSb290IFRyYWNraW5n IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDY8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgICAgIDMuMS4xLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+TTwvc3Bhbj5WUE4g VHVubmVsIFJvb3QgVHJhY2tpbmcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIDMuMS4yLiAgUEUtUCBVcHN0cmVhbSBMaW5r IFN0YXR1cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgIDMuMS4yLiAgUEUtUCBVcHN0cmVhbSBMaW5rIFN0YXR1cyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgICAgMy4xLjMuICBQMk1QIFJTVlAtVEUgVHVubmVscyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgIDc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAg My4xLjMuICBQMk1QIFJTVlAtVEUgVHVubmVscyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgIDc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAzLjEuNC4gIExlYWYt aW5pdGlhdGVkIFAtdHVubmVscyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgODwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAzLjEuNC4gIExlYWYtaW5pdGlhdGVk IFAtdHVubmVscyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgODwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgICAgIDMuMS41LiAgKEMtUywgQy1HKSBDb3VudGVyIEluZm9ybWF0 aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgIDMuMS41LiAgKEMtUywgQy1HKSBDb3VudGVyIEluZm9ybWF0aW9uICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gICA4PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAg My4xLjYuICBCRkQgRGlzY3JpbWluYXRvciBBdHRyaWJ1dGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgIDg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgMy4xLjYuICBC RkQgRGlzY3JpbWluYXRvciBBdHRyaWJ1dGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDg8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAzLjEuNy4gIFBlciBQRS1DRSBMaW5r IEJGRCBEaXNjcmltaW5hdG9yICAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAzLjEuNy4gIFBlciBQRS1DRSBMaW5rIEJGRCBEaXNj cmltaW5hdG9yICAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgNC4gIFN0YW5kYnkgQy1tdWx0aWNhc3QgUm91dGUgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDEyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg NC4gIFN0YW5kYnkgQy1tdWx0aWNhc3QgUm91dGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDEyPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDQuMS4gIERvd25z dHJlYW0gUEUgQmVoYXZpb3IgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTM8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDQuMS4gIERvd25zdHJlYW0gUEUg QmVoYXZpb3IgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgNC4yLiAgVXBzdHJlYW0gUEUgQmVoYXZpb3IgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgNC4yLiAgVXBzdHJlYW0gUEUgQmVoYXZpb3IgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICA0LjMuICBSZWFjaGFiaWxpdHkgRGV0ZXJtaW5hdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDE1PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICA0LjMuICBS ZWFjaGFiaWxpdHkgRGV0ZXJtaW5hdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDE1PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0i cGFydC0zIiBjbGFzcz0iY2hhbmdlIj48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNo YW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3c2LmlldGYub3JnL3JmY2RpZmYvcmZj ZGlmZi5weWh0I3BhcnQtMyI+PGVtPiBwYWdlIDMsIGxpbmUgMjc8c3BhbiBjbGFzcz0iaGlkZSI+ IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48c21hbGw+c2tpcHBpbmcgdG8g Y2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dzYuaWV0Zi5vcmcvcmZjZGlmZi9y ZmNkaWZmLnB5aHQjcGFydC0zIj48ZW0+IHBhZ2UgMywgbGluZSAyNzxzcGFuIGNsYXNzPSJoaWRl Ij4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjb25uZWN0ZWQgdG8gYSByZWNl aXZlciBzaXRlKSB0byB0YWtlIGludG8gYWNjb3VudCB0aGUgc3RhdHVzIG9mPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY29ubmVjdGVkIHRvIGEgcmVjZWl2ZXIgc2l0ZSkgdG8g dGFrZSBpbnRvIGFjY291bnQgdGhlIHN0YXR1cyBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgUC10dW5uZWxzIHRvIGRldGVybWluZSB0aGUgVXBzdHJlYW0gTXVsdGljYXN0IEhvcCAo VU1IKSBmb3IgYSBnaXZlbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFAtdHVu bmVscyB0byBkZXRlcm1pbmUgdGhlIFVwc3RyZWFtIE11bHRpY2FzdCBIb3AgKFVNSCkgZm9yIGEg Z2l2ZW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIChDLVMsIEMtRykuICBPbmUgb2Yg dGhlIG9wdGlvbmFsIG1ldGhvZHMgdXNlcyBbUkZDODU2Ml0gYW5kIHRoZSBuZXc8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAoQy1TLCBDLUcpLiAgT25lIG9mIHRoZSBvcHRpb25h bCBtZXRob2RzIHVzZXMgW1JGQzg1NjJdIGFuZCB0aGUgbmV3PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBCR1AgQXR0cmlidXRlIC0gQkZEIERpc2NyaW1pbmF0b3IuICBOb25lIG9mIHRo ZXNlIG1ldGhvZHMgcHJvdmlkZSBhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg QkdQIEF0dHJpYnV0ZSAtIEJGRCBEaXNjcmltaW5hdG9yLiAgTm9uZSBvZiB0aGVzZSBtZXRob2Rz IHByb3ZpZGUgYTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgImZhc3QgZmFpbG92ZXIi IHNvbHV0aW9uIHdoZW4gdXNlZCBhbG9uZSwgYnV0IGNhbiBiZSB1c2VkIHRvZ2V0aGVyPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgImZhc3QgZmFpbG92ZXIiIHNvbHV0aW9uIHdo ZW4gdXNlZCBhbG9uZSwgYnV0IGNhbiBiZSB1c2VkIHRvZ2V0aGVyPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICB3aXRoIHRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluIFNlY3Rpb24gNCBm b3IgYSAiZmFzdCBmYWlsb3ZlciI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB3 aXRoIHRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluIFNlY3Rpb24gNCBmb3IgYSAiZmFzdCBmYWls b3ZlciI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNvbHV0aW9uLjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHNvbHV0aW9uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBTZWN0aW9uIDQgZGVzY3JpYmVzIGFuIG9wdGlvbmFsIEJHUCBleHRlbnNp b24sIGEgbmV3IFN0YW5kYnkgUEU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBT ZWN0aW9uIDQgZGVzY3JpYmVzIGFuIG9wdGlvbmFsIEJHUCBleHRlbnNpb24sIGEgbmV3IFN0YW5k YnkgUEU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIENvbW11bml0eS4gdGhhdCBjYW4g c3BlZWQgdXAgZmFpbG92ZXIgYnkgbm90IHJlcXVpcmluZyBhbnkgbXVsdGljYXN0PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQ29tbXVuaXR5LiB0aGF0IGNhbiBzcGVlZCB1cCBm YWlsb3ZlciBieSBub3QgcmVxdWlyaW5nIGFueSBtdWx0aWNhc3Q8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDciPjx0ZD48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgVlBO IHJvdXRpbmcgbWVzc2FnZSBleGNoYW5nZSBhdCByZWNvdmVyeSB0aW1lLjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICBWUE4gPHNwYW4gY2xhc3M9Imluc2VydCI+KE1WUE4pIDwv c3Bhbj5yb3V0aW5nIG1lc3NhZ2UgZXhjaGFuZ2UgYXQgcmVjb3ZlcnkgdGltZS48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgU2VjdGlvbiA1IGRlc2NyaWJlcyBhICJob3QgbGVh ZiBzdGFuZGJ5IiBtZWNoYW5pc20gdGhhdCBjYW4gYmUgdXNlZDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIFNlY3Rpb24gNSBkZXNjcmliZXMgYSAiaG90IGxlYWYgc3RhbmRieSIg bWVjaGFuaXNtIHRoYXQgY2FuIGJlIHVzZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IHRvIGltcHJvdmUgZmFpbG92ZXIgdGltZSBpbiBNVlBOLiAgVGhlIGFwcHJvYWNoIGNvbWJpbmVz IG1lY2hhbmlzbXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0byBpbXByb3Zl IGZhaWxvdmVyIHRpbWUgaW4gTVZQTi4gIFRoZSBhcHByb2FjaCBjb21iaW5lcyBtZWNoYW5pc21z PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkZWZpbmVkIGluIFNlY3Rpb24gMyBhbmQg U2VjdGlvbiA0IGhhcyBzaW1pbGFyaXRpZXMgd2l0aCB0aGUgc29sdXRpb248L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkZWZpbmVkIGluIFNlY3Rpb24gMyBhbmQgU2VjdGlvbiA0 IGhhcyBzaW1pbGFyaXRpZXMgd2l0aCB0aGUgc29sdXRpb248L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIGRlc2NyaWJlZCBpbiBbUkZDNzQzMV0gdG8gaW1wcm92ZSBmYWlsb3ZlciB0aW1l cyB3aGVuIFBJTSByb3V0aW5nIGlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ZGVzY3JpYmVkIGluIFtSRkM3NDMxXSB0byBpbXByb3ZlIGZhaWxvdmVyIHRpbWVzIHdoZW4gUElN IHJvdXRpbmcgaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHVzZWQgaW4gYSBuZXR3 b3JrIGdpdmVuIHNvbWUgdG9wb2xvZ3kgYW5kIG1ldHJpYyBjb25zdHJhaW50cy48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB1c2VkIGluIGEgbmV0d29yayBnaXZlbiBzb21lIHRv cG9sb2d5IGFuZCBtZXRyaWMgY29uc3RyYWludHMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIFRoZSBwcm9jZWR1cmVzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGFyZSBv cHRpb25hbCB0byBlbmFibGUgYW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBU aGUgcHJvY2VkdXJlcyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBhcmUgb3B0aW9uYWwgdG8g ZW5hYmxlIGFuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvcGVyYXRvciB0byBwcm92 aWRlIHByb3RlY3Rpb24gZm9yIG11bHRpY2FzdCBzZXJ2aWNlcyBpbiBCR1AvTVBMUyBJUDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9wZXJhdG9yIHRvIHByb3ZpZGUgcHJvdGVj dGlvbiBmb3IgbXVsdGljYXN0IHNlcnZpY2VzIGluIEJHUC9NUExTIElQPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBWUE5zLiAgQW4gb3BlcmF0b3Igd291bGQgZW5hYmxlIHRoZXNlIG1l Y2hhbmlzbXMgdXNpbmcgYSBtZXRob2Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBWUE5zLiAgQW4gb3BlcmF0b3Igd291bGQgZW5hYmxlIHRoZXNlIG1lY2hhbmlzbXMgdXNpbmcg YSBtZXRob2Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy IGlkPSJwYXJ0LTQiIGNsYXNzPSJjaGFuZ2UiPjx0ZD48L3RkPjx0aD48c21hbGw+c2tpcHBpbmcg dG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dzYuaWV0Zi5vcmcvcmZjZGlm Zi9yZmNkaWZmLnB5aHQjcGFydC00Ij48ZW0+IHBhZ2UgNiwgbGluZSA0NjxzcGFuIGNsYXNzPSJo aWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGlu ZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9yZmNk aWZmL3JmY2RpZmYucHlodCNwYXJ0LTQiPjxlbT4gcGFnZSA2LCBsaW5lIDQ2PHNwYW4gY2xhc3M9 ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIERlcGVuZGluZyBvbiB0 aGUgY3JpdGVyaWEgdXNlZCB0byBkZXRlcm1pbmUgdGhlIHN0YXR1cyBvZiBhIFAtdHVubmVsLDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIERlcGVuZGluZyBvbiB0aGUgY3JpdGVy aWEgdXNlZCB0byBkZXRlcm1pbmUgdGhlIHN0YXR1cyBvZiBhIFAtdHVubmVsLDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlcmUgbWF5IGJlIGFuIGludGVyYWN0aW9uIHdpdGggYW5v dGhlciByZXNpbGllbmN5IG1lY2hhbmlzbSB1c2VkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgdGhlcmUgbWF5IGJlIGFuIGludGVyYWN0aW9uIHdpdGggYW5vdGhlciByZXNpbGll bmN5IG1lY2hhbmlzbSB1c2VkPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBmb3IgdGhl IFAtdHVubmVsIGl0c2VsZiwgYW5kIHRoZSBVTUggdXBkYXRlIG1heSBoYXBwZW4gaW1tZWRpYXRl bHkgb3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBmb3IgdGhlIFAtdHVubmVs IGl0c2VsZiwgYW5kIHRoZSBVTUggdXBkYXRlIG1heSBoYXBwZW4gaW1tZWRpYXRlbHkgb3I8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG1heSBuZWVkIHRvIGJlIGRlbGF5ZWQuICBFYWNo IHBhcnRpY3VsYXIgY2FzZSBpcyBjb3ZlcmVkIGluIGVhY2g8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBtYXkgbmVlZCB0byBiZSBkZWxheWVkLiAgRWFjaCBwYXJ0aWN1bGFyIGNh c2UgaXMgY292ZXJlZCBpbiBlYWNoPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzZXBh cmF0ZSBzdWItc2VjdGlvbiBiZWxvdy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBzZXBhcmF0ZSBzdWItc2VjdGlvbiBiZWxvdy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgQW4gaW1wbGVtZW50YXRpb24gbWF5IHN1cHBvcnQgYW55IGNvbWJpbmF0aW9uIG9m IHRoZSBtZXRob2RzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQW4gaW1wbGVt ZW50YXRpb24gbWF5IHN1cHBvcnQgYW55IGNvbWJpbmF0aW9uIG9mIHRoZSBtZXRob2RzPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkZXNjcmliZWQgaW4gdGhpcyBzZWN0aW9uIGFuZCBw cm92aWRlIGEgbmV0d29yayBvcGVyYXRvciB3aXRoIGNvbnRyb2w8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBkZXNjcmliZWQgaW4gdGhpcyBzZWN0aW9uIGFuZCBwcm92aWRlIGEg bmV0d29yayBvcGVyYXRvciB3aXRoIGNvbnRyb2w8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIHRvIGNob29zZSB3aGljaCBvbmUgdG8gdXNlIGluIHRoZSBwYXJ0aWN1bGFyIGRlcGxveW1l bnQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdG8gY2hvb3NlIHdoaWNoIG9u ZSB0byB1c2UgaW4gdGhlIHBhcnRpY3VsYXIgZGVwbG95bWVudC48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwOCI+PHRkPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4z LjEuMS4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPm08L3NwYW4+VlBOIFR1bm5lbCBSb290IFRyYWNr aW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjMuMS4xLiAgPHNwYW4gY2xhc3M9 Imluc2VydCI+TTwvc3Bhbj5WUE4gVHVubmVsIFJvb3QgVHJhY2tpbmc8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgQSBjb25kaXRpb24gdG8gY29uc2lkZXIgdGhhdCB0aGUgc3Rh dHVzIG9mIGEgUC10dW5uZWwgaXMgVXAgaXMgdGhhdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIEEgY29uZGl0aW9uIHRvIGNvbnNpZGVyIHRoYXQgdGhlIHN0YXR1cyBvZiBhIFAt dHVubmVsIGlzIFVwIGlzIHRoYXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoZSBy b290IG9mIHRoZSB0dW5uZWwsIGFzIGRldGVybWluZWQgaW4gdGhlIHgtUE1TSSBUdW5uZWwgYXR0 cmlidXRlLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZSByb290IG9mIHRo ZSB0dW5uZWwsIGFzIGRldGVybWluZWQgaW4gdGhlIHgtUE1TSSBUdW5uZWwgYXR0cmlidXRlLDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaXMgcmVhY2hhYmxlIHRocm91Z2ggdW5pY2Fz dCByb3V0aW5nIHRhYmxlcy4gIEluIHRoaXMgY2FzZSwgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgaXMgcmVhY2hhYmxlIHRocm91Z2ggdW5pY2FzdCByb3V0aW5nIHRhYmxl cy4gIEluIHRoaXMgY2FzZSwgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkb3du c3RyZWFtIFBFIGNhbiBpbW1lZGlhdGVseSB1cGRhdGUgaXRzIFVNSCB3aGVuIHRoZSByZWFjaGFi aWxpdHk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkb3duc3RyZWFtIFBFIGNh biBpbW1lZGlhdGVseSB1cGRhdGUgaXRzIFVNSCB3aGVuIHRoZSByZWFjaGFiaWxpdHk8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNvbmRpdGlvbiBjaGFuZ2VzLjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNvbmRpdGlvbiBjaGFuZ2VzLjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGF0IGlzIHNpbWlsYXIgdG8gQkdQIG5leHQtaG9wIHRyYWNr aW5nIGZvciBWUE4gcm91dGVzLCBleGNlcHQgdGhhdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIFRoYXQgaXMgc2ltaWxhciB0byBCR1AgbmV4dC1ob3AgdHJhY2tpbmcgZm9yIFZQ TiByb3V0ZXMsIGV4Y2VwdCB0aGF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGUg YWRkcmVzcyBjb25zaWRlcmVkIGlzIG5vdCB0aGUgQkdQIG5leHQtaG9wIGFkZHJlc3MsIGJ1dCB0 aGUgcm9vdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZSBhZGRyZXNzIGNv bnNpZGVyZWQgaXMgbm90IHRoZSBCR1AgbmV4dC1ob3AgYWRkcmVzcywgYnV0IHRoZSByb290PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhZGRyZXNzIGluIHRoZSB4LVBNU0kgVHVubmVs IGF0dHJpYnV0ZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhZGRyZXNzIGlu IHRoZSB4LVBNU0kgVHVubmVsIGF0dHJpYnV0ZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTUiIGNsYXNzPSJjaGFuZ2UiPjx0ZD48L3Rk Pjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczov L3d3dzYuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC01Ij48ZW0+IHBhZ2UgMTIs IGxpbmUgMzA8c3BhbiBjbGFzcz0iaGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8 L3RoPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRw czovL3d3dzYuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC01Ij48ZW0+IHBhZ2Ug MTIsIGxpbmUgMzA8c3BhbiBjbGFzcz0iaGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRk PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgRG93biAocGVyIFNlY3Rpb24gNi44LjE3IFtSRkM1ODgwXSksIHVubGVzcyBpdCBz d2l0Y2hlcyB0byBhIG5ldyBQRS08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBE b3duIChwZXIgU2VjdGlvbiA2LjguMTcgW1JGQzU4ODBdKSwgdW5sZXNzIGl0IHN3aXRjaGVzIHRv IGEgbmV3IFBFLTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ0UgbGluayB3aXRoaW4g dGhlIHRpbWUgb2YgYmZkLkRlc2lyZWRNaW5UeEludGVydmFsIGZvciB0aGUgUDJNUCBCRkQ8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBDRSBsaW5rIHdpdGhpbiB0aGUgdGltZSBv ZiBiZmQuRGVzaXJlZE1pblR4SW50ZXJ2YWwgZm9yIHRoZSBQMk1QIEJGRDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgc2Vzc2lvbiAoaW4gdGhhdCBjYXNlLCB0aGUgVXBzdHJlYW0gUEUg d2lsbCBzdGFydCB0cmFja2luZyB0aGUgc3RhdHVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgc2Vzc2lvbiAoaW4gdGhhdCBjYXNlLCB0aGUgVXBzdHJlYW0gUEUgd2lsbCBzdGFy dCB0cmFja2luZyB0aGUgc3RhdHVzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvZiB0 aGUgbmV3IFBFLUNFIGxpbmspLiAgV2hlbiBhIGRvd25zdHJlYW0gUEUgcmVjZWl2ZXMgdGhhdDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9mIHRoZSBuZXcgUEUtQ0UgbGluayku ICBXaGVuIGEgZG93bnN0cmVhbSBQRSByZWNlaXZlcyB0aGF0PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBiZmQuTG9jYWxEaWFnIGNvZGUsIGl0IHRyZWF0cyBpdCBhcyBpZiB0aGUgdHVu bmVsIGl0c2VsZiBmYWlsZWQgYW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg YmZkLkxvY2FsRGlhZyBjb2RlLCBpdCB0cmVhdHMgaXQgYXMgaWYgdGhlIHR1bm5lbCBpdHNlbGYg ZmFpbGVkIGFuZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdHJpZXMgdG8gc3dpdGNo IHRvIGEgYmFja3VwIFBFLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRyaWVz IHRvIHN3aXRjaCB0byBhIGJhY2t1cCBQRS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+NC4gIFN0YW5kYnkgQy1tdWx0aWNhc3QgUm91dGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij40LiAgU3RhbmRieSBDLW11bHRpY2FzdCBSb3V0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBUaGUgcHJvY2VkdXJlcyBkZXNjcmliZWQgYmVsb3cgYXJlIGxpbWl0 ZWQgdG8gdGhlIGNhc2Ugd2hlcmUgdGhlIHNpdGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBUaGUgcHJvY2VkdXJlcyBkZXNjcmliZWQgYmVsb3cgYXJlIGxpbWl0ZWQgdG8gdGhl IGNhc2Ugd2hlcmUgdGhlIHNpdGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0ciBpZD0iZGlmZjAwMDkiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgdGhhdCBjb250YWlucyBDLVMgaXMg Y29ubmVjdGVkIHRvIHR3byBvciBtb3JlIDxzcGFuIGNsYXNzPSJkZWxldGUiPlBFczwvc3Bhbj4g dGhvdWdoLCB0byBzaW1wbGlmeTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICB0 aGF0IGNvbnRhaW5zIEMtUyBpcyBjb25uZWN0ZWQgdG8gdHdvIG9yIG1vcmUgPHNwYW4gY2xhc3M9 Imluc2VydCI+UEVzLDwvc3Bhbj4gdGhvdWdoLCB0bzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICB0aGUgZGVzY3JpcHRpb24sIHRoZSBjYXNlIG9mIGR1YWwtaG9taW5nIGlzIGRlc2Ny aWJlZC4gIFRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBzaW1wbGlmeSB0 aGUgZGVzY3JpcHRpb24sIHRoZSBjYXNlIG9mIGR1YWwtaG9taW5nIGlzIGRlc2NyaWJlZC4gIFRo ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcHJvY2VkdXJlcyByZXF1aXJlIGFsbCB0 aGUgUEVzIG9mIHRoYXQgTVZQTiB0byBmb2xsb3cgdGhlIHNhbWUgVU1IPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgcHJvY2VkdXJlcyByZXF1aXJlIGFsbCB0aGUgUEVzIG9mIHRo YXQgTVZQTiB0byBmb2xsb3cgdGhlIHNhbWUgVU1IPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBzZWxlY3Rpb24gcHJvY2VkdXJlLCBhcyBzcGVjaWZpZWQgaW4gW1JGQzY1MTNdLCB3aGV0 aGVyIHRoZSBQRTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHNlbGVjdGlvbiBw cm9jZWR1cmUsIGFzIHNwZWNpZmllZCBpbiBbUkZDNjUxM10sIHdoZXRoZXIgdGhlIFBFPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzZWxlY3RlZCBiYXNlZCBvbiBpdHMgSVAgYWRkcmVz cywgaGFzaGluZyBhbGdvcml0aG0gZGVzY3JpYmVkIGluPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgc2VsZWN0ZWQgYmFzZWQgb24gaXRzIElQIGFkZHJlc3MsIGhhc2hpbmcgYWxn b3JpdGhtIGRlc2NyaWJlZCBpbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgc2VjdGlv biA1LjEuMyBvZiBbUkZDNjUxM10sIG9yIEluc3RhbGxlZCBVTUggUm91dGUuICBUaGUgcHJvY2Vk dXJlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHNlY3Rpb24gNS4xLjMgb2Yg W1JGQzY1MTNdLCBvciBJbnN0YWxsZWQgVU1IIFJvdXRlLiAgVGhlIHByb2NlZHVyZXM8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFzc3VtZSB0aGF0IGlmIGEgc2l0ZSBvZiBhIGdpdmVu IE1WUE4gdGhhdCBjb250YWlucyBDLVMgaXMgZHVhbC1ob21lZDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIGFzc3VtZSB0aGF0IGlmIGEgc2l0ZSBvZiBhIGdpdmVuIE1WUE4gdGhh dCBjb250YWlucyBDLVMgaXMgZHVhbC1ob21lZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgdG8gdHdvIFBFcywgdGhlbiBhbGwgdGhlIG90aGVyIHNpdGVzIG9mIHRoYXQgTVZQTiB3b3Vs ZCBoYXZlIHR3bzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRvIHR3byBQRXMs IHRoZW4gYWxsIHRoZSBvdGhlciBzaXRlcyBvZiB0aGF0IE1WUE4gd291bGQgaGF2ZSB0d288L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHVuaWNhc3QgVlBOIHJvdXRlcyAoVlBOLUlQdjQg b3IgVlBOLUlQdjYpIHRvIEMtUywgZWFjaCB3aXRoIGl0cyBSRC48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICB1bmljYXN0IFZQTiByb3V0ZXMgKFZQTi1JUHY0IG9yIFZQTi1JUHY2 KSB0byBDLVMsIGVhY2ggd2l0aCBpdHMgUkQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIEFzIGxvbmcgYXMgQy1TIGlzIHJlYWNoYWJsZSB2aWEgYm90aCBQRXMsIGEgZ2l2ZW4g ZG93bnN0cmVhbSBQRSB3aWxsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQXMg bG9uZyBhcyBDLVMgaXMgcmVhY2hhYmxlIHZpYSBib3RoIFBFcywgYSBnaXZlbiBkb3duc3RyZWFt IFBFIHdpbGw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNlbGVjdCBvbmUgb2YgdGhl IFBFcyBjb25uZWN0ZWQgdG8gQy1TIGFzIGl0cyBVcHN0cmVhbSBQRSBmb3IgQy1TLjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHNlbGVjdCBvbmUgb2YgdGhlIFBFcyBjb25uZWN0 ZWQgdG8gQy1TIGFzIGl0cyBVcHN0cmVhbSBQRSBmb3IgQy1TLjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9InBhcnQtNiIgY2xhc3M9ImNoYW5nZSI+ PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9 Imh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9yZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTYiPjxlbT4g cGFnZSAyMCwgbGluZSA1PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3Ro Pjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJl Zj0iaHR0cHM6Ly93d3c2LmlldGYub3JnL3JmY2RpZmYvcmZjZGlmZi5weWh0I3BhcnQtNiI+PGVt PiBwYWdlIDE5LCBsaW5lIDUxPHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48 L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIGFuZCBoZW5jZSBzaGFyZXMgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIHJlc3BlY3RpdmVseSByZXByZXNlbnRlZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIGFuZCBoZW5jZSBzaGFyZXMgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHJlc3Bl Y3RpdmVseSByZXByZXNlbnRlZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaW4gdGhl c2Ugc3BlY2lmaWNhdGlvbnMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaW4g dGhlc2Ugc3BlY2lmaWNhdGlvbnMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IFRoaXMgZG9jdW1lbnQgdXNlcyBQMk1QIEJGRCwgYXMgZGVmaW5lZCBpbiBbUkZDODU2Ml0sIHdo aWNoLCBpbiB0dXJuLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgZG9j dW1lbnQgdXNlcyBQMk1QIEJGRCwgYXMgZGVmaW5lZCBpbiBbUkZDODU2Ml0sIHdoaWNoLCBpbiB0 dXJuLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaXMgYmFzZWQgb24gW1JGQzU4ODBd LiAgU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgcmVsZXZhbnQgdG8gZWFjaDwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIGlzIGJhc2VkIG9uIFtSRkM1ODgwXS4gIFNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIHJlbGV2YW50IHRvIGVhY2g8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIHByb3RvY29sIGFyZSBkaXNjdXNzZWQgaW4gdGhlIHJlc3BlY3RpdmUgcHJvdG9jb2wgc3Bl Y2lmaWNhdGlvbnMuICBBbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHByb3Rv Y29sIGFyZSBkaXNjdXNzZWQgaW4gdGhlIHJlc3BlY3RpdmUgcHJvdG9jb2wgc3BlY2lmaWNhdGlv bnMuICBBbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaW1wbGVtZW50YXRpb24gdGhh dCBzdXBwb3J0cyB0aGlzIHNwZWNpZmljYXRpb24gTVVTVCB1c2UgYSBtZWNoYW5pc208L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbXBsZW1lbnRhdGlvbiB0aGF0IHN1cHBvcnRz IHRoaXMgc3BlY2lmaWNhdGlvbiBNVVNUIHVzZSBhIG1lY2hhbmlzbTwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgdG8gY29udHJvbCB0aGUgbWF4aW11bSBudW1iZXIgb2YgUDJNUCBCRkQg c2Vzc2lvbnMgdGhhdCBjYW4gYmUgYWN0aXZlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgdG8gY29udHJvbCB0aGUgbWF4aW11bSBudW1iZXIgb2YgUDJNUCBCRkQgc2Vzc2lvbnMg dGhhdCBjYW4gYmUgYWN0aXZlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhdCB0aGUg c2FtZSB0aW1lLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGF0IHRoZSBzYW1l IHRpbWUuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBp ZD0iZGlmZjAwMTAiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPlRoZSBtZXRob2RzIGRlc2NyaWJlZCBpbiB0aGlzIHNl Y3Rpb25TZWN0aW9uIDMuMSBtYXkgcHJvZHVjZSBmYWxzZS08L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj bGFzcz0iaW5zZXJ0Ij4gICBuZWdhdGl2ZSBzdGF0ZSBjaGFuZ2VzIHRoYXQgY2FuIGJlIHRoZSB0 cmlnZ2VyIGZvciBhbiB1bm5lY2Vzc2FyeTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl cnQiPiAgIGNvbnZlcmdlbmNlIGluIHRoZSBjb250cm9sIHBsYW5lLCB1bHRpbWF0ZWx5IG5lZ2F0 aXZlbHkgaW1wYWN0aW5nIHRoZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAg IG11bHRpY2FzdCBzZXJ2aWNlIHByb3ZpZGVkIGJ5IHRoZSBWUE4uICBBbiBvcGVyYXRvciBpcyBl eHBlY3RlZCB0bzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGNvbnNpZGVy IHRoZSBuZXR3b3JrIGVudmlyb25tZW50IGFuZCB1c2UgYXZhaWxhYmxlIGNvbnRyb2xzIG9mIHRo ZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIG1lY2hhbmlzbSB1c2VkIHRv IGRldGVybWluZSB0aGUgc3RhdHVzIG9mIGEgUC10dW5uZWwuPC9zcGFuPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+OS4gIEFja25vd2xlZGdtZW50 czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjkuICBBY2tub3dsZWRnbWVudHM8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIGF1dGhvcnMgd2FudCB0byB0aGFu ayBHcmVnIFJlYXVtZSwgRXJpYyBSb3NlbiwgSmVmZnJleSBaaGFuZyw8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgYXV0aG9ycyB3YW50IHRvIHRoYW5rIEdyZWcgUmVhdW1l LCBFcmljIFJvc2VuLCBKZWZmcmV5IFpoYW5nLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgTWFydGluIFZpZ291cmV1eCwgQWRyaWFuIEZhcnJlbCwgYW5kIFpoZW5nIChTYW5keSkgWmhh bmcgZm9yIHRoZWlyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTWFydGluIFZp Z291cmV1eCwgQWRyaWFuIEZhcnJlbCwgYW5kIFpoZW5nIChTYW5keSkgWmhhbmcgZm9yIHRoZWly PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICByZXZpZXdzLCB1c2VmdWwgY29tbWVudHMs IGFuZCBoZWxwZnVsIHN1Z2dlc3Rpb25zLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIHJldmlld3MsIHVzZWZ1bCBjb21tZW50cywgYW5kIGhlbHBmdWwgc3VnZ2VzdGlvbnMuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjEwLiAgQ29udHJpYnV0b3IgQWRkcmVzc2Vz PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+MTAuICBDb250cmlidXRvciBBZGRyZXNz ZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQmVsb3cgaXMgYSBsaXN0IG9m IG90aGVyIGNvbnRyaWJ1dGluZyBhdXRob3JzIGluIGFscGhhYmV0aWNhbCBvcmRlcjo8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBCZWxvdyBpcyBhIGxpc3Qgb2Ygb3RoZXIgY29u dHJpYnV0aW5nIGF1dGhvcnMgaW4gYWxwaGFiZXRpY2FsIG9yZGVyOjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgoKICAgICA8dHI+PHRkPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZD48L3RkPjwvdHI+CiAg ICAgPHRyIGlkPSJlbmQiIGJnY29sb3I9ImdyYXkiPjx0aCBjb2xzcGFuPSI1IiBhbGlnbj0iY2Vu dGVyIj4mbmJzcDtFbmQgb2YgY2hhbmdlcy4gMTAgY2hhbmdlIGJsb2Nrcy4mbmJzcDs8L3RoPjwv dHI+CiAgICAgPHRyIGNsYXNzPSJzdGF0cyI+PHRkPjwvdGQ+PHRoPjxpPjExIGxpbmVzIGNoYW5n ZWQgb3IgZGVsZXRlZDwvaT48L3RoPjx0aD48aT4gPC9pPjwvdGg+PHRoPjxpPjE5IGxpbmVzIGNo YW5nZWQgb3IgYWRkZWQ8L2k+PC90aD48dGQ+PC90ZD48L3RyPgogICAgIDx0cj48dGQgY29sc3Bh bj0iNSIgYWxpZ249ImNlbnRlciIgY2xhc3M9InNtYWxsIj48YnI+VGhpcyBodG1sIGRpZmYgd2Fz IHByb2R1Y2VkIGJ5IHJmY2RpZmYgMS40OC4gVGhlIGxhdGVzdCB2ZXJzaW9uIGlzIGF2YWlsYWJs ZSBmcm9tIDxhIGhyZWY9Imh0dHA6Ly93d3cudG9vbHMuaWV0Zi5vcmcvdG9vbHMvcmZjZGlmZi8i Pmh0dHA6Ly90b29scy5pZXRmLm9yZy90b29scy9yZmNkaWZmLzwvYT4gPC90ZD48L3RyPgogICA8 L3Rib2R5PjwvdGFibGU+CiAgIAogICAKPC9ib2R5PjwvaHRtbD4= --00000000000045a2ba05b3ee8fb1-- From nobody Thu Nov 12 13:33:33 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE293A0997; Thu, 12 Nov 2020 13:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JoDC4zYLLab; Thu, 12 Nov 2020 13:33:23 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750077.outbound.protection.outlook.com [40.107.75.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93D993A0995; Thu, 12 Nov 2020 13:32:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Nd4dnjyMY3iew1WTMfeqsa8V/VFPN/XxW/5HJaoJ4TPZAi3/o1lnZYXm1u0UXu5HnTo5mwE9fy58qFNcCRDlhYm5FXmkfS+pyOPOdE67N0PxLu6KACxHHF/J0rm5EuzhT320hYQJOR02H4NfU9xgcmtn6b7eoC/Gde4sNd+sZj9KGNPEWRpRQESJifCSXDmEPOWFubVyCNByi+H6h3XqmmaXNlIWWXf2nyF6/4hTQJ/x1h106pw8UXyZjh/ONucj1Bw+K2j8N7Sn4CVC9spRwA1gGRWYFcRb8RuQRPzX2kOREjiHFmaFTaEJWtCv+1+fpL3yAlYqblaimR2Tb3aO6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C6+bTMgjLZuMqjUyaaNbN/VYtzn8KAqgVjrUx0aSjJI=; b=IFjaEGIYu0GSaGNTa7qDkhaV3LRWMFqrEs5YSi1UMIH63IKFklu+01VQ/qeb+JuPos4czdNPBzHe/z6tDcp2EO1t8J920I2fnD7QLOcqW+YcQRi+Zfa+GVFRSXJeB53/xAO/ueotU+yDFCcWCSxFpVxhxGD6qwHFuJycKinTy6kjbhI2Nk7FarE9ojPxV4yrt4N+rhwoKwyG3mhhdUYQ4RtEO+KZ5E8y72MKJhvZQV/irynTqPXwM4aLD1NOW1HWOmPtBrElKaFcst+9gHjD+i7cl5Rewht3Z7cdFeQuQzRVnoCY27J9xZFv3Wbldh2gwLX6Ce2GzQewAwAiLjdW4Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C6+bTMgjLZuMqjUyaaNbN/VYtzn8KAqgVjrUx0aSjJI=; b=s02CM7JhLntUpqxoJOhref+dWI8nz4zUm6pquzn7hf1hTszS03h9fiLPca/sPlZR2TdXOq4ojHbtfUnNf8AuaoxVnB75c9+nwKWOm5iK1zzZX82n9I9qwImoABvHFGWXLTx1vE7rbx6KqQkQO5VOx+Ahq9fZclFaRH8WuxU5nGU= Received: from DM6PR15MB2379.namprd15.prod.outlook.com (2603:10b6:5:8a::16) by DM5PR15MB1481.namprd15.prod.outlook.com (2603:10b6:3:ca::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Thu, 12 Nov 2020 21:32:51 +0000 Received: from DM6PR15MB2379.namprd15.prod.outlook.com ([fe80::28b4:8429:419b:15b0]) by DM6PR15MB2379.namprd15.prod.outlook.com ([fe80::28b4:8429:419b:15b0%3]) with mapi id 15.20.3541.025; Thu, 12 Nov 2020 21:32:51 +0000 From: Daniel Migault To: Greg Mirsky CC: "secdir@ietf.org" , BESS , "last-call@ietf.org" , "draft-ietf-bess-mvpn-fast-failover.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-bess-mvpn-fast-failover-11 Thread-Index: AQHWt9C5emGUONFgKUKxrX3Gy2SfzqnDA2lugAGjIICAAAkkm4AAQX+AgAASbnU= Date: Thu, 12 Nov 2020 21:32:51 +0000 Message-ID: References: <160345656094.22100.7057001737682109381@ietfa.amsl.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [96.22.11.129] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e11caf84-0c92-4236-6945-08d887528241 x-ms-traffictypediagnostic: DM5PR15MB1481: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: c0sIjdaSx6IBVpsKgUn+lZISQG1xtAo4J52HNodgjMfDpuOqPAgYjnbgQPiR9n52ucyn9ppyRQ3hkGDPNm62DGEkLiKi4SVce614Kz4vXlcfmJuEHnsaBZ0kBXrZOVGTykuOuzkVoEh1X3r7Qt9ah3awN+8e6RbOFTesTUpYrPLA1Drb6ltv5W0U84vVoZWQpVYY+Mhg88NbiMN1ZczF29FlCLsUtZR1GjXYIiQpaH01vbchPaNZTucjVNLym/irBnxsd+eOZE6mvxMVabhrbMhYbUnhkKApdNHIyj9Iq6D4PcAPScr0Y9cfZf4VyLL5+iw6KMuaD1bcjhHQqFOuUbX+JW6hUbVuqj3PpPK4tiv0XvqqOFVoS6IrHnZFxjQk x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR15MB2379.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(376002)(346002)(366004)(136003)(396003)(7696005)(55016002)(9686003)(478600001)(44832011)(54906003)(91956017)(64756008)(71200400001)(66476007)(316002)(19627405001)(76116006)(30864003)(26005)(66446008)(52536014)(8676002)(6506007)(8936002)(33656002)(83380400001)(5660300002)(2906002)(66574015)(6916009)(86362001)(186003)(53546011)(66946007)(4326008)(66556008)(21314003)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ugcHvIeYgx2yeUCoqYMMNMcaHhLQKN9yBd6IfpTlKXuAhL3lCHW9EbA/sMqWjdoy01fYKfHVhesrrJgM4P4dZF/urhlwVJHmZladglui/3DaW7GG8D0JfugQDPialBwym9dccCuRPVkP3s+VBx/VXY0tomqpnNC0AcBvnBXjPZQEN9u43LN/yw2uFywBi1TcRmKbiGcrwiOpR1B8JZ+8zXhDOVppEK+B5W8ZQnO713shQa/oWpRYCNt7NSAtaF8RWToK4YkQB2fbosQemkug68LkrOtpMAml/7fNZ8nlpufaI2yK4cqyCwtPbNu9bHc9bG+BRT2fIsSEQ6lmhKgbc4m57219UbzEH6ferSQUQbZlMntGQAxARMmgSdZeJ4vP0fZZNAbCtbueRaZcKVpBm2tHPrrvTM1ppzkSvwPMvqgpgV/m4qpZs7RbgLo+U38hkvJ/2rPQ7T5Pr3Wlh1U3TBvVd+C/kzfQJN0BLdTy4kpaKAemopwpOEPkwf++sd5mIxRD3LN4b8OB3uoOJeWFh9GUmuewqlw2AxDusGHCDD0WXBEoIcvda3X+Gv72a8GQioLLco2CT6uHZQ+0E3OXKYYfJ0T8ETo4JvtdUYUqAuU1SwPVDe8I0oF5ANWpgt8+rlk4yImREPMFSmieja7jDw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR15MB2379A3F41D9EDE7A22BC7DBAE3E70DM6PR15MB2379namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR15MB2379.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e11caf84-0c92-4236-6945-08d887528241 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2020 21:32:51.4948 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Jv7kLZ5T2i7Fz09qX9jWcnsNYtDdwPKhjZgQjiLoShXiWb1W6qTKTUqxiTTMxiCF/e8aSsahZ4jj94kPpCbzMLJD8FGyo7EJJKNfPCtR5T4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR15MB1481 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-bess-mvpn-fast-failover-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 21:33:28 -0000 --_000_DM6PR15MB2379A3F41D9EDE7A22BC7DBAE3E70DM6PR15MB2379namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the response and explanation. I am fine with the text you propos= ed and I consider all my concerns being addressed. I am reading your text as implicitly suggesting the following lines of your= response, which seems reasonable. """ it is difficult to make any assumptions on how the convergence in the cont= rol plane may impact the forwarding plane and what effect that will have on= a multicast flow. I think that very much depends on the implementation and= the HW capabilities of the platform used. """ There one additional nit s/sectionSection/Section/ which I think comes fro= m the conversion. Thanks for all your clarifications! Yours, Daniel ________________________________ From: Greg Mirsky Sent: Thursday, November 12, 2020 3:14 PM To: Daniel Migault Cc: secdir@ietf.org ; BESS ; last-call@ietf= .org ; draft-ietf-bess-mvpn-fast-failover.all@ietf.org = Subject: Re: Secdir last call review of draft-ietf-bess-mvpn-fast-failover-= 11 Hi Daniel, thank you for the additional information. I understand your concerns and ag= ree that it is helpful to provide implementors and operators with useful in= formation about the potential impact the new functionality may demonstrate = in the network and how to mitigate the risks. I believe it is important to = recognize that this draft proposes mechanisms that expedite the failure det= ection in a P-tunnel from the perspective of a downstream PE. And the detec= tion directly impacts the control plane, not the data plane. I believe that= it is difficult to make any assumptions on how the convergence in the cont= rol plane may impact the forwarding plane and what effect that will have on= a multicast flow. I think that very much depends on the implementation and= the HW capabilities of the platform used. I've moved the new text from Sec= tion 3.1 into the Security Considerations section. Please let me know if yo= u think that is a more appropriate place for that paragraph. Also, I've realized that the text I've proposed earlier that refers to 1:N = and N:M protection might be the source of questions and arguments and would= like to withdraw it. I hope you'll agree. I've attached the new diff reflecting the changes in the working version. Regards, Greg On Thu, Nov 12, 2020 at 9:02 AM Daniel Migault > wrote: Hi Greg, Thanks for the response Greg. This seems to go in the right direction, but = I think it would be nice to detail a bit on the negative impact that may re= sult from the fast-fail over. """ unnecessary failover negatively impacting the multicast service """ I apology to appear being maybe a bit picky, but, at least to me, the secur= ity consideration section is the place to point on specific impacts that an= operator may not have thought of and the text appears to me a bit too vagu= e on what can impact negatively the multicast service. Let me dig a bit on what I mean and probably what information I would have = expected to find. Maybe that would have been useful I provided those earlie= r. Again, not being an expert in this area, please take my following recomm= endations with a pitch of salt. What I would like, for example, to understand is whether having a fast-fail= over between nodes that work properly results in a packet lost or not. I also envision that in some cases, this will result in packet re-ordering = which might result in packet being rejected by the end node. In IPsec vpns, we have specific counters, keys that make fail-over relative= ly complex as a context has to be maintained between the old and the new no= de to pass anti replay protection and enable appropriated encryption/decryp= tion. It would be good to clarify if any parameters need - or not - to be s= ynchronized between the two nodes as its transfer represents a risk of disr= upting the traffic, and thus may be mentioned. There probably other points I am missing due to my lack of expertise - espe= cially those due to operational practices. I believe that any information that you could think of that would encourage= you to double check/validate a network outage is present over performing t= he fast failover might be useful information. Similarly, it would be good to mention cases where an operator may choose n= ot to deploy such mechanism. Yours, Daniel ________________________________ From: Greg Mirsky > Sent: Thursday, November 12, 2020 10:47 AM To: Daniel Migault > Cc: secdir@ietf.org >; BESS >; last-call@ietf.org<= mailto:last-call@ietf.org> >;= draft-ietf-bess-mvpn-fast-failover.all@ietf.org > Subject: Re: Secdir last call review of draft-ietf-bess-mvpn-fast-failover-= 11 Hi Daniel, thank you for your kind consideration of my notes. I've top-copied what app= eared to me as the remaining open issues. I hope I've not missed any of you= r questions. Please find my notes in-line below tagged GIM>>. Attached are = the updated working version and the new diff. Regards, Greg sure. If you know the network is down, then fast fail-over is definitively = a plus. What I think could be useful is to evaluate the cost associated to = a fast-fail-over without any network failure. This would be useful for an = operator to evaluate whether it should spend more time in diagnosing a netw= ork failure versus performing a fast-fail-over. Typically, if a fast failover comes a no cost at all, one operator would ma= ybe use one exchange to test the liveness of a node rather than 3. At that point, it seems to me that additional text coudl be added to charac= terize the impact. These could be high level and indicative, but it seems t= o me that knowing these impacts presents some value to the operators. GIM>> I would like to add a new paragraph in Section 3.1: NEW TEXT: All methods described in this section may produce false-negative state changes that can be the trigger for an unnecessary failover negatively impacting the multicast service provided by the VPN. An operator expected to consider the network environment and use available controls of the mechanism used to determine the status of a P-tunnel. Would the new text be helpful? Thanks for the feed back, It seems to me important to mention it is not rec= ommended these two mechanism co-exist. How to avoid false negative transition might be out of scope of the draft I= agree, but it seems to me worth being mentioned especially in relation to = the impacts associated to a fail-over. In case the fast-failover comes wit= h no impact this becomes less of a problem for operator deploying it. GIM>> I hope that the new text presented above addresses this concern. I understand the document is addressing a 1:N scenario. That said, if M:N s= cenario leverage from 1:N protection it seems to me worth raising the issue= . GIM>> I propose adding the clarification of the use of the Sandby PE in Sec= tion 4: OLD TEXT: The procedures described below are limited to the case where the site that contains C-S is connected to two or more PEs, though, to simplify the description, the case of dual-homing is described. NEW TEXT: The procedures described below are limited to the case where the site that contains C-S is connected to two or more PEs, though, to simplify the description, the case of dual-homing is described. Such a redundancy protection scheme, referred to as 1:N protection, is the special case of M:N protection, where M working instances are sharing protection of the N standby instances. In addition to a network failure detection mechanism, the latter scheme requires using a mechanism to coordinate the failover among working instances. For that reason, M:N protection is outside the scope of this specification. On Wed, Nov 11, 2020 at 8:48 AM Daniel Migault > wrote: Hi Greg, Thanks for the response and clarifications. Most of my comments have been a= ddressed/answered. However, it seems to me that some additional text might = be added to the security consideration section document the impact on the n= etwork of a fast-failover operation. The knowledge of these impact might be= useful for an operator to determine when the trigger can be done. Please see more comments inline. Yours, Daniel ________________________________ From: Greg Mirsky > Sent: Tuesday, November 10, 2020 9:13 PM To: Daniel Migault > Cc: secdir@ietf.org >; BESS >; last-call@ietf.org<= mailto:last-call@ietf.org> >;= draft-ietf-bess-mvpn-fast-failover.all@ietf.org > Subject: Re: Secdir last call review of draft-ietf-bess-mvpn-fast-failover-= 11 Hi Daniel, many thanks for the review, thoughtful comments, and questions, all are muc= h appreciated. Also, my apologies for the long delay to respond to your com= ments. Please find my answers and notes in-line below tagged by GIM>>. Atta= ched are the new working version and the diff to -12. Regards, Greg On Fri, Oct 23, 2020 at 5:36 AM Daniel Migault via Datatracker > wrote: Reviewer: Daniel Migault Review result: Has Nits Hi, I reviewed this document as part of the Security Directorate's ongoing effo= rt to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors, document editors, and WG chairs should treat these comments just l= ike any other IETF Last Call comments. Please note also that my expertise in B= GP is limited, so feel free to take these comments with a pitch of salt. Review Results: Has Nits Please find my comments below. Yours, Daniel Multicast VPN Fast Upstream Failover draft-ietf-bess-mvpn-fast-failover-11 Abstract This document defines multicast VPN extensions and procedures that allow fast failover for upstream failures, by allowing downstream PEs to take into account the status of Provider-Tunnels (P-tunnels) when selecting the Upstream PE for a VPN multicast flow, and extending BGP MVPN routing so that a C-multicast route can be advertised toward a Standby Upstream PE. Though it might be just a nit, if MVPN designates multicast VPN, it might be clarifying to specify the acronym in the first sentence. This would later make the correlation with BGP MVPN clearer. GIM>> I've updated s/BGP MVPN/BGP multicast VPN/. Also, s/mVPN/MVPN/ throug= hout the document. 1. Introduction In the context of multicast in BGP/MPLS VPNs, it is desirable to provide mechanisms allowing fast recovery of connectivity on different types of failures. This document addresses failures of elements in the provider network that are upstream of PEs connected to VPN sites with receivers. Well I am not familiar with neither BGP nor MPLS. It seems that BGP/MLPS IP VPNS and MPLS/BGP IP VPNs are both used. I am wondering if there is a distinction between the two and a preferred way to designate these VPNs. My understanding is that the VPN-IPv4 characterizes the VPN while MPLS is used by the backbone for the transport. Since the PE are connected to the backbone the VPN-IPv4 needs to be labeled. GIM>> I understand that this document often sends the reader to check RFC 6= 513 and/or RFC 6514. BGP/MPLS MVPN identifies the case of providing a multi= cast service over an IP VPN that is overlayed on the MPLS data plane using = the BGP control plane. Section 3 describes local procedures allowing an egress PE (a PE connected to a receiver site) to take into account the status of P-tunnels to determine the Upstream Multicast Hop (UMH) for a given (C-S, C-G). This method does not provide a "fast failover" solution I understand the limitation is due to BGP convergence. GIM>> Yes, a dynamic routing protocol, BGP in this case, provides the servi= ce restoration functionality but the restoration time is significant and af= fects the experience of a client. when used alone, but can be used together with the mechanism described in Section 4 for a "fast failover" solution. Section 4 describes protocol extensions that can speed up failover by not requiring any multicast VPN routing message exchange at recovery time. Moreover, section 5 describes a "hot leaf standby" mechanism, that uses a combination of these two mechanisms. This approach has similarities with the solution described in [RFC7431] to improve failover times when PIM routing is used in a network given some topology and metric constraints. [...] 3.1.1. mVPN Tunnel Root Tracking A condition to consider that the status of a P-tunnel is up is that the root of the tunnel, as determined in the x-PMSI Tunnel attribute, is reachable through unicast routing tables. In this case, the downstream PE can immediately update its UMH when the reachability condition changes. That is similar to BGP next-hop tracking for VPN routes, except that the address considered is not the BGP next-hop address, but the root address in the x-PMSI Tunnel attribute. If BGP next-hop tracking is done for VPN routes and the root address of a given tunnel happens to be the same as the next-hop address in the BGP A-D Route advertising the tunnel, then checking, in unicast routing tables, whether the tunnel root is reachable, will be unnecessary duplication and thus will not bring any specific benefit. It seems to me that x-PMSI address designates a different interface than the one used by the Tunnel itself. If that is correct, such mechanisms seems to assume that one equipment up on one interface will be up on the other interfaces. I have the impression that a configuration change in a PE may end up in the P-tunnel being down, while the PE still being reachable though the x-PMSI Tunnel attribute. If that is a possible scenario, the current mechanisms may not provide more efficient mechanism than then those of the standard BGP. GIM>> That is a very interesting angle, thank you. Yes, in OAM, and in the = Fault Management (FM) OAM in particular, we have to make some assumptions a= bout the state of the remote system based on a single event or change of st= ate. Usually, AFAIK, operators use not a physical interface but a loopback = to associate with a tunnel. With a fast IGP convergence, a loopback interfa= ce is reachable as long as there's a path through the network between two n= odes. Thanks for the clarification Similarly, it is assumed the tunnel is either up or down and the determination of not being up if being down. I am not convinced that the two only states. Typically services under DDoS may be down for a small amount of time. While this affects the network, there is not always a clear cut between the PE being up or down. GIM>> In defect detection a system often has some hysteresis, i.e., time t= hat the system has to wait to change its state. For example, BFD changes st= ate from Up to Down after the system does not receive N consecutive packets= (usually 3). As a result, in some cases, the system can be tuned to detect= relatively short outages while in others be slower and miss short-lived ou= tages. [...] 3.1.6. BFD Discriminator Attribute P-tunnel status may be derived from the status of a multipoint BFD session [RFC8562] whose discriminator is advertised along with an x-PMSI A-D Route. This document defines the format and ways of using a new BGP attribute called the "BFD Discriminator". It is an optional transitive BGP attribute. In Section 7.2, IANA is requested to allocate the codepoint value (TBA2). The format of this attribute is shown in Figure 1. I feel that the sentence "In Section ... TBA2)." should be removed. GIM>> We use this to mark where to note the allocated value. Usually, this = text is replaced by the RFC Editor to read In Section 7.2 IANA allocated codepoint XXX. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFD Mode | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFD Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Optional TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Format of the BFD Discriminator Attribute Where: BFD Mode field is the one octet long. This specification defines the P2MP BFD Session as value 1 Section 7.2. Reserved field is three octets long, and the value MUST be zeroed on transmission and ignored on receipt. BFD Discriminator field is four octets long. Morin, et al. Expires April 5, 2021 [Page 7] Internet-Draft mVPN Fast Upstream Failover October 2020 Optional TLVs is the optional variable-length field that MAY be used in the BFD Discriminator attribute for future extensions. TLVs MAY be included in a sequential or nested manner. To allow for TLV nesting, it is advised to define a new TLV as a variable- length object. Figure 2 presents the Optional TLV format TLV that consists of: * one octet-long field of TLV 's Type value (Section 7.3) * one octet-long field of the length of the Value field in octets * variable length Value field. The length of a TLV MUST be multiple of four octets. I am wondering why the constraint on the length is not mentioned in the paragraph associated to the field - as opposed to a separate paragraph. GIM>> There might be a slight confusion due to the use of Length and length= . Capitalized - the name of the field which value is the length of the Valu= e field. The last sentence refers to the overall length of a TLV, including= lengths of Type, Length and Value fields. you are correct that might have confused me. [..] 8. Security Considerations This document describes procedures based on [RFC6513] and [RFC6514] and hence shares the security considerations respectively represented in these specifications. This document uses p2mp BFD, as defined in [RFC8562], which, in turn, is based on [RFC5880]. Security considerations relevant to each protocol are discussed in the respective protocol specifications. An implementation that supports this specification MUST use a mechanism to control the maximum number of p2mp BFD sessions that can be active at the same time. At a high level view - or at least my interpretation of it - the document proposes a mechanism based on BFD to detect fault in the path. Upon a fault detection a fail-over operation is instructed using BGP. This rocedure is expected to perform a faster fail-over than traditional BGP convergence on maintaining routing tables. Once the fail over has been performed, BFD is confirms the new path is "legitimate" and works. It seems correct to me that the current protocol relies on BGP / BFD security. That said, having BFD authentication based on MD5 or SHA1 may suggest that stronger primitives be recommended. While this does not concerns the current document, it seems to me that the information might be relayed to routing ADs. What remains unclear to me - and I assume this might be due to my lake or expertise in routing area - is the impact associated to performing a fail-over both on 1) the data plane and 2) the standard BGP way to establish routing tables. Regarding the data plane, I am wondering if fail-over results in a lost of packets for example - I suppose for example that at least the packets in the process of being forwarded might be lost. I believe that providing details on this may be good. GIM>> You bring up a very topic for the discussion, thank you. With network= failure detection in place, the fail-over can be viewed as the reaction to= a network failure. If that is the case, then packet loss experienced by s= ervice due to the fail-over is the result of the network failure. Would you= agree with that view? A shorter failure detection interval and faster fail= -over should minimize the packet loss and, as a result, the negative impact= on the service itself. sure. If you know the network is down, then fast fail-over is definitively = a plus. What I think could be useful is to evaluate the cost associated to = a fast-fail-over without any network failure. This would be useful for an = operator to evaluate whether it should spend more time in diagnosing a netw= ork failure versus performing a fast-fail-over. Typically, if a fast failover comes a no cost at all, one operator would ma= ybe use one exchange to test the liveness of a node rather than 3. At that point, it seems to me that additional text coudl be added to charac= terize the impact. These could be high level and indicative, but it seems t= o me that knowing these impacts presents some value to the operators. If there are any impacts I would like to understand also in which cases the decision to perform a failover operation may result in more harm than the event that has been over-interpreted. An hypothetical scenario could be that the non reception of a BFD packet is interpreted as a PE being down while it may not be correct and the PE might have been simply under stress. A "too fast" fail-over may over interpreted it and perform a fail-over. If such things could happen, an attacker could leverage a micro event to perform network operation that are not negligible. Another way to see that is that an attacker might not have direct access to the control plan, but could use the data plan to generate a stress and sort of control the fail over. It seems to me that some text might be welcome to prevent such cases to happen. This could be guidance for declaring a tunnel down for example. GIM>> I agree with your scenario. Over-short detection interval may produce= a false-negative transition to the Down state in BFD and thus triggering t= he fail-over. I think that that is more an operational issue, something tha= t an operator will consider when deploying the mechanism specified in this = draft. Resulting from addressing RtgDir review the draft was updated to pro= vide more guidance: In many cases, it is not practical to use both protection methods at the same time because uncorrelated timers might cause unnecessary switchovers and destabilize the network. Thanks for the feed back, It seems to me important to mention it is not rec= ommended these two mechanism co-exist. How to avoid false negative transition might be out of scope of the draft I= agree, but it seems to me worth being mentioned especially in relation to = the impacts associated to a fail-over. In case the fast-failover comes wit= h no impact this becomes less of a problem for operator deploying it. Though the text above might not be general, I think that it also applies to= the scenario you've presented. Similarly, it would be good to add some text regarding the interferences with the non-fast forwarding fail over when performed by the standard BGP. Typically, my impression is that the fast fail-over mechanism is a local decision versus the BGP convergence that is more global. As a result, even with more time this two mechanisms may come with different outcomes. One such example to illustrate my purpose could be the following. Note that this is only illustrative of my purpose, and I let you find and pick on ethat is more appropriated. I am thinking of a case where a standby PE is be shared among multiple PEs - supposing this situation could occur. Typically, if PE_1, PE_2 are shared by PE_a, ..., PE_z. In case PE_a and PE_b are down, we expect PE_a to switch to PE_1 and PE_b to switch to PE_2. It seems to me that BGP would end up in such situation while a local decision may end up in PE_a and PE_a to switch to PE_1. GIM>> Thank you for the scenario that is very common in deploying protectio= n based on the shared redundant resources. Such schemes, referred to as M:N= protection, in addition to using mechanism detecting a network failure, e.= g., BFD, require a protocol to coordinate the switchover. This specificatio= n applies to a more special deployment scenario where one working PE is pro= tected by one or more standby PEs, i.e., 1:N protection. I understand the document is addressing a 1:N scenario. That said, if M:N s= cenario leverage from 1:N protection it seems to me worth raising the issue= . --_000_DM6PR15MB2379A3F41D9EDE7A22BC7DBAE3E70DM6PR15MB2379namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks for the response and explanation. I am fine with the text you propos= ed and I consider all my concerns being addressed.

I am reading your text as implicitly suggesting the following lines of your= response, which seems reasonable.   
 
"""
 it is difficult to make any assumptions on how the convergence in the control= plane may impact the forwarding plane and what effect that will have on a = multicast flow. I think that very much depends on the implementation and th= e HW capabilities of the platform used.
"= ;""

There=   one additional nit s/sectionSection/Section/ which I think comes from the conv= ersion. 

Thanks for all your clarifications!

Yours, 
Daniel

From: Greg Mirsky <gregi= mirsky@gmail.com>
Sent: Thursday, November 12, 2020 3:14 PM
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: secdir@ietf.org <secdir@ietf.org>; BESS <bess@ietf.org&= gt;; last-call@ietf.org <last-call@ietf.org>; draft-ietf-bess-mvpn-fa= st-failover.all@ietf.org <draft-ietf-bess-mvpn-fast-failover.all@ietf.or= g>
Subject: Re: Secdir last call review of draft-ietf-bess-mvpn-fast-fa= ilover-11
 
Hi Daniel,
thank you for the additional information. I understand your concerns&n= bsp;and agree that it is helpful to provide implementors and operators with= useful information about the potential impact the new functionality may de= monstrate in the network and how to mitigate the risks. I believe it is important to recognize that this draft proposes= mechanisms that expedite the failure detection in a P-tunnel from the pers= pective of a downstream PE. And the detection directly impacts the control = plane, not the data plane. I believe that it is difficult to make any assumptions on how the convergence in the= control plane may impact the forwarding plane and what effect that will ha= ve on a multicast flow. I think that very much depends on the implementatio= n and the HW capabilities of the platform used. I've moved the new text from Section 3.1 into the Secu= rity Considerations section. Please let me know if you think that is a more= appropriate place for that paragraph.
Also, I've realized that the text I've proposed earlier that refers to= 1:N and N:M protection might be the source of questions and arguments and = would like to withdraw it. I hope you'll agree.

I've attached the new diff reflecting the changes in the working versi= on.

Regards,
Greg


On Thu, Nov 12, 2020 at 9:02 AM Dan= iel Migault <daniel.migau= lt@ericsson.com> wrote:
Hi Greg, 

Thanks for the response Greg. This seems to go in the right direction, but = I think it would be nice to detail a bit on the negative impact that may re= sult from the fast-fail over. 

"""
unnecessary failover negatively impacting the multicast service
"""

I apology to appear being maybe a b= it picky, but, at least to me, the security consideration section is the pl= ace to point on specific impacts that an operator may not have thought of and the text appears to me a bit too v= ague on what can impact negatively the multicast service. 

Let me dig a bit on what I mean and= probably what information I would have expected to find. Maybe that would = have been useful I provided those earlier. Again, not being an expert in t= his area, please take my following recommendations with a pitch of salt.&nb= sp;

What I would like, for example, to understand is whether having a fast-fail= over between nodes that work properly results in a packet lost or not. = ;
I also envision that in some cases, this will result in packet re-ordering = which might result in packet being rejected by the end node. 
In IPsec vpns, we have specific counters, keys that make fail-over relative= ly complex as a context has to be maintained between the old and the new no= de to pass anti replay protection and enable appropriated encryption/decryp= tion. It would be good to clarify if any parameters need - or not - to be synchronized between the two nodes= as its transfer represents a risk of disrupting the traffic, and thus may = be mentioned. 
There probably other points I am missing due to my lack of expertise - espe= cially those due to operational practices. 
I believe that any information that you could think of that would encourage= you to double check/validate a network outage is present over performing t= he fast failover might be useful information.    
Similarly, it would be good to mention cases where an operator may choose n= ot to deploy such mechanism.

Yours, 
Daniel

Fr= om: Greg Mirsky <gregimirsky@gmail.com>
Sent: Thursday, November 12, 2020 10:47 AM
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: secdir@ietf= .org <secdir@ie= tf.org>; BESS <bess@ietf.org>; last-call@ietf.org<= /a> <last-call@i= etf.org>; draft-ietf-bess-mvpn-fast-failover.all@ietf.org <draft-iet= f-bess-mvpn-fast-failover.all@ietf.org>
Subject: Re: Secdir last call review of draft-ietf-bess-mvpn-fast-fa= ilover-11
 
Hi Daniel,
thank you for your kind consideration of my notes. I've top-copied wha= t appeared to me as the remaining open issues. I hope I've not missed&= nbsp;any of your questions. Please find my notes in-line below tagged GIM&g= t;>. Attached are the updated working version and the new diff.

Regards,
Greg

<mglt>
sure. If you know the network is down, then fast fail-over is definitively = a plus. What I think could be useful is to evaluate the cost associated to = a fast-fail-over without any network failure.  This would be useful fo= r an operator to evaluate whether it should spend more time in diagnosing a network failure versus performing a= fast-fail-over.
Typically, if a fast failover comes a no cost at all, one operator would ma= ybe use one exchange to test the liveness of a node rather than 3.   &= nbsp;  

At that point, it seems to me that additional text coudl be added to charac= terize the impact. These could be high level and indicative, but it seems t= o me that knowing these impacts presents some value to the operators.  = ;    
</mglt>
GIM>> I would like to add a new paragraph in Section 3.1:
NEW TEXT:
   All methods described in this section may produce false-n= egative
   state changes that can be the trigger for an unnecessary failo= ver
   negatively impacting the multicast service provided by the VPN= .  An
   operator expected to consider the network environment and use<= br>    available controls of the mechanism used to determine the stat= us of a
   P-tunnel.

Would the new text be helpful?

<mglt>
Thanks for the feed back, It seems to me important to mention it is not rec= ommended these two mechanism co-exist.
How to avoid false negative transition might be out of scope of the draft I= agree, but it seems to me worth being mentioned especially in relation to = the impacts associated to a fail-over.  In case the fast-failover come= s with no impact this becomes less of a problem for operator deploying it.
 
</mglt>
GIM>> I hope that the new text presented above addresses this co= ncern.

<mglt>
I understand the document is addressing a 1:N scenario. That said, if M:N s= cenario leverage from 1:N protection it seems to me worth raising the issue= .
</mglt>
GIM>> I propose adding the clarification of the use of the Sandb= y PE in Section 4:
OLD TEXT:
   The procedures described below are limited to the case wh= ere the site
   that contains C-S is connected to two or more PEs, though, to<= br>    simplify the description, the case of dual-homing is described= .
NEW TEXT:
   The procedures described below are limited to the case wh= ere the site
   that contains C-S is connected to two or more PEs, though, to<= br>    simplify the description, the case of dual-homing is described= .  Such
   a redundancy protection scheme, referred to as 1:N protection,= is the
   special case of M:N protection, where M working instances are = sharing
   protection of the N standby instances.  In addition to a = network
   failure detection mechanism, the latter scheme requires using = a
   mechanism to coordinate the failover among working instances.&= nbsp; For
   that reason, M:N protection is outside the scope of this
   specification. 

On Wed, Nov 11, 2020 at 8:48 AM Daniel Migault <daniel.migault@er= icsson.com> wrote:
Hi Greg, 

Thanks for the response and clarifications. Most of my comments have been a= ddressed/answered. However, it seems to me that some additional text might = be added to the security consideration section document the impact on the n= etwork of a fast-failover operation. The knowledge of these impact might be useful for an operator to determine= when the trigger can be done. 

Please see more comments inline. 

Yours, 
Daniel 

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Tuesday, November 10, 2020 9:13 PM
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: secdir@ietf= .org <secdir@ie= tf.org>; BESS <bess@ietf.org>; last-call@ietf.org<= /a> <last-call@i= etf.org>; draft-ietf-bess-mvpn-fast-failover.all@ietf.org <draft-iet= f-bess-mvpn-fast-failover.all@ietf.org>
Subject: Re: Secdir last call review of draft-ietf-bess-mvpn-fast-fa= ilover-11
 
Hi Daniel,
many thanks for the review, thoughtful comments, and questions, all ar= e much appreciated. Also, my apologies for the long delay to respond to you= r comments. Please find my answers and notes in-line below tagged by GIM>= ;>. Attached are the new working version and the diff to -12.

Regards,
Greg

On Fri, Oct 23, 2020 at 5:36 AM Daniel Migault via Datatra= cker <noreply@ietf= .org> wrote:
Reviewer: Daniel Migault
Review result: Has Nits

Hi,


I reviewed this document as part of the Security Directorate's ongoing effo= rt to
review all IETF documents being processed by the IESG.  These comments= were
written primarily for the benefit of the Security Area Directors.  Doc= ument
authors, document editors, and WG chairs should treat these comments just l= ike
any other IETF Last Call comments.  Please note also that my expertise= in BGP is
limited, so feel free to take these comments with a pitch of salt. 
Review Results: Has Nits

Please find my comments below.

Yours,
Daniel


                  Multicast VP= N Fast Upstream Failover
                 draft-ietf-be= ss-mvpn-fast-failover-11

Abstract

   This document defines multicast VPN extensions and procedures = that
   allow fast failover for upstream failures, by allowing downstr= eam PEs
   to take into account the status of Provider-Tunnels (P-tunnels= ) when
   selecting the Upstream PE for a VPN multicast flow, and extend= ing BGP
   MVPN routing so that a C-multicast route can be advertised tow= ard a
   Standby Upstream PE.

<mglt>
Though it might be just a nit, if MVPN
designates multicast VPN, it might be
clarifying to specify the acronym in the
first sentence. This would later make
the correlation with BGP MVPN clearer.

</mglt>
GIM>> I've updated s/BGP MVPN/BGP multicast VPN/. Also, s/mVPN/M= VPN/ throughout the document.


1.  Introduction

   In the context of multicast in BGP/MPLS VPNs, it is desirable = to
   provide mechanisms allowing fast recovery of connectivity on    different types of failures.  This document addresses fai= lures of
   elements in the provider network that are upstream of PEs conn= ected
   to VPN sites with receivers.

<mglt>
Well I am not familiar with neither BGP
nor MPLS. It seems that BGP/MLPS IP VPNS
and MPLS/BGP IP VPNs are both used. I am
wondering if there is a distinction
between the two and a preferred way to
designate these VPNs.  My understanding
is that the VPN-IPv4 characterizes the
VPN while MPLS is used by the backbone
for the transport.  Since the PE are
connected to the backbone the VPN-IPv4
needs to be labeled.

</mglt>
GIM>> I understand that this document often sends the reader to = check RFC 6513 and/or RFC 6514. BGP/MPLS MVPN identifies the case of provid= ing a multicast service over an IP VPN that is overlayed on the MPLS d= ata plane using the BGP control plane.

   Section 3 describes local procedures allowing an egress PE (a = PE
   connected to a receiver site) to take into account the status = of
   P-tunnels to determine the Upstream Multicast Hop (UMH) for a = given
   (C-S, C-G).  This method does not provide a "fast fa= ilover" solution
<mglt>
I understand the limitation is due to
BGP convergence.

</mglt>
GIM>> Yes, a dynamic routing protocol, BGP in this case, provide= s the service restoration functionality but the restoration time is signifi= cant and affects the experience of a client.

   when used alone, but can be used together with the mechanism    described in Section 4 for a "fast failover" solutio= n.

   Section 4 describes protocol extensions that can speed up fail= over by
   not requiring any multicast VPN routing message exchange at re= covery
   time.

   Moreover, section 5 describes a "hot leaf standby" m= echanism, that
   uses a combination of these two mechanisms.  This approac= h has
   similarities with the solution described in [RFC7431] to impro= ve
   failover times when PIM routing is used in a network given som= e
   topology and metric constraints.


[...]

3.1.1.  mVPN Tunnel Root Tracking

   A condition to consider that the status of a P-tunnel is up is= that
   the root of the tunnel, as determined in the x-PMSI Tunnel att= ribute,
   is reachable through unicast routing tables.  In this cas= e, the
   downstream PE can immediately update its UMH when the reachabi= lity
   condition changes.

   That is similar to BGP next-hop tracking for VPN routes, excep= t that
   the address considered is not the BGP next-hop address, but th= e root
   address in the x-PMSI Tunnel attribute.

   If BGP next-hop tracking is done for VPN routes and the root a= ddress
   of a given tunnel happens to be the same as the next-hop addre= ss in
   the BGP A-D Route advertising the tunnel, then checking, in un= icast
   routing tables, whether the tunnel root is reachable, will be<= br>    unnecessary duplication and thus will not bring any specific b= enefit.

<mglt>
It seems to me that x-PMSI address
designates a different interface than
the one used by the Tunnel itself. If
that is correct, such mechanisms seems
to assume that one equipment up on one
interface will be up on the other
interfaces. I have the impression that a
configuration change in a PE may end up
in the P-tunnel being down, while the PE
still being reachable though the x-PMSI
Tunnel attribute. If that is a possible
scenario, the current mechanisms may not
provide more efficient mechanism than
then those of the standard BGP.
GIM>> That is a very interesting angle, thank you. Yes, in OAM, = and in the Fault Management (FM) OAM in particular, we have to make some as= sumptions about the state of the remote system based on a single event= or change of state. Usually, AFAIK, operators use not a physical interface but a loopback to associate with a tunnel. Wi= th a fast IGP convergence, a loopback interface is reachable as long as the= re's a path through the network between two nodes.
<mglt>
Thanks for the clarification
</mglt>

Similarly, it is assumed the tunnel is
either up or down and the determination
of not being up if being down.  I am not
convinced that the two only states.
Typically services under DDoS may be
down for a small amount of time. While
this affects the network, there is not
always a clear cut between the PE being
up or down.
</mglt>
GIM>>  In defect detection a system often has some hysteres= is, i.e., time that the system has to wait to change its state. For example= , BFD changes state from Up to Down after the system does not receive N con= secutive packets (usually 3). As a result, in some cases, the system can be tuned to detect relatively short outages = while in others be slower and miss short-lived outages.


[...]

3.1.6.  BFD Discriminator Attribute

   P-tunnel status may be derived from the status of a multipoint= BFD
   session [RFC8562] whose discriminator is advertised along with= an
   x-PMSI A-D Route.

   This document defines the format and ways of using a new BGP    attribute called the "BFD Discriminator".  It i= s an optional
   transitive BGP attribute.  In Section 7.2, IANA is reques= ted to
   allocate the codepoint value (TBA2).  The format of this = attribute is
   shown in Figure 1.

<mglt>
I feel that the sentence "In Section ...
TBA2)." should be removed.

</mglt>
GIM>> We use this to mark where to note the allocated value. Usu= ally, this text is replaced by the RFC Editor to read 
In Section 7.2 IANA allocated codepoint XXX.



       0             = ;      1              &nb= sp;    2                &= nbsp;  3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
      |    BFD Mode   |    &nb= sp;             Reserved      =                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
      |              &nbs= p;        BFD Discriminator        =                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
      ~              &nbs= p;          Optional TLVs      &nbs= p;                  ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+


            Figure 1: Format of the BFD Discr= iminator Attribute

   Where:

      BFD Mode field is the one octet long.  This speci= fication defines
      the P2MP BFD Session as value 1 Section 7.2.

      Reserved field is three octets long, and the value MUS= T be zeroed
      on transmission and ignored on receipt.

      BFD Discriminator field is four octets long.





Morin, et al.             Expires April = 5, 2021                 [Page = 7]

Internet-Draft         mVPN Fast Upstream Failover=           October 2020


      Optional TLVs is the optional variable-length field th= at MAY be
      used in the BFD Discriminator attribute for future ext= ensions.
      TLVs MAY be included in a sequential or nested manner.=   To allow
      for TLV nesting, it is advised to define a new TLV as = a variable-
      length object.  Figure 2 presents the Optional TL= V format TLV that
      consists of:

      *  one octet-long field of TLV 's Type value (Sec= tion 7.3)

      *  one octet-long field of the length of the Valu= e field in octets

      *  variable length Value field.

      The length of a TLV MUST be multiple of four octets. <mglt>
I am wondering why the constraint on the
length is not mentioned in the paragraph
associated to the field - as opposed to
a  separate paragraph.

</mglt>
GIM>> There might be a slight confusion due to the use of Length= and length. Capitalized - the name of the field which value is the length = of the Value field. The last sentence refers to the overall length of a TLV= , including lengths of Type, Length and Value fields.

<mglt>
you are correct that might have confused me. 
</mglt>

[..]

8.  Security Considerations

   This document describes procedures based on [RFC6513] and [RFC= 6514]
   and hence shares the security considerations respectively repr= esented
   in these specifications.

   This document uses p2mp BFD, as defined in [RFC8562], which, i= n turn,
   is based on [RFC5880].  Security considerations relevant = to each
   protocol are discussed in the respective protocol specificatio= ns.  An
   implementation that supports this specification MUST use a mec= hanism
   to control the maximum number of p2mp BFD sessions that can be= active
   at the same time.

<mglt>
At a high level view - or at least my
interpretation of it - the document
proposes a mechanism based on BFD to
detect fault in the path.  Upon a fault
detection a fail-over operation is
instructed using BGP. This rocedure is
expected to perform a faster fail-over
than traditional BGP convergence on
maintaining routing tables. Once the
fail over has been performed, BFD is
confirms the new path is "legitimate"
and works.

It seems correct to me that the current
protocol relies on BGP / BFD security.
That said, having BFD authentication
based on MD5 or SHA1 may suggest that
stronger primitives be recommended.
While this does not concerns the current
document, it seems to me that the
information might be relayed to routing
ADs.

What remains unclear to me - and I
assume this might be due to my lake or
expertise in routing area - is the impact
associated to performing a fail-over
both on 1) the data plane and 2) the
standard BGP way to establish routing
tables.

Regarding the data plane, I am wondering
if fail-over results in a lost of
packets for example - I suppose for
example that at least the packets in the
process of being forwarded might be
lost. I believe that providing details
on this may be good.
GIM>> You bring up a very topic for the discussion, thank you. W= ith network failure detection in place, the fail-over can be viewed as the = reaction to a network failure.  If that is the case, then packet loss = experienced by service due to the fail-over is the result of the network failure. Would you agree with that view? A sh= orter failure detection interval and faster fail-over should minimize = the packet loss and, as a result, the negative impact on the service itself= .

<mglt>
sure. If you know the network is down, then fast fail-over is definiti= vely a plus. What I think could be useful is to evaluate the cost associate= d to a fast-fail-over without any network failure.  This would be usef= ul for an operator to evaluate whether it should spend more time in diagnosing a network failure versus performin= g a fast-fail-over. 
Typically, if a fast failover comes a no cost at all, one operator wou= ld maybe use one exchange to test the liveness of a node rather than 3.&nbs= p;     

At that point, it seems to me that additional text coudl be added to c= haracterize the impact. These could be high level and indicative, but it se= ems to me that knowing these impacts presents some value to the operators.&= nbsp;     
</mglt>

If there are any impacts I would like to
understand also in which cases the
decision to perform a failover operation
may result in more harm than the event
that has been over-interpreted. An
hypothetical scenario could be that the
non reception of a BFD packet is
interpreted as a PE being down while it
may not be correct and the PE might have
been simply under stress. A "too fast" fail-over
may over interpreted it and perform a
fail-over. If such things could happen,
an attacker could leverage a micro event
to perform network operation that are
not negligible. Another way to see that
is that an attacker might not have
direct access to the control plan, but
could use the data plan to generate a
stress and sort of control the fail
over. It seems to me that some text
might be welcome to prevent such cases
to happen. This could be guidance for
declaring a tunnel down for example.
GIM>> I agree with your scenario. Over-short detection interval = may produce a false-negative transition to the Down state in BFD and thus t= riggering the fail-over. I think that that is more an operational issue, so= mething that an operator will consider when deploying the mechanism specified in this draft. Resulting from addre= ssing RtgDir review the draft was updated to provide more guidance:
   In many cases, it is not practical to use both protection=
   methods at the same time because uncorrelated timers might cau= se
   unnecessary switchovers and destabilize the network.
<mglt>
Thanks for the feed back, It seems to me important to mention it is no= t recommended these two mechanism co-exist. 
How to avoid false negative transition might be out of scope of the dr= aft I agree, but it seems to me worth being mentioned especially in relatio= n to the impacts associated to a fail-over.  In case the fast-failover= comes with no impact this becomes less of a problem for operator deploying it.
 
</mglt>
Though the text above might not be general, I think that it also appli= es to the scenario you've presented.

Similarly, it would be good to add some
text regarding the interferences with
the non-fast forwarding fail over when
performed by the standard BGP.
Typically, my impression is that the
fast fail-over mechanism is a local
decision versus the BGP convergence that
is more global. As a result, even with
more time this two mechanisms may come
with different outcomes. One such
example to illustrate my purpose could
be the following. Note that this is only
illustrative of my purpose, and I let
you find and pick on ethat is more
appropriated.   I am thinking of a case
where a standby PE is be shared among
multiple PEs - supposing this situation
could occur.  Typically, if PE_1, PE_2
are shared by PE_a, ..., PE_z. In case
PE_a and PE_b are down, we expect PE_a
to switch to PE_1 and PE_b to switch to
PE_2. It seems to me that BGP would end
up in such situation while a local
decision may end up in PE_a and PE_a to
switch to PE_1.

</mglt>
GIM>> Thank you for the scenario that is very common in deployin= g protection based on the shared redundant resources. Such schemes, referre= d to as M:N protection, in addition to using mechanism detecting a network = failure, e.g., BFD, require a protocol to coordinate the switchover. This specification applies to a more special= deployment scenario where one working PE is protected by one or more stand= by PEs, i.e., 1:N protection.

<mglt>
I understand the document is addressing a 1:N scenario. That said, if = M:N scenario leverage from 1:N protection it seems to me worth raising the = issue. 
</mglt>
--_000_DM6PR15MB2379A3F41D9EDE7A22BC7DBAE3E70DM6PR15MB2379namp_-- From nobody Thu Nov 12 13:43:41 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F623A0997; Thu, 12 Nov 2020 13:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9j3vNI7Uzhy; Thu, 12 Nov 2020 13:43:32 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 658273A0995; Thu, 12 Nov 2020 13:43:31 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id u18so10693044lfd.9; Thu, 12 Nov 2020 13:43:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iH4oHCt7qYFV0rPKesP3LTqaXTFcZbc86sOXTLCVa/w=; b=NnHfU+SyLoaqsFRMyMHOhz6DGiqE+ZwPvqyRwoPuqSZz/NYuYxzL4iTIPZqHNScKcL Eu2mICIUAD71jzhB2GmtLEoGJUs5D9itE+gUA7wIQadZbE+QOu0nRIIC8sGWQCN64lre Ae5a8GhpHbwcd8110OxQRkLBCISr6cepfIYzwYlLxrd/d66tfMaja/aPRkLA+fyHf0po bpH0Zuh+HA1uke3VJB+yPJLQSUUw5R/9gBqeTiLTS7x9RDlRCBW2fS+y3QsiPW4uExsg Uq7nDrTkS9pR54oKo9JHX/6Ejr6APAQLEowgcqa0oqJDjjSkOWvvdgUp39cHYg2y2T8/ yeKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iH4oHCt7qYFV0rPKesP3LTqaXTFcZbc86sOXTLCVa/w=; b=SLFJyj8fCTPtx0mg0u/Tv+RhOS3DNBjnaZ+uHgds7cnMTA6rnXaNq6jQdzV08zQ2Gz cYkoOas94uQeEsBnvgyEj3y/KunGG9UNZA+lDzDoit/xeySDiIQ9qtK7LoV/eMFOkyqF DjbPbJyVYFGqf1wHwSRHU7cu+hzLjfH9xPMh8Go6WO4k9Hc4RM/5Fiu+lUN+1dI+2bLi RZ7k/ObxOI+ilMqKuL35bOmZ+TmPwDq5ofwddx9gFLM634YH0fWPIU/m+JII4a1SmHwF nhphzfL4SU40eMFFWUMuEXwqFEzltavAo8F1nONkzCRPFONhjSpS/dwTyNVoMrRHS/Nh lZtA== X-Gm-Message-State: AOAM533kgeA1jLz9CoBDebts6GEwCuBd7WmW6B/tOzzgSbMxM/XXPppO HOc1W1wrXBthnYU/x9lkWafJm6rMrIA+5gtRi4E= X-Google-Smtp-Source: ABdhPJy1S6HWiasypZb9cWa6EVCRjR5e+JexmJLVNBIkUiuwDt8S5k2jrP95I2TgSaCQJXBwV0WbbD/PLjrHAgDsY+Y= X-Received: by 2002:ac2:544d:: with SMTP id d13mr513840lfn.500.1605217409302; Thu, 12 Nov 2020 13:43:29 -0800 (PST) MIME-Version: 1.0 References: <160345656094.22100.7057001737682109381@ietfa.amsl.com> In-Reply-To: From: Greg Mirsky Date: Thu, 12 Nov 2020 13:43:18 -0800 Message-ID: To: Daniel Migault Cc: "secdir@ietf.org" , BESS , "last-call@ietf.org" , "draft-ietf-bess-mvpn-fast-failover.all@ietf.org" Content-Type: multipart/alternative; boundary="00000000000078059905b3efcda5" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-bess-mvpn-fast-failover-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 21:43:36 -0000 --00000000000078059905b3efcda5 Content-Type: text/plain; charset="UTF-8" Hi Daniel, thank you for spotting it, fixed. I enjoyed our discussion and, again, thank you for the review and your thoughtful comments. Best regards, Greg On Thu, Nov 12, 2020 at 1:32 PM Daniel Migault wrote: > Thanks for the response and explanation. I am fine with the text you > proposed and I consider all my concerns being addressed. > > I am reading your text as implicitly suggesting the following lines of > your response, which seems reasonable. > > """ > it is difficult to make any assumptions on how the convergence in the > control plane may impact the forwarding plane and what effect that will > have on a multicast flow. I think that very much depends on the > implementation and the HW capabilities of the platform used. > """ > > There one additional nit s/sectionSection/Section/ which I think comes > from the conversion. > > Thanks for all your clarifications! > > Yours, > Daniel > > ------------------------------ > *From:* Greg Mirsky > *Sent:* Thursday, November 12, 2020 3:14 PM > *To:* Daniel Migault > *Cc:* secdir@ietf.org ; BESS ; > last-call@ietf.org ; > draft-ietf-bess-mvpn-fast-failover.all@ietf.org < > draft-ietf-bess-mvpn-fast-failover.all@ietf.org> > *Subject:* Re: Secdir last call review of > draft-ietf-bess-mvpn-fast-failover-11 > > Hi Daniel, > thank you for the additional information. I understand your concerns and > agree that it is helpful to provide implementors and operators with useful > information about the potential impact the new functionality may > demonstrate in the network and how to mitigate the risks. I believe it is > important to recognize that this draft proposes mechanisms that expedite > the failure detection in a P-tunnel from the perspective of a downstream > PE. And the detection directly impacts the control plane, not the data > plane. I believe that it is difficult to make any assumptions on how the > convergence in the control plane may impact the forwarding plane and what > effect that will have on a multicast flow. I think that very much depends > on the implementation and the HW capabilities of the platform used. I've > moved the new text from Section 3.1 into the Security Considerations > section. Please let me know if you think that is a more appropriate place > for that paragraph. > Also, I've realized that the text I've proposed earlier that refers to 1:N > and N:M protection might be the source of questions and arguments and would > like to withdraw it. I hope you'll agree. > > I've attached the new diff reflecting the changes in the working version. > > Regards, > Greg > > > On Thu, Nov 12, 2020 at 9:02 AM Daniel Migault < > daniel.migault@ericsson.com> wrote: > > Hi Greg, > > Thanks for the response Greg. This seems to go in the right direction, but > I think it would be nice to detail a bit on the negative impact that may > result from the fast-fail over. > > """ > unnecessary failover negatively impacting the multicast service > """ > > I apology to appear being maybe a bit picky, but, at least to me, the > security consideration section is the place to point on specific impacts > that an operator may not have thought of and the text appears to me a bit > too vague on what can impact negatively the multicast service. > > Let me dig a bit on what I mean and probably what information I would have > expected to find. Maybe that would have been useful I provided those > earlier. Again, not being an expert in this area, please take my > following recommendations with a pitch of salt. > > What I would like, for example, to understand is whether having a > fast-failover between nodes that work properly results in a packet lost or > not. > I also envision that in some cases, this will result in packet re-ordering > which might result in packet being rejected by the end node. > In IPsec vpns, we have specific counters, keys that make fail-over > relatively complex as a context has to be maintained between the old and > the new node to pass anti replay protection and enable appropriated > encryption/decryption. It would be good to clarify if any parameters need - > or not - to be synchronized between the two nodes as its transfer > represents a risk of disrupting the traffic, and thus may be mentioned. > There probably other points I am missing due to my lack of expertise - > especially those due to operational practices. > I believe that any information that you could think of that would > encourage you to double check/validate a network outage is present over > performing the fast failover might be useful information. > Similarly, it would be good to mention cases where an operator may choose > not to deploy such mechanism. > > Yours, > Daniel > > ------------------------------ > *From:* Greg Mirsky > *Sent:* Thursday, November 12, 2020 10:47 AM > *To:* Daniel Migault > *Cc:* secdir@ietf.org ; BESS ; > last-call@ietf.org ; > draft-ietf-bess-mvpn-fast-failover.all@ietf.org < > draft-ietf-bess-mvpn-fast-failover.all@ietf.org> > *Subject:* Re: Secdir last call review of > draft-ietf-bess-mvpn-fast-failover-11 > > Hi Daniel, > thank you for your kind consideration of my notes. I've top-copied what > appeared to me as the remaining open issues. I hope I've not missed any of > your questions. Please find my notes in-line below tagged GIM>>. Attached > are the updated working version and the new diff. > > Regards, > Greg > > > sure. If you know the network is down, then fast fail-over is definitively > a plus. What I think could be useful is to evaluate the cost associated to > a fast-fail-over without any network failure. This would be useful for an > operator to evaluate whether it should spend more time in diagnosing a > network failure versus performing a fast-fail-over. > Typically, if a fast failover comes a no cost at all, one operator would > maybe use one exchange to test the liveness of a node rather than 3. > > At that point, it seems to me that additional text coudl be added to > characterize the impact. These could be high level and indicative, but it > seems to me that knowing these impacts presents some value to the > operators. > > GIM>> I would like to add a new paragraph in Section 3.1: > NEW TEXT: > All methods described in this section may produce false-negative > state changes that can be the trigger for an unnecessary failover > negatively impacting the multicast service provided by the VPN. An > operator expected to consider the network environment and use > available controls of the mechanism used to determine the status of a > P-tunnel. > > Would the new text be helpful? > > > Thanks for the feed back, It seems to me important to mention it is not > recommended these two mechanism co-exist. > How to avoid false negative transition might be out of scope of the draft > I agree, but it seems to me worth being mentioned especially in relation to > the impacts associated to a fail-over. In case the fast-failover comes > with no impact this becomes less of a problem for operator deploying it. > > > GIM>> I hope that the new text presented above addresses this concern. > > > I understand the document is addressing a 1:N scenario. That said, if M:N > scenario leverage from 1:N protection it seems to me worth raising the > issue. > > GIM>> I propose adding the clarification of the use of the Sandby PE in > Section 4: > OLD TEXT: > The procedures described below are limited to the case where the site > that contains C-S is connected to two or more PEs, though, to > simplify the description, the case of dual-homing is described. > NEW TEXT: > The procedures described below are limited to the case where the site > that contains C-S is connected to two or more PEs, though, to > simplify the description, the case of dual-homing is described. Such > a redundancy protection scheme, referred to as 1:N protection, is the > special case of M:N protection, where M working instances are sharing > protection of the N standby instances. In addition to a network > failure detection mechanism, the latter scheme requires using a > mechanism to coordinate the failover among working instances. For > that reason, M:N protection is outside the scope of this > specification. > > On Wed, Nov 11, 2020 at 8:48 AM Daniel Migault < > daniel.migault@ericsson.com> wrote: > > Hi Greg, > > Thanks for the response and clarifications. Most of my comments have been > addressed/answered. However, it seems to me that some additional text might > be added to the security consideration section document the impact on the > network of a fast-failover operation. The knowledge of these impact might > be useful for an operator to determine when the trigger can be done. > > Please see more comments inline. > > Yours, > Daniel > > ------------------------------ > *From:* Greg Mirsky > *Sent:* Tuesday, November 10, 2020 9:13 PM > *To:* Daniel Migault > *Cc:* secdir@ietf.org ; BESS ; > last-call@ietf.org ; > draft-ietf-bess-mvpn-fast-failover.all@ietf.org < > draft-ietf-bess-mvpn-fast-failover.all@ietf.org> > *Subject:* Re: Secdir last call review of > draft-ietf-bess-mvpn-fast-failover-11 > > Hi Daniel, > many thanks for the review, thoughtful comments, and questions, all are > much appreciated. Also, my apologies for the long delay to respond to your > comments. Please find my answers and notes in-line below tagged by GIM>>. > Attached are the new working version and the diff to -12. > > Regards, > Greg > > On Fri, Oct 23, 2020 at 5:36 AM Daniel Migault via Datatracker < > noreply@ietf.org> wrote: > > Reviewer: Daniel Migault > Review result: Has Nits > > Hi, > > > I reviewed this document as part of the Security Directorate's ongoing > effort to > review all IETF documents being processed by the IESG. These comments were > written primarily for the benefit of the Security Area Directors. Document > authors, document editors, and WG chairs should treat these comments just > like > any other IETF Last Call comments. Please note also that my expertise in > BGP is > limited, so feel free to take these comments with a pitch of salt. > > Review Results: Has Nits > > Please find my comments below. > > Yours, > Daniel > > > Multicast VPN Fast Upstream Failover > draft-ietf-bess-mvpn-fast-failover-11 > > Abstract > > This document defines multicast VPN extensions and procedures that > allow fast failover for upstream failures, by allowing downstream PEs > to take into account the status of Provider-Tunnels (P-tunnels) when > selecting the Upstream PE for a VPN multicast flow, and extending BGP > MVPN routing so that a C-multicast route can be advertised toward a > Standby Upstream PE. > > > Though it might be just a nit, if MVPN > designates multicast VPN, it might be > clarifying to specify the acronym in the > first sentence. This would later make > the correlation with BGP MVPN clearer. > > > > GIM>> I've updated s/BGP MVPN/BGP multicast VPN/. Also, s/mVPN/MVPN/ > throughout the document. > > > > 1. Introduction > > In the context of multicast in BGP/MPLS VPNs, it is desirable to > provide mechanisms allowing fast recovery of connectivity on > different types of failures. This document addresses failures of > elements in the provider network that are upstream of PEs connected > to VPN sites with receivers. > > > Well I am not familiar with neither BGP > nor MPLS. It seems that BGP/MLPS IP VPNS > and MPLS/BGP IP VPNs are both used. I am > wondering if there is a distinction > between the two and a preferred way to > designate these VPNs. My understanding > is that the VPN-IPv4 characterizes the > VPN while MPLS is used by the backbone > for the transport. Since the PE are > connected to the backbone the VPN-IPv4 > needs to be labeled. > > > > GIM>> I understand that this document often sends the reader to check RFC > 6513 and/or RFC 6514. BGP/MPLS MVPN identifies the case of providing a > multicast service over an IP VPN that is overlayed on the MPLS data plane > using the BGP control plane. > > > Section 3 describes local procedures allowing an egress PE (a PE > connected to a receiver site) to take into account the status of > P-tunnels to determine the Upstream Multicast Hop (UMH) for a given > (C-S, C-G). This method does not provide a "fast failover" solution > > I understand the limitation is due to > BGP convergence. > > > > GIM>> Yes, a dynamic routing protocol, BGP in this case, provides the > service restoration functionality but the restoration time is significant > and affects the experience of a client. > > when used alone, but can be used together with the mechanism > described in Section 4 for a "fast failover" solution. > > Section 4 describes protocol extensions that can speed up failover by > not requiring any multicast VPN routing message exchange at recovery > time. > > Moreover, section 5 describes a "hot leaf standby" mechanism, that > uses a combination of these two mechanisms. This approach has > similarities with the solution described in [RFC7431] to improve > failover times when PIM routing is used in a network given some > topology and metric constraints. > > > [...] > > 3.1.1. mVPN Tunnel Root Tracking > > A condition to consider that the status of a P-tunnel is up is that > the root of the tunnel, as determined in the x-PMSI Tunnel attribute, > is reachable through unicast routing tables. In this case, the > downstream PE can immediately update its UMH when the reachability > condition changes. > > That is similar to BGP next-hop tracking for VPN routes, except that > the address considered is not the BGP next-hop address, but the root > address in the x-PMSI Tunnel attribute. > > If BGP next-hop tracking is done for VPN routes and the root address > of a given tunnel happens to be the same as the next-hop address in > the BGP A-D Route advertising the tunnel, then checking, in unicast > routing tables, whether the tunnel root is reachable, will be > unnecessary duplication and thus will not bring any specific benefit. > > > It seems to me that x-PMSI address > designates a different interface than > the one used by the Tunnel itself. If > that is correct, such mechanisms seems > to assume that one equipment up on one > interface will be up on the other > interfaces. I have the impression that a > configuration change in a PE may end up > in the P-tunnel being down, while the PE > still being reachable though the x-PMSI > Tunnel attribute. If that is a possible > scenario, the current mechanisms may not > provide more efficient mechanism than > then those of the standard BGP. > > GIM>> That is a very interesting angle, thank you. Yes, in OAM, and in the > Fault Management (FM) OAM in particular, we have to make some > assumptions about the state of the remote system based on a single event or > change of state. Usually, AFAIK, operators use not a physical interface but > a loopback to associate with a tunnel. With a fast IGP convergence, a > loopback interface is reachable as long as there's a path through the > network between two nodes. > > Thanks for the clarification > > > > Similarly, it is assumed the tunnel is > either up or down and the determination > of not being up if being down. I am not > convinced that the two only states. > Typically services under DDoS may be > down for a small amount of time. While > this affects the network, there is not > always a clear cut between the PE being > up or down. > > > GIM>> In defect detection a system often has some hysteresis, i.e., time > that the system has to wait to change its state. For example, BFD changes > state from Up to Down after the system does not receive N consecutive > packets (usually 3). As a result, in some cases, the system can be tuned to > detect relatively short outages while in others be slower and miss > short-lived outages. > > > > [...] > > 3.1.6. BFD Discriminator Attribute > > P-tunnel status may be derived from the status of a multipoint BFD > session [RFC8562] whose discriminator is advertised along with an > x-PMSI A-D Route. > > This document defines the format and ways of using a new BGP > attribute called the "BFD Discriminator". It is an optional > transitive BGP attribute. In Section 7.2, IANA is requested to > allocate the codepoint value (TBA2). The format of this attribute is > shown in Figure 1. > > > I feel that the sentence "In Section ... > TBA2)." should be removed. > > > > GIM>> We use this to mark where to note the allocated value. Usually, this > text is replaced by the RFC Editor to read > > In Section 7.2 IANA allocated codepoint XXX. > > > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BFD Mode | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BFD Discriminator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Optional TLVs ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 1: Format of the BFD Discriminator Attribute > > Where: > > BFD Mode field is the one octet long. This specification defines > the P2MP BFD Session as value 1 Section 7.2. > > Reserved field is three octets long, and the value MUST be zeroed > on transmission and ignored on receipt. > > BFD Discriminator field is four octets long. > > > > > > Morin, et al. Expires April 5, 2021 [Page 7] > > Internet-Draft mVPN Fast Upstream Failover October 2020 > > > Optional TLVs is the optional variable-length field that MAY be > used in the BFD Discriminator attribute for future extensions. > TLVs MAY be included in a sequential or nested manner. To allow > for TLV nesting, it is advised to define a new TLV as a variable- > length object. Figure 2 presents the Optional TLV format TLV that > consists of: > > * one octet-long field of TLV 's Type value (Section 7.3) > > * one octet-long field of the length of the Value field in octets > > * variable length Value field. > > The length of a TLV MUST be multiple of four octets. > > I am wondering why the constraint on the > length is not mentioned in the paragraph > associated to the field - as opposed to > a separate paragraph. > > > > GIM>> There might be a slight confusion due to the use of Length and > length. Capitalized - the name of the field which value is the length of > the Value field. The last sentence refers to the overall length of a TLV, > including lengths of Type, Length and Value fields. > > > you are correct that might have confused me. > > > > [..] > > 8. Security Considerations > > This document describes procedures based on [RFC6513] and [RFC6514] > and hence shares the security considerations respectively represented > in these specifications. > > This document uses p2mp BFD, as defined in [RFC8562], which, in turn, > is based on [RFC5880]. Security considerations relevant to each > protocol are discussed in the respective protocol specifications. An > implementation that supports this specification MUST use a mechanism > to control the maximum number of p2mp BFD sessions that can be active > at the same time. > > > At a high level view - or at least my > interpretation of it - the document > proposes a mechanism based on BFD to > detect fault in the path. Upon a fault > detection a fail-over operation is > instructed using BGP. This rocedure is > expected to perform a faster fail-over > than traditional BGP convergence on > maintaining routing tables. Once the > fail over has been performed, BFD is > confirms the new path is "legitimate" > and works. > > It seems correct to me that the current > protocol relies on BGP / BFD security. > That said, having BFD authentication > based on MD5 or SHA1 may suggest that > stronger primitives be recommended. > While this does not concerns the current > document, it seems to me that the > information might be relayed to routing > ADs. > > What remains unclear to me - and I > assume this might be due to my lake or > expertise in routing area - is the impact > associated to performing a fail-over > both on 1) the data plane and 2) the > standard BGP way to establish routing > tables. > > Regarding the data plane, I am wondering > if fail-over results in a lost of > packets for example - I suppose for > example that at least the packets in the > process of being forwarded might be > lost. I believe that providing details > on this may be good. > > GIM>> You bring up a very topic for the discussion, thank you. With > network failure detection in place, the fail-over can be viewed as the > reaction to a network failure. If that is the case, then packet loss > experienced by service due to the fail-over is the result of the network > failure. Would you agree with that view? A shorter failure detection > interval and faster fail-over should minimize the packet loss and, as a > result, the negative impact on the service itself. > > > sure. If you know the network is down, then fast fail-over is definitively > a plus. What I think could be useful is to evaluate the cost associated to > a fast-fail-over without any network failure. This would be useful for an > operator to evaluate whether it should spend more time in diagnosing a > network failure versus performing a fast-fail-over. > Typically, if a fast failover comes a no cost at all, one operator would > maybe use one exchange to test the liveness of a node rather than 3. > > At that point, it seems to me that additional text coudl be added to > characterize the impact. These could be high level and indicative, but it > seems to me that knowing these impacts presents some value to the > operators. > > > If there are any impacts I would like to > understand also in which cases the > decision to perform a failover operation > may result in more harm than the event > that has been over-interpreted. An > hypothetical scenario could be that the > non reception of a BFD packet is > interpreted as a PE being down while it > may not be correct and the PE might have > been simply under stress. A "too fast" fail-over > may over interpreted it and perform a > fail-over. If such things could happen, > an attacker could leverage a micro event > to perform network operation that are > not negligible. Another way to see that > is that an attacker might not have > direct access to the control plan, but > could use the data plan to generate a > stress and sort of control the fail > over. It seems to me that some text > might be welcome to prevent such cases > to happen. This could be guidance for > declaring a tunnel down for example. > > GIM>> I agree with your scenario. Over-short detection interval may > produce a false-negative transition to the Down state in BFD and thus > triggering the fail-over. I think that that is more an operational issue, > something that an operator will consider when deploying the mechanism > specified in this draft. Resulting from addressing RtgDir review the draft > was updated to provide more guidance: > In many cases, it is not practical to use both protection > methods at the same time because uncorrelated timers might cause > unnecessary switchovers and destabilize the network. > > Thanks for the feed back, It seems to me important to mention it is not > recommended these two mechanism co-exist. > How to avoid false negative transition might be out of scope of the draft > I agree, but it seems to me worth being mentioned especially in relation to > the impacts associated to a fail-over. In case the fast-failover comes > with no impact this becomes less of a problem for operator deploying it. > > > Though the text above might not be general, I think that it also applies > to the scenario you've presented. > > > Similarly, it would be good to add some > text regarding the interferences with > the non-fast forwarding fail over when > performed by the standard BGP. > Typically, my impression is that the > fast fail-over mechanism is a local > decision versus the BGP convergence that > is more global. As a result, even with > more time this two mechanisms may come > with different outcomes. One such > example to illustrate my purpose could > be the following. Note that this is only > illustrative of my purpose, and I let > you find and pick on ethat is more > appropriated. I am thinking of a case > where a standby PE is be shared among > multiple PEs - supposing this situation > could occur. Typically, if PE_1, PE_2 > are shared by PE_a, ..., PE_z. In case > PE_a and PE_b are down, we expect PE_a > to switch to PE_1 and PE_b to switch to > PE_2. It seems to me that BGP would end > up in such situation while a local > decision may end up in PE_a and PE_a to > switch to PE_1. > > > > GIM>> Thank you for the scenario that is very common in deploying > protection based on the shared redundant resources. Such schemes, referred > to as M:N protection, in addition to using mechanism detecting a network > failure, e.g., BFD, require a protocol to coordinate the switchover. This > specification applies to a more special deployment scenario where one > working PE is protected by one or more standby PEs, i.e., 1:N protection. > > > I understand the document is addressing a 1:N scenario. That said, if M:N > scenario leverage from 1:N protection it seems to me worth raising the > issue. > > > --00000000000078059905b3efcda5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Daniel,
thank you for spotting it, fixed.
=C2=A0I enjoyed our discussion and, again, thank you for the review and yo= ur thoughtful comments.

Best regards,
Gr= eg

On Thu, Nov 12, 2020 at 1:32 PM Daniel Migault <daniel.migault@ericsson.com> wrote:
Thanks for the response and explanation. I am fine with the text you propos= ed and I consider all my concerns being addressed.

I am reading your text as implicitly suggesting the following lines of your= response, which seems reasonable.=C2=A0 =C2=A0
=C2=A0
"""
=C2=A0it is difficult to make any assumptions on how the convergence in the control= plane may impact the forwarding plane and what effect that will have on a = multicast flow. I think that very much depends on the implementation and th= e HW capabilities of the platform used.
"""

There=C2=A0=C2=A0one additional nit s/sectionSection/Section/ which I think comes from the conv= ersion.=C2=A0

Thanks for all your clar= ifications!

Yours,=C2=A0
Daniel

From= : Greg Mirsky <gregimirsky@gmail.com>
Sent: Thursday, November 12, 2020 3:14 PM
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: secdir@ietf= .org <secdir@ie= tf.org>; BESS <bess@ietf.org>; last-call@ietf.org <last-call@ietf.org>; draft-ietf-bess-mvpn-fas= t-failover.all@ietf.org <draft-ietf-bess-mvpn-fast-failove= r.all@ietf.org>
Subject: Re: Secdir last call review of draft-ietf-bess-mvpn-fast-fa= ilover-11
=C2=A0
Hi Daniel,
thank you for the additional information. I understand your concerns= =C2=A0and agree that it is helpful to provide implementors and operators wi= th useful information about the potential impact the new functionality may = demonstrate in the network and how to mitigate the risks. I believe it is important to recognize that this draft proposes= mechanisms that expedite the failure detection in a P-tunnel from the pers= pective of a downstream PE. And the detection directly impacts the control = plane, not the data plane. I believe that it is difficult to make any assumptions on how the convergence in the= control plane may impact the forwarding plane and what effect that will ha= ve on a multicast flow. I think that very much depends on the implementatio= n and the HW capabilities of the platform used. I've moved=C2=A0the new text from Section 3.1 into the = Security Considerations section. Please let me know if you think that is a = more appropriate place for that paragraph.
Also, I've realized that the text I've proposed earlier that r= efers to 1:N and N:M protection might be the source of questions and argume= nts and would like to withdraw it. I hope you'll agree.

I've attached the new diff reflecting the changes in the working v= ersion.

Regards,
Greg


On Thu, Nov 12, 2020 at 9:02 AM Daniel Migault <daniel.migault@er= icsson.com> wrote:
Hi Greg,=C2=A0

Thanks for the response Greg. This seems to go in the right direction, but = I think it would be nice to detail a bit on the negative impact that may re= sult from the fast-fail over.=C2=A0

"""
unnecessary failover=C2=A0negatively impacting the multicast service
"""

I apology to appear being maybe a bit p= icky, but, at least to me, the security consideration section is the place = to point on specific impacts that an operator may not have thought of and the text appears to me a bit too v= ague on what can impact negatively the multicast service.=C2=A0

Let me dig a bit on what I mean and pro= bably what information I would have expected to find. Maybe that would have= been useful I provided those earlier.=C2=A0Again, not being an expert in thi= s area, please take my following recommendations with a pitch of salt.=C2= =A0

What I would like, for example, to understand is whether having a fast-fail= over between nodes that work properly results in a packet lost or not.=C2= =A0
I also envision that in some cases, this will result in packet re-ordering = which might result in packet being rejected by the end node.=C2=A0
In IPsec vpns, we have specific counters, keys that make fail-over relative= ly complex as a context has to be maintained between the old and the new no= de to pass anti replay protection and enable appropriated encryption/decryp= tion. It would be good to clarify if any parameters need - or not - to be synchronized between the two nodes= as its transfer represents a risk of disrupting the traffic, and thus may = be mentioned.=C2=A0
There probably other points I am missing due to my lack of expertise - espe= cially those due to operational practices.=C2=A0
I believe that any information that you could think of that would encourage= you to double check/validate a network outage is present over performing t= he fast failover might be useful information.=C2=A0 =C2=A0=C2=A0
Similarly, it would be good to mention cases where an operator may choose n= ot to deploy such mechanism.

Yours,=C2=A0
Daniel

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Thursday, November 12, 2020 10:47 AM
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: secdir@ietf= .org <secdir@ie= tf.org>; BESS <bess@ietf.org>; last-call@ietf.org<= /a> <last-call@i= etf.org>; draft-ietf-bess-mvpn-fast-failover.all@ietf.org <draft-iet= f-bess-mvpn-fast-failover.all@ietf.org>
Subject: Re: Secdir last call review of draft-ietf-bess-mvpn-fast-fa= ilover-11
=C2=A0
Hi Daniel,
thank you for your kind consideration of my notes. I've top-copied= what appeared to me as the remaining open issues. I hope I've not=C2= =A0missed=C2=A0any of your questions. Please find my notes in-line below ta= gged GIM>>. Attached are the updated working version and the new diff.

Regards,
Greg

<mglt>
sure. If you know the network is down, then fast fail-over is definitively = a plus. What I think could be useful is to evaluate the cost associated to = a fast-fail-over without any network failure.=C2=A0 This would be useful fo= r an operator to evaluate whether it should spend more time in diagnosing a network failure versus performing a= fast-fail-over.
Typically, if a fast failover comes a no cost at all, one operator would ma= ybe use one exchange to test the liveness of a node rather than 3. =C2=A0 = =C2=A0 =C2=A0

At that point, it seems to me that additional text coudl be added to charac= terize the impact. These could be high level and indicative, but it seems t= o me that knowing these impacts presents some value to the operators. =C2= =A0 =C2=A0 =C2=A0
</mglt>
GIM>> I would like to add a new paragraph in Section 3.1:
NEW TEXT:
=C2=A0 =C2=A0All methods described in this section may produce false-n= egative
=C2=A0 =C2=A0state changes that can be the trigger for an unnecessary failo= ver
=C2=A0 =C2=A0negatively impacting the multicast service provided by the VPN= .=C2=A0 An
=C2=A0 =C2=A0operator expected to consider the network environment and use<= br> =C2=A0 =C2=A0available controls of the mechanism used to determine the stat= us of a
=C2=A0 =C2=A0P-tunnel.

Would the new text be helpful?

<mglt>
Thanks for the feed back, It seems to me important to mention it is not rec= ommended these two mechanism co-exist.
How to avoid false negative transition might be out of scope of the draft I= agree, but it seems to me worth being mentioned especially in relation to = the impacts associated to a fail-over.=C2=A0 In case the fast-failover come= s with no impact this becomes less of a problem for operator deploying it.
=C2=A0
</mglt>
GIM>> I hope that the new text presented above addresses this co= ncern.

<mglt>
I understand the document is addressing a 1:N scenario. That said, if M:N s= cenario leverage from 1:N protection it seems to me worth raising the issue= .
</mglt>
GIM>> I propose adding the clarification of the use of the Sandb= y PE in Section 4:
OLD TEXT:
=C2=A0 =C2=A0The procedures described below are limited to the case wh= ere the site
=C2=A0 =C2=A0that contains C-S is connected to two or more PEs, though, to<= br> =C2=A0 =C2=A0simplify the description, the case of dual-homing is described= .
NEW TEXT:
=C2=A0 =C2=A0The procedures described below are limited to the case wh= ere the site
=C2=A0 =C2=A0that contains C-S is connected to two or more PEs, though, to<= br> =C2=A0 =C2=A0simplify the description, the case of dual-homing is described= .=C2=A0 Such
=C2=A0 =C2=A0a redundancy protection scheme, referred to as 1:N protection,= is the
=C2=A0 =C2=A0special case of M:N protection, where M working instances are = sharing
=C2=A0 =C2=A0protection of the N standby instances.=C2=A0 In addition to a = network
=C2=A0 =C2=A0failure detection mechanism, the latter scheme requires using = a
=C2=A0 =C2=A0mechanism to coordinate the failover among working instances.= =C2=A0 For
=C2=A0 =C2=A0that reason, M:N protection is outside the scope of this
=C2=A0 =C2=A0specification.=C2=A0

On Wed, Nov 11, 2020 at 8:48 AM Daniel Migault <daniel.migault@er= icsson.com> wrote:
Hi Greg,=C2=A0

Thanks for the response and clarifications. Most of my comments have been a= ddressed/answered. However, it seems to me that some additional text might = be added to the security consideration section document the impact on the n= etwork of a fast-failover operation. The knowledge of these impact might be useful for an operator to determine= when the trigger can be done.=C2=A0

Please see more comments inline.=C2=A0

Yours,=C2=A0
Daniel=C2=A0

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Tuesday, November 10, 2020 9:13 PM
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: secdir@ietf= .org <secdir@ie= tf.org>; BESS <bess@ietf.org>; last-call@ietf.org<= /a> <last-call@i= etf.org>; draft-ietf-bess-mvpn-fast-failover.all@ietf.org <draft-iet= f-bess-mvpn-fast-failover.all@ietf.org>
Subject: Re: Secdir last call review of draft-ietf-bess-mvpn-fast-fa= ilover-11
=C2=A0
Hi Daniel,
many thanks for the review, thoughtful comments, and questions, all ar= e much appreciated. Also, my apologies for the long delay to respond to you= r comments. Please find my answers and notes in-line below tagged by GIM>= ;>. Attached are the new working version and the diff to -12.

Regards,
Greg

On Fri, Oct 23, 2020 at 5:36 AM Daniel Migault via Datatra= cker <noreply@ietf= .org> wrote:
Reviewer: Daniel Migault
Review result: Has Nits

Hi,


I reviewed this document as part of the Security Directorate's ongoing = effort to
review all IETF documents being processed by the IESG.=C2=A0 These comments= were
written primarily for the benefit of the Security Area Directors.=C2=A0 Doc= ument
authors, document editors, and WG chairs should treat these comments just l= ike
any other IETF Last Call comments.=C2=A0 Please note also that my expertise= in BGP is
limited, so feel free to take these comments with a pitch of salt.=C2=A0
Review Results: Has Nits

Please find my comments below.

Yours,
Daniel


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Multicast VP= N Fast Upstream Failover
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-be= ss-mvpn-fast-failover-11

Abstract

=C2=A0 =C2=A0This document defines multicast VPN extensions and procedures = that
=C2=A0 =C2=A0allow fast failover for upstream failures, by allowing downstr= eam PEs
=C2=A0 =C2=A0to take into account the status of Provider-Tunnels (P-tunnels= ) when
=C2=A0 =C2=A0selecting the Upstream PE for a VPN multicast flow, and extend= ing BGP
=C2=A0 =C2=A0MVPN routing so that a C-multicast route can be advertised tow= ard a
=C2=A0 =C2=A0Standby Upstream PE.

<mglt>
Though it might be just a nit, if MVPN
designates multicast VPN, it might be
clarifying to specify the acronym in the
first sentence. This would later make
the correlation with BGP MVPN clearer.

</mglt>
GIM>> I've updated s/BGP MVPN/BGP multicast VPN/. Also, s/mV= PN/MVPN/ throughout the document.


1.=C2=A0 Introduction

=C2=A0 =C2=A0In the context of multicast in BGP/MPLS VPNs, it is desirable = to
=C2=A0 =C2=A0provide mechanisms allowing fast recovery of connectivity on =C2=A0 =C2=A0different types of failures.=C2=A0 This document addresses fai= lures of
=C2=A0 =C2=A0elements in the provider network that are upstream of PEs conn= ected
=C2=A0 =C2=A0to VPN sites with receivers.

<mglt>
Well I am not familiar with neither BGP
nor MPLS. It seems that BGP/MLPS IP VPNS
and MPLS/BGP IP VPNs are both used. I am
wondering if there is a distinction
between the two and a preferred way to
designate these VPNs.=C2=A0 My understanding
is that the VPN-IPv4 characterizes the
VPN while MPLS is used by the backbone
for the transport.=C2=A0 Since the PE are
connected to the backbone the VPN-IPv4
needs to be labeled.

</mglt>
GIM>> I understand that this document often sends the reader to = check RFC 6513 and/or RFC 6514. BGP/MPLS MVPN identifies the case of provid= ing a multicast service over an IP VPN that is overlayed=C2=A0on the MPLS d= ata plane using the BGP control plane.

=C2=A0 =C2=A0Section 3 describes local procedures allowing an egress PE (a = PE
=C2=A0 =C2=A0connected to a receiver site) to take into account the status = of
=C2=A0 =C2=A0P-tunnels to determine the Upstream Multicast Hop (UMH) for a = given
=C2=A0 =C2=A0(C-S, C-G).=C2=A0 This method does not provide a "fast fa= ilover" solution
<mglt>
I understand the limitation is due to
BGP convergence.

</mglt>
GIM>> Yes, a dynamic routing protocol, BGP in this case, provide= s the service restoration functionality but the restoration time is signifi= cant and affects the experience of a client.

=C2=A0 =C2=A0when used alone, but can be used together with the mechanism =C2=A0 =C2=A0described in Section 4 for a "fast failover" solutio= n.

=C2=A0 =C2=A0Section 4 describes protocol extensions that can speed up fail= over by
=C2=A0 =C2=A0not requiring any multicast VPN routing message exchange at re= covery
=C2=A0 =C2=A0time.

=C2=A0 =C2=A0Moreover, section 5 describes a "hot leaf standby" m= echanism, that
=C2=A0 =C2=A0uses a combination of these two mechanisms.=C2=A0 This approac= h has
=C2=A0 =C2=A0similarities with the solution described in [RFC7431] to impro= ve
=C2=A0 =C2=A0failover times when PIM routing is used in a network given som= e
=C2=A0 =C2=A0topology and metric constraints.


[...]

3.1.1.=C2=A0 mVPN Tunnel Root Tracking

=C2=A0 =C2=A0A condition to consider that the status of a P-tunnel is up is= that
=C2=A0 =C2=A0the root of the tunnel, as determined in the x-PMSI Tunnel att= ribute,
=C2=A0 =C2=A0is reachable through unicast routing tables.=C2=A0 In this cas= e, the
=C2=A0 =C2=A0downstream PE can immediately update its UMH when the reachabi= lity
=C2=A0 =C2=A0condition changes.

=C2=A0 =C2=A0That is similar to BGP next-hop tracking for VPN routes, excep= t that
=C2=A0 =C2=A0the address considered is not the BGP next-hop address, but th= e root
=C2=A0 =C2=A0address in the x-PMSI Tunnel attribute.

=C2=A0 =C2=A0If BGP next-hop tracking is done for VPN routes and the root a= ddress
=C2=A0 =C2=A0of a given tunnel happens to be the same as the next-hop addre= ss in
=C2=A0 =C2=A0the BGP A-D Route advertising the tunnel, then checking, in un= icast
=C2=A0 =C2=A0routing tables, whether the tunnel root is reachable, will be<= br> =C2=A0 =C2=A0unnecessary duplication and thus will not bring any specific b= enefit.

<mglt>
It seems to me that x-PMSI address
designates a different interface than
the one used by the Tunnel itself. If
that is correct, such mechanisms seems
to assume that one equipment up on one
interface will be up on the other
interfaces. I have the impression that a
configuration change in a PE may end up
in the P-tunnel being down, while the PE
still being reachable though the x-PMSI
Tunnel attribute. If that is a possible
scenario, the current mechanisms may not
provide more efficient mechanism than
then those of the standard BGP.
GIM>> That is a very interesting angle, thank you. Yes, in OAM, = and in the Fault Management (FM) OAM in particular, we have to make some as= sumptions=C2=A0about the state of the remote system based on a single event= or change of state. Usually, AFAIK, operators use not a physical interface but a loopback to associate with a tunnel. Wi= th a fast IGP convergence, a loopback interface is reachable as long as the= re's a path through the network between two nodes.
<mglt>
Thanks for the clarification
</mglt>

Similarly, it is assumed the tunnel is
either up or down and the determination
of not being up if being down.=C2=A0 I am not
convinced that the two only states.
Typically services under DDoS may be
down for a small amount of time. While
this affects the network, there is not
always a clear cut between the PE being
up or down.
</mglt>
GIM>>=C2=A0 In defect detection a system often has some hysteres= is, i.e., time that the system has to wait to change its state. For example= , BFD changes state from Up to Down after the system does not receive N con= secutive packets (usually 3). As a result, in some cases, the system can be tuned to detect relatively short outages = while in others be slower and miss short-lived outages.


[...]

3.1.6.=C2=A0 BFD Discriminator Attribute

=C2=A0 =C2=A0P-tunnel status may be derived from the status of a multipoint= BFD
=C2=A0 =C2=A0session [RFC8562] whose discriminator is advertised along with= an
=C2=A0 =C2=A0x-PMSI A-D Route.

=C2=A0 =C2=A0This document defines the format and ways of using a new BGP =C2=A0 =C2=A0attribute called the "BFD Discriminator".=C2=A0 It i= s an optional
=C2=A0 =C2=A0transitive BGP attribute.=C2=A0 In Section 7.2, IANA is reques= ted to
=C2=A0 =C2=A0allocate the codepoint value (TBA2).=C2=A0 The format of this = attribute is
=C2=A0 =C2=A0shown in Figure 1.

<mglt>
I feel that the sentence "In Section ...
TBA2)." should be removed.

</mglt>
GIM>> We use this to mark where to note the allocated value. Usu= ally, this text is replaced by the RFC Editor to read=C2=A0
In Section 7.2 IANA allocated codepoint XXX.



=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A03
=C2=A0 =C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1
=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 BFD Mode=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Reserved=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=A0BFD Discriminator=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=A0Optional TLVs=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 Figure 1: Format of the BFD Discr= iminator Attribute

=C2=A0 =C2=A0Where:

=C2=A0 =C2=A0 =C2=A0 BFD Mode field is the one octet long.=C2=A0 This speci= fication defines
=C2=A0 =C2=A0 =C2=A0 the P2MP BFD Session as value 1 Section 7.2.

=C2=A0 =C2=A0 =C2=A0 Reserved field is three octets long, and the value MUS= T be zeroed
=C2=A0 =C2=A0 =C2=A0 on transmission and ignored on receipt.

=C2=A0 =C2=A0 =C2=A0 BFD Discriminator field is four octets long.





Morin, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires April = 5, 2021=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page = 7]

Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mVPN Fast Upstream Failover= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 October 2020


=C2=A0 =C2=A0 =C2=A0 Optional TLVs is the optional variable-length field th= at MAY be
=C2=A0 =C2=A0 =C2=A0 used in the BFD Discriminator attribute for future ext= ensions.
=C2=A0 =C2=A0 =C2=A0 TLVs MAY be included in a sequential or nested manner.= =C2=A0 To allow
=C2=A0 =C2=A0 =C2=A0 for TLV nesting, it is advised to define a new TLV as = a variable-
=C2=A0 =C2=A0 =C2=A0 length object.=C2=A0 Figure 2 presents the Optional TL= V format TLV that
=C2=A0 =C2=A0 =C2=A0 consists of:

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 one octet-long field of TLV 's Type value = (Section 7.3)

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 one octet-long field of the length of the Valu= e field in octets

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 variable length Value field.

=C2=A0 =C2=A0 =C2=A0 The length of a TLV MUST be multiple of four octets. <mglt>
I am wondering why the constraint on the
length is not mentioned in the paragraph
associated to the field - as opposed to
a=C2=A0 separate paragraph.

</mglt>
GIM>> There might be a slight confusion due to the use of Length= and length. Capitalized - the name of the field which value is the length = of the Value field. The last sentence refers to the overall length of a TLV= , including lengths of Type, Length and Value fields.

<mglt>
you are correct that might have confused me.=C2=A0
</mglt>

[..]

8.=C2=A0 Security Considerations

=C2=A0 =C2=A0This document describes procedures based on [RFC6513] and [RFC= 6514]
=C2=A0 =C2=A0and hence shares the security considerations respectively repr= esented
=C2=A0 =C2=A0in these specifications.

=C2=A0 =C2=A0This document uses p2mp BFD, as defined in [RFC8562], which, i= n turn,
=C2=A0 =C2=A0is based on [RFC5880].=C2=A0 Security considerations relevant = to each
=C2=A0 =C2=A0protocol are discussed in the respective protocol specificatio= ns.=C2=A0 An
=C2=A0 =C2=A0implementation that supports this specification MUST use a mec= hanism
=C2=A0 =C2=A0to control the maximum number of p2mp BFD sessions that can be= active
=C2=A0 =C2=A0at the same time.

<mglt>
At a high level view - or at least my
interpretation of it - the document
proposes a mechanism based on BFD to
detect fault in the path.=C2=A0 Upon a fault
detection a fail-over operation is
instructed using BGP. This rocedure is
expected to perform a faster fail-over
than traditional BGP convergence on
maintaining routing tables. Once the
fail over has been performed, BFD is
confirms the new path is "legitimate"
and works.

It seems correct to me that the current
protocol relies on BGP / BFD security.
That said, having BFD authentication
based on MD5 or SHA1 may suggest that
stronger primitives be recommended.
While this does not concerns the current
document, it seems to me that the
information might be relayed to routing
ADs.

What remains unclear to me - and I
assume this might be due to my lake or
expertise in routing area - is the impact
associated to performing a fail-over
both on 1) the data plane and 2) the
standard BGP way to establish routing
tables.

Regarding the data plane, I am wondering
if fail-over results in a lost of
packets for example - I suppose for
example that at least the packets in the
process of being forwarded might be
lost. I believe that providing details
on this may be good.
GIM>> You bring up a very topic for the discussion, thank you. W= ith network failure detection in place, the fail-over can be viewed as the = reaction to a network failure.=C2=A0 If that is the case, then packet loss = experienced by service due to the fail-over is the result of the network failure. Would you agree with that view? A sh= orter failure detection interval=C2=A0and faster fail-over should minimize = the packet loss and, as a result, the negative impact on the service itself= .

<mglt>
sure. If you know the network is down, then fast fail-over is definiti= vely a plus. What I think could be useful is to evaluate the cost associate= d to a fast-fail-over without any network failure.=C2=A0 This would be usef= ul for an operator to evaluate whether it should spend more time in diagnosing a network failure versus performin= g a fast-fail-over.=C2=A0
Typically, if a fast failover comes a no cost at all, one operator wou= ld maybe use one exchange to test the liveness of a node rather than 3.=C2= =A0 =C2=A0 =C2=A0=C2=A0

At that point, it seems to me that additional text coudl be added to c= haracterize the impact. These could be high level and indicative, but it se= ems to me that knowing these impacts presents some value to the operators.= =C2=A0 =C2=A0 =C2=A0=C2=A0
</mglt>

If there are any impacts I would like to
understand also in which cases the
decision to perform a failover operation
may result in more harm than the event
that has been over-interpreted. An
hypothetical scenario could be that the
non reception of a BFD packet is
interpreted as a PE being down while it
may not be correct and the PE might have
been simply under stress. A "too fast" fail-over
may over interpreted it and perform a
fail-over. If such things could happen,
an attacker could leverage a micro event
to perform network operation that are
not negligible. Another way to see that
is that an attacker might not have
direct access to the control plan, but
could use the data plan to generate a
stress and sort of control the fail
over. It seems to me that some text
might be welcome to prevent such cases
to happen. This could be guidance for
declaring a tunnel down for example.
GIM>> I agree with your scenario. Over-short detection interval = may produce a false-negative transition to the Down state in BFD and thus t= riggering the fail-over. I think that that is more an operational issue, so= mething that an operator will consider when deploying the mechanism specified in this draft. Resulting from addre= ssing RtgDir review the draft was updated to provide more guidance:
=C2=A0 =C2=A0In many cases, it is not practical to use both protection=
=C2=A0 =C2=A0methods at the same time because uncorrelated timers might cau= se
=C2=A0 =C2=A0unnecessary switchovers and destabilize the network.
<mglt>
Thanks for the feed back, It seems to me important to mention it is no= t recommended these two mechanism co-exist.=C2=A0
How to avoid false negative transition might be out of scope of the dr= aft I agree, but it seems to me worth being mentioned especially in relatio= n to the impacts associated to a fail-over.=C2=A0 In case the fast-failover= comes with no impact this becomes less of a problem for operator deploying it.
=C2=A0
</mglt>
Though the text above might not be general, I think that it also appli= es to the scenario you've presented.

Similarly, it would be good to add some
text regarding the interferences with
the non-fast forwarding fail over when
performed by the standard BGP.
Typically, my impression is that the
fast fail-over mechanism is a local
decision versus the BGP convergence that
is more global. As a result, even with
more time this two mechanisms may come
with different outcomes. One such
example to illustrate my purpose could
be the following. Note that this is only
illustrative of my purpose, and I let
you find and pick on ethat is more
appropriated.=C2=A0 =C2=A0I am thinking of a case
where a standby PE is be shared among
multiple PEs - supposing this situation
could occur.=C2=A0 Typically, if PE_1, PE_2
are shared by PE_a, ..., PE_z. In case
PE_a and PE_b are down, we expect PE_a
to switch to PE_1 and PE_b to switch to
PE_2. It seems to me that BGP would end
up in such situation while a local
decision may end up in PE_a and PE_a to
switch to PE_1.

</mglt>
GIM>> Thank you for the scenario that is very common in deployin= g protection based on the shared redundant resources. Such schemes, referre= d to as M:N protection, in addition to using mechanism detecting a network = failure, e.g., BFD, require a protocol to coordinate the switchover. This specification applies to a more special= deployment scenario where one working PE is protected by one or more stand= by PEs, i.e., 1:N protection.

<mglt>
I understand the document is addressing a 1:N scenario. That said, if = M:N scenario leverage from 1:N protection it seems to me worth raising the = issue.=C2=A0
</mglt>
--00000000000078059905b3efcda5-- From nobody Sun Nov 15 11:53:20 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C423A0995; Sun, 15 Nov 2020 11:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqVc4e9cyWjR; Sun, 15 Nov 2020 11:53:17 -0800 (PST) Received: from smtp82.iad3a.emailsrvr.com (smtp82.iad3a.emailsrvr.com [173.203.187.82]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 755CA3A0991; Sun, 15 Nov 2020 11:53:17 -0800 (PST) Received: from app35.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp27.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 890CF210D7; Sun, 15 Nov 2020 14:53:16 -0500 (EST) Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app35.wa-webapps.iad3a (Postfix) with ESMTP id 76667A0081; Sun, 15 Nov 2020 14:53:16 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Sun, 15 Nov 2020 11:53:16 -0800 (PST) X-Auth-ID: scott@hyperthought.com Date: Sun, 15 Nov 2020 11:53:16 -0800 (PST) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-idr-tunnel-encaps.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain X-Client-IP: 24.23.138.127 Message-ID: <1605469996.482420581@apps.rackspace.com> X-Mailer: webmail/18.1.9-RC X-Classification-ID: b259966a-3b60-4128-b5b2-0465e66a28c6-1-1 Archived-At: Subject: [secdir] secdir review of draft-ietf-idr-tunnel-encaps-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 19:53:19 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments.=0A=0AThe summary of the review is ready.=0A=0AT= his review is more than a month late, and I'm not certain whether it is sti= ll useful, but I'm sending it along to clear it from everyone's backlog.=0A= =0AFrom the abstract, "This document deprecates the Encapsulation SAFI (whi= ch has never been used in production), and specifies semantics for the attr= ibute when it is carried in UPDATEs of certain other SAFIs. This document a= dds support for additional Tunnel Types, and allows a remote tunnel endpoin= t address to be specified for each tunnel. This document also provides sup= port for specifying fields of any inner or outer encapsulations that may be= used by a particular tunnel."=0A=0AIn a nutshell, the document deprecates = one way of defining how to tunnel specific types of traffic, and then defin= es a different way to accomplish this. I'm not a BGP expert, and that's par= t of why it's taken me so long to respond. The main question I have is, doe= s this introduce new ways to attack BGP, ways that have not already been co= nsidered?=0A=0AThe security considerations section says that the tunnel enc= apsulation attribute should only be used within a well-defined scope under = the control of a single administrative entity, and references RFC4272 (BGP = Security Vulnerabilities Analysis). It talks about traffic diversion attack= s, noting that a tunnel encapsulation attribute adds a new way to divert tr= affic. It then describes several mitigation measures.=0A=0ABased on my very= limited understanding of BGP and a quick read of RFC4272, I think the secu= rity considerations are complete, and I see no security issues with this dr= aft.=0A=0A--Scott=0A=0A=0A From nobody Mon Nov 16 20:59:50 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CA63A0D81; Mon, 16 Nov 2020 20:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bq_0OemI7jCK; Mon, 16 Nov 2020 20:59:48 -0800 (PST) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C75E3A0D7E; Mon, 16 Nov 2020 20:59:47 -0800 (PST) Received: from in01.mta.xmission.com ([166.70.13.51]) by out02.mta.xmission.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1ket5l-00CP9U-JV; Mon, 16 Nov 2020 21:59:45 -0700 Received: from [166.70.232.207] (helo=rumpleteazer.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1ket5k-0001N4-Ug; Mon, 16 Nov 2020 21:59:45 -0700 Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 0AH4uQYl022070; Mon, 16 Nov 2020 21:56:26 -0700 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id 0AH4uQAN022069; Mon, 16 Nov 2020 21:56:26 -0700 Date: Mon, 16 Nov 2020 21:56:26 -0700 Message-Id: <202011170456.0AH4uQAN022069@rumpleteazer.rhmr.com> From: "Hilarie Orman" Reply-To: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org Cc: draft-ietf-quic-http.all@ietf.org X-XM-SPF: eid=1ket5k-0001N4-Ug; ; ; mid=<202011170456.0AH4uQAN022069@rumpleteazer.rhmr.com>; ; ; hst=in01.mta.xmission.com; ; ; ip=166.70.232.207; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-AID: U2FsdGVkX18pcbdgU+6FocgaK1Za+t0+ X-SA-Exim-Connect-IP: 166.70.232.207 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-Virus: No X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ****;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 297 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 3.7 (1.2%), b_tie_ro: 2.5 (0.8%), parse: 1.06 (0.4%), extract_message_metadata: 4.5 (1.5%), get_uri_detail_list: 1.33 (0.5%), tests_pri_-1000: 3.0 (1.0%), tests_pri_-950: 1.48 (0.5%), tests_pri_-900: 1.18 (0.4%), tests_pri_-90: 55 (18.5%), check_bayes: 53 (18.0%), b_tokenize: 7 (2.2%), b_tok_get_all: 7 (2.2%), b_comp_prob: 1.57 (0.5%), b_tok_touch_all: 36 (12.2%), b_finish: 0.67 (0.2%), tests_pri_0: 215 (72.5%), check_dkim_signature: 0.34 (0.1%), check_dkim_adsp: 30 (10.0%), poll_dns_idle: 25 (8.5%), tests_pri_10: 2.6 (0.9%), tests_pri_500: 6 (2.2%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Archived-At: Subject: [secdir] Security directorate review of draft-ietf-quic-http-32 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 04:59:49 -0000 Security review of Hypertext Transfer Protocol Version 3 draft-ietf-quic-http-32 Do not be alarmed. I generated this review of this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes "describes a mapping of HTTP semantics over QUIC. [... It] also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to HTTP/3." I would like to see the Security Considerations spell out exactly what security features HTTP expects from QUIC. There are reasonably good Security Consideration sections for both this document and for QUIC transport. The only problem that I have is that the authentication model for QUIC-HTTP is not explicitly spelled out. The only discussion is in section 3.4 Connection Reuse, and although that section may be technically correct, I find it hard to understand. Similarly, there is brief mention of privacy wrt reused connections in 10.11, but that is weak beer, simply saying that HTTP 3 prefers not to reuse connections. And integrity of the data isn't mentioned at all, perhaps because all this is assumed to be provided by QUIC. Section 10.2 says that all QUIC packets are encrypted; I'm not sure if that's true, or if QUIC has an option for "non-modifiable" without encryption. The QUIC draft is 200 pages and is still in progress, ... like a wimp I skimmed it but did not read it in detail. Hilarie From nobody Mon Nov 16 21:29:30 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713D63A0E09; Mon, 16 Nov 2020 21:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org 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 4nLEgFd4kaGY; Mon, 16 Nov 2020 21:29:28 -0800 (PST) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B34D13A0E03; Mon, 16 Nov 2020 21:29:27 -0800 (PST) Received: from [IPv6:2a00:ac00:4000:400:f87a:925d:978e:33a7] (unknown [IPv6:2a00:ac00:4000:400:f87a:925d:978e:33a7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 1F6746104EC; Tue, 17 Nov 2020 07:29:21 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1605590961; bh=QTedjIv/iqGBgPFS0p0tvM8J20L61kReIVLmWWGi7pg=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=Jo2Gu1Nzc6jbtMN+fcfbBtbjz1Cm1bNLWb97XkJvc8Nzqp2r3ZTIRKzQ7vby7SLm3 IQkXSe0t7uM5QGVOnDu4KDj0fi2O6Wirv6LI5C0o2McumDr5onYHthrvb78PelXZ3i AwACroBonSlIxW1e7tkp95I/wjpklu0skmjE0C7c= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7B87C937-A230-40EF-A948-F8BF10FC262C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Tue, 17 Nov 2020 07:29:20 +0200 In-Reply-To: <202011170456.0AH4uQAN022069@rumpleteazer.rhmr.com> Cc: The IESG , secdir@ietf.org, draft-ietf-quic-http.all@ietf.org To: Hilarie Orman References: <202011170456.0AH4uQAN022069@rumpleteazer.rhmr.com> X-MailScanner-ID: 1F6746104EC.A6888 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [secdir] Security directorate review of draft-ietf-quic-http-32 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 05:29:30 -0000 --Apple-Mail=_7B87C937-A230-40EF-A948-F8BF10FC262C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Hilarie, thanks for the review! Since the QUIC WG uses a Github Workflow I've = created a separate issue for each of the items in your review and tagged = you in it, see in-line responses for the precise issue link. All issues = are track in the milestone = https://github.com/quicwg/base-drafts/milestone/10 We'd appreciate it if you could coordinate with the HTTP document editor = via GitHub, on the issue itself and/or any Pull Request that might be = raised to address your comments. On 2020-11-17, at 6:56, Hilarie Orman wrote: >=20 > Security review of Hypertext Transfer Protocol Version 3 > draft-ietf-quic-http-32 >=20 > Do not be alarmed. I generated this review of this document as part > of the security directorate's ongoing effort to review all IETF > documents being processed by the IESG. These comments were written > with the intent of improving security requirements and considerations > in IETF drafts. Comments not addressed in last call may be included > in AD reviews during the IESG review. Document editors and WG chairs > should treat these comments just like any other last call comments. >=20 > This document describes "describes a mapping of HTTP semantics over > QUIC. [... It] also identifies HTTP/2 features that are subsumed by > QUIC, and describes how HTTP/2 extensions can be ported to HTTP/3." >=20 > I would like to see the Security Considerations spell out exactly > what security features HTTP expects from QUIC. >=20 > There are reasonably good Security Consideration sections for > both this document and for QUIC transport. The only problem that > I have is that the authentication model for QUIC-HTTP is not > explicitly spelled out. The only discussion is in section 3.4 > Connection Reuse, and although that section may be technically > correct, I find it hard to understand. https://github.com/quicwg/base-drafts/issues/4362 > Similarly, there is brief > mention of privacy wrt reused connections in 10.11, but that is > weak beer, simply saying that HTTP 3 prefers not to reuse connections. https://github.com/quicwg/base-drafts/issues/4363 > And integrity of the data isn't mentioned at all, perhaps because > all this is assumed to be provided by QUIC. Section 10.2 says that > all QUIC packets are encrypted; I'm not sure if that's true, or if > QUIC has an option for "non-modifiable" without encryption. https://github.com/quicwg/base-drafts/issues/4364 Thanks, Lars > The > QUIC draft is 200 pages and is still in progress, ... like a wimp > I skimmed it but did not read it in detail. >=20 > Hilarie >=20 >=20 >=20 --Apple-Mail=_7B87C937-A230-40EF-A948-F8BF10FC262C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl+zX7AACgkQVLXDCb9w wVe3RhAAk7T09nM5warXb6BzbwGYcV84xjBUWfaFjxaePdaRCZjnNGG/sD/98SKL AkcjNf0MirkrnDSU3U4FUeeYCxrsd90WK/VXH8mbvmI/WtrzA3GmUWbuPE8wscDL uYbgP+rt0whpSs9CL4EG9I0YEgt0wbWQSZMtmE3Y6Mvd1YELQA+nkXBG9TTXEmUh I+2dsHJUVw21qRs27yvfI1dfGelnDGtKaBeV31A1j9RxjpadQXU64pIxahN6Y7HY l3io6ya8wcJXgLj7WurKN6FtVgLYzjQ+iSMEf2IcBALfqpanvra/TYXcjnHKLYvH /Kc1EEXdN1B7MVHFAhODYln/rN3NmWPiEp+UW250lQ8nJE3Qt73nj+tYoOQyQTpB 5IeCId/HQ5WoN37h2tMLD1MmVH6mDagZrdntk+4Bd5jzA8qYeleQKur77j8AmamT 8HNUIa9GI6XvoC4rwEqTy8EGes1m/PLQwWPqf1w8R8KAT/TjrsXxLEhjltmLDV6c ff7yzP4dIxoatCDznhGSf/epPlTvuFhstpmpFRJuzuOjPK4ZAlcoiLyBloN06XLR ct/i8zNZWE0vtEHPY9TjzmuJH4uao7JUFgxHRrRQcMGS8p++ag4fuzc+HeNbv2D5 kQB5KjyjkNtXM/IcM9KVbpKc7iI55QG9pcyZsy1Z9hSyXg0ataI= =CF0C -----END PGP SIGNATURE----- --Apple-Mail=_7B87C937-A230-40EF-A948-F8BF10FC262C-- From nobody Mon Nov 16 21:30:36 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193C23A0E0E; Mon, 16 Nov 2020 21:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org 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 Ds1KVOSbVq-N; Mon, 16 Nov 2020 21:30:32 -0800 (PST) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 383953A0E0A; Mon, 16 Nov 2020 21:30:32 -0800 (PST) Received: from [IPv6:2a00:ac00:4000:400:f87a:925d:978e:33a7] (unknown [IPv6:2a00:ac00:4000:400:f87a:925d:978e:33a7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 2DBBF6104ED; Tue, 17 Nov 2020 07:29:42 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1605590982; bh=dSIbrez94pO32vTvp0JZhJwgV9ZNGASZskF+S7n1ggw=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=0UnfkwkYgZC5gVW5Xmfgwa+7cCrNhKC0EucnEGgaV+KTT8dN9HpuVMwtzsT48dwLi 1cI9U7EXgLKfIb8MJ/uj7BTSQDSpuYTB0lfBvD2X/8MCYB38XRMU05ctnyG7ot8EkR qtWeESiS4/B/lCiiLS+J9nMFj6VWu3ob8vMxRUlI= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_836BAB18-D5F9-40BD-B713-BDEBCDAB1716"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Tue, 17 Nov 2020 07:29:41 +0200 In-Reply-To: <202011170456.0AH4uQAN022069@rumpleteazer.rhmr.com> Cc: The IESG , secdir@ietf.org, draft-ietf-quic-http.all@ietf.org, QUIC WG To: Hilarie Orman References: <202011170456.0AH4uQAN022069@rumpleteazer.rhmr.com> X-MailScanner-ID: 2DBBF6104ED.A8B56 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [secdir] Security directorate review of draft-ietf-quic-http-32 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 05:30:34 -0000 --Apple-Mail=_836BAB18-D5F9-40BD-B713-BDEBCDAB1716 Content-Type: multipart/alternative; boundary="Apple-Mail=_48C9C044-B672-48BF-BC92-EC41E3D221A2" --Apple-Mail=_48C9C044-B672-48BF-BC92-EC41E3D221A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [CC'ing the WG] Hi Hilarie, thanks for the review! Since the QUIC WG uses a Github Workflow I've = created a separate issue for each of the items in your review and tagged = you in it, see in-line responses for the precise issue link. All issues = are track in the milestone = https://github.com/quicwg/base-drafts/milestone/10 = We'd appreciate it if you could coordinate with the HTTP document editor = via GitHub, on the issue itself and/or any Pull Request that might be = raised to address your comments. On 2020-11-17, at 6:56, Hilarie Orman > wrote: >=20 > Security review of Hypertext Transfer Protocol Version 3 > draft-ietf-quic-http-32 >=20 > Do not be alarmed. I generated this review of this document as part > of the security directorate's ongoing effort to review all IETF > documents being processed by the IESG. These comments were written > with the intent of improving security requirements and considerations > in IETF drafts. Comments not addressed in last call may be included > in AD reviews during the IESG review. Document editors and WG chairs > should treat these comments just like any other last call comments. >=20 > This document describes "describes a mapping of HTTP semantics over > QUIC. [... It] also identifies HTTP/2 features that are subsumed by > QUIC, and describes how HTTP/2 extensions can be ported to HTTP/3." >=20 > I would like to see the Security Considerations spell out exactly > what security features HTTP expects from QUIC. >=20 > There are reasonably good Security Consideration sections for > both this document and for QUIC transport. The only problem that > I have is that the authentication model for QUIC-HTTP is not > explicitly spelled out. The only discussion is in section 3.4 > Connection Reuse, and although that section may be technically > correct, I find it hard to understand. https://github.com/quicwg/base-drafts/issues/4362 = > Similarly, there is brief > mention of privacy wrt reused connections in 10.11, but that is > weak beer, simply saying that HTTP 3 prefers not to reuse connections. https://github.com/quicwg/base-drafts/issues/4363 = > And integrity of the data isn't mentioned at all, perhaps because > all this is assumed to be provided by QUIC. Section 10.2 says that > all QUIC packets are encrypted; I'm not sure if that's true, or if > QUIC has an option for "non-modifiable" without encryption. https://github.com/quicwg/base-drafts/issues/4364 = Thanks, Lars > The > QUIC draft is 200 pages and is still in progress, ... like a wimp > I skimmed it but did not read it in detail. >=20 > Hilarie --Apple-Mail=_48C9C044-B672-48BF-BC92-EC41E3D221A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
[CC'ing the = WG]

Hi Hilarie,

thanks = for the review! Since the QUIC WG uses a Github Workflow I've created a = separate issue for each of the items in your review and tagged you in = it, see in-line responses for the precise issue link. All issues are = track in the milestone https://github.com/quicwg/base-drafts/milestone/10

We'd appreciate it if you could coordinate = with the HTTP document editor via GitHub, on the issue itself and/or any = Pull Request that might be raised to address your comments.

On 2020-11-17, at 6:56, Hilarie Orman <hilarie@purplestreak.com> wrote:

 Security review of = Hypertext Transfer Protocol Version 3
 draft-ietf-quic-http-32

Do not be alarmed.  I generated this = review of this document as part
of the security = directorate's ongoing effort to review all IETF
documents = being processed by the IESG.  These comments were written
with the intent of improving security requirements and = considerations
in IETF drafts.  Comments not = addressed in last call may be included
in AD reviews = during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call = comments.

This document describes = "describes a mapping of HTTP semantics over
QUIC. =  [... It]  also identifies HTTP/2 features that are subsumed = by
QUIC, and describes how HTTP/2 extensions can be ported = to HTTP/3."

I would like to see the = Security Considerations spell out exactly
what security = features HTTP expects from QUIC.

There are = reasonably good Security Consideration sections for
both = this document and for QUIC transport. The only problem that
I have is that the authentication model for QUIC-HTTP is = not
explicitly spelled out.  The only discussion is = in section 3.4
Connection Reuse, and although that section = may be technically
correct, I find it hard to = understand.

https://github.com/quicwg/base-drafts/issues/4362

Similarly, = there is brief
mention of privacy wrt reused connections = in 10.11, but that is
weak beer, simply saying that HTTP 3 = prefers not to reuse connections.

https://github.com/quicwg/base-drafts/issues/4363

And = integrity of the data isn't mentioned at all, perhaps because
all this is assumed to be provided by QUIC.  Section = 10.2 says that
all QUIC packets are encrypted; I'm not = sure if that's true, or if
QUIC has an option for = "non-modifiable" without encryption.

https://github.com/quicwg/base-drafts/issues/4364

Thanks,
Lars

The
QUIC = draft is 200 pages and is still in progress, ... like a wimp
I skimmed it but did not read it in detail.

Hilarie
= --Apple-Mail=_48C9C044-B672-48BF-BC92-EC41E3D221A2-- --Apple-Mail=_836BAB18-D5F9-40BD-B713-BDEBCDAB1716 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl+zX8UACgkQVLXDCb9w wVfJ5BAAk40cg1f/yNmjIlZ4YOuKjAvPHYd1e2tvb641n7ivkUQcRe9Fl4Kl98D4 J+9abHWAB62pIIaLINRN+/ebFpEf6INAD3AJrfTOBkAU/9yY0kSgfTUqnMpI8JfK Xvmqzm4fOZk0QkQ7hypVxI9pXNc+aAuSzmbM21rByLIz7Zr6MjbFbCL4QEwuLXd7 g+0yWIC6GM7aCZBjJtp9WOOcJpTifm3DzT6MUpF7dgyHqjS8uJBD4t1rMevKdVJ8 mX6hjgDUPQxVR/4dZ2pzP0DuotQmhCxSx+J4pu+Kp4OCj7cSy/iuMIgbmkGecvRz Pmu1JKLP4OZE1X1El6hsi5SSOUGwSWhIO/HBMdLovn1WXr57D7SBknQ4byB1gH+Y tRfTq8thc8HuQ11Z8FOQxeNxqflL5Fe1vXpzFQ+LFHCmSqYBRFMtAQLa6S6ITIyM 5jaB4FpIS3OnW3mVOL6cHAy1Rc4BMMzl1sfSSk/QjZvKBjFaQEpft0fxzQNlAUmC qA8KoE+6Eq5QLhg8eAfvq0wlGugEh5Cxh1agPDRWPfDaavnq7cghE4hFK1rLdw0k u9mDnLZG15+Z5wWOMdwOkJAdEAGk68wPABOLDH0ZnE1mjzKuFZdH+rDyVQ+t6gaV 97BfSWON7ggbuCc48t1eU4CgMwi36vmuWA+PhpgttQZog/u3sYM= =f0Rz -----END PGP SIGNATURE----- --Apple-Mail=_836BAB18-D5F9-40BD-B713-BDEBCDAB1716-- From nobody Wed Nov 18 14:24:34 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 113D03A0DEE; Wed, 18 Nov 2020 14:24:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Catherine Meadows via Datatracker To: Cc: 6lo@ietf.org, draft-ietf-6lo-blemesh.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160573826402.16462.7124606612381130154@ietfa.amsl.com> Reply-To: Catherine Meadows Date: Wed, 18 Nov 2020 14:24:24 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-6lo-blemesh-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 22:24:24 -0000 Reviewer: Catherine Meadows Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies mechanisms that are needed to enable IPv6 mesh topologies over Bluetooth Low Energy Links established using the Bluetooth Internet Protocol Support Profile. It does not specify the routing protocol to be used in an IPv6, and it does not specify security mechanisms. In the Security Considerations Section the document directs the reader to the relevant documents. For most security issues, it points the reader to RFC 7668, “IPv6 over BLUETOOTH(R) Low Energy.” For security issues produced by the routing protocol, the reader is directed to RFC 7416, “ A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs)”, and it is noted that the issues addressed in that RFC are useful for other low energy routing protocols as well. Finally it is noted that the Registration Ownership Verifier (ROVR) field can be derived from the Bluetooth address, and that this field is also subject to impersonation and spoofing. For this the document refers the reader the Internet Draft on "Address Protected Neighbor Discovery for Low-power and Lossy Networks.” I think that this document does an excellent job of identifying the relevant security issues to related to its topic, and of directing the reader to the relevant documents. I consider this document Ready. From nobody Wed Nov 18 16:34:21 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 054E33A1033; Wed, 18 Nov 2020 16:34:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Derrell Piper via Datatracker To: Cc: last-call@ietf.org, draft-ietf-suit-information-model.all@ietf.org, suit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160574605497.24260.13971208595707468000@ietfa.amsl.com> Reply-To: Derrell Piper Date: Wed, 18 Nov 2020 16:34:15 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-suit-information-model-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 00:34:15 -0000 Reviewer: Derrell Piper Review result: Not Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is: Not Ready Caveat: I found this document difficult. I've not previously encountered an "Informational Model" like this one, and I have not been following IoT. If these comments sound completely unhelpful then I may just not be the right person to review this informational model. I would prefer MAY, MUST, or SHOULD be used consistently instead of OPTIONAL and RECOMMENDED. Both are used here. The draft is split into five lists, with 10 pages of Manifest Information Element descriptions presumably forming the basis of the draft, but followed by the bulk of the document as the Security Consideratios section. I found the organization confusing, too abstract, and somewhat circular. In summary: o manifest elements satisfy one or more requirements o threats are mitigated by one or more requirements o security requirements (REQ.SEC) mitigate one or more threats o user stories are satisfied by one or more usability requirements o usability requirements (REQ.USE) satisfy user stories pp.7 "the DNS name space ID" This implies private DNS namespace may be a concern, and I'd like to understand why and how, because this is based on Trust Anchors as described in RFC6024. What other DNS namespaces are under consideration? pp.17, "This model uses the S.T.R.I.D.E. approach" Microsoft's STRIDE Threat Model defines six types of threats: identity spoofing, data tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Why call out this particular approach? There may be traffic analysis and fingerprinting concerns if the manifest is not encrypted, specifically if the vendor IDs are sent unencrypted. pp.10, "...that version MUST be specified" It MUST be specified IF, but the element is OPTIONAL? pp.10 Manifest Element: Expiration Time Time is mentioned but no time format is specified. Is synchronized time a security requirement, and should specific time formats be specified? pp.32 4.4.3, "Satisfied by USER_STORY.OVERRIDE (Section 4.4.3)" Section 4.4.3 is circular (satisfies itself) Derrell From nobody Wed Nov 18 22:00:05 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D3E3A0E29 for ; Wed, 18 Nov 2020 22:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ckqPO8ErNpM for ; Wed, 18 Nov 2020 22:00:02 -0800 (PST) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B91C13A0E28 for ; Wed, 18 Nov 2020 22:00:02 -0800 (PST) Received: by mail-il1-x12d.google.com with SMTP id w8so4224712ilg.12; Wed, 18 Nov 2020 22:00:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=rhru7VH0ahCYqg2KFM+k25YtGx85LRxu6apxl8gdhnY=; b=jrF71OS5LP02pHKiRzzYD+7DzZ5EkEm1bj954UoIC3uv1IyoT4IG4k75iUgxdXhh3v JtcO03suW2Ufo9vZi8oiMk+4+5IODg+3rKMxBZuCqhiOqlqN6MCyaZK2vCnUXh5SyhOk el3Dp3xHxIIlYvEboH2tS/pPvilBDgvex08hfoKXyRgllQXmsr+w2msaQj2NV1wbmtUf OyeocKiCyNl7gj8vsFnOuweqerbHAX62WkKSem8iN8oRuqOOReHwhfnze0n8y60AVodn WMj3oB+4nlBSQL3mpEDaL0I64z4YdwF2O6a9zRInu0JQ2NtwCKTc7vRn3XLyGDQPd3SQ T7Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=rhru7VH0ahCYqg2KFM+k25YtGx85LRxu6apxl8gdhnY=; b=Iif9Y0FI8q9KjbaQKLsskyKZN3DcmicYQ9KGW2RPtSBforomAgbNDgSmdccLHIHlYj Z0jYuKJfHB2YNNo/yaaxPBYXPOt5sS31vXrjoACjhIvOoBZYGuM9lBf8f24sj6WIvvjN Tvr4t96faRg5WW41qbIlqRener7s0evd/k6lEDXoJv2Of4e7z6xBRhpICEQsw8gIzPES xPr5TrjO511nGafYhCb+MI30E5mmzHELVPo5w6Ry04H2V24k/3A+pmLN5UtjeKXuMH29 Kdkb4DGzQXgjVW16MJHHxJsg5y2M6JC9kjMKygiHtaIH7Q7oWW3YUUWrrV+D9pUT/5EP 0ZFA== X-Gm-Message-State: AOAM533YmA7omq4o9T7n30iSp6fwai9KCdoxVExMTSEGTI8lmpOqteSH r745aeifTA8qOO+uSUFhzMmnRiUpFwBJW3dh3Q4/ZdNr X-Google-Smtp-Source: ABdhPJyzu6FAG4jTzPM65VJbWdNeF0ZhFqbtN+OvUPwp1yC6qxuhriN0jLK8SkgQLmxBHw3+cTb2dDtbdv62vhq2Vu4= X-Received: by 2002:a92:a1c8:: with SMTP id b69mr4242666ill.186.1605765601865; Wed, 18 Nov 2020 22:00:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Wed, 18 Nov 2020 21:59:50 -0800 Message-ID: To: secdir@ietf.org, draft-ietf-quic-qpac@ietf.org Content-Type: multipart/alternative; boundary="0000000000004ab34f05b46f70c7" Archived-At: Subject: [secdir] Secdir review of draft-ietf-quic-qpack X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 06:00:05 -0000 --0000000000004ab34f05b46f70c7 Content-Type: text/plain; charset="UTF-8" I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a mechanism for compressing HTTP fields in the context of HTTP/3. - The security considerations section is well written, but the attack scenario of "mutual distrustful parties" is unclear to me. One stated scenario is where multiple client connections aggregate at an intermediary that then maintains a single connection to an origin server. Another stated scenario is where multiple origin servers connect to an intermediary which then serves a client. In these scenarios, is the concern that the intermediary may control either a client or an origin server and thus would be able to leverage the compression context at, say, a second client and then observe (as the intermediary) the result of a guess for a field tuple? It may be helpful to explain this in a little more detail. While there are several options listed, there is also no recommendation as to what strategy (option) implementations should choose to protect against this attack. It seems like the Never-Indexed-Literal is a good candidate which should be easy to implement. - For Section 7.5, is it intended to communicate that an attacker will not be able (based on no current known attack against static Huffman encodings) to mount the previously described "probing" attack? If so, adding a sentence at the end of the section along the lines of "Thus, the previously mentioned probing attack is not known to be applicable for any fields where static Huffman encoding is used." Thanks, -- Magnus --0000000000004ab34f05b46f70c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= div class=3D"gmail_quote">
I have reviewed this document as part of the security directorate's ong= oing effort to review all IETF documents being processed by the IESG. These= comments were written primarily for the benefit of the security area direc= tors.=C2=A0 Document editors and WG chairs should treat these comments just= like any other last call comments.

This document describes a mechanism for compressing HTT= P fields in the context of HTTP/3.
<= /div>
  • The security considerations section is well writte= n, but the attack scenario of "mutual distrustful parties" is unc= lear to me. One stated scenario is where multiple client connections aggreg= ate at an intermediary that then maintains a single connection to an origin= server. Another stated scenario is where multiple origin servers connect t= o an intermediary which then serves a client. In these scenarios, is the co= ncern that the intermediary may control either a client or an origin server= and thus would be able to leverage the compression context at, say, a seco= nd client and then observe (as the intermediary) the result of a guess for = a field tuple? It may be helpful to explain this in a little more detail.
    While there are several options listed, there is also no recommendati= on as to what strategy (option) implementations should choose to protect ag= ainst this attack. It seems like the Never-Indexed-Literal is a good candid= ate which should be easy to implement.
  • For Section 7.5, is it inten= ded to communicate that an attacker will not be able (based on no current k= nown attack against static Huffman encodings) to mount the previously descr= ibed "probing" attack? If so, adding a sentence at the end of the= section along the lines of "Thus, the previously mentioned probing at= tack is not known to be applicable for any fields where static Huffman enco= ding is used."
Thanks,
<= div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature= ">-- Magnus
--0000000000004ab34f05b46f70c7-- From nobody Wed Nov 18 22:15:09 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68843A0E67; Wed, 18 Nov 2020 22:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkb0Nmx2jfRZ; Wed, 18 Nov 2020 22:15:06 -0800 (PST) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADA353A0E66; Wed, 18 Nov 2020 22:15:06 -0800 (PST) Received: by mail-il1-x136.google.com with SMTP id l13so4297703ilg.3; Wed, 18 Nov 2020 22:15:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=t/BK0Yi0OcZNMoh5Lhs2huZ5tvWnkl8zM4tpC08ANYM=; b=ZfHAeb9l0/W6nJXGoF0vc47NxH9cvMaUIU/P9ELBzqVswba76BnmbpeMpsfxk72XD8 KsBy9csm+YiHiCE6Tzlz6W9+bN1nj2zlK5cMSodFsPnJrpLcAZx5AIaJqKfWflJGQRci ziq3aR/HokJi6gA7m2Q9n3COP22vq5KrR5A+ukgOVTuCie3zMrHnfPPvzZPI73tfY3p7 IrLQHHplu6DDCDEgpL8riaNws7tSxkY+wEDrAZ5QtdMKX1qgwwmCBz80fxR69lkONUzH Qjcew++lvju/AucfMmM3Y8QpC5S2lBGp9GZeK0JAylCSO1CbdVHaFCfCnZOw4lSsFnQP d8zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=t/BK0Yi0OcZNMoh5Lhs2huZ5tvWnkl8zM4tpC08ANYM=; b=LjoA12rdCIW2dvaCZgoZLFR/kxnPS7pjX9dOjVrlb7PkVShJ2RS+q7s6QJ3ckbizPM VDuJ/1Y+nL56BNl0eAe5i8HKMTlxTRDAA+9ZrlraoK7ve6PTBtv9IqA1bZxag45TqjA8 n6YrEQ6eGKWa95/aRdqFQFCLG2zH/nJaO1fFIM0P2+NKILUV+ZHBVaW+OGa7/5EOcZYv Mv3cF67e4ZeeAaZYucQDAtskRlhCH9yHm4vHTBw5tVwB/Bxwqxx/Zn+N+Q3hN+GRv3Z/ CY4JWRl5+8I5msKHETmWo8rwMPpOYsfJpBPavhPB3XLqyCOS6Lj0DvwliMAqGuYptpsJ gLHg== X-Gm-Message-State: AOAM531aprcLHisoUsWvGcecCr362dwQ4Kii2ZNssUDpxwP6hvBskWkT FVzgQ2ewRdCCCDEkfYFjn/c/EBFGDPObl6/qbdE03n7Q X-Google-Smtp-Source: ABdhPJxi9O71XrjMDjk9ZPNMBgLkj4Gd/IyYP0qb0tazE7gRVJ3ih1wZ9ADWno5e9XtJv42hyVpbxovkeJsQY3LoMeo= X-Received: by 2002:a92:a1c8:: with SMTP id b69mr4310770ill.186.1605766505763; Wed, 18 Nov 2020 22:15:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Wed, 18 Nov 2020 22:14:54 -0800 Message-ID: To: secdir@ietf.org, draft-ietf-quic-qpack@ietf.org Content-Type: multipart/alternative; boundary="0000000000002b1ad605b46fa611" Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-quic-qpack X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 06:15:08 -0000 --0000000000002b1ad605b46fa611 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Correcting qpack ietf email address, sorry. On Wed, Nov 18, 2020 at 9:59 PM Magnus Nystr=C3=B6m wro= te: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security are= a > directors. Document editors and WG chairs should treat these comments ju= st > like any other last call comments. > > This document describes a mechanism for compressing HTTP fields in the > context of HTTP/3. > > - The security considerations section is well written, but the attack > scenario of "mutual distrustful parties" is unclear to me. One stated > scenario is where multiple client connections aggregate at an intermed= iary > that then maintains a single connection to an origin server. Another s= tated > scenario is where multiple origin servers connect to an intermediary w= hich > then serves a client. In these scenarios, is the concern that the > intermediary may control either a client or an origin server and thus = would > be able to leverage the compression context at, say, a second client a= nd > then observe (as the intermediary) the result of a guess for a field t= uple? > It may be helpful to explain this in a little more detail. > > While there are several options listed, there is also no > recommendation as to what strategy (option) implementations should cho= ose > to protect against this attack. It seems like the Never-Indexed-Litera= l is > a good candidate which should be easy to implement. > - For Section 7.5, is it intended to communicate that an attacker will > not be able (based on no current known attack against static Huffman > encodings) to mount the previously described "probing" attack? If so, > adding a sentence at the end of the section along the lines of "Thus, = the > previously mentioned probing attack is not known to be applicable for = any > fields where static Huffman encoding is used." > > Thanks, > -- Magnus > --0000000000002b1ad605b46fa611 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Correcting qpack ietf email address, sorr= y.

On Wed, Nov 18, 2020 at 9:59 PM Magnus Nystr=C3=B6m <magnusn@gmail.com> wrote:
I have reviewed this document as part of the security directorate's ong= oing effort to review all IETF documents being processed by the IESG. These= comments were written primarily for the benefit of the security area direc= tors.=C2=A0 Document editors and WG chairs should treat these comments just= like any other last call comments.

This document describes a mechanism for compressing HTT= P fields in the context of HTTP/3.
<= /div>
  • The security considerations section is well writte= n, but the attack scenario of "mutual distrustful parties" is unc= lear to me. One stated scenario is where multiple client connections aggreg= ate at an intermediary that then maintains a single connection to an origin= server. Another stated scenario is where multiple origin servers connect t= o an intermediary which then serves a client. In these scenarios, is the co= ncern that the intermediary may control either a client or an origin server= and thus would be able to leverage the compression context at, say, a seco= nd client and then observe (as the intermediary) the result of a guess for = a field tuple? It may be helpful to explain this in a little more detail.
    While there are several options listed, there is also no recommendati= on as to what strategy (option) implementations should choose to protect ag= ainst this attack. It seems like the Never-Indexed-Literal is a good candid= ate which should be easy to implement.
  • For Section 7.5, is it inten= ded to communicate that an attacker will not be able (based on no current k= nown attack against static Huffman encodings) to mount the previously descr= ibed "probing" attack? If so, adding a sentence at the end of the= section along the lines of "Thus, the previously mentioned probing at= tack is not known to be applicable for any fields where static Huffman enco= ding is used."
Thanks,
<= div dir=3D"ltr">-- Magnus
--0000000000002b1ad605b46fa611-- From nobody Thu Nov 19 06:42:39 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4173A0408 for ; Thu, 19 Nov 2020 06:42:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <160579695802.21797.313059238144724560@ietfa.amsl.com> Date: Thu, 19 Nov 2020 06:42:38 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 14:42:39 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-12-03 Reviewer LC end Draft Daniel Gillmor 2020-09-30 draft-ietf-ccamp-layer0-types-08 Steve Hanna 2020-09-30 draft-ietf-ccamp-wson-yang-27 Joseph Salowey R2020-10-28 draft-ietf-anima-grasp-api-08 Christopher Wood R2019-11-06 draft-ietf-dtn-tcpclv4-23 For telechat 2020-12-17 Reviewer LC end Draft Daniel Migault R2020-10-19 draft-ietf-bess-mvpn-fast-failover-13 Mališa Vučinić None draft-ietf-bmwg-b2b-frame-03 Last calls: Reviewer LC end Draft Derek Atkins R2020-09-04 draft-ietf-i2nsf-sdn-ipsec-flow-protection-12 Daniel Franke 2020-09-18 draft-ietf-jmap-mdn-15 Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-10 Daniel Gillmor 2020-09-30 draft-ietf-ccamp-layer0-types-08 Phillip Hallam-Baker 2020-09-30 draft-ietf-lwig-tcp-constrained-node-networks-13 Steve Hanna 2020-09-30 draft-ietf-ccamp-wson-yang-27 Dan Harkins None draft-ietf-rtgwg-policy-model-03 Leif Johansson 2020-10-02 draft-ietf-lpwan-schc-over-lorawan-13 Daniel Migault R2020-10-19 draft-ietf-bess-mvpn-fast-failover-13 Adam Montville 2020-11-30 draft-ietf-tls-oldversions-deprecate-09 Kathleen Moriarty 2020-07-20 draft-ietf-ace-oscore-profile-13 Russ Mundy 2020-07-20 draft-ietf-ace-dtls-authorize-14 Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer-05 Tirumaleswar Reddy.K 2020-11-16 draft-ietf-quic-transport-32 Joseph Salowey R2020-10-28 draft-ietf-anima-grasp-api-08 Rich Salz R2020-08-14 draft-ietf-suit-architecture-14 Sean Turner 2020-12-01 draft-ietf-ipsecme-ipv6-ipv4-codes-05 Mališa Vučinić None draft-ietf-bmwg-b2b-frame-03 Carl Wallace 2020-12-09 draft-ietf-roll-unaware-leaves-23 Samuel Weiler 2020-12-02 draft-ietf-extra-sieve-mailboxid-05 Brian Weis 2020-12-02 draft-ietf-core-dev-urn-08 Klaas Wierenga 2020-12-02 draft-ietf-core-echo-request-tag-11 Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth-09 Christopher Wood 2020-09-23 draft-ietf-6man-rfc4941bis-12 Christopher Wood R2019-11-06 draft-ietf-dtn-tcpclv4-23 Paul Wouters 2020-11-30 draft-ietf-tcpm-rack-13 Paul Wouters 2020-09-08 draft-ietf-i2nsf-capability-data-model-13 Liang Xia 2020-11-30 draft-ietf-spring-sr-yang-23 Early review requests: Reviewer Due Draft Nancy Cam-Winget 2020-12-07 draft-ietf-idr-ext-opt-param-09 Linda Dunbar 2020-12-07 draft-ietf-idr-bgp-optimal-route-reflection-21 Dacheng Zhang 2020-12-07 draft-ietf-idr-eag-distribution-13 Next in the reviewer rotation: Donald Eastlake Shawn Emery Stephen Farrell Daniel Franke Daniel Gillmor Phillip Hallam-Baker Steve Hanna Dan Harkins Russ Housley Christian Huitema From nobody Thu Nov 19 06:59:01 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E7F3A12D9; Thu, 19 Nov 2020 06:58:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Derek Atkins via Datatracker To: Cc: draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org, last-call@ietf.org, i2nsf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160579792461.16428.2780947461207565003@ietfa.amsl.com> Reply-To: Derek Atkins Date: Thu, 19 Nov 2020 06:58:44 -0800 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 14:58:52 -0000 Reviewer: Derek Atkins Review result: Ready I have reviewed the changes between -08 and -12; my nits have been fixed and I did not notice any additional issues. From nobody Thu Nov 19 07:08:50 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C305D3A09A8; Thu, 19 Nov 2020 07:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=N+YRUHYC; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=N+YRUHYC 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 je_twR6LmmjY; Thu, 19 Nov 2020 07:08:45 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30056.outbound.protection.outlook.com [40.107.3.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F3C3A09C4; Thu, 19 Nov 2020 07:08:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6VTXT+GVUdiy9zJ2mOA5YU4eAwPNbvZFH9VzAU/ko8M=; b=N+YRUHYCWEyr+xFqWHU5rqA11k2nGN2zKgV5DnaWFS/HtcP8zX6c12Q135pFn155glxwOseoO7btw1LckFo8z7Hdo29x6Am6gvqqpSes+Tgi8dRBdjSeKkfhGFKfIyzSxiGrpOo+TAoW99UWUlLDlhiZ0QJhYZJILymtjXT52fo= Received: from DB6P195CA0021.EURP195.PROD.OUTLOOK.COM (2603:10a6:4:cb::31) by VI1PR0801MB2061.eurprd08.prod.outlook.com (2603:10a6:800:8e::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20; Thu, 19 Nov 2020 15:08:38 +0000 Received: from DB5EUR03FT049.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:cb:cafe::30) by DB6P195CA0021.outlook.office365.com (2603:10a6:4:cb::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Thu, 19 Nov 2020 15:08:38 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT049.mail.protection.outlook.com (10.152.20.191) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Thu, 19 Nov 2020 15:08:38 +0000 Received: ("Tessian outbound fcd5bc555ddc:v71"); Thu, 19 Nov 2020 15:08:38 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: e68948a0b505df4d X-CR-MTA-TID: 64aa7808 Received: from 903bdaf8dd7b.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 6B2B8915-A5C4-4C36-90E8-D1D16A1B8A1D.1; Thu, 19 Nov 2020 15:08:20 +0000 Received: from EUR03-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 903bdaf8dd7b.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 19 Nov 2020 15:08:20 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XMi9UoDz3qP2uItEDekHutWz9voGyoYtASNZ1ur7kN+Fxok/U6gFxSQdEbti5/ockARNYzgzaLz6h6lVxb+cGc+RiTpSMQE9EcfeHlQmv4JfyPkMbuGCm0LFHVMzaKya1Zugd/2RFUrtFl57X0lSqMWJJIk2HU/oTCsNKOX7f2DS2njiB7VzjoyVsz9yOZvCWPbkGNSI9GL6tuKhNULp75f10c/J2WU09SJVKJmxnsd+yLjXwlz50z6BNjc4BgvjEnN+tcITmG5lJn38pR8zdYGLNzGsF0JZgWhuvpBS1Aj5xFZBhvV0sDBOeniBqnrIDuwkMS3p08NPoRIeDvAjGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6VTXT+GVUdiy9zJ2mOA5YU4eAwPNbvZFH9VzAU/ko8M=; b=QqHVSJeUiS2k/Vu7ivoszrhWt6s+NZXH6z83/xX0U5RMTw8d47pD4xNrXaVClabe6QAAq9bjd0AnsPD0cxUGwZUs2D5J87ddieHYEDe2W+2zi+RC7f9e1oYA2TjAo/05sql+U+g6ciYx2/Dce3Om6px3yo/IUXdsycTNoIH/FmMAC14Yxsq5GnsFoJVtCqG1/U8zPDexVzgeRin3t+FnTftdofRovyNEgDRw2S96SnUcq0o2e2d3sTZJkBFlGstxhTW2gOa+zEX5rXnejy1uWawvrgOnXLacAULuFFrX4gkS7IPH4D/4gsutJjFp6sqizwqxGSQr+KftGviRs1lBaA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6VTXT+GVUdiy9zJ2mOA5YU4eAwPNbvZFH9VzAU/ko8M=; b=N+YRUHYCWEyr+xFqWHU5rqA11k2nGN2zKgV5DnaWFS/HtcP8zX6c12Q135pFn155glxwOseoO7btw1LckFo8z7Hdo29x6Am6gvqqpSes+Tgi8dRBdjSeKkfhGFKfIyzSxiGrpOo+TAoW99UWUlLDlhiZ0QJhYZJILymtjXT52fo= Received: from AM9PR08MB6146.eurprd08.prod.outlook.com (2603:10a6:20b:2db::17) by AM9PR08MB6163.eurprd08.prod.outlook.com (2603:10a6:20b:2de::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20; Thu, 19 Nov 2020 15:08:19 +0000 Received: from AM9PR08MB6146.eurprd08.prod.outlook.com ([fe80::c848:df2:1b39:78d5]) by AM9PR08MB6146.eurprd08.prod.outlook.com ([fe80::c848:df2:1b39:78d5%4]) with mapi id 15.20.3589.021; Thu, 19 Nov 2020 15:08:19 +0000 From: Brendan Moran To: Derrell Piper CC: "secdir@ietf.org" , "draft-ietf-suit-information-model.all@ietf.org" , "last-call@ietf.org" , "suit@ietf.org" Thread-Topic: [Suit] Secdir last call review of draft-ietf-suit-information-model-08 Thread-Index: AQHWvgvPhlBbsjTKVUWq+88B5DBW36nPj4mA Date: Thu, 19 Nov 2020 15:08:19 +0000 Message-ID: <7BD14CD2-1CD2-4307-966E-637211539F6B@arm.com> References: <160574605497.24260.13971208595707468000@ietfa.amsl.com> In-Reply-To: <160574605497.24260.13971208595707468000@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.120.23.2.1) Authentication-Results-Original: electric-loft.org; dkim=none (message not signed) header.d=none;electric-loft.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.7.184.196] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 310d9537-b12f-4fa1-80f0-08d88c9cfe6e x-ms-traffictypediagnostic: AM9PR08MB6163:|VI1PR0801MB2061: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: jGuIDJqRvoTAyXFNIsZUpLR9tlgaIs65LxXppgmeFgU7TKMVybTaHQAAr558KqAHjervXFXjz9eE8YsQ07xOQ7bgpKwxpg0UNdKPoHcOAxqSwkSH/MpkDco2zLY6NGtQWlnDVL0TgKUe2lCBMs7L1dXUtv7GsgXZ6q5TGUHt6jmqUcJBcA5FtJu+skF/5UWgptIwPG8a7Ku2PRKoRTW+6HHCbQheYmtgkGpDprj/wNwpSwDDjINSUUJ10+i5Ib6/uOavVbWCsIb+yJ9ri+y8XNTqNezteHnS1bsxT0RezpJWnfMT7nrQV0J667/0FitDov95XjQ022BNTwOVbKc5G4ONJbJevfrfPPzV3VjuMmH9OSLD6mtZjCMRQJr+SDxqoP8dBpcLOBXDt5tdk8DkSw== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM9PR08MB6146.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(376002)(346002)(366004)(136003)(396003)(6486002)(86362001)(8676002)(53546011)(8936002)(26005)(6506007)(6512007)(6916009)(36756003)(478600001)(83380400001)(5660300002)(66446008)(54906003)(316002)(966005)(45080400002)(2906002)(91956017)(186003)(64756008)(4326008)(71200400001)(2616005)(66556008)(33656002)(66476007)(66946007)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: byoVf+Ij9t+5mLfVS6q6IiWJv34HdaG7mbSmDL1NSFpeyEZyOpkk+JW2L1QXnSxfD7Lnyrj762SkfDqXfuuPYtecU5lHsTZjeYjxETJZc06wTH6aYo7a6x2KPZr2DhLS1yg8CzqURZVCz3CKKCzx6zGqCUPSfnREkTxqAW4y7IXhQk7gOddLnQY7jsoIBXQQvzIfz7x4/EcZZFiahmVh2DEm70YNfrlkfjnWIImO1n5I9XBdopmAEqGEsf2GGAoHG1Y3f8N5QKp4xVSW1QjvqAg8HipkDCFeqwwHTX9cYV9p+kfycJEPW3JpCLHd+MVfndg1iz8IbQd1YzLzH0TY64gRyy2J19qTd9nxnSwuCV8Ha1qVl35BTjOi3VEB3mXas0gnTWipqUFuKzYamGjIamS6ZWGs0ieJ0Jm3E5870XWebxqiyn4jz8w2Z6v0k01JBSTJvQfvzlJZHsxM+zxmyS0jz1d97q+7l+u7a/ISQoPhSaAq3891C0nie8aEmymGdtDI8n97VH6qzVWnm0Yao4d1DgmWJzhiOHJ9WQfTv/5JeR9hP+h8lwWTVq05Nq6vF4xnSkGdXwf5YuRG1cen9DkwQFX9qXTOMTOJj0g/xaum+9dPfnhBie+D+nEv03zH5KfJ//L1nYpvdk1XowQL4VCMX0iTmeGkwc8O/KgZZY5rifcLS9fc/ZDaEFBooMrdZ9C+mxKGZyuO30Z+MdU1KFY9YGoNnX3gHPrAucxi0Zbet97a4ltSyV3H8AYpZdYN1KH1sRy8FP+5ALPGV1gV2Ys+oBy7A5yIuvwayzUBhnDNQJ371QBAxrLU27ebgv1wPdmPHMJ/XYXadNae0zcqQ38Pp2gYnjUMOrZ65wew9irgPUFTCuToZDtqUoSqdTlvS6lFEuXUEXvmACfEGb9Q2Q== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <9F06C4779E040F43ABB9565811D48B88@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB6163 Original-Authentication-Results: electric-loft.org; dkim=none (message not signed) header.d=none;electric-loft.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT049.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 39b5443e-5691-485e-a4b2-08d88c9cf355 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: IFpyQyR5qIpgqxi3WDtK5+24LoZAO0KbXKvofcCYzn92y3rpwyhQJxhFt7SMcoZKlaPpshnaFXtsJPOw5X9jhG3D36/YHTJX1WriWf54rx0MUk1CIyFhFBKvb0GHk/g7cyiBtzMV5zNYZqZXYj7qV0mDwXDcOBLWPRS7oZdKg4PBYQNZJ486/Z23v/iurPGtOpxxEHqkf5/5+luC9BuuA3dfhFdqVY5O6aNpr1+420MFWbNoPQDqbclG0jtB7iTnObR+5BwBjOmvfCywaQVN/RBIQl97kYvdt3S2tilrphfOpcHjLm/C7cA7x4bEcNTnVxOgqFy1CDAG7aw5rBpZJ1NjIrE+Raeasv3D3zAC+yflQlqNFGmJc0aXTp//ltXaqstM/dYqU09JYgyspCjO29LW8l7Um+TaZIV62o9VEa4z+pgBG1quTqxVvZt5ApHr9IH1Euou07X4XbohgafYdulFK7kabahwPHrotHczlSg= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(136003)(39850400004)(396003)(346002)(376002)(46966005)(316002)(478600001)(26005)(70206006)(2906002)(83380400001)(6486002)(186003)(82740400003)(8936002)(4326008)(356005)(336012)(54906003)(36756003)(47076004)(966005)(450100002)(81166007)(6862004)(70586007)(8676002)(86362001)(33656002)(5660300002)(6506007)(82310400003)(53546011)(2616005)(6512007)(45080400002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Nov 2020 15:08:38.4216 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 310d9537-b12f-4fa1-80f0-08d88c9cfe6e X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT049.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2061 Archived-At: Subject: Re: [secdir] [Suit] Secdir last call review of draft-ietf-suit-information-model-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 15:08:48 -0000 SGkgRGVycmVsbCwNCg0KSXQgc2VlbXMgbGlrZSB3ZeKAmXJlIGNvbWluZyBhdCB0aGlzIGZyb20g dmVyeSBkaWZmZXJlbnQgYW5nbGVzLCBzbyBsZXQgbWUgdHJ5IHRvIHNldCBzb21lIGNvbnRleHQu IFRoZSBTVUlUIG1hbmlmZXN0LCB3aGljaCBpcyB0aGUgZmlyc3Qgbm9ybWF0aXZlIHNwZWNpZmlj YXRpb24gZXhwZWN0ZWQgZnJvbSB0aGUgU1VJVCBXRywgaXMgYSBkb2N1bWVudCBmb3JtYXQgdGhh dCBkZWZpbmVzIGEgcHJvY2VzcyBmb3IgYSBkZXZpY2UgdG8gcHJvZ3Jlc3MgZnJvbSBvbmUgdmVy c2lvbiBvZiBvbmUgb3IgbW9yZSBmaXJtd2FyZS9zb2Z0d2FyZS9kYXRhIGNvbXBvbmVudHMgdG8g YW5vdGhlciB2ZXJzaW9uIG9mIHRoYXQvdGhvc2UgY29tcG9uZW50cy4gQSBtYW5pZmVzdCBtYXkg YWxzbyBkZWZpbmUgYSBwcm9jZXNzIGZvciBhIGRldmljZSB0byBkZXRlcm1pbmUgd2hldGhlciBv ciBub3QgaXQgaGFzIGFsbCByZXF1aXJlZCBjb21wb25lbnRzLCB0aGF0IHRoZXkgYXJlIGNvcnJl Y3QsIGxvYWQgdGhvc2UgY29tcG9uZW50cyBpbnRvIGV4ZWN1dGFibGUgbWVtb3J5IGlmIG5lZWRl ZCwgYW5kIHRoZW4gaW52b2tlIG9uZSBvciBtb3JlIGNvbXBvbmVudHMuDQoNClVwZGF0aW5nIHRo ZSBjb21wb25lbnRzIG9mIGEgZGV2aWNlLCBpcyBhIHNlY3VyaXR5IHNlbnNpdGl2ZSBwcm9jZXNz IHRoYXQgaXMsIGJ5IGl0cyB2ZXJ5IGRlZmluaXRpb24sIHJlbW90ZSBjb2RlIGV4ZWN1dGlvbi4g VGh1cywgd2hpbGUgZmlybXdhcmUgdXBkYXRlIG1lY2hhbmlzbXMgYXJlIHRoZSBzaW5nbGUgbW9z dCBpbXBvcnRhbnQgc2VjdXJpdHkgdG9vbCB3ZSBoYXZlIGZvciBwYXRjaGluZyB2dWxuZXJhYmls aXRpZXMsIHRoZXkgYXJlIGFsc28gdGhlIHNpbmdsZSBtb3N0IGRhbmdlcm91cyB0b29sOiBhbnkg ZmxhdyBpbiBhbiB1cGRhdGUgbWVjaGFuaXNtIGNvdWxkIGxlYWQgdG8gY29tcGxldGUgbWFsaWNp b3VzIHRha2VvdmVyIG9mIGEgZGV2aWNlLiBBcyBhIHJlc3VsdCwgd2UgaGF2ZSB0YWtlbiBhIHZl cnkgcGFydGljdWxhciBhcHByb2FjaCB0byB0aGUgSW5mb3JtYXRpb24gbW9kZWwuDQoNCkl0IHNo b3VsZCBiZSBzYWlkIHRoYXQgdGhlIEluZm9ybWF0aW9uIE1vZGVsIHdhcyBvcmlnaW5hbGx5IGRl ZmluZWQgYXMgYSBUaHJlYXQgTW9kZWwgd2l0aGluIHRoZSBhcmNoaXRlY3R1cmUsIGJ1dCBpdCB3 YXMgbGF0ZXIgc2VwYXJhdGVkIGZyb20gdGhlIGFyY2hpdGVjdHVyZSBhbmQgZ3JvdXBlZCB3aXRo IGEgbGlzdCBvZiByZXF1aXJlZCBpbmZvcm1hdGlvbiwgcmVzdWx0aW5nIGluIHRoZSBpbmZvcm1h dGlvbiBtb2RlbCBhcyBpdCBpcyB0b2RheS4gSXQgd291bGQgcHJvYmFibHkgYmUgbW9yZSBwcmVj aXNlIHRvIGRlZmluZSB0aGUgZG9jdW1lbnQgYXMgYSDigJxTZWN1cml0eSBhbmQgVXNhYmlsaXR5 IG1vZGVsLuKAnSBNYXliZSB3ZSBzaG91bGQgY2FsbCBpdCBhbiDigJxpbmZvcm1hdGlvbiBhbmQg dGhyZWF0IG1vZGVsLiINCg0KUGxlYXNlIHNlZSBmdXJ0aGVyIGNvbW1lbnRzIGlubGluZS4NCg0K QmVzdCBSZWdhcmRzLA0KQnJlbmRhbg0KDQo+IE9uIDE5IE5vdiAyMDIwLCBhdCAwMDozNCwgRGVy cmVsbCBQaXBlciB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KPg0K PiBSZXZpZXdlcjogRGVycmVsbCBQaXBlcg0KPiBSZXZpZXcgcmVzdWx0OiBOb3QgUmVhZHkNCj4N Cj4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkg ZGlyZWN0b3JhdGUncyBvbmdvaW5nDQo+IGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1l bnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlDQo+IGNvbW1lbnRzIHdlcmUg d3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhDQo+ IGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQg dGhlc2UgY29tbWVudHMganVzdA0KPiBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMu DQo+DQo+IFRoZSBzdW1tYXJ5IG9mIHRoZSByZXZpZXcgaXM6IE5vdCBSZWFkeQ0KPg0KPiBDYXZl YXQ6IEkgZm91bmQgdGhpcyBkb2N1bWVudCBkaWZmaWN1bHQuICBJJ3ZlIG5vdCBwcmV2aW91c2x5 IGVuY291bnRlcmVkIGFuDQo+ICJJbmZvcm1hdGlvbmFsIE1vZGVsIiBsaWtlIHRoaXMgb25lLCBh bmQgSSBoYXZlIG5vdCBiZWVuIGZvbGxvd2luZyBJb1QuICBJZg0KPiB0aGVzZSBjb21tZW50cyBz b3VuZCBjb21wbGV0ZWx5IHVuaGVscGZ1bCB0aGVuIEkgbWF5IGp1c3Qgbm90IGJlIHRoZSByaWdo dA0KPiBwZXJzb24gdG8gcmV2aWV3IHRoaXMgaW5mb3JtYXRpb25hbCBtb2RlbC4NCg0KV2UgYmVs aWV2ZSB0aGF0IGl0IGlzIG5lY2Vzc2FyeSB0byBqdXN0aWZ5IHRoZSBwcmVzZW5jZSBvZiBlYWNo IGluZm9ybWF0aW9uIGVsZW1lbnQuIFRoaXMgcmVxdWlyZXMgZGVmaW5pbmcgZXhhY3RseSB3aGlj aCBzZWN1cml0eSByZXF1aXJlbWVudHMgYW5kIHVzYWJpbGl0eSByZXF1aXJlbWVudHMgZ2l2ZSBy aXNlIHRvIGVhY2ggaW5mb3JtYXRpb24gZWxlbWVudC4gU2ltaWxhcmx5IHNlY3VyaXR5IHJlcXVp cmVtZW50cyBhbmQgdXNhYmlsaXR5IHJlcXVpcmVtZW50cyBkbyBub3QgZXhpc3QgaW4gYSB2YWN1 dW0uIFNlY3VyaXR5IHJlcXVpcmVtZW50cyB0aGF0IGRvIG5vdCBtaXRpZ2F0ZSB0aHJlYXRzIGFu ZCB1c2FiaWxpdHkgcmVxdWlyZW1lbnRzIHRoYXQgZG8gbm90IGVuYWJsZSB1c2VyIHN0b3JpZXMg YXJlIG5lZWRsZXNzIGNvbXBsZXhpdHkuIEluc3RlYWQgb2YgbGVhdmluZyB0aGVzZSBpbXBsaWNp dCwgYXMgaXMgZG9uZSBpbiBtYW55IGRvY3VtZW50cywgd2UgaGF2ZSBmdWxseSBkZWZpbmVkIHRo ZW0uDQoNClRoaXMgZG9lcyBtYWtlIHRoZSBkb2N1bWVudCBzb21ld2hhdCBkaWZmZXJlbnQgZnJv bSBvdGhlciBpbmZvcm1hdGlvbiBtb2RlbHMsIGJ1dCB3ZSBiZWxpZXZlIHRoYXQgdGhvc2Ugd2hv IHJlYWQgdGhlIGluZm9ybWF0aW9uIG1vZGVsIHNob3VsZCB1bmRlcnN0YW5kIHRoZSBwdXJwb3Nl IG9mIGVhY2ggZWxlbWVudCBhbmQgdGhhdCB0aGUgb25seSB3YXkgdGhhdCB0aGV5IGNhbiB1bmRl cnN0YW5kIHRob3NlIHB1cnBvc2VzIGlzIHRvIHNlZSB3aHkgdGhlIGVsZW1lbnRzIGFyZSB0aGVy ZS4NCg0KPiBJIHdvdWxkIHByZWZlciBNQVksIE1VU1QsIG9yIFNIT1VMRCBiZSB1c2VkIGNvbnNp c3RlbnRseSBpbnN0ZWFkIG9mIE9QVElPTkFMDQo+IGFuZCBSRUNPTU1FTkRFRC4gIEJvdGggYXJl IHVzZWQgaGVyZS4NCg0KV2UgaGF2ZSBjaG9zZW4gdGVybXMgYmFzZWQgb24gaG93IHRoZXkgYmVz dCBmaXQgdGhlIHN0cnVjdHVyZSBvZiB0aGUgc3Vycm91bmRpbmcgZ3JhbW1hci4gSWYgd2UgbmVl ZCB0byBjaG9vc2Ugb25lIHNldCBvZiB0ZXJtaW5vbG9neSwgd2UgY2FuIGRvIHRoaXMsIGJ1dCBp dCB3aWxsIHJlcXVpcmUgc3Vic3RhbnRpYWwgcmVwaHJhc2luZy4gQkNQMTQgZG9lcyBub3QgZ2l2 ZSBndWlkYW5jZSBvbiB1c2luZyBvbmx5IG9uZSBvZiAoTUFZLE9QVElPTkFMKSBvciAoU0hPVUxE LFJFQ09NTUVOREVEKSBjb25zaXN0ZW50bHkuIElzIHRoZXJlIGEgcmVmZXJlbmNlIHRoYXQgZ2l2 ZXMgZ3VpZGFuY2Ugb24gdGhpcyB0b3BpYz8NCg0KPiBUaGUgZHJhZnQgaXMgc3BsaXQgaW50byBm aXZlIGxpc3RzLCB3aXRoIDEwIHBhZ2VzIG9mIE1hbmlmZXN0IEluZm9ybWF0aW9uDQo+IEVsZW1l bnQgZGVzY3JpcHRpb25zIHByZXN1bWFibHkgZm9ybWluZyB0aGUgYmFzaXMgb2YgdGhlIGRyYWZ0 LCBidXQgZm9sbG93ZWQNCj4gYnkgdGhlIGJ1bGsgb2YgdGhlIGRvY3VtZW50IGFzIHRoZSBTZWN1 cml0eSBDb25zaWRlcmF0aW9zIHNlY3Rpb24uICBJIGZvdW5kDQo+IHRoZSBvcmdhbml6YXRpb24g Y29uZnVzaW5nLCB0b28gYWJzdHJhY3QsIGFuZCBzb21ld2hhdCBjaXJjdWxhci4gIEluIHN1bW1h cnk6DQo+DQo+ICBvIG1hbmlmZXN0IGVsZW1lbnRzIHNhdGlzZnkgb25lIG9yIG1vcmUgcmVxdWly ZW1lbnRzDQo+ICBvIHRocmVhdHMgYXJlIG1pdGlnYXRlZCBieSBvbmUgb3IgbW9yZSByZXF1aXJl bWVudHMNCj4gIG8gc2VjdXJpdHkgcmVxdWlyZW1lbnRzIChSRVEuU0VDKSBtaXRpZ2F0ZSBvbmUg b3IgbW9yZSB0aHJlYXRzDQo+ICBvIHVzZXIgc3RvcmllcyBhcmUgc2F0aXNmaWVkIGJ5IG9uZSBv ciBtb3JlIHVzYWJpbGl0eSByZXF1aXJlbWVudHMNCj4gIG8gdXNhYmlsaXR5IHJlcXVpcmVtZW50 cyAoUkVRLlVTRSkgc2F0aXNmeSB1c2VyIHN0b3JpZXMNCg0KV291bGQgeW91IGZpbmQgaXQgbGVz cyBjb25mdXNpbmcgdG8gb3JkZXIgaXQgYXMgZm9sbG93cz8NCg0KICBvIGVsZW1lbnRzDQogIG8g cmVxdWlyZW1lbnRzDQogIG8gdGhyZWF0cy91c2VyIHN0b3JpZXMNCg0KVGhlIHdvcmtpbmcgZ3Jv dXAgd2FzIHF1aXRlIGNsZWFyIHRoYXQgdGhlIGxpc3Qgb2YgaW5mb3JtYXRpb24gZWxlbWVudHMg c2hvdWxkIGNvbWUgZmlyc3QgYW5kIGJlIGp1c3RpZmllZCBieSBzdWJzZXF1ZW50IHNlY3Rpb25z Lg0KDQo+IHBwLjcgInRoZSBETlMgbmFtZSBzcGFjZSBJRCINCj4NCj4gVGhpcyBpbXBsaWVzIHBy aXZhdGUgRE5TIG5hbWVzcGFjZSBtYXkgYmUgYSBjb25jZXJuLCBhbmQgSSdkIGxpa2UgdG8NCj4g dW5kZXJzdGFuZCB3aHkgYW5kIGhvdywgYmVjYXVzZSB0aGlzIGlzIGJhc2VkIG9uIFRydXN0IEFu Y2hvcnMgYXMgZGVzY3JpYmVkIGluDQo+IFJGQzYwMjQuICBXaGF0IG90aGVyIEROUyBuYW1lc3Bh Y2VzIGFyZSB1bmRlciBjb25zaWRlcmF0aW9uPw0KDQpUaGlzIGlzIGFuIGV4cGxpY2l0IHJlZmVy ZW5jZXMgdG8gUkZDNDEyMi4gVGhlIGZ1bGwgc2VudGVuY2UgdW5kZXIgZGlzY3Vzc2lvbiByZWFk czoNCg0KPiAgICBSZWNvbW1lbmRlZCBwcmFjdGljZQ0KPiAgICBpcyB0byB1c2UgWw0KPiBSRkM0 MTIyDQo+IF0gdmVyc2lvbiA1IFVVSURzIHdpdGggdGhlIHZlbmRvcidzIGRvbWFpbiBuYW1lIGFu ZA0KPiAgICB0aGUgRE5TIG5hbWUgc3BhY2UgSUQuDQo+DQoNClJGQzQxMjIgc2F5cyAoaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQxMjIjc2VjdGlvbi00LjMpOg0KDQo+ICAgICAgIEFs bG9jYXRlIGEgVVVJRCB0byB1c2UgYXMgYSAibmFtZSBzcGFjZSBJRCIgZm9yIGFsbCBVVUlEcw0K PiAgICAgICBnZW5lcmF0ZWQgZnJvbSBuYW1lcyBpbiB0aGF0IG5hbWUgc3BhY2U7IHNlZQ0KPiBB cHBlbmRpeCBDDQo+ICBmb3Igc29tZQ0KPiAgICAgICBwcmUtZGVmaW5lZCB2YWx1ZXMNCj4NCg0K QW5kIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDEyMiNhcHBlbmRpeC1DKToNCg0K PiAgICAvKiBOYW1lIHN0cmluZyBpcyBhIGZ1bGx5LXF1YWxpZmllZCBkb21haW4gbmFtZSAqLw0K PiAgICB1dWlkX3QgTmFtZVNwYWNlX0ROUyA9IHsgLyogNmJhN2I4MTAtOWRhZC0xMWQxLTgwYjQt MDBjMDRmZDQzMGM4ICovDQo+ICAgICAgICAweDZiYTdiODEwLA0KPiAgICAgICAgMHg5ZGFkLA0K PiAgICAgICAgMHgxMWQxLA0KPiAgICAgICAgMHg4MCwgMHhiNCwgMHgwMCwgMHhjMCwgMHg0Ziwg MHhkNCwgMHgzMCwgMHhjOA0KPiAgICB9Ow0KDQpUaGVyZWZvcmUsIHdoZW4gdGhlIHN1aXQtaW5m b3JtYXRpb24tbW9kZWwgcmVmZXJlbmNlcyDigJx0aGUgRE5TIG5hbWUgc3BhY2UgSUTigJ0gaXQg aXMgcmVmZXJyaW5nIHRvIHRoZSBVVUlEIGluIFJGQzQxMjIsIEFwcGVuZGl4LUM6DQoNCj4gNmJh N2I4MTAtOWRhZC0xMWQxLTgwYjQtMDBjMDRmZDQzMGM4DQoNCldvdWxkIGl0IGJlIGNsZWFyZXIg dG8gcmVwaHJhc2UgdGhlIG9yaWdpbmFsIHRleHQgYXMgZm9sbG93cz8NCg0KPiAgICBSZWNvbW1l bmRlZCBwcmFjdGljZQ0KPiAgICBpcyB0byB1c2UgWw0KPiBSRkM0MTIyDQo+IF0gdmVyc2lvbiA1 IFVVSURzIHdpdGggdGhlIHZlbmRvcidzIGRvbWFpbiBuYW1lIGFuZA0KPiAgICA2YmE3YjgxMC05 ZGFkLTExZDEtODBiNC0wMGMwNGZkNDMwYzggKHRoZSBETlMgbmFtZSBzcGFjZSBJRCkuDQo+DQoN CkFzIGl0IGhhcHBlbnMsIHRoZSBTVUlUIHdvcmtpbmcgZ3JvdXAgaGFzIGRpc2N1c3NlZCB0aGUg cG9zc2liaWxpdHkgb2YgdXNpbmcgUHJpdmF0ZSBFbnRlcnByaXNlIE51bWJlcnMgaW4gcGxhY2Ug b2YgVVVJRHMgZm9yIFZlbmRvciBJRHMgYXMgd2VsbC4gVGhpcyBhY3Rpb24gaXMgIHBlbmRpbmcg aW4gdGhlIHdvcmtpbmcgZ3JvdXAsIGFzIGFuIHVwZGF0ZSB0byB0aGUgbWFuaWZlc3Qgc3BlY2lm aWNhdGlvbi4NCg0KDQo+IHBwLjE3LCAiVGhpcyBtb2RlbCB1c2VzIHRoZSBTLlQuUi5JLkQuRS4g YXBwcm9hY2giDQo+DQo+IE1pY3Jvc29mdCdzIFNUUklERSBUaHJlYXQgTW9kZWwgZGVmaW5lcyBz aXggdHlwZXMgb2YgdGhyZWF0czogaWRlbnRpdHkNCj4gc3Bvb2ZpbmcsIGRhdGEgdGFtcGVyaW5n LCByZXB1ZGlhdGlvbiwgaW5mb3JtYXRpb24gZGlzY2xvc3VyZSwgZGVuaWFsIG9mDQo+IHNlcnZp Y2UsIGFuZCBlbGV2YXRpb24gb2YgcHJpdmlsZWdlLiAgV2h5IGNhbGwgb3V0IHRoaXMgcGFydGlj dWxhciBhcHByb2FjaD8NCg0KU29tZSBtZXRob2RvbG9neSBtdXN0IGJlIHVzZWQgaW4gb3JkZXIg dG8gcGVyZm9ybSBhIHRocmVhdCBhbmFseXNpcy4gVGhpcyBpcyB0aGUgbWV0aG9kIHdlIHVzZWQg YW5kIGl0IGRlZmluZXMgdGhlIHRlcm1pbm9sb2d5IHVzZWQgdG8gY2xhc3NpZnkgdGhlIHZhcmlv dXMgdGhyZWF0cyBpbiB0aGUgdGhyZWF0IG1vZGVsLiBJcyB0aGVyZSBhIHJlYXNvbiB0byByZW1v dmUgdGhpcyByZWZlcmVuY2UgZ2l2ZW4gdGhhdCBpdCBkZWZpbmVzIHRoZSB0ZXJtaW5vbG9neSB1 c2VkIGluIHRoZSB0aHJlYXQgbW9kZWw/DQoNCj4gVGhlcmUgbWF5IGJlIHRyYWZmaWMgYW5hbHlz aXMgYW5kIGZpbmdlcnByaW50aW5nIGNvbmNlcm5zIGlmIHRoZSBtYW5pZmVzdCBpcw0KPiBub3Qg ZW5jcnlwdGVkLCBzcGVjaWZpY2FsbHkgaWYgdGhlIHZlbmRvciBJRHMgYXJlIHNlbnQgdW5lbmNy eXB0ZWQuDQoNCkkgYmVsaWV2ZSB0aGlzIGlzIFRIUkVBVC5NRlNULkVYUE9TVVJFIGFuZC9vciBU SFJFQVQuTkVULk9OUEFUSC4gVGhlIG1pdGlnYXRpb24gaXM6IFJFUS5TRUMuTUZTVC5DT05GSURF TlRJQUxJVFk6IEVuY3J5cHRlZCBNYW5pZmVzdHMsIHdoaWNoIGlzIGltcGxlbWVudGVkIGJ5OiBF eHRlcm5hbCBFbmNyeXB0aW9uIFdyYXBwZXIgLyBUcmFuc3BvcnQgU2VjdXJpdHkNCg0KU2VlIHRo ZXNlIHNlY3Rpb25zIGZvciBmdWxsIGRldGFpbHM6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1zdWl0LWluZm9ybWF0aW9uLW1vZGVsLTA4I3NlY3Rpb24tNC4yLjcNCmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXN1aXQtaW5mb3JtYXRpb24tbW9k ZWwtMDgjc2VjdGlvbi00LjIuMTQNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXN1aXQtaW5mb3JtYXRpb24tbW9kZWwtMDgjc2VjdGlvbi00LjMuMTQNCg0KPiBwcC4xMCwg Ii4uLnRoYXQgdmVyc2lvbiBNVVNUIGJlIHNwZWNpZmllZCINCj4NCj4gSXQgTVVTVCBiZSBzcGVj aWZpZWQgSUYsIGJ1dCB0aGUgZWxlbWVudCBpcyBPUFRJT05BTD8NCg0KQ29ycmVjdC4gSXQgTVVT VCBiZSBzdXBwb3J0ZWQgYnkgdGhlIHNlcmlhbGl6YXRpb24sIGJ1dCBhIGdpdmVuIGRlcGxveW1l bnQgZG9lcyBub3QgcmVxdWlyZSBpdCBpZiwgZm9yIGV4YW1wbGUsIGl0IGRvZXMgbm90IHN1cHBv cnQgZGlmZmVyZW50aWFsIHVwZGF0ZXMuIFNvIGl0IGlzIFJFUVVJUkVEIGluIHRoZSBzZXJpYWxp emF0aW9uLCBidXQgT1BUSU9OQUwgdG8gaW1wbGVtZW50IGluIGFueSBnaXZlbiBtYW5pZmVzdCBv ciBtYW5pZmVzdCBwcm9jZXNzb3IuDQoNCj4gcHAuMTAgTWFuaWZlc3QgRWxlbWVudDogRXhwaXJh dGlvbiBUaW1lDQo+DQo+IFRpbWUgaXMgbWVudGlvbmVkIGJ1dCBubyB0aW1lIGZvcm1hdCBpcyBz cGVjaWZpZWQuICBJcyBzeW5jaHJvbml6ZWQgdGltZSBhDQo+IHNlY3VyaXR5IHJlcXVpcmVtZW50 LCBhbmQgc2hvdWxkIHNwZWNpZmljIHRpbWUgZm9ybWF0cyBiZSBzcGVjaWZpZWQ/DQoNCkluIGdl bmVyYWwsIHdlIHRyeSBub3QgdG8gcmVxdWlyZSBhIHN5bmNocm9uaXNlZCB0aW1lIHNvdXJjZSwg c2luY2UgdGhpcyBwdXRzIHN1YnN0YW50aWFsIHJlcXVpcmVtZW50cyBvbiBhIGNvbnN0cmFpbmVk IGRldmljZS4gWW91IGFyZSBjb3JyZWN0IHRoYXQsIGZvciBhbiBpbWFnZSB0byBleHBpcmUsIHNv bWUgbm90aW9uIG9mIHRpbWUgaXMgbmVjZXNzYXJ5LiBUaGlzIGNhbiBiZSBjb21wbGV4IG9yIHNp bXBsZS4gV2UgZG8gbm90IHJlcXVpcmUgbWlsbGlzZWNvbmQgYWNjdXJhY3k7IGV2ZW4gZGlzcGxh eWluZyDigJxUb2RheeKAmXMgRGF0ZeKAnSB0byBhIHVzZXIgd291bGQgYmUg4oCcc2VjdXJlIGVu b3VnaOKAnSBmb3IgdGhpcyB1c2Ugc2luY2UsIGFzIG5vdGVkIGluIHRoZSBkcmFmdDoNCg0KPiAg ICBUaGlzIGVsZW1lbnQgbWF5IGFsc28gYmUgZGlzcGxheWVkIChlLmcuIHZpYSBhbiBhcHApDQo+ ICAgIGZvciB1c2VyIGNvbmZpcm1hdGlvbiBzaW5jZSB1c2VycyB0eXBpY2FsbHkgaGF2ZSBhIHJl bGlhYmxlIGtub3dsZWRnZQ0KPiAgICBvZiB0aGUgZGF0ZS4NCj4NCg0KSXMgdGhlcmUgYSByZWFz b24gdG8gaW5jbHVkZSBzcGVjaWZpYyB0aW1lIGZvcm1hdHMgaW4gdGhlIGluZm9ybWF0aW9uIG1v ZGVsLCByYXRoZXIgdGhhbiBhIHNlcmlhbGl6YXRpb24gdGhlcmVvZj8NCg0KPiBwcC4zMiA0LjQu MywgIlNhdGlzZmllZCBieSBVU0VSX1NUT1JZLk9WRVJSSURFIChTZWN0aW9uIDQuNC4zKSINCj4N Cj4gU2VjdGlvbiA0LjQuMyBpcyBjaXJjdWxhciAoc2F0aXNmaWVzIGl0c2VsZikNCg0KVGhpcyBp cyBhIHJlZmVyZW5jZSBlcnJvci4gVGhhbmtzIGZvciBwaWNraW5nIGl0IHVwLiBUaGUgY29ycmVj dCByZWZlcmVuY2UgaXM6DQoNCjQuNS4yLiBSRVEuVVNFLk1GU1QuT1ZFUlJJREVfUkVNT1RFDQoN Cj4gRGVycmVsbA0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBTdWl0IG1haWxpbmcgbGlzdA0KPiBTdWl0QGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3VpdA0KDQpJTVBPUlRBTlQgTk9U SUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBj b25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs eSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1 c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBp biBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Thu Nov 19 11:54:20 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01CF3A10E7 for ; Thu, 19 Nov 2020 11:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjbRTwKhMw4d for ; Thu, 19 Nov 2020 11:54:17 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 469473A10E6 for ; Thu, 19 Nov 2020 11:54:17 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 0AJJpqEm029134; Thu, 19 Nov 2020 19:54:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=RQGaulk41AWDQOGxkP17xj2BdBNP1FX22RVa3Qv7nqk=; b=GinRxkLA5TULbo+99jXnQHz3ccVi/anoaBrdnxhSCFApNDUgEZ11uoVo0UBlX5DhcT0Q gCQIFxXaiiWtF6X6pkrs6VQdhL17JxeHR7MbSA6KSk0/KE+jj9YF0rjkxdlz5hzjZ5VN k/pgXW4XuLDPgFG6i5PxU0LfUFbKx01WCfFz/J0Nai35mYRcS6TLKRFtiFEaLsqeIhHI 3xtltJ4hJvXhDjl2Hcss5Z6jkACWHBt+or/nndRC0nz32eovYk7SinMmFyRtK2VYQOiM pNROmrE2idHL5ddH82/I1LbqxCqHlVj/OpQK/JQJI6g3rEiukD20oBj8L8ZjyoldzLhv xQ== Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 34w7v2fr5e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Nov 2020 19:54:16 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 0AJJoYsO017022; Thu, 19 Nov 2020 14:54:15 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.113]) by prod-mail-ppoint3.akamai.com with ESMTP id 34tbf2w9n1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 19 Nov 2020 14:54:15 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.165.122) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 19 Nov 2020 13:54:14 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.008; Thu, 19 Nov 2020 13:54:14 -0600 From: "Salz, Rich" To: Kent Watsen CC: "secdir@ietf.org" Thread-Topic: Netconf Thread-Index: AQHWvq3Bzm+Fi5XhMEi4+eo7kj1TKQ== Date: Thu, 19 Nov 2020 19:54:14 +0000 Message-ID: <851CA40A-5BCB-47DD-9FCD-5354A4EB6215@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_851CA40A5BCB47DD9FCD5354A4EB6215akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-19_10:2020-11-19, 2020-11-19 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 adultscore=0 mlxlogscore=775 malwarescore=0 spamscore=0 suspectscore=0 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011190136 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-19_10:2020-11-19, 2020-11-19 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 phishscore=0 lowpriorityscore=0 adultscore=0 mlxlogscore=699 spamscore=0 impostorscore=0 suspectscore=0 bulkscore=0 mlxscore=0 malwarescore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011190136 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.31) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint3 Archived-At: Subject: [secdir] Netconf X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 19:54:19 -0000 --_000_851CA40A5BCB47DD9FCD5354A4EB6215akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 S2VudCwNCg0KSSBqb2luZWQgTmV0Y29uZiB0byBoZWxwIHdpdGggdGhlIHNlY3VyaXR5L3lhbmcg cGFydHMuIEkgdGhpbmsgaXTigJlzIGRvbmUgKEkgbGVhcm5lZCBhIGxvdCksIGFuZCBJIGFtIGFi b3V0IHRvIGxlYXZlIHRoZSBncm91cC4NCg0KSSBlbmpveWVkIHdvcmtpbmcgd2l0aCB5b3UsIGl0 IHdhcyBncmVhdCB0byBzZWUgc3VjaCBlYXJuZXN0IGludGVyZXN0IGluIGRvaW5nIHRoZSByaWdo dCB0aGluZzsgdGhhdCBkb2VzbuKAmXQgaGFwcGVuIHZlcnkgb2Z0ZW4gd2hlbiBzb21lb25lIGZy b20gdGhlIHNlY3VyaXR5IGNvbWVzIGluIDopDQoNCkZlZWwgZnJlZSB0byBjYWxsIG9uIG15IGFu eXRpbWUsIGJ1dCB5b3UgZ290IHRoaXMuDQoNClRoYW5rcy4NCiAgICAgICAgICAgICAgICAvciQN Cg0K --_000_851CA40A5BCB47DD9FCD5354A4EB6215akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <353DDBCC7F974C49B290ACF28AD65FAE@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiIHN0 eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPktlbnQs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGpvaW5lZCBOZXRj b25mIHRvIGhlbHAgd2l0aCB0aGUgc2VjdXJpdHkveWFuZyBwYXJ0cy4gSSB0aGluayBpdOKAmXMg ZG9uZSAoSSBsZWFybmVkIGEgbG90KSwgYW5kIEkgYW0gYWJvdXQgdG8gbGVhdmUgdGhlIGdyb3Vw LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SSBlbmpveWVkIHdv cmtpbmcgd2l0aCB5b3UsIGl0IHdhcyBncmVhdCB0byBzZWUgc3VjaCBlYXJuZXN0IGludGVyZXN0 IGluIGRvaW5nIHRoZSByaWdodCB0aGluZzsgdGhhdCBkb2VzbuKAmXQgaGFwcGVuIHZlcnkgb2Z0 ZW4gd2hlbiBzb21lb25lIGZyb20gdGhlIHNlY3VyaXR5IGNvbWVzIGluIDopPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5GZWVsIGZyZWUgdG8gY2FsbCBvbiBteSBh bnl0aW1lLCBidXQgeW91IGdvdCB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+VGhhbmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgL3IkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_851CA40A5BCB47DD9FCD5354A4EB6215akamaicom_-- From nobody Thu Nov 19 11:57:38 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1363A10F9; Thu, 19 Nov 2020 11:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0X970sn0VDx; Thu, 19 Nov 2020 11:57:35 -0800 (PST) Received: from Mail1.Yoyodyne.COM (mail1.yoyodyne.com [IPv6:2604:4ec0:1000::7]) by ietfa.amsl.com (Postfix) with SMTP id 0D2C23A12D4; Thu, 19 Nov 2020 11:57:10 -0800 (PST) Received: from [192.168.1.83] ([24.5.60.91]) by Mail1.Yoyodyne.COM via Internet for (and others); Thu, 19 Nov 2020 11:56:32 PST To: Brendan Moran Cc: "secdir@ietf.org" , "draft-ietf-suit-information-model.all@ietf.org" , "last-call@ietf.org" , "suit@ietf.org" References: <160574605497.24260.13971208595707468000@ietfa.amsl.com> <7BD14CD2-1CD2-4307-966E-637211539F6B@arm.com> From: Derrell Piper Message-ID: Date: Thu, 19 Nov 2020 11:57:03 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <7BD14CD2-1CD2-4307-966E-637211539F6B@arm.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050003030705060505060508" Archived-At: Subject: Re: [secdir] [Suit] Secdir last call review of draft-ietf-suit-information-model-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 19:57:38 -0000 This is a cryptographically signed message in MIME format. --------------ms050003030705060505060508 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Brendon, On 11/19/2020 7:08 AM, Brendan Moran wrote: > It should be said that the Information Model was originally defined as = a Threat Model within the architecture, but it was later separated from t= he architecture and grouped with a list of required information, resultin= g in the information model as it is today. It would probably be more prec= ise to define the document as a =E2=80=9CSecurity and Usability model.=E2= =80=9D Maybe we should call it an =E2=80=9Cinformation and threat model."= I think that change would help. I almost wrote that I felt this=20 document should have been contained in another, so there you go. > We believe that it is necessary to justify the presence of each informa= tion element. This requires defining exactly which security requirements = and usability requirements give rise to each information element. Similar= ly security requirements and usability requirements do not exist in a vac= uum. Security requirements that do not mitigate threats and usability req= uirements that do not enable user stories are needless complexity. Instea= d of leaving these implicit, as is done in many documents, we have fully = defined them. Absolutely no need to apologize for considering usability. > This does make the document somewhat different from other information m= odels, but we believe that those who read the information model should un= derstand the purpose of each element and that the only way that they can = understand those purposes is to see why the elements are there. >=20 >> I would prefer MAY, MUST, or SHOULD be used consistently instead of OP= TIONAL >> and RECOMMENDED. Both are used here. >=20 > We have chosen terms based on how they best fit the structure of the su= rrounding grammar. If we need to choose one set of terminology, we can do= this, but it will require substantial rephrasing. BCP14 does not give gu= idance on using only one of (MAY,OPTIONAL) or (SHOULD,RECOMMENDED) consis= tently. Is there a reference that gives guidance on this topic? BCP14 is where I'd go so leave it. >> The draft is split into five lists, with 10 pages of Manifest Informat= ion >> Element descriptions presumably forming the basis of the draft, but fo= llowed >> by the bulk of the document as the Security Consideratios section. I = found >> the organization confusing, too abstract, and somewhat circular. In s= ummary: >> >> o manifest elements satisfy one or more requirements >> o threats are mitigated by one or more requirements >> o security requirements (REQ.SEC) mitigate one or more threats >> o user stories are satisfied by one or more usability requirements >> o usability requirements (REQ.USE) satisfy user stories >=20 > Would you find it less confusing to order it as follows? >=20 > o elements > o requirements > o threats/user stories Yes, I think that would really help. > The working group was quite clear that the list of information elements= should come first and be justified by subsequent sections. They belong up front, if you reorg it that'll probably go a long way. >> pp.7 "the DNS name space ID" >> >> This implies private DNS namespace may be a concern, and I'd like to >> understand why and how, because this is based on Trust Anchors as desc= ribed in >> RFC6024. What other DNS namespaces are under consideration? >=20 > This is an explicit references to RFC4122. The full sentence under disc= ussion reads: >> Recommended practice >> is to use [ >> RFC4122 >> ] version 5 UUIDs with the vendor's domain name and >> the DNS name space ID. >> >=20 > RFC4122 says (https://tools.ietf.org/html/rfc4122#section-4.3): >=20 >> Allocate a UUID to use as a "name space ID" for all UUIDs >> generated from names in that name space; see >> Appendix C >> for some >> pre-defined values >> >=20 > And (https://tools.ietf.org/html/rfc4122#appendix-C): >=20 >> /* Name string is a fully-qualified domain name */ >> uuid_t NameSpace_DNS =3D { /* 6ba7b810-9dad-11d1-80b4-00c04fd430c8= */ >> 0x6ba7b810, >> 0x9dad, >> 0x11d1, >> 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8 >> }; >=20 > Therefore, when the suit-information-model references =E2=80=9Cthe DNS = name space ID=E2=80=9D it is referring to the UUID in RFC4122, Appendix-C= : >=20 >> 6ba7b810-9dad-11d1-80b4-00c04fd430c8 >=20 > Would it be clearer to rephrase the original text as follow > >> Recommended practice >> is to use [ >> RFC4122 >> ] version 5 UUIDs with the vendor's domain name and >> 6ba7b810-9dad-11d1-80b4-00c04fd430c8 (the DNS name space ID). Yes, it would be. > As it happens, the SUIT working group has discussed the possibility of = using Private Enterprise Numbers in place of UUIDs for Vendor IDs as well= =2E This action is pending in the working group, as an update to the man= ifest specification. Okay. >> pp.17, "This model uses the S.T.R.I.D.E. approach" >> >> Microsoft's STRIDE Threat Model defines six types of threats: identity= >> spoofing, data tampering, repudiation, information disclosure, denial = of >> service, and elevation of privilege. Why call out this particular app= roach? >=20 > Some methodology must be used in order to perform a threat analysis. Th= is is the method we used and it defines the terminology used to classify = the various threats in the threat model. Is there a reason to remove this= reference given that it defines the terminology used in the threat model= ? It's the procedural point that you're pointing into Microsoft's=20 corporate web's description of the Microsoft Commerce Server 2002, which = may not be online forever. I guess you have to have a reference, hum. >> There may be traffic analysis and fingerprinting concerns if the manif= est is >> not encrypted, specifically if the vendor IDs are sent unencrypted. >=20 > I believe this is THREAT.MFST.EXPOSURE and/or THREAT.NET.ONPATH. The mi= tigation is: REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests, which is = implemented by: External Encryption Wrapper / Transport Security >=20 > See these sections for full details: > https://tools.ietf.org/html/draft-ietf-suit-information-model-08#sectio= n-4.2.7 > https://tools.ietf.org/html/draft-ietf-suit-information-model-08#sectio= n-4.2.14 > https://tools.ietf.org/html/draft-ietf-suit-information-model-08#sectio= n-4.3.14 That is the mitigation, and I even like it, so okay! >> pp.10, "...that version MUST be specified" >> >> It MUST be specified IF, but the element is OPTIONAL? >=20 > Correct. It MUST be supported by the serialization, but a given deploym= ent does not require it if, for example, it does not support differential= updates. So it is REQUIRED in the serialization, but OPTIONAL to impleme= nt in any given manifest or manifest processor. I thought so, so I'd just add that text explicitly to clarify. >> pp.10 Manifest Element: Expiration Time >> >> Time is mentioned but no time format is specified. Is synchronized ti= me a >> security requirement, and should specific time formats be specified? >=20 > In general, we try not to require a synchronised time source, since thi= s puts substantial requirements on a constrained device. You are correct = that, for an image to expire, some notion of time is necessary. This can = be complex or simple. We do not require millisecond accuracy; even displa= ying =E2=80=9CToday=E2=80=99s Date=E2=80=9D to a user would be =E2=80=9Cs= ecure enough=E2=80=9D for this use since, as noted in the draft: >=20 >> This element may also be displayed (e.g. via an app) >> for user confirmation since users typically have a reliable knowle= dge >> of the date. >> >=20 > Is there a reason to include specific time formats in the information m= odel, rather than a serialization thereof? No, serialization would canonicalize it coming out, and that was my conce= rn. Derrell --------------ms050003030705060505060508 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CqUwggUuMIIEFqADAgECAhBuYWaYcrycMAAAAABR05MeMA0GCSqGSIb3DQEBCwUAMIG+MQsw CQYDVQQGEwJVUzEWMBQGA1UEChMNRW50cnVzdCwgSW5jLjEoMCYGA1UECxMfU2VlIHd3dy5l bnRydXN0Lm5ldC9sZWdhbC10ZXJtczE5MDcGA1UECxMwKGMpIDIwMDkgRW50cnVzdCwgSW5j LiAtIGZvciBhdXRob3JpemVkIHVzZSBvbmx5MTIwMAYDVQQDEylFbnRydXN0IFJvb3QgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjAeFw0xOTA0MTYxNTM1NTJaFw0zMDExMTYxNjA1 NTJaMIG3MQswCQYDVQQGEwJVUzEWMBQGA1UEChMNRW50cnVzdCwgSW5jLjEoMCYGA1UECxMf U2VlIHd3dy5lbnRydXN0Lm5ldC9sZWdhbC10ZXJtczE5MDcGA1UECxMwKGMpIDIwMTUgRW50 cnVzdCwgSW5jLiAtIGZvciBhdXRob3JpemVkIHVzZSBvbmx5MSswKQYDVQQDEyJFbnRydXN0 IENsYXNzIDEgQ2xpZW50IENBIC0gU0hBMjU2MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2DmtXj1lwZOXaWXvERtOSP7QMI+Ts82RQc2etqDeYwctILXqkwsQrZB6YjKa1BQn BmLHxn3cWxKJtqCT7ZP95YVxc0MXjP5ifP9xD/f59jlYd/7SPIxQUjX1+vsV6aY4tTzPiaOu 3VHVGbD70si3WdUvJh367CMOU2o0mXi9MwW1fBwMHK99NKgpwpr4QhyT2aZ+os/hGGQLUYms e5Dfshq79eelXyFC1FIrvM0AhAk+T3NKFPmckKwyk30jkFMElSneTR7ganOTMeT1OEqVomyJ sMzJugVaMzuSt4vhJFSt/XXRMPcPT9PEx39X78NNkWeTTkL1Ghq9O2WeAStQNwIDAQABo4IB KzCCAScwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMDsGA1UdIAQ0MDIwMAYEVR0gADAoMCYGCCsGAQUFBwIBFhpo dHRwOi8vd3d3LmVudHJ1c3QubmV0L3JwYTAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUHMAGG F2h0dHA6Ly9vY3NwLmVudHJ1c3QubmV0MDAGA1UdHwQpMCcwJaAjoCGGH2h0dHA6Ly9jcmwu ZW50cnVzdC5uZXQvZzJjYS5jcmwwHQYDVR0OBBYEFOJJuewl3rcM3uVQGFtIzAyOFfKmMB8G A1UdIwQYMBaAFGpyJnrQHu995ztpUdRsjZ+QEmarMA0GCSqGSIb3DQEBCwUAA4IBAQBVuaCw N5r85cQphcyUe+RXqaYyUmVEqTWG/a98UJdX44vkCgzdD/+Cn4o6wbRun7Ak0kdCR3qfFA17 /5QOQ8DLOyR5X37Ytxby24lTLKKehNlc3japM8XQQFaJqLMq3MXXFYhWlFk4UHwXYLcDR7Xy A3hYuaL6HU92h+uGSDEcBeV+nXrk4FRgEfGvilHfd+8ozBjSVKOF6L1+fuJNkaFWYvJ4Qi64 nlmXDsk6K9f6P4FT8hXA2Cn6tQGAqCz8t6bn7ljtaxCMJ10LE+omiZDfWXv4PrkvgWnNqZEz Qw+E09HwEc7DjV9/fGqUhLR2AKkjYE/78rlymYPvOf7bmpSYMIIFbzCCBFegAwIBAgIRAI1S U9vc6Vc5AAAAAFVj5MUwDQYJKoZIhvcNAQELBQAwgbcxCzAJBgNVBAYTAlVTMRYwFAYDVQQK Ew1FbnRydXN0LCBJbmMuMSgwJgYDVQQLEx9TZWUgd3d3LmVudHJ1c3QubmV0L2xlZ2FsLXRl cm1zMTkwNwYDVQQLEzAoYykgMjAxNSBFbnRydXN0LCBJbmMuIC0gZm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxKzApBgNVBAMTIkVudHJ1c3QgQ2xhc3MgMSBDbGllbnQgQ0EgLSBTSEEyNTYw HhcNMjAwNjA1MTY1ODI5WhcNMjMwNjA1MTcyODI5WjCBnzEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQLEy5FbnRydXN0IENsYXNzIDEgSWRlbnRpdHkgQ2VydGlm aWNhdGlvbiBTZXJ2aWNlMR4wHAYDVQQDDBVkZHBAZWxlY3RyaWMtbG9mdC5vcmcxJDAiBgkq hkiG9w0BCQEWFWRkcEBlbGVjdHJpYy1sb2Z0Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAM0lzjLFuD62oMZvzX4bx9JUT4wvdd/AbGIvYXvsY6VbsPF6HjtiLZlN2sZQ z973qCs3BXM0sMfCRbtNczoITG5KNkWoQNcCjIrtGDP1Op93HpAO7nIMXJQJ8qcKzZ1nO7Mv ciQ1GdHgvaZ2TyWUWSKCNhgbLT8gc4rB6XC5t6QHHKXKG9yc1huOq1TOVNvqCZJ7tx1ckumm Be7YU4NJTbu0XGSM0578jcuFbBzisj0gAt/Lj18Pi5Sqj3QqUT+xo9aofjydw+kKpinNyFQZ MqABXybuAO9/nzZ2cH0RE5MGx6pHb8GOhL6yvgqgUpu1QfovFrsTeBZbP24LViu7cisCAwEA AaOCAYowggGGMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwQgYDVR0gBDswOTA3BgtghkgBhvpsCgEEATAoMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3 LmVudHJ1c3QubmV0L3JwYTAJBgNVHRMEAjAAMGkGCCsGAQUFBwEBBF0wWzAjBggrBgEFBQcw AYYXaHR0cDovL29jc3AuZW50cnVzdC5uZXQwNAYIKwYBBQUHMAKGKGh0dHA6Ly9haWEuZW50 cnVzdC5uZXQvY2xhc3MxLXNoYTI1Ni5jZXIwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2Ny bC5lbnRydXN0Lm5ldC9jbGFzczEtc2hhMjU2LmNybDAgBgNVHREEGTAXgRVkZHBAZWxlY3Ry aWMtbG9mdC5vcmcwHwYDVR0jBBgwFoAU4km57CXetwze5VAYW0jMDI4V8qYwHQYDVR0OBBYE FBldpeksJRT1eoN4ViLNnG4wgVdJMA0GCSqGSIb3DQEBCwUAA4IBAQBp4AZ3Z1ElfrhGuGjK BrtbVZBLQ122NbUZHF/msa83PGaqKYu+/NAARDM6oeGJg7K4J3qtM8UyGpuhvQI/GUMdiNiq x7Km0R0iqadG59smeNNvE+B4o7q95v8k3A0nd57DXmlNUYm+Xv/UIuNy18PAokYye0xiLOoV uHQPFpdN2TyLbHLbQmjwHa/FeHlQYw9xc4byRxDDg62g4bzcRgbuCEgzh4m3sMoIVgLeuiFT JWSpvnzBJSMWAMeBbs5LYN531kwFA/eSk/FQ4aiUl5cpkpUKjq3yPrUIvIIioYsQwQ11P13B Le+ll7ECwxX8egXWMAh/ca9dmElbgVUcqnjmMYIEmDCCBJQCAQEwgc0wgbcxCzAJBgNVBAYT AlVTMRYwFAYDVQQKEw1FbnRydXN0LCBJbmMuMSgwJgYDVQQLEx9TZWUgd3d3LmVudHJ1c3Qu bmV0L2xlZ2FsLXRlcm1zMTkwNwYDVQQLEzAoYykgMjAxNSBFbnRydXN0LCBJbmMuIC0gZm9y IGF1dGhvcml6ZWQgdXNlIG9ubHkxKzApBgNVBAMTIkVudHJ1c3QgQ2xhc3MgMSBDbGllbnQg Q0EgLSBTSEEyNTYCEQCNUlPb3OlXOQAAAABVY+TFMA0GCWCGSAFlAwQCAQUAoIICmzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDExMTkxOTU3MDNaMC8G CSqGSIb3DQEJBDEiBCBZuKR+bIPmnlp9nIGSt3pLEvZKR923AhZxbMDOXR5e2zBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHeBgkr BgEEAYI3EAQxgdAwgc0wgbcxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1FbnRydXN0LCBJbmMu MSgwJgYDVQQLEx9TZWUgd3d3LmVudHJ1c3QubmV0L2xlZ2FsLXRlcm1zMTkwNwYDVQQLEzAo YykgMjAxNSBFbnRydXN0LCBJbmMuIC0gZm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxKzApBgNV BAMTIkVudHJ1c3QgQ2xhc3MgMSBDbGllbnQgQ0EgLSBTSEEyNTYCEQCNUlPb3OlXOQAAAABV Y+TFMIHgBgsqhkiG9w0BCRACCzGB0KCBzTCBtzELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUVu dHJ1c3QsIEluYy4xKDAmBgNVBAsTH1NlZSB3d3cuZW50cnVzdC5uZXQvbGVnYWwtdGVybXMx OTA3BgNVBAsTMChjKSAyMDE1IEVudHJ1c3QsIEluYy4gLSBmb3IgYXV0aG9yaXplZCB1c2Ug b25seTErMCkGA1UEAxMiRW50cnVzdCBDbGFzcyAxIENsaWVudCBDQSAtIFNIQTI1NgIRAI1S U9vc6Vc5AAAAAFVj5MUwDQYJKoZIhvcNAQEBBQAEggEAiRp2CkNHLmHqRWxQYFzJ73TrQNee 4fr0uIjQIFbVWROvlrn//CyfbAOLKa8SNRW8Ok8dny4s8s+Udp4sfOMUfCLXJ5FHzUJtorpk wrakY93Zo9/BxAfPwOXtuxHhIYJ0Q5TL37f+ppoCmAew/mPnklX6duxQb3vgj2esaM1iFVLW lVAJsGsWFbL9DB4mqTSuUQGktvU9nymhm129eXCpOTZwu7Z/YH0g+sSNdpDErXyS6loMOkoH f0nT9lYJ/DIIxWUfwEAAjXnFYL6x2WBLY2Qwo6tj9FXIQdfnuuzgqlPXlAdFwHkhQ+LCXlUT Q5j7b/i9GDj+1KgheYWrpbeZHAAAAAAAAA== --------------ms050003030705060505060508-- From nobody Thu Nov 19 12:36:19 2020 Return-Path: <01000175e238cdb5-a350a956-2d66-4e2a-9b6c-ccfc81cbc42f-000000@amazonses.watsen.net> X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9063A11E2 for ; Thu, 19 Nov 2020 12:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8SEsXj5l4i3 for ; Thu, 19 Nov 2020 12:36:16 -0800 (PST) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5982F3A11DC for ; Thu, 19 Nov 2020 12:36:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1605818175; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=aFEwNGOYbdzVV5Z3BgscP0A2h9GDU+qVu4BUr/AbWKI=; b=iwn3dWxoAHkRRCQCQlW9aZKbBkSAEO9jbuE4m9Awm1masHZiocqDaF7FhZWXDfRK 0Iw9U3NVrvWAgO6FoTNj5L7z8sZoW1Hx6JBZUTSKQubLI9gU+pusWUIQYTvms/nW/TS 2B4r8PsRoVg7xzwl33dHdOz/nosX3Lc8vmzSo+kQ= From: Kent Watsen Message-ID: <01000175e238cdb5-a350a956-2d66-4e2a-9b6c-ccfc81cbc42f-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1DE52155-5E86-41B3-9B13-CB011455F1F8" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 19 Nov 2020 20:36:15 +0000 In-Reply-To: <851CA40A-5BCB-47DD-9FCD-5354A4EB6215@akamai.com> Cc: "secdir@ietf.org" To: "Salz, Rich" References: <851CA40A-5BCB-47DD-9FCD-5354A4EB6215@akamai.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.11.19-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [secdir] Netconf X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 20:36:17 -0000 --Apple-Mail=_1DE52155-5E86-41B3-9B13-CB011455F1F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Rich. I likewise appreciate all that you=E2=80=99ve done. I know you came in to help with the algorithm-identifiers issue. We = actually never resolved that, we merely side-stepped it by postponing = the ability the request a device to generate keys. Of course, that = issue will come back, so maybe we=E2=80=99ll see you again then. K. =20 > On Nov 19, 2020, at 2:54 PM, Salz, Rich wrote: >=20 > Kent, > =20 > I joined Netconf to help with the security/yang parts. I think it=E2=80=99= s done (I learned a lot), and I am about to leave the group. > =20 > I enjoyed working with you, it was great to see such earnest interest = in doing the right thing; that doesn=E2=80=99t happen very often when = someone from the security comes in :) > =20 > Feel free to call on my anytime, but you got this. > =20 > Thanks. > /r$ --Apple-Mail=_1DE52155-5E86-41B3-9B13-CB011455F1F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Rich.

I likewise appreciate all that you=E2=80=99ve done.

I know you came in to = help with the algorithm-identifiers issue.  We actually never = resolved that, we merely side-stepped it by postponing the ability the = request a device to generate keys.  Of course, that issue will come = back, so maybe we=E2=80=99ll see you again then.

K.
 


On Nov 19, 2020, at 2:54 PM, Salz, Rich = <rsalz@akamai.com> wrote:

Kent,
 
I joined Netconf to help with the = security/yang parts. I think it=E2=80=99s done (I learned a lot), and I = am about to leave the group.
 
I enjoyed working with you, it was = great to see such earnest interest in doing the right thing; that = doesn=E2=80=99t happen very often when someone from the security comes = in :)
 
Feel free to call on my anytime, = but you got this.
 
Thanks.
          &nb= sp;     = /r$

= --Apple-Mail=_1DE52155-5E86-41B3-9B13-CB011455F1F8-- From nobody Fri Nov 20 00:41:06 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 024803A1A97; Fri, 20 Nov 2020 00:40:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner via Datatracker To: Cc: last-call@ietf.org, draft-ietf-ipsecme-ipv6-ipv4-codes.all@ietf.org, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160586165897.15805.9482261922121041926@ietfa.amsl.com> Reply-To: Sean Turner Date: Fri, 20 Nov 2020 00:40:59 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-ipsecme-ipv6-ipv4-codes-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 08:40:59 -0000 Reviewer: Sean Turner Review result: Ready looks good to me From nobody Fri Nov 20 01:27:36 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E572E3A1B28; Fri, 20 Nov 2020 01:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org 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 Odo1xRxVLVpY; Fri, 20 Nov 2020 01:27:27 -0800 (PST) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D0193A1B27; Fri, 20 Nov 2020 01:27:27 -0800 (PST) Received: from [IPv6:2a00:ac00:4000:400:b9ed:9d2d:94cd:1d3c] (unknown [IPv6:2a00:ac00:4000:400:b9ed:9d2d:94cd:1d3c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 6B2CF607BE2; Fri, 20 Nov 2020 11:27:18 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1605864438; bh=G+oQ6taGWISfmyLBdbU7C6Wirhbwadz979VYnwjcc1w=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=dugB72K2KfsjkLz1cqrtR7fvW9pGb7ofXdHu/LpsSuEZ3iyc7U26KnafiOr5XzHee Oq7OcIbkgeIkn3Vu07gp71haIDvZCmmkdKcU2xDQQ3l96nEDu8pTvb/gyQDjnr7nCd e7ld3xMKV8cG+P18ZGy8IGIOAVYglHcNm+i4qWYM= From: Lars Eggert Message-Id: <790322E5-2F2B-4D16-8392-003BA7889EB5@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_B7B1D2ED-47CA-4121-903C-573844BBC632"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 20 Nov 2020 11:27:15 +0200 In-Reply-To: <5b8ef2d6fc186410b781273c79439403ba707b81.camel@ericsson.com> Cc: Magnus Westerlund , magnusn@gmail.com, secdir@ietf.org To: QUIC WG References: <160579622789.12999.1938532053389460211@ietfa.amsl.com> <5b8ef2d6fc186410b781273c79439403ba707b81.camel@ericsson.com> X-MailScanner-ID: 6B2CF607BE2.A46B2 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [secdir] [Fwd: "Has Issues" review submitted for draft-ietf-quic-qpack-19] X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 09:27:34 -0000 --Apple-Mail=_B7B1D2ED-47CA-4121-903C-573844BBC632 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2020-11-20, at 11:13, Magnus Westerlund = wrote: > This has been entered intot he datatracker. I guess the reviewer = didn't press > the email out the result. Thanks for catching this! The tracking milestone is = https://github.com/quicwg/base-drafts/milestone/21 and has links to the = three individual issues raised. Thanks, Lars --Apple-Mail=_B7B1D2ED-47CA-4121-903C-573844BBC632 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl+3i/MACgkQVLXDCb9w wVeAsQ/+NepVG4mwQPTr6Q5jHkpp523Q4q/1Qdva8J0RdC+/Ekwo2MfMIslRATRu nsta5aiTGXiJglpULoiQrIXaCMjZhTuNz0zWPM67XpTNOqpS4gIlWeYSbQrjfz8P 2w9XgWiLyLMZCFbmy0kLUyKRJqvfx2EYKn6lZp5izuXEH+EC/7wu5ThG1LBnXoqa kOL84tIxop0WrvRwOmnOFRNpL5v356U92mgXx5fhFlx5wJEW8TgVzLBTeeCIUawJ N2HZGtq3EBG8tofvEzzqOYqKziihZRYm4hoWJhjayL8WVLRQBA95QFfiOg4liM0p 5yNUGtlOPYpbpwW32Bw23s/59eNfp5qRTL5bOAC4Kdrlm1kORPAdJndf5o1ardwO 1V9UBvIzU6r4eedtaMzY86/Msvg22KN9wJOat1jF2vE0KJyergjykku+6hUKzf/M rk7VNY67HhAuu1wHV3OTbFJ0b2+kXq90XhDR7JOjRXTtXqmwM0i40Q8M6WutEyjI 9wYltyeE6OfibMO4mwmXQA9wv+YmPBNT9tEwRh3RLhiALuXmlEuUBuup4C4TQctf jmspOcvZFtkrSELpcLuh3nn+tEkmi154Yf2kUqdDXtV4uBXh+tlDM7y77wOvTqdh tFOEAwXYXa9+RsTkh9JSP9FeN1mhSYngmgubtCyOuEe/DTvXJmQ= =PqgP -----END PGP SIGNATURE----- --Apple-Mail=_B7B1D2ED-47CA-4121-903C-573844BBC632-- From nobody Sat Nov 21 01:05:37 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C41C3A0EF6; Fri, 20 Nov 2020 08:47:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1605890822; bh=EXB/BacwO5nWLLGBNobcUZIzhEH0rN3x6I/7DjQ7Mr8=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=CR98mI6HJBbTZAwtLam7I6dg9ZqsPE5KYDuBdQMuZ82WFb41H4NNtVQ0bC0TQboH6 /QiL3qJj0sLCCaR55/NrKi0jocLKvi0Ql/LlWLeT7Z8+xfImLZbmqYj+MrBETQsdjn v8tTY2JA4V3yRDEESd+Z7PcUbfJkF9WrPavKrmiY= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Nov 20 08:47:01 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 298D13A0FCA; Fri, 20 Nov 2020 08:47:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1605890821; bh=EXB/BacwO5nWLLGBNobcUZIzhEH0rN3x6I/7DjQ7Mr8=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=UaaSIK939k0501TasWHrw/d5SjY71ymJ5EWou2YuEV/kTKpdaaPRvTX5onUREgw02 irC6BXocfPlmzejL81vRKEA3/QCm3VCWdkF21xnX3FSZig8P281uP0YCCsEAkPU2kj hwPkmqIwZcxfX7a/WW7pFDf/dqEAENnySoYVLWJs= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD5E3A0ED7 for ; Fri, 20 Nov 2020 08:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9lN7AFqxoDe for ; Fri, 20 Nov 2020 08:46:51 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2AA43A0EB9 for ; Fri, 20 Nov 2020 08:46:51 -0800 (PST) Received: from [42.100.3.195] (helo=[192.168.0.101]) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kg9Yf-0004LG-VF for new-work@ietf.org; Fri, 20 Nov 2020 16:46:50 +0000 To: new-work@ietf.org From: xueyuan Message-ID: <0a210858-3ea4-4fac-f242-3fab79d25dcf@w3.org> Date: Sat, 21 Nov 2020 00:46:42 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Sat, 21 Nov 2020 01:05:36 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: MiniApps Working Group (until 2020-12-19/20) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 16:47:04 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsIHRvIApyZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgTWluaUFw cHMgV29ya2luZyBHcm91cDoKIMKgIGh0dHBzOi8vd3d3LnczLm9yZy8yMDIwLzExL3Byb3Bvc2Vk LW1pbmlhcHBzLXdnLWNoYXJ0ZXIuaHRtbAoKQXMgcGFydCBvZiBlbnN1cmluZyB0aGF0IHRoZSBj b21tdW5pdHkgaXMgYXdhcmUgb2YgcHJvcG9zZWQgd29yayBhdCBXM0MsIAp0aGlzIGRyYWZ0IGNo YXJ0ZXIgaXMgcHVibGljIGR1cmluZyB0aGUgQWR2aXNvcnkgQ29tbWl0dGVlIHJldmlldyBwZXJp b2QuCgpXM0MgaW52aXRlcyBwdWJsaWMgY29tbWVudHMgdGhyb3VnaCAwNDo1OSBVVEMgb24gMjAy MC0xMi0yMCAoMjM6NTksIApCb3N0b24gdGltZSBvbiAyMDIwLTEyLTE5KSBvbiB0aGUgcHJvcG9z ZWQgY2hhcnRlci4KClBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHB1YmxpYy1uZXctd29ya0B3My5v cmcsIHdoaWNoIGhhcyBhIHB1YmxpYyBhcmNoaXZlOgogwqAgaHR0cDovL2xpc3RzLnczLm9yZy9B cmNoaXZlcy9QdWJsaWMvcHVibGljLW5ldy13b3JrLwoKT3RoZXIgdGhhbiBjb21tZW50cyBzZW50 IGluIGZvcm1hbCByZXNwb25zZXMgYnkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSAKUmVwcmVzZW50 YXRpdmVzLCBXM0MgY2Fubm90IGd1YXJhbnRlZSBhIHJlc3BvbnNlIHRvIGNvbW1lbnRzLiBJZiB5 b3UgCndvcmsgZm9yIGEgVzNDIE1lbWJlciBbMV0sIHBsZWFzZSBjb29yZGluYXRlIHlvdXIgY29t bWVudHMgd2l0aCB5b3VyIApBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmUuIEZvciBl eGFtcGxlLCB5b3UgbWF5IHdpc2ggdG8gbWFrZSAKcHVibGljIGNvbW1lbnRzIHZpYSB0aGlzIGxp c3QgYW5kIGhhdmUgeW91ciBBZHZpc29yeSBDb21taXR0ZWUgClJlcHJlc2VudGF0aXZlIHJlZmVy IHRvIGl0IGZyb20gaGlzIG9yIGhlciBmb3JtYWwgcmV2aWV3IGNvbW1lbnRzLgoKSWYgeW91IHNo b3VsZCBoYXZlIGFueSBxdWVzdGlvbnMgb3IgbmVlZCBmdXJ0aGVyIGluZm9ybWF0aW9uLCBwbGVh c2UgCmNvbnRhY3QgRnVxaWFvIFh1ZSwgcHJvcG9zZWQgTWluaUFwcHMgV0cgVGVhbSBDb250YWN0 LCBhdCA8eGZxQHczLm9yZz4uCgpUaGFuayB5b3UsClh1ZXl1YW4gSmlhLMKgIFczQyBNYXJrZXRp bmcgJiBDb21tdW5pY2F0aW9ucwoKWzFdIGh0dHA6Ly93d3cudzMub3JnL0NvbnNvcnRpdW0vTWVt YmVyL0xpc3QKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cm5ldy13b3JrIG1haWxpbmcgbGlzdApuZXctd29ya0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldy13b3JrCg== From nobody Mon Nov 23 07:25:50 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1383A044E; Mon, 23 Nov 2020 07:25:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Montville via Datatracker To: Cc: last-call@ietf.org, draft-ietf-tls-oldversions-deprecate.all@ietf.org, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160614514380.28200.9053950536344915172@ietfa.amsl.com> Reply-To: Adam Montville Date: Mon, 23 Nov 2020 07:25:43 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-tls-oldversions-deprecate-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 15:25:44 -0000 Reviewer: Adam Montville Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is READY. It's a short, but comprehensive document deprecating use of TLS v1.1 and v1.2, and DTLS v1.0. This deprecation avoids reliance upon weak ciphersuites/cryptographic primitives, and should help focus implementations on a reduced number of requirements (i.e. no fall-back to weak protocols), which ideally results in fewer implementation errors. From nobody Mon Nov 23 08:40:24 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94653A0A0B; Mon, 23 Nov 2020 08:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BiWk-z0qEFW; Mon, 23 Nov 2020 08:40:16 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10127.outbound.protection.outlook.com [40.107.1.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ECD63A0A13; Mon, 23 Nov 2020 08:40:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZwTWe1pZciHICMsh7PauJo03oSLiW9C3oiK0oMMjIChKHjATqc7npvEFfllZh9EgqujBGTATebDB78MuTa4vI5XaeEwagGfB3tlWpBAldRNnyHvvQGbA+Wn5WLKerrOXJ2YDGQ3ViQaY61SP85NhInATp9Cy1xceQAoo68d1sP+u2gT9unlxjoXMUjKPfEIJASs5zYCzKGjsDAwUwvn/853+/QWsA7fnf8F4VnM+CJYx7MHg+Sr63qPSMu+EzzmadE7CHUE5+P7yAl3mR7y+enlguGPjrN/MlJwCf9tg+KafJYTD2X6VIkrs3X2dQe1Qos1fWiPveieWgu5Vc9MsFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L42qFQK+J5TfLlvZ7/xijKfneiLCawoKs+vImD0+y3Y=; b=Atk2FI9dqEhjCiWXXryu+abaHJGS593+uYlIB19VmSGcEj+9DVgj6KjCUid11iTgW+ovXJuVfmkCUtraECIPwUwCFE12T5MxCUkDg3MhJXMJc03ZwjV7Wt0M1UGwhSx+82dBhpLdz9nfDgo3WE2VWdI7i/14o48gLGwE4t0FXGMNrx0B0dyqREehvjrtpOz3SIDqOP/8CduLnQ6nrw2POfYMNuArNh8jiKKcqWq0eSO/6PiZIVKOgLY/aD+EDutrKZ2KSijwcT8YWj0y+0CIsrowKjb/5ieBtJ7hblL12HEp920u1QQ9rUW8NWLOEsmFfpCjEQoEe2OCXaEiFRTu/A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L42qFQK+J5TfLlvZ7/xijKfneiLCawoKs+vImD0+y3Y=; b=ixyb6goie4VBo5T8yeSzM2To95Iu8D2GgbIvggP2Hu29wTTvHGmcfw3yLYi8BoL8PCGa1HbylkTVl76zuJlIZWd9PXlptjL049/GMHh/6jC0U1T15k9+nKwCtzu8XIqdp/Yct/wVPG+F8ObqHJsuRphs27GHMCBmsSYWhD31sYs= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com; Received: from VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) by VI1PR0702MB3600.eurprd07.prod.outlook.com (2603:10a6:803:11::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.12; Mon, 23 Nov 2020 16:40:12 +0000 Received: from VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae]) by VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae%7]) with mapi id 15.20.3611.016; Mon, 23 Nov 2020 16:40:12 +0000 To: Adam Montville , secdir@ietf.org References: <160614514380.28200.9053950536344915172@ietfa.amsl.com> Cc: last-call@ietf.org, draft-ietf-tls-oldversions-deprecate.all@ietf.org From: tom petch Message-ID: <5FBBE5E6.2000801@btconnect.com> Date: Mon, 23 Nov 2020 16:40:06 +0000 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <160614514380.28200.9053950536344915172@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [86.146.121.140] X-ClientProxiedBy: LO3P265CA0003.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:bb::8) To VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.65] (86.146.121.140) by LO3P265CA0003.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:bb::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3589.20 via Frontend Transport; Mon, 23 Nov 2020 16:40:11 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3cd5faf0-2dd3-4d22-1a85-08d88fce7255 X-MS-TrafficTypeDiagnostic: VI1PR0702MB3600: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: meW8wrS1P6GNVFZZHfbqQa9ckvEhg8z7niwGl+PMJOf9pM0NX2+GNEl374B+6jC3PdrQzOSyCTItQHdIXpFQYnLLmcR2cA265Mbes8p/57RfBzzndhJsl2Og58QK13gpKvija7uOOkS7ysIqVRIy9vSndg/wnL6fVRXjAtrSxLU68JbBCH0J5gKhfbzk97/QZPDOL0kcC1HnPTlqXCCCW0Bfsz2Ugir1/e5OzYt4ApTphc12FIrvnrVDvjF9V86fthk2sM+fYN2od2KvCP66kEL/JyPTKCmioRvWNWtgm5aqcl+KuXzA6+Mpc/vMfwh/2NaVVI67f7jQ/tCrkvwzAA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6704.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(366004)(136003)(346002)(396003)(39860400002)(16526019)(33656002)(5660300002)(6666004)(4326008)(66946007)(26005)(66556008)(2616005)(956004)(53546011)(83380400001)(66476007)(6486002)(2906002)(87266011)(36756003)(86362001)(8676002)(4744005)(478600001)(186003)(316002)(52116002)(16576012)(8936002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: qMTy37GUVcq5U05sGIcrsrJzsOwP8EPnhrPIh2PxThqEFf1tK+fUOWuDMDepFH3/p12LtR+k7A4k3mzEglae4VdM40MUFSEBf/zEkTQ+mO47F1lCfzsRj9FnJf74pSSuTu+i2ZzqpTiyuFeVN3YWLJWeH1DVmDde4BVC+6j+b0OaunrHij4LSwgTsQT6YiJMRDRoC4VcTuQQbncDPksGo7mobzsN2kCmEzqsKy+JBzjLHlM3Egdqes30uQg9Z6JfcfiwQ2ZkTgoOe6duaDK9Ln7sQtmiFVX132W0Nvq7M/7TdWz8k7zcOG/ijzCIYkt7FrRlPUl0JSRXdZ+eQIOxoeUu3UtLLjuHJZmBQUwZsWXFjhp6yll1Yce1VzN003Ix4gj9ltaU0z/llVwlCXkR0Jx3IZNlO1nWbprXBMOtxm+fj7VaZfPUrEcflzZwdBsjvAEjRUmAFHCyxxFpSwhhGy4e55ohcQzHvpctg0o/oASPSFuJlOpmxgKwtwwhs5alQmIj3mp2syTrpTtdsKO9i0V09X0hQE7vcPj+QtzNg4ulHZ7oCpSpcws97IJyzz7G/Pjqpq6GcY7NTaO3wu/ZmWCfmm/Hb9reHMQWOIXPA5c0rc5je9/e5z2KwmSSqSjVPIbP5DP6TWP5kQKAloSZzKbOI2izIXj929Ps3e7UqHOoMHwoOyzXY3+NP1454R8pp4q1UIpOW5iuhC70o9vY9h5wcMF1e0DCaEl0SrW8rDcvr+cb/oWMOkRFa6CO+LZbiBEsURP8RUqrueY7MA/ORtpK1TDExOLosphbafX7Z4MwLXhHDg92+0qkSmMCQpbhwj8rlfnGWxJZXkrPrBJELThKf/EHEN4VoqAUElL4JHedKMt45zIcRnqgF/Ji3qTEOUPxCFJfrPpKrA/quyoLWA== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3cd5faf0-2dd3-4d22-1a85-08d88fce7255 X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Nov 2020 16:40:12.4318 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: HGOrw+OoDrKOD13uXkh/TxAIqBYizki3LHrtFStRqWi1bFqGCTdtuzSzQ02UDn/mOdGYVfDyN+tB7fFeZb/G7Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0702MB3600 Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-tls-oldversions-deprecate-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 16:40:18 -0000 On 23/11/2020 15:25, Adam Montville via Datatracker wrote: > Reviewer: Adam Montville > Review result: Ready > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The summary of the review is READY. > > It's a short, but comprehensive document deprecating use of TLS v1.1 and v1.2, > and DTLS v1.0. This deprecation avoids reliance upon weak Curious. I am sure that the version that I reviewed deprecated TLS v1.0 and not TLS v1.2 Tom Petch > ciphersuites/cryptographic primitives, and should help focus implementations on > a reduced number of requirements (i.e. no fall-back to weak protocols), which > ideally results in fewer implementation errors. > > From nobody Mon Nov 23 09:23:12 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72E33A07E6; Mon, 23 Nov 2020 09:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 xgQwEn1L8-lx; Mon, 23 Nov 2020 09:23:05 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFAD43A07DF; Mon, 23 Nov 2020 09:23:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A3467BE5D; Mon, 23 Nov 2020 17:23:02 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Yw0JAPbSdXy; Mon, 23 Nov 2020 17:23:01 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 07C0BBE5C; Mon, 23 Nov 2020 17:23:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1606152181; bh=8VHUAUWMIrN0VoZ4Wr0otPkhI22m1euiKFxr6TDkvto=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=YjJxoBFk0PxZhDJdVee/J4q0aUC6XptT/TGLy/AmSgEfJk9+mQurmFoSstjmZarMq eI1FTV3u25/Qfy14K72DC79nydTuDmZkTGDw5TYHmFqEf1t7KfPhR5RCTtScWxlSZH L9EsKBwC7KFWSTKdA++h8JXe/13lqK18a+Uyy4Ng= To: tom petch , Adam Montville , secdir@ietf.org Cc: last-call@ietf.org, draft-ietf-tls-oldversions-deprecate.all@ietf.org References: <160614514380.28200.9053950536344915172@ietfa.amsl.com> <5FBBE5E6.2000801@btconnect.com> From: Stephen Farrell Message-ID: Date: Mon, 23 Nov 2020 17:22:59 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.2 MIME-Version: 1.0 In-Reply-To: <5FBBE5E6.2000801@btconnect.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cCTBgPOgbu5M5uXX0fwRp47r5aJACiagq" Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-tls-oldversions-deprecate-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 17:23:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cCTBgPOgbu5M5uXX0fwRp47r5aJACiagq Content-Type: multipart/mixed; boundary="6HKHwJ8M4huNDB2jK4KX9JtpjKlwkKZ0C"; protected-headers="v1" From: Stephen Farrell To: tom petch , Adam Montville , secdir@ietf.org Cc: last-call@ietf.org, draft-ietf-tls-oldversions-deprecate.all@ietf.org Message-ID: Subject: Re: [Last-Call] Secdir last call review of draft-ietf-tls-oldversions-deprecate-09 References: <160614514380.28200.9053950536344915172@ietfa.amsl.com> <5FBBE5E6.2000801@btconnect.com> In-Reply-To: <5FBBE5E6.2000801@btconnect.com> --6HKHwJ8M4huNDB2jK4KX9JtpjKlwkKZ0C Content-Type: multipart/mixed; boundary="------------B61C79476C9AD560239FDEA4" Content-Language: en-US This is a multi-part message in MIME format. --------------B61C79476C9AD560239FDEA4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 23/11/2020 16:40, tom petch wrote: > I am sure that the version that I reviewed deprecated TLS v1.0 and not = > TLS=C2=A0v1.2 Correct. We're not doing 1.2 yet:-) I guess that was just a typo for 1.1 S. --------------B61C79476C9AD560239FDEA4 Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5= Cg8 gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq= 978 CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu= D/Q 9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4= tNn cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB= wV+ 4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir= 1GC YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav= ACY Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D= VQu 8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER= 8la 5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE= wEI ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC= xAA pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX= Az9 +VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL= F+X +degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4= g1U QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre= k3U P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2= niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL= 4Nw tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m= 6vt ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7= +8A CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ= LvC wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8= rpK o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr= qJs CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa= W/r KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG= gMW rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u= rqR 1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/= 0A9 J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc= JBD EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4= vrp 2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA= xvK dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK= xlf tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg= Uky o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO= aHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp= yyz JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ= uLE FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w= sDc BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer= 3UM TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP= jt5 uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK= 171 RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR= Lpg RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov= wza tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0= zG3 6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ= eah r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ= GNz LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o= 3cC GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo= w5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h= Rcs RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC= Y98 iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd= h2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4= EIk CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ= DIJ pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4= tvy a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4= ul3 qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc= G9g ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt= w/r 1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ= Jaf 3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1= 4Q0 7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf= qtu Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C= gHw 26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC= wIE FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL= rfb e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF= etu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8= v39 +qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr= 1oD 3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr= m2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby= y/A UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO= jao P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz= leL Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC= 2X4 pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g= 1MS BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34= YT0 auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb= edD Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3= 1qG /aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV= YW6 R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg= 4Im VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm= qyH eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx= qnk SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ= Esc YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n= 2Hw xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F= eIY jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E= AuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4= 2AY R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH= X5v aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q= Csw Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq= yA4 3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m= Eer 0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI= Dxz dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC= QgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ= i0B igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn= i9g OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy= sIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n= 66v xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/= 3r2 BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM= YtU N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr= 5iW XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/= zek ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b= a0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP= Ic2 gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6= XE6 i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1= 16u /HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J= G9a SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW= OMq N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz= 0YO K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4= vYl zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx= nNb KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+= 5HN HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq= 4hn l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn= Zbg JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d= nJj j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8= WLI aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc= dPC Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX= o4+ Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO= Tyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9= hZM 0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5= P3f WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp= cL2 lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk= etP GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3= zRq k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0= 20q pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U= DIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x= /nL PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE= hOV fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D= VI9 DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT= uW/ eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD= aWT 3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6= 1df mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8= MAv 2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA= HZR 5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo= qj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6= Mas qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi= RkM dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB= ++/ KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX= xMD rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf= ZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN= 2OE 0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT= zcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7= IKP 3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW= Iys s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------B61C79476C9AD560239FDEA4-- --6HKHwJ8M4huNDB2jK4KX9JtpjKlwkKZ0C-- --cCTBgPOgbu5M5uXX0fwRp47r5aJACiagq Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl+77/MFAwAAAAAACgkQWrL68XsXK+qQ bQ/8CN7elNSE+2FQPFnB/3rT6DbE/mAKTb9vB/itv5L3tDkgKpnQFNgRKffUnhTNGi3dJih6PQ8N zfUpyaqzMzgJ6t9ZAJAZP3j/9ZIhBTfj+f5fpOFzSYvFA0jy7+kJ1ueRZglz/U9iFDdfa8ciCUsi rmk0bWhDJk/R1CM6VX9wPRmizpW6oRtZjLckxvItLejyEO8KBGFog7/TzgelkRdMfO3+8buKjwHT cSsVspwEmHvS/zCOGBm8uNzafn93XXSVusg3PwS8nulMEd3PLiwi2q+sKv+SUhL1tkFhxCsxmYOL T2JsM6doXEwO58Hkr1qjhTZHn6CiWgj94TYCQXvH4slAAmxYoVLRFBljo1X6PAlUtsMgnTyMqhK4 LVBXTlm54ITJjH9ewW6MKmfjlSsgmAnvZSL3IoPMY+TOte4f/cH90vmsVeOc9GoCPEa80iw5nGAl opXlE0X1cTwALk2euDrbIHeHBjzn+mYqBHj93MCSiWuNR5sEzG4OPifNxRiz6ZiPCMKU/PmQPYEU VLjMOaTIsl+V4qwWJVRDXTdhTU69dlg8mEb9GV6G1CoQTEG6CUOd/RsdJqsNBufukYF0WWhAws4g TberZp5ov9E+CvqEOHYx6dLNyC1EudXkvNjCdKjnNbQBw0z3S3GsDVAmhuAArgHG3NMu87zpQSVq khU= =xO/+ -----END PGP SIGNATURE----- --cCTBgPOgbu5M5uXX0fwRp47r5aJACiagq-- From nobody Thu Nov 26 09:24:41 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEA53A1519 for ; Thu, 26 Nov 2020 09:24:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <160641148001.12191.17271997209288091500@ietfa.amsl.com> Date: Thu, 26 Nov 2020 09:24:40 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 17:24:40 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-12-03 Reviewer LC end Draft Daniel Gillmor 2020-09-30 draft-ietf-ccamp-layer0-types-08 Steve Hanna 2020-09-30 draft-ietf-ccamp-wson-yang-27 Joseph Salowey R2020-10-28 draft-ietf-anima-grasp-api-08 Christopher Wood R2019-11-06 draft-ietf-dtn-tcpclv4-23 For telechat 2020-12-17 Reviewer LC end Draft Stephen Farrell 2020-12-04 draft-ietf-dnsop-server-cookies-04 Daniel Migault R2020-10-19 draft-ietf-bess-mvpn-fast-failover-13 Mališa Vučinić 2020-12-04 draft-ietf-bmwg-b2b-frame-03 Last calls: Reviewer LC end Draft Donald Eastlake 2020-12-10 draft-ietf-teas-pce-native-ip-14 Shawn Emery 2020-12-08 draft-ietf-ippm-ioam-data-11 Stephen Farrell 2020-12-04 draft-ietf-dnsop-server-cookies-04 Daniel Franke 2020-09-18 draft-ietf-jmap-mdn-15 Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-10 Daniel Gillmor 2020-09-30 draft-ietf-ccamp-layer0-types-08 Phillip Hallam-Baker 2020-12-03 draft-ietf-tls-ticketrequests-06 Phillip Hallam-Baker 2020-09-30 draft-ietf-lwig-tcp-constrained-node-networks-13 Steve Hanna 2020-09-30 draft-ietf-ccamp-wson-yang-27 Dan Harkins None draft-ietf-rtgwg-policy-model-03 Leif Johansson 2020-10-02 draft-ietf-lpwan-schc-over-lorawan-13 Daniel Migault R2020-10-19 draft-ietf-bess-mvpn-fast-failover-13 Kathleen Moriarty 2020-07-20 draft-ietf-ace-oscore-profile-13 Russ Mundy 2020-07-20 draft-ietf-ace-dtls-authorize-14 Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer-05 Tirumaleswar Reddy.K 2020-11-16 draft-ietf-quic-transport-32 Joseph Salowey R2020-10-28 draft-ietf-anima-grasp-api-08 Rich Salz R2020-08-14 draft-ietf-suit-architecture-14 Mališa Vučinić 2020-12-04 draft-ietf-bmwg-b2b-frame-03 Carl Wallace 2020-12-09 draft-ietf-roll-unaware-leaves-23 Samuel Weiler 2020-12-02 draft-ietf-extra-sieve-mailboxid-05 Brian Weis 2020-12-02 draft-ietf-core-dev-urn-08 Klaas Wierenga 2020-12-02 draft-ietf-core-echo-request-tag-11 Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth-09 Christopher Wood 2020-09-23 draft-ietf-6man-rfc4941bis-12 Christopher Wood R2019-11-06 draft-ietf-dtn-tcpclv4-23 Paul Wouters 2020-11-30 draft-ietf-tcpm-rack-13 Paul Wouters 2020-09-08 draft-ietf-i2nsf-capability-data-model-13 Liang Xia 2020-11-30 draft-ietf-spring-sr-yang-26 Early review requests: Reviewer Due Draft Nancy Cam-Winget 2020-12-07 draft-ietf-idr-ext-opt-param-09 Linda Dunbar 2020-12-07 draft-ietf-idr-bgp-optimal-route-reflection-21 Steve Hanna 2020-12-23 draft-ietf-sfc-nsh-integrity-01 Dacheng Zhang 2020-12-07 draft-ietf-idr-eag-distribution-13 Next in the reviewer rotation: Dan Harkins Russ Housley Christian Huitema Leif Johansson Charlie Kaufman Scott Kelly Tero Kivinen Watson Ladd Chris Lonvick Aanchal Malhotra From nobody Thu Nov 26 16:15:46 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0863A082F; Thu, 26 Nov 2020 15:46:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1606434386; bh=W+Yk56IIxAESFpfMs64bBodgri7Yc+ghrGp5yQjDmag=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=o6V9aKvfE7xhACCY4Z5jxxQB0/rw8hO/IFSHSO2c1xezj98gtKlv5xNpdAGXsZOot UhCM8E+2YIm6VaNFKwzHT3OHvbJZ/EFr1bdo3H8Jtx/ywPPAdTQxXpyaCH6x53Bz5d otem8HfP+e924cP2F12+IiedNC8mAHlVLp5C7Oug= X-Mailbox-Line: From new-work-bounces@ietf.org Thu Nov 26 15:46:19 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2534C3A08A9; Thu, 26 Nov 2020 15:46:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1606434375; bh=W+Yk56IIxAESFpfMs64bBodgri7Yc+ghrGp5yQjDmag=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=Ocde79P6nlviLEVe+8jEj/VpGmpodZpVxoZS7xIX2VRL/S/ljnH8Sn0Q4STxQFzJJ 0MGa8GxIRbR50kDQdqboaDdzvfnercKQ/SPPiGykUAcyaIeATEsc8C5vrqaqUxFBhf kVdreeQ4i12gY+DfgD7ReY/JogQW3njNQl4TDuyU= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1B63A07E6 for ; Thu, 26 Nov 2020 15:46:08 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <160643436824.11589.7365269360672478077@ietfa.amsl.com> Date: Thu, 26 Nov 2020 15:46:08 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Reply-To: iesg@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 26 Nov 2020 16:15:45 -0800 Subject: [secdir] [new-work] WG Review: Open Specification for Pretty Good Privacy (openpgp) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 23:46:34 -0000 A new IETF WG has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2020-12-06. Open Specification for Pretty Good Privacy (openpgp) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Stephen Farrell Daniel Gillmor Assigned Area Director: Benjamin Kaduk Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: openpgp@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/openpgp Archive: https://mailarchive.ietf.org/arch/browse/openpgp/ Group page: https://datatracker.ietf.org/group/openpgp/ Charter: https://datatracker.ietf.org/doc/charter-ietf-openpgp/ OpenPGP is an Internet standard that covers object encryption, object signing, and identity certification. These were defined by the first incarnation of the OpenPGP working group. The following is an excerpt from the charter of the original incarnation of the openpgp working group > The goal of the OpenPGP working group is to provide IETF > standards for the algorithms and formats of PGP processed > objects as well as providing the MIME framework for exchanging > them via e-mail or other transport protocols. The working group concluded this work and was closed in March of 2008. In the intervening period, there has been a rough consensus reached that the RFC that defined the IETF openpgp standard, RFC4880, is in need of revision. This incarnation of the working group is chartered to primarily produce a revision of RFC4880 to address issues that have been identified by the community since the working group was originally closed. These revisions will include, but are not necessarily limited to: - Inclusion of elliptic curves recommended by the Crypto Forum Research Group (CFRG) (see note below) - A symmetric encryption mechanism that offers modern message integrity protection (e.g. AEAD) - Revision of mandatory-to-implement algorithm selection and deprecation of weak algorithms - An updated public-key fingerprint mechanism The Working Group will perform the following work: - Revise RFC4880. The intent is to start from the current rfc4880bis draft. - Other work related to OpenPGP may be entertained by the working group as long as it does not interfere with the completion of the RFC4880 revision. As the revision of RFC4880 is the primary goal of the working group, other work may be undertaken, so long as: 1. The work will not unduly delay the closure of the working group after the revision is finished (unless the working group is rechartered). 2. The work has widespread support in the working group. These additional work items may only be added with approval from the responsible Area Director who may additionally require re-chartering for certain work items, as needed. Inclusion of CFRG Curves ----------------------------- The Working Group will consider CFRG curves as possible Mandatory to Implement (MTI) algorithms. Working Group Process -------------------------- The working group will endeavor to complete most if not all of its work online on the working group's mailing list. We expect that the requirement for face-to-face sessions at IETF meetings to be minimal. For the revision of RFC 4880, all changes from RFC 4880, and for other work items, all content, require both consensus on the mailing list and the demonstration of interoperable support by at least two independent implementations, before being submitted to the IESG. Furthermore, the working group will adopt no I-D's as working group items unless there is a review by at least two un-interested parties of the I-D as part of the adoption process. Milestones: Jun 2021 - submit RFC 4880 revision to the IESG _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Nov 27 09:33:35 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8183A0AB4; Fri, 27 Nov 2020 09:33:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Paul Wouters via Datatracker To: Cc: tcpm@ietf.org, last-call@ietf.org, draft-ietf-tcpm-rack.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160649840913.22803.17626724526067078564@ietfa.amsl.com> Reply-To: Paul Wouters Date: Fri, 27 Nov 2020 09:33:29 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-tcpm-rack-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 17:33:29 -0000 Reviewer: Paul Wouters Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready I am not a TCP expert, but the text in the Security Considerations is clear and shows an actual increase in security compared to other methods of packet loss detection and retransmission. From nobody Sat Nov 28 11:47:15 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD2F3A0816; Sat, 28 Nov 2020 11:47:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey via Datatracker To: Cc: last-call@ietf.org, anima@ietf.org, draft-ietf-anima-grasp-api.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160659282546.13314.14594654200761429865@ietfa.amsl.com> Reply-To: Joseph Salowey Date: Sat, 28 Nov 2020 11:47:05 -0800 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-anima-grasp-api-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2020 19:47:06 -0000 Reviewer: Joseph Salowey Review result: Ready This document is ready, my comments were sufficiently addressed within the security capabilities the anima framework provides.