From nobody Wed Nov 8 09:27:51 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B09012946A; Wed, 8 Nov 2017 09:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 3I0OA-j42mmC; Wed, 8 Nov 2017 09:27:43 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E100612726E; Wed, 8 Nov 2017 09:27:42 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id r68so12031379wmr.1; Wed, 08 Nov 2017 09:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=jeOK59oT+VX71/wppbjdIOksV7hFkganrkwNxvkSmek=; b=jDRYthp+9qCz/O5rUDipqTpMJOzcqz6bWkYZeFCQnJw//m72SsM+XK3BIkASsw6okg yU+MDysfwDJYysN2QhUrY/FC7oOkm1szq7R8CCciAftWInh0Bdk29hBchaa7t9shqPUG Pv/YWkY83DFk7FnoRDQknXcbT0zIemdkb26qGEcvW8KmAIS8gyM70QUNXbTNA8DRPpfj usTTmpmYwJ2XPkTcKEmZgGmAMzSfLXnvY+2tIzDOWrkWdxy6njz8cjpybvaZABD/ygbX VHypadfnFQFqdCvJxk4BEWA61KVvWSisQIvZUlB+cbJZpyQMZ9p6+kS+lqeZMzZiXRbt 2/YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jeOK59oT+VX71/wppbjdIOksV7hFkganrkwNxvkSmek=; b=iTZSKgfABg0k5n87nmcRl+GbQDq+QZeJq9vVvkJnoqtmznRf089B9qTYhDa/AcvU94 CjOAEBnmy7OhSDmC+4Gon6YQ+lBrLx86cfIALJr3pwqNeQ2HtQdk8HsMxo5OZ9ATk5El cVILp05AErtcpHF5RSPwvLGcYjCKQDAXX6czl227FMhZQzj14YgwLJPDZGZMJ474bi46 sFF6/T6KYd7OhXN+KVsEN/H2sz0JIkUHmHvLku0rsgGYwfmdvm5Gi95C6BM9ZngAAHeL y5mDxjI919X37DiBT1430mWw4y0VjGGlHFv3ihMr+PxUTmq/zr3+UrXOnqlAzA978h5r IJ2g== X-Gm-Message-State: AJaThX7dGxT99Z0lrxLyn5Bq77uiFPWqlLNlSy/1eRBjL6zTvDe0zMdM 8WPfWFo6T9GRywFHnvPk26kJy8D4 X-Google-Smtp-Source: ABhQp+TnqIT9Mn9rbgz/m05Cm+0eyl/AIQbSdZNglFt3xnlfT+N5mj9QcE1BznjU679s3T2NzVqLcA== X-Received: by 10.80.144.178 with SMTP id c47mr429739eda.240.1510162061159; Wed, 08 Nov 2017 09:27:41 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id c5sm4340435edd.38.2017.11.08.09.27.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 09:27:40 -0800 (PST) From: Stewart Bryant To: sec-ads@ietf.org, "" Cc: "mpls-chairs@ietf.org" , "pals-chairs@tools.ietf.org" , "mpls@ietf.org" , "pals@ietf.org" References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <5994f353-5306-0fa8-2d2d-024ebdbb10df@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> Message-ID: <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> Date: Wed, 8 Nov 2017 17:27:39 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: [Pals] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 17:27:44 -0000 To the SEC and RTG ADs, I am sending the following message on behalf of the MPLS and the PALS WG Chairs. There is a concern shared among the security community and the working groups that develop the LDP protocol that LDP is no longer adequately secured. LDP currently relies on MD5 for cryptographic security of its messages, but MD5 is a hash function that is no longer considered to meet current security requirements. In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2. Session communication carried by TCP the following statements is made: "LDP specifies use of the TCP MD5 Signature Option to provide for the authenticity and integrity of session messages. "[RFC2385] asserts that MD5 authentication is now considered by some to be too weak for this application.  It also points out that a similar TCP option with a stronger hashing algorithm (it cites SHA-1 as an example) could be deployed.  To our knowledge, no such TCP option has been defined and deployed.  However, we note that LDP can use whatever TCP message digest techniques are available, and when one stronger than MD5 is specified and implemented, upgrading LDP to use it would be relatively straightforward." We note that BGP has already been through this process, and replaced MD5 with TCP-AO in RFC 7454. I would be logical to follow the same approach to secure LDP. However, as far as we are able to ascertain, there is currently no recommended, mandatory to implement, cryptographic function specified. We are concerned that without such a mandatory function, implementations will simply fall back to MD5 and we will be no further forward We think that the best way forward is to publish a draft similar to RFC 7454 that contains the following requirement: "Implementations conforming to this RFC MUST implement TCP-AO to secure the TCP sessions carrying LDP in addition to the currently required TCP MD5 Signature Option. Furthermore, the TBD cryptographic mechanism must be implemented and provided to TCP-AO to secure LDP messages. The TBD mechanism is the preferred option, and MD5 is only to be used when TBD is unavailable." We are not an experts on this part of the stack, but it seems that TCP security negotiation is still work in progress. If we are wrong, then we need to include a requirement that such negotiation is also required. In the absence of a negotiation protocol, however, we need to leave this as a configuration process until such time as the negotiation protocol work is complete. On completion of a suitable negotiation protocol we need to issue a further update requiring its use. Additionally we should note that no cryptographic mechanism has an indefinite lifetime, and that implementation should note the IETF anticipates updating the default cryptographic mechanism over time. The TBD default security function will need to be chosen such that it can reasonably be implemented on a typical router route processor, and which will provide adequate security without significantly degrading the convergence time of an LSR. Without a function that does not significantly impact router convergence we simply close one vulnerability and open another. As experts on the LDP protocol, but not on security mechanisms, we  need to ask the security area for a review of our proposed approach, and help correcting any misunderstanding of the security issues or our misunderstanding of the existing security mechanisms. We also need the recommendations of a suitable security function (TBD in the above text). Best regards The MPLS WG Chairs The PALS WG Chairs From nobody Wed Nov 8 10:00:47 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54041294E7 for ; Wed, 8 Nov 2017 10:00:40 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 juOk4EthJEHa for ; Wed, 8 Nov 2017 10:00:39 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 C802A1294EC for ; Wed, 8 Nov 2017 10:00:25 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id c186so421839ywb.2 for ; Wed, 08 Nov 2017 10:00:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/RZkCphureJliGcCJy7BoV6ea3Xb1ZNxAgGh4CysROY=; b=I7BFVOn8VXyCtTncIV8T051eeMvvdamx5bDGscfmIADTmKxFWtRhHQnemZPHba17ZE e1XgTy6YQz9fQObpC6E1kHVU4GQs6rKGTL7hZp63tDF97+QBepindbjWqJD3Bj1MYL2N UNSXGSI18pdEdopkcZZcnSsqaEZO5fIilgJO7ARcK+4SzLwCxIU/0XpZjU/SiflgXkIS z00Alj7bQFKhhSrrqEF+FG79qS6tRggAmmp/LAT1oV1FKYs1RxcCJMZcDAOG3l99DCDj pgSzxA3kJs6dxYlk3xtVz99MBXgQ0RAvpb9HUKierdrAlszBgHmAopPhYuZcvw1LfFbu Q23g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/RZkCphureJliGcCJy7BoV6ea3Xb1ZNxAgGh4CysROY=; b=ahxq9skqH8ngvsOkQvWhifM29UtOhcTwP6PiaOoFeniZFAXyGFlITxZfbk9rEryOd/ UIvYYowJdOsisW3f8oW7Gsg3jB8WxzEGQA/ooDod5kZ5vR7Y1wfRzjd/Kka5OngJy9qE QB1KlVlkkW9ag1ShMe186x5n+Vn4bC3H6DUtldaFCXkS7m/uDn9Iwi2LHP3mopnluNFd xCNYknc90+Yn3Aq7QfyQnNaGtNek8kt7EmKBFfKtpSgAaDk0NlvePYXvPN7a1Gl1IT7k K1WmeO12XNXhHTfC1I0YXHkGzj38UoOo0i/M9onaiAX//eMG2iJGW47sFnbz1hqxFb9I rSBw== X-Gm-Message-State: AJaThX5jJowwV9nZlDJgzgwpMZDkgP1LNd5RJZQhLJJLs7HJ3sdrF+fY GaNs328SqAduvEDrSw+4kQAsj2Pqqufju7Z3m1/muQ== X-Google-Smtp-Source: ABhQp+R0CZoUgFfT0eVATB7W+/Knr74Af/9k7/zBe7FO31l5n5Xt6ykG4rd2ww9mfVeRruJTviUExLbxHDiL5gTg1k4= X-Received: by 10.129.26.208 with SMTP id a199mr889107ywa.280.1510164024987; Wed, 08 Nov 2017 10:00:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Wed, 8 Nov 2017 09:59:44 -0800 (PST) In-Reply-To: <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <5994f353-5306-0fa8-2d2d-024ebdbb10df@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> From: Eric Rescorla Date: Wed, 8 Nov 2017 09:59:44 -0800 Message-ID: To: Stewart Bryant Cc: "" , "" , "mpls-chairs@ietf.org" , "pals-chairs@tools.ietf.org" , "mpls@ietf.org" , "pals@ietf.org" Content-Type: multipart/alternative; boundary="001a1142d0d4432907055d7c76f5" Archived-At: Subject: Re: [Pals] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 18:00:41 -0000 --001a1142d0d4432907055d7c76f5 Content-Type: text/plain; charset="UTF-8" Hi Stewart Thanks for your note. My overall sense of the state of play is, I think much like yours. TCP-MD5 is inadequate in two major respects: - It uses weak algorithms - It has a bad negotiation/setuop story (manual key management) TCP-AO is intended to be a drop-in replacement for TCP-MD5 and so remedies the algorithm issue but not the key management issue [0]. We haven't made much progress on the key management story, and that seems to be a major impediment to deploying either of these technologies (which I am given to understand don't see a lot of use). We should probably talk in Singapore about that, but that's not going to get better any time soon. In the interim, I think the text you have is OK, and "TBD" should read "SHA-256", with the fallback being SHA-256 -> SHA-1 -> MD5. -Ekr [0] Technically It has better support for rollover, but this is not a huge improvement. [1] tcpcrypt is kind of orthogonal here as it's unauthenticated but opportunistic. That said, it would provide defense against attackers who gain access to the link after connection setup and doesn't require configuration. On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant wrote: > To the SEC and RTG ADs, > > I am sending the following message on behalf of the MPLS and the > PALS WG Chairs. > > There is a concern shared among the security community and the working > groups that develop the LDP protocol that LDP is no longer adequately > secured. LDP currently relies on MD5 for cryptographic security of its > messages, but MD5 is a hash function that is no longer considered to meet > current security requirements. > > In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2. > Session communication carried by TCP the following statements is made: > > "LDP specifies use of the TCP MD5 Signature Option to provide for the > authenticity and integrity of session messages. > > "[RFC2385] asserts that MD5 authentication is now considered by some to be > too weak for this application. It also points out that a similar TCP > option with a stronger hashing algorithm (it cites SHA-1 as an example) > could be deployed. To our knowledge, no such TCP option has been defined > and deployed. However, we note that LDP can use whatever TCP message > digest techniques are available, and when one stronger than MD5 is > specified and implemented, upgrading LDP to use it would be relatively > straightforward." > > We note that BGP has already been through this process, and replaced MD5 > with TCP-AO in RFC 7454. I would be logical to follow the same approach to > secure LDP. However, as far as we are able to ascertain, there is currently > no recommended, mandatory to implement, cryptographic function specified. > We are concerned that without such a mandatory function, implementations > will simply fall back to MD5 and we will be no further forward > > We think that the best way forward is to publish a draft similar to RFC > 7454 that contains the following requirement: > > "Implementations conforming to this RFC MUST implement TCP-AO to secure > the TCP sessions carrying LDP in addition to the currently required TCP MD5 > Signature Option. Furthermore, the TBD cryptographic mechanism must be > implemented and provided to TCP-AO to secure LDP messages. The TBD > mechanism is the preferred option, and MD5 is only to be used when TBD is > unavailable." > > We are not an experts on this part of the stack, but it seems that TCP > security negotiation is still work in progress. If we are wrong, then we > need to include a requirement that such negotiation is also required. In > the absence of a negotiation protocol, however, we need to leave this as a > configuration process until such time as the negotiation protocol work is > complete. On completion of a suitable negotiation protocol we need to issue > a further update requiring its use. > > Additionally we should note that no cryptographic mechanism has an > indefinite lifetime, and that implementation should note the IETF > anticipates updating the default cryptographic mechanism over time. > > The TBD default security function will need to be chosen such that it can > reasonably be implemented on a typical router route processor, and which > will provide adequate security without significantly degrading the > convergence time of an LSR. Without a function that does not significantly > impact router convergence we simply close one vulnerability and open > another. > > As experts on the LDP protocol, but not on security mechanisms, we need > to ask the security area for a review of our proposed approach, and help > correcting any misunderstanding of the security issues or our > misunderstanding of the existing security mechanisms. We also need the > recommendations of a suitable security function (TBD in the above text). > > Best regards > > The MPLS WG Chairs > The PALS WG Chairs > > > --001a1142d0d4432907055d7c76f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Stewart

Thanks for your note.
<= div>
My overall sense of the state of play is, I think much l= ike yours.

TCP-MD5 is inadequate in two major resp= ects:
- It uses weak algorithms
- It has a bad nego= tiation/setuop story (manual key management)

TCP-A= O is intended to be a drop-in replacement for TCP-MD5 and so remedies the a= lgorithm
issue but not the key management issue [0]. We haven'= ;t made much progress on the key
management story, and that seems= to be a major impediment to deploying either of these
technologi= es (which I am given to understand don't see a lot of use). We should p= robably
talk in Singapore about that, but that's not going to= get better any time soon.

In the interim, I think= the text you have is OK, and "TBD" should read "SHA-256&quo= t;, with
the fallback being SHA-256 -> SHA-1 -> MD5.
<= div>
-Ekr


[0] Technic= ally It has better support for rollover, but this is not a huge improvement= .
[1] tcpcrypt is kind of orthogonal here as it's unauthentic= ated but opportunistic.=C2=A0 That said,
it would provide defense= against attackers who gain access to the link after connection
s= etup and doesn't require configuration.

On Wed, Nov 8, 2017 at 9:27 AM, Stewa= rt Bryant <stewart.bryant@gmail.com> wrote:
To the SEC and RTG ADs,

I am sending the following message on behalf of the MPLS and the
PALS WG Chairs.

There is a concern shared among the security community and the working grou= ps that develop the LDP protocol that LDP is no longer adequately secured. = LDP currently relies on MD5 for cryptographic security of its messages, but= MD5 is a hash function that is no longer considered to meet current securi= ty requirements.

In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2. Sessio= n communication carried by TCP the following statements is made:

"LDP specifies use of the TCP MD5 Signature Option to provide for the = authenticity and integrity of session messages.

"[RFC2385] asserts that MD5 authentication is now considered by some t= o be too weak for this application.=C2=A0 It also points out that a similar= TCP option with a stronger hashing algorithm (it cites SHA-1 as an example= ) could be deployed.=C2=A0 To our knowledge, no such TCP option has been de= fined and deployed.=C2=A0 However, we note that LDP can use whatever TCP me= ssage digest techniques are available, and when one stronger than MD5 is sp= ecified and implemented, upgrading LDP to use it would be relatively straig= htforward."

We note that BGP has already been through this process, and replaced MD5 wi= th TCP-AO in RFC 7454. I would be logical to follow the same approach to se= cure LDP. However, as far as we are able to ascertain, there is currently n= o recommended, mandatory to implement, cryptographic function specified. We= are concerned that without such a mandatory function, implementations will= simply fall back to MD5 and we will be no further forward

We think that the best way forward is to publish a draft similar to RFC 745= 4 that contains the following requirement:

"Implementations conforming to this RFC MUST implement TCP-AO to secur= e the TCP sessions carrying LDP in addition to the currently required TCP M= D5 Signature Option. Furthermore, the TBD cryptographic mechanism must be i= mplemented and provided to TCP-AO to secure LDP messages. The TBD mechanism= is the preferred option, and MD5 is only to be used when TBD is unavailabl= e."

We are not an experts on this part of the stack, but it seems that TCP secu= rity negotiation is still work in progress. If we are wrong, then we need t= o include a requirement that such negotiation is also required. In the abse= nce of a negotiation protocol, however, we need to leave this as a configur= ation process until such time as the negotiation protocol work is complete.= On completion of a suitable negotiation protocol we need to issue a furthe= r update requiring its use.

Additionally we should note that no cryptographic mechanism has an indefini= te lifetime, and that implementation should note the IETF anticipates updat= ing the default cryptographic mechanism over time.

The TBD default security function will need to be chosen such that it can r= easonably be implemented on a typical router route processor, and which wil= l provide adequate security without significantly degrading the convergence= time of an LSR. Without a function that does not significantly impact rout= er convergence we simply close one vulnerability and open another.

As experts on the LDP protocol, but not on security mechanisms, we=C2=A0 ne= ed to ask the security area for a review of our proposed approach, and help= correcting any misunderstanding of the security issues or our misunderstan= ding of the existing security mechanisms. We also need the recommendations = of a suitable security function (TBD in the above text).

Best regards

The MPLS WG Chairs
The PALS WG Chairs



--001a1142d0d4432907055d7c76f5-- From nobody Wed Nov 8 11:57:44 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B99A126DFF; Wed, 8 Nov 2017 11:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42ZtrYjA18aI; Wed, 8 Nov 2017 11:57:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36C91126D3F; Wed, 8 Nov 2017 11:57:38 -0800 (PST) Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DZK66155; Wed, 08 Nov 2017 19:57:36 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 8 Nov 2017 19:57:35 +0000 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.92]) by SJCEML702-CHM.china.huawei.com ([169.254.4.145]) with mapi id 14.03.0361.001; Wed, 8 Nov 2017 11:57:30 -0800 From: Uma Chunduri To: Eric Rescorla , Stewart Bryant CC: "mpls@ietf.org" , "pals-chairs@tools.ietf.org" , "" , "mpls-chairs@ietf.org" , "pals@ietf.org" , "" Thread-Topic: [mpls] LDP Security Thread-Index: AQHTWLbyOfMae53/m0ycVXrEQ0bS1aMLS2UA//+SrUA= Date: Wed, 8 Nov 2017 19:57:29 +0000 Message-ID: <25B4902B1192E84696414485F57268541351915D@sjceml521-mbs.china.huawei.com> References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <5994f353-5306-0fa8-2d2d-024ebdbb10df@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.168] Content-Type: multipart/alternative; boundary="_000_25B4902B1192E84696414485F57268541351915Dsjceml521mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5A0361B0.01D9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.92, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 14d312b36b9605c70916f063eabc04c2 Archived-At: Subject: Re: [Pals] [mpls] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 19:57:43 -0000 --_000_25B4902B1192E84696414485F57268541351915Dsjceml521mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3Rld2FydCwNCg0KSSB3b3VsZCBub3RlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM2OTUyIC0gd2hlcmUgTERQIHNlY3VyaXR5IGlzIGFuYWx5emVkIGZyb20gYWxsIGFzcGVjdHMu DQoNCkVyaWMsDQoNClF1aWNrIGNvbW1lbnRzIGJlbG93IFtVbWFdOg0KDQotLQ0KVW1hIEMuDQoN CkZyb206IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBF cmljIFJlc2NvcmxhDQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDA4LCAyMDE3IDEwOjAwIEFN DQpUbzogU3Rld2FydCBCcnlhbnQgPHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbT4NCkNjOiBtcGxz QGlldGYub3JnOyBwYWxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgPHJ0Zy1hZHNAaWV0Zi5vcmc+ IDxydGctYWRzQGlldGYub3JnPjsgbXBscy1jaGFpcnNAaWV0Zi5vcmc7IHBhbHNAaWV0Zi5vcmc7 IDxzZWMtYWRzQGlldGYub3JnPiA8c2VjLWFkc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbXBs c10gTERQIFNlY3VyaXR5DQoNCkhpIFN0ZXdhcnQNCg0KVGhhbmtzIGZvciB5b3VyIG5vdGUuDQoN Ck15IG92ZXJhbGwgc2Vuc2Ugb2YgdGhlIHN0YXRlIG9mIHBsYXkgaXMsIEkgdGhpbmsgbXVjaCBs aWtlIHlvdXJzLg0KDQpUQ1AtTUQ1IGlzIGluYWRlcXVhdGUgaW4gdHdvIG1ham9yIHJlc3BlY3Rz Og0KLSBJdCB1c2VzIHdlYWsgYWxnb3JpdGhtcw0KLSBJdCBoYXMgYSBiYWQgbmVnb3RpYXRpb24v c2V0dW9wIHN0b3J5IChtYW51YWwga2V5IG1hbmFnZW1lbnQpDQoNClRDUC1BTyBpcyBpbnRlbmRl ZCB0byBiZSBhIGRyb3AtaW4gcmVwbGFjZW1lbnQgZm9yIFRDUC1NRDUgYW5kIHNvIHJlbWVkaWVz IHRoZSBhbGdvcml0aG0NCklzc3VlDQoNCltVbWFdOiBZZXMsIGlmIHdlIGdvIHdpdGggUkZDIDU5 MjYgbWFuZGF0b3J5IGxpc3QuLg0KDQpidXQgbm90IHRoZSBrZXkgbWFuYWdlbWVudCBpc3N1ZSBb MF0uIFdlIGhhdmVuJ3QgbWFkZSBtdWNoIHByb2dyZXNzIG9uIHRoZSBrZXkNCm1hbmFnZW1lbnQg c3RvcnksIGFuZCB0aGF0IHNlZW1zIHRvIGJlIGEgbWFqb3IgaW1wZWRpbWVudCB0byBkZXBsb3lp bmcgZWl0aGVyIG9mIHRoZXNlDQp0ZWNobm9sb2dpZXMgKHdoaWNoIEkgYW0gZ2l2ZW4gdG8gdW5k ZXJzdGFuZCBkb24ndCBzZWUgYSBsb3Qgb2YgdXNlKS4NCg0KW1VtYV06IFRydWUuDQogICAgICAg ICAgICAgICBCdXQgSSB3b3VsZCBpbmRpY2F0ZSBzb21lIGVmZm9ydCBkb25lIGZldyB5ZWFycyBi YWNrIHJlZ2FyZGluZyBrZXkgbWFuYWdlbWVudCBmb3IgcGFpciB3aXNlIHJvdXRpbmcgcHJvdG9j b2xzIChCR1AsIExEUCwgUENFUCwgTVNEUCAuLikuDQogICAgICAgICAgICAgICBPbmUgc3VjaCBw cm9wb3NhbCBpcyBieSBleHRlbmRpbmcgSUtFdjIgdG8gbmVnb3RpYXRlIFRDUC1BTyBNS1RzICh3 aGljaCBjYW4gZ2l2ZSByZWtleSAmIGFsZ28uIGFnaWxpdHkpIC0gaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LW1haGVzaC1rYXJwLXJrbXAtMDUNCiAgICAgICAgICAgICAgIFRoaXMg YWxzbyByZXF1aXJlcyBzb21lIG1vcmUgd29yayB3aXRoIFRDUC1BTzsgbWUgJiBKb2UgcHV0IHRv Z2V0aGVyIGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtY2h1bmR1cmkta2Fy cC11c2luZy1pa2V2Mi13aXRoLXRjcC1hby0wNi50eHQNCiAgICAgICAgICAgTm90ZSB0aGUgYWJv dmUgZGlkbuKAmXQgcHJvZ3Jlc3MgaW4gdGhlIGNvbmNsdWRlZCBLQVJQIFdHIChub3QgZnVsbHkg c3VyZSB0aGUgcmVhc29ucyBvbiB3aHkpLg0KDQpXZSBzaG91bGQgcHJvYmFibHkgdGFsayBpbiBT aW5nYXBvcmUgYWJvdXQgdGhhdCwgYnV0IHRoYXQncyBub3QgZ29pbmcgdG8gZ2V0IGJldHRlciBh bnkgdGltZSBzb29uLg0KDQpJbiB0aGUgaW50ZXJpbSwgSSB0aGluayB0aGUgdGV4dCB5b3UgaGF2 ZSBpcyBPSywgYW5kICJUQkQiIHNob3VsZCByZWFkICJTSEEtMjU2Iiwgd2l0aA0KdGhlIGZhbGxi YWNrIGJlaW5nIFNIQS0yNTYgLT4gU0hBLTEgLT4gTUQ1Lg0KDQpbVW1hXTogV2hpbGUgdGhlIGxp c3QgY2FuIGJlIGV4dGVuZGVkIC0gSSBkaWRu4oCZdCBzZWUgU0hBMjU2IGluIHRoZSBtYW5kYXRv cnkgbGlzdCBpbiBSRkMgNTkyNiBmb3IgTUFDLg0KDQotRWtyDQoNCg0KWzBdIFRlY2huaWNhbGx5 IEl0IGhhcyBiZXR0ZXIgc3VwcG9ydCBmb3Igcm9sbG92ZXIsIGJ1dCB0aGlzIGlzIG5vdCBhIGh1 Z2UgaW1wcm92ZW1lbnQuDQpbMV0gdGNwY3J5cHQgaXMga2luZCBvZiBvcnRob2dvbmFsIGhlcmUg YXMgaXQncyB1bmF1dGhlbnRpY2F0ZWQgYnV0IG9wcG9ydHVuaXN0aWMuICBUaGF0IHNhaWQsDQpp dCB3b3VsZCBwcm92aWRlIGRlZmVuc2UgYWdhaW5zdCBhdHRhY2tlcnMgd2hvIGdhaW4gYWNjZXNz IHRvIHRoZSBsaW5rIGFmdGVyIGNvbm5lY3Rpb24NCnNldHVwIGFuZCBkb2Vzbid0IHJlcXVpcmUg Y29uZmlndXJhdGlvbi4NCg0KT24gV2VkLCBOb3YgOCwgMjAxNyBhdCA5OjI3IEFNLCBTdGV3YXJ0 IEJyeWFudCA8c3Rld2FydC5icnlhbnRAZ21haWwuY29tPG1haWx0bzpzdGV3YXJ0LmJyeWFudEBn bWFpbC5jb20+PiB3cm90ZToNClRvIHRoZSBTRUMgYW5kIFJURyBBRHMsDQoNCkkgYW0gc2VuZGlu ZyB0aGUgZm9sbG93aW5nIG1lc3NhZ2Ugb24gYmVoYWxmIG9mIHRoZSBNUExTIGFuZCB0aGUNClBB TFMgV0cgQ2hhaXJzLg0KDQpUaGVyZSBpcyBhIGNvbmNlcm4gc2hhcmVkIGFtb25nIHRoZSBzZWN1 cml0eSBjb21tdW5pdHkgYW5kIHRoZSB3b3JraW5nIGdyb3VwcyB0aGF0IGRldmVsb3AgdGhlIExE UCBwcm90b2NvbCB0aGF0IExEUCBpcyBubyBsb25nZXIgYWRlcXVhdGVseSBzZWN1cmVkLiBMRFAg Y3VycmVudGx5IHJlbGllcyBvbiBNRDUgZm9yIGNyeXB0b2dyYXBoaWMgc2VjdXJpdHkgb2YgaXRz IG1lc3NhZ2VzLCBidXQgTUQ1IGlzIGEgaGFzaCBmdW5jdGlvbiB0aGF0IGlzIG5vIGxvbmdlciBj b25zaWRlcmVkIHRvIG1lZXQgY3VycmVudCBzZWN1cml0eSByZXF1aXJlbWVudHMuDQoNCkluIFJG QzUwMzYgKHB1Ymxpc2hlZCAyMDA3KSBTZWN0aW9uIDUuMSAoU3Bvb2ZpbmcpICwgTGlzdCBlbGVt ZW50IDIuIFNlc3Npb24gY29tbXVuaWNhdGlvbiBjYXJyaWVkIGJ5IFRDUCB0aGUgZm9sbG93aW5n IHN0YXRlbWVudHMgaXMgbWFkZToNCg0KIkxEUCBzcGVjaWZpZXMgdXNlIG9mIHRoZSBUQ1AgTUQ1 IFNpZ25hdHVyZSBPcHRpb24gdG8gcHJvdmlkZSBmb3IgdGhlIGF1dGhlbnRpY2l0eSBhbmQgaW50 ZWdyaXR5IG9mIHNlc3Npb24gbWVzc2FnZXMuDQoNCiJbUkZDMjM4NV0gYXNzZXJ0cyB0aGF0IE1E NSBhdXRoZW50aWNhdGlvbiBpcyBub3cgY29uc2lkZXJlZCBieSBzb21lIHRvIGJlIHRvbyB3ZWFr IGZvciB0aGlzIGFwcGxpY2F0aW9uLiAgSXQgYWxzbyBwb2ludHMgb3V0IHRoYXQgYSBzaW1pbGFy IFRDUCBvcHRpb24gd2l0aCBhIHN0cm9uZ2VyIGhhc2hpbmcgYWxnb3JpdGhtIChpdCBjaXRlcyBT SEEtMSBhcyBhbiBleGFtcGxlKSBjb3VsZCBiZSBkZXBsb3llZC4gIFRvIG91ciBrbm93bGVkZ2Us IG5vIHN1Y2ggVENQIG9wdGlvbiBoYXMgYmVlbiBkZWZpbmVkIGFuZCBkZXBsb3llZC4gIEhvd2V2 ZXIsIHdlIG5vdGUgdGhhdCBMRFAgY2FuIHVzZSB3aGF0ZXZlciBUQ1AgbWVzc2FnZSBkaWdlc3Qg dGVjaG5pcXVlcyBhcmUgYXZhaWxhYmxlLCBhbmQgd2hlbiBvbmUgc3Ryb25nZXIgdGhhbiBNRDUg aXMgc3BlY2lmaWVkIGFuZCBpbXBsZW1lbnRlZCwgdXBncmFkaW5nIExEUCB0byB1c2UgaXQgd291 bGQgYmUgcmVsYXRpdmVseSBzdHJhaWdodGZvcndhcmQuIg0KDQpXZSBub3RlIHRoYXQgQkdQIGhh cyBhbHJlYWR5IGJlZW4gdGhyb3VnaCB0aGlzIHByb2Nlc3MsIGFuZCByZXBsYWNlZCBNRDUgd2l0 aCBUQ1AtQU8gaW4gUkZDIDc0NTQuIEkgd291bGQgYmUgbG9naWNhbCB0byBmb2xsb3cgdGhlIHNh bWUgYXBwcm9hY2ggdG8gc2VjdXJlIExEUC4gSG93ZXZlciwgYXMgZmFyIGFzIHdlIGFyZSBhYmxl IHRvIGFzY2VydGFpbiwgdGhlcmUgaXMgY3VycmVudGx5IG5vIHJlY29tbWVuZGVkLCBtYW5kYXRv cnkgdG8gaW1wbGVtZW50LCBjcnlwdG9ncmFwaGljIGZ1bmN0aW9uIHNwZWNpZmllZC4gV2UgYXJl IGNvbmNlcm5lZCB0aGF0IHdpdGhvdXQgc3VjaCBhIG1hbmRhdG9yeSBmdW5jdGlvbiwgaW1wbGVt ZW50YXRpb25zIHdpbGwgc2ltcGx5IGZhbGwgYmFjayB0byBNRDUgYW5kIHdlIHdpbGwgYmUgbm8g ZnVydGhlciBmb3J3YXJkDQoNCldlIHRoaW5rIHRoYXQgdGhlIGJlc3Qgd2F5IGZvcndhcmQgaXMg dG8gcHVibGlzaCBhIGRyYWZ0IHNpbWlsYXIgdG8gUkZDIDc0NTQgdGhhdCBjb250YWlucyB0aGUg Zm9sbG93aW5nIHJlcXVpcmVtZW50Og0KDQoiSW1wbGVtZW50YXRpb25zIGNvbmZvcm1pbmcgdG8g dGhpcyBSRkMgTVVTVCBpbXBsZW1lbnQgVENQLUFPIHRvIHNlY3VyZSB0aGUgVENQIHNlc3Npb25z IGNhcnJ5aW5nIExEUCBpbiBhZGRpdGlvbiB0byB0aGUgY3VycmVudGx5IHJlcXVpcmVkIFRDUCBN RDUgU2lnbmF0dXJlIE9wdGlvbi4gRnVydGhlcm1vcmUsIHRoZSBUQkQgY3J5cHRvZ3JhcGhpYyBt ZWNoYW5pc20gbXVzdCBiZSBpbXBsZW1lbnRlZCBhbmQgcHJvdmlkZWQgdG8gVENQLUFPIHRvIHNl Y3VyZSBMRFAgbWVzc2FnZXMuIFRoZSBUQkQgbWVjaGFuaXNtIGlzIHRoZSBwcmVmZXJyZWQgb3B0 aW9uLCBhbmQgTUQ1IGlzIG9ubHkgdG8gYmUgdXNlZCB3aGVuIFRCRCBpcyB1bmF2YWlsYWJsZS4i DQoNCldlIGFyZSBub3QgYW4gZXhwZXJ0cyBvbiB0aGlzIHBhcnQgb2YgdGhlIHN0YWNrLCBidXQg aXQgc2VlbXMgdGhhdCBUQ1Agc2VjdXJpdHkgbmVnb3RpYXRpb24gaXMgc3RpbGwgd29yayBpbiBw cm9ncmVzcy4gSWYgd2UgYXJlIHdyb25nLCB0aGVuIHdlIG5lZWQgdG8gaW5jbHVkZSBhIHJlcXVp cmVtZW50IHRoYXQgc3VjaCBuZWdvdGlhdGlvbiBpcyBhbHNvIHJlcXVpcmVkLiBJbiB0aGUgYWJz ZW5jZSBvZiBhIG5lZ290aWF0aW9uIHByb3RvY29sLCBob3dldmVyLCB3ZSBuZWVkIHRvIGxlYXZl IHRoaXMgYXMgYSBjb25maWd1cmF0aW9uIHByb2Nlc3MgdW50aWwgc3VjaCB0aW1lIGFzIHRoZSBu ZWdvdGlhdGlvbiBwcm90b2NvbCB3b3JrIGlzIGNvbXBsZXRlLiBPbiBjb21wbGV0aW9uIG9mIGEg c3VpdGFibGUgbmVnb3RpYXRpb24gcHJvdG9jb2wgd2UgbmVlZCB0byBpc3N1ZSBhIGZ1cnRoZXIg dXBkYXRlIHJlcXVpcmluZyBpdHMgdXNlLg0KDQpBZGRpdGlvbmFsbHkgd2Ugc2hvdWxkIG5vdGUg dGhhdCBubyBjcnlwdG9ncmFwaGljIG1lY2hhbmlzbSBoYXMgYW4gaW5kZWZpbml0ZSBsaWZldGlt ZSwgYW5kIHRoYXQgaW1wbGVtZW50YXRpb24gc2hvdWxkIG5vdGUgdGhlIElFVEYgYW50aWNpcGF0 ZXMgdXBkYXRpbmcgdGhlIGRlZmF1bHQgY3J5cHRvZ3JhcGhpYyBtZWNoYW5pc20gb3ZlciB0aW1l Lg0KDQpUaGUgVEJEIGRlZmF1bHQgc2VjdXJpdHkgZnVuY3Rpb24gd2lsbCBuZWVkIHRvIGJlIGNo b3NlbiBzdWNoIHRoYXQgaXQgY2FuIHJlYXNvbmFibHkgYmUgaW1wbGVtZW50ZWQgb24gYSB0eXBp Y2FsIHJvdXRlciByb3V0ZSBwcm9jZXNzb3IsIGFuZCB3aGljaCB3aWxsIHByb3ZpZGUgYWRlcXVh dGUgc2VjdXJpdHkgd2l0aG91dCBzaWduaWZpY2FudGx5IGRlZ3JhZGluZyB0aGUgY29udmVyZ2Vu Y2UgdGltZSBvZiBhbiBMU1IuIFdpdGhvdXQgYSBmdW5jdGlvbiB0aGF0IGRvZXMgbm90IHNpZ25p ZmljYW50bHkgaW1wYWN0IHJvdXRlciBjb252ZXJnZW5jZSB3ZSBzaW1wbHkgY2xvc2Ugb25lIHZ1 bG5lcmFiaWxpdHkgYW5kIG9wZW4gYW5vdGhlci4NCg0KQXMgZXhwZXJ0cyBvbiB0aGUgTERQIHBy b3RvY29sLCBidXQgbm90IG9uIHNlY3VyaXR5IG1lY2hhbmlzbXMsIHdlICBuZWVkIHRvIGFzayB0 aGUgc2VjdXJpdHkgYXJlYSBmb3IgYSByZXZpZXcgb2Ygb3VyIHByb3Bvc2VkIGFwcHJvYWNoLCBh bmQgaGVscCBjb3JyZWN0aW5nIGFueSBtaXN1bmRlcnN0YW5kaW5nIG9mIHRoZSBzZWN1cml0eSBp c3N1ZXMgb3Igb3VyIG1pc3VuZGVyc3RhbmRpbmcgb2YgdGhlIGV4aXN0aW5nIHNlY3VyaXR5IG1l Y2hhbmlzbXMuIFdlIGFsc28gbmVlZCB0aGUgcmVjb21tZW5kYXRpb25zIG9mIGEgc3VpdGFibGUg c2VjdXJpdHkgZnVuY3Rpb24gKFRCRCBpbiB0aGUgYWJvdmUgdGV4dCkuDQoNCkJlc3QgcmVnYXJk cw0KDQpUaGUgTVBMUyBXRyBDaGFpcnMNClRoZSBQQUxTIFdHIENoYWlycw0KDQoNCg== --_000_25B4902B1192E84696414485F57268541351915Dsjceml521mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJCcnVzaCBTY3JpcHQg TVQiOw0KCXBhbm9zZS0xOjMgNiA4IDIgNCA0IDYgNyAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiRnJlZXN0eWxlIFNjcmlwdCI7DQoJcGFub3NlLTE6MyA4IDQgMiAzIDIgNSAxMSA0 IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIg MSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SGkgU3Rld2FydCw8bzpwPjwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5JIHdvdWxkIG5vdGUNCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNjk1MiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNjk1Mjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiAtIHdoZXJlIExEUCBzZWN1cml0eQ0KIGlzIGFuYWx5emVkIGZyb20gYWxsIGFzcGVj dHMuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RXJpYyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlF1aWNrIGNvbW1lbnRzIGJl bG93IFtVbWFdOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LS08 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7RnJl ZXN0eWxlIFNjcmlwdCZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VW1h IEMuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0JydXNoIFNjcmlwdCBNVCZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gbXBscyBbbWFp bHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RXJpYyBSZXNj b3JsYTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE5vdmVtYmVyIDA4LCAyMDE3IDEwOjAw IEFNPGJyPg0KPGI+VG86PC9iPiBTdGV3YXJ0IEJyeWFudCAmbHQ7c3Rld2FydC5icnlhbnRAZ21h aWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gbXBsc0BpZXRmLm9yZzsgcGFscy1jaGFpcnNAdG9v bHMuaWV0Zi5vcmc7ICZsdDtydGctYWRzQGlldGYub3JnJmd0OyAmbHQ7cnRnLWFkc0BpZXRmLm9y ZyZndDs7IG1wbHMtY2hhaXJzQGlldGYub3JnOyBwYWxzQGlldGYub3JnOyAmbHQ7c2VjLWFkc0Bp ZXRmLm9yZyZndDsgJmx0O3NlYy1hZHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbbXBsc10gTERQIFNlY3VyaXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGkgU3Rld2FydDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhhbmtzIGZvciB5b3VyIG5vdGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IG92ZXJhbGwgc2Vuc2Ugb2YgdGhlIHN0YXRlIG9m IHBsYXkgaXMsIEkgdGhpbmsgbXVjaCBsaWtlIHlvdXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UQ1AtTUQ1IGlzIGluYWRlcXVhdGUgaW4g dHdvIG1ham9yIHJlc3BlY3RzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+LSBJdCB1c2VzIHdlYWsgYWxnb3JpdGhtczxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBJdCBoYXMgYSBiYWQgbmVnb3Rp YXRpb24vc2V0dW9wIHN0b3J5IChtYW51YWwga2V5IG1hbmFnZW1lbnQpPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRDUC1BTyBpcyBpbnRlbmRl ZCB0byBiZSBhIGRyb3AtaW4gcmVwbGFjZW1lbnQgZm9yIFRDUC1NRDUgYW5kIHNvIHJlbWVkaWVz IHRoZSBhbGdvcml0aG08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPklzc3VlPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1VtYV06IFllcywgaWYgd2UgZ28gd2l0aCBS RkMgNTkyNiBtYW5kYXRvcnkgbGlzdC4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJ1dCBub3QgdGhlIGtleSBtYW5h Z2VtZW50IGlzc3VlIFswXS4gV2UgaGF2ZW4ndCBtYWRlIG11Y2ggcHJvZ3Jlc3Mgb24gdGhlIGtl eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bWFu YWdlbWVudCBzdG9yeSwgYW5kIHRoYXQgc2VlbXMgdG8gYmUgYSBtYWpvciBpbXBlZGltZW50IHRv IGRlcGxveWluZyBlaXRoZXIgb2YgdGhlc2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRlY2hub2xvZ2llcyAod2hpY2ggSSBhbSBnaXZlbiB0byB1 bmRlcnN0YW5kIGRvbid0IHNlZSBhIGxvdCBvZiB1c2UpLg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1VtYV06 IFRydWUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7QnV0IEkgd291bGQgaW5kaWNhdGUgc29tZSBlZmZvcnQgZG9uZSBmZXcgeWVhcnMgYmFjayBy ZWdhcmRpbmcga2V5IG1hbmFnZW1lbnQgZm9yIHBhaXIgd2lzZSByb3V0aW5nIHByb3RvY29scyAo QkdQLCBMRFAsIFBDRVAsIE1TRFAgLi4pLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO09uZSBzdWNoIHByb3Bvc2FsIGlzIGJ5IGV4dGVuZGluZyBJ S0V2MiB0byBuZWdvdGlhdGUgVENQLUFPIE1LVHMgKHdoaWNoIGNhbiBnaXZlIHJla2V5ICZhbXA7 IGFsZ28uIGFnaWxpdHkpIC0NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtbWFoZXNoLWthcnAtcmttcC0wNSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LW1haGVzaC1rYXJwLXJrbXAtMDU8L2E+Jm5ic3A7DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO1RoaXMgYWxzbyByZXF1aXJlcyBzb21lIG1vcmUgd29yayB3aXRoIFRDUC1BTzsg bWUgJmFtcDsgSm9lIHB1dCB0b2dldGhlcg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtY2h1bmR1cmkta2FycC11c2luZy1pa2V2Mi13aXRoLXRj cC1hby0wNi50eHQiPmh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtY2h1bmR1 cmkta2FycC11c2luZy1pa2V2Mi13aXRoLXRjcC1hby0wNi50eHQ8L2E+DQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5Ob3RlIHRoZSBhYm92ZSBkaWRu4oCZdCBwcm9ncmVzcyBpbiB0aGUgY29uY2x1ZGVk IEtBUlAgV0cgKG5vdCBmdWxseSBzdXJlIHRoZSByZWFzb25zIG9uIHdoeSkuDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+V2Ugc2hvdWxkIHByb2JhYmx5PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPiA8L3NwYW4+dGFsayBpbiBTaW5nYXBvcmUgYWJvdXQgdGhhdCwgYnV0IHRoYXQncyBu b3QgZ29pbmcgdG8gZ2V0IGJldHRlciBhbnkgdGltZSBzb29uLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkluIHRoZSBpbnRlcmltLCBJIHRoaW5rIHRoZSB0ZXh0IHlvdSBoYXZlIGlzIE9LLCBhbmQgJnF1 b3Q7VEJEJnF1b3Q7IHNob3VsZCByZWFkICZxdW90O1NIQS0yNTYmcXVvdDssIHdpdGg8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBmYWxsYmFj ayBiZWluZyBTSEEtMjU2IC0mZ3Q7IFNIQS0xIC0mZ3Q7IE1ENS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+W1VtYV06IFdoaWxlIHRoZSBsaXN0IGNhbiBiZSBleHRlbmRlZCAt IEkgZGlkbuKAmXQgc2VlIFNIQTI1NiBpbiB0aGUgbWFuZGF0b3J5IGxpc3QgaW4gUkZDIDU5MjYg Zm9yIE1BQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5bMF0gVGVjaG5pY2FsbHkgSXQgaGFzIGJldHRlciBzdXBwb3J0IGZv ciByb2xsb3ZlciwgYnV0IHRoaXMgaXMgbm90IGEgaHVnZSBpbXByb3ZlbWVudC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlsxXSB0Y3BjcnlwdCBp cyBraW5kIG9mIG9ydGhvZ29uYWwgaGVyZSBhcyBpdCdzIHVuYXV0aGVudGljYXRlZCBidXQgb3Bw b3J0dW5pc3RpYy4mbmJzcDsgVGhhdCBzYWlkLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aXQgd291bGQgcHJvdmlkZSBkZWZlbnNlIGFnYWluc3Qg YXR0YWNrZXJzIHdobyBnYWluIGFjY2VzcyB0byB0aGUgbGluayBhZnRlciBjb25uZWN0aW9uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zZXR1cCBh bmQgZG9lc24ndCByZXF1aXJlIGNvbmZpZ3VyYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgTm92IDgsIDIwMTcgYXQgOToy NyBBTSwgU3Rld2FydCBCcnlhbnQgJmx0OzxhIGhyZWY9Im1haWx0bzpzdGV3YXJ0LmJyeWFudEBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zdGV3YXJ0LmJyeWFudEBnbWFpbC5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRvIHRoZSBTRUMgYW5kIFJURyBBRHMsPGJy Pg0KPGJyPg0KSSBhbSBzZW5kaW5nIHRoZSBmb2xsb3dpbmcgbWVzc2FnZSBvbiBiZWhhbGYgb2Yg dGhlIE1QTFMgYW5kIHRoZTxicj4NClBBTFMgV0cgQ2hhaXJzLjxicj4NCjxicj4NClRoZXJlIGlz IGEgY29uY2VybiBzaGFyZWQgYW1vbmcgdGhlIHNlY3VyaXR5IGNvbW11bml0eSBhbmQgdGhlIHdv cmtpbmcgZ3JvdXBzIHRoYXQgZGV2ZWxvcCB0aGUgTERQIHByb3RvY29sIHRoYXQgTERQIGlzIG5v IGxvbmdlciBhZGVxdWF0ZWx5IHNlY3VyZWQuIExEUCBjdXJyZW50bHkgcmVsaWVzIG9uIE1ENSBm b3IgY3J5cHRvZ3JhcGhpYyBzZWN1cml0eSBvZiBpdHMgbWVzc2FnZXMsIGJ1dCBNRDUgaXMgYSBo YXNoIGZ1bmN0aW9uIHRoYXQgaXMNCiBubyBsb25nZXIgY29uc2lkZXJlZCB0byBtZWV0IGN1cnJl bnQgc2VjdXJpdHkgcmVxdWlyZW1lbnRzLjxicj4NCjxicj4NCkluIFJGQzUwMzYgKHB1Ymxpc2hl ZCAyMDA3KSBTZWN0aW9uIDUuMSAoU3Bvb2ZpbmcpICwgTGlzdCBlbGVtZW50IDIuIFNlc3Npb24g Y29tbXVuaWNhdGlvbiBjYXJyaWVkIGJ5IFRDUCB0aGUgZm9sbG93aW5nIHN0YXRlbWVudHMgaXMg bWFkZTo8YnI+DQo8YnI+DQomcXVvdDtMRFAgc3BlY2lmaWVzIHVzZSBvZiB0aGUgVENQIE1ENSBT aWduYXR1cmUgT3B0aW9uIHRvIHByb3ZpZGUgZm9yIHRoZSBhdXRoZW50aWNpdHkgYW5kIGludGVn cml0eSBvZiBzZXNzaW9uIG1lc3NhZ2VzLjxicj4NCjxicj4NCiZxdW90O1tSRkMyMzg1XSBhc3Nl cnRzIHRoYXQgTUQ1IGF1dGhlbnRpY2F0aW9uIGlzIG5vdyBjb25zaWRlcmVkIGJ5IHNvbWUgdG8g YmUgdG9vIHdlYWsgZm9yIHRoaXMgYXBwbGljYXRpb24uJm5ic3A7IEl0IGFsc28gcG9pbnRzIG91 dCB0aGF0IGEgc2ltaWxhciBUQ1Agb3B0aW9uIHdpdGggYSBzdHJvbmdlciBoYXNoaW5nIGFsZ29y aXRobSAoaXQgY2l0ZXMgU0hBLTEgYXMgYW4gZXhhbXBsZSkgY291bGQgYmUgZGVwbG95ZWQuJm5i c3A7IFRvIG91ciBrbm93bGVkZ2UsIG5vDQogc3VjaCBUQ1Agb3B0aW9uIGhhcyBiZWVuIGRlZmlu ZWQgYW5kIGRlcGxveWVkLiZuYnNwOyBIb3dldmVyLCB3ZSBub3RlIHRoYXQgTERQIGNhbiB1c2Ug d2hhdGV2ZXIgVENQIG1lc3NhZ2UgZGlnZXN0IHRlY2huaXF1ZXMgYXJlIGF2YWlsYWJsZSwgYW5k IHdoZW4gb25lIHN0cm9uZ2VyIHRoYW4gTUQ1IGlzIHNwZWNpZmllZCBhbmQgaW1wbGVtZW50ZWQs IHVwZ3JhZGluZyBMRFAgdG8gdXNlIGl0IHdvdWxkIGJlIHJlbGF0aXZlbHkgc3RyYWlnaHRmb3J3 YXJkLiZxdW90Ozxicj4NCjxicj4NCldlIG5vdGUgdGhhdCBCR1AgaGFzIGFscmVhZHkgYmVlbiB0 aHJvdWdoIHRoaXMgcHJvY2VzcywgYW5kIHJlcGxhY2VkIE1ENSB3aXRoIFRDUC1BTyBpbiBSRkMg NzQ1NC4gSSB3b3VsZCBiZSBsb2dpY2FsIHRvIGZvbGxvdyB0aGUgc2FtZSBhcHByb2FjaCB0byBz ZWN1cmUgTERQLiBIb3dldmVyLCBhcyBmYXIgYXMgd2UgYXJlIGFibGUgdG8gYXNjZXJ0YWluLCB0 aGVyZSBpcyBjdXJyZW50bHkgbm8gcmVjb21tZW5kZWQsIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQs DQogY3J5cHRvZ3JhcGhpYyBmdW5jdGlvbiBzcGVjaWZpZWQuIFdlIGFyZSBjb25jZXJuZWQgdGhh dCB3aXRob3V0IHN1Y2ggYSBtYW5kYXRvcnkgZnVuY3Rpb24sIGltcGxlbWVudGF0aW9ucyB3aWxs IHNpbXBseSBmYWxsIGJhY2sgdG8gTUQ1IGFuZCB3ZSB3aWxsIGJlIG5vIGZ1cnRoZXIgZm9yd2Fy ZDxicj4NCjxicj4NCldlIHRoaW5rIHRoYXQgdGhlIGJlc3Qgd2F5IGZvcndhcmQgaXMgdG8gcHVi bGlzaCBhIGRyYWZ0IHNpbWlsYXIgdG8gUkZDIDc0NTQgdGhhdCBjb250YWlucyB0aGUgZm9sbG93 aW5nIHJlcXVpcmVtZW50Ojxicj4NCjxicj4NCiZxdW90O0ltcGxlbWVudGF0aW9ucyBjb25mb3Jt aW5nIHRvIHRoaXMgUkZDIE1VU1QgaW1wbGVtZW50IFRDUC1BTyB0byBzZWN1cmUgdGhlIFRDUCBz ZXNzaW9ucyBjYXJyeWluZyBMRFAgaW4gYWRkaXRpb24gdG8gdGhlIGN1cnJlbnRseSByZXF1aXJl ZCBUQ1AgTUQ1IFNpZ25hdHVyZSBPcHRpb24uIEZ1cnRoZXJtb3JlLCB0aGUgVEJEIGNyeXB0b2dy YXBoaWMgbWVjaGFuaXNtIG11c3QgYmUgaW1wbGVtZW50ZWQgYW5kIHByb3ZpZGVkIHRvIFRDUC1B TyB0bw0KIHNlY3VyZSBMRFAgbWVzc2FnZXMuIFRoZSBUQkQgbWVjaGFuaXNtIGlzIHRoZSBwcmVm ZXJyZWQgb3B0aW9uLCBhbmQgTUQ1IGlzIG9ubHkgdG8gYmUgdXNlZCB3aGVuIFRCRCBpcyB1bmF2 YWlsYWJsZS4mcXVvdDs8YnI+DQo8YnI+DQpXZSBhcmUgbm90IGFuIGV4cGVydHMgb24gdGhpcyBw YXJ0IG9mIHRoZSBzdGFjaywgYnV0IGl0IHNlZW1zIHRoYXQgVENQIHNlY3VyaXR5IG5lZ290aWF0 aW9uIGlzIHN0aWxsIHdvcmsgaW4gcHJvZ3Jlc3MuIElmIHdlIGFyZSB3cm9uZywgdGhlbiB3ZSBu ZWVkIHRvIGluY2x1ZGUgYSByZXF1aXJlbWVudCB0aGF0IHN1Y2ggbmVnb3RpYXRpb24gaXMgYWxz byByZXF1aXJlZC4gSW4gdGhlIGFic2VuY2Ugb2YgYSBuZWdvdGlhdGlvbiBwcm90b2NvbCwgaG93 ZXZlciwNCiB3ZSBuZWVkIHRvIGxlYXZlIHRoaXMgYXMgYSBjb25maWd1cmF0aW9uIHByb2Nlc3Mg dW50aWwgc3VjaCB0aW1lIGFzIHRoZSBuZWdvdGlhdGlvbiBwcm90b2NvbCB3b3JrIGlzIGNvbXBs ZXRlLiBPbiBjb21wbGV0aW9uIG9mIGEgc3VpdGFibGUgbmVnb3RpYXRpb24gcHJvdG9jb2wgd2Ug bmVlZCB0byBpc3N1ZSBhIGZ1cnRoZXIgdXBkYXRlIHJlcXVpcmluZyBpdHMgdXNlLjxicj4NCjxi cj4NCkFkZGl0aW9uYWxseSB3ZSBzaG91bGQgbm90ZSB0aGF0IG5vIGNyeXB0b2dyYXBoaWMgbWVj aGFuaXNtIGhhcyBhbiBpbmRlZmluaXRlIGxpZmV0aW1lLCBhbmQgdGhhdCBpbXBsZW1lbnRhdGlv biBzaG91bGQgbm90ZSB0aGUgSUVURiBhbnRpY2lwYXRlcyB1cGRhdGluZyB0aGUgZGVmYXVsdCBj cnlwdG9ncmFwaGljIG1lY2hhbmlzbSBvdmVyIHRpbWUuPGJyPg0KPGJyPg0KVGhlIFRCRCBkZWZh dWx0IHNlY3VyaXR5IGZ1bmN0aW9uIHdpbGwgbmVlZCB0byBiZSBjaG9zZW4gc3VjaCB0aGF0IGl0 IGNhbiByZWFzb25hYmx5IGJlIGltcGxlbWVudGVkIG9uIGEgdHlwaWNhbCByb3V0ZXIgcm91dGUg cHJvY2Vzc29yLCBhbmQgd2hpY2ggd2lsbCBwcm92aWRlIGFkZXF1YXRlIHNlY3VyaXR5IHdpdGhv dXQgc2lnbmlmaWNhbnRseSBkZWdyYWRpbmcgdGhlIGNvbnZlcmdlbmNlIHRpbWUgb2YgYW4gTFNS LiBXaXRob3V0IGEgZnVuY3Rpb24NCiB0aGF0IGRvZXMgbm90IHNpZ25pZmljYW50bHkgaW1wYWN0 IHJvdXRlciBjb252ZXJnZW5jZSB3ZSBzaW1wbHkgY2xvc2Ugb25lIHZ1bG5lcmFiaWxpdHkgYW5k IG9wZW4gYW5vdGhlci48YnI+DQo8YnI+DQpBcyBleHBlcnRzIG9uIHRoZSBMRFAgcHJvdG9jb2ws IGJ1dCBub3Qgb24gc2VjdXJpdHkgbWVjaGFuaXNtcywgd2UmbmJzcDsgbmVlZCB0byBhc2sgdGhl IHNlY3VyaXR5IGFyZWEgZm9yIGEgcmV2aWV3IG9mIG91ciBwcm9wb3NlZCBhcHByb2FjaCwgYW5k IGhlbHAgY29ycmVjdGluZyBhbnkgbWlzdW5kZXJzdGFuZGluZyBvZiB0aGUgc2VjdXJpdHkgaXNz dWVzIG9yIG91ciBtaXN1bmRlcnN0YW5kaW5nIG9mIHRoZSBleGlzdGluZyBzZWN1cml0eSBtZWNo YW5pc21zLg0KIFdlIGFsc28gbmVlZCB0aGUgcmVjb21tZW5kYXRpb25zIG9mIGEgc3VpdGFibGUg c2VjdXJpdHkgZnVuY3Rpb24gKFRCRCBpbiB0aGUgYWJvdmUgdGV4dCkuPGJyPg0KPGJyPg0KQmVz dCByZWdhcmRzPGJyPg0KPGJyPg0KVGhlIE1QTFMgV0cgQ2hhaXJzPGJyPg0KVGhlIFBBTFMgV0cg Q2hhaXJzPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_25B4902B1192E84696414485F57268541351915Dsjceml521mbschi_-- From nobody Wed Nov 8 12:53:33 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B403129BEF for ; Wed, 8 Nov 2017 12:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 gCPonmLSP081 for ; Wed, 8 Nov 2017 12:53:25 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 D23BD129BF0 for ; Wed, 8 Nov 2017 12:53:22 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id k3so3469863ywk.8 for ; Wed, 08 Nov 2017 12:53:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GBXv3fjmoifgs2bTfFEd/Y+Z6YL2UrfYuI4s5yqrBw8=; b=t9afKuIHH0xfXCZsDraQLqnC8UDzB6lyjQbR12SxEn2H72abuK647uxxN0Nzeu+36J iWYQX8jtkCXC+CR7VxgZx4M0e/R+OW0o+OoKT1c7nuvOBno0P7ocmKPKJgtv/cOEXX3D fezp2IfosYk40PDAUm2f+720ItTfVVFuGYF4yoRy/G9VpvGgJp23/aWtxUdxyhUkuid1 ym3ETGdQkr8FRLUpGuhV5FoRLwEDbCAq27T/fGrOu4v3AxT0P7biZ4n7ogp2Lol4Wmhd oNsdWLV/BiXrbRLd0eV1006g9V/uagCCY+wHoXarjcNTmn/UQBQ5TCSIxSh41U4uYg9H qQYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GBXv3fjmoifgs2bTfFEd/Y+Z6YL2UrfYuI4s5yqrBw8=; b=JXukr/db6zDXj/DpWeAicPnVnuVheDAV35mqIIDGWB/nyWen2i0UrqfScnUDWRD8fD zHWJ+Xf3hoEEUJgbHfuogmsxaL2QqlV4J4mMMl2LzUy+w73C54ALpO5wSI9Fi0zecJtu ELmu7EqNbGc2R1wgexWHBvGIRcg6/ZbXGhLXLPUYMubhA5IBECd9RSvJWHdEsPB+Knrn OcyKnOaDCtJ/c30sI3y44/X0RqBK2pfTV5W09SAyWT9aL5REJlrL2VXbfolG4tbK3ZRu 7LpxSfZk9hP7lB94e+Mm01+VxfmpP6/QMkvRm6odV1CRzxZfgx3tyhgrACOSxNQxzoNt zCUw== X-Gm-Message-State: AJaThX4E4VtQJhOjCgf/KOanpywD91scDNfRYeURDwevVWPicfmuerYW 1iMW6MRvvfEdJrXCrY0NC+IVGBSWuCgI37zeKOlN+Q== X-Google-Smtp-Source: ABhQp+TCdFSl2i3LKNcwwoMuBZchMlbEkjP9uBKDp83NWSZKlal1p87d0lC53vxI4gRJ4ntGn/KzmnlLTvl7nwNzCoE= X-Received: by 10.37.209.208 with SMTP id i199mr1213171ybg.339.1510174401937; Wed, 08 Nov 2017 12:53:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Wed, 8 Nov 2017 12:52:40 -0800 (PST) In-Reply-To: <25B4902B1192E84696414485F57268541351915D@sjceml521-mbs.china.huawei.com> References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <5994f353-5306-0fa8-2d2d-024ebdbb10df@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> <25B4902B1192E84696414485F57268541351915D@sjceml521-mbs.china.huawei.com> From: Eric Rescorla Date: Wed, 8 Nov 2017 12:52:40 -0800 Message-ID: To: Uma Chunduri Cc: Stewart Bryant , "mpls@ietf.org" , "pals-chairs@tools.ietf.org" , "" , "mpls-chairs@ietf.org" , "pals@ietf.org" , "" Content-Type: multipart/alternative; boundary="94eb2c05e1a6c6da8d055d7ee0eb" Archived-At: Subject: Re: [Pals] [mpls] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 20:53:28 -0000 --94eb2c05e1a6c6da8d055d7ee0eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 8, 2017 at 11:57 AM, Uma Chunduri wrote: > Hi Stewart, > > > > I would note https://tools.ietf.org/html/rfc6952 - where LDP security is > analyzed from all aspects. > > > > Eric, > > > > Quick comments below [Uma]: > > > > -- > > Uma C. > > > > *From:* mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Eric Rescorla > *Sent:* Wednesday, November 08, 2017 10:00 AM > *To:* Stewart Bryant > *Cc:* mpls@ietf.org; pals-chairs@tools.ietf.org; < > rtg-ads@ietf.org>; mpls-chairs@ietf.org; pals@ietf.org; > > *Subject:* Re: [mpls] LDP Security > > > > Hi Stewart > > > > Thanks for your note. > > > > My overall sense of the state of play is, I think much like yours. > > > > TCP-MD5 is inadequate in two major respects: > > - It uses weak algorithms > > - It has a bad negotiation/setuop story (manual key management) > > > > TCP-AO is intended to be a drop-in replacement for TCP-MD5 and so remedie= s > the algorithm > > Issue > > > > [Uma]: Yes, if we go with RFC 5926 mandatory list.. > > > > but not the key management issue [0]. We haven't made much progress on th= e > key > > management story, and that seems to be a major impediment to deploying > either of these > > technologies (which I am given to understand don't see a lot of use). > > > > [Uma]: True. > > But I would indicate some effort done few years back > regarding key management for pair wise routing protocols (BGP, LDP, PCEP, > MSDP ..). > > One such proposal is by extending IKEv2 to negotiate TCP-A= O > MKTs (which can give rekey & algo. agility) - https://tools.ietf.org/html= / > draft-mahesh-karp-rkmp-05 > > This also requires some more work with TCP-AO; me & Joe pu= t > together https://www.ietf.org/archive/id/draft-chunduri-karp-using- > ikev2-with-tcp-ao-06.txt > > Note the above didn=E2=80=99t progress in the concluded KARP W= G (not > fully sure the reasons on why). > Yeah, I know that people tried to do this, but my impression was it kinda didn't progress much. > We should probably talk in Singapore about that, but that's not going to > get better any time soon. > > > > In the interim, I think the text you have is OK, and "TBD" should read > "SHA-256", with > > the fallback being SHA-256 -> SHA-1 -> MD5. > > > > [Uma]: While the list can be extended - I didn=E2=80=99t see SHA256 in th= e > mandatory list in RFC 5926 for MAC. > Generally we're trying to move away from SHA-1 towards SHA-256. -Ekr > > -Ekr > > > > > > [0] Technically It has better support for rollover, but this is not a hug= e > improvement. > > [1] tcpcrypt is kind of orthogonal here as it's unauthenticated but > opportunistic. That said, > > it would provide defense against attackers who gain access to the link > after connection > > setup and doesn't require configuration. > > > > On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant > wrote: > > To the SEC and RTG ADs, > > I am sending the following message on behalf of the MPLS and the > PALS WG Chairs. > > There is a concern shared among the security community and the working > groups that develop the LDP protocol that LDP is no longer adequately > secured. LDP currently relies on MD5 for cryptographic security of its > messages, but MD5 is a hash function that is no longer considered to meet > current security requirements. > > In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2. > Session communication carried by TCP the following statements is made: > > "LDP specifies use of the TCP MD5 Signature Option to provide for the > authenticity and integrity of session messages. > > "[RFC2385] asserts that MD5 authentication is now considered by some to b= e > too weak for this application. It also points out that a similar TCP > option with a stronger hashing algorithm (it cites SHA-1 as an example) > could be deployed. To our knowledge, no such TCP option has been defined > and deployed. However, we note that LDP can use whatever TCP message > digest techniques are available, and when one stronger than MD5 is > specified and implemented, upgrading LDP to use it would be relatively > straightforward." > > We note that BGP has already been through this process, and replaced MD5 > with TCP-AO in RFC 7454. I would be logical to follow the same approach t= o > secure LDP. However, as far as we are able to ascertain, there is current= ly > no recommended, mandatory to implement, cryptographic function specified. > We are concerned that without such a mandatory function, implementations > will simply fall back to MD5 and we will be no further forward > > We think that the best way forward is to publish a draft similar to RFC > 7454 that contains the following requirement: > > "Implementations conforming to this RFC MUST implement TCP-AO to secure > the TCP sessions carrying LDP in addition to the currently required TCP M= D5 > Signature Option. Furthermore, the TBD cryptographic mechanism must be > implemented and provided to TCP-AO to secure LDP messages. The TBD > mechanism is the preferred option, and MD5 is only to be used when TBD is > unavailable." > > We are not an experts on this part of the stack, but it seems that TCP > security negotiation is still work in progress. If we are wrong, then we > need to include a requirement that such negotiation is also required. In > the absence of a negotiation protocol, however, we need to leave this as = a > configuration process until such time as the negotiation protocol work is > complete. On completion of a suitable negotiation protocol we need to iss= ue > a further update requiring its use. > > Additionally we should note that no cryptographic mechanism has an > indefinite lifetime, and that implementation should note the IETF > anticipates updating the default cryptographic mechanism over time. > > The TBD default security function will need to be chosen such that it can > reasonably be implemented on a typical router route processor, and which > will provide adequate security without significantly degrading the > convergence time of an LSR. Without a function that does not significantl= y > impact router convergence we simply close one vulnerability and open > another. > > As experts on the LDP protocol, but not on security mechanisms, we need > to ask the security area for a review of our proposed approach, and help > correcting any misunderstanding of the security issues or our > misunderstanding of the existing security mechanisms. We also need the > recommendations of a suitable security function (TBD in the above text). > > Best regards > > The MPLS WG Chairs > The PALS WG Chairs > > > --94eb2c05e1a6c6da8d055d7ee0eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 8, 2017 at 11:57 AM, Uma Chunduri <uma.chunduri@huaw= ei.com> wrote:

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:#1f497d">Hi Stewart,

=C2=A0

I would note h= ttps://tools.ietf.org/html/rfc6952 - where L= DP security is analyzed from all aspects.

=C2=A0

Eric,

=C2=A0

Quick comments below [Uma]:=

=C2=A0

--<= /span>

Uma C.

=C2=A0

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Wednesday, November 08, 2017 10:00 AM
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: mpls@ietf.org= ; pals-= chairs@tools.ietf.org; <rtg-ads@ietf.org> <rtg-ads@ietf.org>; mpls-chairs@ietf.org; pals@ietf.org; <sec-ads@ietf.org> <sec-ads@ietf.org>
Subject: Re: [mpls] LDP Security

=C2=A0

Hi Stewart

=C2=A0

Thanks for your note.

=C2=A0

My overall sense of the state of play is, I think mu= ch like yours.

=C2=A0

TCP-MD5 is inadequate in two major respects:<= u>

- It uses weak algorithms

- It has a bad negotiation/setuop story (manual key = management)

=C2=A0

TCP-AO is intended to be a drop-in replacement for T= CP-MD5 and so remedies the algorithm

Issue

=C2=A0

[Uma]: Yes, if we go with RFC 5926 ma= ndatory list..

=C2=A0

but not the key management issue [0]. We haven't= made much progress on the key

management story, and that seems to be a major imped= iment to deploying either of these

technologies (which I am given to understand don'= ;t see a lot of use).

=C2=A0

[Uma]: True.

=C2=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=A0But I would indicate = some effort done few years back regarding key management for pair wise rout= ing protocols (BGP, LDP, PCEP, MSDP ..).

=C2=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=A0One such proposal is = by extending IKEv2 to negotiate TCP-AO MKTs (which can give rekey & alg= o. agility) - https://tools.ietf.org/html/draft-mahesh-karp-rkmp-05<= /a>=C2=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=A0This also requires so= me more work with TCP-AO; me & Joe put together https://www.ietf.org/archive/<= wbr>id/draft-chunduri-karp-using-ikev2-with-tcp-ao-06.txt

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0Note the above didn=E2=80=99t progress in the= concluded KARP WG (not fully sure the reasons on why).


Yeah, I know that people tr= ied to do this, but my impression was it kinda didn't progress much.


=C2=A0

We should probably talk in Singapore about that, but that's not going to get better an= y time soon.

=C2=A0

In the interim, I think the text you have is OK, and= "TBD" should read "SHA-256", with

the fallback being SHA-256 -> SHA-1 -> MD5.=

=C2=A0

[Uma]: While the list can be e= xtended - I didn=E2=80=99t see SHA256 in the mandatory list in RFC 5926 for= MAC.


Ge= nerally we're trying to move away from SHA-1 towards SHA-256.

-Ekr

<= /u>

=C2=A0

-Ekr

=C2=A0

=C2=A0

[0] Technically It has better support for rollover, = but this is not a huge improvement.

[1] tcpcrypt is kind of orthogonal here as it's = unauthenticated but opportunistic.=C2=A0 That said,

it would provide defense against attackers who gain = access to the link after connection

setup and doesn't require configuration.<= u>

=C2=A0

On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant <<= a href=3D"mailto:stewart.bryant@gmail.com" target=3D"_blank">stewart.bryant= @gmail.com> wrote:

To the SEC and RTG AD= s,

I am sending the following message on behalf of the MPLS and the
PALS WG Chairs.

There is a concern shared among the security community and the working grou= ps that develop the LDP protocol that LDP is no longer adequately secured. = LDP currently relies on MD5 for cryptographic security of its messages, but= MD5 is a hash function that is no longer considered to meet current security requirements.

In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2. Sessio= n communication carried by TCP the following statements is made:

"LDP specifies use of the TCP MD5 Signature Option to provide for the = authenticity and integrity of session messages.

"[RFC2385] asserts that MD5 authentication is now considered by some t= o be too weak for this application.=C2=A0 It also points out that a similar= TCP option with a stronger hashing algorithm (it cites SHA-1 as an example= ) could be deployed.=C2=A0 To our knowledge, no such TCP option has been defined and deployed.=C2=A0 However, we note that= LDP can use whatever TCP message digest techniques are available, and when= one stronger than MD5 is specified and implemented, upgrading LDP to use i= t would be relatively straightforward."

We note that BGP has already been through this process, and replaced MD5 wi= th TCP-AO in RFC 7454. I would be logical to follow the same approach to se= cure LDP. However, as far as we are able to ascertain, there is currently n= o recommended, mandatory to implement, cryptographic function specified. We are concerned that without such a man= datory function, implementations will simply fall back to MD5 and we will b= e no further forward

We think that the best way forward is to publish a draft similar to RFC 745= 4 that contains the following requirement:

"Implementations conforming to this RFC MUST implement TCP-AO to secur= e the TCP sessions carrying LDP in addition to the currently required TCP M= D5 Signature Option. Furthermore, the TBD cryptographic mechanism must be i= mplemented and provided to TCP-AO to secure LDP messages. The TBD mechanism is the preferred option, and MD5 is= only to be used when TBD is unavailable."

We are not an experts on this part of the stack, but it seems that TCP secu= rity negotiation is still work in progress. If we are wrong, then we need t= o include a requirement that such negotiation is also required. In the abse= nce of a negotiation protocol, however, we need to leave this as a configuration process until such time as the ne= gotiation protocol work is complete. On completion of a suitable negotiatio= n protocol we need to issue a further update requiring its use.

Additionally we should note that no cryptographic mechanism has an indefini= te lifetime, and that implementation should note the IETF anticipates updat= ing the default cryptographic mechanism over time.

The TBD default security function will need to be chosen such that it can r= easonably be implemented on a typical router route processor, and which wil= l provide adequate security without significantly degrading the convergence= time of an LSR. Without a function that does not significantly impact router convergence we simply close one = vulnerability and open another.

As experts on the LDP protocol, but not on security mechanisms, we=C2=A0 ne= ed to ask the security area for a review of our proposed approach, and help= correcting any misunderstanding of the security issues or our misunderstan= ding of the existing security mechanisms. We also need the recommendations of a suitable security function (TBD in t= he above text).

Best regards

The MPLS WG Chairs
The PALS WG Chairs

=C2=A0


--94eb2c05e1a6c6da8d055d7ee0eb-- From nobody Wed Nov 8 13:34:26 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58C3126DEE; Wed, 8 Nov 2017 13:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMmRrrYhRu-4; Wed, 8 Nov 2017 13:34:23 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 B1760126BF7; Wed, 8 Nov 2017 13:34:22 -0800 (PST) X-AuditID: c618062d-8d7ff70000004288-f3-5a03785d200c Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 6C.D4.17032.D58730A5; Wed, 8 Nov 2017 22:34:21 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0352.000; Wed, 8 Nov 2017 16:34:21 -0500 From: Eric Gray To: Stewart Bryant , "sec-ads@ietf.org" , "" CC: "mpls@ietf.org" , "pals-chairs@tools.ietf.org" , "mpls-chairs@ietf.org" , "pals@ietf.org" Thread-Topic: [mpls] LDP Security Thread-Index: AQHTWLbpcFjTDKhuoEWsKIVkOj1Ru6MLAD6w Date: Wed, 8 Nov 2017 21:34:20 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF64B870052@eusaamb107.ericsson.se> References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <5994f353-5306-0fa8-2d2d-024ebdbb10df@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> In-Reply-To: <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZXLonXDe2gjnKYOoNc4t1l0+xWdxaupLV 4vmVBYwWa/6tY7I4OecHs8X66V9YLE49SHRg99g56y67x5IlP5k8vlz+zBbAHMVlk5Kak1mW WqRvl8CVcehBE2vBDv2K3b/+sjQwztHrYuTkkBAwkZh4/yJbFyMXh5DAEUaJrr/72CGcZYwS L9reMIFUsQloSBy7s5YRxBYRqJdYv+wOM0gRs8AmRokvPZOAHA4OYQEFiWv/pCBqFCXuXpnJ BmEbSaxv2cMOYrMIqEhs3NIFNodXwFdi77LvUJsXsktMfj8LbBmngK3Ekld3WEBsRgExie+n 1oDFmQXEJW49mc8EcbaAxJI955khbFGJl4//sULYShKTlp5jBbmHWUBTYv0ufYhWRYkp3Q/Z IfYKSpyc+YRlAqPoLCRTZyF0zELSMQtJxwJGllWMHKXFBTm56UYGmxiBcXRMgk13B+P96Z6H GAU4GJV4eCekM0cJsSaWFVfmHmKU4GBWEuG1zgQK8aYkVlalFuXHF5XmpBYfYpTmYFES551w /kKEkEB6YklqdmpqQWoRTJaJg1OqgVFRLfHEyZCXe9und6+vDDNbma23xyHJwOTIlfDIIxtY WlzdZ/lXyd5N6tB88HKxnb3RSYEEppc/Gks4el1jngvraRo8nfu8S+Gxic5y7yc/e1u5goJc uneurv1fOFfDSt/i344jrosby7e1xtxPMexT89pd2OTpPPmuyd+nBduCvt8JulcyV4mlOCPR UIu5qDgRAMj5JB2fAgAA Archived-At: Subject: Re: [Pals] [mpls] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 21:34:25 -0000 U3Rld2FydCwNCg0KCUxEUCB1c2VzIHRoZSBzYW1lIHNlY3VyaXR5IG1lYXN1cmVzIHRoYXQgd2Vy ZSBhdmFpbGFibGUgaW4gQkdQIGltcGxlbWVudGF0aW9ucyBhdCB0aGUgdGltZSBvZiBMRFAgc3Bl Y2lmaWNhdGlvbiwgZm9yIHJlYXNvbnMgdGhhdCB3ZXJlIHByZXR0eSBvYnZpb3VzIHRvIGFueW9u ZSB3aG8gaW1wbGVtZW50ZWQgTERQIGJhc2VkIG9uIEJHUC4NCg0KCUkgY2FuIHRoaW5rIG9mIG5v IHJlYXNvbiB3aHkgYW55IG1vcmUgY29tcGxpY2F0ZWQgYXBwcm9hY2ggbWlnaHQgYmUgcmVxdWly ZWQgdGhhbiB5b3UgaGF2ZSBzdWdnZXN0ZWQsIGJhc2VkIG9uIHRoZSBldm9sdXRpb24gb2YgQkdQ Lg0KDQotLQ0KRXJpYw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbXBscyBb bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0ZXdhcnQgQnJ5YW50 DQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDA4LCAyMDE3IDEyOjI4IFBNDQpUbzogc2VjLWFk c0BpZXRmLm9yZzsgPHJ0Zy1hZHNAaWV0Zi5vcmc+IDxydGctYWRzQGlldGYub3JnPg0KQ2M6IG1w bHNAaWV0Zi5vcmc7IHBhbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBtcGxzLWNoYWlyc0BpZXRm Lm9yZzsgcGFsc0BpZXRmLm9yZw0KU3ViamVjdDogW21wbHNdIExEUCBTZWN1cml0eQ0KDQpUbyB0 aGUgU0VDIGFuZCBSVEcgQURzLA0KDQpJIGFtIHNlbmRpbmcgdGhlIGZvbGxvd2luZyBtZXNzYWdl IG9uIGJlaGFsZiBvZiB0aGUgTVBMUyBhbmQgdGhlIFBBTFMgV0cgQ2hhaXJzLg0KDQpUaGVyZSBp cyBhIGNvbmNlcm4gc2hhcmVkIGFtb25nIHRoZSBzZWN1cml0eSBjb21tdW5pdHkgYW5kIHRoZSB3 b3JraW5nIGdyb3VwcyB0aGF0IGRldmVsb3AgdGhlIExEUCBwcm90b2NvbCB0aGF0IExEUCBpcyBu byBsb25nZXIgYWRlcXVhdGVseSBzZWN1cmVkLiBMRFAgY3VycmVudGx5IHJlbGllcyBvbiBNRDUg Zm9yIGNyeXB0b2dyYXBoaWMgc2VjdXJpdHkgb2YgaXRzIG1lc3NhZ2VzLCBidXQgTUQ1IGlzIGEg aGFzaCBmdW5jdGlvbiB0aGF0IGlzIG5vIGxvbmdlciBjb25zaWRlcmVkIHRvIG1lZXQgY3VycmVu dCBzZWN1cml0eSByZXF1aXJlbWVudHMuDQoNCkluIFJGQzUwMzYgKHB1Ymxpc2hlZCAyMDA3KSBT ZWN0aW9uIDUuMSAoU3Bvb2ZpbmcpICwgTGlzdCBlbGVtZW50IDIuIA0KU2Vzc2lvbiBjb21tdW5p Y2F0aW9uIGNhcnJpZWQgYnkgVENQIHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50cyBpcyBtYWRlOg0K DQoiTERQIHNwZWNpZmllcyB1c2Ugb2YgdGhlIFRDUCBNRDUgU2lnbmF0dXJlIE9wdGlvbiB0byBw cm92aWRlIGZvciB0aGUgYXV0aGVudGljaXR5IGFuZCBpbnRlZ3JpdHkgb2Ygc2Vzc2lvbiBtZXNz YWdlcy4NCg0KIltSRkMyMzg1XSBhc3NlcnRzIHRoYXQgTUQ1IGF1dGhlbnRpY2F0aW9uIGlzIG5v dyBjb25zaWRlcmVkIGJ5IHNvbWUgdG8gYmUgdG9vIHdlYWsgZm9yIHRoaXMgYXBwbGljYXRpb24u wqAgSXQgYWxzbyBwb2ludHMgb3V0IHRoYXQgYSBzaW1pbGFyIFRDUCBvcHRpb24gd2l0aCBhIHN0 cm9uZ2VyIGhhc2hpbmcgYWxnb3JpdGhtIChpdCBjaXRlcyBTSEEtMSBhcyBhbiBleGFtcGxlKSBj b3VsZCBiZSBkZXBsb3llZC7CoCBUbyBvdXIga25vd2xlZGdlLCBubyBzdWNoIFRDUCBvcHRpb24g aGFzIGJlZW4gZGVmaW5lZCBhbmQgZGVwbG95ZWQuwqAgSG93ZXZlciwgd2Ugbm90ZSB0aGF0IExE UCBjYW4gdXNlIHdoYXRldmVyIFRDUCBtZXNzYWdlIGRpZ2VzdCB0ZWNobmlxdWVzIGFyZSBhdmFp bGFibGUsIGFuZCB3aGVuIG9uZSBzdHJvbmdlciB0aGFuIE1ENSBpcyBzcGVjaWZpZWQgYW5kIGlt cGxlbWVudGVkLCB1cGdyYWRpbmcgTERQIHRvIHVzZSBpdCB3b3VsZCBiZSByZWxhdGl2ZWx5IHN0 cmFpZ2h0Zm9yd2FyZC4iDQoNCldlIG5vdGUgdGhhdCBCR1AgaGFzIGFscmVhZHkgYmVlbiB0aHJv dWdoIHRoaXMgcHJvY2VzcywgYW5kIHJlcGxhY2VkIE1ENSB3aXRoIFRDUC1BTyBpbiBSRkMgNzQ1 NC4gSSB3b3VsZCBiZSBsb2dpY2FsIHRvIGZvbGxvdyB0aGUgc2FtZSBhcHByb2FjaCB0byBzZWN1 cmUgTERQLiBIb3dldmVyLCBhcyBmYXIgYXMgd2UgYXJlIGFibGUgdG8gYXNjZXJ0YWluLCB0aGVy ZSBpcyBjdXJyZW50bHkgbm8gcmVjb21tZW5kZWQsIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQsIGNy eXB0b2dyYXBoaWMgZnVuY3Rpb24gc3BlY2lmaWVkLiBXZSBhcmUgY29uY2VybmVkIHRoYXQgd2l0 aG91dCBzdWNoIGEgbWFuZGF0b3J5IGZ1bmN0aW9uLCBpbXBsZW1lbnRhdGlvbnMgd2lsbCBzaW1w bHkgZmFsbCBiYWNrIHRvIE1ENSBhbmQgd2Ugd2lsbCBiZSBubyBmdXJ0aGVyIGZvcndhcmQNCg0K V2UgdGhpbmsgdGhhdCB0aGUgYmVzdCB3YXkgZm9yd2FyZCBpcyB0byBwdWJsaXNoIGEgZHJhZnQg c2ltaWxhciB0byBSRkMNCjc0NTQgdGhhdCBjb250YWlucyB0aGUgZm9sbG93aW5nIHJlcXVpcmVt ZW50Og0KDQoiSW1wbGVtZW50YXRpb25zIGNvbmZvcm1pbmcgdG8gdGhpcyBSRkMgTVVTVCBpbXBs ZW1lbnQgVENQLUFPIHRvIHNlY3VyZSB0aGUgVENQIHNlc3Npb25zIGNhcnJ5aW5nIExEUCBpbiBh ZGRpdGlvbiB0byB0aGUgY3VycmVudGx5IHJlcXVpcmVkIFRDUA0KTUQ1IFNpZ25hdHVyZSBPcHRp b24uIEZ1cnRoZXJtb3JlLCB0aGUgVEJEIGNyeXB0b2dyYXBoaWMgbWVjaGFuaXNtIG11c3QgYmUg aW1wbGVtZW50ZWQgYW5kIHByb3ZpZGVkIHRvIFRDUC1BTyB0byBzZWN1cmUgTERQIG1lc3NhZ2Vz LiBUaGUgVEJEIG1lY2hhbmlzbSBpcyB0aGUgcHJlZmVycmVkIG9wdGlvbiwgYW5kIE1ENSBpcyBv bmx5IHRvIGJlIHVzZWQgd2hlbiBUQkQgaXMgdW5hdmFpbGFibGUuIg0KDQpXZSBhcmUgbm90IGFu IGV4cGVydHMgb24gdGhpcyBwYXJ0IG9mIHRoZSBzdGFjaywgYnV0IGl0IHNlZW1zIHRoYXQgVENQ IHNlY3VyaXR5IG5lZ290aWF0aW9uIGlzIHN0aWxsIHdvcmsgaW4gcHJvZ3Jlc3MuIElmIHdlIGFy ZSB3cm9uZywgdGhlbiB3ZSBuZWVkIHRvIGluY2x1ZGUgYSByZXF1aXJlbWVudCB0aGF0IHN1Y2gg bmVnb3RpYXRpb24gaXMgYWxzbyByZXF1aXJlZC4gSW4gdGhlIGFic2VuY2Ugb2YgYSBuZWdvdGlh dGlvbiBwcm90b2NvbCwgaG93ZXZlciwgd2UgbmVlZCB0byBsZWF2ZSB0aGlzIGFzIGEgY29uZmln dXJhdGlvbiBwcm9jZXNzIHVudGlsIHN1Y2ggdGltZSBhcyB0aGUgbmVnb3RpYXRpb24gcHJvdG9j b2wgd29yayBpcyBjb21wbGV0ZS4gT24gY29tcGxldGlvbiBvZiBhIHN1aXRhYmxlIG5lZ290aWF0 aW9uIHByb3RvY29sIHdlIG5lZWQgdG8gaXNzdWUgYSBmdXJ0aGVyIHVwZGF0ZSByZXF1aXJpbmcg aXRzIHVzZS4NCg0KQWRkaXRpb25hbGx5IHdlIHNob3VsZCBub3RlIHRoYXQgbm8gY3J5cHRvZ3Jh cGhpYyBtZWNoYW5pc20gaGFzIGFuIGluZGVmaW5pdGUgbGlmZXRpbWUsIGFuZCB0aGF0IGltcGxl bWVudGF0aW9uIHNob3VsZCBub3RlIHRoZSBJRVRGIGFudGljaXBhdGVzIHVwZGF0aW5nIHRoZSBk ZWZhdWx0IGNyeXB0b2dyYXBoaWMgbWVjaGFuaXNtIG92ZXIgdGltZS4NCg0KVGhlIFRCRCBkZWZh dWx0IHNlY3VyaXR5IGZ1bmN0aW9uIHdpbGwgbmVlZCB0byBiZSBjaG9zZW4gc3VjaCB0aGF0IGl0 IGNhbiByZWFzb25hYmx5IGJlIGltcGxlbWVudGVkIG9uIGEgdHlwaWNhbCByb3V0ZXIgcm91dGUg cHJvY2Vzc29yLCBhbmQgd2hpY2ggd2lsbCBwcm92aWRlIGFkZXF1YXRlIHNlY3VyaXR5IHdpdGhv dXQgc2lnbmlmaWNhbnRseSBkZWdyYWRpbmcgdGhlIGNvbnZlcmdlbmNlIHRpbWUgb2YgYW4gTFNS LiBXaXRob3V0IGEgZnVuY3Rpb24gdGhhdCBkb2VzIG5vdCBzaWduaWZpY2FudGx5IGltcGFjdCBy b3V0ZXIgY29udmVyZ2VuY2Ugd2Ugc2ltcGx5IGNsb3NlIG9uZSB2dWxuZXJhYmlsaXR5IGFuZCBv cGVuIGFub3RoZXIuDQoNCkFzIGV4cGVydHMgb24gdGhlIExEUCBwcm90b2NvbCwgYnV0IG5vdCBv biBzZWN1cml0eSBtZWNoYW5pc21zLCB3ZcKgIG5lZWQgdG8gYXNrIHRoZSBzZWN1cml0eSBhcmVh IGZvciBhIHJldmlldyBvZiBvdXIgcHJvcG9zZWQgYXBwcm9hY2gsIGFuZCBoZWxwIGNvcnJlY3Rp bmcgYW55IG1pc3VuZGVyc3RhbmRpbmcgb2YgdGhlIHNlY3VyaXR5IGlzc3VlcyBvciBvdXIgbWlz dW5kZXJzdGFuZGluZyBvZiB0aGUgZXhpc3Rpbmcgc2VjdXJpdHkgbWVjaGFuaXNtcy4gV2UgYWxz byBuZWVkIHRoZSByZWNvbW1lbmRhdGlvbnMgb2YgYSBzdWl0YWJsZSBzZWN1cml0eSBmdW5jdGlv biAoVEJEIGluIHRoZSBhYm92ZSB0ZXh0KS4NCg0KQmVzdCByZWdhcmRzDQoNClRoZSBNUExTIFdH IENoYWlycw0KVGhlIFBBTFMgV0cgQ2hhaXJzDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== From nobody Wed Nov 8 14:01:11 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8DB129B52; Wed, 8 Nov 2017 14:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuczQEMb8Um5; Wed, 8 Nov 2017 14:01:07 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 8401D1271FD; Wed, 8 Nov 2017 14:01:04 -0800 (PST) X-AuditID: c618062d-8efff70000004288-2a-5a037e9f33ba Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 75.07.17032.F9E730A5; Wed, 8 Nov 2017 23:01:04 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0352.000; Wed, 8 Nov 2017 17:01:03 -0500 From: Eric Gray To: Eric Rescorla , Stewart Bryant CC: "mpls@ietf.org" , "pals-chairs@tools.ietf.org" , "" , "mpls-chairs@ietf.org" , "pals@ietf.org" , "" Thread-Topic: [mpls] LDP Security Thread-Index: AQHTWLbpcFjTDKhuoEWsKIVkOj1Ru6MLGRoA///qPtA= Date: Wed, 8 Nov 2017 22:01:02 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF64B870140@eusaamb107.ericsson.se> References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <5994f353-5306-0fa8-2d2d-024ebdbb10df@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF64B870140eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPIsWRmVeSWpSXmKPExsUyuXRPoO6COuYog++fGS1WvD7HbrHu8ik2 i1tLV7JaPL+ygNFizb91TBYn5/xgtlg//QuLxakHiQ4cHjtn3WX3WLLkJ5PH5MdtzB5fLn9m C2CJ4rJJSc3JLEst0rdL4Mr4eOYuU8GmFYwVH741sTYwflnM2MXIySEhYCJxZOYEIJuLQ0jg CKPEnkfvoJxljBL7Gg6yglSxCWhIHLuzFqxDRMBb4tOdBlaQImaBNiaJyzvmACU4OIQFFCSu /ZOCqFGUuHtlJhtIWETASuJ3kzBImEVARWLi/lNMIDavgK/EupkXwcYLCbxglzj5PRTE5hQI lJh5aBJYnFFATOL7qTVg9cwC4hK3nsxngjhaQGLJnvPMELaoxMvH/1ghbCWJSUvPsULU50t8 a17GDLFLUOLkzCcsExhFZiEZNQtJ2SwkZbOArmYW0JRYv0sfokRRYkr3Q3YIW0Oidc5cdmTx BYzsqxg5SosLcnLTjQw2MQKj8ZgEm+4OxvvTPQ8xCnAwKvHwTkhnjhJiTSwrrsw9xCjBwawk wmudCRTiTUmsrEotyo8vKs1JLT7EKM3BoiTOO+H8hQghgfTEktTs1NSC1CKYLBMHp1QD4zIR wYkhJ9YcXf998dRV+2UOcNXcvPYxn892ekXpMvs7U5MqRV9r2S7nfLrh6yy7Hudr8SePb6hi fb3Pm7dNSHJ6wJQ5fxRmMF2f1NCXGtdsc2CL2ctJrYJXTFbGF805q596O1z55PfAzxWTzx01 nqS+r8I+ZYbjNdX0jx+e8dv8K9tw+yrTNn8lluKMREMt5qLiRABV0LNtwgIAAA== Archived-At: Subject: Re: [Pals] [mpls] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 22:01:10 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF64B870140eusaamb107erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXJpYywNCg0KICAgICAgICAgICAgICAgIFRoaXMgYmVjb21lcyBhbm90aGVyIGFyZ3VtZW50IHRv IGZvbGxvdyBCR1AgaW4gcmVzb2x2aW5nIHRoZSBpc3N1ZXMuICBUaGUgcHVzaCBmcm9tIGN1c3Rv bWVycyB0byBmaXggdGhlIHByb2JsZW0gaXMgZXNzZW50aWFsbHkgdGhlIHNhbWUgYW5kIHJlc29s dmluZyB0aGUgcHJvYmxlbSBmb3IgQkdQIHdpbGwgYWxtb3N0IGNlcnRhaW5seSByZXNvbHZlIGl0 IGZvciBMRFAgYXMgd2VsbC4NCg0KLS0NCkVyaWMNCg0KRnJvbTogbXBscyBbbWFpbHRvOm1wbHMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyaWMgUmVzY29ybGENClNlbnQ6IFdlZG5l c2RheSwgTm92ZW1iZXIgMDgsIDIwMTcgMTowMCBQTQ0KVG86IFN0ZXdhcnQgQnJ5YW50IDxzdGV3 YXJ0LmJyeWFudEBnbWFpbC5jb20+DQpDYzogbXBsc0BpZXRmLm9yZzsgcGFscy1jaGFpcnNAdG9v bHMuaWV0Zi5vcmc7IDxydGctYWRzQGlldGYub3JnPiA8cnRnLWFkc0BpZXRmLm9yZz47IG1wbHMt Y2hhaXJzQGlldGYub3JnOyBwYWxzQGlldGYub3JnOyA8c2VjLWFkc0BpZXRmLm9yZz4gPHNlYy1h ZHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21wbHNdIExEUCBTZWN1cml0eQ0KDQpIaSBTdGV3 YXJ0DQoNClRoYW5rcyBmb3IgeW91ciBub3RlLg0KDQpNeSBvdmVyYWxsIHNlbnNlIG9mIHRoZSBz dGF0ZSBvZiBwbGF5IGlzLCBJIHRoaW5rIG11Y2ggbGlrZSB5b3Vycy4NCg0KVENQLU1ENSBpcyBp bmFkZXF1YXRlIGluIHR3byBtYWpvciByZXNwZWN0czoNCi0gSXQgdXNlcyB3ZWFrIGFsZ29yaXRo bXMNCi0gSXQgaGFzIGEgYmFkIG5lZ290aWF0aW9uL3NldHVvcCBzdG9yeSAobWFudWFsIGtleSBt YW5hZ2VtZW50KQ0KDQpUQ1AtQU8gaXMgaW50ZW5kZWQgdG8gYmUgYSBkcm9wLWluIHJlcGxhY2Vt ZW50IGZvciBUQ1AtTUQ1IGFuZCBzbyByZW1lZGllcyB0aGUgYWxnb3JpdGhtDQppc3N1ZSBidXQg bm90IHRoZSBrZXkgbWFuYWdlbWVudCBpc3N1ZSBbMF0uIFdlIGhhdmVuJ3QgbWFkZSBtdWNoIHBy b2dyZXNzIG9uIHRoZSBrZXkNCm1hbmFnZW1lbnQgc3RvcnksIGFuZCB0aGF0IHNlZW1zIHRvIGJl IGEgbWFqb3IgaW1wZWRpbWVudCB0byBkZXBsb3lpbmcgZWl0aGVyIG9mIHRoZXNlDQp0ZWNobm9s b2dpZXMgKHdoaWNoIEkgYW0gZ2l2ZW4gdG8gdW5kZXJzdGFuZCBkb24ndCBzZWUgYSBsb3Qgb2Yg dXNlKS4gV2Ugc2hvdWxkIHByb2JhYmx5DQp0YWxrIGluIFNpbmdhcG9yZSBhYm91dCB0aGF0LCBi dXQgdGhhdCdzIG5vdCBnb2luZyB0byBnZXQgYmV0dGVyIGFueSB0aW1lIHNvb24uDQoNCkluIHRo ZSBpbnRlcmltLCBJIHRoaW5rIHRoZSB0ZXh0IHlvdSBoYXZlIGlzIE9LLCBhbmQgIlRCRCIgc2hv dWxkIHJlYWQgIlNIQS0yNTYiLCB3aXRoDQp0aGUgZmFsbGJhY2sgYmVpbmcgU0hBLTI1NiAtPiBT SEEtMSAtPiBNRDUuDQoNCi1Fa3INCg0KDQpbMF0gVGVjaG5pY2FsbHkgSXQgaGFzIGJldHRlciBz dXBwb3J0IGZvciByb2xsb3ZlciwgYnV0IHRoaXMgaXMgbm90IGEgaHVnZSBpbXByb3ZlbWVudC4N ClsxXSB0Y3BjcnlwdCBpcyBraW5kIG9mIG9ydGhvZ29uYWwgaGVyZSBhcyBpdCdzIHVuYXV0aGVu dGljYXRlZCBidXQgb3Bwb3J0dW5pc3RpYy4gIFRoYXQgc2FpZCwNCml0IHdvdWxkIHByb3ZpZGUg ZGVmZW5zZSBhZ2FpbnN0IGF0dGFja2VycyB3aG8gZ2FpbiBhY2Nlc3MgdG8gdGhlIGxpbmsgYWZ0 ZXIgY29ubmVjdGlvbg0Kc2V0dXAgYW5kIGRvZXNuJ3QgcmVxdWlyZSBjb25maWd1cmF0aW9uLg0K DQpPbiBXZWQsIE5vdiA4LCAyMDE3IGF0IDk6MjcgQU0sIFN0ZXdhcnQgQnJ5YW50IDxzdGV3YXJ0 LmJyeWFudEBnbWFpbC5jb208bWFpbHRvOnN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbT4+IHdyb3Rl Og0KVG8gdGhlIFNFQyBhbmQgUlRHIEFEcywNCg0KSSBhbSBzZW5kaW5nIHRoZSBmb2xsb3dpbmcg bWVzc2FnZSBvbiBiZWhhbGYgb2YgdGhlIE1QTFMgYW5kIHRoZQ0KUEFMUyBXRyBDaGFpcnMuDQoN ClRoZXJlIGlzIGEgY29uY2VybiBzaGFyZWQgYW1vbmcgdGhlIHNlY3VyaXR5IGNvbW11bml0eSBh bmQgdGhlIHdvcmtpbmcgZ3JvdXBzIHRoYXQgZGV2ZWxvcCB0aGUgTERQIHByb3RvY29sIHRoYXQg TERQIGlzIG5vIGxvbmdlciBhZGVxdWF0ZWx5IHNlY3VyZWQuIExEUCBjdXJyZW50bHkgcmVsaWVz IG9uIE1ENSBmb3IgY3J5cHRvZ3JhcGhpYyBzZWN1cml0eSBvZiBpdHMgbWVzc2FnZXMsIGJ1dCBN RDUgaXMgYSBoYXNoIGZ1bmN0aW9uIHRoYXQgaXMgbm8gbG9uZ2VyIGNvbnNpZGVyZWQgdG8gbWVl dCBjdXJyZW50IHNlY3VyaXR5IHJlcXVpcmVtZW50cy4NCg0KSW4gUkZDNTAzNiAocHVibGlzaGVk IDIwMDcpIFNlY3Rpb24gNS4xIChTcG9vZmluZykgLCBMaXN0IGVsZW1lbnQgMi4gU2Vzc2lvbiBj b21tdW5pY2F0aW9uIGNhcnJpZWQgYnkgVENQIHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50cyBpcyBt YWRlOg0KDQoiTERQIHNwZWNpZmllcyB1c2Ugb2YgdGhlIFRDUCBNRDUgU2lnbmF0dXJlIE9wdGlv biB0byBwcm92aWRlIGZvciB0aGUgYXV0aGVudGljaXR5IGFuZCBpbnRlZ3JpdHkgb2Ygc2Vzc2lv biBtZXNzYWdlcy4NCg0KIltSRkMyMzg1XSBhc3NlcnRzIHRoYXQgTUQ1IGF1dGhlbnRpY2F0aW9u IGlzIG5vdyBjb25zaWRlcmVkIGJ5IHNvbWUgdG8gYmUgdG9vIHdlYWsgZm9yIHRoaXMgYXBwbGlj YXRpb24uICBJdCBhbHNvIHBvaW50cyBvdXQgdGhhdCBhIHNpbWlsYXIgVENQIG9wdGlvbiB3aXRo IGEgc3Ryb25nZXIgaGFzaGluZyBhbGdvcml0aG0gKGl0IGNpdGVzIFNIQS0xIGFzIGFuIGV4YW1w bGUpIGNvdWxkIGJlIGRlcGxveWVkLiAgVG8gb3VyIGtub3dsZWRnZSwgbm8gc3VjaCBUQ1Agb3B0 aW9uIGhhcyBiZWVuIGRlZmluZWQgYW5kIGRlcGxveWVkLiAgSG93ZXZlciwgd2Ugbm90ZSB0aGF0 IExEUCBjYW4gdXNlIHdoYXRldmVyIFRDUCBtZXNzYWdlIGRpZ2VzdCB0ZWNobmlxdWVzIGFyZSBh dmFpbGFibGUsIGFuZCB3aGVuIG9uZSBzdHJvbmdlciB0aGFuIE1ENSBpcyBzcGVjaWZpZWQgYW5k IGltcGxlbWVudGVkLCB1cGdyYWRpbmcgTERQIHRvIHVzZSBpdCB3b3VsZCBiZSByZWxhdGl2ZWx5 IHN0cmFpZ2h0Zm9yd2FyZC4iDQoNCldlIG5vdGUgdGhhdCBCR1AgaGFzIGFscmVhZHkgYmVlbiB0 aHJvdWdoIHRoaXMgcHJvY2VzcywgYW5kIHJlcGxhY2VkIE1ENSB3aXRoIFRDUC1BTyBpbiBSRkMg NzQ1NC4gSSB3b3VsZCBiZSBsb2dpY2FsIHRvIGZvbGxvdyB0aGUgc2FtZSBhcHByb2FjaCB0byBz ZWN1cmUgTERQLiBIb3dldmVyLCBhcyBmYXIgYXMgd2UgYXJlIGFibGUgdG8gYXNjZXJ0YWluLCB0 aGVyZSBpcyBjdXJyZW50bHkgbm8gcmVjb21tZW5kZWQsIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQs IGNyeXB0b2dyYXBoaWMgZnVuY3Rpb24gc3BlY2lmaWVkLiBXZSBhcmUgY29uY2VybmVkIHRoYXQg d2l0aG91dCBzdWNoIGEgbWFuZGF0b3J5IGZ1bmN0aW9uLCBpbXBsZW1lbnRhdGlvbnMgd2lsbCBz aW1wbHkgZmFsbCBiYWNrIHRvIE1ENSBhbmQgd2Ugd2lsbCBiZSBubyBmdXJ0aGVyIGZvcndhcmQN Cg0KV2UgdGhpbmsgdGhhdCB0aGUgYmVzdCB3YXkgZm9yd2FyZCBpcyB0byBwdWJsaXNoIGEgZHJh ZnQgc2ltaWxhciB0byBSRkMgNzQ1NCB0aGF0IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgcmVxdWly ZW1lbnQ6DQoNCiJJbXBsZW1lbnRhdGlvbnMgY29uZm9ybWluZyB0byB0aGlzIFJGQyBNVVNUIGlt cGxlbWVudCBUQ1AtQU8gdG8gc2VjdXJlIHRoZSBUQ1Agc2Vzc2lvbnMgY2FycnlpbmcgTERQIGlu IGFkZGl0aW9uIHRvIHRoZSBjdXJyZW50bHkgcmVxdWlyZWQgVENQIE1ENSBTaWduYXR1cmUgT3B0 aW9uLiBGdXJ0aGVybW9yZSwgdGhlIFRCRCBjcnlwdG9ncmFwaGljIG1lY2hhbmlzbSBtdXN0IGJl IGltcGxlbWVudGVkIGFuZCBwcm92aWRlZCB0byBUQ1AtQU8gdG8gc2VjdXJlIExEUCBtZXNzYWdl cy4gVGhlIFRCRCBtZWNoYW5pc20gaXMgdGhlIHByZWZlcnJlZCBvcHRpb24sIGFuZCBNRDUgaXMg b25seSB0byBiZSB1c2VkIHdoZW4gVEJEIGlzIHVuYXZhaWxhYmxlLiINCg0KV2UgYXJlIG5vdCBh biBleHBlcnRzIG9uIHRoaXMgcGFydCBvZiB0aGUgc3RhY2ssIGJ1dCBpdCBzZWVtcyB0aGF0IFRD UCBzZWN1cml0eSBuZWdvdGlhdGlvbiBpcyBzdGlsbCB3b3JrIGluIHByb2dyZXNzLiBJZiB3ZSBh cmUgd3JvbmcsIHRoZW4gd2UgbmVlZCB0byBpbmNsdWRlIGEgcmVxdWlyZW1lbnQgdGhhdCBzdWNo IG5lZ290aWF0aW9uIGlzIGFsc28gcmVxdWlyZWQuIEluIHRoZSBhYnNlbmNlIG9mIGEgbmVnb3Rp YXRpb24gcHJvdG9jb2wsIGhvd2V2ZXIsIHdlIG5lZWQgdG8gbGVhdmUgdGhpcyBhcyBhIGNvbmZp Z3VyYXRpb24gcHJvY2VzcyB1bnRpbCBzdWNoIHRpbWUgYXMgdGhlIG5lZ290aWF0aW9uIHByb3Rv Y29sIHdvcmsgaXMgY29tcGxldGUuIE9uIGNvbXBsZXRpb24gb2YgYSBzdWl0YWJsZSBuZWdvdGlh dGlvbiBwcm90b2NvbCB3ZSBuZWVkIHRvIGlzc3VlIGEgZnVydGhlciB1cGRhdGUgcmVxdWlyaW5n IGl0cyB1c2UuDQoNCkFkZGl0aW9uYWxseSB3ZSBzaG91bGQgbm90ZSB0aGF0IG5vIGNyeXB0b2dy YXBoaWMgbWVjaGFuaXNtIGhhcyBhbiBpbmRlZmluaXRlIGxpZmV0aW1lLCBhbmQgdGhhdCBpbXBs ZW1lbnRhdGlvbiBzaG91bGQgbm90ZSB0aGUgSUVURiBhbnRpY2lwYXRlcyB1cGRhdGluZyB0aGUg ZGVmYXVsdCBjcnlwdG9ncmFwaGljIG1lY2hhbmlzbSBvdmVyIHRpbWUuDQoNClRoZSBUQkQgZGVm YXVsdCBzZWN1cml0eSBmdW5jdGlvbiB3aWxsIG5lZWQgdG8gYmUgY2hvc2VuIHN1Y2ggdGhhdCBp dCBjYW4gcmVhc29uYWJseSBiZSBpbXBsZW1lbnRlZCBvbiBhIHR5cGljYWwgcm91dGVyIHJvdXRl IHByb2Nlc3NvciwgYW5kIHdoaWNoIHdpbGwgcHJvdmlkZSBhZGVxdWF0ZSBzZWN1cml0eSB3aXRo b3V0IHNpZ25pZmljYW50bHkgZGVncmFkaW5nIHRoZSBjb252ZXJnZW5jZSB0aW1lIG9mIGFuIExT Ui4gV2l0aG91dCBhIGZ1bmN0aW9uIHRoYXQgZG9lcyBub3Qgc2lnbmlmaWNhbnRseSBpbXBhY3Qg cm91dGVyIGNvbnZlcmdlbmNlIHdlIHNpbXBseSBjbG9zZSBvbmUgdnVsbmVyYWJpbGl0eSBhbmQg b3BlbiBhbm90aGVyLg0KDQpBcyBleHBlcnRzIG9uIHRoZSBMRFAgcHJvdG9jb2wsIGJ1dCBub3Qg b24gc2VjdXJpdHkgbWVjaGFuaXNtcywgd2UgIG5lZWQgdG8gYXNrIHRoZSBzZWN1cml0eSBhcmVh IGZvciBhIHJldmlldyBvZiBvdXIgcHJvcG9zZWQgYXBwcm9hY2gsIGFuZCBoZWxwIGNvcnJlY3Rp bmcgYW55IG1pc3VuZGVyc3RhbmRpbmcgb2YgdGhlIHNlY3VyaXR5IGlzc3VlcyBvciBvdXIgbWlz dW5kZXJzdGFuZGluZyBvZiB0aGUgZXhpc3Rpbmcgc2VjdXJpdHkgbWVjaGFuaXNtcy4gV2UgYWxz byBuZWVkIHRoZSByZWNvbW1lbmRhdGlvbnMgb2YgYSBzdWl0YWJsZSBzZWN1cml0eSBmdW5jdGlv biAoVEJEIGluIHRoZSBhYm92ZSB0ZXh0KS4NCg0KQmVzdCByZWdhcmRzDQoNClRoZSBNUExTIFdH IENoYWlycw0KVGhlIFBBTFMgV0cgQ2hhaXJzDQoNCg0K --_000_48E1A67CB9CA044EADFEAB87D814BFF64B870140eusaamb107erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FcmljLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBiZWNvbWVzIGFub3RoZXIg YXJndW1lbnQgdG8gZm9sbG93IEJHUCBpbiByZXNvbHZpbmcgdGhlIGlzc3Vlcy4gJm5ic3A7VGhl IHB1c2ggZnJvbSBjdXN0b21lcnMgdG8gZml4IHRoZSBwcm9ibGVtIGlzIGVzc2VudGlhbGx5IHRo ZSBzYW1lIGFuZCByZXNvbHZpbmcgdGhlIHByb2JsZW0gZm9yIEJHUCB3aWxsIGFsbW9zdCBjZXJ0 YWlubHkgcmVzb2x2ZSBpdCBmb3IgTERQIGFzIHdlbGwuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FcmljPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYu b3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5FcmljIFJlc2NvcmxhPGJyPg0KPGI+U2VudDo8L2I+ IFdlZG5lc2RheSwgTm92ZW1iZXIgMDgsIDIwMTcgMTowMCBQTTxicj4NCjxiPlRvOjwvYj4gU3Rl d2FydCBCcnlhbnQgJmx0O3N0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8 L2I+IG1wbHNAaWV0Zi5vcmc7IHBhbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyAmbHQ7cnRnLWFk c0BpZXRmLm9yZyZndDsgJmx0O3J0Zy1hZHNAaWV0Zi5vcmcmZ3Q7OyBtcGxzLWNoYWlyc0BpZXRm Lm9yZzsgcGFsc0BpZXRmLm9yZzsgJmx0O3NlYy1hZHNAaWV0Zi5vcmcmZ3Q7ICZsdDtzZWMtYWRz QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21wbHNdIExEUCBTZWN1cml0 eTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgU3Rld2FydDxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciB5b3VyIG5vdGUuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IG92 ZXJhbGwgc2Vuc2Ugb2YgdGhlIHN0YXRlIG9mIHBsYXkgaXMsIEkgdGhpbmsgbXVjaCBsaWtlIHlv dXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UQ1AtTUQ1IGlzIGluYWRlcXVhdGUgaW4gdHdvIG1ham9yIHJlc3BlY3RzOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBJdCB1c2VzIHdlYWsg YWxnb3JpdGhtczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+LSBJdCBoYXMgYSBiYWQgbmVnb3RpYXRpb24vc2V0dW9wIHN0b3J5IChtYW51YWwga2V5 IG1hbmFnZW1lbnQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRDUC1BTyBpcyBpbnRlbmRlZCB0byBiZSBhIGRyb3AtaW4gcmVwbGFjZW1lbnQg Zm9yIFRDUC1NRDUgYW5kIHNvIHJlbWVkaWVzIHRoZSBhbGdvcml0aG08bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmlzc3VlIGJ1dCBub3QgdGhlIGtl eSBtYW5hZ2VtZW50IGlzc3VlIFswXS4gV2UgaGF2ZW4ndCBtYWRlIG11Y2ggcHJvZ3Jlc3Mgb24g dGhlIGtleTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+bWFuYWdlbWVudCBzdG9yeSwgYW5kIHRoYXQgc2VlbXMgdG8gYmUgYSBtYWpvciBpbXBlZGlt ZW50IHRvIGRlcGxveWluZyBlaXRoZXIgb2YgdGhlc2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRlY2hub2xvZ2llcyAod2hpY2ggSSBhbSBnaXZl biB0byB1bmRlcnN0YW5kIGRvbid0IHNlZSBhIGxvdCBvZiB1c2UpLiBXZSBzaG91bGQgcHJvYmFi bHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRh bGsgaW4gU2luZ2Fwb3JlIGFib3V0IHRoYXQsIGJ1dCB0aGF0J3Mgbm90IGdvaW5nIHRvIGdldCBi ZXR0ZXIgYW55IHRpbWUgc29vbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhlIGludGVyaW0sIEkgdGhpbmsgdGhlIHRleHQgeW91IGhh dmUgaXMgT0ssIGFuZCAmcXVvdDtUQkQmcXVvdDsgc2hvdWxkIHJlYWQgJnF1b3Q7U0hBLTI1NiZx dW90Oywgd2l0aDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+dGhlIGZhbGxiYWNrIGJlaW5nIFNIQS0yNTYgLSZndDsgU0hBLTEgLSZndDsgTUQ1Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWty PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ WzBdIFRlY2huaWNhbGx5IEl0IGhhcyBiZXR0ZXIgc3VwcG9ydCBmb3Igcm9sbG92ZXIsIGJ1dCB0 aGlzIGlzIG5vdCBhIGh1Z2UgaW1wcm92ZW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bMV0gdGNwY3J5cHQgaXMga2luZCBvZiBvcnRob2dv bmFsIGhlcmUgYXMgaXQncyB1bmF1dGhlbnRpY2F0ZWQgYnV0IG9wcG9ydHVuaXN0aWMuJm5ic3A7 IFRoYXQgc2FpZCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPml0IHdvdWxkIHByb3ZpZGUgZGVmZW5zZSBhZ2FpbnN0IGF0dGFja2VycyB3aG8gZ2Fp biBhY2Nlc3MgdG8gdGhlIGxpbmsgYWZ0ZXIgY29ubmVjdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c2V0dXAgYW5kIGRvZXNuJ3QgcmVxdWly ZSBjb25maWd1cmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBXZWQsIE5vdiA4LCAyMDE3IGF0IDk6MjcgQU0sIFN0ZXdhcnQgQnJ5 YW50ICZsdDs8YSBocmVmPSJtYWlsdG86c3Rld2FydC5icnlhbnRAZ21haWwuY29tIiB0YXJnZXQ9 Il9ibGFuayI+c3Rld2FydC5icnlhbnRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij5UbyB0aGUgU0VDIGFuZCBSVEcgQURzLDxicj4NCjxicj4NCkkgYW0gc2Vu ZGluZyB0aGUgZm9sbG93aW5nIG1lc3NhZ2Ugb24gYmVoYWxmIG9mIHRoZSBNUExTIGFuZCB0aGU8 YnI+DQpQQUxTIFdHIENoYWlycy48YnI+DQo8YnI+DQpUaGVyZSBpcyBhIGNvbmNlcm4gc2hhcmVk IGFtb25nIHRoZSBzZWN1cml0eSBjb21tdW5pdHkgYW5kIHRoZSB3b3JraW5nIGdyb3VwcyB0aGF0 IGRldmVsb3AgdGhlIExEUCBwcm90b2NvbCB0aGF0IExEUCBpcyBubyBsb25nZXIgYWRlcXVhdGVs eSBzZWN1cmVkLiBMRFAgY3VycmVudGx5IHJlbGllcyBvbiBNRDUgZm9yIGNyeXB0b2dyYXBoaWMg c2VjdXJpdHkgb2YgaXRzIG1lc3NhZ2VzLCBidXQgTUQ1IGlzIGEgaGFzaCBmdW5jdGlvbiB0aGF0 IGlzDQogbm8gbG9uZ2VyIGNvbnNpZGVyZWQgdG8gbWVldCBjdXJyZW50IHNlY3VyaXR5IHJlcXVp cmVtZW50cy48YnI+DQo8YnI+DQpJbiBSRkM1MDM2IChwdWJsaXNoZWQgMjAwNykgU2VjdGlvbiA1 LjEgKFNwb29maW5nKSAsIExpc3QgZWxlbWVudCAyLiBTZXNzaW9uIGNvbW11bmljYXRpb24gY2Fy cmllZCBieSBUQ1AgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnRzIGlzIG1hZGU6PGJyPg0KPGJyPg0K JnF1b3Q7TERQIHNwZWNpZmllcyB1c2Ugb2YgdGhlIFRDUCBNRDUgU2lnbmF0dXJlIE9wdGlvbiB0 byBwcm92aWRlIGZvciB0aGUgYXV0aGVudGljaXR5IGFuZCBpbnRlZ3JpdHkgb2Ygc2Vzc2lvbiBt ZXNzYWdlcy48YnI+DQo8YnI+DQomcXVvdDtbUkZDMjM4NV0gYXNzZXJ0cyB0aGF0IE1ENSBhdXRo ZW50aWNhdGlvbiBpcyBub3cgY29uc2lkZXJlZCBieSBzb21lIHRvIGJlIHRvbyB3ZWFrIGZvciB0 aGlzIGFwcGxpY2F0aW9uLiZuYnNwOyBJdCBhbHNvIHBvaW50cyBvdXQgdGhhdCBhIHNpbWlsYXIg VENQIG9wdGlvbiB3aXRoIGEgc3Ryb25nZXIgaGFzaGluZyBhbGdvcml0aG0gKGl0IGNpdGVzIFNI QS0xIGFzIGFuIGV4YW1wbGUpIGNvdWxkIGJlIGRlcGxveWVkLiZuYnNwOyBUbyBvdXIga25vd2xl ZGdlLCBubw0KIHN1Y2ggVENQIG9wdGlvbiBoYXMgYmVlbiBkZWZpbmVkIGFuZCBkZXBsb3llZC4m bmJzcDsgSG93ZXZlciwgd2Ugbm90ZSB0aGF0IExEUCBjYW4gdXNlIHdoYXRldmVyIFRDUCBtZXNz YWdlIGRpZ2VzdCB0ZWNobmlxdWVzIGFyZSBhdmFpbGFibGUsIGFuZCB3aGVuIG9uZSBzdHJvbmdl ciB0aGFuIE1ENSBpcyBzcGVjaWZpZWQgYW5kIGltcGxlbWVudGVkLCB1cGdyYWRpbmcgTERQIHRv IHVzZSBpdCB3b3VsZCBiZSByZWxhdGl2ZWx5IHN0cmFpZ2h0Zm9yd2FyZC4mcXVvdDs8YnI+DQo8 YnI+DQpXZSBub3RlIHRoYXQgQkdQIGhhcyBhbHJlYWR5IGJlZW4gdGhyb3VnaCB0aGlzIHByb2Nl c3MsIGFuZCByZXBsYWNlZCBNRDUgd2l0aCBUQ1AtQU8gaW4gUkZDIDc0NTQuIEkgd291bGQgYmUg bG9naWNhbCB0byBmb2xsb3cgdGhlIHNhbWUgYXBwcm9hY2ggdG8gc2VjdXJlIExEUC4gSG93ZXZl ciwgYXMgZmFyIGFzIHdlIGFyZSBhYmxlIHRvIGFzY2VydGFpbiwgdGhlcmUgaXMgY3VycmVudGx5 IG5vIHJlY29tbWVuZGVkLCBtYW5kYXRvcnkgdG8gaW1wbGVtZW50LA0KIGNyeXB0b2dyYXBoaWMg ZnVuY3Rpb24gc3BlY2lmaWVkLiBXZSBhcmUgY29uY2VybmVkIHRoYXQgd2l0aG91dCBzdWNoIGEg bWFuZGF0b3J5IGZ1bmN0aW9uLCBpbXBsZW1lbnRhdGlvbnMgd2lsbCBzaW1wbHkgZmFsbCBiYWNr IHRvIE1ENSBhbmQgd2Ugd2lsbCBiZSBubyBmdXJ0aGVyIGZvcndhcmQ8YnI+DQo8YnI+DQpXZSB0 aGluayB0aGF0IHRoZSBiZXN0IHdheSBmb3J3YXJkIGlzIHRvIHB1Ymxpc2ggYSBkcmFmdCBzaW1p bGFyIHRvIFJGQyA3NDU0IHRoYXQgY29udGFpbnMgdGhlIGZvbGxvd2luZyByZXF1aXJlbWVudDo8 YnI+DQo8YnI+DQomcXVvdDtJbXBsZW1lbnRhdGlvbnMgY29uZm9ybWluZyB0byB0aGlzIFJGQyBN VVNUIGltcGxlbWVudCBUQ1AtQU8gdG8gc2VjdXJlIHRoZSBUQ1Agc2Vzc2lvbnMgY2Fycnlpbmcg TERQIGluIGFkZGl0aW9uIHRvIHRoZSBjdXJyZW50bHkgcmVxdWlyZWQgVENQIE1ENSBTaWduYXR1 cmUgT3B0aW9uLiBGdXJ0aGVybW9yZSwgdGhlIFRCRCBjcnlwdG9ncmFwaGljIG1lY2hhbmlzbSBt dXN0IGJlIGltcGxlbWVudGVkIGFuZCBwcm92aWRlZCB0byBUQ1AtQU8gdG8NCiBzZWN1cmUgTERQ IG1lc3NhZ2VzLiBUaGUgVEJEIG1lY2hhbmlzbSBpcyB0aGUgcHJlZmVycmVkIG9wdGlvbiwgYW5k IE1ENSBpcyBvbmx5IHRvIGJlIHVzZWQgd2hlbiBUQkQgaXMgdW5hdmFpbGFibGUuJnF1b3Q7PGJy Pg0KPGJyPg0KV2UgYXJlIG5vdCBhbiBleHBlcnRzIG9uIHRoaXMgcGFydCBvZiB0aGUgc3RhY2ss IGJ1dCBpdCBzZWVtcyB0aGF0IFRDUCBzZWN1cml0eSBuZWdvdGlhdGlvbiBpcyBzdGlsbCB3b3Jr IGluIHByb2dyZXNzLiBJZiB3ZSBhcmUgd3JvbmcsIHRoZW4gd2UgbmVlZCB0byBpbmNsdWRlIGEg cmVxdWlyZW1lbnQgdGhhdCBzdWNoIG5lZ290aWF0aW9uIGlzIGFsc28gcmVxdWlyZWQuIEluIHRo ZSBhYnNlbmNlIG9mIGEgbmVnb3RpYXRpb24gcHJvdG9jb2wsIGhvd2V2ZXIsDQogd2UgbmVlZCB0 byBsZWF2ZSB0aGlzIGFzIGEgY29uZmlndXJhdGlvbiBwcm9jZXNzIHVudGlsIHN1Y2ggdGltZSBh cyB0aGUgbmVnb3RpYXRpb24gcHJvdG9jb2wgd29yayBpcyBjb21wbGV0ZS4gT24gY29tcGxldGlv biBvZiBhIHN1aXRhYmxlIG5lZ290aWF0aW9uIHByb3RvY29sIHdlIG5lZWQgdG8gaXNzdWUgYSBm dXJ0aGVyIHVwZGF0ZSByZXF1aXJpbmcgaXRzIHVzZS48YnI+DQo8YnI+DQpBZGRpdGlvbmFsbHkg d2Ugc2hvdWxkIG5vdGUgdGhhdCBubyBjcnlwdG9ncmFwaGljIG1lY2hhbmlzbSBoYXMgYW4gaW5k ZWZpbml0ZSBsaWZldGltZSwgYW5kIHRoYXQgaW1wbGVtZW50YXRpb24gc2hvdWxkIG5vdGUgdGhl IElFVEYgYW50aWNpcGF0ZXMgdXBkYXRpbmcgdGhlIGRlZmF1bHQgY3J5cHRvZ3JhcGhpYyBtZWNo YW5pc20gb3ZlciB0aW1lLjxicj4NCjxicj4NClRoZSBUQkQgZGVmYXVsdCBzZWN1cml0eSBmdW5j dGlvbiB3aWxsIG5lZWQgdG8gYmUgY2hvc2VuIHN1Y2ggdGhhdCBpdCBjYW4gcmVhc29uYWJseSBi ZSBpbXBsZW1lbnRlZCBvbiBhIHR5cGljYWwgcm91dGVyIHJvdXRlIHByb2Nlc3NvciwgYW5kIHdo aWNoIHdpbGwgcHJvdmlkZSBhZGVxdWF0ZSBzZWN1cml0eSB3aXRob3V0IHNpZ25pZmljYW50bHkg ZGVncmFkaW5nIHRoZSBjb252ZXJnZW5jZSB0aW1lIG9mIGFuIExTUi4gV2l0aG91dCBhIGZ1bmN0 aW9uDQogdGhhdCBkb2VzIG5vdCBzaWduaWZpY2FudGx5IGltcGFjdCByb3V0ZXIgY29udmVyZ2Vu Y2Ugd2Ugc2ltcGx5IGNsb3NlIG9uZSB2dWxuZXJhYmlsaXR5IGFuZCBvcGVuIGFub3RoZXIuPGJy Pg0KPGJyPg0KQXMgZXhwZXJ0cyBvbiB0aGUgTERQIHByb3RvY29sLCBidXQgbm90IG9uIHNlY3Vy aXR5IG1lY2hhbmlzbXMsIHdlJm5ic3A7IG5lZWQgdG8gYXNrIHRoZSBzZWN1cml0eSBhcmVhIGZv ciBhIHJldmlldyBvZiBvdXIgcHJvcG9zZWQgYXBwcm9hY2gsIGFuZCBoZWxwIGNvcnJlY3Rpbmcg YW55IG1pc3VuZGVyc3RhbmRpbmcgb2YgdGhlIHNlY3VyaXR5IGlzc3VlcyBvciBvdXIgbWlzdW5k ZXJzdGFuZGluZyBvZiB0aGUgZXhpc3Rpbmcgc2VjdXJpdHkgbWVjaGFuaXNtcy4NCiBXZSBhbHNv IG5lZWQgdGhlIHJlY29tbWVuZGF0aW9ucyBvZiBhIHN1aXRhYmxlIHNlY3VyaXR5IGZ1bmN0aW9u IChUQkQgaW4gdGhlIGFib3ZlIHRleHQpLjxicj4NCjxicj4NCkJlc3QgcmVnYXJkczxicj4NCjxi cj4NClRoZSBNUExTIFdHIENoYWlyczxicj4NClRoZSBQQUxTIFdHIENoYWlyczxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_48E1A67CB9CA044EADFEAB87D814BFF64B870140eusaamb107erics_-- From nobody Wed Nov 8 15:50:40 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541CD12778E; Wed, 8 Nov 2017 15:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AncWLaEE2lCO; Wed, 8 Nov 2017 15:50:35 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06BF6127010; Wed, 8 Nov 2017 15:50:33 -0800 (PST) Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DZK78312; Wed, 08 Nov 2017 23:50:32 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 8 Nov 2017 23:50:30 +0000 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.92]) by SJCEML701-CHM.china.huawei.com ([169.254.3.104]) with mapi id 14.03.0361.001; Wed, 8 Nov 2017 15:50:25 -0800 From: Uma Chunduri To: Eric Rescorla CC: Stewart Bryant , "mpls@ietf.org" , "pals-chairs@tools.ietf.org" , "" , "mpls-chairs@ietf.org" , "pals@ietf.org" , "" Thread-Topic: [mpls] LDP Security Thread-Index: AQHTWLbyOfMae53/m0ycVXrEQ0bS1aMLS2UA//+SrUCAAJ2kAP//pwtQ Date: Wed, 8 Nov 2017 23:50:24 +0000 Message-ID: <25B4902B1192E84696414485F5726854135191D6@sjceml521-mbs.china.huawei.com> References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <5994f353-5306-0fa8-2d2d-024ebdbb10df@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> <25B4902B1192E84696414485F57268541351915D@sjceml521-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.168] Content-Type: multipart/alternative; boundary="_000_25B4902B1192E84696414485F5726854135191D6sjceml521mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5A039848.00F5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.92, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 14d312b36b9605c70916f063eabc04c2 Archived-At: Subject: Re: [Pals] [mpls] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 23:50:38 -0000 --_000_25B4902B1192E84696414485F5726854135191D6sjceml521mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4tbGluZSBbVW1hMV06DQotLQ0KVW1hIEMuDQoNCkZyb206IEVyaWMgUmVzY29ybGEgW21haWx0 bzpla3JAcnRmbS5jb21dDQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDA4LCAyMDE3IDEyOjUz IFBNDQpUbzogVW1hIENodW5kdXJpIDx1bWEuY2h1bmR1cmlAaHVhd2VpLmNvbT4NCkNjOiBTdGV3 YXJ0IEJyeWFudCA8c3Rld2FydC5icnlhbnRAZ21haWwuY29tPjsgbXBsc0BpZXRmLm9yZzsgcGFs cy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IDxydGctYWRzQGlldGYub3JnPiA8cnRnLWFkc0BpZXRm Lm9yZz47IG1wbHMtY2hhaXJzQGlldGYub3JnOyBwYWxzQGlldGYub3JnOyA8c2VjLWFkc0BpZXRm Lm9yZz4gPHNlYy1hZHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21wbHNdIExEUCBTZWN1cml0 eQ0KDQoNCg0KT24gV2VkLCBOb3YgOCwgMjAxNyBhdCAxMTo1NyBBTSwgVW1hIENodW5kdXJpIDx1 bWEuY2h1bmR1cmlAaHVhd2VpLmNvbTxtYWlsdG86dW1hLmNodW5kdXJpQGh1YXdlaS5jb20+PiB3 cm90ZToNCkhpIFN0ZXdhcnQsDQoNCkkgd291bGQgbm90ZSBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNjk1MiAtIHdoZXJlIExEUCBzZWN1cml0eSBpcyBhbmFseXplZCBmcm9tIGFsbCBh c3BlY3RzLg0KDQpFcmljLA0KDQpRdWljayBjb21tZW50cyBiZWxvdyBbVW1hXToNCg0KLS0NClVt YSBDLg0KDQpGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpt cGxzLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2VudDog V2VkbmVzZGF5LCBOb3ZlbWJlciAwOCwgMjAxNyAxMDowMCBBTQ0KVG86IFN0ZXdhcnQgQnJ5YW50 IDxzdGV3YXJ0LmJyeWFudEBnbWFpbC5jb208bWFpbHRvOnN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNv bT4+DQpDYzogbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz47IHBhbHMtY2hhaXJz QHRvb2xzLmlldGYub3JnPG1haWx0bzpwYWxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz47IDxydGct YWRzQGlldGYub3JnPG1haWx0bzpydGctYWRzQGlldGYub3JnPj4gPHJ0Zy1hZHNAaWV0Zi5vcmc8 bWFpbHRvOnJ0Zy1hZHNAaWV0Zi5vcmc+PjsgbXBscy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOm1w bHMtY2hhaXJzQGlldGYub3JnPjsgcGFsc0BpZXRmLm9yZzxtYWlsdG86cGFsc0BpZXRmLm9yZz47 IDxzZWMtYWRzQGlldGYub3JnPG1haWx0bzpzZWMtYWRzQGlldGYub3JnPj4gPHNlYy1hZHNAaWV0 Zi5vcmc8bWFpbHRvOnNlYy1hZHNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFttcGxzXSBMRFAg U2VjdXJpdHkNCg0KSGkgU3Rld2FydA0KDQpUaGFua3MgZm9yIHlvdXIgbm90ZS4NCg0KTXkgb3Zl cmFsbCBzZW5zZSBvZiB0aGUgc3RhdGUgb2YgcGxheSBpcywgSSB0aGluayBtdWNoIGxpa2UgeW91 cnMuDQoNClRDUC1NRDUgaXMgaW5hZGVxdWF0ZSBpbiB0d28gbWFqb3IgcmVzcGVjdHM6DQotIEl0 IHVzZXMgd2VhayBhbGdvcml0aG1zDQotIEl0IGhhcyBhIGJhZCBuZWdvdGlhdGlvbi9zZXR1b3Ag c3RvcnkgKG1hbnVhbCBrZXkgbWFuYWdlbWVudCkNCg0KVENQLUFPIGlzIGludGVuZGVkIHRvIGJl IGEgZHJvcC1pbiByZXBsYWNlbWVudCBmb3IgVENQLU1ENSBhbmQgc28gcmVtZWRpZXMgdGhlIGFs Z29yaXRobQ0KSXNzdWUNCg0KW1VtYV06IFllcywgaWYgd2UgZ28gd2l0aCBSRkMgNTkyNiBtYW5k YXRvcnkgbGlzdC4uDQoNCmJ1dCBub3QgdGhlIGtleSBtYW5hZ2VtZW50IGlzc3VlIFswXS4gV2Ug aGF2ZW4ndCBtYWRlIG11Y2ggcHJvZ3Jlc3Mgb24gdGhlIGtleQ0KbWFuYWdlbWVudCBzdG9yeSwg YW5kIHRoYXQgc2VlbXMgdG8gYmUgYSBtYWpvciBpbXBlZGltZW50IHRvIGRlcGxveWluZyBlaXRo ZXIgb2YgdGhlc2UNCnRlY2hub2xvZ2llcyAod2hpY2ggSSBhbSBnaXZlbiB0byB1bmRlcnN0YW5k IGRvbid0IHNlZSBhIGxvdCBvZiB1c2UpLg0KDQpbVW1hXTogVHJ1ZS4NCiAgICAgICAgICAgICAg IEJ1dCBJIHdvdWxkIGluZGljYXRlIHNvbWUgZWZmb3J0IGRvbmUgZmV3IHllYXJzIGJhY2sgcmVn YXJkaW5nIGtleSBtYW5hZ2VtZW50IGZvciBwYWlyIHdpc2Ugcm91dGluZyBwcm90b2NvbHMgKEJH UCwgTERQLCBQQ0VQLCBNU0RQIC4uKS4NCiAgICAgICAgICAgICAgIE9uZSBzdWNoIHByb3Bvc2Fs IGlzIGJ5IGV4dGVuZGluZyBJS0V2MiB0byBuZWdvdGlhdGUgVENQLUFPIE1LVHMgKHdoaWNoIGNh biBnaXZlIHJla2V5ICYgYWxnby4gYWdpbGl0eSkgLSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtbWFoZXNoLWthcnAtcmttcC0wNQ0KICAgICAgICAgICAgICAgVGhpcyBhbHNvIHJl cXVpcmVzIHNvbWUgbW9yZSB3b3JrIHdpdGggVENQLUFPOyBtZSAmIEpvZSBwdXQgdG9nZXRoZXIg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1jaHVuZHVyaS1rYXJwLXVzaW5n LWlrZXYyLXdpdGgtdGNwLWFvLTA2LnR4dA0KICAgICAgICAgICBOb3RlIHRoZSBhYm92ZSBkaWRu 4oCZdCBwcm9ncmVzcyBpbiB0aGUgY29uY2x1ZGVkIEtBUlAgV0cgKG5vdCBmdWxseSBzdXJlIHRo ZSByZWFzb25zIG9uIHdoeSkuDQoNClllYWgsIEkga25vdyB0aGF0IHBlb3BsZSB0cmllZCB0byBk byB0aGlzLCBidXQgbXkgaW1wcmVzc2lvbiB3YXMgaXQga2luZGEgZGlkbid0IHByb2dyZXNzIG11 Y2guDQoNCg0KDQpXZSBzaG91bGQgcHJvYmFibHkgdGFsayBpbiBTaW5nYXBvcmUgYWJvdXQgdGhh dCwgYnV0IHRoYXQncyBub3QgZ29pbmcgdG8gZ2V0IGJldHRlciBhbnkgdGltZSBzb29uLg0KDQpJ biB0aGUgaW50ZXJpbSwgSSB0aGluayB0aGUgdGV4dCB5b3UgaGF2ZSBpcyBPSywgYW5kICJUQkQi IHNob3VsZCByZWFkICJTSEEtMjU2Iiwgd2l0aA0KdGhlIGZhbGxiYWNrIGJlaW5nIFNIQS0yNTYg LT4gU0hBLTEgLT4gTUQ1Lg0KDQpbVW1hXTogV2hpbGUgdGhlIGxpc3QgY2FuIGJlIGV4dGVuZGVk IC0gSSBkaWRu4oCZdCBzZWUgU0hBMjU2IGluIHRoZSBtYW5kYXRvcnkgbGlzdCBpbiBSRkMgNTky NiBmb3IgTUFDLg0KDQpHZW5lcmFsbHkgd2UncmUgdHJ5aW5nIHRvIG1vdmUgYXdheSBmcm9tIFNI QS0xIHRvd2FyZHMgU0hBLTI1Ni4NCg0KW1VtYTFdOiBDb3VwbGUgb2YgdGhpbmdzOg0KDQoxLiAg ICAgICBOb3RoaW5nIHRvIGJlIGRvbmUgKGZyb20gc3BlYyBwb3Ygb2YgY291cnNlKTogVXNlIFRD UC1BTyAoaW5zdGVhZCBvZiBjdXJyZW50IE1ENSkgd2l0aCB0aGUgUkZDIDU5MjYgbWFuZGF0ZWQg TUFDcy9LREZzIOKAkyBzbyB0aGUg4oCYVEJE4oCZIGluIFN0ZXdhcnQgc3VnZ2VzdGluZyBiZWxv dyBpcyBhbHJlYWR5IHRoZXJlLg0KDQoyLiAgICAgICBBcyAjMSB0b28gaXMgbm90IGdvb2QgZW5v dWdoIGZyb20geW91ciBhYm92ZSBub3RlIC0gZG8gU0hBLTI1NiBhbmQgbGl2ZSB3aXRoIGl0IChu byBhbGdvcml0aG0gYWdpbGl0eSkuIFN0aWxsIGEgc2VjdXJpdHkgYmVuZWZpdCBpbiBvbmUgd2F5 IGZyb20gZXhpc3Rpbmcgc3R1ZmYgb3IgZXZlbiAgIzEuDQoNCjMuICAgICAgIERvIGtleSBtYW5h Z2VtZW50IGFuZCDigJx0aGVvcmV0aWNhbGx54oCdIGdldCBhbGwgd2Ugd2FudGVk4oCmLg0KDQpX ZSBoYXZlIGJlZW4gaGVyZSBtdWx0aXBsZSB0aW1lczsgYmVjYXVzZSAjMSBpdHNlbGYgaXMgbm90 ICptb3N0bHkqIGRlcGxveWVkIChuZWl0aGVyIGluIEJHUCBub3IgaW4gTERQKSBpZiB0aGVyZSBp cyBhbnkgYXBwZXRpdGUgZm9yICMyIGFuZCAjMyBmb3IgcHJhY3RpY2FsIGRlcGxveW1lbnRzLiBC dXQgc3RpbGwgaXQgbWF5IGJlIGdvb2QgdG8gZG8gIzIgYW55IHdheXMuDQoNCg0KLUVrcg0KDQoN Ci1Fa3INCg0KDQpbMF0gVGVjaG5pY2FsbHkgSXQgaGFzIGJldHRlciBzdXBwb3J0IGZvciByb2xs b3ZlciwgYnV0IHRoaXMgaXMgbm90IGEgaHVnZSBpbXByb3ZlbWVudC4NClsxXSB0Y3BjcnlwdCBp cyBraW5kIG9mIG9ydGhvZ29uYWwgaGVyZSBhcyBpdCdzIHVuYXV0aGVudGljYXRlZCBidXQgb3Bw b3J0dW5pc3RpYy4gIFRoYXQgc2FpZCwNCml0IHdvdWxkIHByb3ZpZGUgZGVmZW5zZSBhZ2FpbnN0 IGF0dGFja2VycyB3aG8gZ2FpbiBhY2Nlc3MgdG8gdGhlIGxpbmsgYWZ0ZXIgY29ubmVjdGlvbg0K c2V0dXAgYW5kIGRvZXNuJ3QgcmVxdWlyZSBjb25maWd1cmF0aW9uLg0KDQpPbiBXZWQsIE5vdiA4 LCAyMDE3IGF0IDk6MjcgQU0sIFN0ZXdhcnQgQnJ5YW50IDxzdGV3YXJ0LmJyeWFudEBnbWFpbC5j b208bWFpbHRvOnN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbT4+IHdyb3RlOg0KVG8gdGhlIFNFQyBh bmQgUlRHIEFEcywNCg0KSSBhbSBzZW5kaW5nIHRoZSBmb2xsb3dpbmcgbWVzc2FnZSBvbiBiZWhh bGYgb2YgdGhlIE1QTFMgYW5kIHRoZQ0KUEFMUyBXRyBDaGFpcnMuDQoNClRoZXJlIGlzIGEgY29u Y2VybiBzaGFyZWQgYW1vbmcgdGhlIHNlY3VyaXR5IGNvbW11bml0eSBhbmQgdGhlIHdvcmtpbmcg Z3JvdXBzIHRoYXQgZGV2ZWxvcCB0aGUgTERQIHByb3RvY29sIHRoYXQgTERQIGlzIG5vIGxvbmdl ciBhZGVxdWF0ZWx5IHNlY3VyZWQuIExEUCBjdXJyZW50bHkgcmVsaWVzIG9uIE1ENSBmb3IgY3J5 cHRvZ3JhcGhpYyBzZWN1cml0eSBvZiBpdHMgbWVzc2FnZXMsIGJ1dCBNRDUgaXMgYSBoYXNoIGZ1 bmN0aW9uIHRoYXQgaXMgbm8gbG9uZ2VyIGNvbnNpZGVyZWQgdG8gbWVldCBjdXJyZW50IHNlY3Vy aXR5IHJlcXVpcmVtZW50cy4NCg0KSW4gUkZDNTAzNiAocHVibGlzaGVkIDIwMDcpIFNlY3Rpb24g NS4xIChTcG9vZmluZykgLCBMaXN0IGVsZW1lbnQgMi4gU2Vzc2lvbiBjb21tdW5pY2F0aW9uIGNh cnJpZWQgYnkgVENQIHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50cyBpcyBtYWRlOg0KDQoiTERQIHNw ZWNpZmllcyB1c2Ugb2YgdGhlIFRDUCBNRDUgU2lnbmF0dXJlIE9wdGlvbiB0byBwcm92aWRlIGZv ciB0aGUgYXV0aGVudGljaXR5IGFuZCBpbnRlZ3JpdHkgb2Ygc2Vzc2lvbiBtZXNzYWdlcy4NCg0K IltSRkMyMzg1XSBhc3NlcnRzIHRoYXQgTUQ1IGF1dGhlbnRpY2F0aW9uIGlzIG5vdyBjb25zaWRl cmVkIGJ5IHNvbWUgdG8gYmUgdG9vIHdlYWsgZm9yIHRoaXMgYXBwbGljYXRpb24uICBJdCBhbHNv IHBvaW50cyBvdXQgdGhhdCBhIHNpbWlsYXIgVENQIG9wdGlvbiB3aXRoIGEgc3Ryb25nZXIgaGFz aGluZyBhbGdvcml0aG0gKGl0IGNpdGVzIFNIQS0xIGFzIGFuIGV4YW1wbGUpIGNvdWxkIGJlIGRl cGxveWVkLiAgVG8gb3VyIGtub3dsZWRnZSwgbm8gc3VjaCBUQ1Agb3B0aW9uIGhhcyBiZWVuIGRl ZmluZWQgYW5kIGRlcGxveWVkLiAgSG93ZXZlciwgd2Ugbm90ZSB0aGF0IExEUCBjYW4gdXNlIHdo YXRldmVyIFRDUCBtZXNzYWdlIGRpZ2VzdCB0ZWNobmlxdWVzIGFyZSBhdmFpbGFibGUsIGFuZCB3 aGVuIG9uZSBzdHJvbmdlciB0aGFuIE1ENSBpcyBzcGVjaWZpZWQgYW5kIGltcGxlbWVudGVkLCB1 cGdyYWRpbmcgTERQIHRvIHVzZSBpdCB3b3VsZCBiZSByZWxhdGl2ZWx5IHN0cmFpZ2h0Zm9yd2Fy ZC4iDQoNCldlIG5vdGUgdGhhdCBCR1AgaGFzIGFscmVhZHkgYmVlbiB0aHJvdWdoIHRoaXMgcHJv Y2VzcywgYW5kIHJlcGxhY2VkIE1ENSB3aXRoIFRDUC1BTyBpbiBSRkMgNzQ1NC4gSSB3b3VsZCBi ZSBsb2dpY2FsIHRvIGZvbGxvdyB0aGUgc2FtZSBhcHByb2FjaCB0byBzZWN1cmUgTERQLiBIb3dl dmVyLCBhcyBmYXIgYXMgd2UgYXJlIGFibGUgdG8gYXNjZXJ0YWluLCB0aGVyZSBpcyBjdXJyZW50 bHkgbm8gcmVjb21tZW5kZWQsIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQsIGNyeXB0b2dyYXBoaWMg ZnVuY3Rpb24gc3BlY2lmaWVkLiBXZSBhcmUgY29uY2VybmVkIHRoYXQgd2l0aG91dCBzdWNoIGEg bWFuZGF0b3J5IGZ1bmN0aW9uLCBpbXBsZW1lbnRhdGlvbnMgd2lsbCBzaW1wbHkgZmFsbCBiYWNr IHRvIE1ENSBhbmQgd2Ugd2lsbCBiZSBubyBmdXJ0aGVyIGZvcndhcmQNCg0KV2UgdGhpbmsgdGhh dCB0aGUgYmVzdCB3YXkgZm9yd2FyZCBpcyB0byBwdWJsaXNoIGEgZHJhZnQgc2ltaWxhciB0byBS RkMgNzQ1NCB0aGF0IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgcmVxdWlyZW1lbnQ6DQoNCiJJbXBs ZW1lbnRhdGlvbnMgY29uZm9ybWluZyB0byB0aGlzIFJGQyBNVVNUIGltcGxlbWVudCBUQ1AtQU8g dG8gc2VjdXJlIHRoZSBUQ1Agc2Vzc2lvbnMgY2FycnlpbmcgTERQIGluIGFkZGl0aW9uIHRvIHRo ZSBjdXJyZW50bHkgcmVxdWlyZWQgVENQIE1ENSBTaWduYXR1cmUgT3B0aW9uLiBGdXJ0aGVybW9y ZSwgdGhlIFRCRCBjcnlwdG9ncmFwaGljIG1lY2hhbmlzbSBtdXN0IGJlIGltcGxlbWVudGVkIGFu ZCBwcm92aWRlZCB0byBUQ1AtQU8gdG8gc2VjdXJlIExEUCBtZXNzYWdlcy4gVGhlIFRCRCBtZWNo YW5pc20gaXMgdGhlIHByZWZlcnJlZCBvcHRpb24sIGFuZCBNRDUgaXMgb25seSB0byBiZSB1c2Vk IHdoZW4gVEJEIGlzIHVuYXZhaWxhYmxlLiINCg0KV2UgYXJlIG5vdCBhbiBleHBlcnRzIG9uIHRo aXMgcGFydCBvZiB0aGUgc3RhY2ssIGJ1dCBpdCBzZWVtcyB0aGF0IFRDUCBzZWN1cml0eSBuZWdv dGlhdGlvbiBpcyBzdGlsbCB3b3JrIGluIHByb2dyZXNzLiBJZiB3ZSBhcmUgd3JvbmcsIHRoZW4g d2UgbmVlZCB0byBpbmNsdWRlIGEgcmVxdWlyZW1lbnQgdGhhdCBzdWNoIG5lZ290aWF0aW9uIGlz IGFsc28gcmVxdWlyZWQuIEluIHRoZSBhYnNlbmNlIG9mIGEgbmVnb3RpYXRpb24gcHJvdG9jb2ws IGhvd2V2ZXIsIHdlIG5lZWQgdG8gbGVhdmUgdGhpcyBhcyBhIGNvbmZpZ3VyYXRpb24gcHJvY2Vz cyB1bnRpbCBzdWNoIHRpbWUgYXMgdGhlIG5lZ290aWF0aW9uIHByb3RvY29sIHdvcmsgaXMgY29t cGxldGUuIE9uIGNvbXBsZXRpb24gb2YgYSBzdWl0YWJsZSBuZWdvdGlhdGlvbiBwcm90b2NvbCB3 ZSBuZWVkIHRvIGlzc3VlIGEgZnVydGhlciB1cGRhdGUgcmVxdWlyaW5nIGl0cyB1c2UuDQoNCkFk ZGl0aW9uYWxseSB3ZSBzaG91bGQgbm90ZSB0aGF0IG5vIGNyeXB0b2dyYXBoaWMgbWVjaGFuaXNt IGhhcyBhbiBpbmRlZmluaXRlIGxpZmV0aW1lLCBhbmQgdGhhdCBpbXBsZW1lbnRhdGlvbiBzaG91 bGQgbm90ZSB0aGUgSUVURiBhbnRpY2lwYXRlcyB1cGRhdGluZyB0aGUgZGVmYXVsdCBjcnlwdG9n cmFwaGljIG1lY2hhbmlzbSBvdmVyIHRpbWUuDQoNClRoZSBUQkQgZGVmYXVsdCBzZWN1cml0eSBm dW5jdGlvbiB3aWxsIG5lZWQgdG8gYmUgY2hvc2VuIHN1Y2ggdGhhdCBpdCBjYW4gcmVhc29uYWJs eSBiZSBpbXBsZW1lbnRlZCBvbiBhIHR5cGljYWwgcm91dGVyIHJvdXRlIHByb2Nlc3NvciwgYW5k IHdoaWNoIHdpbGwgcHJvdmlkZSBhZGVxdWF0ZSBzZWN1cml0eSB3aXRob3V0IHNpZ25pZmljYW50 bHkgZGVncmFkaW5nIHRoZSBjb252ZXJnZW5jZSB0aW1lIG9mIGFuIExTUi4gV2l0aG91dCBhIGZ1 bmN0aW9uIHRoYXQgZG9lcyBub3Qgc2lnbmlmaWNhbnRseSBpbXBhY3Qgcm91dGVyIGNvbnZlcmdl bmNlIHdlIHNpbXBseSBjbG9zZSBvbmUgdnVsbmVyYWJpbGl0eSBhbmQgb3BlbiBhbm90aGVyLg0K DQpBcyBleHBlcnRzIG9uIHRoZSBMRFAgcHJvdG9jb2wsIGJ1dCBub3Qgb24gc2VjdXJpdHkgbWVj aGFuaXNtcywgd2UgIG5lZWQgdG8gYXNrIHRoZSBzZWN1cml0eSBhcmVhIGZvciBhIHJldmlldyBv ZiBvdXIgcHJvcG9zZWQgYXBwcm9hY2gsIGFuZCBoZWxwIGNvcnJlY3RpbmcgYW55IG1pc3VuZGVy c3RhbmRpbmcgb2YgdGhlIHNlY3VyaXR5IGlzc3VlcyBvciBvdXIgbWlzdW5kZXJzdGFuZGluZyBv ZiB0aGUgZXhpc3Rpbmcgc2VjdXJpdHkgbWVjaGFuaXNtcy4gV2UgYWxzbyBuZWVkIHRoZSByZWNv bW1lbmRhdGlvbnMgb2YgYSBzdWl0YWJsZSBzZWN1cml0eSBmdW5jdGlvbiAoVEJEIGluIHRoZSBh Ym92ZSB0ZXh0KS4NCg0KQmVzdCByZWdhcmRzDQoNClRoZSBNUExTIFdHIENoYWlycw0KVGhlIFBB TFMgV0cgQ2hhaXJzDQoNCg0K --_000_25B4902B1192E84696414485F5726854135191D6sjceml521mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJCcnVzaCBTY3JpcHQg TVQiOw0KCXBhbm9zZS0xOjMgNiA4IDIgNCA0IDYgNyAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiRnJlZXN0eWxlIFNjcmlwdCI7DQoJcGFub3NlLTE6MyA4IDQgMiAzIDIgNSAxMSA0 IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIg MSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZp bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MzE5NTA3OTM0Ow0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTQwMDczNjAxMiAtMjA0NDAy NjY0NiA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcw MyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0 OjU4LjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo5NC41cHQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjEzMC41cHQ7DQoJdGV4 dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTY2 LjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMDIuNXB0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4tbGVmdDoyMzguNXB0Ow0KCXRleHQt aW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjI3NC41 cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MzEwLjVwdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJbWFyZ2luLWxlZnQ6MzQ2LjVwdDsNCgl0ZXh0LWlu ZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkluLWxpbmUgW1VtYTFdOjxvOnA+PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LS08L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7RnJlZXN0eWxlIFNj cmlwdCZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VW1hIEMuPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0JydXNoIFNj cmlwdCBNVCZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gRXJpYyBSZXNjb3JsYSBbbWFp bHRvOmVrckBydGZtLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE5vdmVtYmVy IDA4LCAyMDE3IDEyOjUzIFBNPGJyPg0KPGI+VG86PC9iPiBVbWEgQ2h1bmR1cmkgJmx0O3VtYS5j aHVuZHVyaUBodWF3ZWkuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gU3Rld2FydCBCcnlhbnQgJmx0 O3N0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbSZndDs7IG1wbHNAaWV0Zi5vcmc7IHBhbHMtY2hhaXJz QHRvb2xzLmlldGYub3JnOyAmbHQ7cnRnLWFkc0BpZXRmLm9yZyZndDsgJmx0O3J0Zy1hZHNAaWV0 Zi5vcmcmZ3Q7OyBtcGxzLWNoYWlyc0BpZXRmLm9yZzsgcGFsc0BpZXRmLm9yZzsgJmx0O3NlYy1h ZHNAaWV0Zi5vcmcmZ3Q7ICZsdDtzZWMtYWRzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW21wbHNdIExEUCBTZWN1cml0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IFdlZCwgTm92IDgsIDIwMTcgYXQgMTE6NTcgQU0sIFVtYSBDaHVuZHVyaSAmbHQ7PGEgaHJlZj0i bWFpbHRvOnVtYS5jaHVuZHVyaUBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+dW1hLmNodW5k dXJpQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgbmFtZT0ibV8tNzY4NDQ4 ODMxNDY3MTQzMDIyM19fTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5IaSBTdGV3YXJ0LDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5JIHdvdWxkIG5vdGUNCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNjk1MiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY5NTI8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4NCiAtIHdoZXJlIExEUCBzZWN1cml0eSBpcyBhbmFseXplZCBmcm9t IGFsbCBhc3BlY3RzLiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5FcmljLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PlF1aWNrIGNvbW1lbnRzIGJlbG93IFtVbWFdOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPi0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VW1hIEMuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBtcGxzIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm1wbHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBOb3ZlbWJl ciAwOCwgMjAxNyAxMDowMCBBTTxicj4NCjxiPlRvOjwvYj4gU3Rld2FydCBCcnlhbnQgJmx0Ozxh IGhyZWY9Im1haWx0bzpzdGV3YXJ0LmJyeWFudEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5z dGV3YXJ0LmJyeWFudEBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0i bWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYub3JnPC9hPjsg PGEgaHJlZj0ibWFpbHRvOnBhbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+DQpwYWxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT47ICZsdDs8YSBocmVmPSJtYWlsdG86 cnRnLWFkc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Zy1hZHNAaWV0Zi5vcmc8L2E+Jmd0 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Zy1hZHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5y dGctYWRzQGlldGYub3JnPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86bXBscy1jaGFpcnNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzLWNoYWlyc0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9 Im1haWx0bzpwYWxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpwYWxzQGlldGYub3JnPC9h PjsgJmx0OzxhIGhyZWY9Im1haWx0bzpzZWMtYWRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ c2VjLWFkc0BpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2VjLWFkc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNlYy1hZHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW21wbHNdIExEUCBTZWN1cml0eTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5IaSBTdGV3YXJ0PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzIGZvciB5b3VyIG5vdGUuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5NeSBvdmVyYWxs IHNlbnNlIG9mIHRoZSBzdGF0ZSBvZiBwbGF5IGlzLCBJIHRoaW5rIG11Y2ggbGlrZSB5b3Vycy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PlRDUC1NRDUgaXMgaW5hZGVxdWF0ZSBpbiB0d28gbWFqb3IgcmVzcGVjdHM6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gSXQgdXNlcyB3ZWFr IGFsZ29yaXRobXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+LSBJdCBoYXMgYSBiYWQgbmVnb3RpYXRpb24vc2V0dW9wIHN0b3J5IChtYW51YWwg a2V5IG1hbmFnZW1lbnQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5UQ1AtQU8gaXMgaW50ZW5kZWQgdG8gYmUgYSBkcm9wLWluIHJlcGxh Y2VtZW50IGZvciBUQ1AtTUQ1IGFuZCBzbyByZW1lZGllcyB0aGUgYWxnb3JpdGhtPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklzc3VlPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bVW1hXTogWWVzLCBpZiB3ZSBnbyB3 aXRoIFJGQyA1OTI2IG1hbmRhdG9yeSBsaXN0Li48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmJ1dCBub3QgdGhl IGtleSBtYW5hZ2VtZW50IGlzc3VlIFswXS4gV2UgaGF2ZW4ndCBtYWRlIG11Y2ggcHJvZ3Jlc3Mg b24gdGhlIGtleTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5tYW5hZ2VtZW50IHN0b3J5LCBhbmQgdGhhdCBzZWVtcyB0byBiZSBhIG1ham9yIGlt cGVkaW1lbnQgdG8gZGVwbG95aW5nIGVpdGhlciBvZiB0aGVzZTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj50ZWNobm9sb2dpZXMgKHdoaWNoIEkg YW0gZ2l2ZW4gdG8gdW5kZXJzdGFuZCBkb24ndCBzZWUgYSBsb3Qgb2YgdXNlKS4NCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1VtYV06IFRydWUuDQo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtCdXQgSSB3b3VsZCBp bmRpY2F0ZSBzb21lIGVmZm9ydCBkb25lIGZldyB5ZWFycyBiYWNrIHJlZ2FyZGluZyBrZXkgbWFu YWdlbWVudCBmb3IgcGFpcg0KIHdpc2Ugcm91dGluZyBwcm90b2NvbHMgKEJHUCwgTERQLCBQQ0VQ LCBNU0RQIC4uKS4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7T25lIHN1Y2ggcHJvcG9zYWwgaXMgYnkgZXh0ZW5kaW5nIElLRXYyIHRvIG5lZ290 aWF0ZSBUQ1AtQU8gTUtUcyAod2hpY2ggY2FuIGdpdmUgcmVrZXkNCiAmYW1wOyBhbGdvLiBhZ2ls aXR5KSAtIDwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt bWFoZXNoLWthcnAtcmttcC0wNSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1tYWhlc2gta2FycC1ya21wLTA1PC9hPiZuYnNwOw0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGlzIGFsc28gcmVxdWlyZXMgc29t ZSBtb3JlIHdvcmsgd2l0aCBUQ1AtQU87IG1lICZhbXA7IEpvZSBwdXQgdG9nZXRoZXINCjwvc3Bh bj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWNodW5kdXJp LWthcnAtdXNpbmctaWtldjItd2l0aC10Y3AtYW8tMDYudHh0IiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1jaHVuZHVyaS1rYXJwLXVzaW5nLWlr ZXYyLXdpdGgtdGNwLWFvLTA2LnR4dDwvYT4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Tm90ZSB0 aGUgYWJvdmUgZGlkbuKAmXQgcHJvZ3Jlc3MgaW4gdGhlIGNvbmNsdWRlZCBLQVJQIFdHIChub3Qg ZnVsbHkgc3VyZSB0aGUgcmVhc29ucyBvbiB3aHkpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+WWVhaCwgSSBrbm93IHRoYXQgcGVvcGxlIHRyaWVkIHRvIGRvIHRo aXMsIGJ1dCBteSBpbXByZXNzaW9uIHdhcyBpdCBraW5kYSBkaWRuJ3QgcHJvZ3Jlc3MgbXVjaC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+V2Ugc2hvdWxkIHByb2JhYmx5PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPg0KPC9zcGFuPnRhbGsgaW4gU2luZ2Fwb3JlIGFib3V0IHRoYXQsIGJ1dCB0aGF0J3Mg bm90IGdvaW5nIHRvIGdldCBiZXR0ZXIgYW55IHRpbWUgc29vbi48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SW4gdGhlIGludGVyaW0sIEkgdGhpbmsgdGhlIHRleHQgeW91IGhhdmUgaXMgT0ssIGFu ZCAmcXVvdDtUQkQmcXVvdDsgc2hvdWxkIHJlYWQgJnF1b3Q7U0hBLTI1NiZxdW90Oywgd2l0aDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj50aGUg ZmFsbGJhY2sgYmVpbmcgU0hBLTI1NiAtJmd0OyBTSEEtMSAtJmd0OyBNRDUuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bVW1hXTogV2hpbGUgdGhlIGxpc3QgY2FuIGJl IGV4dGVuZGVkIC0gSSBkaWRu4oCZdCBzZWUgU0hBMjU2IGluIHRoZSBtYW5kYXRvcnkgbGlzdCBp biBSRkMgNTkyNiBmb3IgTUFDLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+R2VuZXJhbGx5IHdlJ3JlIHRyeWluZyB0byBtb3ZlIGF3YXkgZnJvbSBTSEEtMSB0b3dh cmRzIFNIQS0yNTYuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltVbWExXTog Q291cGxlIG9mIHRoaW5nczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjU4LjVwdDt0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Tm90aGluZyB0byBiZSBkb25l IChmcm9tIHNwZWMgcG92IG9mIGNvdXJzZSk6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+IFVzZSBUQ1AtQU8NCiAoaW5zdGVhZCBvZiBjdXJyZW50IE1ENSkgd2l0aCB0 aGUgUkZDIDU5MjYgbWFuZGF0ZWQgTUFDcy9LREZzIOKAkyBzbyB0aGUg4oCYVEJE4oCZIGluIFN0 ZXdhcnQgc3VnZ2VzdGluZyBiZWxvdyBpcyBhbHJlYWR5IHRoZXJlLg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo1 OC41cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkFzICMxIHRvbyBpcyBub3QgZ29vZCBlbm91Z2ggZnJvbSB5b3VyIGFib3ZlIG5vdGUgLSBk byBTSEEtMjU2IGFuZCBsaXZlIHdpdGggaXQgKG5vIGFsZ29yaXRobSBhZ2lsaXR5KS4gU3RpbGwg YSBzZWN1cml0eSBiZW5lZml0IGluIG9uZSB3YXkgZnJvbSBleGlzdGluZw0KIHN0dWZmIG9yIGV2 ZW4gJm5ic3A7IzEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo1OC41cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4zLjxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkRvIGtleSBtYW5hZ2VtZW50IGFuZCDigJx0 aGVvcmV0aWNhbGx54oCdIGdldCBhbGwgd2Ugd2FudGVk4oCmLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2UgaGF2ZSBiZWVuIGhlcmUgbXVsdGlwbGUgdGltZXM7 IGJlY2F1c2UgIzEgaXRzZWxmIGlzIG5vdCAqPGI+bW9zdGx5PC9iPiogZGVwbG95ZWQgKG5laXRo ZXIgaW4gQkdQIG5vciBpbiBMRFApIGlmIHRoZXJlIGlzIGFueSBhcHBldGl0ZSBmb3IgIzIgYW5k ICMzIGZvciBwcmFjdGljYWwNCiBkZXBsb3ltZW50cy4gQnV0IHN0aWxsIGl0IG1heSBiZSBnb29k IHRvIGRvICMyIGFueSB3YXlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1Fa3I8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5bMF0gVGVjaG5pY2Fs bHkgSXQgaGFzIGJldHRlciBzdXBwb3J0IGZvciByb2xsb3ZlciwgYnV0IHRoaXMgaXMgbm90IGEg aHVnZSBpbXByb3ZlbWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+WzFdIHRjcGNyeXB0IGlzIGtpbmQgb2Ygb3J0aG9nb25hbCBoZXJlIGFz IGl0J3MgdW5hdXRoZW50aWNhdGVkIGJ1dCBvcHBvcnR1bmlzdGljLiZuYnNwOyBUaGF0IHNhaWQs PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPml0 IHdvdWxkIHByb3ZpZGUgZGVmZW5zZSBhZ2FpbnN0IGF0dGFja2VycyB3aG8gZ2FpbiBhY2Nlc3Mg dG8gdGhlIGxpbmsgYWZ0ZXIgY29ubmVjdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5zZXR1cCBhbmQgZG9lc24ndCByZXF1aXJlIGNvbmZp Z3VyYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5PbiBXZWQsIE5vdiA4LCAyMDE3IGF0IDk6MjcgQU0sIFN0ZXdhcnQgQnJ5YW50 ICZsdDs8YSBocmVmPSJtYWlsdG86c3Rld2FydC5icnlhbnRAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+c3Rld2FydC5icnlhbnRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdCI+VG8gdGhlIFNFQyBhbmQgUlRHIEFEcyw8YnI+DQo8YnI+DQpJIGFtIHNl bmRpbmcgdGhlIGZvbGxvd2luZyBtZXNzYWdlIG9uIGJlaGFsZiBvZiB0aGUgTVBMUyBhbmQgdGhl PGJyPg0KUEFMUyBXRyBDaGFpcnMuPGJyPg0KPGJyPg0KVGhlcmUgaXMgYSBjb25jZXJuIHNoYXJl ZCBhbW9uZyB0aGUgc2VjdXJpdHkgY29tbXVuaXR5IGFuZCB0aGUgd29ya2luZyBncm91cHMgdGhh dCBkZXZlbG9wIHRoZSBMRFAgcHJvdG9jb2wgdGhhdCBMRFAgaXMgbm8gbG9uZ2VyIGFkZXF1YXRl bHkgc2VjdXJlZC4gTERQIGN1cnJlbnRseSByZWxpZXMgb24gTUQ1IGZvciBjcnlwdG9ncmFwaGlj IHNlY3VyaXR5IG9mIGl0cyBtZXNzYWdlcywgYnV0IE1ENSBpcyBhIGhhc2ggZnVuY3Rpb24gdGhh dCBpcw0KIG5vIGxvbmdlciBjb25zaWRlcmVkIHRvIG1lZXQgY3VycmVudCBzZWN1cml0eSByZXF1 aXJlbWVudHMuPGJyPg0KPGJyPg0KSW4gUkZDNTAzNiAocHVibGlzaGVkIDIwMDcpIFNlY3Rpb24g NS4xIChTcG9vZmluZykgLCBMaXN0IGVsZW1lbnQgMi4gU2Vzc2lvbiBjb21tdW5pY2F0aW9uIGNh cnJpZWQgYnkgVENQIHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50cyBpcyBtYWRlOjxicj4NCjxicj4N CiZxdW90O0xEUCBzcGVjaWZpZXMgdXNlIG9mIHRoZSBUQ1AgTUQ1IFNpZ25hdHVyZSBPcHRpb24g dG8gcHJvdmlkZSBmb3IgdGhlIGF1dGhlbnRpY2l0eSBhbmQgaW50ZWdyaXR5IG9mIHNlc3Npb24g bWVzc2FnZXMuPGJyPg0KPGJyPg0KJnF1b3Q7W1JGQzIzODVdIGFzc2VydHMgdGhhdCBNRDUgYXV0 aGVudGljYXRpb24gaXMgbm93IGNvbnNpZGVyZWQgYnkgc29tZSB0byBiZSB0b28gd2VhayBmb3Ig dGhpcyBhcHBsaWNhdGlvbi4mbmJzcDsgSXQgYWxzbyBwb2ludHMgb3V0IHRoYXQgYSBzaW1pbGFy IFRDUCBvcHRpb24gd2l0aCBhIHN0cm9uZ2VyIGhhc2hpbmcgYWxnb3JpdGhtIChpdCBjaXRlcyBT SEEtMSBhcyBhbiBleGFtcGxlKSBjb3VsZCBiZSBkZXBsb3llZC4mbmJzcDsgVG8gb3VyIGtub3ds ZWRnZSwgbm8NCiBzdWNoIFRDUCBvcHRpb24gaGFzIGJlZW4gZGVmaW5lZCBhbmQgZGVwbG95ZWQu Jm5ic3A7IEhvd2V2ZXIsIHdlIG5vdGUgdGhhdCBMRFAgY2FuIHVzZSB3aGF0ZXZlciBUQ1AgbWVz c2FnZSBkaWdlc3QgdGVjaG5pcXVlcyBhcmUgYXZhaWxhYmxlLCBhbmQgd2hlbiBvbmUgc3Ryb25n ZXIgdGhhbiBNRDUgaXMgc3BlY2lmaWVkIGFuZCBpbXBsZW1lbnRlZCwgdXBncmFkaW5nIExEUCB0 byB1c2UgaXQgd291bGQgYmUgcmVsYXRpdmVseSBzdHJhaWdodGZvcndhcmQuJnF1b3Q7PGJyPg0K PGJyPg0KV2Ugbm90ZSB0aGF0IEJHUCBoYXMgYWxyZWFkeSBiZWVuIHRocm91Z2ggdGhpcyBwcm9j ZXNzLCBhbmQgcmVwbGFjZWQgTUQ1IHdpdGggVENQLUFPIGluIFJGQyA3NDU0LiBJIHdvdWxkIGJl IGxvZ2ljYWwgdG8gZm9sbG93IHRoZSBzYW1lIGFwcHJvYWNoIHRvIHNlY3VyZSBMRFAuIEhvd2V2 ZXIsIGFzIGZhciBhcyB3ZSBhcmUgYWJsZSB0byBhc2NlcnRhaW4sIHRoZXJlIGlzIGN1cnJlbnRs eSBubyByZWNvbW1lbmRlZCwgbWFuZGF0b3J5IHRvIGltcGxlbWVudCwNCiBjcnlwdG9ncmFwaGlj IGZ1bmN0aW9uIHNwZWNpZmllZC4gV2UgYXJlIGNvbmNlcm5lZCB0aGF0IHdpdGhvdXQgc3VjaCBh IG1hbmRhdG9yeSBmdW5jdGlvbiwgaW1wbGVtZW50YXRpb25zIHdpbGwgc2ltcGx5IGZhbGwgYmFj ayB0byBNRDUgYW5kIHdlIHdpbGwgYmUgbm8gZnVydGhlciBmb3J3YXJkPGJyPg0KPGJyPg0KV2Ug dGhpbmsgdGhhdCB0aGUgYmVzdCB3YXkgZm9yd2FyZCBpcyB0byBwdWJsaXNoIGEgZHJhZnQgc2lt aWxhciB0byBSRkMgNzQ1NCB0aGF0IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgcmVxdWlyZW1lbnQ6 PGJyPg0KPGJyPg0KJnF1b3Q7SW1wbGVtZW50YXRpb25zIGNvbmZvcm1pbmcgdG8gdGhpcyBSRkMg TVVTVCBpbXBsZW1lbnQgVENQLUFPIHRvIHNlY3VyZSB0aGUgVENQIHNlc3Npb25zIGNhcnJ5aW5n IExEUCBpbiBhZGRpdGlvbiB0byB0aGUgY3VycmVudGx5IHJlcXVpcmVkIFRDUCBNRDUgU2lnbmF0 dXJlIE9wdGlvbi4gRnVydGhlcm1vcmUsIHRoZSBUQkQgY3J5cHRvZ3JhcGhpYyBtZWNoYW5pc20g bXVzdCBiZSBpbXBsZW1lbnRlZCBhbmQgcHJvdmlkZWQgdG8gVENQLUFPIHRvDQogc2VjdXJlIExE UCBtZXNzYWdlcy4gVGhlIFRCRCBtZWNoYW5pc20gaXMgdGhlIHByZWZlcnJlZCBvcHRpb24sIGFu ZCBNRDUgaXMgb25seSB0byBiZSB1c2VkIHdoZW4gVEJEIGlzIHVuYXZhaWxhYmxlLiZxdW90Ozxi cj4NCjxicj4NCldlIGFyZSBub3QgYW4gZXhwZXJ0cyBvbiB0aGlzIHBhcnQgb2YgdGhlIHN0YWNr LCBidXQgaXQgc2VlbXMgdGhhdCBUQ1Agc2VjdXJpdHkgbmVnb3RpYXRpb24gaXMgc3RpbGwgd29y ayBpbiBwcm9ncmVzcy4gSWYgd2UgYXJlIHdyb25nLCB0aGVuIHdlIG5lZWQgdG8gaW5jbHVkZSBh IHJlcXVpcmVtZW50IHRoYXQgc3VjaCBuZWdvdGlhdGlvbiBpcyBhbHNvIHJlcXVpcmVkLiBJbiB0 aGUgYWJzZW5jZSBvZiBhIG5lZ290aWF0aW9uIHByb3RvY29sLCBob3dldmVyLA0KIHdlIG5lZWQg dG8gbGVhdmUgdGhpcyBhcyBhIGNvbmZpZ3VyYXRpb24gcHJvY2VzcyB1bnRpbCBzdWNoIHRpbWUg YXMgdGhlIG5lZ290aWF0aW9uIHByb3RvY29sIHdvcmsgaXMgY29tcGxldGUuIE9uIGNvbXBsZXRp b24gb2YgYSBzdWl0YWJsZSBuZWdvdGlhdGlvbiBwcm90b2NvbCB3ZSBuZWVkIHRvIGlzc3VlIGEg ZnVydGhlciB1cGRhdGUgcmVxdWlyaW5nIGl0cyB1c2UuPGJyPg0KPGJyPg0KQWRkaXRpb25hbGx5 IHdlIHNob3VsZCBub3RlIHRoYXQgbm8gY3J5cHRvZ3JhcGhpYyBtZWNoYW5pc20gaGFzIGFuIGlu ZGVmaW5pdGUgbGlmZXRpbWUsIGFuZCB0aGF0IGltcGxlbWVudGF0aW9uIHNob3VsZCBub3RlIHRo ZSBJRVRGIGFudGljaXBhdGVzIHVwZGF0aW5nIHRoZSBkZWZhdWx0IGNyeXB0b2dyYXBoaWMgbWVj aGFuaXNtIG92ZXIgdGltZS48YnI+DQo8YnI+DQpUaGUgVEJEIGRlZmF1bHQgc2VjdXJpdHkgZnVu Y3Rpb24gd2lsbCBuZWVkIHRvIGJlIGNob3NlbiBzdWNoIHRoYXQgaXQgY2FuIHJlYXNvbmFibHkg YmUgaW1wbGVtZW50ZWQgb24gYSB0eXBpY2FsIHJvdXRlciByb3V0ZSBwcm9jZXNzb3IsIGFuZCB3 aGljaCB3aWxsIHByb3ZpZGUgYWRlcXVhdGUgc2VjdXJpdHkgd2l0aG91dCBzaWduaWZpY2FudGx5 IGRlZ3JhZGluZyB0aGUgY29udmVyZ2VuY2UgdGltZSBvZiBhbiBMU1IuIFdpdGhvdXQgYSBmdW5j dGlvbg0KIHRoYXQgZG9lcyBub3Qgc2lnbmlmaWNhbnRseSBpbXBhY3Qgcm91dGVyIGNvbnZlcmdl bmNlIHdlIHNpbXBseSBjbG9zZSBvbmUgdnVsbmVyYWJpbGl0eSBhbmQgb3BlbiBhbm90aGVyLjxi cj4NCjxicj4NCkFzIGV4cGVydHMgb24gdGhlIExEUCBwcm90b2NvbCwgYnV0IG5vdCBvbiBzZWN1 cml0eSBtZWNoYW5pc21zLCB3ZSZuYnNwOyBuZWVkIHRvIGFzayB0aGUgc2VjdXJpdHkgYXJlYSBm b3IgYSByZXZpZXcgb2Ygb3VyIHByb3Bvc2VkIGFwcHJvYWNoLCBhbmQgaGVscCBjb3JyZWN0aW5n IGFueSBtaXN1bmRlcnN0YW5kaW5nIG9mIHRoZSBzZWN1cml0eSBpc3N1ZXMgb3Igb3VyIG1pc3Vu ZGVyc3RhbmRpbmcgb2YgdGhlIGV4aXN0aW5nIHNlY3VyaXR5IG1lY2hhbmlzbXMuDQogV2UgYWxz byBuZWVkIHRoZSByZWNvbW1lbmRhdGlvbnMgb2YgYSBzdWl0YWJsZSBzZWN1cml0eSBmdW5jdGlv biAoVEJEIGluIHRoZSBhYm92ZSB0ZXh0KS48YnI+DQo8YnI+DQpCZXN0IHJlZ2FyZHM8YnI+DQo8 YnI+DQpUaGUgTVBMUyBXRyBDaGFpcnM8YnI+DQpUaGUgUEFMUyBXRyBDaGFpcnM8bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_25B4902B1192E84696414485F5726854135191D6sjceml521mbschi_-- From nobody Wed Nov 8 15:53:38 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA3512940C for ; Wed, 8 Nov 2017 15:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 RaAjxB2pKoIR for ; Wed, 8 Nov 2017 15:53:32 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95FC41293D9 for ; Wed, 8 Nov 2017 15:53:32 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id y75so3864029ywg.0 for ; Wed, 08 Nov 2017 15:53:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mFYOAp+rok1qpmu9Yq9yAnrv6yGbPtzYyR3j2gLzdqc=; b=ESjhLt6U2u9J+vs4ioIZKR4qOoUeMlIjVEq+7I/99r3/2hn2aOfeM1o3i4tuKuvMlY 5paSZp2ZA7dhGAjtUo7sxri6+YR9UX7uO7DnAMO/kDLMiehGqH2bm7+2wrGN2zQ4hkrf 272LCj5Rb4ChiSiPRUhrSvJLry+M08qujoMniTnrHQPy9LwgcmA83HrSLEFwaO/t50pt qhwLZ/yQopBTJcC0xnrH70dT+d5DmwMopEQxME/no/cZl1To5eqwORufGykBOO1D1JRj YMfxXB8WZyVBBpVTayQwn57POdEugKYTuxeijbdqcuHbGj1sdtKL37P7WqchAm75ahv6 sdFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mFYOAp+rok1qpmu9Yq9yAnrv6yGbPtzYyR3j2gLzdqc=; b=oOVUyl0a8/JSsuS0+0C6xj+ORqJci2J/Ydt9kSd/aiACZU/IrSmutosPstpCVVhoTu iaO2J/7v1cI8k1+AxQz5SPZSKV7UG/EIO2aHV9ZKH6lKvsPHn8zcKXlncvOJyD01ulR1 kWHT4Qkp874HYW5jmY4JXED2inUpbrsoxsLZu1KJ/B6tYZMzj/ooKyPQ93PpaYfXHJ5F dneTGR4LiFLXYMD9LvbGLCdQ/CUwAyqJJsvrKa+3FicjDaEc3AyM1LpAXNV/U4z52ekI QL4w3Sba9ZTG1AaEQD2yXQP+30IH14JT6C3sES+NFBkRzR1y6xDkkY2MLG0RbE9RLUny lMWQ== X-Gm-Message-State: AJaThX6/IBlkjZnpGFB5IkgPHUgHvX9+FinwFSQhfXzkAYlvevn9SlQH GNOXeUxS7r+EjGRwqi0Nl0wFB0n8G6kRxQIE3JoCxw== X-Google-Smtp-Source: ABhQp+R9ssLrhxcC2h62b8461lcTqYasZe1dUOih7yDwpX6rAdNHJ+uWcLLt3lWUiNrKD1GTqwt8z2/VYyD5WFJMJkc= X-Received: by 10.37.22.8 with SMTP id 8mr1516708ybw.353.1510185211641; Wed, 08 Nov 2017 15:53:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Wed, 8 Nov 2017 15:52:51 -0800 (PST) In-Reply-To: <25B4902B1192E84696414485F5726854135191D6@sjceml521-mbs.china.huawei.com> References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <5994f353-5306-0fa8-2d2d-024ebdbb10df@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> <25B4902B1192E84696414485F57268541351915D@sjceml521-mbs.china.huawei.com> <25B4902B1192E84696414485F5726854135191D6@sjceml521-mbs.china.huawei.com> From: Eric Rescorla Date: Wed, 8 Nov 2017 15:52:51 -0800 Message-ID: To: Uma Chunduri Cc: Stewart Bryant , "mpls@ietf.org" , "pals-chairs@tools.ietf.org" , "" , "mpls-chairs@ietf.org" , "pals@ietf.org" , "" Content-Type: multipart/alternative; boundary="001a1141671815d758055d8165b4" Archived-At: Subject: Re: [Pals] [mpls] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 23:53:36 -0000 --001a1141671815d758055d8165b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 8, 2017 at 3:50 PM, Uma Chunduri wrote: > In-line [Uma1]: > > -- > > Uma C. > > > > *From:* Eric Rescorla [mailto:ekr@rtfm.com] > *Sent:* Wednesday, November 08, 2017 12:53 PM > *To:* Uma Chunduri > *Cc:* Stewart Bryant ; mpls@ietf.org; > pals-chairs@tools.ietf.org; ; > mpls-chairs@ietf.org; pals@ietf.org; > > *Subject:* Re: [mpls] LDP Security > > > > > > > > On Wed, Nov 8, 2017 at 11:57 AM, Uma Chunduri > wrote: > > Hi Stewart, > > > > I would note https://tools.ietf.org/html/rfc6952 - where LDP security is > analyzed from all aspects. > > > > Eric, > > > > Quick comments below [Uma]: > > > > -- > > Uma C. > > > > *From:* mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Eric Rescorla > *Sent:* Wednesday, November 08, 2017 10:00 AM > *To:* Stewart Bryant > *Cc:* mpls@ietf.org; pals-chairs@tools.ietf.org; < > rtg-ads@ietf.org>; mpls-chairs@ietf.org; pals@ietf.org; > > *Subject:* Re: [mpls] LDP Security > > > > Hi Stewart > > > > Thanks for your note. > > > > My overall sense of the state of play is, I think much like yours. > > > > TCP-MD5 is inadequate in two major respects: > > - It uses weak algorithms > > - It has a bad negotiation/setuop story (manual key management) > > > > TCP-AO is intended to be a drop-in replacement for TCP-MD5 and so remedie= s > the algorithm > > Issue > > > > [Uma]: Yes, if we go with RFC 5926 mandatory list.. > > > > but not the key management issue [0]. We haven't made much progress on th= e > key > > management story, and that seems to be a major impediment to deploying > either of these > > technologies (which I am given to understand don't see a lot of use). > > > > [Uma]: True. > > But I would indicate some effort done few years back > regarding key management for pair wise routing protocols (BGP, LDP, PCEP, > MSDP ..). > > One such proposal is by extending IKEv2 to negotiate TCP-A= O > MKTs (which can give rekey & algo. agility) - https://tools.ietf.org/html= / > draft-mahesh-karp-rkmp-05 > > This also requires some more work with TCP-AO; me & Joe pu= t > together https://www.ietf.org/archive/id/draft-chunduri-karp-using- > ikev2-with-tcp-ao-06.txt > > Note the above didn=E2=80=99t progress in the concluded KARP W= G (not > fully sure the reasons on why). > > > > Yeah, I know that people tried to do this, but my impression was it kinda > didn't progress much. > > > > > > > > We should probably talk in Singapore about that, but that's not going to > get better any time soon. > > > > In the interim, I think the text you have is OK, and "TBD" should read > "SHA-256", with > > the fallback being SHA-256 -> SHA-1 -> MD5. > > > > [Uma]: While the list can be extended - I didn=E2=80=99t see SHA256 in th= e > mandatory list in RFC 5926 for MAC. > > > > Generally we're trying to move away from SHA-1 towards SHA-256. > > > > [Uma1]: Couple of things: > > 1. *Nothing to be done (from spec pov of course):* Use TCP-AO > (instead of current MD5) with the RFC 5926 mandated MACs/KDFs =E2=80=93 s= o the > =E2=80=98TBD=E2=80=99 in Stewart suggesting below is already there. > > 2. As #1 too is not good enough from your above note - do SHA-256 > and live with it (no algorithm agility). Still a security benefit in one > way from existing stuff or even #1. > I'm not sure why you say "no algorithm agility". You'd be using AO, just with a different algorithm than SHA-1. AES-CMAC is still fine as far as I know. -Ekr > 3. Do key management and =E2=80=9Ctheoretically=E2=80=9D get all we= wanted=E2=80=A6. > > > > We have been here multiple times; because #1 itself is not **mostly** > deployed (neither in BGP nor in LDP) if there is any appetite for #2 and = #3 > for practical deployments. But still it may be good to do #2 any ways. > > > > > > -Ekr > > > > > > -Ekr > > > > > > [0] Technically It has better support for rollover, but this is not a hug= e > improvement. > > [1] tcpcrypt is kind of orthogonal here as it's unauthenticated but > opportunistic. That said, > > it would provide defense against attackers who gain access to the link > after connection > > setup and doesn't require configuration. > > > > On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant > wrote: > > To the SEC and RTG ADs, > > I am sending the following message on behalf of the MPLS and the > PALS WG Chairs. > > There is a concern shared among the security community and the working > groups that develop the LDP protocol that LDP is no longer adequately > secured. LDP currently relies on MD5 for cryptographic security of its > messages, but MD5 is a hash function that is no longer considered to meet > current security requirements. > > In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2. > Session communication carried by TCP the following statements is made: > > "LDP specifies use of the TCP MD5 Signature Option to provide for the > authenticity and integrity of session messages. > > "[RFC2385] asserts that MD5 authentication is now considered by some to b= e > too weak for this application. It also points out that a similar TCP > option with a stronger hashing algorithm (it cites SHA-1 as an example) > could be deployed. To our knowledge, no such TCP option has been defined > and deployed. However, we note that LDP can use whatever TCP message > digest techniques are available, and when one stronger than MD5 is > specified and implemented, upgrading LDP to use it would be relatively > straightforward." > > We note that BGP has already been through this process, and replaced MD5 > with TCP-AO in RFC 7454. I would be logical to follow the same approach t= o > secure LDP. However, as far as we are able to ascertain, there is current= ly > no recommended, mandatory to implement, cryptographic function specified. > We are concerned that without such a mandatory function, implementations > will simply fall back to MD5 and we will be no further forward > > We think that the best way forward is to publish a draft similar to RFC > 7454 that contains the following requirement: > > "Implementations conforming to this RFC MUST implement TCP-AO to secure > the TCP sessions carrying LDP in addition to the currently required TCP M= D5 > Signature Option. Furthermore, the TBD cryptographic mechanism must be > implemented and provided to TCP-AO to secure LDP messages. The TBD > mechanism is the preferred option, and MD5 is only to be used when TBD is > unavailable." > > We are not an experts on this part of the stack, but it seems that TCP > security negotiation is still work in progress. If we are wrong, then we > need to include a requirement that such negotiation is also required. In > the absence of a negotiation protocol, however, we need to leave this as = a > configuration process until such time as the negotiation protocol work is > complete. On completion of a suitable negotiation protocol we need to iss= ue > a further update requiring its use. > > Additionally we should note that no cryptographic mechanism has an > indefinite lifetime, and that implementation should note the IETF > anticipates updating the default cryptographic mechanism over time. > > The TBD default security function will need to be chosen such that it can > reasonably be implemented on a typical router route processor, and which > will provide adequate security without significantly degrading the > convergence time of an LSR. Without a function that does not significantl= y > impact router convergence we simply close one vulnerability and open > another. > > As experts on the LDP protocol, but not on security mechanisms, we need > to ask the security area for a review of our proposed approach, and help > correcting any misunderstanding of the security issues or our > misunderstanding of the existing security mechanisms. We also need the > recommendations of a suitable security function (TBD in the above text). > > Best regards > > The MPLS WG Chairs > The PALS WG Chairs > > > > > --001a1141671815d758055d8165b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 8, 2017 at 3:50 PM, Uma Chunduri <uma.chunduri@huawe= i.com> wrote:

In-line [Uma1]:

--<= /span>

Uma C.

=C2=A0

From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Wednesday, November 08, 2017 12:53 PM
To: Uma Chunduri <uma.chunduri@huawei.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>; mpls@ietf.org; pals-chairs@tools.ietf.org; <rtg-ads@ietf.org> = <rtg-ads@ietf.org<= /a>>; mpls-cha= irs@ietf.org; pals@i= etf.org; <sec-= ads@ietf.org> <sec-ads@ietf.org>


Subject: Re: [mpls] LDP Security

=C2=A0

=C2=A0

=C2=A0

On Wed, Nov 8, 2017 at 11:57 AM, Uma Chunduri <uma.chunduri@hua= wei.com> wrote:

Hi Stewart,

=C2=A0

I would note h= ttps://tools.ietf.org/html/rfc6952 - where LDP security is analyzed from all aspects.

=C2=A0

Eric,

=C2=A0

Quick comments below [Uma]:=

=C2=A0

--

Uma C.

=C2=A0

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Wednesday, November 08, 2017 10:00 AM
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: mpls@ietf.org= ; pals-chairs@tools.ietf.org; <rtg-ads@ietf.org> <rtg-ads@ietf.org>; mpls-chairs@ietf.= org; pals@ietf.org; <sec-ads@ietf.org> <sec-ads@ietf.org>
Subject: Re: [mpls] LDP Security

=C2=A0

Hi Stewart

=C2=A0

Thanks for your note.

=C2=A0

My overall sense of the state of play is, I think mu= ch like yours.

=C2=A0

TCP-MD5 is inadequate in two major respects:<= u>

- It uses weak algorithms

- It has a bad negotiation/setuop story (manual key = management)

=C2=A0

TCP-AO is intended to be a drop-in replacement for T= CP-MD5 and so remedies the algorithm

Issue

=C2=A0

[Uma]: Yes, if we go with RFC 5926 ma= ndatory list..

=C2=A0

but not the key management issue [0]. We haven't= made much progress on the key

management story, and that seems to be a major imped= iment to deploying either of these

technologies (which I am given to understand don'= ;t see a lot of use).

=C2=A0

[Uma]: True.

=C2=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=A0But I would indicate = some effort done few years back regarding key management for pair wise routing protocols (BGP, LDP, PCEP, MSDP ..).

=C2=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=A0One such proposal is = by extending IKEv2 to negotiate TCP-AO MKTs (which can give rekey & algo. agility) - https://tools.ietf.org/html/dr= aft-mahesh-karp-rkmp-05=C2=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=A0This also requires so= me more work with TCP-AO; me & Joe put together https://www.ietf.org/archive/<= wbr>id/draft-chunduri-karp-using-ikev2-with-tcp-ao-06.txt

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0Note the above didn=E2=80=99t progress in the= concluded KARP WG (not fully sure the reasons on why).

=C2=A0

Yeah, I know that people tried to do this, but my im= pression was it kinda didn't progress much.

=C2=A0

=C2=A0

=C2=A0

We should probably talk in Singapore about that, but that's not going to get better= any time soon.

=C2=A0

In the interim, I think the text you have is OK, and= "TBD" should read "SHA-256", with

the fallback being SHA-256 -> SHA-1 -> MD5.=

=C2=A0

[Uma]: While the list can be extended= - I didn=E2=80=99t see SHA256 in the mandatory list in RFC 5926 for MAC.

=C2=A0

Generally we're trying to move away from SHA-1 t= owards SHA-256.

=C2=A0

[Uma1]: Couple of things:=

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Nothing to be done (from spec= pov of course): Use TCP-AO (instead of current MD5) with the RFC 5926 mandated MACs/KDFs =E2=80=93 so= the =E2=80=98TBD=E2=80=99 in Stewart suggesting below is already there.

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 As #1 too is not good enough fro= m your above note - do SHA-256 and live with it (no algorithm agility). Sti= ll a security benefit in one way from existing stuff or even =C2=A0#1.

I'm not sure why you say "no algorithm agility"= . You'd be using AO, just with a different algorithm than SHA-1. AES-CM= AC is still fine as far as I know.

-Ekr
= =C2=A0

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Do key management and =E2=80=9Ct= heoretically=E2=80=9D get all we wanted=E2=80=A6.

=C2=A0

We have been here multiple times; bec= ause #1 itself is not *mostly* deployed (neither in BGP nor in LDP) = if there is any appetite for #2 and #3 for practical deployments. But still it may be good to do #2 any ways.

=C2=A0

=C2=A0

-Ekr

=C2=A0

=C2=A0

-Ekr

=C2=A0

=C2=A0

[0] Technically It has better support for rollover, = but this is not a huge improvement.

[1] tcpcrypt is kind of orthogonal here as it's = unauthenticated but opportunistic.=C2=A0 That said,

it would provide defense against attackers who gain = access to the link after connection

setup and doesn't require configuration.<= u>

=C2=A0

On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant <<= a href=3D"mailto:stewart.bryant@gmail.com" target=3D"_blank">stewart.bryant= @gmail.com> wrote:

To the SEC and RTG AD= s,

I am sending the following message on behalf of the MPLS and the
PALS WG Chairs.

There is a concern shared among the security community and the working grou= ps that develop the LDP protocol that LDP is no longer adequately secured. = LDP currently relies on MD5 for cryptographic security of its messages, but= MD5 is a hash function that is no longer considered to meet current security requirements.

In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2. Sessio= n communication carried by TCP the following statements is made:

"LDP specifies use of the TCP MD5 Signature Option to provide for the = authenticity and integrity of session messages.

"[RFC2385] asserts that MD5 authentication is now considered by some t= o be too weak for this application.=C2=A0 It also points out that a similar= TCP option with a stronger hashing algorithm (it cites SHA-1 as an example= ) could be deployed.=C2=A0 To our knowledge, no such TCP option has been defined and deployed.=C2=A0 However, we note that= LDP can use whatever TCP message digest techniques are available, and when= one stronger than MD5 is specified and implemented, upgrading LDP to use i= t would be relatively straightforward."

We note that BGP has already been through this process, and replaced MD5 wi= th TCP-AO in RFC 7454. I would be logical to follow the same approach to se= cure LDP. However, as far as we are able to ascertain, there is currently n= o recommended, mandatory to implement, cryptographic function specified. We are concerned that without such a man= datory function, implementations will simply fall back to MD5 and we will b= e no further forward

We think that the best way forward is to publish a draft similar to RFC 745= 4 that contains the following requirement:

"Implementations conforming to this RFC MUST implement TCP-AO to secur= e the TCP sessions carrying LDP in addition to the currently required TCP M= D5 Signature Option. Furthermore, the TBD cryptographic mechanism must be i= mplemented and provided to TCP-AO to secure LDP messages. The TBD mechanism is the preferred option, and MD5 is= only to be used when TBD is unavailable."

We are not an experts on this part of the stack, but it seems that TCP secu= rity negotiation is still work in progress. If we are wrong, then we need t= o include a requirement that such negotiation is also required. In the abse= nce of a negotiation protocol, however, we need to leave this as a configuration process until such time as the ne= gotiation protocol work is complete. On completion of a suitable negotiatio= n protocol we need to issue a further update requiring its use.

Additionally we should note that no cryptographic mechanism has an indefini= te lifetime, and that implementation should note the IETF anticipates updat= ing the default cryptographic mechanism over time.

The TBD default security function will need to be chosen such that it can r= easonably be implemented on a typical router route processor, and which wil= l provide adequate security without significantly degrading the convergence= time of an LSR. Without a function that does not significantly impact router convergence we simply close one = vulnerability and open another.

As experts on the LDP protocol, but not on security mechanisms, we=C2=A0 ne= ed to ask the security area for a review of our proposed approach, and help= correcting any misunderstanding of the security issues or our misunderstan= ding of the existing security mechanisms. We also need the recommendations of a suitable security function (TBD in t= he above text).

Best regards

The MPLS WG Chairs
The PALS WG Chairs

=C2=A0

=C2=A0


--001a1141671815d758055d8165b4-- From nobody Wed Nov 8 16:14:36 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D839612778E; Wed, 8 Nov 2017 16:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVitposHkGFL; Wed, 8 Nov 2017 16:14:25 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F049129418; Wed, 8 Nov 2017 16:14:22 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DZK79517; Thu, 09 Nov 2017 00:14:20 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 9 Nov 2017 00:14:19 +0000 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.92]) by SJCEML703-CHM.china.huawei.com ([169.254.5.27]) with mapi id 14.03.0361.001; Wed, 8 Nov 2017 16:14:13 -0800 From: Uma Chunduri To: Eric Rescorla CC: Stewart Bryant , "mpls@ietf.org" , "pals-chairs@tools.ietf.org" , "" , "mpls-chairs@ietf.org" , "pals@ietf.org" , "" Thread-Topic: [mpls] LDP Security Thread-Index: AQHTWLbyOfMae53/m0ycVXrEQ0bS1aMLS2UA//+SrUCAAJ2kAP//pwtQgACLTYD//3zyYA== Date: Thu, 9 Nov 2017 00:14:12 +0000 Message-ID: <25B4902B1192E84696414485F572685413519209@sjceml521-mbs.china.huawei.com> References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <5994f353-5306-0fa8-2d2d-024ebdbb10df@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> <25B4902B1192E84696414485F57268541351915D@sjceml521-mbs.china.huawei.com> <25B4902B1192E84696414485F5726854135191D6@sjceml521-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.168] Content-Type: multipart/alternative; boundary="_000_25B4902B1192E84696414485F572685413519209sjceml521mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5A039DDD.00C2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.92, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 14d312b36b9605c70916f063eabc04c2 Archived-At: Subject: Re: [Pals] [mpls] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 00:14:28 -0000 --_000_25B4902B1192E84696414485F572685413519209sjceml521mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogRXJpYyBSZXNjb3JsYSBbbWFpbHRvOmVrckBydGZtLmNvbV0NClNlbnQ6IFdlZG5lc2Rh eSwgTm92ZW1iZXIgMDgsIDIwMTcgMzo1MyBQTQ0KVG86IFVtYSBDaHVuZHVyaSA8dW1hLmNodW5k dXJpQGh1YXdlaS5jb20+DQpDYzogU3Rld2FydCBCcnlhbnQgPHN0ZXdhcnQuYnJ5YW50QGdtYWls LmNvbT47IG1wbHNAaWV0Zi5vcmc7IHBhbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyA8cnRnLWFk c0BpZXRmLm9yZz4gPHJ0Zy1hZHNAaWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0BpZXRmLm9yZzsgcGFs c0BpZXRmLm9yZzsgPHNlYy1hZHNAaWV0Zi5vcmc+IDxzZWMtYWRzQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFttcGxzXSBMRFAgU2VjdXJpdHkNCg0KDQoNCk9uIFdlZCwgTm92IDgsIDIwMTcgYXQg Mzo1MCBQTSwgVW1hIENodW5kdXJpIDx1bWEuY2h1bmR1cmlAaHVhd2VpLmNvbTxtYWlsdG86dW1h LmNodW5kdXJpQGh1YXdlaS5jb20+PiB3cm90ZToNCkluLWxpbmUgW1VtYTFdOg0KLS0NClVtYSBD Lg0KDQpGcm9tOiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JA cnRmbS5jb20+XQ0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAwOCwgMjAxNyAxMjo1MyBQTQ0K VG86IFVtYSBDaHVuZHVyaSA8dW1hLmNodW5kdXJpQGh1YXdlaS5jb208bWFpbHRvOnVtYS5jaHVu ZHVyaUBodWF3ZWkuY29tPj4NCkNjOiBTdGV3YXJ0IEJyeWFudCA8c3Rld2FydC5icnlhbnRAZ21h aWwuY29tPG1haWx0bzpzdGV3YXJ0LmJyeWFudEBnbWFpbC5jb20+PjsgbXBsc0BpZXRmLm9yZzxt YWlsdG86bXBsc0BpZXRmLm9yZz47IHBhbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzpw YWxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz47IDxydGctYWRzQGlldGYub3JnPG1haWx0bzpydGct YWRzQGlldGYub3JnPj4gPHJ0Zy1hZHNAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1hZHNAaWV0Zi5vcmc+ PjsgbXBscy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQGlldGYub3JnPjsgcGFs c0BpZXRmLm9yZzxtYWlsdG86cGFsc0BpZXRmLm9yZz47IDxzZWMtYWRzQGlldGYub3JnPG1haWx0 bzpzZWMtYWRzQGlldGYub3JnPj4gPHNlYy1hZHNAaWV0Zi5vcmc8bWFpbHRvOnNlYy1hZHNAaWV0 Zi5vcmc+Pg0KDQpTdWJqZWN0OiBSZTogW21wbHNdIExEUCBTZWN1cml0eQ0KDQoNCg0KT24gV2Vk LCBOb3YgOCwgMjAxNyBhdCAxMTo1NyBBTSwgVW1hIENodW5kdXJpIDx1bWEuY2h1bmR1cmlAaHVh d2VpLmNvbTxtYWlsdG86dW1hLmNodW5kdXJpQGh1YXdlaS5jb20+PiB3cm90ZToNCkhpIFN0ZXdh cnQsDQoNCkkgd291bGQgbm90ZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjk1MiAt IHdoZXJlIExEUCBzZWN1cml0eSBpcyBhbmFseXplZCBmcm9tIGFsbCBhc3BlY3RzLg0KDQpFcmlj LA0KDQpRdWljayBjb21tZW50cyBiZWxvdyBbVW1hXToNCg0KLS0NClVtYSBDLg0KDQpGcm9tOiBt cGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptcGxzLWJvdW5jZXNAaWV0 Zi5vcmc+XSBPbiBCZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2VudDogV2VkbmVzZGF5LCBOb3Zl bWJlciAwOCwgMjAxNyAxMDowMCBBTQ0KVG86IFN0ZXdhcnQgQnJ5YW50IDxzdGV3YXJ0LmJyeWFu dEBnbWFpbC5jb208bWFpbHRvOnN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbT4+DQpDYzogbXBsc0Bp ZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz47IHBhbHMtY2hhaXJzQHRvb2xzLmlldGYub3Jn PG1haWx0bzpwYWxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz47IDxydGctYWRzQGlldGYub3JnPG1h aWx0bzpydGctYWRzQGlldGYub3JnPj4gPHJ0Zy1hZHNAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1hZHNA aWV0Zi5vcmc+PjsgbXBscy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQGlldGYu b3JnPjsgcGFsc0BpZXRmLm9yZzxtYWlsdG86cGFsc0BpZXRmLm9yZz47IDxzZWMtYWRzQGlldGYu b3JnPG1haWx0bzpzZWMtYWRzQGlldGYub3JnPj4gPHNlYy1hZHNAaWV0Zi5vcmc8bWFpbHRvOnNl Yy1hZHNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFttcGxzXSBMRFAgU2VjdXJpdHkNCg0KSGkg U3Rld2FydA0KDQpUaGFua3MgZm9yIHlvdXIgbm90ZS4NCg0KTXkgb3ZlcmFsbCBzZW5zZSBvZiB0 aGUgc3RhdGUgb2YgcGxheSBpcywgSSB0aGluayBtdWNoIGxpa2UgeW91cnMuDQoNClRDUC1NRDUg aXMgaW5hZGVxdWF0ZSBpbiB0d28gbWFqb3IgcmVzcGVjdHM6DQotIEl0IHVzZXMgd2VhayBhbGdv cml0aG1zDQotIEl0IGhhcyBhIGJhZCBuZWdvdGlhdGlvbi9zZXR1b3Agc3RvcnkgKG1hbnVhbCBr ZXkgbWFuYWdlbWVudCkNCg0KVENQLUFPIGlzIGludGVuZGVkIHRvIGJlIGEgZHJvcC1pbiByZXBs YWNlbWVudCBmb3IgVENQLU1ENSBhbmQgc28gcmVtZWRpZXMgdGhlIGFsZ29yaXRobQ0KSXNzdWUN Cg0KW1VtYV06IFllcywgaWYgd2UgZ28gd2l0aCBSRkMgNTkyNiBtYW5kYXRvcnkgbGlzdC4uDQoN CmJ1dCBub3QgdGhlIGtleSBtYW5hZ2VtZW50IGlzc3VlIFswXS4gV2UgaGF2ZW4ndCBtYWRlIG11 Y2ggcHJvZ3Jlc3Mgb24gdGhlIGtleQ0KbWFuYWdlbWVudCBzdG9yeSwgYW5kIHRoYXQgc2VlbXMg dG8gYmUgYSBtYWpvciBpbXBlZGltZW50IHRvIGRlcGxveWluZyBlaXRoZXIgb2YgdGhlc2UNCnRl Y2hub2xvZ2llcyAod2hpY2ggSSBhbSBnaXZlbiB0byB1bmRlcnN0YW5kIGRvbid0IHNlZSBhIGxv dCBvZiB1c2UpLg0KDQpbVW1hXTogVHJ1ZS4NCiAgICAgICAgICAgICAgIEJ1dCBJIHdvdWxkIGlu ZGljYXRlIHNvbWUgZWZmb3J0IGRvbmUgZmV3IHllYXJzIGJhY2sgcmVnYXJkaW5nIGtleSBtYW5h Z2VtZW50IGZvciBwYWlyIHdpc2Ugcm91dGluZyBwcm90b2NvbHMgKEJHUCwgTERQLCBQQ0VQLCBN U0RQIC4uKS4NCiAgICAgICAgICAgICAgIE9uZSBzdWNoIHByb3Bvc2FsIGlzIGJ5IGV4dGVuZGlu ZyBJS0V2MiB0byBuZWdvdGlhdGUgVENQLUFPIE1LVHMgKHdoaWNoIGNhbiBnaXZlIHJla2V5ICYg YWxnby4gYWdpbGl0eSkgLSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFoZXNo LWthcnAtcmttcC0wNQ0KICAgICAgICAgICAgICAgVGhpcyBhbHNvIHJlcXVpcmVzIHNvbWUgbW9y ZSB3b3JrIHdpdGggVENQLUFPOyBtZSAmIEpvZSBwdXQgdG9nZXRoZXIgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1jaHVuZHVyaS1rYXJwLXVzaW5nLWlrZXYyLXdpdGgtdGNw LWFvLTA2LnR4dA0KICAgICAgICAgICBOb3RlIHRoZSBhYm92ZSBkaWRu4oCZdCBwcm9ncmVzcyBp biB0aGUgY29uY2x1ZGVkIEtBUlAgV0cgKG5vdCBmdWxseSBzdXJlIHRoZSByZWFzb25zIG9uIHdo eSkuDQoNClllYWgsIEkga25vdyB0aGF0IHBlb3BsZSB0cmllZCB0byBkbyB0aGlzLCBidXQgbXkg aW1wcmVzc2lvbiB3YXMgaXQga2luZGEgZGlkbid0IHByb2dyZXNzIG11Y2guDQoNCg0KDQpXZSBz aG91bGQgcHJvYmFibHkgdGFsayBpbiBTaW5nYXBvcmUgYWJvdXQgdGhhdCwgYnV0IHRoYXQncyBu b3QgZ29pbmcgdG8gZ2V0IGJldHRlciBhbnkgdGltZSBzb29uLg0KDQpJbiB0aGUgaW50ZXJpbSwg SSB0aGluayB0aGUgdGV4dCB5b3UgaGF2ZSBpcyBPSywgYW5kICJUQkQiIHNob3VsZCByZWFkICJT SEEtMjU2Iiwgd2l0aA0KdGhlIGZhbGxiYWNrIGJlaW5nIFNIQS0yNTYgLT4gU0hBLTEgLT4gTUQ1 Lg0KDQpbVW1hXTogV2hpbGUgdGhlIGxpc3QgY2FuIGJlIGV4dGVuZGVkIC0gSSBkaWRu4oCZdCBz ZWUgU0hBMjU2IGluIHRoZSBtYW5kYXRvcnkgbGlzdCBpbiBSRkMgNTkyNiBmb3IgTUFDLg0KDQpH ZW5lcmFsbHkgd2UncmUgdHJ5aW5nIHRvIG1vdmUgYXdheSBmcm9tIFNIQS0xIHRvd2FyZHMgU0hB LTI1Ni4NCg0KW1VtYTFdOiBDb3VwbGUgb2YgdGhpbmdzOg0KDQoxLiAgICAgICBOb3RoaW5nIHRv IGJlIGRvbmUgKGZyb20gc3BlYyBwb3Ygb2YgY291cnNlKTogVXNlIFRDUC1BTyAoaW5zdGVhZCBv ZiBjdXJyZW50IE1ENSkgd2l0aCB0aGUgUkZDIDU5MjYgbWFuZGF0ZWQgTUFDcy9LREZzIOKAkyBz byB0aGUg4oCYVEJE4oCZIGluIFN0ZXdhcnQgc3VnZ2VzdGluZyBiZWxvdyBpcyBhbHJlYWR5IHRo ZXJlLg0KDQoyLiAgICAgICBBcyAjMSB0b28gaXMgbm90IGdvb2QgZW5vdWdoIGZyb20geW91ciBh Ym92ZSBub3RlIC0gZG8gU0hBLTI1NiBhbmQgbGl2ZSB3aXRoIGl0IChubyBhbGdvcml0aG0gYWdp bGl0eSkuIFN0aWxsIGEgc2VjdXJpdHkgYmVuZWZpdCBpbiBvbmUgd2F5IGZyb20gZXhpc3Rpbmcg c3R1ZmYgb3IgZXZlbiAgIzEuDQpJJ20gbm90IHN1cmUgd2h5IHlvdSBzYXkgIm5vIGFsZ29yaXRo bSBhZ2lsaXR5Ii4gWW91J2QgYmUgdXNpbmcgQU8sIGp1c3Qgd2l0aCBhIGRpZmZlcmVudCBhbGdv cml0aG0gdGhhbiBTSEEtMS4gQUVTLUNNQUMgaXMgc3RpbGwgZmluZSBhcyBmYXIgYXMgSSBrbm93 Lg0KW1VtYTJdOiBTdXJlLCB5b3UgaGF2ZSBpdCwgaWYgeW91IHVzZSBBTzsNCiAgICAgICAgICAg ICAgICAgQnV0IHRoZW4gIEkgYW0gbm90IGdldHRpbmcgaG93IHdlIGNhbiBtYW5kYXRlIG9uZSBN VVNUIGltcGxlbWVudCBhbGdvcml0aG0gYXMgc3VnZ2VzdGVkIGJlbG93IFRCRCAgd291bGQgYWN0 dWFsbHkgd29yayAgKGVzcGVjaWFsbHkgLSAqaWYqICMxIGlzIGFscmVhZHkgZGVwbG95ZWQgc29t ZXdoZXJlPykNCiAgICAgICAgICAgICAgICAgUGVyaGFwcyBzdGF5aW5nIHdpdGggIzEgaXMgdGhl IGJlc3QgYmV0IG9yIGRvIG5lZ290aWF0aW9uIHRocm91Z2ggIzMsIHdpdGggYWxyZWFkeSBtYW5k YXRlZCBhbmQgYWRkaXRpb25hbCBzdHVmZi4NCg0KLUVrcg0KDQoNCjMuICAgICAgIERvIGtleSBt YW5hZ2VtZW50IGFuZCDigJx0aGVvcmV0aWNhbGx54oCdIGdldCBhbGwgd2Ugd2FudGVk4oCmLg0K DQpXZSBoYXZlIGJlZW4gaGVyZSBtdWx0aXBsZSB0aW1lczsgYmVjYXVzZSAjMSBpdHNlbGYgaXMg bm90ICptb3N0bHkqIGRlcGxveWVkIChuZWl0aGVyIGluIEJHUCBub3IgaW4gTERQKSBpZiB0aGVy ZSBpcyBhbnkgYXBwZXRpdGUgZm9yICMyIGFuZCAjMyBmb3IgcHJhY3RpY2FsIGRlcGxveW1lbnRz LiBCdXQgc3RpbGwgaXQgbWF5IGJlIGdvb2QgdG8gZG8gIzIgYW55IHdheXMuDQoNCg0KLUVrcg0K DQoNCi1Fa3INCg0KDQpbMF0gVGVjaG5pY2FsbHkgSXQgaGFzIGJldHRlciBzdXBwb3J0IGZvciBy b2xsb3ZlciwgYnV0IHRoaXMgaXMgbm90IGEgaHVnZSBpbXByb3ZlbWVudC4NClsxXSB0Y3Bjcnlw dCBpcyBraW5kIG9mIG9ydGhvZ29uYWwgaGVyZSBhcyBpdCdzIHVuYXV0aGVudGljYXRlZCBidXQg b3Bwb3J0dW5pc3RpYy4gIFRoYXQgc2FpZCwNCml0IHdvdWxkIHByb3ZpZGUgZGVmZW5zZSBhZ2Fp bnN0IGF0dGFja2VycyB3aG8gZ2FpbiBhY2Nlc3MgdG8gdGhlIGxpbmsgYWZ0ZXIgY29ubmVjdGlv bg0Kc2V0dXAgYW5kIGRvZXNuJ3QgcmVxdWlyZSBjb25maWd1cmF0aW9uLg0KDQpPbiBXZWQsIE5v diA4LCAyMDE3IGF0IDk6MjcgQU0sIFN0ZXdhcnQgQnJ5YW50IDxzdGV3YXJ0LmJyeWFudEBnbWFp bC5jb208bWFpbHRvOnN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbT4+IHdyb3RlOg0KVG8gdGhlIFNF QyBhbmQgUlRHIEFEcywNCg0KSSBhbSBzZW5kaW5nIHRoZSBmb2xsb3dpbmcgbWVzc2FnZSBvbiBi ZWhhbGYgb2YgdGhlIE1QTFMgYW5kIHRoZQ0KUEFMUyBXRyBDaGFpcnMuDQoNClRoZXJlIGlzIGEg Y29uY2VybiBzaGFyZWQgYW1vbmcgdGhlIHNlY3VyaXR5IGNvbW11bml0eSBhbmQgdGhlIHdvcmtp bmcgZ3JvdXBzIHRoYXQgZGV2ZWxvcCB0aGUgTERQIHByb3RvY29sIHRoYXQgTERQIGlzIG5vIGxv bmdlciBhZGVxdWF0ZWx5IHNlY3VyZWQuIExEUCBjdXJyZW50bHkgcmVsaWVzIG9uIE1ENSBmb3Ig Y3J5cHRvZ3JhcGhpYyBzZWN1cml0eSBvZiBpdHMgbWVzc2FnZXMsIGJ1dCBNRDUgaXMgYSBoYXNo IGZ1bmN0aW9uIHRoYXQgaXMgbm8gbG9uZ2VyIGNvbnNpZGVyZWQgdG8gbWVldCBjdXJyZW50IHNl Y3VyaXR5IHJlcXVpcmVtZW50cy4NCg0KSW4gUkZDNTAzNiAocHVibGlzaGVkIDIwMDcpIFNlY3Rp b24gNS4xIChTcG9vZmluZykgLCBMaXN0IGVsZW1lbnQgMi4gU2Vzc2lvbiBjb21tdW5pY2F0aW9u IGNhcnJpZWQgYnkgVENQIHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50cyBpcyBtYWRlOg0KDQoiTERQ IHNwZWNpZmllcyB1c2Ugb2YgdGhlIFRDUCBNRDUgU2lnbmF0dXJlIE9wdGlvbiB0byBwcm92aWRl IGZvciB0aGUgYXV0aGVudGljaXR5IGFuZCBpbnRlZ3JpdHkgb2Ygc2Vzc2lvbiBtZXNzYWdlcy4N Cg0KIltSRkMyMzg1XSBhc3NlcnRzIHRoYXQgTUQ1IGF1dGhlbnRpY2F0aW9uIGlzIG5vdyBjb25z aWRlcmVkIGJ5IHNvbWUgdG8gYmUgdG9vIHdlYWsgZm9yIHRoaXMgYXBwbGljYXRpb24uICBJdCBh bHNvIHBvaW50cyBvdXQgdGhhdCBhIHNpbWlsYXIgVENQIG9wdGlvbiB3aXRoIGEgc3Ryb25nZXIg aGFzaGluZyBhbGdvcml0aG0gKGl0IGNpdGVzIFNIQS0xIGFzIGFuIGV4YW1wbGUpIGNvdWxkIGJl IGRlcGxveWVkLiAgVG8gb3VyIGtub3dsZWRnZSwgbm8gc3VjaCBUQ1Agb3B0aW9uIGhhcyBiZWVu IGRlZmluZWQgYW5kIGRlcGxveWVkLiAgSG93ZXZlciwgd2Ugbm90ZSB0aGF0IExEUCBjYW4gdXNl IHdoYXRldmVyIFRDUCBtZXNzYWdlIGRpZ2VzdCB0ZWNobmlxdWVzIGFyZSBhdmFpbGFibGUsIGFu ZCB3aGVuIG9uZSBzdHJvbmdlciB0aGFuIE1ENSBpcyBzcGVjaWZpZWQgYW5kIGltcGxlbWVudGVk LCB1cGdyYWRpbmcgTERQIHRvIHVzZSBpdCB3b3VsZCBiZSByZWxhdGl2ZWx5IHN0cmFpZ2h0Zm9y d2FyZC4iDQoNCldlIG5vdGUgdGhhdCBCR1AgaGFzIGFscmVhZHkgYmVlbiB0aHJvdWdoIHRoaXMg cHJvY2VzcywgYW5kIHJlcGxhY2VkIE1ENSB3aXRoIFRDUC1BTyBpbiBSRkMgNzQ1NC4gSSB3b3Vs ZCBiZSBsb2dpY2FsIHRvIGZvbGxvdyB0aGUgc2FtZSBhcHByb2FjaCB0byBzZWN1cmUgTERQLiBI b3dldmVyLCBhcyBmYXIgYXMgd2UgYXJlIGFibGUgdG8gYXNjZXJ0YWluLCB0aGVyZSBpcyBjdXJy ZW50bHkgbm8gcmVjb21tZW5kZWQsIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQsIGNyeXB0b2dyYXBo aWMgZnVuY3Rpb24gc3BlY2lmaWVkLiBXZSBhcmUgY29uY2VybmVkIHRoYXQgd2l0aG91dCBzdWNo IGEgbWFuZGF0b3J5IGZ1bmN0aW9uLCBpbXBsZW1lbnRhdGlvbnMgd2lsbCBzaW1wbHkgZmFsbCBi YWNrIHRvIE1ENSBhbmQgd2Ugd2lsbCBiZSBubyBmdXJ0aGVyIGZvcndhcmQNCg0KV2UgdGhpbmsg dGhhdCB0aGUgYmVzdCB3YXkgZm9yd2FyZCBpcyB0byBwdWJsaXNoIGEgZHJhZnQgc2ltaWxhciB0 byBSRkMgNzQ1NCB0aGF0IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgcmVxdWlyZW1lbnQ6DQoNCiJJ bXBsZW1lbnRhdGlvbnMgY29uZm9ybWluZyB0byB0aGlzIFJGQyBNVVNUIGltcGxlbWVudCBUQ1At QU8gdG8gc2VjdXJlIHRoZSBUQ1Agc2Vzc2lvbnMgY2FycnlpbmcgTERQIGluIGFkZGl0aW9uIHRv IHRoZSBjdXJyZW50bHkgcmVxdWlyZWQgVENQIE1ENSBTaWduYXR1cmUgT3B0aW9uLiBGdXJ0aGVy bW9yZSwgdGhlIFRCRCBjcnlwdG9ncmFwaGljIG1lY2hhbmlzbSBtdXN0IGJlIGltcGxlbWVudGVk IGFuZCBwcm92aWRlZCB0byBUQ1AtQU8gdG8gc2VjdXJlIExEUCBtZXNzYWdlcy4gVGhlIFRCRCBt ZWNoYW5pc20gaXMgdGhlIHByZWZlcnJlZCBvcHRpb24sIGFuZCBNRDUgaXMgb25seSB0byBiZSB1 c2VkIHdoZW4gVEJEIGlzIHVuYXZhaWxhYmxlLiINCg0KV2UgYXJlIG5vdCBhbiBleHBlcnRzIG9u IHRoaXMgcGFydCBvZiB0aGUgc3RhY2ssIGJ1dCBpdCBzZWVtcyB0aGF0IFRDUCBzZWN1cml0eSBu ZWdvdGlhdGlvbiBpcyBzdGlsbCB3b3JrIGluIHByb2dyZXNzLiBJZiB3ZSBhcmUgd3JvbmcsIHRo ZW4gd2UgbmVlZCB0byBpbmNsdWRlIGEgcmVxdWlyZW1lbnQgdGhhdCBzdWNoIG5lZ290aWF0aW9u IGlzIGFsc28gcmVxdWlyZWQuIEluIHRoZSBhYnNlbmNlIG9mIGEgbmVnb3RpYXRpb24gcHJvdG9j b2wsIGhvd2V2ZXIsIHdlIG5lZWQgdG8gbGVhdmUgdGhpcyBhcyBhIGNvbmZpZ3VyYXRpb24gcHJv Y2VzcyB1bnRpbCBzdWNoIHRpbWUgYXMgdGhlIG5lZ290aWF0aW9uIHByb3RvY29sIHdvcmsgaXMg Y29tcGxldGUuIE9uIGNvbXBsZXRpb24gb2YgYSBzdWl0YWJsZSBuZWdvdGlhdGlvbiBwcm90b2Nv bCB3ZSBuZWVkIHRvIGlzc3VlIGEgZnVydGhlciB1cGRhdGUgcmVxdWlyaW5nIGl0cyB1c2UuDQoN CkFkZGl0aW9uYWxseSB3ZSBzaG91bGQgbm90ZSB0aGF0IG5vIGNyeXB0b2dyYXBoaWMgbWVjaGFu aXNtIGhhcyBhbiBpbmRlZmluaXRlIGxpZmV0aW1lLCBhbmQgdGhhdCBpbXBsZW1lbnRhdGlvbiBz aG91bGQgbm90ZSB0aGUgSUVURiBhbnRpY2lwYXRlcyB1cGRhdGluZyB0aGUgZGVmYXVsdCBjcnlw dG9ncmFwaGljIG1lY2hhbmlzbSBvdmVyIHRpbWUuDQoNClRoZSBUQkQgZGVmYXVsdCBzZWN1cml0 eSBmdW5jdGlvbiB3aWxsIG5lZWQgdG8gYmUgY2hvc2VuIHN1Y2ggdGhhdCBpdCBjYW4gcmVhc29u YWJseSBiZSBpbXBsZW1lbnRlZCBvbiBhIHR5cGljYWwgcm91dGVyIHJvdXRlIHByb2Nlc3Nvciwg YW5kIHdoaWNoIHdpbGwgcHJvdmlkZSBhZGVxdWF0ZSBzZWN1cml0eSB3aXRob3V0IHNpZ25pZmlj YW50bHkgZGVncmFkaW5nIHRoZSBjb252ZXJnZW5jZSB0aW1lIG9mIGFuIExTUi4gV2l0aG91dCBh IGZ1bmN0aW9uIHRoYXQgZG9lcyBub3Qgc2lnbmlmaWNhbnRseSBpbXBhY3Qgcm91dGVyIGNvbnZl cmdlbmNlIHdlIHNpbXBseSBjbG9zZSBvbmUgdnVsbmVyYWJpbGl0eSBhbmQgb3BlbiBhbm90aGVy Lg0KDQpBcyBleHBlcnRzIG9uIHRoZSBMRFAgcHJvdG9jb2wsIGJ1dCBub3Qgb24gc2VjdXJpdHkg bWVjaGFuaXNtcywgd2UgIG5lZWQgdG8gYXNrIHRoZSBzZWN1cml0eSBhcmVhIGZvciBhIHJldmll dyBvZiBvdXIgcHJvcG9zZWQgYXBwcm9hY2gsIGFuZCBoZWxwIGNvcnJlY3RpbmcgYW55IG1pc3Vu ZGVyc3RhbmRpbmcgb2YgdGhlIHNlY3VyaXR5IGlzc3VlcyBvciBvdXIgbWlzdW5kZXJzdGFuZGlu ZyBvZiB0aGUgZXhpc3Rpbmcgc2VjdXJpdHkgbWVjaGFuaXNtcy4gV2UgYWxzbyBuZWVkIHRoZSBy ZWNvbW1lbmRhdGlvbnMgb2YgYSBzdWl0YWJsZSBzZWN1cml0eSBmdW5jdGlvbiAoVEJEIGluIHRo ZSBhYm92ZSB0ZXh0KS4NCg0KQmVzdCByZWdhcmRzDQoNClRoZSBNUExTIFdHIENoYWlycw0KVGhl IFBBTFMgV0cgQ2hhaXJzDQoNCg0KDQo= --_000_25B4902B1192E84696414485F572685413519209sjceml521mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tOTIwMTM5Mjk5NjYwNDU1MzE0MG1zb2xpc3RwYXJhZ3Jh cGgsIGxpLm05MjAxMzkyOTk2NjA0NTUzMTQwbXNvbGlzdHBhcmFncmFwaCwgZGl2Lm05MjAxMzky OTk2NjA0NTUzMTQwbXNvbGlzdHBhcmFncmFwaA0KCXttc28tc3R5bGUtbmFtZTptXzkyMDEzOTI5 OTY2MDQ1NTMxNDBtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu LWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JA cnRmbS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBOb3ZlbWJlciAwOCwgMjAx NyAzOjUzIFBNPGJyPg0KPGI+VG86PC9iPiBVbWEgQ2h1bmR1cmkgJmx0O3VtYS5jaHVuZHVyaUBo dWF3ZWkuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gU3Rld2FydCBCcnlhbnQgJmx0O3N0ZXdhcnQu YnJ5YW50QGdtYWlsLmNvbSZndDs7IG1wbHNAaWV0Zi5vcmc7IHBhbHMtY2hhaXJzQHRvb2xzLmll dGYub3JnOyAmbHQ7cnRnLWFkc0BpZXRmLm9yZyZndDsgJmx0O3J0Zy1hZHNAaWV0Zi5vcmcmZ3Q7 OyBtcGxzLWNoYWlyc0BpZXRmLm9yZzsgcGFsc0BpZXRmLm9yZzsgJmx0O3NlYy1hZHNAaWV0Zi5v cmcmZ3Q7ICZsdDtzZWMtYWRzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W21wbHNdIExEUCBTZWN1cml0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgTm92 IDgsIDIwMTcgYXQgMzo1MCBQTSwgVW1hIENodW5kdXJpICZsdDs8YSBocmVmPSJtYWlsdG86dW1h LmNodW5kdXJpQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj51bWEuY2h1bmR1cmlAaHVhd2Vp LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBuYW1lPSJtXzkyMDEzOTI5OTY2MDQ1NTMx NDBfX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SW4tbGlu ZSBbVW1hMV06PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPi0tPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ VW1hIEMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiBFcmljIFJlc2NvcmxhIFttYWlsdG86PGEgaHJlZj0ibWFpbHRv OmVrckBydGZtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVrckBydGZtLmNvbTwvYT5dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBOb3ZlbWJlciAwOCwgMjAxNyAxMjo1MyBQTTxicj4NCjxi PlRvOjwvYj4gVW1hIENodW5kdXJpICZsdDs8YSBocmVmPSJtYWlsdG86dW1hLmNodW5kdXJpQGh1 YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj51bWEuY2h1bmR1cmlAaHVhd2VpLmNvbTwvYT4mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBTdGV3YXJ0IEJyeWFudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZXdh cnQuYnJ5YW50QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZXdhcnQuYnJ5YW50QGdtYWls LmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5tcGxzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnBhbHMtY2hhaXJzQHRvb2xz LmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpwYWxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzwv YT47ICZsdDs8YSBocmVmPSJtYWlsdG86cnRnLWFkc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnJ0Zy1hZHNAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Zy1hZHNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGctYWRzQGlldGYub3JnPC9hPiZndDs7DQo8YSBocmVm PSJtYWlsdG86bXBscy1jaGFpcnNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzLWNoYWly c0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpwYWxzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+DQpwYWxzQGlldGYub3JnPC9hPjsgJmx0OzxhIGhyZWY9Im1haWx0bzpzZWMtYWRzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2VjLWFkc0BpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86c2VjLWFkc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNlYy1hZHNAaWV0 Zi5vcmc8L2E+Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbXBsc10gTERQIFNlY3Vy aXR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk9uIFdlZCwgTm92IDgsIDIwMTcgYXQgMTE6NTcgQU0sIFVtYSBDaHVuZHVyaSAmbHQ7PGEg aHJlZj0ibWFpbHRvOnVtYS5jaHVuZHVyaUBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+dW1h LmNodW5kdXJpQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9Im1fOTIwMTM5Mjk5NjYwNDU1MzE0MF9t Xy03Njg0NDg4MzE0NjcxNDMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBTdGV3 YXJ0LDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5J IHdvdWxkIG5vdGUNCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNjk1MiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzY5NTI8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4NCiAtIHdoZXJlIExEUCBzZWN1cml0eSBpcyBhbmFseXplZCBmcm9tIGFsbCBhc3BlY3Rz LiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5FcmljLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlF1aWNrIGNvbW1l bnRzIGJlbG93IFtVbWFdOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPi0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VW1hIEMuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBtcGxzIFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPm1wbHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyaWMg UmVzY29ybGE8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBOb3ZlbWJlciAwOCwgMjAxNyAx MDowMCBBTTxicj4NCjxiPlRvOjwvYj4gU3Rld2FydCBCcnlhbnQgJmx0OzxhIGhyZWY9Im1haWx0 bzpzdGV3YXJ0LmJyeWFudEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zdGV3YXJ0LmJyeWFu dEBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm1wbHNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFp bHRvOnBhbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpwYWxzLWNo YWlyc0B0b29scy5pZXRmLm9yZzwvYT47ICZsdDs8YSBocmVmPSJtYWlsdG86cnRnLWFkc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Zy1hZHNAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJ0Zy1hZHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGctYWRzQGlldGYu b3JnPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86bXBscy1jaGFpcnNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5tcGxzLWNoYWlyc0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpwYWxz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpwYWxzQGlldGYub3JnPC9hPjsgJmx0OzxhIGhy ZWY9Im1haWx0bzpzZWMtYWRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2VjLWFkc0BpZXRm Lm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2VjLWFkc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnNlYy1hZHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW21wbHNdIExEUCBTZWN1cml0eTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5IaSBTdGV3YXJ0PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+VGhhbmtzIGZvciB5b3VyIG5vdGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5NeSBvdmVyYWxsIHNlbnNlIG9mIHRo ZSBzdGF0ZSBvZiBwbGF5IGlzLCBJIHRoaW5rIG11Y2ggbGlrZSB5b3Vycy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRDUC1NRDUgaXMg aW5hZGVxdWF0ZSBpbiB0d28gbWFqb3IgcmVzcGVjdHM6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gSXQgdXNlcyB3ZWFrIGFsZ29yaXRobXM8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBJ dCBoYXMgYSBiYWQgbmVnb3RpYXRpb24vc2V0dW9wIHN0b3J5IChtYW51YWwga2V5IG1hbmFnZW1l bnQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5UQ1AtQU8gaXMgaW50ZW5kZWQgdG8gYmUgYSBkcm9wLWluIHJlcGxhY2VtZW50IGZvciBU Q1AtTUQ1IGFuZCBzbyByZW1lZGllcyB0aGUgYWxnb3JpdGhtPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklzc3VlPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bVW1hXTogWWVzLCBpZiB3ZSBnbyB3aXRoIFJGQyA1OTI2 IG1hbmRhdG9yeSBsaXN0Li48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmJ1dCBub3QgdGhlIGtleSBtYW5hZ2Vt ZW50IGlzc3VlIFswXS4gV2UgaGF2ZW4ndCBtYWRlIG11Y2ggcHJvZ3Jlc3Mgb24gdGhlIGtleTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5tYW5h Z2VtZW50IHN0b3J5LCBhbmQgdGhhdCBzZWVtcyB0byBiZSBhIG1ham9yIGltcGVkaW1lbnQgdG8g ZGVwbG95aW5nIGVpdGhlciBvZiB0aGVzZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj50ZWNobm9sb2dpZXMgKHdoaWNoIEkgYW0gZ2l2ZW4gdG8g dW5kZXJzdGFuZCBkb24ndCBzZWUgYSBsb3Qgb2YgdXNlKS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+W1VtYV06IFRydWUuDQo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtCdXQgSSB3b3VsZCBpbmRpY2F0ZSBzb21l IGVmZm9ydCBkb25lIGZldyB5ZWFycyBiYWNrIHJlZ2FyZGluZyBrZXkgbWFuYWdlbWVudCBmb3Ig cGFpcg0KIHdpc2Ugcm91dGluZyBwcm90b2NvbHMgKEJHUCwgTERQLCBQQ0VQLCBNU0RQIC4uKS4g PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7T25l IHN1Y2ggcHJvcG9zYWwgaXMgYnkgZXh0ZW5kaW5nIElLRXYyIHRvIG5lZ290aWF0ZSBUQ1AtQU8g TUtUcyAod2hpY2ggY2FuIGdpdmUgcmVrZXkNCiAmYW1wOyBhbGdvLiBhZ2lsaXR5KSAtIDwvc3Bh bj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFoZXNoLWthcnAt cmttcC0wNSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1tYWhlc2gta2FycC1ya21wLTA1PC9hPiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGlzIGFsc28gcmVxdWlyZXMgc29tZSBtb3JlIHdvcmsg d2l0aCBUQ1AtQU87IG1lICZhbXA7IEpvZSBwdXQgdG9nZXRoZXINCjwvc3Bhbj48YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWNodW5kdXJpLWthcnAtdXNpbmct aWtldjItd2l0aC10Y3AtYW8tMDYudHh0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1jaHVuZHVyaS1rYXJwLXVzaW5nLWlrZXYyLXdpdGgtdGNw LWFvLTA2LnR4dDwvYT4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Tm90ZSB0aGUgYWJvdmUgZGlk buKAmXQgcHJvZ3Jlc3MgaW4gdGhlIGNvbmNsdWRlZCBLQVJQIFdHIChub3QgZnVsbHkgc3VyZSB0 aGUgcmVhc29ucyBvbiB3aHkpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlllYWgsIEkga25vdyB0aGF0IHBlb3BsZSB0cmllZCB0byBkbyB0aGlzLCBidXQg bXkgaW1wcmVzc2lvbiB3YXMgaXQga2luZGEgZGlkbid0IHByb2dyZXNzIG11Y2guPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XZSBz aG91bGQgcHJvYmFibHk8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+DQo8L3NwYW4+dGFsayBp biBTaW5nYXBvcmUgYWJvdXQgdGhhdCwgYnV0IHRoYXQncyBub3QgZ29pbmcgdG8gZ2V0IGJldHRl ciBhbnkgdGltZSBzb29uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbiB0aGUgaW50ZXJpbSwg SSB0aGluayB0aGUgdGV4dCB5b3UgaGF2ZSBpcyBPSywgYW5kICZxdW90O1RCRCZxdW90OyBzaG91 bGQgcmVhZCAmcXVvdDtTSEEtMjU2JnF1b3Q7LCB3aXRoPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnRoZSBmYWxsYmFjayBiZWluZyBTSEEtMjU2 IC0mZ3Q7IFNIQS0xIC0mZ3Q7IE1ENS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPltVbWFdOiBXaGlsZSB0aGUgbGlzdCBjYW4gYmUgZXh0ZW5kZWQgLSBJIGRpZG7igJl0 IHNlZSBTSEEyNTYgaW4gdGhlIG1hbmRhdG9yeSBsaXN0IGluIFJGQyA1OTI2IGZvciBNQUMuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+R2VuZXJhbGx5IHdlJ3JlIHRyeWluZyB0byBtb3ZlIGF3YXkgZnJv bSBTSEEtMSB0b3dhcmRzIFNIQS0yNTYuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1VtYTFdOiBDb3VwbGUgb2YgdGhpbmdzOjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtOTIwMTM5Mjk5NjYwNDU1MzE0MG1zb2xpc3RwYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo1OC41cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4xLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ob3RoaW5nIHRvIGJlIGRvbmUgKGZyb20gc3BlYyBw b3Ygb2YgY291cnNlKTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4g VXNlIFRDUC1BTyAoaW5zdGVhZCBvZiBjdXJyZW50IE1ENSkNCiB3aXRoIHRoZSBSRkMgNTkyNiBt YW5kYXRlZCBNQUNzL0tERnMg4oCTIHNvIHRoZSDigJhUQkTigJkgaW4gU3Rld2FydCBzdWdnZXN0 aW5nIGJlbG93IGlzIGFscmVhZHkgdGhlcmUuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0ibTkyMDEzOTI5OTY2MDQ1NTMxNDBtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6NTguNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Mi48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+QXMgIzEgdG9vIGlzIG5vdCBnb29kIGVub3VnaCBmcm9tIHlvdXIgYWJvdmUgbm90ZSAtIGRv IFNIQS0yNTYgYW5kIGxpdmUgd2l0aCBpdCAobm8gYWxnb3JpdGhtIGFnaWxpdHkpLiBTdGlsbCBh IHNlY3VyaXR5IGJlbmVmaXQgaW4gb25lIHdheSBmcm9tIGV4aXN0aW5nIHN0dWZmIG9yIGV2ZW4g Jm5ic3A7IzEuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkknbSBub3Qgc3VyZSB3aHkgeW91IHNheSAmcXVvdDtubyBhbGdvcml0aG0gYWdp bGl0eSZxdW90Oy4gWW91J2QgYmUgdXNpbmcgQU8sIGp1c3Qgd2l0aCBhIGRpZmZlcmVudCBhbGdv cml0aG0gdGhhbiBTSEEtMS4gQUVTLUNNQUMgaXMgc3RpbGwgZmluZSBhcyBmYXIgYXMgSSBrbm93 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPltVbWEyXTogU3VyZSwgeW91IGhhdmUgaXQsIGlmIHlvdSB1c2UgQU87DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7QnV0IHRoZW4gJm5ic3A7SSBhbSBub3QgZ2V0dGluZyBob3cgd2UgY2FuIG1hbmRhdGUg b25lIE1VU1QgaW1wbGVtZW50IGFsZ29yaXRobSBhcyBzdWdnZXN0ZWQgYmVsb3cgVEJEJm5ic3A7 IHdvdWxkIGFjdHVhbGx5IHdvcmsgJm5ic3A7KGVzcGVjaWFsbHkgLSAqPGI+aWY8L2I+Kg0KICMx IGlzIGFscmVhZHkgZGVwbG95ZWQgc29tZXdoZXJlPykmbmJzcDsmbmJzcDsgPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1Blcmhh cHMgc3RheWluZyB3aXRoICMxIGlzIHRoZSBiZXN0IGJldCBvciBkbyBuZWdvdGlhdGlvbiB0aHJv dWdoICMzLCB3aXRoIGFscmVhZHkgbWFuZGF0ZWQgYW5kIGFkZGl0aW9uYWwgc3R1ZmYuJm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Im05MjAxMzkyOTk2NjA0NTUzMTQwbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjU4LjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjMuPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkRv IGtleSBtYW5hZ2VtZW50IGFuZCDigJx0aGVvcmV0aWNhbGx54oCdIGdldCBhbGwgd2Ugd2FudGVk 4oCmLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldlIGhh dmUgYmVlbiBoZXJlIG11bHRpcGxlIHRpbWVzOyBiZWNhdXNlICMxIGl0c2VsZiBpcyBub3QgKjxi Pm1vc3RseTwvYj4qIGRlcGxveWVkIChuZWl0aGVyIGluIEJHUA0KIG5vciBpbiBMRFApIGlmIHRo ZXJlIGlzIGFueSBhcHBldGl0ZSBmb3IgIzIgYW5kICMzIGZvciBwcmFjdGljYWwgZGVwbG95bWVu dHMuIEJ1dCBzdGlsbCBpdCBtYXkgYmUgZ29vZCB0byBkbyAjMiBhbnkgd2F5cy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tRWtyPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+WzBdIFRlY2huaWNhbGx5IEl0IGhhcyBiZXR0ZXIgc3VwcG9ydCBmb3Igcm9sbG92ZXIsIGJ1 dCB0aGlzIGlzIG5vdCBhIGh1Z2UgaW1wcm92ZW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlsxXSB0Y3BjcnlwdCBpcyBraW5kIG9mIG9y dGhvZ29uYWwgaGVyZSBhcyBpdCdzIHVuYXV0aGVudGljYXRlZCBidXQgb3Bwb3J0dW5pc3RpYy4m bmJzcDsgVGhhdCBzYWlkLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5pdCB3b3VsZCBwcm92aWRlIGRlZmVuc2UgYWdhaW5zdCBhdHRhY2tlcnMg d2hvIGdhaW4gYWNjZXNzIHRvIHRoZSBsaW5rIGFmdGVyIGNvbm5lY3Rpb248bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+c2V0dXAgYW5kIGRvZXNu J3QgcmVxdWlyZSBjb25maWd1cmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBOb3YgOCwgMjAxNyBhdCA5OjI3IEFN LCBTdGV3YXJ0IEJyeWFudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZXdhcnQuYnJ5YW50QGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPlRvIHRoZSBTRUMgYW5kIFJURyBBRHMsPGJy Pg0KPGJyPg0KSSBhbSBzZW5kaW5nIHRoZSBmb2xsb3dpbmcgbWVzc2FnZSBvbiBiZWhhbGYgb2Yg dGhlIE1QTFMgYW5kIHRoZTxicj4NClBBTFMgV0cgQ2hhaXJzLjxicj4NCjxicj4NClRoZXJlIGlz IGEgY29uY2VybiBzaGFyZWQgYW1vbmcgdGhlIHNlY3VyaXR5IGNvbW11bml0eSBhbmQgdGhlIHdv cmtpbmcgZ3JvdXBzIHRoYXQgZGV2ZWxvcCB0aGUgTERQIHByb3RvY29sIHRoYXQgTERQIGlzIG5v IGxvbmdlciBhZGVxdWF0ZWx5IHNlY3VyZWQuIExEUCBjdXJyZW50bHkgcmVsaWVzIG9uIE1ENSBm b3IgY3J5cHRvZ3JhcGhpYyBzZWN1cml0eSBvZiBpdHMgbWVzc2FnZXMsIGJ1dCBNRDUgaXMgYSBo YXNoIGZ1bmN0aW9uIHRoYXQgaXMNCiBubyBsb25nZXIgY29uc2lkZXJlZCB0byBtZWV0IGN1cnJl bnQgc2VjdXJpdHkgcmVxdWlyZW1lbnRzLjxicj4NCjxicj4NCkluIFJGQzUwMzYgKHB1Ymxpc2hl ZCAyMDA3KSBTZWN0aW9uIDUuMSAoU3Bvb2ZpbmcpICwgTGlzdCBlbGVtZW50IDIuIFNlc3Npb24g Y29tbXVuaWNhdGlvbiBjYXJyaWVkIGJ5IFRDUCB0aGUgZm9sbG93aW5nIHN0YXRlbWVudHMgaXMg bWFkZTo8YnI+DQo8YnI+DQomcXVvdDtMRFAgc3BlY2lmaWVzIHVzZSBvZiB0aGUgVENQIE1ENSBT aWduYXR1cmUgT3B0aW9uIHRvIHByb3ZpZGUgZm9yIHRoZSBhdXRoZW50aWNpdHkgYW5kIGludGVn cml0eSBvZiBzZXNzaW9uIG1lc3NhZ2VzLjxicj4NCjxicj4NCiZxdW90O1tSRkMyMzg1XSBhc3Nl cnRzIHRoYXQgTUQ1IGF1dGhlbnRpY2F0aW9uIGlzIG5vdyBjb25zaWRlcmVkIGJ5IHNvbWUgdG8g YmUgdG9vIHdlYWsgZm9yIHRoaXMgYXBwbGljYXRpb24uJm5ic3A7IEl0IGFsc28gcG9pbnRzIG91 dCB0aGF0IGEgc2ltaWxhciBUQ1Agb3B0aW9uIHdpdGggYSBzdHJvbmdlciBoYXNoaW5nIGFsZ29y aXRobSAoaXQgY2l0ZXMgU0hBLTEgYXMgYW4gZXhhbXBsZSkgY291bGQgYmUgZGVwbG95ZWQuJm5i c3A7IFRvIG91ciBrbm93bGVkZ2UsIG5vDQogc3VjaCBUQ1Agb3B0aW9uIGhhcyBiZWVuIGRlZmlu ZWQgYW5kIGRlcGxveWVkLiZuYnNwOyBIb3dldmVyLCB3ZSBub3RlIHRoYXQgTERQIGNhbiB1c2Ug d2hhdGV2ZXIgVENQIG1lc3NhZ2UgZGlnZXN0IHRlY2huaXF1ZXMgYXJlIGF2YWlsYWJsZSwgYW5k IHdoZW4gb25lIHN0cm9uZ2VyIHRoYW4gTUQ1IGlzIHNwZWNpZmllZCBhbmQgaW1wbGVtZW50ZWQs IHVwZ3JhZGluZyBMRFAgdG8gdXNlIGl0IHdvdWxkIGJlIHJlbGF0aXZlbHkgc3RyYWlnaHRmb3J3 YXJkLiZxdW90Ozxicj4NCjxicj4NCldlIG5vdGUgdGhhdCBCR1AgaGFzIGFscmVhZHkgYmVlbiB0 aHJvdWdoIHRoaXMgcHJvY2VzcywgYW5kIHJlcGxhY2VkIE1ENSB3aXRoIFRDUC1BTyBpbiBSRkMg NzQ1NC4gSSB3b3VsZCBiZSBsb2dpY2FsIHRvIGZvbGxvdyB0aGUgc2FtZSBhcHByb2FjaCB0byBz ZWN1cmUgTERQLiBIb3dldmVyLCBhcyBmYXIgYXMgd2UgYXJlIGFibGUgdG8gYXNjZXJ0YWluLCB0 aGVyZSBpcyBjdXJyZW50bHkgbm8gcmVjb21tZW5kZWQsIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQs DQogY3J5cHRvZ3JhcGhpYyBmdW5jdGlvbiBzcGVjaWZpZWQuIFdlIGFyZSBjb25jZXJuZWQgdGhh dCB3aXRob3V0IHN1Y2ggYSBtYW5kYXRvcnkgZnVuY3Rpb24sIGltcGxlbWVudGF0aW9ucyB3aWxs IHNpbXBseSBmYWxsIGJhY2sgdG8gTUQ1IGFuZCB3ZSB3aWxsIGJlIG5vIGZ1cnRoZXIgZm9yd2Fy ZDxicj4NCjxicj4NCldlIHRoaW5rIHRoYXQgdGhlIGJlc3Qgd2F5IGZvcndhcmQgaXMgdG8gcHVi bGlzaCBhIGRyYWZ0IHNpbWlsYXIgdG8gUkZDIDc0NTQgdGhhdCBjb250YWlucyB0aGUgZm9sbG93 aW5nIHJlcXVpcmVtZW50Ojxicj4NCjxicj4NCiZxdW90O0ltcGxlbWVudGF0aW9ucyBjb25mb3Jt aW5nIHRvIHRoaXMgUkZDIE1VU1QgaW1wbGVtZW50IFRDUC1BTyB0byBzZWN1cmUgdGhlIFRDUCBz ZXNzaW9ucyBjYXJyeWluZyBMRFAgaW4gYWRkaXRpb24gdG8gdGhlIGN1cnJlbnRseSByZXF1aXJl ZCBUQ1AgTUQ1IFNpZ25hdHVyZSBPcHRpb24uIEZ1cnRoZXJtb3JlLCB0aGUgVEJEIGNyeXB0b2dy YXBoaWMgbWVjaGFuaXNtIG11c3QgYmUgaW1wbGVtZW50ZWQgYW5kIHByb3ZpZGVkIHRvIFRDUC1B TyB0bw0KIHNlY3VyZSBMRFAgbWVzc2FnZXMuIFRoZSBUQkQgbWVjaGFuaXNtIGlzIHRoZSBwcmVm ZXJyZWQgb3B0aW9uLCBhbmQgTUQ1IGlzIG9ubHkgdG8gYmUgdXNlZCB3aGVuIFRCRCBpcyB1bmF2 YWlsYWJsZS4mcXVvdDs8YnI+DQo8YnI+DQpXZSBhcmUgbm90IGFuIGV4cGVydHMgb24gdGhpcyBw YXJ0IG9mIHRoZSBzdGFjaywgYnV0IGl0IHNlZW1zIHRoYXQgVENQIHNlY3VyaXR5IG5lZ290aWF0 aW9uIGlzIHN0aWxsIHdvcmsgaW4gcHJvZ3Jlc3MuIElmIHdlIGFyZSB3cm9uZywgdGhlbiB3ZSBu ZWVkIHRvIGluY2x1ZGUgYSByZXF1aXJlbWVudCB0aGF0IHN1Y2ggbmVnb3RpYXRpb24gaXMgYWxz byByZXF1aXJlZC4gSW4gdGhlIGFic2VuY2Ugb2YgYSBuZWdvdGlhdGlvbiBwcm90b2NvbCwgaG93 ZXZlciwNCiB3ZSBuZWVkIHRvIGxlYXZlIHRoaXMgYXMgYSBjb25maWd1cmF0aW9uIHByb2Nlc3Mg dW50aWwgc3VjaCB0aW1lIGFzIHRoZSBuZWdvdGlhdGlvbiBwcm90b2NvbCB3b3JrIGlzIGNvbXBs ZXRlLiBPbiBjb21wbGV0aW9uIG9mIGEgc3VpdGFibGUgbmVnb3RpYXRpb24gcHJvdG9jb2wgd2Ug bmVlZCB0byBpc3N1ZSBhIGZ1cnRoZXIgdXBkYXRlIHJlcXVpcmluZyBpdHMgdXNlLjxicj4NCjxi cj4NCkFkZGl0aW9uYWxseSB3ZSBzaG91bGQgbm90ZSB0aGF0IG5vIGNyeXB0b2dyYXBoaWMgbWVj aGFuaXNtIGhhcyBhbiBpbmRlZmluaXRlIGxpZmV0aW1lLCBhbmQgdGhhdCBpbXBsZW1lbnRhdGlv biBzaG91bGQgbm90ZSB0aGUgSUVURiBhbnRpY2lwYXRlcyB1cGRhdGluZyB0aGUgZGVmYXVsdCBj cnlwdG9ncmFwaGljIG1lY2hhbmlzbSBvdmVyIHRpbWUuPGJyPg0KPGJyPg0KVGhlIFRCRCBkZWZh dWx0IHNlY3VyaXR5IGZ1bmN0aW9uIHdpbGwgbmVlZCB0byBiZSBjaG9zZW4gc3VjaCB0aGF0IGl0 IGNhbiByZWFzb25hYmx5IGJlIGltcGxlbWVudGVkIG9uIGEgdHlwaWNhbCByb3V0ZXIgcm91dGUg cHJvY2Vzc29yLCBhbmQgd2hpY2ggd2lsbCBwcm92aWRlIGFkZXF1YXRlIHNlY3VyaXR5IHdpdGhv dXQgc2lnbmlmaWNhbnRseSBkZWdyYWRpbmcgdGhlIGNvbnZlcmdlbmNlIHRpbWUgb2YgYW4gTFNS LiBXaXRob3V0IGEgZnVuY3Rpb24NCiB0aGF0IGRvZXMgbm90IHNpZ25pZmljYW50bHkgaW1wYWN0 IHJvdXRlciBjb252ZXJnZW5jZSB3ZSBzaW1wbHkgY2xvc2Ugb25lIHZ1bG5lcmFiaWxpdHkgYW5k IG9wZW4gYW5vdGhlci48YnI+DQo8YnI+DQpBcyBleHBlcnRzIG9uIHRoZSBMRFAgcHJvdG9jb2ws IGJ1dCBub3Qgb24gc2VjdXJpdHkgbWVjaGFuaXNtcywgd2UmbmJzcDsgbmVlZCB0byBhc2sgdGhl IHNlY3VyaXR5IGFyZWEgZm9yIGEgcmV2aWV3IG9mIG91ciBwcm9wb3NlZCBhcHByb2FjaCwgYW5k IGhlbHAgY29ycmVjdGluZyBhbnkgbWlzdW5kZXJzdGFuZGluZyBvZiB0aGUgc2VjdXJpdHkgaXNz dWVzIG9yIG91ciBtaXN1bmRlcnN0YW5kaW5nIG9mIHRoZSBleGlzdGluZyBzZWN1cml0eSBtZWNo YW5pc21zLg0KIFdlIGFsc28gbmVlZCB0aGUgcmVjb21tZW5kYXRpb25zIG9mIGEgc3VpdGFibGUg c2VjdXJpdHkgZnVuY3Rpb24gKFRCRCBpbiB0aGUgYWJvdmUgdGV4dCkuPGJyPg0KPGJyPg0KQmVz dCByZWdhcmRzPGJyPg0KPGJyPg0KVGhlIE1QTFMgV0cgQ2hhaXJzPGJyPg0KVGhlIFBBTFMgV0cg Q2hhaXJzPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_25B4902B1192E84696414485F572685413519209sjceml521mbschi_-- From nobody Wed Nov 8 16:45:18 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3981F129480 for ; Wed, 8 Nov 2017 16:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 B56DnaqpVXKt for ; Wed, 8 Nov 2017 16:45:11 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 26C82129454 for ; Wed, 8 Nov 2017 16:45:11 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id q1so3933759ywh.5 for ; Wed, 08 Nov 2017 16:45:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t2WQRwB+5VjRcrYtHUKt1OYw7xYwanfLQxo+daoR4Q8=; b=KXR1CncP2FTezUj7iJAd8RS+sesilA9mFkvQyvU+TGZ8mjwuhBenBScBJxROK2mEWT um7Lcrrzv+u1ltvYPkBmfJS7dflJlbUeb4MaN/V9j4UgDRtDNgognCz1HI4uBObuzRtq HwWKdlZ933SI3qtrERHKqplkY6BPthpwvIQ9AuSzuQRBmnFwjCrTFHnw+b42Krb4PEiF QgT443GtYe2zeiwGntxPWb6R/vQmQHjdwhEkHtpeIxcZ3Hg+2aWt1QQTvPLYIZQcdj3A dKlneGOA1csN7w4hbr1e8TQjzooq/wOa9IZjKQi33UEbRwNjw8OOnvze60vfSZ4O37AC 8Zmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t2WQRwB+5VjRcrYtHUKt1OYw7xYwanfLQxo+daoR4Q8=; b=JhPvNuC8NaOwxvjht38SwBggXYYQm3dMx7Ozgk+peO80IHcvIu+dPb+FD70CbyJzKf DVClJuWDaPBc7hNNC0PoXRbI/OO98izxg05TY5iMuvkXaaoksH8RKcDwLq/oA72SCj88 7R0suCQdKN2SkBt3KrtTucfNNbuTmwzniH1/1aQh3fF2Ouqq+C4X7gOZH4Pj9zReiymJ lHVS60jGhsDt/ufkr0jNPZpiR0fapJN+2Mddvc6JWCDlxftZoMEZ6HSn59Mk1wRc4S/w 8bhjTr2mVkUk/xpncNnP4CT1oT3U+RY4NW8A+qhaYJhb2jcoofreoMWJcnReJjyv75z7 1hXg== X-Gm-Message-State: AJaThX7AA5UXOFnruc6WacItw51c3lblgvqI0m+sZVQ49+FV3C4BEndB 59LVVX1mOMtkD2OLMH4Q8c1rKrsIkF4pysymZPNDVQ== X-Google-Smtp-Source: ABhQp+Q71rLa2dQYXoI9y5F6HeIVv5LlGM/TiZfG8ClNLa5xUYBWtv2++YIfRO4YsbQhSc6u9QzoDUh/Tgqa8/u8iEU= X-Received: by 10.129.167.66 with SMTP id e63mr1647513ywh.294.1510188309983; Wed, 08 Nov 2017 16:45:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Wed, 8 Nov 2017 16:44:28 -0800 (PST) In-Reply-To: <25B4902B1192E84696414485F572685413519209@sjceml521-mbs.china.huawei.com> References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <5994f353-5306-0fa8-2d2d-024ebdbb10df@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> <25B4902B1192E84696414485F57268541351915D@sjceml521-mbs.china.huawei.com> <25B4902B1192E84696414485F5726854135191D6@sjceml521-mbs.china.huawei.com> <25B4902B1192E84696414485F572685413519209@sjceml521-mbs.china.huawei.com> From: Eric Rescorla Date: Wed, 8 Nov 2017 16:44:28 -0800 Message-ID: To: Uma Chunduri Cc: Stewart Bryant , "mpls@ietf.org" , "pals-chairs@tools.ietf.org" , "" , "mpls-chairs@ietf.org" , "pals@ietf.org" , "" Content-Type: multipart/alternative; boundary="94eb2c079026c30986055d821d85" Archived-At: Subject: Re: [Pals] [mpls] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 00:45:16 -0000 --94eb2c079026c30986055d821d85 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't understand what you're getting at here. Yes, if people have TCP-AO then presumably they have SHA-1. But now we're talking about requiring people to have TCP-AO in this case, so we should try to move them to SHA-256 at the time we require AO. -Ekr On Wed, Nov 8, 2017 at 4:14 PM, Uma Chunduri wrote: > *From:* Eric Rescorla [mailto:ekr@rtfm.com] > *Sent:* Wednesday, November 08, 2017 3:53 PM > > *To:* Uma Chunduri > *Cc:* Stewart Bryant ; mpls@ietf.org; > pals-chairs@tools.ietf.org; ; > mpls-chairs@ietf.org; pals@ietf.org; > *Subject:* Re: [mpls] LDP Security > > > > > > > > On Wed, Nov 8, 2017 at 3:50 PM, Uma Chunduri > wrote: > > In-line [Uma1]: > > -- > > Uma C. > > > > *From:* Eric Rescorla [mailto:ekr@rtfm.com] > *Sent:* Wednesday, November 08, 2017 12:53 PM > *To:* Uma Chunduri > *Cc:* Stewart Bryant ; mpls@ietf.org; > pals-chairs@tools.ietf.org; ; > mpls-chairs@ietf.org; pals@ietf.org; > > > *Subject:* Re: [mpls] LDP Security > > > > > > > > On Wed, Nov 8, 2017 at 11:57 AM, Uma Chunduri > wrote: > > Hi Stewart, > > > > I would note https://tools.ietf.org/html/rfc6952 - where LDP security is > analyzed from all aspects. > > > > Eric, > > > > Quick comments below [Uma]: > > > > -- > > Uma C. > > > > *From:* mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Eric Rescorla > *Sent:* Wednesday, November 08, 2017 10:00 AM > *To:* Stewart Bryant > *Cc:* mpls@ietf.org; pals-chairs@tools.ietf.org; < > rtg-ads@ietf.org>; mpls-chairs@ietf.org; pals@ietf.org; > > *Subject:* Re: [mpls] LDP Security > > > > Hi Stewart > > > > Thanks for your note. > > > > My overall sense of the state of play is, I think much like yours. > > > > TCP-MD5 is inadequate in two major respects: > > - It uses weak algorithms > > - It has a bad negotiation/setuop story (manual key management) > > > > TCP-AO is intended to be a drop-in replacement for TCP-MD5 and so remedie= s > the algorithm > > Issue > > > > [Uma]: Yes, if we go with RFC 5926 mandatory list.. > > > > but not the key management issue [0]. We haven't made much progress on th= e > key > > management story, and that seems to be a major impediment to deploying > either of these > > technologies (which I am given to understand don't see a lot of use). > > > > [Uma]: True. > > But I would indicate some effort done few years back > regarding key management for pair wise routing protocols (BGP, LDP, PCEP, > MSDP ..). > > One such proposal is by extending IKEv2 to negotiate TCP-A= O > MKTs (which can give rekey & algo. agility) - https://tools.ietf.org/html= / > draft-mahesh-karp-rkmp-05 > > This also requires some more work with TCP-AO; me & Joe pu= t > together https://www.ietf.org/archive/id/draft-chunduri-karp-using- > ikev2-with-tcp-ao-06.txt > > Note the above didn=E2=80=99t progress in the concluded KARP W= G (not > fully sure the reasons on why). > > > > Yeah, I know that people tried to do this, but my impression was it kinda > didn't progress much. > > > > > > > > We should probably talk in Singapore about that, but that's not going to > get better any time soon. > > > > In the interim, I think the text you have is OK, and "TBD" should read > "SHA-256", with > > the fallback being SHA-256 -> SHA-1 -> MD5. > > > > [Uma]: While the list can be extended - I didn=E2=80=99t see SHA256 in th= e > mandatory list in RFC 5926 for MAC. > > > > Generally we're trying to move away from SHA-1 towards SHA-256. > > > > [Uma1]: Couple of things: > > 1. *Nothing to be done (from spec pov of course):* Use TCP-AO > (instead of current MD5) with the RFC 5926 mandated MACs/KDFs =E2=80=93 s= o the > =E2=80=98TBD=E2=80=99 in Stewart suggesting below is already there. > > 2. As #1 too is not good enough from your above note - do SHA-256 > and live with it (no algorithm agility). Still a security benefit in one > way from existing stuff or even #1. > > I'm not sure why you say "no algorithm agility". You'd be using AO, just > with a different algorithm than SHA-1. AES-CMAC is still fine as far as I > know. > > [Uma2]: Sure, you have it, if you use AO; > > But then I am not getting how we can mandate one MUST > implement algorithm as suggested below TBD would actually work > (especially - **if** #1 is already deployed somewhere?) > > Perhaps staying with #1 is the best bet or do negotiatio= n > through #3, with already mandated and additional stuff. > > > > -Ekr > > > > 3. Do key management and =E2=80=9Ctheoretically=E2=80=9D get all we= wanted=E2=80=A6. > > > > We have been here multiple times; because #1 itself is not **mostly** > deployed (neither in BGP nor in LDP) if there is any appetite for #2 and = #3 > for practical deployments. But still it may be good to do #2 any ways. > > > > > > -Ekr > > > > > > -Ekr > > > > > > [0] Technically It has better support for rollover, but this is not a hug= e > improvement. > > [1] tcpcrypt is kind of orthogonal here as it's unauthenticated but > opportunistic. That said, > > it would provide defense against attackers who gain access to the link > after connection > > setup and doesn't require configuration. > > > > On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant > wrote: > > To the SEC and RTG ADs, > > I am sending the following message on behalf of the MPLS and the > PALS WG Chairs. > > There is a concern shared among the security community and the working > groups that develop the LDP protocol that LDP is no longer adequately > secured. LDP currently relies on MD5 for cryptographic security of its > messages, but MD5 is a hash function that is no longer considered to meet > current security requirements. > > In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2. > Session communication carried by TCP the following statements is made: > > "LDP specifies use of the TCP MD5 Signature Option to provide for the > authenticity and integrity of session messages. > > "[RFC2385] asserts that MD5 authentication is now considered by some to b= e > too weak for this application. It also points out that a similar TCP > option with a stronger hashing algorithm (it cites SHA-1 as an example) > could be deployed. To our knowledge, no such TCP option has been defined > and deployed. However, we note that LDP can use whatever TCP message > digest techniques are available, and when one stronger than MD5 is > specified and implemented, upgrading LDP to use it would be relatively > straightforward." > > We note that BGP has already been through this process, and replaced MD5 > with TCP-AO in RFC 7454. I would be logical to follow the same approach t= o > secure LDP. However, as far as we are able to ascertain, there is current= ly > no recommended, mandatory to implement, cryptographic function specified. > We are concerned that without such a mandatory function, implementations > will simply fall back to MD5 and we will be no further forward > > We think that the best way forward is to publish a draft similar to RFC > 7454 that contains the following requirement: > > "Implementations conforming to this RFC MUST implement TCP-AO to secure > the TCP sessions carrying LDP in addition to the currently required TCP M= D5 > Signature Option. Furthermore, the TBD cryptographic mechanism must be > implemented and provided to TCP-AO to secure LDP messages. The TBD > mechanism is the preferred option, and MD5 is only to be used when TBD is > unavailable." > > We are not an experts on this part of the stack, but it seems that TCP > security negotiation is still work in progress. If we are wrong, then we > need to include a requirement that such negotiation is also required. In > the absence of a negotiation protocol, however, we need to leave this as = a > configuration process until such time as the negotiation protocol work is > complete. On completion of a suitable negotiation protocol we need to iss= ue > a further update requiring its use. > > Additionally we should note that no cryptographic mechanism has an > indefinite lifetime, and that implementation should note the IETF > anticipates updating the default cryptographic mechanism over time. > > The TBD default security function will need to be chosen such that it can > reasonably be implemented on a typical router route processor, and which > will provide adequate security without significantly degrading the > convergence time of an LSR. Without a function that does not significantl= y > impact router convergence we simply close one vulnerability and open > another. > > As experts on the LDP protocol, but not on security mechanisms, we need > to ask the security area for a review of our proposed approach, and help > correcting any misunderstanding of the security issues or our > misunderstanding of the existing security mechanisms. We also need the > recommendations of a suitable security function (TBD in the above text). > > Best regards > > The MPLS WG Chairs > The PALS WG Chairs > > > > > > > --94eb2c079026c30986055d821d85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't understand what you're getting at here. Ye= s, if people have TCP-AO then presumably they have SHA-1.

But now we're talking about requiring people to have TCP-AO in this c= ase, so we should try to move them to SHA-256 at the time we require AO.

-Ekr


On Wed, Nov 8, 2017 at = 4:14 PM, Uma Chunduri <uma.chunduri@huawei.com> wrote:=

From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Wednesday, November 08, 2017 3:53 PM

=C2=A0

=C2=A0

=C2=A0

On Wed, Nov 8, 2017 at 3:50 PM, Uma Chunduri <uma.chunduri@huaw= ei.com> wrote:

In-line [Uma1]:=

--

Uma C.

=C2=A0

From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Wednesday, November 08, 2017 12:53 PM
To: Uma Chunduri <uma.chunduri@huawei.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>; mpls@ietf.org; pals-chairs@tools.ietf.org; <rtg-ads@ietf.org> <rtg-ads@ietf.org>; mpls-chairs@ietf.= org; pals@ietf.org; <sec-ads@ietf.org> <sec-ads@ietf.org>


Subject: Re: [mpls] LDP Security

=C2=A0

=C2=A0

=C2=A0

On Wed, Nov 8, 2017 at 11:57 AM, Uma Chunduri <uma.chunduri@hua= wei.com> wrote:

Hi Stewart,<= /p>

=C2=A0

I would note h= ttps://tools.ietf.org/html/rfc6952 - where LDP security is analyzed from all aspects.

=C2=A0

Eric,

=C2=A0

Quick comments below [Uma]:=

=C2=A0

--

Uma C.

=C2=A0

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Wednesday, November 08, 2017 10:00 AM
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: mpls@ietf.org= ; pals-chairs@tools.ietf.org; <rtg-ads@ietf.org> <rtg-ads@ietf.org>; mpls-chairs@ietf.= org; pals@ietf.org; <sec-ads@ietf.org> <sec-ads@ietf.org>
Subject: Re: [mpls] LDP Security

=C2=A0

Hi Stewart

=C2=A0

Thanks for your note.

=C2=A0

My overall sense of the state of play is, I think mu= ch like yours.

=C2=A0

TCP-MD5 is inadequate in two major respects:<= u>

- It uses weak algorithms

- It has a bad negotiation/setuop story (manual key = management)

=C2=A0

TCP-AO is intended to be a drop-in replacement for T= CP-MD5 and so remedies the algorithm

Issue

=C2=A0

[Uma]: Yes, if we go with RFC 5926 ma= ndatory list..

=C2=A0

but not the key management issue [0]. We haven't= made much progress on the key

management story, and that seems to be a major imped= iment to deploying either of these

technologies (which I am given to understand don'= ;t see a lot of use).

=C2=A0

[Uma]: True.

=C2=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=A0But I would indicate = some effort done few years back regarding key management for pair wise routing protocols (BGP, LDP, PCEP, MSDP ..).

=C2=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=A0One such proposal is = by extending IKEv2 to negotiate TCP-AO MKTs (which can give rekey & algo. agility) - https://tools.ietf.org/html/dr= aft-mahesh-karp-rkmp-05=C2=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=A0This also requires so= me more work with TCP-AO; me & Joe put together https://www.ietf.org/archive/<= wbr>id/draft-chunduri-karp-using-ikev2-with-tcp-ao-06.txt

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0Note the above didn=E2=80=99t progress in the= concluded KARP WG (not fully sure the reasons on why).

=C2=A0

Yeah, I know that people tried to do this, but my im= pression was it kinda didn't progress much.

=C2=A0

=C2=A0

=C2=A0

We should probably talk in Singapore about that, but that's not going to get better= any time soon.

=C2=A0

In the interim, I think the text you have is OK, and= "TBD" should read "SHA-256", with

the fallback being SHA-256 -> SHA-1 -> MD5.=

=C2=A0

[Uma]: While the list can be extended= - I didn=E2=80=99t see SHA256 in the mandatory list in RFC 5926 for MAC.

=C2=A0

Generally we're trying to move away from SHA-1 t= owards SHA-256.

=C2=A0

[Uma1]: Couple of things:

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Nothing to be done (from spec pov of course): Use TCP-AO (instead of current MD5) with the RFC 5926 mandated MACs/KDFs =E2=80=93 so the =E2=80=98TBD=E2=80= =99 in Stewart suggesting below is already there.

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 As #1 too is not good enough from your above note - d= o SHA-256 and live with it (no algorithm agility). Still a security benefit= in one way from existing stuff or even =C2=A0#1.

I'm not sure why you say "no algorithm agil= ity". You'd be using AO, just with a different algorithm than SHA-= 1. AES-CMAC is still fine as far as I know.

[Uma2]: Sure, you have it= , if you use AO;

=C2=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=A0But then = =C2=A0I am not getting how we can mandate one MUST implement algorithm as s= uggested below TBD=C2=A0 would actually work =C2=A0(especially - *if= * #1 is already deployed somewhere?)=C2=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=A0Perhaps s= taying with #1 is the best bet or do negotiation through #3, with already m= andated and additional stuff.=C2=A0=C2=A0=C2=A0

=C2=A0

-Ekr

=C2=A0

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Do key management and =E2=80=9Ctheoretically=E2=80=9D= get all we wanted=E2=80=A6.

=C2=A0

We have been here multiple times; bec= ause #1 itself is not *mostly* deployed (neither in BGP nor in LDP) if there is any appetite for #2 and #3 for practical deploymen= ts. But still it may be good to do #2 any ways.

=C2=A0

=C2=A0

-Ekr

=C2=A0

=C2=A0

-Ekr

=C2=A0

=C2=A0

[0] Technically It has better support for rollover, = but this is not a huge improvement.

[1] tcpcrypt is kind of orthogonal here as it's = unauthenticated but opportunistic.=C2=A0 That said,

it would provide defense against attackers who gain = access to the link after connection

setup and doesn't require configuration.<= u>

=C2=A0

On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant <<= a href=3D"mailto:stewart.bryant@gmail.com" target=3D"_blank">stewart.bryant= @gmail.com> wrote:

To the SEC and RTG AD= s,

I am sending the following message on behalf of the MPLS and the
PALS WG Chairs.

There is a concern shared among the security community and the working grou= ps that develop the LDP protocol that LDP is no longer adequately secured. = LDP currently relies on MD5 for cryptographic security of its messages, but= MD5 is a hash function that is no longer considered to meet current security requirements.

In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2. Sessio= n communication carried by TCP the following statements is made:

"LDP specifies use of the TCP MD5 Signature Option to provide for the = authenticity and integrity of session messages.

"[RFC2385] asserts that MD5 authentication is now considered by some t= o be too weak for this application.=C2=A0 It also points out that a similar= TCP option with a stronger hashing algorithm (it cites SHA-1 as an example= ) could be deployed.=C2=A0 To our knowledge, no such TCP option has been defined and deployed.=C2=A0 However, we note that= LDP can use whatever TCP message digest techniques are available, and when= one stronger than MD5 is specified and implemented, upgrading LDP to use i= t would be relatively straightforward."

We note that BGP has already been through this process, and replaced MD5 wi= th TCP-AO in RFC 7454. I would be logical to follow the same approach to se= cure LDP. However, as far as we are able to ascertain, there is currently n= o recommended, mandatory to implement, cryptographic function specified. We are concerned that without such a man= datory function, implementations will simply fall back to MD5 and we will b= e no further forward

We think that the best way forward is to publish a draft similar to RFC 745= 4 that contains the following requirement:

"Implementations conforming to this RFC MUST implement TCP-AO to secur= e the TCP sessions carrying LDP in addition to the currently required TCP M= D5 Signature Option. Furthermore, the TBD cryptographic mechanism must be i= mplemented and provided to TCP-AO to secure LDP messages. The TBD mechanism is the preferred option, and MD5 is= only to be used when TBD is unavailable."

We are not an experts on this part of the stack, but it seems that TCP secu= rity negotiation is still work in progress. If we are wrong, then we need t= o include a requirement that such negotiation is also required. In the abse= nce of a negotiation protocol, however, we need to leave this as a configuration process until such time as the ne= gotiation protocol work is complete. On completion of a suitable negotiatio= n protocol we need to issue a further update requiring its use.

Additionally we should note that no cryptographic mechanism has an indefini= te lifetime, and that implementation should note the IETF anticipates updat= ing the default cryptographic mechanism over time.

The TBD default security function will need to be chosen such that it can r= easonably be implemented on a typical router route processor, and which wil= l provide adequate security without significantly degrading the convergence= time of an LSR. Without a function that does not significantly impact router convergence we simply close one = vulnerability and open another.

As experts on the LDP protocol, but not on security mechanisms, we=C2=A0 ne= ed to ask the security area for a review of our proposed approach, and help= correcting any misunderstanding of the security issues or our misunderstan= ding of the existing security mechanisms. We also need the recommendations of a suitable security function (TBD in t= he above text).

Best regards

The MPLS WG Chairs
The PALS WG Chairs

=C2=A0

=C2=A0

=C2=A0


--94eb2c079026c30986055d821d85-- From nobody Wed Nov 8 17:09:18 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227FE129454; Wed, 8 Nov 2017 17:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzHVeseU4c0O; Wed, 8 Nov 2017 17:09:10 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF41124B0A; Wed, 8 Nov 2017 17:09:08 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSF97809; Thu, 09 Nov 2017 01:09:06 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 9 Nov 2017 01:09:05 +0000 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.92]) by SJCEML703-CHM.china.huawei.com ([169.254.5.27]) with mapi id 14.03.0361.001; Wed, 8 Nov 2017 17:09:00 -0800 From: Uma Chunduri To: Eric Rescorla CC: Stewart Bryant , "mpls@ietf.org" , "pals-chairs@tools.ietf.org" , "" , "mpls-chairs@ietf.org" , "pals@ietf.org" , "" Thread-Topic: [mpls] LDP Security Thread-Index: AQHTWLbyOfMae53/m0ycVXrEQ0bS1aMLS2UA//+SrUCAAJ2kAP//pwtQgACLTYD//3zyYAASL0EAABBVDTA= Date: Thu, 9 Nov 2017 01:09:00 +0000 Message-ID: <25B4902B1192E84696414485F57268541351927E@sjceml521-mbs.china.huawei.com> References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <5994f353-5306-0fa8-2d2d-024ebdbb10df@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> <25B4902B1192E84696414485F57268541351915D@sjceml521-mbs.china.huawei.com> <25B4902B1192E84696414485F5726854135191D6@sjceml521-mbs.china.huawei.com> <25B4902B1192E84696414485F572685413519209@sjceml521-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.168] Content-Type: multipart/alternative; boundary="_000_25B4902B1192E84696414485F57268541351927Esjceml521mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5A03AAB3.002A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.92, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 634434b33b0df36ee4730f969fec6de7 Archived-At: Subject: Re: [Pals] [mpls] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 01:09:12 -0000 --_000_25B4902B1192E84696414485F57268541351927Esjceml521mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQo+QnV0IG5vdyB3ZSdyZSB0YWxraW5nIGFib3V0IHJlcXVpcmluZyBwZW9wbGUgdG8gaGF2ZSBU Q1AtQU8gaW4gdGhpcyBjYXNlLCBzbyB3ZSBzaG91bGQgdHJ5IHRvIG1vdmUgdGhlbSB0byBTSEEt MjU2IGF0IHRoZSB0aW1lIHdlIHJlcXVpcmUgQU8uDQoNCkFzIGRpc2N1c3NlZCB0aGlzIGlzIG5v bi1leGlzdGVudCBhcyBmYXIgYXMgQU8gaXMgY29uY2VybmVkIChhcyBvZiB0b2RheSk7IHNvIGlm IHdlIG91Z2h0IHRvIG1hbmRhdGUgdGhpcyB3aXRoIFRCRCBsYW5ndWFnZSBhcyBpbmRpY2F0ZWQt IGZpcnN0IHRoaXMgaGFzIHRvIGJlIGFkZGVkIGFuZCBhc3N1bWUgbm8gYm9keSBkZXBsb3llZCBB Ty4NCg0KDQotLQ0KVW1hIEMuDQo= --_000_25B4902B1192E84696414485F57268541351927Esjceml521mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tNDQ4NzI4MjMzNzk3MzM5NjM0M205MjAxMzkyOTk2NjA0 NTUzMTQwbXNvbGlzdHBhcmFncmFwaCwgbGkubTQ0ODcyODIzMzc5NzMzOTYzNDNtOTIwMTM5Mjk5 NjYwNDU1MzE0MG1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tNDQ4NzI4MjMzNzk3MzM5NjM0M205MjAx MzkyOTk2NjA0NTUzMTQwbXNvbGlzdHBhcmFncmFwaA0KCXttc28tc3R5bGUtbmFtZTptXzQ0ODcy ODIzMzc5NzMzOTYzNDNtOTIwMTM5Mjk5NjYwNDU1MzE0MG1zb2xpc3RwYXJhZ3JhcGg7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDouNWluIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5CdXQgbm93IHdlJ3JlIHRhbGtpbmcgYWJvdXQgcmVxdWly aW5nIHBlb3BsZSB0byBoYXZlIFRDUC1BTyBpbiB0aGlzIGNhc2UsIHNvIHdlIHNob3VsZCB0cnkg dG8gbW92ZSB0aGVtIHRvIFNIQS0yNTYgYXQgdGhlIHRpbWUgd2UgcmVxdWlyZSBBTy48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5BcyBkaXNjdXNzZWQgdGhpcyBpcyBub24tZXhpc3RlbnQgYXMgZmFyIGFzIEFPIGlz IGNvbmNlcm5lZCAoYXMgb2YgdG9kYXkpOyBzbyBpZiB3ZSBvdWdodCB0byBtYW5kYXRlIHRoaXMg d2l0aCBUQkQgbGFuZ3VhZ2UgYXMgaW5kaWNhdGVkLSBmaXJzdCB0aGlzIGhhcyB0byBiZQ0KIGFk ZGVkIGFuZCBhc3N1bWUgbm8gYm9keSBkZXBsb3llZCBBTy4gPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LS08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+VW1hIEMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_25B4902B1192E84696414485F57268541351927Esjceml521mbschi_-- From nobody Wed Nov 8 17:14:23 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58FB129524 for ; Wed, 8 Nov 2017 17:14:21 -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_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 LSrpcc0ijnwU for ; Wed, 8 Nov 2017 17:14:20 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 A302B1294E8 for ; Wed, 8 Nov 2017 17:14:18 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id y75so3991848ywg.0 for ; Wed, 08 Nov 2017 17:14:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nRIkitXe2Y13jw1msRczuU6dhA/gjDp7NfzGyQlAnq4=; b=nTt/Aitc56WYe3JqimiXuFZjbp7JFf1UD+2MTVtcKwm2Osdq48OmuXr4s/pQSv3flW sIv9gZcSoroU6OIdFd+19Lc13+c4iwg1BG6pcPLHwvfwBgRhB1XwVMhi91HyAoFU1Ad5 IP7FD/6amYs8Q9lXLAORs4SEyWmFICJEA7STGsHa9fRkFC9RkDMAHUaed5s8aZ38FtJJ v3wi5KtIaxi6NYeAmBcLb9ouwcga5H5/uA5v7gObefPM/YBtVaPRIaVpJPj+RKzE+YI9 LIhsVLpm5drwrJta0uoKDyy1fUqLmqqPIQfPTlc5338pEX0e4elylMpomctuFdW9zxps 1kcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nRIkitXe2Y13jw1msRczuU6dhA/gjDp7NfzGyQlAnq4=; b=fj1y6YcPKxSbjB4WkfHvL6Z40mhaiY/6cFXBPTNpGyZp+NUm5g+ZbxBb5UbFw8Eet0 otuVhkHo6tKiv4YFlz+ixzVMzfswtkiunQ/sGBkUJa3AQKhV3A7TdvuhPCN1VOv/tKtJ njRNGSYEVo24RHwq0v4ZbJyUBmrbi3RuLY7KNIEBj/baze39Lk6rmcm3naONVajBGhIR 9ud+MhoE/QcjgmSDrJJ23Bp8Gpz6aKp2l6S2J3IlNHiJLL6SvvyGid0EtTSzFgpKIOqG fd9GRM83QD9ouf6sKCed/mIgWyj7oZ/IS9TmgQqgP9rEh7t2OSpDkWTUNcl/VoRLvucv BEng== X-Gm-Message-State: AJaThX5P+8Y8IdKKRSHjmhXPUkZ5EFpZOfQ3J3II4FE0n5Ozsir4+JoE vAUlKUCmesjj3dD2cajY1z6V8NNg59aqRaDSAiTfHA== X-Google-Smtp-Source: ABhQp+ROTbW9eQALb756r1RnELtC3Nge43LC15wGNR//RcWJtfq9hfVRKTjapq+ux0pYFdNbCm8AfRfVQyXJLIQH+FI= X-Received: by 10.129.36.1 with SMTP id k1mr1618548ywk.485.1510190057836; Wed, 08 Nov 2017 17:14:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Wed, 8 Nov 2017 17:13:37 -0800 (PST) In-Reply-To: <25B4902B1192E84696414485F57268541351927E@sjceml521-mbs.china.huawei.com> References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <5994f353-5306-0fa8-2d2d-024ebdbb10df@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> <25B4902B1192E84696414485F57268541351915D@sjceml521-mbs.china.huawei.com> <25B4902B1192E84696414485F5726854135191D6@sjceml521-mbs.china.huawei.com> <25B4902B1192E84696414485F572685413519209@sjceml521-mbs.china.huawei.com> <25B4902B1192E84696414485F57268541351927E@sjceml521-mbs.china.huawei.com> From: Eric Rescorla Date: Wed, 8 Nov 2017 17:13:37 -0800 Message-ID: To: Uma Chunduri Cc: Stewart Bryant , "mpls@ietf.org" , "pals-chairs@tools.ietf.org" , "" , "mpls-chairs@ietf.org" , "pals@ietf.org" , "" Content-Type: multipart/alternative; boundary="001a1142e4ccf10165055d828599" Archived-At: Subject: Re: [Pals] [mpls] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 01:14:22 -0000 --001a1142e4ccf10165055d828599 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 8, 2017 at 5:09 PM, Uma Chunduri wrote: > > > >But now we're talking about requiring people to have TCP-AO in this > case, so we should try to move them to SHA-256 at the time we require AO. > > > > As discussed this > What is "this"? -Ekr > is non-existent as far as AO is concerned (as of today); so if we ought to > mandate this with TBD language as indicated- first this has to be added and > assume no body deployed AO. > > > > > > -- > > Uma C. > --001a1142e4ccf10165055d828599 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Wed, Nov 8, 2017 at 5:09 PM, Uma Chunduri <uma.chunduri@huawei.c= om> wrote:

=C2=A0

>But now we're talking about requiring people to have TC= P-AO in this case, so we should try to move them to SHA-256 at the time we = require AO.

=C2=A0

As discussed this

<= /div>

What is "this&= quot;?

-Ekr
=C2=A0

is non-existent as far as AO is concerned (as of today); so if= we ought to mandate this with TBD language as indicated- first this has to= be added and assume no body deployed AO.

=C2=A0

=C2=A0

--

Uma C.


--001a1142e4ccf10165055d828599-- From nobody Wed Nov 8 17:16:43 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42511294F3; Wed, 8 Nov 2017 17:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8miuNrCh6Ln; Wed, 8 Nov 2017 17:16:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 052C212711D; Wed, 8 Nov 2017 17:16:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DZK82945; Thu, 09 Nov 2017 01:16:37 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 9 Nov 2017 01:16:36 +0000 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.92]) by SJCEML702-CHM.china.huawei.com ([169.254.4.145]) with mapi id 14.03.0361.001; Wed, 8 Nov 2017 17:16:31 -0800 From: Uma Chunduri To: Eric Rescorla CC: Stewart Bryant , "mpls@ietf.org" , "pals-chairs@tools.ietf.org" , "" , "mpls-chairs@ietf.org" , "pals@ietf.org" , "" Thread-Topic: [mpls] LDP Security Thread-Index: AQHTWLbyOfMae53/m0ycVXrEQ0bS1aMLS2UA//+SrUCAAJ2kAP//pwtQgACLTYD//3zyYAASL0EAABBVDTD//4V8gIAAharw Date: Thu, 9 Nov 2017 01:16:30 +0000 Message-ID: <25B4902B1192E84696414485F572685413519297@sjceml521-mbs.china.huawei.com> References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <5994f353-5306-0fa8-2d2d-024ebdbb10df@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> <25B4902B1192E84696414485F57268541351915D@sjceml521-mbs.china.huawei.com> <25B4902B1192E84696414485F5726854135191D6@sjceml521-mbs.china.huawei.com> <25B4902B1192E84696414485F572685413519209@sjceml521-mbs.china.huawei.com> <25B4902B1192E84696414485F57268541351927E@sjceml521-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.168] Content-Type: multipart/alternative; boundary="_000_25B4902B1192E84696414485F572685413519297sjceml521mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5A03AC75.00C6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.92, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 14d312b36b9605c70916f063eabc04c2 Archived-At: Subject: Re: [Pals] [mpls] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 01:16:42 -0000 --_000_25B4902B1192E84696414485F572685413519297sjceml521mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGcm9tOiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tXQ0KU2VudDogV2VkbmVz ZGF5LCBOb3ZlbWJlciAwOCwgMjAxNyA1OjE0IFBNDQpUbzogVW1hIENodW5kdXJpIDx1bWEuY2h1 bmR1cmlAaHVhd2VpLmNvbT4NCkNjOiBTdGV3YXJ0IEJyeWFudCA8c3Rld2FydC5icnlhbnRAZ21h aWwuY29tPjsgbXBsc0BpZXRmLm9yZzsgcGFscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IDxydGct YWRzQGlldGYub3JnPiA8cnRnLWFkc0BpZXRmLm9yZz47IG1wbHMtY2hhaXJzQGlldGYub3JnOyBw YWxzQGlldGYub3JnOyA8c2VjLWFkc0BpZXRmLm9yZz4gPHNlYy1hZHNAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW21wbHNdIExEUCBTZWN1cml0eQ0KDQoNCk9uIFdlZCwgTm92IDgsIDIwMTcgYXQg NTowOSBQTSwgVW1hIENodW5kdXJpIDx1bWEuY2h1bmR1cmlAaHVhd2VpLmNvbTxtYWlsdG86dW1h LmNodW5kdXJpQGh1YXdlaS5jb20+PiB3cm90ZToNCg0KPkJ1dCBub3cgd2UncmUgdGFsa2luZyBh Ym91dCByZXF1aXJpbmcgcGVvcGxlIHRvIGhhdmUgVENQLUFPIGluIHRoaXMgY2FzZSwgc28gd2Ug c2hvdWxkIHRyeSB0byBtb3ZlIHRoZW0gdG8gU0hBLTI1NiBhdCB0aGUgdGltZSB3ZSByZXF1aXJl IEFPLg0KDQpBcyBkaXNjdXNzZWQgdGhpcw0KDQpXaGF0IGlzICJ0aGlzIj8NCg0KU0hBLTI1NiB1 c2FnZSBhcyBhIHBvdGVudGlhbCBNQUMgb3IvYW5kIEtERiBmb3IgQU8uDQoNCi1Fa3INCg0KaXMg bm9uLWV4aXN0ZW50IGFzIGZhciBhcyBBTyBpcyBjb25jZXJuZWQgKGFzIG9mIHRvZGF5KTsgc28g aWYgd2Ugb3VnaHQgdG8gbWFuZGF0ZSB0aGlzIHdpdGggVEJEIGxhbmd1YWdlIGFzIGluZGljYXRl ZC0gZmlyc3QgdGhpcyBoYXMgdG8gYmUgYWRkZWQgYW5kIGFzc3VtZSBubyBib2R5IGRlcGxveWVk IEFPLg0KDQoNCi0tDQpVbWEgQy4NCg0K --_000_25B4902B1192E84696414485F572685413519297sjceml521mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gRXJpYyBSZXNjb3JsYSBbbWFpbHRvOmVrckBydGZtLmNvbV0N Cjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE5vdmVtYmVyIDA4LCAyMDE3IDU6MTQgUE08 YnI+DQo8Yj5Ubzo8L2I+IFVtYSBDaHVuZHVyaSAmbHQ7dW1hLmNodW5kdXJpQGh1YXdlaS5jb20m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBTdGV3YXJ0IEJyeWFudCAmbHQ7c3Rld2FydC5icnlhbnRAZ21h aWwuY29tJmd0OzsgbXBsc0BpZXRmLm9yZzsgcGFscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7ICZs dDtydGctYWRzQGlldGYub3JnJmd0OyAmbHQ7cnRnLWFkc0BpZXRmLm9yZyZndDs7IG1wbHMtY2hh aXJzQGlldGYub3JnOyBwYWxzQGlldGYub3JnOyAmbHQ7c2VjLWFkc0BpZXRmLm9yZyZndDsgJmx0 O3NlYy1hZHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbXBsc10gTERQ IFNlY3VyaXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwg Tm92IDgsIDIwMTcgYXQgNTowOSBQTSwgVW1hIENodW5kdXJpICZsdDs8YSBocmVmPSJtYWlsdG86 dW1hLmNodW5kdXJpQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj51bWEuY2h1bmR1cmlAaHVh d2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtaW5k ZW50Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+QnV0IG5v dyB3ZSdyZSB0YWxraW5nIGFib3V0IHJlcXVpcmluZyBwZW9wbGUgdG8gaGF2ZSBUQ1AtQU8gaW4g dGhpcyBjYXNlLCBzbyB3ZSBzaG91bGQgdHJ5IHRvIG1vdmUgdGhlbSB0byBTSEEtMjU2IGF0IHRo ZSB0aW1lIHdlIHJlcXVpcmUgQU8uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5BcyBkaXNjdXNzZWQgdGhpcw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XaGF0IGlzICZxdW90O3RoaXMmcXVvdDs/PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlNIQS0yNTYgdXNhZ2UgYXMgYSBwb3RlbnRpYWwgTUFDIG9yL2FuZCBL REYgZm9yIEFPLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aXMgbm9uLWV4aXN0ZW50IGFzIGZhciBhcyBBTyBp cyBjb25jZXJuZWQgKGFzIG9mIHRvZGF5KTsgc28gaWYgd2Ugb3VnaHQgdG8gbWFuZGF0ZSB0aGlz IHdpdGggVEJEIGxhbmd1YWdlDQogYXMgaW5kaWNhdGVkLSBmaXJzdCB0aGlzIGhhcyB0byBiZSBh ZGRlZCBhbmQgYXNzdW1lIG5vIGJvZHkgZGVwbG95ZWQgQU8uIDwvc3Bhbj4NCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ LS08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5VbWEgQy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_25B4902B1192E84696414485F572685413519297sjceml521mbschi_-- From nobody Wed Nov 8 21:15:52 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BADE12EAFC; Wed, 8 Nov 2017 21:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=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 EURksRYG9R68; Wed, 8 Nov 2017 21:15:47 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 C173112EB40; Wed, 8 Nov 2017 21:15:46 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.230.21.53; From: "Susan Hares" To: "'Eric Rescorla'" , "'Uma Chunduri'" Cc: , , , , , References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <5994f353-5306-0fa8-2d2d-024ebdbb10df@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> <25B4902B1192E84696414485F572 68541351915D@s jceml521-mbs.china.huawei.com> <25B4902B1192E84696414485F5726854135191D6@sjceml521-mbs.china.huawei.com> <25B4902B1192E84696414485F572685413519209@sjceml521-mbs.china.huawei.com> In-Reply-To: Date: Thu, 9 Nov 2017 00:15:34 -0500 Message-ID: <002101d35919$c6295b90$527c12b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01D358EF.DD56FD10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHQ4LkDJ6Z/J5TaTb+XshLIa/JnkwFbRp7YAmwCdnMA/HavIAGkQiT3AY0bhdsBndke1AMFAIO+ARBf2LkCdM8cTgI5zEjPANLg1FoCskmr1QJotocDAdpri4gCKx0VhQNlnZqeAuEitKUBRMy6pQJqBPgpAfaobakCIS5j5QGMVIqeobFOk1A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Pals] [mpls] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 05:15:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0022_01D358EF.DD56FD10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Eric:=20 =20 BGP and LDP would be more secure if TCP-AO deployed with all BGP and LDP = =E2=80=93 but there are issues with customer pick-up and deployment of = these protocols on many networks. I wished we had TCP-AO when BGP = started, but we did not.=20 =20 Some of the least secure BGP is in data centers =E2=80=93 where the DC = providers say =E2=80=9CIt=E2=80=99s all under one = administration=E2=80=9D. Another problem is on private lines. We = should chat about the networks each of these protocols are actually = deployed on. If you have any insight on a way to encourage adoption, = I=E2=80=99d love to hear it. Require TCP-AO does not really mean = anything if providers and Data Centers do not adopt it. =20 =20 Going from SHA-1 to SHA-256 on a TCP-AO is simple upgrade compared to = getting people to TCP-AO. =20 =20 Sue=20 =20 From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Wednesday, November 8, 2017 7:44 PM To: Uma Chunduri Cc: mpls@ietf.org; pals-chairs@tools.ietf.org; ; = mpls-chairs@ietf.org; pals@ietf.org; Subject: Re: [mpls] LDP Security =20 I don't understand what you're getting at here. Yes, if people have = TCP-AO then presumably they have SHA-1. =20 But now we're talking about requiring people to have TCP-AO in this = case, so we should try to move them to SHA-256 at the time we require = AO. =20 -Ekr =20 =20 On Wed, Nov 8, 2017 at 4:14 PM, Uma Chunduri = wrote: From: Eric Rescorla [mailto:ekr@rtfm.com]=20 Sent: Wednesday, November 08, 2017 3:53 PM To: Uma Chunduri Cc: Stewart Bryant ; mpls@ietf.org; = pals-chairs@tools.ietf.org; ; = mpls-chairs@ietf.org; pals@ietf.org; = Subject: Re: [mpls] LDP Security =20 =20 =20 On Wed, Nov 8, 2017 at 3:50 PM, Uma Chunduri = wrote: In-line [Uma1]: -- Uma C. =20 From: Eric Rescorla [mailto: ekr@rtfm.com]=20 Sent: Wednesday, November 08, 2017 12:53 PM To: Uma Chunduri < = uma.chunduri@huawei.com> Cc: Stewart Bryant < = stewart.bryant@gmail.com>; mpls@ietf.org; = pals-chairs@tools.ietf.org; < = rtg-ads@ietf.org> < = rtg-ads@ietf.org>; mpls-chairs@ietf.org; = pals@ietf.org; < = sec-ads@ietf.org> < sec-ads@ietf.org> Subject: Re: [mpls] LDP Security =20 =20 =20 On Wed, Nov 8, 2017 at 11:57 AM, Uma Chunduri = wrote: Hi Stewart, =20 I would note = https://tools.ietf.org/html/rfc6952 - where LDP security is analyzed = from all aspects.=20 =20 Eric, =20 Quick comments below [Uma]: =20 -- Uma C. =20 From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Wednesday, November 08, 2017 10:00 AM To: Stewart Bryant Cc: mpls@ietf.org; pals-chairs@tools.ietf.org; = ; mpls-chairs@ietf.org; pals@ietf.org; = Subject: Re: [mpls] LDP Security =20 Hi Stewart =20 Thanks for your note. =20 My overall sense of the state of play is, I think much like yours. =20 TCP-MD5 is inadequate in two major respects: - It uses weak algorithms - It has a bad negotiation/setuop story (manual key management) =20 TCP-AO is intended to be a drop-in replacement for TCP-MD5 and so = remedies the algorithm Issue =20 [Uma]: Yes, if we go with RFC 5926 mandatory list.. =20 but not the key management issue [0]. We haven't made much progress on = the key management story, and that seems to be a major impediment to deploying = either of these technologies (which I am given to understand don't see a lot of use).=20 =20 [Uma]: True.=20 But I would indicate some effort done few years back = regarding key management for pair wise routing protocols (BGP, LDP, = PCEP, MSDP ..).=20 One such proposal is by extending IKEv2 to negotiate = TCP-AO MKTs (which can give rekey & algo. agility) - = https://tools.ietf.org/html/draft-mahesh-karp-rkmp-05 =20 This also requires some more work with TCP-AO; me & Joe = put together = https://www.ietf.org/archive/id/draft-chunduri-karp-using-ikev2-with-tcp-= ao-06.txt=20 Note the above didn=E2=80=99t progress in the concluded KARP = WG (not fully sure the reasons on why). =20 Yeah, I know that people tried to do this, but my impression was it = kinda didn't progress much. =20 =20 =20 We should probably talk in Singapore about that, but that's not going to = get better any time soon. =20 In the interim, I think the text you have is OK, and "TBD" should read = "SHA-256", with the fallback being SHA-256 -> SHA-1 -> MD5. =20 [Uma]: While the list can be extended - I didn=E2=80=99t see SHA256 in = the mandatory list in RFC 5926 for MAC. =20 Generally we're trying to move away from SHA-1 towards SHA-256. =20 [Uma1]: Couple of things: 1. Nothing to be done (from spec pov of course): Use TCP-AO = (instead of current MD5) with the RFC 5926 mandated MACs/KDFs =E2=80=93 = so the =E2=80=98TBD=E2=80=99 in Stewart suggesting below is already = there.=20 2. As #1 too is not good enough from your above note - do SHA-256 = and live with it (no algorithm agility). Still a security benefit in one = way from existing stuff or even #1. I'm not sure why you say "no algorithm agility". You'd be using AO, just = with a different algorithm than SHA-1. AES-CMAC is still fine as far as = I know. [Uma2]: Sure, you have it, if you use AO;=20 But then I am not getting how we can mandate one MUST = implement algorithm as suggested below TBD would actually work = (especially - *if* #1 is already deployed somewhere?) =20 Perhaps staying with #1 is the best bet or do = negotiation through #3, with already mandated and additional stuff. =20 =20 -Ekr =20 3. Do key management and =E2=80=9Ctheoretically=E2=80=9D get all = we wanted=E2=80=A6. =20 We have been here multiple times; because #1 itself is not *mostly* = deployed (neither in BGP nor in LDP) if there is any appetite for #2 and = #3 for practical deployments. But still it may be good to do #2 any = ways. =20 =20 -Ekr =20 =20 -Ekr =20 =20 [0] Technically It has better support for rollover, but this is not a = huge improvement. [1] tcpcrypt is kind of orthogonal here as it's unauthenticated but = opportunistic. That said, it would provide defense against attackers who gain access to the link = after connection setup and doesn't require configuration. =20 On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant = wrote: To the SEC and RTG ADs, I am sending the following message on behalf of the MPLS and the PALS WG Chairs. There is a concern shared among the security community and the working = groups that develop the LDP protocol that LDP is no longer adequately = secured. LDP currently relies on MD5 for cryptographic security of its = messages, but MD5 is a hash function that is no longer considered to = meet current security requirements. In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2. = Session communication carried by TCP the following statements is made: "LDP specifies use of the TCP MD5 Signature Option to provide for the = authenticity and integrity of session messages. "[RFC2385] asserts that MD5 authentication is now considered by some to = be too weak for this application. It also points out that a similar TCP = option with a stronger hashing algorithm (it cites SHA-1 as an example) = could be deployed. To our knowledge, no such TCP option has been = defined and deployed. However, we note that LDP can use whatever TCP = message digest techniques are available, and when one stronger than MD5 = is specified and implemented, upgrading LDP to use it would be = relatively straightforward." We note that BGP has already been through this process, and replaced MD5 = with TCP-AO in RFC 7454. I would be logical to follow the same approach = to secure LDP. However, as far as we are able to ascertain, there is = currently no recommended, mandatory to implement, cryptographic function = specified. We are concerned that without such a mandatory function, = implementations will simply fall back to MD5 and we will be no further = forward We think that the best way forward is to publish a draft similar to RFC = 7454 that contains the following requirement: "Implementations conforming to this RFC MUST implement TCP-AO to secure = the TCP sessions carrying LDP in addition to the currently required TCP = MD5 Signature Option. Furthermore, the TBD cryptographic mechanism must = be implemented and provided to TCP-AO to secure LDP messages. The TBD = mechanism is the preferred option, and MD5 is only to be used when TBD = is unavailable." We are not an experts on this part of the stack, but it seems that TCP = security negotiation is still work in progress. If we are wrong, then we = need to include a requirement that such negotiation is also required. In = the absence of a negotiation protocol, however, we need to leave this as = a configuration process until such time as the negotiation protocol work = is complete. On completion of a suitable negotiation protocol we need to = issue a further update requiring its use. Additionally we should note that no cryptographic mechanism has an = indefinite lifetime, and that implementation should note the IETF = anticipates updating the default cryptographic mechanism over time. The TBD default security function will need to be chosen such that it = can reasonably be implemented on a typical router route processor, and = which will provide adequate security without significantly degrading the = convergence time of an LSR. Without a function that does not = significantly impact router convergence we simply close one = vulnerability and open another. As experts on the LDP protocol, but not on security mechanisms, we need = to ask the security area for a review of our proposed approach, and help = correcting any misunderstanding of the security issues or our = misunderstanding of the existing security mechanisms. We also need the = recommendations of a suitable security function (TBD in the above text). Best regards The MPLS WG Chairs The PALS WG Chairs =20 =20 =20 =20 ------=_NextPart_000_0022_01D358EF.DD56FD10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Eric:

 

BGP and LDP would be more secure if TCP-AO deployed with all BGP and = LDP =E2=80=93 but there are issues with customer pick-up and deployment = of these protocols on many networks.=C2=A0 I wished we had TCP-AO when = BGP started, but we did not.

 

Some of the least secure BGP is in data centers =E2=80=93 where the = DC providers say =E2=80=9CIt=E2=80=99s all under one = administration=E2=80=9D.=C2=A0 Another problem is on private = lines.=C2=A0=C2=A0 =C2=A0We should chat about the networks each of these = protocols are actually deployed on.=C2=A0 =C2=A0If you have any insight = on a way to encourage adoption, I=E2=80=99d love to hear it. Require = TCP-AO does not really mean anything if providers and Data Centers do = not adopt it. =C2=A0

 

Going from SHA-1 to SHA-256 on a TCP-AO is simple upgrade compared to = getting people to TCP-AO. =C2=A0=C2=A0

 

Sue

 

From:= = mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric = Rescorla
Sent: Wednesday, November 8, 2017 7:44 = PM
To: Uma Chunduri
Cc: mpls@ietf.org; = pals-chairs@tools.ietf.org; <rtg-ads@ietf.org>; = mpls-chairs@ietf.org; pals@ietf.org; = <sec-ads@ietf.org>
Subject: Re: [mpls] LDP = Security

 

I don't = understand what you're getting at here. Yes, if people have TCP-AO then = presumably they have SHA-1.

 

But now we're talking about requiring people to have = TCP-AO in this case, so we should try to move them to SHA-256 at the = time we require AO.

 

-Ekr

 

 

On Wed, = Nov 8, 2017 at 4:14 PM, Uma Chunduri <uma.chunduri@huawei.com> = wrote:

From: Eric = Rescorla [mailto:ekr@rtfm.com]
Sent: Wednesday, November = 08, 2017 3:53 PM

 <= /o:p>

 <= /o:p>

 <= /o:p>

On Wed, Nov = 8, 2017 at 3:50 PM, Uma Chunduri <uma.chunduri@huawei.com> = wrote:

In-line [Uma1]:

--

Uma C.

 

From: Eric = Rescorla [mailto:ekr@rtfm.co= m] =
Sent: Wednesday, November 08, 2017 12:53 PM
To: Uma = Chunduri <uma.chundur= i@huawei.com>
= Cc: Stewart Bryant <stewart.bry= ant@gmail.com>; = mpls@ietf.o= rg; = pals-chairs= @tools.ietf.org; = <rtg-ads@iet= f.org> = <rtg-ads@iet= f.org>; = mpls-chairs= @ietf.org; = pals@ietf.o= rg; = <sec-ads@iet= f.org> = <sec-ads@iet= f.org>=


Subje= ct: Re: [mpls] LDP Security

 <= /o:p>

 <= /o:p>

 <= /o:p>

On Wed, Nov = 8, 2017 at 11:57 AM, Uma Chunduri <uma.chunduri@huawei.com> = wrote:

Hi Stewart,

 

I would note https://too= ls.ietf.org/html/rfc6952 - where LDP security is analyzed from all aspects. =

 

Eric,

 

Quick comments below [Uma]:

 

--

Uma C.

 

From: mpls = [mailto:mpls-bounces@ietf.org] On Behalf Of Eric = Rescorla
Sent: Wednesday, November 08, 2017 10:00 = AM
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: mpls@ietf.org; pals-chairs@tools.ietf.org; <rtg-ads@ietf.org> <rtg-ads@ietf.org>; mpls-chairs@ietf.org; pals@ietf.org; = <sec-ads@ietf.org> <sec-ads@ietf.org>
Subject: Re: [mpls] = LDP Security

 <= /o:p>

Hi = Stewart

 <= /o:p>

Thanks for = your note.

 <= /o:p>

My overall = sense of the state of play is, I think much like = yours.

 <= /o:p>

TCP-MD5 is = inadequate in two major respects:

- It uses = weak algorithms

- It has a = bad negotiation/setuop story (manual key = management)

 <= /o:p>

TCP-AO is = intended to be a drop-in replacement for TCP-MD5 and so remedies the = algorithm

Issue

 

[Uma]: Yes, if we go with RFC 5926 mandatory = list..

 

but not the = key management issue [0]. We haven't made much progress on the = key

management = story, and that seems to be a major impediment to deploying either of = these

technologies= (which I am given to understand don't see a lot of use). =

 

[Uma]: True.

           &nbs= p;   But I would indicate some effort done few years back = regarding key management for pair wise routing protocols (BGP, LDP, = PCEP, MSDP ..).

           &nbs= p;   One such proposal is by extending IKEv2 to negotiate = TCP-AO MKTs (which can give rekey & algo. agility) - https://tools.ietf.org/html/draft-mahesh-karp-rkmp-05 

           &nbs= p;   This also requires some more work with TCP-AO; me = & Joe put together https://www.ietf.org/archive/id/draft-chunduri-karp-usi= ng-ikev2-with-tcp-ao-06.txt

  =          Note the above didn=E2=80=99t progress in the concluded KARP WG (not = fully sure the reasons on = why).

 <= /o:p>

Yeah, I = know that people tried to do this, but my impression was it kinda didn't = progress much.

 <= /o:p>

 <= /o:p>

 

We should = probably talk in Singapore about = that, but that's not going to get better any time soon.

 

In the = interim, I think the text you have is OK, and "TBD" should = read "SHA-256", with

the = fallback being SHA-256 -> SHA-1 -> MD5.

 

[Uma]: While the list can be extended - I didn=E2=80=99t see SHA256 = in the mandatory list in RFC 5926 for = MAC.

 <= /o:p>

Generally = we're trying to move away from SHA-1 towards SHA-256.

 

[Uma1]: Couple of things:

1.     &nb= sp; Nothing to be done (from spec pov of course): Use TCP-AO (instead of current MD5) with the RFC 5926 mandated = MACs/KDFs =E2=80=93 so the =E2=80=98TBD=E2=80=99 in Stewart suggesting = below is already there.

2.     &nb= sp; As #1 too is not good enough from your above note - do SHA-256 and = live with it (no algorithm agility). Still a security benefit in one way = from existing stuff or even =  #1.

I'm not = sure why you say "no algorithm agility". You'd be using AO, = just with a different algorithm than SHA-1. AES-CMAC is still fine as = far as I know.

[Uma2]: Sure, you have it, if you use AO;

           &nbs= p;     But then  I am not getting how we = can mandate one MUST implement algorithm as suggested below TBD  = would actually work  (especially - *if* #1 is already = deployed somewhere?)  

           &nbs= p;     Perhaps staying with #1 is the best bet = or do negotiation through #3, with already mandated and additional = stuff.   

 <= /o:p>

-Ekr

 <= /o:p>

3.     &nb= sp; Do key management and =E2=80=9Ctheoretically=E2=80=9D get all we = wanted=E2=80=A6.

 

We have been here multiple times; because #1 itself is not = *mostly* deployed (neither in BGP nor in LDP) if there is any = appetite for #2 and #3 for practical deployments. But still it may be = good to do #2 any ways.

 

 <= /o:p>

-Ekr

 <= /o:p>

 <= /o:p>

-Ekr

 <= /o:p>

 <= /o:p>

[0] = Technically It has better support for rollover, but this is not a huge = improvement.

[1] = tcpcrypt is kind of orthogonal here as it's unauthenticated but = opportunistic.  That said,

it would = provide defense against attackers who gain access to the link after = connection

setup and = doesn't require configuration.

 <= /o:p>

On Wed, Nov = 8, 2017 at 9:27 AM, Stewart Bryant <stewart.bryant@gmail.com> = wrote:

To the SEC and = RTG ADs,

I am sending the following message on behalf of the MPLS = and the
PALS WG Chairs.

There is a concern shared among the = security community and the working groups that develop the LDP protocol = that LDP is no longer adequately secured. LDP currently relies on MD5 = for cryptographic security of its messages, but MD5 is a hash function = that is no longer considered to meet current security = requirements.

In RFC5036 (published 2007) Section 5.1 (Spoofing) = , List element 2. Session communication carried by TCP the following = statements is made:

"LDP specifies use of the TCP MD5 = Signature Option to provide for the authenticity and integrity of = session messages.

"[RFC2385] asserts that MD5 authentication = is now considered by some to be too weak for this application.  It = also points out that a similar TCP option with a stronger hashing = algorithm (it cites SHA-1 as an example) could be deployed.  To our = knowledge, no such TCP option has been defined and deployed.  = However, we note that LDP can use whatever TCP message digest techniques = are available, and when one stronger than MD5 is specified and = implemented, upgrading LDP to use it would be relatively = straightforward."

We note that BGP has already been through = this process, and replaced MD5 with TCP-AO in RFC 7454. I would be = logical to follow the same approach to secure LDP. However, as far as we = are able to ascertain, there is currently no recommended, mandatory to = implement, cryptographic function specified. We are concerned that = without such a mandatory function, implementations will simply fall back = to MD5 and we will be no further forward

We think that the best = way forward is to publish a draft similar to RFC 7454 that contains the = following requirement:

"Implementations conforming to this = RFC MUST implement TCP-AO to secure the TCP sessions carrying LDP in = addition to the currently required TCP MD5 Signature Option. = Furthermore, the TBD cryptographic mechanism must be implemented and = provided to TCP-AO to secure LDP messages. The TBD mechanism is the = preferred option, and MD5 is only to be used when TBD is = unavailable."

We are not an experts on this part of the = stack, but it seems that TCP security negotiation is still work in = progress. If we are wrong, then we need to include a requirement that = such negotiation is also required. In the absence of a negotiation = protocol, however, we need to leave this as a configuration process = until such time as the negotiation protocol work is complete. On = completion of a suitable negotiation protocol we need to issue a further = update requiring its use.

Additionally we should note that no = cryptographic mechanism has an indefinite lifetime, and that = implementation should note the IETF anticipates updating the default = cryptographic mechanism over time.

The TBD default security = function will need to be chosen such that it can reasonably be = implemented on a typical router route processor, and which will provide = adequate security without significantly degrading the convergence time = of an LSR. Without a function that does not significantly impact router = convergence we simply close one vulnerability and open = another.

As experts on the LDP protocol, but not on security = mechanisms, we  need to ask the security area for a review of our = proposed approach, and help correcting any misunderstanding of the = security issues or our misunderstanding of the existing security = mechanisms. We also need the recommendations of a suitable security = function (TBD in the above text).

Best regards

The MPLS WG = Chairs
The PALS WG Chairs

 <= /o:p>

 <= /o:p>

 <= /o:p>

 

------=_NextPart_000_0022_01D358EF.DD56FD10-- From nobody Thu Nov 9 02:43:24 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4313912F251; Thu, 9 Nov 2017 02:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 xR-L74_ZfaNB; Thu, 9 Nov 2017 02:43:21 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 8A81412ECA0; Thu, 9 Nov 2017 02:43:21 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id 2so6237586qkg.13; Thu, 09 Nov 2017 02:43:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=3nmKhi0htlZs6CV+YSuZzaXTfUGAhn3mIwhRdvrOrwM=; b=AwqCX6at2RWzQq9xyt55oGMi9kjl5UpTGhl+Rv5yk2i7+7j01uh2GJhKzCWtaIgDh9 QnJv1F9n4dvoCJvWIWh0SlFkHQzMYN82Zg4z92srBah+6sVF+ApmOCUL6KiSl1f2hfMm 39MGOm29PqMkZPod6gn1uJTzOGTgyTCuM9RS5Swm0I4oMyAuGNPSc8D99ah8lNkPA/if NUo34NGy+VBgzQ7MEXTuqlm7lZ1vxnNQQbDZ6yUZuBeIJ5XyW6Wm7+JU0I1Ue6UfLogL +mMBSsX2ddvVfBCYFceXCLV5sB+CMSRVMpqlr84V/zOuM0yZwzrCV+qZdmYE+JYntF7E lggQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=3nmKhi0htlZs6CV+YSuZzaXTfUGAhn3mIwhRdvrOrwM=; b=McKd9UFvf6fjTJo0Gim2LeIDAh6Sh31CH3mIWVsaYC4/+wGlbORdnQfCmn5m8NtCXP +m+hNW+XuCHb5gRAg0ka+19tsuQNb+u0rG5LLbuOGi2Qkm5EtQZp+TXh6KnXzoREUCCB /R7TQXUP0z/MSiww4r6pvwlPXT+8PujmfGDjOjFQq/+KURufdmZ2OcPDzEjn/ONc65xo GAMicQpizj8JdqHGEABVSl79wHFR6IAe2V+TtQ0T8s0khrAeA29saz+5IID0JeW7xYq5 qlRBJuxWmYyCvYW8cFgFc5D9wDU/EJgAOMOavFgv9mRtKTyN9nl/rpravsP0rs1LQN9i Hchg== X-Gm-Message-State: AJaThX6uSgjR/ilcDAYXFv+51tabgD5f1ghTt4M4Ti8FC37TN3mBO1x9 TZw3dziNjsD5LTsYcI9cyqU6CViMyiqanDtXiyJ5qw== X-Google-Smtp-Source: AGs4zMarIUVoZljVyofckrZk1naB48K2B/zSdqISAawsi3+jz054ns/at7vc3xZPFaeEPUjgponK9STZCDZNL1M+ADo= X-Received: by 10.233.244.70 with SMTP id z6mr40789qkl.300.1510224200516; Thu, 09 Nov 2017 02:43:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.106.71 with HTTP; Thu, 9 Nov 2017 02:42:49 -0800 (PST) In-Reply-To: <796be686-40ac-e680-0b01-f218e4bd3516@gmail.com> References: <8e6901f8-63ff-008b-ae00-e49620b76769@gmail.com> <796be686-40ac-e680-0b01-f218e4bd3516@gmail.com> From: James Bensley Date: Thu, 9 Nov 2017 10:42:49 +0000 Message-ID: To: Stewart Bryant , draft-ietf-pals-ethernet-cw@ietf.org, "Andrew G. Malis" , "pals@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Pals] draft-ietf-pals-ethernet-cw and enhanced heuristics X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 10:43:23 -0000 On 25 October 2017 at 19:08, Stewart Bryant wrot= e: > RFC6790 ought to be another way to address the problem, but as we noted a > while ago in the SFL work it stops short of mandating DPI type LB. > > I think I therefore agree that we out to just use 6391, after all with th= at > negotiated by both ends it would be rather silly to then do the DPI. > > Not sure if I will get the text done by Monday, but this thread should gi= ve > everyone a heads-up, I will put it on the slides for discussion and if I > don't get the draft out I will put it in some other accessible place. > > - Stewart Hi guys, Sorry I'm late with this response. I think that saying FAT pseudowires or entropy labels SHOULD be used when support is a suitable way forward I believe however, is it worth putting something in the draft about enabling the PWMCW with sequencing? Many devices support pseudowires that don=E2=80=99t support FAT/ELI, is there benefit in adding to the draft, words to the effect of: =E2=80=9Cwhen FAT/ELI isn=E2=80=99t support, PWMCW SHOULD be used with sequ= encing, even though it is known that the CW doesn=E2=80=99t fully resolve the issue= of packet reordering (such as with a XEROX MAC address), for that FAT/ELI is required, but it does greatly reduce the likelihood and when reordering does occur, it provides a mechanism to at least detect it=E2=80= =9D ? I think it is a big problem that the packet reordering is not easily detectable/diagnosable when using just a CW without sequencing. Also on a side note, someone has probably pointed these out already but just in case there are a few typos in the draft; Draft: Since that time the RAC has issued Ethernet MAC addresses start with 0x4 or 0x6 "....starting with..." Draft: used. This document updates RFC4448 [RFC4448] to state that where both both the ingress PE and the egress PE support the Ethernet "... both both..." Draft: as a data packet. This is described in detail section 7 of [RFC6391], and section 6 of RFC6790. "... detail in section 7..." Draft: Email: ibagdona.ietf@gmail.com> "...>" Cheers, James. From nobody Thu Nov 9 07:47:00 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B64A126D05; Thu, 9 Nov 2017 07:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ignzV8Csu8J4; Thu, 9 Nov 2017 07:46:56 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 26EB2126557; Thu, 9 Nov 2017 07:46:56 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id r68so18643374wmr.3; Thu, 09 Nov 2017 07:46:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=boPVOCGEjHXFL1pkLLB2qwuj/nyuY9pwNwMMOHSoLR8=; b=Ranq9GYoJDfqeqMaiDPIj75UP2hRd+JlVDXghtsIMfbUcHYpfqKcpbKVQ83plQbNuP K5UrCUWOz29+f8BV9EArQN3lxVRZLU7XZtljdk5sNzSPYHyRmpdB6XCKFkpNbMwxW2U0 Y8RGFuqYEUvlEB4Vf8GWweNh4jsK/orVoQOo9UToUu5N7hSDYzNsj11A+7yWr48jKfCU RfA8VbkTZ1szVzuatENQ0eRCNfDzgADAzlVeazFlExHEHGDofgNU42Nk5UqGpZ+zAYjm /Os8yDOdgo+5gFiTCasXXFPT3BE6I9RyyYpsznC3oYOKEz/uCVFRJEQ0TrRRPzZ44tD9 E0xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=boPVOCGEjHXFL1pkLLB2qwuj/nyuY9pwNwMMOHSoLR8=; b=C9e1tIM4GOLwEQy5eW/BDCvizt9869FfvOiQGLRlU1QgC6SBJf78yBlKTigE2s6cLE 205pnhBrRk9IbvHB6mOKNOPegS77nIpENViTJn3XPabCSkVyIJAH1tg5NExoJrNfF+lS GuSAQNWBdm5V7Nie6o72lVle+S9Kd4YcNxnH2gZsRXVyR+XRJtIMMPSVlgdioUhLK1bW 4F316yY6ZHIJYaAksNPExQC1WETn33fRTm7PzC4xtOiequMtsrV9jPHM8gahKlXsMVZ/ dGdY9x7qImrnj/yLI/Tkd46IsG6dPyfE66XMHIopZ5XT4z9YN41QGaO2o38qB4sQy1RO yNgg== X-Gm-Message-State: AJaThX6s89mvgTYD6Ghqt/E/szxqtIb5lZieHB7AlKEpJCI1byBP+G5w fm2SC1OdqpWNQgMhkA1PCxF5kg92 X-Google-Smtp-Source: ABhQp+ShtKOXrZFEFFvFbzKOyJDbIKyMdlzNzAUP4hYmtgB1Mkr2Pd+jOKA7meTP7j+qFhfP4agmnQ== X-Received: by 10.80.218.202 with SMTP id s10mr1260106edj.212.1510242414435; Thu, 09 Nov 2017 07:46:54 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id a39sm6606998eda.79.2017.11.09.07.46.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Nov 2017 07:46:53 -0800 (PST) To: James Bensley , draft-ietf-pals-ethernet-cw@ietf.org, "Andrew G. Malis" , "pals@ietf.org" References: <8e6901f8-63ff-008b-ae00-e49620b76769@gmail.com> <796be686-40ac-e680-0b01-f218e4bd3516@gmail.com> From: Stewart Bryant Message-ID: Date: Thu, 9 Nov 2017 15:46:53 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [Pals] draft-ietf-pals-ethernet-cw and enhanced heuristics X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 15:46:58 -0000 Hi James Thank you for your comments. I will look at the detailed editorial points in the next version. However I don't know of any platforms that support CW S/N for Ethernet. In most forwarding architectures it is much easier to add FAT or ELI support than it is to add support for S/N. This is a discussion we are also having in DETNET. Supporting FAT and ELI is a stateless operation that any forwarding architecture I can think of can support. Supporting S/N is stateful. This is hard to so at speed, and may force the implementer to a specific forwarding architecture (egress packet filtering). Given the above I am not in favour of including the text on CW S/N. If members of the WG believe I am wrong in my assessment of the difficultly of implementing CW S/N or it turns out that it is implemented in a critical mass of platforms then I will change my position on this proposal. Best regards Stewart On 09/11/2017 10:42, James Bensley wrote: > On 25 October 2017 at 19:08, Stewart Bryant wrote: >> RFC6790 ought to be another way to address the problem, but as we noted a >> while ago in the SFL work it stops short of mandating DPI type LB. >> >> I think I therefore agree that we out to just use 6391, after all with that >> negotiated by both ends it would be rather silly to then do the DPI. >> >> Not sure if I will get the text done by Monday, but this thread should give >> everyone a heads-up, I will put it on the slides for discussion and if I >> don't get the draft out I will put it in some other accessible place. >> >> - Stewart > > Hi guys, > > Sorry I'm late with this response. > > I think that saying FAT pseudowires or entropy labels SHOULD be used > when support is a suitable way forward I believe however, is it worth > putting something in the draft about enabling the PWMCW with > sequencing? Many devices support pseudowires that don’t support > FAT/ELI, is there benefit in adding to the draft, words to the effect > of: > > “when FAT/ELI isn’t support, PWMCW SHOULD be used with sequencing, > even though it is known that the CW doesn’t fully resolve the issue of > packet reordering (such as with a XEROX MAC address), for that FAT/ELI > is required, but it does greatly reduce the likelihood and when > reordering does occur, it provides a mechanism to at least detect it” > ? > > I think it is a big problem that the packet reordering is not easily > detectable/diagnosable when using just a CW without sequencing. > > > Also on a side note, someone has probably pointed these out already > but just in case there are a few typos in the draft; > > Draft: > Since that time the RAC has issued Ethernet MAC addresses start with > 0x4 or 0x6 > > "....starting with..." > > Draft: > used. This document updates RFC4448 [RFC4448] to state that where > both both the ingress PE and the egress PE support the Ethernet > > "... both both..." > > Draft: > as a data packet. This is described in detail section 7 of > [RFC6391], and section 6 of RFC6790. > > "... detail in section 7..." > > Draft: > Email: ibagdona.ietf@gmail.com> > > "...>" > > > Cheers, > James. From nobody Thu Nov 9 07:56:00 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDA112741D; Thu, 9 Nov 2017 07:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.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 iwzbPeHxrybz; Thu, 9 Nov 2017 07:55:57 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.145]) (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 0564E126557; Thu, 9 Nov 2017 07:55:56 -0800 (PST) Received: from [85.158.139.163] by server-9.bemta-5.messagelabs.com id 3D/3F-02029-A8A740A5; Thu, 09 Nov 2017 15:55:54 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1VSWUwTURT1zUzbkVDyKCDXKkbqEiBSSxRTNET /rEaMnwREmeJIq22pM0WrX8WoUUAjAVwIi8RGVAgqCggaE4sCAgFDogQjFAKKghsRF0CJM526 zde599x3zrmTS5OqWrmaZp0OlrMxFo08gFobuSkt9tQRKkVXXr9O3znWIdeX1d1R6Ocu79fXz NUS+o4hZpPM0FQyoDC43dPEDiJFZrYZs5zpMtNI/jp7bozz/Ldnchd6FJ2LAmgKnyDh2NNpSi xUuICA895cf+FF0J3XpMhF82k5ToS66gG5iENxLNTMTMjFIRI/RDAx1CUUNB2CN4P7S5w0Y4C mS0NIwuuh6uRNQsQUXg79s16ZiJV4J3xtuK2QzGoIKDxV6TOYL5i9K3P5hhBeAN86anyPSRwO L0YrfBgwBvf9HlLCYfB2ZM4/bwTvq0ok9SPhwmCpQsIR0FuRh0QzwB4FNH7vlUmEFuoL3vsfJ MHZyilCXAbwMrjzJk1qX0FQXExJOAb6brf6M2yAWxNj/gz7oftzDyHpD8ig7+OgX3MxFL044z e+JwdXzknfliqcAe2ln6mzaFXJP8uVCN4kjoYbzauldiQU5Q0rSnw/LBieXBylLiHqOoriWe4 gy8XG6bVGzpxpclgZsyU2ThevtbI8z2SyFsbIazOyrHVIuJp5wncXHW3c4kELaUITplQnUCmq IGPWnsMmhjft5rItLO9Bi2laA8qqwwIXzLGZrHOv2SKc3m8a6EBNqLLfKdBK3s5YeXOmRHWgN fTo8/KfBP364oSLVFG2LBurDlfyohIWR03Ztj9Cv8+4F0WoQ5RIiKYKtLOc1ez4nx9H4TTShC gLRJVAs83xx29ciEIIUVIVvigO5i+ldiGWmUx+/KE9rTCN6Yp6ei4itdnTkjjc5rEtsbca9+V 7dxry0a4V+0oHx6rL85M/WbZ+D1rZGdg5/uCLzp6tW/QyO2isu2Vj0tLTOvfMcXw1Jb0hXn9t PIdomyILVFsN5lr+lfbHARM3O7l925INzW+el81sX5Yz2HZotrS2Z6oyQUPxJiYuhuR45hcx5 L6NwQMAAA== X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-13.tower-188.messagelabs.com!1510242950!115544712!1 X-Originating-IP: [52.33.64.93] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 11374 invoked from network); 9 Nov 2017 15:55:53 -0000 Received: from ec2-52-33-64-93.us-west-2.compute.amazonaws.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (52.33.64.93) by server-13.tower-188.messagelabs.com with AES256-SHA256 encrypted SMTP; 9 Nov 2017 15:55:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sMqWq6lMC9cDyJxzm5HtB6YHRlSg12vZ7YO7OA7FjSQ=; b=gMNM+rGOrM9/K7YWy6MLur/0oyzYJYTarMemvdFfmPp1cVew4DmvU7YVgVdQdlZfJ9+dnTGbn4l4uJt6tAHWZv8rtTqpYVQv6hFQKjf3C6XAV5MJo91WVEwdoDBX0h1h68WEdoneKfE+o2HAaQktwAU4t1k558XySKHDABX+ufA= Received: from AM4PR03MB1713.eurprd03.prod.outlook.com (10.167.88.15) by AM4PR03MB1716.eurprd03.prod.outlook.com (10.167.88.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Thu, 9 Nov 2017 15:55:48 +0000 Received: from AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::3dd6:85df:7ee8:2216]) by AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::3dd6:85df:7ee8:2216%13]) with mapi id 15.20.0197.017; Thu, 9 Nov 2017 15:55:48 +0000 From: Alexander Vainshtein To: Stewart Bryant CC: James Bensley , "draft-ietf-pals-ethernet-cw@ietf.org" , "Andrew G. Malis" , "pals@ietf.org" Thread-Topic: [Pals] draft-ietf-pals-ethernet-cw and enhanced heuristics Thread-Index: AQHTWUeWP8lXwHbmdEii65d+8Lz846MMMV6AgAACIpA= Date: Thu, 9 Nov 2017 15:55:48 +0000 Message-ID: References: <8e6901f8-63ff-008b-ae00-e49620b76769@gmail.com> <796be686-40ac-e680-0b01-f218e4bd3516@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR03MB1716; 6:RrpYthYlLw0zJLhtub3ZwhNNGpISYDd2eLBslVG8t9AFxEU46vtNIOGXdlZp3hjUDrndo5PLNl+x1wxLnV5wBAhWQwjwanGqkfHxsGwLx10MhXTgrWEV5d2OqwvI8MNKXDacyb1WZ/CLACrOOytU30SHhb1julu/2w0SA+d9dfEjTJMtoNwDjx4WY9s+ybIsjFvh8AJbRZnUTI0sNmzlrXY9zQuVQSKy8W7LFbqIbXJlTabf2hDY320RBzlI8d7NysSF4n+zduSzc32Klue2m6y/Rku3qeSSwo5xdy1dbhdNl3aKPn2VU1DOhdRpQFzyO6mW4zXQL9kd7FLGmfhwOn+bKS2KBZks2vEpwaLqL1I=; 5:2GVi9ycPHAx86gNwkxqPA18i+M0XFDpmISHQAqyvz637ce0Vto6IrC5ILsETf/xb/UIMxbQXklYmeCPlaaXlRxEb8qNsiPWK29elyQ9mX/cyFe2DXke8xXdCppAVP+Eqb+78lMHnngZ0Fq3lzbSK611CjO9tJGnphWxYoAVEa4k=; 24:Y+9J/3/KTtPnAUPMksn6qCcFt+F0xQL/eXMBm9kRCqzO81ZCwD6Lk6IIMCBYep7DwH91FjcpUAOemBYiwUPs8qpnpM29mDfl+O8hFMhM2Ak=; 7:Dh8w+WE/ssN95mIAmmI119L9d2QWDm9EK/ka44lcnIMmWCB+uZU+lcYfw4GAWh3qkPNroPQyEj+b/qjHJyLs1IIEChnbSl0M2JQJIS7HbsXJBlvWEXvv1sXafpjPP+x+T/u7bGRSe3B83f59MHLTVhlAKyHu5+Z94uA16SEeXpTfwSF4Qy5mP3xlpwlVGyodnI8lq3zJzsj1SvN+xcmyw0TPrMuPU1XblerS6gXljp36HU8CjYxgrHuKsLshbdvd x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 56de3fe8-3054-446e-d963-08d5278a589f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM4PR03MB1716; x-ms-traffictypediagnostic: AM4PR03MB1716: x-exchange-antispam-report-test: UriScan:(279101305709854); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3231021)(3002001)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR03MB1716; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR03MB1716; x-forefront-prvs: 0486A0CB86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(252514010)(189002)(51444003)(199003)(13464003)(24454002)(316002)(53546010)(325944009)(3280700002)(55016002)(5250100002)(9686003)(6306002)(25786009)(189998001)(3846002)(6116002)(33656002)(102836003)(50986999)(76176999)(54356999)(93886005)(8676002)(81156014)(81166006)(2900100001)(68736007)(66066001)(6916009)(561944003)(53936002)(7736002)(966005)(345774005)(8936002)(230783001)(7696004)(97736004)(2950100002)(105586002)(106356001)(3660700001)(4326008)(39060400002)(74316002)(6506006)(478600001)(72206003)(101416001)(6246003)(6436002)(54906003)(86362001)(305945005)(5660300001)(2906002)(14454004)(229853002)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR03MB1716; H:AM4PR03MB1713.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 56de3fe8-3054-446e-d963-08d5278a589f X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2017 15:55:48.8009 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB1716 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pals] draft-ietf-pals-ethernet-cw and enhanced heuristics X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 15:56:00 -0000 U3Rld2FydCwgCkkgYWdyZWUgd2l0aCB5b3VyIGFzc2Vzc21lbnQgb2YgdGhlIGRpZmZpY3VsdGx5 IG9mIGltcGxlbWVudGluZyBDVyBTL04gZm9yIEV0aGVybmV0IFBXcy4KQW5kIEkgYW0gbm90IGF3 YXJlIG9mIGFueSBpbXBsZW1lbnRhdGlvbi4KClJlZ2FyZHMsClNhc2hhCgpPZmZpY2U6ICs5NzIt MzkyNjYzMDIKQ2VsbDogICAgICArOTcyLTU0OTI2NjMwMgpFbWFpbDogICBBbGV4YW5kZXIuVmFp bnNodGVpbkBlY2l0ZWxlLmNvbQoKCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCkZyb206IFBh bHMgW21haWx0bzpwYWxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGV3YXJ0IEJy eWFudApTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgOSwgMjAxNyA1OjQ3IFBNClRvOiBKYW1lcyBC ZW5zbGV5IDxqd2JlbnNsZXlAZ21haWwuY29tPjsgZHJhZnQtaWV0Zi1wYWxzLWV0aGVybmV0LWN3 QGlldGYub3JnOyBBbmRyZXcgRy4gTWFsaXMgPGFnbWFsaXNAZ21haWwuY29tPjsgcGFsc0BpZXRm Lm9yZwpTdWJqZWN0OiBSZTogW1BhbHNdIGRyYWZ0LWlldGYtcGFscy1ldGhlcm5ldC1jdyBhbmQg ZW5oYW5jZWQgaGV1cmlzdGljcwoKSGkgSmFtZXMKClRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50 cy4KCkkgd2lsbCBsb29rIGF0IHRoZSBkZXRhaWxlZCBlZGl0b3JpYWwgcG9pbnRzIGluIHRoZSBu ZXh0IHZlcnNpb24uCgpIb3dldmVyIEkgZG9uJ3Qga25vdyBvZiBhbnkgcGxhdGZvcm1zIHRoYXQg c3VwcG9ydCBDVyBTL04gZm9yIEV0aGVybmV0LiAKSW4gbW9zdCBmb3J3YXJkaW5nIGFyY2hpdGVj dHVyZXMgaXQgaXMgbXVjaCBlYXNpZXIgdG8gYWRkIEZBVCBvciBFTEkgc3VwcG9ydCB0aGFuIGl0 IGlzIHRvIGFkZCBzdXBwb3J0IGZvciBTL04uIFRoaXMgaXMgYSBkaXNjdXNzaW9uIHdlIGFyZSBh bHNvIGhhdmluZyBpbiBERVRORVQuCgpTdXBwb3J0aW5nIEZBVCBhbmQgRUxJIGlzIGEgc3RhdGVs ZXNzIG9wZXJhdGlvbiB0aGF0IGFueSBmb3J3YXJkaW5nIGFyY2hpdGVjdHVyZSBJIGNhbiB0aGlu ayBvZiBjYW4gc3VwcG9ydC4KClN1cHBvcnRpbmcgUy9OIGlzIHN0YXRlZnVsLiBUaGlzIGlzIGhh cmQgdG8gc28gYXQgc3BlZWQsIGFuZCBtYXkgZm9yY2UgdGhlIGltcGxlbWVudGVyIHRvIGEgc3Bl Y2lmaWMgZm9yd2FyZGluZyBhcmNoaXRlY3R1cmUgKGVncmVzcyBwYWNrZXQgZmlsdGVyaW5nKS4K CkdpdmVuIHRoZSBhYm92ZSBJIGFtIG5vdCBpbiBmYXZvdXIgb2YgaW5jbHVkaW5nIHRoZSB0ZXh0 IG9uIENXIFMvTi4KCklmIG1lbWJlcnMgb2YgdGhlIFdHIGJlbGlldmUgSSBhbSB3cm9uZyBpbiBt eSBhc3Nlc3NtZW50IG9mIHRoZSBkaWZmaWN1bHRseSBvZiBpbXBsZW1lbnRpbmcgQ1cgUy9OIG9y IGl0IHR1cm5zIG91dCB0aGF0IGl0IGlzIGltcGxlbWVudGVkIGluIGEgY3JpdGljYWwgbWFzcyBv ZiBwbGF0Zm9ybXMgdGhlbiBJIHdpbGwgY2hhbmdlIG15IHBvc2l0aW9uIG9uIHRoaXMgcHJvcG9z YWwuCgpCZXN0IHJlZ2FyZHMKClN0ZXdhcnQKCgpPbiAwOS8xMS8yMDE3IDEwOjQyLCBKYW1lcyBC ZW5zbGV5IHdyb3RlOgo+IE9uIDI1IE9jdG9iZXIgMjAxNyBhdCAxOTowOCwgU3Rld2FydCBCcnlh bnQgPHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbT4gd3JvdGU6Cj4+IFJGQzY3OTAgb3VnaHQgdG8g YmUgYW5vdGhlciB3YXkgdG8gYWRkcmVzcyB0aGUgcHJvYmxlbSwgYnV0IGFzIHdlIAo+PiBub3Rl ZCBhIHdoaWxlIGFnbyBpbiB0aGUgU0ZMIHdvcmsgaXQgc3RvcHMgc2hvcnQgb2YgbWFuZGF0aW5n IERQSSB0eXBlIExCLgo+Pgo+PiBJIHRoaW5rIEkgdGhlcmVmb3JlIGFncmVlIHRoYXQgd2Ugb3V0 IHRvIGp1c3QgdXNlIDYzOTEsIGFmdGVyIGFsbCAKPj4gd2l0aCB0aGF0IG5lZ290aWF0ZWQgYnkg Ym90aCBlbmRzIGl0IHdvdWxkIGJlIHJhdGhlciBzaWxseSB0byB0aGVuIGRvIHRoZSBEUEkuCj4+ Cj4+IE5vdCBzdXJlIGlmIEkgd2lsbCBnZXQgdGhlIHRleHQgZG9uZSBieSBNb25kYXksIGJ1dCB0 aGlzIHRocmVhZCAKPj4gc2hvdWxkIGdpdmUgZXZlcnlvbmUgYSBoZWFkcy11cCwgSSB3aWxsIHB1 dCBpdCBvbiB0aGUgc2xpZGVzIGZvciAKPj4gZGlzY3Vzc2lvbiBhbmQgaWYgSSBkb24ndCBnZXQg dGhlIGRyYWZ0IG91dCBJIHdpbGwgcHV0IGl0IGluIHNvbWUgb3RoZXIgYWNjZXNzaWJsZSBwbGFj ZS4KPj4KPj4gLSBTdGV3YXJ0Cj4KPiBIaSBndXlzLAo+Cj4gU29ycnkgSSdtIGxhdGUgd2l0aCB0 aGlzIHJlc3BvbnNlLgo+Cj4gSSB0aGluayB0aGF0IHNheWluZyBGQVQgcHNldWRvd2lyZXMgb3Ig ZW50cm9weSBsYWJlbHMgU0hPVUxEIGJlIHVzZWQgCj4gd2hlbiBzdXBwb3J0IGlzIGEgc3VpdGFi bGUgd2F5IGZvcndhcmQgSSBiZWxpZXZlIGhvd2V2ZXIsIGlzIGl0IHdvcnRoIAo+IHB1dHRpbmcg c29tZXRoaW5nIGluIHRoZSBkcmFmdCBhYm91dCBlbmFibGluZyB0aGUgUFdNQ1cgd2l0aCAKPiBz ZXF1ZW5jaW5nPyBNYW55IGRldmljZXMgc3VwcG9ydCBwc2V1ZG93aXJlcyB0aGF0IGRvbuKAmXQg c3VwcG9ydCAKPiBGQVQvRUxJLCBpcyB0aGVyZSBiZW5lZml0IGluIGFkZGluZyB0byB0aGUgZHJh ZnQsIHdvcmRzIHRvIHRoZSBlZmZlY3QKPiBvZjoKPgo+IOKAnHdoZW4gRkFUL0VMSSBpc27igJl0 IHN1cHBvcnQsIFBXTUNXIFNIT1VMRCBiZSB1c2VkIHdpdGggc2VxdWVuY2luZywgCj4gZXZlbiB0 aG91Z2ggaXQgaXMga25vd24gdGhhdCB0aGUgQ1cgZG9lc27igJl0IGZ1bGx5IHJlc29sdmUgdGhl IGlzc3VlIG9mIAo+IHBhY2tldCByZW9yZGVyaW5nIChzdWNoIGFzIHdpdGggYSBYRVJPWCBNQUMg YWRkcmVzcyksIGZvciB0aGF0IEZBVC9FTEkgCj4gaXMgcmVxdWlyZWQsIGJ1dCBpdCBkb2VzIGdy ZWF0bHkgcmVkdWNlIHRoZSBsaWtlbGlob29kIGFuZCB3aGVuIAo+IHJlb3JkZXJpbmcgZG9lcyBv Y2N1ciwgaXQgcHJvdmlkZXMgYSBtZWNoYW5pc20gdG8gYXQgbGVhc3QgZGV0ZWN0IGl04oCdCj4g Pwo+Cj4gSSB0aGluayBpdCBpcyBhIGJpZyBwcm9ibGVtIHRoYXQgdGhlIHBhY2tldCByZW9yZGVy aW5nIGlzIG5vdCBlYXNpbHkgCj4gZGV0ZWN0YWJsZS9kaWFnbm9zYWJsZSB3aGVuIHVzaW5nIGp1 c3QgYSBDVyB3aXRob3V0IHNlcXVlbmNpbmcuCj4KPgo+IEFsc28gb24gYSBzaWRlIG5vdGUsIHNv bWVvbmUgaGFzIHByb2JhYmx5IHBvaW50ZWQgdGhlc2Ugb3V0IGFscmVhZHkgCj4gYnV0IGp1c3Qg aW4gY2FzZSB0aGVyZSBhcmUgYSBmZXcgdHlwb3MgaW4gdGhlIGRyYWZ0Owo+Cj4gRHJhZnQ6Cj4g U2luY2UgdGhhdCB0aW1lIHRoZSBSQUMgaGFzIGlzc3VlZCBFdGhlcm5ldCBNQUMgYWRkcmVzc2Vz IHN0YXJ0IHdpdGgKPiAweDQgb3IgMHg2Cj4KPiAiLi4uLnN0YXJ0aW5nIHdpdGguLi4iCj4KPiBE cmFmdDoKPiB1c2VkLiBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgUkZDNDQ0OCBbUkZDNDQ0OF0gdG8g c3RhdGUgdGhhdCB3aGVyZSBib3RoIAo+IGJvdGggdGhlIGluZ3Jlc3MgUEUgYW5kIHRoZSBlZ3Jl c3MgUEUgc3VwcG9ydCB0aGUgRXRoZXJuZXQKPgo+ICIuLi4gYm90aCBib3RoLi4uIgo+Cj4gRHJh ZnQ6Cj4gYXMgYSBkYXRhIHBhY2tldC4gVGhpcyBpcyBkZXNjcmliZWQgaW4gZGV0YWlsIHNlY3Rp b24gNyBvZiBbUkZDNjM5MV0sIAo+IGFuZCBzZWN0aW9uIDYgb2YgUkZDNjc5MC4KPgo+ICIuLi4g ZGV0YWlsIGluIHNlY3Rpb24gNy4uLiIKPgo+IERyYWZ0Ogo+IEVtYWlsOiBpYmFnZG9uYS5pZXRm QGdtYWlsLmNvbT4KPgo+ICIuLi4+Igo+Cj4KPiBDaGVlcnMsCj4gSmFtZXMuCgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpQYWxzIG1haWxpbmcgbGlzdApQ YWxzQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGFscwoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCgpUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0 aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzIApDT05G SURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyAKdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5m b3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdp bmFsIAphbmQgYWxsIGNvcGllcyB0aGVyZW9mLgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K From nobody Thu Nov 9 08:04:17 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600EC12706D; Thu, 9 Nov 2017 08:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 jRMIXx0QQsGK; Thu, 9 Nov 2017 08:04:14 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA2C0126557; Thu, 9 Nov 2017 08:04:13 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id b189so18047628wmd.4; Thu, 09 Nov 2017 08:04:13 -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-transfer-encoding:content-language; bh=labQBcomJ6kce68XdpzdNjKJjZBrWOcBjgNLxo/Fa8A=; b=PhXHd/FdRctmlQTk7LlOtuT6MQn8Oi6eUUVci10pl0e8cqmPEQkLxSw0CXjoy2fCyF tj2wCSAE16fY01pTu6lvRKiKglBS6puYNYezidjd5sihtqDM2Ps9wzzsiyPOh4S4brgt dbJ4cQ/0Udn0X3o8BEogp/EBGGB+p1h+ikkg5k34+kjN5ngePsSEpTPMjLERY6knvyBq ljHqlVWaxrhU3BZJGspxhIJNnnlYqEte6U1KOtXSauI9DibsUWEGLVsyBmuctd3CT7RI Y0xEKIfgtJlRSEQIU4qHkzC0QxIK3FZ5nIvcoGN0C/zqrZtobahPRyz34vVtSZv+4Cmt zqMg== 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-transfer-encoding :content-language; bh=labQBcomJ6kce68XdpzdNjKJjZBrWOcBjgNLxo/Fa8A=; b=HINFKCkM64UscmOS4GHsZ0xmuMOWX5So78w5CuGJcvQuS7XKJMasARM7qPXNSsHf4L xu20WsE0XGgG8Wzkx/5bluc8XDZKgTfbwrZmWY6AyTmEJxG5SeyYaTR8aGyVlHgNE1cg DNVyeGE06eDeR9QB+V9Zfs89+GLU0eCUfYePMPi7N4JTIUsBw5RxymN+RlhdcgAxp+fx k601UWbW/wq4q9J6yg14RkDh6F4lxy7knNiIMNBNqhpggENpMyY/N9/2DGXx1Pa1EuDF xY7OfIqP4UAYw8k7aPw16VmoVZWV4ToucA/F1/ncJHTJIhdxpqBpOzhGvqkAmmW29yVo lJCg== X-Gm-Message-State: AJaThX6bMfQa8H3P6vo1LCXZJlJckCkqHBAF1dxcEmGe0OwZWHLMTx29 kVH2KHnxkZALWq0+i/uCIDJwLEcA X-Google-Smtp-Source: AGs4zMZyb4rIRcpMh8SSGmmTNDJptEiBQl2IA9I762SeFWU5GfI2ZUzt5yXOXpeXD8eDLnOZWMiDjQ== X-Received: by 10.28.142.20 with SMTP id q20mr245385wmd.37.1510243452215; Thu, 09 Nov 2017 08:04:12 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id m37sm7693782wrm.4.2017.11.09.08.04.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Nov 2017 08:04:11 -0800 (PST) To: Alexander Vainshtein Cc: James Bensley , "draft-ietf-pals-ethernet-cw@ietf.org" , "Andrew G. Malis" , "pals@ietf.org" References: <8e6901f8-63ff-008b-ae00-e49620b76769@gmail.com> <796be686-40ac-e680-0b01-f218e4bd3516@gmail.com> From: Stewart Bryant Message-ID: <62e75932-3fd1-6f47-7448-05729c3638eb@gmail.com> Date: Thu, 9 Nov 2017 16:04:11 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [Pals] draft-ietf-pals-ethernet-cw and enhanced heuristics X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 16:04:16 -0000 Thanks. I can explain why it is a hard problem if people need the background. - Stewart On 09/11/2017 15:55, Alexander Vainshtein wrote: > Stewart, > I agree with your assessment of the difficultly of implementing CW S/N for Ethernet PWs. > And I am not aware of any implementation. > > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > > > -----Original Message----- > From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Stewart Bryant > Sent: Thursday, November 9, 2017 5:47 PM > To: James Bensley ; draft-ietf-pals-ethernet-cw@ietf.org; Andrew G. Malis ; pals@ietf.org > Subject: Re: [Pals] draft-ietf-pals-ethernet-cw and enhanced heuristics > > Hi James > > Thank you for your comments. > > I will look at the detailed editorial points in the next version. > > However I don't know of any platforms that support CW S/N for Ethernet. > In most forwarding architectures it is much easier to add FAT or ELI support than it is to add support for S/N. This is a discussion we are also having in DETNET. > > Supporting FAT and ELI is a stateless operation that any forwarding architecture I can think of can support. > > Supporting S/N is stateful. This is hard to so at speed, and may force the implementer to a specific forwarding architecture (egress packet filtering). > > Given the above I am not in favour of including the text on CW S/N. > > If members of the WG believe I am wrong in my assessment of the difficultly of implementing CW S/N or it turns out that it is implemented in a critical mass of platforms then I will change my position on this proposal. > > Best regards > > Stewart > > > On 09/11/2017 10:42, James Bensley wrote: >> On 25 October 2017 at 19:08, Stewart Bryant wrote: >>> RFC6790 ought to be another way to address the problem, but as we >>> noted a while ago in the SFL work it stops short of mandating DPI type LB. >>> >>> I think I therefore agree that we out to just use 6391, after all >>> with that negotiated by both ends it would be rather silly to then do the DPI. >>> >>> Not sure if I will get the text done by Monday, but this thread >>> should give everyone a heads-up, I will put it on the slides for >>> discussion and if I don't get the draft out I will put it in some other accessible place. >>> >>> - Stewart >> Hi guys, >> >> Sorry I'm late with this response. >> >> I think that saying FAT pseudowires or entropy labels SHOULD be used >> when support is a suitable way forward I believe however, is it worth >> putting something in the draft about enabling the PWMCW with >> sequencing? Many devices support pseudowires that don’t support >> FAT/ELI, is there benefit in adding to the draft, words to the effect >> of: >> >> “when FAT/ELI isn’t support, PWMCW SHOULD be used with sequencing, >> even though it is known that the CW doesn’t fully resolve the issue of >> packet reordering (such as with a XEROX MAC address), for that FAT/ELI >> is required, but it does greatly reduce the likelihood and when >> reordering does occur, it provides a mechanism to at least detect it” >> ? >> >> I think it is a big problem that the packet reordering is not easily >> detectable/diagnosable when using just a CW without sequencing. >> >> >> Also on a side note, someone has probably pointed these out already >> but just in case there are a few typos in the draft; >> >> Draft: >> Since that time the RAC has issued Ethernet MAC addresses start with >> 0x4 or 0x6 >> >> "....starting with..." >> >> Draft: >> used. This document updates RFC4448 [RFC4448] to state that where both >> both the ingress PE and the egress PE support the Ethernet >> >> "... both both..." >> >> Draft: >> as a data packet. This is described in detail section 7 of [RFC6391], >> and section 6 of RFC6790. >> >> "... detail in section 7..." >> >> Draft: >> Email: ibagdona.ietf@gmail.com> >> >> "...>" >> >> >> Cheers, >> James. > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this > transmission in error, please inform us by e-mail, phone or fax, and then delete the original > and all copies thereof. > ___________________________________________________________________________ From nobody Thu Nov 9 11:10:21 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE70129534 for ; Thu, 9 Nov 2017 11:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 Bb8Ks8GrPB4p for ; Thu, 9 Nov 2017 11:10:15 -0800 (PST) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 D857112951E for ; Thu, 9 Nov 2017 11:10:14 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id d2so1680051ywb.11 for ; Thu, 09 Nov 2017 11:10:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aZ8EIByYnQBBR3oE8p1KV4Dhw4JoBysuLhEM80kt044=; b=fwmNWySR7vGmthTP9CnJgCUm3/Icy8NBGDeX4iheWzOHLsqT35bTsoARX2r9tALgjt RFvrceTtYHJH+TrcDqedw4py2m/enRLLT5YTBg81UM6cXP9cuW30l8M4zcGgeWevkqqG F649HkE9jCcX74OVjvekaG0U6+ihcYfrtb/oxsp+ufgwUTxGpIb+QhsiWUE6heiw1KrQ stTagftdXc7ZMt6LKxg3FPnuZuvndR13M2g7WETydJiHfAQK+4dLOsVOycVLZB/E7oje YsOztCn1oXsTOkoCNwSZi9mPo9L0L1SvyAusJKD+lTUGI3n0zYR+ijUni9t7BxTmikoP VXZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aZ8EIByYnQBBR3oE8p1KV4Dhw4JoBysuLhEM80kt044=; b=B2LQzZOH4LuhhNM9fC4/C6bKdq4s7iP5R/iSY34lNIXsvqWcuw1K/cbQLEkFHvTBSn cK8/7aKxoHZbsKRWey3jMpZJqqUVHzL2fl0NkAXbbQbiHTHxIRfcZ3Slc67t6Gg3iG7U gWY1XQdCmI56ARxB0cGpPQNdW4CHDSdMcg3Bc76wml6A+JAmgtysxO32nv0rUWB2IPdx O6b19beK7ZUj5NteaVnxAQI7RAKkuaYnaEf1RaDmWIQ5MOC7zMLlyrG/UjlCdtcMc2V2 Q+e/x7dLg+9iP1Tg5HUw7aps4oj+GY9nMCmyVwYs/JSTWmXjuFSknNswLkwF2WHkNvPE /5dg== X-Gm-Message-State: AJaThX71sgIMf5bXfz8VjbqwRpgHsK/IKAFtPZX5DHwTG73PrQ1vwnMc rv1mV/kjzVj2mA3uMOWHtUvx8+27//THy1YQWyZAEA== X-Google-Smtp-Source: ABhQp+SrCmrm5XvVNo3+tZg6gndXvDC4SUq19MleqUhNI4uREHXnWRdFNiRldmTS6L4cbBKkr5NrwHe2hp0xNP3MWuU= X-Received: by 10.129.108.3 with SMTP id h3mr1065022ywc.327.1510254613983; Thu, 09 Nov 2017 11:10:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Thu, 9 Nov 2017 11:09:33 -0800 (PST) In-Reply-To: <002101d35919$c6295b90$527c12b0$@ndzh.com> References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <5994f353-5306-0fa8-2d2d-024ebdbb10df@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> <25B4902B1192E84696414485F5726854135191D6@sjceml521-mbs.china.huawei.com> <25B4902B1192E84696414485F572685413519209@sjceml521-mbs.china.huawei.com> <002101d35919$c6295b90$527c12b0$@ndzh.com> From: Eric Rescorla Date: Thu, 9 Nov 2017 11:09:33 -0800 Message-ID: To: Susan Hares Cc: Uma Chunduri , mpls@ietf.org, pals-chairs@tools.ietf.org, "" , mpls-chairs@ietf.org, pals@ietf.org, "" Content-Type: multipart/alternative; boundary="001a114d9a28c9a6e2055d918dba" Archived-At: Subject: Re: [Pals] [mpls] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 19:10:19 -0000 --001a114d9a28c9a6e2055d918dba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yeah, I agree. I don't really have any good ideas how to get people to do AO. Based on comments I've heard, providers don't see a lot of value, rightly or wrongly.... -Ekr On Wed, Nov 8, 2017 at 9:15 PM, Susan Hares wrote: > Eric: > > > > BGP and LDP would be more secure if TCP-AO deployed with all BGP and LDP = =E2=80=93 > but there are issues with customer pick-up and deployment of these > protocols on many networks. I wished we had TCP-AO when BGP started, but > we did not. > > > > Some of the least secure BGP is in data centers =E2=80=93 where the DC pr= oviders > say =E2=80=9CIt=E2=80=99s all under one administration=E2=80=9D. Another= problem is on private > lines. We should chat about the networks each of these protocols are > actually deployed on. If you have any insight on a way to encourage > adoption, I=E2=80=99d love to hear it. Require TCP-AO does not really mea= n anything > if providers and Data Centers do not adopt it. > > > > Going from SHA-1 to SHA-256 on a TCP-AO is simple upgrade compared to > getting people to TCP-AO. > > > > Sue > > > > *From:* mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Eric Rescorla > *Sent:* Wednesday, November 8, 2017 7:44 PM > *To:* Uma Chunduri > *Cc:* mpls@ietf.org; pals-chairs@tools.ietf.org; ; > mpls-chairs@ietf.org; pals@ietf.org; > > *Subject:* Re: [mpls] LDP Security > > > > I don't understand what you're getting at here. Yes, if people have TCP-A= O > then presumably they have SHA-1. > > > > But now we're talking about requiring people to have TCP-AO in this case, > so we should try to move them to SHA-256 at the time we require AO. > > > > -Ekr > > > > > > On Wed, Nov 8, 2017 at 4:14 PM, Uma Chunduri > wrote: > > *From:* Eric Rescorla [mailto:ekr@rtfm.com] > *Sent:* Wednesday, November 08, 2017 3:53 PM > > > *To:* Uma Chunduri > *Cc:* Stewart Bryant ; mpls@ietf.org; > pals-chairs@tools.ietf.org; ; > mpls-chairs@ietf.org; pals@ietf.org; > *Subject:* Re: [mpls] LDP Security > > > > > > > > On Wed, Nov 8, 2017 at 3:50 PM, Uma Chunduri > wrote: > > In-line [Uma1]: > > -- > > Uma C. > > > > *From:* Eric Rescorla [mailto:ekr@rtfm.com] > *Sent:* Wednesday, November 08, 2017 12:53 PM > *To:* Uma Chunduri > *Cc:* Stewart Bryant ; mpls@ietf.org; > pals-chairs@tools.ietf.org; ; > mpls-chairs@ietf.org; pals@ietf.org; > > > *Subject:* Re: [mpls] LDP Security > > > > > > > > On Wed, Nov 8, 2017 at 11:57 AM, Uma Chunduri > wrote: > > Hi Stewart, > > > > I would note https://tools.ietf.org/html/rfc6952 - where LDP security is > analyzed from all aspects. > > > > Eric, > > > > Quick comments below [Uma]: > > > > -- > > Uma C. > > > > *From:* mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Eric Rescorla > *Sent:* Wednesday, November 08, 2017 10:00 AM > *To:* Stewart Bryant > *Cc:* mpls@ietf.org; pals-chairs@tools.ietf.org; < > rtg-ads@ietf.org>; mpls-chairs@ietf.org; pals@ietf.org; > > *Subject:* Re: [mpls] LDP Security > > > > Hi Stewart > > > > Thanks for your note. > > > > My overall sense of the state of play is, I think much like yours. > > > > TCP-MD5 is inadequate in two major respects: > > - It uses weak algorithms > > - It has a bad negotiation/setuop story (manual key management) > > > > TCP-AO is intended to be a drop-in replacement for TCP-MD5 and so remedie= s > the algorithm > > Issue > > > > [Uma]: Yes, if we go with RFC 5926 mandatory list.. > > > > but not the key management issue [0]. We haven't made much progress on th= e > key > > management story, and that seems to be a major impediment to deploying > either of these > > technologies (which I am given to understand don't see a lot of use). > > > > [Uma]: True. > > But I would indicate some effort done few years back > regarding key management for pair wise routing protocols (BGP, LDP, PCEP, > MSDP ..). > > One such proposal is by extending IKEv2 to negotiate TCP-A= O > MKTs (which can give rekey & algo. agility) - https://tools.ietf.org/html= / > draft-mahesh-karp-rkmp-05 > > This also requires some more work with TCP-AO; me & Joe pu= t > together https://www.ietf.org/archive/id/draft-chunduri-karp-using- > ikev2-with-tcp-ao-06.txt > > Note the above didn=E2=80=99t progress in the concluded KARP W= G (not > fully sure the reasons on why). > > > > Yeah, I know that people tried to do this, but my impression was it kinda > didn't progress much. > > > > > > > > We should probably talk in Singapore about that, but that's not going to > get better any time soon. > > > > In the interim, I think the text you have is OK, and "TBD" should read > "SHA-256", with > > the fallback being SHA-256 -> SHA-1 -> MD5. > > > > [Uma]: While the list can be extended - I didn=E2=80=99t see SHA256 in th= e > mandatory list in RFC 5926 for MAC. > > > > Generally we're trying to move away from SHA-1 towards SHA-256. > > > > [Uma1]: Couple of things: > > 1. *Nothing to be done (from spec pov of course):* Use TCP-AO > (instead of current MD5) with the RFC 5926 mandated MACs/KDFs =E2=80=93 s= o the > =E2=80=98TBD=E2=80=99 in Stewart suggesting below is already there. > > 2. As #1 too is not good enough from your above note - do SHA-256 > and live with it (no algorithm agility). Still a security benefit in one > way from existing stuff or even #1. > > I'm not sure why you say "no algorithm agility". You'd be using AO, just > with a different algorithm than SHA-1. AES-CMAC is still fine as far as I > know. > > [Uma2]: Sure, you have it, if you use AO; > > But then I am not getting how we can mandate one MUST > implement algorithm as suggested below TBD would actually work > (especially - **if** #1 is already deployed somewhere?) > > Perhaps staying with #1 is the best bet or do negotiatio= n > through #3, with already mandated and additional stuff. > > > > -Ekr > > > > 3. Do key management and =E2=80=9Ctheoretically=E2=80=9D get all we= wanted=E2=80=A6. > > > > We have been here multiple times; because #1 itself is not **mostly** > deployed (neither in BGP nor in LDP) if there is any appetite for #2 and = #3 > for practical deployments. But still it may be good to do #2 any ways. > > > > > > -Ekr > > > > > > -Ekr > > > > > > [0] Technically It has better support for rollover, but this is not a hug= e > improvement. > > [1] tcpcrypt is kind of orthogonal here as it's unauthenticated but > opportunistic. That said, > > it would provide defense against attackers who gain access to the link > after connection > > setup and doesn't require configuration. > > > > On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant > wrote: > > To the SEC and RTG ADs, > > I am sending the following message on behalf of the MPLS and the > PALS WG Chairs. > > There is a concern shared among the security community and the working > groups that develop the LDP protocol that LDP is no longer adequately > secured. LDP currently relies on MD5 for cryptographic security of its > messages, but MD5 is a hash function that is no longer considered to meet > current security requirements. > > In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2. > Session communication carried by TCP the following statements is made: > > "LDP specifies use of the TCP MD5 Signature Option to provide for the > authenticity and integrity of session messages. > > "[RFC2385] asserts that MD5 authentication is now considered by some to b= e > too weak for this application. It also points out that a similar TCP > option with a stronger hashing algorithm (it cites SHA-1 as an example) > could be deployed. To our knowledge, no such TCP option has been defined > and deployed. However, we note that LDP can use whatever TCP message > digest techniques are available, and when one stronger than MD5 is > specified and implemented, upgrading LDP to use it would be relatively > straightforward." > > We note that BGP has already been through this process, and replaced MD5 > with TCP-AO in RFC 7454. I would be logical to follow the same approach t= o > secure LDP. However, as far as we are able to ascertain, there is current= ly > no recommended, mandatory to implement, cryptographic function specified. > We are concerned that without such a mandatory function, implementations > will simply fall back to MD5 and we will be no further forward > > We think that the best way forward is to publish a draft similar to RFC > 7454 that contains the following requirement: > > "Implementations conforming to this RFC MUST implement TCP-AO to secure > the TCP sessions carrying LDP in addition to the currently required TCP M= D5 > Signature Option. Furthermore, the TBD cryptographic mechanism must be > implemented and provided to TCP-AO to secure LDP messages. The TBD > mechanism is the preferred option, and MD5 is only to be used when TBD is > unavailable." > > We are not an experts on this part of the stack, but it seems that TCP > security negotiation is still work in progress. If we are wrong, then we > need to include a requirement that such negotiation is also required. In > the absence of a negotiation protocol, however, we need to leave this as = a > configuration process until such time as the negotiation protocol work is > complete. On completion of a suitable negotiation protocol we need to iss= ue > a further update requiring its use. > > Additionally we should note that no cryptographic mechanism has an > indefinite lifetime, and that implementation should note the IETF > anticipates updating the default cryptographic mechanism over time. > > The TBD default security function will need to be chosen such that it can > reasonably be implemented on a typical router route processor, and which > will provide adequate security without significantly degrading the > convergence time of an LSR. Without a function that does not significantl= y > impact router convergence we simply close one vulnerability and open > another. > > As experts on the LDP protocol, but not on security mechanisms, we need > to ask the security area for a review of our proposed approach, and help > correcting any misunderstanding of the security issues or our > misunderstanding of the existing security mechanisms. We also need the > recommendations of a suitable security function (TBD in the above text). > > Best regards > > The MPLS WG Chairs > The PALS WG Chairs > > > > > > > > > --001a114d9a28c9a6e2055d918dba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, I agree. I don't really have any good ideas how = to get people to do AO. Based on comments I've heard, providers don'= ;t see a lot of value, rightly or wrongly....

-Ekr
=


On Wed, Nov 8, 2017 at 9:15 PM, Susan Hares <shares@ndzh.com> wrote:

Eric:

=C2=A0

BGP and LDP would = be more secure if TCP-AO deployed with all BGP and LDP =E2=80=93 but there = are issues with customer pick-up and deployment of these protocols on many = networks.=C2=A0 I wished we had TCP-AO when BGP started, but we did not.

=C2=A0

Some of the least secure BGP is in data centers =E2=80=93 where the DC = providers say =E2=80=9CIt=E2=80=99s all under one administration=E2=80=9D.= =C2=A0 Another problem is on private lines.=C2=A0=C2=A0 =C2=A0We should cha= t about the networks each of these protocols are actually deployed on.=C2= =A0 =C2=A0If you have any insight on a way to encourage adoption, I=E2=80= =99d love to hear it. Require TCP-AO does not really mean anything if provi= ders and Data Centers do not adopt it. =C2=A0

=C2=A0

Going from SHA-1 to SHA-= 256 on a TCP-AO is simple upgrade compared to getting people to TCP-AO. =C2= =A0=C2=A0

=C2=A0

Sue

=C2=A0

<= b>From: mpls [mailto:mpls-bounces@ietf.org] On Be= half Of Eric Rescorla
Sent: Wednesday, November 8, 2017 7:44 = PM
To: Uma Chunduri
Cc: mpls@ietf.org; pals-chairs@tools.ietf.org; <rtg-ads@ietf.org>; mpls-chairs@ietf.org; pals@ietf.org; &l= t;sec-ads@ietf.org>

=C2=A0

=C2=A0

On Wed, Nov 8, 2017 at 4:14 P= M, Uma Chunduri <uma.chunduri@huawei.com> wrote:

From: Eric Resc= orla [mailto:ekr@rtfm.com= ]
Sent: Wednesday, November 08, 2017 3:53 PM


To: Uma Chunduri <<= a href=3D"mailto:uma.chunduri@huawei.com" target=3D"_blank">uma.chunduri@hu= awei.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>; mpls@ietf.org; pals-chairs@tools.= ietf.org; <rtg= -ads@ietf.org> <rtg-ads@ietf.org>; mpls-chairs@ietf.org; pals@ietf.org; <sec-ads@ietf.org> <sec-ads@ietf.org>
Subject: Re: [= mpls] LDP Security

=C2= =A0

=C2=A0

=C2=A0

On Wed, Nov 8, 2017 at 3:50 PM, Uma Chunduri <uma.chunduri@huawei.com> wrote:

In-line [Uma1]:

<= p class=3D"MsoNormal">--

Uma C.<= /u>

=C2=A0

From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent:= Wednesday, November 08, 2017 12:53 PM
To: Uma Chunduri <<= /span>uma.chunduri@huawei.com>
Cc: Stew= art Bryant <stewart.bryant@gmail.com>;= mpl= s@ietf.org; pals-chairs@tools.ietf.org; <rtg-ads@ietf.org> <<= /span>rt= g-ads@ietf.org>; mpls-chairs@ietf.org<= /a>; pals@ietf.org; <sec-ads@ietf.org> <sec-ads@ietf.org>


Subject:= Re: [mpls] LDP Security

=C2=A0

=C2=A0<= /p>

=C2=A0

On Wed, Nov 8, 2017 at 11:57 AM, Uma Chunduri <uma.chunduri@huawei.c= om> wrote:

Hi Stewart,

=C2=A0

I would note https://tools.ietf.org/html/rfc6952 - where LDP security is analyzed from all aspects. <= /u>

=C2=A0

Eric,=

=C2=A0<= /span>

Q= uick comments below [Uma]:

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">=C2=A0

--

Uma C.

=C2=A0

From: mpls [ma= ilto:mpls-bounce= s@ietf.org] On Behalf Of Eric Rescorla
Sent: Wednesday= , November 08, 2017 10:00 AM
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: mpl= s@ietf.org; pals-chairs@tools.ietf.org; <rtg-ads@ietf.org> <rtg-ads@ietf.org>; mpls-chairs@ietf.org; pals@ietf.org; <sec-ads@ietf.org> <sec-ads@ietf.org>Subject: Re: [mpls] LDP Security

=C2=A0

Hi Stewa= rt

=C2=A0

Thanks for your note.

=C2=A0

My overall sense of the state of play is, I think much like you= rs.

=C2=A0=

TCP-MD5 is inadequate in two major re= spects:

- It uses weak a= lgorithms

- It has a bad= negotiation/setuop story (manual key management)

=C2=A0

TCP-AO is intended to be a drop-in replacement for TCP-MD5 and so = remedies the algorithm

I= ssue

=C2= =A0

[Uma]: Yes, if we go with RFC 5926 mandatory list..=

=C2=A0<= u>

but not the key management issue [0]. We h= aven't made much progress on the key

management story, and that seems to be a major impediment = to deploying either of these

technologies (which I am given to understand don't see a lot of us= e).

=C2= =A0

[Uma]: True.

=C2=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=A0But I would indicate some effort done few = years back regarding key management for pair wise routing protocols (BGP, L= DP, PCEP, MSDP ..).

=C2=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=A0One such proposal is by extending IKEv2= to negotiate TCP-AO MKTs (which can give rekey & algo. agility) - https://tools.ietf.org/html/draft-mahesh-karp-rkmp-05= =C2=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=A0This also requires some more work with TCP-AO; me & Joe = put together https://www.ietf.= org/archive/id/draft-chunduri-karp-using-ikev2-with-tcp-ao-06.txt=

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Note the = above didn=E2=80=99t progress in the concluded KARP WG (not fully sure the = reasons on why).

=C2=A0

Yeah, I know that people tried to do this, but my impression= was it kinda didn't progress much.

=C2=A0

= =C2=A0

=C2=A0

We should probably talk in Singapore about that, but that's not going to get bet= ter any time soon.

=C2=A0

In the interim, I think the text you have is OK, and "TBD" shoul= d read "SHA-256", with

the fallback being SHA-256 -> SHA-1 -> MD5.

=C2=A0<= /u>

[Uma]: While the l= ist can be extended - I didn=E2=80=99t see SHA256 in the mandatory list in = RFC 5926 for MAC.

=C2=A0

<= div>

Generally we're trying to move awa= y from SHA-1 towards SHA-256.

=C2=A0

[Uma1]: Couple of things:<= u>

1.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Noth= ing to be done (from spec pov of course): Use TCP-AO (instead of current MD5) with the RFC 5926 mandated MACs/KD= Fs =E2=80=93 so the =E2=80=98TBD=E2=80=99 in Stewart suggesting below is al= ready there.

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 As #1 too is not good enough from your above note - do SHA-256 a= nd live with it (no algorithm agility). Still a security benefit in one way= from existing stuff or even =C2=A0#1.

=

I'm not sure why you say "no algorithm agility". = You'd be using AO, just with a different algorithm than SHA-1. AES-CMAC= is still fine as far as I know.

[Uma2]: Sure, you have it, if you use = AO;

=C2=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=A0But then =C2=A0I am not getting how we can= mandate one MUST implement algorithm as suggested below TBD=C2=A0 would ac= tually work =C2=A0(especially - *if* #1 is already deployed somewher= e?)=C2=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=A0Perhaps staying with #1 is the= best bet or do negotiation through #3, with already mandated and additiona= l stuff.=C2=A0=C2=A0=C2=A0

=C2=A0

-Ekr

=C2=A0

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Do key management and =E2=80=9Ctheoreticall= y=E2=80=9D get all we wanted=E2=80=A6.

=C2=A0

We have been here multiple time= s; because #1 itself is not *mostly* deployed (neither in BGP nor in= LDP) if there is any appetite for #2 and #3 for practical deployments. But= still it may be good to do #2 any ways.

=C2=A0

=C2=A0

-Ekr

=C2= =A0

=C2=A0

-Ekr<= /u>

=C2=A0

=C2=A0

[0] Technically It has better support for rollover, but this= is not a huge improvement.

[1] tcpcrypt is kind of orthogonal here as it's unauthenticated but= opportunistic.=C2=A0 That said,

it would provide defense against attackers who gain access to the = link after connection

se= tup and doesn't require configuration.

=C2=A0

On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant <stewart.bryant@gmail.com> wr= ote:

To the SEC and RTG ADs,

I am sending the following me= ssage on behalf of the MPLS and the
PALS WG Chairs.

There is a co= ncern shared among the security community and the working groups that devel= op the LDP protocol that LDP is no longer adequately secured. LDP currently= relies on MD5 for cryptographic security of its messages, but MD5 is a has= h function that is no longer considered to meet current security requiremen= ts.

In RFC5036 (published 2007) Section 5.1 (Spoofing) , List elemen= t 2. Session communication carried by TCP the following statements is made:=

"LDP specifies use of the TCP MD5 Signature Option to provide = for the authenticity and integrity of session messages.

"[RFC23= 85] asserts that MD5 authentication is now considered by some to be too wea= k for this application.=C2=A0 It also points out that a similar TCP option = with a stronger hashing algorithm (it cites SHA-1 as an example) could be d= eployed.=C2=A0 To our knowledge, no such TCP option has been defined and de= ployed.=C2=A0 However, we note that LDP can use whatever TCP message digest= techniques are available, and when one stronger than MD5 is specified and = implemented, upgrading LDP to use it would be relatively straightforward.&q= uot;

We note that BGP has already been through this process, and rep= laced MD5 with TCP-AO in RFC 7454. I would be logical to follow the same ap= proach to secure LDP. However, as far as we are able to ascertain, there is= currently no recommended, mandatory to implement, cryptographic function s= pecified. We are concerned that without such a mandatory function, implemen= tations will simply fall back to MD5 and we will be no further forward
<= br>We think that the best way forward is to publish a draft similar to RFC = 7454 that contains the following requirement:

"Implementations = conforming to this RFC MUST implement TCP-AO to secure the TCP sessions car= rying LDP in addition to the currently required TCP MD5 Signature Option. F= urthermore, the TBD cryptographic mechanism must be implemented and provide= d to TCP-AO to secure LDP messages. The TBD mechanism is the preferred opti= on, and MD5 is only to be used when TBD is unavailable."

We are= not an experts on this part of the stack, but it seems that TCP security n= egotiation is still work in progress. If we are wrong, then we need to incl= ude a requirement that such negotiation is also required. In the absence of= a negotiation protocol, however, we need to leave this as a configuration = process until such time as the negotiation protocol work is complete. On co= mpletion of a suitable negotiation protocol we need to issue a further upda= te requiring its use.

Additionally we should note that no cryptograp= hic mechanism has an indefinite lifetime, and that implementation should no= te the IETF anticipates updating the default cryptographic mechanism over t= ime.

The TBD default security function will need to be chosen such t= hat it can reasonably be implemented on a typical router route processor, a= nd which will provide adequate security without significantly degrading the= convergence time of an LSR. Without a function that does not significantly= impact router convergence we simply close one vulnerability and open anoth= er.

As experts on the LDP protocol, but not on security mechanisms, = we=C2=A0 need to ask the security area for a review of our proposed approac= h, and help correcting any misunderstanding of the security issues or our m= isunderstanding of the existing security mechanisms. We also need the recom= mendations of a suitable security function (TBD in the above text).

= Best regards

The MPLS WG Chairs
The PALS WG Chairs<= /p>

=C2=A0

=

=C2=A0<= /p>

=C2=A0

=C2=A0

=
--001a114d9a28c9a6e2055d918dba-- From nobody Thu Nov 9 12:09:58 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C70129AD1; Thu, 9 Nov 2017 12:09:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 V2OcdRw010hh; Thu, 9 Nov 2017 12:09:49 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (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 1F475129AB3; Thu, 9 Nov 2017 12:09:49 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id s2so5568085pge.10; Thu, 09 Nov 2017 12:09:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mYEnohxa89uR+x1qb5ys8/ozeq9Fugapw5xoqvAr7GY=; b=UEp6L0ysBMzDeM+pU990WIOQZrjzUAUY8dUJQJoj0JxeF/ZizaMnxM03bzrhGEiSw5 59Wxr9G48qMpi6Dje9q6gXdvHiYwldZgceqP9iLqJrTly8pxKVcTG8HcjDPW6CJiBJDt 22lQ6VIAjZZwhJF+3e91oSptsGLGCP4BUBTtURUdu9QbQa17ga0hxoLeKuWAGnnWN9rH ENc9JgtM5Tkeo5Im7/4AEHnuyh9/eN10atE3y14cYiL3UyuLgTXcEH95DutlfZm7pa7o EYOt5DiXZaW+P3tdEvpngIDZwoimLe/XxeaB5FsGgX5Z+i4A091rCxYOEKPI+kynqP2l vo5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mYEnohxa89uR+x1qb5ys8/ozeq9Fugapw5xoqvAr7GY=; b=Uwi3g2yKRo9FOoDhBPWDgQMRfkTLl/oyYOzq7qbKlDUqfzzwy4oTWkfYli60DmtbyE DZLCiL+vDg2qWGQsCTAuiOjEhMYppPI0pydKUGnLxMKl1X5DtJH3AFtHAgh/gRaDJ+35 ABhzUeyk82xRpXspTfvsYiWLGkQMU8wHSUy46uXdZ6WHreJdpTbuBTjUqV1abr7lfS6Q s81mcGe24aGmqmJQH4CHIk/uXCusa0U7YiRgfTVeiSl/+pUQDjYeUM1JR5oFA+tF038x hAwxX/Dinp0bPO9NyN2DYQSJKc2aOZwMnm5Xm7Q5OIGcHEljMOIsObF6qJqUgBiquSdO KJ6Q== X-Gm-Message-State: AJaThX6PmwuVKTYsh1JfDbszBVdV0oRT29sHvjQ12xEJCuWkSHU0H5na rDmSa7hpxFerJCnpjeuU2UOGxY2XkWRZi+C2wBI= X-Google-Smtp-Source: ABhQp+T8DHV/zLGsYfAOjFUtDx9/OQZWZFe9aAFjfzUzvknwmufftXQm0rcSpe+qWfc6A3V3zz9cNVzbL8EjpnVGhWM= X-Received: by 10.99.117.7 with SMTP id q7mr1574357pgc.339.1510258188577; Thu, 09 Nov 2017 12:09:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.155.9 with HTTP; Thu, 9 Nov 2017 12:09:08 -0800 (PST) In-Reply-To: References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <5994f353-5306-0fa8-2d2d-024ebdbb10df@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> <25B4902B1192E84696414485F5726854135191D6@sjceml521-mbs.china.huawei.com> <25B4902B1192E84696414485F572685413519209@sjceml521-mbs.china.huawei.com> <002101d35919$c6295b90$527c12b0$@ndzh.com> From: Kathleen Moriarty Date: Thu, 9 Nov 2017 15:09:08 -0500 Message-ID: To: Eric Rescorla Cc: Susan Hares , Uma Chunduri , mpls@ietf.org, pals-chairs@tools.ietf.org, "" , mpls-chairs , pals@ietf.org, "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Pals] [mpls] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 20:09:52 -0000 On Thu, Nov 9, 2017 at 2:09 PM, Eric Rescorla wrote: > Yeah, I agree. I don't really have any good ideas how to get people to do > AO. Based on comments I've heard, providers don't see a lot of value, > rightly or wrongly.... I know Alia has been talking about a possible Linux implementation to drive the way. I agree with EKR on other points and have been following along. Best, Kathleen > > -Ekr > > > On Wed, Nov 8, 2017 at 9:15 PM, Susan Hares wrote: >> >> Eric: >> >> >> >> BGP and LDP would be more secure if TCP-AO deployed with all BGP and LDP= =E2=80=93 >> but there are issues with customer pick-up and deployment of these proto= cols >> on many networks. I wished we had TCP-AO when BGP started, but we did n= ot. >> >> >> >> Some of the least secure BGP is in data centers =E2=80=93 where the DC p= roviders >> say =E2=80=9CIt=E2=80=99s all under one administration=E2=80=9D. Anothe= r problem is on private >> lines. We should chat about the networks each of these protocols are >> actually deployed on. If you have any insight on a way to encourage >> adoption, I=E2=80=99d love to hear it. Require TCP-AO does not really me= an anything >> if providers and Data Centers do not adopt it. >> >> >> >> Going from SHA-1 to SHA-256 on a TCP-AO is simple upgrade compared to >> getting people to TCP-AO. >> >> >> >> Sue >> >> >> >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla >> Sent: Wednesday, November 8, 2017 7:44 PM >> To: Uma Chunduri >> Cc: mpls@ietf.org; pals-chairs@tools.ietf.org; ; >> mpls-chairs@ietf.org; pals@ietf.org; >> >> >> Subject: Re: [mpls] LDP Security >> >> >> >> I don't understand what you're getting at here. Yes, if people have TCP-= AO >> then presumably they have SHA-1. >> >> >> >> But now we're talking about requiring people to have TCP-AO in this case= , >> so we should try to move them to SHA-256 at the time we require AO. >> >> >> >> -Ekr >> >> >> >> >> >> On Wed, Nov 8, 2017 at 4:14 PM, Uma Chunduri >> wrote: >> >> From: Eric Rescorla [mailto:ekr@rtfm.com] >> Sent: Wednesday, November 08, 2017 3:53 PM >> >> >> To: Uma Chunduri >> Cc: Stewart Bryant ; mpls@ietf.org; >> pals-chairs@tools.ietf.org; ; >> mpls-chairs@ietf.org; pals@ietf.org; >> Subject: Re: [mpls] LDP Security >> >> >> >> >> >> >> >> On Wed, Nov 8, 2017 at 3:50 PM, Uma Chunduri >> wrote: >> >> In-line [Uma1]: >> >> -- >> >> Uma C. >> >> >> >> From: Eric Rescorla [mailto:ekr@rtfm.com] >> Sent: Wednesday, November 08, 2017 12:53 PM >> To: Uma Chunduri >> Cc: Stewart Bryant ; mpls@ietf.org; >> pals-chairs@tools.ietf.org; ; >> mpls-chairs@ietf.org; pals@ietf.org; >> >> >> Subject: Re: [mpls] LDP Security >> >> >> >> >> >> >> >> On Wed, Nov 8, 2017 at 11:57 AM, Uma Chunduri >> wrote: >> >> Hi Stewart, >> >> >> >> I would note https://tools.ietf.org/html/rfc6952 - where LDP security is >> analyzed from all aspects. >> >> >> >> Eric, >> >> >> >> Quick comments below [Uma]: >> >> >> >> -- >> >> Uma C. >> >> >> >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla >> Sent: Wednesday, November 08, 2017 10:00 AM >> To: Stewart Bryant >> Cc: mpls@ietf.org; pals-chairs@tools.ietf.org; >> ; mpls-chairs@ietf.org; pals@ietf.org; >> >> Subject: Re: [mpls] LDP Security >> >> >> >> Hi Stewart >> >> >> >> Thanks for your note. >> >> >> >> My overall sense of the state of play is, I think much like yours. >> >> >> >> TCP-MD5 is inadequate in two major respects: >> >> - It uses weak algorithms >> >> - It has a bad negotiation/setuop story (manual key management) >> >> >> >> TCP-AO is intended to be a drop-in replacement for TCP-MD5 and so remedi= es >> the algorithm >> >> Issue >> >> >> >> [Uma]: Yes, if we go with RFC 5926 mandatory list.. >> >> >> >> but not the key management issue [0]. We haven't made much progress on t= he >> key >> >> management story, and that seems to be a major impediment to deploying >> either of these >> >> technologies (which I am given to understand don't see a lot of use). >> >> >> >> [Uma]: True. >> >> But I would indicate some effort done few years back >> regarding key management for pair wise routing protocols (BGP, LDP, PCEP= , >> MSDP ..). >> >> One such proposal is by extending IKEv2 to negotiate TCP-= AO >> MKTs (which can give rekey & algo. agility) - >> https://tools.ietf.org/html/draft-mahesh-karp-rkmp-05 >> >> This also requires some more work with TCP-AO; me & Joe p= ut >> together >> https://www.ietf.org/archive/id/draft-chunduri-karp-using-ikev2-with-tcp= -ao-06.txt >> >> Note the above didn=E2=80=99t progress in the concluded KARP = WG (not >> fully sure the reasons on why). >> >> >> >> Yeah, I know that people tried to do this, but my impression was it kind= a >> didn't progress much. >> >> >> >> >> >> >> >> We should probably talk in Singapore about that, but that's not going to >> get better any time soon. >> >> >> >> In the interim, I think the text you have is OK, and "TBD" should read >> "SHA-256", with >> >> the fallback being SHA-256 -> SHA-1 -> MD5. >> >> >> >> [Uma]: While the list can be extended - I didn=E2=80=99t see SHA256 in t= he >> mandatory list in RFC 5926 for MAC. >> >> >> >> Generally we're trying to move away from SHA-1 towards SHA-256. >> >> >> >> [Uma1]: Couple of things: >> >> 1. Nothing to be done (from spec pov of course): Use TCP-AO (inste= ad >> of current MD5) with the RFC 5926 mandated MACs/KDFs =E2=80=93 so the = =E2=80=98TBD=E2=80=99 in >> Stewart suggesting below is already there. >> >> 2. As #1 too is not good enough from your above note - do SHA-256 >> and live with it (no algorithm agility). Still a security benefit in one= way >> from existing stuff or even #1. >> >> I'm not sure why you say "no algorithm agility". You'd be using AO, just >> with a different algorithm than SHA-1. AES-CMAC is still fine as far as = I >> know. >> >> [Uma2]: Sure, you have it, if you use AO; >> >> But then I am not getting how we can mandate one MUST >> implement algorithm as suggested below TBD would actually work (especi= ally >> - *if* #1 is already deployed somewhere?) >> >> Perhaps staying with #1 is the best bet or do negotiati= on >> through #3, with already mandated and additional stuff. >> >> >> >> -Ekr >> >> >> >> 3. Do key management and =E2=80=9Ctheoretically=E2=80=9D get all w= e wanted=E2=80=A6. >> >> >> >> We have been here multiple times; because #1 itself is not *mostly* >> deployed (neither in BGP nor in LDP) if there is any appetite for #2 and= #3 >> for practical deployments. But still it may be good to do #2 any ways. >> >> >> >> >> >> -Ekr >> >> >> >> >> >> -Ekr >> >> >> >> >> >> [0] Technically It has better support for rollover, but this is not a hu= ge >> improvement. >> >> [1] tcpcrypt is kind of orthogonal here as it's unauthenticated but >> opportunistic. That said, >> >> it would provide defense against attackers who gain access to the link >> after connection >> >> setup and doesn't require configuration. >> >> >> >> On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant >> wrote: >> >> To the SEC and RTG ADs, >> >> I am sending the following message on behalf of the MPLS and the >> PALS WG Chairs. >> >> There is a concern shared among the security community and the working >> groups that develop the LDP protocol that LDP is no longer adequately >> secured. LDP currently relies on MD5 for cryptographic security of its >> messages, but MD5 is a hash function that is no longer considered to mee= t >> current security requirements. >> >> In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2. >> Session communication carried by TCP the following statements is made: >> >> "LDP specifies use of the TCP MD5 Signature Option to provide for the >> authenticity and integrity of session messages. >> >> "[RFC2385] asserts that MD5 authentication is now considered by some to = be >> too weak for this application. It also points out that a similar TCP op= tion >> with a stronger hashing algorithm (it cites SHA-1 as an example) could b= e >> deployed. To our knowledge, no such TCP option has been defined and >> deployed. However, we note that LDP can use whatever TCP message digest >> techniques are available, and when one stronger than MD5 is specified an= d >> implemented, upgrading LDP to use it would be relatively straightforward= ." >> >> We note that BGP has already been through this process, and replaced MD5 >> with TCP-AO in RFC 7454. I would be logical to follow the same approach = to >> secure LDP. However, as far as we are able to ascertain, there is curren= tly >> no recommended, mandatory to implement, cryptographic function specified= . We >> are concerned that without such a mandatory function, implementations wi= ll >> simply fall back to MD5 and we will be no further forward >> >> We think that the best way forward is to publish a draft similar to RFC >> 7454 that contains the following requirement: >> >> "Implementations conforming to this RFC MUST implement TCP-AO to secure >> the TCP sessions carrying LDP in addition to the currently required TCP = MD5 >> Signature Option. Furthermore, the TBD cryptographic mechanism must be >> implemented and provided to TCP-AO to secure LDP messages. The TBD mecha= nism >> is the preferred option, and MD5 is only to be used when TBD is >> unavailable." >> >> We are not an experts on this part of the stack, but it seems that TCP >> security negotiation is still work in progress. If we are wrong, then we >> need to include a requirement that such negotiation is also required. In= the >> absence of a negotiation protocol, however, we need to leave this as a >> configuration process until such time as the negotiation protocol work i= s >> complete. On completion of a suitable negotiation protocol we need to is= sue >> a further update requiring its use. >> >> Additionally we should note that no cryptographic mechanism has an >> indefinite lifetime, and that implementation should note the IETF >> anticipates updating the default cryptographic mechanism over time. >> >> The TBD default security function will need to be chosen such that it ca= n >> reasonably be implemented on a typical router route processor, and which >> will provide adequate security without significantly degrading the >> convergence time of an LSR. Without a function that does not significant= ly >> impact router convergence we simply close one vulnerability and open >> another. >> >> As experts on the LDP protocol, but not on security mechanisms, we need >> to ask the security area for a review of our proposed approach, and help >> correcting any misunderstanding of the security issues or our >> misunderstanding of the existing security mechanisms. We also need the >> recommendations of a suitable security function (TBD in the above text). >> >> Best regards >> >> The MPLS WG Chairs >> The PALS WG Chairs >> >> >> >> >> >> >> >> > > --=20 Best regards, Kathleen From nobody Thu Nov 9 15:02:09 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20170129353; Thu, 9 Nov 2017 15:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 CAgBR6EQk6Ie; Thu, 9 Nov 2017 15:02:02 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 0DD1B129411; Thu, 9 Nov 2017 15:02:02 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id r68so3902567wmr.0; Thu, 09 Nov 2017 15:02:01 -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-transfer-encoding:content-language; bh=LrNpCtJyE/DN1qPFngxCsdDhpW6JsWB/iY4oklx+q40=; b=J3Np7Y5fdzxxREp39+DSvz88IXmDRDKqM+d97CRCGkUFck4h38VbKdUakqD/a1HbSU msLByEIJRmKppyZldeBS9NbgXluIJ5bcHGylcY3hzQatlgAI5rkDDJVYH7bbutWIeyUm IO4xs+pvl4yzCkF2caw2G1d1zAY+ygJahkapga6n9ah6IzryAlRijHdl/PQV3hmLSuj5 GRkdquG8Y5GlwWHQdFHHlJjiv2b/sXsgbLvKAivxSjcqMR7S7ATzoQR+hZ5uwzO0M2ID qTKS9qZ+0OLR3DL3hI5nvD27X10dB86srHqpX0O3yhh1A8ZgJp/24elQI5E7g62VxHmh KO3Q== 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-transfer-encoding :content-language; bh=LrNpCtJyE/DN1qPFngxCsdDhpW6JsWB/iY4oklx+q40=; b=MZbHyPfA6Rrysky6FFIjIYBAjQs2tVqWqyclMPo2+nfGxg84a5ahlBC/m6AADbdtCl BIrPC1p60KFKCJDvUvk2S/Jh4t+FHf8DOJAGnTTSiOWHl7h9bOif3+R4oC0SJpNZKcv+ dv4iKaxiSV9ePzj2dahzH6AMgCA4N9HuvWePWfb3DHvkeRZyQvr84Lk+3Pf9k603UXkp aUgKTY25ojljgPVH9C8TfUvdZ1WgoEYfbXcmZpltH6KjbDsC3tbKRDbZmdz4k2OScKn5 xFZEgI09EzBywVNY5aRfN+zdZQTxHuOIPomMiVeQMLVsrd31w/zbZ+YP6IrZimbikXIB T6SA== X-Gm-Message-State: AJaThX7LGyii5EcwuXvo1Sou720pivZDsLWaDLQYjWdifWed5OOpxqk1 0gNsz6aM5yaKumBUeytXLKvoHEM5 X-Google-Smtp-Source: AGs4zMYjUrtwo2+WkvWAWXIwkc8wo3/SO6g26GilFtL8D3HxA9Kch+IpcV7yI6GUFVxuLqdecPQrbg== X-Received: by 10.28.58.145 with SMTP id h139mr973197wma.56.1510268520213; Thu, 09 Nov 2017 15:02:00 -0800 (PST) Received: from [192.168.2.174] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id f19sm9493176wrh.64.2017.11.09.15.01.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Nov 2017 15:01:59 -0800 (PST) To: Kathleen Moriarty , Eric Rescorla Cc: mpls@ietf.org, pals-chairs@tools.ietf.org, "" , mpls-chairs , pals@ietf.org, "" References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> <25B4902B1192E84696414485F5726854135191D6@sjceml521-mbs.china.huawei.com> <25B4902B1192E84696414485F572685413519209@sjceml521-mbs.china.huawei.com> <002101d35919$c6295b90$527c12b0$@ndzh.com> From: Stewart Bryant Message-ID: Date: Thu, 9 Nov 2017 23:02:08 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [Pals] [mpls] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 23:02:06 -0000 Another data point is that for a long time operators only turned on MD5 for the link state protocols to get a better checksum, not because they perceived a threat. There is security at different levels, for example MACsec, which has the advantage of securing the customer traffic from pervasive monitoring as well as securing the routing layer. Additionally it is common for customer traffic gets put straight into MPLS and so cannot be used as an attack vector. - Stewart On 09/11/2017 20:09, Kathleen Moriarty wrote: > On Thu, Nov 9, 2017 at 2:09 PM, Eric Rescorla wrote: >> Yeah, I agree. I don't really have any good ideas how to get people to do >> AO. Based on comments I've heard, providers don't see a lot of value, >> rightly or wrongly.... > I know Alia has been talking about a possible Linux implementation to > drive the way. I agree with EKR on other points and have been > following along. > > Best, > Kathleen >> -Ekr >> >> >> On Wed, Nov 8, 2017 at 9:15 PM, Susan Hares wrote: >>> Eric: >>> >>> >>> >>> BGP and LDP would be more secure if TCP-AO deployed with all BGP and LDP – >>> but there are issues with customer pick-up and deployment of these protocols >>> on many networks. I wished we had TCP-AO when BGP started, but we did not. >>> >>> >>> >>> Some of the least secure BGP is in data centers – where the DC providers >>> say “It’s all under one administration”. Another problem is on private >>> lines. We should chat about the networks each of these protocols are >>> actually deployed on. If you have any insight on a way to encourage >>> adoption, I’d love to hear it. Require TCP-AO does not really mean anything >>> if providers and Data Centers do not adopt it. >>> >>> >>> >>> Going from SHA-1 to SHA-256 on a TCP-AO is simple upgrade compared to >>> getting people to TCP-AO. >>> >>> >>> >>> Sue >>> >>> >>> >>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla >>> Sent: Wednesday, November 8, 2017 7:44 PM >>> To: Uma Chunduri >>> Cc: mpls@ietf.org; pals-chairs@tools.ietf.org; ; >>> mpls-chairs@ietf.org; pals@ietf.org; >>> >>> >>> Subject: Re: [mpls] LDP Security >>> >>> >>> >>> I don't understand what you're getting at here. Yes, if people have TCP-AO >>> then presumably they have SHA-1. >>> >>> >>> >>> But now we're talking about requiring people to have TCP-AO in this case, >>> so we should try to move them to SHA-256 at the time we require AO. >>> >>> >>> >>> -Ekr >>> >>> >>> >>> >>> >>> On Wed, Nov 8, 2017 at 4:14 PM, Uma Chunduri >>> wrote: >>> >>> From: Eric Rescorla [mailto:ekr@rtfm.com] >>> Sent: Wednesday, November 08, 2017 3:53 PM >>> >>> >>> To: Uma Chunduri >>> Cc: Stewart Bryant ; mpls@ietf.org; >>> pals-chairs@tools.ietf.org; ; >>> mpls-chairs@ietf.org; pals@ietf.org; >>> Subject: Re: [mpls] LDP Security >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Nov 8, 2017 at 3:50 PM, Uma Chunduri >>> wrote: >>> >>> In-line [Uma1]: >>> >>> -- >>> >>> Uma C. >>> >>> >>> >>> From: Eric Rescorla [mailto:ekr@rtfm.com] >>> Sent: Wednesday, November 08, 2017 12:53 PM >>> To: Uma Chunduri >>> Cc: Stewart Bryant ; mpls@ietf.org; >>> pals-chairs@tools.ietf.org; ; >>> mpls-chairs@ietf.org; pals@ietf.org; >>> >>> >>> Subject: Re: [mpls] LDP Security >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Nov 8, 2017 at 11:57 AM, Uma Chunduri >>> wrote: >>> >>> Hi Stewart, >>> >>> >>> >>> I would note https://tools.ietf.org/html/rfc6952 - where LDP security is >>> analyzed from all aspects. >>> >>> >>> >>> Eric, >>> >>> >>> >>> Quick comments below [Uma]: >>> >>> >>> >>> -- >>> >>> Uma C. >>> >>> >>> >>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla >>> Sent: Wednesday, November 08, 2017 10:00 AM >>> To: Stewart Bryant >>> Cc: mpls@ietf.org; pals-chairs@tools.ietf.org; >>> ; mpls-chairs@ietf.org; pals@ietf.org; >>> >>> Subject: Re: [mpls] LDP Security >>> >>> >>> >>> Hi Stewart >>> >>> >>> >>> Thanks for your note. >>> >>> >>> >>> My overall sense of the state of play is, I think much like yours. >>> >>> >>> >>> TCP-MD5 is inadequate in two major respects: >>> >>> - It uses weak algorithms >>> >>> - It has a bad negotiation/setuop story (manual key management) >>> >>> >>> >>> TCP-AO is intended to be a drop-in replacement for TCP-MD5 and so remedies >>> the algorithm >>> >>> Issue >>> >>> >>> >>> [Uma]: Yes, if we go with RFC 5926 mandatory list.. >>> >>> >>> >>> but not the key management issue [0]. We haven't made much progress on the >>> key >>> >>> management story, and that seems to be a major impediment to deploying >>> either of these >>> >>> technologies (which I am given to understand don't see a lot of use). >>> >>> >>> >>> [Uma]: True. >>> >>> But I would indicate some effort done few years back >>> regarding key management for pair wise routing protocols (BGP, LDP, PCEP, >>> MSDP ..). >>> >>> One such proposal is by extending IKEv2 to negotiate TCP-AO >>> MKTs (which can give rekey & algo. agility) - >>> https://tools.ietf.org/html/draft-mahesh-karp-rkmp-05 >>> >>> This also requires some more work with TCP-AO; me & Joe put >>> together >>> https://www.ietf.org/archive/id/draft-chunduri-karp-using-ikev2-with-tcp-ao-06.txt >>> >>> Note the above didn’t progress in the concluded KARP WG (not >>> fully sure the reasons on why). >>> >>> >>> >>> Yeah, I know that people tried to do this, but my impression was it kinda >>> didn't progress much. >>> >>> >>> >>> >>> >>> >>> >>> We should probably talk in Singapore about that, but that's not going to >>> get better any time soon. >>> >>> >>> >>> In the interim, I think the text you have is OK, and "TBD" should read >>> "SHA-256", with >>> >>> the fallback being SHA-256 -> SHA-1 -> MD5. >>> >>> >>> >>> [Uma]: While the list can be extended - I didn’t see SHA256 in the >>> mandatory list in RFC 5926 for MAC. >>> >>> >>> >>> Generally we're trying to move away from SHA-1 towards SHA-256. >>> >>> >>> >>> [Uma1]: Couple of things: >>> >>> 1. Nothing to be done (from spec pov of course): Use TCP-AO (instead >>> of current MD5) with the RFC 5926 mandated MACs/KDFs – so the ‘TBD’ in >>> Stewart suggesting below is already there. >>> >>> 2. As #1 too is not good enough from your above note - do SHA-256 >>> and live with it (no algorithm agility). Still a security benefit in one way >>> from existing stuff or even #1. >>> >>> I'm not sure why you say "no algorithm agility". You'd be using AO, just >>> with a different algorithm than SHA-1. AES-CMAC is still fine as far as I >>> know. >>> >>> [Uma2]: Sure, you have it, if you use AO; >>> >>> But then I am not getting how we can mandate one MUST >>> implement algorithm as suggested below TBD would actually work (especially >>> - *if* #1 is already deployed somewhere?) >>> >>> Perhaps staying with #1 is the best bet or do negotiation >>> through #3, with already mandated and additional stuff. >>> >>> >>> >>> -Ekr >>> >>> >>> >>> 3. Do key management and “theoretically” get all we wanted…. >>> >>> >>> >>> We have been here multiple times; because #1 itself is not *mostly* >>> deployed (neither in BGP nor in LDP) if there is any appetite for #2 and #3 >>> for practical deployments. But still it may be good to do #2 any ways. >>> >>> >>> >>> >>> >>> -Ekr >>> >>> >>> >>> >>> >>> -Ekr >>> >>> >>> >>> >>> >>> [0] Technically It has better support for rollover, but this is not a huge >>> improvement. >>> >>> [1] tcpcrypt is kind of orthogonal here as it's unauthenticated but >>> opportunistic. That said, >>> >>> it would provide defense against attackers who gain access to the link >>> after connection >>> >>> setup and doesn't require configuration. >>> >>> >>> >>> On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant >>> wrote: >>> >>> To the SEC and RTG ADs, >>> >>> I am sending the following message on behalf of the MPLS and the >>> PALS WG Chairs. >>> >>> There is a concern shared among the security community and the working >>> groups that develop the LDP protocol that LDP is no longer adequately >>> secured. LDP currently relies on MD5 for cryptographic security of its >>> messages, but MD5 is a hash function that is no longer considered to meet >>> current security requirements. >>> >>> In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2. >>> Session communication carried by TCP the following statements is made: >>> >>> "LDP specifies use of the TCP MD5 Signature Option to provide for the >>> authenticity and integrity of session messages. >>> >>> "[RFC2385] asserts that MD5 authentication is now considered by some to be >>> too weak for this application. It also points out that a similar TCP option >>> with a stronger hashing algorithm (it cites SHA-1 as an example) could be >>> deployed. To our knowledge, no such TCP option has been defined and >>> deployed. However, we note that LDP can use whatever TCP message digest >>> techniques are available, and when one stronger than MD5 is specified and >>> implemented, upgrading LDP to use it would be relatively straightforward." >>> >>> We note that BGP has already been through this process, and replaced MD5 >>> with TCP-AO in RFC 7454. I would be logical to follow the same approach to >>> secure LDP. However, as far as we are able to ascertain, there is currently >>> no recommended, mandatory to implement, cryptographic function specified. We >>> are concerned that without such a mandatory function, implementations will >>> simply fall back to MD5 and we will be no further forward >>> >>> We think that the best way forward is to publish a draft similar to RFC >>> 7454 that contains the following requirement: >>> >>> "Implementations conforming to this RFC MUST implement TCP-AO to secure >>> the TCP sessions carrying LDP in addition to the currently required TCP MD5 >>> Signature Option. Furthermore, the TBD cryptographic mechanism must be >>> implemented and provided to TCP-AO to secure LDP messages. The TBD mechanism >>> is the preferred option, and MD5 is only to be used when TBD is >>> unavailable." >>> >>> We are not an experts on this part of the stack, but it seems that TCP >>> security negotiation is still work in progress. If we are wrong, then we >>> need to include a requirement that such negotiation is also required. In the >>> absence of a negotiation protocol, however, we need to leave this as a >>> configuration process until such time as the negotiation protocol work is >>> complete. On completion of a suitable negotiation protocol we need to issue >>> a further update requiring its use. >>> >>> Additionally we should note that no cryptographic mechanism has an >>> indefinite lifetime, and that implementation should note the IETF >>> anticipates updating the default cryptographic mechanism over time. >>> >>> The TBD default security function will need to be chosen such that it can >>> reasonably be implemented on a typical router route processor, and which >>> will provide adequate security without significantly degrading the >>> convergence time of an LSR. Without a function that does not significantly >>> impact router convergence we simply close one vulnerability and open >>> another. >>> >>> As experts on the LDP protocol, but not on security mechanisms, we need >>> to ask the security area for a review of our proposed approach, and help >>> correcting any misunderstanding of the security issues or our >>> misunderstanding of the existing security mechanisms. We also need the >>> recommendations of a suitable security function (TBD in the above text). >>> >>> Best regards >>> >>> The MPLS WG Chairs >>> The PALS WG Chairs >>> >>> >>> >>> >>> >>> >>> >>> >> > > From nobody Thu Nov 9 23:16:34 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E746612EB71 for ; Thu, 9 Nov 2017 23:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 LSAvFAS0pb4B for ; Thu, 9 Nov 2017 23:16:14 -0800 (PST) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 D694112EB90 for ; Thu, 9 Nov 2017 23:16:06 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id q126so7414813ywq.10 for ; Thu, 09 Nov 2017 23:16:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9H37yw4fcL6CsxOpblHeImKfp+2lbd+c/PW5qlGKr8A=; b=a+ULuRxxTiYinzDdokc7psk4BqRouVR/U4EXZLmuz5RK6FzrIptfgCIhcsd3YGynXd /h2aiN+7yNXvJuCcrx7/EzQOWCT0oMeIfnwPCVqY78PHUTWVlbTJ26GzzRdh5jhgKvZ0 Phdp1ATLjUnhAlqXpXpGqxDNe6EF7gJ0nNDxL/dzk4BkYNHSHra0H7qh3rJrvwe1Trm2 LvOLcGrtf5QfpqcqATeRLGD6y57pJ75flANHA8pnnqykR6wtb3o4a1rWxck4XI7MwHAK QcjfnZHvZU171FwsFAPX2bZXd3ajDE5jDcX0TY0ayoTjI9F+YSEZXsKe54nDE8GnG+bH 4ScQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9H37yw4fcL6CsxOpblHeImKfp+2lbd+c/PW5qlGKr8A=; b=lSIDQc/iixUqSRZaB6fZ2AgEP7y1UKTvIBS0m75AcplL0xKdOP6/DmwyKYh+mHT+kq ZXf0HOilKMlfMUhs8ubbAx4aRan0arJDoGbRRul5V0Cf04ATmw1jZJ1TuFPN6ApBsf7t XcGdXcFohk4iL9d5uPmaxP6xaKQ80WKn1Od3rcyiKSUKfXSvxXnMUpcm/zCPQApw318k vPiGr3a128EBXrbEcVoZfq6Er0+wHoGos7sO0UMyFs1yNBkfjlhnsQlbcbIEX2NYtQIp aArwmSbjX5oToxeUF+PsXrTil/vVV4TurGV9ri9Bag5+ODh2UkjZB3X691l9AtVlmizf iLKg== X-Gm-Message-State: AJaThX7CERDhxzJ0U9pHPNuJJpGvv0l7g8wi4bQ/R/OVNwYD64n6wBhv 6CFRch0K5zPNW8kFPCd3wQ6hCEAfC1vGyuTFmxEgHw== X-Google-Smtp-Source: ABhQp+SBMvmPBlf+ZoJoQD4XSd1A0SmMklbkX89s2fM46YI7jmWODR++swcb7u5HVTOz29HHQEHla5nDivD1ge2sjJ4= X-Received: by 10.129.26.208 with SMTP id a199mr2017597ywa.280.1510298166033; Thu, 09 Nov 2017 23:16:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Thu, 9 Nov 2017 23:15:25 -0800 (PST) In-Reply-To: References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> <25B4902B1192E84696414485F5726854135191D6@sjceml521-mbs.china.huawei.com> <25B4902B1192E84696414485F572685413519209@sjceml521-mbs.china.huawei.com> <002101d35919$c6295b90$527c12b0$@ndzh.com> From: Eric Rescorla Date: Thu, 9 Nov 2017 23:15:25 -0800 Message-ID: To: Stewart Bryant Cc: Kathleen Moriarty , mpls@ietf.org, pals-chairs@tools.ietf.org, "" , mpls-chairs , pals@ietf.org, "" Content-Type: multipart/alternative; boundary="001a1142d0d4b121a5055d9bb133" Archived-At: Subject: Re: [Pals] [mpls] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 07:16:18 -0000 --001a1142d0d4b121a5055d9bb133 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Nov 9, 2017 at 3:02 PM, Stewart Bryant wrote: > Another data point is that for a long time operators only turned on MD5 > for the > link state protocols to get a better checksum, not because they perceived > a threat. > FWIW, I agree that MD5 is a fine checksum. -Ekr > > There is security at different levels, for example MACsec, which has the > advantage > of securing the customer traffic from pervasive monitoring as well as > securing the > routing layer. Additionally it is common for customer traffic gets put > straight > into MPLS and so cannot be used as an attack vector. > > - Stewart > > > > On 09/11/2017 20:09, Kathleen Moriarty wrote: > >> On Thu, Nov 9, 2017 at 2:09 PM, Eric Rescorla wrote: >> >>> Yeah, I agree. I don't really have any good ideas how to get people to = do >>> AO. Based on comments I've heard, providers don't see a lot of value, >>> rightly or wrongly.... >>> >> I know Alia has been talking about a possible Linux implementation to >> drive the way. I agree with EKR on other points and have been >> following along. >> >> Best, >> Kathleen >> >>> -Ekr >>> >>> >>> On Wed, Nov 8, 2017 at 9:15 PM, Susan Hares wrote: >>> >>>> Eric: >>>> >>>> >>>> >>>> BGP and LDP would be more secure if TCP-AO deployed with all BGP and >>>> LDP =E2=80=93 >>>> but there are issues with customer pick-up and deployment of these >>>> protocols >>>> on many networks. I wished we had TCP-AO when BGP started, but we did >>>> not. >>>> >>>> >>>> >>>> Some of the least secure BGP is in data centers =E2=80=93 where the DC= providers >>>> say =E2=80=9CIt=E2=80=99s all under one administration=E2=80=9D. Anot= her problem is on private >>>> lines. We should chat about the networks each of these protocols ar= e >>>> actually deployed on. If you have any insight on a way to encourage >>>> adoption, I=E2=80=99d love to hear it. Require TCP-AO does not really = mean >>>> anything >>>> if providers and Data Centers do not adopt it. >>>> >>>> >>>> >>>> Going from SHA-1 to SHA-256 on a TCP-AO is simple upgrade compared to >>>> getting people to TCP-AO. >>>> >>>> >>>> >>>> Sue >>>> >>>> >>>> >>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla >>>> Sent: Wednesday, November 8, 2017 7:44 PM >>>> To: Uma Chunduri >>>> Cc: mpls@ietf.org; pals-chairs@tools.ietf.org; ; >>>> mpls-chairs@ietf.org; pals@ietf.org; >>>> >>>> >>>> Subject: Re: [mpls] LDP Security >>>> >>>> >>>> >>>> I don't understand what you're getting at here. Yes, if people have >>>> TCP-AO >>>> then presumably they have SHA-1. >>>> >>>> >>>> >>>> But now we're talking about requiring people to have TCP-AO in this >>>> case, >>>> so we should try to move them to SHA-256 at the time we require AO. >>>> >>>> >>>> >>>> -Ekr >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Nov 8, 2017 at 4:14 PM, Uma Chunduri >>>> wrote: >>>> >>>> From: Eric Rescorla [mailto:ekr@rtfm.com] >>>> Sent: Wednesday, November 08, 2017 3:53 PM >>>> >>>> >>>> To: Uma Chunduri >>>> Cc: Stewart Bryant ; mpls@ietf.org; >>>> pals-chairs@tools.ietf.org; ; >>>> mpls-chairs@ietf.org; pals@ietf.org; < >>>> sec-ads@ietf.org> >>>> Subject: Re: [mpls] LDP Security >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Nov 8, 2017 at 3:50 PM, Uma Chunduri >>>> wrote: >>>> >>>> In-line [Uma1]: >>>> >>>> -- >>>> >>>> Uma C. >>>> >>>> >>>> >>>> From: Eric Rescorla [mailto:ekr@rtfm.com] >>>> Sent: Wednesday, November 08, 2017 12:53 PM >>>> To: Uma Chunduri >>>> Cc: Stewart Bryant ; mpls@ietf.org; >>>> pals-chairs@tools.ietf.org; ; >>>> mpls-chairs@ietf.org; pals@ietf.org; < >>>> sec-ads@ietf.org> >>>> >>>> >>>> Subject: Re: [mpls] LDP Security >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Nov 8, 2017 at 11:57 AM, Uma Chunduri >>>> wrote: >>>> >>>> Hi Stewart, >>>> >>>> >>>> >>>> I would note https://tools.ietf.org/html/rfc6952 - where LDP security >>>> is >>>> analyzed from all aspects. >>>> >>>> >>>> >>>> Eric, >>>> >>>> >>>> >>>> Quick comments below [Uma]: >>>> >>>> >>>> >>>> -- >>>> >>>> Uma C. >>>> >>>> >>>> >>>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla >>>> Sent: Wednesday, November 08, 2017 10:00 AM >>>> To: Stewart Bryant >>>> Cc: mpls@ietf.org; pals-chairs@tools.ietf.org; >>>> ; mpls-chairs@ietf.org; pals@ietf.org; < >>>> sec-ads@ietf.org> >>>> >>>> Subject: Re: [mpls] LDP Security >>>> >>>> >>>> >>>> Hi Stewart >>>> >>>> >>>> >>>> Thanks for your note. >>>> >>>> >>>> >>>> My overall sense of the state of play is, I think much like yours. >>>> >>>> >>>> >>>> TCP-MD5 is inadequate in two major respects: >>>> >>>> - It uses weak algorithms >>>> >>>> - It has a bad negotiation/setuop story (manual key management) >>>> >>>> >>>> >>>> TCP-AO is intended to be a drop-in replacement for TCP-MD5 and so >>>> remedies >>>> the algorithm >>>> >>>> Issue >>>> >>>> >>>> >>>> [Uma]: Yes, if we go with RFC 5926 mandatory list.. >>>> >>>> >>>> >>>> but not the key management issue [0]. We haven't made much progress on >>>> the >>>> key >>>> >>>> management story, and that seems to be a major impediment to deploying >>>> either of these >>>> >>>> technologies (which I am given to understand don't see a lot of use). >>>> >>>> >>>> >>>> [Uma]: True. >>>> >>>> But I would indicate some effort done few years back >>>> regarding key management for pair wise routing protocols (BGP, LDP, >>>> PCEP, >>>> MSDP ..). >>>> >>>> One such proposal is by extending IKEv2 to negotiate >>>> TCP-AO >>>> MKTs (which can give rekey & algo. agility) - >>>> https://tools.ietf.org/html/draft-mahesh-karp-rkmp-05 >>>> >>>> This also requires some more work with TCP-AO; me & Jo= e >>>> put >>>> together >>>> https://www.ietf.org/archive/id/draft-chunduri-karp-using-ik >>>> ev2-with-tcp-ao-06.txt >>>> >>>> Note the above didn=E2=80=99t progress in the concluded KA= RP WG (not >>>> fully sure the reasons on why). >>>> >>>> >>>> >>>> Yeah, I know that people tried to do this, but my impression was it >>>> kinda >>>> didn't progress much. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> We should probably talk in Singapore about that, but that's not going = to >>>> get better any time soon. >>>> >>>> >>>> >>>> In the interim, I think the text you have is OK, and "TBD" should read >>>> "SHA-256", with >>>> >>>> the fallback being SHA-256 -> SHA-1 -> MD5. >>>> >>>> >>>> >>>> [Uma]: While the list can be extended - I didn=E2=80=99t see SHA256 in= the >>>> mandatory list in RFC 5926 for MAC. >>>> >>>> >>>> >>>> Generally we're trying to move away from SHA-1 towards SHA-256. >>>> >>>> >>>> >>>> [Uma1]: Couple of things: >>>> >>>> 1. Nothing to be done (from spec pov of course): Use TCP-AO >>>> (instead >>>> of current MD5) with the RFC 5926 mandated MACs/KDFs =E2=80=93 so the = =E2=80=98TBD=E2=80=99 in >>>> Stewart suggesting below is already there. >>>> >>>> 2. As #1 too is not good enough from your above note - do SHA-25= 6 >>>> and live with it (no algorithm agility). Still a security benefit in >>>> one way >>>> from existing stuff or even #1. >>>> >>>> I'm not sure why you say "no algorithm agility". You'd be using AO, ju= st >>>> with a different algorithm than SHA-1. AES-CMAC is still fine as far a= s >>>> I >>>> know. >>>> >>>> [Uma2]: Sure, you have it, if you use AO; >>>> >>>> But then I am not getting how we can mandate one MU= ST >>>> implement algorithm as suggested below TBD would actually work >>>> (especially >>>> - *if* #1 is already deployed somewhere?) >>>> >>>> Perhaps staying with #1 is the best bet or do >>>> negotiation >>>> through #3, with already mandated and additional stuff. >>>> >>>> >>>> >>>> -Ekr >>>> >>>> >>>> >>>> 3. Do key management and =E2=80=9Ctheoretically=E2=80=9D get all= we wanted=E2=80=A6. >>>> >>>> >>>> >>>> We have been here multiple times; because #1 itself is not *mostly* >>>> deployed (neither in BGP nor in LDP) if there is any appetite for #2 >>>> and #3 >>>> for practical deployments. But still it may be good to do #2 any ways. >>>> >>>> >>>> >>>> >>>> >>>> -Ekr >>>> >>>> >>>> >>>> >>>> >>>> -Ekr >>>> >>>> >>>> >>>> >>>> >>>> [0] Technically It has better support for rollover, but this is not a >>>> huge >>>> improvement. >>>> >>>> [1] tcpcrypt is kind of orthogonal here as it's unauthenticated but >>>> opportunistic. That said, >>>> >>>> it would provide defense against attackers who gain access to the link >>>> after connection >>>> >>>> setup and doesn't require configuration. >>>> >>>> >>>> >>>> On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant < >>>> stewart.bryant@gmail.com> >>>> wrote: >>>> >>>> To the SEC and RTG ADs, >>>> >>>> I am sending the following message on behalf of the MPLS and the >>>> PALS WG Chairs. >>>> >>>> There is a concern shared among the security community and the working >>>> groups that develop the LDP protocol that LDP is no longer adequately >>>> secured. LDP currently relies on MD5 for cryptographic security of its >>>> messages, but MD5 is a hash function that is no longer considered to >>>> meet >>>> current security requirements. >>>> >>>> In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2. >>>> Session communication carried by TCP the following statements is made: >>>> >>>> "LDP specifies use of the TCP MD5 Signature Option to provide for the >>>> authenticity and integrity of session messages. >>>> >>>> "[RFC2385] asserts that MD5 authentication is now considered by some t= o >>>> be >>>> too weak for this application. It also points out that a similar TCP >>>> option >>>> with a stronger hashing algorithm (it cites SHA-1 as an example) could >>>> be >>>> deployed. To our knowledge, no such TCP option has been defined and >>>> deployed. However, we note that LDP can use whatever TCP message dige= st >>>> techniques are available, and when one stronger than MD5 is specified >>>> and >>>> implemented, upgrading LDP to use it would be relatively >>>> straightforward." >>>> >>>> We note that BGP has already been through this process, and replaced M= D5 >>>> with TCP-AO in RFC 7454. I would be logical to follow the same approac= h >>>> to >>>> secure LDP. However, as far as we are able to ascertain, there is >>>> currently >>>> no recommended, mandatory to implement, cryptographic function >>>> specified. We >>>> are concerned that without such a mandatory function, implementations >>>> will >>>> simply fall back to MD5 and we will be no further forward >>>> >>>> We think that the best way forward is to publish a draft similar to RF= C >>>> 7454 that contains the following requirement: >>>> >>>> "Implementations conforming to this RFC MUST implement TCP-AO to secur= e >>>> the TCP sessions carrying LDP in addition to the currently required TC= P >>>> MD5 >>>> Signature Option. Furthermore, the TBD cryptographic mechanism must be >>>> implemented and provided to TCP-AO to secure LDP messages. The TBD >>>> mechanism >>>> is the preferred option, and MD5 is only to be used when TBD is >>>> unavailable." >>>> >>>> We are not an experts on this part of the stack, but it seems that TCP >>>> security negotiation is still work in progress. If we are wrong, then = we >>>> need to include a requirement that such negotiation is also required. >>>> In the >>>> absence of a negotiation protocol, however, we need to leave this as a >>>> configuration process until such time as the negotiation protocol work >>>> is >>>> complete. On completion of a suitable negotiation protocol we need to >>>> issue >>>> a further update requiring its use. >>>> >>>> Additionally we should note that no cryptographic mechanism has an >>>> indefinite lifetime, and that implementation should note the IETF >>>> anticipates updating the default cryptographic mechanism over time. >>>> >>>> The TBD default security function will need to be chosen such that it >>>> can >>>> reasonably be implemented on a typical router route processor, and whi= ch >>>> will provide adequate security without significantly degrading the >>>> convergence time of an LSR. Without a function that does not >>>> significantly >>>> impact router convergence we simply close one vulnerability and open >>>> another. >>>> >>>> As experts on the LDP protocol, but not on security mechanisms, we ne= ed >>>> to ask the security area for a review of our proposed approach, and he= lp >>>> correcting any misunderstanding of the security issues or our >>>> misunderstanding of the existing security mechanisms. We also need the >>>> recommendations of a suitable security function (TBD in the above text= ). >>>> >>>> Best regards >>>> >>>> The MPLS WG Chairs >>>> The PALS WG Chairs >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> >> > --001a1142d0d4b121a5055d9bb133 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Nov 9, 2017 at 3:02 PM, Stewart Bryant <stewart.bryant@= gmail.com> wrote:
Another = data point is that for a long time operators only turned on MD5 for the
link state protocols to get a better checksum, not because they perceived a threat.

FWIW, I agree that MD5 is a f= ine checksum.

-Ekr
=C2=A0

There is security at different levels, for example MACsec, which has the ad= vantage
of securing the customer traffic from pervasive monitoring as well as secur= ing the
routing layer. Additionally it is common for customer traffic gets put stra= ight
into MPLS and so cannot be used as an attack vector.=

- Stewart



On 09/11/2017 20:09, Kathleen Moriarty wrote:
On Thu, Nov 9, 2017 at 2:09 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Yeah, I agree. I don't really have any good ideas how to get people to = do
AO. Based on comments I've heard, providers don't see a lot of valu= e,
rightly or wrongly....
I know Alia has been talking about a possible Linux implementation to
drive the way.=C2=A0 I agree with EKR on other points and have been
following along.

Best,
Kathleen
-Ekr


On Wed, Nov 8, 2017 at 9:15 PM, Susan Hares <shares@ndzh.com> wrote:
Eric:



BGP and LDP would be more secure if TCP-AO deployed with all BGP and LDP = =E2=80=93
but there are issues with customer pick-up and deployment of these protocol= s
on many networks.=C2=A0 I wished we had TCP-AO when BGP started, but we did= not.



Some of the least secure BGP is in data centers =E2=80=93 where the DC prov= iders
say =E2=80=9CIt=E2=80=99s all under one administration=E2=80=9D.=C2=A0 Anot= her problem is on private
lines.=C2=A0 =C2=A0 We should chat about the networks each of these protoco= ls are
actually deployed on.=C2=A0 =C2=A0If you have any insight on a way to encou= rage
adoption, I=E2=80=99d love to hear it. Require TCP-AO does not really mean = anything
if providers and Data Centers do not adopt it.



Going from SHA-1 to SHA-256 on a TCP-AO is simple upgrade compared to
getting people to TCP-AO.



Sue



From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Wednesday, November 8, 2017 7:44 PM
To: Uma Chunduri
Cc: mpls@ietf.org; <= a href=3D"mailto:pals-chairs@tools.ietf.org" target=3D"_blank">pals-chairs@= tools.ietf.org; <rtg-ads@ietf.org>;
mpls-chairs@ietf.= org; pals@ietf.org; <sec-ads@ietf.= org>


Subject: Re: [mpls] LDP Security



I don't understand what you're getting at here. Yes, if people have= TCP-AO
then presumably they have SHA-1.



But now we're talking about requiring people to have TCP-AO in this cas= e,
so we should try to move them to SHA-256 at the time we require AO.



-Ekr





On Wed, Nov 8, 2017 at 4:14 PM, Uma Chunduri <uma.chunduri@huawei.com>
wrote:

From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Wednesday, November 08, 2017 3:53 PM


To: Uma Chunduri <uma.chunduri@huawei.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>; mpls@ietf.org;
pals-chairs= @tools.ietf.org; <rtg-ads@ietf.org> <rtg-ads@ietf.org>;
mpls-chairs@ietf.= org; pals@ietf.org; <sec-ads@ietf.= org> <sec-a= ds@ietf.org>
Subject: Re: [mpls] LDP Security







On Wed, Nov 8, 2017 at 3:50 PM, Uma Chunduri <uma.chunduri@huawei.com>
wrote:

In-line [Uma1]:

--

Uma C.



From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Wednesday, November 08, 2017 12:53 PM
To: Uma Chunduri <uma.chunduri@huawei.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>; mpls@ietf.org;
pals-chairs= @tools.ietf.org; <rtg-ads@ietf.org> <rtg-ads@ietf.org>;
mpls-chairs@ietf.= org; pals@ietf.org; <sec-ads@ietf.= org> <sec-a= ds@ietf.org>


Subject: Re: [mpls] LDP Security







On Wed, Nov 8, 2017 at 11:57 AM, Uma Chunduri <uma.chunduri@huawei.com>
wrote:

Hi Stewart,



I would note https://tools.ietf.org/html/rfc6952 - where= LDP security is
analyzed from all aspects.



Eric,



Quick comments below [Uma]:



--

Uma C.



From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Wednesday, November 08, 2017 10:00 AM
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: mpls@ietf.org; <= a href=3D"mailto:pals-chairs@tools.ietf.org" target=3D"_blank">pals-chairs@= tools.ietf.org; <rtg-ads@ietf.org>
<rtg-ads@ietf.org<= /a>>; mpls-cha= irs@ietf.org; pals@i= etf.org; <sec-= ads@ietf.org>
<sec-ads@ietf.org<= /a>>
Subject: Re: [mpls] LDP Security



Hi Stewart



Thanks for your note.



My overall sense of the state of play is, I think much like yours.



TCP-MD5 is inadequate in two major respects:

- It uses weak algorithms

- It has a bad negotiation/setuop story (manual key management)



TCP-AO is intended to be a drop-in replacement for TCP-MD5 and so remedies<= br> the algorithm

Issue



[Uma]: Yes, if we go with RFC 5926 mandatory list..



but not the key management issue [0]. We haven't made much progress on = the
key

management story, and that seems to be a major impediment to deploying
either of these

technologies (which I am given to understand don't see a lot of use).


[Uma]: True.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 But I would indicat= e some effort done few years back
regarding key management for pair wise routing protocols (BGP, LDP, PCEP, MSDP ..).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 One such proposal i= s by extending IKEv2 to negotiate TCP-AO
MKTs (which can give rekey & algo. agility) -
https://tools.ietf.org/html/draft-mahesh-k= arp-rkmp-05

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This also requires = some more work with TCP-AO; me & Joe put
together
https://www.ietf.o= rg/archive/id/draft-chunduri-karp-using-ikev2-with-tcp-ao-06.txt<= /a>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Note the above didn=E2=80=99t pro= gress in the concluded KARP WG (not
fully sure the reasons on why).



Yeah, I know that people tried to do this, but my impression was it kinda didn't progress much.







We should probably talk in Singapore about that, but that's not going t= o
get better any time soon.



In the interim, I think the text you have is OK, and "TBD" should= read
"SHA-256", with

the fallback being SHA-256 -> SHA-1 -> MD5.



[Uma]: While the list can be extended - I didn=E2=80=99t see SHA256 in the<= br> mandatory list in RFC 5926 for MAC.



Generally we're trying to move away from SHA-1 towards SHA-256.



[Uma1]: Couple of things:

1.=C2=A0 =C2=A0 =C2=A0 =C2=A0Nothing to be done (from spec pov of course): = Use TCP-AO (instead
of current MD5) with the RFC 5926 mandated MACs/KDFs =E2=80=93 so the =E2= =80=98TBD=E2=80=99 in
Stewart suggesting below is already there.

2.=C2=A0 =C2=A0 =C2=A0 =C2=A0As #1 too is not good enough from your above n= ote - do SHA-256
and live with it (no algorithm agility). Still a security benefit in one wa= y
from existing stuff or even=C2=A0 #1.

I'm not sure why you say "no algorithm agility". You'd be= using AO, just
with a different algorithm than SHA-1. AES-CMAC is still fine as far as I know.

[Uma2]: Sure, you have it, if you use AO;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 But then=C2= =A0 I am not getting how we can mandate one MUST
implement algorithm as suggested below TBD=C2=A0 would actually work=C2=A0 = (especially
- *if* #1 is already deployed somewhere?)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Perhaps stay= ing with #1 is the best bet or do negotiation
through #3, with already mandated and additional stuff.



-Ekr



3.=C2=A0 =C2=A0 =C2=A0 =C2=A0Do key management and =E2=80=9Ctheoretically= =E2=80=9D get all we wanted=E2=80=A6.



We have been here multiple times; because #1 itself is not *mostly*
deployed (neither in BGP nor in LDP) if there is any appetite for #2 and #3=
for practical deployments. But still it may be good to do #2 any ways.





-Ekr





-Ekr





[0] Technically It has better support for rollover, but this is not a huge<= br> improvement.

[1] tcpcrypt is kind of orthogonal here as it's unauthenticated but
opportunistic.=C2=A0 That said,

it would provide defense against attackers who gain access to the link
after connection

setup and doesn't require configuration.



On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant <stewart.bryant@gmail.com>
wrote:

To the SEC and RTG ADs,

I am sending the following message on behalf of the MPLS and the
PALS WG Chairs.

There is a concern shared among the security community and the working
groups that develop the LDP protocol that LDP is no longer adequately
secured. LDP currently relies on MD5 for cryptographic security of its
messages, but MD5 is a hash function that is no longer considered to meet current security requirements.

In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2.
Session communication carried by TCP the following statements is made:

"LDP specifies use of the TCP MD5 Signature Option to provide for the<= br> authenticity and integrity of session messages.

"[RFC2385] asserts that MD5 authentication is now considered by some t= o be
too weak for this application.=C2=A0 It also points out that a similar TCP = option
with a stronger hashing algorithm (it cites SHA-1 as an example) could be deployed.=C2=A0 To our knowledge, no such TCP option has been defined and deployed.=C2=A0 However, we note that LDP can use whatever TCP message dige= st
techniques are available, and when one stronger than MD5 is specified and implemented, upgrading LDP to use it would be relatively straightforward.&q= uot;

We note that BGP has already been through this process, and replaced MD5 with TCP-AO in RFC 7454. I would be logical to follow the same approach to<= br> secure LDP. However, as far as we are able to ascertain, there is currently=
no recommended, mandatory to implement, cryptographic function specified. W= e
are concerned that without such a mandatory function, implementations will<= br> simply fall back to MD5 and we will be no further forward

We think that the best way forward is to publish a draft similar to RFC
7454 that contains the following requirement:

"Implementations conforming to this RFC MUST implement TCP-AO to secur= e
the TCP sessions carrying LDP in addition to the currently required TCP MD5=
Signature Option. Furthermore, the TBD cryptographic mechanism must be
implemented and provided to TCP-AO to secure LDP messages. The TBD mechanis= m
is the preferred option, and MD5 is only to be used when TBD is
unavailable."

We are not an experts on this part of the stack, but it seems that TCP
security negotiation is still work in progress. If we are wrong, then we need to include a requirement that such negotiation is also required. In th= e
absence of a negotiation protocol, however, we need to leave this as a
configuration process until such time as the negotiation protocol work is complete. On completion of a suitable negotiation protocol we need to issue=
a further update requiring its use.

Additionally we should note that no cryptographic mechanism has an
indefinite lifetime, and that implementation should note the IETF
anticipates updating the default cryptographic mechanism over time.

The TBD default security function will need to be chosen such that it can reasonably be implemented on a typical router route processor, and which will provide adequate security without significantly degrading the
convergence time of an LSR. Without a function that does not significantly<= br> impact router convergence we simply close one vulnerability and open
another.

As experts on the LDP protocol, but not on security mechanisms, we=C2=A0 ne= ed
to ask the security area for a review of our proposed approach, and help correcting any misunderstanding of the security issues or our
misunderstanding of the existing security mechanisms. We also need the
recommendations of a suitable security function (TBD in the above text).
Best regards

The MPLS WG Chairs
The PALS WG Chairs













--001a1142d0d4b121a5055d9bb133-- From nobody Fri Nov 10 08:22:07 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5820F126DC2; Fri, 10 Nov 2017 08:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 hKvHVpeVimss; Fri, 10 Nov 2017 08:21:56 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0115.outbound.protection.outlook.com [104.47.1.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1AE8126BF6; Fri, 10 Nov 2017 08:21:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=L2pQwvL60GcFyj55A+aqGBkhBHlz5fgc6ICjPQ9fO5o=; b=izW+KfPlTudb7DeCIF79n4+7QQoFZaBT33yy9NlIuiBmfVHpkIyNJTE/HZaCzCPUUlzIynscACg88Nep/rKRurzlUQZd19NfRCa1rGKJgcEQgROkHSL+lOl3KSyIvRxzBSsnz8pibIgkG4fqGsjbrHbaykGQeyM8YljMn6JRflc= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2546.eurprd07.prod.outlook.com (10.173.92.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Fri, 10 Nov 2017 16:21:53 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::14d8:6acd:f568:98f]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::14d8:6acd:f568:98f%17]) with mapi id 15.20.0218.005; Fri, 10 Nov 2017 16:21:53 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: Eric Rescorla , Stewart Bryant , "tcpm@ietf.org" CC: "mpls@ietf.org" , "pals-chairs@tools.ietf.org" , "" , "mpls-chairs@ietf.org" , "pals@ietf.org" , "" Thread-Topic: [mpls] LDP Security Thread-Index: AQHTWLboye/68uxiMkCt9OCmRHsgC6MKxUkAgAMG5/A= Date: Fri, 10 Nov 2017 16:21:52 +0000 Message-ID: References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <5994f353-5306-0fa8-2d2d-024ebdbb10df@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com; x-originating-ip: [103.5.19.85] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2546; 6:i+w4zy713X67zZdcuWu+PLJCbkUtejoaaN1YoPoYnzJjUlwfg0SY66aLYJgkLGUPHj+n4k3V+5iJ7UW6KP/KnuUrUhPv+2Ir1xhtF6+0td+uRD9MCCe7D0rb8U2wAdQ+UuMn7OGLw5bJG5mKD3ArOiKgkph3cFv4orvgbrBpHq3YMJTCYM9pq4SQfEqZtyM9AK+l5Da0nc9CpDMtnz+W2Fidmg09iQ+wXz/awGgYex+YCgB/2z+/pPyOaHiCzTNo61MWyVyFfWplXSAV3C1FuPht2ABGSh7Gd2zfZZugXvj+UV1aBUmPRKTi5P14LsaEnXIoFVsCNU2IdLJ/z7s9BAUtO9zTCfblBoEa3etQuCs=; 5:MzOgw4uVXZd/HaDnsQ2Pz75w6TL+d3f+zhUgyf6LTDlY8737U0jKGCl1Pw0QXCUZ+Pmp62wIY6ExqZIaGBj6sw6tJNKXA4EXzFFtjMq+ssMwgo+0HaTBVd5Ml5w3NiSZIANtrUDsWM4c+oISl8IMqt78ehpL0CC7CWszM8H7W70=; 24:mYxnvYbDtfvGWLCwEiF4pKp5J3HzWc62JsYZk6iMNlhBGpOBR3/Hjwo8WaqyTkGwo3/Ot81OVJGe+D+50MUY5agcCrjv1Kpe+D66olp1soI=; 7:rE7Ljr31pvROSaHL0EWCXOCCE9lWW0yn4qdAG4vI4vouBf+ju7Vzeupp7Lj2BMwYS6ox9dWzILjIvM4m9O4xej+UCt5+M3hwOo3w3bfU8tFj/wZ/AfuSj3JAkEhuCd/rmqXsNIW94Rgk3ECf67K5M/Q5NAd5WN6WcbV6UXTyA3uJg+3n3anj2Y28hucUudHLELKrmwSlWuN99MC1MAAtQWvU8Q9nTeiTW7s1XYslZJ5C4D1avROVlucy86HxiR+D x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 20920c15-d52a-4ae0-2563-08d528572764 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM5PR0701MB2546; x-ms-traffictypediagnostic: AM5PR0701MB2546: x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3231021)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2546; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2546; x-forefront-prvs: 0487C0DB7E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(24454002)(189002)(199003)(93886005)(5250100002)(10710500007)(14454004)(2900100001)(3660700001)(25786009)(3280700002)(4326008)(8936002)(110136005)(2420400007)(15650500001)(54906003)(790700001)(229853002)(3846002)(54356999)(6116002)(76176999)(2906002)(101416001)(6506006)(6436002)(2950100002)(33656002)(50986999)(478600001)(106356001)(97736004)(105586002)(102836003)(2501003)(68736007)(7736002)(53936002)(236005)(6246003)(7696004)(316002)(86362001)(55016002)(74316002)(5660300001)(54896002)(9686003)(6306002)(66066001)(53546010)(8676002)(81166006)(81156014)(99286004)(39060400002)(189998001)(7110500001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2546; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB25472EFBB94C1C98EA2606B393540AM5PR0701MB2547_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 20920c15-d52a-4ae0-2563-08d528572764 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2017 16:21:52.9839 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2546 Archived-At: Subject: Re: [Pals] [mpls] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 16:21:59 -0000 --_000_AM5PR0701MB25472EFBB94C1C98EA2606B393540AM5PR0701MB2547_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 K1RDUE0NCg0KDQoNClBsZWFzZSBmcmVlIHRvIGRpc2N1c3MgY2hhbmdlcyB0byBUQ1AtQU8gb24g dGhlIFRDUE0gbGlzdCwgb3Igc3BlYWsgdXAgYXQgdGhlIHVwY29taW5nIFRDUE0gbWVldGluZy4N Cg0KDQoNClRoZSBhZGRpdGlvbiBvZiBTSEEtMjU2IGhhcyBiZWVuIGRpc2N1c3NlZCBpbiBUQ1BN IGFscmVhZHkgKHNlZSBkcmFmdC1uYXlhay10Y3Atc2hhMi0wMiksIGJ1dCBzbyBmYXIgdGhlcmUg d2FzIG5vdCBtdWNoIGVuZXJneSBhbmQgbm8gaW50ZXJlc3QgZnJvbSBwb3RlbnRpYWwgVENQLUFP IGltcGxlbWVudGVycyBvciB1c2Vycy4NCg0KDQoNCk1pY2hhZWwNCg0KKFRDUE0gY28tY2hhaXIp DQoNCg0KDQpGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAwOCwgMjAxNyA3 OjAwIFBNDQpUbzogU3Rld2FydCBCcnlhbnQgPHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbT4NCkNj OiBtcGxzQGlldGYub3JnOyBwYWxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgPHJ0Zy1hZHNAaWV0 Zi5vcmc+IDxydGctYWRzQGlldGYub3JnPjsgbXBscy1jaGFpcnNAaWV0Zi5vcmc7IHBhbHNAaWV0 Zi5vcmc7IDxzZWMtYWRzQGlldGYub3JnPiA8c2VjLWFkc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbbXBsc10gTERQIFNlY3VyaXR5DQoNCkhpIFN0ZXdhcnQNCg0KVGhhbmtzIGZvciB5b3VyIG5v dGUuDQoNCk15IG92ZXJhbGwgc2Vuc2Ugb2YgdGhlIHN0YXRlIG9mIHBsYXkgaXMsIEkgdGhpbmsg bXVjaCBsaWtlIHlvdXJzLg0KDQpUQ1AtTUQ1IGlzIGluYWRlcXVhdGUgaW4gdHdvIG1ham9yIHJl c3BlY3RzOg0KLSBJdCB1c2VzIHdlYWsgYWxnb3JpdGhtcw0KLSBJdCBoYXMgYSBiYWQgbmVnb3Rp YXRpb24vc2V0dW9wIHN0b3J5IChtYW51YWwga2V5IG1hbmFnZW1lbnQpDQoNClRDUC1BTyBpcyBp bnRlbmRlZCB0byBiZSBhIGRyb3AtaW4gcmVwbGFjZW1lbnQgZm9yIFRDUC1NRDUgYW5kIHNvIHJl bWVkaWVzIHRoZSBhbGdvcml0aG0NCmlzc3VlIGJ1dCBub3QgdGhlIGtleSBtYW5hZ2VtZW50IGlz c3VlIFswXS4gV2UgaGF2ZW4ndCBtYWRlIG11Y2ggcHJvZ3Jlc3Mgb24gdGhlIGtleQ0KbWFuYWdl bWVudCBzdG9yeSwgYW5kIHRoYXQgc2VlbXMgdG8gYmUgYSBtYWpvciBpbXBlZGltZW50IHRvIGRl cGxveWluZyBlaXRoZXIgb2YgdGhlc2UNCnRlY2hub2xvZ2llcyAod2hpY2ggSSBhbSBnaXZlbiB0 byB1bmRlcnN0YW5kIGRvbid0IHNlZSBhIGxvdCBvZiB1c2UpLiBXZSBzaG91bGQgcHJvYmFibHkN CnRhbGsgaW4gU2luZ2Fwb3JlIGFib3V0IHRoYXQsIGJ1dCB0aGF0J3Mgbm90IGdvaW5nIHRvIGdl dCBiZXR0ZXIgYW55IHRpbWUgc29vbi4NCg0KSW4gdGhlIGludGVyaW0sIEkgdGhpbmsgdGhlIHRl eHQgeW91IGhhdmUgaXMgT0ssIGFuZCAiVEJEIiBzaG91bGQgcmVhZCAiU0hBLTI1NiIsIHdpdGgN CnRoZSBmYWxsYmFjayBiZWluZyBTSEEtMjU2IC0+IFNIQS0xIC0+IE1ENS4NCg0KLUVrcg0KDQoN ClswXSBUZWNobmljYWxseSBJdCBoYXMgYmV0dGVyIHN1cHBvcnQgZm9yIHJvbGxvdmVyLCBidXQg dGhpcyBpcyBub3QgYSBodWdlIGltcHJvdmVtZW50Lg0KWzFdIHRjcGNyeXB0IGlzIGtpbmQgb2Yg b3J0aG9nb25hbCBoZXJlIGFzIGl0J3MgdW5hdXRoZW50aWNhdGVkIGJ1dCBvcHBvcnR1bmlzdGlj LiAgVGhhdCBzYWlkLA0KaXQgd291bGQgcHJvdmlkZSBkZWZlbnNlIGFnYWluc3QgYXR0YWNrZXJz IHdobyBnYWluIGFjY2VzcyB0byB0aGUgbGluayBhZnRlciBjb25uZWN0aW9uDQpzZXR1cCBhbmQg ZG9lc24ndCByZXF1aXJlIGNvbmZpZ3VyYXRpb24uDQoNCk9uIFdlZCwgTm92IDgsIDIwMTcgYXQg OToyNyBBTSwgU3Rld2FydCBCcnlhbnQgPHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbTxtYWlsdG86 c3Rld2FydC5icnlhbnRAZ21haWwuY29tPj4gd3JvdGU6DQpUbyB0aGUgU0VDIGFuZCBSVEcgQURz LA0KDQpJIGFtIHNlbmRpbmcgdGhlIGZvbGxvd2luZyBtZXNzYWdlIG9uIGJlaGFsZiBvZiB0aGUg TVBMUyBhbmQgdGhlDQpQQUxTIFdHIENoYWlycy4NCg0KVGhlcmUgaXMgYSBjb25jZXJuIHNoYXJl ZCBhbW9uZyB0aGUgc2VjdXJpdHkgY29tbXVuaXR5IGFuZCB0aGUgd29ya2luZyBncm91cHMgdGhh dCBkZXZlbG9wIHRoZSBMRFAgcHJvdG9jb2wgdGhhdCBMRFAgaXMgbm8gbG9uZ2VyIGFkZXF1YXRl bHkgc2VjdXJlZC4gTERQIGN1cnJlbnRseSByZWxpZXMgb24gTUQ1IGZvciBjcnlwdG9ncmFwaGlj IHNlY3VyaXR5IG9mIGl0cyBtZXNzYWdlcywgYnV0IE1ENSBpcyBhIGhhc2ggZnVuY3Rpb24gdGhh dCBpcyBubyBsb25nZXIgY29uc2lkZXJlZCB0byBtZWV0IGN1cnJlbnQgc2VjdXJpdHkgcmVxdWly ZW1lbnRzLg0KDQpJbiBSRkM1MDM2IChwdWJsaXNoZWQgMjAwNykgU2VjdGlvbiA1LjEgKFNwb29m aW5nKSAsIExpc3QgZWxlbWVudCAyLiBTZXNzaW9uIGNvbW11bmljYXRpb24gY2FycmllZCBieSBU Q1AgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnRzIGlzIG1hZGU6DQoNCiJMRFAgc3BlY2lmaWVzIHVz ZSBvZiB0aGUgVENQIE1ENSBTaWduYXR1cmUgT3B0aW9uIHRvIHByb3ZpZGUgZm9yIHRoZSBhdXRo ZW50aWNpdHkgYW5kIGludGVncml0eSBvZiBzZXNzaW9uIG1lc3NhZ2VzLg0KDQoiW1JGQzIzODVd IGFzc2VydHMgdGhhdCBNRDUgYXV0aGVudGljYXRpb24gaXMgbm93IGNvbnNpZGVyZWQgYnkgc29t ZSB0byBiZSB0b28gd2VhayBmb3IgdGhpcyBhcHBsaWNhdGlvbi4gIEl0IGFsc28gcG9pbnRzIG91 dCB0aGF0IGEgc2ltaWxhciBUQ1Agb3B0aW9uIHdpdGggYSBzdHJvbmdlciBoYXNoaW5nIGFsZ29y aXRobSAoaXQgY2l0ZXMgU0hBLTEgYXMgYW4gZXhhbXBsZSkgY291bGQgYmUgZGVwbG95ZWQuICBU byBvdXIga25vd2xlZGdlLCBubyBzdWNoIFRDUCBvcHRpb24gaGFzIGJlZW4gZGVmaW5lZCBhbmQg ZGVwbG95ZWQuICBIb3dldmVyLCB3ZSBub3RlIHRoYXQgTERQIGNhbiB1c2Ugd2hhdGV2ZXIgVENQ IG1lc3NhZ2UgZGlnZXN0IHRlY2huaXF1ZXMgYXJlIGF2YWlsYWJsZSwgYW5kIHdoZW4gb25lIHN0 cm9uZ2VyIHRoYW4gTUQ1IGlzIHNwZWNpZmllZCBhbmQgaW1wbGVtZW50ZWQsIHVwZ3JhZGluZyBM RFAgdG8gdXNlIGl0IHdvdWxkIGJlIHJlbGF0aXZlbHkgc3RyYWlnaHRmb3J3YXJkLiINCg0KV2Ug bm90ZSB0aGF0IEJHUCBoYXMgYWxyZWFkeSBiZWVuIHRocm91Z2ggdGhpcyBwcm9jZXNzLCBhbmQg cmVwbGFjZWQgTUQ1IHdpdGggVENQLUFPIGluIFJGQyA3NDU0LiBJIHdvdWxkIGJlIGxvZ2ljYWwg dG8gZm9sbG93IHRoZSBzYW1lIGFwcHJvYWNoIHRvIHNlY3VyZSBMRFAuIEhvd2V2ZXIsIGFzIGZh ciBhcyB3ZSBhcmUgYWJsZSB0byBhc2NlcnRhaW4sIHRoZXJlIGlzIGN1cnJlbnRseSBubyByZWNv bW1lbmRlZCwgbWFuZGF0b3J5IHRvIGltcGxlbWVudCwgY3J5cHRvZ3JhcGhpYyBmdW5jdGlvbiBz cGVjaWZpZWQuIFdlIGFyZSBjb25jZXJuZWQgdGhhdCB3aXRob3V0IHN1Y2ggYSBtYW5kYXRvcnkg ZnVuY3Rpb24sIGltcGxlbWVudGF0aW9ucyB3aWxsIHNpbXBseSBmYWxsIGJhY2sgdG8gTUQ1IGFu ZCB3ZSB3aWxsIGJlIG5vIGZ1cnRoZXIgZm9yd2FyZA0KDQpXZSB0aGluayB0aGF0IHRoZSBiZXN0 IHdheSBmb3J3YXJkIGlzIHRvIHB1Ymxpc2ggYSBkcmFmdCBzaW1pbGFyIHRvIFJGQyA3NDU0IHRo YXQgY29udGFpbnMgdGhlIGZvbGxvd2luZyByZXF1aXJlbWVudDoNCg0KIkltcGxlbWVudGF0aW9u cyBjb25mb3JtaW5nIHRvIHRoaXMgUkZDIE1VU1QgaW1wbGVtZW50IFRDUC1BTyB0byBzZWN1cmUg dGhlIFRDUCBzZXNzaW9ucyBjYXJyeWluZyBMRFAgaW4gYWRkaXRpb24gdG8gdGhlIGN1cnJlbnRs eSByZXF1aXJlZCBUQ1AgTUQ1IFNpZ25hdHVyZSBPcHRpb24uIEZ1cnRoZXJtb3JlLCB0aGUgVEJE IGNyeXB0b2dyYXBoaWMgbWVjaGFuaXNtIG11c3QgYmUgaW1wbGVtZW50ZWQgYW5kIHByb3ZpZGVk IHRvIFRDUC1BTyB0byBzZWN1cmUgTERQIG1lc3NhZ2VzLiBUaGUgVEJEIG1lY2hhbmlzbSBpcyB0 aGUgcHJlZmVycmVkIG9wdGlvbiwgYW5kIE1ENSBpcyBvbmx5IHRvIGJlIHVzZWQgd2hlbiBUQkQg aXMgdW5hdmFpbGFibGUuIg0KDQpXZSBhcmUgbm90IGFuIGV4cGVydHMgb24gdGhpcyBwYXJ0IG9m IHRoZSBzdGFjaywgYnV0IGl0IHNlZW1zIHRoYXQgVENQIHNlY3VyaXR5IG5lZ290aWF0aW9uIGlz IHN0aWxsIHdvcmsgaW4gcHJvZ3Jlc3MuIElmIHdlIGFyZSB3cm9uZywgdGhlbiB3ZSBuZWVkIHRv IGluY2x1ZGUgYSByZXF1aXJlbWVudCB0aGF0IHN1Y2ggbmVnb3RpYXRpb24gaXMgYWxzbyByZXF1 aXJlZC4gSW4gdGhlIGFic2VuY2Ugb2YgYSBuZWdvdGlhdGlvbiBwcm90b2NvbCwgaG93ZXZlciwg d2UgbmVlZCB0byBsZWF2ZSB0aGlzIGFzIGEgY29uZmlndXJhdGlvbiBwcm9jZXNzIHVudGlsIHN1 Y2ggdGltZSBhcyB0aGUgbmVnb3RpYXRpb24gcHJvdG9jb2wgd29yayBpcyBjb21wbGV0ZS4gT24g Y29tcGxldGlvbiBvZiBhIHN1aXRhYmxlIG5lZ290aWF0aW9uIHByb3RvY29sIHdlIG5lZWQgdG8g aXNzdWUgYSBmdXJ0aGVyIHVwZGF0ZSByZXF1aXJpbmcgaXRzIHVzZS4NCg0KQWRkaXRpb25hbGx5 IHdlIHNob3VsZCBub3RlIHRoYXQgbm8gY3J5cHRvZ3JhcGhpYyBtZWNoYW5pc20gaGFzIGFuIGlu ZGVmaW5pdGUgbGlmZXRpbWUsIGFuZCB0aGF0IGltcGxlbWVudGF0aW9uIHNob3VsZCBub3RlIHRo ZSBJRVRGIGFudGljaXBhdGVzIHVwZGF0aW5nIHRoZSBkZWZhdWx0IGNyeXB0b2dyYXBoaWMgbWVj aGFuaXNtIG92ZXIgdGltZS4NCg0KVGhlIFRCRCBkZWZhdWx0IHNlY3VyaXR5IGZ1bmN0aW9uIHdp bGwgbmVlZCB0byBiZSBjaG9zZW4gc3VjaCB0aGF0IGl0IGNhbiByZWFzb25hYmx5IGJlIGltcGxl bWVudGVkIG9uIGEgdHlwaWNhbCByb3V0ZXIgcm91dGUgcHJvY2Vzc29yLCBhbmQgd2hpY2ggd2ls bCBwcm92aWRlIGFkZXF1YXRlIHNlY3VyaXR5IHdpdGhvdXQgc2lnbmlmaWNhbnRseSBkZWdyYWRp bmcgdGhlIGNvbnZlcmdlbmNlIHRpbWUgb2YgYW4gTFNSLiBXaXRob3V0IGEgZnVuY3Rpb24gdGhh dCBkb2VzIG5vdCBzaWduaWZpY2FudGx5IGltcGFjdCByb3V0ZXIgY29udmVyZ2VuY2Ugd2Ugc2lt cGx5IGNsb3NlIG9uZSB2dWxuZXJhYmlsaXR5IGFuZCBvcGVuIGFub3RoZXIuDQoNCkFzIGV4cGVy dHMgb24gdGhlIExEUCBwcm90b2NvbCwgYnV0IG5vdCBvbiBzZWN1cml0eSBtZWNoYW5pc21zLCB3 ZSAgbmVlZCB0byBhc2sgdGhlIHNlY3VyaXR5IGFyZWEgZm9yIGEgcmV2aWV3IG9mIG91ciBwcm9w b3NlZCBhcHByb2FjaCwgYW5kIGhlbHAgY29ycmVjdGluZyBhbnkgbWlzdW5kZXJzdGFuZGluZyBv ZiB0aGUgc2VjdXJpdHkgaXNzdWVzIG9yIG91ciBtaXN1bmRlcnN0YW5kaW5nIG9mIHRoZSBleGlz dGluZyBzZWN1cml0eSBtZWNoYW5pc21zLiBXZSBhbHNvIG5lZWQgdGhlIHJlY29tbWVuZGF0aW9u cyBvZiBhIHN1aXRhYmxlIHNlY3VyaXR5IGZ1bmN0aW9uIChUQkQgaW4gdGhlIGFib3ZlIHRleHQp Lg0KDQpCZXN0IHJlZ2FyZHMNCg0KVGhlIE1QTFMgV0cgQ2hhaXJzDQpUaGUgUEFMUyBXRyBDaGFp cnMNCg0KDQo= --_000_AM5PR0701MB25472EFBB94C1C98EA2606B393540AM5PR0701MB2547_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNv UGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFp biBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mIzQzO1RDUE0gPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPlBsZWFzZSBmcmVlIHRvIGRpc2N1c3MgY2hhbmdlcyB0byBUQ1AtQU8gb24gdGhl IFRDUE0gbGlzdCwgb3Igc3BlYWsgdXAgYXQgdGhlIHVwY29taW5nIFRDUE0gbWVldGluZy48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIGFkZGl0aW9uIG9mIFNIQS0yNTYgaGFzIGJl ZW4gZGlzY3Vzc2VkIGluIFRDUE0gYWxyZWFkeSAoc2VlIGRyYWZ0LW5heWFrLXRjcC1zaGEyLTAy KSwgYnV0IHNvIGZhciB0aGVyZSB3YXMgbm90IG11Y2ggZW5lcmd5IGFuZCBubyBpbnRlcmVzdCBm cm9tIHBvdGVudGlhbCBUQ1AtQU8gaW1wbGVtZW50ZXJzIG9yIHVzZXJzLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5NaWNoYWVsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4oVENQTSBjby1jaGFpcik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBtcGxz IFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5Fcmlj IFJlc2NvcmxhPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTm92ZW1iZXIgMDgsIDIwMTcg NzowMCBQTTxicj4NCjxiPlRvOjwvYj4gU3Rld2FydCBCcnlhbnQgJmx0O3N0ZXdhcnQuYnJ5YW50 QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IG1wbHNAaWV0Zi5vcmc7IHBhbHMtY2hhaXJz QHRvb2xzLmlldGYub3JnOyAmbHQ7cnRnLWFkc0BpZXRmLm9yZyZndDsgJmx0O3J0Zy1hZHNAaWV0 Zi5vcmcmZ3Q7OyBtcGxzLWNoYWlyc0BpZXRmLm9yZzsgcGFsc0BpZXRmLm9yZzsgJmx0O3NlYy1h ZHNAaWV0Zi5vcmcmZ3Q7ICZsdDtzZWMtYWRzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW21wbHNdIExEUCBTZWN1cml0eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhpIFN0ZXdhcnQ8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgeW91ciBub3RlLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBvdmVyYWxsIHNlbnNlIG9m IHRoZSBzdGF0ZSBvZiBwbGF5IGlzLCBJIHRoaW5rIG11Y2ggbGlrZSB5b3Vycy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VENQLU1ENSBpcyBp bmFkZXF1YXRlIGluIHR3byBtYWpvciByZXNwZWN0czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gSXQgdXNlcyB3ZWFrIGFsZ29yaXRobXM8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gSXQgaGFz IGEgYmFkIG5lZ290aWF0aW9uL3NldHVvcCBzdG9yeSAobWFudWFsIGtleSBtYW5hZ2VtZW50KTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UQ1At QU8gaXMgaW50ZW5kZWQgdG8gYmUgYSBkcm9wLWluIHJlcGxhY2VtZW50IGZvciBUQ1AtTUQ1IGFu ZCBzbyByZW1lZGllcyB0aGUgYWxnb3JpdGhtPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pc3N1ZSBidXQgbm90IHRoZSBrZXkgbWFuYWdlbWVudCBp c3N1ZSBbMF0uIFdlIGhhdmVuJ3QgbWFkZSBtdWNoIHByb2dyZXNzIG9uIHRoZSBrZXk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm1hbmFnZW1lbnQg c3RvcnksIGFuZCB0aGF0IHNlZW1zIHRvIGJlIGEgbWFqb3IgaW1wZWRpbWVudCB0byBkZXBsb3lp bmcgZWl0aGVyIG9mIHRoZXNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj50ZWNobm9sb2dpZXMgKHdoaWNoIEkgYW0gZ2l2ZW4gdG8gdW5kZXJzdGFu ZCBkb24ndCBzZWUgYSBsb3Qgb2YgdXNlKS4gV2Ugc2hvdWxkIHByb2JhYmx5PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50YWxrIGluIFNpbmdhcG9y ZSBhYm91dCB0aGF0LCBidXQgdGhhdCdzIG5vdCBnb2luZyB0byBnZXQgYmV0dGVyIGFueSB0aW1l IHNvb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkluIHRoZSBpbnRlcmltLCBJIHRoaW5rIHRoZSB0ZXh0IHlvdSBoYXZlIGlzIE9LLCBhbmQg JnF1b3Q7VEJEJnF1b3Q7IHNob3VsZCByZWFkICZxdW90O1NIQS0yNTYmcXVvdDssIHdpdGg8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBmYWxs YmFjayBiZWluZyBTSEEtMjU2IC0mZ3Q7IFNIQS0xIC0mZ3Q7IE1ENS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlswXSBUZWNobmljYWxs eSBJdCBoYXMgYmV0dGVyIHN1cHBvcnQgZm9yIHJvbGxvdmVyLCBidXQgdGhpcyBpcyBub3QgYSBo dWdlIGltcHJvdmVtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+WzFdIHRjcGNyeXB0IGlzIGtpbmQgb2Ygb3J0aG9nb25hbCBoZXJlIGFzIGl0 J3MgdW5hdXRoZW50aWNhdGVkIGJ1dCBvcHBvcnR1bmlzdGljLiZuYnNwOyBUaGF0IHNhaWQsPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pdCB3b3Vs ZCBwcm92aWRlIGRlZmVuc2UgYWdhaW5zdCBhdHRhY2tlcnMgd2hvIGdhaW4gYWNjZXNzIHRvIHRo ZSBsaW5rIGFmdGVyIGNvbm5lY3Rpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPnNldHVwIGFuZCBkb2Vzbid0IHJlcXVpcmUgY29uZmlndXJhdGlv bi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gV2VkLCBOb3YgOCwgMjAxNyBhdCA5OjI3IEFNLCBTdGV3YXJ0IEJyeWFudCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZXdh cnQuYnJ5YW50QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ VG8gdGhlIFNFQyBhbmQgUlRHIEFEcyw8YnI+DQo8YnI+DQpJIGFtIHNlbmRpbmcgdGhlIGZvbGxv d2luZyBtZXNzYWdlIG9uIGJlaGFsZiBvZiB0aGUgTVBMUyBhbmQgdGhlPGJyPg0KUEFMUyBXRyBD aGFpcnMuPGJyPg0KPGJyPg0KVGhlcmUgaXMgYSBjb25jZXJuIHNoYXJlZCBhbW9uZyB0aGUgc2Vj dXJpdHkgY29tbXVuaXR5IGFuZCB0aGUgd29ya2luZyBncm91cHMgdGhhdCBkZXZlbG9wIHRoZSBM RFAgcHJvdG9jb2wgdGhhdCBMRFAgaXMgbm8gbG9uZ2VyIGFkZXF1YXRlbHkgc2VjdXJlZC4gTERQ IGN1cnJlbnRseSByZWxpZXMgb24gTUQ1IGZvciBjcnlwdG9ncmFwaGljIHNlY3VyaXR5IG9mIGl0 cyBtZXNzYWdlcywgYnV0IE1ENSBpcyBhIGhhc2ggZnVuY3Rpb24gdGhhdCBpcw0KIG5vIGxvbmdl ciBjb25zaWRlcmVkIHRvIG1lZXQgY3VycmVudCBzZWN1cml0eSByZXF1aXJlbWVudHMuPGJyPg0K PGJyPg0KSW4gUkZDNTAzNiAocHVibGlzaGVkIDIwMDcpIFNlY3Rpb24gNS4xIChTcG9vZmluZykg LCBMaXN0IGVsZW1lbnQgMi4gU2Vzc2lvbiBjb21tdW5pY2F0aW9uIGNhcnJpZWQgYnkgVENQIHRo ZSBmb2xsb3dpbmcgc3RhdGVtZW50cyBpcyBtYWRlOjxicj4NCjxicj4NCiZxdW90O0xEUCBzcGVj aWZpZXMgdXNlIG9mIHRoZSBUQ1AgTUQ1IFNpZ25hdHVyZSBPcHRpb24gdG8gcHJvdmlkZSBmb3Ig dGhlIGF1dGhlbnRpY2l0eSBhbmQgaW50ZWdyaXR5IG9mIHNlc3Npb24gbWVzc2FnZXMuPGJyPg0K PGJyPg0KJnF1b3Q7W1JGQzIzODVdIGFzc2VydHMgdGhhdCBNRDUgYXV0aGVudGljYXRpb24gaXMg bm93IGNvbnNpZGVyZWQgYnkgc29tZSB0byBiZSB0b28gd2VhayBmb3IgdGhpcyBhcHBsaWNhdGlv bi4mbmJzcDsgSXQgYWxzbyBwb2ludHMgb3V0IHRoYXQgYSBzaW1pbGFyIFRDUCBvcHRpb24gd2l0 aCBhIHN0cm9uZ2VyIGhhc2hpbmcgYWxnb3JpdGhtIChpdCBjaXRlcyBTSEEtMSBhcyBhbiBleGFt cGxlKSBjb3VsZCBiZSBkZXBsb3llZC4mbmJzcDsgVG8gb3VyIGtub3dsZWRnZSwgbm8NCiBzdWNo IFRDUCBvcHRpb24gaGFzIGJlZW4gZGVmaW5lZCBhbmQgZGVwbG95ZWQuJm5ic3A7IEhvd2V2ZXIs IHdlIG5vdGUgdGhhdCBMRFAgY2FuIHVzZSB3aGF0ZXZlciBUQ1AgbWVzc2FnZSBkaWdlc3QgdGVj aG5pcXVlcyBhcmUgYXZhaWxhYmxlLCBhbmQgd2hlbiBvbmUgc3Ryb25nZXIgdGhhbiBNRDUgaXMg c3BlY2lmaWVkIGFuZCBpbXBsZW1lbnRlZCwgdXBncmFkaW5nIExEUCB0byB1c2UgaXQgd291bGQg YmUgcmVsYXRpdmVseSBzdHJhaWdodGZvcndhcmQuJnF1b3Q7PGJyPg0KPGJyPg0KV2Ugbm90ZSB0 aGF0IEJHUCBoYXMgYWxyZWFkeSBiZWVuIHRocm91Z2ggdGhpcyBwcm9jZXNzLCBhbmQgcmVwbGFj ZWQgTUQ1IHdpdGggVENQLUFPIGluIFJGQyA3NDU0LiBJIHdvdWxkIGJlIGxvZ2ljYWwgdG8gZm9s bG93IHRoZSBzYW1lIGFwcHJvYWNoIHRvIHNlY3VyZSBMRFAuIEhvd2V2ZXIsIGFzIGZhciBhcyB3 ZSBhcmUgYWJsZSB0byBhc2NlcnRhaW4sIHRoZXJlIGlzIGN1cnJlbnRseSBubyByZWNvbW1lbmRl ZCwgbWFuZGF0b3J5IHRvIGltcGxlbWVudCwNCiBjcnlwdG9ncmFwaGljIGZ1bmN0aW9uIHNwZWNp ZmllZC4gV2UgYXJlIGNvbmNlcm5lZCB0aGF0IHdpdGhvdXQgc3VjaCBhIG1hbmRhdG9yeSBmdW5j dGlvbiwgaW1wbGVtZW50YXRpb25zIHdpbGwgc2ltcGx5IGZhbGwgYmFjayB0byBNRDUgYW5kIHdl IHdpbGwgYmUgbm8gZnVydGhlciBmb3J3YXJkPGJyPg0KPGJyPg0KV2UgdGhpbmsgdGhhdCB0aGUg YmVzdCB3YXkgZm9yd2FyZCBpcyB0byBwdWJsaXNoIGEgZHJhZnQgc2ltaWxhciB0byBSRkMgNzQ1 NCB0aGF0IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgcmVxdWlyZW1lbnQ6PGJyPg0KPGJyPg0KJnF1 b3Q7SW1wbGVtZW50YXRpb25zIGNvbmZvcm1pbmcgdG8gdGhpcyBSRkMgTVVTVCBpbXBsZW1lbnQg VENQLUFPIHRvIHNlY3VyZSB0aGUgVENQIHNlc3Npb25zIGNhcnJ5aW5nIExEUCBpbiBhZGRpdGlv biB0byB0aGUgY3VycmVudGx5IHJlcXVpcmVkIFRDUCBNRDUgU2lnbmF0dXJlIE9wdGlvbi4gRnVy dGhlcm1vcmUsIHRoZSBUQkQgY3J5cHRvZ3JhcGhpYyBtZWNoYW5pc20gbXVzdCBiZSBpbXBsZW1l bnRlZCBhbmQgcHJvdmlkZWQgdG8gVENQLUFPIHRvDQogc2VjdXJlIExEUCBtZXNzYWdlcy4gVGhl IFRCRCBtZWNoYW5pc20gaXMgdGhlIHByZWZlcnJlZCBvcHRpb24sIGFuZCBNRDUgaXMgb25seSB0 byBiZSB1c2VkIHdoZW4gVEJEIGlzIHVuYXZhaWxhYmxlLiZxdW90Ozxicj4NCjxicj4NCldlIGFy ZSBub3QgYW4gZXhwZXJ0cyBvbiB0aGlzIHBhcnQgb2YgdGhlIHN0YWNrLCBidXQgaXQgc2VlbXMg dGhhdCBUQ1Agc2VjdXJpdHkgbmVnb3RpYXRpb24gaXMgc3RpbGwgd29yayBpbiBwcm9ncmVzcy4g SWYgd2UgYXJlIHdyb25nLCB0aGVuIHdlIG5lZWQgdG8gaW5jbHVkZSBhIHJlcXVpcmVtZW50IHRo YXQgc3VjaCBuZWdvdGlhdGlvbiBpcyBhbHNvIHJlcXVpcmVkLiBJbiB0aGUgYWJzZW5jZSBvZiBh IG5lZ290aWF0aW9uIHByb3RvY29sLCBob3dldmVyLA0KIHdlIG5lZWQgdG8gbGVhdmUgdGhpcyBh cyBhIGNvbmZpZ3VyYXRpb24gcHJvY2VzcyB1bnRpbCBzdWNoIHRpbWUgYXMgdGhlIG5lZ290aWF0 aW9uIHByb3RvY29sIHdvcmsgaXMgY29tcGxldGUuIE9uIGNvbXBsZXRpb24gb2YgYSBzdWl0YWJs ZSBuZWdvdGlhdGlvbiBwcm90b2NvbCB3ZSBuZWVkIHRvIGlzc3VlIGEgZnVydGhlciB1cGRhdGUg cmVxdWlyaW5nIGl0cyB1c2UuPGJyPg0KPGJyPg0KQWRkaXRpb25hbGx5IHdlIHNob3VsZCBub3Rl IHRoYXQgbm8gY3J5cHRvZ3JhcGhpYyBtZWNoYW5pc20gaGFzIGFuIGluZGVmaW5pdGUgbGlmZXRp bWUsIGFuZCB0aGF0IGltcGxlbWVudGF0aW9uIHNob3VsZCBub3RlIHRoZSBJRVRGIGFudGljaXBh dGVzIHVwZGF0aW5nIHRoZSBkZWZhdWx0IGNyeXB0b2dyYXBoaWMgbWVjaGFuaXNtIG92ZXIgdGlt ZS48YnI+DQo8YnI+DQpUaGUgVEJEIGRlZmF1bHQgc2VjdXJpdHkgZnVuY3Rpb24gd2lsbCBuZWVk IHRvIGJlIGNob3NlbiBzdWNoIHRoYXQgaXQgY2FuIHJlYXNvbmFibHkgYmUgaW1wbGVtZW50ZWQg b24gYSB0eXBpY2FsIHJvdXRlciByb3V0ZSBwcm9jZXNzb3IsIGFuZCB3aGljaCB3aWxsIHByb3Zp ZGUgYWRlcXVhdGUgc2VjdXJpdHkgd2l0aG91dCBzaWduaWZpY2FudGx5IGRlZ3JhZGluZyB0aGUg Y29udmVyZ2VuY2UgdGltZSBvZiBhbiBMU1IuIFdpdGhvdXQgYSBmdW5jdGlvbg0KIHRoYXQgZG9l cyBub3Qgc2lnbmlmaWNhbnRseSBpbXBhY3Qgcm91dGVyIGNvbnZlcmdlbmNlIHdlIHNpbXBseSBj bG9zZSBvbmUgdnVsbmVyYWJpbGl0eSBhbmQgb3BlbiBhbm90aGVyLjxicj4NCjxicj4NCkFzIGV4 cGVydHMgb24gdGhlIExEUCBwcm90b2NvbCwgYnV0IG5vdCBvbiBzZWN1cml0eSBtZWNoYW5pc21z LCB3ZSZuYnNwOyBuZWVkIHRvIGFzayB0aGUgc2VjdXJpdHkgYXJlYSBmb3IgYSByZXZpZXcgb2Yg b3VyIHByb3Bvc2VkIGFwcHJvYWNoLCBhbmQgaGVscCBjb3JyZWN0aW5nIGFueSBtaXN1bmRlcnN0 YW5kaW5nIG9mIHRoZSBzZWN1cml0eSBpc3N1ZXMgb3Igb3VyIG1pc3VuZGVyc3RhbmRpbmcgb2Yg dGhlIGV4aXN0aW5nIHNlY3VyaXR5IG1lY2hhbmlzbXMuDQogV2UgYWxzbyBuZWVkIHRoZSByZWNv bW1lbmRhdGlvbnMgb2YgYSBzdWl0YWJsZSBzZWN1cml0eSBmdW5jdGlvbiAoVEJEIGluIHRoZSBh Ym92ZSB0ZXh0KS48YnI+DQo8YnI+DQpCZXN0IHJlZ2FyZHM8YnI+DQo8YnI+DQpUaGUgTVBMUyBX RyBDaGFpcnM8YnI+DQpUaGUgUEFMUyBXRyBDaGFpcnM8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM5PR0701MB25472EFBB94C1C98EA2606B393540AM5PR0701MB2547_-- From nobody Fri Nov 10 13:16:35 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FB512949A; Fri, 10 Nov 2017 13:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 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_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 cIH7G6ss1OA5; Fri, 10 Nov 2017 13:16:32 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20138.outbound.protection.outlook.com [40.107.2.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD02512421A; Fri, 10 Nov 2017 13:16:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=L2pQwvL60GcFyj55A+aqGBkhBHlz5fgc6ICjPQ9fO5o=; b=izW+KfPlTudb7DeCIF79n4+7QQoFZaBT33yy9NlIuiBmfVHpkIyNJTE/HZaCzCPUUlzIynscACg88Nep/rKRurzlUQZd19NfRCa1rGKJgcEQgROkHSL+lOl3KSyIvRxzBSsnz8pibIgkG4fqGsjbrHbaykGQeyM8YljMn6JRflc= Received: from VI1PR0701MB2559.eurprd07.prod.outlook.com (2603:10a6:801:11::12) by VI1PR0701MB2559.eurprd07.prod.outlook.com (2603:10a6:801:11::12) with TransportReplication id Version 15.20 (Build 218.6); Fri, 10 Nov 2017 21:16:28 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2546.eurprd07.prod.outlook.com (10.173.92.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Fri, 10 Nov 2017 16:21:53 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::14d8:6acd:f568:98f]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::14d8:6acd:f568:98f%17]) with mapi id 15.20.0218.005; Fri, 10 Nov 2017 16:21:53 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: Eric Rescorla , Stewart Bryant , "tcpm@ietf.org" CC: "mpls@ietf.org" , "pals-chairs@tools.ietf.org" , "" , "mpls-chairs@ietf.org" , "pals@ietf.org" , "" Thread-Topic: [mpls] LDP Security Thread-Index: AQHTWLboye/68uxiMkCt9OCmRHsgC6MKxUkAgAMG5/A= Date: Fri, 10 Nov 2017 16:21:52 +0000 Message-ID: References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <5994f353-5306-0fa8-2d2d-024ebdbb10df@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [103.5.19.85] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2559; 6:sAQlo/4uvQBgzyIfOMImNTH1KThAg+U7a6AVQSBE3OX869PhyJHygo16dbNS5g4DCGwTbbaRIA1bqtntDT5RWmtRQyzhZI16Gan9rR2wooobJ/hXyScLnJA2mteQ1fNtsJGmEkGHpURuzGnLJKoO0dx/gXhK6c/p27w8xsKepDwKPqDkCLDgHprP9/txoVMPbhqvOhvXHBtUnjBBIzCzA4zQh/gqgiupm1zP90gNCwe7b9upPrDwpv7lWts1nDpVblyjnX5ZQ99eE5TLduNLd7UZSXToMaoVuPFznkeWUpvvK8WTUGbUsCt33Dfv2olK0attl6iERWPxjxn4D94tKIMGODRZafy3KDvzLGPLPts=; 5:BXUwRSYqDdaVsgY2U6knPQk/ZV8kYqf3tILsIEyVAJkClaR1Ncba3kYKnQiicf0JDdBeISaXZnKCSbDh8yD1Bks5LP9aIsSjJKAYPPZVRwwPTVOzF6e0WKB/7VVs7qdVKuFgI/kw3sYsaPbsGJ6Fz5VQJgRyS8cx2P3XMIT58EE=; 24:UylHE8Q3Op2mGlmioIHBYi497IdarIg8kxYA7lXzH97q4BEC1bsiTpfEUZlPcBLK2jcjjdSaQ/Qc7HOVXX7pHt5Sd3U4eIkO0KztULcdkE8=; 7:Q4U3To9GdWFlg9hpi4cLEjjLNNQFo2bFnz0E7wGomaeI3IRLcHhYB6HMqVSgfAQEZWLURKCGWQI+OWmehtVBoHIfG47gAjOItoqljvZCy1iGCObOORaqbS21NUe21/Zuev9zLB6I2i0nCsjuR8zP2/C3bIK7lKNAKDSo545OEaLuGM93LXqPlTB9bUCWd2viEgcIYLh75Mtevb0QVFc02Y2Wg7hMkt1Tnq74EvVBpLT45yU34E41iIrLwpd1sJ9B x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 20920c15-d52a-4ae0-2563-08d528572764 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM5PR0701MB2546; x-ms-traffictypediagnostic: VI1PR0701MB2559: x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3231022)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0701MB2559; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0701MB2559; x-forefront-prvs: 0487C0DB7E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(24454002)(199003)(189002)(229853002)(93886005)(10710500007)(105586002)(2906002)(3280700002)(6506006)(2950100002)(5660300001)(3660700001)(2501003)(102836003)(86362001)(4326008)(3846002)(66066001)(316002)(53546010)(7696004)(790700001)(6116002)(6436002)(39060400002)(110136005)(2420400007)(8676002)(2900100001)(6306002)(54896002)(9686003)(6246003)(7736002)(478600001)(101416001)(99286004)(189998001)(5250100002)(7110500001)(53936002)(15650500001)(8936002)(81166006)(54906003)(33656002)(236005)(81156014)(14454004)(74316002)(68736007)(55016002)(97736004)(106356001)(25786009)(50986999)(54356999)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB2559; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB25472EFBB94C1C98EA2606B393540AM5PR0701MB2547_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 20920c15-d52a-4ae0-2563-08d528572764 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2017 16:21:52.9839 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2559 Archived-At: Subject: Re: [Pals] [mpls] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 21:16:35 -0000 --_000_AM5PR0701MB25472EFBB94C1C98EA2606B393540AM5PR0701MB2547_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 K1RDUE0NCg0KDQoNClBsZWFzZSBmcmVlIHRvIGRpc2N1c3MgY2hhbmdlcyB0byBUQ1AtQU8gb24g dGhlIFRDUE0gbGlzdCwgb3Igc3BlYWsgdXAgYXQgdGhlIHVwY29taW5nIFRDUE0gbWVldGluZy4N Cg0KDQoNClRoZSBhZGRpdGlvbiBvZiBTSEEtMjU2IGhhcyBiZWVuIGRpc2N1c3NlZCBpbiBUQ1BN IGFscmVhZHkgKHNlZSBkcmFmdC1uYXlhay10Y3Atc2hhMi0wMiksIGJ1dCBzbyBmYXIgdGhlcmUg d2FzIG5vdCBtdWNoIGVuZXJneSBhbmQgbm8gaW50ZXJlc3QgZnJvbSBwb3RlbnRpYWwgVENQLUFP IGltcGxlbWVudGVycyBvciB1c2Vycy4NCg0KDQoNCk1pY2hhZWwNCg0KKFRDUE0gY28tY2hhaXIp DQoNCg0KDQpGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAwOCwgMjAxNyA3 OjAwIFBNDQpUbzogU3Rld2FydCBCcnlhbnQgPHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbT4NCkNj OiBtcGxzQGlldGYub3JnOyBwYWxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgPHJ0Zy1hZHNAaWV0 Zi5vcmc+IDxydGctYWRzQGlldGYub3JnPjsgbXBscy1jaGFpcnNAaWV0Zi5vcmc7IHBhbHNAaWV0 Zi5vcmc7IDxzZWMtYWRzQGlldGYub3JnPiA8c2VjLWFkc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbbXBsc10gTERQIFNlY3VyaXR5DQoNCkhpIFN0ZXdhcnQNCg0KVGhhbmtzIGZvciB5b3VyIG5v dGUuDQoNCk15IG92ZXJhbGwgc2Vuc2Ugb2YgdGhlIHN0YXRlIG9mIHBsYXkgaXMsIEkgdGhpbmsg bXVjaCBsaWtlIHlvdXJzLg0KDQpUQ1AtTUQ1IGlzIGluYWRlcXVhdGUgaW4gdHdvIG1ham9yIHJl c3BlY3RzOg0KLSBJdCB1c2VzIHdlYWsgYWxnb3JpdGhtcw0KLSBJdCBoYXMgYSBiYWQgbmVnb3Rp YXRpb24vc2V0dW9wIHN0b3J5IChtYW51YWwga2V5IG1hbmFnZW1lbnQpDQoNClRDUC1BTyBpcyBp bnRlbmRlZCB0byBiZSBhIGRyb3AtaW4gcmVwbGFjZW1lbnQgZm9yIFRDUC1NRDUgYW5kIHNvIHJl bWVkaWVzIHRoZSBhbGdvcml0aG0NCmlzc3VlIGJ1dCBub3QgdGhlIGtleSBtYW5hZ2VtZW50IGlz c3VlIFswXS4gV2UgaGF2ZW4ndCBtYWRlIG11Y2ggcHJvZ3Jlc3Mgb24gdGhlIGtleQ0KbWFuYWdl bWVudCBzdG9yeSwgYW5kIHRoYXQgc2VlbXMgdG8gYmUgYSBtYWpvciBpbXBlZGltZW50IHRvIGRl cGxveWluZyBlaXRoZXIgb2YgdGhlc2UNCnRlY2hub2xvZ2llcyAod2hpY2ggSSBhbSBnaXZlbiB0 byB1bmRlcnN0YW5kIGRvbid0IHNlZSBhIGxvdCBvZiB1c2UpLiBXZSBzaG91bGQgcHJvYmFibHkN CnRhbGsgaW4gU2luZ2Fwb3JlIGFib3V0IHRoYXQsIGJ1dCB0aGF0J3Mgbm90IGdvaW5nIHRvIGdl dCBiZXR0ZXIgYW55IHRpbWUgc29vbi4NCg0KSW4gdGhlIGludGVyaW0sIEkgdGhpbmsgdGhlIHRl eHQgeW91IGhhdmUgaXMgT0ssIGFuZCAiVEJEIiBzaG91bGQgcmVhZCAiU0hBLTI1NiIsIHdpdGgN CnRoZSBmYWxsYmFjayBiZWluZyBTSEEtMjU2IC0+IFNIQS0xIC0+IE1ENS4NCg0KLUVrcg0KDQoN ClswXSBUZWNobmljYWxseSBJdCBoYXMgYmV0dGVyIHN1cHBvcnQgZm9yIHJvbGxvdmVyLCBidXQg dGhpcyBpcyBub3QgYSBodWdlIGltcHJvdmVtZW50Lg0KWzFdIHRjcGNyeXB0IGlzIGtpbmQgb2Yg b3J0aG9nb25hbCBoZXJlIGFzIGl0J3MgdW5hdXRoZW50aWNhdGVkIGJ1dCBvcHBvcnR1bmlzdGlj LiAgVGhhdCBzYWlkLA0KaXQgd291bGQgcHJvdmlkZSBkZWZlbnNlIGFnYWluc3QgYXR0YWNrZXJz IHdobyBnYWluIGFjY2VzcyB0byB0aGUgbGluayBhZnRlciBjb25uZWN0aW9uDQpzZXR1cCBhbmQg ZG9lc24ndCByZXF1aXJlIGNvbmZpZ3VyYXRpb24uDQoNCk9uIFdlZCwgTm92IDgsIDIwMTcgYXQg OToyNyBBTSwgU3Rld2FydCBCcnlhbnQgPHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbTxtYWlsdG86 c3Rld2FydC5icnlhbnRAZ21haWwuY29tPj4gd3JvdGU6DQpUbyB0aGUgU0VDIGFuZCBSVEcgQURz LA0KDQpJIGFtIHNlbmRpbmcgdGhlIGZvbGxvd2luZyBtZXNzYWdlIG9uIGJlaGFsZiBvZiB0aGUg TVBMUyBhbmQgdGhlDQpQQUxTIFdHIENoYWlycy4NCg0KVGhlcmUgaXMgYSBjb25jZXJuIHNoYXJl ZCBhbW9uZyB0aGUgc2VjdXJpdHkgY29tbXVuaXR5IGFuZCB0aGUgd29ya2luZyBncm91cHMgdGhh dCBkZXZlbG9wIHRoZSBMRFAgcHJvdG9jb2wgdGhhdCBMRFAgaXMgbm8gbG9uZ2VyIGFkZXF1YXRl bHkgc2VjdXJlZC4gTERQIGN1cnJlbnRseSByZWxpZXMgb24gTUQ1IGZvciBjcnlwdG9ncmFwaGlj IHNlY3VyaXR5IG9mIGl0cyBtZXNzYWdlcywgYnV0IE1ENSBpcyBhIGhhc2ggZnVuY3Rpb24gdGhh dCBpcyBubyBsb25nZXIgY29uc2lkZXJlZCB0byBtZWV0IGN1cnJlbnQgc2VjdXJpdHkgcmVxdWly ZW1lbnRzLg0KDQpJbiBSRkM1MDM2IChwdWJsaXNoZWQgMjAwNykgU2VjdGlvbiA1LjEgKFNwb29m aW5nKSAsIExpc3QgZWxlbWVudCAyLiBTZXNzaW9uIGNvbW11bmljYXRpb24gY2FycmllZCBieSBU Q1AgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnRzIGlzIG1hZGU6DQoNCiJMRFAgc3BlY2lmaWVzIHVz ZSBvZiB0aGUgVENQIE1ENSBTaWduYXR1cmUgT3B0aW9uIHRvIHByb3ZpZGUgZm9yIHRoZSBhdXRo ZW50aWNpdHkgYW5kIGludGVncml0eSBvZiBzZXNzaW9uIG1lc3NhZ2VzLg0KDQoiW1JGQzIzODVd IGFzc2VydHMgdGhhdCBNRDUgYXV0aGVudGljYXRpb24gaXMgbm93IGNvbnNpZGVyZWQgYnkgc29t ZSB0byBiZSB0b28gd2VhayBmb3IgdGhpcyBhcHBsaWNhdGlvbi4gIEl0IGFsc28gcG9pbnRzIG91 dCB0aGF0IGEgc2ltaWxhciBUQ1Agb3B0aW9uIHdpdGggYSBzdHJvbmdlciBoYXNoaW5nIGFsZ29y aXRobSAoaXQgY2l0ZXMgU0hBLTEgYXMgYW4gZXhhbXBsZSkgY291bGQgYmUgZGVwbG95ZWQuICBU byBvdXIga25vd2xlZGdlLCBubyBzdWNoIFRDUCBvcHRpb24gaGFzIGJlZW4gZGVmaW5lZCBhbmQg ZGVwbG95ZWQuICBIb3dldmVyLCB3ZSBub3RlIHRoYXQgTERQIGNhbiB1c2Ugd2hhdGV2ZXIgVENQ IG1lc3NhZ2UgZGlnZXN0IHRlY2huaXF1ZXMgYXJlIGF2YWlsYWJsZSwgYW5kIHdoZW4gb25lIHN0 cm9uZ2VyIHRoYW4gTUQ1IGlzIHNwZWNpZmllZCBhbmQgaW1wbGVtZW50ZWQsIHVwZ3JhZGluZyBM RFAgdG8gdXNlIGl0IHdvdWxkIGJlIHJlbGF0aXZlbHkgc3RyYWlnaHRmb3J3YXJkLiINCg0KV2Ug bm90ZSB0aGF0IEJHUCBoYXMgYWxyZWFkeSBiZWVuIHRocm91Z2ggdGhpcyBwcm9jZXNzLCBhbmQg cmVwbGFjZWQgTUQ1IHdpdGggVENQLUFPIGluIFJGQyA3NDU0LiBJIHdvdWxkIGJlIGxvZ2ljYWwg dG8gZm9sbG93IHRoZSBzYW1lIGFwcHJvYWNoIHRvIHNlY3VyZSBMRFAuIEhvd2V2ZXIsIGFzIGZh ciBhcyB3ZSBhcmUgYWJsZSB0byBhc2NlcnRhaW4sIHRoZXJlIGlzIGN1cnJlbnRseSBubyByZWNv bW1lbmRlZCwgbWFuZGF0b3J5IHRvIGltcGxlbWVudCwgY3J5cHRvZ3JhcGhpYyBmdW5jdGlvbiBz cGVjaWZpZWQuIFdlIGFyZSBjb25jZXJuZWQgdGhhdCB3aXRob3V0IHN1Y2ggYSBtYW5kYXRvcnkg ZnVuY3Rpb24sIGltcGxlbWVudGF0aW9ucyB3aWxsIHNpbXBseSBmYWxsIGJhY2sgdG8gTUQ1IGFu ZCB3ZSB3aWxsIGJlIG5vIGZ1cnRoZXIgZm9yd2FyZA0KDQpXZSB0aGluayB0aGF0IHRoZSBiZXN0 IHdheSBmb3J3YXJkIGlzIHRvIHB1Ymxpc2ggYSBkcmFmdCBzaW1pbGFyIHRvIFJGQyA3NDU0IHRo YXQgY29udGFpbnMgdGhlIGZvbGxvd2luZyByZXF1aXJlbWVudDoNCg0KIkltcGxlbWVudGF0aW9u cyBjb25mb3JtaW5nIHRvIHRoaXMgUkZDIE1VU1QgaW1wbGVtZW50IFRDUC1BTyB0byBzZWN1cmUg dGhlIFRDUCBzZXNzaW9ucyBjYXJyeWluZyBMRFAgaW4gYWRkaXRpb24gdG8gdGhlIGN1cnJlbnRs eSByZXF1aXJlZCBUQ1AgTUQ1IFNpZ25hdHVyZSBPcHRpb24uIEZ1cnRoZXJtb3JlLCB0aGUgVEJE IGNyeXB0b2dyYXBoaWMgbWVjaGFuaXNtIG11c3QgYmUgaW1wbGVtZW50ZWQgYW5kIHByb3ZpZGVk IHRvIFRDUC1BTyB0byBzZWN1cmUgTERQIG1lc3NhZ2VzLiBUaGUgVEJEIG1lY2hhbmlzbSBpcyB0 aGUgcHJlZmVycmVkIG9wdGlvbiwgYW5kIE1ENSBpcyBvbmx5IHRvIGJlIHVzZWQgd2hlbiBUQkQg aXMgdW5hdmFpbGFibGUuIg0KDQpXZSBhcmUgbm90IGFuIGV4cGVydHMgb24gdGhpcyBwYXJ0IG9m IHRoZSBzdGFjaywgYnV0IGl0IHNlZW1zIHRoYXQgVENQIHNlY3VyaXR5IG5lZ290aWF0aW9uIGlz IHN0aWxsIHdvcmsgaW4gcHJvZ3Jlc3MuIElmIHdlIGFyZSB3cm9uZywgdGhlbiB3ZSBuZWVkIHRv IGluY2x1ZGUgYSByZXF1aXJlbWVudCB0aGF0IHN1Y2ggbmVnb3RpYXRpb24gaXMgYWxzbyByZXF1 aXJlZC4gSW4gdGhlIGFic2VuY2Ugb2YgYSBuZWdvdGlhdGlvbiBwcm90b2NvbCwgaG93ZXZlciwg d2UgbmVlZCB0byBsZWF2ZSB0aGlzIGFzIGEgY29uZmlndXJhdGlvbiBwcm9jZXNzIHVudGlsIHN1 Y2ggdGltZSBhcyB0aGUgbmVnb3RpYXRpb24gcHJvdG9jb2wgd29yayBpcyBjb21wbGV0ZS4gT24g Y29tcGxldGlvbiBvZiBhIHN1aXRhYmxlIG5lZ290aWF0aW9uIHByb3RvY29sIHdlIG5lZWQgdG8g aXNzdWUgYSBmdXJ0aGVyIHVwZGF0ZSByZXF1aXJpbmcgaXRzIHVzZS4NCg0KQWRkaXRpb25hbGx5 IHdlIHNob3VsZCBub3RlIHRoYXQgbm8gY3J5cHRvZ3JhcGhpYyBtZWNoYW5pc20gaGFzIGFuIGlu ZGVmaW5pdGUgbGlmZXRpbWUsIGFuZCB0aGF0IGltcGxlbWVudGF0aW9uIHNob3VsZCBub3RlIHRo ZSBJRVRGIGFudGljaXBhdGVzIHVwZGF0aW5nIHRoZSBkZWZhdWx0IGNyeXB0b2dyYXBoaWMgbWVj aGFuaXNtIG92ZXIgdGltZS4NCg0KVGhlIFRCRCBkZWZhdWx0IHNlY3VyaXR5IGZ1bmN0aW9uIHdp bGwgbmVlZCB0byBiZSBjaG9zZW4gc3VjaCB0aGF0IGl0IGNhbiByZWFzb25hYmx5IGJlIGltcGxl bWVudGVkIG9uIGEgdHlwaWNhbCByb3V0ZXIgcm91dGUgcHJvY2Vzc29yLCBhbmQgd2hpY2ggd2ls bCBwcm92aWRlIGFkZXF1YXRlIHNlY3VyaXR5IHdpdGhvdXQgc2lnbmlmaWNhbnRseSBkZWdyYWRp bmcgdGhlIGNvbnZlcmdlbmNlIHRpbWUgb2YgYW4gTFNSLiBXaXRob3V0IGEgZnVuY3Rpb24gdGhh dCBkb2VzIG5vdCBzaWduaWZpY2FudGx5IGltcGFjdCByb3V0ZXIgY29udmVyZ2VuY2Ugd2Ugc2lt cGx5IGNsb3NlIG9uZSB2dWxuZXJhYmlsaXR5IGFuZCBvcGVuIGFub3RoZXIuDQoNCkFzIGV4cGVy dHMgb24gdGhlIExEUCBwcm90b2NvbCwgYnV0IG5vdCBvbiBzZWN1cml0eSBtZWNoYW5pc21zLCB3 ZSAgbmVlZCB0byBhc2sgdGhlIHNlY3VyaXR5IGFyZWEgZm9yIGEgcmV2aWV3IG9mIG91ciBwcm9w b3NlZCBhcHByb2FjaCwgYW5kIGhlbHAgY29ycmVjdGluZyBhbnkgbWlzdW5kZXJzdGFuZGluZyBv ZiB0aGUgc2VjdXJpdHkgaXNzdWVzIG9yIG91ciBtaXN1bmRlcnN0YW5kaW5nIG9mIHRoZSBleGlz dGluZyBzZWN1cml0eSBtZWNoYW5pc21zLiBXZSBhbHNvIG5lZWQgdGhlIHJlY29tbWVuZGF0aW9u cyBvZiBhIHN1aXRhYmxlIHNlY3VyaXR5IGZ1bmN0aW9uIChUQkQgaW4gdGhlIGFib3ZlIHRleHQp Lg0KDQpCZXN0IHJlZ2FyZHMNCg0KVGhlIE1QTFMgV0cgQ2hhaXJzDQpUaGUgUEFMUyBXRyBDaGFp cnMNCg0KDQo= --_000_AM5PR0701MB25472EFBB94C1C98EA2606B393540AM5PR0701MB2547_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNv UGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFp biBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mIzQzO1RDUE0gPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPlBsZWFzZSBmcmVlIHRvIGRpc2N1c3MgY2hhbmdlcyB0byBUQ1AtQU8gb24gdGhl IFRDUE0gbGlzdCwgb3Igc3BlYWsgdXAgYXQgdGhlIHVwY29taW5nIFRDUE0gbWVldGluZy48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIGFkZGl0aW9uIG9mIFNIQS0yNTYgaGFzIGJl ZW4gZGlzY3Vzc2VkIGluIFRDUE0gYWxyZWFkeSAoc2VlIGRyYWZ0LW5heWFrLXRjcC1zaGEyLTAy KSwgYnV0IHNvIGZhciB0aGVyZSB3YXMgbm90IG11Y2ggZW5lcmd5IGFuZCBubyBpbnRlcmVzdCBm cm9tIHBvdGVudGlhbCBUQ1AtQU8gaW1wbGVtZW50ZXJzIG9yIHVzZXJzLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5NaWNoYWVsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4oVENQTSBjby1jaGFpcik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBtcGxz IFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5Fcmlj IFJlc2NvcmxhPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTm92ZW1iZXIgMDgsIDIwMTcg NzowMCBQTTxicj4NCjxiPlRvOjwvYj4gU3Rld2FydCBCcnlhbnQgJmx0O3N0ZXdhcnQuYnJ5YW50 QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IG1wbHNAaWV0Zi5vcmc7IHBhbHMtY2hhaXJz QHRvb2xzLmlldGYub3JnOyAmbHQ7cnRnLWFkc0BpZXRmLm9yZyZndDsgJmx0O3J0Zy1hZHNAaWV0 Zi5vcmcmZ3Q7OyBtcGxzLWNoYWlyc0BpZXRmLm9yZzsgcGFsc0BpZXRmLm9yZzsgJmx0O3NlYy1h ZHNAaWV0Zi5vcmcmZ3Q7ICZsdDtzZWMtYWRzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW21wbHNdIExEUCBTZWN1cml0eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhpIFN0ZXdhcnQ8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgeW91ciBub3RlLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBvdmVyYWxsIHNlbnNlIG9m IHRoZSBzdGF0ZSBvZiBwbGF5IGlzLCBJIHRoaW5rIG11Y2ggbGlrZSB5b3Vycy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VENQLU1ENSBpcyBp bmFkZXF1YXRlIGluIHR3byBtYWpvciByZXNwZWN0czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gSXQgdXNlcyB3ZWFrIGFsZ29yaXRobXM8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gSXQgaGFz IGEgYmFkIG5lZ290aWF0aW9uL3NldHVvcCBzdG9yeSAobWFudWFsIGtleSBtYW5hZ2VtZW50KTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UQ1At QU8gaXMgaW50ZW5kZWQgdG8gYmUgYSBkcm9wLWluIHJlcGxhY2VtZW50IGZvciBUQ1AtTUQ1IGFu ZCBzbyByZW1lZGllcyB0aGUgYWxnb3JpdGhtPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pc3N1ZSBidXQgbm90IHRoZSBrZXkgbWFuYWdlbWVudCBp c3N1ZSBbMF0uIFdlIGhhdmVuJ3QgbWFkZSBtdWNoIHByb2dyZXNzIG9uIHRoZSBrZXk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm1hbmFnZW1lbnQg c3RvcnksIGFuZCB0aGF0IHNlZW1zIHRvIGJlIGEgbWFqb3IgaW1wZWRpbWVudCB0byBkZXBsb3lp bmcgZWl0aGVyIG9mIHRoZXNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj50ZWNobm9sb2dpZXMgKHdoaWNoIEkgYW0gZ2l2ZW4gdG8gdW5kZXJzdGFu ZCBkb24ndCBzZWUgYSBsb3Qgb2YgdXNlKS4gV2Ugc2hvdWxkIHByb2JhYmx5PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50YWxrIGluIFNpbmdhcG9y ZSBhYm91dCB0aGF0LCBidXQgdGhhdCdzIG5vdCBnb2luZyB0byBnZXQgYmV0dGVyIGFueSB0aW1l IHNvb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkluIHRoZSBpbnRlcmltLCBJIHRoaW5rIHRoZSB0ZXh0IHlvdSBoYXZlIGlzIE9LLCBhbmQg JnF1b3Q7VEJEJnF1b3Q7IHNob3VsZCByZWFkICZxdW90O1NIQS0yNTYmcXVvdDssIHdpdGg8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBmYWxs YmFjayBiZWluZyBTSEEtMjU2IC0mZ3Q7IFNIQS0xIC0mZ3Q7IE1ENS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlswXSBUZWNobmljYWxs eSBJdCBoYXMgYmV0dGVyIHN1cHBvcnQgZm9yIHJvbGxvdmVyLCBidXQgdGhpcyBpcyBub3QgYSBo dWdlIGltcHJvdmVtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+WzFdIHRjcGNyeXB0IGlzIGtpbmQgb2Ygb3J0aG9nb25hbCBoZXJlIGFzIGl0 J3MgdW5hdXRoZW50aWNhdGVkIGJ1dCBvcHBvcnR1bmlzdGljLiZuYnNwOyBUaGF0IHNhaWQsPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pdCB3b3Vs ZCBwcm92aWRlIGRlZmVuc2UgYWdhaW5zdCBhdHRhY2tlcnMgd2hvIGdhaW4gYWNjZXNzIHRvIHRo ZSBsaW5rIGFmdGVyIGNvbm5lY3Rpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPnNldHVwIGFuZCBkb2Vzbid0IHJlcXVpcmUgY29uZmlndXJhdGlv bi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gV2VkLCBOb3YgOCwgMjAxNyBhdCA5OjI3IEFNLCBTdGV3YXJ0IEJyeWFudCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZXdh cnQuYnJ5YW50QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ VG8gdGhlIFNFQyBhbmQgUlRHIEFEcyw8YnI+DQo8YnI+DQpJIGFtIHNlbmRpbmcgdGhlIGZvbGxv d2luZyBtZXNzYWdlIG9uIGJlaGFsZiBvZiB0aGUgTVBMUyBhbmQgdGhlPGJyPg0KUEFMUyBXRyBD aGFpcnMuPGJyPg0KPGJyPg0KVGhlcmUgaXMgYSBjb25jZXJuIHNoYXJlZCBhbW9uZyB0aGUgc2Vj dXJpdHkgY29tbXVuaXR5IGFuZCB0aGUgd29ya2luZyBncm91cHMgdGhhdCBkZXZlbG9wIHRoZSBM RFAgcHJvdG9jb2wgdGhhdCBMRFAgaXMgbm8gbG9uZ2VyIGFkZXF1YXRlbHkgc2VjdXJlZC4gTERQ IGN1cnJlbnRseSByZWxpZXMgb24gTUQ1IGZvciBjcnlwdG9ncmFwaGljIHNlY3VyaXR5IG9mIGl0 cyBtZXNzYWdlcywgYnV0IE1ENSBpcyBhIGhhc2ggZnVuY3Rpb24gdGhhdCBpcw0KIG5vIGxvbmdl ciBjb25zaWRlcmVkIHRvIG1lZXQgY3VycmVudCBzZWN1cml0eSByZXF1aXJlbWVudHMuPGJyPg0K PGJyPg0KSW4gUkZDNTAzNiAocHVibGlzaGVkIDIwMDcpIFNlY3Rpb24gNS4xIChTcG9vZmluZykg LCBMaXN0IGVsZW1lbnQgMi4gU2Vzc2lvbiBjb21tdW5pY2F0aW9uIGNhcnJpZWQgYnkgVENQIHRo ZSBmb2xsb3dpbmcgc3RhdGVtZW50cyBpcyBtYWRlOjxicj4NCjxicj4NCiZxdW90O0xEUCBzcGVj aWZpZXMgdXNlIG9mIHRoZSBUQ1AgTUQ1IFNpZ25hdHVyZSBPcHRpb24gdG8gcHJvdmlkZSBmb3Ig dGhlIGF1dGhlbnRpY2l0eSBhbmQgaW50ZWdyaXR5IG9mIHNlc3Npb24gbWVzc2FnZXMuPGJyPg0K PGJyPg0KJnF1b3Q7W1JGQzIzODVdIGFzc2VydHMgdGhhdCBNRDUgYXV0aGVudGljYXRpb24gaXMg bm93IGNvbnNpZGVyZWQgYnkgc29tZSB0byBiZSB0b28gd2VhayBmb3IgdGhpcyBhcHBsaWNhdGlv bi4mbmJzcDsgSXQgYWxzbyBwb2ludHMgb3V0IHRoYXQgYSBzaW1pbGFyIFRDUCBvcHRpb24gd2l0 aCBhIHN0cm9uZ2VyIGhhc2hpbmcgYWxnb3JpdGhtIChpdCBjaXRlcyBTSEEtMSBhcyBhbiBleGFt cGxlKSBjb3VsZCBiZSBkZXBsb3llZC4mbmJzcDsgVG8gb3VyIGtub3dsZWRnZSwgbm8NCiBzdWNo IFRDUCBvcHRpb24gaGFzIGJlZW4gZGVmaW5lZCBhbmQgZGVwbG95ZWQuJm5ic3A7IEhvd2V2ZXIs IHdlIG5vdGUgdGhhdCBMRFAgY2FuIHVzZSB3aGF0ZXZlciBUQ1AgbWVzc2FnZSBkaWdlc3QgdGVj aG5pcXVlcyBhcmUgYXZhaWxhYmxlLCBhbmQgd2hlbiBvbmUgc3Ryb25nZXIgdGhhbiBNRDUgaXMg c3BlY2lmaWVkIGFuZCBpbXBsZW1lbnRlZCwgdXBncmFkaW5nIExEUCB0byB1c2UgaXQgd291bGQg YmUgcmVsYXRpdmVseSBzdHJhaWdodGZvcndhcmQuJnF1b3Q7PGJyPg0KPGJyPg0KV2Ugbm90ZSB0 aGF0IEJHUCBoYXMgYWxyZWFkeSBiZWVuIHRocm91Z2ggdGhpcyBwcm9jZXNzLCBhbmQgcmVwbGFj ZWQgTUQ1IHdpdGggVENQLUFPIGluIFJGQyA3NDU0LiBJIHdvdWxkIGJlIGxvZ2ljYWwgdG8gZm9s bG93IHRoZSBzYW1lIGFwcHJvYWNoIHRvIHNlY3VyZSBMRFAuIEhvd2V2ZXIsIGFzIGZhciBhcyB3 ZSBhcmUgYWJsZSB0byBhc2NlcnRhaW4sIHRoZXJlIGlzIGN1cnJlbnRseSBubyByZWNvbW1lbmRl ZCwgbWFuZGF0b3J5IHRvIGltcGxlbWVudCwNCiBjcnlwdG9ncmFwaGljIGZ1bmN0aW9uIHNwZWNp ZmllZC4gV2UgYXJlIGNvbmNlcm5lZCB0aGF0IHdpdGhvdXQgc3VjaCBhIG1hbmRhdG9yeSBmdW5j dGlvbiwgaW1wbGVtZW50YXRpb25zIHdpbGwgc2ltcGx5IGZhbGwgYmFjayB0byBNRDUgYW5kIHdl IHdpbGwgYmUgbm8gZnVydGhlciBmb3J3YXJkPGJyPg0KPGJyPg0KV2UgdGhpbmsgdGhhdCB0aGUg YmVzdCB3YXkgZm9yd2FyZCBpcyB0byBwdWJsaXNoIGEgZHJhZnQgc2ltaWxhciB0byBSRkMgNzQ1 NCB0aGF0IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgcmVxdWlyZW1lbnQ6PGJyPg0KPGJyPg0KJnF1 b3Q7SW1wbGVtZW50YXRpb25zIGNvbmZvcm1pbmcgdG8gdGhpcyBSRkMgTVVTVCBpbXBsZW1lbnQg VENQLUFPIHRvIHNlY3VyZSB0aGUgVENQIHNlc3Npb25zIGNhcnJ5aW5nIExEUCBpbiBhZGRpdGlv biB0byB0aGUgY3VycmVudGx5IHJlcXVpcmVkIFRDUCBNRDUgU2lnbmF0dXJlIE9wdGlvbi4gRnVy dGhlcm1vcmUsIHRoZSBUQkQgY3J5cHRvZ3JhcGhpYyBtZWNoYW5pc20gbXVzdCBiZSBpbXBsZW1l bnRlZCBhbmQgcHJvdmlkZWQgdG8gVENQLUFPIHRvDQogc2VjdXJlIExEUCBtZXNzYWdlcy4gVGhl IFRCRCBtZWNoYW5pc20gaXMgdGhlIHByZWZlcnJlZCBvcHRpb24sIGFuZCBNRDUgaXMgb25seSB0 byBiZSB1c2VkIHdoZW4gVEJEIGlzIHVuYXZhaWxhYmxlLiZxdW90Ozxicj4NCjxicj4NCldlIGFy ZSBub3QgYW4gZXhwZXJ0cyBvbiB0aGlzIHBhcnQgb2YgdGhlIHN0YWNrLCBidXQgaXQgc2VlbXMg dGhhdCBUQ1Agc2VjdXJpdHkgbmVnb3RpYXRpb24gaXMgc3RpbGwgd29yayBpbiBwcm9ncmVzcy4g SWYgd2UgYXJlIHdyb25nLCB0aGVuIHdlIG5lZWQgdG8gaW5jbHVkZSBhIHJlcXVpcmVtZW50IHRo YXQgc3VjaCBuZWdvdGlhdGlvbiBpcyBhbHNvIHJlcXVpcmVkLiBJbiB0aGUgYWJzZW5jZSBvZiBh IG5lZ290aWF0aW9uIHByb3RvY29sLCBob3dldmVyLA0KIHdlIG5lZWQgdG8gbGVhdmUgdGhpcyBh cyBhIGNvbmZpZ3VyYXRpb24gcHJvY2VzcyB1bnRpbCBzdWNoIHRpbWUgYXMgdGhlIG5lZ290aWF0 aW9uIHByb3RvY29sIHdvcmsgaXMgY29tcGxldGUuIE9uIGNvbXBsZXRpb24gb2YgYSBzdWl0YWJs ZSBuZWdvdGlhdGlvbiBwcm90b2NvbCB3ZSBuZWVkIHRvIGlzc3VlIGEgZnVydGhlciB1cGRhdGUg cmVxdWlyaW5nIGl0cyB1c2UuPGJyPg0KPGJyPg0KQWRkaXRpb25hbGx5IHdlIHNob3VsZCBub3Rl IHRoYXQgbm8gY3J5cHRvZ3JhcGhpYyBtZWNoYW5pc20gaGFzIGFuIGluZGVmaW5pdGUgbGlmZXRp bWUsIGFuZCB0aGF0IGltcGxlbWVudGF0aW9uIHNob3VsZCBub3RlIHRoZSBJRVRGIGFudGljaXBh dGVzIHVwZGF0aW5nIHRoZSBkZWZhdWx0IGNyeXB0b2dyYXBoaWMgbWVjaGFuaXNtIG92ZXIgdGlt ZS48YnI+DQo8YnI+DQpUaGUgVEJEIGRlZmF1bHQgc2VjdXJpdHkgZnVuY3Rpb24gd2lsbCBuZWVk IHRvIGJlIGNob3NlbiBzdWNoIHRoYXQgaXQgY2FuIHJlYXNvbmFibHkgYmUgaW1wbGVtZW50ZWQg b24gYSB0eXBpY2FsIHJvdXRlciByb3V0ZSBwcm9jZXNzb3IsIGFuZCB3aGljaCB3aWxsIHByb3Zp ZGUgYWRlcXVhdGUgc2VjdXJpdHkgd2l0aG91dCBzaWduaWZpY2FudGx5IGRlZ3JhZGluZyB0aGUg Y29udmVyZ2VuY2UgdGltZSBvZiBhbiBMU1IuIFdpdGhvdXQgYSBmdW5jdGlvbg0KIHRoYXQgZG9l cyBub3Qgc2lnbmlmaWNhbnRseSBpbXBhY3Qgcm91dGVyIGNvbnZlcmdlbmNlIHdlIHNpbXBseSBj bG9zZSBvbmUgdnVsbmVyYWJpbGl0eSBhbmQgb3BlbiBhbm90aGVyLjxicj4NCjxicj4NCkFzIGV4 cGVydHMgb24gdGhlIExEUCBwcm90b2NvbCwgYnV0IG5vdCBvbiBzZWN1cml0eSBtZWNoYW5pc21z LCB3ZSZuYnNwOyBuZWVkIHRvIGFzayB0aGUgc2VjdXJpdHkgYXJlYSBmb3IgYSByZXZpZXcgb2Yg b3VyIHByb3Bvc2VkIGFwcHJvYWNoLCBhbmQgaGVscCBjb3JyZWN0aW5nIGFueSBtaXN1bmRlcnN0 YW5kaW5nIG9mIHRoZSBzZWN1cml0eSBpc3N1ZXMgb3Igb3VyIG1pc3VuZGVyc3RhbmRpbmcgb2Yg dGhlIGV4aXN0aW5nIHNlY3VyaXR5IG1lY2hhbmlzbXMuDQogV2UgYWxzbyBuZWVkIHRoZSByZWNv bW1lbmRhdGlvbnMgb2YgYSBzdWl0YWJsZSBzZWN1cml0eSBmdW5jdGlvbiAoVEJEIGluIHRoZSBh Ym92ZSB0ZXh0KS48YnI+DQo8YnI+DQpCZXN0IHJlZ2FyZHM8YnI+DQo8YnI+DQpUaGUgTVBMUyBX RyBDaGFpcnM8YnI+DQpUaGUgUEFMUyBXRyBDaGFpcnM8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM5PR0701MB25472EFBB94C1C98EA2606B393540AM5PR0701MB2547_-- From nobody Fri Nov 10 19:59:20 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD97128D19; Fri, 10 Nov 2017 19:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=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 8K2-CmkZ8rdh; Fri, 10 Nov 2017 19:59:16 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 43794127977; Fri, 10 Nov 2017 19:59:16 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.157.12; From: "Susan Hares" To: "'Kathleen Moriarty'" , "'Eric Rescorla'" Cc: "'Uma Chunduri'" , , , , "'mpls-chairs'" , , References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <5994f353-5306-0fa8-2d2d-024ebdbb10df@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> <25B4902B1192E84696414485F5726854135191D6@sjceml521-mbs.china.huawei.com> <25B4902B1192E84696414485F572685413519209@sjceml521-mbs.china.huawei.com> <002101d35919$c6295b90$527c12b0$@ndzh.com> In-Reply-To: Date: Fri, 10 Nov 2017 22:58:59 -0500 Message-ID: <041301d35aa1$6b091c30$411b5490$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHQ4LkDJ6Z/J5TaTb+XshLIa/JnkwFbRp7YAmwCdnMA/HavIAGkQiT3AY0bhdsBndke1AMFAIO+ARBf2LkCdM8cTgI5zEjPANLg1FoCskmr1QJotocDAdpri4gCKx0VhQNlnZqeAUTMuqUCagT4KQH2qG2pAiEuY+UBjFSKngIHpgryAswFFnEBEBsu56GbnitQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Pals] [mpls] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 03:59:18 -0000 Kathleen and Eric:=20 I agree that getting linux implementations with TCP-AO is one avenue to = drive things into product. Any ideas on getting more deployment for = routing security - is really important. Pushing both small and large = gains (TCP-AO, registration) will help us continually increase the = security. =20 Sue=20 -----Original Message----- From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]=20 Sent: Thursday, November 9, 2017 3:09 PM To: Eric Rescorla Cc: Susan Hares; Uma Chunduri; mpls@ietf.org; = pals-chairs@tools.ietf.org; ; mpls-chairs; = pals@ietf.org; Subject: Re: [mpls] LDP Security On Thu, Nov 9, 2017 at 2:09 PM, Eric Rescorla wrote: > Yeah, I agree. I don't really have any good ideas how to get people to = > do AO. Based on comments I've heard, providers don't see a lot of=20 > value, rightly or wrongly.... I know Alia has been talking about a possible Linux implementation to = drive the way. I agree with EKR on other points and have been following = along. Best, Kathleen > > -Ekr > > > On Wed, Nov 8, 2017 at 9:15 PM, Susan Hares wrote: >> >> Eric: >> >> >> >> BGP and LDP would be more secure if TCP-AO deployed with all BGP and=20 >> LDP =E2=80=93 but there are issues with customer pick-up and = deployment of=20 >> these protocols on many networks. I wished we had TCP-AO when BGP = started, but we did not. >> >> >> >> Some of the least secure BGP is in data centers =E2=80=93 where the = DC=20 >> providers say =E2=80=9CIt=E2=80=99s all under one = administration=E2=80=9D. Another problem is on private >> lines. We should chat about the networks each of these protocols = are >> actually deployed on. If you have any insight on a way to encourage >> adoption, I=E2=80=99d love to hear it. Require TCP-AO does not really = mean=20 >> anything if providers and Data Centers do not adopt it. >> >> >> >> Going from SHA-1 to SHA-256 on a TCP-AO is simple upgrade compared to = >> getting people to TCP-AO. >> >> >> >> Sue >> >> >> >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla >> Sent: Wednesday, November 8, 2017 7:44 PM >> To: Uma Chunduri >> Cc: mpls@ietf.org; pals-chairs@tools.ietf.org; ;=20 >> mpls-chairs@ietf.org; pals@ietf.org; >> >> >> Subject: Re: [mpls] LDP Security >> >> >> >> I don't understand what you're getting at here. Yes, if people have=20 >> TCP-AO then presumably they have SHA-1. >> >> >> >> But now we're talking about requiring people to have TCP-AO in this=20 >> case, so we should try to move them to SHA-256 at the time we require = AO. >> >> >> >> -Ekr >> >> >> >> >> >> On Wed, Nov 8, 2017 at 4:14 PM, Uma Chunduri=20 >> >> wrote: >> >> From: Eric Rescorla [mailto:ekr@rtfm.com] >> Sent: Wednesday, November 08, 2017 3:53 PM >> >> >> To: Uma Chunduri >> Cc: Stewart Bryant ; mpls@ietf.org;=20 >> pals-chairs@tools.ietf.org; ;=20 >> mpls-chairs@ietf.org; pals@ietf.org; =20 >> >> Subject: Re: [mpls] LDP Security >> >> >> >> >> >> >> >> On Wed, Nov 8, 2017 at 3:50 PM, Uma Chunduri=20 >> >> wrote: >> >> In-line [Uma1]: >> >> -- >> >> Uma C. >> >> >> >> From: Eric Rescorla [mailto:ekr@rtfm.com] >> Sent: Wednesday, November 08, 2017 12:53 PM >> To: Uma Chunduri >> Cc: Stewart Bryant ; mpls@ietf.org;=20 >> pals-chairs@tools.ietf.org; ;=20 >> mpls-chairs@ietf.org; pals@ietf.org; =20 >> >> >> >> Subject: Re: [mpls] LDP Security >> >> >> >> >> >> >> >> On Wed, Nov 8, 2017 at 11:57 AM, Uma Chunduri=20 >> >> wrote: >> >> Hi Stewart, >> >> >> >> I would note https://tools.ietf.org/html/rfc6952 - where LDP security = >> is analyzed from all aspects. >> >> >> >> Eric, >> >> >> >> Quick comments below [Uma]: >> >> >> >> -- >> >> Uma C. >> >> >> >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla >> Sent: Wednesday, November 08, 2017 10:00 AM >> To: Stewart Bryant >> Cc: mpls@ietf.org; pals-chairs@tools.ietf.org; =20 >> ; mpls-chairs@ietf.org; pals@ietf.org;=20 >> >> Subject: Re: [mpls] LDP Security >> >> >> >> Hi Stewart >> >> >> >> Thanks for your note. >> >> >> >> My overall sense of the state of play is, I think much like yours. >> >> >> >> TCP-MD5 is inadequate in two major respects: >> >> - It uses weak algorithms >> >> - It has a bad negotiation/setuop story (manual key management) >> >> >> >> TCP-AO is intended to be a drop-in replacement for TCP-MD5 and so=20 >> remedies the algorithm >> >> Issue >> >> >> >> [Uma]: Yes, if we go with RFC 5926 mandatory list.. >> >> >> >> but not the key management issue [0]. We haven't made much progress=20 >> on the key >> >> management story, and that seems to be a major impediment to=20 >> deploying either of these >> >> technologies (which I am given to understand don't see a lot of use). >> >> >> >> [Uma]: True. >> >> But I would indicate some effort done few years back=20 >> regarding key management for pair wise routing protocols (BGP, LDP,=20 >> PCEP, MSDP ..). >> >> One such proposal is by extending IKEv2 to negotiate=20 >> TCP-AO MKTs (which can give rekey & algo. agility) - >> https://tools.ietf.org/html/draft-mahesh-karp-rkmp-05 >> >> This also requires some more work with TCP-AO; me &=20 >> Joe put together=20 >> https://www.ietf.org/archive/id/draft-chunduri-karp-using-ikev2-with- >> tcp-ao-06.txt >> >> Note the above didn=E2=80=99t progress in the concluded = KARP WG=20 >> (not fully sure the reasons on why). >> >> >> >> Yeah, I know that people tried to do this, but my impression was it=20 >> kinda didn't progress much. >> >> >> >> >> >> >> >> We should probably talk in Singapore about that, but that's not going = >> to get better any time soon. >> >> >> >> In the interim, I think the text you have is OK, and "TBD" should=20 >> read "SHA-256", with >> >> the fallback being SHA-256 -> SHA-1 -> MD5. >> >> >> >> [Uma]: While the list can be extended - I didn=E2=80=99t see SHA256 = in the=20 >> mandatory list in RFC 5926 for MAC. >> >> >> >> Generally we're trying to move away from SHA-1 towards SHA-256. >> >> >> >> [Uma1]: Couple of things: >> >> 1. Nothing to be done (from spec pov of course): Use TCP-AO = (instead >> of current MD5) with the RFC 5926 mandated MACs/KDFs =E2=80=93 so the = =E2=80=98TBD=E2=80=99=20 >> in Stewart suggesting below is already there. >> >> 2. As #1 too is not good enough from your above note - do = SHA-256 >> and live with it (no algorithm agility). Still a security benefit in=20 >> one way from existing stuff or even #1. >> >> I'm not sure why you say "no algorithm agility". You'd be using AO,=20 >> just with a different algorithm than SHA-1. AES-CMAC is still fine as = >> far as I know. >> >> [Uma2]: Sure, you have it, if you use AO; >> >> But then I am not getting how we can mandate one=20 >> MUST implement algorithm as suggested below TBD would actually work = >> (especially >> - *if* #1 is already deployed somewhere?) >> >> Perhaps staying with #1 is the best bet or do=20 >> negotiation through #3, with already mandated and additional stuff. >> >> >> >> -Ekr >> >> >> >> 3. Do key management and =E2=80=9Ctheoretically=E2=80=9D get = all we wanted=E2=80=A6. >> >> >> >> We have been here multiple times; because #1 itself is not *mostly*=20 >> deployed (neither in BGP nor in LDP) if there is any appetite for #2=20 >> and #3 for practical deployments. But still it may be good to do #2 = any ways. >> >> >> >> >> >> -Ekr >> >> >> >> >> >> -Ekr >> >> >> >> >> >> [0] Technically It has better support for rollover, but this is not a = >> huge improvement. >> >> [1] tcpcrypt is kind of orthogonal here as it's unauthenticated but=20 >> opportunistic. That said, >> >> it would provide defense against attackers who gain access to the=20 >> link after connection >> >> setup and doesn't require configuration. >> >> >> >> On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant=20 >> >> wrote: >> >> To the SEC and RTG ADs, >> >> I am sending the following message on behalf of the MPLS and the PALS = >> WG Chairs. >> >> There is a concern shared among the security community and the=20 >> working groups that develop the LDP protocol that LDP is no longer=20 >> adequately secured. LDP currently relies on MD5 for cryptographic=20 >> security of its messages, but MD5 is a hash function that is no=20 >> longer considered to meet current security requirements. >> >> In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2. >> Session communication carried by TCP the following statements is = made: >> >> "LDP specifies use of the TCP MD5 Signature Option to provide for the = >> authenticity and integrity of session messages. >> >> "[RFC2385] asserts that MD5 authentication is now considered by some=20 >> to be too weak for this application. It also points out that a=20 >> similar TCP option with a stronger hashing algorithm (it cites SHA-1=20 >> as an example) could be deployed. To our knowledge, no such TCP=20 >> option has been defined and deployed. However, we note that LDP can=20 >> use whatever TCP message digest techniques are available, and when=20 >> one stronger than MD5 is specified and implemented, upgrading LDP to = use it would be relatively straightforward." >> >> We note that BGP has already been through this process, and replaced=20 >> MD5 with TCP-AO in RFC 7454. I would be logical to follow the same=20 >> approach to secure LDP. However, as far as we are able to ascertain,=20 >> there is currently no recommended, mandatory to implement,=20 >> cryptographic function specified. We are concerned that without such=20 >> a mandatory function, implementations will simply fall back to MD5=20 >> and we will be no further forward >> >> We think that the best way forward is to publish a draft similar to=20 >> RFC >> 7454 that contains the following requirement: >> >> "Implementations conforming to this RFC MUST implement TCP-AO to=20 >> secure the TCP sessions carrying LDP in addition to the currently=20 >> required TCP MD5 Signature Option. Furthermore, the TBD cryptographic = >> mechanism must be implemented and provided to TCP-AO to secure LDP=20 >> messages. The TBD mechanism is the preferred option, and MD5 is only=20 >> to be used when TBD is unavailable." >> >> We are not an experts on this part of the stack, but it seems that=20 >> TCP security negotiation is still work in progress. If we are wrong,=20 >> then we need to include a requirement that such negotiation is also=20 >> required. In the absence of a negotiation protocol, however, we need=20 >> to leave this as a configuration process until such time as the=20 >> negotiation protocol work is complete. On completion of a suitable=20 >> negotiation protocol we need to issue a further update requiring its = use. >> >> Additionally we should note that no cryptographic mechanism has an=20 >> indefinite lifetime, and that implementation should note the IETF=20 >> anticipates updating the default cryptographic mechanism over time. >> >> The TBD default security function will need to be chosen such that it = >> can reasonably be implemented on a typical router route processor,=20 >> and which will provide adequate security without significantly=20 >> degrading the convergence time of an LSR. Without a function that=20 >> does not significantly impact router convergence we simply close one=20 >> vulnerability and open another. >> >> As experts on the LDP protocol, but not on security mechanisms, we =20 >> need to ask the security area for a review of our proposed approach,=20 >> and help correcting any misunderstanding of the security issues or=20 >> our misunderstanding of the existing security mechanisms. We also=20 >> need the recommendations of a suitable security function (TBD in the = above text). >> >> Best regards >> >> The MPLS WG Chairs >> The PALS WG Chairs >> >> >> >> >> >> >> >> > > --=20 Best regards, Kathleen From nobody Sat Nov 11 03:51:18 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F08129408; Fri, 10 Nov 2017 19:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 thX2hvXQ8o4B; Fri, 10 Nov 2017 19:12:06 -0800 (PST) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (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 B82C21200C1; Fri, 10 Nov 2017 19:12:06 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id l19so6195164pgo.2; Fri, 10 Nov 2017 19:12:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zeZ75tWzpVvem0+C/MRWXQ47EzxfApCKHS2ZCdNWwCU=; b=odCN5jbcl6P5YDIcNe/ge1V9tf6yF/uLGjCAJx4qwv3DxLYQaSaIIhDlLHDjb+CmWf Lqb64EdE16zFuytPjJHvhjDxUUEF5TE5LCuYdOZy8Nmux29E4QaKlKdXM6I1vDHdvm0X uo76DFVAx7LqVUOxnm9MKKSSUDgZ7qiKLIPWn1Au3RyVP5D6Lez2AqioyrSqY92STA2w ly98gk/uzDjfZGek9B4vjuoz3hVHpjbaUjhhFZOL4CT/59oQBQhNrUHTh1UmDD5rmE2d V+YkzRNPcyjj4T3KYnvAo5kaPUjZA/apnztmjARpP0uHsgDilK4yNIrBSEjCBP8Lk/84 BRZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zeZ75tWzpVvem0+C/MRWXQ47EzxfApCKHS2ZCdNWwCU=; b=PA/2lB/BQYO1hZWF87ige6jeKIsy02f/05qAI1BekyXJO96xr2peY2Zl7+l4tbF8v2 6kdhFL3KeiynbSPUEUU0jG8WdYhVrUFsEp9fp4oPRBo7gbV1j9wxSSauImU949ceIg6y XRnwK9QJQpYH+DitPnjj7SZ4o6bU0kG6F8NYm1Jt+WDsyYPQTJCImEVQbGVTWgGsHzv2 AWpjwQOGrSTvyhxbbmyZLzHZ6DLxKiCZDB2lWAaItCAgq8CtcfV+J2W8y3uNe68Gadkp 2brm0CUhm3LZ92KqIEZr2x2RI4PSnS5BTZZffuMXydvwZWcLbgln1OL1/Dh01MeyFNVy +F7w== X-Gm-Message-State: AJaThX5r4YdnuR1HXTjxLE2mTHuqRp2eLni9wZYBFTxdenIkG98L8dZE R5Eb6kgxaWd2JMWtxByD9Hd8/4nS X-Google-Smtp-Source: AGs4zMYxPkolZPjIywUbUf2DIuhV7bt/Q8lGrgna87LIrO9U1ILVl3FcyY4E4MMyc+ovC60j84SeCg== X-Received: by 10.98.196.143 with SMTP id h15mr2532599pfk.126.1510369926015; Fri, 10 Nov 2017 19:12:06 -0800 (PST) Received: from [31.133.148.178] (dhcp-94b2.meeting.ietf.org. [31.133.148.178]) by smtp.gmail.com with ESMTPSA id q70sm24612425pfj.39.2017.11.10.19.12.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 19:12:05 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-FDE8250F-18F6-4B4B-B7B0-459161C5CC0F Mime-Version: 1.0 (1.0) From: Jeff Tantsura X-Mailer: iPhone Mail (15A432) In-Reply-To: <4f634e7c-f3b9-f0ab-abc7-80ec1062b52a@strayalpha.com> Date: Sat, 11 Nov 2017 11:11:57 +0800 Cc: "Scharf, Michael (Nokia - DE/Stuttgart)" , Eric Rescorla , Stewart Bryant , "tcpm@ietf.org" , "mpls@ietf.org" , "pals-chairs@tools.ietf.org" , "" , "mpls-chairs@ietf.org" , "pals@ietf.org" , "" Content-Transfer-Encoding: 7bit Message-Id: <697AC959-60C2-401D-9E64-D88E16F35EBB@gmail.com> References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <5994f353-5306-0fa8-2d2d-024ebdbb10df@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> <4f634e7c-f3b9-f0ab-abc7-80ec1062b52a@strayalpha.com> To: Joe Touch Archived-At: X-Mailman-Approved-At: Sat, 11 Nov 2017 03:51:16 -0800 Subject: Re: [Pals] [mpls] [tcpm] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 03:12:10 -0000 --Apple-Mail-FDE8250F-18F6-4B4B-B7B0-459161C5CC0F Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Joe, There=92s no problem with updating, the problem is with adoption... Regards, Jeff > On Nov 11, 2017, at 08:48, Joe Touch wrote: >=20 > Hi, all, >=20 > I don't see a problem if there's a need for updating TCP-AO to include/req= uire other algorithms. It was intended to be extensible. >=20 > I agree with the issue of key management. There was some work on extension= s to IKE to enable its use to manage TCP-AO parameters and keys, but it stal= led twice: >=20 > M. Jethanandani, B. Weis, K. Patel, D. Zhang, S. Hartman, U. Chunduri, A. T= ian, J. Touch, =93Negotiation for Keying Pairwise Routing Protocols in IKEv2= ,=94 (RFC in progress), Nov. 2013. >=20 > U. Chunduri, A. Tian, J. Touch, =93Using IKEv2 with TCP-AO,=94 (RFC in pro= gress), Feb. 2014. >=20 > AFAICT, that would go a long way towards addressing the issues with its us= e outside routing environments where keys are already considered sufficientl= y managed. >=20 > However, the larger problem with TCP-AO is that there are no implementatio= ns available in end system OSes (AFAICT). Designing a new solution simply to= avoid implementing an existing one would be a significant waste of time. > Joe >=20 >> On 11/10/2017 8:21 AM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: >> +TCPM >> =20 >> Please free to discuss changes to TCP-AO on the TCPM list, or speak up at= the upcoming TCPM meeting. >> =20 >> The addition of SHA-256 has been discussed in TCPM already (see draft-nay= ak-tcp-sha2-02), but so far there was not much energy and no interest from p= otential TCP-AO implementers or users. >> =20 >> Michael >> (TCPM co-chair) >> =20 >> =20 >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla >> Sent: Wednesday, November 08, 2017 7:00 PM >> To: Stewart Bryant >> Cc: mpls@ietf.org; pals-chairs@tools.ietf.org; ; mpls-chairs@ietf.org; pals@ietf.org; >> Subject: Re: [mpls] LDP Security >> =20 >> Hi Stewart >> =20 >> Thanks for your note. >> =20 >> My overall sense of the state of play is, I think much like yours. >> =20 >> TCP-MD5 is inadequate in two major respects: >> - It uses weak algorithms >> - It has a bad negotiation/setuop story (manual key management) >> =20 >> TCP-AO is intended to be a drop-in replacement for TCP-MD5 and so remedie= s the algorithm >> issue but not the key management issue [0]. We haven't made much progress= on the key >> management story, and that seems to be a major impediment to deploying ei= ther of these >> technologies (which I am given to understand don't see a lot of use). We s= hould probably >> talk in Singapore about that, but that's not going to get better any time= soon. >> =20 >> In the interim, I think the text you have is OK, and "TBD" should read "S= HA-256", with >> the fallback being SHA-256 -> SHA-1 -> MD5. >> =20 >> -Ekr >> =20 >> =20 >> [0] Technically It has better support for rollover, but this is not a hug= e improvement. >> [1] tcpcrypt is kind of orthogonal here as it's unauthenticated but oppor= tunistic. That said, >> it would provide defense against attackers who gain access to the link af= ter connection >> setup and doesn't require configuration. >> =20 >> On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant = wrote: >> To the SEC and RTG ADs, >>=20 >> I am sending the following message on behalf of the MPLS and the >> PALS WG Chairs. >>=20 >> There is a concern shared among the security community and the working gr= oups that develop the LDP protocol that LDP is no longer adequately secured.= LDP currently relies on MD5 for cryptographic security of its messages, but= MD5 is a hash function that is no longer considered to meet current securit= y requirements. >>=20 >> In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2. Sess= ion communication carried by TCP the following statements is made: >>=20 >> "LDP specifies use of the TCP MD5 Signature Option to provide for the aut= henticity and integrity of session messages. >>=20 >> "[RFC2385] asserts that MD5 authentication is now considered by some to b= e too weak for this application. It also points out that a= similar TCP option with a stronger hashing algorithm (it c= ites SHA-1 as an example) could be deployed. To our knowl= edge, no such TCP option has been defined and deployed. However, we note th= at LDP can use whatever TCP message digest techniques are available, and whe= n one stronger than MD5 is specified and implemented, upgrading LDP to use i= t would be relatively straightforward." >>=20 >> We note that BGP has already been through this process, and replaced MD5 w= ith TCP-AO in RFC 7454. I would be logical to follow the same approach to se= cure LDP. However, as far as we are able to ascertain, there is currently no= recommended, mandatory to implement, cryptographic function specified. We a= re concerned that without such a mandatory function, implementations will si= mply fall back to MD5 and we will be no further forward >>=20 >> We think that the best way forward is to publish a draft similar to RFC 7= 454 that contains the following requirement: >>=20 >> "Implementations conforming to this RFC MUST implement TCP-AO to secure t= he TCP sessions carrying LDP in addition to the currently required TCP MD5 S= ignature Option. Furthermore, the TBD cryptographic mechanism must be implem= ented and provided to TCP-AO to secure LDP messages. The TBD mechanism is th= e preferred option, and MD5 is only to be used when TBD is unavailable." >>=20 >> We are not an experts on this part of the stack, but it seems that TCP se= curity negotiation is still work in progress. If we are wrong, then we need t= o include a requirement that such negotiation is also required. In the absen= ce of a negotiation protocol, however, we need to leave this as a configurat= ion process until such time as the negotiation protocol work is complete. On= completion of a suitable negotiation protocol we need to issue a further up= date requiring its use. >>=20 >> Additionally we should note that no cryptographic mechanism has an indefi= nite lifetime, and that implementation should note the IETF anticipates upda= ting the default cryptographic mechanism over time. >>=20 >> The TBD default security function will need to be chosen such that it can= reasonably be implemented on a typical router route processor, and which wi= ll provide adequate security without significantly degrading the convergence= time of an LSR. Without a function that does not significantly impact route= r convergence we simply close one vulnerability and open another. >>=20 >> As experts on the LDP protocol, but not on security mechanisms, we need t= o ask the security area for a review of our proposed approach, and help corr= ecting any misunderstanding of the security issues or our misunderstanding o= f the existing security mechanisms. We also need the recommendations of a su= itable security function (TBD in the above text). >>=20 >> Best regards >>=20 >> The MPLS WG Chairs >> The PALS WG Chairs >>=20 >>=20 >> =20 >>=20 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail-FDE8250F-18F6-4B4B-B7B0-459161C5CC0F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Joe,

There=E2=80=99s no p= roblem with updating, the problem is with adoption...

Regards,
Jeff

On Nov 11, 2017, at 08= :48, Joe Touch <touch@strayalpha.= com> wrote:

=20 =20 =20

Hi, all,

I don't see a problem if there's a need for updating TCP-AO to include/require other algorithms. It was intended to be extensible.

I agree with the issue of key management. There was some work on extensions to IKE to enable its use to manage TCP-AO parameters and keys, but it stalled twice:

M. Jethanandani, B. Weis, K. Patel, D. Zhang, S. Hartman, U. Chunduri, A. Tian, J. Touch, =E2=80=9CNegotiation for Keying Pairwise Routing Protocols in IKEv2,=E2=80=9D (RFC in= progress), Nov. 2013.

U. Chunduri, A. Tian, J. Touch, =E2=80=9CUsing IKEv2 with TCP-AO,=E2=80=9D (RFC in progress), Feb. 2014.

AFAICT, that would go a long way towards addressing the issues with its use outside routing environments where keys are already considered sufficiently managed.

However, the larger problem with TCP-AO is that there are no implementations available in end system OSes (AFAICT). Designing a new solution simply to avoid implementing an existing one would be a significant waste of time.

Joe


On 11/10/2017 8:21 AM, Scharf, Michael (Nokia - DE/Stuttgart) wrote:

+TCPM

 

Please free to discuss changes to TCP-AO on the TCPM list, or speak up at the upcoming TCPM meeting.

 

The addition of SHA-256 has been discussed in TCPM already (see draft-nayak-tcp-sha2-02), but so far there was not much energy and no interest from potential TCP-AO implementers or users.

 

Michael

(TCPM co-chair)

 

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Wednesday, November 08, 2017 7:00 PM
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: mpls@ietf.org; pals-chairs@tools.ietf.org; <rtg-ads@ietf.org> <rtg-ads@ietf.org>; mpls-chairs@ietf.org; pals@ietf.org; <sec-ads@ietf.org> <sec-ads@ietf.org>
Subject: Re: [mpls] LDP Security

 

Hi Stewart

 

Thanks for your note.

 

My overall sense of the state of play is, I think much like yours.

 

TCP-MD5 is inadequate in two major respects:

- It uses weak algorithms

- It has a bad negotiation/setuop story (manual key management)

 

TCP-AO is intended to be a drop-in replacement for TCP-MD5 and so remedies the algorithm

issue but not the key management issue [0]. We haven't made much progress on the key

management story, and that seems to be a major impediment to deploying either of these

technologies (which I am given to understand don't see a lot of use). We should probably<= /o:p>

talk in Singapore about that, but that's not going to get better any time soon.

=

 

In the interim, I think the text you have is OK, and "TBD" should read "SHA-256", with=

the fallback being SHA-256 -> SHA-1 -> MD5.

 

-Ekr

 

 

[0] Technically It has better support for rollover, but this is not a huge improvement.=

[1] tcpcrypt is kind of orthogonal here as it's unauthenticated but opportunistic.  That said,

it would provide defense against attackers who gain access to the link after connection<= /o:p>

setup and doesn't require configuration.

 

On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant <stewart.bryant@gmail.com&g= t; wrote:

To the= SEC and RTG ADs,

I am sending the following message on behalf of the MPLS and the
PALS WG Chairs.

There is a concern shared among the security community and the working groups that develop the LDP protocol that LDP is no longer adequately secured. LDP currently relies on MD5 for cryptographic security of its messages, but MD5 is a hash function that is no longer considered to meet current security requirements.

In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2. Session communication carried by TCP the following statements is made:

"LDP specifies use of the TCP MD5 Signature Option to provide for the authenticity and integrity of session messages.

"[RFC2385] asserts that MD5 authentication is now considered by some to be too weak for this application.  It also points out that a similar TCP option with a stronger hashing algorithm (it cites SHA-1 as an example) could be deployed.  To our knowledge, no such TCP option has been defined and deployed.  However, we note that LDP can use whatever= TCP message digest techniques are available, and when one stronger than MD5 is specified and implemented, upgrading LDP to use it would be relatively straightforward."

We note that BGP has already been through this process, and replaced MD5 with TCP-AO in RFC 7454. I would be logical to follow the same approach to secure LDP. However, as far as we are able to ascertain, there is currently no recommended, mandatory to implement, cryptographic function specified. We are concerned that without such a mandatory function, implementations will simply fall back to MD5 and we will be no further forward

We think that the best way forward is to publish a draft similar to RFC 7454 that contains the following requirement:

"Implementations conforming to this RFC MUST implement TCP-AO to secure the TCP sessions carrying LDP in addition to the currently required TCP MD5 Signature Option. Furthermore, the TBD cryptographic mechanism must be implemented and provided to TCP-AO to secure LDP messages. The TBD mechanism is the preferred option, and MD5 is only to be used when TBD is unavailable."

We are not an experts on this part of the stack, but it seems that TCP security negotiation is still work in progress. If we are wrong, then we need to include a requirement that such negotiation is also required. In the absence of a negotiation protocol, however, we need to leave this as a configuration process until such time as the negotiation protocol work is complete. On completion of a suitable negotiation protocol we need to issue a further update requiring its use.

Additionally we should note that no cryptographic mechanism has an indefinite lifetime, and that implementation should note the IETF anticipates updating the default cryptographic mechanism over time.

The TBD default security function will need to be chosen such that it can reasonably be implemented on a typical router route processor, and which will provide adequate security without significantly degrading the convergence time of an LSR. Without a function that does not significantly impact router convergence we simply close one vulnerability and open another.

As experts on the LDP protocol, but not on security mechanisms, we  need to ask the security area for a review of our proposed approach, and help correcting any misunderstanding of the security issues or our misunderstanding of the existing security mechanisms. We also need the recommendations of a suitable security function (TBD in the above text).

Best regards

The MPLS WG Chairs
The PALS WG Chairs

 



_______________________________________________
tcpm mailing list
tcpm@iet=
f.org
https://www.ietf.org/mailman/listinfo/tcpm

=20
____________________= ___________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman= /listinfo/mpls
= --Apple-Mail-FDE8250F-18F6-4B4B-B7B0-459161C5CC0F-- From nobody Sat Nov 11 03:51:40 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34806126C83; Fri, 10 Nov 2017 16:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 xbXk1VYdGbqL; Fri, 10 Nov 2017 16:48:22 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 A35CE124B09; Fri, 10 Nov 2017 16:48:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding: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=8nebyL0TxwZadcJqwHBxGZu3gqk0LJfowsjNXILeJAQ=; b=rE/VEwg3wztEZfvpvXIZqK1uo ZzPp3jHxZCttPFcJhQW8NyC5iXjGw3vlm3r8zt+AMR0Mh5lnEZBIXR7q54VXXf1UzgOs6W0ug5NeR osC3poGV3LzMZQBwRdcednwwGQP4+BgVFyR81bc9UwgYjSNL8GBhw/+YCyN4WTuYGMrFKt3vuSJWe EAKGW0e59yfMVDRV+l0aWZxsL5jUVPz6CNBt8PfRwTQVsflhlaW3jOUYdCi1QT/jzNZEt5+Bf+eMn o4bkLAHZV4Sp/ta/bcKHIgGIqnxFxyU4avgxxokVysyqc1+ZYkblwLb+ENbZGUKD6KTPGaujGZJvD OEJe6/UbQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:63103 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eDJy6-003UBx-18; Fri, 10 Nov 2017 19:48:21 -0500 To: "Scharf, Michael (Nokia - DE/Stuttgart)" , Eric Rescorla , Stewart Bryant , "tcpm@ietf.org" Cc: "mpls@ietf.org" , "pals-chairs@tools.ietf.org" , "" , "mpls-chairs@ietf.org" , "pals@ietf.org" , "" References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <5994f353-5306-0fa8-2d2d-024ebdbb10df@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> From: Joe Touch Message-ID: <4f634e7c-f3b9-f0ab-abc7-80ec1062b52a@strayalpha.com> Date: Fri, 10 Nov 2017 16:48:12 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1F1BD7BBF23EC48FC92A7AEF" Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: X-Mailman-Approved-At: Sat, 11 Nov 2017 03:51:38 -0800 Subject: Re: [Pals] [tcpm] [mpls] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 00:48:25 -0000 This is a multi-part message in MIME format. --------------1F1BD7BBF23EC48FC92A7AEF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi, all, I don't see a problem if there's a need for updating TCP-AO to include/require other algorithms. It was intended to be extensible. I agree with the issue of key management. There was some work on extensions to IKE to enable its use to manage TCP-AO parameters and keys, but it stalled twice: M. Jethanandani, B. Weis, K. Patel, D. Zhang, S. Hartman, U. Chunduri, A. Tian, J. Touch, “Negotiation for Keying Pairwise Routing Protocols in IKEv2 ,” (RFC in progress), Nov. 2013. U. Chunduri, A. Tian, J. Touch, “Using IKEv2 with TCP-AO ,” (RFC in progress), Feb. 2014. AFAICT, that would go a long way towards addressing the issues with its use outside routing environments where keys are already considered sufficiently managed. However, the larger problem with TCP-AO is that there are no implementations available in end system OSes (AFAICT). Designing a new solution simply to avoid implementing an existing one would be a significant waste of time. Joe On 11/10/2017 8:21 AM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: > > +TCPM > >   > > Please free to discuss changes to TCP-AO on the TCPM list, or speak up > at the upcoming TCPM meeting. > >   > > The addition of SHA-256 has been discussed in TCPM already (see > draft-nayak-tcp-sha2-02), but so far there was not much energy and no > interest from potential TCP-AO implementers or users. > >   > > Michael > > (TCPM co-chair) > >   > >   > > *From:* mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Eric Rescorla > *Sent:* Wednesday, November 08, 2017 7:00 PM > *To:* Stewart Bryant > *Cc:* mpls@ietf.org; pals-chairs@tools.ietf.org; > ; mpls-chairs@ietf.org; pals@ietf.org; > > *Subject:* Re: [mpls] LDP Security > >   > > Hi Stewart > >   > > Thanks for your note. > >   > > My overall sense of the state of play is, I think much like yours. > >   > > TCP-MD5 is inadequate in two major respects: > > - It uses weak algorithms > > - It has a bad negotiation/setuop story (manual key management) > >   > > TCP-AO is intended to be a drop-in replacement for TCP-MD5 and so > remedies the algorithm > > issue but not the key management issue [0]. We haven't made much > progress on the key > > management story, and that seems to be a major impediment to deploying > either of these > > technologies (which I am given to understand don't see a lot of use). > We should probably > > talk in Singapore about that, but that's not going to get better any > time soon. > >   > > In the interim, I think the text you have is OK, and "TBD" should read > "SHA-256", with > > the fallback being SHA-256 -> SHA-1 -> MD5. > >   > > -Ekr > >   > >   > > [0] Technically It has better support for rollover, but this is not a > huge improvement. > > [1] tcpcrypt is kind of orthogonal here as it's unauthenticated but > opportunistic.  That said, > > it would provide defense against attackers who gain access to the link > after connection > > setup and doesn't require configuration. > >   > > On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant > > wrote: > > To the SEC and RTG ADs, > > I am sending the following message on behalf of the MPLS and the > PALS WG Chairs. > > There is a concern shared among the security community and the > working groups that develop the LDP protocol that LDP is no longer > adequately secured. LDP currently relies on MD5 for cryptographic > security of its messages, but MD5 is a hash function that is no > longer considered to meet current security requirements. > > In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element > 2. Session communication carried by TCP the following statements > is made: > > "LDP specifies use of the TCP MD5 Signature Option to provide for > the authenticity and integrity of session messages. > > "[RFC2385] asserts that MD5 authentication is now considered by > some to be too weak for this application.  It also points out that > a similar TCP option with a stronger hashing algorithm (it cites > SHA-1 as an example) could be deployed.  To our knowledge, no such > TCP option has been defined and deployed.  However, we note that > LDP can use whatever TCP message digest techniques are available, > and when one stronger than MD5 is specified and implemented, > upgrading LDP to use it would be relatively straightforward." > > We note that BGP has already been through this process, and > replaced MD5 with TCP-AO in RFC 7454. I would be logical to follow > the same approach to secure LDP. However, as far as we are able to > ascertain, there is currently no recommended, mandatory to > implement, cryptographic function specified. We are concerned that > without such a mandatory function, implementations will simply > fall back to MD5 and we will be no further forward > > We think that the best way forward is to publish a draft similar > to RFC 7454 that contains the following requirement: > > "Implementations conforming to this RFC MUST implement TCP-AO to > secure the TCP sessions carrying LDP in addition to the currently > required TCP MD5 Signature Option. Furthermore, the TBD > cryptographic mechanism must be implemented and provided to TCP-AO > to secure LDP messages. The TBD mechanism is the preferred option, > and MD5 is only to be used when TBD is unavailable." > > We are not an experts on this part of the stack, but it seems that > TCP security negotiation is still work in progress. If we are > wrong, then we need to include a requirement that such negotiation > is also required. In the absence of a negotiation protocol, > however, we need to leave this as a configuration process until > such time as the negotiation protocol work is complete. On > completion of a suitable negotiation protocol we need to issue a > further update requiring its use. > > Additionally we should note that no cryptographic mechanism has an > indefinite lifetime, and that implementation should note the IETF > anticipates updating the default cryptographic mechanism over time. > > The TBD default security function will need to be chosen such that > it can reasonably be implemented on a typical router route > processor, and which will provide adequate security without > significantly degrading the convergence time of an LSR. Without a > function that does not significantly impact router convergence we > simply close one vulnerability and open another. > > As experts on the LDP protocol, but not on security mechanisms, > we  need to ask the security area for a review of our proposed > approach, and help correcting any misunderstanding of the security > issues or our misunderstanding of the existing security > mechanisms. We also need the recommendations of a suitable > security function (TBD in the above text). > > Best regards > > The MPLS WG Chairs > The PALS WG Chairs > >   > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------1F1BD7BBF23EC48FC92A7AEF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi, all,

I don't see a problem if there's a need for updating TCP-AO to include/require other algorithms. It was intended to be extensible.

I agree with the issue of key management. There was some work on extensions to IKE to enable its use to manage TCP-AO parameters and keys, but it stalled twice:

M. Jethanandani, B. Weis, K. Patel, D. Zhang, S. Hartman, U. Chunduri, A. Tian, J. Touch, “Negotiation for Keying Pairwise Routing Protocols in IKEv2,” (RFC in progress), Nov. 2013.

U. Chunduri, A. Tian, J. Touch, “Using IKEv2 with TCP-AO,” (RFC in progress), Feb. 2014.

AFAICT, that would go a long way towards addressing the issues with its use outside routing environments where keys are already considered sufficiently managed.

However, the larger problem with TCP-AO is that there are no implementations available in end system OSes (AFAICT). Designing a new solution simply to avoid implementing an existing one would be a significant waste of time.

Joe


On 11/10/2017 8:21 AM, Scharf, Michael (Nokia - DE/Stuttgart) wrote:

+TCPM

 

Please free to discuss changes to TCP-AO on the TCPM list, or speak up at the upcoming TCPM meeting.

 

The addition of SHA-256 has been discussed in TCPM already (see draft-nayak-tcp-sha2-02), but so far there was not much energy and no interest from potential TCP-AO implementers or users.

 

Michael

(TCPM co-chair)

 

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Wednesday, November 08, 2017 7:00 PM
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: mpls@ietf.org; pals-chairs@tools.ietf.org; <rtg-ads@ietf.org> <rtg-ads@ietf.org>; mpls-chairs@ietf.org; pals@ietf.org; <sec-ads@ietf.org> <sec-ads@ietf.org>
Subject: Re: [mpls] LDP Security

 

Hi Stewart

 

Thanks for your note.

 

My overall sense of the state of play is, I think much like yours.

 

TCP-MD5 is inadequate in two major respects:

- It uses weak algorithms

- It has a bad negotiation/setuop story (manual key management)

 

TCP-AO is intended to be a drop-in replacement for TCP-MD5 and so remedies the algorithm

issue but not the key management issue [0]. We haven't made much progress on the key

management story, and that seems to be a major impediment to deploying either of these

technologies (which I am given to understand don't see a lot of use). We should probably

talk in Singapore about that, but that's not going to get better any time soon.

 

In the interim, I think the text you have is OK, and "TBD" should read "SHA-256", with

the fallback being SHA-256 -> SHA-1 -> MD5.

 

-Ekr

 

 

[0] Technically It has better support for rollover, but this is not a huge improvement.

[1] tcpcrypt is kind of orthogonal here as it's unauthenticated but opportunistic.  That said,

it would provide defense against attackers who gain access to the link after connection

setup and doesn't require configuration.

 

On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant <stewart.bryant@gmail.com> wrote:

To the SEC and RTG ADs,

I am sending the following message on behalf of the MPLS and the
PALS WG Chairs.

There is a concern shared among the security community and the working groups that develop the LDP protocol that LDP is no longer adequately secured. LDP currently relies on MD5 for cryptographic security of its messages, but MD5 is a hash function that is no longer considered to meet current security requirements.

In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2. Session communication carried by TCP the following statements is made:

"LDP specifies use of the TCP MD5 Signature Option to provide for the authenticity and integrity of session messages.

"[RFC2385] asserts that MD5 authentication is now considered by some to be too weak for this application.  It also points out that a similar TCP option with a stronger hashing algorithm (it cites SHA-1 as an example) could be deployed.  To our knowledge, no such TCP option has been defined and deployed.  However, we note that LDP can use whatever TCP message digest techniques are available, and when one stronger than MD5 is specified and implemented, upgrading LDP to use it would be relatively straightforward."

We note that BGP has already been through this process, and replaced MD5 with TCP-AO in RFC 7454. I would be logical to follow the same approach to secure LDP. However, as far as we are able to ascertain, there is currently no recommended, mandatory to implement, cryptographic function specified. We are concerned that without such a mandatory function, implementations will simply fall back to MD5 and we will be no further forward

We think that the best way forward is to publish a draft similar to RFC 7454 that contains the following requirement:

"Implementations conforming to this RFC MUST implement TCP-AO to secure the TCP sessions carrying LDP in addition to the currently required TCP MD5 Signature Option. Furthermore, the TBD cryptographic mechanism must be implemented and provided to TCP-AO to secure LDP messages. The TBD mechanism is the preferred option, and MD5 is only to be used when TBD is unavailable."

We are not an experts on this part of the stack, but it seems that TCP security negotiation is still work in progress. If we are wrong, then we need to include a requirement that such negotiation is also required. In the absence of a negotiation protocol, however, we need to leave this as a configuration process until such time as the negotiation protocol work is complete. On completion of a suitable negotiation protocol we need to issue a further update requiring its use.

Additionally we should note that no cryptographic mechanism has an indefinite lifetime, and that implementation should note the IETF anticipates updating the default cryptographic mechanism over time.

The TBD default security function will need to be chosen such that it can reasonably be implemented on a typical router route processor, and which will provide adequate security without significantly degrading the convergence time of an LSR. Without a function that does not significantly impact router convergence we simply close one vulnerability and open another.

As experts on the LDP protocol, but not on security mechanisms, we  need to ask the security area for a review of our proposed approach, and help correcting any misunderstanding of the security issues or our misunderstanding of the existing security mechanisms. We also need the recommendations of a suitable security function (TBD in the above text).

Best regards

The MPLS WG Chairs
The PALS WG Chairs

 



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

--------------1F1BD7BBF23EC48FC92A7AEF-- From nobody Sat Nov 11 05:05:11 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4AA12951C; Sat, 11 Nov 2017 05:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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=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 49N6DqzTO3G8; Sat, 11 Nov 2017 05:04:59 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0125.outbound.protection.outlook.com [104.47.1.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2565A1270A7; Sat, 11 Nov 2017 05:04:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8hdW9fE1m6XTLI5I6CEd/QhuJqz+i6BoHP04LVJCPnk=; b=LQocyffPEIctx7XMQTnKlCh3uqAfW0kggDz2496JchppfzZfqJ/ZpRGScH/zj3f+2tfODTn5nMPvY79dOt5J6QuovKzvsBnweSOSZpGkEN3l2RxSuiGi/wr7bEGPpK13+MtWzp14qLut3TncHoz+Lm1y3AJg+19q9KwwDNxr6II= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.169.153.236) by HE1PR0701MB3004.eurprd07.prod.outlook.com (2603:10a6:3:4d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Sat, 11 Nov 2017 13:04:54 +0000 Message-ID: <01ad01d35aed$421b22e0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Susan Hares" , "'Kathleen Moriarty'" , "'Eric Rescorla'" Cc: , , , "'mpls-chairs'" , , References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> <25B4902B1192E84696414485F5726854135191D6@sjceml521-mbs.china.huawei.com> <25B4902B1192E84696414485F572685413519209@sjceml521-mbs.china.huawei.com> <002101d35919$c6295b90$527c12b0$@ndzh.com> <041301d35aa1$6b091c30$411b5490$@ndzh.com> Date: Sat, 11 Nov 2017 12:40:15 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.153.236] X-ClientProxiedBy: DB6PR07CA0150.eurprd07.prod.outlook.com (2603:10a6:6:16::43) To HE1PR0701MB3004.eurprd07.prod.outlook.com (2603:10a6:3:4d::10) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b2739d92-6d2f-4b4c-d950-08d52904ce1e X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(2017052603199); SRVR:HE1PR0701MB3004; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3004; 3:j9ByBIitNCA/1KBGF3Bb+B5KYVWUOu6IEsuhVnRB4XLYOClb1GD7pb/2vRzD27LMQS4Xq1uwflljoMcuc4YH3UATudtAA2uFzFbql0KV1FcswxuOR8qaSvfBXdeO32yAPhvyjJkkyw2llJMYc3gQWUW1RpzO5+QvAVq+lGLZKvd0kWD5L7YYDUMKcxlIEhWdD2wSPbyhSCFXGwY2IeoVcaO+cbEQAGkteJqeUhX/s5BanAflhMI75Edrjtw81fXY; 25:pwu9C8RB9MlEAhDUnsVbNw3yFV0PLw+2au+QkbAHDRp43sltHzu5fh+SiVtvzkFjieA2ND1fVicb3fcU+pt1xnjA0U8EaBEq1q42GZcTisnkpHqyBGQi0uVU7eVRyRhTY6pznVdlWykv9/W/hyJXi37dxlicW2JRVbgzjAl9F4Web3p5Vt24Dxn80BM6BcpAPa8Ph53DziRbzBTVgjnc2erxh9PrLTX/O7nAxrmjwqebwuAyRytb5nvH9bGgqZQGC6itw01MIaOZBd/QuTCLODq663kS0RqbiPK9GvEIEiPMeI4Oui6t5SyEN8mxkTXgxHbtFSQKBcunHi2xmSymxw==; 31:16Q7a5Y4BJBrlyaSoQBO94wOlVhBRqzRSQVDeIvZu+HMuVtIVU10fW/Ih8XnduN4fVuqWZZx3z4Cz7W7n0BXYprtP28kFqZBS7Stp2OYrmWlkMn57yC8h04bEsZ3OAWPzh6Q/03pylY/XjARM85lXMpBvgfvYFASHtjtvGjZWNUuisEAX3Gmp0ZF1UJ3U3WTrIOwSeKNB+YyWQB8jHiCXCpZD/lnCMyApjmMoN9AZlw= X-MS-TrafficTypeDiagnostic: HE1PR0701MB3004: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(50582790962513)(155532106045638); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(3231022)(93006095)(93001095)(61426038)(61427038)(6041248)(20161123562025)(20161123558100)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB3004; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB3004; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3004; 4:FBdmsSLSHv5WmsfTZFYaHMfBaPxvef3Qra48XnXbe4FAhYYwqdpRrHcnxzCXt2fX7YRiuDJeIQznjLQrEQFm5cHlZQIxJAajyxeigOUPb6z0m8VnVs5fpxdxBUl/Fo7Eze3RP7/k3A+q8+q4pGn4+27v3UvT8av4DFxrMlq9KG//Vv77VahlyzL8Mm65Ip2ZVT7KAVYOzBRbjUtArYwuyyiEjxi0y4uUjjK3Q/WdAJzk59GkeAfSsehUZn9vsSrUP4FfT95y4IYYmrq5xREpsHqQIfblzE7bE3AHY5nesoIXvAfitBuwWxnzk4/MilF6q8r7Lwx15XSE3RoVBd5SDH+8wzYEbG6ZvdxPrK4XO+dwbcCemUBx4XqshfD/34zv X-Forefront-PRVS: 0488C54DB4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(189002)(24454002)(199003)(13464003)(23676003)(39060400002)(16526018)(84392002)(2870700001)(6306002)(53546010)(316002)(53936002)(86362001)(7736002)(81816999)(6666003)(305945005)(2906002)(4326008)(81686999)(5660300001)(110136005)(93886005)(9686003)(61296003)(54906003)(6116002)(189998001)(15650500001)(3846002)(101416001)(50986999)(76176999)(66066001)(6246003)(116806002)(44716002)(47776003)(106356001)(68736007)(4720700003)(966005)(81166006)(81156014)(8936002)(33646002)(561944003)(6486002)(1456003)(25786009)(105586002)(14496001)(6496005)(97736004)(8676002)(50466002)(1556002)(50226002)(229853002)(44736005)(62236002)(478600001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3004; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3MDFNQjMwMDQ7MjM6b2MzQWIzTEZLbXVGejhRMGJOWWs3T2tI?= =?utf-8?B?VlJKZGp1aXFLc0ZDSVgxOFhidnUxYzBEZDVXYmIrSS9JY1hnRnFtYm1tQkdr?= =?utf-8?B?U3krV2pwWnpMNmc2ZEtBZ2tSYWo0TUIyM1U4ZjV4QlJVWWVsZkN2SjFtSFZ0?= =?utf-8?B?dFJjSXRyQ0NOcHJ1UHpycS8ybjNyR1dqV0hCMFpYRTBTYmQwTXNjUXR3MzZY?= =?utf-8?B?cFpRUzUvYndkU0J4RlZtRU1YbktOSXBPMjRCVENZMHdlTVdsRHowczdyOVFT?= =?utf-8?B?eVIvSFhtd2dDM1h3THBkYjlqMWRBV1JUazVjRy96WUV5SVFicDk5NUhvZ2ti?= =?utf-8?B?Q2NjMG1BRU9pbUFueFhUSEowbk9LVjljNDlYUUpzU0dwYmN4NWFFZ25SZUJP?= =?utf-8?B?U24rL29GRGV3dTkyZFJPSXNQQ1M5TjFPbEk2UVQzMTFTQXYrRVJqUTZIZGxl?= =?utf-8?B?ZWJYR1Rqb05RMWJLTjJTNHNGMFhrNnZycUlSbFdSY21sV1lObGQ0bE9QbDJ0?= =?utf-8?B?b0NhaDdHdDI3Szh0R0RUY1dCcGNUTGFobkV6ZkdraFFqUEhSckpVNkovRzA1?= =?utf-8?B?aTg5N1dndkVMSlNRcVhFa3kvS1AxTVRwdGFha1Q1RzB2REVvdWFCbnN4bnEx?= =?utf-8?B?Vm9jQXEySXI1QS8rTkhWQWhPVzMvaytMbmR3Rk0ycFczUjdSdTBZV3d1bXA1?= =?utf-8?B?VWhablhlZWNlSmNzSHpveWJnNStlSFJ1WlJYaDY1RENxOEg3R1dac0xIV20x?= =?utf-8?B?cFVkdjBHKzEvQmxESzR3a2cyWXNwb0lBcXcyR3lrMUFBQWZhdDJMendyWXVm?= =?utf-8?B?cU5DQTJEUTVjM09sV2xYWDkzQnR4U3lPTU94bExGZDBkMU9VeUEydlV0OXZk?= =?utf-8?B?dVN5eXV0anhvdW5Fb01SWjZ1dTJMRTEzWTlaTW1aSDgvSDZHOTY2K3dEb0wy?= =?utf-8?B?Y1FuNU16aEt4VzYwVitHd0ZyLzZhOWJVU01SMzVPU0hKdC9qa2ZncUUvZkFz?= =?utf-8?B?NnRGcW5qVUI4Mko5ckFjQWV2SlZrYS9nKytxUmtKWEt3Z0JyZk01MW5lWDRG?= =?utf-8?B?aVpsZDNKS0pzRUxZMFBwc1FPbWhLOTlZWnFpTkFPYzFMa1lYOXlpMWl2NGtw?= =?utf-8?B?UElzV1RXTUhmbmFtK0FzbXdCenRsdlFKZisyaC90UE5tN0cwbjJaMXNESWFF?= =?utf-8?B?OGRqNmMrTzV5a1RKMzhyeDkyZlFoU3JEbEgxelZTZFA3b2VOOG42VHJqYm9j?= =?utf-8?B?RFgzeWMraUFvNmJiOTA1V1VsR0liY3hPQndhVHk5ZXhQRjBQTFRNY3JLRUZy?= =?utf-8?B?bGdORm94Q002K1BTS3A4RkV4TzJabXN2VkN2bm9CUzl2Wng1S29hTnRUZCs3?= =?utf-8?B?UnRpdG1la1ZIY0xnYVRFRWhKWUFGTFJSVXEwMHpQTG9mVEovYzA4NGZUZElF?= =?utf-8?B?MC96M2JEQU1sZ1orbmVocTJCL040T0djZlJrUDNwM2d5ekFUbDFTU1dFemkw?= =?utf-8?B?a2xVL0kyS2RmazhtdEY1ZktISHc1bTA3MFVPQmJsc0diTmxKazdVeGVEZm5X?= =?utf-8?B?RjBrbGozc2I0dG1aV2ZGcWFSaTFsR0ZZYUZLbit1czBFRklNRkZjQ0ZxUnZC?= =?utf-8?B?MFM5MTkwMXZFa0tNRGhkYk81djZuTmNBbDZQR3BZSndwOUNLUUVDYkpQaHJ0?= =?utf-8?B?Tk01UnBpeDNqdCt6VFhrSEh1eG54R1pkSlJ5cEJpYUFvL0NWdjZpcHVPU0Jp?= =?utf-8?B?TXBzc0xLN2xIQndUWjVXL1RlVE1XUFNiWXFYS1N5MHNNc3ExRGsvV2VaQ0d6?= =?utf-8?B?UTFCNG4rMVdkb0lLdWRwS3NCUmhMNnJRTmJJZnF5VmphTUlRUHZHZVlVWisr?= =?utf-8?B?VndjeHNRYmpkQjJhTmpEeDFFNVFxM3VyYVpEZ2JyditYWFdFVlhuUGo0K25P?= =?utf-8?B?UUwraGswVDQ2QUVYWUJiMHBhM01qNUVEOXNuWkRpMTQ5R3NWZ2JzQTZBcEFx?= =?utf-8?B?bTdNT2xYbzRUbEx1dWl5NWNLanlUNDRIbjIwV1RqSDNHSkQwdFZlWHEzSHFM?= =?utf-8?B?NDkwZUFBWFlnS2hWczVwOU5SSmhaVGhFVS9pTTB0ODQ1U1VuUEc3ZnRCbUNT?= =?utf-8?Q?fWmi9vSmuFE9kPoVWfTi8+PeY=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3004; 6:ayRC07UEqHeHHa7oWh3DbGuTFjnp3KqI998NFJYcgIfRrbMUbFW/GX/RDR69hzoDg+dcu2QYoia6rGCGW01HuokUoShec6DsllEu2gpW2nxYfsuStp7gfUxUrB8A6s6heTJLa877OL4ztFgeMtuHRlc50rdWpHgyRsiHP8De1KhwqellUIXqZMFkW5+SrGbSY3apZr9Gx3Mwu7aEA4WTmVpf23hgtrIkWVM7NDqiKvUS6XYOheRdFgiG+sP7mftnqoYfdE4E2Y6Co/Pqd2fO+lRaKAekK443v7SWXjQvNKZ3Hw74+DD0ePRXAR3D5EsHQ5jL0uULdiPfv+7EUllkxqK2CBwYZUUDcHgELM8vBvw=; 5:8F+Hmj/Q7QbCm5Yp/ValdxwXxvouZIsJ1q/mmkw/siwnUTEgqu3Lk1qvPXaBB2xQv/qmwOaB5dXDrClhT/Kq2g1o/lRJ8MCehW5W/NMFyNIHaicBBzjJ72KUlnF1Obq6lO7TjUyn0HsGtmhXtPQqbq3Kl0OgrSwFWJs9kSZTJc4=; 24:2iz9yWSSqS/RCveiVUAdU7Y1k2fO3XfYKag1q0gbqu2AiMlvBXyxAQE5cmxitHhw0EgWNNrVFC6tMpo5/UJeBZrVuxqcgAIdDZFePpxCZZA=; 7:nEo5LT5Fi9d2bs1rtdbyySuhoSkLuvy2CGyKYMSMcSf550qynHJeaodZ646QP/GPmtZojT9uXSpJdKXYNxmxNPEAzJVizPJtFuu2pedF58p0jWL0pWkL91GS2+RY2J1pBgpyih9gmOnMrxxjki0t9CEiBt0tZWTCGSTFUq9Ex1b4L+JUeDVwyMXu6P8EOwOG/NQbMUOEp4cBQt/fq6SZWLvuZNwIiOEBLG4WSik+2WQEDml75wWxzbwIjeiGlPXr SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Nov 2017 13:04:54.6123 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b2739d92-6d2f-4b4c-d950-08d52904ce1e X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3004 Archived-At: Subject: Re: [Pals] [mpls] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 13:05:03 -0000 ----- Original Message ----- From: "Susan Hares" Sent: Saturday, November 11, 2017 3:58 AM > Kathleen and Eric: > > I agree that getting linux implementations with TCP-AO is one avenue to drive things into product. Any ideas on getting more deployment for routing security - is really important. Pushing both small and large gains (TCP-AO, registration) will help us continually increase the security. > After a lifetime of trying to forestall disasters, and failing, only to have clients say afterwards 'I wish we had listened to you', my conclusion is that the disaster has to happen first; only then will users be motivated enough to incur the cost, the hassle of changing their ways. I see this with systems and networks, and I hear of just such a case which led to the present level of security being added to BGP. What we should - must - do is ensure that when disaster strikes, and users are motivated, then the specifications are ready; two stalled I-Ds, as was mentioned up-thread, is not ready. Tom Petch > Sue > > -----Original Message----- > From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] > Sent: Thursday, November 9, 2017 3:09 PM > > On Thu, Nov 9, 2017 at 2:09 PM, Eric Rescorla wrote: > > Yeah, I agree. I don't really have any good ideas how to get people to > > do AO. Based on comments I've heard, providers don't see a lot of > > value, rightly or wrongly.... > > I know Alia has been talking about a possible Linux implementation to drive the way. I agree with EKR on other points and have been following along. > > Best, > Kathleen > > > > -Ekr > > > > On Wed, Nov 8, 2017 at 9:15 PM, Susan Hares wrote: > >> > >> Eric: > >> > >> BGP and LDP would be more secure if TCP-AO deployed with all BGP and > >> LDP – but there are issues with customer pick-up and deployment of > >> these protocols on many networks. I wished we had TCP-AO when BGP started, but we did not. > >> > >> Some of the least secure BGP is in data centers – where the DC > >> providers say “It’s all under one administration”. Another problem is on private > >> lines. We should chat about the networks each of these protocols are > >> actually deployed on. If you have any insight on a way to encourage > >> adoption, I’d love to hear it. Require TCP-AO does not really mean > >> anything if providers and Data Centers do not adopt it. > >> > >> Going from SHA-1 to SHA-256 on a TCP-AO is simple upgrade compared to > >> getting people to TCP-AO. > >> > >> Sue > >> > >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla > >> Sent: Wednesday, November 8, 2017 7:44 PM > >> To: Uma Chunduri > >> > >> I don't understand what you're getting at here. Yes, if people have > >> TCP-AO then presumably they have SHA-1. > >> > >> But now we're talking about requiring people to have TCP-AO in this > >> case, so we should try to move them to SHA-256 at the time we require AO. > >> > >> -Ekr > >> > >> On Wed, Nov 8, 2017 at 4:14 PM, Uma Chunduri > >> > >> wrote: > >> > >> From: Eric Rescorla [mailto:ekr@rtfm.com] > >> Sent: Wednesday, November 08, 2017 3:53 PM > >> > >> To: Uma Chunduri > >> > >> On Wed, Nov 8, 2017 at 3:50 PM, Uma Chunduri > >> > >> wrote: > >> > >> In-line [Uma1]: > >> > >> Uma C. > >> > >> > >> From: Eric Rescorla [mailto:ekr@rtfm.com] > >> Sent: Wednesday, November 08, 2017 12:53 PM > >> > >> On Wed, Nov 8, 2017 at 11:57 AM, Uma Chunduri > >> > >> wrote: > >> > >> Hi Stewart, > >> > >> I would note https://tools.ietf.org/html/rfc6952 - where LDP security > >> is analyzed from all aspects. > >> > >> Eric, > >> > >> Quick comments below [Uma]: > >> > >> Uma C. > >> > >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla > >> Sent: Wednesday, November 08, 2017 10:00 AM > >> > >> Hi Stewart > >> > >> Thanks for your note. > >> > >> My overall sense of the state of play is, I think much like yours. > >> > >> TCP-MD5 is inadequate in two major respects: > >> > >> - It uses weak algorithms > >> > >> - It has a bad negotiation/setuop story (manual key management) > >> > >> TCP-AO is intended to be a drop-in replacement for TCP-MD5 and so > >> remedies the algorithm > >> > >> Issue > >> > >> [Uma]: Yes, if we go with RFC 5926 mandatory list.. > >> > >> but not the key management issue [0]. We haven't made much progress > >> on the key > >> > >> management story, and that seems to be a major impediment to > >> deploying either of these > >> > >> technologies (which I am given to understand don't see a lot of use). > >> > >> [Uma]: True. > >> > >> But I would indicate some effort done few years back > >> regarding key management for pair wise routing protocols (BGP, LDP, > >> PCEP, MSDP ..). > >> > >> One such proposal is by extending IKEv2 to negotiate > >> TCP-AO MKTs (which can give rekey & algo. agility) - > >> https://tools.ietf.org/html/draft-mahesh-karp-rkmp-05 > >> > >> This also requires some more work with TCP-AO; me & > >> Joe put together > >> https://www.ietf.org/archive/id/draft-chunduri-karp-using-ikev2-with- > >> tcp-ao-06.txt > >> > >> Note the above didn’t progress in the concluded KARP WG > >> (not fully sure the reasons on why). > >> > >> Yeah, I know that people tried to do this, but my impression was it > >> kinda didn't progress much. > >> > >> We should probably talk in Singapore about that, but that's not going > >> to get better any time soon. > >> > >> In the interim, I think the text you have is OK, and "TBD" should > >> read "SHA-256", with > >> > >> the fallback being SHA-256 -> SHA-1 -> MD5. > >> > >> [Uma]: While the list can be extended - I didn’t see SHA256 in the > >> mandatory list in RFC 5926 for MAC. > >> > >> Generally we're trying to move away from SHA-1 towards SHA-256. > >> > >> [Uma1]: Couple of things: > >> > >> 1. Nothing to be done (from spec pov of course): Use TCP-AO (instead > >> of current MD5) with the RFC 5926 mandated MACs/KDFs – so the ‘TBD’ > >> in Stewart suggesting below is already there. > >> > >> 2. As #1 too is not good enough from your above note - do SHA-256 > >> and live with it (no algorithm agility). Still a security benefit in > >> one way from existing stuff or even #1. > >> > >> I'm not sure why you say "no algorithm agility". You'd be using AO, > >> just with a different algorithm than SHA-1. AES-CMAC is still fine as > >> far as I know. > >> > >> [Uma2]: Sure, you have it, if you use AO; > >> > >> But then I am not getting how we can mandate one > >> MUST implement algorithm as suggested below TBD would actually work > >> (especially > >> - *if* #1 is already deployed somewhere?) > >> > >> Perhaps staying with #1 is the best bet or do > >> negotiation through #3, with already mandated and additional stuff. > >> > >> -Ekr > >> 3. Do key management and “theoretically” get all we wanted…. > >> > >> We have been here multiple times; because #1 itself is not *mostly* > >> deployed (neither in BGP nor in LDP) if there is any appetite for #2 > >> and #3 for practical deployments. But still it may be good to do #2 any ways. > >> > >> -Ekr > >> > >> -Ekr > >> > >> [0] Technically It has better support for rollover, but this is not a > >> huge improvement. > >> > >> [1] tcpcrypt is kind of orthogonal here as it's unauthenticated but > >> opportunistic. That said, > >> > >> it would provide defense against attackers who gain access to the > >> link after connection > >> > >> setup and doesn't require configuration. > >> > >> On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant > >> wrote: > >> > >> To the SEC and RTG ADs, > >> > >> I am sending the following message on behalf of the MPLS and the PALS > >> WG Chairs. > >> > >> There is a concern shared among the security community and the > >> working groups that develop the LDP protocol that LDP is no longer > >> adequately secured. LDP currently relies on MD5 for cryptographic > >> security of its messages, but MD5 is a hash function that is no > >> longer considered to meet current security requirements. > >> > >> In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2. > >> Session communication carried by TCP the following statements is made: > >> > >> "LDP specifies use of the TCP MD5 Signature Option to provide for the > >> authenticity and integrity of session messages. > >> > >> "[RFC2385] asserts that MD5 authentication is now considered by some > >> to be too weak for this application. It also points out that a > >> similar TCP option with a stronger hashing algorithm (it cites SHA-1 > >> as an example) could be deployed. To our knowledge, no such TCP > >> option has been defined and deployed. However, we note that LDP can > >> use whatever TCP message digest techniques are available, and when > >> one stronger than MD5 is specified and implemented, upgrading LDP to use it would be relatively straightforward." > >> > >> We note that BGP has already been through this process, and replaced > >> MD5 with TCP-AO in RFC 7454. I would be logical to follow the same > >> approach to secure LDP. However, as far as we are able to ascertain, > >> there is currently no recommended, mandatory to implement, > >> cryptographic function specified. We are concerned that without such > >> a mandatory function, implementations will simply fall back to MD5 > >> and we will be no further forward > >> > >> We think that the best way forward is to publish a draft similar to > >> RFC > >> 7454 that contains the following requirement: > >> > >> "Implementations conforming to this RFC MUST implement TCP-AO to > >> secure the TCP sessions carrying LDP in addition to the currently > >> required TCP MD5 Signature Option. Furthermore, the TBD cryptographic > >> mechanism must be implemented and provided to TCP-AO to secure LDP > >> messages. The TBD mechanism is the preferred option, and MD5 is only > >> to be used when TBD is unavailable." > >> > >> We are not an experts on this part of the stack, but it seems that > >> TCP security negotiation is still work in progress. If we are wrong, > >> then we need to include a requirement that such negotiation is also > >> required. In the absence of a negotiation protocol, however, we need > >> to leave this as a configuration process until such time as the > >> negotiation protocol work is complete. On completion of a suitable > >> negotiation protocol we need to issue a further update requiring its use. > >> > >> Additionally we should note that no cryptographic mechanism has an > >> indefinite lifetime, and that implementation should note the IETF > >> anticipates updating the default cryptographic mechanism over time. > >> > >> The TBD default security function will need to be chosen such that it > >> can reasonably be implemented on a typical router route processor, > >> and which will provide adequate security without significantly > >> degrading the convergence time of an LSR. Without a function that > >> does not significantly impact router convergence we simply close one > >> vulnerability and open another. > >> > >> As experts on the LDP protocol, but not on security mechanisms, we > >> need to ask the security area for a review of our proposed approach, > >> and help correcting any misunderstanding of the security issues or > >> our misunderstanding of the existing security mechanisms. We also > >> need the recommendations of a suitable security function (TBD in the above text). > >> > >> Best regards > >> > >> The MPLS WG Chairs > >> The PALS WG Chairs From nobody Sat Nov 11 11:53:48 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5621204DA; Sat, 11 Nov 2017 11:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=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 u8iM5bdR7yRm; Sat, 11 Nov 2017 11:53:38 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 BF15912008A; Sat, 11 Nov 2017 11:53:37 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.157.12; From: "Susan Hares" To: "'t.petch'" , "'Kathleen Moriarty'" , "'Eric Rescorla'" Cc: , , , "'mpls-chairs'" , , References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> <25B4902B1192E84696414485F5726854135191D6@sjceml521-mbs.china.huawei.com> <25B4902B1192E84696414485F572685413519209@sjceml521-mbs.china.huawei.com> <002101d35919$c6295b90$527c12b0$@ndzh.com> <041301d35aa1$6b091c30$411b5490$@ndzh.com> <01a d01d35aed$421b 22e0$4001a8c0@gateway.2wire.net> In-Reply-To: <01ad01d35aed$421b22e0$4001a8c0@gateway.2wire.net> Date: Sat, 11 Nov 2017 14:53:27 -0500 Message-ID: <006901d35b26$c0b68bb0$4223a310$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHQ4LkDJ6Z/J5TaTb+XshLIa/JnkwDS4NRaArJJq9UCaLaHAwHaa4uIAisdFYUDZZ2angL1Eio4AmoE+CkB9qhtqQIhLmPlAYxUip4CB6YK8gLMBRZxARAbLucBVGQL8wHtQw4Eogh8sgA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Pals] [mpls] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 19:53:41 -0000 Tom: +1. Wise words. My father-in-law gave this same advice to the = researchers at Corning. Their projects - such as fiber optics went from = "prototypes" to massive deployments with aid from standards + = appropriate fixes. =20 Sue=20 -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com]=20 Sent: Saturday, November 11, 2017 7:40 AM To: Susan Hares; 'Kathleen Moriarty'; 'Eric Rescorla' Cc: mpls@ietf.org; pals-chairs@tools.ietf.org; rtg-ads@ietf.org; = 'mpls-chairs'; pals@ietf.org; sec-ads@ietf.org Subject: Re: [mpls] LDP Security ----- Original Message ----- From: "Susan Hares" Sent: Saturday, November 11, 2017 3:58 AM > Kathleen and Eric: > > I agree that getting linux implementations with TCP-AO is one avenue to drive things into product. Any ideas on getting more deployment for routing security - is really important. Pushing both small and large gains (TCP-AO, registration) will help us continually increase the = security. > After a lifetime of trying to forestall disasters, and failing, only to = have clients say afterwards 'I wish we had listened to you', my = conclusion is that the disaster has to happen first; only then will = users be motivated enough to incur the cost, the hassle of changing = their ways. I see this with systems and networks, and I hear of just such a case = which led to the present level of security being added to BGP. What we should - must - do is ensure that when disaster strikes, and = users are motivated, then the specifications are ready; two stalled = I-Ds, as was mentioned up-thread, is not ready. Tom Petch > Sue > > -----Original Message----- > From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] > Sent: Thursday, November 9, 2017 3:09 PM > > On Thu, Nov 9, 2017 at 2:09 PM, Eric Rescorla wrote: > > Yeah, I agree. I don't really have any good ideas how to get people to > > do AO. Based on comments I've heard, providers don't see a lot of=20 > > value, rightly or wrongly.... > > I know Alia has been talking about a possible Linux implementation to drive the way. I agree with EKR on other points and have been following = along. > > Best, > Kathleen > > > > -Ekr > > > > On Wed, Nov 8, 2017 at 9:15 PM, Susan Hares wrote: > >> > >> Eric: > >> > >> BGP and LDP would be more secure if TCP-AO deployed with all BGP and > >> LDP =E2=80=93 but there are issues with customer pick-up and = deployment of=20 > >> these protocols on many networks. I wished we had TCP-AO when BGP started, but we did not. > >> > >> Some of the least secure BGP is in data centers =E2=80=93 where the = DC=20 > >> providers say =E2=80=9CIt=E2=80=99s all under one = administration=E2=80=9D. Another problem is on private > >> lines. We should chat about the networks each of these protocols are > >> actually deployed on. If you have any insight on a way to encourage > >> adoption, I=E2=80=99d love to hear it. Require TCP-AO does not = really mean=20 > >> anything if providers and Data Centers do not adopt it. > >> > >> Going from SHA-1 to SHA-256 on a TCP-AO is simple upgrade compared to > >> getting people to TCP-AO. > >> > >> Sue > >> > >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla > >> Sent: Wednesday, November 8, 2017 7:44 PM > >> To: Uma Chunduri > >> > >> I don't understand what you're getting at here. Yes, if people have = > >> TCP-AO then presumably they have SHA-1. > >> > >> But now we're talking about requiring people to have TCP-AO in this = > >> case, so we should try to move them to SHA-256 at the time we require AO. > >> > >> -Ekr > >> > >> On Wed, Nov 8, 2017 at 4:14 PM, Uma Chunduri=20 > >> > >> wrote: > >> > >> From: Eric Rescorla [mailto:ekr@rtfm.com] > >> Sent: Wednesday, November 08, 2017 3:53 PM > >> > >> To: Uma Chunduri > >> > >> On Wed, Nov 8, 2017 at 3:50 PM, Uma Chunduri=20 > >> > >> wrote: > >> > >> In-line [Uma1]: > >> > >> Uma C. > >> > >> > >> From: Eric Rescorla [mailto:ekr@rtfm.com] > >> Sent: Wednesday, November 08, 2017 12:53 PM > >> > >> On Wed, Nov 8, 2017 at 11:57 AM, Uma Chunduri=20 > >> > >> wrote: > >> > >> Hi Stewart, > >> > >> I would note https://tools.ietf.org/html/rfc6952 - where LDP security > >> is analyzed from all aspects. > >> > >> Eric, > >> > >> Quick comments below [Uma]: > >> > >> Uma C. > >> > >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla > >> Sent: Wednesday, November 08, 2017 10:00 AM > >> > >> Hi Stewart > >> > >> Thanks for your note. > >> > >> My overall sense of the state of play is, I think much like yours. > >> > >> TCP-MD5 is inadequate in two major respects: > >> > >> - It uses weak algorithms > >> > >> - It has a bad negotiation/setuop story (manual key management) > >> > >> TCP-AO is intended to be a drop-in replacement for TCP-MD5 and so=20 > >> remedies the algorithm > >> > >> Issue > >> > >> [Uma]: Yes, if we go with RFC 5926 mandatory list.. > >> > >> but not the key management issue [0]. We haven't made much progress = > >> on the key > >> > >> management story, and that seems to be a major impediment to=20 > >> deploying either of these > >> > >> technologies (which I am given to understand don't see a lot of use). > >> > >> [Uma]: True. > >> > >> But I would indicate some effort done few years back = > >> regarding key management for pair wise routing protocols (BGP, LDP, = > >> PCEP, MSDP ..). > >> > >> One such proposal is by extending IKEv2 to negotiate = > >> TCP-AO MKTs (which can give rekey & algo. agility) - > >> https://tools.ietf.org/html/draft-mahesh-karp-rkmp-05 > >> > >> This also requires some more work with TCP-AO; me &=20 > >> Joe put together > >> https://www.ietf.org/archive/id/draft-chunduri-karp-using-ikev2-with- > >> tcp-ao-06.txt > >> > >> Note the above didn=E2=80=99t progress in the concluded = KARP WG=20 > >> (not fully sure the reasons on why). > >> > >> Yeah, I know that people tried to do this, but my impression was it = > >> kinda didn't progress much. > >> > >> We should probably talk in Singapore about that, but that's not going > >> to get better any time soon. > >> > >> In the interim, I think the text you have is OK, and "TBD" should=20 > >> read "SHA-256", with > >> > >> the fallback being SHA-256 -> SHA-1 -> MD5. > >> > >> [Uma]: While the list can be extended - I didn=E2=80=99t see SHA256 = in the=20 > >> mandatory list in RFC 5926 for MAC. > >> > >> Generally we're trying to move away from SHA-1 towards SHA-256. > >> > >> [Uma1]: Couple of things: > >> > >> 1. Nothing to be done (from spec pov of course): Use TCP-AO (instead > >> of current MD5) with the RFC 5926 mandated MACs/KDFs =E2=80=93 so = the =E2=80=98TBD=E2=80=99 > >> in Stewart suggesting below is already there. > >> > >> 2. As #1 too is not good enough from your above note - do SHA-256 > >> and live with it (no algorithm agility). Still a security benefit in > >> one way from existing stuff or even #1. > >> > >> I'm not sure why you say "no algorithm agility". You'd be using AO, = > >> just with a different algorithm than SHA-1. AES-CMAC is still fine as > >> far as I know. > >> > >> [Uma2]: Sure, you have it, if you use AO; > >> > >> But then I am not getting how we can mandate one=20 > >> MUST implement algorithm as suggested below TBD would actually work > >> (especially > >> - *if* #1 is already deployed somewhere?) > >> > >> Perhaps staying with #1 is the best bet or do=20 > >> negotiation through #3, with already mandated and additional stuff. > >> > >> -Ekr > >> 3. Do key management and =E2=80=9Ctheoretically=E2=80=9D get = all we wanted=E2=80=A6. > >> > >> We have been here multiple times; because #1 itself is not *mostly* = > >> deployed (neither in BGP nor in LDP) if there is any appetite for #2 > >> and #3 for practical deployments. But still it may be good to do #2 any ways. > >> > >> -Ekr > >> > >> -Ekr > >> > >> [0] Technically It has better support for rollover, but this is not a > >> huge improvement. > >> > >> [1] tcpcrypt is kind of orthogonal here as it's unauthenticated but = > >> opportunistic. That said, > >> > >> it would provide defense against attackers who gain access to the=20 > >> link after connection > >> > >> setup and doesn't require configuration. > >> > >> On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant=20 > >> wrote: > >> > >> To the SEC and RTG ADs, > >> > >> I am sending the following message on behalf of the MPLS and the PALS > >> WG Chairs. > >> > >> There is a concern shared among the security community and the=20 > >> working groups that develop the LDP protocol that LDP is no longer=20 > >> adequately secured. LDP currently relies on MD5 for cryptographic=20 > >> security of its messages, but MD5 is a hash function that is no=20 > >> longer considered to meet current security requirements. > >> > >> In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2. > >> Session communication carried by TCP the following statements is made: > >> > >> "LDP specifies use of the TCP MD5 Signature Option to provide for the > >> authenticity and integrity of session messages. > >> > >> "[RFC2385] asserts that MD5 authentication is now considered by some > >> to be too weak for this application. It also points out that a=20 > >> similar TCP option with a stronger hashing algorithm (it cites SHA-1 > >> as an example) could be deployed. To our knowledge, no such TCP=20 > >> option has been defined and deployed. However, we note that LDP can > >> use whatever TCP message digest techniques are available, and when=20 > >> one stronger than MD5 is specified and implemented, upgrading LDP to use it would be relatively straightforward." > >> > >> We note that BGP has already been through this process, and replaced > >> MD5 with TCP-AO in RFC 7454. I would be logical to follow the same=20 > >> approach to secure LDP. However, as far as we are able to ascertain, > >> there is currently no recommended, mandatory to implement,=20 > >> cryptographic function specified. We are concerned that without such > >> a mandatory function, implementations will simply fall back to MD5=20 > >> and we will be no further forward > >> > >> We think that the best way forward is to publish a draft similar to = > >> RFC > >> 7454 that contains the following requirement: > >> > >> "Implementations conforming to this RFC MUST implement TCP-AO to=20 > >> secure the TCP sessions carrying LDP in addition to the currently=20 > >> required TCP MD5 Signature Option. Furthermore, the TBD cryptographic > >> mechanism must be implemented and provided to TCP-AO to secure LDP=20 > >> messages. The TBD mechanism is the preferred option, and MD5 is only > >> to be used when TBD is unavailable." > >> > >> We are not an experts on this part of the stack, but it seems that=20 > >> TCP security negotiation is still work in progress. If we are wrong, > >> then we need to include a requirement that such negotiation is also = > >> required. In the absence of a negotiation protocol, however, we need > >> to leave this as a configuration process until such time as the=20 > >> negotiation protocol work is complete. On completion of a suitable=20 > >> negotiation protocol we need to issue a further update requiring its use. > >> > >> Additionally we should note that no cryptographic mechanism has an=20 > >> indefinite lifetime, and that implementation should note the IETF=20 > >> anticipates updating the default cryptographic mechanism over time. > >> > >> The TBD default security function will need to be chosen such that it > >> can reasonably be implemented on a typical router route processor,=20 > >> and which will provide adequate security without significantly=20 > >> degrading the convergence time of an LSR. Without a function that=20 > >> does not significantly impact router convergence we simply close one > >> vulnerability and open another. > >> > >> As experts on the LDP protocol, but not on security mechanisms, we=20 > >> need to ask the security area for a review of our proposed approach, > >> and help correcting any misunderstanding of the security issues or=20 > >> our misunderstanding of the existing security mechanisms. We also=20 > >> need the recommendations of a suitable security function (TBD in the above text). > >> > >> Best regards > >> > >> The MPLS WG Chairs > >> The PALS WG Chairs From nobody Sat Nov 11 19:25:21 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAB4129AE0; Sat, 11 Nov 2017 08:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 Gm13uByixGD0; Sat, 11 Nov 2017 08:06:33 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 51C58129AD3; Sat, 11 Nov 2017 08:06:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject: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=THq4yJ1i1UPAJTmetmY3JgurTeQBAAJ+K1GJ9W5g++Q=; b=0aonypU5cNajRm8ckHw3HLvV3Q 909eDHlsCjTduo1GTSzIKFZfoOxG9aXPrWhojbkKOgqgBeCtFwCN3XjDaJgPT33VW3soI6p3UhLsP OjquC1Xh5FiNH3WfuVRzwqzF8nF42jDA21qjX1neHoJlhBLNDM7q4XHc/Y0K8SREfRKEg8Y+TUHnj H8qQMi8EawO3NPq33DLY/TvQM0c00Az6v8ATL+SF6PooQgfsYSb/08CrKe8aBvSQe+JovG7IpnWSl puUzyC0TB7AG1x5ipxedYbOaVjApEEQ+d7rW/cWYdk+kwqKabdZfeDkLhH66OQd5S3RSL009fWz1g jEo+U24A==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:63379 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eDYIg-000PaV-V1; Sat, 11 Nov 2017 11:06:31 -0500 To: Jeff Tantsura Cc: "mpls@ietf.org" , Eric Rescorla , "tcpm@ietf.org" , "pals-chairs@tools.ietf.org" , "" , "mpls-chairs@ietf.org" , "pals@ietf.org" , Stewart Bryant , "" References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> <4f634e7c-f3b9-f0ab-abc7-80ec1062b52a@strayalpha.com> <697AC959-60C2-401D-9E64-D88E16F35EBB@gmail.com> From: Joe Touch Message-ID: <798b8e6a-5964-a364-9e43-4520f4430793@strayalpha.com> Date: Sat, 11 Nov 2017 08:06:25 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <697AC959-60C2-401D-9E64-D88E16F35EBB@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: X-Mailman-Approved-At: Sat, 11 Nov 2017 19:25:20 -0800 Subject: Re: [Pals] [tcpm] [mpls] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 16:06:34 -0000 On 11/10/2017 7:11 PM, Jeff Tantsura wrote: > Joe, > > There’s no problem with updating, the problem is with adoption... Sure, but I hope designing a new solution isn't assumed to be the best way to achieve that. tcpinc showed that it's easy to get it wrong (it may provide help to TCP content, but "TCP security" it isn't). Joe From nobody Sat Nov 11 19:25:26 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3954124239; Sat, 11 Nov 2017 12:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=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 1SPWSXI2t750; Sat, 11 Nov 2017 12:46:11 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 2E56E1200B9; Sat, 11 Nov 2017 12:46:11 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.157.12; From: "Susan Hares" To: "'Joe Touch'" , "'Jeff Tantsura'" Cc: , "'Eric Rescorla'" , , , , , , References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> <4f634e7c-f3b9-f0ab-abc7-80ec1062b52a@strayalpha.com> <697AC959-60C2-401D-9E64-D88E16F35EBB@gmail.com> <798b8e6 a-5964-a364-9e 43-4520f4430793@strayalpha.com> In-Reply-To: <798b8e6a-5964-a364-9e43-4520f4430793@strayalpha.com> Date: Sat, 11 Nov 2017 15:45:56 -0500 Message-ID: <001401d35b2e$1559db70$400d9250$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHQ4LkDJ6Z/J5TaTb+XshLIa/JnkwGkQiT3AY0bhdsBndke1AMFAIO+ARBf2LkCdM8cTgI5zEjPANLg1FoCskmr1QJotocDAdpri4gCKx0VhQNlnZqeAl3ROVgCo0BnMAGzT1xmAe6o4WOh+B8gYA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Sat, 11 Nov 2017 19:25:20 -0800 Subject: Re: [Pals] [mpls] [tcpm] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 20:46:13 -0000 Joe:=20 No - the mentioning of deployment issues was just background on = discussion and an expression of my personal angst on this topic.=20 Sue Hares=20 -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Joe Touch Sent: Saturday, November 11, 2017 11:06 AM To: Jeff Tantsura Cc: mpls@ietf.org; Eric Rescorla; tcpm@ietf.org; = pals-chairs@tools.ietf.org; ; mpls-chairs@ietf.org; = pals@ietf.org; Subject: Re: [mpls] [tcpm] LDP Security On 11/10/2017 7:11 PM, Jeff Tantsura wrote: > Joe, > > There=E2=80=99s no problem with updating, the problem is with = adoption... Sure, but I hope designing a new solution isn't assumed to be the best = way to achieve that. tcpinc showed that it's easy to get it wrong (it = may provide help to TCP content, but "TCP security" it isn't). Joe _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Sun Nov 12 18:21:16 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9381243FE; Sun, 12 Nov 2017 18:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onevmw.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 nrUre40_M6xa; Sun, 12 Nov 2017 18:21:12 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0047.outbound.protection.outlook.com [104.47.34.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCDF21241F5; Sun, 12 Nov 2017 18:21:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Q2PxAfFxdZzl5vXAxCjDYQd1PphvvjnNTdrT++jd+EE=; b=CDJSRzSvWX7S+hPlTix6NrnIsW2jCZQ0tlIQZOWoD2A3R4q8/qsRVyqswm0KP6+JN/cz2NLptE/Z5GXF6a4IdYpISfFol3Cm3uuixXpJhcpdzXSPySvywqxt+pRbzbvqNKrHQfbw6YyuksxVdXCx0vOvTElU8Aswi7Ove4Hroyk= Received: from MWHPR05MB3389.namprd05.prod.outlook.com (10.174.175.150) by MWHPR05MB3390.namprd05.prod.outlook.com (10.174.175.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.239.4; Mon, 13 Nov 2017 02:21:10 +0000 Received: from MWHPR05MB3389.namprd05.prod.outlook.com ([10.174.175.150]) by MWHPR05MB3389.namprd05.prod.outlook.com ([10.174.175.150]) with mapi id 15.20.0239.004; Mon, 13 Nov 2017 02:21:10 +0000 From: Sami Boutros To: Suresh Krishnan , The IESG CC: "draft-ietf-pals-p2mp-pw@ietf.org" , Stewart Bryant , "pals-chairs@ietf.org" , "pals@ietf.org" Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-pals-p2mp-pw-03: (with DISCUSS and COMMENT) Thread-Index: AQHTIfWJxL/EWMIJk0OSrpx4+O4vbqMRghqA Date: Mon, 13 Nov 2017 02:21:10 +0000 Message-ID: <2127F0E0-4880-4555-85EE-13A0EC9AD965@vmware.com> References: <150414165129.16888.245048756650963482.idtracker@ietfa.amsl.com> In-Reply-To: <150414165129.16888.245048756650963482.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sboutros@vmware.com; x-originating-ip: [2001:67c:1232:144:ed1e:a2fb:69b1:a6af] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR05MB3390; 20:zTQvD+t+Iiigv6IPhLvfEwUoOJ7UUNrE9isf2eNy6d0vJqoawLntfgTdPEHyfG1oL+vi6HPxiMGVqSFZcnIT5shEbQwRcrGgqp5aMApIZZ33K7xCYG/ogPJ9UrqlV3r0NMIzhpre6TGyDpxGmA6u8Mz6d5ldk7QQzE7400YAXHI= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 171eaab7-6f41-4293-6fbd-08d52a3d3462 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:MWHPR05MB3390; x-ms-traffictypediagnostic: MWHPR05MB3390: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3231022)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR05MB3390; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR05MB3390; x-forefront-prvs: 0490BBA1F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(199003)(189002)(68736007)(6116002)(8936002)(305945005)(83716003)(2950100002)(6506006)(229853002)(7736002)(81166006)(50986999)(77096006)(76176999)(54356999)(6486002)(6436002)(189998001)(97736004)(102836003)(2900100001)(3280700002)(54906003)(99286004)(53936002)(2906002)(230783001)(316002)(6306002)(8676002)(5890100001)(110136005)(82746002)(4326008)(81156014)(6246003)(25786009)(3660700001)(575784001)(478600001)(33656002)(5660300001)(86362001)(106356001)(101416001)(105586002)(39060400002)(14454004)(6512007)(36756003)(440344003); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR05MB3390; H:MWHPR05MB3389.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: vmware.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-Network-Message-Id: 171eaab7-6f41-4293-6fbd-08d52a3d3462 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 02:21:10.2562 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3390 Archived-At: Subject: Re: [Pals] Suresh Krishnan's Discuss on draft-ietf-pals-p2mp-pw-03: (with DISCUSS and COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 02:21:14 -0000 SGkgU3VyZXNoLA0KDQpQbGVhc2Ugc2VlIGNvbW1lbnRzIGlubGluZSBTYW1pOg0KDQoNCg0KVGhh bmtzLA0KDQpTYW1pDQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPkRJU0NVU1M6DQo+LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Pg0KPiogU2VjdGlvbiA3LjMuIG1MRFAgT3BhcXVlIFZhbHVlIEVsZW1lbnQgVExWIFR5cGUNCj4N Cj4+RnJvbSBteSByZWFkaW5nIG9mIFJGQzYzODgsIHRoZSAiVmFsdWUiIGluIHRoZSBUTFYgdHlw ZSBpcyBpbnRlcnByZXRlZCBiYXNlZCBvbg0KPnRoZSB0eXBlIGFuZCB0aGlzIGRvY3VtZW50IGRv ZXMgbm90IHNlZW0gdG8gc3BlY2lmeSB3aGF0IGdvZXMgaW50byB0aGUgdmFsdWUuDQo+DQo+QWRk aXRpb25hbGx5LCB0aGUgZG9jdW1lbnQgcmVxdWVzdHMgdGhlIHR5cGUgIjB4MyIgYnV0IGl0IGxv b2tzIGxpa2UgdGhhdCB0eXBlDQo+aGFzIGJlZW4gYWxsb2NhdGVkIGFscmVhZHkgdG8gIlRyYW5z aXQgSVB2NCBTb3VyY2UgVExWIHR5cGUiIGFzIHBlcg0KPg0KPmh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlhbmEub3JnX2Fzc2lnbm1lbnRz X2xkcC0yRG5hbWVzcGFjZXNfbGRwLTJEbmFtZXNwYWNlcy54aHRtbC0yM2xkcC0yRG5hbWVzcGFj ZXMtMkQxMSZkPUR3SUNhUSZjPXVpbGFLOTBENFRPVm9INThKTlhSZ1Emcj1JVnpjVFJMUWRwdGEw OEwwYl95MnpEa3F2d0poUktNQ0FiWC0ySy1MVjk4Jm09MExTUU1MZ0lQbDBNMlhMQ3RJZVI4MmVy MERiODYzVzh6TVMwcGwwOVhjcyZzPTFMUzExR1hrc0ZuYlJmc0VxWHRHbHJWX3E3NWM1X1V1SWw2 eUIta2tqaEEmZT0gDQo+DQoNClNhbWk6DQpJIGNoYW5nZWQgdGhlIHNlY3Rpb24gdG8gdGhlIGZv bGxvd2luZzoNCg0KICBUaGlzIGRvY3VtZW50IHJlcXVpcmVzIGFsbG9jYXRpb24gb2YgYSBuZXcg bUxEUCBPcGFxdWUgVmFsdWUgRWxlbWVudA0KICAgVHlwZSBmcm9tICJMRFAgTVAgT3BhcXVlIFZh bHVlIEVsZW1lbnQgYmFzaWMgdHlwZSIgbmFtZSBzcGFjZSBkZWZpbmVkDQogICBpbiBbUkZDNjM4 OF0uDQoNCiAgIFRoZSBmb2xsb3dpbmcgdmFsdWUgaXMgc3VnZ2VzdGVkIGZvciBhc3NpZ25tZW50 Og0KDQogICAgICAgICBUTFYgdHlwZSAgRGVzY3JpcHRpb24NCiAgICAgICAgICAgMTMgICAgICBM MlZQTi1NQ0FTVCBhcHBsaWNhdGlvbiBUTFYNCg0KICAgICAgICAgTGVuZ3RoOiAgNA0KDQogICAg ICAgICBWYWx1ZTogIEEgMzItYml0IGludGVnZXIsIHVuaXF1ZSBpbiB0aGUgY29udGV4dCBvZiB0 aGUgcm9vdCwgYXMNCiAgICAgICAgIGlkZW50aWZpZWQgYnkgdGhlIHJvb3QncyBhZGRyZXNzLg0K DQpTYW1pOg0KDQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPkNPTU1FTlQ6DQo+LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Pg0KPiogSSB0aGluayB0aGVyZSBpcyBhIHR5cG8gaW4gRmlndXJlIDIuDQo+DQo+VGhlICJBSUkg VHlwZSIgZmllbGQgc2hvdWxkIGJlIGxhYmVsZWQgIlNBSUkgVHlwZSIgaW5zdGVhZA0KDQpTYW1p Og0KDQpObywgdGhpcyBpcyBjb3JyZWN0LCBhdHRhY2htZW50IGluZGl2aWR1YWwgaWRlbnRpZmll cnMgQUlJIHR5cGUgMSBvciB0eXBlIDIgaWRlbnRpZmllcyBhIFNBSUkgb3IgYSBUQUlJLg0KDQpT YW1pOg0KDQoNCj4qIFdoeSBpcyB0aGUgUFcgdHlwZSByZWZlcmVuY2luZyBSRkM0NDQ3IHdoZW4g dGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50IHJlZmVycw0KPnNvbGVseSB0byBSRkM0NDQ3YmlzPyBJ cyB0aGlzIGludGVudGlvbmFsIG9yIGEgbWlzdGFrZT8NCg0KU2FtaTogRml4ZWQuDQo+DQo+Iiog UFcgVHlwZTogMTUgYml0cyByZXByZXNlbnRhdGlvbiBvZiBQVyB0eXBlIGFzIHNwZWNpZmllZCBp biBbUkZDNDQ0N10uIg0KPg0KPiogVGhlIHRlcm0gIlBNU0kgVHVubmVsIGluZm8iIGlzIHVzZWQg d2l0aG91dCBiZWluZyBkZWZpbmVkIGFuZCBpcyByZXF1aXJlZCB0bw0KPmNhbGN1bGF0ZSB0aGUg bGVuZ3RoLiBJIGFtIGd1ZXNzaW5nICJQTVNJIFR1bm5lbCBpbmZvIiBtZWFucyB0aGUgY29tYmlu YXRpb24gb2YNCj5QTVNJIFR1bm5lbCBUeXBlLCBMZW5ndGggYW5kIFRyYW5zcG9ydCBMU1AgSUQu IElmIHRoaXMgaXMgc28sIHBsZWFzZSBtYWtlIGl0DQo+ZXhwbGljaXQgYW5kIGRlZmluZS4gSWYg bm90LCBjbGFyaWZ5Lg0KDQpTYW1pOiBTdXJlIHdpbGwgc2F5IHRoYXQgaW4gdGhlIG5leHQgcmV2 LA0KDQpUaGFua3MsDQoNClNhbWkNCj4NCj4NCg== From nobody Sun Nov 12 18:36:19 2017 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 266881271DF; Sun, 12 Nov 2017 18:36:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pals@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151054057911.21474.3553241734210378785@ietfa.amsl.com> Date: Sun, 12 Nov 2017 18:36:19 -0800 Archived-At: Subject: [Pals] I-D Action: draft-ietf-pals-p2mp-pw-04.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 02:36:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire And LDP-enabled Services WG of the IETF. Title : Signaling Root-Initiated Point-to-Multipoint Pseudowire using LDP Authors : Sami Boutros Siva Sivabalan Filename : draft-ietf-pals-p2mp-pw-04.txt Pages : 17 Date : 2017-11-12 Abstract: This document specifies a mechanism to signal Point-to-Multipoint (P2MP) Pseudowires (PW) tree using LDP. Such a mechanism is suitable for any Layer 2 VPN service requiring P2MP connectivity over an IP or MPLS enabled PSN. A P2MP PW established via the proposed mechanism is root initiated. This document updates RFC7385 by re-assigning reserved value 0xFF to be the wildcard transport tunnel type. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-p2mp-pw/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pals-p2mp-pw-04 https://datatracker.ietf.org/doc/html/draft-ietf-pals-p2mp-pw-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-p2mp-pw-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Nov 12 22:33:39 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4A31294A2; Sun, 12 Nov 2017 22:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 WR9zN8jLDOMq; Sun, 12 Nov 2017 22:33:36 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 066421294B5; Sun, 12 Nov 2017 22:33:16 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id i5so11192771pfe.6; Sun, 12 Nov 2017 22:33:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rlqYCii0OtL8QbeDywGrF7bTGskp6NG+sEnBR3CGnx4=; b=eoA8w57jjMk/aISdNEsy3RMtFsDEV/iOm4HW+/n3E9D/NVq4RCXe1VFnC/8XKLCXUw 0iL6/31PAVPanPS21JlN+doysQiABww9G3aTdaNkIioZIEEbfE8y+fYFO6GME6BEYuq2 HZ1MI6qkGBV8L5jkwK3TLDqR24EWiHDdzrTfDycnzotdF3lLakuI/U2jDKwHpesTIkZC 9pPVsLRsTP3GUizGOruBLi1M1oC5HafQw83vhhRXurf6ABFgYFmJZ0pv+ug7fQ4RMOBn 4SBAbZdFBCy0jeSYHxhVzRIqI3X7RldNaV++f5enExDIHBJeRtkkkibpOic6pMI82ttq mc+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rlqYCii0OtL8QbeDywGrF7bTGskp6NG+sEnBR3CGnx4=; b=fGW8EkeURrgCcYySl/i2hd62Slf/Gn6pkcTBiKhtD98mmQ/j+eH36Iuxhsn1jRr/sP fcPh2bEdV18P6bfHN0o03/C0DasBvuBY4QcGIQEQDebdJ1KptqMauWyO0yti+6L1YgPy /u7YfZufP32Y8o3WcYplr4oUsvtOm6EX1z6t5sFRPFrQp9XW/w/slQ/qafrjfZ8jnnlx gUgk+maqETD4pSpWiGBMBWiiGwH1zeSofuUzLjbN/1NPus6dZOMj+0r3EGBu0Pm1Gtyc kHDxck2ifIrE5JFLiQ6drCYJdACLxbmTWCsdmTIknUsKPAwIvBwWi5fDvPw6ELHuanva C3pg== X-Gm-Message-State: AJaThX6bz4Xjvs3d1DfO9M5Sb95I8GFsNIrzUNBvbjVkSK70GiHujmjE mMeojeWOOofBGV3lorj8sDs= X-Google-Smtp-Source: AGs4zMbkUM/kWhaOWQbA9oJFS6wBgbZs743Opgtnb1eyypponGTD4afJtiVIPQ5OxZnF/r23KLP4Ug== X-Received: by 10.101.87.139 with SMTP id b11mr7872047pgr.314.1510554795352; Sun, 12 Nov 2017 22:33:15 -0800 (PST) Received: from ?IPv6:2001:67c:370:1998:500e:7d66:ee01:4309? ([2001:67c:370:1998:500e:7d66:ee01:4309]) by smtp.gmail.com with ESMTPSA id w184sm5152168pgb.36.2017.11.12.22.33.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 22:33:14 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Suresh Krishnan In-Reply-To: <2127F0E0-4880-4555-85EE-13A0EC9AD965@vmware.com> Date: Mon, 13 Nov 2017 14:33:14 +0800 Cc: The IESG , "draft-ietf-pals-p2mp-pw@ietf.org" , Stewart Bryant , "pals-chairs@ietf.org" , "pals@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <150414165129.16888.245048756650963482.idtracker@ietfa.amsl.com> <2127F0E0-4880-4555-85EE-13A0EC9AD965@vmware.com> To: Sami Boutros X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Pals] Suresh Krishnan's Discuss on draft-ietf-pals-p2mp-pw-03: (with DISCUSS and COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 06:33:38 -0000 Hi Sami, Thanks for addressing by DISCUSS point and all but one of my COMMENT = points. All of your resolutions work for me. I will clear based on that. = One open item inline regarding my COMMENT=20 > On Nov 13, 2017, at 10:21 AM, Sami Boutros = wrote: >=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> * I think there is a typo in Figure 2. >>=20 >> The "AII Type" field should be labeled "SAII Type" instead >=20 > Sami: >=20 > No, this is correct, attachment individual identifiers AII type 1 or = type 2 identifies a SAII or a TAII. I understand your point but that is not what the figure describes. My = request is for the figure to be consistent. If you want to use "AII = type" then don=E2=80=99t label the value as "SAII value" as it may be a = TAII value based on the AII type. Label it as =E2=80=9CAII Value=E2=80=9D = or lock down the AII type to 2. I am not blocking on this and I leave it = up to your discretion if you want to address this.=20 Thanks Suresh From nobody Sun Nov 12 22:34:26 2017 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDE1129484; Sun, 12 Nov 2017 22:34:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-pals-p2mp-pw@ietf.org, Stewart Bryant , pals-chairs@ietf.org, stewart.bryant@gmail.com, pals@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151055485896.21390.16198122822946607175.idtracker@ietfa.amsl.com> Date: Sun, 12 Nov 2017 22:34:18 -0800 Archived-At: Subject: [Pals] Suresh Krishnan's No Objection on draft-ietf-pals-p2mp-pw-04: (with COMMENT) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 06:34:19 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-pals-p2mp-pw-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pals-p2mp-pw/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS point. From nobody Sun Nov 12 23:59:29 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51747127444 for ; Sun, 12 Nov 2017 23:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 WSJa-RvUC-_Z for ; Sun, 12 Nov 2017 23:59:27 -0800 (PST) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::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 58EE0126B6E for ; Sun, 12 Nov 2017 23:59:27 -0800 (PST) Received: by mail-ot0-x22f.google.com with SMTP id v15so3755195ote.6 for ; Sun, 12 Nov 2017 23:59:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=D8+zPvJt5P6J16lDISeEBBkxhi1EQoog8piSHygPDo8=; b=Lw5Gj7AkQ7PN8281Ckia35B2tbPWXBfRlvzwGC7RF+8ZvsqF0cxSAKeKCO+jNUKYK5 Zu/bJOw3RMrhlzlyDHVXh2Xyxx2adQaPrWSO7POyCWp8DrAtdGoyNReAY7BU02eHniJk uanqEWLOHhJpxe7d0ffWlvJ8QDTWMJHwWWmKlzqMLwrZjZ/Ab9xLew+uq3hj2I5lW6Xz h7aYGNqLP5AY15jSKsWbPuxjI3R1dPHACP9Crny3K5PlMKYnnv6dgrCFfW/j0fgOcmER 1Z49KoWEMLMZQrEJkck6cnqgE1MPX/shASfhV5aEmWKL7NljOkA6i5Rf2rtpuzRAaXkV blvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=D8+zPvJt5P6J16lDISeEBBkxhi1EQoog8piSHygPDo8=; b=Fv5G1im0kBajkVOrJB2mv8w7Jgq3VAlu2d6nReBBVy90byA/7q6Nsx3aUqOCqCLMp1 KLMaQ8n7KV8kjUegnMsLDWaJEQERkrO8T5njqySCmkgepEuYOAFymuu/h+qbLe822jDu 0DqHkVAW9PcQn90N1iY/5lPvRQ5DZKU4EaHYXG1Cp10ZkOeqnPl2v290NHO7kODKmQEu MS2i5mXXpg78JnnhCZWpylbk58b376fjOVQ+VzkbBDWB6OipTxbQJ4dTCRyUVRdwvWhh cctpCUXmBFlipau9EHHfKiepRTK3U/VzaNtdK8bdwiUY9d4///Z5RXxgjp1glDvnSWDo HSTg== X-Gm-Message-State: AJaThX4Uw6G7ky2AoJy0m0sLV5cie/wxHrkbIUi7oROwUsYRV4Su/ko4 5eXabjvSaoaHtlUfifjNv6z/4jG6Ef+I/O3ZfeCjng== X-Google-Smtp-Source: AGs4zMbduZE/Qf/AbS/Nx7fZ5iGn4NznXpFbS9ohs3+Cz7lIbvAZpg+9tPlb6e2T8RuoB5ADGzM2/iRNpfvy3fJ+6dM= X-Received: by 10.157.66.199 with SMTP id c7mr3760096otj.148.1510559966420; Sun, 12 Nov 2017 23:59:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.83.141 with HTTP; Sun, 12 Nov 2017 23:59:06 -0800 (PST) From: "Andrew G. Malis" Date: Mon, 13 Nov 2017 15:59:06 +0800 Message-ID: To: "pals@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1c0e8a35e17a055dd8a621" Archived-At: Subject: [Pals] A reminder: PALS is coming up at 17:40 X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 07:59:28 -0000 --94eb2c1c0e8a35e17a055dd8a621 Content-Type: text/plain; charset="UTF-8" A reminder: the PALS meeting is coming up at 17:40 Singapore time! See you there locally or via Meetecho. Cheers, Andy --94eb2c1c0e8a35e17a055dd8a621 Content-Type: text/html; charset="UTF-8"
A reminder: the PALS meeting is coming up at 17:40 Singapore time! See you there locally or via Meetecho.

Cheers,
Andy

--94eb2c1c0e8a35e17a055dd8a621-- From nobody Mon Nov 13 06:19:59 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D45128BB6; Mon, 13 Nov 2017 01:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 7GWxoJq02oIU; Mon, 13 Nov 2017 01:24:07 -0800 (PST) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 50B42128BC8; Mon, 13 Nov 2017 01:24:07 -0800 (PST) Received: by mail-it0-x22d.google.com with SMTP id f187so8629413itb.1; Mon, 13 Nov 2017 01:24:07 -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; bh=fNbF7Z2oGcr8zNiOqSZpmqBhXn63XYriDAfPpMzmC8o=; b=sXCzdB3IoQx9kQpxfsbY2bupzFsjtRCgA3H1Lf11JMe/fGRak3BfLn5IfFYc+ap9Sj vN6F13ufnYrEVCoYAXk7s4hDIzogeH6WkiwK7ORFc9r6InbAP2rmsWqkFmALB6DTwHUI mwjl6+HeVUToroyqRieGQ0ZTtR+yxW0nOHgbcKZX+rIPblaYQb+zY+79e7yS/adUNgIx QlTc80bdFRrSRoOPaxCgWCqORM0uQYAdD4kCjX3TEwJa5e3N6omqwRo2ILbUyWQcilIL FolX2CHmGbjBnNW58CiNjElBOe3QaXhzkpfg4aPr0wCebTNtMOWTYhxt9nUxSdVggUsW FEVw== 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; bh=fNbF7Z2oGcr8zNiOqSZpmqBhXn63XYriDAfPpMzmC8o=; b=p7+WPVTtj76Uddlb29QjLksdNRQAgCZJ6CVoK9+zDvCB10vOEvX8HkV/ZsSK6Up1LW WX1g/TtCg+0QR2hi+IdWHtwC3gRcVjrjWXt0tpkzcSEVPehwXmrbwvSI4DhQiW92kh4u ndxL7810caiFszWtNMcW1ByK2E3gV3WPBbS6pn4S+OdhAJ4fvawj+jfbxS15Djf+1VtT rqJ6LB0NH6KKEbqaZgiWx/dSuy5ufrHoahzNut60MM63BzK+VMnjcDCPYcJlfE8VCyV3 9z+AkcvFeDIsDYqe7Zkh4UCGn7hKC77DC1i3bxS70JC8SaCtY3Cawe4+J6lYK2BF24Be Wsfg== X-Gm-Message-State: AJaThX7ZXAKcJAKoD5DEttOj6R7YRdDJWfRnu5E8qfjQ3YbmhlF8GHFW emyB85qawC6CsRfwXKleBO+n4uC1Gpo= X-Google-Smtp-Source: AGs4zMZfdPEKl+/9AtNDzk8QzYQK6mZ8TnNxKDKIBnAz7Njy0vfjk1DSf1MJAZ+SDbopt2hlZZDcYw== X-Received: by 10.36.182.2 with SMTP id g2mr9920817itf.34.1510565046236; Mon, 13 Nov 2017 01:24:06 -0800 (PST) Received: from [172.16.182.160] ([101.100.166.67]) by smtp.gmail.com with ESMTPSA id i63sm7457754ioi.68.2017.11.13.01.24.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 01:24:05 -0800 (PST) To: Jeff Tantsura , Joe Touch Cc: "mpls@ietf.org" , Eric Rescorla , "tcpm@ietf.org" , "pals-chairs@tools.ietf.org" , "" , "Scharf, Michael (Nokia - DE/Stuttgart)" , "mpls-chairs@ietf.org" , "pals@ietf.org" , "" References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> <4f634e7c-f3b9-f0ab-abc7-80ec1062b52a@strayalpha.com> <697AC959-60C2-401D-9E64-D88E16F35EBB@gmail.com> From: Ignas Bagdonas Message-ID: <1817bcab-e088-b822-bf6d-07e52b9fb998@gmail.com> Date: Mon, 13 Nov 2017 09:24:00 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <697AC959-60C2-401D-9E64-D88E16F35EBB@gmail.com> Content-Type: multipart/alternative; boundary="------------12525C3C2481F53811CFBDBA" Content-Language: en-GB Archived-At: X-Mailman-Approved-At: Mon, 13 Nov 2017 06:19:57 -0800 Subject: Re: [Pals] [mpls] [tcpm] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 09:24:11 -0000 This is a multi-part message in MIME format. --------------12525C3C2481F53811CFBDBA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit An operator’s view here. Addressing multiple points in a single message here. Yes, the issue is with adoption. It is not being adopted because the problem solution does not necessary address the actual problem. Taking BGP as an example (and most of this applies to LDP as well) – we need to differentiate what security means in BGP context. Is it BGP transport security – the confidentiality of BGP messages exchanged between the peers (which MD5 or AO can address), or BGP information security – whether the peer is authorized to advertise a prefix and with what attributes (to which the presence or absence of MD5 and AO is orthogonal). Any cryptographically strong security mechanism is not a substitute for practical operational hygiene. If you have right confidentiality mechanism for BGP transport but do not implement proper edge filtering – you will run into problems. Not because there will be a compromise of BGP session transport, but because there will be a variety of DoS forms on the BGP component itself and the platform on which it is running. Proper edge filtering plus TTL validation is good enough and simple enough to be universally deployed, and MD5 option is used to validate that you are indeed speaking to the same peer to which you were speaking before the maintenance window, it is a form of a strong checksum. AO or BGP over TLS (dare I to say that :-) ) does nothing to address the BGP information security aspects of who is or is not allowed to advertise certain types of BGP routing information – which is the source of virtually all of practical (and successful) attacks happening in BGP context. This is the reason why AO or some other strong cryptographic mechanism for BGP transport session is not on the top of the list of operational worries, if at that list at all. RPKI family of solutions tries to address the BGP information security part. It tries, not necessary addresses it in a practical way. But that is above the session level security problems. Any cryptographically strong security mechanism is not a substitute for proper network design. Taking the DC example, if the attack vector is based on the tenant’s ability to interfere with BGP sessions used for controlling the topology that does not belong to the tenant – that is a broken network design, and it should be fixed first before trying to fix BGP itself. BGP is not at fault here, the design of the network that does not allow for sufficient isolation between entities is. No protocol is able to fix the design problems by itself. This does not mean that AO or some other transport security mechanism is not relevant or not needed. At least the solution for key rollover that is better than manual synchronization over phone is definitely of value. Ignas On 11/11/2017 03:11, Jeff Tantsura wrote: > Joe, > > There’s no problem with updating, the problem is with adoption... > > Regards, > Jeff > > On Nov 11, 2017, at 08:48, Joe Touch > wrote: > >> Hi, all, >> >> I don't see a problem if there's a need for updating TCP-AO to >> include/require other algorithms. It was intended to be extensible. >> >> I agree with the issue of key management. There was some work on >> extensions to IKE to enable its use to manage TCP-AO parameters and >> keys, but it stalled twice: >> >> M. Jethanandani, B. Weis, K. Patel, D. Zhang, S. Hartman, U. >> Chunduri, A. Tian, J. Touch, “Negotiation for Keying Pairwise Routing >> Protocols in IKEv2 >> ,” (RFC >> in progress), Nov. 2013. >> >> U. Chunduri, A. Tian, J. Touch, “Using IKEv2 with TCP-AO >> ,” >> (RFC in progress), Feb. 2014. >> >> AFAICT, that would go a long way towards addressing the issues with >> its use outside routing environments where keys are already >> considered sufficiently managed. >> >> However, the larger problem with TCP-AO is that there are no >> implementations available in end system OSes (AFAICT). Designing a >> new solution simply to avoid implementing an existing one would be a >> significant waste of time. >> >> Joe >> >> >> On 11/10/2017 8:21 AM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: >>> >>> +TCPM >>> >>> Please free to discuss changes to TCP-AO on the TCPM list, or speak >>> up at the upcoming TCPM meeting. >>> >>> The addition of SHA-256 has been discussed in TCPM already (see >>> draft-nayak-tcp-sha2-02), but so far there was not much energy and >>> no interest from potential TCP-AO implementers or users. >>> >>> Michael >>> >>> (TCPM co-chair) >>> >>> *From:* mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Eric Rescorla >>> *Sent:* Wednesday, November 08, 2017 7:00 PM >>> *To:* Stewart Bryant >>> *Cc:* mpls@ietf.org; pals-chairs@tools.ietf.org; >>> ; mpls-chairs@ietf.org; pals@ietf.org; >>> >>> *Subject:* Re: [mpls] LDP Security >>> >>> Hi Stewart >>> >>> Thanks for your note. >>> >>> My overall sense of the state of play is, I think much like yours. >>> >>> TCP-MD5 is inadequate in two major respects: >>> >>> - It uses weak algorithms >>> >>> - It has a bad negotiation/setuop story (manual key management) >>> >>> TCP-AO is intended to be a drop-in replacement for TCP-MD5 and so >>> remedies the algorithm >>> >>> issue but not the key management issue [0]. We haven't made much >>> progress on the key >>> >>> management story, and that seems to be a major impediment to >>> deploying either of these >>> >>> technologies (which I am given to understand don't see a lot of >>> use). We should probably >>> >>> talk in Singapore about that, but that's not going to get better any >>> time soon. >>> >>> In the interim, I think the text you have is OK, and "TBD" should >>> read "SHA-256", with >>> >>> the fallback being SHA-256 -> SHA-1 -> MD5. >>> >>> -Ekr >>> >>> [0] Technically It has better support for rollover, but this is not >>> a huge improvement. >>> >>> [1] tcpcrypt is kind of orthogonal here as it's unauthenticated but >>> opportunistic.  That said, >>> >>> it would provide defense against attackers who gain access to the >>> link after connection >>> >>> setup and doesn't require configuration. >>> >>> On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant >>> > wrote: >>> >>> To the SEC and RTG ADs, >>> >>> I am sending the following message on behalf of the MPLS and the >>> PALS WG Chairs. >>> >>> There is a concern shared among the security community and the >>> working groups that develop the LDP protocol that LDP is no >>> longer adequately secured. LDP currently relies on MD5 for >>> cryptographic security of its messages, but MD5 is a hash >>> function that is no longer considered to meet current security >>> requirements. >>> >>> In RFC5036 (published 2007) Section 5.1 (Spoofing) , List >>> element 2. Session communication carried by TCP the following >>> statements is made: >>> >>> "LDP specifies use of the TCP MD5 Signature Option to provide >>> for the authenticity and integrity of session messages. >>> >>> "[RFC2385] asserts that MD5 authentication is now considered by >>> some to be too weak for this application.  It also points out >>> that a similar TCP option with a stronger hashing algorithm (it >>> cites SHA-1 as an example) could be deployed.  To our knowledge, >>> no such TCP option has been defined and deployed. However, we >>> note that LDP can use whatever TCP message digest techniques are >>> available, and when one stronger than MD5 is specified and >>> implemented, upgrading LDP to use it would be relatively >>> straightforward." >>> >>> We note that BGP has already been through this process, and >>> replaced MD5 with TCP-AO in RFC 7454. I would be logical to >>> follow the same approach to secure LDP. However, as far as we >>> are able to ascertain, there is currently no recommended, >>> mandatory to implement, cryptographic function specified. We are >>> concerned that without such a mandatory function, >>> implementations will simply fall back to MD5 and we will be no >>> further forward >>> >>> We think that the best way forward is to publish a draft similar >>> to RFC 7454 that contains the following requirement: >>> >>> "Implementations conforming to this RFC MUST implement TCP-AO to >>> secure the TCP sessions carrying LDP in addition to the >>> currently required TCP MD5 Signature Option. Furthermore, the >>> TBD cryptographic mechanism must be implemented and provided to >>> TCP-AO to secure LDP messages. The TBD mechanism is the >>> preferred option, and MD5 is only to be used when TBD is >>> unavailable." >>> >>> We are not an experts on this part of the stack, but it seems >>> that TCP security negotiation is still work in progress. If we >>> are wrong, then we need to include a requirement that such >>> negotiation is also required. In the absence of a negotiation >>> protocol, however, we need to leave this as a configuration >>> process until such time as the negotiation protocol work is >>> complete. On completion of a suitable negotiation protocol we >>> need to issue a further update requiring its use. >>> >>> Additionally we should note that no cryptographic mechanism has >>> an indefinite lifetime, and that implementation should note the >>> IETF anticipates updating the default cryptographic mechanism >>> over time. >>> >>> The TBD default security function will need to be chosen such >>> that it can reasonably be implemented on a typical router route >>> processor, and which will provide adequate security without >>> significantly degrading the convergence time of an LSR. Without >>> a function that does not significantly impact router convergence >>> we simply close one vulnerability and open another. >>> >>> As experts on the LDP protocol, but not on security mechanisms, >>> we  need to ask the security area for a review of our proposed >>> approach, and help correcting any misunderstanding of the >>> security issues or our misunderstanding of the existing security >>> mechanisms. We also need the recommendations of a suitable >>> security function (TBD in the above text). >>> >>> Best regards >>> >>> The MPLS WG Chairs >>> The PALS WG Chairs >>> >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --------------12525C3C2481F53811CFBDBA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

An operator’s view here. Addressing multiple points in a single message here.

Yes, the issue is with adoption. It is not being adopted because the problem solution does not necessary address the actual problem.

Taking BGP as an example (and most of this applies to LDP as well) – we need to differentiate what security means in BGP context. Is it BGP transport security – the confidentiality of BGP messages exchanged between the peers (which MD5 or AO can address), or BGP information security – whether the peer is authorized to advertise a prefix and with what attributes (to which the presence or absence of MD5 and AO is orthogonal).

Any cryptographically strong security mechanism is not a substitute for practical operational hygiene. If you have right confidentiality mechanism for BGP transport but do not implement proper edge filtering – you will run into problems. Not because there will be a compromise of BGP session transport, but because there will be a variety of DoS forms on the BGP component itself and the platform on which it is running. Proper edge filtering plus TTL validation is good enough and simple enough to be universally deployed, and MD5 option is used to validate that you are indeed speaking to the same peer to which you were speaking before the maintenance window, it is a form of a strong checksum. AO or BGP over TLS (dare I to say that :-) ) does nothing to address the BGP information security aspects of who is or is not allowed to advertise certain types of BGP routing information – which is the source of virtually all of practical (and successful) attacks happening in BGP context. This is the reason why AO or some other strong cryptographic mechanism for BGP transport session is not on the top of the list of operational worries, if at that list at all. RPKI family of solutions tries to address the BGP information security part. It tries, not necessary addresses it in a practical way. But that is above the session level security problems.

Any cryptographically strong security mechanism is not a substitute for proper network design. Taking the DC example, if the attack vector is based on the tenant’s ability to interfere with BGP sessions used for controlling the topology that does not belong to the tenant – that is a broken network design, and it should be fixed first before trying to fix BGP itself. BGP is not at fault here, the design of the network that does not allow for sufficient isolation between entities is. No protocol is able to fix the design problems by itself.

This does not mean that AO or some other transport security mechanism is not relevant or not needed. At least the solution for key rollover that is better than manual synchronization over phone is definitely of value.

Ignas


On 11/11/2017 03:11, Jeff Tantsura wrote:
Joe,

There’s no problem with updating, the problem is with adoption...

Regards,
Jeff

On Nov 11, 2017, at 08:48, Joe Touch <touch@strayalpha.com> wrote:

Hi, all,

I don't see a problem if there's a need for updating TCP-AO to include/require other algorithms. It was intended to be extensible.

I agree with the issue of key management. There was some work on extensions to IKE to enable its use to manage TCP-AO parameters and keys, but it stalled twice:

M. Jethanandani, B. Weis, K. Patel, D. Zhang, S. Hartman, U. Chunduri, A. Tian, J. Touch, “Negotiation for Keying Pairwise Routing Protocols in IKEv2,” (RFC in progress), Nov. 2013.

U. Chunduri, A. Tian, J. Touch, “Using IKEv2 with TCP-AO,” (RFC in progress), Feb. 2014.

AFAICT, that would go a long way towards addressing the issues with its use outside routing environments where keys are already considered sufficiently managed.

However, the larger problem with TCP-AO is that there are no implementations available in end system OSes (AFAICT). Designing a new solution simply to avoid implementing an existing one would be a significant waste of time.

Joe


On 11/10/2017 8:21 AM, Scharf, Michael (Nokia - DE/Stuttgart) wrote:

+TCPM

 

Please free to discuss changes to TCP-AO on the TCPM list, or speak up at the upcoming TCPM meeting.

 

The addition of SHA-256 has been discussed in TCPM already (see draft-nayak-tcp-sha2-02), but so far there was not much energy and no interest from potential TCP-AO implementers or users.

 

Michael

(TCPM co-chair)

 

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Wednesday, November 08, 2017 7:00 PM
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: mpls@ietf.org; pals-chairs@tools.ietf.org; <rtg-ads@ietf.org> <rtg-ads@ietf.org>; mpls-chairs@ietf.org; pals@ietf.org; <sec-ads@ietf.org> <sec-ads@ietf.org>
Subject: Re: [mpls] LDP Security

 

Hi Stewart

 

Thanks for your note.

 

My overall sense of the state of play is, I think much like yours.

 

TCP-MD5 is inadequate in two major respects:

- It uses weak algorithms

- It has a bad negotiation/setuop story (manual key management)

 

TCP-AO is intended to be a drop-in replacement for TCP-MD5 and so remedies the algorithm

issue but not the key management issue [0]. We haven't made much progress on the key

management story, and that seems to be a major impediment to deploying either of these

technologies (which I am given to understand don't see a lot of use). We should probably

talk in Singapore about that, but that's not going to get better any time soon.

 

In the interim, I think the text you have is OK, and "TBD" should read "SHA-256", with

the fallback being SHA-256 -> SHA-1 -> MD5.

 

-Ekr

 

 

[0] Technically It has better support for rollover, but this is not a huge improvement.

[1] tcpcrypt is kind of orthogonal here as it's unauthenticated but opportunistic.  That said,

it would provide defense against attackers who gain access to the link after connection

setup and doesn't require configuration.

 

On Wed, Nov 8, 2017 at 9:27 AM, Stewart Bryant <stewart.bryant@gmail.com> wrote:

To the SEC and RTG ADs,

I am sending the following message on behalf of the MPLS and the
PALS WG Chairs.

There is a concern shared among the security community and the working groups that develop the LDP protocol that LDP is no longer adequately secured. LDP currently relies on MD5 for cryptographic security of its messages, but MD5 is a hash function that is no longer considered to meet current security requirements.

In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2. Session communication carried by TCP the following statements is made:

"LDP specifies use of the TCP MD5 Signature Option to provide for the authenticity and integrity of session messages.

"[RFC2385] asserts that MD5 authentication is now considered by some to be too weak for this application.  It also points out that a similar TCP option with a stronger hashing algorithm (it cites SHA-1 as an example) could be deployed.  To our knowledge, no such TCP option has been defined and deployed.  However, we note that LDP can use whatever TCP message digest techniques are available, and when one stronger than MD5 is specified and implemented, upgrading LDP to use it would be relatively straightforward."

We note that BGP has already been through this process, and replaced MD5 with TCP-AO in RFC 7454. I would be logical to follow the same approach to secure LDP. However, as far as we are able to ascertain, there is currently no recommended, mandatory to implement, cryptographic function specified. We are concerned that without such a mandatory function, implementations will simply fall back to MD5 and we will be no further forward

We think that the best way forward is to publish a draft similar to RFC 7454 that contains the following requirement:

"Implementations conforming to this RFC MUST implement TCP-AO to secure the TCP sessions carrying LDP in addition to the currently required TCP MD5 Signature Option. Furthermore, the TBD cryptographic mechanism must be implemented and provided to TCP-AO to secure LDP messages. The TBD mechanism is the preferred option, and MD5 is only to be used when TBD is unavailable."

We are not an experts on this part of the stack, but it seems that TCP security negotiation is still work in progress. If we are wrong, then we need to include a requirement that such negotiation is also required. In the absence of a negotiation protocol, however, we need to leave this as a configuration process until such time as the negotiation protocol work is complete. On completion of a suitable negotiation protocol we need to issue a further update requiring its use.

Additionally we should note that no cryptographic mechanism has an indefinite lifetime, and that implementation should note the IETF anticipates updating the default cryptographic mechanism over time.

The TBD default security function will need to be chosen such that it can reasonably be implemented on a typical router route processor, and which will provide adequate security without significantly degrading the convergence time of an LSR. Without a function that does not significantly impact router convergence we simply close one vulnerability and open another.

As experts on the LDP protocol, but not on security mechanisms, we  need to ask the security area for a review of our proposed approach, and help correcting any misunderstanding of the security issues or our misunderstanding of the existing security mechanisms. We also need the recommendations of a suitable security function (TBD in the above text).

Best regards

The MPLS WG Chairs
The PALS WG Chairs

 



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

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


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

--------------12525C3C2481F53811CFBDBA-- From nobody Mon Nov 13 06:20:03 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99C512957A; Mon, 13 Nov 2017 06:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 zQ4xDlrwZULZ; Mon, 13 Nov 2017 06:10:37 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 01D29129A84; Mon, 13 Nov 2017 06:10:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject: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=6OARAuLshl8pGUwz+FH8u3DR3LqRzV0lHKIdRO+gK+Q=; b=XG66sqivw8fapK0IvREdP7ESgS T/v1+2rVNzBxsi8mqnLfJbEGobuAZvv7xzjaPCcgRVhmFnOhqPcMB9/Zh7SDSfDbWn0vGYoB/rlQF qSCRctQG+5S04SG6V2y6jagDrdnW0zl/0/zBNKqNULS39nX0eb3DNpsel/f4nKvMGv5Jbkvo+3Ets eJpXMQLDgIMi/cX3i/LGmQDkCgrHnpC/XObbDNXjTc+W8Xz2Cj1wubWJ4w+P5q7y6guHNyCeWHccB OB/VHiIRc34D+COCaRP8+eg75gYTSEXOS9JtVDrJGP/lEDcoXkGHcjnjwXcn0kTecEmab6o6XSOFA 7Kw96zYQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:64372 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eEFRS-0003gV-CP; Mon, 13 Nov 2017 09:10:27 -0500 To: Ignas Bagdonas , Jeff Tantsura Cc: "mpls@ietf.org" , Eric Rescorla , "tcpm@ietf.org" , "pals-chairs@tools.ietf.org" , "" , "Scharf, Michael (Nokia - DE/Stuttgart)" , "mpls-chairs@ietf.org" , "pals@ietf.org" , "" References: <2da71163-cf29-cba6-df61-d75a2cfc9c43@gmail.com> <7ee4fd77-7d8d-0db2-527e-9cf91d87e634@gmail.com> <51b9e5b4-0a44-1449-a4df-91e4f9df5d6b@pi.nu> <02a50f02-779e-bc39-505c-5a51d066b3f0@pi.nu> <15335748-e900-280d-554f-24c55c0f3ba5@gmail.com> <4f634e7c-f3b9-f0ab-abc7-80ec1062b52a@strayalpha.com> <697AC959-60C2-401D-9E64-D88E16F35EBB@gmail.com> <1817bcab-e088-b822-bf6d-07e52b9fb998@gmail.com> From: Joe Touch Message-ID: Date: Mon, 13 Nov 2017 06:10:21 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1817bcab-e088-b822-bf6d-07e52b9fb998@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: X-Mailman-Approved-At: Mon, 13 Nov 2017 06:19:57 -0800 Subject: Re: [Pals] [mpls] [tcpm] LDP Security X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 14:10:39 -0000 On 11/13/2017 1:24 AM, Ignas Bagdonas wrote: > > An operator’s view here. Addressing multiple points in a single > message here. > > Yes, the issue is with adoption. It is not being adopted because the > problem solution does not necessary address the actual problem. > > Taking BGP as an example (and most of this applies to LDP as well) – > we need to differentiate what security means in BGP context. Is it BGP > transport security – the confidentiality of BGP messages exchanged > between the peers (which MD5 or AO can address), or BGP information > security – whether the peer is authorized to advertise a prefix and > with what attributes (to which the presence or absence of MD5 and AO > is orthogonal). > I had thought it was widely understood that there are two components to protecting BGP:         - TCP-AO - to protect the TCP connections from attack and authenticate the endpoint pairs         - BGPsec - to validate the authenticity of relayed prefix advertisements and ensure its legitimacy Is there a third aspect that isn't included here that you feel is missing? Or do you feel one of these inadequate in performing *the function it is designed for*? Joe From nobody Mon Nov 13 07:04:23 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6AD129AD1 for ; Mon, 13 Nov 2017 07:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 2p-P5zcrEKQC for ; Mon, 13 Nov 2017 07:04:15 -0800 (PST) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::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 CB348129AD4 for ; Mon, 13 Nov 2017 07:04:13 -0800 (PST) Received: by mail-ot0-x22f.google.com with SMTP id g104so1776126otg.7 for ; Mon, 13 Nov 2017 07:04:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=CRKG9qCN+iy8VOh8d37FwG6gUwjVWmXdOTOZd3B3icM=; b=FiceEhQABOI771f5tQAn/xol2eP4t++bk5G9HoENoMAv8iL9SNDmcYq4i6+hWsy6/n OrCUdn0utaHsbkGMOXZ5+VOFsXQug0RW09zVq3nJAnf4Fy2x2au5EovBtMHY9egN6o9/ N/DRk/VtyAL4DUJ/HHkiG201nrrsWWIJtIn9T5tp+QccUFJ+bCFRcqo1RGJD/dFUr3t3 IMnycGDgg4d9IYs1bkT6wkz5ucO8FBArc5fs+BAKj5oy5NYWCYBK639enbrSQrmgzyAd hVzwDXohy0fCAen0VDLPGIavOVzBHeiCRfyUyJ/yKPNhPUDm/fZNuE/TlR3BLKd41ddd WdPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=CRKG9qCN+iy8VOh8d37FwG6gUwjVWmXdOTOZd3B3icM=; b=rkL+aWc7OYTxIQ2tpDaTVO8vv7JWn0jU5ULqqHuuOkvuZ3fJcO99/AjEpMSIHAPwWg Y+YqnUU3oleU9B7WPwwyZHt2VsgnxVsFKAwRlMeg23F5OkQnGPcGXV9OCF3Yq74kPVDE wHPx2MyKt0bEgs81ot5R86Sd1NpYY+o9wiJs6CVr9mDaGoIMk1ClmoHMZAtM4X4caXrX ElSIKaDvYiEquAjD/UatPZFn1Hup5qkZWAElTW1Cz0VsM2V03Ov6jUsgXUAQIPzcZhJ6 vZRMWS/aV1MSAuU7Q3fn+MXDBZS2NsSm5fYBAROO0ZswTnetj2u5wbvN7zvQPn2tqTgo Y8sw== X-Gm-Message-State: AJaThX66Zns6uCq/IkTUuTS482poW47xT4nPmaNSo7lm+FVGlfub/A7y v4dwYSS8CXvNAevqadkgI2jrhE07Q3pp3iddqyy3nQ== X-Google-Smtp-Source: AGs4zMYsJUb/a6xqw43zFZdvoLydsiK+qhQ9f4ZF+2wZEZlLjiTgzghXaRBS0s52azY2nyk8IW/4AlAqk0UYHDVC5t8= X-Received: by 10.157.65.210 with SMTP id v18mr4756751oti.365.1510585452907; Mon, 13 Nov 2017 07:04:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.83.141 with HTTP; Mon, 13 Nov 2017 07:03:52 -0800 (PST) From: "Andrew G. Malis" Date: Mon, 13 Nov 2017 23:03:52 +0800 Message-ID: To: "pals@ietf.org" Cc: "BRUNGARD, DEBORAH A (ATTLABS)" , David Sinicrope Content-Type: multipart/alternative; boundary="94eb2c1c21d852d0fb055dde95f4" Archived-At: Subject: [Pals] IETF 100 PALS minutes are up, please review X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 15:04:16 -0000 --94eb2c1c21d852d0fb055dde95f4 Content-Type: text/plain; charset="UTF-8" Actually, they went up immediately after the meeting ended. :-) You can find them at https://tools.ietf.org/wg/pals/minutes . Thanks as always to Dave Sinicrope for scribing and getting the minutes up so quickly. Please review them and reply back to this email if you have any comments or corrections. Thanks, Andy --94eb2c1c21d852d0fb055dde95f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Actually, they went up immediately after the meeting ended= . :-) You can find them at=C2=A0https://tools.ietf.org/wg/pals/minutes .

Tha= nks as always to Dave Sinicrope for scribing and getting the minutes up so = quickly.

Please review them and reply back to this= email if you have any comments or corrections.

Th= anks,
Andy

--94eb2c1c21d852d0fb055dde95f4-- From nobody Mon Nov 13 12:03:45 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2934C129B5E; Mon, 13 Nov 2017 12:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 unW0ahi9Hfx3; Mon, 13 Nov 2017 12:03:42 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF4A129B61; Mon, 13 Nov 2017 12:03:42 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id a142so21301533qkb.5; Mon, 13 Nov 2017 12:03:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=g92KHfQrSWpr9xIJbfBfy9wQyLeDnK8kDCLE7Qh/LEQ=; b=ALoDPRNs7LkwSh1FWkvp6lLznmfKr2zXTKDMSz4pmKNuEyh00Y+aN10HpGRF+ppnex XmmGb6hF73pHUyzEq5aVL/1NBuS/XmxDKFBWgTEmgZdBu7Mq6IVbeDiDEFL9//efYWvO Lhk/dKDWohFhYD+z2frmLESg2qyT7Z5jFjuqk7La2xZ6Q8KbHKdml5m9yyxdpw2WGnDz WbUq0vjhcXCfl1sqKjKIns5cyCgecsiTwXX0zW0IQqS4UoctIM2PCwkz52CCbqgvZq6v TQ/ujVlJqrU0RFKWSSLbEFgZp31aWj3JlTvjPJVOvo/ErOeKMzdQj750xHNxBbTV/xot sVzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=g92KHfQrSWpr9xIJbfBfy9wQyLeDnK8kDCLE7Qh/LEQ=; b=mRbacuARnR8X70c19p7JNsEFp1zO4XyINFvUBNxOUa6AKLm3YuUAmUXrFx18icyI7c iBMXxoyjZNl0Ac6Bsaj3P4OQZiT9Skr02M16byBJgPQQ9A9MBfPzc2LhW54QLPAFWjHS +s7gY7RHAioxJqlX4eM21tIiSEF1XLphdrx+c0a0U3j+D/l9e5lRLySyrII8PdA/y/hg /wvGqiInrfEAl7WrxgqImKHgI9DnvnyGMJndEDT9w9IXKmbaYHCXRX29ZTO0GzFw4Zy+ qnS4jxhmjzuipqStjgcBHP01eK36FKAVl81Zr3ZPZygXDzkSHbYiOJ3XX/+aUhpJyglW ZfSw== X-Gm-Message-State: AJaThX6JcXcbAdgSa/Kcs5FMb+msnd1av/+Lpiu258sfq7ifAzAW/aQn 9Ki8MaiEJ01gXJ5VegsoVPvVSZE44rS5oRU52Ac= X-Google-Smtp-Source: AGs4zMaFjwp/y6Fdy0Dq+LcL8PW+K3NkpHarMvRwWibkXz4HP3TwUbC399WltOSf/XCFtaEULCrjBzG8lqbHb/0UaK0= X-Received: by 10.55.22.23 with SMTP id g23mr15637974qkh.231.1510603421506; Mon, 13 Nov 2017 12:03:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.106.71 with HTTP; Mon, 13 Nov 2017 12:03:10 -0800 (PST) In-Reply-To: <62e75932-3fd1-6f47-7448-05729c3638eb@gmail.com> References: <8e6901f8-63ff-008b-ae00-e49620b76769@gmail.com> <796be686-40ac-e680-0b01-f218e4bd3516@gmail.com> <62e75932-3fd1-6f47-7448-05729c3638eb@gmail.com> From: James Bensley Date: Mon, 13 Nov 2017 20:03:10 +0000 Message-ID: To: Stewart Bryant , "draft-ietf-pals-ethernet-cw@ietf.org" , "pals@ietf.org" Cc: Alexander Vainshtein , "Andrew G. Malis" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Pals] draft-ietf-pals-ethernet-cw and enhanced heuristics X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 20:03:44 -0000 Hi guys, Thanks for your responses! >> From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Stewart Bryant >> Sent: Thursday, November 9, 2017 5:47 PM >> To: James Bensley ; >> draft-ietf-pals-ethernet-cw@ietf.org; Andrew G. Malis ; >> pals@ietf.org >> Subject: Re: [Pals] draft-ietf-pals-ethernet-cw and enhanced heuristics >> >> ... I don't know of any platforms that support CW S/N for Ethernet. >> In most forwarding architectures it is much easier to add FAT or ELI >> support than it is to add support for S/N. This is a discussion we are a= lso >> having in DETNET. I=E2=80=99ve just jumped on to a couple of Cisco IOS boxes, they support it (by which I mean the option is in the CLI, I didn=E2=80=99t test it). So if something as wide spread as IOS supports sequencing I=E2=80=99d said it=E2= =80=99s fairly well supported (meaning deployed even if not used). Even so, I am actually not disagreeing with you, I am in full agreement with you that FAT or ELI should be used /when it can be/ however, my point here is that no empirical data is being presented here about the support of FAT, ELI and sequence number support from vendors, or the number of operators that are using pseudowires are using any, a mixture, or none of those techniques to avoid ECMP and what if any of the techniques are available to those operators on their existing kit. So even though I am in agreement with you, I don=E2=80=99t think sequence numbers can be dismissed so easily (as my agreement is based upon my own cone of vision which I know is very limited) for all the existing kit operators have deployed that possibly supports sequencing. >> Supporting FAT and ELI is a stateless operation that any forwarding >> architecture I can think of can support. >> >> Supporting S/N is stateful. This is hard to so at speed, and may force t= he >> implementer to a specific forwarding architecture (egress packet filteri= ng). >> >> Given the above I am not in favour of including the text on CW S/N. I can't comment on how hard it is or isn't to implement sequence numbers as I personally haven=E2=80=99t tried to code this. Although even without trying I can understand that it adds in more state to the edge devices, although debatably not alot more; RFC4385 provides an example using two 16 bit counters and 2 booleans. I would expect any reasonable pseudowire implementation to have 32 or 64 bit counters for packets sent, received, bytes sent, received, drops on tx, rx, as well as many others for uptime, last state change, etc etc... I don't think it is wise to be flippant with device resources but in relative terms I can=E2=80=99t see it being /that/ much state. Also as I said in my first paragraph, if sequence numbers are support in say Cisco IOS for example, the volume of existing devices that may support PWMCW sequence numbers and not FAT and not ELI could be large, so I would think it worth while to include sequence numbers as a last resort recommendation to the operator. Again, I am in full agreement with your recommendation for FAT or ELI despite my lengthy email (sorry!) however, I would like to understand clearly if/when/why sequence numbers shouldn=E2=80=99t be used. Cheers, James. From nobody Mon Nov 13 17:46:07 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F731270A3; Mon, 13 Nov 2017 17:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 8_SArJQRCj1r; Mon, 13 Nov 2017 17:45:58 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10105.outbound.protection.outlook.com [40.107.1.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEDC112955D; Mon, 13 Nov 2017 17:45:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sg15bp8tv7KcTmgLb/WYcgMMTfG1ese7o88jt/3AXUg=; b=nIQYsR3zBXjjkbnqNLFI8ma/5ILA5ZH5YmTRHMK90eVpmHQqfK4Fd91VOWTd3PL3DksgZdVOrzDLYfJXY86hjnUOV0A6Os9tpbn8yfmefLkWTZMDRPIG8DmVmt74wXJf6/lUDpZbcv5nUBpt8LYJZMFe1SOG6OvORMNQE+uLmbk= Received: from HE1PR0701MB2058.eurprd07.prod.outlook.com (10.167.190.10) by HE1PR0701MB2059.eurprd07.prod.outlook.com (10.167.190.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Tue, 14 Nov 2017 01:45:52 +0000 Received: from HE1PR0701MB2058.eurprd07.prod.outlook.com ([fe80::447c:62f4:1bf9:bc23]) by HE1PR0701MB2058.eurprd07.prod.outlook.com ([fe80::447c:62f4:1bf9:bc23%14]) with mapi id 15.20.0239.005; Tue, 14 Nov 2017 01:45:52 +0000 From: "Dolganow, Andrew (Nokia - SG/Singapore)" To: James Bensley , Stewart Bryant , "draft-ietf-pals-ethernet-cw@ietf.org" , "pals@ietf.org" CC: Alexander Vainshtein , "Andrew G. Malis" Thread-Topic: [Pals] draft-ietf-pals-ethernet-cw and enhanced heuristics Thread-Index: AQHTTYGGQN2F5uQBYEqlYkUZrt37W6L0x64AgAAV4ICAFxZngIAAVPWAgAACfgCAAAJXgIAGjBkAgABfuoA= Date: Tue, 14 Nov 2017 01:45:51 +0000 Message-ID: <69E739A1-B477-44CB-912A-0856EAFFA718@nokia.com> References: <8e6901f8-63ff-008b-ae00-e49620b76769@gmail.com> <796be686-40ac-e680-0b01-f218e4bd3516@gmail.com> <62e75932-3fd1-6f47-7448-05729c3638eb@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.dolganow@nokia.com; x-originating-ip: [2001:67c:370:128:612b:f99f:603c:9880] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2059; 6:s30XlWEKo7mtG+OU+NxP1MDNNLAVEXJUu2PlcIz563Yqvp/1wGD6iJldhhGKTAxs/OE9n0yZMVyqFYCA0XKTwHCaFZp4ujLE4TmDsx8IgymdAi9J99reY64mZ8ho58Hf0LTiXChxtVy1qc5n2zpYGj/H2l0duh7qUZ8Xg+mh8EvAu7lgMf/7hHvtAXsZ/ZDl2237qH1x5/J5Tn6YGHztMSnuJBc9NP639fMUhXAgQTlLtfduWZVq76VeAndvz5qN3Vftt5YkUnmAjap0fmhkP1ykOR/d7qOBJ4RRy2GStZcJ9/5pA4FeWMC2oW1xZ6hCU7OnZa9GtHzxPxllFYpb1GTf96JKWpvWSF1IONXWqXs=; 5:XSmqXOKsfRWLaGXwwF45uNn6544wwGAmYrVaFp9zAc3wJrfuaofPU4IOlDKzKxXI9WWix9+lAPg9QQyoKJyXo2/YfReBb2ISJzTGjUXAlG9Ii6lKvbMG5bZg9h89TjrDPuzsLzYd94yStjwIq3l+Hp1Rtu9pdcOIEnwBuhiikwQ=; 24:E1uz+PFrRSoXUIOxq25AwZqeqAbea2vTnMRauckDmBM4xEOizGrUhQKKvK/2OKcHbABqxs21tje70Qx1Cd4KDIVXE2e+mqyvyCq6VWLZCM4=; 7:H1bTMe5cvTI/4V552p83HcFiMmIs2JtUv90n0VH8y6HnmLOHXhiph0/QY+l8OvjRfafJXz5h54Yumc3njJ2Aug84DKGN1RaJRGKW1CQtNdRc1Z0Z7ZZueneKWzovGRoxp6iqqq/2rxSjEQzdpviBRMdV4jIXdYsXhk7kq4U+WGMH0zBPFS8Imh3020TSlDCcmPxDwCF8eXmzYgGV8Ac7MBlLlMf8zxbc/hl/+GftOvLdXugWwrC/lYRgTTdSzSbA x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 68d107f7-078c-41d4-0962-08d52b017035 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:HE1PR0701MB2059; x-ms-traffictypediagnostic: HE1PR0701MB2059: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231022)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123560025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB2059; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB2059; x-forefront-prvs: 04916EA04C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(13464003)(199003)(189002)(3280700002)(101416001)(6512007)(5250100002)(561944003)(76176999)(229853002)(54356999)(2900100001)(83506002)(6506006)(97736004)(50986999)(6436002)(3660700001)(6486002)(68736007)(6116002)(102836003)(33656002)(966005)(93886005)(106356001)(105586002)(478600001)(8676002)(36756003)(81166006)(81156014)(6306002)(2906002)(86362001)(110136005)(230783001)(54906003)(58126008)(83716003)(53936002)(99286004)(39060400002)(2501003)(189998001)(5660300001)(6246003)(2201001)(305945005)(25786009)(14454004)(4326008)(316002)(8936002)(7736002)(82746002)(53546010)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2059; H:HE1PR0701MB2058.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <7FE3D9298024C849AD5D5410742A48B5@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 68d107f7-078c-41d4-0962-08d52b017035 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2017 01:45:51.9248 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2059 Archived-At: Subject: Re: [Pals] draft-ietf-pals-ethernet-cw and enhanced heuristics X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 01:46:01 -0000 TG9va3MgdG8gbWUgdGhhdCB3ZSB3ZW50IGZyb206DQoNCi0gcGVvcGxlIGRvaW5nIEVDTVAgaW4g YSB3YXkgdGhhdCBpdCB3YXMgbm90IGludGVuZGVkIGZvciBQVyBhbmQgZ2V0dGluZyBpbnRvIGlz c3Vlcw0KdG8NCi0gbGV04oCZcyB0cnkgdG8gc29sdmUgdGhlIGlzc3VlcyB0aGV5IHJ1biBpbnRv IHdpdGggZXh0cmEgY29tcGxleGl0eSwgaW5jbHVkaW5nIGRpc2N1c3Npb25zIGF0IHRoZSBzZXNz aW9ucyBvciBhIGJlbG93IHNlcXVlbmNpbmcgcHJvcG9zYWwgDQoNCkkgd291bGQgcmF0aGVyIGdv IGFub3RoZXIgd2F5IGFuZCBjbGVhcmx5IHByb21vdGUgd2hhdCBjYW4gYmUgZG9uZSBmb3IgRUNN UCAgd2l0aCB0aGUgc3RhbmRhcmQgYW5kIGJ5IHBvaW50aW5nIHRoYXQgb3RoZXIg4oCcc29sdXRp b25z4oCdIHRvcCBhdHRlbmRlZCB0byBjaXJjdW12ZW50IG9yIOKAnGV4dGVuZOKAnSB0ZWNobm9s b2d5IGFyZSBrbm93biB0byBoYXZlIHJ1biBpbnRvIGlzc3VlcyBvZiBtaXMtb3JkZXJpbmcgYW5k IHRodXMgb3BlcmF0b3JzIHNob3VsZCBiZSBjYXJlZnVsIGVuYWJsaW5nIHN1Y2gg4oCcc29sdXRp b25z4oCdIGluIGEgbmV0d29yay4NCg0KQW5kcmV3DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBQYWxzIDxwYWxzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBKYW1l cyBCZW5zbGV5IDxqd2JlbnNsZXlAZ21haWwuY29tPg0KRGF0ZTogVHVlc2RheSwgTm92ZW1iZXIg MTQsIDIwMTcgYXQgNDowMyBBTQ0KVG86IFN0ZXdhcnQgQnJ5YW50IDxzdGV3YXJ0LmJyeWFudEBn bWFpbC5jb20+LCAiZHJhZnQtaWV0Zi1wYWxzLWV0aGVybmV0LWN3QGlldGYub3JnIiA8ZHJhZnQt aWV0Zi1wYWxzLWV0aGVybmV0LWN3QGlldGYub3JnPiwgInBhbHNAaWV0Zi5vcmciIDxwYWxzQGll dGYub3JnPg0KQ2M6IEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbT4sICJBbmRyZXcgRy4gTWFsaXMiIDxhZ21hbGlzQGdtYWlsLmNvbT4NClN1Ympl Y3Q6IFJlOiBbUGFsc10gZHJhZnQtaWV0Zi1wYWxzLWV0aGVybmV0LWN3IGFuZCBlbmhhbmNlZCBo ZXVyaXN0aWNzDQoNCiAgICBIaSBndXlzLA0KICAgIA0KICAgIFRoYW5rcyBmb3IgeW91ciByZXNw b25zZXMhDQogICAgDQogICAgPj4gRnJvbTogUGFscyBbbWFpbHRvOnBhbHMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIFN0ZXdhcnQgQnJ5YW50DQogICAgPj4gU2VudDogVGh1cnNkYXks IE5vdmVtYmVyIDksIDIwMTcgNTo0NyBQTQ0KICAgID4+IFRvOiBKYW1lcyBCZW5zbGV5IDxqd2Jl bnNsZXlAZ21haWwuY29tPjsNCiAgICA+PiBkcmFmdC1pZXRmLXBhbHMtZXRoZXJuZXQtY3dAaWV0 Zi5vcmc7IEFuZHJldyBHLiBNYWxpcyA8YWdtYWxpc0BnbWFpbC5jb20+Ow0KICAgID4+IHBhbHNA aWV0Zi5vcmcNCiAgICA+PiBTdWJqZWN0OiBSZTogW1BhbHNdIGRyYWZ0LWlldGYtcGFscy1ldGhl cm5ldC1jdyBhbmQgZW5oYW5jZWQgaGV1cmlzdGljcw0KICAgID4+DQogICAgPj4gLi4uIEkgZG9u J3Qga25vdyBvZiBhbnkgcGxhdGZvcm1zIHRoYXQgc3VwcG9ydCBDVyBTL04gZm9yIEV0aGVybmV0 Lg0KICAgID4+IEluIG1vc3QgZm9yd2FyZGluZyBhcmNoaXRlY3R1cmVzIGl0IGlzIG11Y2ggZWFz aWVyIHRvIGFkZCBGQVQgb3IgRUxJDQogICAgPj4gc3VwcG9ydCB0aGFuIGl0IGlzIHRvIGFkZCBz dXBwb3J0IGZvciBTL04uIFRoaXMgaXMgYSBkaXNjdXNzaW9uIHdlIGFyZSBhbHNvDQogICAgPj4g aGF2aW5nIGluIERFVE5FVC4NCiAgICANCiAgICBJ4oCZdmUganVzdCBqdW1wZWQgb24gdG8gYSBj b3VwbGUgb2YgQ2lzY28gSU9TIGJveGVzLCB0aGV5IHN1cHBvcnQgaXQNCiAgICAoYnkgd2hpY2gg SSBtZWFuIHRoZSBvcHRpb24gaXMgaW4gdGhlIENMSSwgSSBkaWRu4oCZdCB0ZXN0IGl0KS4gU28g aWYNCiAgICBzb21ldGhpbmcgYXMgd2lkZSBzcHJlYWQgYXMgSU9TIHN1cHBvcnRzIHNlcXVlbmNp bmcgSeKAmWQgc2FpZCBpdOKAmXMNCiAgICBmYWlybHkgd2VsbCBzdXBwb3J0ZWQgKG1lYW5pbmcg ZGVwbG95ZWQgZXZlbiBpZiBub3QgdXNlZCkuIEV2ZW4gc28sIEkNCiAgICBhbSBhY3R1YWxseSBu b3QgZGlzYWdyZWVpbmcgd2l0aCB5b3UsIEkgYW0gaW4gZnVsbCBhZ3JlZW1lbnQgd2l0aCB5b3UN CiAgICB0aGF0IEZBVCBvciBFTEkgc2hvdWxkIGJlIHVzZWQgL3doZW4gaXQgY2FuIGJlLyBob3dl dmVyLCBteSBwb2ludCBoZXJlDQogICAgaXMgdGhhdCBubyBlbXBpcmljYWwgZGF0YSBpcyBiZWlu ZyBwcmVzZW50ZWQgaGVyZSBhYm91dCB0aGUgc3VwcG9ydCBvZg0KICAgIEZBVCwgRUxJIGFuZCBz ZXF1ZW5jZSBudW1iZXIgc3VwcG9ydCBmcm9tIHZlbmRvcnMsIG9yIHRoZSBudW1iZXIgb2YNCiAg ICBvcGVyYXRvcnMgdGhhdCBhcmUgdXNpbmcgcHNldWRvd2lyZXMgYXJlIHVzaW5nIGFueSwgYSBt aXh0dXJlLCBvciBub25lDQogICAgb2YgdGhvc2UgdGVjaG5pcXVlcyB0byBhdm9pZCBFQ01QIGFu ZCB3aGF0IGlmIGFueSBvZiB0aGUgdGVjaG5pcXVlcw0KICAgIGFyZSBhdmFpbGFibGUgdG8gdGhv c2Ugb3BlcmF0b3JzIG9uIHRoZWlyIGV4aXN0aW5nIGtpdC4gU28gZXZlbiB0aG91Z2gNCiAgICBJ IGFtIGluIGFncmVlbWVudCB3aXRoIHlvdSwgSSBkb27igJl0IHRoaW5rIHNlcXVlbmNlIG51bWJl cnMgY2FuIGJlDQogICAgZGlzbWlzc2VkIHNvIGVhc2lseSAoYXMgbXkgYWdyZWVtZW50IGlzIGJh c2VkIHVwb24gbXkgb3duIGNvbmUgb2YNCiAgICB2aXNpb24gd2hpY2ggSSBrbm93IGlzIHZlcnkg bGltaXRlZCkgZm9yIGFsbCB0aGUgZXhpc3Rpbmcga2l0DQogICAgb3BlcmF0b3JzIGhhdmUgZGVw bG95ZWQgdGhhdCBwb3NzaWJseSBzdXBwb3J0cyBzZXF1ZW5jaW5nLg0KICAgIA0KICAgIA0KICAg ID4+IFN1cHBvcnRpbmcgRkFUIGFuZCBFTEkgaXMgYSBzdGF0ZWxlc3Mgb3BlcmF0aW9uIHRoYXQg YW55IGZvcndhcmRpbmcNCiAgICA+PiBhcmNoaXRlY3R1cmUgSSBjYW4gdGhpbmsgb2YgY2FuIHN1 cHBvcnQuDQogICAgPj4NCiAgICA+PiBTdXBwb3J0aW5nIFMvTiBpcyBzdGF0ZWZ1bC4gVGhpcyBp cyBoYXJkIHRvIHNvIGF0IHNwZWVkLCBhbmQgbWF5IGZvcmNlIHRoZQ0KICAgID4+IGltcGxlbWVu dGVyIHRvIGEgc3BlY2lmaWMgZm9yd2FyZGluZyBhcmNoaXRlY3R1cmUgKGVncmVzcyBwYWNrZXQg ZmlsdGVyaW5nKS4NCiAgICA+Pg0KICAgID4+IEdpdmVuIHRoZSBhYm92ZSBJIGFtIG5vdCBpbiBm YXZvdXIgb2YgaW5jbHVkaW5nIHRoZSB0ZXh0IG9uIENXIFMvTi4NCiAgICANCiAgICBJIGNhbid0 IGNvbW1lbnQgb24gaG93IGhhcmQgaXQgaXMgb3IgaXNuJ3QgdG8gaW1wbGVtZW50IHNlcXVlbmNl DQogICAgbnVtYmVycyBhcyBJIHBlcnNvbmFsbHkgaGF2ZW7igJl0IHRyaWVkIHRvIGNvZGUgdGhp cy4gQWx0aG91Z2ggZXZlbg0KICAgIHdpdGhvdXQgdHJ5aW5nIEkgY2FuIHVuZGVyc3RhbmQgdGhh dCBpdCBhZGRzIGluIG1vcmUgc3RhdGUgdG8gdGhlIGVkZ2UNCiAgICBkZXZpY2VzLCBhbHRob3Vn aCBkZWJhdGFibHkgbm90IGFsb3QgbW9yZTsgUkZDNDM4NSBwcm92aWRlcyBhbiBleGFtcGxlDQog ICAgdXNpbmcgdHdvIDE2IGJpdCBjb3VudGVycyBhbmQgMiBib29sZWFucy4gSSB3b3VsZCBleHBl Y3QgYW55DQogICAgcmVhc29uYWJsZSBwc2V1ZG93aXJlIGltcGxlbWVudGF0aW9uIHRvIGhhdmUg MzIgb3IgNjQgYml0IGNvdW50ZXJzIGZvcg0KICAgIHBhY2tldHMgc2VudCwgcmVjZWl2ZWQsIGJ5 dGVzIHNlbnQsIHJlY2VpdmVkLCBkcm9wcyBvbiB0eCwgcngsIGFzIHdlbGwNCiAgICBhcyBtYW55 IG90aGVycyBmb3IgdXB0aW1lLCBsYXN0IHN0YXRlIGNoYW5nZSwgZXRjIGV0Yy4uLiBJIGRvbid0 IHRoaW5rDQogICAgaXQgaXMgd2lzZSB0byBiZSBmbGlwcGFudCB3aXRoIGRldmljZSByZXNvdXJj ZXMgYnV0IGluIHJlbGF0aXZlIHRlcm1zDQogICAgSSBjYW7igJl0IHNlZSBpdCBiZWluZyAvdGhh dC8gbXVjaCBzdGF0ZS4NCiAgICANCiAgICBBbHNvIGFzIEkgc2FpZCBpbiBteSBmaXJzdCBwYXJh Z3JhcGgsIGlmIHNlcXVlbmNlIG51bWJlcnMgYXJlIHN1cHBvcnQNCiAgICBpbiBzYXkgQ2lzY28g SU9TIGZvciBleGFtcGxlLCB0aGUgdm9sdW1lIG9mIGV4aXN0aW5nIGRldmljZXMgdGhhdCBtYXkN CiAgICBzdXBwb3J0IFBXTUNXIHNlcXVlbmNlIG51bWJlcnMgYW5kIG5vdCBGQVQgYW5kIG5vdCBF TEkgY291bGQgYmUgbGFyZ2UsDQogICAgc28gSSB3b3VsZCB0aGluayBpdCB3b3J0aCB3aGlsZSB0 byBpbmNsdWRlIHNlcXVlbmNlIG51bWJlcnMgYXMgYSBsYXN0DQogICAgcmVzb3J0IHJlY29tbWVu ZGF0aW9uIHRvIHRoZSBvcGVyYXRvci4NCiAgICANCiAgICBBZ2FpbiwgSSBhbSBpbiBmdWxsIGFn cmVlbWVudCB3aXRoIHlvdXIgcmVjb21tZW5kYXRpb24gZm9yIEZBVCBvciBFTEkNCiAgICBkZXNw aXRlIG15IGxlbmd0aHkgZW1haWwgKHNvcnJ5ISkgaG93ZXZlciwgSSB3b3VsZCBsaWtlIHRvIHVu ZGVyc3RhbmQNCiAgICBjbGVhcmx5IGlmL3doZW4vd2h5IHNlcXVlbmNlIG51bWJlcnMgc2hvdWxk buKAmXQgYmUgdXNlZC4NCiAgICANCiAgICBDaGVlcnMsDQogICAgSmFtZXMuDQogICAgDQogICAg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBQYWxz IG1haWxpbmcgbGlzdA0KICAgIFBhbHNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3BhbHMNCiAgICANCg0K From nobody Mon Nov 13 19:30:30 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA493128D64 for ; Mon, 13 Nov 2017 19:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cienacorp.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 wYmBDa4zAeu1 for ; Mon, 13 Nov 2017 19:30:16 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0069.outbound.protection.outlook.com [104.47.37.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9D021242EA for ; Mon, 13 Nov 2017 19:30:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cienacorp.onmicrosoft.com; s=selector1-ciena-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Oz1CXQlMm7h9AaVUkOcOoB2CBNZN6Mgo4IBXyscxmG0=; b=g0WGImiUN7LyDdXGnuOkkzoOeznLKFciFCAR0hRrgqnlJeH4beLKLx+OrJQdZBASMTZgfuaJgqGze9RhUoArcjmxBYRw7jyC+nXHJEOuD3C+IdAZwyMzCPKRcc5k7K5FePJZGL4fkK3b7K+02Kcwwn2fwHcG+Y1gnWZ0fSLJAkQ= Received: from MWHPR0401MB3562.namprd04.prod.outlook.com (10.167.162.153) by MWHPR0401MB3563.namprd04.prod.outlook.com (10.167.162.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.218.12; Tue, 14 Nov 2017 03:30:13 +0000 Received: from MWHPR0401MB3562.namprd04.prod.outlook.com ([fe80::905b:4368:8f0d:ccb0]) by MWHPR0401MB3562.namprd04.prod.outlook.com ([fe80::905b:4368:8f0d:ccb0%13]) with mapi id 15.20.0218.015; Tue, 14 Nov 2017 03:30:13 +0000 From: "Shah, Himanshu" To: "pals@ietf.org" Thread-Topic: ELI/EL for the PW Thread-Index: AQHTXPjhN3Lj0skIK0+jGZ6pug03Ng== Date: Tue, 14 Nov 2017 03:30:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 authentication-results: spf=none (sender IP is ) smtp.mailfrom=hshah@ciena.com; x-originating-ip: [2001:67c:370:128:e8ec:91ea:b294:b87c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR0401MB3563; 6:C+wImgq1nije5vOrk28RJ6N5/0MMZt57f4iP1/T53VzWOQXpUpmvvmS3Y6WrvdlvlK014b491qSoVWmCengB0GLO21C25+d6ygOdw59kRj+7KW2EF9K/iU0dP15guwncsxweBaK2ne9ppAklRSWlC44RQkV/R8aKuhLguBS7QVEs5Iw1IXvOoXTF4ismNOX0RM1pslJCIauqPxkejWXx0WQ1AvSD2vbhEAIu8KjePqOwPZY2D5P6YuOfmqZzojnURDg+tvqKiV99GOlTs33DhNbc/dJZFE3VismfjfaY2uxT+Z5ewPMXICpSXL7ByAw+I4CyRZhy9GlsnVVk1e7bqRg82o6ZhhBxWw8N+c6yMDw=; 5:AJFsN4MdQ6PkT8MRYZ19/d1tHWZ4ho8F95I41hTCCvGFm42AUH5ogOfb4THFFWsv5GvTk2/+0iy1mg8TwS7v9mW2h6FpasTDXd5velv2bSgQ5+S8Ir1lEUi1r1y5a4E5rNiyw7X47C+iHn92uvL4rAWGN4IAuqH6HAb6UsKVK8Q=; 24:RByM+e9pNNc097SM1+5cwonKo66VVZzSBkcCdEx2okjrYI+PKqAPWele353ladIfBQo4PwIJHrPt7HUSpeMjHGnNfkP9Mv2G6/m/9HqAqmk=; 7:FutkOcYwWV1p88ZQdJto5pzFCPmlXtZrq2ihFxk3Khl/07Aw1gu3xjwV7G4fuTuqWMnNk51lLSfok5tpvEa5+pe+pLtFFh7k5Ayk3Mq8mqo4a98magPTFlbsSf8N47dKJABBQzR0mK68D++gaiHHgOXmyi3E5MwHbmVzWJs99DxO8PUo+smMOezOgwiUh4aOYuqDPztVifIGJCZF1DXUXWeG8R0Va/g/Ln4IRZ+pAXT82Tg8tNXB6hwGCRrxVIbS x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 36c2a48f-7e65-4d1a-b461-08d52b10044a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:MWHPR0401MB3563; x-ms-traffictypediagnostic: MWHPR0401MB3563: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(3002001)(3231022)(93006095)(93001095)(6041248)(20161123558100)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR0401MB3563; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR0401MB3563; x-forefront-prvs: 04916EA04C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(376002)(346002)(199003)(189002)(2900100001)(316002)(54356999)(50986999)(81166006)(81156014)(6436002)(1730700003)(101416001)(8676002)(2501003)(7736002)(6506006)(14454004)(3480700004)(2906002)(8936002)(5640700003)(189998001)(58126008)(53936002)(68736007)(83506002)(106356001)(36756003)(82746002)(99286004)(6116002)(2351001)(105586002)(97736004)(33656002)(86362001)(6306002)(6916009)(102836003)(6486002)(5250100002)(5660300001)(3280700002)(478600001)(3660700001)(54896002)(6512007)(25786009)(83716003); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR0401MB3563; H:MWHPR0401MB3562.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ciena.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_EE709087637C4647ABB8DA5FFAE45D7Dcienacom_" MIME-Version: 1.0 X-OriginatorOrg: ciena.com X-MS-Exchange-CrossTenant-Network-Message-Id: 36c2a48f-7e65-4d1a-b461-08d52b10044a X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2017 03:30:13.2862 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 457a2b01-0019-42ba-a449-45f99e96b60a X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR0401MB3563 Archived-At: Subject: [Pals] ELI/EL for the PW X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 03:30:18 -0000 --_000_EE709087637C4647ABB8DA5FFAE45D7Dcienacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIFBBTFMgV0cgZGlzY3Vzc2lvbnMgeWVzdGVyZGF5IGF0IHRoZSBJRVRGMTAwLCB3ZSBkaXNj dXNzZWQgdGhlIGNvbXBldGluZw0KRkFUIFBXIGFuZCBFTEkvRUwgZm9yIHRoZSBQVyBhbmQgaXRz IGZhdGUgYXQgUy1QRS4NCg0KSSBtZW50aW9uZWQgdGhpcyBhdCBNaWtlIGJ1dCBnb3QgbG9zdCBp biBzdWJzZXF1ZW50IGRpc2N1c3Npb25zLg0KDQpGQVQgUFcgbGFiZWwgYXMgd2VsbCBhcyBFTEkv RUwgZm9yIFBXIChiYXNlZCBvbiBtaWNyb2Zsb3cgd2l0aGluIFBXKSByZXNpZGVzDQpiZWxvdyBQ VyBsYWJlbC4gVGh1cywgQGluZ3Jlc3MgUEUsIG9uY2UgbWljcm9mbG93IGlzIGlkZW50aWZpZWQs IGVpdGhlciBFTEkvRUwNCm9yIEZBVCBQVyBsYWJlbCBpcyBwdXNoZWQuDQoNCkBTLVBFLCBQVyBs YWJlbCBzd2FwIGRvZXMgbm90IGhhdmUgdG8gcHJlc2VydmUgdGhlIEVMSS9FTCB3aGlsZSBkb2lu ZyBQVyBsYWJlbCBzd2FwcGluZywNCkJFQ0FVU0UgaXQgaXMgYWxyZWFkeSBiZWxvdyB0aGUgUFcg bGFiZWwsIGp1c3QgbGlrZSBob3cgRkFUIFBXIGxhYmVsIHdvdWxkIGJlLg0KDQpJIGNvbmZpcm1l ZCB0aGlzIGZyb20gb3VyIGRhdGEgcGxhbmUgZW5naW5lZXIuDQood2UgY2FuIGNoZWNrIHdpdGgg S2lyZWV0aSBhcyB3ZWxsKQ0KDQpJIHdvdWxkIGxpa2UgdG8ga25vdyBpZiBvdGhlciB2ZW5kb3Jz IGFyZSBkb2luZyB0aGlzIGRpZmZlcmVudGx5Pz8NCg0KR2l2ZW4gdGhpcyBpcyB0cnVlLCBmb3Ig dGhlIHN3aXRjaGVzIHRoYXQgZG8gRFBJIHBhc3QgUFcgY29udHJvbCB3b3JkIGZvciBFQ01QLA0K DQogICogICBGQVQgUFcgbGFiZWwgd291bGQgc3VmZmVyIHRoZSBzYW1lIG1pc29yZGVyaW5nIGFz IG5vIEZBVCBQVyBsYWJlbA0KICAqICAgSG93ZXZlciwgRUxJL0VMIHdvdWxkIE5PVCDigJMgYmVj YXVzZSBvZiB0aGUgcHJlc2VuY2Ugb2YgRUxJDQoNClRoYW5rcywNCkhpbWFuc2h1DQo= --_000_EE709087637C4647ABB8DA5FFAE45D7Dcienacom_ Content-Type: text/html; charset="utf-8" Content-ID: <0B8ED4E9689C394BB6A2BA8A0878105F@namprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIg MTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu TXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3Jh cGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIsc2Fucy1zZXJpZjsNCglj b2xvcjojMDQzMkZGOw0KCWZvbnQtc3R5bGU6aXRhbGljO30NCnNwYW4ubXNvSW5zDQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NDM4 NzY1NzI2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczox NjI0MTI5NjQyIDMzMDczODkzOCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2 NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ29uc29sYXMiLHNhbnMtc2VyaWY7 DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGwwOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IixzZXJpZjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0i d2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvbnNvbGFzJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0 MzJGRiI+VGhlIFBBTFMgV0cgZGlzY3Vzc2lvbnMgeWVzdGVyZGF5IGF0IHRoZSBJRVRGMTAwLCB3 ZSBkaXNjdXNzZWQgdGhlIGNvbXBldGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q29uc29s YXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGIj5GQVQgUFcgYW5kIEVMSS9FTCBmb3Ig dGhlIFBXIGFuZCBpdHMgZmF0ZSBhdCBTLVBFLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q29u c29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvbnNvbGFzJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+SSBt ZW50aW9uZWQgdGhpcyBhdCBNaWtlIGJ1dCBnb3QgbG9zdCBpbiBzdWJzZXF1ZW50IGRpc2N1c3Np b25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDQzMkZGIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvbnNvbGFzJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+RkFUIFBXIGxhYmVsIGFzIHdlbGwgYXMgRUxJ L0VMIGZvciBQVyAoYmFzZWQgb24gbWljcm9mbG93IHdpdGhpbiBQVykgcmVzaWRlczxvOnA+PC9v OnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZG Ij5iZWxvdyBQVyBsYWJlbC4gVGh1cywgQGluZ3Jlc3MgUEUsIG9uY2UgbWljcm9mbG93IGlzIGlk ZW50aWZpZWQsIGVpdGhlciBFTEkvRUw8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvbnNvbGFz JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+b3IgRkFUIFBXIGxhYmVsIGlzIHB1c2hl ZC48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvbnNvbGFzJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzA0MzJGRiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb25zb2xhcyZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPkBTLVBFLCBQVyBsYWJlbCBzd2FwIGRvZXMgbm90 IGhhdmUgdG8gcHJlc2VydmUgdGhlIEVMSS9FTCB3aGlsZSBkb2luZyBQVyBsYWJlbCBzd2FwcGlu Zyw8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvbnNvbGFzJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzA0MzJGRiI+QkVDQVVTRSBpdCBpcyBhbHJlYWR5IGJlbG93IHRoZSBQVyBsYWJlbCwganVz dCBsaWtlIGhvdyBGQVQgUFcgbGFiZWwgd291bGQgYmUuPG86cD48L286cD48L3NwYW4+PC9pPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb25zb2xhcyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZG Ij5JIGNvbmZpcm1lZCB0aGlzIGZyb20gb3VyIGRhdGEgcGxhbmUgZW5naW5lZXIuPG86cD48L286 cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb25zb2xhcyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYi Pih3ZSBjYW4gY2hlY2sgd2l0aCBLaXJlZXRpIGFzIHdlbGwpPG86cD48L286cD48L3NwYW4+PC9p PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb25zb2xhcyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQz MkZGIj5JIHdvdWxkIGxpa2UgdG8ga25vdyBpZiBvdGhlciB2ZW5kb3JzIGFyZSBkb2luZyB0aGlz IGRpZmZlcmVudGx5Pz88bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvbnNvbGFzJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b25zb2xhcyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPkdpdmVuIHRoaXMgaXMgdHJ1 ZSwgZm9yIHRoZSBzd2l0Y2hlcyB0aGF0IGRvIERQSSBwYXN0IFBXIGNvbnRyb2wgd29yZCBmb3Ig RUNNUCwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6 MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9ImNv bG9yOiMwNDMyRkY7bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxp PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb25zb2xhcyZxdW90OyxzYW5zLXNlcmlm Ij5GQVQgUFcgbGFiZWwgd291bGQgc3VmZmVyIHRoZSBzYW1lIG1pc29yZGVyaW5nIGFzIG5vIEZB VCBQVyBsYWJlbDxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9ImNvbG9yOiMwNDMyRkY7bWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omww IGxldmVsMSBsZm8xIj4NCjxpPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb25zb2xh cyZxdW90OyxzYW5zLXNlcmlmIj5Ib3dldmVyLCBFTEkvRUwgd291bGQgTk9UIOKAkyBiZWNhdXNl IG9mIHRoZSBwcmVzZW5jZSBvZiBFTEk8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9saT48L3VsPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv bnNvbGFzJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvbnNvbGFzJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzA0MzJGRiI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb25zb2xhcyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPkhpbWFuc2h1 PC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_EE709087637C4647ABB8DA5FFAE45D7Dcienacom_-- From nobody Tue Nov 14 04:14:39 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE14012704B for ; Tue, 14 Nov 2017 04:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.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 Cb5OIEh8R4av for ; Tue, 14 Nov 2017 04:14:36 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.174]) (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 9E70912420B for ; Tue, 14 Nov 2017 04:14:35 -0800 (PST) Received: from [85.158.138.179] by server-14.bemta-3.messagelabs.com id 4C/B1-00431-92EDA0A5; Tue, 14 Nov 2017 12:14:33 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTcRTH97v3brsOb1w3zdNSqpX5KKelhEG BYZRBQRBUSFF3dttG27TdGcuiFFJLRa2kMgWVdIiaj/UgW5YMAzW08pFZraS0hxYVKysI6V7v tPrnx+d8z/d3fuf8OCSufCBTk6zdxlotjEkjUxDxSxL3Roe/VKTEFp+nEm63NqCExukmLBFL7 h2ZJpJran5h27EUqdGiS7PvlxouVTnl6T1b7WVVtdIs1LQxHylIgs7FwZHfSwiBki7FYCKvWC YGowgKcmvl+ciPlNHrwdngkQkcSG+GAe8HXGAVHQZfmp/49OXQ+DZbLvJq6L9yAQlM8J7as4O 8hyQpeg9Ul8xYlPQ6KB24hgnsx5d3t9YTAiN6PvzoaZzRcToYno1VzjDQNNTceYiLHAQf3kxL Rb8OXo1XI1FfDA873/s8odBfWYCEWYB2y6Hxgddn0sKNs598vA1aeoswoTegl8L193tFv4Ofv f27XPREwfC9Llz0HIJrF4Jm5dOdlzHR75FC4akiX6Mh0FGRI/M9LIXsn5O+iVOhq8JLiB+nBs /gGVSCoi7/M6jIFmhzTMkEpugA6C4bI0Q9Fj73VeIirwBH9aSPY6D1Wy/6V69C8noUwbHWI6w 1elWsVmc16g02M2M08VGc1sxyHKNnTYyO06ammZ2IX6aTEgm6hW7mJ7nRAhLTBFHLvPIU5Txd 2oGjBoYz7LNmmFjOjUJIUgNUmEeRogywsnrWftBo4jdyNg2kvyaQihHSFJfOmDmjXkz1oLVky 4jnN0benTnflk1m4UrCkmZh1cFUknCBFi4YMixz5WZ3vB+FqlUUkkgkSv901mo22v7PT6BgEm lU1CKhir/RYpt7dYJvCOMbUguzUJyN+ZtSZ6E1iVuzk1y1G+IWNxS90F7McB3uC23OLHG3BSV rHjsNoZ076ge5kYjId96acNeQ3t2eo1oau6uw5wQ1XnfP5cp8NHBzY1S5vyHg41Vvuao7qy9O eqTu9Tnv6ELUMbZlU979Fge3e+jX0PGnd507y1dK4qe+ugrsiufcsfhI+ZrcYQ3BGZhVUbiVY /4AApd7L94DAAA= X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-15.tower-169.messagelabs.com!1510661666!126142069!1 X-Originating-IP: [52.33.64.93] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 7168 invoked from network); 14 Nov 2017 12:14:29 -0000 Received: from ec2-52-33-64-93.us-west-2.compute.amazonaws.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (52.33.64.93) by server-15.tower-169.messagelabs.com with AES256-SHA256 encrypted SMTP; 14 Nov 2017 12:14:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=N6bQh33rZ0Nt01c7yziKZ2wxx0Zq3kWwMDMdjSm0A3c=; b=RKx3V4GSq4jc32rV1Zf3F6CDGlUW1xDP6LjuMs2vWhqB0TilG3EKEeWQQeDBRvRKns5jjiWagXNn4T2yYzBtKYmQkedqnURZDD4OOHSh9+S1uqxxB13BoCr/Y1Dyucc/X4HAPOpL7fAdGzwEZCFHh6cHuaUGQM/WxvBJDzufShM= Received: from HE1PR03MB1722.eurprd03.prod.outlook.com (10.166.66.144) by HE1PR03MB1723.eurprd03.prod.outlook.com (10.166.66.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.218.12; Tue, 14 Nov 2017 12:14:24 +0000 Received: from HE1PR03MB1722.eurprd03.prod.outlook.com ([fe80::a03b:dba9:da5c:12ce]) by HE1PR03MB1722.eurprd03.prod.outlook.com ([fe80::a03b:dba9:da5c:12ce%14]) with mapi id 15.20.0218.011; Tue, 14 Nov 2017 12:14:24 +0000 From: Alexander Vainshtein To: "pals@ietf.org" , "Shah, Himanshu" Thread-Topic: [Pals] ELI/EL for the PW Thread-Index: AQHTXPjhN3Lj0skIK0+jGZ6pug03NqMTykaA Date: Tue, 14 Nov 2017 12:14:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [52.169.16.87] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR03MB1723; 6:Jd3MN13AeoJRdkeS90KERAv8DwpzxZvoE+Zkcj9NFDJsJFF4kBZfZRTYnG2CD0il7kwb/V+fpAoeG/BS7OpVGMlP4jgWZuF3mSIpI4GcadnimWKMAvRkgXhfZnPJvxPg1CmK7RnRXrKW4seEaj6GI3vqlb3HD874DDDN/Fjki1H5BAobZ/djqBS3jNmqoAY1l8SBZNC40rdgDPNEOxk05S4pqN5wwcBf+Sj62FcBRShrgNNZj2oskDsfxw0rI8lml278bQX4cQWv22VVw67f8yk5STE4R0h8dDpAgETg3Fe6zrPVbr1vZWfuha+Xmx8ofk1hAZ2MKQ9YYS6AYcm5h6jl52/LfRNxUOgI0eI+htI=; 5:uQWmmDzK8QaR8ksHBujXZDK+xOUX3Avdrcki+IEKuQ/UaCnggVqPx53lkKdQNREqHZvx2qyAeS+zDnorkkmA7q+F3JaAM/2WF9gL7A6bww/K9aXa4+QThE/6135zSxttYF4SnZqfiM17AGrsfRM2VkEunrUGv1b00KQIKCn50k4=; 24:qt3qO/8PPwbKKnFQJ9cfJUeW5jf10YivKfRtcWbisabsWAFpYCqQlYSEGSP+MUY+ki10UzK3rq4fMMRIi0GDZKS+yge/qfiAV9BHAg3v6zY=; 7:yI5fl2BrIIZZMKUzv5WPzKz/uyIZe3044tC/moTnMYlY3N1UVAhZ4zR3Boc+xEj0tOi4fS9Go4vswcqF6LL4wRPShkvGvF8A6wvVikO3Fio2trrbY09pJ7BY4/EHy/4VDSRBVOyImW4SufWOsiZIkjCZNp/SQZDDCN91JoRtRhhkNpTp+VrRg3CH96YcEFA7pbFccdO4aHhX5jVhuxuTYEB2+AuwcyoAtRpMKFiNYr3Y0RJA5sFO3b1YYA+/9vPX x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8f50b1fd-9d27-46b3-e99d-08d52b593e9c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:HE1PR03MB1723; x-ms-traffictypediagnostic: HE1PR03MB1723: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231022)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR03MB1723; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR03MB1723; x-forefront-prvs: 04916EA04C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(189002)(199003)(72206003)(101416001)(86362001)(2501003)(99286004)(106356001)(105586002)(53546010)(6246003)(68736007)(3660700001)(3280700002)(53936002)(2906002)(478600001)(33656002)(5660300001)(8936002)(8676002)(81166006)(14454004)(81156014)(25786009)(97736004)(2950100002)(54896002)(50986999)(7696004)(55016002)(189998001)(2900100001)(6436002)(66066001)(74316002)(6506006)(5250100002)(76176999)(9686003)(229853002)(110136005)(7736002)(316002)(54356999)(102836003)(6116002)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR03MB1723; H:HE1PR03MB1722.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR03MB17223A1FC7707363B423E00C9D280HE1PR03MB1722eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8f50b1fd-9d27-46b3-e99d-08d52b593e9c X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2017 12:14:24.4878 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR03MB1723 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pals] ELI/EL for the PW X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 12:14:38 -0000 --_000_HE1PR03MB17223A1FC7707363B423E00C9D280HE1PR03MB1722eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Himamshu and all, I respetfully disagree. As I see it, RFC 6790 in Section 4.2 Ingress LSR" inambiguously states tha= t EL and ELI, if used, between thr TL and "application label" (if spplicat= ion lsbel is used). It also specifies, that EL and ELI are only pushed on = an incoming packet if the tunnel egress LSR has signaled that it can handl= e EL on the specific tunnel LSP it terminates. To me this means that in the case of a MS-PW, EL and ELI CANNOT preserved = by an S-PE. Whether they can be generated by an SPE is another story. FAT labels, on the contrary, are always the BoS labels and thrrfore are pr= eserved by SPEs of a MS-PW. Did I miss something substantial? Thump typed by Sasha Vainshtein ________________________________ From: Pals on behalf of Shah, Himanshu Sent: Tuesday, November 14, 2017 5:30:13 AM To: pals@ietf.org Subject: [Pals] ELI/EL for the PW The PALS WG discussions yesterday at the IETF100, we discussed the competi= ng FAT PW and ELI/EL for the PW and its fate at S-PE. I mentioned this at Mike but got lost in subsequent discussions. FAT PW label as well as ELI/EL for PW (based on microflow within PW) resid= es below PW label. Thus, @ingress PE, once microflow is identified, either EL= I/EL or FAT PW label is pushed. @S-PE, PW label swap does not have to preserve the ELI/EL while doing PW l= abel swapping, BECAUSE it is already below the PW label, just like how FAT PW label would= be. I confirmed this from our data plane engineer. (we can check with Kireeti as well) I would like to know if other vendors are doing this differently?? Given this is true, for the switches that do DPI past PW control word for = ECMP, * FAT PW label would suffer the same misordering as no FAT PW label * However, ELI/EL would NOT =96 because of the presence of ELI Thanks, Himanshu __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may=20be proprietary to ECI Telecom. If you have re= ceived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_HE1PR03MB17223A1FC7707363B423E00C9D280HE1PR03MB1722eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =
Himamshu and all,
I respetfully disagree.

As I see it, RFC 6790 in Section 4.2 Ingress LSR" inambiguously state= s that EL and ELI, if used, between thr TL and "application label&quo= t; (if spplication lsbel is used). It also specifies, that EL and ELI are = only pushed on an incoming packet if the tunnel egress =20LSR has signaled that it can handle EL on the specific tunnel LSP it te= rminates.

To me this means that in the case of a MS-PW, EL and ELI CANNOT preserved = by an S-PE. Whether they can be generated by an SPE is another story.

FAT labels, on the contrary, are always the BoS labels and thrrfore are pr= eserved by SPEs of a MS-PW.

Did I miss something substantial?


Thump typed by Sasha Vainshtein

From: Pals <pals-bounc= es@ietf.org> on behalf of Shah, Himanshu <hshah@ciena.com>
Sent: Tuesday, November 14, 2017 5:30:13 AM
To: pals@ietf.org
Subject: [Pals] ELI/EL for the PW
 

The PALS WG discussions yesterday at the IETF10= 0, we discussed the competing

FAT PW and ELI/EL for the PW and its fate at S-= PE.

 

I mentioned this at Mike but got lost in subseq= uent discussions.

 

FAT PW label as well as ELI/EL for PW (based on= microflow within PW) resides

below PW label. Thus, @ingress PE, once microfl= ow is identified, either ELI/EL

or FAT PW label is pushed.

 

@S-PE, PW label swap does not have to preserve = the ELI/EL while doing PW label swapping,

BECAUSE it is already below the PW label, just = like how FAT PW label would be.

 

I confirmed this from our data plane engineer.<= /span>

(we can check with Kireeti as well)<= /p>

 

I would like to know if other vendors are doing= this differently??

 

Given this is true, for the switches that do DP= I past PW control word for ECMP,

  • FAT PW label = would suffer the same misordering as no FAT PW label
  • However, ELI/EL wou= ld NOT =96 because of the presence of ELI

 

Thanks,

Himanshu


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_HE1PR03MB17223A1FC7707363B423E00C9D280HE1PR03MB1722eurp_-- From nobody Tue Nov 14 17:25:01 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF8C126CD6 for ; Tue, 14 Nov 2017 17:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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=cienacorp.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 eDwDaxf6SXpk for ; Tue, 14 Nov 2017 17:24:56 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0075.outbound.protection.outlook.com [104.47.40.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76EFE12943C for ; Tue, 14 Nov 2017 17:24:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cienacorp.onmicrosoft.com; s=selector1-ciena-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XDJhVxJPbkgfl4/+dHlGPwC9X4LnA/wLM2mxM6tNvqY=; b=jlKhOavNtZZ1Sz1RrPAs6LvoPyXflDBst/ReZ/HKCfQoo9/rThoyPcFZq5q6GgD2tLUTmeD1GpuBQDcbyV6l8u9Sgqu5xBioFRDGFTt8qVPz+ejWwV2UwTNMWTsOrawf109R13Llt315gzOeuFr+C6glVBXPYmh1e0up4Zt4mEA= Received: from MWHPR0401MB3562.namprd04.prod.outlook.com (10.167.162.153) by MWHPR0401MB3563.namprd04.prod.outlook.com (10.167.162.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.218.12; Wed, 15 Nov 2017 01:24:54 +0000 Received: from MWHPR0401MB3562.namprd04.prod.outlook.com ([fe80::905b:4368:8f0d:ccb0]) by MWHPR0401MB3562.namprd04.prod.outlook.com ([fe80::905b:4368:8f0d:ccb0%13]) with mapi id 15.20.0218.015; Wed, 15 Nov 2017 01:24:54 +0000 From: "Shah, Himanshu" To: Alexander Vainshtein , "pals@ietf.org" Thread-Topic: [Pals] ELI/EL for the PW Thread-Index: AQHTXPjhN3Lj0skIK0+jGZ6pug03NqMTykaAgAFi9YA= Date: Wed, 15 Nov 2017 01:24:54 +0000 Message-ID: <741BDF3F-C90F-44FF-AD59-A29CF612FBBD@ciena.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 authentication-results: spf=none (sender IP is ) smtp.mailfrom=hshah@ciena.com; x-originating-ip: [2001:67c:1232:144:b104:16e2:a28b:5544] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR0401MB3563; 6:8deBQQOWa8oTdOKnrKYUKhOGfeSx076iEdsJGHWF+Y7WeXbEjEZuuMkhKRLOnKEkUFmIQZnaLoZg1hWXeyFXkgRfOG+MorHBUEZf0J7e68rsRbUsiLXpbiUzpK4BJ5efe9LgPhm8poa12BUW2/IC4u8KxM3e0+edf22l2RJEmFQBYTN/hBZSCM06xtkxBrivu8G9weD38yEBM+AOEwk9uxeLe5bnVwPKiahRu4tJ1jrCH1+1WFKhRAqxqV+R91jXLB+UijqphanOKMukLUj2jtwerADytWNopEBfhu/0LySP/9b3KmqrB0uK4syJvzxuPPJtOrqjsud4CJCmow+413H+TpNFNMO53Z4kdayYhPM=; 5:NlAO5nWxvrPHyvbDaxAak0kG+vKBzrsAIEVgr9JNX/JGiMYnOuQt638+Hrrb8EQxOOsGoRk43rIE9iCtThQhB1hpwVjDtdcaxd7Y/t5Nqbteb06Hyeq1abg0wbsYk7x6TMRlu1Rww4naa5QJ2HUgDIzH8lLOeCWjr2ZXXjxIdr4=; 24:yte3lErr5RJbL4xCL0iR/8mGJ8RvGMa0jJH6TWJexDa5JBQOVzr7ddxcDL6dkBZLS3OqouySDuPFZ7AYF+aPlnQ3BjtlKLYyl079wNvkv5Y=; 7:M3Bu1y97VLDfj7BDZvkw7rMIiPYXU0jhl4Th5vMUl3geH36dSmde7N/vyFA+GUmdQjNnAtDUO2QeWSMENvb8OgWpw8i2OCRXACuJ6lE4EGE2u/bqQUXiY7Dnelst1NEiIKvLA8LxAlVi0Q1Ju4pBQUVaYBHpPpdEUbo7WPaGqj78ZqKiSe+0xxoCjJs272vjdpxsCi8xQPDgOZf8b4ihXPvDOwbnpYvYXmgNLV3iei6IYYt9uOlG8Yw6rHTjv1n7 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ab658e70-304e-4164-b31e-08d52bc7ad40 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:MWHPR0401MB3563; x-ms-traffictypediagnostic: MWHPR0401MB3563: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227612066756510)(21748063052155)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(3231022)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6041248)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR0401MB3563; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR0401MB3563; x-forefront-prvs: 0492FD61DD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(199003)(189002)(6436002)(101416001)(316002)(76176999)(54356999)(8676002)(81166006)(81156014)(2501003)(6506006)(7736002)(2900100001)(9326002)(14454004)(2906002)(8936002)(58126008)(189998001)(110136005)(53936002)(68736007)(83506002)(106356001)(36756003)(50986999)(53546010)(82746002)(99286004)(105586002)(6116002)(97736004)(5250100002)(6486002)(102836003)(54896002)(229853002)(33656002)(86362001)(6306002)(5660300001)(3280700002)(478600001)(3660700001)(6512007)(25786009)(6246003)(2950100002)(83716003); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR0401MB3563; H:MWHPR0401MB3562.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ciena.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_741BDF3FC90F44FFAD59A29CF612FBBDcienacom_" MIME-Version: 1.0 X-OriginatorOrg: ciena.com X-MS-Exchange-CrossTenant-Network-Message-Id: ab658e70-304e-4164-b31e-08d52bc7ad40 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2017 01:24:54.5946 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 457a2b01-0019-42ba-a449-45f99e96b60a X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR0401MB3563 Archived-At: Subject: Re: [Pals] ELI/EL for the PW X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 01:24:59 -0000 --_000_741BDF3FC90F44FFAD59A29CF612FBBDcienacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2hhc2hhLA0KDQpZb3UgYXJlIGNvcnJlY3QgYWJvdXQgaG93IGl0IGlzIHdyaXR0ZW4gaW4g UkZDIDY3OTAuDQoNCkkgZGlkIHRhbGsgdG8gS2lyZWV0aSBicmllZmx5IGluIHRoZSBoYWxsd2F5 IGFib3V0IHBsYWNlbWVudCBvZiBFTEkvRUwgYW5kIE1TLVBXLg0KSGUgYWxzbyBkaWQgc2F5IHRo ZSBzYW1lIGJ1dCBoZSBhbHNvIHNhaWQgdGhhdCBpdCBkb2VzIG5vdCBtYXR0ZXIgd2hlcmUgeW91 IHBsYWNlIGl0LA0KYXMgZmFyIGFzIHByb2Nlc3Npbmcgb2YgdGhlIEVMSS9FTCwgd291bGQgd29y ayBpcnJlc3BlY3RpdmUuDQoNCk1TLVBXIHRlY2hub2xvZ3kgdGhyb3dzIHRoZSBtb25rZXkgcmFu Y2guDQpPbmUgY291bGQganVzdCBzdXBwb3J0IDY3OTAgYW5kIG5vdCA2MzkxIGZvciBQVyBpZiBF TEkvRUwgcGxhY2VkIGJlbG93IFBXIGxhYmVsLg0KSXQgc29sdmVzIHByZXNlcnZhdGlvbiBvZiBl bnRyb3B5IGFjcm9zcyBTLVBFLCBuaWNlbHkuDQoNClRoYW5rcywNCkhpbWFuc2h1DQoNCkZyb206 ICJBbGV4YW5kZXIgY29tPiIgPEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPg0KRGF0 ZTogVHVlc2RheSwgTm92ZW1iZXIgMTQsIDIwMTcgYXQgODoxNCBQTQ0KVG86ICJwYWxzQGlldGYu b3JnIiA8cGFsc0BpZXRmLm9yZz4sICJTaGFoLCBIaW1hbnNodSIgPGhzaGFoQGNpZW5hLmNvbT4N ClN1YmplY3Q6IFJlOiBbUGFsc10gRUxJL0VMIGZvciB0aGUgUFcNCg0KSGltYW1zaHUgYW5kIGFs bCwNCkkgcmVzcGV0ZnVsbHkgZGlzYWdyZWUuDQpBcyBJIHNlZSBpdCwgUkZDIDY3OTAgaW4gU2Vj dGlvbiA0LjIgSW5ncmVzcyBMU1IiIGluYW1iaWd1b3VzbHkgc3RhdGVzIHRoYXQgRUwgYW5kIEVM SSwgaWYgdXNlZCwgYmV0d2VlbiB0aHIgVEwgYW5kICJhcHBsaWNhdGlvbiBsYWJlbCIgKGlmIHNw cGxpY2F0aW9uIGxzYmVsIGlzIHVzZWQpLiBJdCBhbHNvIHNwZWNpZmllcywgdGhhdCBFTCBhbmQg RUxJIGFyZSBvbmx5IHB1c2hlZCBvbiBhbiBpbmNvbWluZyBwYWNrZXQgaWYgdGhlIHR1bm5lbCBl Z3Jlc3MgTFNSIGhhcyBzaWduYWxlZCB0aGF0IGl0IGNhbiBoYW5kbGUgRUwgb24gdGhlIHNwZWNp ZmljIHR1bm5lbCBMU1AgaXQgdGVybWluYXRlcy4NClRvIG1lIHRoaXMgbWVhbnMgdGhhdCBpbiB0 aGUgY2FzZSBvZiBhIE1TLVBXLCBFTCBhbmQgRUxJIENBTk5PVCBwcmVzZXJ2ZWQgYnkgYW4gUy1Q RS4gV2hldGhlciB0aGV5IGNhbiBiZSBnZW5lcmF0ZWQgYnkgYW4gU1BFIGlzIGFub3RoZXIgc3Rv cnkuDQpGQVQgbGFiZWxzLCBvbiB0aGUgY29udHJhcnksIGFyZSBhbHdheXMgdGhlIEJvUyBsYWJl bHMgYW5kIHRocnJmb3JlIGFyZSBwcmVzZXJ2ZWQgYnkgU1BFcyBvZiBhIE1TLVBXLg0KRGlkIEkg bWlzcyBzb21ldGhpbmcgc3Vic3RhbnRpYWw/DQoNClRodW1wIHR5cGVkIGJ5IFNhc2hhIFZhaW5z aHRlaW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IFBhbHMgPHBh bHMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFNoYWgsIEhpbWFuc2h1IDxoc2hhaEBj aWVuYS5jb20+DQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxNCwgMjAxNyA1OjMwOjEzIEFNDQpU bzogcGFsc0BpZXRmLm9yZw0KU3ViamVjdDogW1BhbHNdIEVMSS9FTCBmb3IgdGhlIFBXDQoNClRo ZSBQQUxTIFdHIGRpc2N1c3Npb25zIHllc3RlcmRheSBhdCB0aGUgSUVURjEwMCwgd2UgZGlzY3Vz c2VkIHRoZSBjb21wZXRpbmcNCkZBVCBQVyBhbmQgRUxJL0VMIGZvciB0aGUgUFcgYW5kIGl0cyBm YXRlIGF0IFMtUEUuDQoNCkkgbWVudGlvbmVkIHRoaXMgYXQgTWlrZSBidXQgZ290IGxvc3QgaW4g c3Vic2VxdWVudCBkaXNjdXNzaW9ucy4NCg0KRkFUIFBXIGxhYmVsIGFzIHdlbGwgYXMgRUxJL0VM IGZvciBQVyAoYmFzZWQgb24gbWljcm9mbG93IHdpdGhpbiBQVykgcmVzaWRlcw0KYmVsb3cgUFcg bGFiZWwuIFRodXMsIEBpbmdyZXNzIFBFLCBvbmNlIG1pY3JvZmxvdyBpcyBpZGVudGlmaWVkLCBl aXRoZXIgRUxJL0VMDQpvciBGQVQgUFcgbGFiZWwgaXMgcHVzaGVkLg0KDQpAUy1QRSwgUFcgbGFi ZWwgc3dhcCBkb2VzIG5vdCBoYXZlIHRvIHByZXNlcnZlIHRoZSBFTEkvRUwgd2hpbGUgZG9pbmcg UFcgbGFiZWwgc3dhcHBpbmcsDQpCRUNBVVNFIGl0IGlzIGFscmVhZHkgYmVsb3cgdGhlIFBXIGxh YmVsLCBqdXN0IGxpa2UgaG93IEZBVCBQVyBsYWJlbCB3b3VsZCBiZS4NCg0KSSBjb25maXJtZWQg dGhpcyBmcm9tIG91ciBkYXRhIHBsYW5lIGVuZ2luZWVyLg0KKHdlIGNhbiBjaGVjayB3aXRoIEtp cmVldGkgYXMgd2VsbCkNCg0KSSB3b3VsZCBsaWtlIHRvIGtub3cgaWYgb3RoZXIgdmVuZG9ycyBh cmUgZG9pbmcgdGhpcyBkaWZmZXJlbnRseT8/DQoNCkdpdmVuIHRoaXMgaXMgdHJ1ZSwgZm9yIHRo ZSBzd2l0Y2hlcyB0aGF0IGRvIERQSSBwYXN0IFBXIGNvbnRyb2wgd29yZCBmb3IgRUNNUCwNCg0K ICAqICAgRkFUIFBXIGxhYmVsIHdvdWxkIHN1ZmZlciB0aGUgc2FtZSBtaXNvcmRlcmluZyBhcyBu byBGQVQgUFcgbGFiZWwNCiAgKiAgIEhvd2V2ZXIsIEVMSS9FTCB3b3VsZCBOT1Qg4oCTIGJlY2F1 c2Ugb2YgdGhlIHByZXNlbmNlIG9mIEVMSQ0KDQpUaGFua3MsDQpIaW1hbnNodQ0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJl Y2lwaWVudCBvbmx5IGFuZCBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBpcw0KQ09ORklERU5U SUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJIFRlbGVjb20uIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMNCnRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1 cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbA0K YW5kIGFsbCBjb3BpZXMgdGhlcmVvZi4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo= --_000_741BDF3FC90F44FFAD59A29CF612FBBDcienacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPjxzdHls ZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hh cGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0 eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcgMyA5IDIgMiA1IDIgNCA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAg MCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5v c2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2Fs aWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlRyZWJ1Y2hldCBNUyI7DQoJcGFub3NlLTE6MiAxMSA2 IDMgMiAyIDIgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29M aXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0K CXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAubXNvY2hwZGVmYXVsdCwgbGkubXNvY2hwZGVmYXVsdCwgZGl2Lm1z b2NocGRlZmF1bHQNCgl7bXNvLXN0eWxlLW5hbWU6bXNvY2hwZGVmYXVsdDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uZW1haWxzdHlsZTE3DQoJe21zby1zdHls ZS1uYW1lOmVtYWlsc3R5bGUxNzsNCglmb250LWZhbWlseToiQ29uc29sYXMiLHNhbnMtc2VyaWY7 DQoJY29sb3I6IzA0MzJGRjsNCglmb250LXN0eWxlOml0YWxpYzt9DQpzcGFuLm1zb2lucw0KCXtt c28tc3R5bGUtbmFtZTptc29pbnM7DQoJY29sb3I6dGVhbDsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJUcmVidWNoZXQgTVMiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzA0 MzJGRjsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5t c29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEyMjM5 MDk2NTM7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE3NjAxODMyMzY7fQ0KQGxpc3QgbDA6bGV2 ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciLHNlcmlmOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0 b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFu Zz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+SGkg U2hhc2hhLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDQzMkZGIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+WW91IGFyZSBjb3JyZWN0IGFib3V0IGhvdyBpdCBp cyB3cml0dGVuIGluIFJGQyA2NzkwLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU cmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGIj5JIGRpZCB0YWxrIHRv IEtpcmVldGkgYnJpZWZseSBpbiB0aGUgaGFsbHdheSBhYm91dCBwbGFjZW1lbnQgb2YgRUxJL0VM IGFuZCBNUy1QVy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzA0MzJGRiI+SGUgYWxzbyBkaWQgc2F5IHRoZSBzYW1lIGJ1dCBoZSBhbHNvIHNh aWQgdGhhdCBpdCBkb2VzIG5vdCBtYXR0ZXIgd2hlcmUgeW91IHBsYWNlIGl0LDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGIj5hcyBm YXIgYXMgcHJvY2Vzc2luZyBvZiB0aGUgRUxJL0VMLCB3b3VsZCB3b3JrIGlycmVzcGVjdGl2ZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0 MzJGRiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwNDMyRkYiPk1TLVBXIHRlY2hub2xvZ3kgdGhyb3dzIHRoZSBtb25rZXkgcmFu Y2guDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzA0MzJGRiI+T25lIGNvdWxkIGp1c3Qgc3VwcG9ydCA2NzkwIGFuZCBub3QgNjM5MSBmb3Ig UFcgaWYgRUxJL0VMIHBsYWNlZCBiZWxvdyBQVyBsYWJlbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJl YnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+SXQgc29sdmVzIHByZXNl cnZhdGlvbiBvZiBlbnRyb3B5IGFjcm9zcyBTLVBFLCBuaWNlbHkuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb25zb2xhcyZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb25zb2xhcyZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwNDMyRkYiPkhpbWFuc2h1PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTogPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZxdW90O0FsZXhhbmRlciBjb20mZ3Q7 JnF1b3Q7ICZsdDtBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbSZndDs8YnI+DQo8Yj5E YXRlOiA8L2I+VHVlc2RheSwgTm92ZW1iZXIgMTQsIDIwMTcgYXQgODoxNCBQTTxicj4NCjxiPlRv OiA8L2I+JnF1b3Q7cGFsc0BpZXRmLm9yZyZxdW90OyAmbHQ7cGFsc0BpZXRmLm9yZyZndDssICZx dW90O1NoYWgsIEhpbWFuc2h1JnF1b3Q7ICZsdDtoc2hhaEBjaWVuYS5jb20mZ3Q7PGJyPg0KPGI+ U3ViamVjdDogPC9iPlJlOiBbUGFsc10gRUxJL0VMIGZvciB0aGUgUFc8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PkhpbWFtc2h1IGFuZCBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SSByZXNwZXRmdWxseSBkaXNhZ3JlZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5BcyBJ IHNlZSBpdCwgUkZDIDY3OTAgaW4gU2VjdGlvbiA0LjIgSW5ncmVzcyBMU1ImcXVvdDsgaW5hbWJp Z3VvdXNseSBzdGF0ZXMgdGhhdCBFTCBhbmQgRUxJLCBpZiB1c2VkLCBiZXR3ZWVuIHRociBUTCBh bmQgJnF1b3Q7YXBwbGljYXRpb24NCiBsYWJlbCZxdW90OyAoaWYgc3BwbGljYXRpb24gbHNiZWwg aXMgdXNlZCkuIEl0IGFsc28gc3BlY2lmaWVzLCB0aGF0IEVMIGFuZCBFTEkgYXJlIG9ubHkgcHVz aGVkIG9uIGFuIGluY29taW5nIHBhY2tldCBpZiB0aGUgdHVubmVsIGVncmVzcyBMU1IgaGFzIHNp Z25hbGVkIHRoYXQgaXQgY2FuIGhhbmRsZSBFTCBvbiB0aGUgc3BlY2lmaWMgdHVubmVsIExTUCBp dCB0ZXJtaW5hdGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPlRvIG1lIHRoaXMgbWVhbnMgdGhhdCBpbiB0aGUgY2FzZSBvZiBh IE1TLVBXLCBFTCBhbmQgRUxJIENBTk5PVCBwcmVzZXJ2ZWQgYnkgYW4gUy1QRS4gV2hldGhlciB0 aGV5IGNhbiBiZSBnZW5lcmF0ZWQgYnkgYW4gU1BFIGlzDQogYW5vdGhlciBzdG9yeS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5G QVQgbGFiZWxzLCBvbiB0aGUgY29udHJhcnksIGFyZSBhbHdheXMgdGhlIEJvUyBsYWJlbHMgYW5k IHRocnJmb3JlIGFyZSBwcmVzZXJ2ZWQgYnkgU1BFcyBvZiBhIE1TLVBXLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkRpZCBJIG1p c3Mgc29tZXRoaW5nIHN1YnN0YW50aWFsPzxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+VGh1bXAgdHlwZWQgYnkgU2FzaGEgVmFpbnNodGVpbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGln bjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4NCjxociBzaXplPSIyIiB3 aWR0aD0iOTglIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgaWQ9ImRpdlJw bHlGd2RNc2ciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjpibGFjayI+IFBhbHMgJmx0O3BhbHMtYm91bmNlc0BpZXRmLm9yZyZn dDsgb24gYmVoYWxmIG9mIFNoYWgsIEhpbWFuc2h1ICZsdDtoc2hhaEBjaWVuYS5jb20mZ3Q7PGJy Pg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE5vdmVtYmVyIDE0LCAyMDE3IDU6MzA6MTMgQU08YnI+ DQo8Yj5Ubzo8L2I+IHBhbHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1BhbHNdIEVM SS9FTCBmb3IgdGhlIFBXPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4gPG86 cD4NCjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb25zb2xhcyZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwNDMyRkYiPlRoZSBQQUxTIFdHIGRpc2N1c3Npb25zIHllc3RlcmRheSBhdCB0aGUgSUVURjEw MCwgd2UgZGlzY3Vzc2VkIHRoZSBjb21wZXRpbmc8L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv bnNvbGFzJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+RkFUIFBXIGFuZCBFTEkvRUwg Zm9yIHRoZSBQVyBhbmQgaXRzIGZhdGUgYXQgUy1QRS48L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvbnNvbGFzJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+Jm5ic3A7PC9zcGFuPjwv aT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb25zb2xhcyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYi PkkgbWVudGlvbmVkIHRoaXMgYXQgTWlrZSBidXQgZ290IGxvc3QgaW4gc3Vic2VxdWVudCBkaXNj dXNzaW9ucy48L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGk+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvbnNvbGFzJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzA0MzJGRiI+Jm5ic3A7PC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb25zb2xh cyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPkZBVCBQVyBsYWJlbCBhcyB3ZWxsIGFz IEVMSS9FTCBmb3IgUFcgKGJhc2VkIG9uIG1pY3JvZmxvdyB3aXRoaW4gUFcpIHJlc2lkZXM8L3Nw YW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvbnNvbGFzJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0 MzJGRiI+YmVsb3cgUFcgbGFiZWwuIFRodXMsIEBpbmdyZXNzIFBFLCBvbmNlIG1pY3JvZmxvdyBp cyBpZGVudGlmaWVkLCBlaXRoZXIgRUxJL0VMPC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb25z b2xhcyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPm9yIEZBVCBQVyBsYWJlbCBpcyBw dXNoZWQuPC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxp PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb25zb2xhcyZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMwNDMyRkYiPiZuYnNwOzwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGIj5AUy1QRSwgUFcgbGFiZWwgc3dhcCBkb2Vz IG5vdCBoYXZlIHRvIHByZXNlcnZlIHRoZSBFTEkvRUwgd2hpbGUgZG9pbmcgUFcgbGFiZWwgc3dh cHBpbmcsPC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxp PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb25zb2xhcyZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMwNDMyRkYiPkJFQ0FVU0UgaXQgaXMgYWxyZWFkeSBiZWxvdyB0aGUgUFcgbGFiZWws IGp1c3QgbGlrZSBob3cgRkFUIFBXIGxhYmVsIHdvdWxkIGJlLjwvc3Bhbj48L2k+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGIj4mbmJzcDs8L3Nw YW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvbnNvbGFzJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0 MzJGRiI+SSBjb25maXJtZWQgdGhpcyBmcm9tIG91ciBkYXRhIHBsYW5lIGVuZ2luZWVyLjwvc3Bh bj48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQz MkZGIj4od2UgY2FuIGNoZWNrIHdpdGggS2lyZWV0aSBhcyB3ZWxsKTwvc3Bhbj48L2k+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGIj4mbmJzcDs8 L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvbnNvbGFzJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzA0MzJGRiI+SSB3b3VsZCBsaWtlIHRvIGtub3cgaWYgb3RoZXIgdmVuZG9ycyBhcmUgZG9pbmcg dGhpcyBkaWZmZXJlbnRseT8/PC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb25zb2xhcyZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPiZuYnNwOzwvc3Bhbj48L2k+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGIj5HaXZlbiB0aGlzIGlz IHRydWUsIGZvciB0aGUgc3dpdGNoZXMgdGhhdCBkbyBEUEkgcGFzdCBQVyBjb250cm9sIHdvcmQg Zm9yIEVDTVAsDQo8L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4t dG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9y OiMwNDMyRkY7bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxpPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb25zb2xhcyZxdW90OyxzYW5zLXNlcmlmIj5G QVQgUFcgbGFiZWwgd291bGQgc3VmZmVyIHRoZSBzYW1lIG1pc29yZGVyaW5nIGFzIG5vIEZBVCBQ VyBsYWJlbDwvc3Bhbj48L2k+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iY29sb3I6IzA0MzJGRjttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPg0KPGk+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvbnNvbGFzJnF1b3Q7LHNh bnMtc2VyaWYiPkhvd2V2ZXIsIEVMSS9FTCB3b3VsZCBOT1Qg4oCTIGJlY2F1c2Ugb2YgdGhlIHBy ZXNlbmNlIG9mIEVMSTwvc3Bhbj48L2k+PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGIj4mbmJzcDs8L3NwYW4+PC9pPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQz MkZGIj5UaGFua3MsPC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv bnNvbGFzJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+SGltYW5zaHU8L3NwYW4+PC9p PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQo8YnI+DQpUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50 IG9ubHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzDQo8YnI+DQpDT05GSURFTlRJ QUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcw0KPGJyPg0KdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5m b3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdp bmFsDQo8YnI+DQphbmQgYWxsIGNvcGllcyB0aGVyZW9mLjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_741BDF3FC90F44FFAD59A29CF612FBBDcienacom_-- From nobody Tue Nov 14 17:37:59 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865EB126CD6 for ; Tue, 14 Nov 2017 17:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=broadcom.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 CaITf9wo314L for ; Tue, 14 Nov 2017 17:37:54 -0800 (PST) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E18D41200CF for ; Tue, 14 Nov 2017 17:37:53 -0800 (PST) Received: by mail-wr0-x235.google.com with SMTP id l8so19106268wre.12 for ; Tue, 14 Nov 2017 17:37:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=eOZGs+kruLvCTYXQKQ+dIXGN8w/jMzDE8cm0aVrAlo0=; b=BFcGt2YfB2JAqDGwxYqaZxmfMIw9CzDOMESJ8zlMDFIW2Jo8Lo2EzNd5fz4UmYo0Pp R03jT2HDAWiDiHbfeyrFO/LiDxb2KDMpyERDcarf8dCgXakvHcqtJnah2QFSA95GZO39 p/i5aIZtmVW5Px6l3oJwCmtzyel+xIO10hPws= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=eOZGs+kruLvCTYXQKQ+dIXGN8w/jMzDE8cm0aVrAlo0=; b=frJ72I3VdRPWqOClpP+3bo8E1d4n3fIepkcvEv6Omf1fFbEnkhtADCFk8Z4MeUPt69 miHUpUOGObod5Fksyw197/fi4hMI96xVJXX0c2hpqDG6oiVikRk8yPPy/OXpptUmLg3A 2UPjFGOUN1LAqF/I8+kHwFzMBeSOP35s+Ugxo9ffTkQcbb2BOxD4SDjT7T8lpnxghxUu pqOB40llOnfr3wjFaTciJvjBkIc919vnC0U2SoszKBeuwYOND7u9JCELeVJp4gV1b35i 7FE7cXJXoXudPDuEXj/l38IsleX3WO3aEkf+G8t6GOsp9seP9jp0gvr9Wz4cpiAR1Q7i fzqw== X-Gm-Message-State: AJaThX7J2Rr53YtIKEme+4DL/et8gJR67cv68/kTskZH3wnitjELU1/N 5KXX/iQDWNeH/bKrwkee6rsPEQ== X-Google-Smtp-Source: AGs4zMbSvx/lyjrezjnJUsl7ynVStv8IL+FGZdcIS8KKpbq1/moMwemq44+JLqUIrx7ytolH473hSQ== X-Received: by 10.223.172.106 with SMTP id v97mr12536291wrc.229.1510709872244; Tue, 14 Nov 2017 17:37:52 -0800 (PST) Received: from c02rq0djfvh9.dhcp.broadcom.net ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id 55sm24043945wrw.60.2017.11.14.17.37.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 14 Nov 2017 17:37:51 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_D150E547-CADC-49E9-9F17-B9DE8055E27B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Shahram Davari In-Reply-To: <741BDF3F-C90F-44FF-AD59-A29CF612FBBD@ciena.com> Date: Tue, 14 Nov 2017 17:37:48 -0800 Cc: Alexander Vainshtein , "pals@ietf.org" Message-Id: References: <741BDF3F-C90F-44FF-AD59-A29CF612FBBD@ciena.com> To: "Shah, Himanshu" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Pals] ELI/EL for the PW X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 01:37:57 -0000 --Apple-Mail=_D150E547-CADC-49E9-9F17-B9DE8055E27B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, We have always assumed ELI/EL are above PW Label and are for LSPs only = as per RFC 6790. This means the only method to provide PW Entropy is FAT = late The only Label that can be below PW Label is PW FAT label. I would recommend keeping it that way. Since we can=E2=80=99t change the = RFC now. Thx Shahram > On Nov 14, 2017, at 5:24 PM, Shah, Himanshu wrote: >=20 > Hi Shasha, > =20 > You are correct about how it is written in RFC 6790. > =20 > I did talk to Kireeti briefly in the hallway about placement of ELI/EL = and MS-PW. > He also did say the same but he also said that it does not matter = where you place it, > as far as processing of the ELI/EL, would work irrespective. > =20 > MS-PW technology throws the monkey ranch. > One could just support 6790 and not 6391 for PW if ELI/EL placed below = PW label. > It solves preservation of entropy across S-PE, nicely. > =20 > Thanks, > Himanshu > =20 > From: "Alexander com>" > > Date: Tuesday, November 14, 2017 at 8:14 PM > To: "pals@ietf.org " >, "Shah, Himanshu" > > Subject: Re: [Pals] ELI/EL for the PW > =20 > Himamshu and all, > I respetfully disagree. >=20 > As I see it, RFC 6790 in Section 4.2 Ingress LSR" inambiguously states = that EL and ELI, if used, between thr TL and "application label" (if = spplication lsbel is used). It also specifies, that EL and ELI are only = pushed on an incoming packet if the tunnel egress LSR has signaled that = it can handle EL on the specific tunnel LSP it terminates. >=20 > To me this means that in the case of a MS-PW, EL and ELI CANNOT = preserved by an S-PE. Whether they can be generated by an SPE is another = story. >=20 > FAT labels, on the contrary, are always the BoS labels and thrrfore = are preserved by SPEs of a MS-PW. >=20 > Did I miss something substantial? >=20 >=20 > Thump typed by Sasha Vainshtein > =20 > From: Pals > on = behalf of Shah, Himanshu > > Sent: Tuesday, November 14, 2017 5:30:13 AM > To: pals@ietf.org > Subject: [Pals] ELI/EL for the PW > =20 > The PALS WG discussions yesterday at the IETF100, we discussed the = competing > FAT PW and ELI/EL for the PW and its fate at S-PE. > =20 > I mentioned this at Mike but got lost in subsequent discussions. > =20 > FAT PW label as well as ELI/EL for PW (based on microflow within PW) = resides > below PW label. Thus, @ingress PE, once microflow is identified, = either ELI/EL > or FAT PW label is pushed. > =20 > @S-PE, PW label swap does not have to preserve the ELI/EL while doing = PW label swapping, > BECAUSE it is already below the PW label, just like how FAT PW label = would be. > =20 > I confirmed this from our data plane engineer. > (we can check with Kireeti as well) > =20 > I would like to know if other vendors are doing this differently?? > =20 > Given this is true, for the switches that do DPI past PW control word = for ECMP, > FAT PW label would suffer the same misordering as no FAT PW label > However, ELI/EL would NOT =E2=80=93 because of the presence of ELI > =20 > Thanks, > Himanshu >=20 > = __________________________________________________________________________= _ >=20 > This e-mail message is intended for the recipient only and contains = information which is=20 > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have = received this=20 > transmission in error, please inform us by e-mail, phone or fax, and = then delete the original=20 > and all copies thereof. > = __________________________________________________________________________= _ >=20 > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals = --Apple-Mail=_D150E547-CADC-49E9-9F17-B9DE8055E27B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

We = have always assumed ELI/EL are above PW Label and are for LSPs only as = per RFC 6790. This means the only method to provide PW Entropy is FAT = late The only Label that can be below PW Label is PW FAT = label.

I would = recommend keeping it that way. Since we can=E2=80=99t change the RFC = now.

Thx
Shahram




On Nov 14, 2017, at 5:24 PM, = Shah, Himanshu <hshah@ciena.com> wrote:

Hi Shasha,
 
You are correct = about how it is written in RFC 6790.
 
I did talk to = Kireeti briefly in the hallway about placement of ELI/EL and MS-PW.
He also did say the same but he also said that it does = not matter where you place it,
as far as = processing of the ELI/EL, would work irrespective.
 
MS-PW technology = throws the monkey ranch.
One could just = support 6790 and not 6391 for PW if ELI/EL placed below PW label.
It solves preservation of entropy across S-PE, = nicely.
 
Thanks,
Himanshu
 
From: "Alexander com>" <Alexander.Vainshtein@ecitele.com>
Date: Tuesday, November 14, = 2017 at 8:14 PM
To: "pals@ietf.org" <pals@ietf.org>, "Shah, = Himanshu" <hshah@ciena.com>
Subject: Re: [Pals] ELI/EL for = the PW
 
Himamshu and = all,

I respetfully = disagree.

As I see it, RFC 6790 in = Section 4.2 Ingress LSR" inambiguously states that EL and ELI, if used, = between thr TL and "application label" (if spplication lsbel is used). = It also specifies, that EL and ELI are only pushed on an incoming packet = if the tunnel egress LSR has signaled that it can handle EL on the = specific tunnel LSP it terminates.

To me this means that in the case of a MS-PW, EL = and ELI CANNOT preserved by an S-PE. Whether they can be generated by an = SPE is another story.

FAT labels, on the contrary, are always the BoS labels and = thrrfore are preserved by SPEs of a MS-PW.

Did I miss something substantial?

Thump typed by Sasha Vainshtein
 
From: Pals <pals-bounces@ietf.org> on = behalf of Shah, Himanshu <hshah@ciena.com>
Sent: Tuesday, November 14, 2017 = 5:30:13 AM
To: pals@ietf.org
Subject: [Pals] ELI/EL for the = PW
 
The PALS WG discussions yesterday at the IETF100, we = discussed the competing
FAT PW and = ELI/EL for the PW and its fate at S-PE.
 
I mentioned this at Mike but got lost in = subsequent discussions.
 
FAT PW label = as well as ELI/EL for PW (based on microflow within PW) = resides
below PW label. Thus, = @ingress PE, once microflow is identified, either ELI/EL
or FAT PW label is pushed.
 
@S-PE, PW label swap does not have to = preserve the ELI/EL while doing PW label swapping,
BECAUSE it is already below the PW label, = just like how FAT PW label would be.
 
I confirmed this from our data plane = engineer.
(we can check with = Kireeti as well)
 
I would like = to know if other vendors are doing this differently??
 
Given this is true, for the switches that = do DPI past PW control word for ECMP,
  • FAT PW label would suffer the same = misordering as no FAT PW label
  • However, ELI/EL would NOT =E2=80=93 because of the presence = of ELI
 
Thanks,
Himanshu

_______________________________________________________________= ____________

This e-mail message is = intended for the recipient only and contains information which is 
CONFIDENTIAL = and which may be proprietary to ECI Telecom. If you have received = this 
transmission in error, please inform us by e-mail, phone or = fax, and then delete the original 
and all = copies thereof.
_______________________________________________________________= ____________

_______________________________________________
Pals mailing list
Pals@ietf.org
https://www.ietf.org/mailman/listinfo/pals

= --Apple-Mail=_D150E547-CADC-49E9-9F17-B9DE8055E27B-- From nobody Tue Nov 14 21:48:26 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2490B1276AF for ; Tue, 14 Nov 2017 21:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.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 RzSqC2qxGSd3 for ; Tue, 14 Nov 2017 21:48:23 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.148]) (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 EE51F127B73 for ; Tue, 14 Nov 2017 21:48:22 -0800 (PST) Received: from [85.158.139.163] by server-12.bemta-5.messagelabs.com id 66/27-20902-525DB0A5; Wed, 15 Nov 2017 05:48:21 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa0hTYRjH955ztp1sp05Hy6elRPMSGS6FoiK C0A+KVETfGmqe2cktd5GdGVphs8LISOxipileGEq5zFlRVliNSjNnkRYkrIJs5SW6KNjFpJ2d o9mXl9/7/z+39+UhcaZXoSa5Ajtns7AmjSKEWLtiS0Z89Mv5uoTGymUbbrtb0AbXdCu2BUv1v p4mUp3On9gOTCc3WvTWgiy54X7ZD3le2XFU4GgbUzpQeWEpCiEJugSHdu8wJlwY+gwG7l+10u UdgrKJC6gUzSMV9GZob/EpBA6jU6B/fBgXOJSOga9XX0l6LLj8xUqRk+DoSG1QJwIxbe62oE7 R6eC56yTEBvcQfPJ2BQqR5LxAA5c7SohB9BKY7HFhAuN0OAwO1QUZaBqcd5/hIi+G4ffTcjFe D28/NCBR18Cka0wpciS8qDuJhF5Ae5TwuPGSZGjhxunPUsI2+H3WLxdmADoKrn/KEOObEDxsH FCIMXHQOzUkDZELXy7elOpsAvfoR1xM8Mnhe8WINF0EjA+USOyRw+CtJIEZOhu6a8YJ8efU4B s4gcpRXPWch4psgZqnzXh18MMWwZOqIULUE+BLXx0u8mpoahiVeA24J7xorl6PlJfRSp6z7ed s8Ylavc2YY7CbWaMpPjFhndbM8Tybw5lYPa/NtprbUWCbDstk6BY6cirZg5aSmGYxFT2u1DEL 9NY9hQaWN+y25Zs43oMiSFIDVHH/fB2zyMblcAV7jabASs7YQKo0YdSYYFN8HmvmjTmi1YM2k m2vfVMY2Rk8/VWjDpwhLFYLpw6nKoQEWkgw5Ftmy80s+QsUqQ6lkEwmY1R5nM1stP/vj6BwEm lCqWtCFZXRYp/tOhIYCAsMpBbeQvF29p+ldqD6rWtldpOXu9NV3BfZufLbApcr/nlaRGVuVHN 5VMXOivX9RVnujyp/6dS5jn3F1j1+Vc31vJJW8lLDWMpgB5d2KLP64K6eVbSz8Hx+tib88hvm QFd6X3IY1hsak3kHu+Jb3pr9tl2d1LnqT41Je8wc+2iC+bGwqONB9/YQutbxXkPwBjYxDrfx7 F/5kWyd3wMAAA== X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-16.tower-188.messagelabs.com!1510724896!120186887!1 X-Originating-IP: [52.33.64.93] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 28097 invoked from network); 15 Nov 2017 05:48:19 -0000 Received: from ec2-52-33-64-93.us-west-2.compute.amazonaws.com (HELO EUR02-VE1-obe.outbound.protection.outlook.com) (52.33.64.93) by server-16.tower-188.messagelabs.com with AES256-SHA256 encrypted SMTP; 15 Nov 2017 05:48:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lldtaG5n12A7XOH7dmYfGAu0wJpSaT0mptfiRBkcTAk=; b=lW6q8AVsVTKRc1Q8XuGtz0bJrp05OVzFIYCtC/kJi4EC1BsRssrg1uFK0GKm2s+3UzHT/2N3w9bmi4XUTmwHelR7XhcpoasgeUJg9VSLztqFwwrrhO9Az2XWwCRQP3jsEDenrk4rZPR2O19hVlB4sqnNR3VBiCESz/RL09bB5MY= Received: from AM4PR03MB1713.eurprd03.prod.outlook.com (10.167.88.15) by AM4PR03MB1714.eurprd03.prod.outlook.com (10.167.88.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Wed, 15 Nov 2017 05:48:15 +0000 Received: from AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::3dd6:85df:7ee8:2216]) by AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::3dd6:85df:7ee8:2216%13]) with mapi id 15.20.0197.017; Wed, 15 Nov 2017 05:48:15 +0000 From: Alexander Vainshtein To: "pals@ietf.org" , "Shah, Himanshu" Thread-Topic: [Pals] ELI/EL for the PW Thread-Index: AQHTXPjhN3Lj0skIK0+jGZ6pug03NqMTykaAgAFi9YD//8N8rA== Date: Wed, 15 Nov 2017 05:48:15 +0000 Message-ID: References: , <741BDF3F-C90F-44FF-AD59-A29CF612FBBD@ciena.com> In-Reply-To: <741BDF3F-C90F-44FF-AD59-A29CF612FBBD@ciena.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [52.164.209.229] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR03MB1714; 6:Scro4xkUG3rZs66hrxkOUH/1qpR6Ub/NkC+Ylo2YcgCiz4JoFurnlEkQLmbWqeJefhiZ/ENjOrPYYX9KeR+SjMqiOMoeU3PDh9sjF01GiEpb4Lm5RTcjdL1SSb0Gfe171yMemthQLd4kq4u5arC7nc3ObjvdWiAOWernmtm91tPeYfdSTseDhXFar/RlNYRkRTgVMZJSy7kxPmQTgA5LUxgcPTiEVUdC4g/WySPL1DndmaMvSIUifiYorYhSfobxe9TUqnWK194V+uAwjSf1+W3NRHpyp6wtt7E5IlwWjpJ2KdZ34j0POFWl86sOia528gU/363kLR5nnTDfXkGmh/xV+xUf8LBsAhgG64pYg4M=; 5:qDK3MIGZ1g82xfxsuTFiMVEVASUfyJpQDXf0AUUnSVeypXOb8qN0LqMeg2yz5+fPSzsFhyQoTE1S8j1ysbCmB2TdpG1nB0q3SMPmbIdqxdE4jdpIkRrDPIdxK3u7Y7cwnunyM+L0W6I7Z/tMSSYiHMZp9qGxnHJRDQSQZlg1V5o=; 24:G6I9J9+QJ3GCxsr2XyiW3Od59F0c6EjvDig36Meilzdxr2n5d3ou3ZzUPAcQ0rfacHZa3SFJsPKxAjCGADd3ErZJbKQOjLKR+bSzDhybOII=; 7:7dkzXb4NjO42lIvFOtEFFcbnsyMzoRszsIY/dWjZTBXuaNaFaZh91WtULWuFBfr9bJu+QuyLDyndV5pmz6QNLUdMCdHzvC9oKLVWy9335qWJRDrCSR54bMkJM6TTv95ZCjx8YUJOb61cU9F+mQZeX/LJa9ZKTV7R2vyqXrC51VwR10qvQb+TlGukfgaQsFEY3KwpdFPx87pqVXIr0dKOndGGYqV3lQHvsaMyIdu036p6KrAax2hAs5YxGQpcOH0s x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1e4368a2-f2c2-48ed-a614-08d52bec771a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:AM4PR03MB1714; x-ms-traffictypediagnostic: AM4PR03MB1714: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(3231022)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR03MB1714; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR03MB1714; x-forefront-prvs: 0492FD61DD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(189002)(199003)(55016002)(110136005)(81166006)(33656002)(106356001)(81156014)(50986999)(76176999)(8676002)(53546010)(105586002)(316002)(54896002)(6246003)(74316002)(9686003)(7736002)(68736007)(2501003)(189998001)(5250100002)(54356999)(86362001)(66066001)(8936002)(2906002)(6436002)(97736004)(53936002)(72206003)(102836003)(3846002)(229853002)(3660700001)(14454004)(478600001)(2950100002)(5660300001)(101416001)(3280700002)(6116002)(7696004)(2900100001)(99286004)(25786009)(6506006); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR03MB1714; H:AM4PR03MB1713.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR03MB1713192DD3D35A69667EDAB79D290AM4PR03MB1713eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1e4368a2-f2c2-48ed-a614-08d52bec771a X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2017 05:48:15.2835 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB1714 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pals] ELI/EL for the PW X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 05:48:25 -0000 --_000_AM4PR03MB1713192DD3D35A69667EDAB79D290AM4PR03MB1713eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Himanshu, Of course EL/ELI can be placed anywhere in the stack. But it can only be i= nserted if the Egress LSR for the tunnel supports it. And in MS-PW each S-= PE terminates the tunnel LSP. >From my POV flow labels are the ONLY right mechanism for adding entropy to= MS-PWs end-to-end. Thump typed by Sasha Vainshtein ________________________________ From: Shah, Himanshu Sent: Wednesday, November 15, 2017 3:24:54 AM To: Alexander Vainshtein; pals@ietf.org Subject: Re: [Pals] ELI/EL for the PW Hi Shasha, You are correct about how it is written in RFC 6790. I did talk to Kireeti briefly in the hallway about placement of ELI/EL and= MS-PW. He also did say the same but he also said that it does not matter where yo= u place it, as far as processing of the ELI/EL, would work irrespective. MS-PW technology throws the monkey ranch. One could just support 6790 and not 6391 for PW if ELI/EL placed below PW = label. It solves preservation of entropy across S-PE, nicely. Thanks, Himanshu From: "Alexander com>" Date: Tuesday, November 14, 2017 at 8:14 PM To: "pals@ietf.org" , "Shah, Himanshu" Subject: Re: [Pals] ELI/EL for the PW Himamshu and all, I respetfully disagree. As I see it, RFC 6790 in Section 4.2 Ingress LSR" inambiguously states tha= t EL and ELI, if used, between thr TL and "application label" (if spplicat= ion lsbel is used). It also specifies, that EL and ELI are only pushed on = an incoming packet if the tunnel egress LSR has signaled that it can handl= e EL on the specific tunnel LSP it terminates. To me this means that in the case of a MS-PW, EL and ELI CANNOT preserved = by an S-PE. Whether they can be generated by an SPE is another story. FAT labels, on the contrary, are always the BoS labels and thrrfore are pr= eserved by SPEs of a MS-PW. Did I miss something substantial? Thump typed by Sasha Vainshtein ________________________________ From: Pals on behalf of Shah, Himanshu Sent: Tuesday, November 14, 2017 5:30:13 AM To: pals@ietf.org Subject: [Pals] ELI/EL for the PW The PALS WG discussions yesterday at the IETF100, we discussed the competi= ng FAT PW and ELI/EL for the PW and its fate at S-PE. I mentioned this at Mike but got lost in subsequent discussions. FAT PW label as well as ELI/EL for PW (based on microflow within PW) resid= es below PW label. Thus, @ingress PE, once microflow is identified, either EL= I/EL or FAT PW label is pushed. @S-PE, PW label swap does not have to preserve the ELI/EL while doing PW l= abel swapping, BECAUSE it is already below the PW label, just like how FAT PW label would= be. I confirmed this from our data plane engineer. (we can check with Kireeti as well) I would like to know if other vendors are doing this differently?? Given this is true, for the switches that do DPI past PW control word for = ECMP, * FAT PW label would suffer the same misordering as no FAT PW label * However, ELI/EL would NOT =96 because of the presence of ELI Thanks, Himanshu __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this transmission in error, please inform us by e-mail, phone or fax, and then = delete the original and all copies thereof. __________________________________________________________________________= _ __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_AM4PR03MB1713192DD3D35A69667EDAB79D290AM4PR03MB1713eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =
Himanshu,
Of course EL/ELI can be placed anywhere in the stack. But it can only be i= nserted if the Egress LSR for the tunnel supports it. And in MS-PW each S-= PE terminates the tunnel LSP.

>From my POV flow labels are the ONLY right mechanism for adding entropy to= MS-PWs end-to-end.

Thump typed by Sasha Vainshtein

From: Shah, Himanshu <= hshah@ciena.com>
Sent: Wednesday, November 15, 2017 3:24:54 AM
To: Alexander Vainshtein; pals@ietf.org
Subject: Re: [Pals] ELI/EL for the PW
 

Hi Shasha,

 

You are correct about how it is written in RFC= 6790.

 

I did talk to Kireeti briefly in the hallway a= bout placement of ELI/EL and MS-PW.

He also did say the same but he also said that= it does not matter where you place it,

as far as processing of the ELI/EL, would work= irrespective.

 

MS-PW technology throws the monkey ranch.

One could just support 6790 and not 6391 for P= W if ELI/EL placed below PW label.

It solves preservation of entropy across S-PE,= nicely.

 

Thanks,

Himanshu

 

From: "Alexander com>" <Alexander.Vains= htein@ecitele.com>
Date: Tuesday, November 14, 2017 at 8:14 PM
To: "pals@ietf.org" <pals@ietf.org>, "Shah, Hi= manshu" <hshah@ciena.com>
Subject: Re: [Pals] ELI/EL for the PW

 

Himamshu and all,

I = respetfully disagree.

As= I see it, RFC 6790 in Section 4.2 Ingress LSR" inambiguously states = that EL and ELI, if used, between thr TL and "application label" (if spplication lsbel is used). It also specifies, that EL an= d ELI are only pushed on an incoming packet if the tunnel egress LSR has s= ignaled that it can handle EL on the specific tunnel LSP it terminates.

To= me this means that in the case of a MS-PW, EL and ELI CANNOT preserved by= an S-PE. Whether they can be generated by an SPE is another story.

FA= T labels, on the contrary, are always the BoS labels and thrrfore are pres= erved by SPEs of a MS-PW.

Di= d I miss something substantial?

Thump typed by Sasha Vainshtein

 

Fr= om: Pals <pals= -bounces@ietf.org> on behalf of Shah, Himanshu <hshah@ciena.com><= br> Sent: Tuesday, November 14, 2017 5:30:13 AM
To: pals@ietf.org
Subject: [Pals] ELI/EL for the PW

 

The PALS WG discussions yesterday at the IETF10= 0, we discussed the competing

FAT PW and ELI/EL for the PW and its fate at S-= PE.

 

I mentioned this at Mike but got lost in subseq= uent discussions.

 

FAT PW label as well as ELI/EL for PW (based on= microflow within PW) resides

below PW label. Thus, @ingress PE, once microfl= ow is identified, either ELI/EL

or FAT PW label is pushed.

 

@S-PE, PW label swap does not have to preserve = the ELI/EL while doing PW label swapping,

BECAUSE it is already below the PW label, just = like how FAT PW label would be.

 

I confirmed this from our data plane engineer.<= /span>

(we can check with Kireeti as well)<= /p>

 

I would like to know if other vendors are doing= this differently??

 

Given this is true, for the switches that do DP= I past PW control word for ECMP,

  • FAT PW label would s= uffer the same misordering as no FAT PW label
  • However, ELI/EL would NOT =96 bec= ause of the presence of ELI

 

Thanks,

Himanshu


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_AM4PR03MB1713192DD3D35A69667EDAB79D290AM4PR03MB1713eurp_-- From nobody Tue Nov 14 21:50:29 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A1E129471 for ; Tue, 14 Nov 2017 21:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.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 kNkvDPoWfQ_2 for ; Tue, 14 Nov 2017 21:50:25 -0800 (PST) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.106]) (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 6DD521243F6 for ; Tue, 14 Nov 2017 21:50:13 -0800 (PST) Received: from [193.109.254.3] by server-2.bemta-6.messagelabs.com id 78/44-05188-395DB0A5; Wed, 15 Nov 2017 05:50:11 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa0gUURTHuzOzu9fHxLS+TluSbVZWaBpaigR GEPuhoqIolqJmbXI3d1eb2WL1i0phZUEP6bUEpoj0sDbXIg3LMnuJqz0sU1o0fLdFwaaZhrSz M73mw+V3z/+cc89/OJhUdyo1mLPbON7KmrXKYCp50XhsfOmbEH1iWz1OvVtzDaVWT90gUl0V3 aoMUufocSt17q4pSldZ+YPYQOoVJqshx75LYWw9dIvIveJG9jF3fiHy1aMSFIwpppiEl+3OwE XNnCZg3HNWIV16ERyc+kGWoCCsZFaC65pHKXI4swU8k0+JEoQxycyDh/2BcBgzH74638opC6B 6sEgl8Ro42l4WaEP5c1pcd5DINLMdauqHAnE18w3BufOzRA5iMqD5SqNCZMREwveWakJkkomC 7v6yAAPDQGVDOylxBIz0Tcn5BugZKEdSPAbcEx2UxNHwquxYwCQwTSpw9DbKSQlw+9RnmdfB6 NsiSvQFfl+3hndI+VUIxmqd8sOLobP2iczZUDzQKg+RDjVe0YxY4FFAs/e9QhJmg6+jWBY+KK Cv9zIhWc6EZxd91Em0xPGPO4mtcOJ6KekI/KUZ8PxCPyXFE+FLWxkp8RKoKvfKvBRqvrnRv/F LSHUVxQkcf4Dj45NSEgy8Kctos7Amc3xS4vIECycIbBZnZg1CQmaOxYX8izXN/9WhsaoNTWgm JrQRdKxPpVdPN+TszjOygnEnv9/MCU1oNsZaoBtfh+jVM3gui7PvMZn92/lbBhyqDac/iTIt5 LIWwZQlSS0oDd/s8vwk8P3AOXjBW0iqKWuOldNE0WfEAkYsMO63/mn3e99foWhNGI38A6pDcz neYrL9r39EURhpw+hasUuoyWr78+pH/0CEfyCN6IUWbOxfSVOIcPhkv6tuVfWRUWfXMJF8cYQ nTSnOuNb82PnM+ZHkyNHgy/QgehAz6Furs9PL8PClojlth1TevenpZJrh8ULH7rzsVP3qw0MN uoKz6n0966it74ryVmw8Hk6Ujg3NXf/9y4ve+wX3Nj5qTttc39Ux0akBzcOUcmL6tiicvakiR ksJRjZpMckL7C9G/gPM6gMAAA== X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-10.tower-184.messagelabs.com!1510725007!144221961!1 X-Originating-IP: [52.41.248.36] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 22450 invoked from network); 15 Nov 2017 05:50:10 -0000 Received: from ec2-52-41-248-36.us-west-2.compute.amazonaws.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (52.41.248.36) by server-10.tower-184.messagelabs.com with AES256-SHA256 encrypted SMTP; 15 Nov 2017 05:50:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lbg9Ypt+K4mpkJxLk1OzfdOvn57/ILU6TZRX8ESAW10=; b=aM06+IKTsBq7q8sgRTvrsxmz6rYHGgyIZb7zeVBasHLFearnMM1sJE3jkOZD+CGHsErAbKmzt80yxI5dAG4E5K79wGlbL993Mi54jHcFIE+J2It7ZZqV/kTYXAKTx+vFwS/EU9Svz+l8XJ+tAFP0uMCnFdyM1obPE+pDETDnDQY= Received: from AM4PR03MB1713.eurprd03.prod.outlook.com (10.167.88.15) by AM4PR03MB1716.eurprd03.prod.outlook.com (10.167.88.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Wed, 15 Nov 2017 05:50:06 +0000 Received: from AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::3dd6:85df:7ee8:2216]) by AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::3dd6:85df:7ee8:2216%13]) with mapi id 15.20.0197.017; Wed, 15 Nov 2017 05:50:06 +0000 From: Alexander Vainshtein To: "Shah, Himanshu" , Shahram Davari CC: "pals@ietf.org" Thread-Topic: [Pals] ELI/EL for the PW Thread-Index: AQHTXPjhN3Lj0skIK0+jGZ6pug03NqMTykaAgAFi9YD//32CAIAARn4j Date: Wed, 15 Nov 2017 05:50:06 +0000 Message-ID: References: <741BDF3F-C90F-44FF-AD59-A29CF612FBBD@ciena.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [40.69.42.217] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR03MB1716; 6:iCEmXpr7S19hS6m12QdcuYSVDOquohiIymOdwZFklawS+d198uJWHGo/ksA4PkogTIA06LQ+rmMRgHD5WOPOCz52/n6qL/x3TMyO+wpBN0xBqd+xgkjYDl0ZFsxh490GEhX7E2jt0byTz7YaF1eRx5LBY0373R+4G3FrAZCmPwl2w0nEQfQAsZG4LgFqH4PJc5QK7qw35L15HnqkZP+sCMmiRkvpbB2AXc6yDdQbNcI4OB+ayeOSySdz8rCp2gLVHUCKRC2Ek5/8t5P9V2CmR57SFq/5U8tzc6mUaQkHhIBSvFCPVs4ollIC2NfgiZvUS+Ozys7NUbkfW31pF3neIM58zqhjvpiV7Ar18E2iUkk=; 5:YRPDuqPraOemw3SXWPbRC7iU0NGEshZYZqHkOwawIbn+Ctu3pJaSmuSeVkAclGLHQcU3I8HDzvSEi3A5OmUbuh33ZajVJlXhkK6e/IzboHQFjsunf9ShHMVdBUER4SEmbtdwiLFKJ5IB06BmXg7TUtLDMfsipW7Cnpr5dWoVNlo=; 24:sG/9H9dNXZL5FZwFY1gOeMhxnOU8x2EMepnsDsJVM+4YCuGBMGRcC/Ianm/9pU7gisUVGY4w7qfk9oDorkoo3AL42oPkzyUJ2G8uCqKUXW8=; 7:DiA/QG7fxsi/X9wdP53Xro466vQYYYDkmHt5kaITe6NjW0qYerjqd1pZ1oTEYEiGLvUy6LfGEgD3/Z3Gd6uQZyq156BKevfapaX/VRvqYUSgwkq5nvshj8Z4KsADs8dLYfSmDazPnzxaQ2gl4+vnP7dFZ6kkNRZiwi5wD/uvuHZXlW4/Su19XY3bSFzuTJwRz6BXMKLoH/NFu6DyK0OR2LcucMCxnz9JoaaWTremPtmaw2qzZsvl235Of4ZvsrCp x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 32330024-d178-424d-e9f4-08d52becb91b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:AM4PR03MB1716; x-ms-traffictypediagnostic: AM4PR03MB1716: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(3231022)(6055026)(6041248)(20161123558100)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR03MB1716; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR03MB1716; x-forefront-prvs: 0492FD61DD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(189002)(199003)(24454002)(6116002)(606006)(55016002)(3846002)(102836003)(53546010)(6306002)(5250100002)(25786009)(189998001)(93886005)(54896002)(9686003)(3280700002)(478600001)(8676002)(76176999)(236005)(72206003)(316002)(2900100001)(68736007)(54356999)(33656002)(50986999)(6506006)(66066001)(53936002)(2950100002)(105586002)(14454004)(966005)(2906002)(8936002)(7736002)(3660700001)(106356001)(7696004)(110136005)(97736004)(99286004)(4326008)(229853002)(101416001)(81156014)(5660300001)(6246003)(74316002)(6436002)(81166006)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR03MB1716; H:AM4PR03MB1713.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR03MB17138A507C9C5CB8681CA3179D290AM4PR03MB1713eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 32330024-d178-424d-e9f4-08d52becb91b X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2017 05:50:06.0371 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB1716 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Pals] ELI/EL for the PW X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 05:50:28 -0000 --_000_AM4PR03MB17138A507C9C5CB8681CA3179D290AM4PR03MB1713eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Shahram, This is obw of a few times when yiu and I are in full agreement on an issu= e discussed on this list?? Thump typed by Sasha Vainshtein ________________________________ From: Shahram Davari Sent: Wednesday, November 15, 2017 3:37:48 AM To: Shah, Himanshu Cc: Alexander Vainshtein; pals@ietf.org Subject: Re: [Pals] ELI/EL for the PW Hi, We have always assumed ELI/EL are above PW Label and are for LSPs only as = per RFC 6790. This means the only method to provide PW Entropy is FAT late= The only Label that can be below PW Label is PW FAT label. I would recommend keeping it that way. Since we can=92t change the RFC now= . Thx Shahram On Nov 14, 2017, at 5:24 PM, Shah, Himanshu > wrote: Hi Shasha, You are correct about how it is written in RFC 6790. I did talk to Kireeti briefly in the hallway about placement of ELI/EL and= MS-PW. He also did say the same but he also said that it does not matter where yo= u place it, as far as processing of the ELI/EL, would work irrespective. MS-PW technology throws the monkey ranch. One could just support 6790 and not 6391 for PW if ELI/EL placed below PW = label. It solves preservation of entropy across S-PE, nicely. Thanks, Himanshu From: "Alexander com>" > Date: Tuesday, November 14, 2017 at 8:14 PM To: "pals@ietf.org" >, "Shah, Himanshu" > Subject: Re: [Pals] ELI/EL for the PW Himamshu and all, I respetfully disagree. As I see it, RFC 6790 in Section 4.2 Ingress LSR" inambiguously states tha= t EL and ELI, if used, between thr TL and "application label" (if spplicat= ion lsbel is used). It also specifies, that EL and ELI are only pushed on = an incoming packet if the tunnel egress LSR has signaled that it can handl= e EL on the specific tunnel LSP it terminates. To me this means that in the case of a MS-PW, EL and ELI CANNOT preserved = by an S-PE. Whether they can be generated by an SPE is another story. FAT labels, on the contrary, are always the BoS labels and thrrfore are pr= eserved by SPEs of a MS-PW. Did I miss something substantial? Thump typed by Sasha Vainshtein ________________________________ From: Pals > on behalf= of Shah, Himanshu > Sent: Tuesday, November 14, 2017 5:30:13 AM To: pals@ietf.org Subject: [Pals] ELI/EL for the PW The PALS WG discussions yesterday at the IETF100, we discussed the competi= ng FAT PW and ELI/EL for the PW and its fate at S-PE. I mentioned this at Mike but got lost in subsequent discussions. FAT PW label as well as ELI/EL for PW (based on microflow within PW) resid= es below PW label. Thus, @ingress PE, once microflow is identified, either EL= I/EL or FAT PW label is pushed. @S-PE, PW label swap does not have to preserve the ELI/EL while doing PW l= abel swapping, BECAUSE it is already below the PW label, just like how FAT PW label would= be. I confirmed this from our data plane engineer. (we can check with Kireeti as well) I would like to know if other vendors are doing this differently?? Given this is true, for the switches that do DPI past PW control word for = ECMP, * FAT PW label would suffer the same misordering as no FAT PW label * However, ELI/EL would NOT =96 because of the presence of ELI Thanks, Himanshu __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this transmission in error, please inform us by e-mail, phone or fax, and then = delete the original and all copies thereof. __________________________________________________________________________= _ _______________________________________________ Pals mailing list Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_AM4PR03MB17138A507C9C5CB8681CA3179D290AM4PR03MB1713eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Shahram,
This is obw of a few times when yiu and I are in full agreement on an issu= e discussed on this list😉

Thump typed by Sasha Vainshtein

From: Shahram Davari=20&l= t;shahram.davari@broadcom.com>
Sent: Wednesday, November 15, 2017 3:37:48 AM
To: Shah, Himanshu
Cc: Alexander Vainshtein; pals@ietf.org
Subject: Re: [Pals] ELI/EL for the PW
 
Hi,

We have always assumed ELI/EL are above PW Label and are f= or LSPs only as per RFC 6790. This means the only method to provide PW Ent= ropy is FAT late The only Label that can be below PW Label is PW FAT label= .

I would recommend keeping it that way. Since we can=92t ch= ange the RFC now.

Thx
Shahram




On Nov 14, 2017, at 5:24 PM, Shah, Himanshu <hshah@ciena.com> wrote:

Hi Shasha,
 
You are correct about how it is written in RFC 6790.
 
I did talk to Kireeti briefly in the hallway about placement o= f ELI/EL and MS-PW.
He also did say the same but he also said that it does not mat= ter where you place it,
as far as processing of the ELI/EL, would work irrespective.
 
MS-PW technology throws the monkey ranch.
One could just support 6790 and not 6391 for PW if ELI/EL plac= ed below PW label.
It solves preservation of entropy across S-PE, nicely.<= /div>
 
Thanks,
Himanshu=
 
From: "Alexa= nder com>" <Ale= xander.Vainshtein@ecitele.com>
Date: = Tuesday, November 14, 2017 at 8:14 PM
To: &q= uot;pals@ietf.org" <pals@ietf.org>, "Shah, Himanshu" <hshah@ciena.= com>
Subject: <= /b>Re: [Pals] ELI/EL for the PW
 


From: Pals <pals-bounces= @ietf.org> on behalf of Shah, Himanshu <hshah@ciena.= com>
Sent: = Tuesday, November 14, 2017 5:30:13 AM
To: pals@ietf.org
Subject: [Pals] ELI/EL for the PW
 
The PALS WG discussions yesterday at the IETF100, we d= iscussed the competing
FAT PW and ELI/EL for the PW and its fate at S-PE.
 
I mentioned this at Mike but got lost in subsequent di= scussions.
 
FAT PW label as well as ELI/EL for PW (based on microf= low within PW) resides
below PW label. Thus, @ingress PE, once microflow is i= dentified, either ELI/EL
or FAT PW label is pushed.
 
@S-PE, PW label swap does not have to preserve the ELI= /EL while doing PW label swapping,
BECAUSE it is already below the PW label, just like ho= w FAT PW label would be.
 
I confirmed this from our data plane engineer.<= /i>
(we can check with Kireeti as well)
 
I would like to know if other vendors are doing this d= ifferently??
 
Given this is true, for the switches that do DPI past = PW control word for ECMP,
  • F= AT PW label would suffer the same misordering as no FAT PW label
  • H= owever, ELI/EL would NOT =96 because of the presence of ELI
 
Thanks,
Himanshu

__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this 
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original 
and all copies thereof.
__________________________________________________________________________= _

_______________________________________________
Pals mailing list
Pals@ietf.= org
https://www.ietf.org/mailman/listinfo/pals


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_AM4PR03MB17138A507C9C5CB8681CA3179D290AM4PR03MB1713eurp_-- From nobody Tue Nov 14 22:15:00 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6AF129504 for ; Tue, 14 Nov 2017 22:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cienacorp.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 LqZivpMj-X1v for ; Tue, 14 Nov 2017 22:14:56 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0056.outbound.protection.outlook.com [104.47.38.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C17071243F6 for ; Tue, 14 Nov 2017 22:14:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cienacorp.onmicrosoft.com; s=selector1-ciena-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zVNv2/Qin1wXt+rqZNZSFNDuu70rvRZr1Y4v2tXOK5s=; b=kdf44ngpvNtzF2smL+ekSUrMz41Zz7leakslt/v+agL1E7Y3salGyqweNbDNupbSfAvI+2iucMaI+JHvEDOLewnlIV6ZCNhpyyUL5ioGa+2s1QkcK4HqXQ91ADAjLubEy0MV5LKcuizwzN6Z20zHIKKBzcQAj5hhuFGIo5cj8Nk= Received: from MWHPR0401MB3562.namprd04.prod.outlook.com (10.167.162.153) by MWHPR0401MB3562.namprd04.prod.outlook.com (10.167.162.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.218.12; Wed, 15 Nov 2017 06:14:53 +0000 Received: from MWHPR0401MB3562.namprd04.prod.outlook.com ([fe80::905b:4368:8f0d:ccb0]) by MWHPR0401MB3562.namprd04.prod.outlook.com ([fe80::905b:4368:8f0d:ccb0%13]) with mapi id 15.20.0218.015; Wed, 15 Nov 2017 06:14:53 +0000 From: "Shah, Himanshu" To: Alexander Vainshtein , "pals@ietf.org" Thread-Topic: [Pals] ELI/EL for the PW Thread-Index: AQHTXPjhN3Lj0skIK0+jGZ6pug03NqMTykaAgAFi9YD//8N8rIAAjYqA Date: Wed, 15 Nov 2017 06:14:53 +0000 Message-ID: References: <741BDF3F-C90F-44FF-AD59-A29CF612FBBD@ciena.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 authentication-results: spf=none (sender IP is ) smtp.mailfrom=hshah@ciena.com; x-originating-ip: [2001:67c:370:128:2d6d:5c16:6027:c12e] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR0401MB3562; 6:fKiU7cVvRmIIVAhXM1bJ1Im3QipT5ZbhLQq7l9tieLDgVMseFHUC534zC6pc15/hHxLz8aPACicP+tp2mjrjhnta71FHb9JHG+/rGg2Pjbdt4urLKDq19yWrPm2j6riN4LBHynin+96IZXzyNw8UX4HGiUp2dsDa9sTKOxVzYoQPcKL18V0H2zAVhxSrSSOMgiUrn5KsAn6vOUnDu7jwdJxKPW/Z6AyD6NhL4t3CFsAkNkR/yZx9rQATdhrGLI/dRGvWRXrKqIAOp5NnkkSz/YVb1CHAE7m0c2DnRxVOT8PqO3p31di9syYab7G9ebqfZvn3tafF+JHNqAc2TuwfC1cm2VSWn7rA0gVyVLEiwp4=; 5:St/7cwcmlfN2dSt7ig3iX93GdpVvUX430PVwGOpyBx3yP+JIBxVj5M7VuNDAtIAIPpQeCMUiQbH0Uw5wETDTzpju1HR/CDKQik25KIuFcGWNPH67STUl1W+b5jhGBNQu+kr9rvT/ZtjFdZ2gHST7ABO9uTwuFHoB+Zcorgkjkzk=; 24:Sc77ej2oZc0izHRmuGm4fYSHPoR8PeO9+hUWu2GaeaXsebT4f+8d65RZuZUhL4AarCXKyH5OaV5GUgKjAqHUPEN5wnlvcVnbn4NCxGa5mfc=; 7:u0KcsG8Mkdqxa0MgZjFOzqJBE2InnlEXhZeOV6PNBQ2tH0+WoHVkJzjBbl8obSdxmtYIBIifDWbpCKPq7EaafA88nQHqs1j2uhm9lz1Vonrl+k/6HPCOUsAxriOT0rOuRiGPtfxauaaO0psf1ZaOjfTCqh/lHz8NkwcoQpLeRzSxWNfikw+wkPLehO/G1Jzb9WoVGcecCTBLPUnMbbyXK8WJ6gVespAtBM+hQzrjtydh0C3GZyyULRB18O79LKL+ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 158491f1-484f-4588-3ffd-08d52bf02fbd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:MWHPR0401MB3562; x-ms-traffictypediagnostic: MWHPR0401MB3562: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227612066756510)(21748063052155)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231022)(100000703101)(100105400095)(10201501046)(6041248)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR0401MB3562; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR0401MB3562; x-forefront-prvs: 0492FD61DD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(199003)(189002)(6116002)(97736004)(105586002)(102836003)(3280700002)(478600001)(6506006)(6246003)(6436002)(2906002)(101416001)(76176999)(93886005)(81166006)(2900100001)(53546010)(36756003)(3660700001)(82746002)(81156014)(50986999)(8676002)(54356999)(25786009)(106356001)(83506002)(68736007)(54896002)(8936002)(14454004)(99286004)(316002)(53936002)(6512007)(6486002)(5250100002)(7736002)(33656002)(229853002)(2950100002)(58126008)(83716003)(6306002)(189998001)(86362001)(5660300001)(110136005)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR0401MB3562; H:MWHPR0401MB3562.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ciena.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_A756C03C90E34BEC95C0B07836C8AE5Ecienacom_" MIME-Version: 1.0 X-OriginatorOrg: ciena.com X-MS-Exchange-CrossTenant-Network-Message-Id: 158491f1-484f-4588-3ffd-08d52bf02fbd X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2017 06:14:53.4932 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 457a2b01-0019-42ba-a449-45f99e96b60a X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR0401MB3562 Archived-At: Subject: Re: [Pals] ELI/EL for the PW X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 06:14:59 -0000 --_000_A756C03C90E34BEC95C0B07836C8AE5Ecienacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2FzaGEg4oCTDQoNCkkgdW5kZXJzdGFuZCB0aGF0IGFuZCBJIGRvIG5vdCB3YW50IHRvIGJl bGFib3IgbXkgcG9pbnQuDQpTbyBqdXN0IHRvIGNsYXJpZnkgbXkgcG9pbnQsIHlvdSBjYW4gdmll dyBNUy1QVyBhcyDigJxQVy1MU1DigJ0NCndpdGggUy1QRSBhcyDigJxQVy1MU1LigJ0uIEluIHRo YXQgY29udGV4dCwgRUxJL0VMIGJlbG93IFBXIGxhYmVsLA0KbWFrZXMgc2Vuc2UuDQoNCkZBVCBQ VyBSRkMgcHJlZGF0ZXMgdGhlIEVMSS9FTCwgYnV0IGlmIHRoYXQgd2FzIG5vdCB0aGUgY2FzZSwN CkVMSS9FTCBlYXNpbHkgd291bGQgaGF2ZSBiZWVuIHVzZWQgYXMgdGhlIHNvbHV0aW9uIHRoZSB3 YXkgSSBkZXNjcmliZSBhYm92ZS4NCg0KQnV0IHRoYXQgaXMgYWxsIHdhdGVyIHVuZGVyIHRoZSBi cmlkZ2UuDQpTbywgbGV0IHVzIG1vdmUgb24uDQoNCk9uIHRoZSBmb2xsb3cgb24gdG9waWMgb24g dGhlIGd1aWRlbGluZSwNCldoZXJlIHdlIHNheSDigJx3aGVuIGJvdGggYXJlIHN1cHBvcnRlZCBP TkxZIE9ORSAoRUxJL0VMIG9yIEZBVCBsYWJlbCkgU0hPVUxEIGJlIHVzZWTigJ0uDQoNClNpbmNl IEZBVCBsYWJlbCBkb2VzIG5vdCBwcm90ZWN0IGZyb20gRUNNUCBiYXNlZCBvbiBEUEkgYmV5b25k IFBXIENXLCBCT1RIIHNjaGVtZXMgYXJlDQpyZXF1aXJlZCBzaW5jZSBGQVQgbGFiZWwgc3VmZmVy cyBzYW1lIG1pcy1vcmRlcmluZyBjb25zZXF1ZW5jZXMuDQpJbiBhZGRpdGlvbiwgUy1QRSBNVVNU IHByZXNlcnZlIGFuZC9vciByZWdlbmVyYXRlIEVMSS9FTCBhYm92ZSBQVyBsYWJlbCwNCklmIFdH IGNob3NlIHRvIHByb3ZpZGUgZ3VpZGVsaW5lcyBvbiBob3cgdG8gYXZvaWQgbWktb3JkZXJpbmcg aW4gdGhlIHByZXNlbmNlIG9mIHN1Y2ggc3dpdGNoZXMuDQoNClRoYW5rcywNCkhpbWFuc2h1DQoN CkZyb206ICJBbGV4YW5kZXIgY29tPiIgPEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29t Pg0KRGF0ZTogV2VkbmVzZGF5LCBOb3ZlbWJlciAxNSwgMjAxNyBhdCAxOjQ4IFBNDQpUbzogInBh bHNAaWV0Zi5vcmciIDxwYWxzQGlldGYub3JnPiwgIlNoYWgsIEhpbWFuc2h1IiA8aHNoYWhAY2ll bmEuY29tPg0KU3ViamVjdDogUmU6IFtQYWxzXSBFTEkvRUwgZm9yIHRoZSBQVw0KDQpIaW1hbnNo dSwNCk9mIGNvdXJzZSBFTC9FTEkgY2FuIGJlIHBsYWNlZCBhbnl3aGVyZSBpbiB0aGUgc3RhY2su IEJ1dCBpdCBjYW4gb25seSBiZSBpbnNlcnRlZCBpZiB0aGUgRWdyZXNzIExTUiBmb3IgdGhlIHR1 bm5lbCBzdXBwb3J0cyBpdC4gQW5kIGluIE1TLVBXIGVhY2ggUy1QRSB0ZXJtaW5hdGVzIHRoZSB0 dW5uZWwgTFNQLg0KRnJvbSBteSBQT1YgZmxvdyBsYWJlbHMgYXJlIHRoZSBPTkxZIHJpZ2h0IG1l Y2hhbmlzbSBmb3IgYWRkaW5nIGVudHJvcHkgdG8gTVMtUFdzIGVuZC10by1lbmQuDQpUaHVtcCB0 eXBlZCBieSBTYXNoYSBWYWluc2h0ZWluDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpGcm9tOiBTaGFoLCBIaW1hbnNodSA8aHNoYWhAY2llbmEuY29tPg0KU2VudDogV2VkbmVz ZGF5LCBOb3ZlbWJlciAxNSwgMjAxNyAzOjI0OjU0IEFNDQpUbzogQWxleGFuZGVyIFZhaW5zaHRl aW47IHBhbHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbUGFsc10gRUxJL0VMIGZvciB0aGUgUFcN Cg0KSGkgU2hhc2hhLA0KDQpZb3UgYXJlIGNvcnJlY3QgYWJvdXQgaG93IGl0IGlzIHdyaXR0ZW4g aW4gUkZDIDY3OTAuDQoNCkkgZGlkIHRhbGsgdG8gS2lyZWV0aSBicmllZmx5IGluIHRoZSBoYWxs d2F5IGFib3V0IHBsYWNlbWVudCBvZiBFTEkvRUwgYW5kIE1TLVBXLg0KSGUgYWxzbyBkaWQgc2F5 IHRoZSBzYW1lIGJ1dCBoZSBhbHNvIHNhaWQgdGhhdCBpdCBkb2VzIG5vdCBtYXR0ZXIgd2hlcmUg eW91IHBsYWNlIGl0LA0KYXMgZmFyIGFzIHByb2Nlc3Npbmcgb2YgdGhlIEVMSS9FTCwgd291bGQg d29yayBpcnJlc3BlY3RpdmUuDQoNCk1TLVBXIHRlY2hub2xvZ3kgdGhyb3dzIHRoZSBtb25rZXkg cmFuY2guDQpPbmUgY291bGQganVzdCBzdXBwb3J0IDY3OTAgYW5kIG5vdCA2MzkxIGZvciBQVyBp ZiBFTEkvRUwgcGxhY2VkIGJlbG93IFBXIGxhYmVsLg0KSXQgc29sdmVzIHByZXNlcnZhdGlvbiBv ZiBlbnRyb3B5IGFjcm9zcyBTLVBFLCBuaWNlbHkuDQoNClRoYW5rcywNCkhpbWFuc2h1DQoNCkZy b206ICJBbGV4YW5kZXIgY29tPiIgPEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPg0K RGF0ZTogVHVlc2RheSwgTm92ZW1iZXIgMTQsIDIwMTcgYXQgODoxNCBQTQ0KVG86ICJwYWxzQGll dGYub3JnIiA8cGFsc0BpZXRmLm9yZz4sICJTaGFoLCBIaW1hbnNodSIgPGhzaGFoQGNpZW5hLmNv bT4NClN1YmplY3Q6IFJlOiBbUGFsc10gRUxJL0VMIGZvciB0aGUgUFcNCg0KSGltYW1zaHUgYW5k IGFsbCwNCkkgcmVzcGV0ZnVsbHkgZGlzYWdyZWUuDQpBcyBJIHNlZSBpdCwgUkZDIDY3OTAgaW4g U2VjdGlvbiA0LjIgSW5ncmVzcyBMU1IiIGluYW1iaWd1b3VzbHkgc3RhdGVzIHRoYXQgRUwgYW5k IEVMSSwgaWYgdXNlZCwgYmV0d2VlbiB0aHIgVEwgYW5kICJhcHBsaWNhdGlvbiBsYWJlbCIgKGlm IHNwcGxpY2F0aW9uIGxzYmVsIGlzIHVzZWQpLiBJdCBhbHNvIHNwZWNpZmllcywgdGhhdCBFTCBh bmQgRUxJIGFyZSBvbmx5IHB1c2hlZCBvbiBhbiBpbmNvbWluZyBwYWNrZXQgaWYgdGhlIHR1bm5l bCBlZ3Jlc3MgTFNSIGhhcyBzaWduYWxlZCB0aGF0IGl0IGNhbiBoYW5kbGUgRUwgb24gdGhlIHNw ZWNpZmljIHR1bm5lbCBMU1AgaXQgdGVybWluYXRlcy4NClRvIG1lIHRoaXMgbWVhbnMgdGhhdCBp biB0aGUgY2FzZSBvZiBhIE1TLVBXLCBFTCBhbmQgRUxJIENBTk5PVCBwcmVzZXJ2ZWQgYnkgYW4g Uy1QRS4gV2hldGhlciB0aGV5IGNhbiBiZSBnZW5lcmF0ZWQgYnkgYW4gU1BFIGlzIGFub3RoZXIg c3RvcnkuDQpGQVQgbGFiZWxzLCBvbiB0aGUgY29udHJhcnksIGFyZSBhbHdheXMgdGhlIEJvUyBs YWJlbHMgYW5kIHRocnJmb3JlIGFyZSBwcmVzZXJ2ZWQgYnkgU1BFcyBvZiBhIE1TLVBXLg0KRGlk IEkgbWlzcyBzb21ldGhpbmcgc3Vic3RhbnRpYWw/DQpUaHVtcCB0eXBlZCBieSBTYXNoYSBWYWlu c2h0ZWluDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBQYWxzIDxw YWxzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBTaGFoLCBIaW1hbnNodSA8aHNoYWhA Y2llbmEuY29tPg0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTQsIDIwMTcgNTozMDoxMyBBTQ0K VG86IHBhbHNAaWV0Zi5vcmcNClN1YmplY3Q6IFtQYWxzXSBFTEkvRUwgZm9yIHRoZSBQVw0KDQpU aGUgUEFMUyBXRyBkaXNjdXNzaW9ucyB5ZXN0ZXJkYXkgYXQgdGhlIElFVEYxMDAsIHdlIGRpc2N1 c3NlZCB0aGUgY29tcGV0aW5nDQpGQVQgUFcgYW5kIEVMSS9FTCBmb3IgdGhlIFBXIGFuZCBpdHMg ZmF0ZSBhdCBTLVBFLg0KDQpJIG1lbnRpb25lZCB0aGlzIGF0IE1pa2UgYnV0IGdvdCBsb3N0IGlu IHN1YnNlcXVlbnQgZGlzY3Vzc2lvbnMuDQoNCkZBVCBQVyBsYWJlbCBhcyB3ZWxsIGFzIEVMSS9F TCBmb3IgUFcgKGJhc2VkIG9uIG1pY3JvZmxvdyB3aXRoaW4gUFcpIHJlc2lkZXMNCmJlbG93IFBX IGxhYmVsLiBUaHVzLCBAaW5ncmVzcyBQRSwgb25jZSBtaWNyb2Zsb3cgaXMgaWRlbnRpZmllZCwg ZWl0aGVyIEVMSS9FTA0Kb3IgRkFUIFBXIGxhYmVsIGlzIHB1c2hlZC4NCg0KQFMtUEUsIFBXIGxh YmVsIHN3YXAgZG9lcyBub3QgaGF2ZSB0byBwcmVzZXJ2ZSB0aGUgRUxJL0VMIHdoaWxlIGRvaW5n IFBXIGxhYmVsIHN3YXBwaW5nLA0KQkVDQVVTRSBpdCBpcyBhbHJlYWR5IGJlbG93IHRoZSBQVyBs YWJlbCwganVzdCBsaWtlIGhvdyBGQVQgUFcgbGFiZWwgd291bGQgYmUuDQoNCkkgY29uZmlybWVk IHRoaXMgZnJvbSBvdXIgZGF0YSBwbGFuZSBlbmdpbmVlci4NCih3ZSBjYW4gY2hlY2sgd2l0aCBL aXJlZXRpIGFzIHdlbGwpDQoNCkkgd291bGQgbGlrZSB0byBrbm93IGlmIG90aGVyIHZlbmRvcnMg YXJlIGRvaW5nIHRoaXMgZGlmZmVyZW50bHk/Pw0KDQpHaXZlbiB0aGlzIGlzIHRydWUsIGZvciB0 aGUgc3dpdGNoZXMgdGhhdCBkbyBEUEkgcGFzdCBQVyBjb250cm9sIHdvcmQgZm9yIEVDTVAsDQoN CiAgKiAgIEZBVCBQVyBsYWJlbCB3b3VsZCBzdWZmZXIgdGhlIHNhbWUgbWlzb3JkZXJpbmcgYXMg bm8gRkFUIFBXIGxhYmVsDQogICogICBIb3dldmVyLCBFTEkvRUwgd291bGQgTk9UIOKAkyBiZWNh dXNlIG9mIHRoZSBwcmVzZW5jZSBvZiBFTEkNCg0KVGhhbmtzLA0KSGltYW5zaHUNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNClRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSBy ZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggaXMNCkNPTkZJREVO VElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzDQp0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0g dXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwN CmFuZCBhbGwgY29waWVzIHRoZXJlb2YuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoNClRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNp cGllbnQgb25seSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggaXMNCkNPTkZJREVOVElB TCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzDQp0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0gdXMg YnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwNCmFu ZCBhbGwgY29waWVzIHRoZXJlb2YuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K --_000_A756C03C90E34BEC95C0B07836C8AE5Ecienacom_ Content-Type: text/html; charset="utf-8" Content-ID: <79497D70E4A0844F9862F13F2BFCF084@namprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPjxzdHls ZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hh cGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0 eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcgMyA5IDIgMiA1IDIgNCA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAg MCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5v c2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2Fs aWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlRyZWJ1Y2hldCBNUyI7DQoJcGFub3NlLTE6MiAxMSA2 IDMgMiAyIDIgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29M aXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0K CXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAubXNvY2hwZGVmYXVsdCwgbGkubXNvY2hwZGVmYXVsdCwgZGl2Lm1z b2NocGRlZmF1bHQNCgl7bXNvLXN0eWxlLW5hbWU6bXNvY2hwZGVmYXVsdDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uZW1haWxzdHlsZTE3DQoJe21zby1zdHls ZS1uYW1lOmVtYWlsc3R5bGUxNzsNCglmb250LWZhbWlseToiQ29uc29sYXMiLHNhbnMtc2VyaWY7 DQoJY29sb3I6IzA0MzJGRjsNCglmb250LXN0eWxlOml0YWxpYzt9DQpzcGFuLm1zb2lucw0KCXtt c28tc3R5bGUtbmFtZTptc29pbnM7DQoJY29sb3I6dGVhbDsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uZW1haWxzdHlsZTIxDQoJe21zby1zdHlsZS1uYW1lOmVtYWlsc3R5bGUy MTsNCglmb250LWZhbWlseToiVHJlYnVjaGV0IE1TIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwNDMy RkY7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4uRW1h aWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJUcmVidWNoZXQgTVMiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzA0MzJGRjsNCglmb250LXdlaWdo dDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5p dGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjExNTgzMjI4OTsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6NDgzNTM2NjA4O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjsNCglt c28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxl Pg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2 M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBN UyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPkhpIFNhc2hhIOKAkzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzA0MzJGRiI+SSB1bmRlcnN0YW5kIHRoYXQgYW5kIEkgZG8gbm90IHdhbnQgdG8gYmVsYWJvciBt eSBwb2ludC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzA0MzJGRiI+U28ganVzdCB0byBjbGFyaWZ5IG15IHBvaW50LCB5b3UgY2FuIHZpZXcg TVMtUFcgYXMg4oCcUFctTFNQ4oCdDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+d2l0aCBTLVBFIGFzIOKAnFBXLUxTUuKAnS4g SW4gdGhhdCBjb250ZXh0LCBFTEkvRUwgYmVsb3cgUFcgbGFiZWwsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPm1ha2VzIHNlbnNl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MDQzMkZGIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzA0MzJGRiI+RkFUIFBXIFJGQyBwcmVkYXRlcyB0aGUgRUxJL0VMLCBidXQg aWYgdGhhdCB3YXMgbm90IHRoZSBjYXNlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGIj5FTEkvRUwgZWFzaWx5IHdvdWxkIGhhdmUg YmVlbiB1c2VkIGFzIHRoZSBzb2x1dGlvbiB0aGUgd2F5IEkgZGVzY3JpYmUgYWJvdmUuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDQzMkZGIj5CdXQgdGhhdCBpcyBhbGwgd2F0ZXIgdW5kZXIgdGhlIGJyaWRnZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJG RiI+U28sIGxldCB1cyBtb3ZlIG9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJl YnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRjtiYWNrZ3JvdW5kOnllbGxv dzttc28taGlnaGxpZ2h0OnllbGxvdyI+T24gdGhlIGZvbGxvdyBvbiB0b3BpYyBvbiB0aGUgZ3Vp ZGVsaW5lLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDQzMkZGO2JhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij5XaGVy ZSB3ZSBzYXkg4oCcd2hlbiBib3RoIGFyZSBzdXBwb3J0ZWQgT05MWSBPTkUgKEVMSS9FTCBvciBG QVQgbGFiZWwpIFNIT1VMRCBiZSB1c2Vk4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQg TVMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGO2JhY2tncm91bmQ6eWVsbG93O21zby1o aWdobGlnaHQ6eWVsbG93Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRjtiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxp Z2h0OnllbGxvdyI+U2luY2UgRkFUIGxhYmVsIGRvZXMgbm90IHByb3RlY3QgZnJvbSBFQ01QIGJh c2VkIG9uIERQSSBiZXlvbmQgUFcgQ1csIEJPVEggc2NoZW1lcyBhcmU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRjtiYWNrZ3JvdW5k OnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+cmVxdWlyZWQgc2luY2UgRkFUIGxhYmVsIHN1 ZmZlcnMgc2FtZSBtaXMtb3JkZXJpbmcgY29uc2VxdWVuY2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU cmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGO2JhY2tncm91bmQ6eWVs bG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij5JbiBhZGRpdGlvbiwgUy1QRSBNVVNUIHByZXNlcnZl IGFuZC9vciByZWdlbmVyYXRlIEVMSS9FTCBhYm92ZSBQVyBsYWJlbCw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRjtiYWNrZ3JvdW5k OnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+SWYgV0cgY2hvc2UgdG8gcHJvdmlkZSBndWlk ZWxpbmVzIG9uIGhvdyB0byBhdm9pZCBtaS1vcmRlcmluZyBpbiB0aGUgcHJlc2VuY2Ugb2Ygc3Vj aCBzd2l0Y2hlcy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hl dCBNUyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU cmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMDQzMkZGIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9pPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MDQzMkZGIj5IaW1hbnNodTwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206IDwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mcXVvdDtBbGV4YW5kZXIgY29tJmd0OyZx dW90OyAmbHQ7QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20mZ3Q7PGJyPg0KPGI+RGF0 ZTogPC9iPldlZG5lc2RheSwgTm92ZW1iZXIgMTUsIDIwMTcgYXQgMTo0OCBQTTxicj4NCjxiPlRv OiA8L2I+JnF1b3Q7cGFsc0BpZXRmLm9yZyZxdW90OyAmbHQ7cGFsc0BpZXRmLm9yZyZndDssICZx dW90O1NoYWgsIEhpbWFuc2h1JnF1b3Q7ICZsdDtoc2hhaEBjaWVuYS5jb20mZ3Q7PGJyPg0KPGI+ U3ViamVjdDogPC9iPlJlOiBbUGFsc10gRUxJL0VMIGZvciB0aGUgUFc8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PkhpbWFuc2h1LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPk9mIGNvdXJzZSBFTC9FTEkgY2FuIGJlIHBsYWNlZCBhbnl3aGVyZSBp biB0aGUgc3RhY2suIEJ1dCBpdCBjYW4gb25seSBiZSBpbnNlcnRlZCBpZiB0aGUgRWdyZXNzIExT UiBmb3IgdGhlIHR1bm5lbCBzdXBwb3J0cyBpdC4gQW5kDQogaW4gTVMtUFcgZWFjaCBTLVBFIHRl cm1pbmF0ZXMgdGhlIHR1bm5lbCBMU1AuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RnJvbSBteSBQT1YgZmxvdyBsYWJlbHMgYXJl IHRoZSBPTkxZIHJpZ2h0IG1lY2hhbmlzbSBmb3IgYWRkaW5nIGVudHJvcHkgdG8gTVMtUFdzIGVu ZC10by1lbmQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRodW1w IHR5cGVkIGJ5IFNhc2hhIFZhaW5zaHRlaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9Ijk4JSIgYWxpZ249ImNlbnRlciI+ DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IGlkPSJkaXZScGx5RndkTXNnIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPiBT aGFoLCBIaW1hbnNodSAmbHQ7aHNoYWhAY2llbmEuY29tJmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBX ZWRuZXNkYXksIE5vdmVtYmVyIDE1LCAyMDE3IDM6MjQ6NTQgQU08YnI+DQo8Yj5Ubzo8L2I+IEFs ZXhhbmRlciBWYWluc2h0ZWluOyBwYWxzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbUGFsc10gRUxJL0VMIGZvciB0aGUgUFc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzA0MzJGRiI+SGkgU2hhc2hhLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNo ZXQgTVMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+WW91IGFy ZSBjb3JyZWN0IGFib3V0IGhvdyBpdCBpcyB3cml0dGVuIGluIFJGQyA2NzkwLg0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMDQzMkZGIj5JIGRpZCB0YWxrIHRvIEtpcmVldGkgYnJpZWZseSBpbiB0aGUgaGFsbHdheSBh Ym91dCBwbGFjZW1lbnQgb2YgRUxJL0VMIGFuZCBNUy1QVy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJl YnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+SGUgYWxzbyBkaWQgc2F5 IHRoZSBzYW1lIGJ1dCBoZSBhbHNvIHNhaWQgdGhhdCBpdCBkb2VzIG5vdCBtYXR0ZXIgd2hlcmUg eW91IHBsYWNlIGl0LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDQzMkZGIj5hcyBmYXIgYXMgcHJvY2Vzc2luZyBvZiB0aGUgRUxJL0VMLCB3 b3VsZCB3b3JrIGlycmVzcGVjdGl2ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Ry ZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPk1TLVBXIHRlY2hub2xv Z3kgdGhyb3dzIHRoZSBtb25rZXkgcmFuY2guDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0 IE1TJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+T25lIGNvdWxkIGp1c3Qgc3VwcG9y dCA2NzkwIGFuZCBub3QgNjM5MSBmb3IgUFcgaWYgRUxJL0VMIHBsYWNlZCBiZWxvdyBQVyBsYWJl bC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzA0MzJGRiI+SXQgc29sdmVzIHByZXNlcnZhdGlvbiBvZiBlbnRyb3B5IGFjcm9zcyBTLVBFLCBu aWNlbHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMwNDMyRkYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb25zb2xhcyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPlRoYW5rcyw8 L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb25zb2xh cyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPkhpbWFuc2h1PC9zcGFuPjwvaT48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206IDwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mcXVvdDtBbGV4YW5kZXIgY29tJmd0OyZx dW90OyAmbHQ7QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20mZ3Q7PGJyPg0KPGI+RGF0 ZTogPC9iPlR1ZXNkYXksIE5vdmVtYmVyIDE0LCAyMDE3IGF0IDg6MTQgUE08YnI+DQo8Yj5Ubzog PC9iPiZxdW90O3BhbHNAaWV0Zi5vcmcmcXVvdDsgJmx0O3BhbHNAaWV0Zi5vcmcmZ3Q7LCAmcXVv dDtTaGFoLCBIaW1hbnNodSZxdW90OyAmbHQ7aHNoYWhAY2llbmEuY29tJmd0Ozxicj4NCjxiPlN1 YmplY3Q6IDwvYj5SZTogW1BhbHNdIEVMSS9FTCBmb3IgdGhlIFBXPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5I aW1hbXNodSBhbmQgYWxsLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPkkgcmVzcGV0ZnVsbHkgZGlzYWdyZWUuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+QXMgSSBz ZWUgaXQsIFJGQyA2NzkwIGluIFNlY3Rpb24gNC4yIEluZ3Jlc3MgTFNSJnF1b3Q7IGluYW1iaWd1 b3VzbHkgc3RhdGVzIHRoYXQgRUwgYW5kIEVMSSwgaWYgdXNlZCwgYmV0d2VlbiB0aHIgVEwgYW5k ICZxdW90O2FwcGxpY2F0aW9uDQogbGFiZWwmcXVvdDsgKGlmIHNwcGxpY2F0aW9uIGxzYmVsIGlz IHVzZWQpLiBJdCBhbHNvIHNwZWNpZmllcywgdGhhdCBFTCBhbmQgRUxJIGFyZSBvbmx5IHB1c2hl ZCBvbiBhbiBpbmNvbWluZyBwYWNrZXQgaWYgdGhlIHR1bm5lbCBlZ3Jlc3MgTFNSIGhhcyBzaWdu YWxlZCB0aGF0IGl0IGNhbiBoYW5kbGUgRUwgb24gdGhlIHNwZWNpZmljIHR1bm5lbCBMU1AgaXQg dGVybWluYXRlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj5UbyBtZSB0aGlzIG1lYW5zIHRoYXQgaW4gdGhlIGNhc2Ugb2YgYSBN Uy1QVywgRUwgYW5kIEVMSSBDQU5OT1QgcHJlc2VydmVkIGJ5IGFuIFMtUEUuIFdoZXRoZXIgdGhl eSBjYW4gYmUgZ2VuZXJhdGVkIGJ5IGFuIFNQRSBpcw0KIGFub3RoZXIgc3RvcnkuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RkFU IGxhYmVscywgb24gdGhlIGNvbnRyYXJ5LCBhcmUgYWx3YXlzIHRoZSBCb1MgbGFiZWxzIGFuZCB0 aHJyZm9yZSBhcmUgcHJlc2VydmVkIGJ5IFNQRXMgb2YgYSBNUy1QVy48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5EaWQgSSBtaXNz IHNvbWV0aGluZyBzdWJzdGFudGlhbD88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPlRodW1wIHR5cGVkIGJ5IFNhc2hhIFZhaW5zaHRlaW48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9Ijk4JSIgYWxp Z249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IGlkPSJkaXZScGx5RndkTXNnIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6YmxhY2siPiBQYWxzICZsdDtwYWxzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBv ZiBTaGFoLCBIaW1hbnNodSAmbHQ7aHNoYWhAY2llbmEuY29tJmd0Ozxicj4NCjxiPlNlbnQ6PC9i PiBUdWVzZGF5LCBOb3ZlbWJlciAxNCwgMjAxNyA1OjMwOjEzIEFNPGJyPg0KPGI+VG86PC9iPiBw YWxzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtQYWxzXSBFTEkvRUwgZm9yIHRoZSBQ Vzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+IDwvc3Bhbj4NCjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGIj5UaGUg UEFMUyBXRyBkaXNjdXNzaW9ucyB5ZXN0ZXJkYXkgYXQgdGhlIElFVEYxMDAsIHdlIGRpc2N1c3Nl ZCB0aGUgY29tcGV0aW5nPC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb25zb2xhcyZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPkZBVCBQVyBhbmQgRUxJL0VMIGZvciB0aGUgUFcgYW5k IGl0cyBmYXRlIGF0IFMtUEUuPC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb25zb2xhcyZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPiZuYnNwOzwvc3Bhbj48L2k+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGIj5JIG1lbnRpb25lZCB0 aGlzIGF0IE1pa2UgYnV0IGdvdCBsb3N0IGluIHN1YnNlcXVlbnQgZGlzY3Vzc2lvbnMuPC9zcGFu PjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb25zb2xhcyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMy RkYiPiZuYnNwOzwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDQzMkZGIj5GQVQgUFcgbGFiZWwgYXMgd2VsbCBhcyBFTEkvRUwgZm9yIFBX IChiYXNlZCBvbiBtaWNyb2Zsb3cgd2l0aGluIFBXKSByZXNpZGVzPC9zcGFuPjwvaT48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb25zb2xhcyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPmJlbG93IFBX IGxhYmVsLiBUaHVzLCBAaW5ncmVzcyBQRSwgb25jZSBtaWNyb2Zsb3cgaXMgaWRlbnRpZmllZCwg ZWl0aGVyIEVMSS9FTDwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMDQzMkZGIj5vciBGQVQgUFcgbGFiZWwgaXMgcHVzaGVkLjwvc3Bhbj48 L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZG Ij4mbmJzcDs8L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGk+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvbnNvbGFzJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzA0MzJGRiI+QFMtUEUsIFBXIGxhYmVsIHN3YXAgZG9lcyBub3QgaGF2ZSB0byBw cmVzZXJ2ZSB0aGUgRUxJL0VMIHdoaWxlIGRvaW5nIFBXIGxhYmVsIHN3YXBwaW5nLDwvc3Bhbj48 L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZG Ij5CRUNBVVNFIGl0IGlzIGFscmVhZHkgYmVsb3cgdGhlIFBXIGxhYmVsLCBqdXN0IGxpa2UgaG93 IEZBVCBQVyBsYWJlbCB3b3VsZCBiZS48L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvbnNvbGFz JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+Jm5ic3A7PC9zcGFuPjwvaT48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb25zb2xhcyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPkkgY29uZmly bWVkIHRoaXMgZnJvbSBvdXIgZGF0YSBwbGFuZSBlbmdpbmVlci48L3NwYW4+PC9pPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvbnNvbGFzJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+KHdlIGNhbiBj aGVjayB3aXRoIEtpcmVldGkgYXMgd2VsbCk8L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvbnNv bGFzJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+Jm5ic3A7PC9zcGFuPjwvaT48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb25zb2xhcyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPkkgd291 bGQgbGlrZSB0byBrbm93IGlmIG90aGVyIHZlbmRvcnMgYXJlIGRvaW5nIHRoaXMgZGlmZmVyZW50 bHk/Pzwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDQzMkZGIj4mbmJzcDs8L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvbnNvbGFzJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+R2l2ZW4gdGhpcyBpcyB0cnVlLCBmb3IgdGhl IHN3aXRjaGVzIHRoYXQgZG8gRFBJIHBhc3QgUFcgY29udHJvbCB3b3JkIGZvciBFQ01QLA0KPC9z cGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9 ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMDQzMkZGO21hcmdp bi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8aT48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZiI+RkFUIFBXIGxhYmVsIHdv dWxkIHN1ZmZlciB0aGUgc2FtZSBtaXNvcmRlcmluZyBhcyBubyBGQVQgUFcgbGFiZWw8L3NwYW4+ PC9pPjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMw NDMyRkY7bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxpPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb25zb2xhcyZxdW90OyxzYW5zLXNlcmlmIj5Ib3dl dmVyLCBFTEkvRUwgd291bGQgTk9UIOKAkyBiZWNhdXNlIG9mIHRoZSBwcmVzZW5jZSBvZiBFTEk8 L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvbnNvbGFzJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzA0MzJGRiI+Jm5ic3A7PC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvbnNvbGFzJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+VGhhbmtzLDwv c3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb25zb2xhcyZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPkhpbWFuc2h1PC9zcGFuPjwvaT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YnI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQo8YnI+DQpUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZv ciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzDQo8 YnI+DQpDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBFQ0kgVGVs ZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcw0KPGJyPg0KdHJhbnNtaXNzaW9uIGluIGVy cm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBk ZWxldGUgdGhlIG9yaWdpbmFsDQo8YnI+DQphbmQgYWxsIGNvcGllcyB0aGVyZW9mLjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KPGJyPg0KVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRl bmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucyBpbmZvcm1hdGlvbiB3aGlj aCBpcw0KPGJyPg0KQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8g RUNJIFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMNCjxicj4NCnRyYW5zbWlzc2lv biBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5k IHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbA0KPGJyPg0KYW5kIGFsbCBjb3BpZXMgdGhlcmVvZi48 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_A756C03C90E34BEC95C0B07836C8AE5Ecienacom_-- From nobody Wed Nov 15 00:07:08 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74B712951F; Wed, 15 Nov 2017 00:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 9s3iu1Bv7AEx; Wed, 15 Nov 2017 00:06:58 -0800 (PST) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 4473B129484; Wed, 15 Nov 2017 00:06:58 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id o7so17448635pgc.4; Wed, 15 Nov 2017 00:06:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=IeO71A3x738udttd11vyTuTxOYRgJf3H9rDo3ePBmdc=; b=RV18zBs3R6yKY1Gx8vs6oyXftndJG8krwq0iMw2LiwmTyTpDDpfI7PCg8xV2rpY0Df LyxP9ILUOS1BOqbO25rx+DkXr1Cfo+H09cFh1AxIyGFM48seQ2B8lJK39p8ppP67DRMX bhpWmrhJ2tFf/CxYNvJBAVtSEUlzvPf/2QNeQB7Ojczk0Q5dLeaed96GHPqErRFElHfl pkNvrk5yZP0+x+N2V9E18YZSUkNQR6x65N0YNOAFlrtqxrnNY2OlLpjwJ+ZSEWzQ+6s6 tXnN0RKSH8oel8Kz/984ZExh99x9TdCnjjWtuLYWWllZqdAa/j7d1RIekF41mabnRyqq TOgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=IeO71A3x738udttd11vyTuTxOYRgJf3H9rDo3ePBmdc=; b=IzhAFrhTrn/JYSSxyRPti6AWhHygN7v+0hzhzOuiWppekuf3LurpZhEYKWwqiNCOL3 /1xNGT+dEc6MSb73oUYKcQSbe0oZsYaqbED7FrKss2Rj996jX10z0l5LFyYNmgpWjMLE f0Q4cXPYiJGnOJJNV9x4VSumBlNhaifIfbmOVPyWkgHJprXIWG00w5wwigP7dBKM0UxN XuL5aVDFfnjTVZRzp8Kgq+wUOnItnwY3NFsTOfnhHPwwOdp21sFRZC0IzylLaAFi4d5e Q3pg14ENvoFl1TxT5rK1w62Uh7/h6IktaZ5ZG+kYrno/5n7PaI5z6Kov2ZnP5hDVjbKD iCWw== X-Gm-Message-State: AJaThX63tSaGbgRebeCUEgKcPeg5dN65o6cM9Zg9GgkSKIAmuc6JebdW gEVVEfE80hbMSv8IDeR85pA8M80s X-Google-Smtp-Source: AGs4zMb70/aJ5XoYKkQ4oVeIMae+4COEqsiqbAKoN6jXs2ZbffFUlQX6kvYCKyjvHaz2Xg6VR4IQRA== X-Received: by 10.84.246.137 with SMTP id m9mr5272040pll.130.1510733217429; Wed, 15 Nov 2017 00:06:57 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:6d57:6a96:8c2e:a38? ([2001:67c:370:128:6d57:6a96:8c2e:a38]) by smtp.gmail.com with ESMTPSA id g7sm41615964pfj.13.2017.11.15.00.06.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 00:06:56 -0800 (PST) To: pals@ietf.org, "mpls@ietf.org" References: <741BDF3F-C90F-44FF-AD59-A29CF612FBBD@ciena.com> From: Stewart Bryant Message-ID: <683f4b93-a3ae-ada5-f716-be7c409188e2@gmail.com> Date: Wed, 15 Nov 2017 08:06:56 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E92078823D2D9CB3F1BB54CB" Content-Language: en-GB Archived-At: Subject: Re: [Pals] ELI/EL for the PW X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 08:07:01 -0000 This is a multi-part message in MIME format. --------------E92078823D2D9CB3F1BB54CB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Copying the thread to MPLS to include them in the discussion. Please will copy future discussion to MPLS on this topic. Thanks Stewart On 15/11/2017 06:14, Shah, Himanshu wrote: > > Hi Sasha – > > I understand that and I do not want to belabor my point. > > So just to clarify my point, you can view MS-PW as “PW-LSP” > > with S-PE as “PW-LSR”. In that context, ELI/EL below PW label, > > makes sense. > > FAT PW RFC predates the ELI/EL, but if that was not the case, > > ELI/EL easily would have been used as the solution the way I describe > above. > > But that is all water under the bridge. > > So, let us move on. > > On the follow on topic on the guideline, > > Where we say “when both are supported ONLY ONE (ELI/EL or FAT label) > SHOULD be used”. > > Since FAT label does not protect from ECMP based on DPI beyond PW CW, > BOTH schemes are > > required since FAT label suffers same mis-ordering consequences. > > In addition, S-PE MUST preserve and/or regenerate ELI/EL above PW label, > > If WG chose to provide guidelines on how to avoid mi-ordering in the > presence of such switches. > > /Thanks,/ > > /Himanshu/ > > *From: *"Alexander com>" > *Date: *Wednesday, November 15, 2017 at 1:48 PM > *To: *"pals@ietf.org" , "Shah, Himanshu" > *Subject: *Re: [Pals] ELI/EL for the PW > > Himanshu, > > Of course EL/ELI can be placed anywhere in the stack. But it can only > be inserted if the Egress LSR for the tunnel supports it. And in MS-PW > each S-PE terminates the tunnel LSP. > > From my POV flow labels are the ONLY right mechanism for adding > entropy to MS-PWs end-to-end. > > Thump typed by Sasha Vainshtein > > ------------------------------------------------------------------------ > > *From:*Shah, Himanshu > *Sent:* Wednesday, November 15, 2017 3:24:54 AM > *To:* Alexander Vainshtein; pals@ietf.org > *Subject:* Re: [Pals] ELI/EL for the PW > > Hi Shasha, > > You are correct about how it is written in RFC 6790. > > I did talk to Kireeti briefly in the hallway about placement of ELI/EL > and MS-PW. > > He also did say the same but he also said that it does not matter > where you place it, > > as far as processing of the ELI/EL, would work irrespective. > > MS-PW technology throws the monkey ranch. > > One could just support 6790 and not 6391 for PW if ELI/EL placed below > PW label. > > It solves preservation of entropy across S-PE, nicely. > > /Thanks,/ > > /Himanshu/ > > *From: *"Alexander com>" > *Date: *Tuesday, November 14, 2017 at 8:14 PM > *To: *"pals@ietf.org" , "Shah, Himanshu" > *Subject: *Re: [Pals] ELI/EL for the PW > > Himamshu and all, > > I respetfully disagree. > > As I see it, RFC 6790 in Section 4.2 Ingress LSR" inambiguously states > that EL and ELI, if used, between thr TL and "application label" (if > spplication lsbel is used). It also specifies, that EL and ELI are > only pushed on an incoming packet if the tunnel egress LSR has > signaled that it can handle EL on the specific tunnel LSP it terminates. > > To me this means that in the case of a MS-PW, EL and ELI CANNOT > preserved by an S-PE. Whether they can be generated by an SPE is > another story. > > FAT labels, on the contrary, are always the BoS labels and thrrfore > are preserved by SPEs of a MS-PW. > > Did I miss something substantial? > > Thump typed by Sasha Vainshtein > > ------------------------------------------------------------------------ > > *From:*Pals on behalf of Shah, Himanshu > > *Sent:* Tuesday, November 14, 2017 5:30:13 AM > *To:* pals@ietf.org > *Subject:* [Pals] ELI/EL for the PW > > /The PALS WG discussions yesterday at the IETF100, we discussed the > competing/ > > /FAT PW and ELI/EL for the PW and its fate at S-PE./ > > // > > /I mentioned this at Mike but got lost in subsequent discussions./ > > // > > /FAT PW label as well as ELI/EL for PW (based on microflow within PW) > resides/ > > /below PW label. Thus, @ingress PE, once microflow is identified, > either ELI/EL/ > > /or FAT PW label is pushed./ > > // > > /@S-PE, PW label swap does not have to preserve the ELI/EL while doing > PW label swapping,/ > > /BECAUSE it is already below the PW label, just like how FAT PW label > would be./ > > // > > /I confirmed this from our data plane engineer./ > > /(we can check with Kireeti as well)/ > > // > > /I would like to know if other vendors are doing this differently??/ > > // > > /Given this is true, for the switches that do DPI past PW control word > for ECMP, / > > * /FAT PW label would suffer the same misordering as no FAT PW label/ > * /However, ELI/EL would NOT – because of the presence of ELI/ > > // > > /Thanks,/ > > /Himanshu/ > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and > then delete the original > and all copies thereof. > ___________________________________________________________________________ > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and > then delete the original > and all copies thereof. > ___________________________________________________________________________ > > > > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals --------------E92078823D2D9CB3F1BB54CB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Copying the thread to MPLS to include them in the discussion.

Please will copy future discussion to MPLS on this topic.

Thanks

Stewart


On 15/11/2017 06:14, Shah, Himanshu wrote:

Hi Sasha –

 

I understand that and I do not want to belabor my point.

So just to clarify my point, you can view MS-PW as “PW-LSP”

with S-PE as “PW-LSR”. In that context, ELI/EL below PW label,

makes sense.

 

FAT PW RFC predates the ELI/EL, but if that was not the case,

ELI/EL easily would have been used as the solution the way I describe above.

 

But that is all water under the bridge.

So, let us move on.

 

On the follow on topic on the guideline,

Where we say “when both are supported ONLY ONE (ELI/EL or FAT label) SHOULD be used”.

 

Since FAT label does not protect from ECMP based on DPI beyond PW CW, BOTH schemes are

required since FAT label suffers same mis-ordering consequences.

In addition, S-PE MUST preserve and/or regenerate ELI/EL above PW label,

If WG chose to provide guidelines on how to avoid mi-ordering in the presence of such switches.

 

Thanks,

Himanshu

 

From: "Alexander com>" <Alexander.Vainshtein@ecitele.com>
Date: Wednesday, November 15, 2017 at 1:48 PM
To: "pals@ietf.org" <pals@ietf.org>, "Shah, Himanshu" <hshah@ciena.com>
Subject: Re: [Pals] ELI/EL for the PW

 

Himanshu,

Of course EL/ELI can be placed anywhere in the stack. But it can only be inserted if the Egress LSR for the tunnel supports it. And in MS-PW each S-PE terminates the tunnel LSP.

From my POV flow labels are the ONLY right mechanism for adding entropy to MS-PWs end-to-end.

Thump typed by Sasha Vainshtein

 

From: Shah, Himanshu <hshah@ciena.com>
Sent: Wednesday, November 15, 2017 3:24:54 AM
To: Alexander Vainshtein; pals@ietf.org
Subject: Re: [Pals] ELI/EL for the PW

 

Hi Shasha,

 

You are correct about how it is written in RFC 6790.

 

I did talk to Kireeti briefly in the hallway about placement of ELI/EL and MS-PW.

He also did say the same but he also said that it does not matter where you place it,

as far as processing of the ELI/EL, would work irrespective.

 

MS-PW technology throws the monkey ranch.

One could just support 6790 and not 6391 for PW if ELI/EL placed below PW label.

It solves preservation of entropy across S-PE, nicely.

 

Thanks,

Himanshu

 

From: "Alexander com>" <Alexander.Vainshtein@ecitele.com>
Date: Tuesday, November 14, 2017 at 8:14 PM
To: "pals@ietf.org" <pals@ietf.org>, "Shah, Himanshu" <hshah@ciena.com>
Subject: Re: [Pals] ELI/EL for the PW

 

Himamshu and all,

I respetfully disagree.

As I see it, RFC 6790 in Section 4.2 Ingress LSR" inambiguously states that EL and ELI, if used, between thr TL and "application label" (if spplication lsbel is used). It also specifies, that EL and ELI are only pushed on an incoming packet if the tunnel egress LSR has signaled that it can handle EL on the specific tunnel LSP it terminates.

To me this means that in the case of a MS-PW, EL and ELI CANNOT preserved by an S-PE. Whether they can be generated by an SPE is another story.

FAT labels, on the contrary, are always the BoS labels and thrrfore are preserved by SPEs of a MS-PW.

Did I miss something substantial?

Thump typed by Sasha Vainshtein

 

From: Pals <pals-bounces@ietf.org> on behalf of Shah, Himanshu <hshah@ciena.com>
Sent: Tuesday, November 14, 2017 5:30:13 AM
To: pals@ietf.org
Subject: [Pals] ELI/EL for the PW

 

The PALS WG discussions yesterday at the IETF100, we discussed the competing

FAT PW and ELI/EL for the PW and its fate at S-PE.

 

I mentioned this at Mike but got lost in subsequent discussions.

 

FAT PW label as well as ELI/EL for PW (based on microflow within PW) resides

below PW label. Thus, @ingress PE, once microflow is identified, either ELI/EL

or FAT PW label is pushed.

 

@S-PE, PW label swap does not have to preserve the ELI/EL while doing PW label swapping,

BECAUSE it is already below the PW label, just like how FAT PW label would be.

 

I confirmed this from our data plane engineer.

(we can check with Kireeti as well)

 

I would like to know if other vendors are doing this differently??

 

Given this is true, for the switches that do DPI past PW control word for ECMP,

  • FAT PW label would suffer the same misordering as no FAT PW label
  • However, ELI/EL would NOT – because of the presence of ELI

 

Thanks,

Himanshu


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________



_______________________________________________
Pals mailing list
Pals@ietf.org
https://www.ietf.org/mailman/listinfo/pals

--------------E92078823D2D9CB3F1BB54CB-- From nobody Wed Nov 15 14:54:02 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7A5128D16 for ; Wed, 15 Nov 2017 14:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=broadcom.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 pvEivsVI4nfD for ; Wed, 15 Nov 2017 14:53:57 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 7D0E5128D0F for ; Wed, 15 Nov 2017 14:53:57 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id r58so14344786qtc.0 for ; Wed, 15 Nov 2017 14:53:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=A74dJTzylO50T8oIQF2Wa2hb0H79ZG/t5dGyaNEUTho=; b=IOqN42mZt+mdUD31EizI7FErmuVfZXslnitAAynJ8if3BRJ4Y6kje63hDxTTnvANZP BGxWYPj5ifUEtqys22Llxv6P0/lT5rWwDTIIXRxWPkvvPZdkHATHjeo9nXpn9yDyweNw AlLxQtCPQEWthbc/CD/e26/t5MnDDmW0MazUg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=A74dJTzylO50T8oIQF2Wa2hb0H79ZG/t5dGyaNEUTho=; b=byO+ZeKOKNngyMEMsgunylzn0C0uWUJm3iKOWvIqEYnbTJtjpnyyy4oZfW5S7g1XCN gPkNc5OKZGsvvASp6XWsR5S9/LotyzutDPGDSjlaRXcj8e5ueb0p8sG1wtF4gESn+niM UmOa4KSolulepElekWaBPpzVp8GtXu8AJFcNS/L2L0rJ1ecO8WVLVo8Be09StUgKfZT1 4U/4LqBAinSoSdYLYqvJBiYEm/HaJSuZrtGEb0FHfLV8bJDXPR9xgjn5XPPgn9KR5eao MFHkiiSQu9iUdq0g/RZv+aR0t4ZY70dWAg0tyNmzIoNHxDtfMJjULT1HXY6xSLoiGyFd o+Ww== X-Gm-Message-State: AJaThX5/+Dy9qaJBk9SDPo0WyvXu+/reJagHmebhdFVr5+uHo4Z5MABX HchDGw2QUqm57GBhXVNFwn+v8A== X-Google-Smtp-Source: AGs4zMaqTuOnApS/fZTV6c2xrVosjsy9CuS5HbmIxaHMvm5ZMB56CXUj8tBfu5rKsZfnFMDo9+gstg== X-Received: by 10.55.27.88 with SMTP id b85mr27114108qkb.144.1510786436285; Wed, 15 Nov 2017 14:53:56 -0800 (PST) Received: from c02rq0djfvh9.dhcp.broadcom.net ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id m6sm14928886qti.14.2017.11.15.14.53.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 15 Nov 2017 14:53:55 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_48882BA7-9DEB-4BBC-9CFC-E466CB29647B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Shahram Davari In-Reply-To: <683f4b93-a3ae-ada5-f716-be7c409188e2@gmail.com> Date: Wed, 15 Nov 2017 14:53:53 -0800 Cc: pals@ietf.org, "mpls@ietf.org" Message-Id: <1A447EAF-9C33-4469-A86C-45C7456DB013@broadcom.com> References: <741BDF3F-C90F-44FF-AD59-A29CF612FBBD@ciena.com> <683f4b93-a3ae-ada5-f716-be7c409188e2@gmail.com> To: Stewart Bryant X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Pals] [mpls] ELI/EL for the PW X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 22:54:01 -0000 --Apple-Mail=_48882BA7-9DEB-4BBC-9CFC-E466CB29647B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Himanshu We can=E2=80=99t consider the PW label as PW-LSP, even though there is a = PW label swapping at S-PE. At most you can consider it as PW-LSP only at the S-PE but not at the Terminating PE. We can=E2=80=99t do it is because we need to get packet processing = context from PW label such as the Payload Type (IP, Ethernet, etc.), = Existence of CW, and whether we are doing PHP or not, etc. If we assume = PW-LSP then we can=E2=80=99t get any of these information from PW label. So I really object to using ELI/EL below PW label. Existing HW that = complies to RFCs can=E2=80=99t support this. Thx Shahram > On Nov 15, 2017, at 12:06 AM, Stewart Bryant = wrote: >=20 > Copying the thread to MPLS to include them in the discussion. >=20 > Please will copy future discussion to MPLS on this topic. >=20 > Thanks >=20 > Stewart >=20 >=20 > On 15/11/2017 06:14, Shah, Himanshu wrote: >> Hi Sasha =E2=80=93 >> =20 >> I understand that and I do not want to belabor my point. >> So just to clarify my point, you can view MS-PW as =E2=80=9CPW-LSP=E2=80= =9D >> with S-PE as =E2=80=9CPW-LSR=E2=80=9D. In that context, ELI/EL below = PW label, >> makes sense. >> =20 >> FAT PW RFC predates the ELI/EL, but if that was not the case, >> ELI/EL easily would have been used as the solution the way I describe = above. >> =20 >> But that is all water under the bridge. >> So, let us move on. >> =20 >> On the follow on topic on the guideline, >> Where we say =E2=80=9Cwhen both are supported ONLY ONE (ELI/EL or FAT = label) SHOULD be used=E2=80=9D. >> =20 >> Since FAT label does not protect from ECMP based on DPI beyond PW CW, = BOTH schemes are >> required since FAT label suffers same mis-ordering consequences. >> In addition, S-PE MUST preserve and/or regenerate ELI/EL above PW = label, >> If WG chose to provide guidelines on how to avoid mi-ordering in the = presence of such switches. >> =20 >> Thanks, >> Himanshu >> =20 >> From: "Alexander com>" = >> Date: Wednesday, November 15, 2017 at 1:48 PM >> To: "pals@ietf.org" = , "Shah, Himanshu" = >> Subject: Re: [Pals] ELI/EL for the PW >> =20 >> Himanshu, >> Of course EL/ELI can be placed anywhere in the stack. But it can only = be inserted if the Egress LSR for the tunnel supports it. And in MS-PW = each S-PE terminates the tunnel LSP. >>=20 >> =46rom my POV flow labels are the ONLY right mechanism for adding = entropy to MS-PWs end-to-end. >>=20 >> Thump typed by Sasha Vainshtein >> =20 >> From: Shah, Himanshu >> Sent: Wednesday, November 15, 2017 3:24:54 AM >> To: Alexander Vainshtein; pals@ietf.org >> Subject: Re: [Pals] ELI/EL for the PW >> =20 >> Hi Shasha, >> =20 >> You are correct about how it is written in RFC 6790. >> =20 >> I did talk to Kireeti briefly in the hallway about placement of = ELI/EL and MS-PW. >> He also did say the same but he also said that it does not matter = where you place it, >> as far as processing of the ELI/EL, would work irrespective. >> =20 >> MS-PW technology throws the monkey ranch. >> One could just support 6790 and not 6391 for PW if ELI/EL placed = below PW label. >> It solves preservation of entropy across S-PE, nicely. >> =20 >> Thanks, >> Himanshu >> =20 >> From: "Alexander com>" = >> Date: Tuesday, November 14, 2017 at 8:14 PM >> To: "pals@ietf.org" = , "Shah, Himanshu" = >> Subject: Re: [Pals] ELI/EL for the PW >> =20 >> Himamshu and all, >> I respetfully disagree. >>=20 >> As I see it, RFC 6790 in Section 4.2 Ingress LSR" inambiguously = states that EL and ELI, if used, between thr TL and "application label" = (if spplication lsbel is used). It also specifies, that EL and ELI are = only pushed on an incoming packet if the tunnel egress LSR has signaled = that it can handle EL on the specific tunnel LSP it terminates. >>=20 >> To me this means that in the case of a MS-PW, EL and ELI CANNOT = preserved by an S-PE. Whether they can be generated by an SPE is another = story. >>=20 >> FAT labels, on the contrary, are always the BoS labels and thrrfore = are preserved by SPEs of a MS-PW. >>=20 >> Did I miss something substantial? >>=20 >> Thump typed by Sasha Vainshtein >> =20 >> From: Pals on = behalf of Shah, Himanshu >> Sent: Tuesday, November 14, 2017 5:30:13 AM >> To: pals@ietf.org >> Subject: [Pals] ELI/EL for the PW >> =20 >> The PALS WG discussions yesterday at the IETF100, we discussed the = competing >> FAT PW and ELI/EL for the PW and its fate at S-PE. >> =20 >> I mentioned this at Mike but got lost in subsequent discussions. >> =20 >> FAT PW label as well as ELI/EL for PW (based on microflow within PW) = resides >> below PW label. Thus, @ingress PE, once microflow is identified, = either ELI/EL >> or FAT PW label is pushed. >> =20 >> @S-PE, PW label swap does not have to preserve the ELI/EL while doing = PW label swapping, >> BECAUSE it is already below the PW label, just like how FAT PW label = would be. >> =20 >> I confirmed this from our data plane engineer. >> (we can check with Kireeti as well) >> =20 >> I would like to know if other vendors are doing this differently?? >> =20 >> Given this is true, for the switches that do DPI past PW control word = for ECMP, >> FAT PW label would suffer the same misordering as no FAT PW label >> However, ELI/EL would NOT =E2=80=93 because of the presence of ELI >> =20 >> Thanks, >> Himanshu >>=20 >> = __________________________________________________________________________= _ >>=20 >> This e-mail message is intended for the recipient only and contains = information which is=20 >> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have = received this=20 >> transmission in error, please inform us by e-mail, phone or fax, and = then delete the original=20 >> and all copies thereof. >> = __________________________________________________________________________= _ >>=20 >>=20 >> = __________________________________________________________________________= _ >>=20 >> This e-mail message is intended for the recipient only and contains = information which is=20 >> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have = received this=20 >> transmission in error, please inform us by e-mail, phone or fax, and = then delete the original=20 >> and all copies thereof. >> = __________________________________________________________________________= _ >>=20 >>=20 >>=20 >> _______________________________________________ >> Pals mailing list >> Pals@ietf.org >> https://www.ietf.org/mailman/listinfo/pals = >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls = --Apple-Mail=_48882BA7-9DEB-4BBC-9CFC-E466CB29647B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Himanshu

We= can=E2=80=99t consider the PW label as PW-LSP, even though there is a = PW label swapping at S-PE.  At most you can consider it
as PW-LSP only at the S-PE but not at the Terminating = PE.

We can=E2=80= =99t do it is because we need to get packet processing context from PW = label such as the Payload Type (IP, Ethernet, etc.), Existence of CW, = and whether we are doing PHP or not, etc. If we assume PW-LSP then we = can=E2=80=99t get any of these information from PW label.

So I really object to = using ELI/EL below PW label.  Existing HW that complies to RFCs = can=E2=80=99t support this.

Thx
Shahram

On Nov 15, 2017, at 12:06 AM, Stewart Bryant = <stewart.bryant@gmail.com> wrote:

Copying the thread to MPLS to include them in the = discussion.

Please will copy = future discussion to MPLS on this topic.

Thanks

Stewart


On 15/11/2017 06:14, Shah, = Himanshu wrote:
Hi Sasha = =E2=80=93
 
I understand that and = I do not want to belabor my point.
So just to clarify my = point, you can view MS-PW as =E2=80=9CPW-LSP=E2=80=9D
with S-PE as =E2=80=9CPW-LSR=E2=80=9D. In that context, = ELI/EL below PW label,
makes sense.
 
FAT PW RFC predates the ELI/EL, but if that = was not the case,
ELI/EL easily would have been used as the = solution the way I describe above.
 
But that is all water under the bridge.
So, let us move on.
 
On the follow on topic on the guideline,
Where we say =E2=80=9Cwhen both are supported ONLY ONE = (ELI/EL or FAT label) SHOULD be used=E2=80=9D.
 
Since FAT label does not protect from ECMP = based on DPI beyond PW CW, BOTH schemes are
required since FAT label suffers same mis-ordering = consequences.
In addition, S-PE MUST preserve and/or = regenerate ELI/EL above PW label,
If WG chose to provide = guidelines on how to avoid mi-ordering in the presence of such = switches.
 
Thanks,
Himanshu
 
From: "Alexander com>" <Alexander.Vainshtein@ecitele.com>
Date: Wednesday, November 15, = 2017 at 1:48 PM
To: "pals@ietf.org" <pals@ietf.org>, "Shah, Himanshu" <hshah@ciena.com>
Subject: Re: [Pals] ELI/EL for = the PW
 
Himanshu,

Of course EL/ELI can be placed anywhere in the = stack. But it can only be inserted if the Egress LSR for the tunnel = supports it. And in MS-PW each S-PE terminates the tunnel LSP.

=46rom my POV flow labels are the ONLY right = mechanism for adding entropy to MS-PWs end-to-end.

Thump typed by Sasha = Vainshtein
 
From: Shah, Himanshu <hshah@ciena.com>
Sent: Wednesday, November 15, = 2017 3:24:54 AM
To: Alexander Vainshtein; pals@ietf.org
Subject: Re: [Pals] ELI/EL for the = PW
 
Hi = Shasha,
 
You are correct about = how it is written in RFC 6790.
 
I did talk to Kireeti briefly in the hallway about placement = of ELI/EL and MS-PW.
He also did say the = same but he also said that it does not matter where you place = it,
as far as processing of the ELI/EL, would = work irrespective.
 
MS-PW technology = throws the monkey ranch.
One could just support = 6790 and not 6391 for PW if ELI/EL placed below PW label.
It solves preservation of entropy across S-PE, = nicely.
 
Thanks,
Himanshu
 
From: "Alexander com>" <Alexander.Vainshtein@ecitele.com>
Date: Tuesday, November 14, = 2017 at 8:14 PM
To: "pals@ietf.org" <pals@ietf.org>, "Shah, Himanshu" <hshah@ciena.com>
Subject: Re: [Pals] ELI/EL for = the PW
 
Himamshu and = all,

I respetfully = disagree.

As I see it, RFC 6790 in = Section 4.2 Ingress LSR" inambiguously states that EL and ELI, if used, = between thr TL and "application label" (if spplication lsbel is used). = It also specifies, that EL and ELI are only pushed on an incoming packet = if the tunnel egress LSR has signaled that it can handle EL on the = specific tunnel LSP it terminates.

To me this means that in the case of a MS-PW, EL = and ELI CANNOT preserved by an S-PE. Whether they can be generated by an = SPE is another story.

FAT labels, on the contrary, are always the BoS labels and = thrrfore are preserved by SPEs of a MS-PW.

Did I miss something substantial?

Thump typed by Sasha = Vainshtein
 
From: Pals <pals-bounces@ietf.org> on behalf of Shah, = Himanshu <hshah@ciena.com>
Sent: Tuesday, November 14, 2017 = 5:30:13 AM
To: pals@ietf.org
Subject: [Pals] ELI/EL for the = PW
 
The PALS WG = discussions yesterday at the IETF100, we discussed the = competing
FAT PW and ELI/EL for = the PW and its fate at S-PE.
 
I mentioned = this at Mike but got lost in subsequent discussions.
 
FAT PW label as well as ELI/EL for PW = (based on microflow within PW) resides
below PW label. Thus, @ingress PE, once = microflow is identified, either ELI/EL
or FAT PW label is pushed.
 
@S-PE, PW label swap does not have to = preserve the ELI/EL while doing PW label swapping,
BECAUSE it is already below the PW label, = just like how FAT PW label would be.
 
I confirmed this from our data plane = engineer.
(we can check with = Kireeti as well)
 
I would like = to know if other vendors are doing this differently??
 
Given this is true, for the switches that = do DPI past PW control word for ECMP,
  • FAT PW label would suffer the same = misordering as no FAT PW label
  • However, ELI/EL would NOT =E2=80=93 because of the presence = of ELI
 
Thanks,
Himanshu


_______________________________________________________________= ____________

This e-mail message is = intended for the recipient only and contains information which is 
CONFIDENTIAL = and which may be proprietary to ECI Telecom. If you have received = this 
transmission in error, please inform us by e-mail, phone or = fax, and then delete the original 
and all = copies thereof.
_______________________________________________________________= ____________


_______________________________________________________________= ____________

This e-mail message is = intended for the recipient only and contains information which is 
CONFIDENTIAL = and which may be proprietary to ECI Telecom. If you have received = this 
transmission in error, please inform us by e-mail, phone or = fax, and then delete the original 
and all = copies thereof.
_______________________________________________________________= ____________



_______________________________________________
Pals mailing list
Pals@ietf.org
https://www.ietf.org/mailman/listinfo/pals

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

= --Apple-Mail=_48882BA7-9DEB-4BBC-9CFC-E466CB29647B-- From nobody Wed Nov 15 20:08:13 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18DE71289B5; Wed, 15 Nov 2017 20:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cienacorp.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 qeC-6BirtRwd; Wed, 15 Nov 2017 20:08:08 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0050.outbound.protection.outlook.com [104.47.41.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4677A12025C; Wed, 15 Nov 2017 20:08:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cienacorp.onmicrosoft.com; s=selector1-ciena-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EebXQxWOinqIDToJjB1Z/k7VFt0zk9U4T8Fk9UbgyTI=; b=kezRje5FmRci9RImiVkU0qqk3uxhFYpJrmr5//Q/DCZq9XyoJQwcFFO35+TLORPxhHrIrXPWMHKp/pevnRqNLTf9kDJ7bKGxzaw58FNCXpRvX3Tc50esOfOCK23HGhTIXLB6TcCVw9//iJGH9J3WyB+WJdhDm5jSO5kvKsED87A= Received: from MWHPR0401MB3562.namprd04.prod.outlook.com (10.167.162.153) by MWHPR0401MB3564.namprd04.prod.outlook.com (10.167.162.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Thu, 16 Nov 2017 04:08:05 +0000 Received: from MWHPR0401MB3562.namprd04.prod.outlook.com ([fe80::905b:4368:8f0d:ccb0]) by MWHPR0401MB3562.namprd04.prod.outlook.com ([fe80::905b:4368:8f0d:ccb0%13]) with mapi id 15.20.0239.005; Thu, 16 Nov 2017 04:08:05 +0000 From: "Shah, Himanshu" To: Shahram Davari , Stewart Bryant CC: "mpls@ietf.org" , "pals@ietf.org" Thread-Topic: [Pals] [mpls] ELI/EL for the PW Thread-Index: AQHTXmSmmoghwyW+n0SqtY9RCT0ib6MW6lGA Date: Thu, 16 Nov 2017 04:08:05 +0000 Message-ID: <754FC568-CFA5-4DC0-8A5C-ED99563F2E4C@ciena.com> References: <741BDF3F-C90F-44FF-AD59-A29CF612FBBD@ciena.com> <683f4b93-a3ae-ada5-f716-be7c409188e2@gmail.com> <1A447EAF-9C33-4469-A86C-45C7456DB013@broadcom.com> In-Reply-To: <1A447EAF-9C33-4469-A86C-45C7456DB013@broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 authentication-results: spf=none (sender IP is ) smtp.mailfrom=hshah@ciena.com; x-originating-ip: [2001:67c:370:128:ccc6:a29:1c57:3f71] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR0401MB3564; 6:yn/O1oej/bSYPzeys+2ujp517nPXc9yKgDTd5BHqjx4whQvumYL5Yf1eD2J+PLu4s+JfPxB+ERpsIKlX3wrRZBiPteO7cq/+zYWSAWYhzSjFL+qxjX1zW2bBDac0gvcNp6Oi4QgT1KHRocc46wvYkxumoKCdnmifS58NN1WHNjRToMHAKX48S0OOW7fRe1qDzLq4OoZOZ6fZJ69Pm8uD5B/tMTJLcmdr3cr2gnGUq/n1CtESoahI3oTX5Jl6CjxIS0UDxROwHZyzPCPPrmqctRELuXodyP5FDr+BCaZROjUcR6TM9+ETVCOuEBCWxgZbHcpHiW2hb9zzhumBtbfXkKC6ZgJejLqRWMgEpgh8lTg=; 5:LK1Ge51+clET7y3MGLbUrNEdoyRa35b0fTr/IIJEdjmUxtz4bZ8ArGtmdDlLAOQigUDFxoE7xpxpvumNjJ3s3vzPhrWEE0V/OLB1/sn2hS5M4Sry8+e8YYUFhHBpb2P0nkvEARZ34PjrAFY33tp0wxKA6zT96Oo8m3/sAiMvXmM=; 24:q/9qh1xXwmHIHrLR7vHc8U6HGwZ/sGBwNZcdvrM74eF+HWCzS1Wt2eX1ERvjfP/AUw4hPT7mfyh7/G7iwBwad6ze2kTIn17nFwaEBMVFor4=; 7:rW5s7zxdn5VJ7elJ71EvaZGzI7T1WZtEAzFkbXkTFAscEc5OSi+acaE1DB1IQlnviUxE/3nPJqKj92Mekw6n6ipcDJYpdDf5gCCivgs98kHwNeDytqrELGAqwOUTGY4YS7pgQ9HDf334al7uzY9XD2DvXm9gE3GAABuOsFdCULomjAEE52mNGGwjjoEE72+aiu00cct1/aLrD5YKAas/GXWocdlqbiSw33GvaWWuteVTeCTY/NLDjNWNxQC72gjA x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: df4336c1-503e-416b-d9b2-08d52ca7a32d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:MWHPR0401MB3564; x-ms-traffictypediagnostic: MWHPR0401MB3564: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227612066756510)(21748063052155)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231022)(93006095)(93001095)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR0401MB3564; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR0401MB3564; x-forefront-prvs: 0493852DA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(189002)(24454002)(199003)(606006)(6436002)(189998001)(6486002)(5660300001)(229853002)(6506006)(4326008)(53936002)(54896002)(6512007)(6306002)(236005)(53546010)(83506002)(8936002)(93886005)(2950100002)(99286004)(106356001)(105586002)(54906003)(110136005)(83716003)(316002)(2900100001)(58126008)(14454004)(966005)(86362001)(36756003)(6246003)(82746002)(2906002)(3280700002)(68736007)(7736002)(39060400002)(3660700001)(25786009)(478600001)(5250100002)(81166006)(81156014)(53946003)(33656002)(8676002)(102836003)(6116002)(76176999)(97736004)(54356999)(50986999)(101416001); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR0401MB3564; H:MWHPR0401MB3562.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ciena.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_754FC568CFA54DC08A5CED99563F2E4Ccienacom_" MIME-Version: 1.0 X-OriginatorOrg: ciena.com X-MS-Exchange-CrossTenant-Network-Message-Id: df4336c1-503e-416b-d9b2-08d52ca7a32d X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 04:08:05.0551 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 457a2b01-0019-42ba-a449-45f99e96b60a X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR0401MB3564 Archived-At: Subject: Re: [Pals] [mpls] ELI/EL for the PW X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 04:08:12 -0000 --_000_754FC568CFA54DC08A5CED99563F2E4Ccienacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2hhaHJhbSDigJMNCg0KWW91IG1pc3NlZCBteSBwb2ludCBvbiDigJxsZXTigJlzIG1vdmUgb27i gJ0uDQooQlRXIOKAkyBqdXN0aWZpY2F0aW9uIHlvdSBwb2ludCBvdXQgYmVsb3cgZm9yIEVMSS9F TCBub3QgZXF1YWxseSBlbGlnaWJsZSB0byBpZGVudGlmeSBmbG93IGFzIEZBVCBsYWJlbCwgZm9y IFBXLA0KYmVjYXVzZSBvZiBULVBFLCBpcyBub3QgdmFsaWQg4oCTIHRoZXJlIGlzIG5vIFBIUCBv ZiBQVyBsYWJlbCkNCg0KQnV0IHJlYWxseSDigJMgbGV04oCZcyBtb3ZlIG9uLCBiZWNhdXNlIGl0 IGlzIGRpc3RyYWN0aW5nIGZyb20gZGlzY3Vzc2lvbnMgb24gdGhlIG90aGVyIHBvaW50IEkgYW0g bWFraW5nLg0KDQpUaGFua3MsDQpIaW1hbnNodQ0KDQpGcm9tOiBQYWxzIDxwYWxzLWJvdW5jZXNA aWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBTaGFocmFtIERhdmFyaSA8c2hhaHJhbS5kYXZhcmlAYnJv YWRjb20uY29tPg0KRGF0ZTogVGh1cnNkYXksIE5vdmVtYmVyIDE2LCAyMDE3IGF0IDY6NTQgQU0N ClRvOiBTdGV3YXJ0IEJyeWFudCA8c3Rld2FydC5icnlhbnRAZ21haWwuY29tPg0KQ2M6ICJtcGxz QGlldGYub3JnIiA8bXBsc0BpZXRmLm9yZz4sICJwYWxzQGlldGYub3JnIiA8cGFsc0BpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbUGFsc10gW21wbHNdIEVMSS9FTCBmb3IgdGhlIFBXDQoNCkhpbWFu c2h1DQoNCldlIGNhbuKAmXQgY29uc2lkZXIgdGhlIFBXIGxhYmVsIGFzIFBXLUxTUCwgZXZlbiB0 aG91Z2ggdGhlcmUgaXMgYSBQVyBsYWJlbCBzd2FwcGluZyBhdCBTLVBFLiAgQXQgbW9zdCB5b3Ug Y2FuIGNvbnNpZGVyIGl0DQphcyBQVy1MU1Agb25seSBhdCB0aGUgUy1QRSBidXQgbm90IGF0IHRo ZSBUZXJtaW5hdGluZyBQRS4NCg0KV2UgY2Fu4oCZdCBkbyBpdCBpcyBiZWNhdXNlIHdlIG5lZWQg dG8gZ2V0IHBhY2tldCBwcm9jZXNzaW5nIGNvbnRleHQgZnJvbSBQVyBsYWJlbCBzdWNoIGFzIHRo ZSBQYXlsb2FkIFR5cGUgKElQLCBFdGhlcm5ldCwgZXRjLiksIEV4aXN0ZW5jZSBvZiBDVywgYW5k IHdoZXRoZXIgd2UgYXJlIGRvaW5nIFBIUCBvciBub3QsIGV0Yy4gSWYgd2UgYXNzdW1lIFBXLUxT UCB0aGVuIHdlIGNhbuKAmXQgZ2V0IGFueSBvZiB0aGVzZSBpbmZvcm1hdGlvbiBmcm9tIFBXIGxh YmVsLg0KDQpTbyBJIHJlYWxseSBvYmplY3QgdG8gdXNpbmcgRUxJL0VMIGJlbG93IFBXIGxhYmVs LiAgRXhpc3RpbmcgSFcgdGhhdCBjb21wbGllcyB0byBSRkNzIGNhbuKAmXQgc3VwcG9ydCB0aGlz Lg0KDQpUaHgNClNoYWhyYW0NCg0KT24gTm92IDE1LCAyMDE3LCBhdCAxMjowNiBBTSwgU3Rld2Fy dCBCcnlhbnQgPHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbTxtYWlsdG86c3Rld2FydC5icnlhbnRA Z21haWwuY29tPj4gd3JvdGU6DQoNCkNvcHlpbmcgdGhlIHRocmVhZCB0byBNUExTIHRvIGluY2x1 ZGUgdGhlbSBpbiB0aGUgZGlzY3Vzc2lvbi4NClBsZWFzZSB3aWxsIGNvcHkgZnV0dXJlIGRpc2N1 c3Npb24gdG8gTVBMUyBvbiB0aGlzIHRvcGljLg0KVGhhbmtzDQpTdGV3YXJ0DQoNCk9uIDE1LzEx LzIwMTcgMDY6MTQsIFNoYWgsIEhpbWFuc2h1IHdyb3RlOg0KSGkgU2FzaGEg4oCTDQoNCkkgdW5k ZXJzdGFuZCB0aGF0IGFuZCBJIGRvIG5vdCB3YW50IHRvIGJlbGFib3IgbXkgcG9pbnQuDQpTbyBq dXN0IHRvIGNsYXJpZnkgbXkgcG9pbnQsIHlvdSBjYW4gdmlldyBNUy1QVyBhcyDigJxQVy1MU1Di gJ0NCndpdGggUy1QRSBhcyDigJxQVy1MU1LigJ0uIEluIHRoYXQgY29udGV4dCwgRUxJL0VMIGJl bG93IFBXIGxhYmVsLA0KbWFrZXMgc2Vuc2UuDQoNCkZBVCBQVyBSRkMgcHJlZGF0ZXMgdGhlIEVM SS9FTCwgYnV0IGlmIHRoYXQgd2FzIG5vdCB0aGUgY2FzZSwNCkVMSS9FTCBlYXNpbHkgd291bGQg aGF2ZSBiZWVuIHVzZWQgYXMgdGhlIHNvbHV0aW9uIHRoZSB3YXkgSSBkZXNjcmliZSBhYm92ZS4N Cg0KQnV0IHRoYXQgaXMgYWxsIHdhdGVyIHVuZGVyIHRoZSBicmlkZ2UuDQpTbywgbGV0IHVzIG1v dmUgb24uDQoNCk9uIHRoZSBmb2xsb3cgb24gdG9waWMgb24gdGhlIGd1aWRlbGluZSwNCldoZXJl IHdlIHNheSDigJx3aGVuIGJvdGggYXJlIHN1cHBvcnRlZCBPTkxZIE9ORSAoRUxJL0VMIG9yIEZB VCBsYWJlbCkgU0hPVUxEIGJlIHVzZWTigJ0uDQoNClNpbmNlIEZBVCBsYWJlbCBkb2VzIG5vdCBw cm90ZWN0IGZyb20gRUNNUCBiYXNlZCBvbiBEUEkgYmV5b25kIFBXIENXLCBCT1RIIHNjaGVtZXMg YXJlDQpyZXF1aXJlZCBzaW5jZSBGQVQgbGFiZWwgc3VmZmVycyBzYW1lIG1pcy1vcmRlcmluZyBj b25zZXF1ZW5jZXMuDQpJbiBhZGRpdGlvbiwgUy1QRSBNVVNUIHByZXNlcnZlIGFuZC9vciByZWdl bmVyYXRlIEVMSS9FTCBhYm92ZSBQVyBsYWJlbCwNCklmIFdHIGNob3NlIHRvIHByb3ZpZGUgZ3Vp ZGVsaW5lcyBvbiBob3cgdG8gYXZvaWQgbWktb3JkZXJpbmcgaW4gdGhlIHByZXNlbmNlIG9mIHN1 Y2ggc3dpdGNoZXMuDQoNClRoYW5rcywNCkhpbWFuc2h1DQoNCkZyb206ICJBbGV4YW5kZXIgY29t PiIgPEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPjxtYWlsdG86QWxleGFuZGVyLlZh aW5zaHRlaW5AZWNpdGVsZS5jb20+DQpEYXRlOiBXZWRuZXNkYXksIE5vdmVtYmVyIDE1LCAyMDE3 IGF0IDE6NDggUE0NClRvOiAicGFsc0BpZXRmLm9yZyI8bWFpbHRvOnBhbHNAaWV0Zi5vcmc+IDxw YWxzQGlldGYub3JnPjxtYWlsdG86cGFsc0BpZXRmLm9yZz4sICJTaGFoLCBIaW1hbnNodSIgPGhz aGFoQGNpZW5hLmNvbT48bWFpbHRvOmhzaGFoQGNpZW5hLmNvbT4NClN1YmplY3Q6IFJlOiBbUGFs c10gRUxJL0VMIGZvciB0aGUgUFcNCg0KSGltYW5zaHUsDQpPZiBjb3Vyc2UgRUwvRUxJIGNhbiBi ZSBwbGFjZWQgYW55d2hlcmUgaW4gdGhlIHN0YWNrLiBCdXQgaXQgY2FuIG9ubHkgYmUgaW5zZXJ0 ZWQgaWYgdGhlIEVncmVzcyBMU1IgZm9yIHRoZSB0dW5uZWwgc3VwcG9ydHMgaXQuIEFuZCBpbiBN Uy1QVyBlYWNoIFMtUEUgdGVybWluYXRlcyB0aGUgdHVubmVsIExTUC4NCkZyb20gbXkgUE9WIGZs b3cgbGFiZWxzIGFyZSB0aGUgT05MWSByaWdodCBtZWNoYW5pc20gZm9yIGFkZGluZyBlbnRyb3B5 IHRvIE1TLVBXcyBlbmQtdG8tZW5kLg0KVGh1bXAgdHlwZWQgYnkgU2FzaGEgVmFpbnNodGVpbg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogU2hhaCwgSGltYW5zaHUg PGhzaGFoQGNpZW5hLmNvbT48bWFpbHRvOmhzaGFoQGNpZW5hLmNvbT4NClNlbnQ6IFdlZG5lc2Rh eSwgTm92ZW1iZXIgMTUsIDIwMTcgMzoyNDo1NCBBTQ0KVG86IEFsZXhhbmRlciBWYWluc2h0ZWlu OyBwYWxzQGlldGYub3JnPG1haWx0bzpwYWxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtQYWxz XSBFTEkvRUwgZm9yIHRoZSBQVw0KDQpIaSBTaGFzaGEsDQoNCllvdSBhcmUgY29ycmVjdCBhYm91 dCBob3cgaXQgaXMgd3JpdHRlbiBpbiBSRkMgNjc5MC4NCg0KSSBkaWQgdGFsayB0byBLaXJlZXRp IGJyaWVmbHkgaW4gdGhlIGhhbGx3YXkgYWJvdXQgcGxhY2VtZW50IG9mIEVMSS9FTCBhbmQgTVMt UFcuDQpIZSBhbHNvIGRpZCBzYXkgdGhlIHNhbWUgYnV0IGhlIGFsc28gc2FpZCB0aGF0IGl0IGRv ZXMgbm90IG1hdHRlciB3aGVyZSB5b3UgcGxhY2UgaXQsDQphcyBmYXIgYXMgcHJvY2Vzc2luZyBv ZiB0aGUgRUxJL0VMLCB3b3VsZCB3b3JrIGlycmVzcGVjdGl2ZS4NCg0KTVMtUFcgdGVjaG5vbG9n eSB0aHJvd3MgdGhlIG1vbmtleSByYW5jaC4NCk9uZSBjb3VsZCBqdXN0IHN1cHBvcnQgNjc5MCBh bmQgbm90IDYzOTEgZm9yIFBXIGlmIEVMSS9FTCBwbGFjZWQgYmVsb3cgUFcgbGFiZWwuDQpJdCBz b2x2ZXMgcHJlc2VydmF0aW9uIG9mIGVudHJvcHkgYWNyb3NzIFMtUEUsIG5pY2VseS4NCg0KVGhh bmtzLA0KSGltYW5zaHUNCg0KRnJvbTogIkFsZXhhbmRlciBjb20+IiA8QWxleGFuZGVyLlZhaW5z aHRlaW5AZWNpdGVsZS5jb20+PG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNv bT4NCkRhdGU6IFR1ZXNkYXksIE5vdmVtYmVyIDE0LCAyMDE3IGF0IDg6MTQgUE0NClRvOiAicGFs c0BpZXRmLm9yZyI8bWFpbHRvOnBhbHNAaWV0Zi5vcmc+IDxwYWxzQGlldGYub3JnPjxtYWlsdG86 cGFsc0BpZXRmLm9yZz4sICJTaGFoLCBIaW1hbnNodSIgPGhzaGFoQGNpZW5hLmNvbT48bWFpbHRv OmhzaGFoQGNpZW5hLmNvbT4NClN1YmplY3Q6IFJlOiBbUGFsc10gRUxJL0VMIGZvciB0aGUgUFcN Cg0KSGltYW1zaHUgYW5kIGFsbCwNCkkgcmVzcGV0ZnVsbHkgZGlzYWdyZWUuDQpBcyBJIHNlZSBp dCwgUkZDIDY3OTAgaW4gU2VjdGlvbiA0LjIgSW5ncmVzcyBMU1IiIGluYW1iaWd1b3VzbHkgc3Rh dGVzIHRoYXQgRUwgYW5kIEVMSSwgaWYgdXNlZCwgYmV0d2VlbiB0aHIgVEwgYW5kICJhcHBsaWNh dGlvbiBsYWJlbCIgKGlmIHNwcGxpY2F0aW9uIGxzYmVsIGlzIHVzZWQpLiBJdCBhbHNvIHNwZWNp ZmllcywgdGhhdCBFTCBhbmQgRUxJIGFyZSBvbmx5IHB1c2hlZCBvbiBhbiBpbmNvbWluZyBwYWNr ZXQgaWYgdGhlIHR1bm5lbCBlZ3Jlc3MgTFNSIGhhcyBzaWduYWxlZCB0aGF0IGl0IGNhbiBoYW5k bGUgRUwgb24gdGhlIHNwZWNpZmljIHR1bm5lbCBMU1AgaXQgdGVybWluYXRlcy4NClRvIG1lIHRo aXMgbWVhbnMgdGhhdCBpbiB0aGUgY2FzZSBvZiBhIE1TLVBXLCBFTCBhbmQgRUxJIENBTk5PVCBw cmVzZXJ2ZWQgYnkgYW4gUy1QRS4gV2hldGhlciB0aGV5IGNhbiBiZSBnZW5lcmF0ZWQgYnkgYW4g U1BFIGlzIGFub3RoZXIgc3RvcnkuDQpGQVQgbGFiZWxzLCBvbiB0aGUgY29udHJhcnksIGFyZSBh bHdheXMgdGhlIEJvUyBsYWJlbHMgYW5kIHRocnJmb3JlIGFyZSBwcmVzZXJ2ZWQgYnkgU1BFcyBv ZiBhIE1TLVBXLg0KRGlkIEkgbWlzcyBzb21ldGhpbmcgc3Vic3RhbnRpYWw/DQpUaHVtcCB0eXBl ZCBieSBTYXNoYSBWYWluc2h0ZWluDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpGcm9tOiBQYWxzIDxwYWxzLWJvdW5jZXNAaWV0Zi5vcmc+PG1haWx0bzpwYWxzLWJvdW5jZXNA aWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBTaGFoLCBIaW1hbnNodSA8aHNoYWhAY2llbmEuY29tPjxt YWlsdG86aHNoYWhAY2llbmEuY29tPg0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTQsIDIwMTcg NTozMDoxMyBBTQ0KVG86IHBhbHNAaWV0Zi5vcmc8bWFpbHRvOnBhbHNAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBbUGFsc10gRUxJL0VMIGZvciB0aGUgUFcNCg0KVGhlIFBBTFMgV0cgZGlzY3Vzc2lvbnMg eWVzdGVyZGF5IGF0IHRoZSBJRVRGMTAwLCB3ZSBkaXNjdXNzZWQgdGhlIGNvbXBldGluZw0KRkFU IFBXIGFuZCBFTEkvRUwgZm9yIHRoZSBQVyBhbmQgaXRzIGZhdGUgYXQgUy1QRS4NCg0KSSBtZW50 aW9uZWQgdGhpcyBhdCBNaWtlIGJ1dCBnb3QgbG9zdCBpbiBzdWJzZXF1ZW50IGRpc2N1c3Npb25z Lg0KDQpGQVQgUFcgbGFiZWwgYXMgd2VsbCBhcyBFTEkvRUwgZm9yIFBXIChiYXNlZCBvbiBtaWNy b2Zsb3cgd2l0aGluIFBXKSByZXNpZGVzDQpiZWxvdyBQVyBsYWJlbC4gVGh1cywgQGluZ3Jlc3Mg UEUsIG9uY2UgbWljcm9mbG93IGlzIGlkZW50aWZpZWQsIGVpdGhlciBFTEkvRUwNCm9yIEZBVCBQ VyBsYWJlbCBpcyBwdXNoZWQuDQoNCkBTLVBFLCBQVyBsYWJlbCBzd2FwIGRvZXMgbm90IGhhdmUg dG8gcHJlc2VydmUgdGhlIEVMSS9FTCB3aGlsZSBkb2luZyBQVyBsYWJlbCBzd2FwcGluZywNCkJF Q0FVU0UgaXQgaXMgYWxyZWFkeSBiZWxvdyB0aGUgUFcgbGFiZWwsIGp1c3QgbGlrZSBob3cgRkFU IFBXIGxhYmVsIHdvdWxkIGJlLg0KDQpJIGNvbmZpcm1lZCB0aGlzIGZyb20gb3VyIGRhdGEgcGxh bmUgZW5naW5lZXIuDQood2UgY2FuIGNoZWNrIHdpdGggS2lyZWV0aSBhcyB3ZWxsKQ0KDQpJIHdv dWxkIGxpa2UgdG8ga25vdyBpZiBvdGhlciB2ZW5kb3JzIGFyZSBkb2luZyB0aGlzIGRpZmZlcmVu dGx5Pz8NCg0KR2l2ZW4gdGhpcyBpcyB0cnVlLCBmb3IgdGhlIHN3aXRjaGVzIHRoYXQgZG8gRFBJ IHBhc3QgUFcgY29udHJvbCB3b3JkIGZvciBFQ01QLA0KDQogICogICBGQVQgUFcgbGFiZWwgd291 bGQgc3VmZmVyIHRoZSBzYW1lIG1pc29yZGVyaW5nIGFzIG5vIEZBVCBQVyBsYWJlbA0KICAqICAg SG93ZXZlciwgRUxJL0VMIHdvdWxkIE5PVCDigJMgYmVjYXVzZSBvZiB0aGUgcHJlc2VuY2Ugb2Yg RUxJDQoNClRoYW5rcywNCkhpbWFuc2h1DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpUaGlzIGUt bWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRh aW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzDQpDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBw cm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcw0KdHJh bnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3Ig ZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsDQphbmQgYWxsIGNvcGllcyB0aGVyZW9m Lg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpUaGlzIGUtbWFp bCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5z IGluZm9ybWF0aW9uIHdoaWNoIGlzDQpDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBwcm9w cmlldGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcw0KdHJhbnNt aXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4 LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsDQphbmQgYWxsIGNvcGllcyB0aGVyZW9mLg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KDQpQYWxzIG1haWxpbmcgbGlzdA0KDQpQYWxzQGlldGYu b3JnPG1haWx0bzpQYWxzQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3BhbHMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg== --_000_754FC568CFA54DC08A5CED99563F2E4Ccienacom_ Content-Type: text/html; charset="utf-8" Content-ID: <5DB41F7B489C9143BB1D2C48F072E9EF@namprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPjxzdHls ZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hh cGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0 eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcgMyA5IDIgMiA1IDIgNCA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1 IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3Nl LTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJUcmVidWNoZXQgTVMiOw0KCXBhbm9zZS0xOjIgMTEgNiAzIDIgMiAyIDIgMiA0 O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNl DQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjAN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IlRyZWJ1Y2hl dCBNUyIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDQzMkZGOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsN Cglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l Ow0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6ODU1NzcyMDAzOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czo1OTc2MDQ3MDg7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0i d2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDQzMkZGIj5TaGFocmFtIOKAkzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPllvdSBtaXNzZWQgbXkgcG9pbnQgb24g4oCcbGV0 4oCZcyBtb3ZlIG9u4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1 Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPihCVFcg4oCTIGp1c3RpZmlj YXRpb24geW91IHBvaW50IG91dCBiZWxvdyBmb3IgRUxJL0VMIG5vdCBlcXVhbGx5IGVsaWdpYmxl IHRvIGlkZW50aWZ5IGZsb3cgYXMgRkFUIGxhYmVsLCBmb3IgUFcsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0 MzJGRiI+YmVjYXVzZSBvZiBULVBFLCBpcyBub3QgdmFsaWQg4oCTIHRoZXJlIGlzIG5vIFBIUCBv ZiBQVyBsYWJlbCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQg TVMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MDQzMkZGIj5CdXQgcmVhbGx5IOKAkyBsZXTigJlzIG1vdmUgb24sIGJlY2F1c2UgaXQgaXMgZGlz dHJhY3RpbmcgZnJvbSBkaXNjdXNzaW9ucyBvbiB0aGUgb3RoZXIgcG9pbnQgSSBhbSBtYWtpbmcu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb25zb2xhcyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPlRoYW5rcyw8bzpwPjwv bzpwPjwvc3Bhbj48L2k+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMDQzMkZGIj5IaW1hbnNodTwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzA0MzJGRiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1T JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlBhbHMgJmx0O3Bh bHMtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIFNoYWhyYW0gRGF2YXJpICZsdDtz aGFocmFtLmRhdmFyaUBicm9hZGNvbS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5 LCBOb3ZlbWJlciAxNiwgMjAxNyBhdCA2OjU0IEFNPGJyPg0KPGI+VG86IDwvYj5TdGV3YXJ0IEJy eWFudCAmbHQ7c3Rld2FydC5icnlhbnRAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1 b3Q7bXBsc0BpZXRmLm9yZyZxdW90OyAmbHQ7bXBsc0BpZXRmLm9yZyZndDssICZxdW90O3BhbHNA aWV0Zi5vcmcmcXVvdDsgJmx0O3BhbHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9i PlJlOiBbUGFsc10gW21wbHNdIEVMSS9FTCBmb3IgdGhlIFBXPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpbWFuc2h1IDxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgY2Fu4oCZdCBjb25zaWRlciB0aGUg UFcgbGFiZWwgYXMgUFctTFNQLCBldmVuIHRob3VnaCB0aGVyZSBpcyBhIFBXIGxhYmVsIHN3YXBw aW5nIGF0IFMtUEUuICZuYnNwO0F0IG1vc3QgeW91IGNhbiBjb25zaWRlciBpdDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YXMgUFctTFNQIG9ubHkg YXQgdGhlIFMtUEUgYnV0IG5vdCBhdCB0aGUgVGVybWluYXRpbmcgUEUuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGNhbuKAmXQgZG8gaXQg aXMgYmVjYXVzZSB3ZSBuZWVkIHRvIGdldCBwYWNrZXQgcHJvY2Vzc2luZyBjb250ZXh0IGZyb20g UFcgbGFiZWwgc3VjaCBhcyB0aGUgUGF5bG9hZCBUeXBlIChJUCwgRXRoZXJuZXQsIGV0Yy4pLCBF eGlzdGVuY2Ugb2YgQ1csIGFuZCB3aGV0aGVyIHdlIGFyZSBkb2luZyBQSFAgb3Igbm90LCBldGMu IElmIHdlIGFzc3VtZSBQVy1MU1AgdGhlbiB3ZSBjYW7igJl0IGdldCBhbnkgb2YgdGhlc2UNCiBp bmZvcm1hdGlvbiBmcm9tIFBXIGxhYmVsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBJIHJlYWxseSBvYmplY3QgdG8gdXNpbmcgRUxJL0VM IGJlbG93IFBXIGxhYmVsLiAmbmJzcDtFeGlzdGluZyBIVyB0aGF0IGNvbXBsaWVzIHRvIFJGQ3Mg Y2Fu4oCZdCBzdXBwb3J0IHRoaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoeDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+U2hhaHJhbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTm92IDE1LCAyMDE3LCBh dCAxMjowNiBBTSwgU3Rld2FydCBCcnlhbnQgJmx0OzxhIGhyZWY9Im1haWx0bzpzdGV3YXJ0LmJy eWFudEBnbWFpbC5jb20iPnN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZTtm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3 aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzow cHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Q29weWluZyB0aGUgdGhyZWFkIHRvIE1QTFMgdG8gaW5j bHVkZSB0aGVtIGluIHRoZSBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlO2ZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5QbGVhc2Ugd2lsbCBjb3B5IGZ1dHVyZSBkaXNjdXNzaW9uIHRvIE1QTFMgb24gdGhpcyB0b3Bp Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3Vu ZDp3aGl0ZTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGln bjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQt c3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGU7Zm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRv Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPlN0ZXdhcnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gMTUvMTEvMjAx NyAwNjoxNCwgU2hhaCwgSGltYW5zaHUgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0O2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0 YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFj aW5nOjBweCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5IaSBTYXNoYSDigJM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+SSB1bmRlcnN0YW5kIHRoYXQgYW5kIEkgZG8gbm90IHdhbnQgdG8gYmVsYWJvciBteSBwb2lu dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPlNvIGp1c3QgdG8gY2xhcmlmeSBteSBwb2ludCwgeW91IGNhbiB2aWV3IE1TLVBXIGFzIOKA nFBXLUxTUOKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+d2l0aCBTLVBFIGFzIOKAnFBXLUxTUuKAnS4gSW4gdGhhdCBjb250ZXh0LCBF TEkvRUwgYmVsb3cgUFcgbGFiZWwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij5tYWtlcyBzZW5zZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+RkFUIFBXIFJGQyBw cmVkYXRlcyB0aGUgRUxJL0VMLCBidXQgaWYgdGhhdCB3YXMgbm90IHRoZSBjYXNlLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+RUxJL0VM IGVhc2lseSB3b3VsZCBoYXZlIGJlZW4gdXNlZCBhcyB0aGUgc29sdXRpb24gdGhlIHdheSBJIGRl c2NyaWJlIGFib3ZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij5CdXQgdGhhdCBpcyBhbGwgd2F0ZXIgdW5kZXIgdGhlIGJy aWRnZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPlNvLCBsZXQgdXMgbW92ZSBvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+T24gdGhlIGZvbGxvdyBvbiB0b3Bp YyBvbiB0aGUgZ3VpZGVsaW5lLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+V2hlcmUgd2Ugc2F5IOKAnHdoZW4gYm90aCBhcmUgc3VwcG9y dGVkIE9OTFkgT05FIChFTEkvRUwgb3IgRkFUIGxhYmVsKSBTSE9VTEQgYmUgdXNlZOKAnS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+U2luY2UgRkFUIGxhYmVsIGRvZXMgbm90IHByb3RlY3QgZnJvbSBFQ01QIGJhc2VkIG9u IERQSSBiZXlvbmQgUFcgQ1csIEJPVEggc2NoZW1lcyBhcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPnJlcXVpcmVkIHNpbmNlIEZBVCBs YWJlbCBzdWZmZXJzIHNhbWUgbWlzLW9yZGVyaW5nIGNvbnNlcXVlbmNlcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkluIGFkZGl0aW9u LCBTLVBFIE1VU1QgcHJlc2VydmUgYW5kL29yIHJlZ2VuZXJhdGUgRUxJL0VMIGFib3ZlIFBXIGxh YmVsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+SWYgV0cgY2hvc2UgdG8gcHJvdmlkZSBndWlkZWxpbmVzIG9uIGhvdyB0byBhdm9pZCBt aS1vcmRlcmluZyBpbiB0aGUgcHJlc2VuY2Ugb2Ygc3VjaCBzd2l0Y2hlcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvbnNvbGFzJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+VGhhbmtzLDwv c3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxpPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb25z b2xhcyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPkhpbWFuc2h1PC9zcGFuPjwvaT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPkZyb206PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZxdW90 O0FsZXhhbmRlciBjb20mZ3Q7JnF1b3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0 ZWxlLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPiZsdDtBbGV4YW5kZXIuVmFpbnNo dGVpbkBlY2l0ZWxlLmNvbSZndDs8L3NwYW4+PC9hPjxicj4NCjxiPkRhdGU6PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5XZWRuZXNkYXksIE5vdmVt YmVyIDE1LCAyMDE3IGF0IDE6NDggUE08YnI+DQo8Yj5Ubzo8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPjxhIGhyZWY9Im1haWx0bzpwYWxzQGlldGYu b3JnIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+JnF1b3Q7cGFsc0BpZXRmLm9yZyZxdW90 Ozwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxhIGhyZWY9Im1haWx0bzpwYWxzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1 NEY3MiI+Jmx0O3BhbHNAaWV0Zi5vcmcmZ3Q7PC9zcGFuPjwvYT4sDQogJnF1b3Q7U2hhaCwgSGlt YW5zaHUmcXVvdDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOmhzaGFoQGNpZW5hLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5 NTRGNzIiPiZsdDtoc2hhaEBjaWVuYS5jb20mZ3Q7PC9zcGFuPjwvYT48YnI+DQo8Yj5TdWJqZWN0 OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+UmU6 IFtQYWxzXSBFTEkvRUwgZm9yIHRoZSBQVzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SGltYW5zaHUsPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9mIGNvdXJzZSBFTC9FTEkgY2FuIGJlIHBsYWNl ZCBhbnl3aGVyZSBpbiB0aGUgc3RhY2suIEJ1dCBpdCBjYW4gb25seSBiZSBpbnNlcnRlZCBpZiB0 aGUgRWdyZXNzIExTUiBmb3IgdGhlIHR1bm5lbCBzdXBwb3J0cyBpdC4gQW5kIGluIE1TLVBXDQog ZWFjaCBTLVBFIHRlcm1pbmF0ZXMgdGhlIHR1bm5lbCBMU1AuPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tIG15IFBPViBmbG93IGxhYmVscyBhcmUgdGhlIE9OTFkgcmlnaHQgbWVj aGFuaXNtIGZvciBhZGRpbmcgZW50cm9weSB0byBNUy1QV3MgZW5kLXRvLWVuZC48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+VGh1bXAgdHlwZWQgYnkgU2FzaGEgVmFpbnNodGVpbjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRl Ij4NCjxociBzaXplPSIyIiB3aWR0aD0iOTglIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPGRp diBpZD0iZGl2UnBseUZ3ZE1zZyI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxiPkZyb206PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5TaGFoLCBIaW1hbnNodTxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86aHNoYWhAY2llbmEu Y29tIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+Jmx0O2hzaGFoQGNpZW5hLmNvbSZndDs8 L3NwYW4+PC9hPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5XZWRuZXNkYXksIE5vdmVtYmVyIDE1LCAyMDE3IDM6MjQ6NTQg QU08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPkFsZXhhbmRlciBWYWluc2h0ZWluOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86cGFsc0BpZXRmLm9yZyI+PHNw YW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPnBhbHNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxi PlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5SZTogW1BhbHNdIEVMSS9FTCBmb3IgdGhlIFBXPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SGkg U2hhc2hhLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij5Zb3UgYXJlIGNvcnJlY3QgYWJvdXQgaG93IGl0IGlzIHdyaXR0ZW4g aW4gUkZDIDY3OTAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkkgZGlkIHRhbGsgdG8gS2lyZWV0aSBicmllZmx5IGluIHRo ZSBoYWxsd2F5IGFib3V0IHBsYWNlbWVudCBvZiBFTEkvRUwgYW5kIE1TLVBXLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SGUgYWxzbyBk aWQgc2F5IHRoZSBzYW1lIGJ1dCBoZSBhbHNvIHNhaWQgdGhhdCBpdCBkb2VzIG5vdCBtYXR0ZXIg d2hlcmUgeW91IHBsYWNlIGl0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+YXMgZmFyIGFzIHByb2Nlc3Npbmcgb2YgdGhlIEVMSS9FTCwg d291bGQgd29yayBpcnJlc3BlY3RpdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPk1TLVBXIHRlY2hub2xvZ3kgdGhyb3dz IHRoZSBtb25rZXkgcmFuY2guPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij5PbmUgY291bGQganVzdCBzdXBwb3J0IDY3OTAgYW5kIG5vdCA2 MzkxIGZvciBQVyBpZiBFTEkvRUwgcGxhY2VkIGJlbG93IFBXIGxhYmVsLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SXQgc29sdmVzIHBy ZXNlcnZhdGlvbiBvZiBlbnRyb3B5IGFjcm9zcyBTLVBFLCBuaWNlbHkuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxpPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb25zb2xhcyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPlRoYW5rcyw8L3Nw YW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q29uc29s YXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGIj5IaW1hbnNodTwvc3Bhbj48L2k+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij5Gcm9tOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mcXVvdDtB bGV4YW5kZXIgY29tJmd0OyZxdW90OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVs ZS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj4mbHQ7QWxleGFuZGVyLlZhaW5zaHRl aW5AZWNpdGVsZS5jb20mZ3Q7PC9zcGFuPjwvYT48YnI+DQo8Yj5EYXRlOjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+VHVlc2RheSwgTm92ZW1iZXIg MTQsIDIwMTcgYXQgODoxNCBQTTxicj4NCjxiPlRvOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+PGEgaHJlZj0ibWFpbHRvOnBhbHNAaWV0Zi5vcmci PjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj4mcXVvdDtwYWxzQGlldGYub3JnJnF1b3Q7PC9z cGFuPjwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOnBhbHNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0Rjcy Ij4mbHQ7cGFsc0BpZXRmLm9yZyZndDs8L3NwYW4+PC9hPiwNCiAmcXVvdDtTaGFoLCBIaW1hbnNo dSZxdW90OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YSBocmVmPSJtYWlsdG86aHNoYWhAY2llbmEuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3 MiI+Jmx0O2hzaGFoQGNpZW5hLmNvbSZndDs8L3NwYW4+PC9hPjxicj4NCjxiPlN1YmplY3Q6PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5SZTogW1Bh bHNdIEVMSS9FTCBmb3IgdGhlIFBXPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5IaW1hbXNodSBhbmQgYWxsLDwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIHJlc3BldGZ1bGx5IGRpc2FncmVlLjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QXMgSSBzZWUgaXQsIFJGQyA2NzkwIGluIFNl Y3Rpb24gNC4yIEluZ3Jlc3MgTFNSJnF1b3Q7IGluYW1iaWd1b3VzbHkgc3RhdGVzIHRoYXQgRUwg YW5kIEVMSSwgaWYgdXNlZCwgYmV0d2VlbiB0aHIgVEwgYW5kICZxdW90O2FwcGxpY2F0aW9uIGxh YmVsJnF1b3Q7IChpZiBzcHBsaWNhdGlvbg0KIGxzYmVsIGlzIHVzZWQpLiBJdCBhbHNvIHNwZWNp ZmllcywgdGhhdCBFTCBhbmQgRUxJIGFyZSBvbmx5IHB1c2hlZCBvbiBhbiBpbmNvbWluZyBwYWNr ZXQgaWYgdGhlIHR1bm5lbCBlZ3Jlc3MgTFNSIGhhcyBzaWduYWxlZCB0aGF0IGl0IGNhbiBoYW5k bGUgRUwgb24gdGhlIHNwZWNpZmljIHR1bm5lbCBMU1AgaXQgdGVybWluYXRlcy48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRvIG1lIHRoaXMgbWVhbnMgdGhhdCBpbiB0aGUgY2FzZSBv ZiBhIE1TLVBXLCBFTCBhbmQgRUxJIENBTk5PVCBwcmVzZXJ2ZWQgYnkgYW4gUy1QRS4gV2hldGhl ciB0aGV5IGNhbiBiZSBnZW5lcmF0ZWQgYnkgYW4gU1BFIGlzIGFub3RoZXIgc3RvcnkuPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5GQVQgbGFiZWxzLCBvbiB0aGUgY29udHJhcnksIGFy ZSBhbHdheXMgdGhlIEJvUyBsYWJlbHMgYW5kIHRocnJmb3JlIGFyZSBwcmVzZXJ2ZWQgYnkgU1BF cyBvZiBhIE1TLVBXLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RGlkIEkgbWlzcyBz b21ldGhpbmcgc3Vic3RhbnRpYWw/PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRodW1wIHR5cGVk IGJ5IFNhc2hhIFZhaW5zaHRlaW48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4 dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9Ijk4 JSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxkaXYgaWQ9ImRpdlJwbHlGd2RNc2ciPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj5Gcm9t OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UGFs czxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVm PSJtYWlsdG86cGFscy1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3 MiI+Jmx0O3BhbHMtYm91bmNlc0BpZXRmLm9yZyZndDs8L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5vbg0KIGJlaGFsZiBvZiBTaGFoLCBI aW1hbnNodTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YSBocmVmPSJtYWlsdG86aHNoYWhAY2llbmEuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3 MiI+Jmx0O2hzaGFoQGNpZW5hLmNvbSZndDs8L3NwYW4+PC9hPjxicj4NCjxiPlNlbnQ6PC9iPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UdWVzZGF5LCBO b3ZlbWJlciAxNCwgMjAxNyA1OjMwOjEzIEFNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86cGFsc0Bp ZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPnBhbHNAaWV0Zi5vcmc8L3NwYW4+ PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5bUGFsc10gRUxJL0VMIGZvciB0aGUgUFc8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvbnNvbGFzJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzA0MzJGRiI+VGhlIFBBTFMgV0cgZGlzY3Vzc2lvbnMgeWVzdGVyZGF5IGF0IHRoZSBJRVRGMTAw LCB3ZSBkaXNjdXNzZWQgdGhlIGNvbXBldGluZzwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48aT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDb25zb2xhcyZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwNDMyRkYiPkZBVCBQVyBhbmQgRUxJL0VMIGZvciB0aGUgUFcgYW5kIGl0cyBm YXRlIGF0IFMtUEUuPC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvbnNvbGFzJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJG RiI+Jm5ic3A7PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvbnNvbGFzJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+ SSBtZW50aW9uZWQgdGhpcyBhdCBNaWtlIGJ1dCBnb3QgbG9zdCBpbiBzdWJzZXF1ZW50IGRpc2N1 c3Npb25zLjwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb25zb2xhcyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPiZu YnNwOzwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtDb25zb2xhcyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPkZBVCBQ VyBsYWJlbCBhcyB3ZWxsIGFzIEVMSS9FTCBmb3IgUFcgKGJhc2VkIG9uIG1pY3JvZmxvdyB3aXRo aW4gUFcpIHJlc2lkZXM8L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQz MkZGIj5iZWxvdyBQVyBsYWJlbC4gVGh1cywgQGluZ3Jlc3MgUEUsIG9uY2UgbWljcm9mbG93IGlz IGlkZW50aWZpZWQsIGVpdGhlciBFTEkvRUw8L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMDQzMkZGIj5vciBGQVQgUFcgbGFiZWwgaXMgcHVzaGVkLjwvc3Bhbj48L2k+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDb25zb2xh cyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPiZuYnNwOzwvc3Bhbj48L2k+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDb25zb2xhcyZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwNDMyRkYiPkBTLVBFLCBQVyBsYWJlbCBzd2FwIGRvZXMg bm90IGhhdmUgdG8gcHJlc2VydmUgdGhlIEVMSS9FTCB3aGlsZSBkb2luZyBQVyBsYWJlbCBzd2Fw cGluZyw8L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGIj5CRUNB VVNFIGl0IGlzIGFscmVhZHkgYmVsb3cgdGhlIFBXIGxhYmVsLCBqdXN0IGxpa2UgaG93IEZBVCBQ VyBsYWJlbCB3b3VsZCBiZS48L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MDQzMkZGIj4mbmJzcDs8L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQz MkZGIj5JIGNvbmZpcm1lZCB0aGlzIGZyb20gb3VyIGRhdGEgcGxhbmUgZW5naW5lZXIuPC9zcGFu PjwvaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvbnNvbGFzJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+KHdlIGNhbiBjaGVjayB3 aXRoIEtpcmVldGkgYXMgd2VsbCk8L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMDQzMkZGIj4mbmJzcDs8L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MDQzMkZGIj5JIHdvdWxkIGxpa2UgdG8ga25vdyBpZiBvdGhlciB2ZW5kb3JzIGFyZSBkb2luZyB0 aGlzIGRpZmZlcmVudGx5Pz88L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MDQzMkZGIj4mbmJzcDs8L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQz MkZGIj5HaXZlbiB0aGlzIGlzIHRydWUsIGZvciB0aGUgc3dpdGNoZXMgdGhhdCBkbyBEUEkgcGFz dCBQVyBjb250cm9sIHdvcmQgZm9yIEVDTVAsPC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8dWwgc3R5bGU9Im1h cmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i Y29sb3I6IzA0MzJGRjttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzE7YmFj a2dyb3VuZDp3aGl0ZSI+DQo8aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtDb25zb2xhcyZxdW90OyxzYW5zLXNlcmlmIj5GQVQgUFcgbGFiZWwgd291bGQg c3VmZmVyIHRoZSBzYW1lIG1pc29yZGVyaW5nIGFzIG5vIEZBVCBQVyBsYWJlbDwvc3Bhbj48L2k+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMDQzMkZGO21hcmdpbi1sZWZ0OjBpbjtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMTtiYWNrZ3JvdW5kOndoaXRlIj4NCjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvbnNvbGFzJnF1b3Q7LHNhbnMt c2VyaWYiPkhvd2V2ZXIsIEVMSS9FTCB3b3VsZCBOT1Qg4oCTIGJlY2F1c2Ugb2YgdGhlIHByZXNl bmNlIG9mIEVMSTwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDQzMkZGIj4m bmJzcDs8L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvbnNv bGFzJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA0MzJGRiI+VGhhbmtzLDwvc3Bhbj48L2k+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q29uc29sYXMmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMDQzMkZGIj5IaW1hbnNodTwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3Jv dW5kOndoaXRlIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8YnI+DQpUaGlzIGUtbWFp bCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5z IGluZm9ybWF0aW9uIHdoaWNoIGlzPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxicj4NCkNPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0 YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzPHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCnRyYW5zbWlzc2lvbiBp biBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRo ZW4gZGVsZXRlIHRoZSBvcmlnaW5hbDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48YnI+DQphbmQgYWxsIGNvcGllcyB0aGVyZW9mLjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8YnI+DQpU aGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5k IGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCkNPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJl IHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzPHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCnRyYW5z bWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZh eCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQphbmQgYWxsIGNvcGllcyB0aGVyZW9mLjxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5QYWxzIG1haWxp bmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 YSBocmVmPSJtYWlsdG86UGFsc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIi PlBhbHNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3BhbHMiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BhbHM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+ DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPm1wbHMgbWFpbGluZyBsaXN0PC9zcGFuPjxicj4NCjwvc3Bhbj48YSBocmVmPSJt YWlsdG86bXBsc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTU0RjcyO2JhY2tn cm91bmQ6d2hpdGUiPm1wbHNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxi cj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21wbHMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk1NEY3MjtiYWNrZ3JvdW5kOndoaXRlIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_754FC568CFA54DC08A5CED99563F2E4Ccienacom_-- From nobody Mon Nov 20 04:10:03 2017 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7598412954C for ; Mon, 20 Nov 2017 04:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 rvV6inCVXxsR for ; Mon, 20 Nov 2017 04:09:58 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8454512954D for ; Mon, 20 Nov 2017 04:09:58 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id vAKC9siZ018079 for ; Mon, 20 Nov 2017 12:09:54 GMT Received: from 950129200 (116.133.112.87.dyn.plus.net [87.112.133.116]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id vAKC9qAc018048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Nov 2017 12:09:54 GMT Reply-To: From: "Adrian Farrel" To: Date: Mon, 20 Nov 2017 12:09:51 -0000 Message-ID: <1a1301d361f8$790041c0$6b00c540$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdNh+HadYlGMpniJTkSdxE7WQICUqw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23476.006 X-TM-AS-Result: No--9.334-10.0-31-10 X-imss-scan-details: No--9.334-10.0-31-10 X-TMASE-MatchedRID: oK2/Kf95y+Jx9EmrVy1N/FVeGWZmxN2MQPCWRE0Lo8LqLnOUXH9QdCh1 yrAzXZsp6wGF3sOydQ7Qj4VaaZCFx7Q9EkyAW8JWxZQoGMRGhhPEGBoHKd3a+RpCHAdmKeAM7Xw YH5RAPXlJMt/mA5553BHs7jeubfJaiwjsyrTVNP7nx2TmxvCbKNSqEluSYtV7SSUXkvSVAdyBuL DzzkmS17ceKqaclAxKgnSYGvpeKgNkXrKx0WO3Sp4CIKY/Hg3AtOt1ofVlaoIc4jS1nsD4HfoLR 4+zsDTtqFhHt/jREamC0x8eHPNPY62rfn+cymRXIPHU6NKnvCPDrzd7w7xmjFZca9RSYo/b Archived-At: Subject: [Pals] Request for review : L2VPN service model X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 12:10:01 -0000 Hi, Just a heads up that the L2VPN service model (https://datatracker.ietf.org/doc/draft-ietf-l2sm-l2vpn-service-model/) is getting close to WG last call (probably just one revision and a YANG review first) and would really benefit from review. Recall that this model is not a device model and is not about how a VPN is implemented or realized in a network, but is about how the VPN service is discussed between a service provider and their customer. In view of this, review from three perspectives would be particularly useful: - customers (e.g., enterprises) to let us know that the description of the service is how you would request a service - service providers to let us know if the model fits with how you describe the services you sell - implementers of management systems to understand that whether they could map from the service description to the network configuration that is needed to operate the VPN. Of course, all other reviews are also welcome. Please send comments to the L2SM list (not this list!). Thanks, Adrian (L2SM co-chair)