From nobody Mon Oct 1 12:47:02 2018 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3901252B7; Mon, 1 Oct 2018 12:46:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: lflynn@amsl.com, tcpm@ietf.org, ietf@kuehlewind.net, tcpm-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.85.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153842321983.22242.12476094106942651102.idtracker@ietfa.amsl.com> Date: Mon, 01 Oct 2018 12:46:59 -0700 Archived-At: Subject: [tcpm] tcpm - Update to a Meeting Session Request for IETF 103 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 19:47:00 -0000 An update to a meeting session request has just been submitted by Liz Flynn, on behalf of the tcpm working group. --------------------------------------------------------- Working Group Name: TCP Maintenance and Minor Extensions Area Name: Transport Area Session Requester: Liz Flynn Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 80 Conflicts to Avoid: First Priority: iccrg tcpinc mptcp taps tsvarea tsvwg quic Second Priority: httpbis lwig rmcat teas Third Priority: rtcweb maprg panrg People who must be present: Yoshifumi Nishida Michael Tuexen Michael Scharf Mirja Kuehlewind Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Oct 2 03:23:07 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5DDF130DD6 for ; Tue, 2 Oct 2018 03:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] 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 8pwotz1mrPau for ; Tue, 2 Oct 2018 03:23:04 -0700 (PDT) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 09D201277C8 for ; Tue, 2 Oct 2018 03:23:04 -0700 (PDT) Received: by mail-it1-x12e.google.com with SMTP id q70-v6so2697970itb.3 for ; Tue, 02 Oct 2018 03:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dZPIFFeBxJr+FBNImcq4sgSAftG5AcLcVg/UNjOLVC8=; b=Zw5pLQ93B8JxfpudWpAOvEE+u8nYGVy17HZ42WNmcXWD4fs6mD8iqoehd9EqCK+hSN q++pdtzWnSqSrWOdXx9/cnYdxVCxsX+/J9+KpqxaOUOu+d26qKe7DOrgeJ3ReZZkTDQ8 6BApeeh4qP0FFi95G/hy80/1ucJJqF7ZNrPSlK7fZuC17CR5VZtRpu+wzBvMP7VlM+R6 YbPiYxfEb/ElJ8p7PfYyDftkES2s5bdVPhlf395qXxUf2NZwLS2LfEKZsurj89/Pj2vp UFQwoWkYk+l/mR41flWLxFgTdQYxJxDUogIdW9TNq1LyA+uDM3y2d3Q6oV4MydGicM37 HDlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dZPIFFeBxJr+FBNImcq4sgSAftG5AcLcVg/UNjOLVC8=; b=dBvfOddqy/PW29c1AWfD1ppEDL9NqsVioowlHy2vkvWbOjmTSrP5jckFmDR6oPqs1s 1Q7H/KIcgMQDmielBvZ9pZ+jfCuw0pDkt7oXLzltQ7MsiD3CKOSIccgziRh2c589XzrG /DsPdNKm+szEXywF5HU40fon3FN9qeooexP2ud2zVXwA2HTpiMcVcV4cGvhvgK5wZJYT vImvYvmfizdenWkRMIX4TxkjnqUaIerZGIGDGto7L0+hk+sNUbvPbtBnCdxZLwdmnb7+ seyQuwEtBHmFY6wLZpQes8WXy0cFDDrTDJcW8kWcPVhq+cFNhjLD93sKip6785BZyMYk LdAA== X-Gm-Message-State: ABuFfoh16dDBm8Yw1lnEDmEcpNOJtEfaDsrH7f03+DvlnWwonCiBaTe1 p0c9sogWJzwbVJC2PSuyIPs+JOijqSwpKYqauSQ= X-Google-Smtp-Source: ACcGV6392whC6/HxZ7RSeJ8nwBoOgL2QTKTwnFQYzAzWxc1JaDvuhCAnuF1xH5rpSMYaf54EiAGIebCUNwGXr8HA2CE= X-Received: by 2002:a02:b60d:: with SMTP id h13-v6mr11818864jam.45.1538475783338; Tue, 02 Oct 2018 03:23:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Loganaden Velvindron Date: Tue, 2 Oct 2018 14:22:52 +0400 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] rfc5961 and suggested updates. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 10:23:06 -0000 On Fri, Aug 24, 2018 at 6:07 PM Mirja K=C3=BChlewind wrote: > > Hi, > > my personal opinion: > > I agree that documenting the problem and recommending the implementation = of per-socket limits would be a useful thing to do. > > I don=E2=80=99t think it is appropriated or needed to update or even depr= ecate RFC5961, therefore I would strongly support the changes to this draft= as you described below. > > Mirja > Gentle reminder. From nobody Wed Oct 3 23:11:21 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC500130DE6 for ; Wed, 3 Oct 2018 23:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] 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 KmYiNZfeNEHj for ; Wed, 3 Oct 2018 23:11:17 -0700 (PDT) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 210A9130DDF for ; Wed, 3 Oct 2018 23:11:17 -0700 (PDT) Received: by mail-it1-x134.google.com with SMTP id 134-v6so11624059itz.2 for ; Wed, 03 Oct 2018 23:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3m8UbRYVfVajrJIfxXmqJnuKQVql8ytCNmG01t0pdZc=; b=l7yvxjelkGGvg4c02Lrru9ljsvd137ZsIboHlUUVMy9kTs+vwxgy9/EdaVHppx6GBm RTNuMDIPG1HraPtfCwnLPhrRNcxYLR+zmK05dadYgbuCtfLt5wvwNWXFdI3HE1RtF7xf HvSbcmTcbmoU9puLR8fkLSR7hEAos87Ohpc6YEdkvsJor4TEAmyVU9cBAPW9TnUxn/3P 5C2oUdNcVDkwRR7vXax3KNxE85ZuGYZnKORWlfOCLWoB+0zaf8j7roRdguw9ivswS3ig bon/xNTweTcnTFJAmha4q9PTCwukS4pIwSZMDEWBUlEScxkSkmFc+KFE82AHctyCrdA4 cJRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3m8UbRYVfVajrJIfxXmqJnuKQVql8ytCNmG01t0pdZc=; b=spqc03W2tAKoVBrBWQitSp5Q7cWSKkuzm+NL1lKSumi7kCNDLKVSQabFvNs0GlVnAD ETPlC8kAcLGBoofAo3keafWFdmtwjXa07uea3qnxDAoBl61saHjYe49xaRViOnsanAMc eEbS79bJy8CjCCTfJSfDKmMUytJC9YiVHj2z0q01BgvtrbRFMn5UteQPn8IDbPJVLopG D/dHjbWuYF5lvxQRwX+guNqXWjPr7ip1geMhR10P2o0i9+PY/DUTYAKse/iGqYNkkJv5 BhiZn/QkiwivZLrXIN8bvDSYTVIWSPT/+853hAcshx068HYvOW48Xe26yJiRTgT7fxJ3 umiw== X-Gm-Message-State: ABuFfoiu2WKbA/1lMRHI3qmhZIvaO95oXyDGaAsid5MOcr8pdtayXEN2 NuDYKIJhGuL7h6TMyXJCJuO99Gl6e6QP3iCu6AQ= X-Google-Smtp-Source: ACcGV63lLlY6l019/KZEOwB0tlzERE5YKtbACAY/i+C8q5R45de3yOawSG+AnF2QT7rlWcDZCo9/5tbmFceqkb7ofeU= X-Received: by 2002:a02:940a:: with SMTP id a10-v6mr3743169jai.94.1538633476375; Wed, 03 Oct 2018 23:11:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Loganaden Velvindron Date: Thu, 4 Oct 2018 10:10:49 +0400 Message-ID: To: zhiyunq@cs.ucr.edu Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , "tcpm@ietf.org Extensions" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] rfc5961 and suggested updates. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 06:11:20 -0000 On Tue, Oct 2, 2018 at 7:38 PM Zhiyun Qian wrote: > > Loganaden and Mirja, > > Not sure if my previous email went through. I'm copying it here: > > Chiming in here. My name is Zhiyun Qian. We are the group of researchers = from UC Riverside who invented the original side channel attack in 2016. Th= anks Loganaden for initiating the changes to the specification and thanks M= irja for putting me in the loop. I've done much research in TCP security th= at I felt like this is home :) > > My 2 cents: > > - I fully support we make it explicit that per-socket rate limit (instead= of global limit) should be implemented either in a separate draft or maybe= RFC5961itself. I am not sure how people will come across a separate draft = like this. Will there be a link from RFC5961? > That's a possibility if there is enough interest. Right now, I've received feedback only from you and Mirja. I was hoping to get feedback from more people. The draft is pretty small, and I've removed the "controversial" parts that some people disagreed with. > - BTW, to this day, Linux still has the global rate limit together with t= he per-socket limit (the latter will apply first), which still leaves some = possibility for attacks (although very slim). I understand the global rate = limit is to prevent the whole system from sending too many challenge ACKs. = However, to be honest, I am not sure why this is considered harmful. Why do= n't we do something simple instead such as no limit at all or apply only th= e per-socket limit? I infer two reasons (1) reflection attacks --- but the= amplification ratio is only 1:1. (2) ACK loops --- but this can be mitigat= ed by the per-socket limit already. Why do we need a global rate limit? The= benefit seems very incremental to me. The only benefit is that when thousa= nds of connections (perhaps on a server) all enter the "ACK loop state" and= started flooding the network but this seems extremely unlikely? > Understood. > Best, > -Zhiyun > > > On Tue, Oct 2, 2018 at 3:23 AM Loganaden Velvindron = wrote: >> >> On Fri, Aug 24, 2018 at 6:07 PM Mirja K=C3=BChlewind >> wrote: >> > >> > Hi, >> > >> > my personal opinion: >> > >> > I agree that documenting the problem and recommending the implementati= on of per-socket limits would be a useful thing to do. >> > >> > I don=E2=80=99t think it is appropriated or needed to update or even d= eprecate RFC5961, therefore I would strongly support the changes to this dr= aft as you described below. >> > >> > Mirja >> > >> >> Gentle reminder. >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Oct 4 08:04:25 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1320612958B for ; Thu, 4 Oct 2018 08:04:23 -0700 (PDT) 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 jShW7khz2pWB for ; Thu, 4 Oct 2018 08:04:20 -0700 (PDT) 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 65644130E3C for ; Thu, 4 Oct 2018 08:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type: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=ah0+cvbNZuJ+zeOvK8/UNmhqmlMcgjZiy2H9YRqtiNg=; b=yEbwJANQgG2sPeJzTh5+HF2wK vNgzNk/mAUJ2bERKbr03va5P4bhfWrFPWrQr61i0E4J2IHKsIGAf4VWJ9SJEMLuVONiz6x6GFBLJI irRhQ/R/l8OhJct5i/y3s8fZygVIyIrivknLDIb1nhLjNd1aVzshyo4y/TvJIDqqdlpdQFZIYKSF0 kNqPfYEsaFSgCqjqWc0uNkRvdPRAyIG6+i0Mfn3N9zdUAjqkt21K0iQBotOPVyGAEZErfmmr86W+9 UAuOm2FWapsfcos332SVHqJ+2B+eLEA5eLMs+o1z/09CckbISNjenrI0y/QrnaAneQtzrciIUd4Fd giNw/adcA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:52808 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1g85An-004KSC-1O; Thu, 04 Oct 2018 11:04:17 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: Date: Thu, 4 Oct 2018 08:04:16 -0700 Cc: zhiyunq@cs.ucr.edu, "tcpm@ietf.org Extensions" Content-Transfer-Encoding: quoted-printable Message-Id: <15EA46D7-D00F-4E3B-B891-B169B12149E9@strayalpha.com> References: To: Loganaden Velvindron X-Mailer: Apple Mail (2.3445.9.1) 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: Subject: Re: [tcpm] rfc5961 and suggested updates. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 15:04:23 -0000 > On Oct 3, 2018, at 11:10 PM, Loganaden Velvindron = wrote: >=20 > On Tue, Oct 2, 2018 at 7:38 PM Zhiyun Qian wrote: >>=20 >> Loganaden and Mirja, >>=20 >> Not sure if my previous email went through. I'm copying it here: >>=20 >> Chiming in here. My name is Zhiyun Qian. We are the group of = researchers from UC Riverside who invented the original side channel = attack in 2016. Thanks Loganaden for initiating the changes to the = specification and thanks Mirja for putting me in the loop. I've done = much research in TCP security that I felt like this is home :) >>=20 >> My 2 cents: >>=20 >> - I fully support we make it explicit that per-socket rate limit = (instead of global limit) should be implemented either in a separate = draft or maybe RFC5961itself. I am not sure how people will come across = a separate draft like this. Will there be a link from RFC5961? To clarify, are you talking about a per =E2=80=9Csocket pair=E2=80=9D = (i.e., per connection) limit? For TCP, the term should be =E2=80=9Csocket = pair=E2=80=9D or =E2=80=9Cconnection=E2=80=9D. A socket could include = one local side of IP/port and many remote IP/ports, and I don=E2=80=99t = think that=E2=80=99s what you intend. (if you mean =E2=80=9Cunix socket=E2=80=9D then you=E2=80=99re writing = recommendations for unix implementers, which is much less useful as an = Internet doc). =E2=80=A6 >> - BTW, to this day, Linux still has the global rate limit together = with the per-socket limit (the latter will apply first), which still = leaves some possibility for attacks (although very slim). I understand = the global rate limit is to prevent the whole system from sending too = many challenge ACKs. However, to be honest, I am not sure why this is = considered harmful. Why don't we do something simple instead such as no = limit at all or apply only the per-socket limit? I infer two reasons = (1) reflection attacks --- but the amplification ratio is only 1:1. (2) = ACK loops --- but this can be mitigated by the per-socket limit already. = Why do we need a global rate limit? The benefit seems very incremental = to me. The only benefit is that when thousands of connections (perhaps = on a server) all enter the "ACK loop state" and started flooding the = network but this seems extremely unlikely? FWIW, all of this basically highlights the issue that simply receiving = these messages is not an =E2=80=9Cattack=E2=80=9D; the attack is = inferred from some threshold of activity. It=E2=80=99s difficult to = understand how to usefully set that threshold in any way that isn=E2=80=99= t trivial or arbitrarily heuristic (and I haven=E2=80=99t found the = draft you=E2=80=99re referring to). It seems like you=E2=80=99re arguing largely that this threshold should = be per connection rather than per IP address. If so, that=E2=80=99s such = a minimal issue it=E2=80=99s hard to understand this as more than an = errata to RFC5961. Joe= From nobody Thu Oct 4 09:43:19 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12630130E82 for ; Thu, 4 Oct 2018 09:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.502 X-Spam-Level: X-Spam-Status: No, score=-17.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 rMRHE68WUjy7 for ; Thu, 4 Oct 2018 09:43:16 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 E1926130DE4 for ; Thu, 4 Oct 2018 09:43:15 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id z8-v6so10576762qto.9 for ; Thu, 04 Oct 2018 09:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=HgkWVVdO+mlMLnbAVCMY0C0MB8n8QtGC6sgfYIfRpfU=; b=h7CfqoIbnlvZbqjaMfwPWeWslitljNTGJydJroov9fMsxDtq4VofE7Q9H8C+inAVgA kQ1twnUopzp1TYG5dDOENIN9Jk0Nxr0Pa6OS4NBAod+/HKq3YnCfwhNG9K7sQz+mk/A2 jUOsmoo8FTO5x7sHCV0hwg/VgPRvyder28mq/pgTU+IoHFyP6fo6evGigDLVmt1qLnvK lsR9kwrZQFGK73laiKa6S+mmeGpypQA2ILt32yfQXQJEbzf3/Y2tHbekC3bDnhJBy4C1 lg+nB/CLHZI7uRDf3ywR/rJi011lZGb7jUh8dYD+1pcYFKe9HQBffUdxHshRexU9MAMw VuTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=HgkWVVdO+mlMLnbAVCMY0C0MB8n8QtGC6sgfYIfRpfU=; b=IXkn09I9JarsDpdXUmrDWpHNCnTNiHdtvMkPD5qUkWlN1giJ02eU/2VUk2pbwsOtan ilqlzStvvN8ZYgxGnP+VIy56NX2wZALoJM/p5dNHVXtdDD/LvgV1rQcUKp6Doz0QbeQB mVXto1VmsAC7DJXL07liSm0kWZrFfM0LZJ5+wAOBOLyrEWutx0+ovw8RnQlYsscxao5g mKt6SSTq+ysUTRc/LkhAblw/rbAB/kXctIJltgkYqOlw7H9TLPc8b/QR1l8b9qMwNZSY FohFXQ0kJsVIlb0UtL/SF/AbCjuXwhrnWJNzlkP2tT3fYKjuXAUW1/MWToe+wbVG8bJ5 4ktw== X-Gm-Message-State: ABuFfoiUhxyayf/rbFnOoRcMBO9kaMVW13ZFpoHRd9VS2uHDHNKN6937 b6cOC3ueSl01iHWvV99tdoARzCOyk7cmO8IZCBJWRw== X-Google-Smtp-Source: ACcGV63aE8kR6q9X5nREO90sNNNKUoKRoy9/AqZlG8kFRmp+P5VsxbCrCJlFhj6ZFWbK4InFhmC+MAb1he6kQcDuaj8= X-Received: by 2002:ad4:5108:: with SMTP id g8-v6mr289442qvp.238.1538671394779; Thu, 04 Oct 2018 09:43:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Neal Cardwell Date: Thu, 4 Oct 2018 12:42:58 -0400 Message-ID: To: Loganaden Velvindron Cc: Zhiyun Qian , "tcpm@ietf.org" , Eric Dumazet , Yuchung Cheng Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] rfc5961 and suggested updates. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 16:43:18 -0000 On Thu, Oct 4, 2018 at 2:11 AM Loganaden Velvindron w= rote: > > On Tue, Oct 2, 2018 at 7:38 PM Zhiyun Qian wrote: > > > > Loganaden and Mirja, > > > > Not sure if my previous email went through. I'm copying it here: > > > > Chiming in here. My name is Zhiyun Qian. We are the group of researcher= s from UC Riverside who invented the original side channel attack in 2016. = Thanks Loganaden for initiating the changes to the specification and thanks= Mirja for putting me in the loop. I've done much research in TCP security = that I felt like this is home :) > > > > My 2 cents: > > > > - I fully support we make it explicit that per-socket rate limit (inste= ad of global limit) should be implemented either in a separate draft or may= be RFC5961itself. I am not sure how people will come across a separate draf= t like this. Will there be a link from RFC5961? > > > > That's a possibility if there is enough interest. Right now, I've > received feedback only from you and Mirja. I was hoping to get > feedback from more people. > The draft is pretty small, and I've removed the "controversial" parts > that some people disagreed with. > > > - BTW, to this day, Linux still has the global rate limit together with= the per-socket limit (the latter will apply first), which still leaves som= e possibility for attacks (although very slim). I understand the global rat= e limit is to prevent the whole system from sending too many challenge ACKs= . However, to be honest, I am not sure why this is considered harmful. Why = don't we do something simple instead such as no limit at all or apply only = the per-socket limit? I infer two reasons (1) reflection attacks --- but t= he amplification ratio is only 1:1. (2) ACK loops --- but this can be mitig= ated by the per-socket limit already. Why do we need a global rate limit? T= he benefit seems very incremental to me. The only benefit is that when thou= sands of connections (perhaps on a server) all enter the "ACK loop state" a= nd started flooding the network but this seems extremely unlikely? > > Re: https://tools.ietf.org/html/draft-lvelvindron-ack-throttling-03 I would support the suggestion to publish these recommendations (for per-connection rather than per-IP-address rate limiting) as an errata to RFC5961. neal From nobody Thu Oct 4 10:13:44 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30841130E7A for ; Thu, 4 Oct 2018 10:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 HCG5FNejY3q9 for ; Thu, 4 Oct 2018 10:13:39 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7091C130DD3 for ; Thu, 4 Oct 2018 10:13:39 -0700 (PDT) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 422DA278355 for ; Fri, 5 Oct 2018 02:13:37 +0900 (JST) Received: by mail-io1-f46.google.com with SMTP id p4-v6so8524763iom.3 for ; Thu, 04 Oct 2018 10:13:37 -0700 (PDT) X-Gm-Message-State: ABuFfojcis6TskrfBuwhtnLIvGlXj88ipVP+ADlUzrQ9Z4K/bl4qIfTO HxjyTCQATGpy9jMYeGlAvMaotHe6CIqCdAEFnCs= X-Google-Smtp-Source: ACcGV60NkngVDb6gcbQlzYVktB7Mf4IoCrfv2MA7j0meCTRNLqBDkzupu2UB6wMh36xuJZrWqcqyHWjhwMXI9USuBTA= X-Received: by 2002:a6b:c586:: with SMTP id v128-v6mr5229498iof.7.1538673215876; Thu, 04 Oct 2018 10:13:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yoshifumi Nishida Date: Thu, 4 Oct 2018 10:13:24 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "tcpm@ietf.org" Cc: loganaden@gmail.com, edumazet@google.com, ncardwell=40google.com@dmarc.ietf.org Content-Type: multipart/alternative; boundary="0000000000007537e705776a46b1" Archived-At: Subject: Re: [tcpm] rfc5961 and suggested updates. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 17:13:42 -0000 --0000000000007537e705776a46b1 Content-Type: text/plain; charset="UTF-8" Hi, I am personally wondering if per-connection or per-address based limit is the best way for this. In my reading of the usenix paper, it says using fixed value for global limit would be vulnerable. So, it seems to me that it would be ok if the value is not fixed, I think there're several ways to do this such as 1) keep changing global limit at certain interval. 2) after exceeding a certain threshold, send challenge ACKs with a certain probability. I am thinking this might be relatively inexpensive rather than having per-connection/address limit. Thanks, -- Yoshi On Thu, Oct 4, 2018 at 9:42 AM Neal Cardwell wrote: > On Thu, Oct 4, 2018 at 2:11 AM Loganaden Velvindron > wrote: > > > > On Tue, Oct 2, 2018 at 7:38 PM Zhiyun Qian wrote: > > > > > > Loganaden and Mirja, > > > > > > Not sure if my previous email went through. I'm copying it here: > > > > > > Chiming in here. My name is Zhiyun Qian. We are the group of > researchers from UC Riverside who invented the original side channel attack > in 2016. Thanks Loganaden for initiating the changes to the specification > and thanks Mirja for putting me in the loop. I've done much research in TCP > security that I felt like this is home :) > > > > > > My 2 cents: > > > > > > - I fully support we make it explicit that per-socket rate limit > (instead of global limit) should be implemented either in a separate draft > or maybe RFC5961itself. I am not sure how people will come across a > separate draft like this. Will there be a link from RFC5961? > > > > > > > That's a possibility if there is enough interest. Right now, I've > > received feedback only from you and Mirja. I was hoping to get > > feedback from more people. > > The draft is pretty small, and I've removed the "controversial" parts > > that some people disagreed with. > > > > > - BTW, to this day, Linux still has the global rate limit together > with the per-socket limit (the latter will apply first), which still leaves > some possibility for attacks (although very slim). I understand the global > rate limit is to prevent the whole system from sending too many challenge > ACKs. However, to be honest, I am not sure why this is considered harmful. > Why don't we do something simple instead such as no limit at all or apply > only the per-socket limit? I infer two reasons (1) reflection attacks --- > but the amplification ratio is only 1:1. (2) ACK loops --- but this can be > mitigated by the per-socket limit already. Why do we need a global rate > limit? The benefit seems very incremental to me. The only benefit is that > when thousands of connections (perhaps on a server) all enter the "ACK loop > state" and started flooding the network but this seems extremely unlikely? > > > > > Re: > https://tools.ietf.org/html/draft-lvelvindron-ack-throttling-03 > > I would support the suggestion to publish these recommendations (for > per-connection rather than per-IP-address rate limiting) as an errata > to RFC5961. > > neal > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --0000000000007537e705776a46b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, I am personally wondering if per-connection or per-add= ress based limit is the best way for this.
In my reading of the usenix = paper, it says using fixed value for global limit would be vulnerable. So, = it seems to me that it would be ok if the value is not fixed,=C2=A0
I think there're several ways to do this such as 1) keep changing gl= obal limit at certain interval. 2) after exceeding a certain threshold, sen= d challenge ACKs with a certain probability. I am thinking this might be re= latively inexpensive rather than having per-connection/address limit.
=

Thanks,
--
Yoshi

On Thu, Oct 4, 2018 at 9:42 AM Neal Cardw= ell <ncardwell=3D40google= .com@dmarc.ietf.org> wrote:
= On Thu, Oct 4, 2018 at 2:11 AM Loganaden Velvindron <loganaden@gmail.com> wrote: >
> On Tue, Oct 2, 2018 at 7:38 PM Zhiyun Qian <zhiyunq@cs.ucr.edu> wrote:
> >
> > Loganaden and Mirja,
> >
> > Not sure if my previous email went through. I'm copying it he= re:
> >
> > Chiming in here. My name is Zhiyun Qian. We are the group of rese= archers from UC Riverside who invented the original side channel attack in = 2016. Thanks Loganaden for initiating the changes to the specification and = thanks Mirja for putting me in the loop. I've done much research in TCP= security that I felt like this is home :)
> >
> > My 2 cents:
> >
> > - I fully support we make it explicit that per-socket rate limit = (instead of global limit) should be implemented either in a separate draft = or maybe RFC5961itself. I am not sure how people will come across a separat= e draft like this. Will there be a link from RFC5961?
> >
>
> That's a possibility if there is enough interest. Right now, I'= ;ve
> received feedback only from you and Mirja. I was hoping to get
> feedback from more people.
> The draft is pretty small, and I've removed the "controversia= l" parts
> that some people disagreed with.
>
> > - BTW, to this day, Linux still has the global rate limit togethe= r with the per-socket limit (the latter will apply first), which still leav= es some possibility for attacks (although very slim). I understand the glob= al rate limit is to prevent the whole system from sending too many challeng= e ACKs. However, to be honest, I am not sure why this is considered harmful= . Why don't we do something simple instead such as no limit at all or a= pply only the per-socket limit? I infer two reasons=C2=A0 (1) reflection at= tacks --- but the amplification ratio is only 1:1. (2) ACK loops --- but th= is can be mitigated by the per-socket limit already. Why do we need a globa= l rate limit? The benefit seems very incremental to me. The only benefit is= that when thousands of connections (perhaps on a server) all enter the &qu= ot;ACK loop state" and started flooding the network but this seems ext= remely unlikely?
> >

Re:
=C2=A0 https://tools.ietf.org/html/dr= aft-lvelvindron-ack-throttling-03

I would support the suggestion to publish these recommendations (for
per-connection rather than per-IP-address rate limiting) as an errata
to RFC5961.

neal

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--0000000000007537e705776a46b1-- From nobody Thu Oct 4 17:29:59 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0570C129385 for ; Thu, 4 Oct 2018 17:29:56 -0700 (PDT) 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 4HwuadMI1mON for ; Thu, 4 Oct 2018 17:29:54 -0700 (PDT) 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 EC64B126F72 for ; Thu, 4 Oct 2018 17:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type: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=6zFr0IhNgXmJOBTQwFXAr6atfaVis82WLsbtYf5hD4E=; b=QZBvtZjcD6cJjjXptXcfIKfnp ZztabI1J4yo2oe84r2lav2OcrW8yeN55BeRgbWSMW5MuLd7fw9xprwzjThk4zUiEKhQBY9B5X81gP HYjDEeasrQ9TEvVv+tmfepX5MIxaejYqT+uY3JzCU3SY14LoqozREHl7ajOEqePf0FtSatdMFsCeW cu75RQP6cAnDz3keQW2Ec0ZI4NofF8aMhoYBgv+AvU3tkoOkHJ/pWuvMayWcuPaJVCZs2TgS7wuL0 /LP/AvcpDkIOwfgOKbpM8NpPy5CuVm69v3OC9stuIuEgVHf+JCYwIv4JiD/PS/u3x2RTsyCMvH6k2 hKGXR9FHw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:52876 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1g8E08-001wMG-2x; Thu, 04 Oct 2018 20:29:52 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_7C58F158-9C76-4EA1-B99D-FA77BDBA5C6F" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: Date: Thu, 4 Oct 2018 17:29:51 -0700 Cc: Loganaden Velvindron , tcpm@ietf.org Message-Id: References: <15EA46D7-D00F-4E3B-B891-B169B12149E9@strayalpha.com> To: Zhiyun Qian X-Mailer: Apple Mail (2.3445.9.1) 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: Subject: Re: [tcpm] rfc5961 and suggested updates. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 00:29:56 -0000 --Apple-Mail=_7C58F158-9C76-4EA1-B99D-FA77BDBA5C6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 4, 2018, at 9:26 AM, Zhiyun Qian wrote: >=20 > Last time I checked, FreeBSD/macOS and Windows have not fully = implemented RFC5961 yet. That seems correct to me. This mechanism is relevant only for on-path attackers and useful mostly = for long-lived services. Neither is typical for end users. Joe --Apple-Mail=_7C58F158-9C76-4EA1-B99D-FA77BDBA5C6F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Oct 4, 2018, at 9:26 AM, Zhiyun Qian <zhiyunq@cs.ucr.edu> = wrote:

Last time I checked, = FreeBSD/macOS and Windows have not fully implemented RFC5961 = yet.

That seems = correct to me.

This mechanism is = relevant only for on-path attackers and useful mostly for long-lived = services. Neither is typical for end users.

Joe

= --Apple-Mail=_7C58F158-9C76-4EA1-B99D-FA77BDBA5C6F-- From nobody Thu Oct 4 18:20:57 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4BA130DC7 for ; Thu, 4 Oct 2018 18:20:55 -0700 (PDT) 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=unavailable 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 Ar5BiYIqYVZe for ; Thu, 4 Oct 2018 18:20:53 -0700 (PDT) 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 22ABD130DC4 for ; Thu, 4 Oct 2018 18:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type: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=prTmyfu5qa7GvzjoYojT4rNLpWSEnThtxIfb1G8mEwE=; b=4ldq006ZeNy/+eTcNnm835lG1 WQLD2xPcqRGEIP9okFYJCfoDSM9YXbPRMlLhsIWt/giIHRNsuzEUkyxE0yY5JuJtPQLOZj1wnFtbW WO48hsrzxfyivq1AWdQtYrpsEw1FTJxqPi8YvRCT38z/yVQqQJPr9SEuLpwMmgqEPzUdsNXyJyNcx +Tsr1Sn0dklQq1zzP4b/Muj5dII+yQQ0LATRTMkfCabBbownof8yzaCoBC6/QInsjZaf0JqoxaV7k AjFVl/HVNutqjwMQoWb+9PCX+M0z5E2QYT2aaM1YyB/9SIHX4UDZ2CQrOXDSohiZvF6WThJFlRi+z bpg79XeCQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:52876 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1g8E0Z-001wMG-Fp; Thu, 04 Oct 2018 20:30:25 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_85E04FA3-739F-4808-9C48-75FCF99E8C77" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: Date: Thu, 4 Oct 2018 17:30:19 -0700 Cc: Loganaden Velvindron , Eric Dumazet , "tcpm@ietf.org" Message-Id: <91E0378A-354A-41A0-A1A9-C888AD4E0178@strayalpha.com> References: To: Neal Cardwell X-Mailer: Apple Mail (2.3445.9.1) 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: Subject: Re: [tcpm] rfc5961 and suggested updates. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 01:20:56 -0000 --Apple-Mail=_85E04FA3-739F-4808-9C48-75FCF99E8C77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FWIW, that makes the most sense to me. > On Oct 4, 2018, at 9:42 AM, Neal Cardwell = wrote: >=20 > Re: > https://tools.ietf.org/html/draft-lvelvindron-ack-throttling-03 = >=20 > I would support the suggestion to publish these recommendations (for > per-connection rather than per-IP-address rate limiting) as an errata > to RFC5961. >=20 > neal --Apple-Mail=_85E04FA3-739F-4808-9C48-75FCF99E8C77 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FWIW,= that makes the most sense to me.

On Oct = 4, 2018, at 9:42 AM, Neal Cardwell <ncardwell=3D40google.com@dmarc.ietf.org> = wrote:

Re:
 https://tools.ietf.org/html/draft-lvelvindron-ack-throttling-03=

I would = support the suggestion to publish these recommendations (for
per-connection rather than = per-IP-address rate limiting) as an errata
to RFC5961.

neal

= --Apple-Mail=_85E04FA3-739F-4808-9C48-75FCF99E8C77-- From nobody Fri Oct 5 09:40:51 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE1E130E55 for ; Fri, 5 Oct 2018 09:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 nGoYv7IajND9 for ; Fri, 5 Oct 2018 09:40:48 -0700 (PDT) Received: from lxdnp29m.centurylink.com (lxdnp29m.centurylink.com [155.70.32.52]) (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 E19AB130E51 for ; Fri, 5 Oct 2018 09:40:47 -0700 (PDT) Received: from lxomp90v.corp.intranet (emailout.qintra.com [151.117.203.59]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id w95GeiFa025431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 5 Oct 2018 10:40:45 -0600 Received: from lxomp90v.corp.intranet (localhost [127.0.0.1]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id w95Gedab056842; Fri, 5 Oct 2018 11:40:39 -0500 Received: from lxdnp31k.corp.intranet (lxomp81v.corp.intranet [151.117.18.14]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id w95GedDg056831 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Fri, 5 Oct 2018 11:40:39 -0500 Received: from lxdnp31k.corp.intranet (localhost [127.0.0.1]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id w95GecOV042102; Fri, 5 Oct 2018 10:40:38 -0600 Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id w95Gect7042094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Oct 2018 10:40:38 -0600 Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([151.119.128.28]) with mapi id 14.03.0339.000; Fri, 5 Oct 2018 10:40:38 -0600 From: "Smith, Donald" To: Joe Touch , Neal Cardwell CC: Eric Dumazet , "tcpm@ietf.org" Thread-Topic: [tcpm] rfc5961 and suggested updates. Thread-Index: AQHUO7PXINhfy3iY1ka1dkXbKt8YOaUMYO0AgAJ6EZOAARTMAIAAgpOAgACfKdw= Date: Fri, 5 Oct 2018 16:40:37 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D53E3759D@PDDCWMBXEX503.ctl.intranet> References: , <91E0378A-354A-41A0-A1A9-C888AD4E0178@strayalpha.com> In-Reply-To: <91E0378A-354A-41A0-A1A9-C888AD4E0178@strayalpha.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.8] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tcpm] rfc5961 and suggested updates. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 16:40:50 -0000 Has anyone done the math to show this wouldn't be a 64k increase in counter= s/buffers/challenge ACKs? Intuitively I know it isn't, in most cases you only have a few open ports/s= ervices, so probably 2x, 3x... ? Is there any value to saying only OPEN sockets, ports or services or is tha= t implied? Is open socket the same as if it would have been allowed by a filter? Clearly the OS doesn't know if a middle box would have filtered it, but it = could in theory know if a host based filter would have stopped it. "2. Recommendation for ACK throttling mechanism An implementation SHOULD have a per-socket ACK throttling mechanism which is not shared across the system." Socket implies open port/service, but if a port is open at the OS level but= closed or limited to a specific set of source addresses via ACL, Iptables,= IPF (HFW)=85 or even a middle box should that be taken into account Packe= t could be filtered at a higher level than basic OS socket creation so no c= hallenge ack nor counter needed unless it could have been allowed? If you only send challenge acks for open ports/services would this provide = a way to do negative scans? The src is spoofed, so I don't think so, as the blind reset sender isn't se= eing the challenges. Metric System < +000 > -000 Extra People's Terribly Good Meals Kept mY uNCLE Ned Purring For A= ges Exa Peta Tera Giga Mega Kilo milli Micro(u) Nano Pico Fe= mto Atto Donald.Smith@centurylink.com From: tcpm [tcpm-bounces@ietf.org] on behalf of Joe Touch [touch@strayalpha= .com] Sent: Thursday, October 04, 2018 6:30 PM To: Neal Cardwell Cc: Eric Dumazet; tcpm@ietf.org Subject: Re: [tcpm] rfc5961 and suggested updates. FWIW, that makes the most sense to me. On Oct 4, 2018, at 9:42 AM, Neal Cardwell wrote: Re: https://tools.ietf.org/html/draft-lvelvindron-ack-throttling-03 I would support the suggestion to publish these recommendations (for per-connection rather than per-IP-address rate limiting) as an errata to RFC5961. neal This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Fri Oct 5 16:50:34 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16302130EF7 for ; Fri, 5 Oct 2018 16:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.101 X-Spam-Level: *** X-Spam-Status: No, score=3.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, SPF_PASS=-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 F607g-zoDl-j for ; Fri, 5 Oct 2018 16:50:21 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9EE6130ED3 for ; Fri, 5 Oct 2018 16:50:20 -0700 (PDT) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A19A5278460 for ; Sat, 6 Oct 2018 08:50:18 +0900 (JST) Received: by mail-io1-f50.google.com with SMTP id x26-v6so11931433iog.11 for ; Fri, 05 Oct 2018 16:50:18 -0700 (PDT) X-Gm-Message-State: ABuFfogE1ntLyekAUtLjUzJt652mjpebi67mQb37Xk4vfw2mB6MJmUx9 opnPm3WDY6hUNDfmIeFRnH+onebu7N5C8U6XhiE= X-Google-Smtp-Source: ACcGV61n1Whst5HfCbBpfjInH0DN8MI16LnqBOsAxsGnTTM919HCBgqTtMWtwGLQe5BiRICwDcZDQg6fJgakHodrXxg= X-Received: by 2002:a6b:b558:: with SMTP id e85-v6mr9552986iof.6.1538783416692; Fri, 05 Oct 2018 16:50:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yoshifumi Nishida Date: Fri, 5 Oct 2018 16:50:04 -0700 X-Gmail-Original-Message-ID: Message-ID: To: zhiyunq@cs.ucr.edu Cc: Yoshifumi Nishida , "tcpm@ietf.org" , edumazet@google.com, ncardwell=40google.com@dmarc.ietf.org Content-Type: multipart/alternative; boundary="000000000000f043bb057783ee37" Archived-At: Subject: Re: [tcpm] rfc5961 and suggested updates. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 23:50:33 -0000 --000000000000f043bb057783ee37 Content-Type: text/plain; charset="UTF-8" Hi Zhiyun, OK. So, in my understanding, this attack infers the lower bound at first, then repeating the process to expect eventually the target selects the lower bound value again everytime they narrow down to identify the proper seqno or ackno. I also think this could be a potential risk, but we can easily increase the difficulties by using wide random range or probability-based response without increasing the complexity of the implementations much. Anyway, if many implementors think having per-connection/address limit is easier and inexpensive, I don't have any more opinions on it. Thanks for the info! -- Yoshi On Thu, Oct 4, 2018 at 11:07 PM Zhiyun Qian wrote: > Yoshifumi, > > Linux did implement the fix to randomize the global limit for each > 1-second interval (I think Eric made the patch if I am not mistaken). > However, such randomization can be tricky to analyze and is not fool-proof. > In fact, there is still information leakage in the current Linux > implementation (albeit much more difficult to exploit). Hence I'd still > vote for the per-connection rate limit. > > Let us imagine the random range of the limit to be 100 to 200 (Linux uses > a larger range but let us use it just for the sake of discussion). To infer > whether a spoofed packet triggers a challenge ACK, the attacker can do the > following: it sends 1 spoofed packet and 100 non-spoofed packets (the sum > of which would be 101, just slightly over the lower bound of the limit). > Whenever the spoofed packet triggers a challenge ACK from the victim > server, and the server happens to choose 100 as the limit of the current > interval, the attacker will see exactly 99 challenge ACKs back to itself > --- this is the only time the attacker should see 99 (all other times the > attacker will see 100, which doesn't leak anything because it could either > be the case that spoofed packet does not triggger a challenge ACK, or > perhaps it did but the server's limit at the moment is higher than 100). > This still allows the attacker to infer whether a spoofed packet does > trigger a challenge ACK. It just needs to guess 50X more times (on average) > compared to the original attack. Obviously here this is just an example. > The larger the random range, the longer it will take the server to pick the > lower bound as its limit by chance. > > In terms of how expensive it is to implement this, Linux seems to have the > per-connection rate limit even before the challenge ACK was introduced. So > it doesn't seem to be a lot of overhead? > > Best, > -Zhiyun > > > On Thu, Oct 4, 2018 at 10:13 AM Yoshifumi Nishida > wrote: > >> Hi, I am personally wondering if per-connection or per-address based >> limit is the best way for this. >> In my reading of the usenix paper, it says using fixed value for global >> limit would be vulnerable. So, it seems to me that it would be ok if the >> value is not fixed, >> I think there're several ways to do this such as 1) keep changing global >> limit at certain interval. 2) after exceeding a certain threshold, send >> challenge ACKs with a certain probability. I am thinking this might be >> relatively inexpensive rather than having per-connection/address limit. >> >> Thanks, >> -- >> Yoshi >> >> On Thu, Oct 4, 2018 at 9:42 AM Neal Cardwell > 40google..com@dmarc.ietf.org <40google.com@dmarc.ietf.org>> wrote: >> >>> On Thu, Oct 4, 2018 at 2:11 AM Loganaden Velvindron >>> wrote: >>> > >>> > On Tue, Oct 2, 2018 at 7:38 PM Zhiyun Qian wrote: >>> > > >>> > > Loganaden and Mirja, >>> > > >>> > > Not sure if my previous email went through. I'm copying it here: >>> > > >>> > > Chiming in here. My name is Zhiyun Qian. We are the group of >>> researchers from UC Riverside who invented the original side channel attack >>> in 2016. Thanks Loganaden for initiating the changes to the specification >>> and thanks Mirja for putting me in the loop. I've done much research in TCP >>> security that I felt like this is home :) >>> > > >>> > > My 2 cents: >>> > > >>> > > - I fully support we make it explicit that per-socket rate limit >>> (instead of global limit) should be implemented either in a separate draft >>> or maybe RFC5961itself. I am not sure how people will come across a >>> separate draft like this. Will there be a link from RFC5961? >>> > > >>> > >>> > That's a possibility if there is enough interest. Right now, I've >>> > received feedback only from you and Mirja. I was hoping to get >>> > feedback from more people. >>> > The draft is pretty small, and I've removed the "controversial" parts >>> > that some people disagreed with. >>> > >>> > > - BTW, to this day, Linux still has the global rate limit together >>> with the per-socket limit (the latter will apply first), which still leaves >>> some possibility for attacks (although very slim). I understand the global >>> rate limit is to prevent the whole system from sending too many challenge >>> ACKs. However, to be honest, I am not sure why this is considered harmful.. >>> Why don't we do something simple instead such as no limit at all or apply >>> only the per-socket limit? I infer two reasons (1) reflection attacks --- >>> but the amplification ratio is only 1:1. (2) ACK loops --- but this can be >>> mitigated by the per-socket limit already. Why do we need a global rate >>> limit? The benefit seems very incremental to me. The only benefit is that >>> when thousands of connections (perhaps on a server) all enter the "ACK loop >>> state" and started flooding the network but this seems extremely unlikely? >>> > > >>> >>> Re: >>> https://tools.ietf.org/html/draft-lvelvindron-ack-throttling-03 >>> >>> I would support the suggestion to publish these recommendations (for >>> per-connection rather than per-IP-address rate limiting) as an errata >>> to RFC5961. >>> >>> neal >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > --000000000000f043bb057783ee37 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Zhiyun,

OK. So, in my understanding,= this attack infers the lower bound at first, then repeating the process to= expect eventually the target selects the lower bound value again everytime= they narrow down to identify the proper seqno or ackno.=C2=A0
I = also think this could be a potential risk, but we can easily increase the d= ifficulties by using wide random range or probability-based response withou= t increasing the complexity of the implementations much.
Anyway, = if many implementors think having per-connection/address limit is easier an= d inexpensive, I don't have any more opinions on it.
Thanks f= or the info!
--
Yoshi


On Thu, Oct 4, 2018 at 11:07 PM Zhiyun Qi= an <zhiyunq@cs.u= cr.edu> wrote:
Yoshifumi,

Linux did implement the fix to randomize = the global limit for each 1-second interval (I think Eric made the patch if= I am not mistaken). However, such randomization can be tricky to analyze a= nd is not fool-proof. In fact, there is still information leakage in the cu= rrent Linux implementation (albeit much more difficult to exploit). Hence I= 'd still vote for the per-connection rate limit.

Let us imagine the random range of the limit to be 100 to 200 (Linux use= s a larger range but let us use it just for the sake of discussion). To inf= er whether a spoofed packet triggers a challenge ACK, the attacker can do t= he following: it sends 1 spoofed packet and 100 non-spoofed packets (the su= m of which would be 101, just slightly over the lower bound of the limit). = Whenever the spoofed packet triggers a challenge ACK from the victim server= , and the server happens to choose 100 as the limit of the current interval= , the attacker will see exactly 99 challenge ACKs back to itself --- this i= s the only time the attacker should see 99 (all other times the attacker wi= ll see 100, which doesn't leak anything because it could either be the = case that spoofed packet does not triggger a challenge ACK, or perhaps it d= id but the server's limit at the moment is higher than 100). This still= allows the attacker to infer whether a spoofed packet does trigger a chall= enge ACK. It just needs to guess 50X more times (on average) compared to th= e original attack. Obviously here this is just an example. The larger the r= andom range, the longer it will take the server to pick the lower bound as = its limit by chance.

In terms of how expensive it = is to implement this, Linux seems to have the per-connection rate limit eve= n before the challenge ACK was introduced. So it doesn't seem to be a l= ot of overhead?

Best,
-Zhiyun


On Thu, Oct 4, 2018 = at 10:13 AM Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
Hi, I am personally wondering if per= -connection or per-address based limit is the best way for this.
In my = reading of the usenix paper, it says using fixed value for global limit wou= ld be vulnerable. So, it seems to me that it would be ok if the value is no= t fixed,=C2=A0
I think there're several ways to do this such = as 1) keep changing global limit at certain interval. 2) after exceeding a = certain threshold, send challenge ACKs with a certain probability. I am thi= nking this might be relatively inexpensive rather than having per-connectio= n/address limit.

Thanks,
--
Yo= shi

On Thu, Oct 4, 2018 = at 9:42 AM Neal Cardwell <ncardwell=3D40google..com@dmarc.ietf.org> wrote:<= br>
On Thu, Oct 4, 2018 at 2:11 AM Loga= naden Velvindron <loganaden@gmail.com> wrote:
>
> On Tue, Oct 2, 2018 at 7:38 PM Zhiyun Qian <zhiyunq@cs.ucr.edu> wrote:
> >
> > Loganaden and Mirja,
> >
> > Not sure if my previous email went through. I'm copying it he= re:
> >
> > Chiming in here. My name is Zhiyun Qian. We are the group of rese= archers from UC Riverside who invented the original side channel attack in = 2016. Thanks Loganaden for initiating the changes to the specification and = thanks Mirja for putting me in the loop. I've done much research in TCP= security that I felt like this is home :)
> >
> > My 2 cents:
> >
> > - I fully support we make it explicit that per-socket rate limit = (instead of global limit) should be implemented either in a separate draft = or maybe RFC5961itself. I am not sure how people will come across a separat= e draft like this. Will there be a link from RFC5961?
> >
>
> That's a possibility if there is enough interest. Right now, I'= ;ve
> received feedback only from you and Mirja. I was hoping to get
> feedback from more people.
> The draft is pretty small, and I've removed the "controversia= l" parts
> that some people disagreed with.
>
> > - BTW, to this day, Linux still has the global rate limit togethe= r with the per-socket limit (the latter will apply first), which still leav= es some possibility for attacks (although very slim). I understand the glob= al rate limit is to prevent the whole system from sending too many challeng= e ACKs. However, to be honest, I am not sure why this is considered harmful= .. Why don't we do something simple instead such as no limit at all or = apply only the per-socket limit? I infer two reasons=C2=A0 (1) reflection a= ttacks --- but the amplification ratio is only 1:1. (2) ACK loops --- but t= his can be mitigated by the per-socket limit already. Why do we need a glob= al rate limit? The benefit seems very incremental to me. The only benefit i= s that when thousands of connections (perhaps on a server) all enter the &q= uot;ACK loop state" and started flooding the network but this seems ex= tremely unlikely?
> >

Re:
=C2=A0 https://tools.ietf.org/html/dr= aft-lvelvindron-ack-throttling-03

I would support the suggestion to publish these recommendations (for
per-connection rather than per-IP-address rate limiting) as an errata
to RFC5961.

neal

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000f043bb057783ee37-- From nobody Fri Oct 5 16:52:22 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08729130EAC for ; Fri, 5 Oct 2018 16:52:08 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 3ASeOOGEDMaB for ; Fri, 5 Oct 2018 16:52:06 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80BF4130DD7 for ; Fri, 5 Oct 2018 16:52:05 -0700 (PDT) Received: from mail-it1-f181.google.com (mail-it1-f181.google.com [209.85.166.181]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id ED3F6278460 for ; Sat, 6 Oct 2018 08:52:03 +0900 (JST) Received: by mail-it1-f181.google.com with SMTP id q70-v6so4804090itb.3 for ; Fri, 05 Oct 2018 16:52:03 -0700 (PDT) X-Gm-Message-State: ABuFfogrPZgvr7AcH7gsNPs0uKWPS47n0AQq5FyaYf5DRoI4DpXBQUwK meZFhEb/EyRdRB0iXg0p0nL8XRH+/xEogfFEEpY= X-Google-Smtp-Source: ACcGV61nHXfjGPnrhL5rFccm4j+lsv0p8BHBkuOjh4VVeSnBpzipkzPtcYSCmSw0rqmQpHmQdV79P8efZv12/H45xqI= X-Received: by 2002:a24:f30f:: with SMTP id t15-v6mr9722811ith.95.1538783522713; Fri, 05 Oct 2018 16:52:02 -0700 (PDT) MIME-Version: 1.0 References: <91E0378A-354A-41A0-A1A9-C888AD4E0178@strayalpha.com> In-Reply-To: <91E0378A-354A-41A0-A1A9-C888AD4E0178@strayalpha.com> From: Yoshifumi Nishida Date: Fri, 5 Oct 2018 16:51:49 -0700 X-Gmail-Original-Message-ID: Message-ID: To: touch@strayalpha.com Cc: ncardwell=40google.com@dmarc.ietf.org, edumazet@google.com, "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="00000000000041fa36057783f56d" Archived-At: Subject: Re: [tcpm] rfc5961 and suggested updates. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 23:52:21 -0000 --00000000000041fa36057783f56d Content-Type: text/plain; charset="UTF-8" Just in case.. The errata 4772 https://www.rfc-editor.org/errata/eid4772 has mentioned this issue and 793bis already refers it. -- Yoshi On Thu, Oct 4, 2018 at 5:30 PM Joe Touch wrote: > FWIW, that makes the most sense to me. > > On Oct 4, 2018, at 9:42 AM, Neal Cardwell < > ncardwell=40google.com@dmarc.ietf.org> wrote: > > Re: > https://tools.ietf.org/html/draft-lvelvindron-ack-throttling-03 > > I would support the suggestion to publish these recommendations (for > per-connection rather than per-IP-address rate limiting) as an errata > to RFC5961. > > neal > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --00000000000041fa36057783f56d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just in case..
The errata 4772=C2=A0https://ww= w.rfc-editor.org/errata/eid4772=C2=A0has mentioned this issue and 793bi= s already refers it.
--
Yoshi

On Thu, Oct 4, 2018 at 5:30 PM Jo= e Touch <touch= @strayalpha.com> wrote:
FWIW, that makes the most sense to me.

On Oct 4, 2018, at 9:42 AM, Neal Cardwell <= ncardwell=3D40google.com@dmarc.ietf.org> wrote:

Re:
=C2=A0https= ://tools.ietf.org/html/draft-lvelvindron-ack-throttling-03

= I would support the suggestion to publish these recommendations (for=
per-con= nection rather than per-IP-address rate limiting) as an errata
to RFC5961.

neal

___________= ____________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--00000000000041fa36057783f56d-- From nobody Mon Oct 8 22:47:17 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F18131153; Mon, 8 Oct 2018 22:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 BRYBbtjCJEUR; Mon, 8 Oct 2018 22:47:12 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 E48CC13114E; Mon, 8 Oct 2018 22:47:11 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w995l9R3041079; Tue, 9 Oct 2018 07:47:09 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id B8E8F1D53C1; Tue, 9 Oct 2018 07:47:09 +0200 (CEST) Received: from 83.35.166.151 by webmail.entel.upc.edu with HTTP; Tue, 9 Oct 2018 07:47:09 +0200 Message-ID: <26ed385e2f00a41e717a9d4b4043f9b9.squirrel@webmail.entel.upc.edu> Date: Tue, 9 Oct 2018 07:47:09 +0200 From: "Carles Gomez Montenegro" To: tcpm@ietf.org, lwip@ietf.org User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at violet X-Virus-Status: Clean X-Greylist: ACL matched, not delayed by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Tue, 09 Oct 2018 07:47:09 +0200 (CEST) Archived-At: Subject: [tcpm] [Fwd: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-04.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 05:47:15 -0000 Dear LWIG and TCPM WGs, As you can see below, we have updated the "TCP Usage Guidance in the Internet of Things (IoT)" draft. This revision intends to address previously pending TODOs, as well as comments from the LWIG session in Montreal. As you may recall, we are getting ready for requesting a WGLC. Your comments will be most welcome. Thanks, Carles (on behalf of all authors) ---------------------------- Original Message ---------------------------- Subject: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-04.txt From: internet-drafts@ietf.org Date: Tue, October 9, 2018 7:30 am To: i-d-announce@ietf.org Cc: lwip@ietf.org -------------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Light-Weight Implementation Guidance WG of the IETF. Title : TCP Usage Guidance in the Internet of Things (IoT) Authors : Carles Gomez Jon Crowcroft Michael Scharf Filename : draft-ietf-lwig-tcp-constrained-node-networks-04.txt Pages : 25 Date : 2018-10-08 Abstract: This document provides guidance on how to implement and use the Transmission Control Protocol (TCP) in Constrained-Node Networks (CNNs), which are a characterstic of the Internet of Things (IoT). Such environments require a lightweight TCP implementation and may not make use of optional functionality. This document explains a number of known and deployed techniques to simplify a TCP stack as well as corresponding tradeoffs. The objective is to help embedded developers with decisions on which TCP features to use. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-04 https://datatracker.ietf.org/doc/html/draft-ietf-lwig-tcp-constrained-node-networks-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-tcp-constrained-node-networks-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/ _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip From nobody Wed Oct 10 00:47:54 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B04F130DF4; Wed, 10 Oct 2018 00:47:53 -0700 (PDT) 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, 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 pypFt6SQxy2m; Wed, 10 Oct 2018 00:47:51 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB824130DEF; Wed, 10 Oct 2018 00:47:50 -0700 (PDT) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id B34B2278331; Wed, 10 Oct 2018 16:47:48 +0900 (JST) Received: by mail-io1-f50.google.com with SMTP id y10-v6so3176406ioa.10; Wed, 10 Oct 2018 00:47:48 -0700 (PDT) X-Gm-Message-State: ABuFfojCu4yU1H4fGFpPGfZtaecdZxLo4L+0uXldIC+a+HJcxVP9zn3R cA7tch/oxiX6zbwg7l99N6McjyJmi/K+pHtZ36Y= X-Google-Smtp-Source: ACcGV63uvAlRAV7HaF02xDUq4EtSbkgrVJqeNRyxZyaMOtgFxjz/CScRnaUTKx3sLS8rFyEM3faVFZ8nT1mELywLyRg= X-Received: by 2002:a6b:b558:: with SMTP id e85-v6mr21299844iof.6.1539157667481; Wed, 10 Oct 2018 00:47:47 -0700 (PDT) MIME-Version: 1.0 From: Yoshifumi Nishida Date: Wed, 10 Oct 2018 00:47:33 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "tcpm@ietf.org" Cc: "tcpm-chairs@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [tcpm] IETF 103 agenda request X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 07:47:53 -0000 Hello, As it's shown in the current agenda ( https://datatracker.ietf.org/meeting/103/agenda.html ), we are planning to have two slots at the Bangkok meeting. But, we are thinking about using one slot (Tuesday Morning session II) for a dedicated topic. So, our usual WG meeting will be on Monday (11/05) 16:10-18:10. (Monday Afternoon session II) If you are planning to present something, please let the chairs know the following information. * Title / draft name * Presenter's name * Total time (including Q/A) * If it's a remote presentation, please specify it We'll make an announcement about the Tuesday session later. Also, please note that the current schedule is still preliminary and might be changed. Thanks, -- tcpm co-chairs From nobody Thu Oct 11 13:54:06 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897FD124C04 for ; Thu, 11 Oct 2018 13:54:04 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de 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 KfvMkRQHeaEg for ; Thu, 11 Oct 2018 13:54:01 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E70C120072 for ; Thu, 11 Oct 2018 13:54:01 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 5C49025A16 for ; Thu, 11 Oct 2018 22:53:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1539291239; bh=mEsxcMelg77tWG5KsjGD22I2ckZ7FlGAZxPFm6tlRWc=; h=From:To:Subject:Date:From; b=ntyOUlG3DxTM63T50bheMKeWjRA73eNc2rMVIqviy3hPljALtiEV0g1/f0YBtciEN ju2sE/tdM2W8zwlSPrCVQ1o6jCEUtzfFct48WsZP5tOEntTlhpYV2cF7+rt0WsVsTO uFzQgtW6aaiUWbknY5DGKpiNUV9fDZ6UhlaAehv8= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsbFCgXxV0IM for ; Thu, 11 Oct 2018 22:53:59 +0200 (CEST) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.hs-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS for ; Thu, 11 Oct 2018 22:53:59 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.25]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Thu, 11 Oct 2018 22:53:59 +0200 From: "Scharf, Michael" To: "'tcpm@ietf.org'" Thread-Topic: Transmission Control Protocol (TCP) YANG Model Thread-Index: AdRhn/W/gtmtK7AsSNmAr1axaU5oYg== Date: Thu, 11 Oct 2018 20:53:58 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D136925@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] Transmission Control Protocol (TCP) YANG Model X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 20:54:05 -0000 Hi all, As individual contributor I have submitted a new I-D that discusses whether= a TCP YANG model would be useful. The -00 draft content is just meant as a starting point for triggering that= discussion in the IETF. The YANG model currently included in the I-D obvio= usly has issues. The document also includes a (long) list of open questions= . This topic may not be a low-hanging fruit. Please have a look at the I-D and let me know any feedback. If there is interest, I could try to improve the document, possibly targeti= ng IETF 104 in Prague. Thanks Michael (obviously with chair hat off) -----Original Message----- From: I-D-Announce On Behalf Of internet-dr= afts@ietf.org Sent: Thursday, October 11, 2018 10:20 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-scharf-tcpm-yang-tcp-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Transmission Control Protocol (TCP) YANG Model Author : Michael Scharf Filename : draft-scharf-tcpm-yang-tcp-00.txt Pages : 22 Date : 2018-10-11 Abstract: This document specifies a base YANG model for TCP on devices that are configured by network management protocols. The YANG model follows the standard TCP-MIB [RFC4022]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-scharf-tcpm-yang-tcp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-scharf-tcpm-yang-tcp-00 https://datatracker.ietf.org/doc/html/draft-scharf-tcpm-yang-tcp-00 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt From nobody Thu Oct 18 07:58:58 2018 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 682AB12426A; Thu, 18 Oct 2018 07:58:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <153987472937.22306.7630356449161062661@ietfa.amsl.com> Date: Thu, 18 Oct 2018 07:58:49 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-converters-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 14:58:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. Title : 0-RTT TCP Convert Protocol Authors : Olivier Bonaventure Mohamed Boucadair Sri Gundavelli SungHoon Seo Filename : draft-ietf-tcpm-converters-03.txt Pages : 37 Date : 2018-10-18 Abstract: This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. This proxy is designed to avoid inducing extra delay when involved in a network-assisted connection (that is, 0-RTT). This specification assumes an explicit model, where the proxy is explicitly configured on hosts. -- Editorial Note (To be removed by RFC Editor) Please update these statements with the RFC number to be assigned to this document: [This-RFC] Please update TBA statements with the port number to be assigned to the Converter Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-converters-03 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-converters-03 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 Fri Oct 19 06:30:23 2018 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 890F3130EE7; Fri, 19 Oct 2018 06:30:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <153995582254.6513.12676705033550957254@ietfa.amsl.com> Date: Fri, 19 Oct 2018 06:30:22 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rto-consider-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 13:30:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. Title : Retransmission Timeout Requirements Author : Mark Allman Filename : draft-ietf-tcpm-rto-consider-06.txt Pages : 10 Date : 2018-10-19 Abstract: Ensuring reliable communication often manifests in a timeout and retry mechanism. Each implementation of a retransmission timeout mechanism represents a balance between correctness and timeliness and therefore no implementation suits all situations. This document provides high-level requirements for retransmission timeout schemes appropriate for general use in the Internet. Within the requirements, implementations have latitude to define particulars that best address each situation. Terminology The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-06 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rto-consider-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rto-consider-06 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 Fri Oct 19 06:44:54 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF85130EF2 for ; Fri, 19 Oct 2018 06:44:51 -0700 (PDT) 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 pTMamImSn_Xu for ; Fri, 19 Oct 2018 06:44:49 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2CD5130EEC for ; Fri, 19 Oct 2018 06:44:49 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id w9JDik4p007063 for ; Fri, 19 Oct 2018 06:44:46 -0700 (PDT) Received: from [192.168.1.207] (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 61D8EF425698 for ; Fri, 19 Oct 2018 09:44:49 -0400 (EDT) From: "Mark Allman" To: Extensions Date: Fri, 19 Oct 2018 09:44:49 -0400 X-Mailer: MailMate (1.12r5523) Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_F82B26E0-6C25-46EC-99F6-E3800C533AA6_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: [tcpm] new version of rto-consider X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 13:44:51 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_F82B26E0-6C25-46EC-99F6-E3800C533AA6_= Content-Type: text/plain Folks- I have been coaxed into trying the rto-consider document again. I just posted an update. It is draft-ietf-tcpm-rto-consider-06.txt. In the past, I think we haven't converged on this document because it is a bit weird and that makes the process less than straightforward. The document is sort of strange in that it tries to add requirements (a) where there haven't been any before, but (b) where we already have existing solutions. The biggest change in this version of the document is a new section (the current section 2), which tries to address this weirdness and set the context for the document and how it should be read. I have circulated this version to a few folks informally and the feedback I have received is "that helps". So, I'd now like to ask the broader community to take a look and see what you think. I look forward to your feedback. allman --=_MailMate_F82B26E0-6C25-46EC-99F6-E3800C533AA6_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCW8nf0REcbWFsbG1hbkBp Y2lyLm9yZwAKCRBbKutazjIizmSqAJ9PBwYSOwhUNdjC5c2OOSwwaIrfnQCeOAn2 UyWorq5zx4vMG0PIWzjrOpY= =JA4s -----END PGP SIGNATURE----- --=_MailMate_F82B26E0-6C25-46EC-99F6-E3800C533AA6_=-- From nobody Fri Oct 19 11:57:27 2018 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE16513109B; Fri, 19 Oct 2018 11:56:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: tcpm@ietf.org, ietf@kuehlewind.net X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153997538570.6592.12764840933281793203.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2018 11:56:25 -0700 Archived-At: Subject: [tcpm] tcpm - Requested sessions have been scheduled for IETF 103 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 18:56:33 -0000 Dear Yoshifumi Nishida, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tcpm Session 1 (2:00 requested) Monday, 5 November 2018, Afternoon Session II 1610-1810 Room Name: Meeting 1 size: 150 --------------------------------------------- tcpm Session 2 (1:00 requested) Tuesday, 6 November 2018, Morning Session II 1120-1220 Room Name: Chitlada 1 size: 300 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/103/sessions/tcpm.ics Request Information: --------------------------------------------------------- Working Group Name: TCP Maintenance and Minor Extensions Area Name: Transport Area Session Requester: Yoshifumi Nishida Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 80 Conflicts to Avoid: First Priority: iccrg tcpinc mptcp taps tsvarea tsvwg quic Second Priority: httpbis lwig rmcat teas Third Priority: rtcweb maprg panrg People who must be present: Yoshifumi Nishida Michael Tuexen Michael Scharf Mirja Kuehlewind Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Oct 22 05:17:47 2018 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E9F130E01; Mon, 22 Oct 2018 05:17:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <154021066636.15316.4153547423376762994@ietfa.amsl.com> Date: Mon, 22 Oct 2018 05:17:46 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-converters-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 12:17:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. Title : 0-RTT TCP Convert Protocol Authors : Olivier Bonaventure Mohamed Boucadair Sri Gundavelli SungHoon Seo Filename : draft-ietf-tcpm-converters-04.txt Pages : 39 Date : 2018-10-22 Abstract: This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. This proxy is designed to avoid inducing extra delay when involved in a network-assisted connection (that is, 0-RTT). This specification assumes an explicit model, where the proxy is explicitly configured on hosts. -- Editorial Note (To be removed by RFC Editor) Please update these statements with the RFC number to be assigned to this document: [This-RFC] Please update TBA statements with the port number to be assigned to the Converter Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-converters-04 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-converters-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-converters-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 Mon Oct 22 05:24:31 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1CF4130DFB; Mon, 22 Oct 2018 05:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 3moWYf1VZnWE; Mon, 22 Oct 2018 05:24:27 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8DBB127133; Mon, 22 Oct 2018 05:24:23 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 42dwgV0G5zz7vJY; Mon, 22 Oct 2018 14:24:22 +0200 (CEST) Received: from localhost.localdomain (unknown [127.0.0.1]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 42dwgT6nRhz5vN6; Mon, 22 Oct 2018 14:24:21 +0200 (CEST) Received: from opfedar07.bagnolet.francetelecom.fr by opfedar07.bagnolet.francetelecom.fr with queue id 736168-33; Mon, 22 Oct 2018 12:24:21 GMT Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 42dwgT69zqz5vN2; Mon, 22 Oct 2018 14:24:21 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0415.000; Mon, 22 Oct 2018 14:24:21 +0200 From: To: "philip.eardley@bt.com" , "tcpm@ietf.org" CC: "draft-ietf-tcpm-converters@ietf.org" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-converters-01.txt Thread-Index: AQHTtK4iDI+Mo6jxv0utHg3D/M2BoKQpg4TwgGLB2BCAoFPqwA== Date: Mon, 22 Oct 2018 12:24:20 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302E018535@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152027380186.14624.8843516061240272538@ietfa.amsl.com> <718b17025c25456490724ad442040422@rew09926dag03b.domain1.systemhost.net> <787AE7BB302AE849A7480A190F8B93302DF598FD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DF598FD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-converters-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 12:24:30 -0000 Hi Phil, all, FWIW, an updated version among what it was mentioned in my reply is availab= le online:=20 https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/=20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-converters-04 Cheers, Med > -----Message d'origine----- > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de > mohamed.boucadair@orange.com > Envoy=E9=A0: jeudi 12 juillet 2018 14:23 > =C0=A0: philip.eardley@bt.com; tcpm@ietf.org > Objet=A0: Re: [tcpm] I-D Action: draft-ietf-tcpm-converters-01.txt >=20 > Hi Phil, >=20 > Apologies of the delay to answer. >=20 > Thank you for sharing these comments. >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de > philip.eardley@bt.com > > Envoy=E9=A0: jeudi 10 mai 2018 17:51 > > =C0=A0: tcpm@ietf.org > > Objet=A0: Re: [tcpm] I-D Action: draft-ietf-tcpm-converters-01.txt > > > > Hi, > > > > I remember in the London discussion there were some comments about thin= gs > it > > would be good to add to the draft - mainly about more examples. I agree > with > > this, it would be useful I think to cover: > > > > - The example is for one client. I assume multiple clients each require > > their own Ipv6 address on the converter (ie which is the source address= for > > that client's converter-server(s) connections)? >=20 > [Med] This is deployment-specific. The converter may behave in address > sharing or address preservation modes. A text change is proposed here: > https://github.com/obonaventure/draft-tcp- > converters/pull/41/commits/de004090c1861f0f8b076285b4119d48f7ab47e8 >=20 > "The Converter may behave in address preservation or address sharing mode= s as > discussed in Section 5.4 of {{draft-nam-mptcp-deployment-considerations}}= . > Which behavior to use by a Converter is deployment-specific. If address > sharing mode is enabled, the Converter MUST adhere to REQ-2 of RFC6888 wh= ich > implies a default "IP address pooling" behavior of "Paired" (as defined i= n > Section 4.1 of [RFC4787]) must be supported. This behavior is meant to av= oid > breaking applications that depend on the external address remaining const= ant. > Also, maintaining the same external IP address for a client is meant to > preserve the validity of the TFO cookie." >=20 > > - How would the client access Ipv4 content? >=20 > [Med] We would like to avoid overloading the document with deployment- > specific examples. Plenty of those are described in draft-nam-mptcp- > deployment-considerations. We may add a pointer if needed. >=20 > > - I assume the client has to be configured somehow with the converter's > > address >=20 > [Med] Yes, we do have the following text in the draft: >=20 > This document assumes that a client is configured with one or a list > of Converters (e.g., [I-D.boucadair-tcpm-dhc-converter]). > Configuration means are outside the scope of this document. >=20 > > - What happens if the converter fails? I suppose the client has to > > somehow notice, and (at config time) it gets told the address for a bac= k-up > > converter or a DNS name. >=20 > [Med] I-D.boucadair-tcpm-dhc-converter specifies a procedure to provisio= n > one or multiple converters; each identified by a list of IP addresses. Th= e > procedure to follow for selecting the address to use will need to be > specified. Should we include it in draft-ietf-tcpm-converters or in I- > D.boucadair-tcpm-dhc-converter? I do prefer to leave that procedure out o= f > draft-ietf-tcpm-converters because the selection may not only be based on= the > availability of an address, but based on other criteria. >=20 > > - What happens if a link fails? I assume if one of the client-converter > > links fails, then MPTCP shifts all the traffic to the other path. >=20 > [Med] This is normal MPTCP behavior. Do we really need to say something > there? >=20 > If the > > converter-server connection fails, how does the client discover this? >=20 > [Med] This is done by means of the "Network Failure (65)" error code: >=20 > o Network Failure (65): This error indicates that the Converter is > experiencing a network failure to relay the request. >=20 > The Converter MUST send this error code when it experiences > forwarding issues to relay a connection. >=20 > I > > assume packets build up at the converter and are dropped, and at some p= oint > > the converter informs the client. > > > > Thanks, > > Best wishes, > > phil > > From nobody Mon Oct 22 07:07:50 2018 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C50130E48; Mon, 22 Oct 2018 07:07:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <154021725516.5714.283043041428080288@ietfa.amsl.com> Date: Mon, 22 Oct 2018 07:07:35 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-generalized-ecn-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 14:07:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. Title : ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets Authors : Marcelo Bagnulo Bob Briscoe Filename : draft-ietf-tcpm-generalized-ecn-03.txt Pages : 44 Date : 2018-10-22 Abstract: This document describes an experimental modification to ECN when used with TCP. It allows the use of ECN on the following TCP packets: SYNs, pure ACKs, Window probes, FINs, RSTs and retransmissions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-generalized-ecn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-03 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-generalized-ecn-03 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 Mon Oct 22 09:32:47 2018 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F910127333; Mon, 22 Oct 2018 09:32:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <154022595802.5440.1182772928129617316@ietfa.amsl.com> Date: Mon, 22 Oct 2018 09:32:38 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-11.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 16:32:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. Title : Transmission Control Protocol Specification Author : Wesley M. Eddy Filename : draft-ietf-tcpm-rfc793bis-11.txt Pages : 104 Date : 2018-10-22 Abstract: This document specifies the Internet's Transmission Control Protocol (TCP). TCP is an important transport layer protocol in the Internet stack, and has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFC 1122, and should be considered as a replacement for the portions of that document dealing with TCP requirements. It updates RFC 5961 due to a small clarification in reset handling while in the SYN-RECEIVED state. RFC EDITOR NOTE: If approved for publication as an RFC, this should be marked additionally as "STD: 7" and replace RFC 793 in that role. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-11 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-11 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 Thu Oct 25 10:53:08 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780F0130DE5; Thu, 25 Oct 2018 10:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QFLNKQY1msLO; Thu, 25 Oct 2018 10:53:04 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7F2F1277D2; Thu, 25 Oct 2018 10:53:03 -0700 (PDT) Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 1799927894A; Fri, 26 Oct 2018 02:53:01 +0900 (JST) Received: by mail-ot1-f53.google.com with SMTP id u26so8838791otk.13; Thu, 25 Oct 2018 10:53:01 -0700 (PDT) X-Gm-Message-State: AGRZ1gJPW1kLWHectTjoddl3Tj3hQhPiHbVlT6UTsAB1CHxPmoncPOj8 UyScByvfGJCj3s+HCE/0/GHOG9VPudLBh+tTfOA= X-Google-Smtp-Source: AJdET5frn7DJbjE3DiJKLLSazOa96jiJQQ3/FMZc5exSzc8flrnKYDbv2aCTDYRe8MzhzROfYbIV6XEz1rxl20EdFLk= X-Received: by 2002:a9d:2084:: with SMTP id x4mr131504ota.111.1540489979648; Thu, 25 Oct 2018 10:52:59 -0700 (PDT) MIME-Version: 1.0 From: Yoshifumi Nishida Date: Thu, 25 Oct 2018 10:52:47 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "tcpm@ietf.org" Cc: "tcpm-chairs@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [tcpm] meeting agenda has been uploaded X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 17:53:07 -0000 Hi, I have uploaded the current agedan on https://tools.ietf.org/wg/tcpm/agenda As we mentioned before, we will have two slots at Bangkok. The first one (Monday afternoon) is our usual WG meeting. The second one (Tuesday morning) is dedicated for discussions on congestion control and loss mechanisms in QUIC and TCP. Also, it seems we still have some extra time for our usual WG meeting. If you still want to present something, please contact the chairs. Please let us know if you have questions or suggestions. Thanks! -- Yoshi From nobody Sun Oct 28 20:02:59 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C4712F1A6; Sun, 28 Oct 2018 20:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CvJ0Dj1i4b6T; Sun, 28 Oct 2018 20:02:55 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D0A71286D9; Sun, 28 Oct 2018 20:02:54 -0700 (PDT) Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com [209.85.167.182]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 0E934278593; Mon, 29 Oct 2018 12:02:52 +0900 (JST) Received: by mail-oi1-f182.google.com with SMTP id k64-v6so5748443oia.13; Sun, 28 Oct 2018 20:02:51 -0700 (PDT) X-Gm-Message-State: AGRZ1gKHwoef2yTL10LA7RWzbk2OxTJojKMkA7HKsVc7HuFrL5DnH4wm 8/ob+PBAN09L8NKBuVgNHtp/MjS7/MPkB39lSUI= X-Google-Smtp-Source: AJdET5dtDgApD09BCQHAabAPyVXQjg8lcmaEB6cSAbcPLi21hzAjBvtD3SpIlavXthqbftKKFerTaufbxReSAPUgkS0= X-Received: by 2002:a54:4390:: with SMTP id u16-v6mr7728264oiv.186.1540782170678; Sun, 28 Oct 2018 20:02:50 -0700 (PDT) MIME-Version: 1.0 References: <26ed385e2f00a41e717a9d4b4043f9b9.squirrel@webmail.entel.upc.edu> In-Reply-To: <26ed385e2f00a41e717a9d4b4043f9b9.squirrel@webmail.entel.upc.edu> From: Yoshifumi Nishida Date: Sun, 28 Oct 2018 20:02:38 -0700 X-Gmail-Original-Message-ID: Message-ID: To: carlesgo@entel.upc.edu Cc: "tcpm@ietf.org" , lwip@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] [Fwd: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-04.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 03:02:58 -0000 Hello, I've read the draft and I think the draft looks fine and mostly ready. I have some comments below.. 1: Section 4.2.4: "In that case, RTO algorithm tuning may be considered, although careful assessment of possible drawbacks is recommended" -> It might be better if we refer draft-ietf-tcpm-rto-consider here although it is not very certain the draft will be published at this moment? It seems to me the motivation of the doc fits the situation like this. 2: Section 4.3.1: "These algorithms work efficiently for window size of at least 5 MSS" -> Just curious why this is 5? Is it because the use of delayed ack is presumed? A receiver may have a chance to send an ack for segment 1 before segment 3 arrives. 3: Section 5.3 CCN -> CNN? "This overhead could be reduced by TCP Fast Open (TFO)" -> Yes, but the use of TLS is not mandatory in this draft. If an implementation utilizes TFO, we might want to mention about app level idempotency here. "TCP keep-alive messages are not very useful to..." -> We don't need to discuss reducing the interval of keep-alive here? Thanks, -- Yoshi On Mon, Oct 8, 2018 at 10:47 PM Carles Gomez Montenegro wrote: > > Dear LWIG and TCPM WGs, > > As you can see below, we have updated the "TCP Usage Guidance in the > Internet of Things (IoT)" draft. > > This revision intends to address previously pending TODOs, as well as > comments from the LWIG session in Montreal. > > As you may recall, we are getting ready for requesting a WGLC. Your > comments will be most welcome. > > Thanks, > > Carles (on behalf of all authors) > > > ---------------------------- Original Message ---------------------------- > Subject: [Lwip] I-D Action: > draft-ietf-lwig-tcp-constrained-node-networks-04.txt > From: internet-drafts@ietf.org > Date: Tue, October 9, 2018 7:30 am > To: i-d-announce@ietf.org > Cc: lwip@ietf.org > -------------------------------------------------------------------------- > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Light-Weight Implementation Guidance WG > of the IETF. > > Title : TCP Usage Guidance in the Internet of Things (IoT) > Authors : Carles Gomez > Jon Crowcroft > Michael Scharf > Filename : draft-ietf-lwig-tcp-constrained-node-networks-04.txt > Pages : 25 > Date : 2018-10-08 > > Abstract: > This document provides guidance on how to implement and use the > Transmission Control Protocol (TCP) in Constrained-Node Networks > (CNNs), which are a characterstic of the Internet of Things (IoT). > Such environments require a lightweight TCP implementation and may > not make use of optional functionality. This document explains a > number of known and deployed techniques to simplify a TCP stack as > well as corresponding tradeoffs. The objective is to help embedded > developers with decisions on which TCP features to use. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-04 > https://datatracker.ietf.org/doc/html/draft-ietf-lwig-tcp-constrained-node-networks-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-tcp-constrained-node-networks-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/ > > _______________________________________________ > Lwip mailing list > Lwip@ietf.org > https://www.ietf.org/mailman/listinfo/lwip > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Oct 29 10:02:37 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6421813101F; Mon, 29 Oct 2018 10:02:35 -0700 (PDT) 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, 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 t734ml4oYQrr; Mon, 29 Oct 2018 10:02:32 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 725B5131011; Mon, 29 Oct 2018 10:02:32 -0700 (PDT) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 265D7278576; Tue, 30 Oct 2018 02:02:30 +0900 (JST) Received: by mail-ot1-f41.google.com with SMTP id q5so2814594otl.13; Mon, 29 Oct 2018 10:02:30 -0700 (PDT) X-Gm-Message-State: AGRZ1gJ5cQ73fX2Qk/cEfSiAiTA26YDwwUI+o15oUmxoFB0TlopWX3rj udA77W2kO8H3vCNk4Le70T8eQAnKYpi8ORZH1kg= X-Google-Smtp-Source: AJdET5cfPzSHL2LhxraGNxr+KRuTeK0Y8B1qSV1PEP3yhprcQY1XGr8k7Fn/gAEMb2PmtDtq7LTtmpA4W+Y2V4oNmNY= X-Received: by 2002:a9d:2084:: with SMTP id x4mr8497711ota.111.1540832547884; Mon, 29 Oct 2018 10:02:27 -0700 (PDT) MIME-Version: 1.0 From: Yoshifumi Nishida Date: Mon, 29 Oct 2018 10:02:15 -0700 X-Gmail-Original-Message-ID: Message-ID: To: quic@ietf.org, "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [tcpm] questions on draft-ietf-quic-recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 17:02:35 -0000 Hello, At Bangkok, TCPM WG will have a session to discuss loss recovery and congestion control mechanism in QUIC and TCP. (11/6 Tuesday 11:20-12:20) I really appreciate Ian and Jana for the efforts. I might overlook something as I couldn't follow up all discussion in QUIC, but I am thinking that it might be good if we could get some comments on the following questions. I have listed several questions on the value of some parameters, but it doesn't mean I disagree with these values. I just would like to check where these values came from. Hope this will be useful in some ways. Section 4: QUIC supports both ack and timer for loss detection. But, it's not very clear whether an implementation can choose one of them or it should implement both and can use both at the same time. Can it be clarified? Section 4.1.1: For RTT sampling, implementations will need to maintain the transmission time for each sending packets even if they support only ack-based method. But, this requirement might be hard for tiny devices. Wouldn't it limit the applicability of QUIC? "the largest newly acked packet" might be confusing. packet that acks the largest packet number? Section 4.2.1: TCP RACK's reo_wnd is aiming to be 1/4 RTT. Why QUIC uses 1/8 RTT? Section 4.2.2: The early retransmit logic in QUIC seems to be different from TCP's one. It doesn't look ack-based as it relies on timer. (I don't say this is bad, but it's a bit strange to categorize it as an ack-based method) TCP's early retransmit will be triggered only when the amount of outstanding data is less than 4*SMSS, but this draft doesn't mention about the condition. Is there any reason for it? when timer-based loss detection is used, it this logic still available? or it won't be used with timer-based loss detection? We might need clarifications here. Section 4.3.2: TCP RACK's PTO is aiming to be 2 * SRTT. Why QUIC uses 1.5 * SRTT? Section 4.3.3: RFC5681 uses 1 SMSS as the size of loss window, while QUIC uses 2. I understand the motivation to reduce the possibility of consecutive RTO events. But, this may means when TCP and QUIC connections are under heavy congestion, QUIC connections will recover more quickly than TCP connections. We might want to think how much QUIC and TCP should be fair. BTW, it might not be necessarily, but QUIC does not need the upper bound for RTO? Section 4.4: why the default value of max_ack_delay is 25ms? Section 4.5.7.3: Sorry.. what is 1/4 RTT timer for early retransmit? Section 5.8.1: Why the recommended value is 1200 bytes? From nobody Mon Oct 29 17:45:15 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E504131001 for ; Mon, 29 Oct 2018 17:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.97 X-Spam-Level: X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 EB2pGV_bIuwF for ; Mon, 29 Oct 2018 17:45:11 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51D7F12426A for ; Mon, 29 Oct 2018 17:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4747; q=dns/txt; s=iport; t=1540860311; x=1542069911; h=from:to:subject:date:message-id:mime-version; bh=66TL2KHR9cLcMDGZOKa4+fbIUfF5u9xHx9c6O1L12yA=; b=ciTCZ0GCpQvHftoTVlXnF2+cRDCjIw8Jsrd0sKHMv7OTUy1EdsBRFLCP /ApHr6u0T/6nwht08iuiGbQvG/Y0VfEGbYdYR5+63xiEj8bonF7mD77Do v7/WcTs/GcJ2ppdN0qkHRw3T91hplvsCO4BMy7vDMf4mtnEBPAlv3j2iY 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A/AACcqNdb/5RdJa1kHAEBAQQBAQc?= =?us-ascii?q?EAQGBUgYBAQsBgQ13Zn8ymByTYoVLgXoLAQGIGyE1DA0BAwEBAgEBAm0dC4V?= =?us-ascii?q?uXgGBACYBBBuDGoEdZKsxiiKLSR4XgUE/hHyKAAKOSoYiiUlUCQKQeiCQR5Z?= =?us-ascii?q?1AhEUgSYfAzOBVXAVgyiCJAEXjhqMdYEfAQE?= X-IronPort-AV: E=Sophos;i="5.54,442,1534809600"; d="scan'208,217";a="471104265" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2018 00:45:10 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id w9U0jAj6017516 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 30 Oct 2018 00:45:10 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 29 Oct 2018 19:45:09 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1395.000; Mon, 29 Oct 2018 19:45:09 -0500 From: "Jakob Heitz (jheitz)" To: "tcpm@ietf.org" Thread-Topic: public-private keys for TCP-AO Thread-Index: AdRv51Oca8SVyggpTLame1T3B/a0kQ== Date: Tue, 30 Oct 2018 00:45:09 +0000 Message-ID: <95f4b81948844b2799ecca33450bdde1@XCH-ALN-014.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.161.174] Content-Type: multipart/alternative; boundary="_000_95f4b81948844b2799ecca33450bdde1XCHALN014ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.23, xch-aln-013.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: [tcpm] public-private keys for TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 00:45:13 -0000 --_000_95f4b81948844b2799ecca33450bdde1XCHALN014ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Why was there not a public-private key algorithm specified for TCP-AO? Or d= id I miss it? For example ECC. An MKT can specify a private key for the sender and a public key for the re= ceivers. To use, the sender will hash the data, encrypt the hash and put the result = into the MAC field. The receiver would decrypt the MAC field, then hash the data and verify the= hash against the decrypted MAC. This way, the private key never needs to be exposed to anyone, simplifying = key management. Is there any objection to getting this done? Regards, Jakob. --_000_95f4b81948844b2799ecca33450bdde1XCHALN014ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Why was there not a public-private key= algorithm specified for TCP-AO? Or did I miss it?

For example ECC.

An MKT can specify a private key for t= he sender and a public key for the receivers.

To use, the sender will hash the data,= encrypt the hash and put the result into the MAC field.<= /p>

The receiver would decrypt the MAC fie= ld, then hash the data and verify the hash against the decrypted MAC.<= /o:p>

This way, the private key never needs = to be exposed to anyone, simplifying key management.

Is there any objection to getting this= done?

 

Regards,

Jakob.

 

--_000_95f4b81948844b2799ecca33450bdde1XCHALN014ciscocom_-- From nobody Mon Oct 29 18:13:25 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEB51288BD for ; Mon, 29 Oct 2018 18:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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] 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 7ffe59E9ooH1 for ; Mon, 29 Oct 2018 18:13:20 -0700 (PDT) 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 43CC5130F58 for ; Mon, 29 Oct 2018 18:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type: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=4zmZYRrpMrAeY/1m2BGXtAuVP3oAjSV+oRAGgIBRtvw=; b=QWrDbzfr91Y0gXWG0iP8uHaFX gFiG67p1d7bKcdUrFRu2CN7eMAoFI8pCime1PBY0itqhOVg3QD3DaulKFtUeUQAtnXmkZHOnjwX4O Z63NJIydDrvw09EyXcOFekt4yXqG79qHLd8JgHV4wwUt3/8HH0zAxvLu8xgWnehn7Mh6XCb/dBl2S AlfjRHEL6pRIU2cW2YHjUAZxSK6b5ybiatvhmbZQ4/jcyjRzDojj9e7SE0BoXnQO5EYPixo19MN3s DsBGdCUBwv7ZabljSrrdaXxm4QLI8kq+I2ZbZE/kZR3WSRmaSPl4eGZcCPUTYF/2QOpgDF+UI2WEn XSSQYJorA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:54728 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gHIao-001dgg-CK; Mon, 29 Oct 2018 21:13:17 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_86396AA9-E0C9-492E-8697-4B55CCD64A0C" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: <95f4b81948844b2799ecca33450bdde1@XCH-ALN-014.cisco.com> Date: Mon, 29 Oct 2018 18:13:13 -0700 Cc: "tcpm@ietf.org" Message-Id: References: <95f4b81948844b2799ecca33450bdde1@XCH-ALN-014.cisco.com> To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.3445.9.1) 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: Subject: Re: [tcpm] public-private keys for TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 01:13:23 -0000 --Apple-Mail=_86396AA9-E0C9-492E-8697-4B55CCD64A0C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 29, 2018, at 5:45 PM, Jakob Heitz (jheitz) = wrote: >=20 > Why was there not a public-private key algorithm specified for TCP-AO? = Or did I miss it? There has not been. I doubt it would make sense (see below). > For example ECC. > An MKT can specify a private key for the sender and a public key for = the receivers. Yes, but the MKT is derived into public/private keys using a KDF. I am not aware of a KDF that can take a private key and generate a = derived private key that would work with a correspondingly derived = public key generated from the corresponding public key. > To use, the sender will hash the data, encrypt the hash and put the = result into the MAC field. > The receiver would decrypt the MAC field, then hash the data and = verify the hash against the decrypted MAC. > This way, the private key never needs to be exposed to anyone, = simplifying key management. > Is there any objection to getting this done? See above; it doesn=E2=80=99t make sense with the way TCP-AO derives = keys for each connection, AFAICT. Joe > =20 > Regards, > Jakob. > =20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = --Apple-Mail=_86396AA9-E0C9-492E-8697-4B55CCD64A0C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 29, 2018, at 5:45 PM, Jakob Heitz (jheitz) <jheitz@cisco.com> = wrote:

Why was there not a public-private = key algorithm specified for TCP-AO? Or did I miss = it?

There has not been. I doubt it would make sense = (see below).

For example = ECC.
An MKT can = specify a private key for the sender and a public key for the = receivers.

Yes, but the MKT is derived into public/private = keys using a KDF.

I am not aware of = a KDF that can take a private key and generate a derived private key = that would work with a correspondingly derived public key generated from = the corresponding public key.

To use, the = sender will hash the data, encrypt the hash and put the result into the = MAC field.
The receiver = would decrypt the MAC field, then hash the data and verify the hash = against the decrypted MAC.
This way, the private key never needs to be exposed to = anyone, simplifying key management.
Is there any objection to getting this = done?

See = above; it doesn=E2=80=99t make sense with the way TCP-AO derives keys = for each connection, AFAICT.

Joe

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

= --Apple-Mail=_86396AA9-E0C9-492E-8697-4B55CCD64A0C-- From nobody Mon Oct 29 18:22:24 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4E11288BD for ; Mon, 29 Oct 2018 18:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 R1lWU-GASROy for ; Mon, 29 Oct 2018 18:22:20 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3F1912870E for ; Mon, 29 Oct 2018 18:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16424; q=dns/txt; s=iport; t=1540862540; x=1542072140; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GN66AJOY99fycJz6ltOU2yASku73T16vkt2oEycfrqk=; b=DprhupXZK1U58v5kRr3jZJ+dmlf2+soH/uPY+3N3/aKw79SLavHhe1aw 8scXq4q1WEEUREbR1DTkBaG0LvtBnocV+d2573j6DLQDZMm6dX10sST99 bhNxYx18K1RO2khw3DIgULwfGv8tG7uvr5NwU4hQBTDKzK0EJd49XrRll g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAACYsddb/5xdJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDUgvZn8oCoNriBiMGYINkVWFS4F6CwEBGAE?= =?us-ascii?q?KhEkCF4MWITQNDQEDAQECAQECbRwMhToBAQEBAwEBIQpBCxACAQgRBAEBKAM?= =?us-ascii?q?CAgIlCxQJCAEBBA4FCIMagR1kD6lygS6KHQWLSR4XgUE/hCNZgkIBAYIXgk6?= =?us-ascii?q?CVwKOSoYiiUlUCQKQeiCNZoJhlnUCERSBJh04gVVwFTuCbIIlAReIXIU+b4w?= =?us-ascii?q?GgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,442,1534809600"; d="scan'208,217";a="193457499" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2018 01:22:18 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id w9U1MIn1002240 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Oct 2018 01:22:18 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 29 Oct 2018 20:22:17 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1395.000; Mon, 29 Oct 2018 20:22:17 -0500 From: "Jakob Heitz (jheitz)" To: Joe Touch CC: "tcpm@ietf.org" Thread-Topic: [tcpm] public-private keys for TCP-AO Thread-Index: AdRv51Oca8SVyggpTLame1T3B/a0kQAME/iAAApbkFA= Date: Tue, 30 Oct 2018 01:22:17 +0000 Message-ID: <7597333b9a414761be688375acf48dd6@XCH-ALN-014.cisco.com> References: <95f4b81948844b2799ecca33450bdde1@XCH-ALN-014.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.161.174] Content-Type: multipart/alternative; boundary="_000_7597333b9a414761be688375acf48dd6XCHALN014ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.22, xch-aln-012.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [tcpm] public-private keys for TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 01:22:22 -0000 --_000_7597333b9a414761be688375acf48dd6XCHALN014ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2FuIHlvdSB0aGluayBvZiBhIHdheSB0byBkbyBpdCB0aGF0IHdpbGwgd29yaz8NCkxpa2UgdGhl IEtERiBpcyBqdXN0IGEgc3RhdGljIGxpc3Qgb3Igc29tZXRoaW5nLg0KVGhlIHNlbmRlciBnZW5l cmF0ZXMgYSBzZXQgb2Yga2V5IHBhaXJzIGFuZCBudW1iZXJzIHRoZW0uDQpJdCB0aGVuIHB1dHMg dGhlIGxpc3Qgb2YgcHVibGljIGtleXMgaW50byBhIGZpbGUgYW5kIGRpc3RyaWJ1dGVzIHRoZW0g dG8gYWxsIHJlY2VpdmVycyBpbiB0aGUgY2xlYXIuDQpUaGUgS0RGIGlzIGp1c3QgdG8gaW5kZXgg aW50byB0aGlzIGZpbGUuDQoNCkJlY2F1c2UgdGhlIHVzZSBjYXNlLCBhdCBsZWFzdCwgbWFrZXMg c2Vuc2UuDQoNClJlZ2FyZHMsDQpKYWtvYi4NCg0KRnJvbTogSm9lIFRvdWNoIDx0b3VjaEBzdHJh eWFscGhhLmNvbT4NClNlbnQ6IE1vbmRheSwgT2N0b2JlciAyOSwgMjAxOCA2OjEzIFBNDQpUbzog SmFrb2IgSGVpdHogKGpoZWl0eikgPGpoZWl0ekBjaXNjby5jb20+DQpDYzogdGNwbUBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFt0Y3BtXSBwdWJsaWMtcHJpdmF0ZSBrZXlzIGZvciBUQ1AtQU8NCg0K DQoNCg0KT24gT2N0IDI5LCAyMDE4LCBhdCA1OjQ1IFBNLCBKYWtvYiBIZWl0eiAoamhlaXR6KSA8 amhlaXR6QGNpc2NvLmNvbTxtYWlsdG86amhlaXR6QGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpXaHkg d2FzIHRoZXJlIG5vdCBhIHB1YmxpYy1wcml2YXRlIGtleSBhbGdvcml0aG0gc3BlY2lmaWVkIGZv ciBUQ1AtQU8/IE9yIGRpZCBJIG1pc3MgaXQ/DQoNClRoZXJlIGhhcyBub3QgYmVlbi4gSSBkb3Vi dCBpdCB3b3VsZCBtYWtlIHNlbnNlIChzZWUgYmVsb3cpLg0KDQoNCkZvciBleGFtcGxlIEVDQy4N CkFuIE1LVCBjYW4gc3BlY2lmeSBhIHByaXZhdGUga2V5IGZvciB0aGUgc2VuZGVyIGFuZCBhIHB1 YmxpYyBrZXkgZm9yIHRoZSByZWNlaXZlcnMuDQoNClllcywgYnV0IHRoZSBNS1QgaXMgZGVyaXZl ZCBpbnRvIHB1YmxpYy9wcml2YXRlIGtleXMgdXNpbmcgYSBLREYuDQoNCkkgYW0gbm90IGF3YXJl IG9mIGEgS0RGIHRoYXQgY2FuIHRha2UgYSBwcml2YXRlIGtleSBhbmQgZ2VuZXJhdGUgYSBkZXJp dmVkIHByaXZhdGUga2V5IHRoYXQgd291bGQgd29yayB3aXRoIGEgY29ycmVzcG9uZGluZ2x5IGRl cml2ZWQgcHVibGljIGtleSBnZW5lcmF0ZWQgZnJvbSB0aGUgY29ycmVzcG9uZGluZyBwdWJsaWMg a2V5Lg0KDQpUbyB1c2UsIHRoZSBzZW5kZXIgd2lsbCBoYXNoIHRoZSBkYXRhLCBlbmNyeXB0IHRo ZSBoYXNoIGFuZCBwdXQgdGhlIHJlc3VsdCBpbnRvIHRoZSBNQUMgZmllbGQuDQpUaGUgcmVjZWl2 ZXIgd291bGQgZGVjcnlwdCB0aGUgTUFDIGZpZWxkLCB0aGVuIGhhc2ggdGhlIGRhdGEgYW5kIHZl cmlmeSB0aGUgaGFzaCBhZ2FpbnN0IHRoZSBkZWNyeXB0ZWQgTUFDLg0KVGhpcyB3YXksIHRoZSBw cml2YXRlIGtleSBuZXZlciBuZWVkcyB0byBiZSBleHBvc2VkIHRvIGFueW9uZSwgc2ltcGxpZnlp bmcga2V5IG1hbmFnZW1lbnQuDQpJcyB0aGVyZSBhbnkgb2JqZWN0aW9uIHRvIGdldHRpbmcgdGhp cyBkb25lPw0KDQpTZWUgYWJvdmU7IGl0IGRvZXNu4oCZdCBtYWtlIHNlbnNlIHdpdGggdGhlIHdh eSBUQ1AtQU8gZGVyaXZlcyBrZXlzIGZvciBlYWNoIGNvbm5lY3Rpb24sIEFGQUlDVC4NCg0KSm9l DQoNCg0KDQpSZWdhcmRzLA0KSmFrb2IuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQp0Y3BtIG1haWxpbmcgbGlzdA0KdGNwbUBpZXRmLm9yZzxtYWls dG86dGNwbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dGNwbQ0KDQo= --_000_7597333b9a414761be688375acf48dd6XCHALN014ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIg MSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IlxARGVuZ1hpYW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRp di5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7 DQoJY29sb3I6IzcwMzBBMDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBB MCI+Q2FuIHlvdSB0aGluayBvZiBhIHdheSB0byBkbyBpdCB0aGF0IHdpbGwgd29yaz88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xv cjojNzAzMEEwIj5MaWtlIHRoZSBLREYgaXMganVzdCBhIHN0YXRpYyBsaXN0IG9yIHNvbWV0aGlu Zy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oyxz ZXJpZjtjb2xvcjojNzAzMEEwIj5UaGUgc2VuZGVyIGdlbmVyYXRlcyBhIHNldCBvZiBrZXkgcGFp cnMgYW5kIG51bWJlcnMgdGhlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5JdCB0aGVuIHB1dHMgdGhlIGxp c3Qgb2YgcHVibGljIGtleXMgaW50byBhIGZpbGUgYW5kIGRpc3RyaWJ1dGVzIHRoZW0gdG8gYWxs IHJlY2VpdmVycyBpbiB0aGUgY2xlYXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+VGhlIEtERiBpcyBqdXN0 IHRvIGluZGV4IGludG8gdGhpcyBmaWxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9y OiM3MDMwQTAiPkJlY2F1c2UgdGhlIHVzZSBjYXNlLCBhdCBsZWFzdCwgbWFrZXMgc2Vuc2UuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7 Y29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPlJlZ2FyZHMsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7 Y29sb3I6IzcwMzBBMCI+SmFrb2IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gSm9lIFRvdWNoICZsdDt0b3VjaEBzdHJheWFscGhhLmNvbSZndDsNCjxi cj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE9jdG9iZXIgMjksIDIwMTggNjoxMyBQTTxicj4NCjxi PlRvOjwvYj4gSmFrb2IgSGVpdHogKGpoZWl0eikgJmx0O2poZWl0ekBjaXNjby5jb20mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiB0Y3BtQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdGNw bV0gcHVibGljLXByaXZhdGUga2V5cyBmb3IgVENQLUFPPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBPY3QgMjksIDIwMTgsIGF0IDU6NDUgUE0sIEpha29iIEhl aXR6IChqaGVpdHopICZsdDs8YSBocmVmPSJtYWlsdG86amhlaXR6QGNpc2NvLmNvbSI+amhlaXR6 QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+V2h5IHdhcyB0aGVy ZSBub3QgYSBwdWJsaWMtcHJpdmF0ZSBrZXkgYWxnb3JpdGhtIHNwZWNpZmllZCBmb3IgVENQLUFP PyBPciBkaWQgSSBtaXNzIGl0Pzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGVyZSBoYXMgbm90IGJlZW4uIEkgZG91YnQgaXQgd291bGQgbWFrZSBz ZW5zZSAoc2VlIGJlbG93KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+Rm9yIGV4YW1wbGUg RUNDLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMw QTAiPkFuIE1LVCBjYW4gc3BlY2lmeSBhIHByaXZhdGUga2V5IGZvciB0aGUgc2VuZGVyIGFuZCBh IHB1YmxpYyBrZXkgZm9yIHRoZSByZWNlaXZlcnMuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgYnV0IHRoZSBNS1QgaXMgZGVyaXZlZCBpbnRv IHB1YmxpYy9wcml2YXRlIGtleXMgdXNpbmcgYSBLREYuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gbm90IGF3YXJlIG9mIGEgS0RGIHRo YXQgY2FuIHRha2UgYSBwcml2YXRlIGtleSBhbmQgZ2VuZXJhdGUgYSBkZXJpdmVkIHByaXZhdGUg a2V5IHRoYXQgd291bGQgd29yayB3aXRoIGEgY29ycmVzcG9uZGluZ2x5IGRlcml2ZWQgcHVibGlj IGtleSBnZW5lcmF0ZWQgZnJvbSB0aGUgY29ycmVzcG9uZGluZyBwdWJsaWMga2V5LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5UbyB1c2UsIHRoZSBzZW5kZXIgd2lsbCBoYXNo IHRoZSBkYXRhLCBlbmNyeXB0IHRoZSBoYXNoIGFuZCBwdXQgdGhlIHJlc3VsdCBpbnRvIHRoZSBN QUMgZmllbGQuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6 IzcwMzBBMCI+VGhlIHJlY2VpdmVyIHdvdWxkIGRlY3J5cHQgdGhlIE1BQyBmaWVsZCwgdGhlbiBo YXNoIHRoZSBkYXRhIGFuZCB2ZXJpZnkgdGhlIGhhc2ggYWdhaW5zdCB0aGUgZGVjcnlwdGVkIE1B Qy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEw Ij5UaGlzIHdheSwgdGhlIHByaXZhdGUga2V5IG5ldmVyIG5lZWRzIHRvIGJlIGV4cG9zZWQgdG8g YW55b25lLCBzaW1wbGlmeWluZyBrZXkgbWFuYWdlbWVudC48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5JcyB0aGVyZSBhbnkgb2JqZWN0aW9u IHRvIGdldHRpbmcgdGhpcyBkb25lPzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlNlZSBhYm92ZTsgaXQgZG9lc27igJl0IG1ha2Ugc2Vuc2Ugd2l0aCB0aGUgd2F5 IFRDUC1BTyBkZXJpdmVzIGtleXMgZm9yIGVhY2ggY29ubmVjdGlvbiwgQUZBSUNULjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2U8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPlJlZ2FyZHMsPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+SmFrb2IuPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdGNwbSBt YWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk1NEY3MiI+dGNwbUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdGNwbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTU0RjcyIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG08L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7597333b9a414761be688375acf48dd6XCHALN014ciscocom_-- From nobody Mon Oct 29 18:36:56 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5234512872C for ; Mon, 29 Oct 2018 18:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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] 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 LDJ4VjorulYI for ; Mon, 29 Oct 2018 18:36:52 -0700 (PDT) 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 C5BB51274D0 for ; Mon, 29 Oct 2018 18:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type: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=T7e7LN9GuWNwaclUjUTfGoXL9mHaz1T+W6MlN+vpfWc=; b=bvR13/ONa0AvHrzthfUybFoml K78ljlclSUHPe+RinAVjRjbVn4ZSRKO7Pp58FMHY3YKbOZFRt6EVJSd2BugkpXjuX/FEh4rOwEBkB K9uREi3Ikfcbq5qEg1BWIfKPgQpcLCFVAX098sw/QH/UH4Cx3eDLb8ZR6C7wMG/jlLQNovbjFX5D9 c/GNS2Cd0MjXNlQ0dpEZTxE/AXjh5wo+hWF6TG1/gbHFHzcCrlzPlBuBw8BheAgzAGgDDHXY4lY6L erNHgprLA5shI1PicMw/Mnzo+fnNIvuOOlAfwqLNe8p4mI8IKYwcOq6ia65qAT0BF21CEngy6uFez MxZ/FZ8UA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:55525 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gHIxc-001uwv-AR; Mon, 29 Oct 2018 21:36:50 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_8E0F86C3-02D7-40B8-A508-E78AB7CA5324" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: <7597333b9a414761be688375acf48dd6@XCH-ALN-014.cisco.com> Date: Mon, 29 Oct 2018 18:36:47 -0700 Cc: "tcpm@ietf.org" Message-Id: <0C168054-E3D6-4BC5-9E1E-A28059F1A27B@strayalpha.com> References: <95f4b81948844b2799ecca33450bdde1@XCH-ALN-014.cisco.com> <7597333b9a414761be688375acf48dd6@XCH-ALN-014.cisco.com> To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.3445.9.1) 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: Subject: Re: [tcpm] public-private keys for TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 01:36:54 -0000 --Apple-Mail=_8E0F86C3-02D7-40B8-A508-E78AB7CA5324 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 29, 2018, at 6:22 PM, Jakob Heitz (jheitz) = wrote: >=20 > Can you think of a way to do it that will work? > Like the KDF is just a static list or something. > The sender generates a set of key pairs and numbers them. > It then puts the list of public keys into a file and distributes them = to all receivers in the clear. You=E2=80=99d have to find a way to specify the use of private and = public keys on both sides, in advance, and distribute enough for the = upcoming connections - then you=E2=80=99d have to hash into that list in = a way that avoids reuse. At that point, why not just distribute = symmetric keys and be done with it? Joe > The KDF is just to index into this file. > =20 > Because the use case, at least, makes sense. > =20 > Regards, > Jakob. > =20 > From: Joe Touch =20 > Sent: Monday, October 29, 2018 6:13 PM > To: Jakob Heitz (jheitz) > Cc: tcpm@ietf.org > Subject: Re: [tcpm] public-private keys for TCP-AO > =20 > =20 >=20 >=20 > On Oct 29, 2018, at 5:45 PM, Jakob Heitz (jheitz) > wrote: > =20 > Why was there not a public-private key algorithm specified for TCP-AO? = Or did I miss it? > =20 > There has not been. I doubt it would make sense (see below). >=20 >=20 > For example ECC. > An MKT can specify a private key for the sender and a public key for = the receivers. > =20 > Yes, but the MKT is derived into public/private keys using a KDF. > =20 > I am not aware of a KDF that can take a private key and generate a = derived private key that would work with a correspondingly derived = public key generated from the corresponding public key. > =20 > To use, the sender will hash the data, encrypt the hash and put the = result into the MAC field. > The receiver would decrypt the MAC field, then hash the data and = verify the hash against the decrypted MAC. > This way, the private key never needs to be exposed to anyone, = simplifying key management. > Is there any objection to getting this done? > =20 > See above; it doesn=E2=80=99t make sense with the way TCP-AO derives = keys for each connection, AFAICT. > =20 > Joe >=20 >=20 > =20 > Regards, > Jakob. > =20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = > =20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_8E0F86C3-02D7-40B8-A508-E78AB7CA5324 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 29, 2018, at 6:22 PM, Jakob Heitz (jheitz) <jheitz@cisco.com> = wrote:

Can you think of = a way to do it that will work?
Like the KDF is just a static list or something.
The sender = generates a set of key pairs and numbers them.
It then puts the = list of public keys into a file and distributes them to all receivers in = the clear.

You=E2=80=99d have to find a way to specify the = use of private and public keys on both sides, in advance, and distribute = enough for the upcoming connections - then you=E2=80=99d have to hash = into that list in a way that avoids reuse. At that point, why not just = distribute symmetric keys and be done with it?

Joe

The KDF is just = to index into this file.
 
Because the use case, at least, makes sense.
 
Regards,
Jakob.
 
From: Joe Touch <touch@strayalpha.com> 
Sent: Monday, October 29, 2018 = 6:13 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: tcpm@ietf.org
Subject: Re: [tcpm] public-private = keys for TCP-AO
 
 


On Oct 29, 2018, at 5:45 PM, Jakob Heitz = (jheitz) <jheitz@cisco.com> = wrote:
 
Why was there not a public-private = key algorithm specified for TCP-AO? Or did I miss it?
 
There has not been. I doubt it would = make sense (see below).


For example ECC.
An MKT can specify a private key for the sender and a public = key for the receivers.
 
Yes, but the MKT is derived into = public/private keys using a KDF.
 
I am not aware of a KDF that can take a = private key and generate a derived private key that would work with a = correspondingly derived public key generated from the corresponding = public key.
 
To use, the sender will hash the data, encrypt the = hash and put the result into the MAC field.
The receiver would decrypt the MAC field, then hash = the data and verify the hash against the decrypted MAC.
This way, the private key never needs to be exposed to = anyone, simplifying key management.
Is there any objection to getting this done?
 
See above; it doesn=E2=80=99t make sense with the way = TCP-AO derives keys for each connection, AFAICT.
 
Joe


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

= --Apple-Mail=_8E0F86C3-02D7-40B8-A508-E78AB7CA5324-- From nobody Mon Oct 29 18:41:55 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB19A1274D0 for ; Mon, 29 Oct 2018 18:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.97 X-Spam-Level: X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ed2OyP9BxnW0 for ; Mon, 29 Oct 2018 18:41:50 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48946126DBF for ; Mon, 29 Oct 2018 18:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23150; q=dns/txt; s=iport; t=1540863710; x=1542073310; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Sp4JIqIId0FMLSvJhuH11nb6ZnnA4CH3uzk7VxZyyJc=; b=MoKyKBN35E7S+oHmR5ZGndlZtSa3pmAVR6Zg191ZC+yN10m3Zt/DYJVT 6MVB61HJUGgoE4YnZg9kM7azTzyWabNe/1neMhUledTnXW6jCEueRN6D5 wn0COVBm1l6FP1S60tFfngkZl0MZQb+8QXM0JHMWS9irF79buQDAWmoJe E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAACZtddb/5JdJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDUgvZn8oCoNriBiMGYINlyCBegsBARgBCoR?= =?us-ascii?q?JAheDFiE0DQ0BAwEBAgEBAm0cDIU6AQEBAQMBASEKQQsQAgEIEQQBASgDAgI?= =?us-ascii?q?CJQsUCQgBAQQOBQiDGoEdZA+pbIEuih0Fi0keF4FBP4QjWYJCAQGCF4JOglc?= =?us-ascii?q?CjkqGIolJVAkCkHogjWaCYZZ1AhEUgSYdOIFVcBU7gmyCJQEXiFyFPm+MBoE?= =?us-ascii?q?fAQE?= X-IronPort-AV: E=Sophos;i="5.54,442,1534809600"; d="scan'208,217";a="193766347" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2018 01:41:49 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id w9U1fmj1011936 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Oct 2018 01:41:49 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 29 Oct 2018 20:41:48 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1395.000; Mon, 29 Oct 2018 20:41:48 -0500 From: "Jakob Heitz (jheitz)" To: Joe Touch CC: "tcpm@ietf.org" Thread-Topic: [tcpm] public-private keys for TCP-AO Thread-Index: AdRv51Oca8SVyggpTLame1T3B/a0kQAME/iAAApbkFD//7O5gIAAU4Pg Date: Tue, 30 Oct 2018 01:41:48 +0000 Message-ID: <12b0f677e60443d8a32b4d56370787d7@XCH-ALN-014.cisco.com> References: <95f4b81948844b2799ecca33450bdde1@XCH-ALN-014.cisco.com> <7597333b9a414761be688375acf48dd6@XCH-ALN-014.cisco.com> <0C168054-E3D6-4BC5-9E1E-A28059F1A27B@strayalpha.com> In-Reply-To: <0C168054-E3D6-4BC5-9E1E-A28059F1A27B@strayalpha.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.161.174] Content-Type: multipart/alternative; boundary="_000_12b0f677e60443d8a32b4d56370787d7XCHALN014ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.23, xch-aln-013.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [tcpm] public-private keys for TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 01:41:53 -0000 --_000_12b0f677e60443d8a32b4d56370787d7XCHALN014ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVjYXVzZSBkaXN0cmlidXRpbmcgcHVibGljIGtleXMgaXMgZWFzaWVyLg0KUHJpdmF0ZSBrZXlz IGRvbid0IG5lZWQgdG8gYmUgZGlzdHJpYnV0ZWQuIFRoZXkgc3RheSBpbnNpZGUgdGhlIG1hY2hp bmUgdGhhdCBnZW5lcmF0ZXMgdGhlbS4NCg0KRGlzdHJpYnV0aW5nIGFuZCBzYWZlIGd1YXJkaW5n IHN5bW1ldHJpYyBrZXlzIGlzIGEgbWFqb3IgaGFzc2xlLg0KDQpSZWdhcmRzLA0KSmFrb2IuDQoN CkZyb206IEpvZSBUb3VjaCA8dG91Y2hAc3RyYXlhbHBoYS5jb20+DQpTZW50OiBNb25kYXksIE9j dG9iZXIgMjksIDIwMTggNjozNyBQTQ0KVG86IEpha29iIEhlaXR6IChqaGVpdHopIDxqaGVpdHpA Y2lzY28uY29tPg0KQ2M6IHRjcG1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdGNwbV0gcHVibGlj LXByaXZhdGUga2V5cyBmb3IgVENQLUFPDQoNCg0KDQoNCk9uIE9jdCAyOSwgMjAxOCwgYXQgNjoy MiBQTSwgSmFrb2IgSGVpdHogKGpoZWl0eikgPGpoZWl0ekBjaXNjby5jb208bWFpbHRvOmpoZWl0 ekBjaXNjby5jb20+PiB3cm90ZToNCg0KQ2FuIHlvdSB0aGluayBvZiBhIHdheSB0byBkbyBpdCB0 aGF0IHdpbGwgd29yaz8NCkxpa2UgdGhlIEtERiBpcyBqdXN0IGEgc3RhdGljIGxpc3Qgb3Igc29t ZXRoaW5nLg0KVGhlIHNlbmRlciBnZW5lcmF0ZXMgYSBzZXQgb2Yga2V5IHBhaXJzIGFuZCBudW1i ZXJzIHRoZW0uDQpJdCB0aGVuIHB1dHMgdGhlIGxpc3Qgb2YgcHVibGljIGtleXMgaW50byBhIGZp bGUgYW5kIGRpc3RyaWJ1dGVzIHRoZW0gdG8gYWxsIHJlY2VpdmVycyBpbiB0aGUgY2xlYXIuDQoN CllvdeKAmWQgaGF2ZSB0byBmaW5kIGEgd2F5IHRvIHNwZWNpZnkgdGhlIHVzZSBvZiBwcml2YXRl IGFuZCBwdWJsaWMga2V5cyBvbiBib3RoIHNpZGVzLCBpbiBhZHZhbmNlLCBhbmQgZGlzdHJpYnV0 ZSBlbm91Z2ggZm9yIHRoZSB1cGNvbWluZyBjb25uZWN0aW9ucyAtIHRoZW4geW914oCZZCBoYXZl IHRvIGhhc2ggaW50byB0aGF0IGxpc3QgaW4gYSB3YXkgdGhhdCBhdm9pZHMgcmV1c2UuIEF0IHRo YXQgcG9pbnQsIHdoeSBub3QganVzdCBkaXN0cmlidXRlIHN5bW1ldHJpYyBrZXlzIGFuZCBiZSBk b25lIHdpdGggaXQ/DQoNCkpvZQ0KDQpUaGUgS0RGIGlzIGp1c3QgdG8gaW5kZXggaW50byB0aGlz IGZpbGUuDQoNCkJlY2F1c2UgdGhlIHVzZSBjYXNlLCBhdCBsZWFzdCwgbWFrZXMgc2Vuc2UuDQoN ClJlZ2FyZHMsDQpKYWtvYi4NCg0KRnJvbTogSm9lIFRvdWNoIDx0b3VjaEBzdHJheWFscGhhLmNv bTxtYWlsdG86dG91Y2hAc3RyYXlhbHBoYS5jb20+Pg0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDI5 LCAyMDE4IDY6MTMgUE0NClRvOiBKYWtvYiBIZWl0eiAoamhlaXR6KSA8amhlaXR6QGNpc2NvLmNv bTxtYWlsdG86amhlaXR6QGNpc2NvLmNvbT4+DQpDYzogdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNw bUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdGNwbV0gcHVibGljLXByaXZhdGUga2V5cyBmb3Ig VENQLUFPDQoNCg0KDQoNCg0KT24gT2N0IDI5LCAyMDE4LCBhdCA1OjQ1IFBNLCBKYWtvYiBIZWl0 eiAoamhlaXR6KSA8amhlaXR6QGNpc2NvLmNvbTxtYWlsdG86amhlaXR6QGNpc2NvLmNvbT4+IHdy b3RlOg0KDQpXaHkgd2FzIHRoZXJlIG5vdCBhIHB1YmxpYy1wcml2YXRlIGtleSBhbGdvcml0aG0g c3BlY2lmaWVkIGZvciBUQ1AtQU8/IE9yIGRpZCBJIG1pc3MgaXQ/DQoNClRoZXJlIGhhcyBub3Qg YmVlbi4gSSBkb3VidCBpdCB3b3VsZCBtYWtlIHNlbnNlIChzZWUgYmVsb3cpLg0KDQoNCg0KRm9y IGV4YW1wbGUgRUNDLg0KQW4gTUtUIGNhbiBzcGVjaWZ5IGEgcHJpdmF0ZSBrZXkgZm9yIHRoZSBz ZW5kZXIgYW5kIGEgcHVibGljIGtleSBmb3IgdGhlIHJlY2VpdmVycy4NCg0KWWVzLCBidXQgdGhl IE1LVCBpcyBkZXJpdmVkIGludG8gcHVibGljL3ByaXZhdGUga2V5cyB1c2luZyBhIEtERi4NCg0K SSBhbSBub3QgYXdhcmUgb2YgYSBLREYgdGhhdCBjYW4gdGFrZSBhIHByaXZhdGUga2V5IGFuZCBn ZW5lcmF0ZSBhIGRlcml2ZWQgcHJpdmF0ZSBrZXkgdGhhdCB3b3VsZCB3b3JrIHdpdGggYSBjb3Jy ZXNwb25kaW5nbHkgZGVyaXZlZCBwdWJsaWMga2V5IGdlbmVyYXRlZCBmcm9tIHRoZSBjb3JyZXNw b25kaW5nIHB1YmxpYyBrZXkuDQoNClRvIHVzZSwgdGhlIHNlbmRlciB3aWxsIGhhc2ggdGhlIGRh dGEsIGVuY3J5cHQgdGhlIGhhc2ggYW5kIHB1dCB0aGUgcmVzdWx0IGludG8gdGhlIE1BQyBmaWVs ZC4NClRoZSByZWNlaXZlciB3b3VsZCBkZWNyeXB0IHRoZSBNQUMgZmllbGQsIHRoZW4gaGFzaCB0 aGUgZGF0YSBhbmQgdmVyaWZ5IHRoZSBoYXNoIGFnYWluc3QgdGhlIGRlY3J5cHRlZCBNQUMuDQpU aGlzIHdheSwgdGhlIHByaXZhdGUga2V5IG5ldmVyIG5lZWRzIHRvIGJlIGV4cG9zZWQgdG8gYW55 b25lLCBzaW1wbGlmeWluZyBrZXkgbWFuYWdlbWVudC4NCklzIHRoZXJlIGFueSBvYmplY3Rpb24g dG8gZ2V0dGluZyB0aGlzIGRvbmU/DQoNClNlZSBhYm92ZTsgaXQgZG9lc27igJl0IG1ha2Ugc2Vu c2Ugd2l0aCB0aGUgd2F5IFRDUC1BTyBkZXJpdmVzIGtleXMgZm9yIGVhY2ggY29ubmVjdGlvbiwg QUZBSUNULg0KDQpKb2UNCg0KDQoNCg0KUmVnYXJkcywNCkpha29iLg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdGNwbSBtYWlsaW5nIGxpc3QNCnRj cG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RjcG0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnRjcG0gbWFpbGluZyBsaXN0DQp0Y3BtQGlldGYub3JnPG1haWx0bzp0 Y3BtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3Bt DQoNCg== --_000_12b0f677e60443d8a32b4d56370787d7XCHALN014ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIg MSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IlxARGVuZ1hpYW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRp di5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJ e21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciLHNlcmlmOw0KCWNvbG9yOiM3MDMwQTA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm O2NvbG9yOiM3MDMwQTAiPkJlY2F1c2UgZGlzdHJpYnV0aW5nIHB1YmxpYyBrZXlzIGlzIGVhc2ll ci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oyxz ZXJpZjtjb2xvcjojNzAzMEEwIj5Qcml2YXRlIGtleXMgZG9uJ3QgbmVlZCB0byBiZSBkaXN0cmli dXRlZC4gVGhleSBzdGF5IGluc2lkZSB0aGUgbWFjaGluZSB0aGF0IGdlbmVyYXRlcyB0aGVtLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm O2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPkRpc3RyaWJ1dGluZyBhbmQg c2FmZSBndWFyZGluZyBzeW1tZXRyaWMga2V5cyBpcyBhIG1ham9yIGhhc3NsZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjoj NzAzMEEwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+UmVnYXJkcyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjoj NzAzMEEwIj5KYWtvYi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiBKb2UgVG91Y2ggJmx0O3RvdWNoQHN0cmF5YWxwaGEuY29tJmd0Ow0KPGJyPg0KPGI+ U2VudDo8L2I+IE1vbmRheSwgT2N0b2JlciAyOSwgMjAxOCA2OjM3IFBNPGJyPg0KPGI+VG86PC9i PiBKYWtvYiBIZWl0eiAoamhlaXR6KSAmbHQ7amhlaXR6QGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5D Yzo8L2I+IHRjcG1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0Y3BtXSBwdWJs aWMtcHJpdmF0ZSBrZXlzIGZvciBUQ1AtQU88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIE9jdCAyOSwgMjAxOCwgYXQgNjoyMiBQTSwgSmFrb2IgSGVpdHogKGpo ZWl0eikgJmx0OzxhIGhyZWY9Im1haWx0bzpqaGVpdHpAY2lzY28uY29tIj5qaGVpdHpAY2lzY28u Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5DYW4geW91IHRoaW5rIG9mIGEg d2F5IHRvIGRvIGl0IHRoYXQgd2lsbCB3b3JrPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMw QTAiPkxpa2UgdGhlIEtERiBpcyBqdXN0IGEgc3RhdGljIGxpc3Qgb3Igc29tZXRoaW5nLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPlRoZSBzZW5kZXIgZ2VuZXJhdGVzIGEgc2V0IG9m IGtleSBwYWlycyBhbmQgbnVtYmVycyB0aGVtLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMw QTAiPkl0IHRoZW4gcHV0cyB0aGUgbGlzdCBvZiBwdWJsaWMga2V5cyBpbnRvIGEgZmlsZSBhbmQg ZGlzdHJpYnV0ZXMgdGhlbSB0byBhbGwgcmVjZWl2ZXJzIGluIHRoZSBjbGVhci48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+WW914oCZZCBoYXZlIHRvIGZpbmQgYSB3YXkgdG8gc3BlY2lmeSB0 aGUgdXNlIG9mIHByaXZhdGUgYW5kIHB1YmxpYyBrZXlzIG9uIGJvdGggc2lkZXMsIGluIGFkdmFu Y2UsIGFuZCBkaXN0cmlidXRlIGVub3VnaCBmb3IgdGhlIHVwY29taW5nIGNvbm5lY3Rpb25zIC0g dGhlbiB5b3XigJlkIGhhdmUgdG8gaGFzaCBpbnRvIHRoYXQgbGlzdCBpbiBhIHdheSB0aGF0IGF2 b2lkcyByZXVzZS4gQXQgdGhhdCBwb2ludCwgd2h5DQogbm90IGp1c3QgZGlzdHJpYnV0ZSBzeW1t ZXRyaWMga2V5cyBhbmQgYmUgZG9uZSB3aXRoIGl0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29s b3I6IzcwMzBBMCI+VGhlIEtERiBpcyBqdXN0IHRvIGluZGV4IGludG8gdGhpcyBmaWxlLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9y OiM3MDMwQTAiPkJlY2F1c2UgdGhlIHVzZSBjYXNlLCBhdCBsZWFzdCwgbWFrZXMgc2Vuc2UuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNl cmlmO2NvbG9yOiM3MDMwQTAiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBB MCI+SmFrb2IuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Sm9lDQogVG91 Y2ggJmx0OzxhIGhyZWY9Im1haWx0bzp0b3VjaEBzdHJheWFscGhhLmNvbSI+dG91Y2hAc3RyYXlh bHBoYS5jb208L2E+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+TW9uZGF5LCBPY3RvYmVyIDI5LCAyMDE4IDY6MTMgUE08YnI+DQo8 Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pkpha29iIEhlaXR6IChqaGVpdHopICZsdDs8YSBocmVmPSJtYWlsdG86amhlaXR6QGNpc2NvLmNv bSI+amhlaXR6QGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86dGNwbUBp ZXRmLm9yZyI+dGNwbUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFt0Y3BtXSBwdWJsaWMt cHJpdmF0ZSBrZXlzIGZvciBUQ1AtQU88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIE9jdCAyOSwgMjAxOCwgYXQgNTo0NSBQTSwgSmFrb2IgSGVp dHogKGpoZWl0eikgJmx0OzxhIGhyZWY9Im1haWx0bzpqaGVpdHpAY2lzY28uY29tIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5qaGVpdHpAY2lzY28uY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+V2h5IHdh cyB0aGVyZSBub3QgYSBwdWJsaWMtcHJpdmF0ZSBrZXkgYWxnb3JpdGhtIHNwZWNpZmllZCBmb3Ig VENQLUFPPyBPciBkaWQgSSBtaXNzIGl0Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBoYXMgbm90IGJlZW4uIEkgZG91YnQgaXQg d291bGQgbWFrZSBzZW5zZSAoc2VlIGJlbG93KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+Rm9yIGV4YW1wbGUgRUNDLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPkFuIE1LVCBjYW4gc3Bl Y2lmeSBhIHByaXZhdGUga2V5IGZvciB0aGUgc2VuZGVyIGFuZCBhIHB1YmxpYyBrZXkgZm9yIHRo ZSByZWNlaXZlcnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlllcywgYnV0IHRoZSBNS1QgaXMgZGVyaXZlZCBpbnRvIHB1YmxpYy9wcml2 YXRlIGtleXMgdXNpbmcgYSBLREYuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gbm90 IGF3YXJlIG9mIGEgS0RGIHRoYXQgY2FuIHRha2UgYSBwcml2YXRlIGtleSBhbmQgZ2VuZXJhdGUg YSBkZXJpdmVkIHByaXZhdGUga2V5IHRoYXQgd291bGQgd29yayB3aXRoIGEgY29ycmVzcG9uZGlu Z2x5IGRlcml2ZWQgcHVibGljIGtleSBnZW5lcmF0ZWQgZnJvbSB0aGUgY29ycmVzcG9uZGluZyBw dWJsaWMga2V5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oyxz ZXJpZjtjb2xvcjojNzAzMEEwIj5UbyB1c2UsIHRoZSBzZW5kZXIgd2lsbCBoYXNoIHRoZSBkYXRh LCBlbmNyeXB0IHRoZSBoYXNoIGFuZCBwdXQgdGhlIHJlc3VsdCBpbnRvIHRoZSBNQUMgZmllbGQu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+VGhlIHJlY2Vp dmVyIHdvdWxkIGRlY3J5cHQgdGhlIE1BQyBmaWVsZCwgdGhlbiBoYXNoIHRoZSBkYXRhIGFuZCB2 ZXJpZnkgdGhlIGhhc2ggYWdhaW5zdCB0aGUgZGVjcnlwdGVkIE1BQy48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5UaGlzIHdheSwgdGhlIHByaXZhdGUga2V5 IG5ldmVyIG5lZWRzIHRvIGJlIGV4cG9zZWQgdG8gYW55b25lLCBzaW1wbGlmeWluZyBrZXkgbWFu YWdlbWVudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5J cyB0aGVyZSBhbnkgb2JqZWN0aW9uIHRvIGdldHRpbmcgdGhpcyBkb25lPzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlZSBhYm92ZTsgaXQgZG9lc27i gJl0IG1ha2Ugc2Vuc2Ugd2l0aCB0aGUgd2F5IFRDUC1BTyBkZXJpdmVzIGtleXMgZm9yIGVhY2gg Y29ubmVjdGlvbiwgQUZBSUNULjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2U8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3 MDMwQTAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMw QTAiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBB MCI+SmFrb2IuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KdGNwbSBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOnRjcG1AaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk1NEY3MiI+dGNw bUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojOTU0RjcyIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RjcG08L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnRj cG0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciPnRjcG1A aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90Y3BtIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG08 L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_12b0f677e60443d8a32b4d56370787d7XCHALN014ciscocom_-- From nobody Mon Oct 29 18:49:22 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFBE1288BD for ; Mon, 29 Oct 2018 18:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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] 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 YAqDAukaZFsb for ; Mon, 29 Oct 2018 18:49:18 -0700 (PDT) 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 0E8C212872C for ; Mon, 29 Oct 2018 18:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type: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=l8cY6pnmKDghx1rXZAHT0Nk5AfG14sLYvEcEXaD2Cgk=; b=uw5r1BZFFCqN68vomctGe7oye 5RcB4q/U5sU432EfNAHEXVazUTyg9r3xmrqrGHtQuRekwZQ70aqwE+9Z9kWBNKRcJf5eQ9XyOUvf6 laBUDFSdd8jnZIfaDUhZyl1s/KZjrWoFjxxZVIg8dH1QEawCRiw2uNpx+AuIu8BnVY9G1M1i13EK3 H7Vc45v/YXrCJMfGZu5sg1nuowu4Xv3vv1+IvZ8es++JApl4gwE+yYMLYxu+wOE75q+6bZM0ALyoQ ZxAOVuZzQ4jBbtlflBsnxQqYJ/yITSilW7thQViKOZfTGxxTcl+iuKSEjnPZ8GaqVeW2jATsz+3je umvlchYjA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:55839 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gHJ9e-0023kA-5j; Mon, 29 Oct 2018 21:49:16 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_10A0720F-57DF-47DE-9B4D-9CFF9F1DE9B9" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: <12b0f677e60443d8a32b4d56370787d7@XCH-ALN-014.cisco.com> Date: Mon, 29 Oct 2018 18:49:13 -0700 Cc: "tcpm@ietf.org" Message-Id: <4C874E0B-BB5D-4765-8A33-3B9C736B646B@strayalpha.com> References: <95f4b81948844b2799ecca33450bdde1@XCH-ALN-014.cisco.com> <7597333b9a414761be688375acf48dd6@XCH-ALN-014.cisco.com> <0C168054-E3D6-4BC5-9E1E-A28059F1A27B@strayalpha.com> <12b0f677e60443d8a32b4d56370787d7@XCH-ALN-014.cisco.com> To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.3445.9.1) 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: Subject: Re: [tcpm] public-private keys for TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 01:49:21 -0000 --Apple-Mail=_10A0720F-57DF-47DE-9B4D-9CFF9F1DE9B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 29, 2018, at 6:41 PM, Jakob Heitz (jheitz) = wrote: >=20 > Because distributing public keys is easier. > Private keys don't need to be distributed. They stay inside the = machine that generates them. Sure, but you need to generate private/public key pairs on both sides of = the connection - many of them - and then distribute them to both sides. = I.e., the work gets a LOT larger. > =20 > Distributing and safe guarding symmetric keys is a major hassle. Agreed, but you only need one such shared key between each endpoint pair = because you can derive session keys algorithmically. You can certainly TRY to work out the details as you suggest, but I = suspect the number of keys needed would be prohibitive even for a single = pair of endpoints. Joe > =20 > Regards, > Jakob. > =20 > From: Joe Touch >=20= > Sent: Monday, October 29, 2018 6:37 PM > To: Jakob Heitz (jheitz) > > Cc: tcpm@ietf.org > Subject: Re: [tcpm] public-private keys for TCP-AO > =20 > =20 >=20 >=20 > On Oct 29, 2018, at 6:22 PM, Jakob Heitz (jheitz) > wrote: > =20 > Can you think of a way to do it that will work? > Like the KDF is just a static list or something. > The sender generates a set of key pairs and numbers them. > It then puts the list of public keys into a file and distributes them = to all receivers in the clear. > =20 > You=E2=80=99d have to find a way to specify the use of private and = public keys on both sides, in advance, and distribute enough for the = upcoming connections - then you=E2=80=99d have to hash into that list in = a way that avoids reuse. At that point, why not just distribute = symmetric keys and be done with it? > =20 > Joe > =20 > The KDF is just to index into this file. > =20 > Because the use case, at least, makes sense. > =20 > Regards, > Jakob. > =20 > From: Joe Touch >=20= > Sent: Monday, October 29, 2018 6:13 PM > To: Jakob Heitz (jheitz) > > Cc: tcpm@ietf.org > Subject: Re: [tcpm] public-private keys for TCP-AO > =20 > =20 >=20 >=20 >=20 > On Oct 29, 2018, at 5:45 PM, Jakob Heitz (jheitz) > wrote: > =20 > Why was there not a public-private key algorithm specified for TCP-AO? = Or did I miss it? > =20 > There has not been. I doubt it would make sense (see below). >=20 >=20 >=20 > For example ECC. > An MKT can specify a private key for the sender and a public key for = the receivers. > =20 > Yes, but the MKT is derived into public/private keys using a KDF. > =20 > I am not aware of a KDF that can take a private key and generate a = derived private key that would work with a correspondingly derived = public key generated from the corresponding public key. > =20 > To use, the sender will hash the data, encrypt the hash and put the = result into the MAC field. > The receiver would decrypt the MAC field, then hash the data and = verify the hash against the decrypted MAC. > This way, the private key never needs to be exposed to anyone, = simplifying key management. > Is there any objection to getting this done? > =20 > See above; it doesn=E2=80=99t make sense with the way TCP-AO derives = keys for each connection, AFAICT. > =20 > Joe >=20 >=20 >=20 > =20 > Regards, > Jakob. > =20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = > =20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = > =20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = --Apple-Mail=_10A0720F-57DF-47DE-9B4D-9CFF9F1DE9B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 29, 2018, at 6:41 PM, Jakob Heitz (jheitz) <jheitz@cisco.com> = wrote:

Because = distributing public keys is easier.
Private keys don't need to be distributed. They stay = inside the machine that generates = them.

Sure, but you need to generate private/public key = pairs on both sides of the connection - many of them - and then = distribute them to both sides. I.e., the work gets a LOT = larger.

 
Distributing and safe guarding symmetric keys is a major = hassle.

Agreed, but you only need one such shared key = between each endpoint pair because you can derive session keys = algorithmically.

You can certainly = TRY to work out the details as you suggest, but I suspect the number of = keys needed would be prohibitive even for a single pair of = endpoints.

Joe

 
Regards,
Jakob.
 
From: Joe Touch <touch@strayalpha.com> 
Sent: Monday, October 29, 2018 = 6:37 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: tcpm@ietf.org
Subject: Re: [tcpm] public-private = keys for TCP-AO
 
 


On Oct 29, 2018, at 6:22 PM, Jakob Heitz = (jheitz) <jheitz@cisco.com> = wrote:
 
Can you think of a way to do it = that will work?
Like the KDF is just a static list = or something.
The sender generates a set of key pairs and numbers = them.
It then puts the list of public keys into a file and = distributes them to all receivers in the clear.
 
You=E2=80=99d have to find a way to = specify the use of private and public keys on both sides, in advance, = and distribute enough for the upcoming connections - then you=E2=80=99d = have to hash into that list in a way that avoids reuse. At that point, = why not just distribute symmetric keys and be done with it?
 
Joe
 
The KDF is just = to index into this file.
 
Because the use case, at least, makes sense.
 
Regards,
Jakob.
 
From: Joe Touch <touch@strayalpha.com> 
Sent: Monday, October 29, 2018 = 6:13 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: tcpm@ietf.org
Subject: Re: [tcpm] public-private = keys for TCP-AO
 
 



On Oct 29, 2018, at 5:45 = PM, Jakob Heitz (jheitz) <jheitz@cisco.com> = wrote:
 
Why was there not a public-private = key algorithm specified for TCP-AO? Or did I miss it?
 
There has not been. I = doubt it would make sense (see below).



For = example ECC.
An MKT can = specify a private key for the sender and a public key for the = receivers.
 
Yes, but the MKT is = derived into public/private keys using a KDF.
 
I am not aware of a KDF = that can take a private key and generate a derived private key that = would work with a correspondingly derived public key generated from the = corresponding public key.
 
To = use, the sender will hash the data, encrypt the hash and put the result = into the MAC field.
The receiver = would decrypt the MAC field, then hash the data and verify the hash = against the decrypted MAC.
This way, the private key never needs to be exposed to = anyone, simplifying key management.
Is there any objection to getting this = done?
 
See above; it doesn=E2=80=99t make sense = with the way TCP-AO derives keys for each connection, AFAICT.
 
Joe



 
Regards,
Jakob.
 
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
 
_______________________________________________tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
 
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
= --Apple-Mail=_10A0720F-57DF-47DE-9B4D-9CFF9F1DE9B9-- From nobody Mon Oct 29 19:00:23 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381DE1288BD for ; Mon, 29 Oct 2018 19:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.97 X-Spam-Level: X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 vQlsAUeAYMSG for ; Mon, 29 Oct 2018 19:00:19 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3211126DBF for ; Mon, 29 Oct 2018 19:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32968; q=dns/txt; s=iport; t=1540864818; x=1542074418; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yqlR0FxYLbkoPkZx61yM7hxmFp2uk1gfvdL1zTq0uyc=; b=km3cKNxq65uwqn5xmAeeaY3CrS74VjHscpn3PBt31IQ2bg8uCpF8WMfD B5iC0bnFB8HtT4I6FhmJJUlS+ZbSKfuxzUyrMrlhq+Ko3KazeJixTIEhZ PY08ZNr+wHCyMGdw5S00lsT3BIa2dAJRsIMW0HMf7gdUIsA1GIgjeoinl M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAA/utdb/5hdJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDUgvZn8oCoNriBiMGYINlyCBegsBARgBCoR?= =?us-ascii?q?JAheDFiE0DQ0BAwEBAgEBAm0cDIU6AQEBAQMBASEKQQsQAgEIEQQBASEHAwI?= =?us-ascii?q?CAiULFAkIAgQOBQiDGoEdZA+pZoEuih0Fi0keF4FBP4QjWYJCAQGCF4JOglc?= =?us-ascii?q?CiGmFYYYiiUlUCQKQeiCNZoJhlnUCERSBJh04gVVwFTuCbIIlAReIXIU+b4w?= =?us-ascii?q?GgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,442,1534809600"; d="scan'208,217";a="192925432" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2018 02:00:17 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id w9U20HG5005086 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Oct 2018 02:00:17 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 29 Oct 2018 21:00:16 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1395.000; Mon, 29 Oct 2018 21:00:16 -0500 From: "Jakob Heitz (jheitz)" To: Joe Touch CC: "tcpm@ietf.org" Thread-Topic: [tcpm] public-private keys for TCP-AO Thread-Index: AdRv51Oca8SVyggpTLame1T3B/a0kQAME/iAAApbkFD//7O5gIAAU4Pg//+v9oCAAFNQ4A== Date: Tue, 30 Oct 2018 02:00:16 +0000 Message-ID: References: <95f4b81948844b2799ecca33450bdde1@XCH-ALN-014.cisco.com> <7597333b9a414761be688375acf48dd6@XCH-ALN-014.cisco.com> <0C168054-E3D6-4BC5-9E1E-A28059F1A27B@strayalpha.com> <12b0f677e60443d8a32b4d56370787d7@XCH-ALN-014.cisco.com> <4C874E0B-BB5D-4765-8A33-3B9C736B646B@strayalpha.com> In-Reply-To: <4C874E0B-BB5D-4765-8A33-3B9C736B646B@strayalpha.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.161.174] Content-Type: multipart/alternative; boundary="_000_bd707072e91b420d93dd898f69d94898XCHALN014ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.21, xch-aln-011.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [tcpm] public-private keys for TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 02:00:22 -0000 --_000_bd707072e91b420d93dd898f69d94898XCHALN014ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgYXJlIHVzZSBjYXNlcyB3aGVyZSBJIGRvbid0IG5lZWQgdG8gZ2VuZXJhdGUgYSBMT1Qu DQpPbmUgYSBtb250aCBzaG91bGQgYmUganVzdCBmaW5lLCBiZWNhdXNlIEkgaGF2ZSBubyBmZWFy IG9mIHRoZW0gbGVha2luZyBpbnRvIGVuZW15IGhhbmRzLg0KSSBwb3NpdCB0aGF0IGRpc3RyaWJ1 dGluZyBvbmUgc2hhcmVkIHNlY3JldCBrZXkgaXMgYSBMT1QgaGFyZGVyIHRoYW4gZGlzdHJpYnV0 aW5nIDEwMDAgcHVibGljIGtleXMuDQoNClJlZ2FyZHMsDQpKYWtvYi4NCg0KRnJvbTogSm9lIFRv dWNoIDx0b3VjaEBzdHJheWFscGhhLmNvbT4NClNlbnQ6IE1vbmRheSwgT2N0b2JlciAyOSwgMjAx OCA2OjQ5IFBNDQpUbzogSmFrb2IgSGVpdHogKGpoZWl0eikgPGpoZWl0ekBjaXNjby5jb20+DQpD YzogdGNwbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt0Y3BtXSBwdWJsaWMtcHJpdmF0ZSBrZXlz IGZvciBUQ1AtQU8NCg0KDQoNCg0KT24gT2N0IDI5LCAyMDE4LCBhdCA2OjQxIFBNLCBKYWtvYiBI ZWl0eiAoamhlaXR6KSA8amhlaXR6QGNpc2NvLmNvbTxtYWlsdG86amhlaXR6QGNpc2NvLmNvbT4+ IHdyb3RlOg0KDQpCZWNhdXNlIGRpc3RyaWJ1dGluZyBwdWJsaWMga2V5cyBpcyBlYXNpZXIuDQpQ cml2YXRlIGtleXMgZG9uJ3QgbmVlZCB0byBiZSBkaXN0cmlidXRlZC4gVGhleSBzdGF5IGluc2lk ZSB0aGUgbWFjaGluZSB0aGF0IGdlbmVyYXRlcyB0aGVtLg0KDQpTdXJlLCBidXQgeW91IG5lZWQg dG8gZ2VuZXJhdGUgcHJpdmF0ZS9wdWJsaWMga2V5IHBhaXJzIG9uIGJvdGggc2lkZXMgb2YgdGhl IGNvbm5lY3Rpb24gLSBtYW55IG9mIHRoZW0gLSBhbmQgdGhlbiBkaXN0cmlidXRlIHRoZW0gdG8g Ym90aCBzaWRlcy4gSS5lLiwgdGhlIHdvcmsgZ2V0cyBhIExPVCBsYXJnZXIuDQoNCg0KRGlzdHJp YnV0aW5nIGFuZCBzYWZlIGd1YXJkaW5nIHN5bW1ldHJpYyBrZXlzIGlzIGEgbWFqb3IgaGFzc2xl Lg0KDQpBZ3JlZWQsIGJ1dCB5b3Ugb25seSBuZWVkIG9uZSBzdWNoIHNoYXJlZCBrZXkgYmV0d2Vl biBlYWNoIGVuZHBvaW50IHBhaXIgYmVjYXVzZSB5b3UgY2FuIGRlcml2ZSBzZXNzaW9uIGtleXMg YWxnb3JpdGhtaWNhbGx5Lg0KDQpZb3UgY2FuIGNlcnRhaW5seSBUUlkgdG8gd29yayBvdXQgdGhl IGRldGFpbHMgYXMgeW91IHN1Z2dlc3QsIGJ1dCBJIHN1c3BlY3QgdGhlIG51bWJlciBvZiBrZXlz IG5lZWRlZCB3b3VsZCBiZSBwcm9oaWJpdGl2ZSBldmVuIGZvciBhIHNpbmdsZSBwYWlyIG9mIGVu ZHBvaW50cy4NCg0KSm9lDQoNCg0KDQpSZWdhcmRzLA0KSmFrb2IuDQoNCkZyb206IEpvZSBUb3Vj aCA8dG91Y2hAc3RyYXlhbHBoYS5jb208bWFpbHRvOnRvdWNoQHN0cmF5YWxwaGEuY29tPj4NClNl bnQ6IE1vbmRheSwgT2N0b2JlciAyOSwgMjAxOCA2OjM3IFBNDQpUbzogSmFrb2IgSGVpdHogKGpo ZWl0eikgPGpoZWl0ekBjaXNjby5jb208bWFpbHRvOmpoZWl0ekBjaXNjby5jb20+Pg0KQ2M6IHRj cG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3RjcG1dIHB1 YmxpYy1wcml2YXRlIGtleXMgZm9yIFRDUC1BTw0KDQoNCg0KDQoNCk9uIE9jdCAyOSwgMjAxOCwg YXQgNjoyMiBQTSwgSmFrb2IgSGVpdHogKGpoZWl0eikgPGpoZWl0ekBjaXNjby5jb208bWFpbHRv OmpoZWl0ekBjaXNjby5jb20+PiB3cm90ZToNCg0KQ2FuIHlvdSB0aGluayBvZiBhIHdheSB0byBk byBpdCB0aGF0IHdpbGwgd29yaz8NCkxpa2UgdGhlIEtERiBpcyBqdXN0IGEgc3RhdGljIGxpc3Qg b3Igc29tZXRoaW5nLg0KVGhlIHNlbmRlciBnZW5lcmF0ZXMgYSBzZXQgb2Yga2V5IHBhaXJzIGFu ZCBudW1iZXJzIHRoZW0uDQpJdCB0aGVuIHB1dHMgdGhlIGxpc3Qgb2YgcHVibGljIGtleXMgaW50 byBhIGZpbGUgYW5kIGRpc3RyaWJ1dGVzIHRoZW0gdG8gYWxsIHJlY2VpdmVycyBpbiB0aGUgY2xl YXIuDQoNCllvdeKAmWQgaGF2ZSB0byBmaW5kIGEgd2F5IHRvIHNwZWNpZnkgdGhlIHVzZSBvZiBw cml2YXRlIGFuZCBwdWJsaWMga2V5cyBvbiBib3RoIHNpZGVzLCBpbiBhZHZhbmNlLCBhbmQgZGlz dHJpYnV0ZSBlbm91Z2ggZm9yIHRoZSB1cGNvbWluZyBjb25uZWN0aW9ucyAtIHRoZW4geW914oCZ ZCBoYXZlIHRvIGhhc2ggaW50byB0aGF0IGxpc3QgaW4gYSB3YXkgdGhhdCBhdm9pZHMgcmV1c2Uu IEF0IHRoYXQgcG9pbnQsIHdoeSBub3QganVzdCBkaXN0cmlidXRlIHN5bW1ldHJpYyBrZXlzIGFu ZCBiZSBkb25lIHdpdGggaXQ/DQoNCkpvZQ0KDQpUaGUgS0RGIGlzIGp1c3QgdG8gaW5kZXggaW50 byB0aGlzIGZpbGUuDQoNCkJlY2F1c2UgdGhlIHVzZSBjYXNlLCBhdCBsZWFzdCwgbWFrZXMgc2Vu c2UuDQoNClJlZ2FyZHMsDQpKYWtvYi4NCg0KRnJvbTogSm9lIFRvdWNoIDx0b3VjaEBzdHJheWFs cGhhLmNvbTxtYWlsdG86dG91Y2hAc3RyYXlhbHBoYS5jb20+Pg0KU2VudDogTW9uZGF5LCBPY3Rv YmVyIDI5LCAyMDE4IDY6MTMgUE0NClRvOiBKYWtvYiBIZWl0eiAoamhlaXR6KSA8amhlaXR6QGNp c2NvLmNvbTxtYWlsdG86amhlaXR6QGNpc2NvLmNvbT4+DQpDYzogdGNwbUBpZXRmLm9yZzxtYWls dG86dGNwbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdGNwbV0gcHVibGljLXByaXZhdGUga2V5 cyBmb3IgVENQLUFPDQoNCg0KDQoNCg0KDQpPbiBPY3QgMjksIDIwMTgsIGF0IDU6NDUgUE0sIEph a29iIEhlaXR6IChqaGVpdHopIDxqaGVpdHpAY2lzY28uY29tPG1haWx0bzpqaGVpdHpAY2lzY28u Y29tPj4gd3JvdGU6DQoNCldoeSB3YXMgdGhlcmUgbm90IGEgcHVibGljLXByaXZhdGUga2V5IGFs Z29yaXRobSBzcGVjaWZpZWQgZm9yIFRDUC1BTz8gT3IgZGlkIEkgbWlzcyBpdD8NCg0KVGhlcmUg aGFzIG5vdCBiZWVuLiBJIGRvdWJ0IGl0IHdvdWxkIG1ha2Ugc2Vuc2UgKHNlZSBiZWxvdykuDQoN Cg0KDQoNCkZvciBleGFtcGxlIEVDQy4NCkFuIE1LVCBjYW4gc3BlY2lmeSBhIHByaXZhdGUga2V5 IGZvciB0aGUgc2VuZGVyIGFuZCBhIHB1YmxpYyBrZXkgZm9yIHRoZSByZWNlaXZlcnMuDQoNClll cywgYnV0IHRoZSBNS1QgaXMgZGVyaXZlZCBpbnRvIHB1YmxpYy9wcml2YXRlIGtleXMgdXNpbmcg YSBLREYuDQoNCkkgYW0gbm90IGF3YXJlIG9mIGEgS0RGIHRoYXQgY2FuIHRha2UgYSBwcml2YXRl IGtleSBhbmQgZ2VuZXJhdGUgYSBkZXJpdmVkIHByaXZhdGUga2V5IHRoYXQgd291bGQgd29yayB3 aXRoIGEgY29ycmVzcG9uZGluZ2x5IGRlcml2ZWQgcHVibGljIGtleSBnZW5lcmF0ZWQgZnJvbSB0 aGUgY29ycmVzcG9uZGluZyBwdWJsaWMga2V5Lg0KDQpUbyB1c2UsIHRoZSBzZW5kZXIgd2lsbCBo YXNoIHRoZSBkYXRhLCBlbmNyeXB0IHRoZSBoYXNoIGFuZCBwdXQgdGhlIHJlc3VsdCBpbnRvIHRo ZSBNQUMgZmllbGQuDQpUaGUgcmVjZWl2ZXIgd291bGQgZGVjcnlwdCB0aGUgTUFDIGZpZWxkLCB0 aGVuIGhhc2ggdGhlIGRhdGEgYW5kIHZlcmlmeSB0aGUgaGFzaCBhZ2FpbnN0IHRoZSBkZWNyeXB0 ZWQgTUFDLg0KVGhpcyB3YXksIHRoZSBwcml2YXRlIGtleSBuZXZlciBuZWVkcyB0byBiZSBleHBv c2VkIHRvIGFueW9uZSwgc2ltcGxpZnlpbmcga2V5IG1hbmFnZW1lbnQuDQpJcyB0aGVyZSBhbnkg b2JqZWN0aW9uIHRvIGdldHRpbmcgdGhpcyBkb25lPw0KDQpTZWUgYWJvdmU7IGl0IGRvZXNu4oCZ dCBtYWtlIHNlbnNlIHdpdGggdGhlIHdheSBUQ1AtQU8gZGVyaXZlcyBrZXlzIGZvciBlYWNoIGNv bm5lY3Rpb24sIEFGQUlDVC4NCg0KSm9lDQoNCg0KDQoNCg0KUmVnYXJkcywNCkpha29iLg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdGNwbSBtYWls aW5nIGxpc3QNCnRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnRjcG0gbWFpbGluZyBsaXN0DQp0Y3BtQGlldGYu b3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90Y3BtDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQp0Y3BtIG1haWxpbmcgbGlzdA0KdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0KDQo= --_000_bd707072e91b420d93dd898f69d94898XCHALN014ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIg MSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IlxARGVuZ1hpYW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRp di5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJ e21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciLHNlcmlmOw0KCWNvbG9yOiM3MDMwQTA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm O2NvbG9yOiM3MDMwQTAiPlRoZXJlIGFyZSB1c2UgY2FzZXMgd2hlcmUgSSBkb24ndCBuZWVkIHRv IGdlbmVyYXRlIGEgTE9ULjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPk9uZSBhIG1vbnRoIHNob3VsZCBiZSBq dXN0IGZpbmUsIGJlY2F1c2UgSSBoYXZlIG5vIGZlYXIgb2YgdGhlbSBsZWFraW5nIGludG8gZW5l bXkgaGFuZHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+SSBwb3NpdCB0aGF0IGRpc3RyaWJ1dGluZyBvbmUg c2hhcmVkIHNlY3JldCBrZXkgaXMgYSBMT1QgaGFyZGVyIHRoYW4gZGlzdHJpYnV0aW5nIDEwMDAg cHVibGljIGtleXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMw QTAiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+SmFrb2IuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAz MEEwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSm9lIFRvdWNoICZsdDt0b3VjaEBzdHJheWFs cGhhLmNvbSZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE9jdG9iZXIgMjksIDIwMTgg Njo0OSBQTTxicj4NCjxiPlRvOjwvYj4gSmFrb2IgSGVpdHogKGpoZWl0eikgJmx0O2poZWl0ekBj aXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiB0Y3BtQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbdGNwbV0gcHVibGljLXByaXZhdGUga2V5cyBmb3IgVENQLUFPPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBPY3QgMjksIDIwMTgsIGF0IDY6 NDEgUE0sIEpha29iIEhlaXR6IChqaGVpdHopICZsdDs8YSBocmVmPSJtYWlsdG86amhlaXR6QGNp c2NvLmNvbSI+amhlaXR6QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBB MCI+QmVjYXVzZSBkaXN0cmlidXRpbmcgcHVibGljIGtleXMgaXMgZWFzaWVyLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 LHNlcmlmO2NvbG9yOiM3MDMwQTAiPlByaXZhdGUga2V5cyBkb24ndCBuZWVkIHRvIGJlIGRpc3Ry aWJ1dGVkLiBUaGV5IHN0YXkgaW5zaWRlIHRoZSBtYWNoaW5lIHRoYXQgZ2VuZXJhdGVzIHRoZW0u PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1cmUsIGJ1dCB5b3UgbmVlZCB0byBnZW5lcmF0 ZSBwcml2YXRlL3B1YmxpYyBrZXkgcGFpcnMgb24gYm90aCBzaWRlcyBvZiB0aGUgY29ubmVjdGlv biAtIG1hbnkgb2YgdGhlbSAtIGFuZCB0aGVuIGRpc3RyaWJ1dGUgdGhlbSB0byBib3RoIHNpZGVz LiBJLmUuLCB0aGUgd29yayBnZXRzIGEgTE9UIGxhcmdlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7 Y29sb3I6IzcwMzBBMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+RGlz dHJpYnV0aW5nIGFuZCBzYWZlIGd1YXJkaW5nIHN5bW1ldHJpYyBrZXlzIGlzIGEgbWFqb3IgaGFz c2xlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ3JlZWQsIGJ1dCB5b3Ugb25seSBuZWVk IG9uZSBzdWNoIHNoYXJlZCBrZXkgYmV0d2VlbiBlYWNoIGVuZHBvaW50IHBhaXIgYmVjYXVzZSB5 b3UgY2FuIGRlcml2ZSBzZXNzaW9uIGtleXMgYWxnb3JpdGhtaWNhbGx5LjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3UgY2FuIGNlcnRhaW5s eSBUUlkgdG8gd29yayBvdXQgdGhlIGRldGFpbHMgYXMgeW91IHN1Z2dlc3QsIGJ1dCBJIHN1c3Bl Y3QgdGhlIG51bWJlciBvZiBrZXlzIG5lZWRlZCB3b3VsZCBiZSBwcm9oaWJpdGl2ZSBldmVuIGZv ciBhIHNpbmdsZSBwYWlyIG9mIGVuZHBvaW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5SZWdhcmRzLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPkpha29iLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDss c2VyaWY7Y29sb3I6IzcwMzBBMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkpvZQ0KIFRvdWNoICZsdDs8YSBocmVmPSJtYWlsdG86dG91Y2hA c3RyYXlhbHBoYS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnRvdWNoQHN0cmF5YWxw aGEuY29tPC9zcGFuPjwvYT4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Nb25kYXksIE9jdG9iZXIgMjksIDIwMTggNjozNyBQTTxi cj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+SmFrb2IgSGVpdHogKGpoZWl0eikgJmx0OzxhIGhyZWY9Im1haWx0bzpqaGVpdHpAY2lz Y28uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5qaGVpdHpAY2lzY28uY29tPC9zcGFu PjwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+dGNwbUBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGI+U3ViamVj dDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJl OiBbdGNwbV0gcHVibGljLXByaXZhdGUga2V5cyBmb3IgVENQLUFPPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBPY3QgMjksIDIwMTgsIGF0IDY6 MjIgUE0sIEpha29iIEhlaXR6IChqaGVpdHopICZsdDs8YSBocmVmPSJtYWlsdG86amhlaXR6QGNp c2NvLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+amhlaXR6QGNpc2NvLmNvbTwvc3Bh bj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9y OiM3MDMwQTAiPkNhbiB5b3UgdGhpbmsgb2YgYSB3YXkgdG8gZG8gaXQgdGhhdCB3aWxsIHdvcms/ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+TGlrZSB0aGUg S0RGIGlzIGp1c3QgYSBzdGF0aWMgbGlzdCBvciBzb21ldGhpbmcuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+VGhlIHNlbmRlciBnZW5lcmF0ZXMgYSBzZXQg b2Yga2V5IHBhaXJzIGFuZCBudW1iZXJzIHRoZW0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDss c2VyaWY7Y29sb3I6IzcwMzBBMCI+SXQgdGhlbiBwdXRzIHRoZSBsaXN0IG9mIHB1YmxpYyBrZXlz IGludG8gYSBmaWxlIGFuZCBkaXN0cmlidXRlcyB0aGVtIHRvIGFsbCByZWNlaXZlcnMgaW4gdGhl IGNsZWFyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Zb3XigJlkIGhhdmUgdG8gZmluZCBhIHdheSB0byBzcGVjaWZ5IHRoZSB1c2Ugb2Yg cHJpdmF0ZSBhbmQgcHVibGljIGtleXMgb24gYm90aCBzaWRlcywgaW4gYWR2YW5jZSwgYW5kIGRp c3RyaWJ1dGUgZW5vdWdoIGZvciB0aGUgdXBjb21pbmcgY29ubmVjdGlvbnMgLSB0aGVuIHlvdeKA mWQgaGF2ZSB0byBoYXNoIGludG8gdGhhdCBsaXN0IGluIGEgd2F5IHRoYXQgYXZvaWRzIHJldXNl LiBBdCB0aGF0IHBvaW50LCB3aHkNCiBub3QganVzdCBkaXN0cmlidXRlIHN5bW1ldHJpYyBrZXlz IGFuZCBiZSBkb25lIHdpdGggaXQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvZTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAz MEEwIj5UaGUgS0RGIGlzIGp1c3QgdG8gaW5kZXggaW50byB0aGlzIGZpbGUuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+QmVjYXVzZSB0aGUgdXNlIGNhc2UsIGF0 IGxlYXN0LCBtYWtlcyBzZW5zZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xv cjojNzAzMEEwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7 Y29sb3I6IzcwMzBBMCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtj b2xvcjojNzAzMEEwIj5KYWtvYi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNl cmlmO2NvbG9yOiM3MDMwQTAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Kb2UNCiBUb3VjaCAmbHQ7PGEgaHJlZj0i bWFpbHRvOnRvdWNoQHN0cmF5YWxwaGEuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj50 b3VjaEBzdHJheWFscGhhLmNvbTwvc3Bhbj48L2E+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TW9uZGF5LCBPY3RvYmVyIDI5LCAy MDE4IDY6MTMgUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPkpha29iIEhlaXR6IChqaGVpdHopICZsdDs8YSBocmVmPSJtYWls dG86amhlaXR6QGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+amhlaXR6QGNp c2NvLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5v cmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnRjcG1AaWV0Zi5vcmc8L3NwYW4+PC9hPjxi cj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5SZTogW3RjcG1dIHB1YmxpYy1wcml2YXRlIGtleXMgZm9yIFRDUC1BTzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gT2N0IDI5LCAyMDE4LCBhdCA1OjQ1IFBNLCBKYWtvYiBIZWl0eiAoamhlaXR6KSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmpoZWl0ekBjaXNjby5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi PmpoZWl0ekBjaXNjby5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAz MEEwIj5XaHkgd2FzIHRoZXJlIG5vdCBhIHB1YmxpYy1wcml2YXRlIGtleSBhbGdvcml0aG0gc3Bl Y2lmaWVkIGZvciBUQ1AtQU8/IE9yIGRpZCBJIG1pc3MgaXQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZXJlIGhhcyBub3QgYmVlbi4gSSBkb3VidCBpdCB3b3VsZCBtYWtlIHNlbnNl IChzZWUgYmVsb3cpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5G b3IgZXhhbXBsZSBFQ0MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDss c2VyaWY7Y29sb3I6IzcwMzBBMCI+QW4gTUtUIGNhbiBzcGVjaWZ5IGEgcHJpdmF0ZSBrZXkgZm9y IHRoZSBzZW5kZXIgYW5kIGEgcHVibGljIGtleSBmb3IgdGhlIHJlY2VpdmVycy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCBidXQgdGhlIE1LVCBpcyBkZXJpdmVkIGludG8gcHVi bGljL3ByaXZhdGUga2V5cyB1c2luZyBhIEtERi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBub3QgYXdhcmUgb2YgYSBLREYgdGhh dCBjYW4gdGFrZSBhIHByaXZhdGUga2V5IGFuZCBnZW5lcmF0ZSBhIGRlcml2ZWQgcHJpdmF0ZSBr ZXkgdGhhdCB3b3VsZCB3b3JrIHdpdGggYSBjb3JyZXNwb25kaW5nbHkgZGVyaXZlZCBwdWJsaWMg a2V5IGdlbmVyYXRlZCBmcm9tIHRoZSBjb3JyZXNwb25kaW5nIHB1YmxpYyBrZXkuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPlRvIHVzZSwgdGhlIHNlbmRlciB3aWxsIGhh c2ggdGhlIGRhdGEsIGVuY3J5cHQgdGhlIGhhc2ggYW5kIHB1dCB0aGUgcmVzdWx0IGludG8gdGhl IE1BQyBmaWVsZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJp Zjtjb2xvcjojNzAzMEEwIj5UaGUgcmVjZWl2ZXIgd291bGQgZGVjcnlwdCB0aGUgTUFDIGZpZWxk LCB0aGVuIGhhc2ggdGhlIGRhdGEgYW5kIHZlcmlmeSB0aGUgaGFzaCBhZ2FpbnN0IHRoZSBkZWNy eXB0ZWQgTUFDLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm O2NvbG9yOiM3MDMwQTAiPlRoaXMgd2F5LCB0aGUgcHJpdmF0ZSBrZXkgbmV2ZXIgbmVlZHMgdG8g YmUgZXhwb3NlZCB0byBhbnlvbmUsIHNpbXBsaWZ5aW5nIGtleSBtYW5hZ2VtZW50Ljwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPklz IHRoZXJlIGFueSBvYmplY3Rpb24gdG8gZ2V0dGluZyB0aGlzIGRvbmU/PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+U2VlIGFib3ZlOyBpdCBkb2VzbuKAmXQgbWFrZSBzZW5zZSB3aXRoIHRoZSB3YXkg VENQLUFPIGRlcml2ZXMga2V5cyBmb3IgZWFjaCBjb25uZWN0aW9uLCBBRkFJQ1QuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvZTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+ UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtj b2xvcjojNzAzMEEwIj5KYWtvYi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQp0Y3BtIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86dGNwbUBpZXRm Lm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTU0RjcyIj50Y3BtQGlldGYub3JnPC9zcGFu PjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5 NTRGNzIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbTwvc3Bhbj48 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KdGNwbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86dGNwbUBp ZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+dGNwbUBpZXRmLm9yZzwvc3Bhbj48 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 Y3BtIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3RjcG08L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQp0Y3BtIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWls dG86dGNwbUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGUiPnRjcG1AaWV0 Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rj cG08L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_bd707072e91b420d93dd898f69d94898XCHALN014ciscocom_-- From nobody Mon Oct 29 19:55:08 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34616126DBF for ; Mon, 29 Oct 2018 19:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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] 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 zchQCXolwlcx for ; Mon, 29 Oct 2018 19:55:03 -0700 (PDT) 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 A7B47123FFD for ; Mon, 29 Oct 2018 19:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type: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=2ZfDryRuP8Eb8RbhsS7Vwpa4H+Xyl8IEyV8Y3KzdCDk=; b=k5KzIb8Z9YvpAvJ/nlk7hlVSe IDg//2arUpq/aurWzAblZpTR5+geDaN2DaOlUR2hifwsqyA1bX7wN9IE1ESJ4HOEznkBwt6/vsRwE 8DTOfTy+ySKGQXDtlJal/d3dCEa5AfRfW0rrtwGGfiVr35KNX1tDrOP0Vt2ANEf8uWFlYsOcmX6LT y8SShQaE0tDm92phirMsFWtlXCBKydxm2gq49gDw1ttAw0s7/4wdsqTjXPHDkeiY1nyWO7XoprLnT IumWg9kWCQZaADcQo1xVPMVHVd2V5JDFi1HXnGqkTPQgeGqu3+O8bHF6Wb10ZOSRIg+crVKpZWKz4 Lk5XQ7brA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:55880 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gHKBF-002oRQ-UJ; Mon, 29 Oct 2018 22:55:01 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_BC64B9E1-EAA6-4D4E-9CA1-C9B3AF14100E" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: Date: Mon, 29 Oct 2018 19:54:55 -0700 Cc: "tcpm@ietf.org" Message-Id: <68FFD5DF-E6B1-4E3A-B5F7-AB5114DA1BA0@strayalpha.com> References: <95f4b81948844b2799ecca33450bdde1@XCH-ALN-014.cisco.com> <7597333b9a414761be688375acf48dd6@XCH-ALN-014.cisco.com> <0C168054-E3D6-4BC5-9E1E-A28059F1A27B@strayalpha.com> <12b0f677e60443d8a32b4d56370787d7@XCH-ALN-014.cisco.com> <4C874E0B-BB5D-4765-8A33-3B9C736B646B@strayalpha.com> To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.3445.9.1) 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: Subject: Re: [tcpm] public-private keys for TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 02:55:06 -0000 --Apple-Mail=_BC64B9E1-EAA6-4D4E-9CA1-C9B3AF14100E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 You=E2=80=99d want basically one per connection (the point is to avoid = reusing them). You=E2=80=99d be surprised how many connections a pair of = endpoints use over time. Joe > On Oct 29, 2018, at 7:00 PM, Jakob Heitz (jheitz) = wrote: >=20 > There are use cases where I don't need to generate a LOT. > One a month should be just fine, because I have no fear of them = leaking into enemy hands. > I posit that distributing one shared secret key is a LOT harder than = distributing 1000 public keys. > =20 > Regards, > Jakob. > =20 > From: Joe Touch >=20= > Sent: Monday, October 29, 2018 6:49 PM > To: Jakob Heitz (jheitz) > > Cc: tcpm@ietf.org > Subject: Re: [tcpm] public-private keys for TCP-AO > =20 > =20 >=20 >=20 > On Oct 29, 2018, at 6:41 PM, Jakob Heitz (jheitz) > wrote: > =20 > Because distributing public keys is easier. > Private keys don't need to be distributed. They stay inside the = machine that generates them. > =20 > Sure, but you need to generate private/public key pairs on both sides = of the connection - many of them - and then distribute them to both = sides. I.e., the work gets a LOT larger. > =20 > =20 > Distributing and safe guarding symmetric keys is a major hassle. > =20 > Agreed, but you only need one such shared key between each endpoint = pair because you can derive session keys algorithmically. > =20 > You can certainly TRY to work out the details as you suggest, but I = suspect the number of keys needed would be prohibitive even for a single = pair of endpoints. > =20 > Joe >=20 >=20 > =20 > Regards, > Jakob. > =20 > From: Joe Touch >=20= > Sent: Monday, October 29, 2018 6:37 PM > To: Jakob Heitz (jheitz) > > Cc: tcpm@ietf.org > Subject: Re: [tcpm] public-private keys for TCP-AO > =20 > =20 >=20 >=20 >=20 > On Oct 29, 2018, at 6:22 PM, Jakob Heitz (jheitz) > wrote: > =20 > Can you think of a way to do it that will work? > Like the KDF is just a static list or something. > The sender generates a set of key pairs and numbers them. > It then puts the list of public keys into a file and distributes them = to all receivers in the clear. > =20 > You=E2=80=99d have to find a way to specify the use of private and = public keys on both sides, in advance, and distribute enough for the = upcoming connections - then you=E2=80=99d have to hash into that list in = a way that avoids reuse. At that point, why not just distribute = symmetric keys and be done with it? > =20 > Joe > =20 > The KDF is just to index into this file. > =20 > Because the use case, at least, makes sense. > =20 > Regards, > Jakob. > =20 > From: Joe Touch >=20= > Sent: Monday, October 29, 2018 6:13 PM > To: Jakob Heitz (jheitz) > > Cc: tcpm@ietf.org > Subject: Re: [tcpm] public-private keys for TCP-AO > =20 > =20 >=20 >=20 >=20 >=20 > On Oct 29, 2018, at 5:45 PM, Jakob Heitz (jheitz) > wrote: > =20 > Why was there not a public-private key algorithm specified for TCP-AO? = Or did I miss it? > =20 > There has not been. I doubt it would make sense (see below). >=20 >=20 >=20 >=20 > For example ECC. > An MKT can specify a private key for the sender and a public key for = the receivers. > =20 > Yes, but the MKT is derived into public/private keys using a KDF. > =20 > I am not aware of a KDF that can take a private key and generate a = derived private key that would work with a correspondingly derived = public key generated from the corresponding public key. > =20 > To use, the sender will hash the data, encrypt the hash and put the = result into the MAC field. > The receiver would decrypt the MAC field, then hash the data and = verify the hash against the decrypted MAC. > This way, the private key never needs to be exposed to anyone, = simplifying key management. > Is there any objection to getting this done? > =20 > See above; it doesn=E2=80=99t make sense with the way TCP-AO derives = keys for each connection, AFAICT. > =20 > Joe >=20 >=20 >=20 >=20 > =20 > Regards, > Jakob. > =20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = > =20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = > =20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = > =20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = --Apple-Mail=_BC64B9E1-EAA6-4D4E-9CA1-C9B3AF14100E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 You=E2=80=99d want basically one per connection (the point is = to avoid reusing them). You=E2=80=99d be surprised how many connections = a pair of endpoints use over time.

Joe

On Oct 29, 2018, at 7:00 PM, Jakob Heitz (jheitz) <jheitz@cisco.com> = wrote:

There are use = cases where I don't need to generate a LOT.
One a month = should be just fine, because I have no fear of them leaking into enemy = hands.
I = posit that distributing one shared secret key is a LOT harder than = distributing 1000 public keys.
 
Regards,
Jakob.
 
From: Joe Touch <touch@strayalpha.com> 
Sent: Monday, October 29, 2018 = 6:49 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: tcpm@ietf.org
Subject: Re: [tcpm] public-private = keys for TCP-AO
 
 


On Oct 29, 2018, at 6:41 PM, Jakob Heitz = (jheitz) <jheitz@cisco.com> = wrote:
 
Because distributing public keys = is easier.
Private keys don't need to be distributed. They stay = inside the machine that generates them.
 
Sure, but you need to generate = private/public key pairs on both sides of the connection - many of them = - and then distribute them to both sides. I.e., the work gets a LOT = larger.
 
 
Distributing and safe guarding = symmetric keys is a major hassle.
 
Agreed, but you only need one such = shared key between each endpoint pair because you can derive session = keys algorithmically.
 
You can certainly TRY to work out the = details as you suggest, but I suspect the number of keys needed would be = prohibitive even for a single pair of endpoints.
 
Joe


 
Regards,
Jakob.
 
From: Joe Touch <touch@strayalpha.com> 
Sent: Monday, October 29, 2018 = 6:37 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: tcpm@ietf.org
Subject: Re: [tcpm] public-private = keys for TCP-AO
 
 



On Oct 29, 2018, at 6:22 = PM, Jakob Heitz (jheitz) <jheitz@cisco.com> = wrote:
 
Can you think of a way to do it = that will work?
Like the KDF is = just a static list or something.
The sender generates a set of key pairs and numbers = them.
It then puts the list of public = keys into a file and distributes them to all receivers in the = clear.
 
You=E2=80=99d have to = find a way to specify the use of private and public keys on both sides, = in advance, and distribute enough for the upcoming connections - then = you=E2=80=99d have to hash into that list in a way that avoids reuse. At = that point, why not just distribute symmetric keys and be done with = it?
 
Joe
 
The KDF is just to index into this = file.
 
Because the use case, at least, makes = sense.
 
Regards,
Jakob.
 
From: Joe Touch <touch@strayalpha.com> 
Sent: Monday, October 29, 2018 = 6:13 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: tcpm@ietf.org
Subject: Re: [tcpm] public-private = keys for TCP-AO
 
 




On Oct 29, = 2018, at 5:45 PM, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
 
Why was there = not a public-private key algorithm specified for TCP-AO? Or did I miss = it?
 
There has not been. I doubt it would make sense (see = below).




For example = ECC.
An = MKT can specify a private key for the sender and a public key for the = receivers.
 
Yes, but the MKT is derived into public/private keys using a = KDF.
 
I am not aware of a KDF that can take a private key = and generate a derived private key that would work with a = correspondingly derived public key generated from the corresponding = public key.
 
To use, the = sender will hash the data, encrypt the hash and put the result into the = MAC field.
The = receiver would decrypt the MAC field, then hash the data and verify the = hash against the decrypted MAC.
This way, the = private key never needs to be exposed to anyone, simplifying key = management.
Is = there any objection to getting this done?
 
See above; = it doesn=E2=80=99t make sense with the way TCP-AO derives keys for each = connection, AFAICT.
 
Joe




 
Regards,
Jakob.
 
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
 
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
 
_______________________________________________tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
 
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

= --Apple-Mail=_BC64B9E1-EAA6-4D4E-9CA1-C9B3AF14100E-- From nobody Mon Oct 29 20:19:49 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1E8127598 for ; Mon, 29 Oct 2018 20:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 oMBbWC5-azRq for ; Mon, 29 Oct 2018 20:19:46 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43FA51277BB for ; Mon, 29 Oct 2018 20:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40604; q=dns/txt; s=iport; t=1540869586; x=1542079186; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lY1mcHb6aMTPGNlijLtReZXhr6DUD6O2+fwyOJBpDd4=; b=Lf08CpH6HlJ3csWO48hyub7eVrbkEKkEN3agEfqvBa4r7qbUKe+Enj+K 4n1A+2NhcPAyALBFL0rPIyEJAvggmIMu3iev8a6bqSFkqHHmOtCpk2HDf KrFX9sX5VTA8K+6AxPIBzyLxA8ed0QJLe9SoDuGltF3+euHFOTS5ahYh9 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAABjzddb/4ENJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDUgvZn8oCoNriBiMGYINlyCBdwMLAQEYAQq?= =?us-ascii?q?ESQIXgxYhNA0NAQMBAQIBAQJtHAyFOgEBAQEDAQEhCkELEAIBCBEEAQEhAQY?= =?us-ascii?q?DAgICJQsUCQgCBA4FCIMagR1kD6ligS6KHAWLSR4XgUE/hCNZgkIBAYIXgk6?= =?us-ascii?q?CVwKIVxKFYYYiiUlUCQKQeiCNZoJhlnUCERSBJh04gVVwFTuCbIIlAReIXIU?= =?us-ascii?q?+b4wGgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,442,1534809600"; d="scan'208,217";a="462770339" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2018 03:19:25 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id w9U3JOXc026555 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Oct 2018 03:19:25 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 29 Oct 2018 22:19:23 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1395.000; Mon, 29 Oct 2018 22:19:24 -0500 From: "Jakob Heitz (jheitz)" To: Joe Touch CC: "tcpm@ietf.org" Thread-Topic: [tcpm] public-private keys for TCP-AO Thread-Index: AdRv51Oca8SVyggpTLame1T3B/a0kQAME/iAAApbkFD//7O5gIAAU4Pg//+v9oCAAFNQ4P//vwuAgABNFSA= Date: Tue, 30 Oct 2018 03:19:24 +0000 Message-ID: References: <95f4b81948844b2799ecca33450bdde1@XCH-ALN-014.cisco.com> <7597333b9a414761be688375acf48dd6@XCH-ALN-014.cisco.com> <0C168054-E3D6-4BC5-9E1E-A28059F1A27B@strayalpha.com> <12b0f677e60443d8a32b4d56370787d7@XCH-ALN-014.cisco.com> <4C874E0B-BB5D-4765-8A33-3B9C736B646B@strayalpha.com> <68FFD5DF-E6B1-4E3A-B5F7-AB5114DA1BA0@strayalpha.com> In-Reply-To: <68FFD5DF-E6B1-4E3A-B5F7-AB5114DA1BA0@strayalpha.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.29.185] Content-Type: multipart/alternative; boundary="_000_eae2d83112e04871ba30bd300f210bceXCHALN014ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.21, xch-rcd-011.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [tcpm] public-private keys for TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 03:19:49 -0000 --_000_eae2d83112e04871ba30bd300f210bceXCHALN014ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2suDQpTaGFsbCBJIHdyaXRlIGEgZHJhZnQ/DQoNClJlZ2FyZHMsDQpKYWtvYi4NCg0KRnJvbTog Sm9lIFRvdWNoIDx0b3VjaEBzdHJheWFscGhhLmNvbT4NClNlbnQ6IE1vbmRheSwgT2N0b2JlciAy OSwgMjAxOCA3OjU1IFBNDQpUbzogSmFrb2IgSGVpdHogKGpoZWl0eikgPGpoZWl0ekBjaXNjby5j b20+DQpDYzogdGNwbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt0Y3BtXSBwdWJsaWMtcHJpdmF0 ZSBrZXlzIGZvciBUQ1AtQU8NCg0KWW914oCZZCB3YW50IGJhc2ljYWxseSBvbmUgcGVyIGNvbm5l Y3Rpb24gKHRoZSBwb2ludCBpcyB0byBhdm9pZCByZXVzaW5nIHRoZW0pLiBZb3XigJlkIGJlIHN1 cnByaXNlZCBob3cgbWFueSBjb25uZWN0aW9ucyBhIHBhaXIgb2YgZW5kcG9pbnRzIHVzZSBvdmVy IHRpbWUuDQoNCkpvZQ0KDQoNCk9uIE9jdCAyOSwgMjAxOCwgYXQgNzowMCBQTSwgSmFrb2IgSGVp dHogKGpoZWl0eikgPGpoZWl0ekBjaXNjby5jb208bWFpbHRvOmpoZWl0ekBjaXNjby5jb20+PiB3 cm90ZToNCg0KVGhlcmUgYXJlIHVzZSBjYXNlcyB3aGVyZSBJIGRvbid0IG5lZWQgdG8gZ2VuZXJh dGUgYSBMT1QuDQpPbmUgYSBtb250aCBzaG91bGQgYmUganVzdCBmaW5lLCBiZWNhdXNlIEkgaGF2 ZSBubyBmZWFyIG9mIHRoZW0gbGVha2luZyBpbnRvIGVuZW15IGhhbmRzLg0KSSBwb3NpdCB0aGF0 IGRpc3RyaWJ1dGluZyBvbmUgc2hhcmVkIHNlY3JldCBrZXkgaXMgYSBMT1QgaGFyZGVyIHRoYW4g ZGlzdHJpYnV0aW5nIDEwMDAgcHVibGljIGtleXMuDQoNClJlZ2FyZHMsDQpKYWtvYi4NCg0KRnJv bTogSm9lIFRvdWNoIDx0b3VjaEBzdHJheWFscGhhLmNvbTxtYWlsdG86dG91Y2hAc3RyYXlhbHBo YS5jb20+Pg0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDI5LCAyMDE4IDY6NDkgUE0NClRvOiBKYWtv YiBIZWl0eiAoamhlaXR6KSA8amhlaXR6QGNpc2NvLmNvbTxtYWlsdG86amhlaXR6QGNpc2NvLmNv bT4+DQpDYzogdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbdGNwbV0gcHVibGljLXByaXZhdGUga2V5cyBmb3IgVENQLUFPDQoNCg0KDQoNCg0KT24gT2N0 IDI5LCAyMDE4LCBhdCA2OjQxIFBNLCBKYWtvYiBIZWl0eiAoamhlaXR6KSA8amhlaXR6QGNpc2Nv LmNvbTxtYWlsdG86amhlaXR6QGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpCZWNhdXNlIGRpc3RyaWJ1 dGluZyBwdWJsaWMga2V5cyBpcyBlYXNpZXIuDQpQcml2YXRlIGtleXMgZG9uJ3QgbmVlZCB0byBi ZSBkaXN0cmlidXRlZC4gVGhleSBzdGF5IGluc2lkZSB0aGUgbWFjaGluZSB0aGF0IGdlbmVyYXRl cyB0aGVtLg0KDQpTdXJlLCBidXQgeW91IG5lZWQgdG8gZ2VuZXJhdGUgcHJpdmF0ZS9wdWJsaWMg a2V5IHBhaXJzIG9uIGJvdGggc2lkZXMgb2YgdGhlIGNvbm5lY3Rpb24gLSBtYW55IG9mIHRoZW0g LSBhbmQgdGhlbiBkaXN0cmlidXRlIHRoZW0gdG8gYm90aCBzaWRlcy4gSS5lLiwgdGhlIHdvcmsg Z2V0cyBhIExPVCBsYXJnZXIuDQoNCg0KRGlzdHJpYnV0aW5nIGFuZCBzYWZlIGd1YXJkaW5nIHN5 bW1ldHJpYyBrZXlzIGlzIGEgbWFqb3IgaGFzc2xlLg0KDQpBZ3JlZWQsIGJ1dCB5b3Ugb25seSBu ZWVkIG9uZSBzdWNoIHNoYXJlZCBrZXkgYmV0d2VlbiBlYWNoIGVuZHBvaW50IHBhaXIgYmVjYXVz ZSB5b3UgY2FuIGRlcml2ZSBzZXNzaW9uIGtleXMgYWxnb3JpdGhtaWNhbGx5Lg0KDQpZb3UgY2Fu IGNlcnRhaW5seSBUUlkgdG8gd29yayBvdXQgdGhlIGRldGFpbHMgYXMgeW91IHN1Z2dlc3QsIGJ1 dCBJIHN1c3BlY3QgdGhlIG51bWJlciBvZiBrZXlzIG5lZWRlZCB3b3VsZCBiZSBwcm9oaWJpdGl2 ZSBldmVuIGZvciBhIHNpbmdsZSBwYWlyIG9mIGVuZHBvaW50cy4NCg0KSm9lDQoNCg0KDQoNClJl Z2FyZHMsDQpKYWtvYi4NCg0KRnJvbTogSm9lIFRvdWNoIDx0b3VjaEBzdHJheWFscGhhLmNvbTxt YWlsdG86dG91Y2hAc3RyYXlhbHBoYS5jb20+Pg0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDI5LCAy MDE4IDY6MzcgUE0NClRvOiBKYWtvYiBIZWl0eiAoamhlaXR6KSA8amhlaXR6QGNpc2NvLmNvbTxt YWlsdG86amhlaXR6QGNpc2NvLmNvbT4+DQpDYzogdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdGNwbV0gcHVibGljLXByaXZhdGUga2V5cyBmb3IgVENQ LUFPDQoNCg0KDQoNCg0KDQpPbiBPY3QgMjksIDIwMTgsIGF0IDY6MjIgUE0sIEpha29iIEhlaXR6 IChqaGVpdHopIDxqaGVpdHpAY2lzY28uY29tPG1haWx0bzpqaGVpdHpAY2lzY28uY29tPj4gd3Jv dGU6DQoNCkNhbiB5b3UgdGhpbmsgb2YgYSB3YXkgdG8gZG8gaXQgdGhhdCB3aWxsIHdvcms/DQpM aWtlIHRoZSBLREYgaXMganVzdCBhIHN0YXRpYyBsaXN0IG9yIHNvbWV0aGluZy4NClRoZSBzZW5k ZXIgZ2VuZXJhdGVzIGEgc2V0IG9mIGtleSBwYWlycyBhbmQgbnVtYmVycyB0aGVtLg0KSXQgdGhl biBwdXRzIHRoZSBsaXN0IG9mIHB1YmxpYyBrZXlzIGludG8gYSBmaWxlIGFuZCBkaXN0cmlidXRl cyB0aGVtIHRvIGFsbCByZWNlaXZlcnMgaW4gdGhlIGNsZWFyLg0KDQpZb3XigJlkIGhhdmUgdG8g ZmluZCBhIHdheSB0byBzcGVjaWZ5IHRoZSB1c2Ugb2YgcHJpdmF0ZSBhbmQgcHVibGljIGtleXMg b24gYm90aCBzaWRlcywgaW4gYWR2YW5jZSwgYW5kIGRpc3RyaWJ1dGUgZW5vdWdoIGZvciB0aGUg dXBjb21pbmcgY29ubmVjdGlvbnMgLSB0aGVuIHlvdeKAmWQgaGF2ZSB0byBoYXNoIGludG8gdGhh dCBsaXN0IGluIGEgd2F5IHRoYXQgYXZvaWRzIHJldXNlLiBBdCB0aGF0IHBvaW50LCB3aHkgbm90 IGp1c3QgZGlzdHJpYnV0ZSBzeW1tZXRyaWMga2V5cyBhbmQgYmUgZG9uZSB3aXRoIGl0Pw0KDQpK b2UNCg0KVGhlIEtERiBpcyBqdXN0IHRvIGluZGV4IGludG8gdGhpcyBmaWxlLg0KDQpCZWNhdXNl IHRoZSB1c2UgY2FzZSwgYXQgbGVhc3QsIG1ha2VzIHNlbnNlLg0KDQpSZWdhcmRzLA0KSmFrb2Iu DQoNCkZyb206IEpvZSBUb3VjaCA8dG91Y2hAc3RyYXlhbHBoYS5jb208bWFpbHRvOnRvdWNoQHN0 cmF5YWxwaGEuY29tPj4NClNlbnQ6IE1vbmRheSwgT2N0b2JlciAyOSwgMjAxOCA2OjEzIFBNDQpU bzogSmFrb2IgSGVpdHogKGpoZWl0eikgPGpoZWl0ekBjaXNjby5jb208bWFpbHRvOmpoZWl0ekBj aXNjby5jb20+Pg0KQ2M6IHRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW3RjcG1dIHB1YmxpYy1wcml2YXRlIGtleXMgZm9yIFRDUC1BTw0KDQoNCg0KDQoN Cg0KDQpPbiBPY3QgMjksIDIwMTgsIGF0IDU6NDUgUE0sIEpha29iIEhlaXR6IChqaGVpdHopIDxq aGVpdHpAY2lzY28uY29tPG1haWx0bzpqaGVpdHpAY2lzY28uY29tPj4gd3JvdGU6DQoNCldoeSB3 YXMgdGhlcmUgbm90IGEgcHVibGljLXByaXZhdGUga2V5IGFsZ29yaXRobSBzcGVjaWZpZWQgZm9y IFRDUC1BTz8gT3IgZGlkIEkgbWlzcyBpdD8NCg0KVGhlcmUgaGFzIG5vdCBiZWVuLiBJIGRvdWJ0 IGl0IHdvdWxkIG1ha2Ugc2Vuc2UgKHNlZSBiZWxvdykuDQoNCg0KDQoNCg0KRm9yIGV4YW1wbGUg RUNDLg0KQW4gTUtUIGNhbiBzcGVjaWZ5IGEgcHJpdmF0ZSBrZXkgZm9yIHRoZSBzZW5kZXIgYW5k IGEgcHVibGljIGtleSBmb3IgdGhlIHJlY2VpdmVycy4NCg0KWWVzLCBidXQgdGhlIE1LVCBpcyBk ZXJpdmVkIGludG8gcHVibGljL3ByaXZhdGUga2V5cyB1c2luZyBhIEtERi4NCg0KSSBhbSBub3Qg YXdhcmUgb2YgYSBLREYgdGhhdCBjYW4gdGFrZSBhIHByaXZhdGUga2V5IGFuZCBnZW5lcmF0ZSBh IGRlcml2ZWQgcHJpdmF0ZSBrZXkgdGhhdCB3b3VsZCB3b3JrIHdpdGggYSBjb3JyZXNwb25kaW5n bHkgZGVyaXZlZCBwdWJsaWMga2V5IGdlbmVyYXRlZCBmcm9tIHRoZSBjb3JyZXNwb25kaW5nIHB1 YmxpYyBrZXkuDQoNClRvIHVzZSwgdGhlIHNlbmRlciB3aWxsIGhhc2ggdGhlIGRhdGEsIGVuY3J5 cHQgdGhlIGhhc2ggYW5kIHB1dCB0aGUgcmVzdWx0IGludG8gdGhlIE1BQyBmaWVsZC4NClRoZSBy ZWNlaXZlciB3b3VsZCBkZWNyeXB0IHRoZSBNQUMgZmllbGQsIHRoZW4gaGFzaCB0aGUgZGF0YSBh bmQgdmVyaWZ5IHRoZSBoYXNoIGFnYWluc3QgdGhlIGRlY3J5cHRlZCBNQUMuDQpUaGlzIHdheSwg dGhlIHByaXZhdGUga2V5IG5ldmVyIG5lZWRzIHRvIGJlIGV4cG9zZWQgdG8gYW55b25lLCBzaW1w bGlmeWluZyBrZXkgbWFuYWdlbWVudC4NCklzIHRoZXJlIGFueSBvYmplY3Rpb24gdG8gZ2V0dGlu ZyB0aGlzIGRvbmU/DQoNClNlZSBhYm92ZTsgaXQgZG9lc27igJl0IG1ha2Ugc2Vuc2Ugd2l0aCB0 aGUgd2F5IFRDUC1BTyBkZXJpdmVzIGtleXMgZm9yIGVhY2ggY29ubmVjdGlvbiwgQUZBSUNULg0K DQpKb2UNCg0KDQoNCg0KDQoNClJlZ2FyZHMsDQpKYWtvYi4NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRjcG0gbWFpbGluZyBsaXN0DQp0Y3BtQGll dGYub3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90Y3BtDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQp0Y3BtIG1haWxpbmcgbGlzdA0KdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdGNwbSBtYWls aW5nIGxpc3QNCnRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnRjcG0gbWFpbGluZyBsaXN0DQp0Y3BtQGlldGYu b3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90Y3BtDQoNCg== --_000_eae2d83112e04871ba30bd300f210bceXCHALN014ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIg MSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IlxARGVuZ1hpYW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRp di5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJ e21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciLHNlcmlmOw0KCWNvbG9yOiM3MDMwQTA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm O2NvbG9yOiM3MDMwQTAiPk9rLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPlNoYWxsIEkgd3JpdGUgYSBkcmFm dD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oyxz ZXJpZjtjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+UmVnYXJk cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oyxz ZXJpZjtjb2xvcjojNzAzMEEwIj5KYWtvYi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiBKb2UgVG91Y2ggJmx0O3RvdWNoQHN0cmF5YWxwaGEuY29tJmd0 Ow0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgT2N0b2JlciAyOSwgMjAxOCA3OjU1IFBNPGJy Pg0KPGI+VG86PC9iPiBKYWtvYiBIZWl0eiAoamhlaXR6KSAmbHQ7amhlaXR6QGNpc2NvLmNvbSZn dDs8YnI+DQo8Yj5DYzo8L2I+IHRjcG1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFt0Y3BtXSBwdWJsaWMtcHJpdmF0ZSBrZXlzIGZvciBUQ1AtQU88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3XigJlkIHdhbnQgYmFzaWNhbGx5IG9uZSBw ZXIgY29ubmVjdGlvbiAodGhlIHBvaW50IGlzIHRvIGF2b2lkIHJldXNpbmcgdGhlbSkuIFlvdeKA mWQgYmUgc3VycHJpc2VkIGhvdyBtYW55IGNvbm5lY3Rpb25zIGEgcGFpciBvZiBlbmRwb2ludHMg dXNlIG92ZXIgdGltZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkpvZTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIE9jdCAyOSwgMjAxOCwgYXQgNzowMCBQTSwgSmFrb2IgSGVpdHogKGpoZWl0eikgJmx0 OzxhIGhyZWY9Im1haWx0bzpqaGVpdHpAY2lzY28uY29tIj5qaGVpdHpAY2lzY28uY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5UaGVyZSBhcmUgdXNlIGNhc2VzIHdoZXJlIEkg ZG9uJ3QgbmVlZCB0byBnZW5lcmF0ZSBhIExPVC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAz MEEwIj5PbmUgYSBtb250aCBzaG91bGQgYmUganVzdCBmaW5lLCBiZWNhdXNlIEkgaGF2ZSBubyBm ZWFyIG9mIHRoZW0gbGVha2luZyBpbnRvIGVuZW15IGhhbmRzLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2Nv bG9yOiM3MDMwQTAiPkkgcG9zaXQgdGhhdCBkaXN0cmlidXRpbmcgb25lIHNoYXJlZCBzZWNyZXQg a2V5IGlzIGEgTE9UIGhhcmRlciB0aGFuIGRpc3RyaWJ1dGluZyAxMDAwIHB1YmxpYyBrZXlzLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oyxz ZXJpZjtjb2xvcjojNzAzMEEwIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMw QTAiPkpha29iLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkpvZQ0KIFRv dWNoICZsdDs8YSBocmVmPSJtYWlsdG86dG91Y2hAc3RyYXlhbHBoYS5jb20iPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPnRvdWNoQHN0cmF5YWxwaGEuY29tPC9zcGFuPjwvYT4mZ3Q7PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6 PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Nb25k YXksIE9jdG9iZXIgMjksIDIwMTggNjo0OSBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+SmFrb2IgSGVpdHogKGpoZWl0eikg Jmx0OzxhIGhyZWY9Im1haWx0bzpqaGVpdHpAY2lzY28uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5qaGVpdHpAY2lzY28uY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJt YWlsdG86dGNwbUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+dGNwbUBpZXRm Lm9yZzwvc3Bhbj48L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbdGNwbV0gcHVibGljLXByaXZhdGUga2V5 cyBmb3IgVENQLUFPPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBPY3QgMjksIDIwMTgsIGF0IDY6NDEgUE0sIEpha29iIEhlaXR6IChqaGVpdHop ICZsdDs8YSBocmVmPSJtYWlsdG86amhlaXR6QGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+amhlaXR6QGNpc2NvLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPkJlY2F1c2UgZGlzdHJpYnV0 aW5nIHB1YmxpYyBrZXlzIGlzIGVhc2llci48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJp Zjtjb2xvcjojNzAzMEEwIj5Qcml2YXRlIGtleXMgZG9uJ3QgbmVlZCB0byBiZSBkaXN0cmlidXRl ZC4gVGhleSBzdGF5IGluc2lkZSB0aGUgbWFjaGluZSB0aGF0IGdlbmVyYXRlcyB0aGVtLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdXJl LCBidXQgeW91IG5lZWQgdG8gZ2VuZXJhdGUgcHJpdmF0ZS9wdWJsaWMga2V5IHBhaXJzIG9uIGJv dGggc2lkZXMgb2YgdGhlIGNvbm5lY3Rpb24gLSBtYW55IG9mIHRoZW0gLSBhbmQgdGhlbiBkaXN0 cmlidXRlIHRoZW0gdG8gYm90aCBzaWRlcy4gSS5lLiwgdGhlIHdvcmsgZ2V0cyBhIExPVCBsYXJn ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2Nv bG9yOiM3MDMwQTAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9y OiM3MDMwQTAiPkRpc3RyaWJ1dGluZyBhbmQgc2FmZSBndWFyZGluZyBzeW1tZXRyaWMga2V5cyBp cyBhIG1ham9yIGhhc3NsZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QWdyZWVkLCBidXQgeW91IG9ubHkgbmVlZCBvbmUgc3VjaCBzaGFy ZWQga2V5IGJldHdlZW4gZWFjaCBlbmRwb2ludCBwYWlyIGJlY2F1c2UgeW91IGNhbiBkZXJpdmUg c2Vzc2lvbiBrZXlzIGFsZ29yaXRobWljYWxseS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ WW91IGNhbiBjZXJ0YWlubHkgVFJZIHRvIHdvcmsgb3V0IHRoZSBkZXRhaWxzIGFzIHlvdSBzdWdn ZXN0LCBidXQgSSBzdXNwZWN0IHRoZSBudW1iZXIgb2Yga2V5cyBuZWVkZWQgd291bGQgYmUgcHJv aGliaXRpdmUgZXZlbiBmb3IgYSBzaW5nbGUgcGFpciBvZiBlbmRwb2ludHMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkpvZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5KYWtvYi48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Kb2UNCiBUb3Vj aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvdWNoQHN0cmF5YWxwaGEuY29tIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj50b3VjaEBzdHJheWFscGhhLmNvbTwvc3Bhbj48L2E+Jmd0OzxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50Ojwv Yj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TW9uZGF5 LCBPY3RvYmVyIDI5LCAyMDE4IDY6MzcgUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkpha29iIEhlaXR6IChqaGVpdHopICZs dDs8YSBocmVmPSJtYWlsdG86amhlaXR6QGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+amhlaXR6QGNpc2NvLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOnRjcG1AaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnRjcG1AaWV0Zi5v cmc8L3NwYW4+PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW3RjcG1dIHB1YmxpYy1wcml2YXRlIGtleXMg Zm9yIFRDUC1BTzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gT2N0IDI5LCAyMDE4LCBhdCA2OjIyIFBNLCBKYWtvYiBIZWl0eiAo amhlaXR6KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpoZWl0ekBjaXNjby5jb20iPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPmpoZWl0ekBjaXNjby5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oyxz ZXJpZjtjb2xvcjojNzAzMEEwIj5DYW4geW91IHRoaW5rIG9mIGEgd2F5IHRvIGRvIGl0IHRoYXQg d2lsbCB3b3JrPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm O2NvbG9yOiM3MDMwQTAiPkxpa2UgdGhlIEtERiBpcyBqdXN0IGEgc3RhdGljIGxpc3Qgb3Igc29t ZXRoaW5nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2Nv bG9yOiM3MDMwQTAiPlRoZSBzZW5kZXIgZ2VuZXJhdGVzIGEgc2V0IG9mIGtleSBwYWlycyBhbmQg bnVtYmVycyB0aGVtLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNl cmlmO2NvbG9yOiM3MDMwQTAiPkl0IHRoZW4gcHV0cyB0aGUgbGlzdCBvZiBwdWJsaWMga2V5cyBp bnRvIGEgZmlsZSBhbmQgZGlzdHJpYnV0ZXMgdGhlbSB0byBhbGwgcmVjZWl2ZXJzIGluIHRoZSBj bGVhci48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW914oCZZCBoYXZlIHRvIGZpbmQg YSB3YXkgdG8gc3BlY2lmeSB0aGUgdXNlIG9mIHByaXZhdGUgYW5kIHB1YmxpYyBrZXlzIG9uIGJv dGggc2lkZXMsIGluIGFkdmFuY2UsIGFuZCBkaXN0cmlidXRlIGVub3VnaCBmb3IgdGhlIHVwY29t aW5nIGNvbm5lY3Rpb25zIC0gdGhlbiB5b3XigJlkIGhhdmUgdG8gaGFzaCBpbnRvIHRoYXQgbGlz dCBpbiBhIHdheSB0aGF0IGF2b2lkcyByZXVzZS4gQXQgdGhhdCBwb2ludCwgd2h5DQogbm90IGp1 c3QgZGlzdHJpYnV0ZSBzeW1tZXRyaWMga2V5cyBhbmQgYmUgZG9uZSB3aXRoIGl0PzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2U8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+VGhlIEtERiBpcyBqdXN0IHRvIGlu ZGV4IGludG8gdGhpcyBmaWxlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPkJlY2F1c2UgdGhlIHVzZSBjYXNl LCBhdCBsZWFzdCwgbWFrZXMgc2Vuc2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPlJlZ2FyZHMs PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6Izcw MzBBMCI+SmFrb2IuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Sm9l DQogVG91Y2ggJmx0OzxhIGhyZWY9Im1haWx0bzp0b3VjaEBzdHJheWFscGhhLmNvbSI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+dG91Y2hAc3RyYXlhbHBoYS5jb208L3NwYW4+PC9hPiZndDs8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+ U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pk1vbmRheSwgT2N0b2JlciAyOSwgMjAxOCA2OjEzIFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5KYWtvYiBIZWl0eiAoamhl aXR6KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpoZWl0ekBjaXNjby5jb20iPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPmpoZWl0ekBjaXNjby5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5DYzo8 L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhy ZWY9Im1haWx0bzp0Y3BtQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj50Y3Bt QGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFt0Y3BtXSBwdWJsaWMtcHJpdmF0 ZSBrZXlzIGZvciBUQ1AtQU88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE9jdCAyOSwgMjAxOCwgYXQgNTo0NSBQ TSwgSmFrb2IgSGVpdHogKGpoZWl0eikgJmx0OzxhIGhyZWY9Im1haWx0bzpqaGVpdHpAY2lzY28u Y29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5qaGVpdHpAY2lzY28uY29tPC9zcGFuPjwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6 IzcwMzBBMCI+V2h5IHdhcyB0aGVyZSBub3QgYSBwdWJsaWMtcHJpdmF0ZSBrZXkgYWxnb3JpdGht IHNwZWNpZmllZCBmb3IgVENQLUFPPyBPciBkaWQgSSBtaXNzIGl0Pzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBoYXMgbm90 IGJlZW4uIEkgZG91YnQgaXQgd291bGQgbWFrZSBzZW5zZSAoc2VlIGJlbG93KS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29s b3I6IzcwMzBBMCI+Rm9yIGV4YW1wbGUgRUNDLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPkFuIE1LVCBj YW4gc3BlY2lmeSBhIHByaXZhdGUga2V5IGZvciB0aGUgc2VuZGVyIGFuZCBhIHB1YmxpYyBrZXkg Zm9yIHRoZSByZWNlaXZlcnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgYnV0IHRoZSBNS1QgaXMgZGVyaXZlZCBpbnRvIHB1 YmxpYy9wcml2YXRlIGtleXMgdXNpbmcgYSBLREYuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgYW0gbm90IGF3YXJlIG9mIGEgS0RGIHRoYXQgY2FuIHRha2UgYSBwcml2YXRlIGtleSBh bmQgZ2VuZXJhdGUgYSBkZXJpdmVkIHByaXZhdGUga2V5IHRoYXQgd291bGQgd29yayB3aXRoIGEg Y29ycmVzcG9uZGluZ2x5IGRlcml2ZWQgcHVibGljIGtleSBnZW5lcmF0ZWQgZnJvbSB0aGUgY29y cmVzcG9uZGluZyBwdWJsaWMga2V5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5UbyB1c2UsIHRoZSBzZW5kZXIgd2ls bCBoYXNoIHRoZSBkYXRhLCBlbmNyeXB0IHRoZSBoYXNoIGFuZCBwdXQgdGhlIHJlc3VsdCBpbnRv IHRoZSBNQUMgZmllbGQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+VGhlIHJlY2VpdmVyIHdvdWxkIGRl Y3J5cHQgdGhlIE1BQyBmaWVsZCwgdGhlbiBoYXNoIHRoZSBkYXRhIGFuZCB2ZXJpZnkgdGhlIGhh c2ggYWdhaW5zdCB0aGUgZGVjcnlwdGVkIE1BQy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5UaGlzIHdh eSwgdGhlIHByaXZhdGUga2V5IG5ldmVyIG5lZWRzIHRvIGJlIGV4cG9zZWQgdG8gYW55b25lLCBz aW1wbGlmeWluZyBrZXkgbWFuYWdlbWVudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5JcyB0aGVyZSBh bnkgb2JqZWN0aW9uIHRvIGdldHRpbmcgdGhpcyBkb25lPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlZSBhYm92ZTsgaXQgZG9lc27igJl0IG1h a2Ugc2Vuc2Ugd2l0aCB0aGUgd2F5IFRDUC1BTyBkZXJpdmVzIGtleXMgZm9yIGVhY2ggY29ubmVj dGlvbiwgQUZBSUNULjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2U8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNl cmlmO2NvbG9yOiM3MDMwQTAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPlJlZ2FyZHMsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2Vy aWY7Y29sb3I6IzcwMzBBMCI+SmFrb2IuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdGNwbSBtYWlsaW5nIGxpc3Q8YnI+ DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6Izk1NEY3MiI+dGNwbUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdGNwbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTU0RjcyIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG08L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCnRjcG0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv OnRjcG1AaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnRjcG1AaWV0Zi5vcmc8 L3NwYW4+PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdGNwbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90Y3BtPC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdGNwbSBt YWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj50Y3BtQGlldGYub3JnPC9zcGFuPjwvYT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90Y3BtIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0Y3BtIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bh bj48YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpw dXJwbGUiPnRjcG1AaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjwv c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3RjcG08L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_eae2d83112e04871ba30bd300f210bceXCHALN014ciscocom_-- From nobody Mon Oct 29 20:24:37 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85734127B92 for ; Mon, 29 Oct 2018 20:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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] 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 beMirtB7VbxJ for ; Mon, 29 Oct 2018 20:24:30 -0700 (PDT) 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 6524D127598 for ; Mon, 29 Oct 2018 20:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type: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=zyIetHqCjrNE/3pIszb0m/PhYxzrlM46tBFkKjbXDRo=; b=4vMzwrurUVcke7k9qdYqAUWxe sfTMcRhNl7JdfnwsCJlGMRU/7rnDZC0MDi8Z28tL8tKh8gdhpsPNa/8ajKuiBRHDRX+dBt8A/8meQ Zde4Z5Dl0U4j4eY4/kYnNdmt/5jacqFczjLHCLoVHo6MNajlSQMCBgc679fDxLJyK+A3s2q6vOMra kp0u4iTDnEJL4X4Gq4QYnHExMxpaNBh9rnAYXCOpbFZRBNMZhmyVO/i4CgXtUX9l0gGDa77ieBFiU BTVAgMmjlLoOXQZRvIYH5qENeEMwOkxTk3sEfRW3KT/bBAPMDGK9I8h1zeG0BiX6tLhLWK3RgX+Yl 7j20shzIA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:56078 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gHKdo-003C9R-98; Mon, 29 Oct 2018 23:24:29 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_D4CC5173-6612-4B8A-A70F-2D3493C56B1F" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: Date: Mon, 29 Oct 2018 20:24:27 -0700 Cc: "tcpm@ietf.org" Message-Id: References: <95f4b81948844b2799ecca33450bdde1@XCH-ALN-014.cisco.com> <7597333b9a414761be688375acf48dd6@XCH-ALN-014.cisco.com> <0C168054-E3D6-4BC5-9E1E-A28059F1A27B@strayalpha.com> <12b0f677e60443d8a32b4d56370787d7@XCH-ALN-014.cisco.com> <4C874E0B-BB5D-4765-8A33-3B9C736B646B@strayalpha.com> <68FFD5DF-E6B1-4E3A-B5F7-AB5114DA1BA0@strayalpha.com> To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.3445.9.1) 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: Subject: Re: [tcpm] public-private keys for TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 03:24:33 -0000 --Apple-Mail=_D4CC5173-6612-4B8A-A70F-2D3493C56B1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 You certainly can, but I don=E2=80=99t plan to be further involved. My = IETF cycles are spoken for, even for reviews. > On Oct 29, 2018, at 8:19 PM, Jakob Heitz (jheitz) = wrote: >=20 > Ok. > Shall I write a draft? > =20 > Regards, > Jakob. > =20 > From: Joe Touch =20 > Sent: Monday, October 29, 2018 7:55 PM > To: Jakob Heitz (jheitz) > Cc: tcpm@ietf.org > Subject: Re: [tcpm] public-private keys for TCP-AO > =20 > You=E2=80=99d want basically one per connection (the point is to avoid = reusing them). You=E2=80=99d be surprised how many connections a pair of = endpoints use over time. > =20 > Joe >=20 >=20 > On Oct 29, 2018, at 7:00 PM, Jakob Heitz (jheitz) > wrote: > =20 > There are use cases where I don't need to generate a LOT. > One a month should be just fine, because I have no fear of them = leaking into enemy hands. > I posit that distributing one shared secret key is a LOT harder than = distributing 1000 public keys. > =20 > Regards, > Jakob. > =20 > From: Joe Touch >=20= > Sent: Monday, October 29, 2018 6:49 PM > To: Jakob Heitz (jheitz) > > Cc: tcpm@ietf.org > Subject: Re: [tcpm] public-private keys for TCP-AO > =20 > =20 >=20 >=20 >=20 > On Oct 29, 2018, at 6:41 PM, Jakob Heitz (jheitz) > wrote: > =20 > Because distributing public keys is easier. > Private keys don't need to be distributed. They stay inside the = machine that generates them. > =20 > Sure, but you need to generate private/public key pairs on both sides = of the connection - many of them - and then distribute them to both = sides. I.e., the work gets a LOT larger. > =20 > =20 > Distributing and safe guarding symmetric keys is a major hassle. > =20 > Agreed, but you only need one such shared key between each endpoint = pair because you can derive session keys algorithmically. > =20 > You can certainly TRY to work out the details as you suggest, but I = suspect the number of keys needed would be prohibitive even for a single = pair of endpoints. > =20 > Joe >=20 >=20 >=20 > =20 > Regards, > Jakob. > =20 > From: Joe Touch >=20= > Sent: Monday, October 29, 2018 6:37 PM > To: Jakob Heitz (jheitz) > > Cc: tcpm@ietf.org > Subject: Re: [tcpm] public-private keys for TCP-AO > =20 > =20 >=20 >=20 >=20 >=20 > On Oct 29, 2018, at 6:22 PM, Jakob Heitz (jheitz) > wrote: > =20 > Can you think of a way to do it that will work? > Like the KDF is just a static list or something. > The sender generates a set of key pairs and numbers them. > It then puts the list of public keys into a file and distributes them = to all receivers in the clear. > =20 > You=E2=80=99d have to find a way to specify the use of private and = public keys on both sides, in advance, and distribute enough for the = upcoming connections - then you=E2=80=99d have to hash into that list in = a way that avoids reuse. At that point, why not just distribute = symmetric keys and be done with it? > =20 > Joe > =20 > The KDF is just to index into this file. > =20 > Because the use case, at least, makes sense. > =20 > Regards, > Jakob. > =20 > From: Joe Touch >=20= > Sent: Monday, October 29, 2018 6:13 PM > To: Jakob Heitz (jheitz) > > Cc: tcpm@ietf.org > Subject: Re: [tcpm] public-private keys for TCP-AO > =20 > =20 >=20 >=20 >=20 >=20 >=20 > On Oct 29, 2018, at 5:45 PM, Jakob Heitz (jheitz) > wrote: > =20 > Why was there not a public-private key algorithm specified for TCP-AO? = Or did I miss it? > =20 > There has not been. I doubt it would make sense (see below). >=20 >=20 >=20 >=20 >=20 > For example ECC. > An MKT can specify a private key for the sender and a public key for = the receivers. > =20 > Yes, but the MKT is derived into public/private keys using a KDF. > =20 > I am not aware of a KDF that can take a private key and generate a = derived private key that would work with a correspondingly derived = public key generated from the corresponding public key. > =20 > To use, the sender will hash the data, encrypt the hash and put the = result into the MAC field. > The receiver would decrypt the MAC field, then hash the data and = verify the hash against the decrypted MAC. > This way, the private key never needs to be exposed to anyone, = simplifying key management. > Is there any objection to getting this done? > =20 > See above; it doesn=E2=80=99t make sense with the way TCP-AO derives = keys for each connection, AFAICT. > =20 > Joe >=20 >=20 >=20 >=20 >=20 > =20 > Regards, > Jakob. > =20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = > =20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = > =20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = > =20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = --Apple-Mail=_D4CC5173-6612-4B8A-A70F-2D3493C56B1F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 You = certainly can, but I don=E2=80=99t plan to be further involved. My IETF = cycles are spoken for, even for reviews.

On Oct = 29, 2018, at 8:19 PM, Jakob Heitz (jheitz) <jheitz@cisco.com> = wrote:

Ok.
Shall I write a = draft?
 
Regards,
Jakob.
 
From: Joe Touch <touch@strayalpha.com> 
Sent: Monday, October 29, 2018 = 7:55 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: tcpm@ietf.org
Subject: Re: [tcpm] public-private = keys for TCP-AO
 
You=E2=80=99d want basically one per connection (the point is = to avoid reusing them). You=E2=80=99d be surprised how many connections = a pair of endpoints use over time.
 
Joe


On Oct 29, 2018, at 7:00 PM, Jakob Heitz = (jheitz) <jheitz@cisco.com> = wrote:
 
There are use cases where I don't = need to generate a LOT.
One a month should be just fine, = because I have no fear of them leaking into enemy hands.
I = posit that distributing one shared secret key is a LOT harder than = distributing 1000 public keys.
 
Regards,
Jakob.
 
From: Joe Touch <touch@strayalpha.com> 
Sent: Monday, October 29, 2018 = 6:49 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: tcpm@ietf.org
Subject: Re: [tcpm] public-private = keys for TCP-AO
 
 



On Oct 29, 2018, at 6:41 = PM, Jakob Heitz (jheitz) <jheitz@cisco.com> = wrote:
 
Because distributing public keys = is easier.
Private keys = don't need to be distributed. They stay inside the machine that = generates them.
 
Sure, but you need to = generate private/public key pairs on both sides of the connection - many = of them - and then distribute them to both sides. I.e., the work gets a = LOT larger.
 
 
Distributing and safe guarding symmetric keys is a = major hassle.
 
Agreed, but you only = need one such shared key between each endpoint pair because you can = derive session keys algorithmically.
 
You can certainly TRY to = work out the details as you suggest, but I suspect the number of keys = needed would be prohibitive even for a single pair of endpoints.
 
Joe



 
Regards,
Jakob.
 
From: Joe Touch <touch@strayalpha.com> 
Sent: Monday, October 29, 2018 = 6:37 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: tcpm@ietf.org
Subject: Re: [tcpm] public-private = keys for TCP-AO
 
 




On Oct 29, = 2018, at 6:22 PM, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
 
Can you think of = a way to do it that will work?
Like the KDF is = just a static list or something.
The sender = generates a set of key pairs and numbers them.
It then puts the = list of public keys into a file and distributes them to all receivers in = the clear.
 
You=E2=80=99d have to find a way to specify the use of = private and public keys on both sides, in advance, and distribute enough = for the upcoming connections - then you=E2=80=99d have to hash into that = list in a way that avoids reuse. At that point, why not just distribute = symmetric keys and be done with it?
 
Joe
 
The KDF is just = to index into this file.
 
Because the use = case, at least, makes sense.
 
Regards,
Jakob.
 
From: Joe Touch <touch@strayalpha.com> 
Sent: Monday, October 29, 2018 = 6:13 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: tcpm@ietf.org
Subject: Re: [tcpm] public-private = keys for TCP-AO
 
 





On Oct 29, 2018, at 5:45 PM, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
 
Why was there not a public-private = key algorithm specified for TCP-AO? Or did I miss it?
 
There has not been. I doubt it would make sense (see = below).





For = example ECC.
An = MKT can specify a private key for the sender and a public key for the = receivers.
 
Yes, but the MKT is derived into public/private keys = using a KDF.
 
I am not aware of a KDF that can take a private key = and generate a derived private key that would work with a = correspondingly derived public key generated from the corresponding = public key.
 
To use, the sender will hash the = data, encrypt the hash and put the result into the MAC field.
The = receiver would decrypt the MAC field, then hash the data and verify the = hash against the decrypted MAC.
This= way, the private key never needs to be exposed to anyone, simplifying = key management.
Is = there any objection to getting this done?
 
See above; it doesn=E2=80=99t make sense with the way TCP-AO = derives keys for each connection, AFAICT.
 
Joe





 
Regards,
Jakob.
 
_______________________________________________tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
 
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
 
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
 
_______________________________________________tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

= --Apple-Mail=_D4CC5173-6612-4B8A-A70F-2D3493C56B1F-- From nobody Mon Oct 29 20:25:19 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE09A124D68 for ; Mon, 29 Oct 2018 20:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.97 X-Spam-Level: X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 b1x_8EF6-S5i for ; Mon, 29 Oct 2018 20:25:16 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0272D127598 for ; Mon, 29 Oct 2018 20:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40896; q=dns/txt; s=iport; t=1540869914; x=1542079514; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BZNRbTWNW6KblMdR7NqhNxMhwkS/GfCGdo4RHb9K8Hs=; b=mD+Jzf8oDmIOyOQbo2Suk5+MTm0D43R+bdMNHXPcmXqRCewgscxbyym1 eQuRL7iC0SFZSuTUuiiTZDfrIRmUS9Qu6KNKEU7mKV0BjFzEBU/DUOlQ5 90eiCOOEEmT1THiLZP4zudeNCH1UgBl1ZAQ+JZjYa0qvaurt90cEE9pTT k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAANztdb/4cNJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDUgvZn8oCoNriBiMGYINlyCBdwMLAQEYAQq?= =?us-ascii?q?ESQIXgxYhNA0NAQMBAQIBAQJtHAyFOgEBAQEDAQEhCkELEAIBCBEEAQEhAQY?= =?us-ascii?q?DAgICJQsUCQgCBA4FCIMagR1kD6lkgS6KHAWLSR4XgUE/hCNZgkIBAYIXgk6?= =?us-ascii?q?CVwKIVxKFYYYiiUlUCQKQeiCNZoJhlnUCERSBJh04gVVwFTuCbIIlAReIXIU?= =?us-ascii?q?+b4wGgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,442,1534809600"; d="scan'208,217";a="193548287" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2018 03:25:12 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id w9U3PCvj024491 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Oct 2018 03:25:12 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 29 Oct 2018 22:25:12 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1395.000; Mon, 29 Oct 2018 22:25:11 -0500 From: "Jakob Heitz (jheitz)" To: Joe Touch CC: "tcpm@ietf.org" Thread-Topic: [tcpm] public-private keys for TCP-AO Thread-Index: AdRv51Oca8SVyggpTLame1T3B/a0kQAME/iAAApbkFD//7O5gIAAU4Pg//+v9oCAAFNQ4P//vwuAgABMT1A= Date: Tue, 30 Oct 2018 03:25:11 +0000 Message-ID: <6ec702c1f6ae426f9b169a035eda5345@XCH-ALN-014.cisco.com> References: <95f4b81948844b2799ecca33450bdde1@XCH-ALN-014.cisco.com> <7597333b9a414761be688375acf48dd6@XCH-ALN-014.cisco.com> <0C168054-E3D6-4BC5-9E1E-A28059F1A27B@strayalpha.com> <12b0f677e60443d8a32b4d56370787d7@XCH-ALN-014.cisco.com> <4C874E0B-BB5D-4765-8A33-3B9C736B646B@strayalpha.com> <68FFD5DF-E6B1-4E3A-B5F7-AB5114DA1BA0@strayalpha.com> In-Reply-To: <68FFD5DF-E6B1-4E3A-B5F7-AB5114DA1BA0@strayalpha.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.29.185] Content-Type: multipart/alternative; boundary="_000_6ec702c1f6ae426f9b169a035eda5345XCHALN014ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.24, xch-aln-014.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [tcpm] public-private keys for TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 03:25:19 -0000 --_000_6ec702c1f6ae426f9b169a035eda5345XCHALN014ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgaXQncyBwdWJsaWMtcHJpdmF0ZSwgSSBuZWVkIG9uZSBwZXIgc2VuZGVyLg0KSXQgZG9lc24n dCBuZWVkIHRvIGJlIHRoZSBzYW1lIGtleSBJRCBpbiBib3RoIGRpcmVjdGlvbnMgb24gdGhlIHNh bWUgc2Vzc2lvbiwgZG9lcyBpdD8NCg0KUmVnYXJkcywNCkpha29iLg0KDQpGcm9tOiBKb2UgVG91 Y2ggPHRvdWNoQHN0cmF5YWxwaGEuY29tPg0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDI5LCAyMDE4 IDc6NTUgUE0NClRvOiBKYWtvYiBIZWl0eiAoamhlaXR6KSA8amhlaXR6QGNpc2NvLmNvbT4NCkNj OiB0Y3BtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3RjcG1dIHB1YmxpYy1wcml2YXRlIGtleXMg Zm9yIFRDUC1BTw0KDQpZb3XigJlkIHdhbnQgYmFzaWNhbGx5IG9uZSBwZXIgY29ubmVjdGlvbiAo dGhlIHBvaW50IGlzIHRvIGF2b2lkIHJldXNpbmcgdGhlbSkuIFlvdeKAmWQgYmUgc3VycHJpc2Vk IGhvdyBtYW55IGNvbm5lY3Rpb25zIGEgcGFpciBvZiBlbmRwb2ludHMgdXNlIG92ZXIgdGltZS4N Cg0KSm9lDQoNCg0KT24gT2N0IDI5LCAyMDE4LCBhdCA3OjAwIFBNLCBKYWtvYiBIZWl0eiAoamhl aXR6KSA8amhlaXR6QGNpc2NvLmNvbTxtYWlsdG86amhlaXR6QGNpc2NvLmNvbT4+IHdyb3RlOg0K DQpUaGVyZSBhcmUgdXNlIGNhc2VzIHdoZXJlIEkgZG9uJ3QgbmVlZCB0byBnZW5lcmF0ZSBhIExP VC4NCk9uZSBhIG1vbnRoIHNob3VsZCBiZSBqdXN0IGZpbmUsIGJlY2F1c2UgSSBoYXZlIG5vIGZl YXIgb2YgdGhlbSBsZWFraW5nIGludG8gZW5lbXkgaGFuZHMuDQpJIHBvc2l0IHRoYXQgZGlzdHJp YnV0aW5nIG9uZSBzaGFyZWQgc2VjcmV0IGtleSBpcyBhIExPVCBoYXJkZXIgdGhhbiBkaXN0cmli dXRpbmcgMTAwMCBwdWJsaWMga2V5cy4NCg0KUmVnYXJkcywNCkpha29iLg0KDQpGcm9tOiBKb2Ug VG91Y2ggPHRvdWNoQHN0cmF5YWxwaGEuY29tPG1haWx0bzp0b3VjaEBzdHJheWFscGhhLmNvbT4+ DQpTZW50OiBNb25kYXksIE9jdG9iZXIgMjksIDIwMTggNjo0OSBQTQ0KVG86IEpha29iIEhlaXR6 IChqaGVpdHopIDxqaGVpdHpAY2lzY28uY29tPG1haWx0bzpqaGVpdHpAY2lzY28uY29tPj4NCkNj OiB0Y3BtQGlldGYub3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt0Y3Bt XSBwdWJsaWMtcHJpdmF0ZSBrZXlzIGZvciBUQ1AtQU8NCg0KDQoNCg0KDQpPbiBPY3QgMjksIDIw MTgsIGF0IDY6NDEgUE0sIEpha29iIEhlaXR6IChqaGVpdHopIDxqaGVpdHpAY2lzY28uY29tPG1h aWx0bzpqaGVpdHpAY2lzY28uY29tPj4gd3JvdGU6DQoNCkJlY2F1c2UgZGlzdHJpYnV0aW5nIHB1 YmxpYyBrZXlzIGlzIGVhc2llci4NClByaXZhdGUga2V5cyBkb24ndCBuZWVkIHRvIGJlIGRpc3Ry aWJ1dGVkLiBUaGV5IHN0YXkgaW5zaWRlIHRoZSBtYWNoaW5lIHRoYXQgZ2VuZXJhdGVzIHRoZW0u DQoNClN1cmUsIGJ1dCB5b3UgbmVlZCB0byBnZW5lcmF0ZSBwcml2YXRlL3B1YmxpYyBrZXkgcGFp cnMgb24gYm90aCBzaWRlcyBvZiB0aGUgY29ubmVjdGlvbiAtIG1hbnkgb2YgdGhlbSAtIGFuZCB0 aGVuIGRpc3RyaWJ1dGUgdGhlbSB0byBib3RoIHNpZGVzLiBJLmUuLCB0aGUgd29yayBnZXRzIGEg TE9UIGxhcmdlci4NCg0KDQpEaXN0cmlidXRpbmcgYW5kIHNhZmUgZ3VhcmRpbmcgc3ltbWV0cmlj IGtleXMgaXMgYSBtYWpvciBoYXNzbGUuDQoNCkFncmVlZCwgYnV0IHlvdSBvbmx5IG5lZWQgb25l IHN1Y2ggc2hhcmVkIGtleSBiZXR3ZWVuIGVhY2ggZW5kcG9pbnQgcGFpciBiZWNhdXNlIHlvdSBj YW4gZGVyaXZlIHNlc3Npb24ga2V5cyBhbGdvcml0aG1pY2FsbHkuDQoNCllvdSBjYW4gY2VydGFp bmx5IFRSWSB0byB3b3JrIG91dCB0aGUgZGV0YWlscyBhcyB5b3Ugc3VnZ2VzdCwgYnV0IEkgc3Vz cGVjdCB0aGUgbnVtYmVyIG9mIGtleXMgbmVlZGVkIHdvdWxkIGJlIHByb2hpYml0aXZlIGV2ZW4g Zm9yIGEgc2luZ2xlIHBhaXIgb2YgZW5kcG9pbnRzLg0KDQpKb2UNCg0KDQoNCg0KUmVnYXJkcywN Ckpha29iLg0KDQpGcm9tOiBKb2UgVG91Y2ggPHRvdWNoQHN0cmF5YWxwaGEuY29tPG1haWx0bzp0 b3VjaEBzdHJheWFscGhhLmNvbT4+DQpTZW50OiBNb25kYXksIE9jdG9iZXIgMjksIDIwMTggNjoz NyBQTQ0KVG86IEpha29iIEhlaXR6IChqaGVpdHopIDxqaGVpdHpAY2lzY28uY29tPG1haWx0bzpq aGVpdHpAY2lzY28uY29tPj4NCkNjOiB0Y3BtQGlldGYub3JnPG1haWx0bzp0Y3BtQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFt0Y3BtXSBwdWJsaWMtcHJpdmF0ZSBrZXlzIGZvciBUQ1AtQU8NCg0K DQoNCg0KDQoNCk9uIE9jdCAyOSwgMjAxOCwgYXQgNjoyMiBQTSwgSmFrb2IgSGVpdHogKGpoZWl0 eikgPGpoZWl0ekBjaXNjby5jb208bWFpbHRvOmpoZWl0ekBjaXNjby5jb20+PiB3cm90ZToNCg0K Q2FuIHlvdSB0aGluayBvZiBhIHdheSB0byBkbyBpdCB0aGF0IHdpbGwgd29yaz8NCkxpa2UgdGhl IEtERiBpcyBqdXN0IGEgc3RhdGljIGxpc3Qgb3Igc29tZXRoaW5nLg0KVGhlIHNlbmRlciBnZW5l cmF0ZXMgYSBzZXQgb2Yga2V5IHBhaXJzIGFuZCBudW1iZXJzIHRoZW0uDQpJdCB0aGVuIHB1dHMg dGhlIGxpc3Qgb2YgcHVibGljIGtleXMgaW50byBhIGZpbGUgYW5kIGRpc3RyaWJ1dGVzIHRoZW0g dG8gYWxsIHJlY2VpdmVycyBpbiB0aGUgY2xlYXIuDQoNCllvdeKAmWQgaGF2ZSB0byBmaW5kIGEg d2F5IHRvIHNwZWNpZnkgdGhlIHVzZSBvZiBwcml2YXRlIGFuZCBwdWJsaWMga2V5cyBvbiBib3Ro IHNpZGVzLCBpbiBhZHZhbmNlLCBhbmQgZGlzdHJpYnV0ZSBlbm91Z2ggZm9yIHRoZSB1cGNvbWlu ZyBjb25uZWN0aW9ucyAtIHRoZW4geW914oCZZCBoYXZlIHRvIGhhc2ggaW50byB0aGF0IGxpc3Qg aW4gYSB3YXkgdGhhdCBhdm9pZHMgcmV1c2UuIEF0IHRoYXQgcG9pbnQsIHdoeSBub3QganVzdCBk aXN0cmlidXRlIHN5bW1ldHJpYyBrZXlzIGFuZCBiZSBkb25lIHdpdGggaXQ/DQoNCkpvZQ0KDQpU aGUgS0RGIGlzIGp1c3QgdG8gaW5kZXggaW50byB0aGlzIGZpbGUuDQoNCkJlY2F1c2UgdGhlIHVz ZSBjYXNlLCBhdCBsZWFzdCwgbWFrZXMgc2Vuc2UuDQoNClJlZ2FyZHMsDQpKYWtvYi4NCg0KRnJv bTogSm9lIFRvdWNoIDx0b3VjaEBzdHJheWFscGhhLmNvbTxtYWlsdG86dG91Y2hAc3RyYXlhbHBo YS5jb20+Pg0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDI5LCAyMDE4IDY6MTMgUE0NClRvOiBKYWtv YiBIZWl0eiAoamhlaXR6KSA8amhlaXR6QGNpc2NvLmNvbTxtYWlsdG86amhlaXR6QGNpc2NvLmNv bT4+DQpDYzogdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbdGNwbV0gcHVibGljLXByaXZhdGUga2V5cyBmb3IgVENQLUFPDQoNCg0KDQoNCg0KDQoNCk9u IE9jdCAyOSwgMjAxOCwgYXQgNTo0NSBQTSwgSmFrb2IgSGVpdHogKGpoZWl0eikgPGpoZWl0ekBj aXNjby5jb208bWFpbHRvOmpoZWl0ekBjaXNjby5jb20+PiB3cm90ZToNCg0KV2h5IHdhcyB0aGVy ZSBub3QgYSBwdWJsaWMtcHJpdmF0ZSBrZXkgYWxnb3JpdGhtIHNwZWNpZmllZCBmb3IgVENQLUFP PyBPciBkaWQgSSBtaXNzIGl0Pw0KDQpUaGVyZSBoYXMgbm90IGJlZW4uIEkgZG91YnQgaXQgd291 bGQgbWFrZSBzZW5zZSAoc2VlIGJlbG93KS4NCg0KDQoNCg0KDQpGb3IgZXhhbXBsZSBFQ0MuDQpB biBNS1QgY2FuIHNwZWNpZnkgYSBwcml2YXRlIGtleSBmb3IgdGhlIHNlbmRlciBhbmQgYSBwdWJs aWMga2V5IGZvciB0aGUgcmVjZWl2ZXJzLg0KDQpZZXMsIGJ1dCB0aGUgTUtUIGlzIGRlcml2ZWQg aW50byBwdWJsaWMvcHJpdmF0ZSBrZXlzIHVzaW5nIGEgS0RGLg0KDQpJIGFtIG5vdCBhd2FyZSBv ZiBhIEtERiB0aGF0IGNhbiB0YWtlIGEgcHJpdmF0ZSBrZXkgYW5kIGdlbmVyYXRlIGEgZGVyaXZl ZCBwcml2YXRlIGtleSB0aGF0IHdvdWxkIHdvcmsgd2l0aCBhIGNvcnJlc3BvbmRpbmdseSBkZXJp dmVkIHB1YmxpYyBrZXkgZ2VuZXJhdGVkIGZyb20gdGhlIGNvcnJlc3BvbmRpbmcgcHVibGljIGtl eS4NCg0KVG8gdXNlLCB0aGUgc2VuZGVyIHdpbGwgaGFzaCB0aGUgZGF0YSwgZW5jcnlwdCB0aGUg aGFzaCBhbmQgcHV0IHRoZSByZXN1bHQgaW50byB0aGUgTUFDIGZpZWxkLg0KVGhlIHJlY2VpdmVy IHdvdWxkIGRlY3J5cHQgdGhlIE1BQyBmaWVsZCwgdGhlbiBoYXNoIHRoZSBkYXRhIGFuZCB2ZXJp ZnkgdGhlIGhhc2ggYWdhaW5zdCB0aGUgZGVjcnlwdGVkIE1BQy4NClRoaXMgd2F5LCB0aGUgcHJp dmF0ZSBrZXkgbmV2ZXIgbmVlZHMgdG8gYmUgZXhwb3NlZCB0byBhbnlvbmUsIHNpbXBsaWZ5aW5n IGtleSBtYW5hZ2VtZW50Lg0KSXMgdGhlcmUgYW55IG9iamVjdGlvbiB0byBnZXR0aW5nIHRoaXMg ZG9uZT8NCg0KU2VlIGFib3ZlOyBpdCBkb2VzbuKAmXQgbWFrZSBzZW5zZSB3aXRoIHRoZSB3YXkg VENQLUFPIGRlcml2ZXMga2V5cyBmb3IgZWFjaCBjb25uZWN0aW9uLCBBRkFJQ1QuDQoNCkpvZQ0K DQoNCg0KDQoNCg0KUmVnYXJkcywNCkpha29iLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KdGNwbSBtYWlsaW5nIGxpc3QNCnRjcG1AaWV0Zi5vcmc8 bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RjcG0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnRjcG0gbWFpbGluZyBsaXN0DQp0Y3BtQGlldGYub3JnPG1haWx0bzp0Y3BtQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp0Y3BtIG1haWxpbmcgbGlz dA0KdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KdGNwbSBtYWlsaW5nIGxpc3QNCnRjcG1AaWV0Zi5vcmc8bWFp bHRvOnRjcG1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3RjcG0NCg0K --_000_6ec702c1f6ae426f9b169a035eda5345XCHALN014ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIg MSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IlxARGVuZ1hpYW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRp di5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJ e21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciLHNlcmlmOw0KCWNvbG9yOiM3MDMwQTA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm O2NvbG9yOiM3MDMwQTAiPklmIGl0J3MgcHVibGljLXByaXZhdGUsIEkgbmVlZCBvbmUgcGVyIHNl bmRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5JdCBkb2Vzbid0IG5lZWQgdG8gYmUgdGhlIHNhbWUga2V5 IElEIGluIGJvdGggZGlyZWN0aW9ucyBvbiB0aGUgc2FtZSBzZXNzaW9uLCBkb2VzIGl0PzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2Nv bG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5SZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2Nv bG9yOiM3MDMwQTAiPkpha29iLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+IEpvZSBUb3VjaCAmbHQ7dG91Y2hAc3RyYXlhbHBoYS5jb20mZ3Q7DQo8YnI+ DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBPY3RvYmVyIDI5LCAyMDE4IDc6NTUgUE08YnI+DQo8Yj5U bzo8L2I+IEpha29iIEhlaXR6IChqaGVpdHopICZsdDtqaGVpdHpAY2lzY28uY29tJmd0Ozxicj4N CjxiPkNjOjwvYj4gdGNwbUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3RjcG1d IHB1YmxpYy1wcml2YXRlIGtleXMgZm9yIFRDUC1BTzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdeKAmWQgd2FudCBiYXNpY2FsbHkgb25lIHBlciBjb25u ZWN0aW9uICh0aGUgcG9pbnQgaXMgdG8gYXZvaWQgcmV1c2luZyB0aGVtKS4gWW914oCZZCBiZSBz dXJwcmlzZWQgaG93IG1hbnkgY29ubmVjdGlvbnMgYSBwYWlyIG9mIGVuZHBvaW50cyB1c2Ugb3Zl ciB0aW1lLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9l PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g T2N0IDI5LCAyMDE4LCBhdCA3OjAwIFBNLCBKYWtvYiBIZWl0eiAoamhlaXR6KSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmpoZWl0ekBjaXNjby5jb20iPmpoZWl0ekBjaXNjby5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 LHNlcmlmO2NvbG9yOiM3MDMwQTAiPlRoZXJlIGFyZSB1c2UgY2FzZXMgd2hlcmUgSSBkb24ndCBu ZWVkIHRvIGdlbmVyYXRlIGEgTE9ULjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPk9u ZSBhIG1vbnRoIHNob3VsZCBiZSBqdXN0IGZpbmUsIGJlY2F1c2UgSSBoYXZlIG5vIGZlYXIgb2Yg dGhlbSBsZWFraW5nIGludG8gZW5lbXkgaGFuZHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6Izcw MzBBMCI+SSBwb3NpdCB0aGF0IGRpc3RyaWJ1dGluZyBvbmUgc2hhcmVkIHNlY3JldCBrZXkgaXMg YSBMT1QgaGFyZGVyIHRoYW4gZGlzdHJpYnV0aW5nIDEwMDAgcHVibGljIGtleXMuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2Nv bG9yOiM3MDMwQTAiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+SmFr b2IuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Sm9lDQogVG91Y2ggJmx0 OzxhIGhyZWY9Im1haWx0bzp0b3VjaEBzdHJheWFscGhhLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+dG91Y2hAc3RyYXlhbHBoYS5jb208L3NwYW4+PC9hPiZndDs8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1vbmRheSwgT2N0 b2JlciAyOSwgMjAxOCA2OjQ5IFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5KYWtvYiBIZWl0eiAoamhlaXR6KSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmpoZWl0ekBjaXNjby5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi PmpoZWl0ekBjaXNjby5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0 Y3BtQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj50Y3BtQGlldGYub3JnPC9z cGFuPjwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFt0Y3BtXSBwdWJsaWMtcHJpdmF0ZSBrZXlzIGZvciBU Q1AtQU88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIE9jdCAyOSwgMjAxOCwgYXQgNjo0MSBQTSwgSmFrb2IgSGVpdHogKGpoZWl0eikgJmx0Ozxh IGhyZWY9Im1haWx0bzpqaGVpdHpAY2lzY28uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5qaGVpdHpAY2lzY28uY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+QmVjYXVzZSBkaXN0cmlidXRpbmcgcHVi bGljIGtleXMgaXMgZWFzaWVyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9y OiM3MDMwQTAiPlByaXZhdGUga2V5cyBkb24ndCBuZWVkIHRvIGJlIGRpc3RyaWJ1dGVkLiBUaGV5 IHN0YXkgaW5zaWRlIHRoZSBtYWNoaW5lIHRoYXQgZ2VuZXJhdGVzIHRoZW0uPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1cmUsIGJ1dCB5 b3UgbmVlZCB0byBnZW5lcmF0ZSBwcml2YXRlL3B1YmxpYyBrZXkgcGFpcnMgb24gYm90aCBzaWRl cyBvZiB0aGUgY29ubmVjdGlvbiAtIG1hbnkgb2YgdGhlbSAtIGFuZCB0aGVuIGRpc3RyaWJ1dGUg dGhlbSB0byBib3RoIHNpZGVzLiBJLmUuLCB0aGUgd29yayBnZXRzIGEgTE9UIGxhcmdlci48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6Izcw MzBBMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBB MCI+RGlzdHJpYnV0aW5nIGFuZCBzYWZlIGd1YXJkaW5nIHN5bW1ldHJpYyBrZXlzIGlzIGEgbWFq b3IgaGFzc2xlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BZ3JlZWQsIGJ1dCB5b3Ugb25seSBuZWVkIG9uZSBzdWNoIHNoYXJlZCBrZXkg YmV0d2VlbiBlYWNoIGVuZHBvaW50IHBhaXIgYmVjYXVzZSB5b3UgY2FuIGRlcml2ZSBzZXNzaW9u IGtleXMgYWxnb3JpdGhtaWNhbGx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3UgY2Fu IGNlcnRhaW5seSBUUlkgdG8gd29yayBvdXQgdGhlIGRldGFpbHMgYXMgeW91IHN1Z2dlc3QsIGJ1 dCBJIHN1c3BlY3QgdGhlIG51bWJlciBvZiBrZXlzIG5lZWRlZCB3b3VsZCBiZSBwcm9oaWJpdGl2 ZSBldmVuIGZvciBhIHNpbmdsZSBwYWlyIG9mIGVuZHBvaW50cy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Sm9lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNl cmlmO2NvbG9yOiM3MDMwQTAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 LHNlcmlmO2NvbG9yOiM3MDMwQTAiPkpha29iLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkpvZQ0KIFRvdWNoICZsdDs8 YSBocmVmPSJtYWlsdG86dG91Y2hAc3RyYXlhbHBoYS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPnRvdWNoQHN0cmF5YWxwaGEuY29tPC9zcGFuPjwvYT4mZ3Q7PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Nb25kYXksIE9jdG9i ZXIgMjksIDIwMTggNjozNyBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+SmFrb2IgSGVpdHogKGpoZWl0eikgJmx0OzxhIGhy ZWY9Im1haWx0bzpqaGVpdHpAY2lzY28uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5q aGVpdHpAY2lzY28uY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86dGNw bUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+dGNwbUBpZXRmLm9yZzwvc3Bh bj48L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbdGNwbV0gcHVibGljLXByaXZhdGUga2V5cyBmb3IgVENQ LUFPPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBPY3QgMjksIDIwMTgsIGF0IDY6MjIgUE0sIEpha29iIEhlaXR6IChqaGVpdHop ICZsdDs8YSBocmVmPSJtYWlsdG86amhlaXR6QGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+amhlaXR6QGNpc2NvLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2Nv bG9yOiM3MDMwQTAiPkNhbiB5b3UgdGhpbmsgb2YgYSB3YXkgdG8gZG8gaXQgdGhhdCB3aWxsIHdv cms/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6 IzcwMzBBMCI+TGlrZSB0aGUgS0RGIGlzIGp1c3QgYSBzdGF0aWMgbGlzdCBvciBzb21ldGhpbmcu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6Izcw MzBBMCI+VGhlIHNlbmRlciBnZW5lcmF0ZXMgYSBzZXQgb2Yga2V5IHBhaXJzIGFuZCBudW1iZXJz IHRoZW0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29s b3I6IzcwMzBBMCI+SXQgdGhlbiBwdXRzIHRoZSBsaXN0IG9mIHB1YmxpYyBrZXlzIGludG8gYSBm aWxlIGFuZCBkaXN0cmlidXRlcyB0aGVtIHRvIGFsbCByZWNlaXZlcnMgaW4gdGhlIGNsZWFyLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3XigJlkIGhhdmUgdG8gZmluZCBhIHdheSB0 byBzcGVjaWZ5IHRoZSB1c2Ugb2YgcHJpdmF0ZSBhbmQgcHVibGljIGtleXMgb24gYm90aCBzaWRl cywgaW4gYWR2YW5jZSwgYW5kIGRpc3RyaWJ1dGUgZW5vdWdoIGZvciB0aGUgdXBjb21pbmcgY29u bmVjdGlvbnMgLSB0aGVuIHlvdeKAmWQgaGF2ZSB0byBoYXNoIGludG8gdGhhdCBsaXN0IGluIGEg d2F5IHRoYXQgYXZvaWRzIHJldXNlLiBBdCB0aGF0IHBvaW50LCB3aHkNCiBub3QganVzdCBkaXN0 cmlidXRlIHN5bW1ldHJpYyBrZXlzIGFuZCBiZSBkb25lIHdpdGggaXQ/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvZTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5UaGUgS0RGIGlzIGp1c3QgdG8gaW5kZXggaW50 byB0aGlzIGZpbGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2Vy aWY7Y29sb3I6IzcwMzBBMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+QmVjYXVzZSB0aGUgdXNlIGNhc2UsIGF0IGxl YXN0LCBtYWtlcyBzZW5zZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyxzZXJpZjtjb2xvcjojNzAzMEEwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+UmVnYXJkcyw8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5K YWtvYi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNl cmlmO2NvbG9yOiM3MDMwQTAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Kb2UNCiBUb3Vj aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvdWNoQHN0cmF5YWxwaGEuY29tIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj50b3VjaEBzdHJheWFscGhhLmNvbTwvc3Bhbj48L2E+Jmd0OzxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50Ojwv Yj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TW9uZGF5 LCBPY3RvYmVyIDI5LCAyMDE4IDY6MTMgUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkpha29iIEhlaXR6IChqaGVpdHopICZs dDs8YSBocmVmPSJtYWlsdG86amhlaXR6QGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+amhlaXR6QGNpc2NvLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOnRjcG1AaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnRjcG1AaWV0Zi5v cmc8L3NwYW4+PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW3RjcG1dIHB1YmxpYy1wcml2YXRlIGtleXMg Zm9yIFRDUC1BTzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gT2N0IDI5LCAyMDE4LCBhdCA1OjQ1IFBNLCBKYWtv YiBIZWl0eiAoamhlaXR6KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpoZWl0ekBjaXNjby5jb20iPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmpoZWl0ekBjaXNjby5jb208L3NwYW4+PC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEw Ij5XaHkgd2FzIHRoZXJlIG5vdCBhIHB1YmxpYy1wcml2YXRlIGtleSBhbGdvcml0aG0gc3BlY2lm aWVkIGZvciBUQ1AtQU8/IE9yIGRpZCBJIG1pc3MgaXQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGhhcyBub3QgYmVlbi4g SSBkb3VidCBpdCB3b3VsZCBtYWtlIHNlbnNlIChzZWUgYmVsb3cpLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAz MEEwIj5Gb3IgZXhhbXBsZSBFQ0MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+QW4gTUtUIGNhbiBzcGVj aWZ5IGEgcHJpdmF0ZSBrZXkgZm9yIHRoZSBzZW5kZXIgYW5kIGEgcHVibGljIGtleSBmb3IgdGhl IHJlY2VpdmVycy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+WWVzLCBidXQgdGhlIE1LVCBpcyBkZXJpdmVkIGludG8gcHVibGljL3By aXZhdGUga2V5cyB1c2luZyBhIEtERi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBh bSBub3QgYXdhcmUgb2YgYSBLREYgdGhhdCBjYW4gdGFrZSBhIHByaXZhdGUga2V5IGFuZCBnZW5l cmF0ZSBhIGRlcml2ZWQgcHJpdmF0ZSBrZXkgdGhhdCB3b3VsZCB3b3JrIHdpdGggYSBjb3JyZXNw b25kaW5nbHkgZGVyaXZlZCBwdWJsaWMga2V5IGdlbmVyYXRlZCBmcm9tIHRoZSBjb3JyZXNwb25k aW5nIHB1YmxpYyBrZXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPlRvIHVzZSwgdGhlIHNlbmRlciB3aWxsIGhhc2gg dGhlIGRhdGEsIGVuY3J5cHQgdGhlIGhhc2ggYW5kIHB1dCB0aGUgcmVzdWx0IGludG8gdGhlIE1B QyBmaWVsZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj5UaGUgcmVjZWl2ZXIgd291bGQgZGVjcnlwdCB0 aGUgTUFDIGZpZWxkLCB0aGVuIGhhc2ggdGhlIGRhdGEgYW5kIHZlcmlmeSB0aGUgaGFzaCBhZ2Fp bnN0IHRoZSBkZWNyeXB0ZWQgTUFDLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPlRoaXMgd2F5LCB0aGUg cHJpdmF0ZSBrZXkgbmV2ZXIgbmVlZHMgdG8gYmUgZXhwb3NlZCB0byBhbnlvbmUsIHNpbXBsaWZ5 aW5nIGtleSBtYW5hZ2VtZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPklzIHRoZXJlIGFueSBvYmpl Y3Rpb24gdG8gZ2V0dGluZyB0aGlzIGRvbmU/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VlIGFib3ZlOyBpdCBkb2VzbuKAmXQgbWFrZSBzZW5z ZSB3aXRoIHRoZSB3YXkgVENQLUFPIGRlcml2ZXMga2V5cyBmb3IgZWFjaCBjb25uZWN0aW9uLCBB RkFJQ1QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvZTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29s b3I6IzcwMzBBMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDssc2VyaWY7Y29sb3I6IzcwMzBBMCI+UmVnYXJkcyw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xv cjojNzAzMEEwIj5KYWtvYi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0Y3BtIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bh bj48YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj OTU0RjcyIj50Y3BtQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8 L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3Bt Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5NTRGNzIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdGNwbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KdGNwbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86dGNwbUBp ZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+dGNwbUBpZXRmLm9yZzwvc3Bhbj48 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 Y3BtIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3RjcG08L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0Y3BtIG1haWxpbmcg bGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpwdXJwbGUiPnRjcG1AaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3RjcG0iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG08L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCnRjcG0gbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhy ZWY9Im1haWx0bzp0Y3BtQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+ dGNwbUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdGNwbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6ec702c1f6ae426f9b169a035eda5345XCHALN014ciscocom_-- From nobody Tue Oct 30 18:35:05 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70411130DD8 for ; Tue, 30 Oct 2018 18:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ozZHu9vBG7Dn for ; Tue, 30 Oct 2018 18:34:55 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 61BBF130DDD for ; Tue, 30 Oct 2018 18:34:54 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id x12-v6so14651837wrw.8 for ; Tue, 30 Oct 2018 18:34:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o3nP+gVvuUqsAJGx7M278VJx0xJyMk51eHy0bl8JvJA=; b=jxYf3SuAkeaiQ2jbFJKzPrppJ36SYbCwWE57ccEWf/ItiEr3ezLD7pY1OtYAyNThc+ X2dalCF/W/quNyduagIRlwS00hMrtierprwKqb/jX4hDwmLlHit6uPH279KeB+pDFQIJ vHYTJnvy7FBl7FvEJdZ6aVRYJif/Fo4qPeH8PN1/X27C6oj9gc1vm0gn5Tbna9Qoozdq HFApuw96EcaRQaxmSg9dSpxlcvaGvyG6k+dPnlOunlCHCOe5WOJCVcADczAQ+t/Q3WVt DqGDn9yOpJ3RnVkeaBOxoZxJxC+TxXiUOxYisCnK9QLe3olXm646QDXz5EmlbcwVo40S zrEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o3nP+gVvuUqsAJGx7M278VJx0xJyMk51eHy0bl8JvJA=; b=ikaAQP8ssRsP9KC+o9JcDDgRg/bJggY/lR2L0/Ze5Qs47y8T7BpMnMhMi5yL2eJiOr bAyq/2OL5oMpmmM76U8n2Ey5EDE0sUl7JVpYWgBtGC/ep3emzp9r8G/6DCU9jIrvvoQo DAZoqVRDsPkbVDPkSnqlmEANSDCedsxu2BdZrP9uhQk6EIVmCc9PQa+F1vbm/f2WruHV F2e14E57RZ31mBsTj2TyWP9FEbYSmHI4hJqG+3e66zmghe5pC4wub1rP6/bwUu+kXa2n UQikyY8o2nKhxJCopCnkJdGF0A05m7TQ3M8hbM/Go3Jzyecey3F8mWlLmbX+xWZGdZgs YhoQ== X-Gm-Message-State: AGRZ1gLoJCAfsq5RIfzFldVZYTvLZznC/fYFabgK+brtgXy68E7IJ6pd P5exMO4kEJLFZMvgZE9ty6raSE7pydhIF0mHp9Z10A== X-Google-Smtp-Source: AJdET5dN0fjpo2wH1DbqTXzMxHnDWKbH22mas17Wry22rROSSea4ivvB8/4U9o4ezwZBs+N1PyQJBX9ww/EDQu9Qse4= X-Received: by 2002:adf:812a:: with SMTP id 39-v6mr811915wrm.84.1540949692646; Tue, 30 Oct 2018 18:34:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Tue, 30 Oct 2018 21:34:39 -0400 Message-ID: To: nishida@sfc.wide.ad.jp Cc: IETF QUIC WG , tcpm@ietf.org, Jana Iyengar Content-Type: multipart/alternative; boundary="0000000000000c6fe605797c4fcf" Archived-At: Subject: Re: [tcpm] questions on draft-ietf-quic-recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 01:34:58 -0000 --0000000000000c6fe605797c4fcf Content-Type: text/plain; charset="UTF-8" Thanks for your careful reading, answers inline. On Mon, Oct 29, 2018 at 1:03 PM Yoshifumi Nishida wrote: > Hello, > > At Bangkok, TCPM WG will have a session to discuss loss recovery and > congestion control mechanism in QUIC and TCP. (11/6 Tuesday > 11:20-12:20) > I really appreciate Ian and Jana for the efforts. > > I might overlook something as I couldn't follow up all discussion in > QUIC, but I am thinking that it might be good if we could get some > comments on the following questions. > I have listed several questions on the value of some parameters, but > it doesn't mean I disagree with these values. I just would like to > check where these values came from. > Hope this will be useful in some ways. > > > Section 4: > QUIC supports both ack and timer for loss detection. > But, it's not very clear whether an implementation can choose one > of them or it should implement both and can use both at the same time. > Can it be clarified? > Yes, there's an open Issue to clarify this. https://github.com/quicwg/base-drafts/issues/1212 The outstanding PR is quite old, but has some helpful clarifications in it, so I'm intending to migrate the best parts to a new PR. Suggestions(or PRs) welcome. > Section 4.1.1: > For RTT sampling, implementations will need to maintain the > transmission time for each sending packets even if they support only > ack-based method. > But, this requirement might be hard for tiny devices. Wouldn't it > limit the applicability of QUIC? > Good question. Assuming a ~1200 byte packet and a 4 byte timestamp, that's <0.5% of the total storage overhead, assuming the data being sent is reliable. That doesn't seem like too much overhead to me, but one could certainly store less granular information if they were really constrained. ie: packet numbers X to X+N all contain a certain sequence of bytes and were sent at approximately a single time. I believe such a storage approach would make it more similar to TCP metadata, but you likely know better than I do. > > "the largest newly acked packet" might be confusing. packet that > acks the largest packet number? > That's the largest packet that was acknowledged in the current ack frame being processed. I re-read the text and I'm not sure how to improve it, so feel free to send a PR. > > Section 4.2.1: > TCP RACK's reo_wnd is aiming to be 1/4 RTT. Why QUIC uses 1/8 RTT? > I ran some experiments that indicated 1/4 RTT was a slight latency regression for web applications and 1/8 RTT still had fewer spurious retransmits than the dupack threshold loss detection. I also presented some reordering data at maprg in Montreal that indicated 1/8 RTT was typically enough. Obviously different networks and workloads are different, and I think the best approach is likely an adaptive one, but I don't have an adaptive algorithm I'm confident enough in to write it up. Suggestions definitely welcome. > > Section 4.2.2: > The early retransmit logic in QUIC seems to be different from TCP's one. > It doesn't look ack-based as it relies on timer. (I don't say this > is bad, but it's a bit strange to categorize it as an ack-based > method) > TCP's early retransmit will be triggered only when the amount of > outstanding data is less than 4*SMSS, but this draft doesn't mention > about the condition. Is there any reason for it? > when timer-based loss detection is used, it this logic still > available? or it won't be used with timer-based loss detection? We > might need clarifications here. > The timer is taken from Linux, as mentioned at the end of 4.2.2. It's categorized as ACK based because it is only armed when a packet with a larger packet number than the one being lost has been acknowledged. One could argue the same issue for time based loss detection, which also needs a timer. Instead of 4*SMSS, we specify kReorderingThreshold, since it seemed like the core issue being fixed was that there was no other mechanism for quickly declaring these packets lost, and if one did implement adaptive reordering tolerance, one threshold wouldn't be out of sync with the other. The intent is that like RACK, timer based loss detection subsumes early retransmit. But yes, this text could use some further clarification, including and not limited to items pointed out in #1212. > > Section 4.3.2: > TCP RACK's PTO is aiming to be 2 * SRTT. Why QUIC uses 1.5 * SRTT? > This arose because TCP uses 1.5 * SRTT + MaxAckDelay if there is only one MSS outstanding. QUIC is still arriving at the optimal algorithm for sending ACKs and how to indicate that to the peer, so QUIC explicitly specifies MaxAckDelay in the handshake and always includes the MaxAckDelay in PTO. We could go back to the approach of trying to determine whether a fast ACK is expected and use 2 * SRTT in that case, if we thought it was better, but this is a bit simpler. > > Section 4.3.3: > RFC5681 uses 1 SMSS as the size of loss window, while QUIC uses 2. > I understand the motivation to reduce the possibility of consecutive > RTO events. But, this may means when TCP and QUIC connections are > under heavy congestion, QUIC connections will recover more quickly > than TCP connections. We might want to think how much QUIC and TCP > should be fair. > I have some experimental code to see if 2 packets makes a difference vs 1 packet. If not, we can change QUIC to 1. If it does make a difference, then we should discuss what to recommend for both TCP and QUIC. > BTW, it might not be necessarily, but QUIC does not need the upper > bound for RTO? > In practice, I'd expect a QUIC connection to idle timeout before it hit the upper bound. We could add one if you think it's useful, but it seemed safer to continue with exponential backoff. > > Section 4.4: > why the default value of max_ack_delay is 25ms? > It was a chosen as a good general purpose value for modern networks. 25ms means sending an ACK for every packet only if packets are evenly spaced and the bandwidth is about 300kbits or lower if my math is correct. That's definitely on the lower end of internet speeds. Additionally, if a client knows they're on such a slow link(2g) they can use the MaxAckDelay transport param to specify a larger ack delay. Or, from 4.6: "A shorter delayed ack time of 25ms was chosen because longer delayed acks can delay loss recovery and for the small number of connections where less than packet per 25ms is delivered, acking every packet is beneficial to congestion control and loss recovery." > Section 4.5.7.3: > Sorry.. what is 1/4 RTT timer for early retransmit? > Sorry, I can't seem to find the reference to a 1/4 RTT timer for early retransmit. > > Section 5.8.1: > Why the recommended value is 1200 bytes? > > That's from QUIC transport, but the intent is to make the minimum MTU fairly large to avoid amplification attacks as well as provide enough room for the TLS ClientHello. --0000000000000c6fe605797c4fcf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your careful reading, answers = inline.
On Mon, Oct 29, 2018= at 1:03 PM Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
Hello,

At Bangkok, TCPM WG will have a session to discuss loss recovery and
congestion control mechanism in QUIC and TCP. (11/6 Tuesday
11:20-12:20)
I really appreciate Ian and Jana for the efforts.

I might overlook something as I couldn't follow up all discussion in QUIC, but I am thinking that it might be good if we could get some
comments on the following questions.
I have listed several questions on the value of some parameters, but
it doesn't mean I disagree with these values. I just would like to
check where these values came from.
Hope this will be useful in some ways.


Section 4:
=C2=A0 =C2=A0QUIC supports both ack and timer for loss detection.
=C2=A0 =C2=A0But, it's not very clear whether an implementation can cho= ose one
of them or it should implement both and can use both at the same time.
Can it be clarified?

Yes, there's an open Issu= e to clarify this.=C2=A0 https://github.com/quicwg/base-drafts/issues/= 1212

The outstanding PR is quite old, but has = some helpful clarifications in it, so I'm intending to migrate the best= parts to a new PR.=C2=A0 Suggestions(or PRs) welcome.

=

Section 4.1.1:
=C2=A0 =C2=A0For RTT sampling, implementations will need to maintain the transmission time for each sending packets even if they support only
ack-based method.
=C2=A0 =C2=A0But, this requirement might be hard for tiny devices. Wouldn&#= 39;t it
limit the applicability of QUIC?

Good q= uestion.=C2=A0 Assuming a ~1200 byte packet and a 4 byte timestamp, that= 9;s <0.5% of the total storage overhead, assuming the data being sent is= reliable.=C2=A0 That doesn't seem like too much overhead to me, but on= e could certainly store less granular information if they were really const= rained.=C2=A0 ie: packet numbers X to X+N all contain a certain sequence of= bytes and were sent at approximately a single time.=C2=A0 I believe such a= storage approach would make it more similar to TCP metadata, but you likel= y know better than I do.
=C2=A0

=C2=A0 =C2=A0"the largest newly acked packet" might be confusing.= packet that
acks the largest packet number?

=C2=A0T= hat's the largest packet that was acknowledged in the current ack frame= being processed.=C2=A0 I re-read the text and I'm not sure how to impr= ove it, so feel free to send a PR.

Section 4.2.1:
=C2=A0 =C2=A0TCP RACK's reo_wnd is aiming to be 1/4 RTT. Why QUIC uses = 1/8 RTT?

I ran some experiments that in= dicated 1/4 RTT was a slight latency regression for web applications and 1/= 8 RTT still had fewer spurious retransmits than the dupack threshold loss d= etection.=C2=A0 I also presented some reordering data at maprg in Montreal = that indicated 1/8 RTT was typically enough.=C2=A0 Obviously different netw= orks and workloads are different, and I think the best approach is likely a= n adaptive one, but I don't have an adaptive algorithm I'm confiden= t enough in to write it up.=C2=A0 Suggestions definitely welcome.

Section 4.2.2:
=C2=A0 =C2=A0The early retransmit logic in QUIC seems to be different from = TCP's one.
=C2=A0 =C2=A0It doesn't look ack-based as it relies on timer. (I don= 9;t say this
is bad, but it's a bit strange to categorize it as an ack-based
method)
=C2=A0 =C2=A0TCP's early retransmit will be triggered only when the amo= unt of
outstanding data is less than 4*SMSS, but this draft doesn't mention about the condition. Is there any reason for it?
=C2=A0 =C2=A0when timer-based loss detection is used, it this logic still available? or it won't be used with timer-based loss detection? We
might need clarifications here.

The tim= er is taken from Linux, as mentioned at the end of 4.2.2.=C2=A0 It's ca= tegorized as ACK based because it is only armed when a packet with a larger= packet number than the one being lost has been acknowledged.=C2=A0 One cou= ld argue the same issue for time based loss detection, which also needs a t= imer.

Instead of 4*SMSS, we specify kReorderingThr= eshold, since it seemed like the core issue being fixed was that there was = no other mechanism for quickly declaring these packets lost, and if one did= implement adaptive reordering tolerance, one threshold wouldn't be out= of sync with the other.

The intent is that like R= ACK, timer based loss detection subsumes early retransmit.=C2=A0 But yes, t= his text could use some further clarification, including and not limited to= items pointed out in #1212.
=C2=A0

Section 4.3.2:
=C2=A0 =C2=A0TCP RACK's PTO is aiming to be 2 * SRTT. Why QUIC uses 1.5= * SRTT?

This arose because TCP uses 1.= 5 * SRTT=C2=A0+ MaxAckDelay if there is only one MSS outstanding.=C2=A0 QUI= C is still arriving at the optimal algorithm for sending ACKs and how to in= dicate that to the peer, so QUIC explicitly specifies MaxAckDelay in the ha= ndshake and always includes the MaxAckDelay in PTO.=C2=A0 We could go back = to the approach of trying to determine whether a fast ACK is expected and u= se 2 * SRTT in that case, if we thought it was better, but this is a bit si= mpler.
=C2=A0

Section 4.3.3:
=C2=A0 =C2=A0RFC5681 uses 1 SMSS as the size of loss window, while QUIC use= s 2.
I understand the motivation to reduce the possibility of consecutive
RTO events. But, this may means when TCP and QUIC connections are
under heavy congestion, QUIC connections will recover more quickly
than TCP connections. We might want to think how much QUIC and TCP
should be fair.

I have some experimenta= l code to see if 2 packets makes a difference vs 1 packet.=C2=A0 If not, we= can change QUIC to 1.=C2=A0 If it does make a difference, then we should d= iscuss what to recommend for both TCP and QUIC.


=C2=A0 =C2=A0BTW, it might not be necessarily, but QUIC does not need the u= pper
bound for RTO?

In practice, I'd exp= ect a QUIC connection to idle timeout before it hit the upper bound.=C2=A0 = We could add one if you think it's useful, but it seemed safer to conti= nue with exponential backoff.=C2=A0

Section 4.4:
=C2=A0 =C2=A0why the default value of max_ack_delay is 25ms?

It was a chosen as a good general purpose value for m= odern networks.=C2=A0 25ms means sending an ACK for every packet only if pa= ckets are evenly spaced and the bandwidth is about 300kbits or lower if my = math is correct.=C2=A0 That's definitely on the lower end of internet s= peeds.=C2=A0 Additionally, if a client knows they're on such a slow lin= k(2g) they can use the MaxAckDelay transport param to specify a larger ack = delay.

Or, from 4.6:
"A shorter delayed ack time of 25ms was chosen because longer delayed
   acks can delay loss recovery and for the small number of con=
nections
   where less than packet per 25ms is delivered, acking every packet is
   beneficial to congestion control and loss recovery."

Section 4.5= .7.3:
=C2=A0 =C2=A0Sorry.. what is 1/4 RTT timer for early retransmit?

=C2=A0Sorry, I can't seem to find the referen= ce to a 1/4 RTT timer for early retransmit.

Section 5.8.1:
=C2=A0 =C2=A0Why the recommended value is 1200 bytes?


That's from QUIC transport, but th= e intent is to make the minimum MTU fairly large to avoid amplification att= acks as well as provide enough room for the TLS ClientHello.
--0000000000000c6fe605797c4fcf--