From nobody Tue Nov 1 00:30:46 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997A2129420 for ; Tue, 1 Nov 2016 00:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRSnG0NKIt8M for ; Tue, 1 Nov 2016 00:30:43 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB50127071 for ; Tue, 1 Nov 2016 00:30:43 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id n67so270320151wme.1 for ; Tue, 01 Nov 2016 00:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OgWocMeZE9/1MWLWGr62mc4YJZGD0NyVbIhrtD71G+Y=; b=LWJB4TyJ23zJUtpmllqEH6SfrpJqizuifB+/a6U2h7ogn+sjQlOToHorZ33eM6pCoB JDVEq84/6E8lxVekRu8IMAUFmVUrGrAgzhu70bYexK5Xtw7vhAPF1v68m1gPRuYr44OQ 0S0ZJ3pLu8vZJE7t3eZIQmfuTsQHpXq2Z5MiV2KyIu0wg4oSMx4/+nZk7N2IsAOWytDm huVpba/7ZPovwA+yt59jVn0pSJC9SG1C/tZKsbEFoM7ojiGY3c96iIPMi3Ovraqc6TbO yKY9SrYN1vQZ5Iwu6GLPMkPYNRZNKtNvwUC19IYBKEu7PW8VrlJi4Y75YuxyVZNLUA1j +l1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=OgWocMeZE9/1MWLWGr62mc4YJZGD0NyVbIhrtD71G+Y=; b=LloHwLpSQmLCZBEIIzlQNXXSLti7XQjvJWYNNA4zV6BVfPfktpPpJAIcj0CPNKOAem s6eeVw7b+y80F/F5647bodoedCZH7q/h4Fq3R0xSDBvAauMp1wOZBqD1QxaKQ/SYnwbq 0puJpxU7DRX7luD5nW0pBKCe0WH6LAL82Vl/2TZdcLQWHXGyc6+VfcOmBEhRbbSylnU+ /l2TsYFzG+sVq+2FF6lRqciGFwxF/sBI3qoMFTmyE37FORd+leeVfD81egDDcUpYJG+n tQb1hdGw1fgKz0bY6XbZy339bhC0oNkaRIz/qdrRxi9bw/eDLRP3SH/gyK93gUslFO4r dAdQ== X-Gm-Message-State: ABUngvc8MDEqQ3OKeAeOo8Jr0ORS9AoAkAyDGRNT4ErzBSC9mMyImlr+sgiyfN0ze4928A== X-Received: by 10.28.5.207 with SMTP id 198mr351998wmf.22.1477985441755; Tue, 01 Nov 2016 00:30:41 -0700 (PDT) Received: from macbook-pro-2.mshome.net ([109.253.201.56]) by smtp.gmail.com with ESMTPSA id y2sm34036999wjx.20.2016.11.01.00.30.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Nov 2016 00:30:41 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9AD5B4AA-70B2-4075-B02D-9B18B4EA1EA7" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Tue, 1 Nov 2016 09:30:38 +0200 In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB272FF@NKGEML515-MBX.china.huawei.com> To: Xuxiaohu References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB272FF@NKGEML515-MBX.china.huawei.com> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 07:30:45 -0000 --Apple-Mail=_9AD5B4AA-70B2-4075-B02D-9B18B4EA1EA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Xiaohu A few comments. Actually, they=E2=80=99re more like questions. How are IPsec SAs mapped to UDP pseudo-connections? Is it a 1:1 mapping = between SPI and source port? If now, how do you deal with the packet reordering that the load = balancer will do? IPsec requires ordered or nearly-ordered delivery. How is this negotiated? In IKE? Prior agreement? Why do we need a new port? What goes wrong if the packets go to port = 4500? Thanks Yoav > On 1 Nov 2016, at 3:45, Xuxiaohu wrote: >=20 > Hi all, >=20 > Any comments and suggestions are welcome. >=20 > Best regards, > Xiaohu >=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B410=E6=9C=8831=E6=97=A5= 19:15 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; zhangdacheng; Xialiang (Frank) >> =E4=B8=BB=E9=A2=98: New Version Notification for = draft-xu-ipsecme-esp-in-udp-lb-00.txt >>=20 >>=20 >> A new version of I-D, draft-xu-ipsecme-esp-in-udp-lb-00.txt >> has been successfully submitted by Liang Xia and posted to the IETF = repository. >>=20 >> Name: draft-xu-ipsecme-esp-in-udp-lb >> Revision: 00 >> Title: Encapsulating IPsec ESP in UDP for = Load-balancing >> Document date: 2016-10-31 >> Group: Individual Submission >> Pages: 7 >> URL: >> = https://www.ietf.org/internet-drafts/draft-xu-ipsecme-esp-in-udp-lb-00.txt= >> Status: >> https://datatracker.ietf.org/doc/draft-xu-ipsecme-esp-in-udp-lb/ >> Htmlized: = https://tools.ietf.org/html/draft-xu-ipsecme-esp-in-udp-lb-00 >>=20 >>=20 >> Abstract: >> IPsec Virtual Private Network (VPN) is widely used by enterprises to >> interconnect their geographical dispersed branch office locations >> across IP Wide Area Network (WAN). To fully utilize the bandwidth >> available in IP WAN, load balancing of traffic between different >> IPsec VPN sites over Equal Cost Multi-Path (ECMP) and/or Link >> Aggregation Group (LAG) within IP WAN is attractive to those >> enterprises deploying IPsec VPN solutions. This document defines a >> method to encapsulate IPsec Encapsulating Security Payload (ESP) >> packets inside UDP packets for improving load-balancing of IPsec >> tunneled traffic. In addition, this encapsulation is also applicable >> to some special multi-tenant data center network environment where >> the overlay tunnels need to be secured. >>=20 >>=20 >>=20 >>=20 >> 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. >>=20 >> The IETF Secretariat >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_9AD5B4AA-70B2-4075-B02D-9B18B4EA1EA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Xiaohu

A few comments. Actually, they=E2=80=99re more like = questions.

  1. How are IPsec SAs = mapped to UDP pseudo-connections?  Is it a 1:1 mapping between SPI = and source port?
  2. If now, how do you deal with the packet reordering that the = load balancer will do? IPsec requires ordered or nearly-ordered = delivery.
  3. How is this = negotiated?  In IKE? Prior agreement?
  4. Why do we need a new port? =  What goes wrong if the packets go to port = 4500?

Thanks

Yoav
On 1 Nov 2016, at 3:45, Xuxiaohu <xuxiaohu@huawei.com>= wrote:

Hi all,

Any comments and = suggestions are welcome.

Best regards,
Xiaohu

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B410=E6=9C=883= 1=E6=97=A5 19:15
=E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; = zhangdacheng; Xialiang (Frank)
=E4=B8=BB=E9=A2=98: New = Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt


A new version of I-D, = draft-xu-ipsecme-esp-in-udp-lb-00.txt
has been = successfully submitted by Liang Xia and posted to the IETF = repository.

Name: = draft-xu-ipsecme-esp-in-udp-lb
Revision: 00
Title:= = Encapsulating IPsec ESP in UDP for Load-balancing
Document date: 2016-10-31
Group:= = Individual Submission
Pages: 7
URL:
https://www.ietf.org/internet-drafts/draft-xu-ipsecme-esp-in-ud= p-lb-00.txt
Status:
https://datatracker.ietf.org/doc/draft-xu-ipsecme-esp-in-udp-lb= /
Htmlized: =       https://tools.ietf.org/html/draft-xu-i= psecme-esp-in-udp-lb-00


Abstract:
 IPsec Virtual Private Network = (VPN) is widely used by enterprises to
 interconnect = their geographical dispersed branch office locations
=  across IP Wide Area Network (WAN). To fully utilize the = bandwidth
 available in IP WAN, load balancing of = traffic between different
 IPsec VPN sites over = Equal Cost Multi-Path (ECMP) and/or Link
=  Aggregation Group (LAG) within IP WAN is attractive to those
 enterprises deploying IPsec VPN solutions. This = document defines a
 method to encapsulate IPsec = Encapsulating Security Payload (ESP)
 packets inside = UDP packets for improving load-balancing of IPsec
=  tunneled traffic. In addition, this encapsulation is also = applicable
 to some special multi-tenant data center = network environment where
 the overlay tunnels need = to be secured.




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.

The IETF Secretariat

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

= --Apple-Mail=_9AD5B4AA-70B2-4075-B02D-9B18B4EA1EA7-- From nobody Tue Nov 1 02:20:49 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD74C12946C for ; Tue, 1 Nov 2016 02:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 mENtHp2YlnYw for ; Tue, 1 Nov 2016 02:20:39 -0700 (PDT) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 255CE129583 for ; Tue, 1 Nov 2016 02:20:39 -0700 (PDT) Received: from TobiLenovo (ObiWan2.nm.ifi.lmu.de [141.84.218.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: guggemos.tobias.nm) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id 9A2F494A278; Tue, 1 Nov 2016 10:20:37 +0100 (CET) From: "Tobias Guggemos" To: "'Valery Smyslov'" , "'Daniel Migault'" , "'IPsecME WG'" References: <147594692832.28921.7850239516371972090.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F98570@eusaamb107.ericsson.se> <001e01d22aa5$d3ebc4a0$7bc34de0$@mnm-team.org> <00e001d22aaa$20e01910$62a04b30$@gmail.com> In-Reply-To: <00e001d22aaa$20e01910$62a04b30$@gmail.com> Date: Tue, 1 Nov 2016 10:20:37 +0100 Message-ID: <001301d23421$34f8ee60$9eeacb20$@mnm-team.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHSIsTPc0J4zAXjlkKN6omZRo+LMaCxAzfw///p+ACAEwtWYA== Content-Language: de Archived-At: Subject: Re: [IPsec] FW: New Version Notification fordraft-mglt-ipsecme-implicit-iv-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 09:20:42 -0000 Hey Valery, Thanks for the explanation. I added the following statement to the = security considerations. Could you please let me know if that resolves your = concerns? As the IV MUST NOT repeat for one SPI when Counter-Mode ciphers are used, Implicit IV as described in this document MUST NOT be used in setups with the chance that the Sequence Number overlaps for one SPI. Multicast as described in [RFC5374], [RFC6407] and [I-D.yeung-g-ikev2] is a prominent example, where many senders share one secret and thus one SPI. Section 3.5 of [RFC6407] explains how repetition MAY BE prevented by using a prefix for each group member, which could be prefixed to the Sequence Number. Otherwise, Implicit IV MUST NOT be used in multicast scenarios. Thanks=20 Tobias -----Urspr=FCngliche Nachricht----- Von: Valery Smyslov [mailto:svanru@gmail.com]=20 Gesendet: Donnerstag, 20. Oktober 2016 10:16 An: 'Tobias Guggemos' ; 'Daniel Migault' ; 'IPsecME WG' Betreff: RE: [IPsec] FW: New Version Notification fordraft-mglt-ipsecme-implicit-iv-01.txt Hi Tobias, > Hey Valery, > Thanks for the clarification, we'll add this statement in the draft! Thank you. > Just because I'm interested: For me, this seems to be a general=20 > problem for implementing counter ciphers > in multicast scenarios, regardless of implicit-iv or not. > Do you know how the IV is usually chosen in multicast-implementations? The Group Controller assigns each sender a unique counter prefix. See Section 3.5 of RFC 6407. Regards, Valery. > Maybe we could add a recommendation in the draft. >=20 > Thanks > Tobias >=20 >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: IPsec [mailto:ipsec-bounces@ietf.org] Im Auftrag von Valery=20 > Smyslov > Gesendet: Montag, 10. Oktober 2016 09:06 > An: Daniel Migault ; IPsecME WG=20 > > Betreff: Re: [IPsec] FW: New Version Notification=20 > fordraft-mglt-ipsecme-implicit-iv-01.txt >=20 > Hi Daniel, >=20 > I think you should add a text in the Security Considerations that=20 > these transforms MUST NOT be used in > situations where there is a chance that Sequence Numbers repeat. The=20 > most prominent example where it > can happen - multicast ESP SA with multiple senders. >=20 > Regards, > Valery. >=20 >=20 > > Hi, > > > > Based on the feed backs and the discussions from the previous IETF,=20 > > see the updated version of our draft. We believe the document is in=20 > > good > shape to become a WG document. > > > > Feel free to support the draft and as usually, comments are welcome! > > > > BR, > > Daniel > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Saturday, October 08, 2016 7:15 PM > > To: Tobias Guggemos ; Yoav Nir=20 > > ; Daniel Migault > > Subject: New Version Notification for=20 > > draft-mglt-ipsecme-implicit-iv-01.txt > > > > > > A new version of I-D, draft-mglt-ipsecme-implicit-iv-01.txt > > has been successfully submitted by Daniel Migault and posted to the=20 > > IETF > repository. > > > > Name: draft-mglt-ipsecme-implicit-iv > > Revision: 01 > > Title: Implicit IV for Counter-based Ciphers in IPsec Document date: > > 2016-10-08 > > Group: Individual Submission > > Pages: 6 > > URL: > https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-implicit-iv-01 > .txt > > Status: > https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ > > Htmlized: > https://tools.ietf.org/html/draft-mglt-ipsecme-implicit-iv-01 > > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-mglt-ipsecme-implicit-iv-01 > > > > Abstract: > > IPsec ESP sends an initialization vector (IV) or nonce in each > > packet, adding 8 or 16 octets. Some algorithms such as AES-GCM, = AES- > > CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do = not > > require an unpredictable nonce. When using such algorithms the > > packet counter value can be used to generate a nonce, saving 8 = octets > > per packet. This document describes how to do this. > > > > > > > > > > Please note that it may take a couple of minutes from the time of=20 > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > The IETF Secretariat > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Nov 1 06:20:40 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CC41296B5 for ; Tue, 1 Nov 2016 06:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.297 X-Spam-Level: * X-Spam-Status: No, score=1.297 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_SORBS_WEB=3.297, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgZ1ZMhPGCAA for ; Tue, 1 Nov 2016 06:20:36 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 E82C712945E for ; Tue, 1 Nov 2016 06:20:35 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id c13so19411515lfg.0 for ; Tue, 01 Nov 2016 06:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=h4c5JN4TUXHYRG2UIXQ6ajGhfMylnE7Cim+Y0RHslnk=; b=OH1zVjtDazifWk9OVVe1VCsGok5Jl4z571g2Ll+FXGbfdNE5f0dGUs7qbiQwfaq7CU W7gn8wQxIg8EQLo/xa6gru8zRcUTat1s51W6VD26iBOxcYuVBPUEe6A+3gA7EIwQ2aG9 0OIAtnetQ/xhnggFpezLI+j+9GgNz4qFqZRedfzHZcHVViF05HJ8NBEm1cwbz2ucmPpY gvASVzWbSOqH6sFM8MrZlNgDrjaDJwe8OcrELDXkJ2SbRQWO/z3J/r1yhJYXTo/ez9wv R1y7Jj4HwjZ2A7DGk7ySk4LofxXGbHFXulWVJELYdCxFHQhR4eMUbXEQdFSo6RXyt7XL sLkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=h4c5JN4TUXHYRG2UIXQ6ajGhfMylnE7Cim+Y0RHslnk=; b=M/mXagRdjH1k+QywABxUo1yxUHpfoiqo0DizO7Wa0BBKihwvepqhnSYxKFqe5gr/z+ 7ZE31H902grptw7F7ymAKVEClsb9ahC3F074VFIIO+fdzMyMqAdYEpClwAFDflY4EO7k S++3a7v1l9auUGIbFGe4b3tpRFE406yW/1nl78MdKTDUZ7yEISipAgF6P+ONIVdRe0pv 8BUTHy9rM0aw2OIch0bPUf8rzTXXbwwyaN1Mff2T+M9qC97ABjWDXX8/AQU4n3mSU9Zu ostCDzQWMA4ez+nQnY33gVNnIIHitEVJrdcG/CJlAkPjgY0YSZYRyGp0Lc+jtWxCU2rr CmZw== X-Gm-Message-State: ABUngvexZ5tRsac3mnEtgseTBb6tghczFivTe2wPeRjGsIeD50eeGJvM1ueD3UTkPNmT0A== X-Received: by 10.25.67.88 with SMTP id m24mr596420lfj.28.1478006433967; Tue, 01 Nov 2016 06:20:33 -0700 (PDT) Received: from svanPC ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id x189sm2141506lfa.28.2016.11.01.06.20.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Nov 2016 06:20:33 -0700 (PDT) From: "Valery Smyslov" To: "'Tobias Guggemos'" , "'Daniel Migault'" , "'IPsecME WG'" References: <147594692832.28921.7850239516371972090.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F98570@eusaamb107.ericsson.se> <001e01d22aa5$d3ebc4a0$7bc34de0$@mnm-team.org> <00e001d22aaa$20e01910$62a04b30$@gmail.com> <001301d23421$34f8ee60$9eeacb20$@mnm-team.org> In-Reply-To: <001301d23421$34f8ee60$9eeacb20$@mnm-team.org> Date: Tue, 1 Nov 2016 16:20:19 +0300 Message-ID: <073401d23442$b1543f20$13fcbd60$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMujZjKyFM1eyZtntAB2Ojf4WSB5wH0L881Ak+afe0CSBmo+ALvyNcOAZ9tScidspCHEA== Content-Language: ru Archived-At: Subject: Re: [IPsec] FW: New Version Notification fordraft-mglt-ipsecme-implicit-iv-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 13:20:39 -0000 Hi Tobias, that works for me, thank you. Regards, Valery. > Hey Valery, > Thanks for the explanation. I added the following statement to the = security considerations. Could you > please let me know if that resolves your concerns? >=20 > As the IV MUST NOT repeat for one SPI when Counter-Mode ciphers are > used, Implicit IV as described in this document MUST NOT be used in > setups with the chance that the Sequence Number overlaps for one = SPI. > Multicast as described in [RFC5374], [RFC6407] and > [I-D.yeung-g-ikev2] is a prominent example, where many senders = share > one secret and thus one SPI. Section 3.5 of [RFC6407] explains how > repetition MAY BE prevented by using a prefix for each group = member, > which could be prefixed to the Sequence Number. Otherwise, = Implicit > IV MUST NOT be used in multicast scenarios. >=20 > Thanks > Tobias >=20 > -----Urspr=FCngliche Nachricht----- > Von: Valery Smyslov [mailto:svanru@gmail.com] > Gesendet: Donnerstag, 20. Oktober 2016 10:16 > An: 'Tobias Guggemos' ; 'Daniel Migault' > ; 'IPsecME WG' > Betreff: RE: [IPsec] FW: New Version Notification = fordraft-mglt-ipsecme-implicit-iv-01.txt >=20 > Hi Tobias, >=20 > > Hey Valery, > > Thanks for the clarification, we'll add this statement in the draft! >=20 > Thank you. >=20 > > Just because I'm interested: For me, this seems to be a general > > problem for implementing counter > ciphers > > in multicast scenarios, regardless of implicit-iv or not. > > Do you know how the IV is usually chosen in = multicast-implementations? >=20 > The Group Controller assigns each sender a unique counter prefix. See = Section 3.5 of RFC 6407. >=20 > Regards, > Valery. >=20 > > Maybe we could add a recommendation in the draft. > > > > Thanks > > Tobias > > > > > > > > -----Urspr=FCngliche Nachricht----- > > Von: IPsec [mailto:ipsec-bounces@ietf.org] Im Auftrag von Valery > > Smyslov > > Gesendet: Montag, 10. Oktober 2016 09:06 > > An: Daniel Migault ; IPsecME WG > > > > Betreff: Re: [IPsec] FW: New Version Notification > > fordraft-mglt-ipsecme-implicit-iv-01.txt > > > > Hi Daniel, > > > > I think you should add a text in the Security Considerations that > > these transforms MUST NOT be > used in > > situations where there is a chance that Sequence Numbers repeat. The > > most prominent example where > it > > can happen - multicast ESP SA with multiple senders. > > > > Regards, > > Valery. > > > > > > > Hi, > > > > > > Based on the feed backs and the discussions from the previous = IETF, > > > see the updated version of our draft. We believe the document is = in > > > good > > shape to become a WG document. > > > > > > Feel free to support the draft and as usually, comments are = welcome! > > > > > > BR, > > > Daniel > > > > > > -----Original Message----- > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > Sent: Saturday, October 08, 2016 7:15 PM > > > To: Tobias Guggemos ; Yoav Nir > > > ; Daniel Migault = > > > Subject: New Version Notification for > > > draft-mglt-ipsecme-implicit-iv-01.txt > > > > > > > > > A new version of I-D, draft-mglt-ipsecme-implicit-iv-01.txt > > > has been successfully submitted by Daniel Migault and posted to = the > > > IETF > > repository. > > > > > > Name: draft-mglt-ipsecme-implicit-iv > > > Revision: 01 > > > Title: Implicit IV for Counter-based Ciphers in IPsec Document = date: > > > 2016-10-08 > > > Group: Individual Submission > > > Pages: 6 > > > URL: > > = https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-implicit-iv-01 > > .txt > > > Status: > > https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ > > > Htmlized: > > https://tools.ietf.org/html/draft-mglt-ipsecme-implicit-iv-01 > > > Diff: > > = https://www.ietf.org/rfcdiff?url2=3Ddraft-mglt-ipsecme-implicit-iv-01 > > > > > > Abstract: > > > IPsec ESP sends an initialization vector (IV) or nonce in each > > > packet, adding 8 or 16 octets. Some algorithms such as AES-GCM, = AES- > > > CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do = not > > > require an unpredictable nonce. When using such algorithms the > > > packet counter value can be used to generate a nonce, saving 8 = octets > > > per packet. This document describes how to do this. > > > > > > > > > > > > > > > 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. > > > > > > The IETF Secretariat > > > > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Nov 1 06:34:27 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D061295E1 for ; Tue, 1 Nov 2016 06:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.297, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yr6SltKcwoaT for ; Tue, 1 Nov 2016 06:34:24 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96715129424 for ; Tue, 1 Nov 2016 06:34:23 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id b81so126087382lfe.1 for ; Tue, 01 Nov 2016 06:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=Hs+RRf1pwUtGq3m/PX5eFRSgJ+fWUSVB20Js2S9S9xE=; b=wXUyNUFW1c4Cef17apMG1pmqtxXkG7nXio7qZP5p5KUiuyQ1pqi56vj/cR5gNWe4qX Sq4xI6VPsqOokwe05cNapKQng3IK+BX6Fo3mTVGbqmMRxB9EfKQVjWeXl9qVrlGWI/PX o/PWyJwK3r4WefJbZ2ecAfDW4X0Kz1TA2IVYxY5RPccWdkkuCnyewMbpDhUnNdORRzdV OE+7nsYDAtqANj+Tl+RZWnsF5CfLfieu/9phGTH8IH3EVAr2jFLKvE8YBYSHspyJ+NbX APz0cyzVYLRYxkuyK6Tglhap6Mk/UwOZR64jtAMYdSpF0yEC0E2Nhp3O9KS7vBN/aXhW GvLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=Hs+RRf1pwUtGq3m/PX5eFRSgJ+fWUSVB20Js2S9S9xE=; b=jotydggGGNfnAHzLwyvTnrnbl3e492ExjD7NXbyKk6EkXyjNs+9Q+2IgnIgavzKKTQ 8v9lUMez2HFgTEra76QHR9SSy3ANzfNe4lsCNdZWD/0oOj42Iyih5RLPBO6zovK/LR+3 q9xLdVNKnuS3luMxT/2eGCcdAkjjcGsqsclj8o3PzSHA4WE/ECOG3gplOVYXIsd9yCVJ l4S68MCT6XLLkfW8y1HoONWdlpSLLIPrtPN6TTUv74N2cXUvWHQ8CGPnLRlHC9rHOcps Yv6TKaDXBQ8UTY6+2ucEwSfQOnoGgmq9o8nofh0RAVkOx87rdkICKAWtpPQN0iE29+xi XpDQ== X-Gm-Message-State: ABUngvcSe72rExLvJYH16BGS8PSrk34cYx6K80lec53KZWf/GvwRrxe0Nl3CtgvLO+7o+w== X-Received: by 10.25.7.141 with SMTP id 135mr21206815lfh.143.1478007261595; Tue, 01 Nov 2016 06:34:21 -0700 (PDT) Received: from svanPC ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id g21sm399593lfe.47.2016.11.01.06.34.20 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Nov 2016 06:34:20 -0700 (PDT) From: "Valery Smyslov" To: "'Yoav Nir'" , "'Xuxiaohu'" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB272FF@NKGEML515-MBX.china.huawei.com> In-Reply-To: Date: Tue, 1 Nov 2016 16:34:06 +0300 Message-ID: <073501d23444$9e9374d0$dbba5e70$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0736_01D2345D.C3F175B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIgijxG97qfZ/mXhIQZ3OCYL8dpCwLV/HLyoBDBDHA= Content-Language: ru Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 13:34:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0736_01D2345D.C3F175B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, =20 I have almost the same list of questions as Yoav=E2=80=99s list. But = main question is -=20 how are you going to ensure that load balancer delivers ESP packets to the same cluster node where IKE messages that create this ESP SA were delivered? In other words, load balancer must deliver ESP packets to the node that can decrypt them, i.e. to the node that has appropriate keys, i.e. to the node that created this ESP SA, i.e. to the node IKE SA messages that created that ESP SA were delivered, and this messages = definitely had=20 different UDP ports. If balancer doesn=E2=80=99t know anything about = IKE/IPsec and looks only=20 on UDP ports, then how the above requirement is met? On the other hand, if you spread ESP keys over all cluster nodes, then why do you bother to care that load balancer delivers all ESP SA packets to the same node? =20 Regards, Valery. =20 From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Tuesday, November 01, 2016 10:31 AM To: Xuxiaohu Cc: ipsec@ietf.org Subject: Re: [IPsec] New Version Notification for = draft-xu-ipsecme-esp-in-udp-lb-00.txt =20 Hi, Xiaohu =20 A few comments. Actually, they=E2=80=99re more like questions. =20 1. How are IPsec SAs mapped to UDP pseudo-connections? Is it a 1:1 = mapping between SPI and source port? 2. If now, how do you deal with the packet reordering that the load = balancer will do? IPsec requires ordered or nearly-ordered delivery. 3. How is this negotiated? In IKE? Prior agreement? 4. Why do we need a new port? What goes wrong if the packets go to port = 4500? =20 Thanks =20 Yoav On 1 Nov 2016, at 3:45, Xuxiaohu wrote: =20 Hi all, Any comments and suggestions are welcome. Best regards, Xiaohu -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org] =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2016=E5=B9=B410=E6=9C=8831=E6=97=A5 19:15 =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; zhangdacheng; Xialiang (Frank) =E4=B8=BB=E9=A2=98: New Version Notification for = draft-xu-ipsecme-esp-in-udp-lb-00.txt A new version of I-D, draft-xu-ipsecme-esp-in-udp-lb-00.txt has been successfully submitted by Liang Xia and posted to the IETF = repository. Name: draft-xu-ipsecme-esp-in-udp-lb Revision: 00 Title: Encapsulating IPsec ESP in UDP for Load-balancing Document date: 2016-10-31 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-xu-ipsecme-esp-in-udp-lb-00.tx= t Status: https://datatracker.ietf.org/doc/draft-xu-ipsecme-esp-in-udp-lb/ Htmlized: = https://tools.ietf.org/html/draft-xu-ipsecme-esp-in-udp-lb-00 Abstract: IPsec Virtual Private Network (VPN) is widely used by enterprises to interconnect their geographical dispersed branch office locations across IP Wide Area Network (WAN). To fully utilize the bandwidth available in IP WAN, load balancing of traffic between different IPsec VPN sites over Equal Cost Multi-Path (ECMP) and/or Link Aggregation Group (LAG) within IP WAN is attractive to those enterprises deploying IPsec VPN solutions. This document defines a method to encapsulate IPsec Encapsulating Security Payload (ESP) packets inside UDP packets for improving load-balancing of IPsec tunneled traffic. In addition, this encapsulation is also applicable to some special multi-tenant data center network environment where the overlay tunnels need to be secured. 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. The IETF Secretariat _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 ------=_NextPart_000_0736_01D2345D.C3F175B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have almost the same list of questions as Yoav=E2=80=99s list. But = main question is -

how are you going to ensure that load balancer delivers ESP = packets

to the same cluster node where IKE messages that create this ESP = SA

were delivered? In other words, load balancer must deliver ESP = packets

to the node that can decrypt them, i.e. to the node that has = appropriate

keys, i.e. to the node that created this ESP SA, i.e. to the node IKE = SA

messages that created that ESP SA were delivered, and this messages = definitely had

different UDP ports. If balancer doesn=E2=80=99t know anything about = IKE/IPsec and looks only

on UDP ports, then how the above requirement is met? On the other = hand,

if you spread ESP keys over all cluster nodes, then why do you bother = to

care that load balancer delivers all ESP SA packets to the same = node?

 

Regards,

Valery.

 

From:= IPsec = [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav = Nir
Sent: Tuesday, November 01, 2016 10:31 AM
To: = Xuxiaohu
Cc: ipsec@ietf.org
Subject: Re: [IPsec] New = Version Notification for = draft-xu-ipsecme-esp-in-udp-lb-00.txt

 

Hi, Xiaohu

 

A few = comments. Actually, they=E2=80=99re more like = questions.

 

  1. How are = IPsec SAs mapped to UDP pseudo-connections?  Is it a 1:1 mapping = between SPI and source port?
  2. If now, = how do you deal with the packet reordering that the load balancer will = do? IPsec requires ordered or nearly-ordered = delivery.
  3. How is = this negotiated?  In IKE? Prior = agreement?
  4. Why do we = need a new port?  What goes wrong if the packets go to port = 4500?

 

Thanks

 

Yoav=

On 1 Nov 2016, at 3:45, Xuxiaohu <xuxiaohu@huawei.com> = wrote:

 

Hi = all,

Any comments and suggestions are welcome.

Best = regards,
Xiaohu


-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB= =B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org<= /a>]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97= =B4: 2016=E5=B9=B410=E6=9C=8831=E6=97=A5 19:15
=E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; zhangdacheng; = Xialiang (Frank)
=E4=B8=BB=E9=A2=98: New Version = Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt


A new = version of I-D, draft-xu-ipsecme-esp-in-udp-lb-00.txt
has been = successfully submitted by Liang Xia and posted to the IETF = repository.

Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 draft-xu-ipsecme-esp-in-udp-lb
Revision:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 00
Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Encapsulating IPsec ESP in UDP for = Load-balancing
Document date:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 2016-10-31
Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Individual Submission
Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 7
URL:
https://www.ietf.org/internet-drafts/draft-xu-ipsecme-esp-in-u= dp-lb-00.txt
Status:
https://datatracker.ietf.org/doc/draft-xu-= ipsecme-esp-in-udp-lb/
Htmlized: =       https://tools.ietf.org/html/draft-xu-= ipsecme-esp-in-udp-lb-00


Abstract:
 IPsec Virtual = Private Network (VPN) is widely used by enterprises = to
 interconnect their geographical dispersed branch office = locations
 across IP Wide Area Network (WAN). To fully utilize = the bandwidth
 available in IP WAN, load balancing of traffic = between different
 IPsec VPN sites over Equal Cost Multi-Path = (ECMP) and/or Link
 Aggregation Group (LAG) within IP WAN is = attractive to those
 enterprises deploying IPsec VPN solutions. = This document defines a
 method to encapsulate IPsec = Encapsulating Security Payload (ESP)
 packets inside UDP packets = for improving load-balancing of IPsec
 tunneled traffic. In = addition, this encapsulation is also applicable
 to some special = multi-tenant data center network environment where
 the overlay = tunnels need to be secured.




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.

The = IETF Secretariat


_______________________________________________
= IPsec mailing list
IPsec@ietf.org
https://www.ietf.org= /mailman/listinfo/ipsec

 

------=_NextPart_000_0736_01D2345D.C3F175B0-- From nobody Wed Nov 2 09:19:45 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66127129694 for ; Wed, 2 Nov 2016 09:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 AG7YwJwY5VSS for ; Wed, 2 Nov 2016 09:19:42 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B58B21294AC for ; Wed, 2 Nov 2016 09:19:42 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7AAE920568; Wed, 2 Nov 2016 12:35:08 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8B336637A6; Wed, 2 Nov 2016 12:19:41 -0400 (EDT) From: Michael Richardson To: Yoav Nir In-Reply-To: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB272FF@NKGEML515-MBX.china.huawei.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: "ipsec@ietf.org" , Xuxiaohu Subject: Re: [IPsec] New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 16:19:44 -0000 --=-=-= Content-Type: text/plain Yoav Nir wrote: > 4 Why do we need a new port? What goes wrong if the > packets go to port 4500? I think that TE/load-balancer in the network calculates the same tuple hash and so takes the same path. (Presuming that it ignores the source UDP port) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWBoSGoCLcPvd0N1lAQJMYwgAq3SnBggEhc7G0Pm2SAHSBUl+N0GUv/q7 mySIyr0RhVArUqXOgrG78aiyMxEhd/QaSzgVUArXILCLKV/MikT5PLYalbrtTArH 3aWnJQ+2NEpoDk4MIPiT5kcq+yF0mL4K45Q2pbJiA/ZmRjMpahJWgzRUGUQFStbp jVGbxhpAvL1uW9msjTZVTWhqcoc0JYlW2rznSpcjVv1MCcrR4wZPhAwhpmMS4hrs XU2Kq2ziUdVKutA1XvC7UyRuhHHmlt+FEvW+PUwf3lg9r+5LcDkENAxPJA+UCAKu vF3g7pEUukZxDZmtLMEvFBdT3yzbb1WznzOYrSIsWCCJiYI2npXrBw== =V3fE -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 2 09:42:29 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8A01296C8 for ; Wed, 2 Nov 2016 09:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7P0W2cril1HM for ; Wed, 2 Nov 2016 09:42:26 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 AC7271296DA for ; Wed, 2 Nov 2016 09:42:25 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id a197so152558384wmd.0 for ; Wed, 02 Nov 2016 09:42:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k2WKtF01MmmauBHkBLBWJpjDMtCFYT7bJzKLABfhMdY=; b=dpek6NmuWTaH9W1jBtusQoVqJT33/mb1ggppYZwjbISeOMy1j45qcqmWKbxKX44vUQ YtL4Hx/ZZ7aNL5sWHc7d5QM1KFjmapkdlsKa6rYirVZ4MUY62JQh/XzGI51vSbJBcJzw /66Rwjc8We8+LtA5xMplFWQRyQt5wArs1GMJDV1i403nXRQsEWICB26eUxozsPUBO8h8 XlGT9CdB8NdGdFOfMyZM/JLiguz3i9c49cbWEUT1bgAfsU8Z483THaNs8AtjPvg8uxJC wWELmnsnIQVXmdjwnblfl1scy7DFgUm0I4LREGcLIcL/lqbG6q6coiuUhQjbZMiBBG6P vslQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k2WKtF01MmmauBHkBLBWJpjDMtCFYT7bJzKLABfhMdY=; b=eyZgD0HtaTDKahoVk4fKOpdkEQ+vzbl4DXKQuNhmeaqpve5t0PrlhKnNWtGWyJ8bmr HmQCYnOPfjkYQMcH3XDIu+LzklYDkjhHZLYDDEkyqVC1sbaH8jw93ia7iVyzIAyyV8Pr dRaYa/DxpA8gnwc8Nq9zf8SpWlQ2wwoOhWvcjYEohzCJNC+ceu1UL2EyXlYCbSg81XF6 A0Lb/yyG6dO43hNEHvasUtNVXntVUpG0Yo0awG0XNGhDTBx/zFif3z44b8KPFfmbx4SM NLTAOUyYNeGhO351KKvyaA8jSUP9w/Lt6nX0wGmamCWs7tj5YQEpqFXgNOef2zTzuLC3 BKgQ== X-Gm-Message-State: ABUngvcSe8Ln4QbcSH5OCx3fse6MvAKZLQdyY4G7V/WI/guvGW0HKTawZod0VWKR7sRAkw== X-Received: by 10.194.222.169 with SMTP id qn9mr3694361wjc.62.1478104944233; Wed, 02 Nov 2016 09:42:24 -0700 (PDT) Received: from macbook-pro-2.mshome.net ([109.253.128.232]) by smtp.gmail.com with ESMTPSA id f4sm37318314wmd.15.2016.11.02.09.42.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Nov 2016 09:42:23 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Yoav Nir In-Reply-To: <18805.1478103581@obiwan.sandelman.ca> Date: Wed, 2 Nov 2016 18:42:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0D919BEB-8335-4E5F-8C83-62E92FC518DB@gmail.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB272FF@NKGEML515-MBX.china.huawei.com> <18805.1478103581@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "ipsec@ietf.org" , Xuxiaohu Subject: Re: [IPsec] New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 16:42:28 -0000 > On 2 Nov 2016, at 18:19, Michael Richardson = wrote: >=20 >=20 > Yoav Nir wrote: >> 4 Why do we need a new port? What goes wrong if the >> packets go to port 4500? >=20 > I think that TE/load-balancer in the network calculates the same tuple = hash > and so takes the same path. (Presuming that it ignores the source UDP = port) I don=E2=80=99t follow. The draft requests a new destination port from = IANA. Let=E2=80=99s assume it is 14500.=20 What is the difference between having every gateway send traffic with = the 5-tuple (me, random_port, UDP, you, 4500) and having every gateway = send traffic with the 5-tuple (me, random_port, UDP, you, 14500) ? Sending UDP-encapsulated traffic from a random port works today, and has = the advantage that middleboxes trying to classify traffic already know = what it is. Yoav . From nobody Wed Nov 2 20:37:01 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDE412968A for ; Wed, 2 Nov 2016 20:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 onf8GRCxvONC for ; Wed, 2 Nov 2016 20:36:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E900F12946F for ; Wed, 2 Nov 2016 20:36:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZO90122; Thu, 03 Nov 2016 03:36:53 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 03:36:52 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 11:36:48 +0800 From: Xuxiaohu To: Yoav Nir , Michael Richardson Thread-Topic: [IPsec] New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt Thread-Index: AQHSM2gb01BpbARQ5EG6ZJX9p7ME46DDW/lw///ayQCAAiYlgIAABlQAgAE66AA= Date: Thu, 3 Nov 2016 03:36:48 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB281C7@NKGEML515-MBX.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB272FF@NKGEML515-MBX.china.huawei.com> <18805.1478103581@obiwan.sandelman.ca> <0D919BEB-8335-4E5F-8C83-62E92FC518DB@gmail.com> In-Reply-To: <0D919BEB-8335-4E5F-8C83-62E92FC518DB@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.581AB0D6.00AC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c4a6b5dd76c3ff94bb2f6e597920df23 Archived-At: Cc: "ipsec@ietf.org" Subject: [IPsec] =?utf-8?b?562U5aSNOiAgTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u?= =?utf-8?q?_for_draft-xu-ipsecme-esp-in-udp-lb-00=2Etxt?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 03:36:59 -0000 SGkgWW9hdiBhbmQgTWljaGFlbCwNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0KDQpJZiBJ IHVuZGVyc3RhbmQgaXQgY29ycmVjdGx5LCB0aGUgZGVzdCBwb3J0IG51bWJlciBvZiA0NTAwIGhh cyBiZWVuIGRlZGljYXRlZCBmb3IgdGhlIE5BVCB0cmF2ZXJzYWwgdXNhZ2UgYXMgZGVzY3JpYmVk IGluIFJGQzM5NDggd2hlcmUgIiB0aGUgU291cmNlIFBvcnQgYW5kIERlc3RpbmF0aW9uIFBvcnQg TVVTVCBiZSB0aGUgc2FtZSBhcyB0aGF0IHVzZWQgYnkgSUtFIHRyYWZmaWMiLCB0aGVyZWZvcmUs IGl0J2QgYmV0dGVyIGZvciB1cyB0byByZXF1ZXN0IGEgbmV3IGRlc3QgcG9ydCBmb3IgdGhlIGxv YWQtYmFsYW5jaW5nIHVzYWdlIGFzIGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0Lg0KDQpCZXN0IHJl Z2FyZHMsDQpYaWFvaHUNCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujog WW9hdiBOaXIgW21haWx0bzp5bmlyLmlldGZAZ21haWwuY29tXQ0KPiDlj5HpgIHml7bpl7Q6IDIw MTblubQxMeaciDPml6UgMDo0Mg0KPiDmlLbku7bkuro6IE1pY2hhZWwgUmljaGFyZHNvbg0KPiDm ioTpgIE6IFh1eGlhb2h1OyBpcHNlY0BpZXRmLm9yZw0KPiDkuLvpopg6IFJlOiBbSVBzZWNdIE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJhZnQteHUtaXBzZWNtZS1lc3AtaW4tdWRw LWxiLTAwLnR4dA0KPiANCj4gDQo+ID4gT24gMiBOb3YgMjAxNiwgYXQgMTg6MTksIE1pY2hhZWwg UmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPg0KPiB3cm90ZToNCj4gPg0KPiA+DQo+ ID4gWW9hdiBOaXIgPHluaXIuaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiA+PiA0IFdoeSBkbyB3 ZSBuZWVkIGEgbmV3IHBvcnQ/IFdoYXQgZ29lcyB3cm9uZyBpZiB0aGUgcGFja2V0cyBnbyB0bw0K PiA+PiBwb3J0IDQ1MDA/DQo+ID4NCj4gPiBJIHRoaW5rIHRoYXQgVEUvbG9hZC1iYWxhbmNlciBp biB0aGUgbmV0d29yayBjYWxjdWxhdGVzIHRoZSBzYW1lIHR1cGxlDQo+ID4gaGFzaCBhbmQgc28g dGFrZXMgdGhlIHNhbWUgcGF0aC4gKFByZXN1bWluZyB0aGF0IGl0IGlnbm9yZXMgdGhlIHNvdXJj ZQ0KPiA+IFVEUCBwb3J0KQ0KPiANCj4gSSBkb27igJl0IGZvbGxvdy4gVGhlIGRyYWZ0IHJlcXVl c3RzIGEgbmV3IGRlc3RpbmF0aW9uIHBvcnQgZnJvbSBJQU5BLiBMZXTigJlzDQo+IGFzc3VtZSBp dCBpcyAxNDUwMC4NCj4gDQo+IFdoYXQgaXMgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBoYXZpbmcg ZXZlcnkgZ2F0ZXdheSBzZW5kIHRyYWZmaWMgd2l0aCB0aGUNCj4gNS10dXBsZSAobWUsIHJhbmRv bV9wb3J0LCBVRFAsIHlvdSwgNDUwMCkgYW5kIGhhdmluZyBldmVyeSBnYXRld2F5IHNlbmQNCj4g dHJhZmZpYyB3aXRoIHRoZSA1LXR1cGxlIChtZSwgcmFuZG9tX3BvcnQsIFVEUCwgeW91LCAxNDUw MCkgPw0KPiANCj4gU2VuZGluZyBVRFAtZW5jYXBzdWxhdGVkIHRyYWZmaWMgZnJvbSBhIHJhbmRv bSBwb3J0IHdvcmtzIHRvZGF5LCBhbmQgaGFzIHRoZQ0KPiBhZHZhbnRhZ2UgdGhhdCBtaWRkbGVi b3hlcyB0cnlpbmcgdG8gY2xhc3NpZnkgdHJhZmZpYyBhbHJlYWR5IGtub3cgd2hhdCBpdCBpcy4N Cj4gDQo+IFlvYXYNCj4gLg0KPiANCg0K From nobody Wed Nov 2 23:19:50 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82668129961 for ; Wed, 2 Nov 2016 23:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 CwpRqMTKT0nw for ; Wed, 2 Nov 2016 23:19:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B4761298C0 for ; Wed, 2 Nov 2016 23:19:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUK64665; Thu, 03 Nov 2016 06:19:39 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 06:19:38 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 14:19:31 +0800 From: Xuxiaohu To: Valery Smyslov , "'Yoav Nir'" Thread-Topic: [IPsec] New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt Thread-Index: AQHSM2gb01BpbARQ5EG6ZJX9p7ME46DDW/lw///ayQCAAGWNAIADMK5Q Date: Thu, 3 Nov 2016 06:19:31 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB28217@NKGEML515-MBX.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB272FF@NKGEML515-MBX.china.huawei.com> <073501d23444$9e9374d0$dbba5e70$@gmail.com> In-Reply-To: <073501d23444$9e9374d0$dbba5e70$@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB28217NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.581AD6FC.0056, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f5a56d0a497d419baf9b3b3967f15b8d Archived-At: Cc: "ipsec@ietf.org" Subject: [IPsec] =?utf-8?b?562U5aSNOiAgTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u?= =?utf-8?q?_for_draft-xu-ipsecme-esp-in-udp-lb-00=2Etxt?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 06:19:47 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB28217NKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVmFsZXJ5LA0KDQpUaGUgbG9hZC1iYWxhbmNpbmcgbWVjaGFuaXNtIGFzIGRlc2NyaWJlZCBp biB0aGlzIGRyYWZ0IGlzIHRvIGJhbGFuY2UgdGhlIHRyYWZmaWMgZmxvd3Mgb3ZlciBFQ01QcyBy YXRoZXIgdGhhbiBvdmVyIGRpZmZlcmVudCBjbHVzdGVyIG5vZGVzLg0KDQpCZXN0IHJlZ2FyZHMs DQpYaWFvaHUNCg0K5Y+R5Lu25Lq6OiBWYWxlcnkgU215c2xvdiBbbWFpbHRvOnN2YW5ydUBnbWFp bC5jb21dDQrlj5HpgIHml7bpl7Q6IDIwMTblubQxMeaciDHml6UgMjE6MzQNCuaUtuS7tuS6ujog J1lvYXYgTmlyJzsgWHV4aWFvaHUNCuaKhOmAgTogaXBzZWNAaWV0Zi5vcmcNCuS4u+mimDogUkU6 IFtJUHNlY10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC14dS1pcHNlY21lLWVz cC1pbi11ZHAtbGItMDAudHh0DQoNCkhpLA0KDQpJIGhhdmUgYWxtb3N0IHRoZSBzYW1lIGxpc3Qg b2YgcXVlc3Rpb25zIGFzIFlvYXbigJlzIGxpc3QuIEJ1dCBtYWluIHF1ZXN0aW9uIGlzIC0NCmhv dyBhcmUgeW91IGdvaW5nIHRvIGVuc3VyZSB0aGF0IGxvYWQgYmFsYW5jZXIgZGVsaXZlcnMgRVNQ IHBhY2tldHMNCnRvIHRoZSBzYW1lIGNsdXN0ZXIgbm9kZSB3aGVyZSBJS0UgbWVzc2FnZXMgdGhh dCBjcmVhdGUgdGhpcyBFU1AgU0ENCndlcmUgZGVsaXZlcmVkPyBJbiBvdGhlciB3b3JkcywgbG9h ZCBiYWxhbmNlciBtdXN0IGRlbGl2ZXIgRVNQIHBhY2tldHMNCnRvIHRoZSBub2RlIHRoYXQgY2Fu IGRlY3J5cHQgdGhlbSwgaS5lLiB0byB0aGUgbm9kZSB0aGF0IGhhcyBhcHByb3ByaWF0ZQ0Ka2V5 cywgaS5lLiB0byB0aGUgbm9kZSB0aGF0IGNyZWF0ZWQgdGhpcyBFU1AgU0EsIGkuZS4gdG8gdGhl IG5vZGUgSUtFIFNBDQptZXNzYWdlcyB0aGF0IGNyZWF0ZWQgdGhhdCBFU1AgU0Egd2VyZSBkZWxp dmVyZWQsIGFuZCB0aGlzIG1lc3NhZ2VzIGRlZmluaXRlbHkgaGFkDQpkaWZmZXJlbnQgVURQIHBv cnRzLiBJZiBiYWxhbmNlciBkb2VzbuKAmXQga25vdyBhbnl0aGluZyBhYm91dCBJS0UvSVBzZWMg YW5kIGxvb2tzIG9ubHkNCm9uIFVEUCBwb3J0cywgdGhlbiBob3cgdGhlIGFib3ZlIHJlcXVpcmVt ZW50IGlzIG1ldD8gT24gdGhlIG90aGVyIGhhbmQsDQppZiB5b3Ugc3ByZWFkIEVTUCBrZXlzIG92 ZXIgYWxsIGNsdXN0ZXIgbm9kZXMsIHRoZW4gd2h5IGRvIHlvdSBib3RoZXIgdG8NCmNhcmUgdGhh dCBsb2FkIGJhbGFuY2VyIGRlbGl2ZXJzIGFsbCBFU1AgU0EgcGFja2V0cyB0byB0aGUgc2FtZSBu b2RlPw0KDQpSZWdhcmRzLA0KVmFsZXJ5Lg0KDQpGcm9tOiBJUHNlYyBbbWFpbHRvOmlwc2VjLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBZb2F2IE5pcg0KU2VudDogVHVlc2RheSwgTm92 ZW1iZXIgMDEsIDIwMTYgMTA6MzEgQU0NClRvOiBYdXhpYW9odQ0KQ2M6IGlwc2VjQGlldGYub3Jn PG1haWx0bzppcHNlY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSVBzZWNdIE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteHUtaXBzZWNtZS1lc3AtaW4tdWRwLWxiLTAwLnR4dA0K DQpIaSwgWGlhb2h1DQoNCkEgZmV3IGNvbW1lbnRzLiBBY3R1YWxseSwgdGhleeKAmXJlIG1vcmUg bGlrZSBxdWVzdGlvbnMuDQoNCg0KICAxLiAgSG93IGFyZSBJUHNlYyBTQXMgbWFwcGVkIHRvIFVE UCBwc2V1ZG8tY29ubmVjdGlvbnM/ICBJcyBpdCBhIDE6MSBtYXBwaW5nIGJldHdlZW4gU1BJIGFu ZCBzb3VyY2UgcG9ydD8NCiAgMi4gIElmIG5vdywgaG93IGRvIHlvdSBkZWFsIHdpdGggdGhlIHBh Y2tldCByZW9yZGVyaW5nIHRoYXQgdGhlIGxvYWQgYmFsYW5jZXIgd2lsbCBkbz8gSVBzZWMgcmVx dWlyZXMgb3JkZXJlZCBvciBuZWFybHktb3JkZXJlZCBkZWxpdmVyeS4NCiAgMy4gIEhvdyBpcyB0 aGlzIG5lZ290aWF0ZWQ/ICBJbiBJS0U/IFByaW9yIGFncmVlbWVudD8NCiAgNC4gIFdoeSBkbyB3 ZSBuZWVkIGEgbmV3IHBvcnQ/ICBXaGF0IGdvZXMgd3JvbmcgaWYgdGhlIHBhY2tldHMgZ28gdG8g cG9ydCA0NTAwPw0KDQpUaGFua3MNCg0KWW9hdg0KT24gMSBOb3YgMjAxNiwgYXQgMzo0NSwgWHV4 aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb208bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20+PiB3 cm90ZToNCg0KSGkgYWxsLA0KDQpBbnkgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxj b21lLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K 5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZz4gW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQrlj5HpgIHml7bp l7Q6IDIwMTblubQxMOaciDMx5pelIDE5OjE1DQrmlLbku7bkuro6IFh1eGlhb2h1OyB6aGFuZ2Rh Y2hlbmc7IFhpYWxpYW5nIChGcmFuaykNCuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC14dS1pcHNlY21lLWVzcC1pbi11ZHAtbGItMDAudHh0DQoNCg0KQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LXh1LWlwc2VjbWUtZXNwLWluLXVkcC1sYi0wMC50eHQNCmhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTGlhbmcgWGlhIGFuZCBwb3N0ZWQgdG8gdGhl IElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LXh1 LWlwc2VjbWUtZXNwLWluLXVkcC1sYg0KUmV2aXNpb246ICAgICAgMDANClRpdGxlOiAgICAgICAg ICAgICBFbmNhcHN1bGF0aW5nIElQc2VjIEVTUCBpbiBVRFAgZm9yIExvYWQtYmFsYW5jaW5nDQpE b2N1bWVudCBkYXRlOiAgICAgICAgMjAxNi0xMC0zMQ0KR3JvdXA6ICAgICAgICAgICAgICAgICAg ICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAgICAgICAgICAgICAgICA3 DQpVUkw6DQpodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteHUtaXBz ZWNtZS1lc3AtaW4tdWRwLWxiLTAwLnR4dA0KU3RhdHVzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQteHUtaXBzZWNtZS1lc3AtaW4tdWRwLWxiLw0KSHRtbGl6ZWQ6ICAg ICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1pcHNlY21lLWVzcC1pbi11 ZHAtbGItMDANCg0KDQpBYnN0cmFjdDoNCiBJUHNlYyBWaXJ0dWFsIFByaXZhdGUgTmV0d29yayAo VlBOKSBpcyB3aWRlbHkgdXNlZCBieSBlbnRlcnByaXNlcyB0bw0KIGludGVyY29ubmVjdCB0aGVp ciBnZW9ncmFwaGljYWwgZGlzcGVyc2VkIGJyYW5jaCBvZmZpY2UgbG9jYXRpb25zDQogYWNyb3Nz IElQIFdpZGUgQXJlYSBOZXR3b3JrIChXQU4pLiBUbyBmdWxseSB1dGlsaXplIHRoZSBiYW5kd2lk dGgNCiBhdmFpbGFibGUgaW4gSVAgV0FOLCBsb2FkIGJhbGFuY2luZyBvZiB0cmFmZmljIGJldHdl ZW4gZGlmZmVyZW50DQogSVBzZWMgVlBOIHNpdGVzIG92ZXIgRXF1YWwgQ29zdCBNdWx0aS1QYXRo IChFQ01QKSBhbmQvb3IgTGluaw0KIEFnZ3JlZ2F0aW9uIEdyb3VwIChMQUcpIHdpdGhpbiBJUCBX QU4gaXMgYXR0cmFjdGl2ZSB0byB0aG9zZQ0KIGVudGVycHJpc2VzIGRlcGxveWluZyBJUHNlYyBW UE4gc29sdXRpb25zLiBUaGlzIGRvY3VtZW50IGRlZmluZXMgYQ0KIG1ldGhvZCB0byBlbmNhcHN1 bGF0ZSBJUHNlYyBFbmNhcHN1bGF0aW5nIFNlY3VyaXR5IFBheWxvYWQgKEVTUCkNCiBwYWNrZXRz IGluc2lkZSBVRFAgcGFja2V0cyBmb3IgaW1wcm92aW5nIGxvYWQtYmFsYW5jaW5nIG9mIElQc2Vj DQogdHVubmVsZWQgdHJhZmZpYy4gSW4gYWRkaXRpb24sIHRoaXMgZW5jYXBzdWxhdGlvbiBpcyBh bHNvIGFwcGxpY2FibGUNCiB0byBzb21lIHNwZWNpYWwgbXVsdGktdGVuYW50IGRhdGEgY2VudGVy IG5ldHdvcmsgZW52aXJvbm1lbnQgd2hlcmUNCiB0aGUgb3ZlcmxheSB0dW5uZWxzIG5lZWQgdG8g YmUgc2VjdXJlZC4NCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0K VGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCklQc2VjIG1haWxpbmcgbGlzdA0KSVBzZWNAaWV0Zi5vcmc8bWFpbHRv OklQc2VjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p cHNlYw0KDQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB28217NKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6UE1pbmdMaVU7DQoJcGFub3NlLTE6MiAyIDUgMCAw IDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0K CXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAw IDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAUE1pbmdMaVUiOw0K CXBhbm9zZS0xOjIgMiA1IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpNZW5sby1SZWd1bGFyO30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH 5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZTo5LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNw YW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojNDQ1NDZBO30NCnNwYW4uQ2hhcg0KCXtt c28tc3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk65a6L 5L2TO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46Mi4wY20gNDIuNXB0IDIuMGNtIDMuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7 bXNvLWxpc3QtaWQ6MjY2MDEzMzQxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTY1NDU5NjE3 Njt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo5MDM0ODYwNTU7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOjgxNDA4OTI1NDt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9w OjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVs NQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNv LWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10 YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgVmFs ZXJ5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgbG9hZC1iYWxhbmNp bmcgbWVjaGFuaXNtIGFzIGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0IGlzIHRvIGJhbGFuY2UgdGhl IHRyYWZmaWMgZmxvd3Mgb3ZlciBFQ01QcyByYXRoZXIgdGhhbiBvdmVyIGRpZmZlcmVudCBjbHVz dGVyIG5vZGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2Fy ZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5YaWFvaHUNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZMiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVO LVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+IFZhbGVyeSBTbXlzbG92IFttYWlsdG86c3Zh bnJ1QGdtYWlsLmNvbV0NCjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTrlrovkvZMiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46 PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+IDIwMTY8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+MTE8L3Nw YW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjE8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPg0K IDIxOjM0PGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+ICdZb2F2IE5pcic7IFh1eGlhb2h1PGJyPg0KPC9zcGFu PjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyI+IGlwc2VjQGlldGYub3JnPGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVT Ij46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJFOiBbSVBzZWNdIE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteHUtaXBzZWNtZS1lc3AtaW4tdWRwLWxiLTAwLnR4dDxv OnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzQ0NTQ2QSI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojNDQ1NDZBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NDU0 NkEiPkkgaGF2ZSBhbG1vc3QgdGhlIHNhbWUgbGlzdCBvZiBxdWVzdGlvbnMgYXMgWW9hduKAmXMg bGlzdC4gQnV0IG1haW4gcXVlc3Rpb24gaXMgLQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTQu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojNDQ1NDZBIj5ob3cgYXJlIHlvdSBnb2luZyB0byBlbnN1cmUgdGhhdCBsb2FkIGJh bGFuY2VyIGRlbGl2ZXJzIEVTUCBwYWNrZXRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojNDQ1NDZBIj50byB0aGUgc2FtZSBjbHVzdGVyIG5vZGUgd2hlcmUgSUtFIG1lc3NhZ2Vz IHRoYXQgY3JlYXRlIHRoaXMgRVNQIFNBPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojNDQ1NDZBIj53ZXJlIGRlbGl2ZXJlZD8gSW4gb3RoZXIgd29yZHMsIGxvYWQgYmFsYW5jZXIg bXVzdCBkZWxpdmVyIEVTUCBwYWNrZXRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojNDQ1NDZBIj50byB0aGUgbm9kZSB0aGF0IGNhbiBkZWNyeXB0IHRoZW0sIGkuZS4gdG8gdGhl IG5vZGUgdGhhdCBoYXMgYXBwcm9wcmlhdGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiM0NDU0NkEiPmtleXMsIGkuZS4gdG8gdGhlIG5vZGUgdGhhdCBjcmVhdGVkIHRoaXMgRVNQ IFNBLCBpLmUuIHRvIHRoZSBub2RlIElLRSBTQTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0LjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzQ0NTQ2QSI+bWVzc2FnZXMgdGhhdCBjcmVhdGVkIHRoYXQgRVNQIFNBIHdlcmUgZGVs aXZlcmVkLCBhbmQgdGhpcyBtZXNzYWdlcyBkZWZpbml0ZWx5IGhhZA0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojNDQ1NDZBIj5kaWZmZXJlbnQgVURQIHBvcnRzLiBJZiBiYWxh bmNlciBkb2VzbuKAmXQga25vdyBhbnl0aGluZyBhYm91dCBJS0UvSVBzZWMgYW5kIGxvb2tzIG9u bHkNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+b24gVURQIHBv cnRzLCB0aGVuIGhvdyB0aGUgYWJvdmUgcmVxdWlyZW1lbnQgaXMgbWV0PyBPbiB0aGUgb3RoZXIg aGFuZCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPmlmIHlvdSBz cHJlYWQgRVNQIGtleXMgb3ZlciBhbGwgY2x1c3RlciBub2RlcywgdGhlbiB3aHkgZG8geW91IGJv dGhlciB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+Y2FyZSB0 aGF0IGxvYWQgYmFsYW5jZXIgZGVsaXZlcnMgYWxsIEVTUCBTQSBwYWNrZXRzIHRvIHRoZSBzYW1l IG5vZGU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDQ1NDZBIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPlJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDQ1NDZBIj5WYWxlcnkuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDQ1NDZBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IElQc2VjIFs8YSBocmVmPSJtYWlsdG86aXBzZWMtYm91bmNlc0BpZXRm Lm9yZyI+bWFpbHRvOmlwc2VjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5Zb2F2IE5pcjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBOb3ZlbWJlciAwMSwgMjAx NiAxMDozMSBBTTxicj4NCjxiPlRvOjwvYj4gWHV4aWFvaHU8YnI+DQo8Yj5DYzo8L2I+IDxhIGhy ZWY9Im1haWx0bzppcHNlY0BpZXRmLm9yZyI+aXBzZWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbSVBzZWNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt eHUtaXBzZWNtZS1lc3AtaW4tdWRwLWxiLTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i UlUiPkhpLCZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJSVSIgc3R5bGU9ImZvbnQtc2l6ZTo4LjVw dDtmb250LWZhbWlseTpNZW5sby1SZWd1bGFyIj5YaWFvaHU8L3NwYW4+PHNwYW4gbGFuZz0iUlUi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJSVSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiIHN0eWxlPSJmb250LXNpemU6OC41 cHQ7Zm9udC1mYW1pbHk6TWVubG8tUmVndWxhciI+QSBmZXcgY29tbWVudHMuIEFjdHVhbGx5LCB0 aGV54oCZcmUgbW9yZSBsaWtlIHF1ZXN0aW9ucy48L3NwYW4+PHNwYW4gbGFuZz0iUlUiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IlJVIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsMSBsZXZlbDEgbGZvMyI+DQo8c3BhbiBsYW5nPSJSVSIgc3R5bGU9ImZvbnQtc2l6ZTo4LjVw dDtmb250LWZhbWlseTpNZW5sby1SZWd1bGFyIj5Ib3cgYXJlIElQc2VjIFNBcyBtYXBwZWQgdG8g VURQIHBzZXVkby1jb25uZWN0aW9ucz8gJm5ic3A7SXMgaXQgYSAxOjEgbWFwcGluZyBiZXR3ZWVu IFNQSSBhbmQgc291cmNlIHBvcnQ/PC9zcGFuPjxzcGFuIGxhbmc9IlJVIj48bzpwPjwvbzpwPjwv c3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMi Pg0KPHNwYW4gbGFuZz0iUlUiIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6TWVu bG8tUmVndWxhciI+SWYgbm93LCBob3cgZG8geW91IGRlYWwgd2l0aCB0aGUgcGFja2V0IHJlb3Jk ZXJpbmcgdGhhdCB0aGUgbG9hZCBiYWxhbmNlciB3aWxsIGRvPyBJUHNlYyByZXF1aXJlcyBvcmRl cmVkIG9yIG5lYXJseS1vcmRlcmVkIGRlbGl2ZXJ5Ljwvc3Bhbj48c3BhbiBsYW5nPSJSVSI+PG86 cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxl dmVsMSBsZm8zIj4NCjxzcGFuIGxhbmc9IlJVIiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQt ZmFtaWx5Ok1lbmxvLVJlZ3VsYXIiPkhvdyBpcyB0aGlzIG5lZ290aWF0ZWQ/ICZuYnNwO0luIElL RT8gUHJpb3IgYWdyZWVtZW50Pzwvc3Bhbj48c3BhbiBsYW5nPSJSVSI+PG86cD48L286cD48L3Nw YW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8zIj4N CjxzcGFuIGxhbmc9IlJVIiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5Ok1lbmxv LVJlZ3VsYXIiPldoeSBkbyB3ZSBuZWVkIGEgbmV3IHBvcnQ/ICZuYnNwO1doYXQgZ29lcyB3cm9u ZyBpZiB0aGUgcGFja2V0cyBnbyB0byBwb3J0IDQ1MDA/PC9zcGFuPjxzcGFuIGxhbmc9IlJVIj48 bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvb2w+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iUlUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIiBzdHlsZT0iZm9udC1zaXpl OjguNXB0O2ZvbnQtZmFtaWx5Ok1lbmxvLVJlZ3VsYXIiPlRoYW5rczwvc3Bhbj48c3BhbiBsYW5n PSJSVSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIiBzdHlsZT0i Zm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5Ok1lbmxvLVJlZ3VsYXIiPllvYXY8L3NwYW4+PHNw YW4gbGFuZz0iUlUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj5PbiAxIE5vdiAyMDE2LCBh dCAzOjQ1LCBYdXhpYW9odSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20i Pnh1eGlhb2h1QGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iUlUiPkhpIGFsbCw8YnI+DQo8 YnI+DQpBbnkgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLjxicj4NCjxicj4N CkJlc3QgcmVnYXJkcyw8YnI+DQpYaWFvaHU8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+LS0tLS08L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1BNaW5nTGlVJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij7pgq7ku7bljp/ku7Y8L3NwYW4+PHNwYW4gbGFuZz0iUlUiPi0tLS0tPGJyPg0KPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtQTWluZ0xpVSZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+5Y+R5Lu25Lq6PC9zcGFuPjxzcGFuIGxhbmc9IlJVIj46IDxhIGhyZWY9Im1haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPg0KaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9h PiBbPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+bWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT5dPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtQTWluZ0xpVSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+5Y+R6YCB5pe26Ze0 PC9zcGFuPjxzcGFuIGxhbmc9IlJVIj46IDIwMTY8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O01TIE1pbmNobyZxdW90OyI+5bm0PC9zcGFuPjxzcGFuIGxhbmc9IlJVIj4xMDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgTWluY2hvJnF1b3Q7Ij7mnIg8 L3NwYW4+PHNwYW4gbGFuZz0iUlUiPjMxPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtNUyBNaW5jaG8mcXVvdDsiPuaXpTwvc3Bhbj48c3BhbiBsYW5nPSJSVSI+DQogMTk6MTU8 YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIE1pbmNobyZxdW90 OyI+5pS25Lu25Lq6PC9zcGFuPjxzcGFuIGxhbmc9IlJVIj46IFh1eGlhb2h1OyB6aGFuZ2RhY2hl bmc7IFhpYWxpYW5nIChGcmFuayk8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O01TIE1pbmNobyZxdW90OyI+5Li7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtQTWluZ0xpVSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+6aKYPC9zcGFuPjxzcGFu IGxhbmc9IlJVIj46IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteHUtaXBzZWNt ZS1lc3AtaW4tdWRwLWxiLTAwLnR4dDxicj4NCjxicj4NCjxicj4NCkEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC14dS1pcHNlY21lLWVzcC1pbi11ZHAtbGItMDAudHh0PGJyPg0KaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMaWFuZyBYaWEgYW5kIHBvc3RlZCB0byB0aGUgSUVU RiByZXBvc2l0b3J5Ljxicj4NCjxicj4NCk5hbWU6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFu Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPmRyYWZ0LXh1LWlwc2VjbWUtZXNwLWluLXVkcC1s Yjxicj4NClJldmlzaW9uOjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4wMDxicj4NClRpdGxlOjxzcGFuIGNsYXNzPSJhcHBs ZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5FbmNhcHN1bGF0aW5nIElQc2VjIEVT UCBpbiBVRFAgZm9yIExvYWQtYmFsYW5jaW5nPGJyPg0KRG9jdW1lbnQgZGF0ZTo8c3BhbiBjbGFz cz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8L3NwYW4+MjAxNi0xMC0zMTxicj4NCkdyb3VwOjxzcGFuIGNsYXNzPSJhcHBsZS10YWIt c3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5JbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQpQYWdl czo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+ Nzxicj4NClVSTDo8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQteHUtaXBzZWNtZS1lc3AtaW4tdWRwLWxiLTAwLnR4dCI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXh1LWlwc2VjbWUtZXNwLWluLXVkcC1sYi0w MC50eHQ8L2E+PGJyPg0KU3RhdHVzOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXh1LWlwc2VjbWUtZXNwLWluLXVkcC1sYi8iPmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXh1LWlwc2VjbWUtZXNwLWluLXVkcC1sYi88L2E+ PGJyPg0KSHRtbGl6ZWQ6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1pcHNlY21lLWVzcC1pbi11 ZHAtbGItMDAiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1pcHNlY21lLWVz cC1pbi11ZHAtbGItMDA8L2E+PGJyPg0KPGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7 SVBzZWMgVmlydHVhbCBQcml2YXRlIE5ldHdvcmsgKFZQTikgaXMgd2lkZWx5IHVzZWQgYnkgZW50 ZXJwcmlzZXMgdG88YnI+DQombmJzcDtpbnRlcmNvbm5lY3QgdGhlaXIgZ2VvZ3JhcGhpY2FsIGRp c3BlcnNlZCBicmFuY2ggb2ZmaWNlIGxvY2F0aW9uczxicj4NCiZuYnNwO2Fjcm9zcyBJUCBXaWRl IEFyZWEgTmV0d29yayAoV0FOKS4gVG8gZnVsbHkgdXRpbGl6ZSB0aGUgYmFuZHdpZHRoPGJyPg0K Jm5ic3A7YXZhaWxhYmxlIGluIElQIFdBTiwgbG9hZCBiYWxhbmNpbmcgb2YgdHJhZmZpYyBiZXR3 ZWVuIGRpZmZlcmVudDxicj4NCiZuYnNwO0lQc2VjIFZQTiBzaXRlcyBvdmVyIEVxdWFsIENvc3Qg TXVsdGktUGF0aCAoRUNNUCkgYW5kL29yIExpbms8YnI+DQombmJzcDtBZ2dyZWdhdGlvbiBHcm91 cCAoTEFHKSB3aXRoaW4gSVAgV0FOIGlzIGF0dHJhY3RpdmUgdG8gdGhvc2U8YnI+DQombmJzcDtl bnRlcnByaXNlcyBkZXBsb3lpbmcgSVBzZWMgVlBOIHNvbHV0aW9ucy4gVGhpcyBkb2N1bWVudCBk ZWZpbmVzIGE8YnI+DQombmJzcDttZXRob2QgdG8gZW5jYXBzdWxhdGUgSVBzZWMgRW5jYXBzdWxh dGluZyBTZWN1cml0eSBQYXlsb2FkIChFU1ApPGJyPg0KJm5ic3A7cGFja2V0cyBpbnNpZGUgVURQ IHBhY2tldHMgZm9yIGltcHJvdmluZyBsb2FkLWJhbGFuY2luZyBvZiBJUHNlYzxicj4NCiZuYnNw O3R1bm5lbGVkIHRyYWZmaWMuIEluIGFkZGl0aW9uLCB0aGlzIGVuY2Fwc3VsYXRpb24gaXMgYWxz byBhcHBsaWNhYmxlPGJyPg0KJm5ic3A7dG8gc29tZSBzcGVjaWFsIG11bHRpLXRlbmFudCBkYXRh IGNlbnRlciBuZXR3b3JrIGVudmlyb25tZW50IHdoZXJlPGJyPg0KJm5ic3A7dGhlIG92ZXJsYXkg dHVubmVscyBuZWVkIHRvIGJlIHNlY3VyZWQuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbjxicj4NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPGJyPg0KPGJyPg0KVGhlIElFVEYg U2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJSVSI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpJUHNlYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 SVBzZWNAaWV0Zi5vcmciPklQc2VjQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaXBzZWM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iUlUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB28217NKGEML515MBXchi_-- From nobody Wed Nov 2 23:29:53 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62BE129407 for ; Wed, 2 Nov 2016 23:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 MxAQCrDUkyzB for ; Wed, 2 Nov 2016 23:29:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21EC51293E8 for ; Wed, 2 Nov 2016 23:29:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUK65791; Thu, 03 Nov 2016 06:29:46 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 06:27:49 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 14:27:43 +0800 From: Xuxiaohu To: Yoav Nir Thread-Topic: [IPsec] New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt Thread-Index: AQHSM2gb01BpbARQ5EG6ZJX9p7ME46DDW/lw///ayQCAA5cDAA== Date: Thu, 3 Nov 2016 06:27:42 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB2822D@NKGEML515-MBX.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB272FF@NKGEML515-MBX.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB2822DNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.581AD95A.007B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f5a56d0a497d419baf9b3b3967f15b8d Archived-At: Cc: "ipsec@ietf.org" Subject: [IPsec] =?utf-8?b?562U5aSNOiAgTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u?= =?utf-8?q?_for_draft-xu-ipsecme-esp-in-udp-lb-00=2Etxt?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 06:29:53 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB2822DNKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWW9hdiwNCg0KVGhlIGxvYWQtYmFsYW5jaW5nIG1lY2hhbmlzbSBhcyBkZXNjcmliZWQgaW4g dGhpcyBkcmFmdCB3b3VsZCBlbnN1cmUgYSBnaXZlbiB0cmFmZmljIGZsb3cgdG8gYmUgZm9yd2Fy ZGVkIG92ZXIgYSBjZXJ0YWluIHBhdGguIEluIG90aGVyIHdvcmRzLCB0aGVyZSBpcyBubyBkaXNv cmRlcmluZyBpc3N1ZS4gVGhlIGRlc3RpbmF0aW9uIHBvcnQgaXMgYXNzaWduZWQgYnkgSUFOQSB3 aGlsZSB0aGUgc291cmNlIHBvcnQgaXMgZHluYW1pY2FsbHkgY2FsY3VsYXRlZCBieSB0aGUgaW5n cmVzcyBvZiB0aGUgSVBzZWMvVURQIHR1bm5lbC4gRnVydGhlcm1vcmUsIGEgZ2l2ZW4gdHJhZmZp YyBmbG93IHdvdWxkIGJlIGZvcndhcmRlZCBvdmVyIGEgY2VydGFpbiBwYXRoIGFuZCB0aGVyZWZv cmUgdGhpcyBpcyBubyBkaXNvcmRlcmluZyBpc3N1ZS4gQXMgZm9yIHdoeSBkbyB3ZSBuZWVkIGEg bmV3IHBvcnQsIEkgaGFkIGF0dGVtcHRlZCB0byByZXBseSBpbiBhbm90aGVyIGVtYWlsLg0KDQpC ZXN0IHJlZ2FyZHMsDQpYSWFvaHUNCg0K5Y+R5Lu25Lq6OiBZb2F2IE5pciBbbWFpbHRvOnluaXIu aWV0ZkBnbWFpbC5jb21dDQrlj5HpgIHml7bpl7Q6IDIwMTblubQxMeaciDHml6UgMTU6MzENCuaU tuS7tuS6ujogWHV4aWFvaHUNCuaKhOmAgTogaXBzZWNAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtJ UHNlY10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC14dS1pcHNlY21lLWVzcC1p bi11ZHAtbGItMDAudHh0DQoNCkhpLCBYaWFvaHUNCg0KQSBmZXcgY29tbWVudHMuIEFjdHVhbGx5 LCB0aGV54oCZcmUgbW9yZSBsaWtlIHF1ZXN0aW9ucy4NCg0KDQogIDEuICBIb3cgYXJlIElQc2Vj IFNBcyBtYXBwZWQgdG8gVURQIHBzZXVkby1jb25uZWN0aW9ucz8gIElzIGl0IGEgMToxIG1hcHBp bmcgYmV0d2VlbiBTUEkgYW5kIHNvdXJjZSBwb3J0Pw0KICAyLiAgSWYgbm93LCBob3cgZG8geW91 IGRlYWwgd2l0aCB0aGUgcGFja2V0IHJlb3JkZXJpbmcgdGhhdCB0aGUgbG9hZCBiYWxhbmNlciB3 aWxsIGRvPyBJUHNlYyByZXF1aXJlcyBvcmRlcmVkIG9yIG5lYXJseS1vcmRlcmVkIGRlbGl2ZXJ5 Lg0KICAzLiAgSG93IGlzIHRoaXMgbmVnb3RpYXRlZD8gIEluIElLRT8gUHJpb3IgYWdyZWVtZW50 Pw0KICA0LiAgV2h5IGRvIHdlIG5lZWQgYSBuZXcgcG9ydD8gIFdoYXQgZ29lcyB3cm9uZyBpZiB0 aGUgcGFja2V0cyBnbyB0byBwb3J0IDQ1MDA/DQoNClRoYW5rcw0KDQpZb2F2DQpPbiAxIE5vdiAy MDE2LCBhdCAzOjQ1LCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbTxtYWlsdG86eHV4aWFv aHVAaHVhd2VpLmNvbT4+IHdyb3RlOg0KDQpIaSBhbGwsDQoNCkFueSBjb21tZW50cyBhbmQgc3Vn Z2VzdGlvbnMgYXJlIHdlbGNvbWUuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQoNCi0tLS0t 6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXQ0K5Y+R6YCB5pe26Ze0OiAyMDE25bm0MTDmnIgzMeaXpSAxOToxNQ0K5pS25Lu25Lq6 OiBYdXhpYW9odTsgemhhbmdkYWNoZW5nOyBYaWFsaWFuZyAoRnJhbmspDQrkuLvpopg6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteHUtaXBzZWNtZS1lc3AtaW4tdWRwLWxiLTAw LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC14dS1pcHNlY21lLWVzcC1pbi11 ZHAtbGItMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IExpYW5nIFhp YSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgZHJhZnQt eHUtaXBzZWNtZS1lc3AtaW4tdWRwLWxiDQpSZXZpc2lvbjogIDAwDQpUaXRsZTogICAgIEVuY2Fw c3VsYXRpbmcgSVBzZWMgRVNQIGluIFVEUCBmb3IgTG9hZC1iYWxhbmNpbmcNCkRvY3VtZW50IGRh dGU6ICAgIDIwMTYtMTAtMzENCkdyb3VwOiAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdl czogICAgIDcNClVSTDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC14dS1pcHNlY21lLWVzcC1pbi11ZHAtbGItMDAudHh0DQpTdGF0dXM6DQpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC14dS1pcHNlY21lLWVzcC1pbi11ZHAtbGIvDQpIdG1s aXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LWlwc2VjbWUt ZXNwLWluLXVkcC1sYi0wMA0KDQoNCkFic3RyYWN0Og0KIElQc2VjIFZpcnR1YWwgUHJpdmF0ZSBO ZXR3b3JrIChWUE4pIGlzIHdpZGVseSB1c2VkIGJ5IGVudGVycHJpc2VzIHRvDQogaW50ZXJjb25u ZWN0IHRoZWlyIGdlb2dyYXBoaWNhbCBkaXNwZXJzZWQgYnJhbmNoIG9mZmljZSBsb2NhdGlvbnMN CiBhY3Jvc3MgSVAgV2lkZSBBcmVhIE5ldHdvcmsgKFdBTikuIFRvIGZ1bGx5IHV0aWxpemUgdGhl IGJhbmR3aWR0aA0KIGF2YWlsYWJsZSBpbiBJUCBXQU4sIGxvYWQgYmFsYW5jaW5nIG9mIHRyYWZm aWMgYmV0d2VlbiBkaWZmZXJlbnQNCiBJUHNlYyBWUE4gc2l0ZXMgb3ZlciBFcXVhbCBDb3N0IE11 bHRpLVBhdGggKEVDTVApIGFuZC9vciBMaW5rDQogQWdncmVnYXRpb24gR3JvdXAgKExBRykgd2l0 aGluIElQIFdBTiBpcyBhdHRyYWN0aXZlIHRvIHRob3NlDQogZW50ZXJwcmlzZXMgZGVwbG95aW5n IElQc2VjIFZQTiBzb2x1dGlvbnMuIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhDQogbWV0aG9kIHRv IGVuY2Fwc3VsYXRlIElQc2VjIEVuY2Fwc3VsYXRpbmcgU2VjdXJpdHkgUGF5bG9hZCAoRVNQKQ0K IHBhY2tldHMgaW5zaWRlIFVEUCBwYWNrZXRzIGZvciBpbXByb3ZpbmcgbG9hZC1iYWxhbmNpbmcg b2YgSVBzZWMNCiB0dW5uZWxlZCB0cmFmZmljLiBJbiBhZGRpdGlvbiwgdGhpcyBlbmNhcHN1bGF0 aW9uIGlzIGFsc28gYXBwbGljYWJsZQ0KIHRvIHNvbWUgc3BlY2lhbCBtdWx0aS10ZW5hbnQgZGF0 YSBjZW50ZXIgbmV0d29yayBlbnZpcm9ubWVudCB3aGVyZQ0KIHRoZSBvdmVybGF5IHR1bm5lbHMg bmVlZCB0byBiZSBzZWN1cmVkLg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KSVBzZWMgbWFpbGluZyBsaXN0DQpJUHNlY0BpZXRmLm9y ZzxtYWlsdG86SVBzZWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lwc2VjDQoNCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB2822DNKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 Ok1lbmxvLVJlZ3VsYXI7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNw YW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bh bi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOuaJueazqOahhuaWh+acrDsNCglmb250 LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNTAxNjk5MzUzOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczoyMDIyOTY3MzA7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2lu LWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SGkgWW9hdiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhl IGxvYWQtYmFsYW5jaW5nIG1lY2hhbmlzbSBhcyBkZXNjcmliZWQgaW4gdGhpcyBkcmFmdCB3b3Vs ZCBlbnN1cmUgYSBnaXZlbiB0cmFmZmljIGZsb3cgdG8gYmUgZm9yd2FyZGVkIG92ZXIgYSBjZXJ0 YWluIHBhdGguIEluIG90aGVyIHdvcmRzLA0KIHRoZXJlIGlzIG5vIGRpc29yZGVyaW5nIGlzc3Vl LiBUaGUgZGVzdGluYXRpb24gcG9ydCBpcyBhc3NpZ25lZCBieSBJQU5BIHdoaWxlIHRoZSBzb3Vy Y2UgcG9ydCBpcyBkeW5hbWljYWxseSBjYWxjdWxhdGVkIGJ5IHRoZSBpbmdyZXNzIG9mIHRoZSBJ UHNlYy9VRFAgdHVubmVsLiBGdXJ0aGVybW9yZSwgYSBnaXZlbiB0cmFmZmljIGZsb3cgd291bGQg YmUgZm9yd2FyZGVkIG92ZXIgYSBjZXJ0YWluIHBhdGggYW5kIHRoZXJlZm9yZSB0aGlzIGlzIG5v DQogZGlzb3JkZXJpbmcgaXNzdWUuIEFzIGZvciB3aHkgZG8gd2UgbmVlZCBhIG5ldyBwb3J0LCBJ IGhhZCBhdHRlbXB0ZWQgdG8gcmVwbHkgaW4gYW5vdGhlciBlbWFpbC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+WElhb2h1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5Hku7bkuro8c3Bh biBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+IFlvYXYgTmlyIFttYWlsdG86eW5pci5pZXRmQGdtYWlsLmNv bV0NCjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R6YCB 5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiAyMDE2PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+MTE8L3NwYW4+5pyIPHNwYW4g bGFuZz0iRU4tVVMiPjE8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPiAxNTozMTxicj4NCjwv c3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiPiBYdXhpYW9odTxicj4NCjwvc3Bhbj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1V UyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBpcHNlY0BpZXRmLm9yZzxicj4NCjwv c3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiPiBSZTogW0lQc2VjXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXh1 LWlwc2VjbWUtZXNwLWluLXVkcC1sYi0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+SGksJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5Ok1lbmxvLVJlZ3VsYXIiPlhpYW9odTwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTpNZW5sby1SZWd1bGFyIj5BIGZl dyBjb21tZW50cy4gQWN0dWFsbHksIHRoZXnigJlyZSBtb3JlIGxpa2UgcXVlc3Rpb25zLjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5Ok1lbmxvLVJlZ3Vs YXIiPkhvdyBhcmUgSVBzZWMgU0FzIG1hcHBlZCB0byBVRFAgcHNldWRvLWNvbm5lY3Rpb25zPyAm bmJzcDtJcyBpdCBhIDE6MSBtYXBwaW5nIGJldHdlZW4gU1BJIGFuZCBzb3VyY2UgcG9ydD88L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTpNZW5sby1SZWd1bGFyIj5JZiBub3cs IGhvdyBkbyB5b3UgZGVhbCB3aXRoIHRoZSBwYWNrZXQgcmVvcmRlcmluZyB0aGF0IHRoZSBsb2Fk IGJhbGFuY2VyIHdpbGwgZG8/IElQc2VjIHJlcXVpcmVzIG9yZGVyZWQgb3IgbmVhcmx5LW9yZGVy ZWQgZGVsaXZlcnkuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6TWVubG8t UmVndWxhciI+SG93IGlzIHRoaXMgbmVnb3RpYXRlZD8gJm5ic3A7SW4gSUtFPyBQcmlvciBhZ3Jl ZW1lbnQ/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6TWVubG8tUmVndWxh ciI+V2h5IGRvIHdlIG5lZWQgYSBuZXcgcG9ydD8gJm5ic3A7V2hhdCBnb2VzIHdyb25nIGlmIHRo ZSBwYWNrZXRzIGdvIHRvIHBvcnQgNDUwMD88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6OC41cHQ7Zm9udC1mYW1pbHk6TWVubG8tUmVndWxhciI+VGhhbmtzPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6TWVubG8tUmVndWxhciI+WW9h djwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pk9uIDEgTm92IDIwMTYsIGF0IDM6NDUsIFh1eGlhb2h1ICZsdDs8YSBocmVmPSJtYWlsdG86eHV4 aWFvaHVAaHVhd2VpLmNvbSI+eHV4aWFvaHVAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIGFsbCw8YnI+DQo8YnI+DQpB bnkgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLjxicj4NCjxicj4NCkJlc3Qg cmVnYXJkcyw8YnI+DQpYaWFvaHU8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS08L3NwYW4+ 6YKu5Lu25Y6f5Lu2PHNwYW4gbGFuZz0iRU4tVVMiPi0tLS0tPGJyPg0KPC9zcGFuPuWPkeS7tuS6 ujxzcGFuIGxhbmc9IkVOLVVTIj46IDxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmciPm1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+ XTxicj4NCjwvc3Bhbj7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+OiAyMDE2PC9zcGFu PuW5tDxzcGFuIGxhbmc9IkVOLVVTIj4xMDwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+MzE8 L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPiAxOToxNTxicj4NCjwvc3Bhbj7mlLbku7bkuro8 c3BhbiBsYW5nPSJFTi1VUyI+OiBYdXhpYW9odTsgemhhbmdkYWNoZW5nOyBYaWFsaWFuZyAoRnJh bmspPGJyPg0KPC9zcGFuPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQteHUtaXBzZWNtZS1lc3AtaW4tdWRwLWxiLTAwLnR4dDxicj4N Cjxicj4NCjxicj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC14dS1pcHNlY21lLWVzcC1p bi11ZHAtbGItMDAudHh0PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBM aWFuZyBYaWEgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Ljxicj4NCjxicj4NCk5h bWU6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgPC9zcGFuPmRyYWZ0LXh1LWlwc2VjbWUtZXNwLWluLXVkcC1sYjxicj4NClJldmlzaW9u OjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7IDwvc3Bhbj4wMDxicj4NClRpdGxl OjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwv c3Bhbj5FbmNhcHN1bGF0aW5nIElQc2VjIEVTUCBpbiBVRFAgZm9yIExvYWQtYmFsYW5jaW5nPGJy Pg0KRG9jdW1lbnQgZGF0ZTo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNw OyZuYnNwOyA8L3NwYW4+MjAxNi0xMC0zMTxicj4NCkdyb3VwOjxzcGFuIGNsYXNzPSJhcHBsZS10 YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5JbmRpdmlkdWFsIFN1Ym1p c3Npb248YnI+DQpQYWdlczo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyA8L3NwYW4+Nzxicj4NClVSTDo8YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteHUtaXBzZWNtZS1lc3AtaW4tdWRwLWxi LTAwLnR4dCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXh1LWlw c2VjbWUtZXNwLWluLXVkcC1sYi0wMC50eHQ8L2E+PGJyPg0KU3RhdHVzOjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXh1LWlwc2VjbWUtZXNwLWlu LXVkcC1sYi8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXh1LWlwc2Vj bWUtZXNwLWluLXVkcC1sYi88L2E+PGJyPg0KSHRtbGl6ZWQ6ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC14dS1pcHNlY21lLWVzcC1pbi11ZHAtbGItMDAiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC14dS1pcHNlY21lLWVzcC1pbi11ZHAtbGItMDA8L2E+PGJyPg0KPGJyPg0KPGJyPg0K QWJzdHJhY3Q6PGJyPg0KJm5ic3A7SVBzZWMgVmlydHVhbCBQcml2YXRlIE5ldHdvcmsgKFZQTikg aXMgd2lkZWx5IHVzZWQgYnkgZW50ZXJwcmlzZXMgdG88YnI+DQombmJzcDtpbnRlcmNvbm5lY3Qg dGhlaXIgZ2VvZ3JhcGhpY2FsIGRpc3BlcnNlZCBicmFuY2ggb2ZmaWNlIGxvY2F0aW9uczxicj4N CiZuYnNwO2Fjcm9zcyBJUCBXaWRlIEFyZWEgTmV0d29yayAoV0FOKS4gVG8gZnVsbHkgdXRpbGl6 ZSB0aGUgYmFuZHdpZHRoPGJyPg0KJm5ic3A7YXZhaWxhYmxlIGluIElQIFdBTiwgbG9hZCBiYWxh bmNpbmcgb2YgdHJhZmZpYyBiZXR3ZWVuIGRpZmZlcmVudDxicj4NCiZuYnNwO0lQc2VjIFZQTiBz aXRlcyBvdmVyIEVxdWFsIENvc3QgTXVsdGktUGF0aCAoRUNNUCkgYW5kL29yIExpbms8YnI+DQom bmJzcDtBZ2dyZWdhdGlvbiBHcm91cCAoTEFHKSB3aXRoaW4gSVAgV0FOIGlzIGF0dHJhY3RpdmUg dG8gdGhvc2U8YnI+DQombmJzcDtlbnRlcnByaXNlcyBkZXBsb3lpbmcgSVBzZWMgVlBOIHNvbHV0 aW9ucy4gVGhpcyBkb2N1bWVudCBkZWZpbmVzIGE8YnI+DQombmJzcDttZXRob2QgdG8gZW5jYXBz dWxhdGUgSVBzZWMgRW5jYXBzdWxhdGluZyBTZWN1cml0eSBQYXlsb2FkIChFU1ApPGJyPg0KJm5i c3A7cGFja2V0cyBpbnNpZGUgVURQIHBhY2tldHMgZm9yIGltcHJvdmluZyBsb2FkLWJhbGFuY2lu ZyBvZiBJUHNlYzxicj4NCiZuYnNwO3R1bm5lbGVkIHRyYWZmaWMuIEluIGFkZGl0aW9uLCB0aGlz IGVuY2Fwc3VsYXRpb24gaXMgYWxzbyBhcHBsaWNhYmxlPGJyPg0KJm5ic3A7dG8gc29tZSBzcGVj aWFsIG11bHRpLXRlbmFudCBkYXRhIGNlbnRlciBuZXR3b3JrIGVudmlyb25tZW50IHdoZXJlPGJy Pg0KJm5ic3A7dGhlIG92ZXJsYXkgdHVubmVscyBuZWVkIHRvIGJlIHNlY3VyZWQuPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxicj4NCnVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu PGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJUHNlYyBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SVBzZWNAaWV0Zi5vcmciPklQc2VjQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBz ZWMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWM8L2E+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB2822DNKGEML515MBXchi_-- From nobody Thu Nov 3 00:02:54 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4270B129516 for ; Thu, 3 Nov 2016 00:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 6YjPPr4PmkTB for ; Thu, 3 Nov 2016 00:02:51 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48237129496 for ; Wed, 2 Nov 2016 23:57:09 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id t79so80430741wmt.0 for ; Wed, 02 Nov 2016 23:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ZlBqd+YFXXo+xijzoxhf+pszSBp34mEZfUqlKpBRlXY=; b=lzALecKoJpY6Ks8TJM1MdKxvWBvcO4oAR5oOVEb2KveZXiG+yEhoS3W9x2SntsVGHD twI7OU6I14WlhEyXUWH6AdF4eFeBTcCG2sAZiinMz8h1nZL8E1IUom9tfLa/kUO1aB4Y V3mSzyNJpNkB1NjNfuWS0V7kg3T2fthbEKlRQZi7U4u1INj6eGD4o3h8tDA1fTqCHgU6 3LgHxPeRT8jDBbR52hXn9ts6Bf27oEMxdv5yIu8EAhhwKhy+dYzdAnqcoRu45k7zXmgM 4mYV1vMrN4Qj3ICoFLVGmcWtL3cRT3fBdLr+jGSm06ZmCKTJx+zfilLrAjLIw9+h2UYF Mqqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ZlBqd+YFXXo+xijzoxhf+pszSBp34mEZfUqlKpBRlXY=; b=PqCVxU07gWAu162tW1jOumUOqCT1LXWSgEB8rGvALNg+QVv3ueJA2dzrQlpzX1T6kX j0xOWhGO/zSVRetILovlULXHhmj/yo08aKvBVCi5bXg4vxBhedZpv7PIxO/phhaDDwB1 vii97jgE1UBMDENh5krwhAX9lyih2XQxIgedrOS461u8+NScT+8MT1lGc+y9r62qhuHZ NiagWvtglCUx5+xGjgtfpjMY3GizKXyog8NpkKxpoqaVoBM6ftTRAx0x5Hr0ZkvunpKI U4awgVzg+VVBVBu71x61ZyvglUKYtLPlt9s+wpcLujYbORmKfwfegG0NreS+E7BoY6ax 60rg== X-Gm-Message-State: ABUngvf59WE8M8Yg0jGc0U8o6vHAZqBoxkA5eQSfkGa15waKozUWxgo2U9J/x/46Sbs90Q== X-Received: by 10.194.188.83 with SMTP id fy19mr5817489wjc.227.1478156227816; Wed, 02 Nov 2016 23:57:07 -0700 (PDT) Received: from [192.168.137.54] ([109.253.197.194]) by smtp.gmail.com with ESMTPSA id s133sm40388048wmd.19.2016.11.02.23.57.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Nov 2016 23:57:06 -0700 (PDT) From: Yoav Nir Message-Id: <418DD440-B823-4AD2-8767-CB213DE8B538@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_095E6428-4FB7-42A4-904F-3149844DEC52" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Thu, 3 Nov 2016 08:57:01 +0200 In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB2822D@NKGEML515-MBX.china.huawei.com> To: Xuxiaohu References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB272FF@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB2822D@NKGEML515-MBX.china.huawei.com> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 07:02:52 -0000 --Apple-Mail=_095E6428-4FB7-42A4-904F-3149844DEC52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The draft has no text about mapping SA to source port. So if I=E2=80=99m = understanding you correctly, the tunnel ingress calculates the port (is = there actual calculation, or just picking?), so if it sends all packets = for a particular SA with the same UDP source port, they will all = traverse the same path and therefore will likely not get re-ordered, or = at least will not get any more re-ordered than IPsec packets on the = regular Internet. Did I understand this correctly? Yoav > On 3 Nov 2016, at 8:27, Xuxiaohu wrote: >=20 > Hi Yoav, > =20 > The load-balancing mechanism as described in this draft would ensure a = given traffic flow to be forwarded over a certain path. In other words, = there is no disordering issue. The destination port is assigned by IANA = while the source port is dynamically calculated by the ingress of the = IPsec/UDP tunnel. Furthermore, a given traffic flow would be forwarded = over a certain path and therefore this is no disordering issue. As for = why do we need a new port, I had attempted to reply in another email. > =20 > Best regards, > XIaohu > =20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: Yoav Nir [mailto:ynir.ietf@gmail.com]=20 > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B411=E6=9C=881=E6=97=A5= 15:31 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu > =E6=8A=84=E9=80=81: ipsec@ietf.org > =E4=B8=BB=E9=A2=98: Re: [IPsec] New Version Notification for = draft-xu-ipsecme-esp-in-udp-lb-00.txt > =20 > Hi, Xiaohu > =20 > A few comments. Actually, they=E2=80=99re more like questions. > =20 > How are IPsec SAs mapped to UDP pseudo-connections? Is it a 1:1 = mapping between SPI and source port? > If now, how do you deal with the packet reordering that the load = balancer will do? IPsec requires ordered or nearly-ordered delivery. > How is this negotiated? In IKE? Prior agreement? > Why do we need a new port? What goes wrong if the packets go to port = 4500? > =20 > Thanks > =20 > Yoav > On 1 Nov 2016, at 3:45, Xuxiaohu > wrote: > =20 > Hi all, >=20 > Any comments and suggestions are welcome. >=20 > Best regards, > Xiaohu >=20 >=20 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org = ] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B410=E6=9C=8831=E6=97=A5= 19:15 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; zhangdacheng; Xialiang (Frank) > =E4=B8=BB=E9=A2=98: New Version Notification for = draft-xu-ipsecme-esp-in-udp-lb-00.txt >=20 >=20 > A new version of I-D, draft-xu-ipsecme-esp-in-udp-lb-00.txt > has been successfully submitted by Liang Xia and posted to the IETF = repository. >=20 > Name: draft-xu-ipsecme-esp-in-udp-lb > Revision: 00 > Title: Encapsulating IPsec ESP in UDP for Load-balancing > Document date: 2016-10-31 > Group: Individual Submission > Pages: 7 > URL: > = https://www.ietf.org/internet-drafts/draft-xu-ipsecme-esp-in-udp-lb-00.txt= = > Status: > https://datatracker.ietf.org/doc/draft-xu-ipsecme-esp-in-udp-lb/ = > Htmlized: = https://tools.ietf.org/html/draft-xu-ipsecme-esp-in-udp-lb-00 = >=20 >=20 > Abstract: > IPsec Virtual Private Network (VPN) is widely used by enterprises to > interconnect their geographical dispersed branch office locations > across IP Wide Area Network (WAN). To fully utilize the bandwidth > available in IP WAN, load balancing of traffic between different > IPsec VPN sites over Equal Cost Multi-Path (ECMP) and/or Link > Aggregation Group (LAG) within IP WAN is attractive to those > enterprises deploying IPsec VPN solutions. This document defines a > method to encapsulate IPsec Encapsulating Security Payload (ESP) > packets inside UDP packets for improving load-balancing of IPsec > tunneled traffic. In addition, this encapsulation is also applicable > to some special multi-tenant data center network environment where > the overlay tunnels need to be secured. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = --Apple-Mail=_095E6428-4FB7-42A4-904F-3149844DEC52 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The draft has no text about mapping SA to source port. So if = I=E2=80=99m understanding you correctly, the tunnel ingress calculates = the port (is there actual calculation, or just picking?), so if it sends = all packets for a particular SA with the same UDP source port, they will = all traverse the same path and therefore will likely not get re-ordered, = or at least will not get any more re-ordered than IPsec packets on the = regular Internet.

Did = I understand this correctly?

Yoav

On = 3 Nov 2016, at 8:27, Xuxiaohu <xuxiaohu@huawei.com> wrote:

Hi Yoav,
 
The = load-balancing mechanism as described in this draft would ensure a given = traffic flow to be forwarded over a certain path. In other words, there = is no disordering issue. The destination port is assigned by IANA while = the source port is dynamically calculated by the ingress of the = IPsec/UDP tunnel. Furthermore, a given traffic flow would be forwarded = over a certain path and therefore this is no disordering issue. As for = why do we need a new port, I had attempted to reply in another = email.
 
Best = regards,
XIaohu
 
=E5=8F=91=E4=BB=B6=E4=BA=BA: Yoav = Nir [mailto:ynir.ietf@gmail.com] 
=E5=8F=91=E9=80=81=E6= =97=B6=E9=97=B4: 2016=E5=B9=B411=E6=9C=881=E6=97=A5 15:31
=E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu
=E6=8A=84=E9=80=81: ipsec@ietf.org
=E4=B8=BB=E9=A2=98: Re: [IPsec] New Version = Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt
 
Hi, Xiaohu
 
A few comments. Actually, = they=E2=80=99re more like questions.
 
  1. How are IPsec SAs mapped = to UDP pseudo-connections?  Is it a 1:1 mapping between SPI and = source port?
  2. If now, how do you deal with the packet reordering that the = load balancer will do? IPsec requires ordered or nearly-ordered = delivery.
  3. How is this negotiated?  In IKE? Prior = agreement?
  4. Why do we need a new port?  What goes wrong if the = packets go to port 4500?
 
Thanks
 
Yoav
On 1 Nov 2016, at 3:45, Xuxiaohu <xuxiaohu@huawei.com> = wrote:
 
Hi = all,

Any comments and suggestions are = welcome.

Best regards,
Xiaohu


-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6= -----
=E5=8F=91=E4=BB= =B6=E4=BA=BA: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B410=E6=9C=8831=E6=97=A5 19:15
=E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; zhangdacheng; Xialiang (Frank)
=E4=B8=BB=E9=A2=98: = New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt


A new version of I-D, = draft-xu-ipsecme-esp-in-udp-lb-00.txt
has been = successfully submitted by Liang Xia and posted to the IETF = repository.

Name:      draft-xu-ipsecme-esp-i= n-udp-lb
Revision:  00
Title:     Encapsulating IPsec = ESP in UDP for Load-balancing
Document date:    2016-10-31
Group:     Individual = Submission
Pages:     7
URL:
https://www.ietf.org/internet-drafts/draft-xu-ipsecme-esp-in-ud= p-lb-00.txt
Status:
https://datatracker.ietf.org/doc/draft-xu-ipsecme-esp-in-udp-lb= /
Htmlized:       https://tools.ietf.org/html/draft-xu-ipsecme-esp-in-udp-lb-00


Abstract:
 IPsec Virtual Private Network (VPN) is widely used by = enterprises to
 interconnect their geographical = dispersed branch office locations
 across IP Wide = Area Network (WAN). To fully utilize the bandwidth
 available in IP WAN, load balancing of traffic between = different
 IPsec VPN sites over Equal Cost Multi-Path = (ECMP) and/or Link
 Aggregation Group (LAG) within IP = WAN is attractive to those
 enterprises deploying = IPsec VPN solutions. This document defines a
 method = to encapsulate IPsec Encapsulating Security Payload (ESP)
 packets inside UDP packets for improving load-balancing = of IPsec
 tunneled traffic. In addition, this = encapsulation is also applicable
 to some special = multi-tenant data center network environment where
 the= overlay tunnels need to be secured.




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.

The IETF Secretariat

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
= --Apple-Mail=_095E6428-4FB7-42A4-904F-3149844DEC52-- From nobody Thu Nov 3 00:07:41 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D25129516 for ; Thu, 3 Nov 2016 00:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 M0ALXaA0w9v1 for ; Thu, 3 Nov 2016 00:07:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DEC6129467 for ; Thu, 3 Nov 2016 00:07:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZP13696; Thu, 03 Nov 2016 07:07:35 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Nov 2016 07:07:34 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Thu, 3 Nov 2016 15:07:07 +0800 From: Xuxiaohu To: Yoav Nir Thread-Topic: [IPsec] New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt Thread-Index: AQHSM2gb01BpbARQ5EG6ZJX9p7ME46DDW/lw///ayQCAA5cDAP//hEKAgACHwBA= Date: Thu, 3 Nov 2016 07:07:07 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB28271@NKGEML515-MBX.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB272FF@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB2822D@NKGEML515-MBX.china.huawei.com> <418DD440-B823-4AD2-8767-CB213DE8B538@gmail.com> In-Reply-To: <418DD440-B823-4AD2-8767-CB213DE8B538@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB28271NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.581AE237.013E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c4a6b5dd76c3ff94bb2f6e597920df23 Archived-At: Cc: "ipsec@ietf.org" Subject: [IPsec] =?utf-8?b?562U5aSNOiAgTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u?= =?utf-8?q?_for_draft-xu-ipsecme-esp-in-udp-lb-00=2Etxt?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 07:07:40 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB28271NKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWW9hdiwNCg0KDQpZb3VyIHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdC4gQlRXLCBpdCBzYWlk IGluIHRoZSBkcmFmdCB0aGF0IOKAnFNvdXJjZSBQb3J0IG9mIFVEUDogVGhpcyBmaWVsZCBjb250 YWlucyBhIDE2LWJpdCBlbnRyb3B5IHZhbHVlIHRoYXQgaXMNCiAgICAgICAgICAgICAgIGdlbmVy YXRlZCBieSB0aGUgZW5jYXBzdWxhdG9yIHRvIHVuaXF1ZWx5IGlkZW50aWZ5IGENCiAgICAgICAg ICAgICAgIGZsb3cuICBXaGF0IGNvbnN0aXR1dGVzIGEgZmxvdyBpcyBsb2NhbGx5IGRldGVybWlu ZWQgYnkNCiAgICAgICAgICAgICAgIHRoZSBlbmNhcHN1bGF0b3IgYW5kIHRoZXJlZm9yZSBpcyBv dXRzaWRlIHRoZSBzY29wZSBvZg0KICAgICAgICAgICAgICAgdGhpcyBkb2N1bWVudC7igJ0NCkZv ciBleGFtcGxlLCB0aGUgZW5jYXBzdWxhdG9yIGNvdWxkIGNhbGN1bGF0ZSBhIGhhc2ggb2YgdGhl IGZpdmUgdHVwbGUgb2YgdGhlIHBheWxvYWQgb2YgdGhlIEVTUCBpZiB0aGUgRVNQIHBheWxvYWQg aXMgYW4gSVAgcGFja2V0Lg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KDQrlj5Hku7bkuro6 IFlvYXYgTmlyIFttYWlsdG86eW5pci5pZXRmQGdtYWlsLmNvbV0NCuWPkemAgeaXtumXtDogMjAx NuW5tDEx5pyIM+aXpSAxNDo1Nw0K5pS25Lu25Lq6OiBYdXhpYW9odQ0K5oqE6YCBOiBpcHNlY0Bp ZXRmLm9yZw0K5Li76aKYOiBSZTogW0lQc2VjXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LXh1LWlwc2VjbWUtZXNwLWluLXVkcC1sYi0wMC50eHQNCg0KVGhlIGRyYWZ0IGhhcyBu byB0ZXh0IGFib3V0IG1hcHBpbmcgU0EgdG8gc291cmNlIHBvcnQuIFNvIGlmIEnigJltIHVuZGVy c3RhbmRpbmcgeW91IGNvcnJlY3RseSwgdGhlIHR1bm5lbCBpbmdyZXNzIGNhbGN1bGF0ZXMgdGhl IHBvcnQgKGlzIHRoZXJlIGFjdHVhbCBjYWxjdWxhdGlvbiwgb3IganVzdCBwaWNraW5nPyksIHNv IGlmIGl0IHNlbmRzIGFsbCBwYWNrZXRzIGZvciBhIHBhcnRpY3VsYXIgU0Egd2l0aCB0aGUgc2Ft ZSBVRFAgc291cmNlIHBvcnQsIHRoZXkgd2lsbCBhbGwgdHJhdmVyc2UgdGhlIHNhbWUgcGF0aCBh bmQgdGhlcmVmb3JlIHdpbGwgbGlrZWx5IG5vdCBnZXQgcmUtb3JkZXJlZCwgb3IgYXQgbGVhc3Qg d2lsbCBub3QgZ2V0IGFueSBtb3JlIHJlLW9yZGVyZWQgdGhhbiBJUHNlYyBwYWNrZXRzIG9uIHRo ZSByZWd1bGFyIEludGVybmV0Lg0KDQpEaWQgSSB1bmRlcnN0YW5kIHRoaXMgY29ycmVjdGx5Pw0K DQpZb2F2DQoNCk9uIDMgTm92IDIwMTYsIGF0IDg6MjcsIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3 ZWkuY29tPG1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tPj4gd3JvdGU6DQoNCkhpIFlvYXYsDQoN ClRoZSBsb2FkLWJhbGFuY2luZyBtZWNoYW5pc20gYXMgZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQg d291bGQgZW5zdXJlIGEgZ2l2ZW4gdHJhZmZpYyBmbG93IHRvIGJlIGZvcndhcmRlZCBvdmVyIGEg Y2VydGFpbiBwYXRoLiBJbiBvdGhlciB3b3JkcywgdGhlcmUgaXMgbm8gZGlzb3JkZXJpbmcgaXNz dWUuIFRoZSBkZXN0aW5hdGlvbiBwb3J0IGlzIGFzc2lnbmVkIGJ5IElBTkEgd2hpbGUgdGhlIHNv dXJjZSBwb3J0IGlzIGR5bmFtaWNhbGx5IGNhbGN1bGF0ZWQgYnkgdGhlIGluZ3Jlc3Mgb2YgdGhl IElQc2VjL1VEUCB0dW5uZWwuIEZ1cnRoZXJtb3JlLCBhIGdpdmVuIHRyYWZmaWMgZmxvdyB3b3Vs ZCBiZSBmb3J3YXJkZWQgb3ZlciBhIGNlcnRhaW4gcGF0aCBhbmQgdGhlcmVmb3JlIHRoaXMgaXMg bm8gZGlzb3JkZXJpbmcgaXNzdWUuIEFzIGZvciB3aHkgZG8gd2UgbmVlZCBhIG5ldyBwb3J0LCBJ IGhhZCBhdHRlbXB0ZWQgdG8gcmVwbHkgaW4gYW5vdGhlciBlbWFpbC4NCg0KQmVzdCByZWdhcmRz LA0KWElhb2h1DQoNCuWPkeS7tuS6ujogWW9hdiBOaXIgW21haWx0bzp5bmlyLmlldGZAZ21haWwu Y29tXQ0K5Y+R6YCB5pe26Ze0OiAyMDE25bm0MTHmnIgx5pelIDE1OjMxDQrmlLbku7bkuro6IFh1 eGlhb2h1DQrmioTpgIE6IGlwc2VjQGlldGYub3JnPG1haWx0bzppcHNlY0BpZXRmLm9yZz4NCuS4 u+mimDogUmU6IFtJUHNlY10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC14dS1p cHNlY21lLWVzcC1pbi11ZHAtbGItMDAudHh0DQoNCkhpLCBYaWFvaHUNCg0KQSBmZXcgY29tbWVu dHMuIEFjdHVhbGx5LCB0aGV54oCZcmUgbW9yZSBsaWtlIHF1ZXN0aW9ucy4NCg0KDQogIDEuICBI b3cgYXJlIElQc2VjIFNBcyBtYXBwZWQgdG8gVURQIHBzZXVkby1jb25uZWN0aW9ucz8gIElzIGl0 IGEgMToxIG1hcHBpbmcgYmV0d2VlbiBTUEkgYW5kIHNvdXJjZSBwb3J0Pw0KICAyLiAgSWYgbm93 LCBob3cgZG8geW91IGRlYWwgd2l0aCB0aGUgcGFja2V0IHJlb3JkZXJpbmcgdGhhdCB0aGUgbG9h ZCBiYWxhbmNlciB3aWxsIGRvPyBJUHNlYyByZXF1aXJlcyBvcmRlcmVkIG9yIG5lYXJseS1vcmRl cmVkIGRlbGl2ZXJ5Lg0KICAzLiAgSG93IGlzIHRoaXMgbmVnb3RpYXRlZD8gIEluIElLRT8gUHJp b3IgYWdyZWVtZW50Pw0KICA0LiAgV2h5IGRvIHdlIG5lZWQgYSBuZXcgcG9ydD8gIFdoYXQgZ29l cyB3cm9uZyBpZiB0aGUgcGFja2V0cyBnbyB0byBwb3J0IDQ1MDA/DQoNClRoYW5rcw0KDQpZb2F2 DQpPbiAxIE5vdiAyMDE2LCBhdCAzOjQ1LCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbTxt YWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbT4+IHdyb3RlOg0KDQpIaSBhbGwsDQoNCkFueSBjb21t ZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9o dQ0KDQoNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddDQrlj5HpgIHml7bpl7Q6IDIwMTblubQxMOaciDMx5pelIDE5 OjE1DQrmlLbku7bkuro6IFh1eGlhb2h1OyB6aGFuZ2RhY2hlbmc7IFhpYWxpYW5nIChGcmFuaykN CuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC14dS1pcHNlY21lLWVz cC1pbi11ZHAtbGItMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXh1LWlw c2VjbWUtZXNwLWluLXVkcC1sYi0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgTGlhbmcgWGlhIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFt ZTogICAgICBkcmFmdC14dS1pcHNlY21lLWVzcC1pbi11ZHAtbGINClJldmlzaW9uOiAgMDANClRp dGxlOiAgICAgRW5jYXBzdWxhdGluZyBJUHNlYyBFU1AgaW4gVURQIGZvciBMb2FkLWJhbGFuY2lu Zw0KRG9jdW1lbnQgZGF0ZTogICAgMjAxNi0xMC0zMQ0KR3JvdXA6ICAgICBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NClBhZ2VzOiAgICAgNw0KVVJMOg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LXh1LWlwc2VjbWUtZXNwLWluLXVkcC1sYi0wMC50eHQNClN0YXR1czoN Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXh1LWlwc2VjbWUtZXNwLWlu LXVkcC1sYi8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQteHUtaXBzZWNtZS1lc3AtaW4tdWRwLWxiLTAwDQoNCg0KQWJzdHJhY3Q6DQogSVBzZWMgVmly dHVhbCBQcml2YXRlIE5ldHdvcmsgKFZQTikgaXMgd2lkZWx5IHVzZWQgYnkgZW50ZXJwcmlzZXMg dG8NCiBpbnRlcmNvbm5lY3QgdGhlaXIgZ2VvZ3JhcGhpY2FsIGRpc3BlcnNlZCBicmFuY2ggb2Zm aWNlIGxvY2F0aW9ucw0KIGFjcm9zcyBJUCBXaWRlIEFyZWEgTmV0d29yayAoV0FOKS4gVG8gZnVs bHkgdXRpbGl6ZSB0aGUgYmFuZHdpZHRoDQogYXZhaWxhYmxlIGluIElQIFdBTiwgbG9hZCBiYWxh bmNpbmcgb2YgdHJhZmZpYyBiZXR3ZWVuIGRpZmZlcmVudA0KIElQc2VjIFZQTiBzaXRlcyBvdmVy IEVxdWFsIENvc3QgTXVsdGktUGF0aCAoRUNNUCkgYW5kL29yIExpbmsNCiBBZ2dyZWdhdGlvbiBH cm91cCAoTEFHKSB3aXRoaW4gSVAgV0FOIGlzIGF0dHJhY3RpdmUgdG8gdGhvc2UNCiBlbnRlcnBy aXNlcyBkZXBsb3lpbmcgSVBzZWMgVlBOIHNvbHV0aW9ucy4gVGhpcyBkb2N1bWVudCBkZWZpbmVz IGENCiBtZXRob2QgdG8gZW5jYXBzdWxhdGUgSVBzZWMgRW5jYXBzdWxhdGluZyBTZWN1cml0eSBQ YXlsb2FkIChFU1ApDQogcGFja2V0cyBpbnNpZGUgVURQIHBhY2tldHMgZm9yIGltcHJvdmluZyBs b2FkLWJhbGFuY2luZyBvZiBJUHNlYw0KIHR1bm5lbGVkIHRyYWZmaWMuIEluIGFkZGl0aW9uLCB0 aGlzIGVuY2Fwc3VsYXRpb24gaXMgYWxzbyBhcHBsaWNhYmxlDQogdG8gc29tZSBzcGVjaWFsIG11 bHRpLXRlbmFudCBkYXRhIGNlbnRlciBuZXR3b3JrIGVudmlyb25tZW50IHdoZXJlDQogdGhlIG92 ZXJsYXkgdHVubmVscyBuZWVkIHRvIGJlIHNlY3VyZWQuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRo YXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1p c3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCg0KVGhlIElFVEYgU2Vj cmV0YXJpYXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCklQc2VjIG1haWxpbmcgbGlzdA0KSVBzZWNAaWV0Zi5vcmc8bWFpbHRvOklQc2VjQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYw0KDQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB28271NKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5Ok1lbmxvLVJlZ3VsYXI7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8g Q2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNw YW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRl ZC1zcGFjZTt9DQpzcGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRh Yi1zcGFuO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbm lofmnKw7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZhbWlseTrlrovkvZM7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJ bWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjQ2MzU0ODA1NDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTk1Nzk5Nzk5 Mjt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBZ b2F2LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlz Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PllvdXIgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LiBCVFcsIGl0IHNhaWQgaW4gdGhlIGRyYWZ0 IHRoYXQg4oCcPC9zcGFuPjxzcGFuIGxhbmc9IkVOIj5Tb3VyY2UgUG9ydCBvZiBVRFA6IFRoaXMg ZmllbGQgY29udGFpbnMgYSAxNi1iaXQgZW50cm9weSB2YWx1ZSB0aGF0IGlzPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGdl bmVyYXRlZCBieSB0aGUgZW5jYXBzdWxhdG9yIHRvIHVuaXF1ZWx5IGlkZW50aWZ5IGE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1i ZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGZsb3cuJm5ic3A7IFdoYXQgY29uc3RpdHV0ZXMgYSBmbG93IGlzIGxvY2FsbHkgZGV0ZXJtaW5l ZCBieTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJw YWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgdGhlIGVuY2Fwc3VsYXRvciBhbmQgdGhlcmVmb3JlIGlzIG91dHNpZGUgdGhl IHNjb3BlIG9mPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGlzIGRvY3VtZW50Ljwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIGV4 YW1wbGUsIHRoZSBlbmNhcHN1bGF0b3IgY291bGQgY2FsY3VsYXRlIGEgaGFzaCBvZiB0aGUgZml2 ZSB0dXBsZSBvZiB0aGUgcGF5bG9hZCBvZiB0aGUgRVNQIGlmIHRoZSBFU1AgcGF5bG9hZCBpcyBh biBJUCBwYWNrZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlhpYW9odTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+IFlvYXYgTmlyIFttYWls dG86eW5pci5pZXRmQGdtYWlsLmNvbV0NCjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiAyMDE2 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lubQ8c3BhbiBsYW5nPSJFTi1V UyI+MTE8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjM8L3NwYW4+5pelPHNwYW4gbGFuZz0i RU4tVVMiPiAxNDo1Nzxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+ Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBYdXhpYW9odTxicj4NCjwvc3Bhbj48Yj7m ioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBp cHNlY0BpZXRmLm9yZzxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBSZTogW0lQc2VjXSBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LXh1LWlwc2VjbWUtZXNwLWluLXVkcC1sYi0wMC50eHQ8bzpwPjwv bzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGRyYWZ0IGhhcyBubyB0ZXh0 IGFib3V0IG1hcHBpbmcgU0EgdG8gc291cmNlIHBvcnQuIFNvIGlmIEnigJltIHVuZGVyc3RhbmRp bmcgeW91IGNvcnJlY3RseSwgdGhlIHR1bm5lbCBpbmdyZXNzIGNhbGN1bGF0ZXMgdGhlIHBvcnQg KGlzIHRoZXJlIGFjdHVhbCBjYWxjdWxhdGlvbiwgb3IganVzdCBwaWNraW5nPyksIHNvIGlmIGl0 IHNlbmRzIGFsbCBwYWNrZXRzIGZvciBhIHBhcnRpY3VsYXINCiBTQSB3aXRoIHRoZSBzYW1lIFVE UCBzb3VyY2UgcG9ydCwgdGhleSB3aWxsIGFsbCB0cmF2ZXJzZSB0aGUgc2FtZSBwYXRoIGFuZCB0 aGVyZWZvcmUgd2lsbCBsaWtlbHkgbm90IGdldCByZS1vcmRlcmVkLCBvciBhdCBsZWFzdCB3aWxs IG5vdCBnZXQgYW55IG1vcmUgcmUtb3JkZXJlZCB0aGFuIElQc2VjIHBhY2tldHMgb24gdGhlIHJl Z3VsYXIgSW50ZXJuZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ RGlkIEkgdW5kZXJzdGFuZCB0aGlzIGNvcnJlY3RseT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPllvYXY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiAzIE5vdiAyMDE2LCBhdCA4OjI3LCBYdXhpYW9odSAm bHQ7PGEgaHJlZj0ibWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20iPnh1eGlhb2h1QGh1YXdlaS5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgWW9hdiw8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2 LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBs b2FkLWJhbGFuY2luZyBtZWNoYW5pc20gYXMgZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQgd291bGQg ZW5zdXJlIGEgZ2l2ZW4gdHJhZmZpYyBmbG93IHRvIGJlIGZvcndhcmRlZCBvdmVyIGEgY2VydGFp biBwYXRoLiBJbiBvdGhlciB3b3JkcywNCiB0aGVyZSBpcyBubyBkaXNvcmRlcmluZyBpc3N1ZS4g VGhlIGRlc3RpbmF0aW9uIHBvcnQgaXMgYXNzaWduZWQgYnkgSUFOQSB3aGlsZSB0aGUgc291cmNl IHBvcnQgaXMgZHluYW1pY2FsbHkgY2FsY3VsYXRlZCBieSB0aGUgaW5ncmVzcyBvZiB0aGUgSVBz ZWMvVURQIHR1bm5lbC4gRnVydGhlcm1vcmUsIGEgZ2l2ZW4gdHJhZmZpYyBmbG93IHdvdWxkIGJl IGZvcndhcmRlZCBvdmVyIGEgY2VydGFpbiBwYXRoIGFuZCB0aGVyZWZvcmUgdGhpcyBpcyBubw0K IGRpc29yZGVyaW5nIGlzc3VlLiBBcyBmb3Igd2h5IGRvIHdlIG5lZWQgYSBuZXcgcG9ydCwgSSBo YWQgYXR0ZW1wdGVkIHRvIHJlcGx5IGluIGFub3RoZXIgZW1haWwuPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMs PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlhJYW9odTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwv c3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+WW9hdiBOaXIgWzxhIGhyZWY9 Im1haWx0bzp5bmlyLmlldGZAZ21haWwuY29tIj5tYWlsdG86eW5pci5pZXRmQGdtYWlsLmNvbTwv YT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4N Cjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R6YCB5pe26Ze0PHNw YW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij4yMDE2PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lubQ8c3Bh biBsYW5nPSJFTi1VUyI+MTE8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjE8L3NwYW4+5pel PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjE1OjMxPGJyPg0KPC9zcGFuPjxi PuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+WHV4aWFvaHU8YnI+DQo8L3NwYW4+PGI+5oqE6YCBPHNwYW4g bGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48YSBocmVmPSJtYWlsdG86aXBzZWNAaWV0Zi5vcmciPmlwc2VjQGlldGYub3JnPC9hPjxi cj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwv c3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPlJlOiBbSVBzZWNdIE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQteHUtaXBzZWNtZS1lc3AtaW4tdWRwLWxiLTAwLnR4dDwvc3Bh bj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpLCZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTpNZW5sby1S ZWd1bGFyIj5YaWFvaHU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6TWVubG8tUmVndWxhciI+QSBmZXcgY29t bWVudHMuIEFjdHVhbGx5LCB0aGV54oCZcmUgbW9yZSBsaWtlIHF1ZXN0aW9ucy48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxvbCBzdHls ZT0ibWFyZ2luLXRvcDowY20iIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5Ok1lbmxvLVJlZ3VsYXIiPkhvdyBhcmUg SVBzZWMgU0FzIG1hcHBlZCB0byBVRFAgcHNldWRvLWNvbm5lY3Rpb25zPyAmbmJzcDtJcyBpdCBh IDE6MSBtYXBwaW5nIGJldHdlZW4gU1BJIGFuZCBzb3VyY2UgcG9ydD88L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6TWVubG8tUmVndWxhciI+SWYgbm93LCBob3cgZG8g eW91IGRlYWwgd2l0aCB0aGUgcGFja2V0IHJlb3JkZXJpbmcgdGhhdCB0aGUgbG9hZCBiYWxhbmNl ciB3aWxsIGRvPyBJUHNlYyByZXF1aXJlcyBvcmRlcmVkIG9yIG5lYXJseS1vcmRlcmVkIGRlbGl2 ZXJ5Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9saT48bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0OmwwIGxldmVsMSBsZm8xIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTpNZW5sby1SZWd1 bGFyIj5Ib3cgaXMgdGhpcyBuZWdvdGlhdGVkPyAmbmJzcDtJbiBJS0U/IFByaW9yIGFncmVlbWVu dD88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6TWVubG8tUmVndWxh ciI+V2h5IGRvIHdlIG5lZWQgYSBuZXcgcG9ydD8gJm5ic3A7V2hhdCBnb2VzIHdyb25nIGlmIHRo ZSBwYWNrZXRzIGdvIHRvIHBvcnQgNDUwMD88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5Ok1lbmxvLVJlZ3VsYXIi PlRoYW5rczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5Ok1lbmxvLVJlZ3VsYXIiPllvYXY8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5PbiAxIE5vdiAyMDE2LCBhdCAzOjQ1LCBYdXhpYW9odSAmbHQ7PGEgaHJlZj0i bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnh1 eGlhb2h1QGh1YXdlaS5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGkg YWxsLDxicj4NCjxicj4NCkFueSBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUu PGJyPg0KPGJyPg0KQmVzdCByZWdhcmRzLDxicj4NClhpYW9odTxicj4NCjxicj4NCjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tLS0tLTwvc3Bhbj7pgq7ku7bljp/ku7Y8c3BhbiBs YW5nPSJFTi1VUyI+LS0tLS08YnI+DQo8L3NwYW4+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMi Pjo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+WzxhIGhyZWY9Im1haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc8L3NwYW4+PC9hPl08YnI+DQo8L3NwYW4+5Y+R6YCB5pe26Ze0 PHNwYW4gbGFuZz0iRU4tVVMiPjogMjAxNjwvc3Bhbj7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+MTA8 L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjMxPC9zcGFuPuaXpTxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj4xOToxNTxicj4NCjwvc3Bhbj7mlLbku7bkuro8c3BhbiBsYW5n PSJFTi1VUyI+OiBYdXhpYW9odTsgemhhbmdkYWNoZW5nOyBYaWFsaWFuZyAoRnJhbmspPGJyPg0K PC9zcGFuPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQteHUtaXBzZWNtZS1lc3AtaW4tdWRwLWxiLTAwLnR4dDxicj4NCjxicj4NCjxi cj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC14dS1pcHNlY21lLWVzcC1pbi11ZHAtbGIt MDAudHh0PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMaWFuZyBYaWEg YW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Ljxicj4NCjxicj4NCk5hbWU6PHNwYW4g Y2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3Nw YW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmRyYWZ0 LXh1LWlwc2VjbWUtZXNwLWluLXVkcC1sYjxicj4NClJldmlzaW9uOjxzcGFuIGNsYXNzPSJhcHBs ZS10YWItc3BhbiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj4wMDxicj4NClRpdGxlOjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3Bh biI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5FbmNhcHN1bGF0aW5nIElQc2VjIEVTUCBpbiBVRFAg Zm9yIExvYWQtYmFsYW5jaW5nPGJyPg0KRG9jdW1lbnQgZGF0ZTo8c3BhbiBjbGFzcz0iYXBwbGUt dGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+MjAxNi0xMC0zMTxicj4NCkdyb3VwOjxzcGFuIGNs YXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5JbmRpdmlkdWFsIFN1 Ym1pc3Npb248YnI+DQpQYWdlczo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+Nzxicj4NClVSTDo8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteHUtaXBzZWNtZS1lc3AtaW4tdWRwLWxiLTAwLnR4 dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LXh1LWlwc2VjbWUtZXNwLWluLXVkcC1sYi0wMC50eHQ8L3NwYW4+PC9h Pjxicj4NClN0YXR1czo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC14dS1pcHNlY21lLWVzcC1pbi11ZHAtbGIvIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC14dS1pcHNlY21l LWVzcC1pbi11ZHAtbGIvPC9zcGFuPjwvYT48YnI+DQpIdG1saXplZDogJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXh1LWlwc2VjbWUtZXNwLWluLXVkcC1sYi0wMCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LWlwc2VjbWUtZXNwLWlu LXVkcC1sYi0wMDwvc3Bhbj48L2E+PGJyPg0KPGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5i c3A7SVBzZWMgVmlydHVhbCBQcml2YXRlIE5ldHdvcmsgKFZQTikgaXMgd2lkZWx5IHVzZWQgYnkg ZW50ZXJwcmlzZXMgdG88YnI+DQombmJzcDtpbnRlcmNvbm5lY3QgdGhlaXIgZ2VvZ3JhcGhpY2Fs IGRpc3BlcnNlZCBicmFuY2ggb2ZmaWNlIGxvY2F0aW9uczxicj4NCiZuYnNwO2Fjcm9zcyBJUCBX aWRlIEFyZWEgTmV0d29yayAoV0FOKS4gVG8gZnVsbHkgdXRpbGl6ZSB0aGUgYmFuZHdpZHRoPGJy Pg0KJm5ic3A7YXZhaWxhYmxlIGluIElQIFdBTiwgbG9hZCBiYWxhbmNpbmcgb2YgdHJhZmZpYyBi ZXR3ZWVuIGRpZmZlcmVudDxicj4NCiZuYnNwO0lQc2VjIFZQTiBzaXRlcyBvdmVyIEVxdWFsIENv c3QgTXVsdGktUGF0aCAoRUNNUCkgYW5kL29yIExpbms8YnI+DQombmJzcDtBZ2dyZWdhdGlvbiBH cm91cCAoTEFHKSB3aXRoaW4gSVAgV0FOIGlzIGF0dHJhY3RpdmUgdG8gdGhvc2U8YnI+DQombmJz cDtlbnRlcnByaXNlcyBkZXBsb3lpbmcgSVBzZWMgVlBOIHNvbHV0aW9ucy4gVGhpcyBkb2N1bWVu dCBkZWZpbmVzIGE8YnI+DQombmJzcDttZXRob2QgdG8gZW5jYXBzdWxhdGUgSVBzZWMgRW5jYXBz dWxhdGluZyBTZWN1cml0eSBQYXlsb2FkIChFU1ApPGJyPg0KJm5ic3A7cGFja2V0cyBpbnNpZGUg VURQIHBhY2tldHMgZm9yIGltcHJvdmluZyBsb2FkLWJhbGFuY2luZyBvZiBJUHNlYzxicj4NCiZu YnNwO3R1bm5lbGVkIHRyYWZmaWMuIEluIGFkZGl0aW9uLCB0aGlzIGVuY2Fwc3VsYXRpb24gaXMg YWxzbyBhcHBsaWNhYmxlPGJyPg0KJm5ic3A7dG8gc29tZSBzcGVjaWFsIG11bHRpLXRlbmFudCBk YXRhIGNlbnRlciBuZXR3b3JrIGVudmlyb25tZW50IHdoZXJlPGJyPg0KJm5ic3A7dGhlIG92ZXJs YXkgdHVubmVscyBuZWVkIHRvIGJlIHNlY3VyZWQuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxicj4NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIj4N CnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCklQc2VjIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpJUHNlY0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SVBzZWNAaWV0Zi5v cmc8L3NwYW4+PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaXBzZWMiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB28271NKGEML515MBXchi_-- From nobody Wed Nov 9 09:52:04 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8F11295BA for ; Wed, 9 Nov 2016 09:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 R21PjWq5CX0d for ; Wed, 9 Nov 2016 09:52:01 -0800 (PST) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 BEBDB129584 for ; Wed, 9 Nov 2016 09:51:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1478713919; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1yK7hxpU3ciEQz2zLhp2scJYccvS+GYdTmDLtHxbinY=; b=uj1sQlgdYFnsCacS5JMEl0DosQwiEar2MjZLVtid0eh3WpX2P0r0wL3+mPwg5l3q gJyVhylZLieYPR2HBMwG52B7z/d6PfrpGpccyiQXCwVzr3yAYZnqV8IIcGo7YJ3j QwxCamwoeJDKlaqN9FwJSGkE8doyzTtIggebiHUm5qGF7IEUyyPtWYCBQDhAYBsJ SZqXZMNWt3d/ELno02lt8V3RW8AZ3SAs0WHyDp8WNH8WkUgROSQY1u2FzlsBMp/o OPRmyperxltRucyErfwHYUgQxyb25xPVLZm0M2JhnQLMDC5wJobjexfV9Md1K7V3 zJIIWQxXpywOaQ1lvmoTjQ==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id B5.1A.32245.F3263285; Wed, 9 Nov 2016 09:51:59 -0800 (PST) X-AuditID: 11973e16-f7e959a000007df5-d9-5823623fbd63 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay2.apple.com (Apple SCV relay) with SMTP id 7B.11.09148.F3263285; Wed, 9 Nov 2016 09:51:59 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_CveeJOV6aMwOAihuHY7xlg)" Received: from [17.226.23.252] (unknown [17.226.23.252]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OGD00427YYMAU90@nwk-mmpp-sz12.apple.com>; Wed, 09 Nov 2016 09:51:59 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Wed, 09 Nov 2016 09:51:58 -0800 In-reply-to: To: Yoav Nir References: <147768444132.24987.10305392703895531882.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3252) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUi2FDorGufpBxhsOSgksWSXc+ZLT7czbXY v+UFm8XSYx+YHFg8ds66y+6xZMlPpgCmKC6blNSczLLUIn27BK6MUxN+sRQccay4d3U+cwPj dMsuRk4OCQETic6zx5i6GLk4hAT2MkrM+jGNESbxfv9dVojEIUaJ3eevgyV4BQQlfky+xwJi MwuESUyasYMdoqiLSeJaz1PmLkYODmEBCYnNexJBatgEVCSOf9vADNFrI3H10hUmiBIHidVz 00DCLAKqEjf6J7KB2JwCthInT+yBGu8scevzL7BWEQElicNXvjJDrGpklHh65Qs7xKGyEiuf bgQ7VELgPpvEsV9H2CcwCs1CcussJLdC2FoS3x+1AsU5gGx5iYPnZSHCmhLP7n2CKtGWePLu AusCRrZVjEK5iZk5upl55nqJBQU5qXrJ+bmbGEHRMd1ObAfjw1VWhxgFOBiVeHg7NJUjhFgT y4orcw8xSnOwKInzTnFXihASSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAaLCfQSbUf/ISbtff 1jvWXjq4zlb/SsryvItRobwcRTZzuNqmplVsqLG8bpSv8mx9t5ru8Zq1rRHT195af+fLmV3s /SlrJS6/iLt9tUXbQdzpzkyjVL+m6zv3r3bOPXhFRO6xkaSojqmDvOVuo3U7mee+Xn/pPGvt xKtz/Nev15J9OGuXQ65riBJLcUaioRZzUXEiAA9aXS9vAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEIsWRmVeSWpSXmKPExsUi2FB8Rtc+STnC4OJsLoslu54zW3y4m2ux f8sLNoulxz4wObB47Jx1l91jyZKfTAFMUVw2Kak5mWWpRfp2CVwZpyb8Yik44lhx7+p85gbG 6ZZdjJwcEgImEu/332WFsMUkLtxbz9bFyMUhJHCIUWL3+euMIAleAUGJH5PvsYDYzAJhEpNm 7GCHKOpikrjW85S5i5GDQ1hAQmLznkSQGjYBFYnj3zYwQ/TaSFy9dIUJosRBYvXcNJAwi4Cq xI3+iWwgNqeArcTJE3ugxjtL3Pr8C6xVREBJ4vCVr8wQqxoZJZ5e+cIOcaisxMqnG1knMArM QnLeLCTnQdhaEt8ftQLFOYBseYmD52UhwpoSz+59girRlnjy7gLrAka2VYwCRak5iZVGeokF BTmpesn5uZsYwUFe6LyD8dgyq0OMAhyMSjy8HZrKEUKsiWXFlbnAMOJgVhLh5UkECvGmJFZW pRblxxeV5qQWH2KcyAj05URmKdHkfGAM5pXEG5qYGJgYG5sZG5ubmNNSWEmc91qHfISQQHpi SWp2ampBahHMUUwcnFINjLs+ay5LEVh03btylpyMP+uXk6W/s71k28+wbxZ9zTSPSevRTrZT 0s9Xu8653az3SOPWksic9GLPIuHCkqclO76///f99JOCcwuPClzffzjh4EKF5OWXb4a2b/3v cUrW3qf1wdu31ackYqfZB/04Evo37SXXtg+WNd4SHyMlXS4s7TQ9WZe+bq0SS3FGoqEWc1Fx IgBEsHo25QIAAA== Archived-At: Cc: ipsec@ietf.org, internet-drafts@ietf.org, i-d-announce@ietf.org Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-eddsa-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 17:52:03 -0000 --Boundary_(ID_CveeJOV6aMwOAihuHY7xlg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi Yoav, Thanks for posting this. The draft looks good, and we're eager to see this move along! If you have an implementation already supporting this, I'd be interested in testing interop. I think the reservation of the 0 IANA hash value for the "Identity" hash makes sense; since it seems pretty straightforward, is there a possibility of getting this reserved soon? Thanks, Tommy > On Oct 29, 2016, at 8:19 AM, Yoav Nir wrote: > > This version is similar to draft-nir-ipsecme-eddsa-01, with the following changes: > Updated references > Removed the title of the Curdle draft from the text because it had become unwieldy [1] > Updated the OIDs in appendix A and added a binary representation as in RFC 7427 > Added some text in IANA considerations > > The XML source is now in https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-ipsecme-eddsa.xml > > Yoav > > [1] Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure > >> On 28 Oct 2016, at 22:54, internet-drafts@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the IP Security Maintenance and Extensions of the IETF. >> >> Title : Using Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange (IKEv2) >> Author : Yoav Nir >> Filename : draft-ietf-ipsecme-eddsa-00.txt >> Pages : 5 >> Date : 2016-10-28 >> >> Abstract: >> This document describes the use of the Edwards-curve digital >> signature algorithm in the IKEv2 protocol. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-eddsa/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-ipsecme-eddsa-00 >> >> >> 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/ >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Boundary_(ID_CveeJOV6aMwOAihuHY7xlg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
Hi Yoav,

Thanks for posting this. The draft = looks good, and we're eager to see this move along! If you have an = implementation already supporting this, I'd be interested in testing = interop.

I = think the reservation of the 0 IANA hash value for the "Identity" hash = makes sense; since it seems pretty straightforward, is there a = possibility of getting this reserved soon?

Thanks,
Tommy

On Oct 29, 2016, at 8:19 AM, Yoav Nir <ynir.ietf@gmail.com>= wrote:

This version = is similar to draft-nir-ipsecme-eddsa-01, with the following = changes:
  1. Updated = references
  2. Removed the title of the Curdle draft from = the text because it had become unwieldy [1]
  3. Updated = the OIDs in appendix A and added a binary representation as in RFC = 7427
  4. Added some text in IANA = considerations

The XML source is now in https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-i= psecme-eddsa.xml

Yoav

[1] Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, = Ed448ph, X25519 and X448 for use in the Internet X.509 Public Key = Infrastructure

On 28 = Oct 2016, at 22:54, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of = the IP Security Maintenance and Extensions of the IETF.

       Title =           : Using = Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key = Exchange (IKEv2)
=        Author =          : Yoav Nir
= Filename        : = draft-ietf-ipsecme-eddsa-00.txt
Pages =           : 5
= Date =            : = 2016-10-28

Abstract:
=   This document describes the use of the Edwards-curve = digital
  signature algorithm in the IKEv2 = protocol.


The IETF = datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-eddsa/<= br class=3D"">
There's also a htmlized version available = at:
https://tools.ietf.org/html/draft-ietf-ipsecme-eddsa-00


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/

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

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

= --Boundary_(ID_CveeJOV6aMwOAihuHY7xlg)-- From nobody Wed Nov 9 12:31:32 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E8F1293DB for ; Wed, 9 Nov 2016 12:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e_jBZgA9kspp for ; Wed, 9 Nov 2016 12:31:27 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62A681296AD for ; Wed, 9 Nov 2016 12:31:27 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id f82so265420265wmf.1 for ; Wed, 09 Nov 2016 12:31:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7lvpB5NiBrQhiEFcLJDJHKyMCMhKxcbwpAn2y2iZS6s=; b=w0CLqkhx3Y58TYm5MB7IdIUEBDltHmoXH4F/f9lyLDQcPVAusxN9Hj5LnbPNsVCgKx oZZLId4Wn23m3Qtj31OXSdbAXyjOaJzOFZKp+yVW8LMJKptX0KpeeTiv7lZkuTbe8um7 Khp7aSYOt6696D0o3QLBKLRscV8FKD21sZ106fYtlgH69tggWAEZ/JTkFGpoinAXlX0x EN5+GBRoVF9mUTNJmUCUAB5qOXboML6uu072frdnU3+PdeIJX80mo26BSKIW2D+IBgpb DMbUnMEtwKy7aZRcRxrmL5en3TpJu7Blb9VD4hTbc6dKl0VlT/Nz8gRVWy67/DIB3wCW 0V8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7lvpB5NiBrQhiEFcLJDJHKyMCMhKxcbwpAn2y2iZS6s=; b=MPiwdEWdT7zDJzN+LTW2ca7Hs4mQT1lTXw128XDXuOPZ9Ik+ZrTsOoxKbBLHSzS2su iKJMldZ0IfSAhpZttIv64U6c+03Ira/1HU4OH/SCfTAldsKZraCzGPklo0kXXpJfj9eW o8FKYowv23JLmAelt6WOrSkc6F4dOb4314Zsd5S0NsMrE72R9YgcT/iaaM7+yII8Exhm wMuIQiIAg3DdvsQuXj74wp0HCai6at/lgqc0aOKdpmR/TdUY/J7Rf9X5O2e+DI8aDG16 JZbSaSQTQO6n7fqkVNvIQvQ7RGfqq+zU2SrEewapH6mOkITyP14VtCnIAm0Y6aOx3l5i 946A== X-Gm-Message-State: ABUngvfmKM1+XxvqhQsN4ouVk8s0OrTeUj2CL3G4hJxV7mTdmFQvnYx0W4i/Z2HEes0lOw== X-Received: by 10.28.35.205 with SMTP id j196mr2374746wmj.62.1478723485882; Wed, 09 Nov 2016 12:31:25 -0800 (PST) Received: from [192.168.1.13] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id s133sm8931987wmd.19.2016.11.09.12.31.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Nov 2016 12:31:25 -0800 (PST) From: Yoav Nir Message-Id: <4BD3D3EB-F609-4D1E-8FCB-C567D616BDBA@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7C322795-5D98-415C-A88B-C526D18C2E1C" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Wed, 9 Nov 2016 22:31:23 +0200 In-Reply-To: To: Tommy Pauly References: <147768444132.24987.10305392703895531882.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-eddsa-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 20:31:30 -0000 --Apple-Mail=_7C322795-5D98-415C-A88B-C526D18C2E1C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 For the most part, it is up to the IETF what gets registered for our = protocols at IANA. If we want early assignment for this, it=E2=80=99s up to the chair, the = document shepherd and the IANA expert. It helps that all three are the = same person (Tero) But if he and we agree that it=E2=80=99s going to end up being zero, = there=E2=80=99s nothing to stop anyone from implementing. And I=E2=80=99m sorry but I don=E2=80=99t have an implementation. Yoav > On 9 Nov 2016, at 19:51, Tommy Pauly wrote: >=20 > Hi Yoav, >=20 > Thanks for posting this. The draft looks good, and we're eager to see = this move along! If you have an implementation already supporting this, = I'd be interested in testing interop. >=20 > I think the reservation of the 0 IANA hash value for the "Identity" = hash makes sense; since it seems pretty straightforward, is there a = possibility of getting this reserved soon? >=20 > Thanks, > Tommy >=20 >> On Oct 29, 2016, at 8:19 AM, Yoav Nir > wrote: >>=20 >> This version is similar to draft-nir-ipsecme-eddsa-01, with the = following changes: >> Updated references >> Removed the title of the Curdle draft from the text because it had = become unwieldy [1] >> Updated the OIDs in appendix A and added a binary representation as = in RFC 7427 >> Added some text in IANA considerations >>=20 >> The XML source is now in = https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-ipsecme-edds= a.xml = >>=20 >> Yoav >>=20 >> [1] Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, Ed448ph, = X25519 and X448 for use in the Internet X.509 Public Key Infrastructure >>=20 >>> On 28 Oct 2016, at 22:54, internet-drafts@ietf.org = wrote: >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the IP Security Maintenance and = Extensions of the IETF. >>>=20 >>> Title : Using Edwards-curve Digital Signature = Algorithm (EdDSA) in the Internet Key Exchange (IKEv2) >>> Author : Yoav Nir >>> Filename : draft-ietf-ipsecme-eddsa-00.txt >>> Pages : 5 >>> Date : 2016-10-28 >>>=20 >>> Abstract: >>> This document describes the use of the Edwards-curve digital >>> signature algorithm in the IKEv2 protocol. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-eddsa/ = >>>=20 >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-ipsecme-eddsa-00 = >>>=20 >>>=20 >>> 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. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 --Apple-Mail=_7C322795-5D98-415C-A88B-C526D18C2E1C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 For the most part, it is up to the IETF what gets registered = for our protocols at IANA.

If we want early assignment for this, it=E2=80=99s up to the = chair, the document shepherd and the IANA expert.  It helps that = all three are the same person (Tero)

But if he and we agree that it=E2=80=99s = going to end up being zero, there=E2=80=99s nothing to stop anyone from = implementing.

And I=E2=80=99m sorry but I don=E2=80=99t have an = implementation.

Yoav


On 9 Nov 2016, at 19:51, Tommy Pauly <tpauly@apple.com> = wrote:

Hi Yoav,

Thanks for posting this. The draft looks good, and we're = eager to see this move along! If you have an implementation already = supporting this, I'd be interested in testing interop.

I think the reservation = of the 0 IANA hash value for the "Identity" hash makes sense; since it = seems pretty straightforward, is there a possibility of getting this = reserved soon?

Thanks,
Tommy

On Oct = 29, 2016, at 8:19 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:

This version = is similar to draft-nir-ipsecme-eddsa-01, with the following = changes:
  1. Updated = references
  2. Removed the title of the Curdle draft from = the text because it had become unwieldy [1]
  3. Updated = the OIDs in appendix A and added a binary representation as in RFC = 7427
  4. Added some text in IANA = considerations

The XML source is now in https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-i= psecme-eddsa.xml

Yoav

[1] Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, = Ed448ph, X25519 and X448 for use in the Internet X.509 Public Key = Infrastructure

On 28 = Oct 2016, at 22:54, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of = the IP Security Maintenance and Extensions of the IETF.

       Title =           : Using = Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key = Exchange (IKEv2)
=        Author =          : Yoav Nir
= Filename        : = draft-ietf-ipsecme-eddsa-00.txt
Pages =           : 5
= Date =            : = 2016-10-28

Abstract:
=   This document describes the use of the Edwards-curve = digital
  signature algorithm in the IKEv2 = protocol.


The IETF = datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-eddsa/<= br class=3D"">
There's also a htmlized version available = at:
https://tools.ietf.org/html/draft-ietf-ipsecme-eddsa-00


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/

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

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


= --Apple-Mail=_7C322795-5D98-415C-A88B-C526D18C2E1C-- From nobody Mon Nov 14 04:52:44 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733C91296B8 for ; Mon, 14 Nov 2016 04:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LccWFH5Wn1Oy for ; Mon, 14 Nov 2016 04:52:40 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 5A0F41296B7 for ; Mon, 14 Nov 2016 04:52:40 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id c4so17834796pfb.1 for ; Mon, 14 Nov 2016 04:52:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:to:from:subject:date:importance :thread-topic:in-reply-to:references; bh=kalAt0nn1ERBzj+Wdb7iA7F35nwYUvpfWB6zIpCUZhU=; b=jFKR9CjZwXyyMOhKsEkg6i0IMrBwn9zwrK9j1p7MnB/l4CTBc5xX4mnioy5fIPl0CC pla1VWony931BK3IrFFGCkLH1kX5ihv5o0Rz8/MTlAlbSeOCOVnAZQ+2rAXg+C/0nu2p Q63BfgmwUvOC96BHCJ+gr1hZWHDiD51zX0T/hiIOJSlI36ckqdgoJa0iVyz2irDNahI8 C/CDevznsgHXyO9qzul2J6PjH5JncGujgOU7c29/Y81vItAUdNRhz27yOVUXxTkfDh/6 2hjo5bxq5F6pwoR3mKr1KnyYXUaFbMDHf2zUOLQFzpqV/aMk94K1l5lCEKcVWiotw9rl o08w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance:thread-topic:in-reply-to:references; bh=kalAt0nn1ERBzj+Wdb7iA7F35nwYUvpfWB6zIpCUZhU=; b=LfEGvZVTnk/knOhTYSgzD+6yvbSYiAaIQYSAEhLeyQDKQLwu46XD8M5DrpKf1juIym uU11gU9t4TGQHRyHbPFT2IlofOpAD0K/LfbVor7sJuDeNO/NX+PoRs4u8Yeuu04Hvz69 5NzSnnF2ORiInwtgF5kSP2lgoObHIlZyHYjlG0TMS+gAirmjhUe6xwCHssWISHqqbR/p /wi5RiBZj+UFMz6OTHFpBR0oXqkpx4Kmrs8PbzT2Pb+N78A92BPpzs1VramTb1wxo2Y1 6jIYXa4n2KVrGxoEzn97jw43vRjdYlLrwBNvPY8uPUXSWyguz+z498gYfWWhPHQJNe// HNpA== X-Gm-Message-State: ABUngvf0aI3ZiXsqaBCArZCdAnf7AcKElSHVvQcf4XRatorEC+ibJ/vN/SA7as603DnXxg== X-Received: by 10.98.81.70 with SMTP id f67mr35351187pfb.179.1479127959912; Mon, 14 Nov 2016 04:52:39 -0800 (PST) Received: from ?IPv6:::ffff:192.168.0.34? ([175.193.211.25]) by smtp.gmail.com with ESMTPSA id r1sm35260378pfg.56.2016.11.14.04.52.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Nov 2016 04:52:39 -0800 (PST) Message-ID: <5829b397.01d6620a.9dfb5.4373@mx.google.com> MIME-Version: 1.0 To: "Scott Fluhrer (sfluhrer)" , "IPsecme WG (ipsec@ietf.org)" From: Valery Smyslov Date: Mon, 14 Nov 2016 21:52:40 +0900 Importance: normal X-Priority: 3 Thread-Topic: Quantum Resistance Requirements In-Reply-To: <6c1585204f6a4598b6e40b05912ba4c4@XCH-RTP-006.cisco.com> References: <6c1585204f6a4598b6e40b05912ba4c4@XCH-RTP-006.cisco.com> Content-Type: multipart/alternative; boundary="_A4C51AB3-D78C-446A-86DF-E62FC4948D12_" Archived-At: Subject: Re: [IPsec] FW: Quantum Resistance Requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 12:52:42 -0000 --_A4C51AB3-D78C-446A-86DF-E62FC4948D12_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Scott, after reading the draft I have one question. The draft redefines both KEYMAT and SKEYSEED for IKE SA rekey derivations for the case when PPK is used. Did you consider variant when only SK_d derivation is modified? Something like this: No modification to SK_* calculation, SKEYSEED calculation and KEYMAT calcul= ation. However, for the PPK use case define SK_d`, that must be used instead of SK= _d, so that SK_d=E2=80=99 =3D prf+(SK_d, Ni=E2=80=99 | Nr=E2=80=99), where Ni= =E2=80=99 =3D prf(PPK, Ni), Nr=E2=80=99 =3D prf(PPK, Nr). This is an ad hoc construction, probably it can be improved, but the idea i= s clear: Introduce a single point (SK_d=E2=80=99 derivation) where modifications to = keys derivation algorithm take place, instead of two points. It will make implementations modificatio= n easier, I think. So, did you consider such variant? Are there any security disadvantages? Regards, Valery Smyslov. From: Scott Fluhrer (sfluhrer) Sent: 28 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2016 =D0=B3. 23:25 To: IPsecme WG (ipsec@ietf.org) Subject: [IPsec] FW: Quantum Resistance Requirements Here is an update on the voting for the list of potential requirements for = a short term Quantum Resistance solution; and a summary of the recent updat= e to our draft (which reflects the stated requirements) The votes so far (omitting the "no opinion" votes); I've listed the voters = chiefly so that if I mischaracterized their votes, they can correct me. - Simplicity; how large of a change to IKE (and IKE implementations) are we= willing to contemplate? Scott Fluhrer: very important Michael Richardson: very important Tommy Pauly: very important Valery Smyslov: not as important as other issues Oscar Garcia-Morchon: very important. - Preserving existing IKE security properties? Scott Fluhrer: very important Michael Richardson: very important Tommy Pauly: very important Valery Smyslov: important Oscar Garcia-Morchon: very important.=20 - What do we feel needs to protected from someone with a Quantum Computer? = =C2=A0Do we feel =C2=A0the need to protect only the IPsec traffic, or do we= need to protect the IKE traffic as well. Tommy Pauly: not clear if IKE traffic needs to be protected. Valery Smylsov: important Oscar Garcia-Morchon: IPsec traffic must be protected, IKE traffic would be= a nice-to-have.=20 - What level of identity protection do we need to provide?=C2=A0 If two dif= ferent IKE negotiations use the same shared secret, do we mind if someone c= an deduce that? Scott Fluhrer: not important Michael Richardson: very important Tommy Pauly: not important Valery Smylsov: this is a nice to have, but not critical Oscar Garcia-Morchon: this is less important Russ Houseley: this is a nice to have, but only if it is cheap - =C2=A0PPK management; how much support do we provide for automatically ma= naging the secrets? Scott Fluhrer: not important Tommy Pauly: not important Oscar Garcia-Morchon: not important - How much support do we provide for nonstatic secrets, for example, by QKD= , or via something like HIMMO (a key distribution mechanism that appears to= be post quantum)? Scott Fluhrer: not important Michael Richardson: not important Tommy Pauly: not important Oscar Garcia-Morchon: not important now, but will become important in the f= uture - Authentication; if someone with a Quantum Computer can break the DH in re= al time, do we care if he can act as a man-in-the-middle? Scott Fluhrer: not important Michael Richardson: important, provided that we don't run into the same iss= ues that IKEv1 PSKs ran into Tommy Pauly: not important Valery Smylsov: this would be nice to have Oscar Garcia-Morchon: this would be nice to have - Algorithm agility; how important is it that we negotiate any cryptoprimit= ives involved? Scott Fluhrer: not important Tommy Pauly: not important Valery Smylsov: important Oscar Garcia-Morchon: less important. My tentative summary of the votes: - Simplicity and preserving existing security properties are the most impor= tant - Protecting IKE traffic was considered less important. We have updated our draft to reflect these requirements; it is much simpler= than the previous draft, but does not provide anonymity. It is based on a= suggestion by Tero (which was to do the initial IKE SA establishment as no= rmal, and then stir in the PPK into the IPsec KEYMAT generation process); t= his makes it much simpler than trying to exchange identities before doing t= he initial key derivation. We did add a modification to how the child SA S= KEYSEED was computed (by stirring in the PPK there as well); the advantage = of this is that this means that any child IKE SAs were also quantum resista= nt. This implies that an implementation that did insist on protecting the = IKE traffic could immediately generate a child SA after negotiation, and th= en use that child SA to do all the real negotiation. We thought that this = flexibility justified the extra complication of modifying the SKEYSEED comp= utation. Such an implementation would leak the identities to a Quantum adv= ersary, but everything else would be protected. Here is how the draft scores against the given criteria: - Simplicity; it is fairly simple - Preserving existing IKE security properties? It preserves all IKE securi= ty properties against an adversary with a conventional computer=20 - What is protected from someone with a Quantum Computer? It protects the = IPsec traffic; it also allows an implementation (with more exchanges) to pr= otect the IKE traffic (apart from the identities) - What level of identity protection do we need to provide? This doesn't pr= ovide any identity protection against someone with a Quantum Computer - PPK management; not addressed - How much support do we provide for nonstatic secrets? Not addressed, how= ever it would not be difficult to add in the future. - Authentication; can an attacker with Quantum Computer act as a man-in-the= -middle? No, not if both sides have PPK mandatory - Algorithm agility; yes, the only algorithms used are the ones negotiated _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_A4C51AB3-D78C-446A-86DF-E62FC4948D12_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

Hi Scott,

 

after reading the draft I have one question. The draft redefines b= oth

KEYMAT and= SKEYSEED for IKE SA rekey derivations for the case

when PPK is used. Did you consider va= riant when only SK_d derivation

<= span lang=3DEN-US>is modified? Something like this:

 

No modification to SK_* calculation, SKEYSE= ED calculation and KEYMAT calculation.

However, for the PPK use case define SK_d`, that m= ust be used instead of SK_d,

so that SK_d=E2=80=99 =3D prf+(SK_d, Ni=E2=80=99 | Nr=E2=80= =99), where Ni=E2=80=99 =3D prf(PPK, Ni), Nr=E2= =80=99 =3D prf(PPK, Nr)= .

 

= This is an ad hoc construction, probably it can be impro= ved, but the idea is clear:

Introduce a single point (SK_d=E2=80=99 derivation) where mod= ifications to keys derivation algorithm

take place, instead of two points. It will make i= mplementations modification easier, I think.

 

So, did you consider such variant? Are there any s= ecurity disadvantages?

 = ;

Regards,

Valery Smyslov.

 

From: Scott Fluhrer (sfluhrer)
Sent: 28 =D0= =BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2016 =D0=B3. 23:25
To: IPsecme WG (ipsec@ietf.org)
Subje= ct: [IPsec] FW: Quantum Resistance Requirements

 

Here is an update on the = voting for the list of potential requirements for a short term Quantum Resi= stance solution; and a summary of the recent update to our draft (which ref= lects the stated requirements)

 

The votes so far (omitting the "no opinion"= votes); I've listed the voters chiefly so that if I mischaracterized their= votes, they can correct me.

 

<= p class=3DMsoNormal> 

- Simplicity;= how large of a change to IKE (and IKE implementations) are we willing to c= ontemplate?

Scott Fluhrer: very important

Michael Richardson: very important

T= ommy Pauly: very important

Valery Smyslov: not as i= mportant as other issues

Oscar Garcia-Morchon: very= important.

 

 

- Preserving existing IKE secu= rity properties?

Scott Fluhrer: very important

<= p class=3DMsoNormal>Michael Richardson: very important

Tommy Pauly: very important

Valery Smyslov: imp= ortant

Oscar Garcia-Morchon: very important.

 

 

- What do we feel needs to protected from someo= ne with a Quantum Computer?  Do we feel  the need to protect only= the IPsec traffic, or do we need to protect the IKE traffic as well.

Tommy Pauly: not clear if IKE traffic needs to be protec= ted.

Valery Smylsov: important

Oscar Garcia-Morchon: IPsec traffic must be protected, IKE traffic woul= d be a nice-to-have.

 

 

 

- What level of identity protection do we need to pro= vide?  If two different IKE negotiations use the same shared secret, d= o we mind if someone can deduce that?

Scott Fluhrer= : not important

Michael Richardson: very important<= /p>

Tommy Pauly: not important

= Valery Smylsov: this is a nice to have, but not critical

Oscar Garcia-Morchon: this is less important

= Russ Houseley: this is a nice to have, but only if it is cheap

 

 

-  PPK management; how much support do we provid= e for automatically managing the secrets?

Scott Flu= hrer: not important

Tommy Pauly: not important

<= p class=3DMsoNormal>Oscar Garcia-Morchon: not important

 

 

- How much support do we provide for nonstatic secrets, for e= xample, by QKD, or via something like HIMMO (a key distribution mechanism t= hat appears to be post quantum)?

Scott Fluhrer: not= important

Michael Richardson: not important

Tommy Pauly: not important

Oscar = Garcia-Morchon: not important now, but will become important in the future<= /p>

 

&nbs= p;

- Authentication; if someone with a Quantu= m Computer can break the DH in real time, do we care if he can act as a man= -in-the-middle?

Scott Fluhrer: not important

Michael Richardson: important, provided that we don't run= into the same issues that IKEv1 PSKs ran into

Tomm= y Pauly: not important

Valery Smylsov: this would b= e nice to have

Oscar Garcia-Morchon: this would be = nice to have

 

 

- Algorithm agility; how impo= rtant is it that we negotiate any cryptoprimitives involved?

Scott Fluhrer: not important

Tommy Pauly:= not important

Valery Smylsov: important

Oscar Garcia-Morchon: less important.

 

My tentative summary of the vote= s:

 

- Simp= licity and preserving existing security properties are the most important

- Protecting IKE traffic was considered less importa= nt.

 

=  

 

We have updated our draft to reflect these requirements; it is much sim= pler than the previous draft, but does not provide anonymity.=C2=A0 It is b= ased on a suggestion by Tero (which was to do the initial IKE SA establishm= ent as normal, and then stir in the PPK into the IPsec KEYMAT generation pr= ocess); this makes it much simpler than trying to exchange identities befor= e doing the initial key derivation.=C2=A0 We did add a modification to how = the child SA SKEYSEED was computed (by stirring in the PPK there as well); = the advantage of this is that this means that any child IKE SAs were also q= uantum resistant.=C2=A0 This implies that an implementation that did insist= on protecting the IKE traffic could immediately generate a child SA after = negotiation, and then use that child SA to do all the real negotiation.=C2= =A0 We thought that this flexibility justified the extra complication of mo= difying the SKEYSEED computation.=C2=A0 Such an implementation would leak t= he identities to a Quantum adversary, but everything else would be protecte= d.

 

Here i= s how the draft scores against the given criteria:

=  

- Simplicity; it is fairly simple=

- Preserving existing IKE security properties?=C2= =A0 It preserves all IKE security properties against an adversary with a co= nventional computer

- What is protected from someo= ne with a Quantum Computer?=C2=A0 It protects the IPsec traffic; it also al= lows an implementation (with more exchanges) to protect the IKE traffic (ap= art from the identities)

- What level of identity p= rotection do we need to provide?=C2=A0 This doesn't provide any identity pr= otection against someone with a Quantum Computer

-= =C2=A0 PPK management; not addressed

- How much sup= port do we provide for nonstatic secrets?=C2=A0 Not addressed, however it w= ould not be difficult to add in the future.

- Authe= ntication; can an attacker with Quantum Computer act as a man-in-the-middle= ?=C2=A0 No, not if both sides have PPK mandatory

- = Algorithm agility; yes, the only algorithms used are the ones negotiated

 

___________= ____________________________________

IPsec mailing = list

IPsec@ietf.org

https:/= /www.ietf.org/mailman/listinfo/ipsec

 

= --_A4C51AB3-D78C-446A-86DF-E62FC4948D12_-- From nobody Mon Nov 14 05:21:39 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893B912967A for ; Mon, 14 Nov 2016 05:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 3OqaSp4PzPRv for ; Mon, 14 Nov 2016 05:21:35 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (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 7235D1296DF for ; Mon, 14 Nov 2016 05:21:35 -0800 (PST) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id C220B4C628F04; Mon, 14 Nov 2016 13:21:31 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id uAEDLY2E014022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Nov 2016 13:21:34 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id uAEDLXeY001086 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Nov 2016 13:21:33 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.86]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0301.000; Mon, 14 Nov 2016 08:21:33 -0500 From: "Hu, Jun (Nokia - US)" To: Tommy Pauly , IPsecME WG Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt Thread-Index: AQHSM5AA1k/Xaiekb0qxCs7Gxchv+6DXe2NQ Date: Mon, 14 Nov 2016 13:21:31 +0000 Message-ID: <876523B00C3F9D47BFD2B654D63DBF92BEB12F24@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <147792938094.32373.833800643936554773.idtracker@ietfa.amsl.com> <61A7C96D-66A0-4BA7-82BE-277CBE13ED45@apple.com> In-Reply-To: <61A7C96D-66A0-4BA7-82BE-277CBE13ED45@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 13:21:37 -0000 VHdvIGNvbW1lbnRzOg0KDQoxLiBUaGUgZHJhZnQgc2VlbXMgdG8gaW1wbHkgdGhhdCBvbmx5IHR1 bm5lbCBpbml0aWF0b3IgaXMgYWxsb3dlZCB0byBpbml0aWF0ZSBUQ1Agc2Vzc2lvbiwgIGhvd2V2 ZXIgd2hhdCBpcyBiZWhhdmlvciBhZnRlciBUQ1AgY29ubmVjdGlvbiBpcyBsb3N0IGFuZCBpbml0 aWF0b3IgbmVlZCB0byByZS1jcmVhdGUgaXQ/IGRvZXMgaXQgZG8gaXQgcmlnaHQgYXdheSBvciBv bmx5IHJlLWNyZWF0ZSBUQ1Agc2Vzc2lvbiB3aGVuIGluaXRpYXRvciBuZWVkIHRvIHNlbmQgc29t ZSBwYWNrZXQ/IEkgYXNzdW1lIGl0IHNob3VsZCBiZSByaWdodCBhd2F5LCBiZWNhdXNlIG90aGVy d2lzZSB0aGVyZSB3aWxsIGJlIHRyYWZmaWMgbG9zcyBpZiB0aGUgcmVzcG9uZGVyIG5lZWQgdG8g c2VuZCBwYWNrZXQgYmVmb3JlIHRoZSBUQ1Agc2Vzc2lvbiBpcyByZS1jcmVhdGVkOw0KU28gaWYg bXkgYWJvdmUgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LCBJJ2QgbGlrZSBkcmFmdCB0byBjbGVh cmx5IHN0YXRlIHRoZSBiZWhhdmlvcjsgDQoNCg0KMi4gc2VjdGlvbiA2IG1lbnRpb24gdGhhdCBp bXBsZW1lbnRhdGlvbiBzaG91bGQgYmUgYWJsZSB0byByZWNlaXZlIGZyb20gYW55IFRDUCBzZXNz aW9uIGFuZCBub3QgZW5mb3JjaW5nIGFueSBzdHJpY3QgbWFwcGluZzsgdGhhdCdzIGZpbmUgZm9y IHJlY2VpdmluZywgaG93ZXZlciBmb3Igc2VuZGluZyB0cmFmZmljLCBzeXN0ZW0gKHNwZWNpYWxs eSByZXNwb25kZXIpIHN0aWxsICBuZWVkIHRvIGtub3cgd2hpY2ggVENQIHNlc3Npb24gdG8gdXNl IHRvIHJlYWNoIHBlZXIgb2YgYSBnaXZlbiBTQTsgZm9yIGV4YW1wbGUsIElmIE5BVCBpcyBkZXRl Y3RlZCwgdGhlbiBpbiBjYXNlIG9mIFRDUCBzZXNzaW9uIGlzIGxvc3Qgb24gaW5pdGlhdG9yIHNp ZGUgYnV0IHN0aWxsIGV4aXN0cyBvbiByZXNwb25kZXIgc2lkZSBhbmQgaW5pdGlhdG9yIHJlLWNy ZWF0ZSB0aGUgVENQIHNlc3Npb24sIHRoZSBuZXcgVENQIHNlc3Npb24gbWlnaHQgaGF2ZSBhIGRp ZmZlcmVudCBOQVQgcHVibGljIHBvcnQgb3IgZXZlbiBkaWZmZXJlbnQgTkFUIHB1YmxpYyBhZGRy ZXNzLCBzbyB0aGUgcmVzcG9uZGVyIGNhbid0IHRlbGwgaWYgdGhlIG5ldyBUQ1Agc2Vzc2lvbiBp cyBmb3IgYW4gZXhpc3RpbmcgU0Egb3IgYSBuZXcgdHVubmVsLCB0aGlzIG1lYW5zIGluaXRpYXRv ciBuZWVkIHRvIHNlbmQgbWVzc2FnZSBmb3IgYWxsIGV4aXN0aW5nIFNBIHRoYXQgbmVlZCB0byB1 c2UgdGhlIG5ldyBUQ1Agc2Vzc2lvbiBzbyB0aGF0IHJlc3BvbmRlciBjb3VsZCB1cGRhdGUgaXRz IFNBLXRvLVRDUCBzZXNzaW9uIG1hcHBpbmcgYmVjYXVzZSBvdGhlcndpc2UgcmVzcG9uZGVyIG1p Z2h0IHVzZSB0aGUgb2xkIFRDUCBzZXNzaW9uIGZvciBvdXRnb2luZyB0cmFmZmljIG9mIGV4aXN0 aW5nIFNBIGFuZCB0cmFmZmljIHdpbGwgYmUgYmxhY2tob2xlZDsgaW4gc2VjdGlvbiA2LCBkcmFm dCBzdGF0ZXMgdGhhdCBlaXRoZXIgVVBEQVRFX1NBX0FERFJFU1Mgb3IgYSBJS0Uga2VlcGFsaXZl IGNvdWxkIGJlIHVzZWQsIGhvd2V2ZXIgdGhlcmUgaXMgbm8gc3BlY2lmaWNhdGlvbiBvZiBiZWhh dmlvciBmb3IgdXBkYXRpbmcgQ0hJTERfU0EgbWFwcGluZyB3aGVuIE1PQklLRSBpcyBub3Qgc3Vw cG9ydGVkOyAgbWF5YmUgaW5pdGlhdG9yIHNob3VsZCBzZW5kIHNvbWUga2luZCBvZiBkdW1teSBw YWNrZXQgb3ZlciB0aGUgQ0hJTERfU0EgdG8gdXBkYXRlIHJlc3BvbmRlcidzIG1hcHBpbmc/DQoN Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJUHNlYyBbbWFpbHRvOmlw c2VjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUb21teSBQYXVseQ0KPiBTZW50OiBN b25kYXksIE9jdG9iZXIgMzEsIDIwMTYgOTowMSBBTQ0KPiBUbzogSVBzZWNNRSBXRw0KPiBTdWJq ZWN0OiBbSVBzZWNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaXBzZWNtZS10Y3AtZW5jYXBzLTAz LnR4dA0KPiANCj4gSGVsbG8sDQo+IA0KPiBJ4oCZdmUgcG9zdGVkIGEgbmV3IHZlcnNpb24gb2Yg dGhlIFRDUCBlbmNhcHN1bGF0aW9uIGRyYWZ0IHdpdGggdGhlIGZvbGxvd2luZw0KPiBjaGFuZ2Vz Og0KPiANCj4gMS4gQWRkZWQgYSBzZWN0aW9uIHRvIGV4cGxpY2l0bHkgZGlzY3VzcyBob3cgdG8g ZmFsbGJhY2sgZnJvbSBVRFAgdG8gVENQDQo+IChyZXRyYW5zbWlzc2lvbnMsIGV0YykgYmFzZWQg b24gZmVlZGJhY2sgZnJvbSB0aGUgY2hhcnRlciBkaXNjdXNzaW9uIDIuDQo+IEV4cGxhaW5lZCB0 aGF0IHRoaXMgbWV0aG9kIG9mIGVuY2Fwc3VsYXRpb24gY2FuIGJlIHVzZWQgZm9yIGFueSBzdHJl YW0NCj4gcHJvdG9jb2wsIGFuZCBpcyBub3QgVENQIHNwZWNpZmljLCBiYXNlZCBvbiBmZWVkYmFj ayBmcm9tIHRoZSBjaGFydGVyDQo+IGRpc2N1c3Npb24gMy4gQ2xhcmlmaWVkIHRoZSB1c2Ugb2Yg bXVsdGlwbGUgVENQIGNvbm5lY3Rpb25zIGZvciBDaGlsZCBTQXMsDQo+IGJhc2VkIG9uIEp1biBI deKAmXMgcXVlc3Rpb25zDQo+IA0KPiBBbHNvLCBJ4oCZbSBoYXBweSB0byBzYXkgdGhhdCB3ZeKA mXZlIGJlZW4gZG9pbmcgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0aW5nIGJldHdlZW4NCj4gQXBwbGUg Y2xpZW50cyBhbmQgQ2lzY28gc2VydmVyIGZvciBUQ1AgZW5jYXBzdWxhdGlvbi4gSWYgYW55b25l IGVsc2UgaGFzIGFuDQo+IGltcGxlbWVudGF0aW9uIHRoZXnigJlkIGxpa2UgdG8gdHJ5IG91dCwg cGxlYXNlIGxldCB1cyBrbm93IQ0KPiANCj4gQmVzdCwNCj4gVG9tbXkNCj4gDQo+ID4gT24gT2N0 IDMxLCAyMDE2LCBhdCA4OjU2IEFNLCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgd3JvdGU6DQo+ ID4NCj4gPg0KPiA+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBv bi1saW5lIEludGVybmV0LURyYWZ0cw0KPiBkaXJlY3Rvcmllcy4NCj4gPiBUaGlzIGRyYWZ0IGlz IGEgd29yayBpdGVtIG9mIHRoZSBJUCBTZWN1cml0eSBNYWludGVuYW5jZSBhbmQgRXh0ZW5zaW9u cyBvZg0KPiB0aGUgSUVURi4NCj4gPg0KPiA+ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBUQ1Ag RW5jYXBzdWxhdGlvbiBvZiBJS0UgYW5kIElQc2VjIFBhY2tldHMNCj4gPiAgICAgICAgQXV0aG9y cyAgICAgICAgIDogVG9tbXkgUGF1bHkNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgU2Ft eSBUb3VhdGkNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgUmF2aSBNYW50aGENCj4gPiAJ RmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1pcHNlY21lLXRjcC1lbmNhcHMtMDMudHh0DQo+ ID4gCVBhZ2VzICAgICAgICAgICA6IDIwDQo+ID4gCURhdGUgICAgICAgICAgICA6IDIwMTYtMTAt MzENCj4gPg0KPiA+IEFic3RyYWN0Og0KPiA+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBt ZXRob2QgdG8gdHJhbnNwb3J0IElLRSBhbmQgSVBzZWMgcGFja2V0cw0KPiA+ICAgb3ZlciBhIFRD UCBjb25uZWN0aW9uIGZvciB0cmF2ZXJzaW5nIG5ldHdvcmsgbWlkZGxlYm94ZXMgdGhhdCBtYXkN Cj4gPiAgIGJsb2NrIElLRSBuZWdvdGlhdGlvbiBvdmVyIFVEUC4gIFRoaXMgbWV0aG9kLCByZWZl cnJlZCB0byBhcyBUQ1ANCj4gPiAgIGVuY2Fwc3VsYXRpb24sIGludm9sdmVzIHNlbmRpbmcgYm90 aCBJS0UgcGFja2V0cyBmb3IgdHVubmVsDQo+ID4gICBlc3RhYmxpc2htZW50IGFzIHdlbGwgYXMg dHVubmVsZWQgcGFja2V0cyB1c2luZyBFU1Agb3ZlciBhIFRDUA0KPiA+ICAgY29ubmVjdGlvbi4g IFRoaXMgbWV0aG9kIGlzIGludGVuZGVkIHRvIGJlIHVzZWQgYXMgYSBmYWxsYmFjayBvcHRpb24N Cj4gPiAgIHdoZW4gSUtFIGNhbm5vdCBiZSBuZWdvdGlhdGVkIG92ZXIgVURQLg0KPiA+DQo+ID4N Cj4gPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoN Cj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlwc2VjbWUt dGNwLWVuY2Fwcy8NCj4gPg0KPiA+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZh aWxhYmxlIGF0Og0KPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlw c2VjbWUtdGNwLWVuY2Fwcy0wMw0KPiA+DQo+ID4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZl cnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1pZXRmLWlwc2VjbWUtdGNwLWVuY2Fwcy0wMw0KPiA+DQo+ID4NCj4gPiBQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZg0KPiA+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gPg0KPiA+IEludGVybmV0LURyYWZ0 cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPiBmdHA6Ly9mdHAu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBJUHNlYyBtYWlsaW5nIGxpc3QNCj4gPiBJ UHNlY0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aXBzZWMNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IElQc2VjIG1haWxpbmcgbGlzdA0KPiBJUHNlY0BpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjDQo= From nobody Mon Nov 14 06:07:20 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0987F12967A for ; Mon, 14 Nov 2016 06:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.017 X-Spam-Level: X-Spam-Status: No, score=-16.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 tWO-KPkjqpHC for ; Mon, 14 Nov 2016 06:07:16 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8053F1293EC for ; Mon, 14 Nov 2016 06:07:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33592; q=dns/txt; s=iport; t=1479132436; x=1480342036; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=7n8klBPCw2ppNBhwbLrUcL4ZjO6maJLS8lQXVET+3Gg=; b=ddj9Ko4lQxa8IVouXIax10/W1aLmcYLUqI3l9fml3LQpxdB9moxJsnEC yl1JtcNFTu73Z6YqkJPbTcpyparJP9r+Zkx40jbm4vY4mrUtkOWCDFP3R fUdxfPtEDjZxq7ac55wMgHouerxUuDboIPpoY0yqQeHh4uA+52qOImIy3 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DgAwAgxClY/4YNJK1VCRoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJzPgEBAQEBH1iBAAekQIdsjHSCBx0BCoV7AhqBf0ATAQIBAQEBAQE?= =?us-ascii?q?BYiiEYQEBAQQBAQEgCkEbAgEGAg4CAQQBASEHAwICAh8GCxQIAQgCBAESCBOIL?= =?us-ascii?q?AMXDpFMnUWCKYcrDYQQAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGPIRagkiBWV2?= =?us-ascii?q?CToJdBYk0iyWFMzUBjRmDPIF2jjGHP4FehCeECQEfATWBAxyDIRyBXXKGcIEMA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.31,638,1473120000"; d="scan'208,217";a="170081210" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Nov 2016 14:07:15 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id uAEE7EuW000478 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Nov 2016 14:07:15 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 14 Nov 2016 09:07:14 -0500 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Mon, 14 Nov 2016 09:07:13 -0500 From: "Scott Fluhrer (sfluhrer)" To: Valery Smyslov , "IPsecme WG (ipsec@ietf.org)" Thread-Topic: [IPsec] FW: Quantum Resistance Requirements Thread-Index: AdH0G8ijQKeg6MaXRiG9vXmtSf0/rwUZFu7ACMepu6AAD1cOEAFR877AA177fAAACCNGQA== Date: Mon, 14 Nov 2016 14:07:13 +0000 Message-ID: <970eaf58d0b94a7ba3082ddc8b276462@XCH-RTP-006.cisco.com> References: <6c1585204f6a4598b6e40b05912ba4c4@XCH-RTP-006.cisco.com> <5829b397.01d6620a.9dfb5.4373@mx.google.com> In-Reply-To: <5829b397.01d6620a.9dfb5.4373@mx.google.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.98.2.54] Content-Type: multipart/alternative; boundary="_000_970eaf58d0b94a7ba3082ddc8b276462XCHRTP006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] FW: Quantum Resistance Requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 14:07:19 -0000 --_000_970eaf58d0b94a7ba3082ddc8b276462XCHRTP006ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8sIHdlIGRpZG7igJl0IGNvbnNpZGVyIG1vZGlmeWluZyB0aGluZ3MgdGhlcmUuDQoNClRoZSBt YWluIHJlYXNvbiB3ZSB3b3VsZG7igJl0IGhhdmUgY29uc2lkZXJlZCB0aGF0IGlzIGEgcG9zc2li bGUgY29tcGxpY2F0aW9uIHRvIGNyeXB0byBoYXJkd2FyZTsgaWYgd2UgYXNzdW1lIHRoYXQgd2Ug aGFkIGhhcmR3YXJlIHRoYXQgZGlkIG1vc3Qgb2YgdGhlIGNyeXB0byBjYWxjdWxhdGlvbnMgaW50 ZXJuYWxseSwgaXQgbWlnaHQga2VlcCB0aGUgU0tfZCB2YWx1ZSBpbnRlcm5hbGx5LCBhbmQgbWln aHQgbm90IGdpdmUgdXMgYW4gZWFzeSB3YXkgdG8gbW9kaWZ5IGl0LiAgSW4gY29udHJhc3QsIHRo ZSBub25jZXMgYXJlIGlucHV0cyB0byB0aGUgaGFyZHdhcmUsIGFuZCBzbyB0aGF0IGhhcmR3YXJl IGlzIGFnbm9zdGljIHRvIHdoZXRoZXIgd2XigJlyZSBhY3R1YWxseSBnaXZpbmcgaXQgdGhlIG5v bmNlcyB0aGF0IGFjdHVhbGx5IGFwcGVhcmVkIGluIHRoZSBwYWNrZXRzLCBvciB3aGV0aGVyIHdl 4oCZcmUgZ2l2aW5nIHRoZW0gbW9kaWZpZWQgdmVyc2lvbnMgb2YgaXQuDQoNCkkgZG9u4oCZdCBl eHBlY3QgdGhlcmUgdG8gYmUgYW55IHNlY3VyaXR5IGRpc2FkdmFudGFnZTsgdGhlIGRpZmZlcmVu Y2VzIHdvdWxkIGJlIGVudGlyZWx5IHByYWN0aWNhbC4NCg0KRnJvbTogVmFsZXJ5IFNteXNsb3Yg W21haWx0bzpzdmFucnVAZ21haWwuY29tXQ0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxNCwgMjAx NiA3OjUzIEFNDQpUbzogU2NvdHQgRmx1aHJlciAoc2ZsdWhyZXIpOyBJUHNlY21lIFdHIChpcHNl Y0BpZXRmLm9yZykNClN1YmplY3Q6IFJFOiBbSVBzZWNdIEZXOiBRdWFudHVtIFJlc2lzdGFuY2Ug UmVxdWlyZW1lbnRzDQoNCkhpIFNjb3R0LA0KDQphZnRlciByZWFkaW5nIHRoZSBkcmFmdCBJIGhh dmUgb25lIHF1ZXN0aW9uLiBUaGUgZHJhZnQgcmVkZWZpbmVzIGJvdGgNCktFWU1BVCBhbmQgU0tF WVNFRUQgZm9yIElLRSBTQSByZWtleSBkZXJpdmF0aW9ucyBmb3IgdGhlIGNhc2UNCndoZW4gUFBL IGlzIHVzZWQuIERpZCB5b3UgY29uc2lkZXIgdmFyaWFudCB3aGVuIG9ubHkgU0tfZCBkZXJpdmF0 aW9uDQppcyBtb2RpZmllZD8gU29tZXRoaW5nIGxpa2UgdGhpczoNCg0KTm8gbW9kaWZpY2F0aW9u IHRvIFNLXyogY2FsY3VsYXRpb24sIFNLRVlTRUVEIGNhbGN1bGF0aW9uIGFuZCBLRVlNQVQgY2Fs Y3VsYXRpb24uDQpIb3dldmVyLCBmb3IgdGhlIFBQSyB1c2UgY2FzZSBkZWZpbmUgU0tfZGAsIHRo YXQgbXVzdCBiZSB1c2VkIGluc3RlYWQgb2YgU0tfZCwNCnNvIHRoYXQgU0tfZOKAmSA9IHByZiso U0tfZCwgTmnigJkgfCBOcuKAmSksIHdoZXJlIE5p4oCZID0gcHJmKFBQSywgTmkpLCBOcuKAmSA9 IHByZihQUEssIE5yKS4NCg0KVGhpcyBpcyBhbiBhZCBob2MgY29uc3RydWN0aW9uLCBwcm9iYWJs eSBpdCBjYW4gYmUgaW1wcm92ZWQsIGJ1dCB0aGUgaWRlYSBpcyBjbGVhcjoNCkludHJvZHVjZSBh IHNpbmdsZSBwb2ludCAoU0tfZOKAmSBkZXJpdmF0aW9uKSB3aGVyZSBtb2RpZmljYXRpb25zIHRv IGtleXMgZGVyaXZhdGlvbiBhbGdvcml0aG0NCnRha2UgcGxhY2UsIGluc3RlYWQgb2YgdHdvIHBv aW50cy4gSXQgd2lsbCBtYWtlIGltcGxlbWVudGF0aW9ucyBtb2RpZmljYXRpb24gZWFzaWVyLCBJ IHRoaW5rLg0KDQpTbywgZGlkIHlvdSBjb25zaWRlciBzdWNoIHZhcmlhbnQ/IEFyZSB0aGVyZSBh bnkgc2VjdXJpdHkgZGlzYWR2YW50YWdlcz8NCg0KUmVnYXJkcywNClZhbGVyeSBTbXlzbG92Lg0K DQpGcm9tOiBTY290dCBGbHVocmVyIChzZmx1aHJlcik8bWFpbHRvOnNmbHVocmVyQGNpc2NvLmNv bT4NClNlbnQ6IDI4INC+0LrRgtGP0LHRgNGPIDIwMTYg0LMuIDIzOjI1DQpUbzogSVBzZWNtZSBX RyAoaXBzZWNAaWV0Zi5vcmcpPG1haWx0bzppcHNlY0BpZXRmLm9yZz4NClN1YmplY3Q6IFtJUHNl Y10gRlc6IFF1YW50dW0gUmVzaXN0YW5jZSBSZXF1aXJlbWVudHMNCg0KSGVyZSBpcyBhbiB1cGRh dGUgb24gdGhlIHZvdGluZyBmb3IgdGhlIGxpc3Qgb2YgcG90ZW50aWFsIHJlcXVpcmVtZW50cyBm b3IgYSBzaG9ydCB0ZXJtIFF1YW50dW0gUmVzaXN0YW5jZSBzb2x1dGlvbjsgYW5kIGEgc3VtbWFy eSBvZiB0aGUgcmVjZW50IHVwZGF0ZSB0byBvdXIgZHJhZnQgKHdoaWNoIHJlZmxlY3RzIHRoZSBz dGF0ZWQgcmVxdWlyZW1lbnRzKQ0KDQpUaGUgdm90ZXMgc28gZmFyIChvbWl0dGluZyB0aGUgIm5v IG9waW5pb24iIHZvdGVzKTsgSSd2ZSBsaXN0ZWQgdGhlIHZvdGVycyBjaGllZmx5IHNvIHRoYXQg aWYgSSBtaXNjaGFyYWN0ZXJpemVkIHRoZWlyIHZvdGVzLCB0aGV5IGNhbiBjb3JyZWN0IG1lLg0K DQoNCi0gU2ltcGxpY2l0eTsgaG93IGxhcmdlIG9mIGEgY2hhbmdlIHRvIElLRSAoYW5kIElLRSBp bXBsZW1lbnRhdGlvbnMpIGFyZSB3ZSB3aWxsaW5nIHRvIGNvbnRlbXBsYXRlPw0KU2NvdHQgRmx1 aHJlcjogdmVyeSBpbXBvcnRhbnQNCk1pY2hhZWwgUmljaGFyZHNvbjogdmVyeSBpbXBvcnRhbnQN ClRvbW15IFBhdWx5OiB2ZXJ5IGltcG9ydGFudA0KVmFsZXJ5IFNteXNsb3Y6IG5vdCBhcyBpbXBv cnRhbnQgYXMgb3RoZXIgaXNzdWVzDQpPc2NhciBHYXJjaWEtTW9yY2hvbjogdmVyeSBpbXBvcnRh bnQuDQoNCg0KLSBQcmVzZXJ2aW5nIGV4aXN0aW5nIElLRSBzZWN1cml0eSBwcm9wZXJ0aWVzPw0K U2NvdHQgRmx1aHJlcjogdmVyeSBpbXBvcnRhbnQNCk1pY2hhZWwgUmljaGFyZHNvbjogdmVyeSBp bXBvcnRhbnQNClRvbW15IFBhdWx5OiB2ZXJ5IGltcG9ydGFudA0KVmFsZXJ5IFNteXNsb3Y6IGlt cG9ydGFudA0KT3NjYXIgR2FyY2lhLU1vcmNob246IHZlcnkgaW1wb3J0YW50Lg0KDQoNCi0gV2hh dCBkbyB3ZSBmZWVsIG5lZWRzIHRvIHByb3RlY3RlZCBmcm9tIHNvbWVvbmUgd2l0aCBhIFF1YW50 dW0gQ29tcHV0ZXI/ICBEbyB3ZSBmZWVsICB0aGUgbmVlZCB0byBwcm90ZWN0IG9ubHkgdGhlIElQ c2VjIHRyYWZmaWMsIG9yIGRvIHdlIG5lZWQgdG8gcHJvdGVjdCB0aGUgSUtFIHRyYWZmaWMgYXMg d2VsbC4NClRvbW15IFBhdWx5OiBub3QgY2xlYXIgaWYgSUtFIHRyYWZmaWMgbmVlZHMgdG8gYmUg cHJvdGVjdGVkLg0KVmFsZXJ5IFNteWxzb3Y6IGltcG9ydGFudA0KT3NjYXIgR2FyY2lhLU1vcmNo b246IElQc2VjIHRyYWZmaWMgbXVzdCBiZSBwcm90ZWN0ZWQsIElLRSB0cmFmZmljIHdvdWxkIGJl IGEgbmljZS10by1oYXZlLg0KDQoNCg0KLSBXaGF0IGxldmVsIG9mIGlkZW50aXR5IHByb3RlY3Rp b24gZG8gd2UgbmVlZCB0byBwcm92aWRlPyAgSWYgdHdvIGRpZmZlcmVudCBJS0UgbmVnb3RpYXRp b25zIHVzZSB0aGUgc2FtZSBzaGFyZWQgc2VjcmV0LCBkbyB3ZSBtaW5kIGlmIHNvbWVvbmUgY2Fu IGRlZHVjZSB0aGF0Pw0KU2NvdHQgRmx1aHJlcjogbm90IGltcG9ydGFudA0KTWljaGFlbCBSaWNo YXJkc29uOiB2ZXJ5IGltcG9ydGFudA0KVG9tbXkgUGF1bHk6IG5vdCBpbXBvcnRhbnQNClZhbGVy eSBTbXlsc292OiB0aGlzIGlzIGEgbmljZSB0byBoYXZlLCBidXQgbm90IGNyaXRpY2FsDQpPc2Nh ciBHYXJjaWEtTW9yY2hvbjogdGhpcyBpcyBsZXNzIGltcG9ydGFudA0KUnVzcyBIb3VzZWxleTog dGhpcyBpcyBhIG5pY2UgdG8gaGF2ZSwgYnV0IG9ubHkgaWYgaXQgaXMgY2hlYXANCg0KDQotICBQ UEsgbWFuYWdlbWVudDsgaG93IG11Y2ggc3VwcG9ydCBkbyB3ZSBwcm92aWRlIGZvciBhdXRvbWF0 aWNhbGx5IG1hbmFnaW5nIHRoZSBzZWNyZXRzPw0KU2NvdHQgRmx1aHJlcjogbm90IGltcG9ydGFu dA0KVG9tbXkgUGF1bHk6IG5vdCBpbXBvcnRhbnQNCk9zY2FyIEdhcmNpYS1Nb3JjaG9uOiBub3Qg aW1wb3J0YW50DQoNCg0KLSBIb3cgbXVjaCBzdXBwb3J0IGRvIHdlIHByb3ZpZGUgZm9yIG5vbnN0 YXRpYyBzZWNyZXRzLCBmb3IgZXhhbXBsZSwgYnkgUUtELCBvciB2aWEgc29tZXRoaW5nIGxpa2Ug SElNTU8gKGEga2V5IGRpc3RyaWJ1dGlvbiBtZWNoYW5pc20gdGhhdCBhcHBlYXJzIHRvIGJlIHBv c3QgcXVhbnR1bSk/DQpTY290dCBGbHVocmVyOiBub3QgaW1wb3J0YW50DQpNaWNoYWVsIFJpY2hh cmRzb246IG5vdCBpbXBvcnRhbnQNClRvbW15IFBhdWx5OiBub3QgaW1wb3J0YW50DQpPc2NhciBH YXJjaWEtTW9yY2hvbjogbm90IGltcG9ydGFudCBub3csIGJ1dCB3aWxsIGJlY29tZSBpbXBvcnRh bnQgaW4gdGhlIGZ1dHVyZQ0KDQoNCi0gQXV0aGVudGljYXRpb247IGlmIHNvbWVvbmUgd2l0aCBh IFF1YW50dW0gQ29tcHV0ZXIgY2FuIGJyZWFrIHRoZSBESCBpbiByZWFsIHRpbWUsIGRvIHdlIGNh cmUgaWYgaGUgY2FuIGFjdCBhcyBhIG1hbi1pbi10aGUtbWlkZGxlPw0KU2NvdHQgRmx1aHJlcjog bm90IGltcG9ydGFudA0KTWljaGFlbCBSaWNoYXJkc29uOiBpbXBvcnRhbnQsIHByb3ZpZGVkIHRo YXQgd2UgZG9uJ3QgcnVuIGludG8gdGhlIHNhbWUgaXNzdWVzIHRoYXQgSUtFdjEgUFNLcyByYW4g aW50bw0KVG9tbXkgUGF1bHk6IG5vdCBpbXBvcnRhbnQNClZhbGVyeSBTbXlsc292OiB0aGlzIHdv dWxkIGJlIG5pY2UgdG8gaGF2ZQ0KT3NjYXIgR2FyY2lhLU1vcmNob246IHRoaXMgd291bGQgYmUg bmljZSB0byBoYXZlDQoNCg0KLSBBbGdvcml0aG0gYWdpbGl0eTsgaG93IGltcG9ydGFudCBpcyBp dCB0aGF0IHdlIG5lZ290aWF0ZSBhbnkgY3J5cHRvcHJpbWl0aXZlcyBpbnZvbHZlZD8NClNjb3R0 IEZsdWhyZXI6IG5vdCBpbXBvcnRhbnQNClRvbW15IFBhdWx5OiBub3QgaW1wb3J0YW50DQpWYWxl cnkgU215bHNvdjogaW1wb3J0YW50DQpPc2NhciBHYXJjaWEtTW9yY2hvbjogbGVzcyBpbXBvcnRh bnQuDQoNCk15IHRlbnRhdGl2ZSBzdW1tYXJ5IG9mIHRoZSB2b3RlczoNCg0KLSBTaW1wbGljaXR5 IGFuZCBwcmVzZXJ2aW5nIGV4aXN0aW5nIHNlY3VyaXR5IHByb3BlcnRpZXMgYXJlIHRoZSBtb3N0 IGltcG9ydGFudA0KLSBQcm90ZWN0aW5nIElLRSB0cmFmZmljIHdhcyBjb25zaWRlcmVkIGxlc3Mg aW1wb3J0YW50Lg0KDQoNCg0KV2UgaGF2ZSB1cGRhdGVkIG91ciBkcmFmdCB0byByZWZsZWN0IHRo ZXNlIHJlcXVpcmVtZW50czsgaXQgaXMgbXVjaCBzaW1wbGVyIHRoYW4gdGhlIHByZXZpb3VzIGRy YWZ0LCBidXQgZG9lcyBub3QgcHJvdmlkZSBhbm9ueW1pdHkuICBJdCBpcyBiYXNlZCBvbiBhIHN1 Z2dlc3Rpb24gYnkgVGVybyAod2hpY2ggd2FzIHRvIGRvIHRoZSBpbml0aWFsIElLRSBTQSBlc3Rh Ymxpc2htZW50IGFzIG5vcm1hbCwgYW5kIHRoZW4gc3RpciBpbiB0aGUgUFBLIGludG8gdGhlIElQ c2VjIEtFWU1BVCBnZW5lcmF0aW9uIHByb2Nlc3MpOyB0aGlzIG1ha2VzIGl0IG11Y2ggc2ltcGxl ciB0aGFuIHRyeWluZyB0byBleGNoYW5nZSBpZGVudGl0aWVzIGJlZm9yZSBkb2luZyB0aGUgaW5p dGlhbCBrZXkgZGVyaXZhdGlvbi4gIFdlIGRpZCBhZGQgYSBtb2RpZmljYXRpb24gdG8gaG93IHRo ZSBjaGlsZCBTQSBTS0VZU0VFRCB3YXMgY29tcHV0ZWQgKGJ5IHN0aXJyaW5nIGluIHRoZSBQUEsg dGhlcmUgYXMgd2VsbCk7IHRoZSBhZHZhbnRhZ2Ugb2YgdGhpcyBpcyB0aGF0IHRoaXMgbWVhbnMg dGhhdCBhbnkgY2hpbGQgSUtFIFNBcyB3ZXJlIGFsc28gcXVhbnR1bSByZXNpc3RhbnQuICBUaGlz IGltcGxpZXMgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiB0aGF0IGRpZCBpbnNpc3Qgb24gcHJvdGVj dGluZyB0aGUgSUtFIHRyYWZmaWMgY291bGQgaW1tZWRpYXRlbHkgZ2VuZXJhdGUgYSBjaGlsZCBT QSBhZnRlciBuZWdvdGlhdGlvbiwgYW5kIHRoZW4gdXNlIHRoYXQgY2hpbGQgU0EgdG8gZG8gYWxs IHRoZSByZWFsIG5lZ290aWF0aW9uLiAgV2UgdGhvdWdodCB0aGF0IHRoaXMgZmxleGliaWxpdHkg anVzdGlmaWVkIHRoZSBleHRyYSBjb21wbGljYXRpb24gb2YgbW9kaWZ5aW5nIHRoZSBTS0VZU0VF RCBjb21wdXRhdGlvbi4gIFN1Y2ggYW4gaW1wbGVtZW50YXRpb24gd291bGQgbGVhayB0aGUgaWRl bnRpdGllcyB0byBhIFF1YW50dW0gYWR2ZXJzYXJ5LCBidXQgZXZlcnl0aGluZyBlbHNlIHdvdWxk IGJlIHByb3RlY3RlZC4NCg0KSGVyZSBpcyBob3cgdGhlIGRyYWZ0IHNjb3JlcyBhZ2FpbnN0IHRo ZSBnaXZlbiBjcml0ZXJpYToNCg0KLSBTaW1wbGljaXR5OyBpdCBpcyBmYWlybHkgc2ltcGxlDQot IFByZXNlcnZpbmcgZXhpc3RpbmcgSUtFIHNlY3VyaXR5IHByb3BlcnRpZXM/ICBJdCBwcmVzZXJ2 ZXMgYWxsIElLRSBzZWN1cml0eSBwcm9wZXJ0aWVzIGFnYWluc3QgYW4gYWR2ZXJzYXJ5IHdpdGgg YSBjb252ZW50aW9uYWwgY29tcHV0ZXINCi0gV2hhdCBpcyBwcm90ZWN0ZWQgZnJvbSBzb21lb25l IHdpdGggYSBRdWFudHVtIENvbXB1dGVyPyAgSXQgcHJvdGVjdHMgdGhlIElQc2VjIHRyYWZmaWM7 IGl0IGFsc28gYWxsb3dzIGFuIGltcGxlbWVudGF0aW9uICh3aXRoIG1vcmUgZXhjaGFuZ2VzKSB0 byBwcm90ZWN0IHRoZSBJS0UgdHJhZmZpYyAoYXBhcnQgZnJvbSB0aGUgaWRlbnRpdGllcykNCi0g V2hhdCBsZXZlbCBvZiBpZGVudGl0eSBwcm90ZWN0aW9uIGRvIHdlIG5lZWQgdG8gcHJvdmlkZT8g IFRoaXMgZG9lc24ndCBwcm92aWRlIGFueSBpZGVudGl0eSBwcm90ZWN0aW9uIGFnYWluc3Qgc29t ZW9uZSB3aXRoIGEgUXVhbnR1bSBDb21wdXRlcg0KLSAgUFBLIG1hbmFnZW1lbnQ7IG5vdCBhZGRy ZXNzZWQNCi0gSG93IG11Y2ggc3VwcG9ydCBkbyB3ZSBwcm92aWRlIGZvciBub25zdGF0aWMgc2Vj cmV0cz8gIE5vdCBhZGRyZXNzZWQsIGhvd2V2ZXIgaXQgd291bGQgbm90IGJlIGRpZmZpY3VsdCB0 byBhZGQgaW4gdGhlIGZ1dHVyZS4NCi0gQXV0aGVudGljYXRpb247IGNhbiBhbiBhdHRhY2tlciB3 aXRoIFF1YW50dW0gQ29tcHV0ZXIgYWN0IGFzIGEgbWFuLWluLXRoZS1taWRkbGU/ICBObywgbm90 IGlmIGJvdGggc2lkZXMgaGF2ZSBQUEsgbWFuZGF0b3J5DQotIEFsZ29yaXRobSBhZ2lsaXR5OyB5 ZXMsIHRoZSBvbmx5IGFsZ29yaXRobXMgdXNlZCBhcmUgdGhlIG9uZXMgbmVnb3RpYXRlZA0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSVBzZWMgbWFp bGluZyBsaXN0DQpJUHNlY0BpZXRmLm9yZzxtYWlsdG86SVBzZWNAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjDQoNCg== --_000_970eaf58d0b94a7ba3082ddc8b276462XCHRTP006ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0 ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24g VGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjo1Ni43cHQg NDIuNXB0IDU2LjdwdCA4NS4wNXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Y29sb3I6YmxhY2siPk5vLCB3ZSBkaWRu4oCZdCBjb25zaWRlciBtb2RpZnlpbmcgdGhpbmdzIHRo ZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNv bG9yOmJsYWNrIj5UaGUgbWFpbiByZWFzb24gd2Ugd291bGRu4oCZdCBoYXZlIGNvbnNpZGVyZWQg dGhhdCBpcyBhIHBvc3NpYmxlIGNvbXBsaWNhdGlvbiB0byBjcnlwdG8gaGFyZHdhcmU7IGlmIHdl IGFzc3VtZSB0aGF0IHdlIGhhZCBoYXJkd2FyZSB0aGF0IGRpZCBtb3N0IG9mIHRoZSBjcnlwdG8g Y2FsY3VsYXRpb25zIGludGVybmFsbHksIGl0IG1pZ2h0IGtlZXANCiB0aGUgU0tfZCB2YWx1ZSBp bnRlcm5hbGx5LCBhbmQgbWlnaHQgbm90IGdpdmUgdXMgYW4gZWFzeSB3YXkgdG8gbW9kaWZ5IGl0 LiZuYnNwOyBJbiBjb250cmFzdCwgdGhlIG5vbmNlcyBhcmUgaW5wdXRzIHRvIHRoZSBoYXJkd2Fy ZSwgYW5kIHNvIHRoYXQgaGFyZHdhcmUgaXMgYWdub3N0aWMgdG8gd2hldGhlciB3ZeKAmXJlIGFj dHVhbGx5IGdpdmluZyBpdCB0aGUgbm9uY2VzIHRoYXQgYWN0dWFsbHkgYXBwZWFyZWQgaW4gdGhl IHBhY2tldHMsIG9yIHdoZXRoZXINCiB3ZeKAmXJlIGdpdmluZyB0aGVtIG1vZGlmaWVkIHZlcnNp b25zIG9mIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Y29sb3I6YmxhY2siPkkgZG9u4oCZdCBleHBlY3QgdGhlcmUgdG8gYmUgYW55IHNlY3VyaXR5IGRp c2FkdmFudGFnZTsgdGhlIGRpZmZlcmVuY2VzIHdvdWxkIGJlIGVudGlyZWx5IHByYWN0aWNhbC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVmFsZXJ5IFNteXNsb3YgW21haWx0bzpzdmFu cnVAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTm92ZW1iZXIgMTQsIDIw MTYgNzo1MyBBTTxicj4NCjxiPlRvOjwvYj4gU2NvdHQgRmx1aHJlciAoc2ZsdWhyZXIpOyBJUHNl Y21lIFdHIChpcHNlY0BpZXRmLm9yZyk8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtJUHNlY10g Rlc6IFF1YW50dW0gUmVzaXN0YW5jZSBSZXF1aXJlbWVudHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBTY290dCw8c3BhbiBsYW5nPSJSVSI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFmdGVyIHJl YWRpbmcgdGhlIGRyYWZ0IEkgaGF2ZSBvbmUgcXVlc3Rpb24uIFRoZSBkcmFmdCByZWRlZmluZXMg Ym90aDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S0VZTUFUIGFuZCBTS0VZ U0VFRCBmb3IgSUtFIFNBIHJla2V5IGRlcml2YXRpb25zIGZvciB0aGUgY2FzZTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2hlbiBQUEsgaXMgdXNlZC4gRGlkIHlvdSBjb25z aWRlciB2YXJpYW50IHdoZW4gb25seSBTS19kIGRlcml2YXRpb248bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmlzIG1vZGlmaWVkPyBTb21ldGhpbmcgbGlrZSB0aGlzOjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5ObyBtb2RpZmljYXRpb24gdG8gU0tfKiBjYWxjdWxhdGlvbiwg U0tFWVNFRUQgY2FsY3VsYXRpb24gYW5kIEtFWU1BVCBjYWxjdWxhdGlvbi48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIsIGZvciB0aGUgUFBLIHVzZSBjYXNlIGRl ZmluZSBTS19kYCwgdGhhdCBtdXN0IGJlIHVzZWQgaW5zdGVhZCBvZiBTS19kLDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c28gdGhhdCBTS19k4oCZID0gcHJmJiM0MzsoU0tf ZCwgTmnigJkgfCBOcuKAmSksIHdoZXJlIE5p4oCZID0gPHNwYW4gbGFuZz0iUlUiPg0KcHJmKFBQ SywgTmkpPC9zcGFuPiwgTnLigJkgPSA8c3BhbiBsYW5nPSJSVSI+cHJmKFBQSywgTjwvc3Bhbj5y PHNwYW4gbGFuZz0iUlUiPik8L3NwYW4+LjxzcGFuIGxhbmc9IlJVIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBhbiBhZCBob2Mg Y29uc3RydWN0aW9uLCBwcm9iYWJseSBpdCBjYW4gYmUgaW1wcm92ZWQsIGJ1dCB0aGUgaWRlYSBp cyBjbGVhcjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkludHJvZHVjZSBh IHNpbmdsZSBwb2ludCAoU0tfZOKAmSBkZXJpdmF0aW9uKSB3aGVyZSBtb2RpZmljYXRpb25zIHRv IGtleXMgZGVyaXZhdGlvbiBhbGdvcml0aG08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPnRha2UgcGxhY2UsIGluc3RlYWQgb2YgdHdvIHBvaW50cy4gSXQgd2lsbCBtYWtlIGlt cGxlbWVudGF0aW9ucyBtb2RpZmljYXRpb24gZWFzaWVyLCBJIHRoaW5rLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5TbywgZGlkIHlvdSBjb25zaWRlciBzdWNoIHZhcmlhbnQ/IEFyZSB0aGVyZSBh bnkgc2VjdXJpdHkgZGlzYWR2YW50YWdlcz88c3BhbiBsYW5nPSJSVSI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPHNwYW4gbGFu Zz0iUlUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlZhbGVy eSBTbXlzbG92LjxzcGFuIGxhbmc9IlJVIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJSVSI+RnJvbTogPC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJSVSI+PGEgaHJlZj0ibWFpbHRvOnNmbHVocmVyQGNpc2NvLmNvbSI+U2NvdHQg Rmx1aHJlciAoc2ZsdWhyZXIpPC9hPjxicj4NCjxiPlNlbnQ6IDwvYj4yOCDQvtC60YLRj9Cx0YDR jyAyMDE2INCzLiAyMzoyNTxicj4NCjxiPlRvOiA8L2I+PGEgaHJlZj0ibWFpbHRvOmlwc2VjQGll dGYub3JnIj5JUHNlY21lIFdHIChpcHNlY0BpZXRmLm9yZyk8L2E+PGJyPg0KPGI+U3ViamVjdDog PC9iPltJUHNlY10gRlc6IFF1YW50dW0gUmVzaXN0YW5jZSBSZXF1aXJlbWVudHM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJV IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj5IZXJlIGlzIGFuIHVwZGF0ZSBv biB0aGUgdm90aW5nIGZvciB0aGUgbGlzdCBvZiBwb3RlbnRpYWwgcmVxdWlyZW1lbnRzIGZvciBh IHNob3J0IHRlcm0gUXVhbnR1bSBSZXNpc3RhbmNlIHNvbHV0aW9uOyBhbmQgYSBzdW1tYXJ5IG9m IHRoZSByZWNlbnQgdXBkYXRlIHRvIG91ciBkcmFmdCAod2hpY2ggcmVmbGVjdHMgdGhlIHN0YXRl ZCByZXF1aXJlbWVudHMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iUlUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj5UaGUgdm90ZXMgc28gZmFyIChvbWl0dGluZyB0 aGUgJnF1b3Q7bm8gb3BpbmlvbiZxdW90OyB2b3Rlcyk7IEkndmUgbGlzdGVkIHRoZSB2b3RlcnMg Y2hpZWZseSBzbyB0aGF0IGlmIEkgbWlzY2hhcmFjdGVyaXplZCB0aGVpciB2b3RlcywgdGhleSBj YW4gY29ycmVjdCBtZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJSVSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj4tIFNpbXBsaWNpdHk7IGhvdyBs YXJnZSBvZiBhIGNoYW5nZSB0byBJS0UgKGFuZCBJS0UgaW1wbGVtZW50YXRpb25zKSBhcmUgd2Ug d2lsbGluZyB0byBjb250ZW1wbGF0ZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+U2NvdHQgRmx1aHJlcjogdmVyeSBpbXBvcnRhbnQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJS VSI+TWljaGFlbCBSaWNoYXJkc29uOiB2ZXJ5IGltcG9ydGFudDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj5Ub21teSBQYXVseTogdmVy eSBpbXBvcnRhbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJSVSI+VmFsZXJ5IFNteXNsb3Y6IG5vdCBhcyBpbXBvcnRhbnQgYXMgb3RoZXIg aXNzdWVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iUlUiPk9zY2FyIEdhcmNpYS1Nb3JjaG9uOiB2ZXJ5IGltcG9ydGFudC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i UlUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IlJVIj4tIFByZXNlcnZpbmcgZXhpc3RpbmcgSUtFIHNlY3VyaXR5IHByb3BlcnRp ZXM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iUlUiPlNjb3R0IEZsdWhyZXI6IHZlcnkgaW1wb3J0YW50PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPk1pY2hhZWwgUmljaGFyZHNv bjogdmVyeSBpbXBvcnRhbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJSVSI+VG9tbXkgUGF1bHk6IHZlcnkgaW1wb3J0YW50PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPlZhbGVy eSBTbXlzbG92OiBpbXBvcnRhbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+T3NjYXIgR2FyY2lhLU1vcmNob246IHZlcnkgaW1wb3J0 YW50LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJSVSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iUlUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj4tIFdoYXQgZG8gd2UgZmVlbCBuZWVkcyB0byBw cm90ZWN0ZWQgZnJvbSBzb21lb25lIHdpdGggYSBRdWFudHVtIENvbXB1dGVyPyAmbmJzcDtEbyB3 ZSBmZWVsICZuYnNwO3RoZSBuZWVkIHRvIHByb3RlY3Qgb25seSB0aGUgSVBzZWMgdHJhZmZpYywg b3IgZG8gd2UgbmVlZCB0byBwcm90ZWN0IHRoZSBJS0UgdHJhZmZpYyBhcyB3ZWxsLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj5Ub21t eSBQYXVseTogbm90IGNsZWFyIGlmIElLRSB0cmFmZmljIG5lZWRzIHRvIGJlIHByb3RlY3RlZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJS VSI+VmFsZXJ5IFNteWxzb3Y6IGltcG9ydGFudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj5Pc2NhciBHYXJjaWEtTW9yY2hvbjogSVBz ZWMgdHJhZmZpYyBtdXN0IGJlIHByb3RlY3RlZCwgSUtFIHRyYWZmaWMgd291bGQgYmUgYSBuaWNl LXRvLWhhdmUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJSVSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+LSBXaGF0IGxldmVs IG9mIGlkZW50aXR5IHByb3RlY3Rpb24gZG8gd2UgbmVlZCB0byBwcm92aWRlPyZuYnNwOyBJZiB0 d28gZGlmZmVyZW50IElLRSBuZWdvdGlhdGlvbnMgdXNlIHRoZSBzYW1lIHNoYXJlZCBzZWNyZXQs IGRvIHdlIG1pbmQgaWYgc29tZW9uZSBjYW4gZGVkdWNlIHRoYXQ/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPlNjb3R0IEZsdWhyZXI6 IG5vdCBpbXBvcnRhbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJSVSI+TWljaGFlbCBSaWNoYXJkc29uOiB2ZXJ5IGltcG9ydGFudDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj5U b21teSBQYXVseTogbm90IGltcG9ydGFudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj5WYWxlcnkgU215bHNvdjogdGhpcyBpcyBhIG5p Y2UgdG8gaGF2ZSwgYnV0IG5vdCBjcml0aWNhbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj5Pc2NhciBHYXJjaWEtTW9yY2hvbjogdGhp cyBpcyBsZXNzIGltcG9ydGFudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IlJVIj5SdXNzIEhvdXNlbGV5OiB0aGlzIGlzIGEgbmljZSB0byBo YXZlLCBidXQgb25seSBpZiBpdCBpcyBjaGVhcDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPi0gJm5i c3A7UFBLIG1hbmFnZW1lbnQ7IGhvdyBtdWNoIHN1cHBvcnQgZG8gd2UgcHJvdmlkZSBmb3IgYXV0 b21hdGljYWxseSBtYW5hZ2luZyB0aGUgc2VjcmV0cz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+U2NvdHQgRmx1aHJlcjogbm90IGlt cG9ydGFudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IlJVIj5Ub21teSBQYXVseTogbm90IGltcG9ydGFudDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj5Pc2NhciBHYXJjaWEtTW9y Y2hvbjogbm90IGltcG9ydGFudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IlJVIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPi0gSG93IG11Y2ggc3Vw cG9ydCBkbyB3ZSBwcm92aWRlIGZvciBub25zdGF0aWMgc2VjcmV0cywgZm9yIGV4YW1wbGUsIGJ5 IFFLRCwgb3IgdmlhIHNvbWV0aGluZyBsaWtlIEhJTU1PIChhIGtleSBkaXN0cmlidXRpb24gbWVj aGFuaXNtIHRoYXQgYXBwZWFycyB0byBiZSBwb3N0IHF1YW50dW0pPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj5TY290dCBGbHVocmVy OiBub3QgaW1wb3J0YW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iUlUiPk1pY2hhZWwgUmljaGFyZHNvbjogbm90IGltcG9ydGFudDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj5U b21teSBQYXVseTogbm90IGltcG9ydGFudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj5Pc2NhciBHYXJjaWEtTW9yY2hvbjogbm90IGlt cG9ydGFudCBub3csIGJ1dCB3aWxsIGJlY29tZSBpbXBvcnRhbnQgaW4gdGhlIGZ1dHVyZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJSVSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iUlUiPi0gQXV0aGVudGljYXRpb247IGlmIHNvbWVvbmUgd2l0aCBhIFF1 YW50dW0gQ29tcHV0ZXIgY2FuIGJyZWFrIHRoZSBESCBpbiByZWFsIHRpbWUsIGRvIHdlIGNhcmUg aWYgaGUgY2FuIGFjdCBhcyBhIG1hbi1pbi10aGUtbWlkZGxlPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj5TY290dCBGbHVocmVyOiBu b3QgaW1wb3J0YW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iUlUiPk1pY2hhZWwgUmljaGFyZHNvbjogaW1wb3J0YW50LCBwcm92aWRlZCB0 aGF0IHdlIGRvbid0IHJ1biBpbnRvIHRoZSBzYW1lIGlzc3VlcyB0aGF0IElLRXYxIFBTS3MgcmFu IGludG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJSVSI+VG9tbXkgUGF1bHk6IG5vdCBpbXBvcnRhbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+VmFsZXJ5IFNteWxzb3Y6IHRo aXMgd291bGQgYmUgbmljZSB0byBoYXZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPk9zY2FyIEdhcmNpYS1Nb3JjaG9uOiB0aGlzIHdv dWxkIGJlIG5pY2UgdG8gaGF2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IlJVIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPi0gQWxnb3JpdGhtIGFn aWxpdHk7IGhvdyBpbXBvcnRhbnQgaXMgaXQgdGhhdCB3ZSBuZWdvdGlhdGUgYW55IGNyeXB0b3By aW1pdGl2ZXMgaW52b2x2ZWQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iUlUiPlNjb3R0IEZsdWhyZXI6IG5vdCBpbXBvcnRhbnQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+VG9t bXkgUGF1bHk6IG5vdCBpbXBvcnRhbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+VmFsZXJ5IFNteWxzb3Y6IGltcG9ydGFudDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj5P c2NhciBHYXJjaWEtTW9yY2hvbjogbGVzcyBpbXBvcnRhbnQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj5NeSB0ZW50 YXRpdmUgc3VtbWFyeSBvZiB0aGUgdm90ZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj4tIFNpbXBsaWNpdHkgYW5k IHByZXNlcnZpbmcgZXhpc3Rpbmcgc2VjdXJpdHkgcHJvcGVydGllcyBhcmUgdGhlIG1vc3QgaW1w b3J0YW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iUlUiPi0gUHJvdGVjdGluZyBJS0UgdHJhZmZpYyB3YXMgY29uc2lkZXJlZCBsZXNzIGlt cG9ydGFudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJSVSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iUlUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+V2UgaGF2ZSB1cGRhdGVk IG91ciBkcmFmdCB0byByZWZsZWN0IHRoZXNlIHJlcXVpcmVtZW50czsgaXQgaXMgbXVjaCBzaW1w bGVyIHRoYW4gdGhlIHByZXZpb3VzIGRyYWZ0LCBidXQgZG9lcyBub3QgcHJvdmlkZSBhbm9ueW1p dHkuJm5ic3A7IEl0IGlzIGJhc2VkIG9uIGEgc3VnZ2VzdGlvbiBieSBUZXJvICh3aGljaCB3YXMg dG8gZG8gdGhlIGluaXRpYWwgSUtFIFNBIGVzdGFibGlzaG1lbnQNCiBhcyBub3JtYWwsIGFuZCB0 aGVuIHN0aXIgaW4gdGhlIFBQSyBpbnRvIHRoZSBJUHNlYyBLRVlNQVQgZ2VuZXJhdGlvbiBwcm9j ZXNzKTsgdGhpcyBtYWtlcyBpdCBtdWNoIHNpbXBsZXIgdGhhbiB0cnlpbmcgdG8gZXhjaGFuZ2Ug aWRlbnRpdGllcyBiZWZvcmUgZG9pbmcgdGhlIGluaXRpYWwga2V5IGRlcml2YXRpb24uJm5ic3A7 IFdlIGRpZCBhZGQgYSBtb2RpZmljYXRpb24gdG8gaG93IHRoZSBjaGlsZCBTQSBTS0VZU0VFRCB3 YXMgY29tcHV0ZWQgKGJ5IHN0aXJyaW5nDQogaW4gdGhlIFBQSyB0aGVyZSBhcyB3ZWxsKTsgdGhl IGFkdmFudGFnZSBvZiB0aGlzIGlzIHRoYXQgdGhpcyBtZWFucyB0aGF0IGFueSBjaGlsZCBJS0Ug U0FzIHdlcmUgYWxzbyBxdWFudHVtIHJlc2lzdGFudC4mbmJzcDsgVGhpcyBpbXBsaWVzIHRoYXQg YW4gaW1wbGVtZW50YXRpb24gdGhhdCBkaWQgaW5zaXN0IG9uIHByb3RlY3RpbmcgdGhlIElLRSB0 cmFmZmljIGNvdWxkIGltbWVkaWF0ZWx5IGdlbmVyYXRlIGEgY2hpbGQgU0EgYWZ0ZXIgbmVnb3Rp YXRpb24sDQogYW5kIHRoZW4gdXNlIHRoYXQgY2hpbGQgU0EgdG8gZG8gYWxsIHRoZSByZWFsIG5l Z290aWF0aW9uLiZuYnNwOyBXZSB0aG91Z2h0IHRoYXQgdGhpcyBmbGV4aWJpbGl0eSBqdXN0aWZp ZWQgdGhlIGV4dHJhIGNvbXBsaWNhdGlvbiBvZiBtb2RpZnlpbmcgdGhlIFNLRVlTRUVEIGNvbXB1 dGF0aW9uLiZuYnNwOyBTdWNoIGFuIGltcGxlbWVudGF0aW9uIHdvdWxkIGxlYWsgdGhlIGlkZW50 aXRpZXMgdG8gYSBRdWFudHVtIGFkdmVyc2FyeSwgYnV0IGV2ZXJ5dGhpbmcgZWxzZQ0KIHdvdWxk IGJlIHByb3RlY3RlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJSVSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPkhlcmUgaXMgaG93IHRoZSBkcmFmdCBzY29yZXMg YWdhaW5zdCB0aGUgZ2l2ZW4gY3JpdGVyaWE6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj4tIFNpbXBsaWNpdHk7IGl0 IGlzIGZhaXJseSBzaW1wbGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJSVSI+LSBQcmVzZXJ2aW5nIGV4aXN0aW5nIElLRSBzZWN1cml0eSBw cm9wZXJ0aWVzPyZuYnNwOyBJdCBwcmVzZXJ2ZXMgYWxsIElLRSBzZWN1cml0eSBwcm9wZXJ0aWVz IGFnYWluc3QgYW4gYWR2ZXJzYXJ5IHdpdGggYSBjb252ZW50aW9uYWwgY29tcHV0ZXINCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj4t IFdoYXQgaXMgcHJvdGVjdGVkIGZyb20gc29tZW9uZSB3aXRoIGEgUXVhbnR1bSBDb21wdXRlcj8m bmJzcDsgSXQgcHJvdGVjdHMgdGhlIElQc2VjIHRyYWZmaWM7IGl0IGFsc28gYWxsb3dzIGFuIGlt cGxlbWVudGF0aW9uICh3aXRoIG1vcmUgZXhjaGFuZ2VzKSB0byBwcm90ZWN0IHRoZSBJS0UgdHJh ZmZpYyAoYXBhcnQgZnJvbSB0aGUgaWRlbnRpdGllcyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+LSBXaGF0IGxldmVsIG9mIGlkZW50 aXR5IHByb3RlY3Rpb24gZG8gd2UgbmVlZCB0byBwcm92aWRlPyZuYnNwOyBUaGlzIGRvZXNuJ3Qg cHJvdmlkZSBhbnkgaWRlbnRpdHkgcHJvdGVjdGlvbiBhZ2FpbnN0IHNvbWVvbmUgd2l0aCBhIFF1 YW50dW0gQ29tcHV0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJSVSI+LSZuYnNwOyBQUEsgbWFuYWdlbWVudDsgbm90IGFkZHJlc3NlZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJV Ij4tIEhvdyBtdWNoIHN1cHBvcnQgZG8gd2UgcHJvdmlkZSBmb3Igbm9uc3RhdGljIHNlY3JldHM/ Jm5ic3A7IE5vdCBhZGRyZXNzZWQsIGhvd2V2ZXIgaXQgd291bGQgbm90IGJlIGRpZmZpY3VsdCB0 byBhZGQgaW4gdGhlIGZ1dHVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+LSBBdXRoZW50aWNhdGlvbjsgY2FuIGFuIGF0dGFja2Vy IHdpdGggUXVhbnR1bSBDb21wdXRlciBhY3QgYXMgYSBtYW4taW4tdGhlLW1pZGRsZT8mbmJzcDsg Tm8sIG5vdCBpZiBib3RoIHNpZGVzIGhhdmUgUFBLIG1hbmRhdG9yeTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj4tIEFsZ29yaXRobSBh Z2lsaXR5OyB5ZXMsIHRoZSBvbmx5IGFsZ29yaXRobXMgdXNlZCBhcmUgdGhlIG9uZXMgbmVnb3Rp YXRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IlJVIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJSVSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJSVSI+SVBzZWMgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPjxhIGhyZWY9Im1haWx0bzpJUHNlY0Bp ZXRmLm9yZyI+SVBzZWNAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaXBzZWM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iUlUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_970eaf58d0b94a7ba3082ddc8b276462XCHRTP006ciscocom_-- From nobody Mon Nov 14 13:36:37 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741C7129621 for ; Mon, 14 Nov 2016 13:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbikIgumdiqr for ; Mon, 14 Nov 2016 13:36:23 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A87511293FF for ; Mon, 14 Nov 2016 13:36:21 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id t79so125290927wmt.0 for ; Mon, 14 Nov 2016 13:36:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:to:from:subject:date:importance :thread-topic:in-reply-to:references; bh=odQ9euNbRMNEkwDDmn4G3o9q0gW33hcepT+D15e+Axg=; b=MQrajgsFXIHKqL8WqzmMxuQfmcNxmCEDXixnRlRb+Oo2atzD4WlX8yltJ32dlpb0Pk ocwkgGZJgfI+onrLRRHOZfRK5V1eZHVpICMlZ6Ix5AZI9eeuL2AaKuEJjptMmpPw6/yd hahiM1bYRqVsdXhzg70k+9U2yNX6C+DBqGcZHwdDFH9ti00M/hUVT9dBy9fhafS42K++ YKnOCRiXqgXL+19KoKLKd9URtjrYwOEIiR5D0CCCVys6viwLnaQT6R424lyBeKQXJE5s B5ldZf5SDy+HpXVhrXJdx1ao2SFdjeSbElMhjuxisSy6fNdG80rHSIDYZZihLoSEAOec saqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance:thread-topic:in-reply-to:references; bh=odQ9euNbRMNEkwDDmn4G3o9q0gW33hcepT+D15e+Axg=; b=nJZdJRuNw2ICsZxqPVDLyKyALhupKRfwY75Z4KNb1FuifhYnVNMl9VkQQXTDhbQzcW IVLAMySpXupc0WPQlYMp4gCd/7UQdH3GVbov6cIIrs88AVEYWt7NgNGq1LNo71+ZFTQO KhWk6+nLMtVemZdOqjjTeJCnVM7MMnKp9p+7SohldOYhkXzcjmqBXB0lmLLVTNsa+Oxj X+6nMBim2qQjoEGdjnjE/I9v1ExzNdVnriuBiKS0XF/PkKuOoDGJXqdIRXUOao7/qQvb A5fzdPQRBrWwPgTnaCeWbghqREl+B98R9/8BWqpKqmrL9zv9BIYq3qf6YUfote3fHXqC vJ5w== X-Gm-Message-State: ABUngvdnOxbphre1hdGmddA/jpGkkyxpMGVAk1FbN27d5bYVnfWr8XxJxrvWMttWWaM9HA== X-Received: by 10.25.92.74 with SMTP id q71mr9560784lfb.140.1479159380032; Mon, 14 Nov 2016 13:36:20 -0800 (PST) Received: from ?IPv6:::ffff:192.168.0.140? ([175.193.211.84]) by smtp.gmail.com with ESMTPSA id h63sm5516102ljh.20.2016.11.14.13.36.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Nov 2016 13:36:19 -0800 (PST) Message-ID: <582a2e53.42212e0a.df555.6ec3@mx.google.com> MIME-Version: 1.0 To: "Hu, Jun (Nokia - US)" , Tommy Pauly , IPsecME WG From: Valery Smyslov Date: Tue, 15 Nov 2016 06:36:23 +0900 Importance: normal X-Priority: 3 Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt In-Reply-To: <876523B00C3F9D47BFD2B654D63DBF92BEB12F24@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <147792938094.32373.833800643936554773.idtracker@ietfa.amsl.com> <61A7C96D-66A0-4BA7-82BE-277CBE13ED45@apple.com> <876523B00C3F9D47BFD2B654D63DBF92BEB12F24@US70UWXCHMBA05.zam.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="_1B91E740-B13D-4187-899B-132A2DB2FE64_" Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 21:36:25 -0000 --_1B91E740-B13D-4187-899B-132A2DB2FE64_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Jun, for the second part: your IKE SA must be linked to all child SAs it created (in other words, child SAs must remember which IKE SA created them and visa versa, otherwise a lot of IKEv2 logic doesn=E2=80=99t work). So there is no need to send packets over all child SAs, it=E2=80=99s enough to send liveness check over IKE SA, so that responder learn new TCP-IKE mapping and use it=20 for linked child SAs as well.=20 Regards, Valery. =20 From: Hu, Jun (Nokia - US) Sent: 14 =D0=BD=D0=BE=D1=8F=D0=B1=D1=80=D1=8F 2016 =D0=B3. 22:21 To: Tommy Pauly; IPsecME WG Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt Two comments: 1. The draft seems to imply that only tunnel initiator is allowed to initia= te TCP session, however what is behavior after TCP connection is lost and = initiator need to re-create it? does it do it right away or only re-create = TCP session when initiator need to send some packet? I assume it should be = right away, because otherwise there will be traffic loss if the responder n= eed to send packet before the TCP session is re-created; So if my above understanding is correct, I'd like draft to clearly state th= e behavior;=20 2. section 6 mention that implementation should be able to receive from any= TCP session and not enforcing any strict mapping; that's fine for receivin= g, however for sending traffic, system (specially responder) still need to= know which TCP session to use to reach peer of a given SA; for example, If= NAT is detected, then in case of TCP session is lost on initiator side but= still exists on responder side and initiator re-create the TCP session, th= e new TCP session might have a different NAT public port or even different = NAT public address, so the responder can't tell if the new TCP session is f= or an existing SA or a new tunnel, this means initiator need to send messag= e for all existing SA that need to use the new TCP session so that responde= r could update its SA-to-TCP session mapping because otherwise responder mi= ght use the old TCP session for outgoing traffic of existing SA and traffic= will be blackholed; in section 6, draft states that either UPDATE_SA_ADDRE= SS or a IKE keepalive could be used, however there is no specification of b= ehavior for updating CHILD_SA mapping when MOBIKE is not supported; maybe = initiator should send some kind of dummy packet over the CHILD_SA to update= responder's mapping? > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tommy Pauly > Sent: Monday, October 31, 2016 9:01 AM > To: IPsecME WG > Subject: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt >=20 > Hello, >=20 > I=E2=80=99ve posted a new version of the TCP encapsulation draft with the= following > changes: >=20 > 1. Added a section to explicitly discuss how to fallback from UDP to TCP > (retransmissions, etc) based on feedback from the charter discussion 2. > Explained that this method of encapsulation can be used for any stream > protocol, and is not TCP specific, based on feedback from the charter > discussion 3. Clarified the use of multiple TCP connections for Child SAs= , > based on Jun Hu=E2=80=99s questions >=20 > Also, I=E2=80=99m happy to say that we=E2=80=99ve been doing interoperabi= lity testing between > Apple clients and Cisco server for TCP encapsulation. If anyone else has = an > implementation they=E2=80=99d like to try out, please let us know! >=20 > Best, > Tommy >=20 > > On Oct 31, 2016, at 8:56 AM, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the IP Security Maintenance and Extensions= of > the IETF. > > > > Title : TCP Encapsulation of IKE and IPsec Packets > > Authors : Tommy Pauly > > Samy Touati > > Ravi Mantha > > Filename : draft-ietf-ipsecme-tcp-encaps-03.txt > > Pages : 20 > > Date : 2016-10-31 > > > > Abstract: > > This document describes a method to transport IKE and IPsec packets > > over a TCP connection for traversing network middleboxes that may > > block IKE negotiation over UDP. This method, referred to as TCP > > encapsulation, involves sending both IKE packets for tunnel > > establishment as well as tunneled packets using ESP over a TCP > > connection. This method is intended to be used as a fallback option > > when IKE cannot be negotiated over UDP. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-03 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-tcp-encaps-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.i= etf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_1B91E740-B13D-4187-899B-132A2DB2FE64_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

Hi Jun,<= /span>

 <= /p>

for the second part: =C2=A0your = IKE SA must be linked to all child SAs

it created (in other words, child SAs must remembe= r which IKE SA

created them and visa versa, otherwise a lot of IKEv2 logic

doesn=E2=80=99t work). So th= ere is no need to send packets over all

child SAs, it=E2=80=99s enough to send liveness c= heck over IKE SA,

so that responder learn new TCP-IKE mapping and use it

for linked child SAs as well.=

 <= /o:p>

Regards,=

Valery.

 

 

From: Hu, Jun (Nokia - = US)
Sent: 14 =D0=BD=D0=BE=D1=8F=D0=B1=D1=80=D1=8F 2016 =D0=B3= . 22:21
To: Tommy Pauly; = IPsecME WG
Subject: Re: [IP= sec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt

 

Two comments:

 

1. The draft seems= to imply that only tunnel initiator is allowed to initiate TCP session,=C2= =A0 however what is behavior after TCP connection is lost and initiator nee= d to re-create it? does it do it right away or only re-create TCP session w= hen initiator need to send some packet? I assume it should be right away, b= ecause otherwise there will be traffic loss if the responder need to send p= acket before the TCP session is re-created;

So if m= y above understanding is correct, I'd like draft to clearly state the behav= ior;

 

 

2. section 6 mention that implementa= tion should be able to receive from any TCP session and not enforcing any s= trict mapping; that's fine for receiving, however for sending traffic, syst= em (specially responder) still=C2=A0 need to know which TCP session to use = to reach peer of a given SA; for example, If NAT is detected, then in case = of TCP session is lost on initiator side but still exists on responder side= and initiator re-create the TCP session, the new TCP session might have a = different NAT public port or even different NAT public address, so the resp= onder can't tell if the new TCP session is for an existing SA or a new tunn= el, this means initiator need to send message for all existing SA that need= to use the new TCP session so that responder could update its SA-to-TCP se= ssion mapping because otherwise responder might use the old TCP session for= outgoing traffic of existing SA and traffic will be blackholed; in section= 6, draft states that either UPDATE_SA_ADDRESS or a IKE keepalive could be = used, however there is no specification of behavior for updating CHILD_SA m= apping when MOBIKE is not supported;=C2=A0 maybe initiator should send some= kind of dummy packet over the CHILD_SA to update responder's mapping?

<= p class=3DMsoNormal> 

 

> -----Original Message-----

> From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tom= my Pauly

> Sent: Monday, October 31, 2016 9:01 A= M

> To: IPsecME WG

> = Subject: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt

>

> Hello,

>

> I=E2=80=99ve posted a new version = of the TCP encapsulation draft with the following

&= gt; changes:

>

> 1. = Added a section to explicitly discuss how to fallback from UDP to TCP

> (retransmissions, etc) based on feedback from the c= harter discussion 2.

> Explained that this metho= d of encapsulation can be used for any stream

> = protocol, and is not TCP specific, based on feedback from the charter

> discussion 3. Clarified the use of multiple TCP con= nections for Child SAs,

> based on Jun Hu=E2=80= =99s questions

>

> A= lso, I=E2=80=99m happy to say that we=E2=80=99ve been doing interoperabilit= y testing between

> Apple clients and Cisco serv= er for TCP encapsulation. If anyone else has an

>= ; implementation they=E2=80=99d like to try out, please let us know!

>

> Best,

> Tommy

>

&g= t; > On Oct 31, 2016, at 8:56 AM, internet-drafts@ietf.org wrote:

> >

> >

> > A New Internet-Draft is available from the on-line I= nternet-Drafts

> directories.

> > This draft is a work item of the IP Security Maintenance an= d Extensions of

> the IETF.

> >

> >=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Title=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 : TCP Encapsulation of IKE and IPsec Packets

> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Authors=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : Tommy Pauly

>= ; >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Samy Touati

> >=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ravi Mantha

> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Filename=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : draft-ietf-ipsecme-tcp-encaps-03.= txt

> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Pages=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 20

<= p class=3DMsoNormal>> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Date=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 2016-10-3= 1

> >

> > Abstr= act:

> >=C2=A0=C2=A0 This document describes = a method to transport IKE and IPsec packets

> &g= t;=C2=A0=C2=A0 over a TCP connection for traversing network middleboxes tha= t may

> >=C2=A0=C2=A0 block IKE negotiation o= ver UDP.=C2=A0 This method, referred to as TCP

>= >=C2=A0=C2=A0 encapsulation, involves sending both IKE packets for tunn= el

> >=C2=A0=C2=A0 establishment as well as t= unneled packets using ESP over a TCP

> >=C2= =A0=C2=A0 connection.=C2=A0 This method is intended to be used as a fallbac= k option

> >=C2=A0=C2=A0 when IKE cannot be n= egotiated over UDP.

> >

> >

> > The IETF datatracker status = page for this draft is:

> > https://datatrack= er.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/

>= >

> > There's also a htmlized version ava= ilable at:

> > https://tools.ietf.org/html/dr= aft-ietf-ipsecme-tcp-encaps-03

> >

> > A diff from the previous version is available at:

> > https://www.ietf.org/rfcdiff?url2=3Ddraft-= ietf-ipsecme-tcp-encaps-03

> >

> >

> > Please note that it m= ay take a couple of minutes from the time of

> &= gt; submission until the htmlized version and diff are available at tools.i= etf.org.

> >

> >= ; Internet-Drafts are also available by anonymous FTP at:

> > ftp://ftp.ietf.org/internet-drafts/

> >

> > _____________________________= __________________

> > IPsec mailing list

=

> > IPsec@ietf.org

> = > https://www.ietf.org/mailman/listinfo/ipsec

&g= t;

> __________________________________________= _____

> IPsec mailing list

> IPsec@ietf.org

> https://www.ietf.org/ma= ilman/listinfo/ipsec

______________________________= _________________

IPsec mailing list

IPsec@ietf.org

https://www.ietf.org/mailm= an/listinfo/ipsec

 

= --_1B91E740-B13D-4187-899B-132A2DB2FE64_-- From nobody Mon Nov 14 13:50:14 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0982A1295CE for ; Mon, 14 Nov 2016 13:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKbqWlkQDyt4 for ; Mon, 14 Nov 2016 13:50:09 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 0908B126579 for ; Mon, 14 Nov 2016 13:50:09 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id g23so125453806wme.1 for ; Mon, 14 Nov 2016 13:50:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:to:from:subject:date:importance :thread-topic:in-reply-to:references; bh=+m2v9jIr6OFGvrxb5LuxgbVvc++WJ2S1J8tfW1SAprQ=; b=cbl/kOyWp+TvXXlerJoa+e29KCTZDDHqYb26bdlcm1gj4UUAKE8W2F8kVqEckbcPU+ Nix2aqfUoW6hEkPUW2gZqhIT0Z0u0PciNRMjGEjBBK7DMABB4DjYT/KtmAnoGlB9MIGy 5g2mrd7ixU5leMdhJ8YJ0Hh9xdoZ/cJu8AsZmIer5pVoIN6m6/K9bZXMEqVeHoIUt950 rGIGvmAVWeVu58aKv2FTqmxrXlHDw+/e9AhpyxctG2Pp6ZBVxxg7ubMPSSjIcqgyPjxt KU5nDYfXmXVOuAERIEfPpG45dTV9LikSYRGiKmRAMJXtMK6JE+bx6pqs9sO2hU3KBFye Vnig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance:thread-topic:in-reply-to:references; bh=+m2v9jIr6OFGvrxb5LuxgbVvc++WJ2S1J8tfW1SAprQ=; b=HjcTTBYRWOgTaCqjTnNpR+fmAlDr6dCkQN+piQpGxnkvB1F3Ce2rqvVmQwL2vcHT9j GNFgDV08ENaLVLaHTtw1/XH2hue5jwcekU/B9FWFAwhOLcKe9nahZLHNgOPUzfhjlF1x UEPDhuXYi6ZK2RUF2/ykSQMPl1c5rOpIFHc4mOMcBbxhUpC5v3W553rHH+vH7CbgOh6A AQK5Hsqq+xGtMRmr5f4MXRpLhGC8hJu9x6yUZJQ+8AV4S3hHhGfijkOD6WRu0NhSeR2K Xny07SJRio/lL0jz0uhbS42uKUeUeogvfMVj5vm+gs0hePeOf0qAPrPGg8MWQ5CifSQy hjSA== X-Gm-Message-State: ABUngvcbruQFK+6bGn7E+limmjaNskTCuUtqhOoMKjDhMY1rTzlG0FpGsoqdCar8o/Stcw== X-Received: by 10.25.18.90 with SMTP id h87mr9239743lfi.91.1479160207426; Mon, 14 Nov 2016 13:50:07 -0800 (PST) Received: from ?IPv6:::ffff:192.168.0.140? ([175.193.211.84]) by smtp.gmail.com with ESMTPSA id d135sm2959660lfg.12.2016.11.14.13.50.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Nov 2016 13:50:06 -0800 (PST) Message-ID: <582a318e.8dcd190a.68a28.ca1f@mx.google.com> MIME-Version: 1.0 To: "Scott Fluhrer (sfluhrer)" , "IPsecme WG (ipsec@ietf.org)" From: Valery Smyslov Date: Tue, 15 Nov 2016 06:50:08 +0900 Importance: normal X-Priority: 3 Thread-Topic: [IPsec] FW: Quantum Resistance Requirements In-Reply-To: <970eaf58d0b94a7ba3082ddc8b276462@XCH-RTP-006.cisco.com> References: <6c1585204f6a4598b6e40b05912ba4c4@XCH-RTP-006.cisco.com> <5829b397.01d6620a.9dfb5.4373@mx.google.com> <970eaf58d0b94a7ba3082ddc8b276462@XCH-RTP-006.cisco.com> Content-Type: multipart/alternative; boundary="_13A27F97-A0EF-4BFA-B736-5A3E2A75D18A_" Archived-At: Subject: Re: [IPsec] FW: Quantum Resistance Requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 21:50:13 -0000 --_13A27F97-A0EF-4BFA-B736-5A3E2A75D18A_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" That=E2=80=99s a double fold problem. You are changing nonces using PPK and it seems that for HSM the PPK operations should also be done in hardware, s= houldn=E2=80=99t them? In this case it=E2=80=99s a bit unfair to say you keeps current hardware in= tact (well, I think that different configurations are possible and I think In some cases your considerations make sense). However, if you need to modify hardware in any case, then my proposal looks a bit simpler =E2=80=93 you have a single point in the IKE key derivation logic that needs modification (and the same is true for software). From: Scott Fluhrer (sfluhrer) Sent: 14 =D0=BD=D0=BE=D1=8F=D0=B1=D1=80=D1=8F 2016 =D0=B3. 23:07 To: Valery Smyslov; IPsecme WG (ipsec@ietf.org) Subject: RE: [IPsec] FW: Quantum Resistance Requirements No, we didn=E2=80=99t consider modifying things there. The main reason we wouldn=E2=80=99t have considered that is a possible comp= lication to crypto hardware; if we assume that we had hardware that did mos= t of the crypto calculations internally, it might keep the SK_d value inter= nally, and might not give us an easy way to modify it.=C2=A0 In contrast, t= he nonces are inputs to the hardware, and so that hardware is agnostic to w= hether we=E2=80=99re actually giving it the nonces that actually appeared i= n the packets, or whether we=E2=80=99re giving them modified versions of it= . I don=E2=80=99t expect there to be any security disadvantage; the differenc= es would be entirely practical. From: Valery Smyslov [mailto:svanru@gmail.com]=20 Sent: Monday, November 14, 2016 7:53 AM To: Scott Fluhrer (sfluhrer); IPsecme WG (ipsec@ietf.org) Subject: RE: [IPsec] FW: Quantum Resistance Requirements Hi Scott, after reading the draft I have one question. The draft redefines both KEYMAT and SKEYSEED for IKE SA rekey derivations for the case when PPK is used. Did you consider variant when only SK_d derivation is modified? Something like this: No modification to SK_* calculation, SKEYSEED calculation and KEYMAT calcul= ation. However, for the PPK use case define SK_d`, that must be used instead of SK= _d, so that SK_d=E2=80=99 =3D prf+(SK_d, Ni=E2=80=99 | Nr=E2=80=99), where Ni= =E2=80=99 =3D prf(PPK, Ni), Nr=E2=80=99 =3D prf(PPK, Nr). This is an ad hoc construction, probably it can be improved, but the idea i= s clear: Introduce a single point (SK_d=E2=80=99 derivation) where modifications to = keys derivation algorithm take place, instead of two points. It will make implementations modificatio= n easier, I think. So, did you consider such variant? Are there any security disadvantages? Regards, Valery Smyslov. From: Scott Fluhrer (sfluhrer) Sent: 28 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2016 =D0=B3. 23:25 To: IPsecme WG (ipsec@ietf.org) Subject: [IPsec] FW: Quantum Resistance Requirements Here is an update on the voting for the list of potential requirements for = a short term Quantum Resistance solution; and a summary of the recent updat= e to our draft (which reflects the stated requirements) The votes so far (omitting the "no opinion" votes); I've listed the voters = chiefly so that if I mischaracterized their votes, they can correct me. - Simplicity; how large of a change to IKE (and IKE implementations) are we= willing to contemplate? Scott Fluhrer: very important Michael Richardson: very important Tommy Pauly: very important Valery Smyslov: not as important as other issues Oscar Garcia-Morchon: very important. - Preserving existing IKE security properties? Scott Fluhrer: very important Michael Richardson: very important Tommy Pauly: very important Valery Smyslov: important Oscar Garcia-Morchon: very important.=20 - What do we feel needs to protected from someone with a Quantum Computer? = =C2=A0Do we feel =C2=A0the need to protect only the IPsec traffic, or do we= need to protect the IKE traffic as well. Tommy Pauly: not clear if IKE traffic needs to be protected. Valery Smylsov: important Oscar Garcia-Morchon: IPsec traffic must be protected, IKE traffic would be= a nice-to-have.=20 - What level of identity protection do we need to provide?=C2=A0 If two dif= ferent IKE negotiations use the same shared secret, do we mind if someone c= an deduce that? Scott Fluhrer: not important Michael Richardson: very important Tommy Pauly: not important Valery Smylsov: this is a nice to have, but not critical Oscar Garcia-Morchon: this is less important Russ Houseley: this is a nice to have, but only if it is cheap - =C2=A0PPK management; how much support do we provide for automatically ma= naging the secrets? Scott Fluhrer: not important Tommy Pauly: not important Oscar Garcia-Morchon: not important - How much support do we provide for nonstatic secrets, for example, by QKD= , or via something like HIMMO (a key distribution mechanism that appears to= be post quantum)? Scott Fluhrer: not important Michael Richardson: not important Tommy Pauly: not important Oscar Garcia-Morchon: not important now, but will become important in the f= uture - Authentication; if someone with a Quantum Computer can break the DH in re= al time, do we care if he can act as a man-in-the-middle? Scott Fluhrer: not important Michael Richardson: important, provided that we don't run into the same iss= ues that IKEv1 PSKs ran into Tommy Pauly: not important Valery Smylsov: this would be nice to have Oscar Garcia-Morchon: this would be nice to have - Algorithm agility; how important is it that we negotiate any cryptoprimit= ives involved? Scott Fluhrer: not important Tommy Pauly: not important Valery Smylsov: important Oscar Garcia-Morchon: less important. My tentative summary of the votes: - Simplicity and preserving existing security properties are the most impor= tant - Protecting IKE traffic was considered less important. We have updated our draft to reflect these requirements; it is much simpler= than the previous draft, but does not provide anonymity.=C2=A0 It is based= on a suggestion by Tero (which was to do the initial IKE SA establishment = as normal, and then stir in the PPK into the IPsec KEYMAT generation proces= s); this makes it much simpler than trying to exchange identities before do= ing the initial key derivation.=C2=A0 We did add a modification to how the = child SA SKEYSEED was computed (by stirring in the PPK there as well); the = advantage of this is that this means that any child IKE SAs were also quant= um resistant.=C2=A0 This implies that an implementation that did insist on = protecting the IKE traffic could immediately generate a child SA after nego= tiation, and then use that child SA to do all the real negotiation.=C2=A0 W= e thought that this flexibility justified the extra complication of modifyi= ng the SKEYSEED computation.=C2=A0 Such an implementation would leak the id= entities to a Quantum adversary, but everything else would be protected. Here is how the draft scores against the given criteria: - Simplicity; it is fairly simple - Preserving existing IKE security properties?=C2=A0 It preserves all IKE s= ecurity properties against an adversary with a conventional computer=20 - What is protected from someone with a Quantum Computer?=C2=A0 It protects= the IPsec traffic; it also allows an implementation (with more exchanges) = to protect the IKE traffic (apart from the identities) - What level of identity protection do we need to provide?=C2=A0 This doesn= 't provide any identity protection against someone with a Quantum Computer -=C2=A0 PPK management; not addressed - How much support do we provide for nonstatic secrets?=C2=A0 Not addressed= , however it would not be difficult to add in the future. - Authentication; can an attacker with Quantum Computer act as a man-in-the= -middle?=C2=A0 No, not if both sides have PPK mandatory - Algorithm agility; yes, the only algorithms used are the ones negotiated _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_13A27F97-A0EF-4BFA-B736-5A3E2A75D18A_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

That=E2=80=99s a do= uble fold problem. You are changing nonces using PPK and<= /p>

it seems that for HSM the PPK op= erations should also be done in hardware, shouldn=E2=80=99t them?

In this case it=E2=80= =99s a bit unfair to say you keeps current hardware intact

(well, I think that different = configurations are possible and I think

In some cases your considerations make sense).

 

However, if you need to= modify hardware in any case, then my proposal looks

<= p class=3DMsoNormal>a bit simpler =E2=80=93 you have a s= ingle point in the IKE key derivation

logic that needs modification (and the same is true= for software).

 =

 

 

From: Scott Fluhrer (sfluhrer)
Sent: 14 =D0=BD=D0=BE=D1=8F= =D0=B1=D1=80=D1=8F 2016 =D0=B3. 23:07
To: Valery Smyslov; IPsecme = WG (ipsec@ietf.org)
Subject: RE: [IPsec] FW: Quantum Resistan= ce Requirements

 

No, we didn=E2=80=99t consider modifying things there.

 

The main rea= son we wouldn=E2=80=99t have considered that is a possible complication to = crypto hardware; if we assume that we had hardware that did most of the cry= pto calculations internally, it might keep the SK_d value internally, and m= ight not give us an easy way to modify it.  In contrast, the nonces ar= e inputs to the hardware, and so that hardware is agnostic to whether we=E2= =80=99re actually giving it the nonces that actually appeared in the packet= s, or whether we=E2=80=99re giving them modified versions of it.=

 

I don=E2=80=99t expect there to be any security disadvantage; = the differences would be entirely practical.

 

From: Valery Smyslov [mailto:svanru@gmail.com]
Sent: Monday, Novembe= r 14, 2016 7:53 AM
To: Scott Fluhrer (sfluhrer); IPsecme WG (ipse= c@ietf.org)
Subject: RE: [IPsec] FW: Quantum Resistance Requireme= nts

 

Hi Sc= ott,

 

after reading the draft I have one question. The draf= t redefines both

KEYMAT and SKEYSEED for IKE SA rekey derivations for the case=

when PPK is used. Did yo= u consider variant when only SK_d derivation

is modified? Something like this:

 

No modification to SK_* calcul= ation, SKEYSEED calculation and KEYMAT calculation.

However, for the PPK use case define = SK_d`, that must be used instead of SK_d,

so that SK_d=E2=80=99 =3D prf+(SK_d, Ni=E2=80= =99 | Nr=E2=80=99), where Ni=E2=80=99 =3D prf(PPK, Ni), Nr=E2=80=99 =3D prf(PPK, Nr).

 

This is an ad hoc construction, probably it= can be improved, but the idea is clear:

Introduce a single point (SK_d=E2=80=99 derivati= on) where modifications to keys derivation algorithm

<= p class=3DMsoNormal>take place, instead of two points. I= t will make implementations modification easier, I think.=

 

So, did you consider such variant? Are= there any security disadvantages?

&nbs= p;

Regards,

Valery Smyslov.

From: Scott Fluhrer (sfluhrer)
Sent= : 28 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2016 =D0=B3. 23:25
<= b>To: IPsecme WG (ipsec@ietf.org)=
Subject: [IPsec] FW: Quantum Resistance Requirements<= /p>

 

He= re is an update on the voting for the list of potential requirements for a = short term Quantum Resistance solution; and a summary of the recent update = to our draft (which reflects the stated requirements)

 

The votes so far (o= mitting the "no opinion" votes); I've listed the voters chiefly s= o that if I mischaracterized their votes, they can correct me.

 

 

- Simplicity; how large of a change to IKE (and IKE i= mplementations) are we willing to contemplate?

Scot= t Fluhrer: very important

Michael Richardson: very = important

Tommy Pauly: very important

Valery Smyslov: not as important as other issues

Oscar Garcia-Morchon: very important.

=  

 

- Preserving existing IKE security properties?

Scott Fluhrer: very important

Michael Richards= on: very important

Tommy Pauly: very important

<= p class=3DMsoNormal>Valery Smyslov: important

Oscar= Garcia-Morchon: very important.

 =

 

- What d= o we feel needs to protected from someone with a Quantum Computer?  Do= we feel  the need to protect only the IPsec traffic, or do we need to= protect the IKE traffic as well.

Tommy Pauly: not = clear if IKE traffic needs to be protected.

Valery = Smylsov: important

Oscar Garcia-Morchon: IPsec traf= fic must be protected, IKE traffic would be a nice-to-have.

 

 

 

- What level o= f identity protection do we need to provide?  If two different IKE neg= otiations use the same shared secret, do we mind if someone can deduce that= ?

Scott Fluhrer: not important

Michael Richardson: very important

Tommy Pauly:= not important

Valery Smylsov: this is a nice to ha= ve, but not critical

Oscar Garcia-Morchon: this is = less important

Russ Houseley: this is a nice to hav= e, but only if it is cheap

 

 

-  PPK man= agement; how much support do we provide for automatically managing the secr= ets?

Scott Fluhrer: not important

Tommy Pauly: not important

Oscar Garcia-Morc= hon: not important

 

 

- How much support do w= e provide for nonstatic secrets, for example, by QKD, or via something like= HIMMO (a key distribution mechanism that appears to be post quantum)?

<= p class=3DMsoNormal>Scott Fluhrer: not important

Mi= chael Richardson: not important

Tommy Pauly: not im= portant

Oscar Garcia-Morchon: not important now, bu= t will become important in the future

 

 

- Au= thentication; if someone with a Quantum Computer can break the DH in real t= ime, do we care if he can act as a man-in-the-middle?

Scott Fluhrer: not important

Michael Richardson:= important, provided that we don't run into the same issues that IKEv1 PSKs= ran into

Tommy Pauly: not important

Valery Smylsov: this would be nice to have

Oscar Garcia-Morchon: this would be nice to have

=  

 

- Algorithm agility; how important is it that we negotiate any cry= ptoprimitives involved?

Scott Fluhrer: not importan= t

Tommy Pauly: not important

Valery Smylsov: important

Oscar Garcia-Morchon: l= ess important.

 

My tentative summary of the votes:

 = ;

- Simplicity and preserving existing securi= ty properties are the most important

- Protecting I= KE traffic was considered less important.

&nbs= p;

 

=  

We have updated our draft to refl= ect these requirements; it is much simpler than the previous draft, but doe= s not provide anonymity.  It is based on a suggestion by Tero (which w= as to do the initial IKE SA establishment as normal, and then stir in the P= PK into the IPsec KEYMAT generation process); this makes it much simpler th= an trying to exchange identities before doing the initial key derivation.&n= bsp; We did add a modification to how the child SA SKEYSEED was computed (b= y stirring in the PPK there as well); the advantage of this is that this me= ans that any child IKE SAs were also quantum resistant.  This implies = that an implementation that did insist on protecting the IKE traffic could = immediately generate a child SA after negotiation, and then use that child = SA to do all the real negotiation.  We thought that this flexibility j= ustified the extra complication of modifying the SKEYSEED computation. = ; Such an implementation would leak the identities to a Quantum adversary, = but everything else would be protected.

 =

Here is how the draft scores against the giv= en criteria:

 

- Simplicity; it is fairly simple

- Preserving = existing IKE security properties?  It preserves all IKE security prope= rties against an adversary with a conventional computer

- What is protected from someone with a Quantum Computer?  It pr= otects the IPsec traffic; it also allows an implementation (with more excha= nges) to protect the IKE traffic (apart from the identities)

- What level of identity protection do we need to provide?  = This doesn't provide any identity protection against someone with a Quantum= Computer

-  PPK management; not addressed

=

- How much support do we provide for nonstatic secrets= ?  Not addressed, however it would not be difficult to add in the futu= re.

- Authentication; can an attacker with Quantum = Computer act as a man-in-the-middle?  No, not if both sides have PPK m= andatory

- Algorithm agility; yes, the only algorit= hms used are the ones negotiated

 <= /p>

_______________________________________________

=

IPsec mailing list

IPsec@ietf.org

https://www.ietf.org/mailm= an/listinfo/ipsec

 

 

= --_13A27F97-A0EF-4BFA-B736-5A3E2A75D18A_-- From nobody Mon Nov 14 15:04:53 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC701294DC for ; Mon, 14 Nov 2016 15:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 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_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 oW3-n_0ejsWx for ; Mon, 14 Nov 2016 15:04:49 -0800 (PST) Received: from mail-in1.asia.apple.com (mail-out.asia.apple.com [17.82.254.63]) (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 40AFA1293E9 for ; Mon, 14 Nov 2016 15:04:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1479164640; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=o8CHJHiWeKVFAFfjNcrVlIXwl7DpwIa5JWWMDWdC22U=; b=Yc4wHTbZPQSucydFwX2Gde67LhvM5TFdo8f/HWCBghcb5yoC4kYbbjfQVsAqnhO2 BJgVifntAlTvUjCS7touxRff3E4fV5p70c5QOjo2+XWcOJ+35hzZ7Mf7UJ6KsJ+8 9xC3f2Wv+n5t+Fb26j/VdYy/ogNq7M9BX4nmdBljmTexFilpLN59/26gFRmnvJej AFXDp+KOWRs2oSd4I6i6/1VK2n2tDXRLCadOk/7LiXJ3RCxheWaQ9ATATG6j0UKu YKbLOVjuP8YivCBdPTJ3TU0w+LH3bjLH1FxhzwrGuXstir9Y1RJp6LMnMQrVVrAd kM19T6Z3G3TM6ogEuI6DkQ==; Received: from relay1.asia.apple.com ( [17.82.200.18]) by mail-in1.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 92.73.12371.0E24A285; Tue, 15 Nov 2016 07:04:00 +0800 (MYT) X-AuditID: 1152fe11-e7e6f9a000003053-5e-582a42e0ce91 Received: from sng-mmpp-sz01.asia.apple.com ( [17.84.80.62]) by relay1.asia.apple.com (Apple Singapore relay) with SMTP id 21.D7.08629.B034A285; Tue, 15 Nov 2016 07:04:46 +0800 (MYT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.83.124.96] (unknown [17.83.124.96]) by sng-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OGN005WFMRQDN10@sng-mmpp-sz01.asia.apple.com>; Tue, 15 Nov 2016 07:04:43 +0800 (SGT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <876523B00C3F9D47BFD2B654D63DBF92BEB12F24@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Tue, 15 Nov 2016 08:04:37 +0900 Content-transfer-encoding: quoted-printable Message-id: References: <147792938094.32373.833800643936554773.idtracker@ietfa.amsl.com> <61A7C96D-66A0-4BA7-82BE-277CBE13ED45@apple.com> <876523B00C3F9D47BFD2B654D63DBF92BEB12F24@US70UWXCHMBA05.zam.alcatel-lucent.com> To: "Hu, Jun (Nokia - US)" X-Mailer: Apple Mail (2.3252) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUiGHRCSPeBk1aEQUuzvsX+LS/YLD78ncDo wOSxZMlPJo+7ty4xBTBFcdmkpOZklqUW6dslcGW8vD+JpeCdYcXh3edYGhg/qHcxcnJICJhI vF88kbGLkYtDSGA3o8THLX9YYRLbtx9kArGFBHYwSkzeZQdi8woISvyYfI+li5GDg1lAXWLK lFyIkklMEn13eEHCwgISEpv3JIKEhQXcJKZ0/mADsdkEVCSOf9vADGJzCsRLNHSdYQGxWQRU Jf71H2EEsZkF5CV6/2+EsrUlnry7wAqx1Ubiw6s7bBBnXmKUuPFtHztIQkRAV+L76ZdsECfL Sqx8upEVpEhCoIdNYtWVl0wTGIVnITl7FsLZs5DsWMDIvIpRPDcxM0c3M89QL7E4M1EvsaAg J1UvOT93EyM4wP8J7mCcutDwEKMAB6MSD+8Sfa0IIdbEsuLK3EOMEhzMSiK8b+2AQrwpiZVV qUX58UWlOanFhxilOViUxHk1sraHCwmkJ5akZqemFqQWwWSZODilGhhZXm57XX1yFbdYO+Pk Hp6y6dsdF96cYxH31rFWwXzL2Xe/HV5oTNvkGebdyNKx4YuhFY8Qz0pfywBmFtv1yz/r3Jx0 cZ5ez49ln5/xNHYdZe9/08MjNLfMZrHP0TMnbvf/07ppvuqyjPiep+cbODj3r428d/JpTOuE s54x4t9aF4d0bfx3WO2CEktxRqKhFnNRcSIABWDXEGwCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUiGBJgp8vnrBVhcKJZwGL/lhdsFh/+TmB0 YPJYsuQnk8fdW5eYApiiuGxSUnMyy1KL9O0SuDJe3p/EUvDOsOLw7nMsDYwf1LsYOTkkBEwk tm8/yARiCwnsYJSYvMsOxOYVEJT4MfkeSxcjBwezgLrElCm5ECWTmCT67vCChIUFJCQ270kE CQsLuElM6fzBBmKzCahIHP+2gRnE5hSIl2joOsMCYrMIqEr86z/CCGIzC8hL9P7fCGVrSzx5 d4EVYquNxIdXd4DmcAGtusQocePbPnaQhIiArsT30y/ZIE6WlVj5dCPrBEaBWUgunYVw6Swk YxcwMq9iFC1KzUmsNNRLLM5M1EssKMhJ1UvOz93ECArIoBNCOxg/7jc4xCjAwajEw3tWTytC iDWxrLgy9xCjBAezkgivoRNQiDclsbIqtSg/vqg0J7X4EKM0B4uSOG/O44/hQgLpiSWp2amp BalFMFkmDk6pBsaTF5VOvJ/w/fKkol3nBH5c67j+t0p3Wft5m3ULHj0+xjxz18Hus4H+Bzjr ahKnOiz5Pn2i6T1OuXVqaw9uzFZ/eil86ibhi895ZFZO3v1e4pV/VmjbtLXtsXz5IoW9l1md y45N+/WH89UXxXUFPo1Lsn7KG3aZsfezXdfg/j9x+cK6DvezSxs9lViKMxINtZiLihMB15aJ ZkQCAAA= Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 23:04:51 -0000 Hello Jun, With regards to your first question, yes, the initiator would generally = want to re-establish the TCP connection promptly. If it does not, the = responder side may need to send a packet, and behave as if it gets no = response (thus timing out and closing the IKE SA). We can add a line to = specify that the re-establishment should be quick. For the second question, I am not sure why the implementation would = necessarily be maintaining an SA to TCP connection mapping. While it is = possible to send traffic for different child SAs over different TCP = flows, data for any of them should be accepted over any. That was the = point of the line saying an implementation SHOULD allow receiving data = on any connection. There is no need to send data for all child SAs to = update the responder's mapping, if there is no mapping maintained. = Traffic should not be blackholed if the responder uses an older = connection that is still established, since the initiator should also = not be enforcing a strict mapping. I agree that trying to maintain a = mapping gets very complicated and adds packet overhead, which is why it = is not recommended. Does this answer your question? Thanks, Tommy > On Nov 14, 2016, at 10:21 PM, Hu, Jun (Nokia - US) = wrote: >=20 > Two comments: >=20 > 1. The draft seems to imply that only tunnel initiator is allowed to = initiate TCP session, however what is behavior after TCP connection is = lost and initiator need to re-create it? does it do it right away or = only re-create TCP session when initiator need to send some packet? I = assume it should be right away, because otherwise there will be traffic = loss if the responder need to send packet before the TCP session is = re-created; > So if my above understanding is correct, I'd like draft to clearly = state the behavior;=20 >=20 >=20 > 2. section 6 mention that implementation should be able to receive = from any TCP session and not enforcing any strict mapping; that's fine = for receiving, however for sending traffic, system (specially responder) = still need to know which TCP session to use to reach peer of a given = SA; for example, If NAT is detected, then in case of TCP session is lost = on initiator side but still exists on responder side and initiator = re-create the TCP session, the new TCP session might have a different = NAT public port or even different NAT public address, so the responder = can't tell if the new TCP session is for an existing SA or a new tunnel, = this means initiator need to send message for all existing SA that need = to use the new TCP session so that responder could update its SA-to-TCP = session mapping because otherwise responder might use the old TCP = session for outgoing traffic of existing SA and traffic will be = blackholed; in section 6, draft states that either UPDATE_SA_ADDRESS or = a IKE keepalive could be used, however there is no specification of = behavior for updating CHILD_SA mapping when MOBIKE is not supported; = maybe initiator should send some kind of dummy packet over the CHILD_SA = to update responder's mapping? >=20 >=20 >> -----Original Message----- >> From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tommy Pauly >> Sent: Monday, October 31, 2016 9:01 AM >> To: IPsecME WG >> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt >>=20 >> Hello, >>=20 >> I=E2=80=99ve posted a new version of the TCP encapsulation draft with = the following >> changes: >>=20 >> 1. Added a section to explicitly discuss how to fallback from UDP to = TCP >> (retransmissions, etc) based on feedback from the charter discussion = 2. >> Explained that this method of encapsulation can be used for any = stream >> protocol, and is not TCP specific, based on feedback from the charter >> discussion 3. Clarified the use of multiple TCP connections for Child = SAs, >> based on Jun Hu=E2=80=99s questions >>=20 >> Also, I=E2=80=99m happy to say that we=E2=80=99ve been doing = interoperability testing between >> Apple clients and Cisco server for TCP encapsulation. If anyone else = has an >> implementation they=E2=80=99d like to try out, please let us know! >>=20 >> Best, >> Tommy >>=20 >>> On Oct 31, 2016, at 8:56 AM, internet-drafts@ietf.org wrote: >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>> This draft is a work item of the IP Security Maintenance and = Extensions of >> the IETF. >>>=20 >>> Title : TCP Encapsulation of IKE and IPsec Packets >>> Authors : Tommy Pauly >>> Samy Touati >>> Ravi Mantha >>> Filename : draft-ietf-ipsecme-tcp-encaps-03.txt >>> Pages : 20 >>> Date : 2016-10-31 >>>=20 >>> Abstract: >>> This document describes a method to transport IKE and IPsec packets >>> over a TCP connection for traversing network middleboxes that may >>> block IKE negotiation over UDP. This method, referred to as TCP >>> encapsulation, involves sending both IKE packets for tunnel >>> establishment as well as tunneled packets using ESP over a TCP >>> connection. This method is intended to be used as a fallback = option >>> when IKE cannot be negotiated over UDP. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ >>>=20 >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-03 >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-tcp-encaps-03 >>>=20 >>>=20 >>> 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. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Nov 14 17:48:55 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEDA129678 for ; Mon, 14 Nov 2016 17:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8soXG8dyEzI for ; Mon, 14 Nov 2016 17:48:50 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 5886912966D for ; Mon, 14 Nov 2016 17:48:50 -0800 (PST) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 0AF173ED064B9; Tue, 15 Nov 2016 01:48:48 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id uAF1mm9d025898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Nov 2016 01:48:48 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id uAF1mm5h001803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Nov 2016 01:48:48 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.86]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0301.000; Mon, 14 Nov 2016 20:48:48 -0500 From: "Hu, Jun (Nokia - US)" To: Valery Smyslov , Tommy Pauly , "IPsecME WG" Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt Thread-Index: AQHSPr8z+2wY0bMtS0OT/aPsLUfYpaDZRbHw Date: Tue, 15 Nov 2016 01:48:47 +0000 Message-ID: <876523B00C3F9D47BFD2B654D63DBF92BEB1549D@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <147792938094.32373.833800643936554773.idtracker@ietfa.amsl.com> <61A7C96D-66A0-4BA7-82BE-277CBE13ED45@apple.com> <876523B00C3F9D47BFD2B654D63DBF92BEB12F24@US70UWXCHMBA05.zam.alcatel-lucent.com> <582a2e53.42212e0a.df555.6ec3@mx.google.com> In-Reply-To: <582a2e53.42212e0a.df555.6ec3@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_876523B00C3F9D47BFD2B654D63DBF92BEB1549DUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 01:48:53 -0000 --_000_876523B00C3F9D47BFD2B654D63DBF92BEB1549DUS70UWXCHMBA05z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SG93ZXZlciBzaW5jZSB0aGUgZHJhZnQgYWxsb3dzIG11bHRpcGxlIFRDUCBjb25uZWN0aW9ucyBm b3IgdGhlIHNhbWUgdHVubmVsOyB0aGluayBvZiBhIGNhc2UgbGlrZSBmb2xsb3dpbmc6DQpBIHR1 bm5lbCBoYXMgdHdvIENISUxEX1NBLCBlYWNoIGhhcyBpdHMgb3duIFRDUCBjb25uZWN0aW9uOyBT QS0xIGhhcyBUQ1AtMSwgU0EtMiBoYXMgVENQLTI7DQpGb3Igc29tZSByZWFzb24gVENQLTIgZ29l cyBkb3duIG9uIGluaXRpYXRvciBzaWRlIChUQ1AtMSBpcyBzdGlsbCB1cCksIHNvIGluaXRpYXRv ciBjcmVhdGUgYSBUQ1AtMywgZm9yIFNBLTIsIGlmIGluaXRpYXRvciBvbmx5IHNlbmQgSUtFIGtl ZXBhbGl2ZSB0byB1cGRhdGUgcmVzcG9uZGVyLCBzbyByZXNwb25kZXIgd2lsbCBjaGFuZ2UgYm90 aCBTQS0xIGFuZCBTQS0yIHRvIFRDUC0zPw0KDQpGcm9tOiBJUHNlYyBbbWFpbHRvOmlwc2VjLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBWYWxlcnkgU215c2xvdg0KU2VudDogTW9uZGF5 LCBOb3ZlbWJlciAxNCwgMjAxNiAxOjM2IFBNDQpUbzogSHUsIEp1biAoTm9raWEgLSBVUyk7IFRv bW15IFBhdWx5OyBJUHNlY01FIFdHDQpTdWJqZWN0OiBSZTogW0lQc2VjXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLWlwc2VjbWUtdGNwLWVuY2Fwcy0wMy50eHQNCg0KSGkgSnVuLA0KDQpmb3IgdGhl IHNlY29uZCBwYXJ0OiAgeW91ciBJS0UgU0EgbXVzdCBiZSBsaW5rZWQgdG8gYWxsIGNoaWxkIFNB cw0KaXQgY3JlYXRlZCAoaW4gb3RoZXIgd29yZHMsIGNoaWxkIFNBcyBtdXN0IHJlbWVtYmVyIHdo aWNoIElLRSBTQQ0KY3JlYXRlZCB0aGVtIGFuZCB2aXNhIHZlcnNhLCBvdGhlcndpc2UgYSBsb3Qg b2YgSUtFdjIgbG9naWMNCmRvZXNu4oCZdCB3b3JrKS4gU28gdGhlcmUgaXMgbm8gbmVlZCB0byBz ZW5kIHBhY2tldHMgb3ZlciBhbGwNCmNoaWxkIFNBcywgaXTigJlzIGVub3VnaCB0byBzZW5kIGxp dmVuZXNzIGNoZWNrIG92ZXIgSUtFIFNBLA0Kc28gdGhhdCByZXNwb25kZXIgbGVhcm4gbmV3IFRD UC1JS0UgbWFwcGluZyBhbmQgdXNlIGl0DQpmb3IgbGlua2VkIGNoaWxkIFNBcyBhcyB3ZWxsLg0K DQpSZWdhcmRzLA0KVmFsZXJ5Lg0KDQoNCkZyb206IEh1LCBKdW4gKE5va2lhIC0gVVMpPG1haWx0 bzpqdW4uaHVAbm9raWEuY29tPg0KU2VudDogMTQg0L3QvtGP0LHRgNGPIDIwMTYg0LMuIDIyOjIx DQpUbzogVG9tbXkgUGF1bHk8bWFpbHRvOnRwYXVseUBhcHBsZS5jb20+OyBJUHNlY01FIFdHPG1h aWx0bzppcHNlY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSVBzZWNdIEktRCBBY3Rpb246IGRy YWZ0LWlldGYtaXBzZWNtZS10Y3AtZW5jYXBzLTAzLnR4dA0KDQpUd28gY29tbWVudHM6DQoNCjEu IFRoZSBkcmFmdCBzZWVtcyB0byBpbXBseSB0aGF0IG9ubHkgdHVubmVsIGluaXRpYXRvciBpcyBh bGxvd2VkIHRvIGluaXRpYXRlIFRDUCBzZXNzaW9uLCAgaG93ZXZlciB3aGF0IGlzIGJlaGF2aW9y IGFmdGVyIFRDUCBjb25uZWN0aW9uIGlzIGxvc3QgYW5kIGluaXRpYXRvciBuZWVkIHRvIHJlLWNy ZWF0ZSBpdD8gZG9lcyBpdCBkbyBpdCByaWdodCBhd2F5IG9yIG9ubHkgcmUtY3JlYXRlIFRDUCBz ZXNzaW9uIHdoZW4gaW5pdGlhdG9yIG5lZWQgdG8gc2VuZCBzb21lIHBhY2tldD8gSSBhc3N1bWUg aXQgc2hvdWxkIGJlIHJpZ2h0IGF3YXksIGJlY2F1c2Ugb3RoZXJ3aXNlIHRoZXJlIHdpbGwgYmUg dHJhZmZpYyBsb3NzIGlmIHRoZSByZXNwb25kZXIgbmVlZCB0byBzZW5kIHBhY2tldCBiZWZvcmUg dGhlIFRDUCBzZXNzaW9uIGlzIHJlLWNyZWF0ZWQ7DQpTbyBpZiBteSBhYm92ZSB1bmRlcnN0YW5k aW5nIGlzIGNvcnJlY3QsIEknZCBsaWtlIGRyYWZ0IHRvIGNsZWFybHkgc3RhdGUgdGhlIGJlaGF2 aW9yOw0KDQoNCjIuIHNlY3Rpb24gNiBtZW50aW9uIHRoYXQgaW1wbGVtZW50YXRpb24gc2hvdWxk IGJlIGFibGUgdG8gcmVjZWl2ZSBmcm9tIGFueSBUQ1Agc2Vzc2lvbiBhbmQgbm90IGVuZm9yY2lu ZyBhbnkgc3RyaWN0IG1hcHBpbmc7IHRoYXQncyBmaW5lIGZvciByZWNlaXZpbmcsIGhvd2V2ZXIg Zm9yIHNlbmRpbmcgdHJhZmZpYywgc3lzdGVtIChzcGVjaWFsbHkgcmVzcG9uZGVyKSBzdGlsbCAg bmVlZCB0byBrbm93IHdoaWNoIFRDUCBzZXNzaW9uIHRvIHVzZSB0byByZWFjaCBwZWVyIG9mIGEg Z2l2ZW4gU0E7IGZvciBleGFtcGxlLCBJZiBOQVQgaXMgZGV0ZWN0ZWQsIHRoZW4gaW4gY2FzZSBv ZiBUQ1Agc2Vzc2lvbiBpcyBsb3N0IG9uIGluaXRpYXRvciBzaWRlIGJ1dCBzdGlsbCBleGlzdHMg b24gcmVzcG9uZGVyIHNpZGUgYW5kIGluaXRpYXRvciByZS1jcmVhdGUgdGhlIFRDUCBzZXNzaW9u LCB0aGUgbmV3IFRDUCBzZXNzaW9uIG1pZ2h0IGhhdmUgYSBkaWZmZXJlbnQgTkFUIHB1YmxpYyBw b3J0IG9yIGV2ZW4gZGlmZmVyZW50IE5BVCBwdWJsaWMgYWRkcmVzcywgc28gdGhlIHJlc3BvbmRl ciBjYW4ndCB0ZWxsIGlmIHRoZSBuZXcgVENQIHNlc3Npb24gaXMgZm9yIGFuIGV4aXN0aW5nIFNB IG9yIGEgbmV3IHR1bm5lbCwgdGhpcyBtZWFucyBpbml0aWF0b3IgbmVlZCB0byBzZW5kIG1lc3Nh Z2UgZm9yIGFsbCBleGlzdGluZyBTQSB0aGF0IG5lZWQgdG8gdXNlIHRoZSBuZXcgVENQIHNlc3Np b24gc28gdGhhdCByZXNwb25kZXIgY291bGQgdXBkYXRlIGl0cyBTQS10by1UQ1Agc2Vzc2lvbiBt YXBwaW5nIGJlY2F1c2Ugb3RoZXJ3aXNlIHJlc3BvbmRlciBtaWdodCB1c2UgdGhlIG9sZCBUQ1Ag c2Vzc2lvbiBmb3Igb3V0Z29pbmcgdHJhZmZpYyBvZiBleGlzdGluZyBTQSBhbmQgdHJhZmZpYyB3 aWxsIGJlIGJsYWNraG9sZWQ7IGluIHNlY3Rpb24gNiwgZHJhZnQgc3RhdGVzIHRoYXQgZWl0aGVy IFVQREFURV9TQV9BRERSRVNTIG9yIGEgSUtFIGtlZXBhbGl2ZSBjb3VsZCBiZSB1c2VkLCBob3dl dmVyIHRoZXJlIGlzIG5vIHNwZWNpZmljYXRpb24gb2YgYmVoYXZpb3IgZm9yIHVwZGF0aW5nIENI SUxEX1NBIG1hcHBpbmcgd2hlbiBNT0JJS0UgaXMgbm90IHN1cHBvcnRlZDsgIG1heWJlIGluaXRp YXRvciBzaG91bGQgc2VuZCBzb21lIGtpbmQgb2YgZHVtbXkgcGFja2V0IG92ZXIgdGhlIENISUxE X1NBIHRvIHVwZGF0ZSByZXNwb25kZXIncyBtYXBwaW5nPw0KDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogSVBzZWMgW21haWx0bzppcHNlYy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgVG9tbXkgUGF1bHkNCj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDMxLCAy MDE2IDk6MDEgQU0NCj4gVG86IElQc2VjTUUgV0cNCj4gU3ViamVjdDogW0lQc2VjXSBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLWlwc2VjbWUtdGNwLWVuY2Fwcy0wMy50eHQNCj4NCj4gSGVsbG8sDQo+ DQo+IEnigJl2ZSBwb3N0ZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgVENQIGVuY2Fwc3VsYXRpb24g ZHJhZnQgd2l0aCB0aGUgZm9sbG93aW5nDQo+IGNoYW5nZXM6DQo+DQo+IDEuIEFkZGVkIGEgc2Vj dGlvbiB0byBleHBsaWNpdGx5IGRpc2N1c3MgaG93IHRvIGZhbGxiYWNrIGZyb20gVURQIHRvIFRD UA0KPiAocmV0cmFuc21pc3Npb25zLCBldGMpIGJhc2VkIG9uIGZlZWRiYWNrIGZyb20gdGhlIGNo YXJ0ZXIgZGlzY3Vzc2lvbiAyLg0KPiBFeHBsYWluZWQgdGhhdCB0aGlzIG1ldGhvZCBvZiBlbmNh cHN1bGF0aW9uIGNhbiBiZSB1c2VkIGZvciBhbnkgc3RyZWFtDQo+IHByb3RvY29sLCBhbmQgaXMg bm90IFRDUCBzcGVjaWZpYywgYmFzZWQgb24gZmVlZGJhY2sgZnJvbSB0aGUgY2hhcnRlcg0KPiBk aXNjdXNzaW9uIDMuIENsYXJpZmllZCB0aGUgdXNlIG9mIG11bHRpcGxlIFRDUCBjb25uZWN0aW9u cyBmb3IgQ2hpbGQgU0FzLA0KPiBiYXNlZCBvbiBKdW4gSHXigJlzIHF1ZXN0aW9ucw0KPg0KPiBB bHNvLCBJ4oCZbSBoYXBweSB0byBzYXkgdGhhdCB3ZeKAmXZlIGJlZW4gZG9pbmcgaW50ZXJvcGVy YWJpbGl0eSB0ZXN0aW5nIGJldHdlZW4NCj4gQXBwbGUgY2xpZW50cyBhbmQgQ2lzY28gc2VydmVy IGZvciBUQ1AgZW5jYXBzdWxhdGlvbi4gSWYgYW55b25lIGVsc2UgaGFzIGFuDQo+IGltcGxlbWVu dGF0aW9uIHRoZXnigJlkIGxpa2UgdG8gdHJ5IG91dCwgcGxlYXNlIGxldCB1cyBrbm93IQ0KPg0K PiBCZXN0LA0KPiBUb21teQ0KPg0KPiA+IE9uIE9jdCAzMSwgMjAxNiwgYXQgODo1NiBBTSwgaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdy b3RlOg0KPiA+DQo+ID4NCj4gPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJv bSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4gZGlyZWN0b3JpZXMuDQo+ID4gVGhpcyBk cmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVAgU2VjdXJpdHkgTWFpbnRlbmFuY2UgYW5kIEV4 dGVuc2lvbnMgb2YNCj4gdGhlIElFVEYuDQo+ID4NCj4gPiAgICAgICAgVGl0bGUgICAgICAgICAg IDogVENQIEVuY2Fwc3VsYXRpb24gb2YgSUtFIGFuZCBJUHNlYyBQYWNrZXRzDQo+ID4gICAgICAg IEF1dGhvcnMgICAgICAgICA6IFRvbW15IFBhdWx5DQo+ID4gICAgICAgICAgICAgICAgICAgICAg ICAgIFNhbXkgVG91YXRpDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgIFJhdmkgTWFudGhh DQo+ID4gICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtaXBzZWNtZS10Y3AtZW5j YXBzLTAzLnR4dA0KPiA+ICAgICAgICBQYWdlcyAgICAgICAgICAgOiAyMA0KPiA+ICAgICAgICBE YXRlICAgICAgICAgICAgOiAyMDE2LTEwLTMxDQo+ID4NCj4gPiBBYnN0cmFjdDoNCj4gPiAgIFRo aXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWV0aG9kIHRvIHRyYW5zcG9ydCBJS0UgYW5kIElQc2Vj IHBhY2tldHMNCj4gPiAgIG92ZXIgYSBUQ1AgY29ubmVjdGlvbiBmb3IgdHJhdmVyc2luZyBuZXR3 b3JrIG1pZGRsZWJveGVzIHRoYXQgbWF5DQo+ID4gICBibG9jayBJS0UgbmVnb3RpYXRpb24gb3Zl ciBVRFAuICBUaGlzIG1ldGhvZCwgcmVmZXJyZWQgdG8gYXMgVENQDQo+ID4gICBlbmNhcHN1bGF0 aW9uLCBpbnZvbHZlcyBzZW5kaW5nIGJvdGggSUtFIHBhY2tldHMgZm9yIHR1bm5lbA0KPiA+ICAg ZXN0YWJsaXNobWVudCBhcyB3ZWxsIGFzIHR1bm5lbGVkIHBhY2tldHMgdXNpbmcgRVNQIG92ZXIg YSBUQ1ANCj4gPiAgIGNvbm5lY3Rpb24uICBUaGlzIG1ldGhvZCBpcyBpbnRlbmRlZCB0byBiZSB1 c2VkIGFzIGEgZmFsbGJhY2sgb3B0aW9uDQo+ID4gICB3aGVuIElLRSBjYW5ub3QgYmUgbmVnb3Rp YXRlZCBvdmVyIFVEUC4NCj4gPg0KPiA+DQo+ID4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVz IHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1pcHNlY21lLXRjcC1lbmNhcHMvDQo+ID4NCj4gPiBUaGVyZSdzIGFs c28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4gPiBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pcHNlY21lLXRjcC1lbmNhcHMtMDMNCj4gPg0KPiA+IEEg ZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gPiBodHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1pcHNlY21lLXRjcC1lbmNh cHMtMDMNCj4gPg0KPiA+DQo+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQo+ID4NCj4gPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91 cyBGVFAgYXQ6DQo+ID4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gPg0K PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g SVBzZWMgbWFpbGluZyBsaXN0DQo+ID4gSVBzZWNAaWV0Zi5vcmc8bWFpbHRvOklQc2VjQGlldGYu b3JnPg0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCj4N Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSVBz ZWMgbWFpbGluZyBsaXN0DQo+IElQc2VjQGlldGYub3JnPG1haWx0bzpJUHNlY0BpZXRmLm9yZz4N Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYw0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklQc2VjIG1haWxpbmcgbGlz dA0KSVBzZWNAaWV0Zi5vcmc8bWFpbHRvOklQc2VjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYw0KDQo= --_000_876523B00C3F9D47BFD2B654D63DBF92BEB1549DUS70UWXCHMBA05z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJO b2tpYSBQdXJlIFRleHQgTGlnaHQiOw0KCXBhbm9zZS0xOjIgMTEgMyA0IDQgNiAyIDYgMyAzO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAw IDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0 YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiTm9raWEgUHVyZSBUZXh0IExpZ2h0Iiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46NTYuN3B0IDQyLjVwdCA1Ni43cHQgODUuMDVwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O05va2lhIFB1cmUgVGV4dCBMaWdodCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIgc2luY2UgdGhlIGRyYWZ0IGFsbG93cyBtdWx0aXBs ZSBUQ1AgY29ubmVjdGlvbnMgZm9yIHRoZSBzYW1lIHR1bm5lbDsgdGhpbmsgb2YgYSBjYXNlIGxp a2UgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtOb2tpYSBQdXJlIFRleHQgTGlnaHQmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BIHR1bm5lbCBoYXMgdHdv IENISUxEX1NBLCBlYWNoIGhhcyBpdHMgb3duIFRDUCBjb25uZWN0aW9uOyBTQS0xIGhhcyBUQ1At MSwgU0EtMiBoYXMgVENQLTI7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O05va2lhIFB1cmUgVGV4dCBMaWdo dCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciBzb21lIHJl YXNvbiBUQ1AtMiBnb2VzIGRvd24gb24gaW5pdGlhdG9yIHNpZGUgKFRDUC0xIGlzIHN0aWxsIHVw KSwgc28gaW5pdGlhdG9yIGNyZWF0ZSBhIFRDUC0zLCBmb3IgU0EtMiwgaWYgaW5pdGlhdG9yIG9u bHkgc2VuZCBJS0Uga2VlcGFsaXZlIHRvIHVwZGF0ZSByZXNwb25kZXIsDQogc28gcmVzcG9uZGVy IHdpbGwgY2hhbmdlIGJvdGggU0EtMSBhbmQgU0EtMiB0byBUQ1AtMz8gPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O05va2lhIFB1cmUgVGV4dCBMaWdodCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IElQc2VjIFttYWlsdG86aXBzZWMtYm91bmNlc0Bp ZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VmFsZXJ5IFNteXNsb3Y8YnI+DQo8Yj5TZW50 OjwvYj4gTW9uZGF5LCBOb3ZlbWJlciAxNCwgMjAxNiAxOjM2IFBNPGJyPg0KPGI+VG86PC9iPiBI dSwgSnVuIChOb2tpYSAtIFVTKTsgVG9tbXkgUGF1bHk7IElQc2VjTUUgV0c8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtJUHNlY10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1pcHNlY21lLXRjcC1l bmNhcHMtMDMudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGkgSnVuLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5mb3IgdGhlIHNlY29uZCBwYXJ0OiAm bmJzcDt5b3VyIElLRSBTQSBtdXN0IGJlIGxpbmtlZCB0byBhbGwgY2hpbGQgU0FzPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pdCBjcmVhdGVkIChpbiBvdGhlciB3b3Jkcywg Y2hpbGQgU0FzIG11c3QgcmVtZW1iZXIgd2hpY2ggSUtFIFNBPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5jcmVhdGVkIHRoZW0gYW5kIHZpc2EgdmVyc2EsIG90aGVyd2lzZSBh IGxvdCBvZiBJS0V2MiBsb2dpYzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ ZG9lc27igJl0IHdvcmspLiBTbyB0aGVyZSBpcyBubyBuZWVkIHRvIHNlbmQgcGFja2V0cyBvdmVy IGFsbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y2hpbGQgU0FzLCBpdOKA mXMgZW5vdWdoIHRvIHNlbmQgbGl2ZW5lc3MgY2hlY2sgb3ZlciBJS0UgU0EsPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zbyB0aGF0IHJlc3BvbmRlciBsZWFybiBuZXcgVENQ LUlLRSBtYXBwaW5nIGFuZCB1c2UgaXQgPG86cD4NCjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmZvciBsaW5rZWQgY2hpbGQgU0FzIGFzIHdlbGwuIDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VmFsZXJ5 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IlJVIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIGxhbmc9IlJVIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IlJVIj48YSBocmVm PSJtYWlsdG86anVuLmh1QG5va2lhLmNvbSI+SHUsIEp1biAoTm9raWEgLSBVUyk8L2E+PGJyPg0K PGI+U2VudDogPC9iPjE0INC90L7Rj9Cx0YDRjyAyMDE2INCzLiAyMjoyMTxicj4NCjxiPlRvOiA8 L2I+PGEgaHJlZj0ibWFpbHRvOnRwYXVseUBhcHBsZS5jb20iPlRvbW15IFBhdWx5PC9hPjsgPGEg aHJlZj0ibWFpbHRvOmlwc2VjQGlldGYub3JnIj4NCklQc2VjTUUgV0c8L2E+PGJyPg0KPGI+U3Vi amVjdDogPC9iPlJlOiBbSVBzZWNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaXBzZWNtZS10Y3At ZW5jYXBzLTAzLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i UlUiPlR3byBjb21tZW50czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJSVSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPjEuIFRoZSBkcmFmdCBzZWVtcyB0byBpbXBs eSB0aGF0IG9ubHkgdHVubmVsIGluaXRpYXRvciBpcyBhbGxvd2VkIHRvIGluaXRpYXRlIFRDUCBz ZXNzaW9uLCZuYnNwOyBob3dldmVyIHdoYXQgaXMgYmVoYXZpb3IgYWZ0ZXIgVENQIGNvbm5lY3Rp b24gaXMgbG9zdCBhbmQgaW5pdGlhdG9yIG5lZWQgdG8gcmUtY3JlYXRlIGl0PyBkb2VzIGl0IGRv IGl0IHJpZ2h0IGF3YXkgb3Igb25seSByZS1jcmVhdGUNCiBUQ1Agc2Vzc2lvbiB3aGVuIGluaXRp YXRvciBuZWVkIHRvIHNlbmQgc29tZSBwYWNrZXQ/IEkgYXNzdW1lIGl0IHNob3VsZCBiZSByaWdo dCBhd2F5LCBiZWNhdXNlIG90aGVyd2lzZSB0aGVyZSB3aWxsIGJlIHRyYWZmaWMgbG9zcyBpZiB0 aGUgcmVzcG9uZGVyIG5lZWQgdG8gc2VuZCBwYWNrZXQgYmVmb3JlIHRoZSBUQ1Agc2Vzc2lvbiBp cyByZS1jcmVhdGVkOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IlJVIj5TbyBpZiBteSBhYm92ZSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3Qs IEknZCBsaWtlIGRyYWZ0IHRvIGNsZWFybHkgc3RhdGUgdGhlIGJlaGF2aW9yOw0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IlJVIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJSVSI+Mi4gc2VjdGlvbiA2IG1lbnRpb24gdGhhdCBpbXBsZW1lbnRhdGlvbiBz aG91bGQgYmUgYWJsZSB0byByZWNlaXZlIGZyb20gYW55IFRDUCBzZXNzaW9uIGFuZCBub3QgZW5m b3JjaW5nIGFueSBzdHJpY3QgbWFwcGluZzsgdGhhdCdzIGZpbmUgZm9yIHJlY2VpdmluZywgaG93 ZXZlciBmb3Igc2VuZGluZyB0cmFmZmljLCBzeXN0ZW0gKHNwZWNpYWxseSByZXNwb25kZXIpIHN0 aWxsJm5ic3A7IG5lZWQNCiB0byBrbm93IHdoaWNoIFRDUCBzZXNzaW9uIHRvIHVzZSB0byByZWFj aCBwZWVyIG9mIGEgZ2l2ZW4gU0E7IGZvciBleGFtcGxlLCBJZiBOQVQgaXMgZGV0ZWN0ZWQsIHRo ZW4gaW4gY2FzZSBvZiBUQ1Agc2Vzc2lvbiBpcyBsb3N0IG9uIGluaXRpYXRvciBzaWRlIGJ1dCBz dGlsbCBleGlzdHMgb24gcmVzcG9uZGVyIHNpZGUgYW5kIGluaXRpYXRvciByZS1jcmVhdGUgdGhl IFRDUCBzZXNzaW9uLCB0aGUgbmV3IFRDUCBzZXNzaW9uIG1pZ2h0IGhhdmUNCiBhIGRpZmZlcmVu dCBOQVQgcHVibGljIHBvcnQgb3IgZXZlbiBkaWZmZXJlbnQgTkFUIHB1YmxpYyBhZGRyZXNzLCBz byB0aGUgcmVzcG9uZGVyIGNhbid0IHRlbGwgaWYgdGhlIG5ldyBUQ1Agc2Vzc2lvbiBpcyBmb3Ig YW4gZXhpc3RpbmcgU0Egb3IgYSBuZXcgdHVubmVsLCB0aGlzIG1lYW5zIGluaXRpYXRvciBuZWVk IHRvIHNlbmQgbWVzc2FnZSBmb3IgYWxsIGV4aXN0aW5nIFNBIHRoYXQgbmVlZCB0byB1c2UgdGhl IG5ldyBUQ1Agc2Vzc2lvbiBzbw0KIHRoYXQgcmVzcG9uZGVyIGNvdWxkIHVwZGF0ZSBpdHMgU0Et dG8tVENQIHNlc3Npb24gbWFwcGluZyBiZWNhdXNlIG90aGVyd2lzZSByZXNwb25kZXIgbWlnaHQg dXNlIHRoZSBvbGQgVENQIHNlc3Npb24gZm9yIG91dGdvaW5nIHRyYWZmaWMgb2YgZXhpc3Rpbmcg U0EgYW5kIHRyYWZmaWMgd2lsbCBiZSBibGFja2hvbGVkOyBpbiBzZWN0aW9uIDYsIGRyYWZ0IHN0 YXRlcyB0aGF0IGVpdGhlciBVUERBVEVfU0FfQUREUkVTUyBvciBhIElLRSBrZWVwYWxpdmUNCiBj b3VsZCBiZSB1c2VkLCBob3dldmVyIHRoZXJlIGlzIG5vIHNwZWNpZmljYXRpb24gb2YgYmVoYXZp b3IgZm9yIHVwZGF0aW5nIENISUxEX1NBIG1hcHBpbmcgd2hlbiBNT0JJS0UgaXMgbm90IHN1cHBv cnRlZDsmbmJzcDsgbWF5YmUgaW5pdGlhdG9yIHNob3VsZCBzZW5kIHNvbWUga2luZCBvZiBkdW1t eSBwYWNrZXQgb3ZlciB0aGUgQ0hJTERfU0EgdG8gdXBkYXRlIHJlc3BvbmRlcidzIG1hcHBpbmc/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i UlUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IlJVIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJV Ij4mZ3Q7IEZyb206IElQc2VjIFs8YSBocmVmPSJtYWlsdG86aXBzZWMtYm91bmNlc0BpZXRmLm9y ZyI+bWFpbHRvOmlwc2VjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgVG9tbXkg UGF1bHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJSVSI+Jmd0OyBTZW50OiBNb25kYXksIE9jdG9iZXIgMzEsIDIwMTYgOTowMSBBTTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj4m Z3Q7IFRvOiBJUHNlY01FIFdHPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iUlUiPiZndDsgU3ViamVjdDogW0lQc2VjXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLWlwc2VjbWUtdGNwLWVuY2Fwcy0wMy50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+Jmd0OyA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+Jmd0OyBIZWxs byw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJSVSI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJSVSI+Jmd0OyBJ4oCZdmUgcG9zdGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIFRD UCBlbmNhcHN1bGF0aW9uIGRyYWZ0IHdpdGggdGhlIGZvbGxvd2luZzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj4mZ3Q7IGNoYW5nZXM6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i UlUiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iUlUiPiZndDsgMS4gQWRkZWQgYSBzZWN0aW9uIHRvIGV4cGxpY2l0bHkgZGlzY3Vz cyBob3cgdG8gZmFsbGJhY2sgZnJvbSBVRFAgdG8gVENQPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPiZndDsgKHJldHJhbnNtaXNzaW9u cywgZXRjKSBiYXNlZCBvbiBmZWVkYmFjayBmcm9tIHRoZSBjaGFydGVyIGRpc2N1c3Npb24gMi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJS VSI+Jmd0OyBFeHBsYWluZWQgdGhhdCB0aGlzIG1ldGhvZCBvZiBlbmNhcHN1bGF0aW9uIGNhbiBi ZSB1c2VkIGZvciBhbnkgc3RyZWFtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPiZndDsgcHJvdG9jb2wsIGFuZCBpcyBub3QgVENQIHNw ZWNpZmljLCBiYXNlZCBvbiBmZWVkYmFjayBmcm9tIHRoZSBjaGFydGVyPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPiZndDsgZGlzY3Vz c2lvbiAzLiBDbGFyaWZpZWQgdGhlIHVzZSBvZiBtdWx0aXBsZSBUQ1AgY29ubmVjdGlvbnMgZm9y IENoaWxkIFNBcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJSVSI+Jmd0OyBiYXNlZCBvbiBKdW4gSHXigJlzIHF1ZXN0aW9uczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj4mZ3Q7 IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IlJVIj4mZ3Q7IEFsc28sIEnigJltIGhhcHB5IHRvIHNheSB0aGF0IHdl4oCZdmUgYmVlbiBkb2lu ZyBpbnRlcm9wZXJhYmlsaXR5IHRlc3RpbmcgYmV0d2VlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj4mZ3Q7IEFwcGxlIGNsaWVudHMg YW5kIENpc2NvIHNlcnZlciBmb3IgVENQIGVuY2Fwc3VsYXRpb24uIElmIGFueW9uZSBlbHNlIGhh cyBhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IlJVIj4mZ3Q7IGltcGxlbWVudGF0aW9uIHRoZXnigJlkIGxpa2UgdG8gdHJ5IG91dCwgcGxl YXNlIGxldCB1cyBrbm93ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IlJVIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj4mZ3Q7IEJlc3QsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPiZndDsgVG9tbXk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+ Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJSVSI+Jmd0OyAmZ3Q7IE9uIE9jdCAzMSwgMjAxNiwgYXQgODo1NiBBTSwgPGEgaHJlZj0i bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+DQppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmc8L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IlJVIj4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPiZndDsgJmd0OyBBIE5l dyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1E cmFmdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJSVSI+Jmd0OyBkaXJlY3Rvcmllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+Jmd0OyAmZ3Q7IFRoaXMgZHJhZnQgaXMgYSB3 b3JrIGl0ZW0gb2YgdGhlIElQIFNlY3VyaXR5IE1haW50ZW5hbmNlIGFuZCBFeHRlbnNpb25zIG9m PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i UlUiPiZndDsgdGhlIElFVEYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iUlUiPiZndDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGl0bGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBUQ1AgRW5jYXBzdWxhdGlv biBvZiBJS0UgYW5kIElQc2VjIFBhY2tldHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEF1dGhvcnMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBUb21teSBQYXVseTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj4mZ3Q7ICZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2FteSBUb3VhdGk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+Jmd0OyAmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJhdmkgTWFudGhhPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPiZndDsgJmd0 OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRmlsZW5hbWUmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBkcmFmdC1pZXRmLWlwc2VjbWUtdGNw LWVuY2Fwcy0wMy50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJSVSI+Jmd0OyAmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBQYWdlcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA6IDIwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPiZndDsgJmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgRGF0ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDIwMTYtMTAtMzE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+Jmd0OyAmZ3Q7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUi PiZndDsgJmd0OyBBYnN0cmFjdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1l bnQgZGVzY3JpYmVzIGEgbWV0aG9kIHRvIHRyYW5zcG9ydCBJS0UgYW5kIElQc2VjIHBhY2tldHM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJS VSI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7IG92ZXIgYSBUQ1AgY29ubmVjdGlvbiBmb3IgdHJhdmVy c2luZyBuZXR3b3JrIG1pZGRsZWJveGVzIHRoYXQgbWF5PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPiZndDsgJmd0OyZuYnNwOyZuYnNw OyBibG9jayBJS0UgbmVnb3RpYXRpb24gb3ZlciBVRFAuJm5ic3A7IFRoaXMgbWV0aG9kLCByZWZl cnJlZCB0byBhcyBUQ1A8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJSVSI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7IGVuY2Fwc3VsYXRpb24sIGlu dm9sdmVzIHNlbmRpbmcgYm90aCBJS0UgcGFja2V0cyBmb3IgdHVubmVsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPiZndDsgJmd0OyZu YnNwOyZuYnNwOyBlc3RhYmxpc2htZW50IGFzIHdlbGwgYXMgdHVubmVsZWQgcGFja2V0cyB1c2lu ZyBFU1Agb3ZlciBhIFRDUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IlJVIj4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsgY29ubmVjdGlvbi4mbmJz cDsgVGhpcyBtZXRob2QgaXMgaW50ZW5kZWQgdG8gYmUgdXNlZCBhcyBhIGZhbGxiYWNrIG9wdGlv bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IlJVIj4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsgd2hlbiBJS0UgY2Fubm90IGJlIG5lZ290aWF0ZWQg b3ZlciBVRFAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iUlUiPiZndDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+Jmd0OyAmZ3Q7IFRoZSBJRVRG IGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj4mZ3Q7ICZndDsg PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pcHNl Y21lLXRjcC1lbmNhcHMvIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtaXBzZWNtZS10Y3AtZW5jYXBzLzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPiZndDsgJmd0OyBU aGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+Jmd0OyAmZ3Q7 IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwc2VjbWUt dGNwLWVuY2Fwcy0wMyI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1p cHNlY21lLXRjcC1lbmNhcHMtMDM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPiZndDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj4mZ3Q7ICZndDsgQSBkaWZm IGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0OjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj4mZ3Q7ICZndDsg PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtaXBz ZWNtZS10Y3AtZW5jYXBzLTAzIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1pZXRmLWlwc2VjbWUtdGNwLWVuY2Fwcy0wMzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+Jmd0OyAmZ3Q7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPiZndDsg Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IlJVIj4mZ3Q7ICZndDsgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJSVSI+Jmd0OyAmZ3Q7IHN1Ym1pc3Npb24gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJSVSI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iUlUiPiZndDsgJmd0OyBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28g YXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPiZndDsgJmd0OyA8YSBocmVmPSJmdHA6 Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyI+DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzLzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJSVSI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPiZndDsgJmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj4mZ3Q7ICZndDsgSVBzZWMgbWFp bGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iUlUiPiZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86SVBzZWNAaWV0Zi5vcmciPklQ c2VjQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IlJVIj4mZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYyI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lwc2VjPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IlJVIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlJVIj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPiZndDsgSVBzZWMgbWFpbGluZyBsaXN0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUi PiZndDsgPGEgaHJlZj0ibWFpbHRvOklQc2VjQGlldGYub3JnIj5JUHNlY0BpZXRmLm9yZzwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJS VSI+Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lw c2VjIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWM8L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUi Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iUlUiPklQc2Vj IG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IlJVIj48YSBocmVmPSJtYWlsdG86SVBzZWNAaWV0Zi5vcmciPklQc2VjQGll dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IlJVIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lwc2VjIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjPC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IlJVIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_876523B00C3F9D47BFD2B654D63DBF92BEB1549DUS70UWXCHMBA05z_-- From nobody Mon Nov 14 17:56:17 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D27129651 for ; Mon, 14 Nov 2016 17:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 YJMImuvn1K5k for ; Mon, 14 Nov 2016 17:56:14 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E4A41295CA for ; Mon, 14 Nov 2016 17:56:14 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id uAF1u3AL018510 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Nov 2016 03:56:03 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uAF1u3LP002227; Tue, 15 Nov 2016 03:56:03 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22570.27443.702141.900110@fireball.acr.fi> Date: Tue, 15 Nov 2016 03:56:03 +0200 From: Tero Kivinen To: "Scott Fluhrer \(sfluhrer\)" In-Reply-To: <970eaf58d0b94a7ba3082ddc8b276462@XCH-RTP-006.cisco.com> References: <6c1585204f6a4598b6e40b05912ba4c4@XCH-RTP-006.cisco.com> <5829b397.01d6620a.9dfb5.4373@mx.google.com> <970eaf58d0b94a7ba3082ddc8b276462@XCH-RTP-006.cisco.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 11 min X-Total-Time: 12 min Archived-At: Cc: "IPsecme WG \(ipsec@ietf.org\)" , Valery Smyslov Subject: Re: [IPsec] FW: Quantum Resistance Requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 01:56:16 -0000 Scott Fluhrer (sfluhrer) writes: > The main reason we wouldn=E2=80=99t have considered that is a possibl= e > complication to crypto hardware; if we assume that we had hardware > that did most of the crypto calculations internally, it might keep > the SK=5Fd value internally, and might not give us an easy way to > modify it. In contrast, the nonces are inputs to the hardware, and > so that hardware is agnostic to whether we=E2=80=99re actually giving= it the > nonces that actually appeared in the packets, or whether we=E2=80=99r= e > giving them modified versions of it. One of the issues of using Ni' =3D PRF(PPK, Ni) instead of modifying th= e SK=5Fd calculation is that the system needs to keep the PPK in memory permanently. I.e., if we only modify the SK=5Fd calculation, i.e., define SK=5Fd' =3D PRF(PPK, SK=5Fd) or something like that, then we can clear the PPK in memory immediately after that point, and we can drop permissions that allows us access to PPK. This will provide better security as attacks similar to the heartbleed cannot read PPK from the memory. Also it is clear that even if PPK is changed during the lifetime of the IKE SA we do not enter the issue that whether we need to use old or new PPK. Especially if some kind of HSM is used to keep PPK, it might not allow access the old PPKs after they are expired. I think the PPK is so important that when you are adding support for the QR to your implementation you want to move the PPK handing in to the hardware crypto module so PPK will be protected, and not add it as addon to the crypto module. --=20 kivinen@iki.fi From nobody Mon Nov 14 18:18:56 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D01129665 for ; Mon, 14 Nov 2016 18:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 9Q5KBL91l5P2 for ; Mon, 14 Nov 2016 18:18:52 -0800 (PST) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 DC6581296A1 for ; Mon, 14 Nov 2016 18:18:51 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id x23so57900316pgx.1 for ; Mon, 14 Nov 2016 18:18:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:to:from:subject:date:importance :thread-topic:in-reply-to:references; bh=FTdo014DZB/heBWMjdVOLFBWX20PwEXvg4Q1pLsQOwg=; b=vZ05KTbJryHqOCVyiNi6kzgo6wt1arf2OgRWHwdCe4r1ut0mGonwuXW9HQUIifkROv iVfXW++oEy+GefkFV+USIUD6tJsmfOWdZSvVnci30yIpHIgatZ/M8S8A55uZ2fPXJimr PMFR233CXR56COFhm3M66f+fxg1wSR0gp25dQ8uKNhKUzPGoF7lXDo2v9R1Kb3ruDew4 rwhGZEFZp17TqXiMhJFGJhACW7Q5uCUlEHTVswJjPuCOG96LG+XUJjcRiUD9UnvawBr+ T6i+a/628uLahOqEycSaUgR2xdSz4udVOESzdx0MQG6cqoyJHLvn6z2D6NIMlNvdAc1g 64oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance:thread-topic:in-reply-to:references; bh=FTdo014DZB/heBWMjdVOLFBWX20PwEXvg4Q1pLsQOwg=; b=O39W0TGt7BEaG6r2Bj4ZEx3bFOmIPzUEgJtUc1ZA713SbIRERBYM5qzga9O0s4ajic 6t/Xy3EfrHrzPtZWmjgR99FnTkhE7/HolmXibSCjJhFtPP7iFldSsyxOxOCqY7NHCM14 3G9qlCPYGiQRAH+GqY5Gt8qAHpykHfQ5yYtZd5EQNEzfnGD9W8ZKbPHs3aMvQ5GamAsS Zst4EGXTcOQnEzbbFgPXlbd+bYQN2Y7viIGQbM9VS1ltzy46PB3emJfOI7u2RHLkfzgs 3LnnHScUMHLLHXQjOb6jmyWgdbhxkQKzLQF6sIMvBUvD83+NayIM410Ce7Ala5r1qgTq FjHA== X-Gm-Message-State: ABUngveHLQWNmjrhEILjyV9ycGb4isYJvxc7qJo0JmhzrZRz2ByMf+WC7orHxnVIi5gyMA== X-Received: by 10.99.245.21 with SMTP id w21mr18187112pgh.5.1479176331382; Mon, 14 Nov 2016 18:18:51 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:6c83:3571:aa94:5239? ([2001:67c:370:128:6c83:3571:aa94:5239]) by smtp.gmail.com with ESMTPSA id p79sm2746028pfj.51.2016.11.14.18.18.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Nov 2016 18:18:50 -0800 (PST) Message-ID: <582a708a.d222620a.fd93f.a655@mx.google.com> MIME-Version: 1.0 To: "Hu, Jun (Nokia - US)" , Tommy Pauly , IPsecME WG From: Valery Smyslov Date: Tue, 15 Nov 2016 11:18:53 +0900 Importance: normal X-Priority: 3 Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt In-Reply-To: <876523B00C3F9D47BFD2B654D63DBF92BEB1549D@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <147792938094.32373.833800643936554773.idtracker@ietfa.amsl.com> <61A7C96D-66A0-4BA7-82BE-277CBE13ED45@apple.com> <876523B00C3F9D47BFD2B654D63DBF92BEB12F24@US70UWXCHMBA05.zam.alcatel-lucent.com> <582a2e53.42212e0a.df555.6ec3@mx.google.com> <876523B00C3F9D47BFD2B654D63DBF92BEB1549D@US70UWXCHMBA05.zam.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="_77E07B42-35A5-491D-9AD1-07A628A3D977_" Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 02:18:54 -0000 --_77E07B42-35A5-491D-9AD1-07A628A3D977_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" What=E2=80=99s wrong with that? As far as I understand the draft, the mapping between IKE/IPsec and TCP is = loose, so it seems that such a scenario is OK (Tommy corrects me if I=E2=80=99m wr= ong).=20 Do you have any problems with it? From: Hu, Jun (Nokia - US) Sent: 15 =D0=BD=D0=BE=D1=8F=D0=B1=D1=80=D1=8F 2016 =D0=B3. 10:48 To: Valery Smyslov; Tommy Pauly; IPsecME WG Subject: RE: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt However since the draft allows multiple TCP connections for the same tunnel= ; think of a case like following: A tunnel has two CHILD_SA, each has its own TCP connection; SA-1 has TCP-1,= SA-2 has TCP-2; For some reason TCP-2 goes down on initiator side (TCP-1 is still up), so i= nitiator create a TCP-3, for SA-2, if initiator only send IKE keepalive to = update responder, so responder will change both SA-1 and SA-2 to TCP-3?=20 From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Valery Smyslov Sent: Monday, November 14, 2016 1:36 PM To: Hu, Jun (Nokia - US); Tommy Pauly; IPsecME WG Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt Hi Jun, for the second part: =C2=A0your IKE SA must be linked to all child SAs it created (in other words, child SAs must remember which IKE SA created them and visa versa, otherwise a lot of IKEv2 logic doesn=E2=80=99t work). So there is no need to send packets over all child SAs, it=E2=80=99s enough to send liveness check over IKE SA, so that responder learn new TCP-IKE mapping and use it=20 for linked child SAs as well.=20 Regards, Valery. From: Hu, Jun (Nokia - US) Sent: 14 =D0=BD=D0=BE=D1=8F=D0=B1=D1=80=D1=8F 2016 =D0=B3. 22:21 To: Tommy Pauly; IPsecME WG Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt Two comments: 1. The draft seems to imply that only tunnel initiator is allowed to initia= te TCP session,=C2=A0 however what is behavior after TCP connection is lost= and initiator need to re-create it? does it do it right away or only re-cr= eate TCP session when initiator need to send some packet? I assume it shoul= d be right away, because otherwise there will be traffic loss if the respon= der need to send packet before the TCP session is re-created; So if my above understanding is correct, I'd like draft to clearly state th= e behavior;=20 2. section 6 mention that implementation should be able to receive from any= TCP session and not enforcing any strict mapping; that's fine for receivin= g, however for sending traffic, system (specially responder) still=C2=A0 ne= ed to know which TCP session to use to reach peer of a given SA; for exampl= e, If NAT is detected, then in case of TCP session is lost on initiator sid= e but still exists on responder side and initiator re-create the TCP sessio= n, the new TCP session might have a different NAT public port or even diffe= rent NAT public address, so the responder can't tell if the new TCP session= is for an existing SA or a new tunnel, this means initiator need to send m= essage for all existing SA that need to use the new TCP session so that res= ponder could update its SA-to-TCP session mapping because otherwise respond= er might use the old TCP session for outgoing traffic of existing SA and tr= affic will be blackholed; in section 6, draft states that either UPDATE_SA_= ADDRESS or a IKE keepalive could be used, however there is no specification= of behavior for updating CHILD_SA mapping when MOBIKE is not supported;=C2= =A0 maybe initiator should send some kind of dummy packet over the CHILD_SA= to update responder's mapping? > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tommy Pauly > Sent: Monday, October 31, 2016 9:01 AM > To: IPsecME WG > Subject: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt >=20 > Hello, >=20 > I=E2=80=99ve posted a new version of the TCP encapsulation draft with the= following > changes: >=20 > 1. Added a section to explicitly discuss how to fallback from UDP to TCP > (retransmissions, etc) based on feedback from the charter discussion 2. > Explained that this method of encapsulation can be used for any stream > protocol, and is not TCP specific, based on feedback from the charter > discussion 3. Clarified the use of multiple TCP connections for Child SAs= , > based on Jun Hu=E2=80=99s questions >=20 > Also, I=E2=80=99m happy to say that we=E2=80=99ve been doing interoperabi= lity testing between > Apple clients and Cisco server for TCP encapsulation. If anyone else has = an > implementation they=E2=80=99d like to try out, please let us know! >=20 > Best, > Tommy >=20 > > On Oct 31, 2016, at 8:56 AM, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the IP Security Maintenance and Extensions= of > the IETF. > > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Title=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : TCP Encapsulation of IKE and IPsec P= ackets > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Authors=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 : Tommy Pauly > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Samy Touati > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Ravi Mantha > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Filename=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 : draft-ietf-ipsecme-tcp-encaps-03.txt > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Pages=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 20 > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Date=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 2016-10-31 > > > > Abstract: > >=C2=A0=C2=A0 This document describes a method to transport IKE and IPsec= packets > >=C2=A0=C2=A0 over a TCP connection for traversing network middleboxes th= at may > >=C2=A0=C2=A0 block IKE negotiation over UDP.=C2=A0 This method, referred= to as TCP > >=C2=A0=C2=A0 encapsulation, involves sending both IKE packets for tunnel > >=C2=A0=C2=A0 establishment as well as tunneled packets using ESP over a = TCP > >=C2=A0=C2=A0 connection.=C2=A0 This method is intended to be used as a f= allback option > >=C2=A0=C2=A0 when IKE cannot be negotiated over UDP. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-03 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-tcp-encaps-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.i= etf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_77E07B42-35A5-491D-9AD1-07A628A3D977_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

What=E2=80=99s wron= g with that?

 

As far as I understand the draft, = the mapping between IKE/IPsec and TCP is loose,

so it seems that such a scenario is OK (T= ommy corrects me if I=E2=80=99m wrong).

Do you have any problems with it?

 

=  

 

 

From: Hu, Jun (Nokia - US)
Sent: 15 =D0=BD=D0=BE= =D1=8F=D0=B1=D1=80=D1=8F 2016 =D0=B3. 10:48
To: Valery Smyslov; = Tommy Pauly; IPsecME WG
Sub= ject: RE: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt

<= /div>

 

Ho= wever since the draft allows multiple TCP connections for the same tunnel; = think of a case like following:

<= span lang=3DEN-US style=3D'font-family:"Nokia Pure Text Light";color:#1F497= D'>A tunnel has two CHILD_SA, each has its own TCP connection; SA-1 has TCP= -1, SA-2 has TCP-2;

For some = reason TCP-2 goes down on initiator side (TCP-1 is still up), so initiator = create a TCP-3, for SA-2, if initiator only send IKE keepalive to update re= sponder, so responder will change both SA-1 and SA-2 to TCP-3? <= /span>

 

From: IPsec [mailto:ips= ec-bounces@ietf.org] On Behalf Of Valery Smyslov
Sent: Mon= day, November 14, 2016 1:36 PM
To: Hu, Jun (Nokia - US); Tommy Pa= uly; IPsecME WG
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsec= me-tcp-encaps-03.txt

=  

Hi Jun,

 

f= or the second part:  your IKE SA must be linked to all child SAs<= /o:p>

it created (in othe= r words, child SAs must remember which IKE SA

created them and visa versa, otherwise a lo= t of IKEv2 logic

doesn=E2=80=99t work). So there is no need to send packets over all=

child SAs, it=E2= =80=99s enough to send liveness check over IKE SA,

so that responder learn new TCP-IKE ma= pping and use it

for linked child SAs as well.

 

Regards,

Valery.

 

 

From: Hu, Jun (Nokia - US)
Sent: 14 =D0=BD=D0=BE=D1=8F=D0=B1=D1=80=D1=8F 2016 =D0=B3. 22:2= 1
To: Tommy Pauly; IPsecME WG
Subject: Re: [IPsec] I= -D Action: draft-ietf-ipsecme-tcp-encaps-03.txt

 

Two comments:=

 

1.= The draft seems to imply that only tunnel initiator is allowed to initiate= TCP session,  however what is behavior after TCP connection is lost a= nd initiator need to re-create it? does it do it right away or only re-crea= te TCP session when initiator need to send some packet? I assume it should = be right away, because otherwise there will be traffic loss if the responde= r need to send packet before the TCP session is re-created;

So if my above understanding is correct, I'd like draft to clearly= state the behavior;

 

 

2. section 6 mention= that implementation should be able to receive from any TCP session and not= enforcing any strict mapping; that's fine for receiving, however for sendi= ng traffic, system (specially responder) still  need to know which TCP= session to use to reach peer of a given SA; for example, If NAT is detecte= d, then in case of TCP session is lost on initiator side but still exists o= n responder side and initiator re-create the TCP session, the new TCP sessi= on might have a different NAT public port or even different NAT public addr= ess, so the responder can't tell if the new TCP session is for an existing = SA or a new tunnel, this means initiator need to send message for all exist= ing SA that need to use the new TCP session so that responder could update = its SA-to-TCP session mapping because otherwise responder might use the old= TCP session for outgoing traffic of existing SA and traffic will be blackh= oled; in section 6, draft states that either UPDATE_SA_ADDRESS or a IKE kee= palive could be used, however there is no specification of behavior for upd= ating CHILD_SA mapping when MOBIKE is not supported;  maybe initiator = should send some kind of dummy packet over the CHILD_SA to update responder= 's mapping?

 

 

> -----Original Message----= -

> From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tommy Pauly

<= p class=3DMsoNormal>> Sent: Monday, October 31, 2016 9:01 AM

> To: IPsecME WG

> Subject: [IPs= ec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt

>

> Hello,

>

> I=E2=80=99ve posted a new version of the TCP en= capsulation draft with the following

> changes:<= /p>

>

> 1. Added a secti= on to explicitly discuss how to fallback from UDP to TCP

> (retransmissions, etc) based on feedback from the charter discus= sion 2.

> Explained that this method of encapsul= ation can be used for any stream

> protocol, and= is not TCP specific, based on feedback from the charter

> discussion 3. Clarified the use of multiple TCP connections for = Child SAs,

> based on Jun Hu=E2=80=99s questions=

>

> Also, I=E2=80= =99m happy to say that we=E2=80=99ve been doing interoperability testing be= tween

> Apple clients and Cisco server for TCP e= ncapsulation. If anyone else has an

> implementa= tion they=E2=80=99d like to try out, please let us know!

>

> Best,

>= Tommy

>

> > On O= ct 31, 2016, at 8:56 AM, intern= et-drafts@ietf.org wrote:

> >

> >

> > A New Internet-Dra= ft is available from the on-line Internet-Drafts

&g= t; directories.

> > This draft is a work item= of the IP Security Maintenance and Extensions of

&= gt; the IETF.

> >

>= ; >        Title   &nb= sp;       : TCP Encapsulation of IKE and IPse= c Packets

> >     &n= bsp;  Authors         : Tommy = Pauly

> >      =             &nb= sp;       Samy Touati

> >           = ;            &n= bsp;  Ravi Mantha

> >    =     Filename        : dra= ft-ietf-ipsecme-tcp-encaps-03.txt

> >  &= nbsp;     Pages      &nbs= p;    : 20

> >   &nb= sp;    Date        &= nbsp;   : 2016-10-31

> >

> > Abstract:

> > &n= bsp; This document describes a method to transport IKE and IPsec packets

> >   over a TCP connection for trave= rsing network middleboxes that may

> > &= nbsp; block IKE negotiation over UDP.  This method, referred to as TCP=

> >   encapsulation, involves send= ing both IKE packets for tunnel

> > &nbs= p; establishment as well as tunneled packets using ESP over a TCP

> >   connection.  This method is inten= ded to be used as a fallback option

> > =   when IKE cannot be negotiated over UDP.

>= >

> >

> > T= he IETF datatracker status page for this draft is:

= > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/<= /a>

> >

> > The= re's also a htmlized version available at:

> >= ; = https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-03

> >

> > A diff from the p= revious version is available at:

> > h= ttps://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-tcp-encaps-03

=

> >

> >

> > Please note that it may take a couple of minutes fr= om the time of

> > submission until the htmli= zed version and diff are available at tools.ietf.org.

> >

> > Internet-Drafts are also ava= ilable by anonymous FTP at:

> > ftp://ftp.ietf.org/internet-drafts/<= /p>

> >

> > _______= ________________________________________

> > = IPsec mailing list

> > IPsec@ietf.org

> > https://www.ietf.org/mailman/= listinfo/ipsec

>

&g= t; _______________________________________________

= > IPsec mailing list

> IPsec@ietf.org

> https://www.ietf.org/mailman/listi= nfo/ipsec

_____________________________________= __________

IPsec mailing list

IPsec@ietf.org

https://www.ie= tf.org/mailman/listinfo/ipsec

 =

 

= --_77E07B42-35A5-491D-9AD1-07A628A3D977_-- From nobody Mon Nov 14 18:26:47 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEBA129698 for ; Mon, 14 Nov 2016 18:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.797 X-Spam-Level: X-Spam-Status: No, score=-5.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 mjblq0kqJn0B for ; Mon, 14 Nov 2016 18:26:43 -0800 (PST) Received: from mail-in2.asia.apple.com (mail-out.asia.apple.com [17.82.254.64]) (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 A9A9A12969A for ; Mon, 14 Nov 2016 18:26:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1479176754; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZgQg5DVFurk7SUPKWwjBJLCkdpJb3DRYj6C0vYaFygM=; b=Vl+6rwxeRc0TFIvmvnnLa+ScRqLdHPEN8sQHwOlJD/zyZgea0eHX4lf1ASWj2dul PzJDvA/Bgg7RWI9rZNQdhFHQlD3dcJObHDD+sM/WjtHex35hlIiIBT+sBXjCPoOI Ngn3iv1VqdJDzsFmzSctZG+Bjl3Y5YO1MfoPRhXjZxX2TOGd5nszfFz/ec1mSg6f a16mV08Mz7gmdI3GEeqjjXxvXt8hxZD25ikmq61RJOKkJTxyh7DyoQFlGlOZYarW unpu7nM2SSM1Ozf/+mLntlNXu3rjAfk3DUXMg1nf+wzQXUCmCcRO8pZI2wrGveou qyEMv8cSAHXT+wbihph0OQ==; Received: from relay1.asia.apple.com ( [17.82.200.18]) by mail-in2.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 04.4A.24048.2327A285; Tue, 15 Nov 2016 10:25:54 +0800 (MYT) X-AuditID: 1152fe06-ac30b9a000005df0-11-582a7232dc97 Received: from sng-mmpp-sz01.asia.apple.com ( [17.84.80.62]) by relay1.asia.apple.com (Apple Singapore relay) with SMTP id 3C.52.08629.F527A285; Tue, 15 Nov 2016 10:26:39 +0800 (MYT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_S7C0ihV4rZbr2scir1yhBw)" Received: from [17.83.124.96] (unknown [17.83.124.96]) by sng-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OGN001IVW450NE0@sng-mmpp-sz01.asia.apple.com>; Tue, 15 Nov 2016 10:26:36 +0800 (SGT) Sender: tpauly@apple.com From: Tommy Pauly X-Priority: 3 In-reply-to: <582a708a.d222620a.fd93f.a655@mx.google.com> Date: Tue, 15 Nov 2016 11:26:28 +0900 Message-id: <3FDBD376-F2F4-4AB1-AA40-E64C056025D6@apple.com> References: <147792938094.32373.833800643936554773.idtracker@ietfa.amsl.com> <61A7C96D-66A0-4BA7-82BE-277CBE13ED45@apple.com> <876523B00C3F9D47BFD2B654D63DBF92BEB12F24@US70UWXCHMBA05.zam.alcatel-lucent.com> <582a2e53.42212e0a.df555.6ec3@mx.google.com> <876523B00C3F9D47BFD2B654D63DBF92BEB1549D@US70UWXCHMBA05.zam.alcatel-lucent.com> <582a708a.d222620a.fd93f.a655@mx.google.com> To: Valery Smyslov , "Hu, Jun (Nokia - US)" X-Mailer: Apple Mail (2.3252) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42IRDDohpGtUpBVhcOaUkMX+LS/YLD78ncBo cePDTDYHZo+ds+6yeyxZ8pPJ4+6tS0wBzFFcNimpOZllqUX6dglcGYfOLGAs2H6FqWLnwiPM DYxblzN1MXJySAiYSGzpvsvSxcjFISSwm1Hi773D7DCJWe+amCESOxglft5eBNbBKyAo8WPy PRYQm1kgTOLy3K1sILaQwCQmiUOzS7oYOTiEBSQkNu9JBAkLC7hK3D12BqycTUBF4vi3DcwQ 83klZrQ/BYtzClhKLOg8CDaGRUBVYuONZ1Dj5SV6/29kBBnJK2Aj8eJ4GsQ5zcwS7RN+gd0p IhAgcWPFF6iZshIrn25kBSmSENjDJrFsx2eWCYzCs5CcPQvJ2bOA5jILqEtMmZILEdaWePLu AiuErSax8PciJmTxBYxsqxjFcxMzc3Qz84z0EoszE/USCwpyUvWS83M3MYJj6B/bDsYFrw0P MQpwMCrx8CZmakUIsSaWFVfmHmKU4GBWEuHNywMK8aYkVlalFuXHF5XmpBYfYpTmYFES59XI 2h4uJJCeWJKanZpakFoEk2Xi4JRqYKzqPrN0ZrPWjmlTDt8U1nh+LT7kua/65eupWjndMYK/ LpSeuef3UDln5UnLE8WTJDYGF1juVfjeWfT43wvNxry7wvfbYnTnvTp+08ddkdXDZqa9quSE yqtLmRNSjoX0B243qjI7z3fgSvDik3nZhjOi//M2upZdq7qTL8t6l6f9ltgfUe2/IkosxRmJ hlrMRcWJAChqj5GdAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUiGBJgpxtfpBVh0LjC1GL/lhdsFh/+TmC0 uPFhJpsDs8fOWXfZPZYs+cnkcffWJaYA5igum5TUnMyy1CJ9uwSujENnFjAWbL/CVLFz4RHm Bsaty5m6GDk5JARMJGa9a2LuYuTiEBLYwSjx8/YisASvgKDEj8n3WEBsZoEwictzt7KB2EIC k5gkDs0u6WLk4BAWkJDYvCcRJCws4Cpx99gZsHI2ARWJ4982MEPM55WY0f4ULM4pYCmxoPMg 2BgWAVWJjTeeQY2Xl+j9v5ERZCSvgI3Ei+NpEOc0M0u0T/jFDlIjIhAgcWPFF6iZshIrn25k ncAoMAvJpbOQXDoLaBSzgLrElCm5EGFtiSfvLrBC2GoSC38vYkIWX8DItopRtCg1J7HSUC+x ODNRL7GgICdVLzk/dxMjKOSDTgjtYPy43+AQowAHoxIP76RMrQgh1sSy4srcQ4wSHMxKIrx5 eUAh3pTEyqrUovz4otKc1OJDjNIcLErivDmPP4YLCaQnlqRmp6YWpBbBZJk4OKUaGP11I/pS fBdaMtrMV5vGJK7PdrebqdZ02Qw2zo7Zh3PebQ91V1Ezs5lTdua9w+ncrkvJ9xh3yc944rqU p+/6/5mVTqZTplltLLaUrr/0oSnm1Tf9q4zzu/aJ/Q1WvfJe47KU1ArxXT6Jn0sYRNuvXuFz nc8syrsvdpHoK4bDNgdEDpR/m77aXomlOCPRUIu5qDgRAOvJToh1AgAA Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 02:26:45 -0000 --Boundary_(ID_S7C0ihV4rZbr2scir1yhBw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable I agree with Valery that there doesn't seem to be any problem here. The = statement that the initiator is "creating a TCP-3 for SA-2" is not a = scenario that we want to support, because there is not strict mapping = between TCP connections and SAs. The responder can respond to both SAs = on the same TCP connection, or it may not. Both sides should support any = combination, and any implementation that refuses to accept packets will = not be compliant with the spec. Thanks, Tommy > On Nov 15, 2016, at 11:18 AM, Valery Smyslov wrote: >=20 > What=E2=80=99s wrong with that? > =20 > As far as I understand the draft, the mapping between IKE/IPsec and = TCP is loose, > so it seems that such a scenario is OK (Tommy corrects me if I=E2=80=99m= wrong).=20 > Do you have any problems with it? > =20 > =20 > =20 > =20 > From: Hu, Jun (Nokia - US) > Sent: 15 =D0=BD=D0=BE=D1=8F=D0=B1=D1=80=D1=8F 2016 =D0=B3. 10:48 > To: Valery Smyslov ; Tommy Pauly = ; IPsecME WG > Subject: RE: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt > =20 > However since the draft allows multiple TCP connections for the same = tunnel; think of a case like following: > A tunnel has two CHILD_SA, each has its own TCP connection; SA-1 has = TCP-1, SA-2 has TCP-2; > For some reason TCP-2 goes down on initiator side (TCP-1 is still up), = so initiator create a TCP-3, for SA-2, if initiator only send IKE = keepalive to update responder, so responder will change both SA-1 and = SA-2 to TCP-3?=20 > =20 > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Valery = Smyslov > Sent: Monday, November 14, 2016 1:36 PM > To: Hu, Jun (Nokia - US); Tommy Pauly; IPsecME WG > Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt > =20 > Hi Jun, > =20 > for the second part: your IKE SA must be linked to all child SAs > it created (in other words, child SAs must remember which IKE SA > created them and visa versa, otherwise a lot of IKEv2 logic > doesn=E2=80=99t work). So there is no need to send packets over all > child SAs, it=E2=80=99s enough to send liveness check over IKE SA, > so that responder learn new TCP-IKE mapping and use it=20 > for linked child SAs as well.=20 > =20 > Regards, > Valery. > =20 > =20 > From: Hu, Jun (Nokia - US) > Sent: 14 =D0=BD=D0=BE=D1=8F=D0=B1=D1=80=D1=8F 2016 =D0=B3. 22:21 > To: Tommy Pauly ; IPsecME WG = > Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt > =20 > Two comments: > =20 > 1. The draft seems to imply that only tunnel initiator is allowed to = initiate TCP session, however what is behavior after TCP connection is = lost and initiator need to re-create it? does it do it right away or = only re-create TCP session when initiator need to send some packet? I = assume it should be right away, because otherwise there will be traffic = loss if the responder need to send packet before the TCP session is = re-created; > So if my above understanding is correct, I'd like draft to clearly = state the behavior; > =20 > =20 > 2. section 6 mention that implementation should be able to receive = from any TCP session and not enforcing any strict mapping; that's fine = for receiving, however for sending traffic, system (specially responder) = still need to know which TCP session to use to reach peer of a given = SA; for example, If NAT is detected, then in case of TCP session is lost = on initiator side but still exists on responder side and initiator = re-create the TCP session, the new TCP session might have a different = NAT public port or even different NAT public address, so the responder = can't tell if the new TCP session is for an existing SA or a new tunnel, = this means initiator need to send message for all existing SA that need = to use the new TCP session so that responder could update its SA-to-TCP = session mapping because otherwise responder might use the old TCP = session for outgoing traffic of existing SA and traffic will be = blackholed; in section 6, draft states that either UPDATE_SA_ADDRESS or = a IKE keepalive could be used, however there is no specification of = behavior for updating CHILD_SA mapping when MOBIKE is not supported; = maybe initiator should send some kind of dummy packet over the CHILD_SA = to update responder's mapping? > =20 > =20 > > -----Original Message----- > > From: IPsec [mailto:ipsec-bounces@ietf.org = ] On Behalf Of Tommy Pauly > > Sent: Monday, October 31, 2016 9:01 AM > > To: IPsecME WG > > Subject: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt > > > > Hello, > > > > I=E2=80=99ve posted a new version of the TCP encapsulation draft = with the following > > changes: > > > > 1. Added a section to explicitly discuss how to fallback from UDP to = TCP > > (retransmissions, etc) based on feedback from the charter discussion = 2. > > Explained that this method of encapsulation can be used for any = stream > > protocol, and is not TCP specific, based on feedback from the = charter > > discussion 3. Clarified the use of multiple TCP connections for = Child SAs, > > based on Jun Hu=E2=80=99s questions > > > > Also, I=E2=80=99m happy to say that we=E2=80=99ve been doing = interoperability testing between > > Apple clients and Cisco server for TCP encapsulation. If anyone else = has an > > implementation they=E2=80=99d like to try out, please let us know! > > > > Best, > > Tommy > > > > > On Oct 31, 2016, at 8:56 AM, internet-drafts@ietf.org = wrote: > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > This draft is a work item of the IP Security Maintenance and = Extensions of > > the IETF. > > > > > > Title : TCP Encapsulation of IKE and IPsec = Packets > > > Authors : Tommy Pauly > > > Samy Touati > > > Ravi Mantha > > > Filename : draft-ietf-ipsecme-tcp-encaps-03.txt > > > Pages : 20 > > > Date : 2016-10-31 > > > > > > Abstract: > > > This document describes a method to transport IKE and IPsec = packets > > > over a TCP connection for traversing network middleboxes that = may > > > block IKE negotiation over UDP. This method, referred to as TCP > > > encapsulation, involves sending both IKE packets for tunnel > > > establishment as well as tunneled packets using ESP over a TCP > > > connection. This method is intended to be used as a fallback = option > > > when IKE cannot be negotiated over UDP. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ = > > > > > > There's also a htmlized version available at: > > > https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-03 = > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-tcp-encaps-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/ = > > > > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec = > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec = > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = > =20 > =20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = --Boundary_(ID_S7C0ihV4rZbr2scir1yhBw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
I agree with Valery that there doesn't seem = to be any problem here. The statement that the initiator is "creating a = TCP-3 for SA-2" is not a scenario that we want to support, because there = is not strict mapping between TCP connections and SAs. The responder can = respond to both SAs on the same TCP connection, or it may not. Both = sides should support any combination, and any implementation that = refuses to accept packets will not be compliant with the spec.

Thanks,
Tommy

On Nov 15, 2016, at 11:18 AM, Valery Smyslov = <svanru@gmail.com> wrote:

What=E2=80=99s wrong with that?
 
As far as I understand the draft, the mapping = between IKE/IPsec and TCP is loose,
so it = seems that such a scenario is OK (Tommy corrects me if I=E2=80=99m = wrong). 
Do you have any problems with it?
 
 
 
 
From: Hu, Jun (Nokia - US)
Sent: 15 =D0=BD=D0=BE=D1=8F=D0=B1= =D1=80=D1=8F 2016 =D0=B3. 10:48
To: Valery Smyslov; Tommy Pauly; IPsecME WG
Subject: RE: [IPsec] I-D Action: = draft-ietf-ipsecme-tcp-encaps-03.txt
 
However since the draft allows multiple TCP connections for = the same tunnel; think of a case like following:
A tunnel has two CHILD_SA, each has its = own TCP connection; SA-1 has TCP-1, SA-2 has TCP-2;
For some reason TCP-2 goes down on = initiator side (TCP-1 is still up), so initiator create a TCP-3, for = SA-2, if initiator only send IKE keepalive to update responder, so = responder will change both SA-1 and SA-2 to TCP-3? 
 
From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf = Of Valery = Smyslov
Sent: Monday, November 14, 2016 = 1:36 PM
To: Hu, Jun (Nokia - US); Tommy = Pauly; IPsecME WG
Subject: Re: [IPsec] I-D Action: = draft-ietf-ipsecme-tcp-encaps-03.txt
 
Hi Jun,
 
for the = second part:  your IKE SA must be linked to all child SAs
it created (in other words, child SAs must = remember which IKE SA
created = them and visa versa, otherwise a lot of IKEv2 logic
doesn=E2=80=99t work). So there is no need to = send packets over all
child = SAs, it=E2=80=99s enough to send liveness check over IKE SA,
so that responder learn new TCP-IKE mapping = and use it 
for linked child SAs as well. 
 
Regards,
Valery.
 
 
From: Hu, Jun (Nokia - US)
Sent: 14 =D0=BD=D0=BE=D1=8F=D0=B1= =D1=80=D1=8F 2016 =D0=B3. 22:21
To: Tommy Pauly; IPsecME WG
Subject: Re: [IPsec] I-D Action: = draft-ietf-ipsecme-tcp-encaps-03.txt
 
Two comments:
 
1. The draft seems to imply that only tunnel initiator is = allowed to initiate TCP session,  however what is behavior after = TCP connection is lost and initiator need to re-create it? does it do it = right away or only re-create TCP session when initiator need to send = some packet? I assume it should be right away, because otherwise there = will be traffic loss if the responder need to send packet before the TCP = session is re-created;
So if my = above understanding is correct, I'd like draft to clearly state the = behavior;
 
 
2. = section 6 mention that implementation should be able to receive from any = TCP session and not enforcing any strict mapping; that's fine for = receiving, however for sending traffic, system (specially responder) = still  need to know which TCP session to use to reach peer of a = given SA; for example, If NAT is detected, then in case of TCP session = is lost on initiator side but still exists on responder side and = initiator re-create the TCP session, the new TCP session might have a = different NAT public port or even different NAT public address, so the = responder can't tell if the new TCP session is for an existing SA or a = new tunnel, this means initiator need to send message for all existing = SA that need to use the new TCP session so that responder could update = its SA-to-TCP session mapping because otherwise responder might use the = old TCP session for outgoing traffic of existing SA and traffic will be = blackholed; in section 6, draft states that either UPDATE_SA_ADDRESS or = a IKE keepalive could be used, however there is no specification of = behavior for updating CHILD_SA mapping when MOBIKE is not = supported;  maybe initiator should send some kind of dummy packet = over the CHILD_SA to update responder's mapping?
 
 
> -----Original = Message-----
> From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tommy = Pauly
> Sent: Monday, October = 31, 2016 9:01 AM
> To: IPsecME = WG
> Subject: [IPsec] I-D = Action: draft-ietf-ipsecme-tcp-encaps-03.txt
>
> = Hello,
>
> I=E2=80=99ve posted a new version = of the TCP encapsulation draft with the following
> changes:
>
> 1. Added a = section to explicitly discuss how to fallback from UDP to TCP
> (retransmissions, etc) based on = feedback from the charter discussion 2.
> Explained that this method of encapsulation can be used = for any stream
> protocol, and = is not TCP specific, based on feedback from the charter
> discussion 3. Clarified the use of = multiple TCP connections for Child SAs,
> based on Jun Hu=E2=80=99s questions
>
> Also, I=E2=80=99m happy to say that we=E2=80=99ve been = doing interoperability testing between
> Apple clients and Cisco server for TCP encapsulation. If = anyone else has an
> = implementation they=E2=80=99d like to try out, please let us = know!
>
> Best,
> Tommy
>
> > On Oct 31, = 2016, at 8:56 AM, internet-drafts@ietf.org wrote:
> >
> >
> > = A New Internet-Draft is available from the on-line = Internet-Drafts
> = directories.
> > This draft = is a work item of the IP Security Maintenance and Extensions = of
> the IETF.
> >
> >        = Title           : TCP = Encapsulation of IKE and IPsec Packets
> >        = Authors         : Tommy = Pauly
> = >           &nbs= p;            =   Samy Touati
> = >           &nbs= p;            =   Ravi Mantha
> > =        = Filename        : = draft-ietf-ipsecme-tcp-encaps-03.txt
> >        = Pages           : = 20
> > =        = Date            : = 2016-10-31
> >
> > Abstract:
> >   This document = describes a method to transport IKE and IPsec packets
> >   over a TCP = connection for traversing network middleboxes that may
> >   block IKE = negotiation over UDP.  This method, referred to as TCP
> >   encapsulation, = involves sending both IKE packets for tunnel
> >   establishment as well as tunneled = packets using ESP over a TCP
> >   connection.  This method is = intended to be used as a fallback option
> >   when IKE cannot be negotiated over = UDP.
> >
> >
> > The IETF datatracker status page for this draft = is:
> > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/=
> >
> > There's also a htmlized = version available at:
> = > https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-03
> >
> > A diff from the previous = version is available at:
> = > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-tcp-enca= ps-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/
> >
> > = _______________________________________________
> > IPsec mailing list
> > https://www.ietf.org/mailman/listinfo/ipsec
>
> = _______________________________________________
> IPsec mailing list
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
 
 
_______________________________________________
IPsec mailing = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
= --Boundary_(ID_S7C0ihV4rZbr2scir1yhBw)-- From nobody Mon Nov 14 18:33:28 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FCF12969A for ; Mon, 14 Nov 2016 18:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 S89TodIV7wS1 for ; Mon, 14 Nov 2016 18:33:23 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 02AC11299B7 for ; Mon, 14 Nov 2016 18:33:21 -0800 (PST) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 83BECAE7C3A81; Tue, 15 Nov 2016 02:33:19 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id uAF2XJ7d018775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Nov 2016 02:33:19 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id uAF2XJo3008509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Nov 2016 02:33:19 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.86]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0301.000; Mon, 14 Nov 2016 21:33:19 -0500 From: "Hu, Jun (Nokia - US)" To: "tpauly@apple.com" , Valery Smyslov Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt Thread-Index: AQHSPr8z+2wY0bMtS0OT/aPsLUfYpaDZRbHwgABd2oCAAAIeAP//rMKw Date: Tue, 15 Nov 2016 02:33:18 +0000 Message-ID: <876523B00C3F9D47BFD2B654D63DBF92BEB156BC@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <147792938094.32373.833800643936554773.idtracker@ietfa.amsl.com> <61A7C96D-66A0-4BA7-82BE-277CBE13ED45@apple.com> <876523B00C3F9D47BFD2B654D63DBF92BEB12F24@US70UWXCHMBA05.zam.alcatel-lucent.com> <582a2e53.42212e0a.df555.6ec3@mx.google.com> <876523B00C3F9D47BFD2B654D63DBF92BEB1549D@US70UWXCHMBA05.zam.alcatel-lucent.com> <582a708a.d222620a.fd93f.a655@mx.google.com> <3FDBD376-F2F4-4AB1-AA40-E64C056025D6@apple.com> In-Reply-To: <3FDBD376-F2F4-4AB1-AA40-E64C056025D6@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_876523B00C3F9D47BFD2B654D63DBF92BEB156BCUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 02:33:26 -0000 --_000_876523B00C3F9D47BFD2B654D63DBF92BEB156BCUS70UWXCHMBA05z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSB0b3RhbGx5IGZpbmUgd2l0aCBiZSBhYmxlIHRvIHJlY2VpdmUgb24gYW55IFRDUCBzZXNz aW9uOyBidXQgdG8gc2VuZCBhIHBhY2tldCwgc3lzdGVtIG5lZWQga25vdyB3aGljaCBUQ1Agc2Vz c2lvbiB0byByZWFjaCB0aGUgcGVlciBmb3IgYSBnaXZlbiBTQSwgc28gSSB0aGluayB0aGVyZSBp cyBzb21lIGtpbmQgbWFwcGluZyBmb3IgZWdyZXNzOw0KU28gaWYgeW91IHNheSAiY3JlYXRpbmcg YSBUQ1AtMyBmb3IgU0EtMiIgaXMgbm90IGEgc3VwcG9ydCBjYXNlLCB0aGVuIHdoeSBpbml0aWF0 b3Igd2lsbCBjcmVhdGUgdHdvIFRDUCBzZXNzaW9ucyBmb3IgYSBnaXZlbiB0dW5uZWwgYXQgZmly c3QgcGxhY2U/DQoNCg0KRnJvbTogdHBhdWx5QGFwcGxlLmNvbSBbbWFpbHRvOnRwYXVseUBhcHBs ZS5jb21dDQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDE0LCAyMDE2IDY6MjYgUE0NClRvOiBWYWxl cnkgU215c2xvdjsgSHUsIEp1biAoTm9raWEgLSBVUykNCkNjOiBJUHNlY01FIFdHDQpTdWJqZWN0 OiBSZTogW0lQc2VjXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWlwc2VjbWUtdGNwLWVuY2Fwcy0w My50eHQNCg0KSSBhZ3JlZSB3aXRoIFZhbGVyeSB0aGF0IHRoZXJlIGRvZXNuJ3Qgc2VlbSB0byBi ZSBhbnkgcHJvYmxlbSBoZXJlLiBUaGUgc3RhdGVtZW50IHRoYXQgdGhlIGluaXRpYXRvciBpcyAi Y3JlYXRpbmcgYSBUQ1AtMyBmb3IgU0EtMiIgaXMgbm90IGEgc2NlbmFyaW8gdGhhdCB3ZSB3YW50 IHRvIHN1cHBvcnQsIGJlY2F1c2UgdGhlcmUgaXMgbm90IHN0cmljdCBtYXBwaW5nIGJldHdlZW4g VENQIGNvbm5lY3Rpb25zIGFuZCBTQXMuIFRoZSByZXNwb25kZXIgY2FuIHJlc3BvbmQgdG8gYm90 aCBTQXMgb24gdGhlIHNhbWUgVENQIGNvbm5lY3Rpb24sIG9yIGl0IG1heSBub3QuIEJvdGggc2lk ZXMgc2hvdWxkIHN1cHBvcnQgYW55IGNvbWJpbmF0aW9uLCBhbmQgYW55IGltcGxlbWVudGF0aW9u IHRoYXQgcmVmdXNlcyB0byBhY2NlcHQgcGFja2V0cyB3aWxsIG5vdCBiZSBjb21wbGlhbnQgd2l0 aCB0aGUgc3BlYy4NCg0KVGhhbmtzLA0KVG9tbXkNCg0KT24gTm92IDE1LCAyMDE2LCBhdCAxMTox OCBBTSwgVmFsZXJ5IFNteXNsb3YgPHN2YW5ydUBnbWFpbC5jb208bWFpbHRvOnN2YW5ydUBnbWFp bC5jb20+PiB3cm90ZToNCg0KV2hhdOKAmXMgd3Jvbmcgd2l0aCB0aGF0Pw0KDQpBcyBmYXIgYXMg SSB1bmRlcnN0YW5kIHRoZSBkcmFmdCwgdGhlIG1hcHBpbmcgYmV0d2VlbiBJS0UvSVBzZWMgYW5k IFRDUCBpcyBsb29zZSwNCnNvIGl0IHNlZW1zIHRoYXQgc3VjaCBhIHNjZW5hcmlvIGlzIE9LIChU b21teSBjb3JyZWN0cyBtZSBpZiBJ4oCZbSB3cm9uZykuDQpEbyB5b3UgaGF2ZSBhbnkgcHJvYmxl bXMgd2l0aCBpdD8NCg0KDQoNCg0KRnJvbTogSHUsIEp1biAoTm9raWEgLSBVUyk8bWFpbHRvOmp1 bi5odUBub2tpYS5jb20+DQpTZW50OiAxNSDQvdC+0Y/QsdGA0Y8gMjAxNiDQsy4gMTA6NDgNClRv OiBWYWxlcnkgU215c2xvdjxtYWlsdG86c3ZhbnJ1QGdtYWlsLmNvbT47IFRvbW15IFBhdWx5PG1h aWx0bzp0cGF1bHlAYXBwbGUuY29tPjsgSVBzZWNNRSBXRzxtYWlsdG86aXBzZWNAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSRTogW0lQc2VjXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWlwc2VjbWUtdGNw LWVuY2Fwcy0wMy50eHQNCg0KSG93ZXZlciBzaW5jZSB0aGUgZHJhZnQgYWxsb3dzIG11bHRpcGxl IFRDUCBjb25uZWN0aW9ucyBmb3IgdGhlIHNhbWUgdHVubmVsOyB0aGluayBvZiBhIGNhc2UgbGlr ZSBmb2xsb3dpbmc6DQpBIHR1bm5lbCBoYXMgdHdvIENISUxEX1NBLCBlYWNoIGhhcyBpdHMgb3du IFRDUCBjb25uZWN0aW9uOyBTQS0xIGhhcyBUQ1AtMSwgU0EtMiBoYXMgVENQLTI7DQpGb3Igc29t ZSByZWFzb24gVENQLTIgZ29lcyBkb3duIG9uIGluaXRpYXRvciBzaWRlIChUQ1AtMSBpcyBzdGls bCB1cCksIHNvIGluaXRpYXRvciBjcmVhdGUgYSBUQ1AtMywgZm9yIFNBLTIsIGlmIGluaXRpYXRv ciBvbmx5IHNlbmQgSUtFIGtlZXBhbGl2ZSB0byB1cGRhdGUgcmVzcG9uZGVyLCBzbyByZXNwb25k ZXIgd2lsbCBjaGFuZ2UgYm90aCBTQS0xIGFuZCBTQS0yIHRvIFRDUC0zPw0KDQpGcm9tOiBJUHNl YyBbbWFpbHRvOmlwc2VjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBWYWxlcnkgU215 c2xvdg0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxNCwgMjAxNiAxOjM2IFBNDQpUbzogSHUsIEp1 biAoTm9raWEgLSBVUyk7IFRvbW15IFBhdWx5OyBJUHNlY01FIFdHDQpTdWJqZWN0OiBSZTogW0lQ c2VjXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWlwc2VjbWUtdGNwLWVuY2Fwcy0wMy50eHQNCg0K SGkgSnVuLA0KDQpmb3IgdGhlIHNlY29uZCBwYXJ0OiAgeW91ciBJS0UgU0EgbXVzdCBiZSBsaW5r ZWQgdG8gYWxsIGNoaWxkIFNBcw0KaXQgY3JlYXRlZCAoaW4gb3RoZXIgd29yZHMsIGNoaWxkIFNB cyBtdXN0IHJlbWVtYmVyIHdoaWNoIElLRSBTQQ0KY3JlYXRlZCB0aGVtIGFuZCB2aXNhIHZlcnNh LCBvdGhlcndpc2UgYSBsb3Qgb2YgSUtFdjIgbG9naWMNCmRvZXNu4oCZdCB3b3JrKS4gU28gdGhl cmUgaXMgbm8gbmVlZCB0byBzZW5kIHBhY2tldHMgb3ZlciBhbGwNCmNoaWxkIFNBcywgaXTigJlz IGVub3VnaCB0byBzZW5kIGxpdmVuZXNzIGNoZWNrIG92ZXIgSUtFIFNBLA0Kc28gdGhhdCByZXNw b25kZXIgbGVhcm4gbmV3IFRDUC1JS0UgbWFwcGluZyBhbmQgdXNlIGl0DQpmb3IgbGlua2VkIGNo aWxkIFNBcyBhcyB3ZWxsLg0KDQpSZWdhcmRzLA0KVmFsZXJ5Lg0KDQoNCkZyb206IEh1LCBKdW4g KE5va2lhIC0gVVMpPG1haWx0bzpqdW4uaHVAbm9raWEuY29tPg0KU2VudDogMTQg0L3QvtGP0LHR gNGPIDIwMTYg0LMuIDIyOjIxDQpUbzogVG9tbXkgUGF1bHk8bWFpbHRvOnRwYXVseUBhcHBsZS5j b20+OyBJUHNlY01FIFdHPG1haWx0bzppcHNlY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSVBz ZWNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaXBzZWNtZS10Y3AtZW5jYXBzLTAzLnR4dA0KDQpU d28gY29tbWVudHM6DQoNCjEuIFRoZSBkcmFmdCBzZWVtcyB0byBpbXBseSB0aGF0IG9ubHkgdHVu bmVsIGluaXRpYXRvciBpcyBhbGxvd2VkIHRvIGluaXRpYXRlIFRDUCBzZXNzaW9uLCAgaG93ZXZl ciB3aGF0IGlzIGJlaGF2aW9yIGFmdGVyIFRDUCBjb25uZWN0aW9uIGlzIGxvc3QgYW5kIGluaXRp YXRvciBuZWVkIHRvIHJlLWNyZWF0ZSBpdD8gZG9lcyBpdCBkbyBpdCByaWdodCBhd2F5IG9yIG9u bHkgcmUtY3JlYXRlIFRDUCBzZXNzaW9uIHdoZW4gaW5pdGlhdG9yIG5lZWQgdG8gc2VuZCBzb21l IHBhY2tldD8gSSBhc3N1bWUgaXQgc2hvdWxkIGJlIHJpZ2h0IGF3YXksIGJlY2F1c2Ugb3RoZXJ3 aXNlIHRoZXJlIHdpbGwgYmUgdHJhZmZpYyBsb3NzIGlmIHRoZSByZXNwb25kZXIgbmVlZCB0byBz ZW5kIHBhY2tldCBiZWZvcmUgdGhlIFRDUCBzZXNzaW9uIGlzIHJlLWNyZWF0ZWQ7DQpTbyBpZiBt eSBhYm92ZSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3QsIEknZCBsaWtlIGRyYWZ0IHRvIGNsZWFy bHkgc3RhdGUgdGhlIGJlaGF2aW9yOw0KDQoNCjIuIHNlY3Rpb24gNiBtZW50aW9uIHRoYXQgaW1w bGVtZW50YXRpb24gc2hvdWxkIGJlIGFibGUgdG8gcmVjZWl2ZSBmcm9tIGFueSBUQ1Agc2Vzc2lv biBhbmQgbm90IGVuZm9yY2luZyBhbnkgc3RyaWN0IG1hcHBpbmc7IHRoYXQncyBmaW5lIGZvciBy ZWNlaXZpbmcsIGhvd2V2ZXIgZm9yIHNlbmRpbmcgdHJhZmZpYywgc3lzdGVtIChzcGVjaWFsbHkg cmVzcG9uZGVyKSBzdGlsbCAgbmVlZCB0byBrbm93IHdoaWNoIFRDUCBzZXNzaW9uIHRvIHVzZSB0 byByZWFjaCBwZWVyIG9mIGEgZ2l2ZW4gU0E7IGZvciBleGFtcGxlLCBJZiBOQVQgaXMgZGV0ZWN0 ZWQsIHRoZW4gaW4gY2FzZSBvZiBUQ1Agc2Vzc2lvbiBpcyBsb3N0IG9uIGluaXRpYXRvciBzaWRl IGJ1dCBzdGlsbCBleGlzdHMgb24gcmVzcG9uZGVyIHNpZGUgYW5kIGluaXRpYXRvciByZS1jcmVh dGUgdGhlIFRDUCBzZXNzaW9uLCB0aGUgbmV3IFRDUCBzZXNzaW9uIG1pZ2h0IGhhdmUgYSBkaWZm ZXJlbnQgTkFUIHB1YmxpYyBwb3J0IG9yIGV2ZW4gZGlmZmVyZW50IE5BVCBwdWJsaWMgYWRkcmVz cywgc28gdGhlIHJlc3BvbmRlciBjYW4ndCB0ZWxsIGlmIHRoZSBuZXcgVENQIHNlc3Npb24gaXMg Zm9yIGFuIGV4aXN0aW5nIFNBIG9yIGEgbmV3IHR1bm5lbCwgdGhpcyBtZWFucyBpbml0aWF0b3Ig bmVlZCB0byBzZW5kIG1lc3NhZ2UgZm9yIGFsbCBleGlzdGluZyBTQSB0aGF0IG5lZWQgdG8gdXNl IHRoZSBuZXcgVENQIHNlc3Npb24gc28gdGhhdCByZXNwb25kZXIgY291bGQgdXBkYXRlIGl0cyBT QS10by1UQ1Agc2Vzc2lvbiBtYXBwaW5nIGJlY2F1c2Ugb3RoZXJ3aXNlIHJlc3BvbmRlciBtaWdo dCB1c2UgdGhlIG9sZCBUQ1Agc2Vzc2lvbiBmb3Igb3V0Z29pbmcgdHJhZmZpYyBvZiBleGlzdGlu ZyBTQSBhbmQgdHJhZmZpYyB3aWxsIGJlIGJsYWNraG9sZWQ7IGluIHNlY3Rpb24gNiwgZHJhZnQg c3RhdGVzIHRoYXQgZWl0aGVyIFVQREFURV9TQV9BRERSRVNTIG9yIGEgSUtFIGtlZXBhbGl2ZSBj b3VsZCBiZSB1c2VkLCBob3dldmVyIHRoZXJlIGlzIG5vIHNwZWNpZmljYXRpb24gb2YgYmVoYXZp b3IgZm9yIHVwZGF0aW5nIENISUxEX1NBIG1hcHBpbmcgd2hlbiBNT0JJS0UgaXMgbm90IHN1cHBv cnRlZDsgIG1heWJlIGluaXRpYXRvciBzaG91bGQgc2VuZCBzb21lIGtpbmQgb2YgZHVtbXkgcGFj a2V0IG92ZXIgdGhlIENISUxEX1NBIHRvIHVwZGF0ZSByZXNwb25kZXIncyBtYXBwaW5nPw0KDQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSVBzZWMgW21haWx0bzppcHNl Yy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVG9tbXkgUGF1bHkNCj4gU2VudDogTW9u ZGF5LCBPY3RvYmVyIDMxLCAyMDE2IDk6MDEgQU0NCj4gVG86IElQc2VjTUUgV0cNCj4gU3ViamVj dDogW0lQc2VjXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWlwc2VjbWUtdGNwLWVuY2Fwcy0wMy50 eHQNCj4NCj4gSGVsbG8sDQo+DQo+IEnigJl2ZSBwb3N0ZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUg VENQIGVuY2Fwc3VsYXRpb24gZHJhZnQgd2l0aCB0aGUgZm9sbG93aW5nDQo+IGNoYW5nZXM6DQo+ DQo+IDEuIEFkZGVkIGEgc2VjdGlvbiB0byBleHBsaWNpdGx5IGRpc2N1c3MgaG93IHRvIGZhbGxi YWNrIGZyb20gVURQIHRvIFRDUA0KPiAocmV0cmFuc21pc3Npb25zLCBldGMpIGJhc2VkIG9uIGZl ZWRiYWNrIGZyb20gdGhlIGNoYXJ0ZXIgZGlzY3Vzc2lvbiAyLg0KPiBFeHBsYWluZWQgdGhhdCB0 aGlzIG1ldGhvZCBvZiBlbmNhcHN1bGF0aW9uIGNhbiBiZSB1c2VkIGZvciBhbnkgc3RyZWFtDQo+ IHByb3RvY29sLCBhbmQgaXMgbm90IFRDUCBzcGVjaWZpYywgYmFzZWQgb24gZmVlZGJhY2sgZnJv bSB0aGUgY2hhcnRlcg0KPiBkaXNjdXNzaW9uIDMuIENsYXJpZmllZCB0aGUgdXNlIG9mIG11bHRp cGxlIFRDUCBjb25uZWN0aW9ucyBmb3IgQ2hpbGQgU0FzLA0KPiBiYXNlZCBvbiBKdW4gSHXigJlz IHF1ZXN0aW9ucw0KPg0KPiBBbHNvLCBJ4oCZbSBoYXBweSB0byBzYXkgdGhhdCB3ZeKAmXZlIGJl ZW4gZG9pbmcgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0aW5nIGJldHdlZW4NCj4gQXBwbGUgY2xpZW50 cyBhbmQgQ2lzY28gc2VydmVyIGZvciBUQ1AgZW5jYXBzdWxhdGlvbi4gSWYgYW55b25lIGVsc2Ug aGFzIGFuDQo+IGltcGxlbWVudGF0aW9uIHRoZXnigJlkIGxpa2UgdG8gdHJ5IG91dCwgcGxlYXNl IGxldCB1cyBrbm93IQ0KPg0KPiBCZXN0LA0KPiBUb21teQ0KPg0KPiA+IE9uIE9jdCAzMSwgMjAx NiwgYXQgODo1NiBBTSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KPiA+DQo+ID4NCj4gPiBBIE5ldyBJbnRlcm5ldC1EcmFm dCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4gZGlyZWN0 b3JpZXMuDQo+ID4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVAgU2VjdXJpdHkg TWFpbnRlbmFuY2UgYW5kIEV4dGVuc2lvbnMgb2YNCj4gdGhlIElFVEYuDQo+ID4NCj4gPiAgICAg ICAgVGl0bGUgICAgICAgICAgIDogVENQIEVuY2Fwc3VsYXRpb24gb2YgSUtFIGFuZCBJUHNlYyBQ YWNrZXRzDQo+ID4gICAgICAgIEF1dGhvcnMgICAgICAgICA6IFRvbW15IFBhdWx5DQo+ID4gICAg ICAgICAgICAgICAgICAgICAgICAgIFNhbXkgVG91YXRpDQo+ID4gICAgICAgICAgICAgICAgICAg ICAgICAgIFJhdmkgTWFudGhhDQo+ID4gICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWll dGYtaXBzZWNtZS10Y3AtZW5jYXBzLTAzLnR4dA0KPiA+ICAgICAgICBQYWdlcyAgICAgICAgICAg OiAyMA0KPiA+ICAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDE2LTEwLTMxDQo+ID4NCj4gPiBB YnN0cmFjdDoNCj4gPiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWV0aG9kIHRvIHRyYW5z cG9ydCBJS0UgYW5kIElQc2VjIHBhY2tldHMNCj4gPiAgIG92ZXIgYSBUQ1AgY29ubmVjdGlvbiBm b3IgdHJhdmVyc2luZyBuZXR3b3JrIG1pZGRsZWJveGVzIHRoYXQgbWF5DQo+ID4gICBibG9jayBJ S0UgbmVnb3RpYXRpb24gb3ZlciBVRFAuICBUaGlzIG1ldGhvZCwgcmVmZXJyZWQgdG8gYXMgVENQ DQo+ID4gICBlbmNhcHN1bGF0aW9uLCBpbnZvbHZlcyBzZW5kaW5nIGJvdGggSUtFIHBhY2tldHMg Zm9yIHR1bm5lbA0KPiA+ICAgZXN0YWJsaXNobWVudCBhcyB3ZWxsIGFzIHR1bm5lbGVkIHBhY2tl dHMgdXNpbmcgRVNQIG92ZXIgYSBUQ1ANCj4gPiAgIGNvbm5lY3Rpb24uICBUaGlzIG1ldGhvZCBp cyBpbnRlbmRlZCB0byBiZSB1c2VkIGFzIGEgZmFsbGJhY2sgb3B0aW9uDQo+ID4gICB3aGVuIElL RSBjYW5ub3QgYmUgbmVnb3RpYXRlZCBvdmVyIFVEUC4NCj4gPg0KPiA+DQo+ID4gVGhlIElFVEYg ZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ID4gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pcHNlY21lLXRjcC1lbmNhcHMvDQo+ ID4NCj4gPiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4g PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pcHNlY21lLXRjcC1lbmNh cHMtMDMNCj4gPg0KPiA+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWls YWJsZSBhdDoNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0 Zi1pcHNlY21lLXRjcC1lbmNhcHMtMDMNCj4gPg0KPiA+DQo+ID4gUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gPiBzdWJt aXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCj4gPg0KPiA+IEludGVy bmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPiBm dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiA+DQo+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBJUHNlYyBtYWlsaW5nIGxp c3QNCj4gPiBJUHNlY0BpZXRmLm9yZzxtYWlsdG86SVBzZWNAaWV0Zi5vcmc+DQo+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYw0KPg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJUHNlYyBtYWlsaW5nIGxpc3QN Cj4gSVBzZWNAaWV0Zi5vcmc8bWFpbHRvOklQc2VjQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KSVBzZWMgbWFpbGluZyBsaXN0DQpJUHNlY0BpZXRmLm9y ZzxtYWlsdG86SVBzZWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lwc2VjDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCklQc2VjIG1haWxpbmcgbGlzdA0KSVBzZWNAaWV0Zi5vcmc8bWFpbHRvOklQc2Vj QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYw0K DQo= --_000_876523B00C3F9D47BFD2B654D63DBF92BEB156BCUS70UWXCHMBA05z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJOb2tpYSBQdXJlIFRleHQgTGlnaHQiOw0KCXBhbm9zZS0xOjIgMTEgMyA0 IDQgNiAyIDYgMyAzO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglw YW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBw dDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1jb252 ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNw YW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQi Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUy MA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiTm9raWEg UHVyZSBUZXh0IExpZ2h0Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4yNWluIDEuMGluIDEuMjVpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtOb2tp YSBQdXJlIFRleHQgTGlnaHQmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JIGFtIHRvdGFsbHkgZmluZSB3aXRoIGJlIGFibGUgdG8gcmVjZWl2ZSBvbiBhbnkgVENQ IHNlc3Npb247IGJ1dCB0byBzZW5kIGEgcGFja2V0LCBzeXN0ZW0gbmVlZCBrbm93IHdoaWNoIFRD UCBzZXNzaW9uIHRvIHJlYWNoIHRoZSBwZWVyIGZvciBhDQogZ2l2ZW4gU0EsIHNvIEkgdGhpbmsg dGhlcmUgaXMgc29tZSBraW5kIG1hcHBpbmcgZm9yIGVncmVzczs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtOb2tpYSBQdXJlIFRleHQgTGlnaHQmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyBpZiB5b3Ugc2F5ICZxdW90O2NyZWF0aW5nIGEg VENQLTMgZm9yIFNBLTImcXVvdDsgaXMgbm90IGEgc3VwcG9ydCBjYXNlLCB0aGVuIHdoeSBpbml0 aWF0b3Igd2lsbCBjcmVhdGUgdHdvIFRDUCBzZXNzaW9ucyBmb3IgYSBnaXZlbiB0dW5uZWwgYXQg Zmlyc3QgcGxhY2U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Tm9raWEgUHVy ZSBUZXh0IExpZ2h0JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Tm9raWEgUHVyZSBUZXh0 IExpZ2h0JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gdHBhdWx5QGFwcGxlLmNvbSBbbWFpbHRvOnRwYXVseUBhcHBsZS5jb21dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBOb3ZlbWJlciAxNCwgMjAxNiA2OjI2IFBNPGJyPg0KPGI+ VG86PC9iPiBWYWxlcnkgU215c2xvdjsgSHUsIEp1biAoTm9raWEgLSBVUyk8YnI+DQo8Yj5DYzo8 L2I+IElQc2VjTUUgV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJUHNlY10gSS1EIEFjdGlv bjogZHJhZnQtaWV0Zi1pcHNlY21lLXRjcC1lbmNhcHMtMDMudHh0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgd2l0aCBWYWxlcnkg dGhhdCB0aGVyZSBkb2Vzbid0IHNlZW0gdG8gYmUgYW55IHByb2JsZW0gaGVyZS4gVGhlIHN0YXRl bWVudCB0aGF0IHRoZSBpbml0aWF0b3IgaXMgJnF1b3Q7Y3JlYXRpbmcgYSBUQ1AtMyBmb3IgU0Et MiZxdW90OyBpcyBub3QgYSBzY2VuYXJpbyB0aGF0IHdlIHdhbnQgdG8gc3VwcG9ydCwgYmVjYXVz ZSB0aGVyZSBpcyBub3Qgc3RyaWN0IG1hcHBpbmcgYmV0d2VlbiBUQ1AgY29ubmVjdGlvbnMgYW5k DQogU0FzLiBUaGUgcmVzcG9uZGVyIGNhbiByZXNwb25kIHRvIGJvdGggU0FzIG9uIHRoZSBzYW1l IFRDUCBjb25uZWN0aW9uLCBvciBpdCBtYXkgbm90LiBCb3RoIHNpZGVzIHNob3VsZCBzdXBwb3J0 IGFueSBjb21iaW5hdGlvbiwgYW5kIGFueSBpbXBsZW1lbnRhdGlvbiB0aGF0IHJlZnVzZXMgdG8g YWNjZXB0IHBhY2tldHMgd2lsbCBub3QgYmUgY29tcGxpYW50IHdpdGggdGhlIHNwZWMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvbW15 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE5vdiAx NSwgMjAxNiwgYXQgMTE6MTggQU0sIFZhbGVyeSBTbXlzbG92ICZsdDs8YSBocmVmPSJtYWlsdG86 c3ZhbnJ1QGdtYWlsLmNvbSI+c3ZhbnJ1QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5XaGF04oCZcyB3cm9uZyB3aXRoIHRoYXQ/PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFzIGZhciBh cyBJIHVuZGVyc3RhbmQgdGhlIGRyYWZ0LCB0aGUgbWFwcGluZyBiZXR3ZWVuIElLRS9JUHNlYyBh bmQgVENQIGlzIGxvb3NlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+c28gaXQgc2Vl bXMgdGhhdCBzdWNoIGEgc2NlbmFyaW8gaXMgT0sgKFRvbW15IGNvcnJlY3RzIG1lIGlmIEnigJlt IHdyb25nKS48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EbyB5b3UgaGF2ZSBhbnkgcHJvYmxlbXMg d2l0aCBpdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpqdW4uaHVAbm9r aWEuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+SHUsDQogSnVuIChOb2tpYSAtIFVT KTwvc3Bhbj48L2E+PGJyPg0KPGI+U2VudDo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PC9iPjE1INC90L7Rj9Cx0YDRjyAyMDE2INCzLiAxMDo0ODxicj4N CjxiPlRvOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 L2I+PGEgaHJlZj0ibWFpbHRvOnN2YW5ydUBnbWFpbC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjoj OTU0RjcyIj5WYWxlcnkgU215c2xvdjwvc3Bhbj48L2E+OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHBhdWx5QGFwcGxlLmNv bSI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPlRvbW15IFBhdWx5PC9zcGFuPjwvYT47PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1h aWx0bzppcHNlY0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPklQc2VjTUUN CiBXRzwvc3Bhbj48L2E+PGJyPg0KPGI+U3ViamVjdDo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlJFOiBbSVBzZWNdIEktRCBBY3Rpb246IGRyYWZ0 LWlldGYtaXBzZWNtZS10Y3AtZW5jYXBzLTAzLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtOb2tpYSBQdXJlIFRleHQgTGlnaHQmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ib3dldmVyIHNpbmNlIHRoZSBkcmFmdCBhbGxvd3MgbXVs dGlwbGUgVENQIGNvbm5lY3Rpb25zIGZvciB0aGUgc2FtZSB0dW5uZWw7IHRoaW5rIG9mIGEgY2Fz ZSBsaWtlIGZvbGxvd2luZzo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtOb2tpYSBQdXJl IFRleHQgTGlnaHQmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5B IHR1bm5lbCBoYXMgdHdvIENISUxEX1NBLCBlYWNoIGhhcyBpdHMgb3duIFRDUCBjb25uZWN0aW9u OyBTQS0xIGhhcyBUQ1AtMSwgU0EtMiBoYXMgVENQLTI7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Tm9raWEgUHVyZSBUZXh0IExpZ2h0JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Rm9yIHNvbWUgcmVhc29uIFRDUC0yIGdvZXMgZG93biBvbiBpbml0aWF0 b3Igc2lkZSAoVENQLTEgaXMgc3RpbGwgdXApLCBzbyBpbml0aWF0b3IgY3JlYXRlIGEgVENQLTMs IGZvciBTQS0yLCBpZiBpbml0aWF0b3Igb25seSBzZW5kIElLRSBrZWVwYWxpdmUNCiB0byB1cGRh dGUgcmVzcG9uZGVyLCBzbyByZXNwb25kZXIgd2lsbCBjaGFuZ2UgYm90aCBTQS0xIGFuZCBTQS0y IHRvIFRDUC0zPzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtOb2tpYSBQdXJlIFRleHQgTGlnaHQmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPklQc2VjDQogWzxhIGhyZWY9Im1haWx0bzppcHNlYy1ib3VuY2Vz QGlldGYub3JnIj5tYWlsdG86aXBzZWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dPHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9uIEJlaGFsZiBPZjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+VmFsZXJ5IFNt eXNsb3Y8YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+TW9uZGF5LCBOb3ZlbWJlciAxNCwgMjAxNiAxOjM2IFBNPGJyPg0KPGI+ VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5I dSwgSnVuIChOb2tpYSAtIFVTKTsgVG9tbXkgUGF1bHk7IElQc2VjTUUgV0c8YnI+DQo8Yj5TdWJq ZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ UmU6IFtJUHNlY10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1pcHNlY21lLXRjcC1lbmNhcHMtMDMu dHh0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5IaSBKdW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmZvciB0aGUgc2Vjb25kIHBhcnQ6ICZuYnNw O3lvdXIgSUtFIFNBIG11c3QgYmUgbGlua2VkIHRvIGFsbCBjaGlsZCBTQXM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPml0IGNyZWF0ZWQgKGluIG90aGVyIHdvcmRzLCBjaGlsZCBTQXMg bXVzdCByZW1lbWJlciB3aGljaCBJS0UgU0E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PmNyZWF0ZWQgdGhlbSBhbmQgdmlzYSB2ZXJzYSwgb3RoZXJ3aXNlIGEgbG90IG9mIElLRXYyIGxv Z2ljPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5kb2VzbuKAmXQgd29yaykuIFNvIHRo ZXJlIGlzIG5vIG5lZWQgdG8gc2VuZCBwYWNrZXRzIG92ZXIgYWxsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5jaGlsZCBTQXMsIGl04oCZcyBlbm91Z2ggdG8gc2VuZCBsaXZlbmVzcyBj aGVjayBvdmVyIElLRSBTQSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnNvIHRoYXQg cmVzcG9uZGVyIGxlYXJuIG5ldyBUQ1AtSUtFIG1hcHBpbmcgYW5kIHVzZSBpdDxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPmZvciBsaW5rZWQgY2hpbGQgU0FzIGFzIHdlbGwuPHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VmFsZXJ5LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86 anVuLmh1QG5va2lhLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPkh1LA0KIEp1biAo Tm9raWEgLSBVUyk8L3NwYW4+PC9hPjxicj4NCjxiPlNlbnQ6PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj4xNCDQvdC+0Y/QsdGA0Y8gMjAxNiDQsy4g MjI6MjE8YnI+DQo8Yj5Ubzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PC9iPjxhIGhyZWY9Im1haWx0bzp0cGF1bHlAYXBwbGUuY29tIj48c3BhbiBzdHls ZT0iY29sb3I6Izk1NEY3MiI+VG9tbXkgUGF1bHk8L3NwYW4+PC9hPjs8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmlwc2VjQGll dGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+SVBzZWNNRSBXRzwvc3Bhbj48L2E+ PGJyPg0KPGI+U3ViamVjdDo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PC9iPlJlOiBbSVBzZWNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaXBzZWNtZS10 Y3AtZW5jYXBzLTAzLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlR3byBjb21tZW50czo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+MS4gVGhlIGRyYWZ0IHNlZW1zIHRvIGltcGx5IHRoYXQgb25seSB0dW5uZWwgaW5pdGlh dG9yIGlzIGFsbG93ZWQgdG8gaW5pdGlhdGUgVENQIHNlc3Npb24sJm5ic3A7IGhvd2V2ZXIgd2hh dCBpcyBiZWhhdmlvciBhZnRlciBUQ1AgY29ubmVjdGlvbiBpcyBsb3N0IGFuZCBpbml0aWF0b3Ig bmVlZCB0byByZS1jcmVhdGUNCiBpdD8gZG9lcyBpdCBkbyBpdCByaWdodCBhd2F5IG9yIG9ubHkg cmUtY3JlYXRlIFRDUCBzZXNzaW9uIHdoZW4gaW5pdGlhdG9yIG5lZWQgdG8gc2VuZCBzb21lIHBh Y2tldD8gSSBhc3N1bWUgaXQgc2hvdWxkIGJlIHJpZ2h0IGF3YXksIGJlY2F1c2Ugb3RoZXJ3aXNl IHRoZXJlIHdpbGwgYmUgdHJhZmZpYyBsb3NzIGlmIHRoZSByZXNwb25kZXIgbmVlZCB0byBzZW5k IHBhY2tldCBiZWZvcmUgdGhlIFRDUCBzZXNzaW9uIGlzIHJlLWNyZWF0ZWQ7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5TbyBpZiBteSBhYm92ZSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJl Y3QsIEknZCBsaWtlIGRyYWZ0IHRvIGNsZWFybHkgc3RhdGUgdGhlIGJlaGF2aW9yOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjIuIHNlY3Rpb24gNiBt ZW50aW9uIHRoYXQgaW1wbGVtZW50YXRpb24gc2hvdWxkIGJlIGFibGUgdG8gcmVjZWl2ZSBmcm9t IGFueSBUQ1Agc2Vzc2lvbiBhbmQgbm90IGVuZm9yY2luZyBhbnkgc3RyaWN0IG1hcHBpbmc7IHRo YXQncyBmaW5lIGZvciByZWNlaXZpbmcsIGhvd2V2ZXIgZm9yIHNlbmRpbmcNCiB0cmFmZmljLCBz eXN0ZW0gKHNwZWNpYWxseSByZXNwb25kZXIpIHN0aWxsJm5ic3A7IG5lZWQgdG8ga25vdyB3aGlj aCBUQ1Agc2Vzc2lvbiB0byB1c2UgdG8gcmVhY2ggcGVlciBvZiBhIGdpdmVuIFNBOyBmb3IgZXhh bXBsZSwgSWYgTkFUIGlzIGRldGVjdGVkLCB0aGVuIGluIGNhc2Ugb2YgVENQIHNlc3Npb24gaXMg bG9zdCBvbiBpbml0aWF0b3Igc2lkZSBidXQgc3RpbGwgZXhpc3RzIG9uIHJlc3BvbmRlciBzaWRl IGFuZCBpbml0aWF0b3IgcmUtY3JlYXRlDQogdGhlIFRDUCBzZXNzaW9uLCB0aGUgbmV3IFRDUCBz ZXNzaW9uIG1pZ2h0IGhhdmUgYSBkaWZmZXJlbnQgTkFUIHB1YmxpYyBwb3J0IG9yIGV2ZW4gZGlm ZmVyZW50IE5BVCBwdWJsaWMgYWRkcmVzcywgc28gdGhlIHJlc3BvbmRlciBjYW4ndCB0ZWxsIGlm IHRoZSBuZXcgVENQIHNlc3Npb24gaXMgZm9yIGFuIGV4aXN0aW5nIFNBIG9yIGEgbmV3IHR1bm5l bCwgdGhpcyBtZWFucyBpbml0aWF0b3IgbmVlZCB0byBzZW5kIG1lc3NhZ2UgZm9yIGFsbCBleGlz dGluZw0KIFNBIHRoYXQgbmVlZCB0byB1c2UgdGhlIG5ldyBUQ1Agc2Vzc2lvbiBzbyB0aGF0IHJl c3BvbmRlciBjb3VsZCB1cGRhdGUgaXRzIFNBLXRvLVRDUCBzZXNzaW9uIG1hcHBpbmcgYmVjYXVz ZSBvdGhlcndpc2UgcmVzcG9uZGVyIG1pZ2h0IHVzZSB0aGUgb2xkIFRDUCBzZXNzaW9uIGZvciBv dXRnb2luZyB0cmFmZmljIG9mIGV4aXN0aW5nIFNBIGFuZCB0cmFmZmljIHdpbGwgYmUgYmxhY2to b2xlZDsgaW4gc2VjdGlvbiA2LCBkcmFmdCBzdGF0ZXMgdGhhdA0KIGVpdGhlciBVUERBVEVfU0Ff QUREUkVTUyBvciBhIElLRSBrZWVwYWxpdmUgY291bGQgYmUgdXNlZCwgaG93ZXZlciB0aGVyZSBp cyBubyBzcGVjaWZpY2F0aW9uIG9mIGJlaGF2aW9yIGZvciB1cGRhdGluZyBDSElMRF9TQSBtYXBw aW5nIHdoZW4gTU9CSUtFIGlzIG5vdCBzdXBwb3J0ZWQ7Jm5ic3A7IG1heWJlIGluaXRpYXRvciBz aG91bGQgc2VuZCBzb21lIGtpbmQgb2YgZHVtbXkgcGFja2V0IG92ZXIgdGhlIENISUxEX1NBIHRv IHVwZGF0ZSByZXNwb25kZXIncw0KIG1hcHBpbmc/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyBGcm9tOiBJUHNlYyBbPGEgaHJlZj0i bWFpbHRvOmlwc2VjLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0Rjcy Ij5tYWlsdG86aXBzZWMtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XSBPbiBCZWhhbGYgT2Yg VG9tbXkgUGF1bHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsgU2VudDogTW9u ZGF5LCBPY3RvYmVyIDMxLCAyMDE2IDk6MDEgQU08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZndDsgVG86IElQc2VjTUUgV0c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZn dDsgU3ViamVjdDogW0lQc2VjXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWlwc2VjbWUtdGNwLWVu Y2Fwcy0wMy50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDs8bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsgSGVsbG8sPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m Z3Q7IEnigJl2ZSBwb3N0ZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgVENQIGVuY2Fwc3VsYXRpb24g ZHJhZnQgd2l0aCB0aGUgZm9sbG93aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m Z3Q7IGNoYW5nZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7IDEuIEFkZGVkIGEgc2VjdGlvbiB0byBl eHBsaWNpdGx5IGRpc2N1c3MgaG93IHRvIGZhbGxiYWNrIGZyb20gVURQIHRvIFRDUDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyAocmV0cmFuc21pc3Npb25zLCBldGMpIGJhc2Vk IG9uIGZlZWRiYWNrIGZyb20gdGhlIGNoYXJ0ZXIgZGlzY3Vzc2lvbiAyLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyBFeHBsYWluZWQgdGhhdCB0aGlzIG1ldGhvZCBvZiBlbmNh cHN1bGF0aW9uIGNhbiBiZSB1c2VkIGZvciBhbnkgc3RyZWFtPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mZ3Q7IHByb3RvY29sLCBhbmQgaXMgbm90IFRDUCBzcGVjaWZpYywgYmFzZWQg b24gZmVlZGJhY2sgZnJvbSB0aGUgY2hhcnRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jmd0OyBkaXNjdXNzaW9uIDMuIENsYXJpZmllZCB0aGUgdXNlIG9mIG11bHRpcGxlIFRDUCBj b25uZWN0aW9ucyBmb3IgQ2hpbGQgU0FzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jmd0OyBiYXNlZCBvbiBKdW4gSHXigJlzIHF1ZXN0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyBB bHNvLCBJ4oCZbSBoYXBweSB0byBzYXkgdGhhdCB3ZeKAmXZlIGJlZW4gZG9pbmcgaW50ZXJvcGVy YWJpbGl0eSB0ZXN0aW5nIGJldHdlZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZn dDsgQXBwbGUgY2xpZW50cyBhbmQgQ2lzY28gc2VydmVyIGZvciBUQ1AgZW5jYXBzdWxhdGlvbi4g SWYgYW55b25lIGVsc2UgaGFzIGFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7 IGltcGxlbWVudGF0aW9uIHRoZXnigJlkIGxpa2UgdG8gdHJ5IG91dCwgcGxlYXNlIGxldCB1cyBr bm93ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyBCZXN0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Jmd0OyBUb21teTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OzxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyAmZ3Q7IE9uIE9jdCAzMSwgMjAx NiwgYXQgODo1NiBBTSw8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+PHNwYW4gc3R5 bGU9ImNvbG9yOiM5NTRGNzIiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPndyb3RlOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsg Jmd0OyBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJ bnRlcm5ldC1EcmFmdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsgZGlyZWN0 b3JpZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7ICZndDsgVGhpcyBkcmFm dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVAgU2VjdXJpdHkgTWFpbnRlbmFuY2UgYW5kIEV4dGVu c2lvbnMgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsgdGhlIElFVEYuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBUaXRsZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA6IFRDUCBFbmNhcHN1bGF0aW9uIG9mIElLRSBhbmQgSVBzZWMgUGFj a2V0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEF1dGhvcnMmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBUb21teSBQYXVseTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFNhbXkgVG91YXRpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7ICZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmF2aSBNYW50aGE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsgJmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgRmlsZW5hbWUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgOiBkcmFmdC1pZXRmLWlwc2VjbWUtdGNwLWVuY2Fwcy0wMy50eHQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsgJmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgUGFnZXMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgOiAyMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jmd0OyAmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBEYXRlJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDogMjAxNi0xMC0zMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyAmZ3Q7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7ICZndDsgQWJzdHJhY3Q6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsgVGhpcyBkb2N1 bWVudCBkZXNjcmliZXMgYSBtZXRob2QgdG8gdHJhbnNwb3J0IElLRSBhbmQgSVBzZWMgcGFja2V0 czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7IG92 ZXIgYSBUQ1AgY29ubmVjdGlvbiBmb3IgdHJhdmVyc2luZyBuZXR3b3JrIG1pZGRsZWJveGVzIHRo YXQgbWF5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7ICZndDsmbmJzcDsmbmJz cDsgYmxvY2sgSUtFIG5lZ290aWF0aW9uIG92ZXIgVURQLiZuYnNwOyBUaGlzIG1ldGhvZCwgcmVm ZXJyZWQgdG8gYXMgVENQPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7ICZndDsm bmJzcDsmbmJzcDsgZW5jYXBzdWxhdGlvbiwgaW52b2x2ZXMgc2VuZGluZyBib3RoIElLRSBwYWNr ZXRzIGZvciB0dW5uZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsgJmd0OyZu YnNwOyZuYnNwOyBlc3RhYmxpc2htZW50IGFzIHdlbGwgYXMgdHVubmVsZWQgcGFja2V0cyB1c2lu ZyBFU1Agb3ZlciBhIFRDUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyAmZ3Q7 Jm5ic3A7Jm5ic3A7IGNvbm5lY3Rpb24uJm5ic3A7IFRoaXMgbWV0aG9kIGlzIGludGVuZGVkIHRv IGJlIHVzZWQgYXMgYSBmYWxsYmFjayBvcHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyB3aGVuIElLRSBjYW5ub3QgYmUgbmVnb3RpYXRlZCBv dmVyIFVEUC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsgJmd0OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mZ3Q7ICZndDsgVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRo aXMgZHJhZnQgaXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7ICZndDs8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pcHNlY21lLXRjcC1lbmNh cHMvIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1pcHNlY21lLXRjcC1lbmNhcHMvPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jmd0OyAmZ3Q7IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxh YmxlIGF0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyAmZ3Q7PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwc2VjbWUtdGNwLWVuY2Fwcy0wMyI+PHNw YW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWlwc2VjbWUtdGNwLWVuY2Fwcy0wMzwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZn dDsgJmd0OyBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7ICZndDs8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtaXBzZWNtZS10Y3AtZW5jYXBzLTAzIj48c3Bh biBzdHlsZT0iY29sb3I6Izk1NEY3MiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LWlldGYtaXBzZWNtZS10Y3AtZW5jYXBzLTAzPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsgJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7ICZndDsgUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsgJmd0OyBzdWJtaXNzaW9u IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCjxh IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyI+dG9vbHMuaWV0Zi5vcmc8L2E+LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mZ3Q7ICZndDsgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBh bm9ueW1vdXMgRlRQIGF0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyAmZ3Q7 PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9 ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvIj48c3BhbiBzdHlsZT0iY29sb3I6 Izk1NEY3MiI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88L3NwYW4+PC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsgJmd0OyBJ UHNlYyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsgJmd0 OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVm PSJtYWlsdG86SVBzZWNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5JUHNl Y0BpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7 ICZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYyI+PHNwYW4g c3R5bGU9ImNvbG9yOiM5NTRGNzIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXBzZWM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0Ozxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Jmd0OyBJUHNlYyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOklQc2VjQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3 MiI+SVBzZWNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjIj48c3Bh biBzdHlsZT0iY29sb3I6Izk1NEY3MiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pcHNlYzwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+SVBzZWMgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86SVBzZWNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJj b2xvcjojOTU0RjcyIj5JUHNlY0BpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lwc2VjIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYzwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCklQc2VjIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bh bj48YSBocmVmPSJtYWlsdG86SVBzZWNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ni4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6Izk1NEY3MiI+SVBzZWNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ni4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjYuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiM5NTRGNzIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBz ZWM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_876523B00C3F9D47BFD2B654D63DBF92BEB156BCUS70UWXCHMBA05z_-- From nobody Mon Nov 14 22:37:53 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6FB712967E for ; Mon, 14 Nov 2016 22:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 CuyCTecuqFyC for ; Mon, 14 Nov 2016 22:37:50 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 4ACD6129A40 for ; Mon, 14 Nov 2016 22:30:08 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tHyDY10zlz3Fn for ; Tue, 15 Nov 2016 07:30:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1479191405; bh=4Qx22OgD54hgmvd4AZo1bd9k9OBCSdMHUB922PrizbY=; h=Date:From:To:Subject; b=oWmHUwlwqwntS8CcPNYRShelrAD/YDqhivc89Cp5SwXJDkvOvLeLgJpFufd7CRyVc 9jefPn+6/E9KgzLJf26LQ6LIYOuPuWc5hdEyIF87fxqnaxiponMS+nE83Cik1DjsFp xh5nCRMkc0innz+0chxwDxqWTolGxdHdICtI8qWw= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id GCdh_VfCsCKe for ; Tue, 15 Nov 2016 07:30:02 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Tue, 15 Nov 2016 07:30:02 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 5F0F412EAE1; Tue, 15 Nov 2016 01:30:00 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 5F0F412EAE1 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4A71040DAA3C for ; Tue, 15 Nov 2016 01:30:00 -0500 (EST) Date: Tue, 15 Nov 2016 01:30:00 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=UTF-8 Content-Transfer-Encoding: 8BIT Archived-At: Subject: [IPsec] IETF97 meeting raw notes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 06:37:52 -0000 Tero: Agenda talk Tero: ddos and safecurves in AUTH48 Tero: 4307/7321 bis documents David: any concerns with 7321bis for WGLC ? none from room Tero: encaps edDSA adopted Tero: Split dns, implicit itv, waiting for adoption [split dns presentation] Some push to get early code point done by Tommy, Paul and Valery [tcp encaps presentation] Yoav: why mention anything bit TCP (http, quick) Tommy: we kind of want to tell people this works for other transports Yoav: I'd need a new document anyway for SCTP or something else Valery: You must specify more precisely to ensure interop Tommy: TCP is opened by initiator. Server should accept any tcp connections (with sane limit) Valery: so you need to support multiple TCP connections for a single SA I think more specifics [Hu Jun] Which TCP session to use? what is the use case to support multiple TCP connections. Tero: can me mandate MOBIKE? various people including Yoav, Paul and Tommy: please do not Tommy: TCP 3way handshake gives some guarantee, so MOBIKE not really required Paul: Be careful of ignoring retransmits over new NAT mapping. When initiating new TCP connection, resend last IKE packet, so responder can determine which TCP session to use. [Yoav edDSA draft, implicit IV draft presentation] Paul: context isnt really needed, IKE/IPsec very specific Tero: Its far fatched, but CRFG says protect against it anyway Dan Harkins: mic: the answer is that it's a signing oracle and that is a bad (if not good) thing. Context is easy fix. mcr: maybe an HSM could be tricked like that? Tero: Attacker can also only use half of it (send or receive). Lots of random things are there not under control of attacker Yoav: This same question comes up in curdle and TLS :) Dan Harkins: mic: not clear, is ipseme's decision based upon what curdle does? [Valery presentation Ambiguity in IKEv2] Paul: why not move into IKE_AUTH, and send different IKE_AUTH after failure? Valery: spec does not allow that - must start with new IKE_INIT Yoav: [missed what he said] Tero: Not a big problem - AUTH is mostly preconfigured/provisioned Dan Harkins: waiting for "will be gone" is not right— given IKEv1's tenaciousness— so if something hurries up -PSS adoption we should do it. Size of message seems to be a small price to pay. [Hu Jun] Not a big problem [David presentation QR] Dan Harkins: mic: since the child SAs use KEYMAT to generate IPsec keys and KEYMAT has the PPK then why mix in the PPK again to generate child SAs? David: Dont have a good answer right now. Scott Fluhrer: Because we want to give an implementor the option of protecting the IKE traffic mcr: I asked for identity protection. interesting child sas would be protected, what i would like to have is an architecture that leads us towards ID protection even if we dont get it right now. Eg use pseudonyms on first round to bound them on second round. site-to-site doesnt have this problem. On mobile site it is increasingly important, see for example TLS 1.3. Eg if we have a bit for ID protection would work. Dan: A future QR replacement for DH could help give us the identity protection. Paul: Isnt PPK ID an anonymous ID anyway Tero: Could add new identity type to use in the initial IKE_AUTH, and then send some new psuedonyms in the next rekey once the channel is safe. We don't need to do this as part of the QR draft, but can add it later in a separate identity protection document. Tero: Agree to not have ppk management now, but we could use the ppk notify payload for some value later. Outside of IKE SA, just used to identify the ppk Debbie: the long term goal is not to have this. Its an interim. Paul: PPK identifier can lead to privately convey ID Tero: it is good enough that we can do WG adoption call [compact format of IKEv2 payloads presentation by Valery] Paul: Tero: reserved field we only use critical bit. using them is not a problem will people really use this? IoT does a lot of weird tricks. Other forms of compression might work better. For IoT, we can reduce SA packet to 1 byte :) Maybe something completely different would be better Valery: for IoT, things split in 128 byte blocks. So a few bytes might actually gain you a lot. Tero: Actually, it is 11 + 3 bytes extra depending on mode..... Tommy: Goal of compressing is great for IoT. I am worried with complexity. You can already reduce transforms if you know what you want/need. You could rather have a new format with "profiles" where you send a profile number that maps to [a proposal] mcr: you need to compare work against generalised header compression which does a good job at removing 0's. Can prob get close to lzh. Worth comparing that. If ioT is already using [????]. Use a transform to signal this? Same as diet ESP, is this really going to be used? I dont think it will be used. I don't think it is worth spending time on now. Maybe in 5 years? Brian Weis Cisco: Rather see a completely different that would achieve more. [Enapsulating ESP in UDP for load balancing presentation] Dan Harkins: SPI already identifies a flow. No need for any other field for flow identification. Any LB decision made by the destination MUST be transparent to the source. Tero/Paul: source port can be anything already, does not need to be 4500, so use that? Lorenzto: Use flow label in ipv6 ????: Tommy: if there is a NAT too, how would this work? Presentor: We assume there is no NAT [GDOI groupkey presentation] Valery: messages can be lost. it is not reliable and can be dangerous Kathleen: please feedback on the list Tero: and CC msec list From nobody Mon Nov 14 23:48:38 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8EF129516 for ; Mon, 14 Nov 2016 23:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 5-oKvv2U_DCz for ; Mon, 14 Nov 2016 23:48:33 -0800 (PST) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3AC71294F3 for ; Mon, 14 Nov 2016 23:48:33 -0800 (PST) Received: from TobiLenovo (ObiWan2.nm.ifi.lmu.de [141.84.218.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: guggemos.tobias.nm) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id 4C50294A419 for ; Tue, 15 Nov 2016 08:48:32 +0100 (CET) From: "Tobias Guggemos" To: "'IPsecME WG'" References: <147919603374.9274.14817886910712050914.idtracker@ietfa.amsl.com> In-Reply-To: <147919603374.9274.14817886910712050914.idtracker@ietfa.amsl.com> Date: Tue, 15 Nov 2016 08:48:32 +0100 Message-ID: <000601d23f14$a9df3880$fd9da980$@mnm-team.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHSPxR9W73AL+Nf4ESJbhYsEuizb6DZqt2w Content-Language: de Archived-At: Subject: [IPsec] WG: New Version Notification for draft-mglt-ipsecme-implicit-iv-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 07:48:36 -0000 Hey all, We just published a new version of the Implicit-IV draft, addressing the = comments we received. Any comments are more than welcome. Regards Tobias -----Urspr=C3=BCngliche Nachricht----- Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Gesendet: Dienstag, 15. November 2016 08:47 An: Yoav Nir ; Daniel Migault = ; Tobias Guggemos Betreff: New Version Notification for = draft-mglt-ipsecme-implicit-iv-02.txt A new version of I-D, draft-mglt-ipsecme-implicit-iv-02.txt has been successfully submitted by Tobias Guggemos and posted to the = IETF repository. Name: draft-mglt-ipsecme-implicit-iv Revision: 02 Title: Implicit IV for Counter-based Ciphers in IPsec Document date: 2016-11-15 Group: Individual Submission Pages: 7 URL: = https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-implicit-iv-02.tx= t Status: = https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ Htmlized: = https://tools.ietf.org/html/draft-mglt-ipsecme-implicit-iv-02 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-mglt-ipsecme-implicit-iv-02 Abstract: IPsec ESP sends an initialization vector (IV) or nonce in each packet, adding 8 or 16 octets. Some algorithms such as AES-GCM, AES- CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not require an unpredictable nonce. When using such algorithms the packet counter value can be used to generate a nonce, saving 8 octets per packet. This document describes how to do this. = =20 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. The IETF Secretariat From nobody Tue Nov 15 00:03:31 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921611294F3 for ; Tue, 15 Nov 2016 00:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 MVE53xYTplAt for ; Tue, 15 Nov 2016 00:03:27 -0800 (PST) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2D91129A35 for ; Tue, 15 Nov 2016 00:03:26 -0800 (PST) Received: from TobiLenovo (ObiWan2.nm.ifi.lmu.de [141.84.218.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: guggemos.tobias.nm) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id A316A94A3F5 for ; Tue, 15 Nov 2016 09:03:25 +0100 (CET) From: "Tobias Guggemos" To: "'IPsecME WG'" References: <147919697235.10340.1449426152122462619.idtracker@ietfa.amsl.com> In-Reply-To: <147919697235.10340.1449426152122462619.idtracker@ietfa.amsl.com> Date: Tue, 15 Nov 2016 09:03:26 +0100 Message-ID: <000701d23f16$be5b71a0$3b1254e0$@mnm-team.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHSPxatKzKGGaHMD0Ke6GWOJCGNzqDZrzpA Content-Language: de Archived-At: Subject: [IPsec] WG: New Version Notification for draft-mglt-ipsecme-diet-esp-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 08:03:28 -0000 Hey all, We just published a new version of the Diet-ESP draft, addressing the = comments we received. Any comments are more than welcome. Regards Tobias -----Urspr=C3=BCngliche Nachricht----- Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Gesendet: Dienstag, 15. November 2016 09:03 An: Carsten Bormann ; Daniel Migault = ; Tobias Guggemos Betreff: New Version Notification for draft-mglt-ipsecme-diet-esp-03.txt A new version of I-D, draft-mglt-ipsecme-diet-esp-03.txt has been successfully submitted by Tobias Guggemos and posted to the = IETF repository. Name: draft-mglt-ipsecme-diet-esp Revision: 03 Title: ESP Header Compression and Diet-ESP Document date: 2016-11-15 Group: Individual Submission Pages: 41 URL: = https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-diet-esp-03.txt Status: = https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/ Htmlized: = https://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-03 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-mglt-ipsecme-diet-esp-03 Abstract: ESP Header Compression (EHC) defines a flexible framework to compress communications protected with IPsec/ESP. Compression and decompression is defined by EHC Rules orchestrated by EHC Strategies. The document specifies the Diet-ESP EHC Strategy and associated EHC Rules. Diet-ESP compresses up to 32 bytes per packet for traditional IPv6 VPN and up to 66 bytes for IPv6 VPN set over a single TCP or UDP session. = =20 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. The IETF Secretariat From nobody Tue Nov 15 01:13:08 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DCB1296A9 for ; Tue, 15 Nov 2016 01:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 TEnrIvoAxXRF for ; Tue, 15 Nov 2016 01:13:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D96C2129450 for ; Tue, 15 Nov 2016 01:13:01 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAK01801; Tue, 15 Nov 2016 09:12:59 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 15 Nov 2016 09:12:52 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 15 Nov 2016 17:12:46 +0800 From: Xuxiaohu To: Paul Wouters , "ipsec@ietf.org WG" Thread-Topic: [IPsec] IETF97 meeting raw notes Thread-Index: AQHSPwrY2pR67zAqBUGwJ/ydy4tqEKDZvKOK Date: Tue, 15 Nov 2016 09:12:45 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB35BFE@NKGEML515-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.127.64] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.582AD19C.0004, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0e5cf83b3660916bfc24bc7d614278d6 Archived-At: Subject: [IPsec] =?gb2312?b?tPC4tDogIElFVEY5NyBtZWV0aW5nIHJhdyBub3Rlcw==?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 09:13:06 -0000 SGkgYWxsLA0KDQpKdXN0IHNvbWUgY2xhcmlmaWNhdGlvbnMgb2YgdGhlIG1vdGl2YXRpb24gZm9y IEVuYXBzdWxhdGluZyBFU1AgaW4gVURQIGZvciBsb2FkIGJhbGFuY2luZzogDQoNCjEpIFRoZSBs b2FkLWJhbGFuY2luZyBoZXJlIG1lYW5zIGRpc3RyaWJ1dGluZyBJUHNlYyB0cmFmZmljIGZsb3dz IG92ZXIgbXVsaXRwbGUgRUNNUHMgKEVxdWFsLUNvc3QgTXVsdGlwYXRoKSB3aXRoaW4gSVAgV0FO IChXaWRlIEFyZWEgTmV0d29yayksIHJhdGhlciB0aGFuIG11bHRpcGxlIElQc2VjIGdhdGV3YXlz LiBTaW5jZSBtb3N0IGV4aXN0aW5nIGNvcmUgcm91dGVycyB3aXRoaW4gSVAgV0FOIGNhbiBhbHJl YWR5IHN1cHBvcnQgYmFsYW5jaW5nIElQIHRyYWZmaWMgZmxvd3MgYmFzZWQgb24gdGhlIGhhc2gg b2YgdGhlIGZpdmUtdHVwbGUgb2YgVURQIHBhY2tldHMsIGJ5IGVuY2Fwc3VsYXRpbmcgSVBzZWMg RW5jYXBzdWxhdGluZyBTZWN1cml0eSBQYXlsb2FkIChFU1ApIHBhY2tldHMgaW5zaWRlIFVEUCBw YWNrZXRzIHdpdGggdGhlIFVEUCBzb3VyY2UgcG9ydCBiZWluZyB1c2VkIGFzIGFuIGVudHJvcHkg ZmllbGQsIGl0IHdpbGwgZW5hYmxlIGV4aXN0aW5nIGNvcmUgcm91dGVycyB0byBwZXJmb3JtIGVm ZmljaWVudCBsb2FkLWJhbGFuY2luZyBvZiB0aGUgSVBzZWMgdHVubmVsZWQgdHJhZmZpYyB3aXRo b3V0IHJlcXVpcmluZyBhbnkgY2hhbmdlIHRvIHRoZW0uIEFGQUlLLCBsb2FkLWJhbGFuY2luZyBi YXNlZCBvbiBTUEkgaGFzIG5vdCBiZWVuIHdpZGVseSBzdXBwb3J0ZWQgYnkgZXhpc3RpbmcgY29y ZSByb3V0ZXJzIHdpdGhpbiBJUCBXQU4uDQoNCjIpIFRoaXMgRVNQLWluLVVEUCBlbmNhcHN1bGF0 aW9uIGlzIG1haW5seSB0YXJnZXRlZCBmb3IgdGhlIHNjZW5hcmlvIHdoZXJlIHRoZXJlIGlzIG5v IE5BVCBib3ggYmV0d2VlbiBJUHNlYyB0dW5uZWwgZW5kcG9pbnRzLCBmb3IgaW5zdGFuY2UsIGJy YW5jaCBvZmZpY2VzIGFuZCBoZWFkcXVhdGVyIGFyZSBjb25uZWN0ZWQgb3ZlciB0aGUgSW50ZXJu ZXQgYnkgdXNpbmcgSVBzZWMgZ2F0ZXdheXMgdGhhdCB1c2UgcHVibGljIElQIGFkZHJlc3NlcyBh cyB0dW5uZWwgZW5kcG9pbnRzLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IElQc2VjIFtpcHNlYy1i b3VuY2VzQGlldGYub3JnXSC0+rHtIFBhdWwgV291dGVycyBbcGF1bEBub2hhdHMuY2FdDQq3osvN yrG85DogMjAxNsTqMTHUwjE1yNUgMTQ6MzANCsrVvP7IyzogaXBzZWNAaWV0Zi5vcmcgV0cNCtb3 zOI6IFtJUHNlY10gSUVURjk3IG1lZXRpbmcgcmF3IG5vdGVzDQoNClRlcm86IEFnZW5kYSB0YWxr DQpUZXJvOiBkZG9zIGFuZCBzYWZlY3VydmVzIGluIEFVVEg0OA0KVGVybzogNDMwNy83MzIxIGJp cyBkb2N1bWVudHMNCkRhdmlkOiBhbnkgY29uY2VybnMgd2l0aCA3MzIxYmlzIGZvciBXR0xDID8g IG5vbmUgZnJvbSByb29tDQpUZXJvOiBlbmNhcHMgZWREU0EgYWRvcHRlZA0KVGVybzogU3BsaXQg ZG5zLCBpbXBsaWNpdCBpdHYsIHdhaXRpbmcgZm9yIGFkb3B0aW9uDQoNCltzcGxpdCBkbnMgcHJl c2VudGF0aW9uXQ0KU29tZSBwdXNoIHRvIGdldCBlYXJseSBjb2RlIHBvaW50IGRvbmUgYnkgVG9t bXksIFBhdWwgYW5kIFZhbGVyeQ0KDQpbdGNwIGVuY2FwcyBwcmVzZW50YXRpb25dDQpZb2F2OiB3 aHkgbWVudGlvbiBhbnl0aGluZyBiaXQgVENQIChodHRwLCBxdWljaykNClRvbW15OiB3ZSBraW5k IG9mIHdhbnQgdG8gdGVsbCBwZW9wbGUgdGhpcyB3b3JrcyBmb3Igb3RoZXIgdHJhbnNwb3J0cw0K WW9hdjogSSdkIG5lZWQgYSBuZXcgZG9jdW1lbnQgYW55d2F5IGZvciBTQ1RQIG9yIHNvbWV0aGlu ZyBlbHNlDQoNClZhbGVyeTogWW91IG11c3Qgc3BlY2lmeSBtb3JlIHByZWNpc2VseSB0byBlbnN1 cmUgaW50ZXJvcA0KVG9tbXk6IFRDUCBpcyBvcGVuZWQgYnkgaW5pdGlhdG9yLiBTZXJ2ZXIgc2hv dWxkIGFjY2VwdCBhbnkgdGNwIGNvbm5lY3Rpb25zDQogICAgICAgICh3aXRoIHNhbmUgbGltaXQp DQpWYWxlcnk6IHNvIHlvdSBuZWVkIHRvIHN1cHBvcnQgbXVsdGlwbGUgVENQIGNvbm5lY3Rpb25z IGZvciBhIHNpbmdsZSBTQQ0KICAgICAgICAgSSB0aGluayBtb3JlIHNwZWNpZmljcw0KW0h1IEp1 bl0gV2hpY2ggVENQIHNlc3Npb24gdG8gdXNlPyB3aGF0IGlzIHRoZSB1c2UgY2FzZSB0byBzdXBw b3J0IG11bHRpcGxlIFRDUA0KICAgICAgIGNvbm5lY3Rpb25zLg0KVGVybzogIGNhbiBtZSBtYW5k YXRlIE1PQklLRT8NCnZhcmlvdXMgcGVvcGxlIGluY2x1ZGluZyBZb2F2LCBQYXVsIGFuZCBUb21t eTogcGxlYXNlIGRvIG5vdA0KVG9tbXk6IFRDUCAzd2F5IGhhbmRzaGFrZSBnaXZlcyBzb21lIGd1 YXJhbnRlZSwgc28gTU9CSUtFIG5vdCByZWFsbHkgcmVxdWlyZWQNClBhdWw6IEJlIGNhcmVmdWwg b2YgaWdub3JpbmcgcmV0cmFuc21pdHMgb3ZlciBuZXcgTkFUIG1hcHBpbmcuDQogICAgICAgV2hl biBpbml0aWF0aW5nIG5ldyBUQ1AgY29ubmVjdGlvbiwgcmVzZW5kIGxhc3QgSUtFIHBhY2tldCwg c28NCiAgICAgICByZXNwb25kZXIgY2FuIGRldGVybWluZSB3aGljaCBUQ1Agc2Vzc2lvbiB0byB1 c2UuDQoNCltZb2F2IGVkRFNBIGRyYWZ0LCBpbXBsaWNpdCBJViBkcmFmdCBwcmVzZW50YXRpb25d DQpQYXVsOiBjb250ZXh0IGlzbnQgcmVhbGx5IG5lZWRlZCwgSUtFL0lQc2VjIHZlcnkgc3BlY2lm aWMNClRlcm86IEl0cyBmYXIgZmF0Y2hlZCwgYnV0IENSRkcgc2F5cyBwcm90ZWN0IGFnYWluc3Qg aXQgYW55d2F5DQpEYW4gSGFya2luczogbWljOiB0aGUgYW5zd2VyIGlzIHRoYXQgaXQncyBhIHNp Z25pbmcgb3JhY2xlIGFuZCB0aGF0IGlzIGEgYmFkIChpZiBub3QgZ29vZCkgdGhpbmcuIENvbnRl eHQgaXMgZWFzeSBmaXguDQptY3I6IG1heWJlIGFuIEhTTSBjb3VsZCBiZSB0cmlja2VkIGxpa2Ug dGhhdD8NClRlcm86IEF0dGFja2VyIGNhbiBhbHNvIG9ubHkgdXNlIGhhbGYgb2YgaXQgKHNlbmQg b3IgcmVjZWl2ZSkuIExvdHMgb2YgcmFuZG9tDQogICAgICAgdGhpbmdzIGFyZSB0aGVyZSBub3Qg dW5kZXIgY29udHJvbCBvZiBhdHRhY2tlcg0KWW9hdjogVGhpcyBzYW1lIHF1ZXN0aW9uIGNvbWVz IHVwIGluIGN1cmRsZSBhbmQgVExTIDopDQpEYW4gSGFya2luczogbWljOiBub3QgY2xlYXIsIGlz IGlwc2VtZSdzIGRlY2lzaW9uIGJhc2VkIHVwb24gd2hhdCBjdXJkbGUgZG9lcz8NCg0KW1ZhbGVy eSBwcmVzZW50YXRpb24gQW1iaWd1aXR5IGluIElLRXYyXQ0KUGF1bDogd2h5IG5vdCBtb3ZlIGlu dG8gSUtFX0FVVEgsIGFuZCBzZW5kIGRpZmZlcmVudCBJS0VfQVVUSCBhZnRlciBmYWlsdXJlPw0K VmFsZXJ5OiBzcGVjIGRvZXMgbm90IGFsbG93IHRoYXQgLSBtdXN0IHN0YXJ0IHdpdGggbmV3IElL RV9JTklUDQpZb2F2OiBbbWlzc2VkIHdoYXQgaGUgc2FpZF0NClRlcm86IE5vdCBhIGJpZyBwcm9i bGVtIC0gQVVUSCBpcyBtb3N0bHkgcHJlY29uZmlndXJlZC9wcm92aXNpb25lZA0KRGFuIEhhcmtp bnM6IHdhaXRpbmcgZm9yICJ3aWxsIGJlIGdvbmUiIGlzIG5vdCByaWdodKGqIGdpdmVuIElLRXYx J3MgdGVuYWNpb3VzbmVzc6GqIHNvIGlmIHNvbWV0aGluZyBodXJyaWVzIHVwIC1QU1MgYWRvcHRp b24gd2Ugc2hvdWxkIGRvIGl0LiBTaXplIG9mIG1lc3NhZ2Ugc2VlbXMgdG8gYmUgYSBzbWFsbCBw cmljZSB0byBwYXkuDQpbSHUgSnVuXSBOb3QgYSBiaWcgcHJvYmxlbQ0KDQpbRGF2aWQgcHJlc2Vu dGF0aW9uIFFSXQ0KRGFuIEhhcmtpbnM6IG1pYzogc2luY2UgdGhlIGNoaWxkIFNBcyB1c2UgS0VZ TUFUIHRvIGdlbmVyYXRlIElQc2VjIGtleXMgYW5kIEtFWU1BVCBoYXMgdGhlIFBQSyB0aGVuIHdo eSBtaXggaW4gdGhlIFBQSyBhZ2FpbiB0byBnZW5lcmF0ZSBjaGlsZCBTQXM/DQpEYXZpZDogRG9u dCBoYXZlIGEgZ29vZCBhbnN3ZXIgcmlnaHQgbm93Lg0KU2NvdHQgRmx1aHJlcjogQmVjYXVzZSB3 ZSB3YW50IHRvIGdpdmUgYW4gaW1wbGVtZW50b3IgdGhlIG9wdGlvbiBvZiBwcm90ZWN0aW5nIHRo ZSBJS0UgdHJhZmZpYw0KbWNyOiBJIGFza2VkIGZvciBpZGVudGl0eSBwcm90ZWN0aW9uLiBpbnRl cmVzdGluZyBjaGlsZCBzYXMgd291bGQgYmUgcHJvdGVjdGVkLCB3aGF0IGkgd291bGQgbGlrZSB0 byBoYXZlIGlzIGFuIGFyY2hpdGVjdHVyZSB0aGF0IGxlYWRzIHVzIHRvd2FyZHMgSUQgcHJvdGVj dGlvbiBldmVuIGlmIHdlIGRvbnQgZ2V0IGl0IHJpZ2h0IG5vdy4gRWcgdXNlIHBzZXVkb255bXMg b24gZmlyc3Qgcm91bmQgdG8gYm91bmQgdGhlbSBvbiBzZWNvbmQgcm91bmQuIHNpdGUtdG8tc2l0 ZSBkb2VzbnQgaGF2ZSB0aGlzIHByb2JsZW0uIE9uIG1vYmlsZSBzaXRlIGl0IGlzIGluY3JlYXNp bmdseSBpbXBvcnRhbnQsIHNlZSBmb3IgZXhhbXBsZSBUTFMgMS4zLiBFZyBpZiB3ZSBoYXZlIGEg Yml0IGZvciBJRCBwcm90ZWN0aW9uIHdvdWxkIHdvcmsuDQpEYW46IEEgZnV0dXJlIFFSIHJlcGxh Y2VtZW50IGZvciBESCBjb3VsZCBoZWxwIGdpdmUgdXMgdGhlIGlkZW50aXR5IHByb3RlY3Rpb24u DQpQYXVsOiBJc250IFBQSyBJRCBhbiBhbm9ueW1vdXMgSUQgYW55d2F5DQpUZXJvOiBDb3VsZCBh ZGQgbmV3IGlkZW50aXR5IHR5cGUgdG8gdXNlIGluIHRoZSBpbml0aWFsIElLRV9BVVRILCBhbmQg dGhlbiBzZW5kIHNvbWUgbmV3IHBzdWVkb255bXMgaW4gdGhlIG5leHQgcmVrZXkgb25jZSB0aGUg Y2hhbm5lbCBpcyBzYWZlLiBXZSBkb24ndCBuZWVkIHRvIGRvIHRoaXMgYXMgcGFydCBvZiB0aGUg UVIgZHJhZnQsIGJ1dCBjYW4gYWRkIGl0IGxhdGVyIGluIGEgc2VwYXJhdGUgaWRlbnRpdHkgcHJv dGVjdGlvbiBkb2N1bWVudC4NClRlcm86IEFncmVlIHRvIG5vdCBoYXZlIHBwayBtYW5hZ2VtZW50 IG5vdywgYnV0IHdlIGNvdWxkIHVzZSB0aGUgcHBrIG5vdGlmeSBwYXlsb2FkIGZvciBzb21lIHZh bHVlIGxhdGVyLiBPdXRzaWRlIG9mIElLRSBTQSwganVzdCB1c2VkIHRvIGlkZW50aWZ5IHRoZSBw cGsNCkRlYmJpZTogdGhlIGxvbmcgdGVybSBnb2FsIGlzIG5vdCB0byBoYXZlIHRoaXMuIEl0cyBh biBpbnRlcmltLg0KUGF1bDogUFBLIGlkZW50aWZpZXIgY2FuIGxlYWQgdG8gcHJpdmF0ZWx5IGNv bnZleSBJRA0KVGVybzogaXQgaXMgZ29vZCBlbm91Z2ggdGhhdCB3ZSBjYW4gZG8gV0cgYWRvcHRp b24gY2FsbA0KDQpbY29tcGFjdCBmb3JtYXQgb2YgSUtFdjIgcGF5bG9hZHMgcHJlc2VudGF0aW9u IGJ5IFZhbGVyeV0NCg0KUGF1bDoNClRlcm86IHJlc2VydmVkIGZpZWxkIHdlIG9ubHkgdXNlIGNy aXRpY2FsIGJpdC4gdXNpbmcgdGhlbSBpcyBub3QgYSBwcm9ibGVtDQogICAgICAgd2lsbCBwZW9w bGUgcmVhbGx5IHVzZSB0aGlzPyBJb1QgZG9lcyBhIGxvdCBvZiB3ZWlyZCB0cmlja3MuDQogICAg ICAgT3RoZXIgZm9ybXMgb2YgY29tcHJlc3Npb24gbWlnaHQgd29yayBiZXR0ZXIuDQogICAgICAg Rm9yIElvVCwgd2UgY2FuIHJlZHVjZSBTQSBwYWNrZXQgdG8gMSBieXRlIDopDQogICAgICAgTWF5 YmUgc29tZXRoaW5nIGNvbXBsZXRlbHkgZGlmZmVyZW50IHdvdWxkIGJlIGJldHRlcg0KVmFsZXJ5 OiBmb3IgSW9ULCB0aGluZ3Mgc3BsaXQgaW4gMTI4IGJ5dGUgYmxvY2tzLiBTbyBhIGZldyBieXRl cyBtaWdodCBhY3R1YWxseQ0KICAgICAgICAgZ2FpbiB5b3UgYSBsb3QuDQpUZXJvOiBBY3R1YWxs eSwgaXQgaXMgMTEgKyAzIGJ5dGVzIGV4dHJhIGRlcGVuZGluZyBvbiBtb2RlLi4uLi4NClRvbW15 OiBHb2FsIG9mIGNvbXByZXNzaW5nIGlzIGdyZWF0IGZvciBJb1QuIEkgYW0gd29ycmllZCB3aXRo IGNvbXBsZXhpdHkuDQogICAgICAgIFlvdSBjYW4gYWxyZWFkeSByZWR1Y2UgdHJhbnNmb3JtcyBp ZiB5b3Uga25vdyB3aGF0IHlvdSB3YW50L25lZWQuDQogICAgICAgIFlvdSBjb3VsZCByYXRoZXIg aGF2ZSBhIG5ldyBmb3JtYXQgd2l0aCAicHJvZmlsZXMiIHdoZXJlIHlvdSBzZW5kDQogICAgICAg IGEgcHJvZmlsZSBudW1iZXIgdGhhdCBtYXBzIHRvIFthIHByb3Bvc2FsXQ0KbWNyOiB5b3UgbmVl ZCB0byBjb21wYXJlIHdvcmsgYWdhaW5zdCBnZW5lcmFsaXNlZCBoZWFkZXIgY29tcHJlc3Npb24g d2hpY2gNCmRvZXMgYSBnb29kIGpvYiBhdCByZW1vdmluZyAwJ3MuIENhbiBwcm9iIGdldCBjbG9z ZSB0byBsemguIFdvcnRoIGNvbXBhcmluZw0KdGhhdC4gSWYgaW9UIGlzIGFscmVhZHkgdXNpbmcg Wz8/Pz9dLiBVc2UgYSB0cmFuc2Zvcm0gdG8gc2lnbmFsIHRoaXM/IFNhbWUNCmFzIGRpZXQgRVNQ LCBpcyB0aGlzIHJlYWxseSBnb2luZyB0byBiZSB1c2VkPyBJIGRvbnQgdGhpbmsgaXQgd2lsbCBi ZSB1c2VkLg0KSSBkb24ndCB0aGluayBpdCBpcyB3b3J0aCBzcGVuZGluZyB0aW1lIG9uIG5vdy4g TWF5YmUgaW4gNSB5ZWFycz8NCkJyaWFuIFdlaXMgQ2lzY286IFJhdGhlciBzZWUgYSBjb21wbGV0 ZWx5IGRpZmZlcmVudCB0aGF0IHdvdWxkIGFjaGlldmUgbW9yZS4NCg0KW0VuYXBzdWxhdGluZyBF U1AgaW4gVURQIGZvciBsb2FkIGJhbGFuY2luZyBwcmVzZW50YXRpb25dDQpEYW4gSGFya2luczog U1BJIGFscmVhZHkgaWRlbnRpZmllcyBhIGZsb3cuIE5vIG5lZWQgZm9yIGFueSBvdGhlciBmaWVs ZCBmb3IgZmxvdyBpZGVudGlmaWNhdGlvbi4gQW55IExCIGRlY2lzaW9uIG1hZGUgYnkgdGhlIGRl c3RpbmF0aW9uIE1VU1QgYmUgdHJhbnNwYXJlbnQgdG8gdGhlIHNvdXJjZS4NClRlcm8vUGF1bDog c291cmNlIHBvcnQgY2FuIGJlIGFueXRoaW5nIGFscmVhZHksIGRvZXMgbm90IG5lZWQgdG8gYmUg NDUwMCwgc28NCiAgICAgICAgICAgIHVzZSB0aGF0Pw0KTG9yZW56dG86IFVzZSBmbG93IGxhYmVs IGluIGlwdjYNCj8/Pz86DQoNClRvbW15OiBpZiB0aGVyZSBpcyBhIE5BVCB0b28sIGhvdyB3b3Vs ZCB0aGlzIHdvcms/DQpQcmVzZW50b3I6IFdlIGFzc3VtZSB0aGVyZSBpcyBubyBOQVQNCg0KW0dE T0kgZ3JvdXBrZXkgcHJlc2VudGF0aW9uXQ0KVmFsZXJ5OiBtZXNzYWdlcyBjYW4gYmUgbG9zdC4g aXQgaXMgbm90IHJlbGlhYmxlIGFuZCBjYW4gYmUgZGFuZ2Vyb3VzDQpLYXRobGVlbjogcGxlYXNl IGZlZWRiYWNrIG9uIHRoZSBsaXN0DQpUZXJvOiBhbmQgQ0MgbXNlYyBsaXN0DQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJUHNlYyBtYWlsaW5nIGxp c3QNCklQc2VjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lwc2Vj From nobody Tue Nov 15 04:54:24 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39808129536 for ; Tue, 15 Nov 2016 04:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 WMXmiGtqHVeA for ; Tue, 15 Nov 2016 04:54:21 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 D78BD12942F for ; Tue, 15 Nov 2016 04:54:20 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tJ6ls5hR3z3JZ; Tue, 15 Nov 2016 13:54:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1479214457; bh=/EYjjKYQ5C9xQWnu5hqDsXX8/7gv++70V3bvk54d5dI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=NFS1ov2BgVn6G5pqUPVn+KY99/TjvakZuw857HvnU3H2BywNooyxost6QqgwXUpOH tFYnBH3oN2prt9SqWQgExsKDATxRoPv/jJIPpsScUt4sKe/1ypO887Ra8vOTDfK0Xv jTKPyJngqqxcHiaZ5xVg4xpI6yd9xFzWTkFpKErg= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id tmMIxNO9ydFZ; Tue, 15 Nov 2016 13:54:15 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 15 Nov 2016 13:54:15 +0100 (CET) Received: from [10.0.10.147] (unknown [211.44.215.72]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 04F7A35A2B3; Tue, 15 Nov 2016 07:54:13 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 04F7A35A2B3 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (14A456) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB35BFE@NKGEML515-MBX.china.huawei.com> Date: Tue, 15 Nov 2016 21:54:10 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <066BA6DE-B0AC-40D6-84FC-7CD36D1D30C7@nohats.ca> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB35BFE@NKGEML515-MBX.china.huawei.com> To: Xuxiaohu Archived-At: Cc: "ipsec@ietf.org WG" Subject: [IPsec] =?utf-8?b?RW5jYXBzIGRvY3VtZW50LCB3YXMgUmU6ICDnrZTlpI06?= =?utf-8?q?__IETF97_meeting_raw_notes?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 12:54:22 -0000 Sent from my iPhone > On Nov 15, 2016, at 18:12, Xuxiaohu wrote: >=20 > Hi all, >=20 > Just some clarifications of the motivation for Enapsulating ESP in UDP for= load balancing:=20 >=20 > 1) The load-balancing here means distributing IPsec traffic flows over mul= itple ECMPs (Equal-Cost Multipath) within IP WAN (Wide Area Network), rather= than multiple IPsec gateways. Since most existing core routers within IP WA= N can already support balancing IP traffic flows based on the hash of the fi= ve-tuple of UDP packets, by encapsulating IPsec Encapsulating Security Paylo= ad (ESP) packets inside UDP packets with the UDP source port being used as a= n entropy field, it will enable existing core routers to perform efficient l= oad-balancing of the IPsec tunneled traffic without requiring any change to t= hem. I do not understand "entropy"? If you have non-NATed endpoints and you do ESPinUDP as per RFC 3948, isn't t= hat unique enough since you assume no NAT? On our implementation (libreswan) you can configure this using forceencaps=3D= yes which results that endpoint in "lying" with the NAT discovery payloads s= o it "detects NAT" and uses encapsulation. Can you explain why you think you need a new document? Paul >=20 From nobody Tue Nov 15 16:45:12 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4364F1294B5 for ; Tue, 15 Nov 2016 16:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 b_F6hhgSr0iQ for ; Tue, 15 Nov 2016 16:45:08 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A8201294CA for ; Tue, 15 Nov 2016 16:45:07 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAL20912; Wed, 16 Nov 2016 00:45:06 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 16 Nov 2016 00:45:05 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Wed, 16 Nov 2016 08:45:00 +0800 From: Xuxiaohu To: Paul Wouters Thread-Topic: =?gb2312?B?RW5jYXBzIGRvY3VtZW50LCB3YXMgUmU6IFtJUHNlY10gtPC4tDogIElFVEY5?= =?gb2312?Q?7_meeting_raw_notes?= Thread-Index: AQHSPz9mHIgCKML1f0uSL89n639EHqDaw+k1 Date: Wed, 16 Nov 2016 00:45:00 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB35EA2@NKGEML515-MBX.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB35BFE@NKGEML515-MBX.china.huawei.com>, <066BA6DE-B0AC-40D6-84FC-7CD36D1D30C7@nohats.ca> In-Reply-To: <066BA6DE-B0AC-40D6-84FC-7CD36D1D30C7@nohats.ca> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.113.232] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.582BAC12.00F9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 71bc61feb133f78c417bdd07819756c5 Archived-At: Cc: "ipsec@ietf.org WG" Subject: [IPsec] =?gb2312?b?tPC4tDogRW5jYXBzIGRvY3VtZW50LCB3YXMgUmU6ICA=?= =?gb2312?b?tPC4tDogIElFVEY5NyBtZWV0aW5nIHJhdyBub3Rlcw==?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 00:45:11 -0000 SGkgUGF1bCwNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBJdCBzYWlkIGluIHRoZSBkcmFm dCB0aGF0IA0KDQoiICBOb3RlIHRoYXQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgRVNQLWlu LVVEUCBlbmNhcHN1bGF0aW9uIGFzDQogIHByb3Bvc2VkIGluIHRoaXMgZG9jdW1lbnQgYW5kIHRo ZSBFU1AtaW4tVURQIGVuY2Fwc3VsYXRpb24gYXMNCiAgZGVzY3JpYmVkIGluIFtSRkMzOTQ4XSBp cyB0aGF0IHRoZSBmb3JtZXIgdXNlcyB0aGUgVURQIHR1bm5lbCBmb3INCiAgbG9hZC1iYWxhbmNp bmcgaW1wcm92ZW1lbnQgcHVycG9zZSBhbmQgdGhlcmVmb3JlIHRoZSBzb3VyY2UgcG9ydCBpcw0K ICB1c2VkIGFzIGFuIGVudHJvcHkgZmllbGQgd2hpbGUgdGhlIGxhdHRlciB1c2VzIHRoZSBVRFAg dHVubmVsIGZvcg0KICBOQVQgdHJhdmVyc2UgcHVycG9zZSBhbmQgdGhlcmVmb3JlIHRoZSBzb3Vy Y2UgcG9ydCBpcyBzZXQgdG8gYQ0KICBjb25zdGFudCB2YWx1ZSAoaS5lLiwgNDUwMCkuIg0KDQpN b3JlIHNwZWNpZmljYWxseSwgd2hlbiB1c2luZyB0aGUgRVNQLWluLVVEUCBlbmNhcHN1bGF0aW9u IGFzIHBlciBSRkMgMzk0OCwgYWxsIHRyYWZmaWMgZmxvd3Mgd291bGQgYmUgZW5jYXBzdWxhdGVk IHdpdGhpbiBhIHNpbmdsZSBVRFAgdHVubmVsIHdoZXJlIHRoZSBzcnQgYW5kIGRlc3QgcG9ydCBh cmUgc2V0IHRvIDQ1MDAuIEFzIGEgcmVzdWx0LCBhbGwgZW5jYXBzdWxhdGVkIHRyYWZmaWMgZmxv d3Mgd291bGQgaGF2ZSB0byBmb3J3YXJkZWQgYWxvbmcgYSBzaW5nbGUgcGF0aCBieSBjb3JlIHJv dXRlcnMgd2hlbiB1c2luZyB0aGUgd2lkZWx5IHN1cHBvcnRlZCBVRFAgZml2ZS10dXBsZSBiYXNl ZCBsb2FkLWJhbGFuY2luZyBtZWNoYW5pc20uIEluIGNvbnRyYXN0LCB3aGVuIHVzaW5nIHRoZSBF U1AtaW4tVURQIGVuY2Fwc3VsYXRpb24gYXMgZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQsIGRpZmZl cmVudCB0cmFmZmljIGZsb3dzIHdvdWxkIGJlIGVuY2Fwc3VsYXRlZCB3aXRoaW4gVURQIHR1bm5l bHMgd2l0aCBkaWZmZXJlbnQgc3J0IHBvcnQgdmFsdWVzLiBJbiB0aGlzIHdheSwgdGhvc2UgZW5j YXBzdWxhdGVkIHRyYWZmaWMgZmxvd3MgY291bGQgYmUgZGlzdHJpYnV0ZWQgYW1vbmcgZGlmZmVy ZW50IEVDTVBzIGJ5IGNvcmUgcm91dGVycyBvbiBiYXNpcyBvZiB0aGUgZml2ZSB0dXBsZSBvZiB0 aGUgVURQIHBhY2tldHMuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IFBhdWwgV291dGVycyBbcGF1bEBu b2hhdHMuY2FdDQq3osvNyrG85DogMjAxNsTqMTHUwjE1yNUgMjA6NTQNCsrVvP7IyzogWHV4aWFv aHUNCrOty806IGlwc2VjQGlldGYub3JnIFdHDQrW98ziOiBFbmNhcHMgZG9jdW1lbnQsIHdhcyBS ZTogW0lQc2VjXSC08Li0OiAgSUVURjk3IG1lZXRpbmcgcmF3IG5vdGVzDQoNClNlbnQgZnJvbSBt eSBpUGhvbmUNCj4gT24gTm92IDE1LCAyMDE2LCBhdCAxODoxMiwgWHV4aWFvaHUgPHh1eGlhb2h1 QGh1YXdlaS5jb20+IHdyb3RlOg0KPg0KPiBIaSBhbGwsDQo+DQo+IEp1c3Qgc29tZSBjbGFyaWZp Y2F0aW9ucyBvZiB0aGUgbW90aXZhdGlvbiBmb3IgRW5hcHN1bGF0aW5nIEVTUCBpbiBVRFAgZm9y IGxvYWQgYmFsYW5jaW5nOg0KPg0KPiAxKSBUaGUgbG9hZC1iYWxhbmNpbmcgaGVyZSBtZWFucyBk aXN0cmlidXRpbmcgSVBzZWMgdHJhZmZpYyBmbG93cyBvdmVyIG11bGl0cGxlIEVDTVBzIChFcXVh bC1Db3N0IE11bHRpcGF0aCkgd2l0aGluIElQIFdBTiAoV2lkZSBBcmVhIE5ldHdvcmspLCByYXRo ZXIgdGhhbiBtdWx0aXBsZSBJUHNlYyBnYXRld2F5cy4gU2luY2UgbW9zdCBleGlzdGluZyBjb3Jl IHJvdXRlcnMgd2l0aGluIElQIFdBTiBjYW4gYWxyZWFkeSBzdXBwb3J0IGJhbGFuY2luZyBJUCB0 cmFmZmljIGZsb3dzIGJhc2VkIG9uIHRoZSBoYXNoIG9mIHRoZSBmaXZlLXR1cGxlIG9mIFVEUCBw YWNrZXRzLCBieSBlbmNhcHN1bGF0aW5nIElQc2VjIEVuY2Fwc3VsYXRpbmcgU2VjdXJpdHkgUGF5 bG9hZCAoRVNQKSBwYWNrZXRzIGluc2lkZSBVRFAgcGFja2V0cyB3aXRoIHRoZSBVRFAgc291cmNl IHBvcnQgYmVpbmcgdXNlZCBhcyBhbiBlbnRyb3B5IGZpZWxkLCBpdCB3aWxsIGVuYWJsZSBleGlz dGluZyBjb3JlIHJvdXRlcnMgdG8gcGVyZm9ybSBlZmZpY2llbnQgbG9hZC1iYWxhbmNpbmcgb2Yg dGhlIElQc2VjIHR1bm5lbGVkIHRyYWZmaWMgd2l0aG91dCByZXF1aXJpbmcgYW55IGNoYW5nZSB0 byB0aGVtLg0KDQpJIGRvIG5vdCB1bmRlcnN0YW5kICJlbnRyb3B5Ij8NCklmIHlvdSBoYXZlIG5v bi1OQVRlZCBlbmRwb2ludHMgYW5kIHlvdSBkbyBFU1BpblVEUCBhcyBwZXIgUkZDIDM5NDgsIGlz bid0IHRoYXQgdW5pcXVlIGVub3VnaCBzaW5jZSB5b3UgYXNzdW1lIG5vIE5BVD8NCg0KT24gb3Vy IGltcGxlbWVudGF0aW9uIChsaWJyZXN3YW4pIHlvdSBjYW4gY29uZmlndXJlIHRoaXMgdXNpbmcg Zm9yY2VlbmNhcHM9eWVzIHdoaWNoIHJlc3VsdHMgdGhhdCBlbmRwb2ludCBpbiAibHlpbmciIHdp dGggdGhlIE5BVCBkaXNjb3ZlcnkgcGF5bG9hZHMgc28gaXQgImRldGVjdHMgTkFUIiBhbmQgdXNl cyBlbmNhcHN1bGF0aW9uLg0KDQpDYW4geW91IGV4cGxhaW4gd2h5IHlvdSB0aGluayB5b3UgbmVl ZCBhIG5ldyBkb2N1bWVudD8NCg0KUGF1bA0KDQo+ From nobody Tue Nov 15 16:58:06 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 093251293D8 for ; Tue, 15 Nov 2016 16:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 qoPY-ph1Q1qY for ; Tue, 15 Nov 2016 16:58:02 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 3550C126CD8 for ; Tue, 15 Nov 2016 16:58:02 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tJQpt4d40zB2W; Wed, 16 Nov 2016 01:57:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1479257878; bh=mR3eyEDahKhQdgfo96inRCwaBM2z8VaJ0MUYIHJOcB0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=EHwrWdxVOoJwL3VzY2UMUaqLZKNlIjVuZWM2vkY88u44wshbBOyWCnTm8GGFlc7vy w55YgSsaynmqLsQobn/3tqCVSzqh3TZi7++uuGrgjXVsGvLEU6TRNGf2obYC95PMWu mV23X/M1AOxPl1Xazirii1XqZGyCuFwBCEYoRZF8= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id yHiKDzBinJiz; Wed, 16 Nov 2016 01:57:55 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 16 Nov 2016 01:57:55 +0100 (CET) Received: from [31.133.136.30] (unknown [31.133.136.30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 2027D35A2B3; Tue, 15 Nov 2016 19:57:53 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 2027D35A2B3 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (14A456) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB35EA2@NKGEML515-MBX.china.huawei.com> Date: Wed, 16 Nov 2016 09:57:48 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <18F4EA53-CD52-41CE-B11A-830DF9239CB4@nohats.ca> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB35BFE@NKGEML515-MBX.china.huawei.com> <066BA6DE-B0AC-40D6-84FC-7CD36D1D30C7@nohats.ca> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB35EA2@NKGEML515-MBX.china.huawei.com> To: Xuxiaohu Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] =?utf-8?b?562U5aSNOiBFbmNhcHMgZG9jdW1lbnQsIHdhcyBSZTog?= =?utf-8?q?_=E7=AD=94=E5=A4=8D=3A__IETF97_meeting_raw_notes?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 00:58:04 -0000 Who are you expecting to set or change the source port? If the IKE daemon, it does not know how much traffic an SA will do. So it wo= n't do a good job. If the network device will rewrite 4500, it is completely transparent to the= IKE daemon. This is fine but then I do not see why you need a standards doc= ument? Paul Sent from my iPhone > On Nov 16, 2016, at 09:45, Xuxiaohu wrote: >=20 > Hi Paul, >=20 > Thanks for your comments. It said in the draft that=20 >=20 > " Note that the difference between the ESP-in-UDP encapsulation as > proposed in this document and the ESP-in-UDP encapsulation as > described in [RFC3948] is that the former uses the UDP tunnel for > load-balancing improvement purpose and therefore the source port is > used as an entropy field while the latter uses the UDP tunnel for > NAT traverse purpose and therefore the source port is set to a > constant value (i.e., 4500)." >=20 > More specifically, when using the ESP-in-UDP encapsulation as per RFC 3948= , all traffic flows would be encapsulated within a single UDP tunnel where t= he srt and dest port are set to 4500. As a result, all encapsulated traffic f= lows would have to forwarded along a single path by core routers when using t= he widely supported UDP five-tuple based load-balancing mechanism. In contra= st, when using the ESP-in-UDP encapsulation as described in this draft, diff= erent traffic flows would be encapsulated within UDP tunnels with different s= rt port values. In this way, those encapsulated traffic flows could be distr= ibuted among different ECMPs by core routers on basis of the five tuple of t= he UDP packets. >=20 > Best regards, > Xiaohu >=20 > ________________________________________ > =E5=8F=91=E4=BB=B6=E4=BA=BA: Paul Wouters [paul@nohats.ca] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B411=E6=9C=8815=E6=97=A5 2= 0:54 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu > =E6=8A=84=E9=80=81: ipsec@ietf.org WG > =E4=B8=BB=E9=A2=98: Encaps document, was Re: [IPsec] =E7=AD=94=E5=A4=8D: I= ETF97 meeting raw notes >=20 > Sent from my iPhone >> On Nov 15, 2016, at 18:12, Xuxiaohu wrote: >>=20 >> Hi all, >>=20 >> Just some clarifications of the motivation for Enapsulating ESP in UDP fo= r load balancing: >>=20 >> 1) The load-balancing here means distributing IPsec traffic flows over mu= litple ECMPs (Equal-Cost Multipath) within IP WAN (Wide Area Network), rathe= r than multiple IPsec gateways. Since most existing core routers within IP W= AN can already support balancing IP traffic flows based on the hash of the f= ive-tuple of UDP packets, by encapsulating IPsec Encapsulating Security Payl= oad (ESP) packets inside UDP packets with the UDP source port being used as a= n entropy field, it will enable existing core routers to perform efficient l= oad-balancing of the IPsec tunneled traffic without requiring any change to t= hem. >=20 > I do not understand "entropy"? > If you have non-NATed endpoints and you do ESPinUDP as per RFC 3948, isn't= that unique enough since you assume no NAT? >=20 > On our implementation (libreswan) you can configure this using forceencaps= =3Dyes which results that endpoint in "lying" with the NAT discovery payload= s so it "detects NAT" and uses encapsulation. >=20 > Can you explain why you think you need a new document? >=20 > Paul >=20 >>=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Nov 15 17:49:54 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8211129552 for ; Tue, 15 Nov 2016 17:49:53 -0800 (PST) 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, 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 HAKebkP7frco for ; Tue, 15 Nov 2016 17:49:52 -0800 (PST) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C06129411 for ; Tue, 15 Nov 2016 17:49:52 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id f188so72819347pgc.3 for ; Tue, 15 Nov 2016 17:49:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=vPRIYuUluG196jLeS3zn5EMO9EvUgfFVdQvQWFnA2gg=; b=iB7EkiWylDanxp9JbbRwXAedufBQ+mcZoCnMxl5PQM4IgpTOSltFuVi2lXBcqWWft7 TnRVomrUGP38lXLwzdpyOygSEE+/9no6Obi6jiSZqLWdQHIV8HKk33oFrW8pOtoU3m1y gE35QphF3+CijISuZWfjBKeV1YYBEHTAW230xNAYjjskNpJJ/kYrkIy9BfvGyzU32eBD S6ZA6MsZPan7uyQAgoBWiO8PmARvDGnX02dJ50uBSzNZw/fjiFKEY8H87gEqCaAerATM 2HAfe+kecypIyRHwODKYcKRFnXsY28h/TZEQXw43W0jGZmJz92AlTXFOPSIQrSGgRhrL syeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=vPRIYuUluG196jLeS3zn5EMO9EvUgfFVdQvQWFnA2gg=; b=V/dWfA97kFLeaTuDpmsc637FsLxZvltR+TRJojOTBq785a3uvOhc80ZFTU0qsI8a7j CQkaYLEmgPqq5+ylbbk+1rHVBvGgsWkikaOs1E5V3ALVEKCYsTXWdRk1I6ZZodBTNZ8w hdgKcjdT+KAeaskWJu6GSfm44N7A+yMcERwxdWoRIE3fOE1t+rt2kJLTNiZVOAenqbzy 5X8ywxFAbVvTdmux52uYAb1ahaOiqTp31GD102OIpngBtEGQF4bCG44suEnkGPuU6qR8 Jv9d6D6sUWFn8RtP5bUB4L1d7xL3OS1CX3YzWZqJJCAs2t240bPM9FjFHIUlNa0basjK xrtg== X-Gm-Message-State: ABUngveLCnOimmezOvWZFtpjQmAgtyUV0++b+nnb4KWgxD0/d033FopcM+TXOxsqumw5/g== X-Received: by 10.99.167.67 with SMTP id w3mr2577277pgo.1.1479260992025; Tue, 15 Nov 2016 17:49:52 -0800 (PST) Received: from t2001067c03700128b0cd002daee86f00.v6.meeting.ietf.org (t2001067c03700128b0cd002daee86f00.v6.meeting.ietf.org. [2001:67c:370:128:b0cd:2d:aee8:6f00]) by smtp.gmail.com with ESMTPSA id c128sm46993356pfc.39.2016.11.15.17.49.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 17:49:51 -0800 (PST) From: Yoav Nir Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: Date: Wed, 16 Nov 2016 10:49:46 +0900 To: "ipsec@ietf.org WG" X-Mailer: Apple Mail (2.3251) Archived-At: Subject: [IPsec] Resolving the Ed448 context issue in the EdDSA draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 01:49:54 -0000 Hi, all As mentioned in Tuesday's session, Ed448 and Ed25519ctx add a new = parameter to the signature function: a context string. Setting this = string to a different value for each application (where application = could be "PKIX", "TLS", "IKE") leads to different results and thus a = signature made in one context does not validate in another context. This = reduces the attack surface for attacks involving signing oracles. The CFRG draft suggests that "contexts SHOULD NOT be used = opportunistically, as that kind of use is very error-prone. If contexts = are used, one SHOULD require all signature schemes available for use in = that purpose support contexts". As I don't think this WG is ready to = deprecate RSA, DSA, and ECDSA in one fell swoop, I think we should not = use contexts.=20 So I suggest to add the following paragraph at the end of section 2 of = the eddsa draft: The context parameter for Ed448 MUST be set to the empty string. =20 Comments? Yoav= From nobody Tue Nov 15 19:41:53 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8600C129621 for ; Tue, 15 Nov 2016 19:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 4HhcEKELUCRf for ; Tue, 15 Nov 2016 19:41:50 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 3C1D1129632 for ; Tue, 15 Nov 2016 19:41:32 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tJVRX0v4wz1HW; Wed, 16 Nov 2016 04:41:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1479267688; bh=CCwHKXNkULEcINzQOPaCF05asVHaRnusPgUdZfN2xOg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ixhkJN1uf5t5g65PSMCx/fXqDHex6v5CV5LKEDZK0NeXTZihKhaUaOpm6MQ4SwmxP f/H4x1H0KMG9eXVbP3Cx69yY+kQDTTrUwyoJYYDBjZAsgXnYNW+5hy9T9qHSv4PWOM fKnr6Y+3sBEszDSWQAv2CiBUPhPTsZKJRukH9Ay8= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id aP0joXvPfgyT; Wed, 16 Nov 2016 04:41:25 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 16 Nov 2016 04:41:25 +0100 (CET) Received: from [31.133.136.30] (unknown [31.133.136.30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 5019E35A2B3; Tue, 15 Nov 2016 22:41:23 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 5019E35A2B3 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (14A456) In-Reply-To: Date: Wed, 16 Nov 2016 12:41:19 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <8B558834-4B93-425B-B87C-C3459BF0E759@nohats.ca> References: To: Yoav Nir Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 03:41:51 -0000 > On Nov 16, 2016, at 10:49, Yoav Nir wrote: >=20 > So I suggest to add the following paragraph at the end of section 2 of the= eddsa draft: >=20 > The context parameter for Ed448 MUST be set to the empty string. I agree. Context seems useful for generic crypto but not for something that i= s already strongly bound by an IETF transport protocol. Additionally, we have a similar problem too when allowing the same key in IK= Ev1 and IKEv2 where the key has different security properties. Paul= From nobody Tue Nov 15 20:35:17 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D3412956E for ; Tue, 15 Nov 2016 20:35:15 -0800 (PST) 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, 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 oNO6lO4ztGhG for ; Tue, 15 Nov 2016 20:35:14 -0800 (PST) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 A255F1294AE for ; Tue, 15 Nov 2016 20:35:14 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id p66so74551569pga.2 for ; Tue, 15 Nov 2016 20:35:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=nFepRxxWBwwd157e/T4CQ28Rh9zBlwhg9qCcD6hic54=; b=Ylxo3LlbIIGQbMtxqwFxdVgwUBjvZ+CCgwh40L9KVaqtngZJAutKVuonQg8i8XrYHG 8Do5dIYjVV+DBIwWuTtgFCrlPCgxLa8ro4/HNRRlrVOsbl9XkPrcRZVZza5o55xO988p qvRUfWWsSzwRcoZScU6j/eowYM0Q9Ld/0B7LtjHLCmQNj42qQcbVgCxQngo6MFOPGZy6 3MiKSPvLpm8AZSwzsiEnh5pppKEGRp+HWa8zMMicEh/a74Kv1lqM9knkqGKeW9u78Fyv IGO5s99mIm8HRgLleQDk/Gl+1xLbhYfYmalLBy8Mi4G/f5cPeKJcl/fw6toffDzSP5qt R4kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=nFepRxxWBwwd157e/T4CQ28Rh9zBlwhg9qCcD6hic54=; b=GhvfbEk18O52sSbyGGYHsU5F4ViH96uzNblzzDjJLNL/eIAX/U6dQ9FOeD8zBCDK0y uyqIjA4s921SU9wCULLicXJX3eJSYkmIfgbER1TKuZvkTdlhYLOjsUmNusqCECsZ3bDm V8Edv/xH0QkSFyhJaCEQCr79yCVKZz8mc+CB9Gp4RtLqr5OLYv1x5AxBz+Q24wK/V6Bq XNlKobJoYaluyPr5iZ9DZ2L3FP6GB0Rp/8WvSCFhaqsnrmShX9gFQ8x+8Ls1DEcuuzG3 NEwzYtfRApdtSlbhML4iLdCunSOlDornrssRprOHXeBmZ1xk/6PbDBRAG+zWStL1j1aF 1lBA== X-Gm-Message-State: ABUngvcQN+elrEydaER/1g++Dg0ZWcNlhNDext2CelbaaqCUjfi4goZ2y6yAic0ffVVEXw== X-Received: by 10.98.7.83 with SMTP id b80mr1755302pfd.79.1479270914271; Tue, 15 Nov 2016 20:35:14 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:2c31:83ce:16bd:fd5f? ([2001:67c:370:128:2c31:83ce:16bd:fd5f]) by smtp.gmail.com with ESMTPSA id b80sm128422pfe.52.2016.11.15.20.35.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 20:35:13 -0800 (PST) From: Yaron Sheffer To: Paul Wouters , Yoav Nir References: <8B558834-4B93-425B-B87C-C3459BF0E759@nohats.ca> Message-ID: <8bd6a71b-d9e5-415b-a105-790e4eba1b12@gmail.com> Date: Wed, 16 Nov 2016 13:35:09 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <8B558834-4B93-425B-B87C-C3459BF0E759@nohats.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 04:35:16 -0000 On 16/11/16 12:41, Paul Wouters wrote: > > >> On Nov 16, 2016, at 10:49, Yoav Nir wrote: >> >> So I suggest to add the following paragraph at the end of section 2 of the eddsa draft: >> >> The context parameter for Ed448 MUST be set to the empty string. > > I agree. Context seems useful for generic crypto but not for something that is already strongly bound by an IETF transport protocol. > > Additionally, we have a similar problem too when allowing the same key in IKEv1 and IKEv2 where the key has different security properties. > > Paul I don't think there's any cost to having a non-empty context string, e.g. "IKEv2", and there's potentially value. TLS cross-protocol attacks show that signatures can be abused even when embedded in a transport protocol. The fact that we have the same problem elsewhere is no reason to propagate it further. Thanks, Yaron From nobody Tue Nov 15 20:47:41 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51B8129653 for ; Tue, 15 Nov 2016 20:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoVygnVQwpNy for ; Tue, 15 Nov 2016 20:47:37 -0800 (PST) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 23141129656 for ; Tue, 15 Nov 2016 20:47:37 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id l8so44876373iti.1 for ; Tue, 15 Nov 2016 20:47:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=xcSNdfKfmQFIBN1CoDkNkyHjH7xsj7x5wtqJ1fPC+5w=; b=vAqyR/5Det7nhk5XUPtNZS3ORXJYhCqeOUBrWSKXW7IRBWBzjn3WHdcbtibuMBaCFT k/IHdQv/LAfBRavaCxCqrok13qdcaJdzDl2jT0a5dGAe7QHJztSnAyMFXaFT7cit4Jei s4NxfqWG8PYiw6ms++lhT6Nvm+RQiJJsJo8H/5jJm4iqey69gV1AaAUez7rPm9mwjGKy Xi6ayJbvD1D2yqIScS4fYc9ZNFlJ9gCMwT1wRLOALMz0SaWjUr56uhVX7ZxcJLXBApiO LrhqYW08yczTAuRnD0QnV3OH1bxTG5yNrZiSax+Jz90cHtDVnEiDM0FXAl/QJPOtoBk/ ZYrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=xcSNdfKfmQFIBN1CoDkNkyHjH7xsj7x5wtqJ1fPC+5w=; b=k6tE2WVV5jubx6LYP67sqygUeqYQEE4DP4fTuhjdgmqrnsliJPeyk1bHyWCgO5ne6P dOtA/uYHpDi0yytn99Yky79M8nmwMeamk8ERMUEQlzUZfvbHhLnHp/YJsha+VB9ddEy5 64uBr/QWtqaQS+J6eMuuETapEbwMrCDHAoBqBMEHweB/h6Am28/FlDRsQg53ZD3yU9pr 73SHik+6u9tDNZZ2QeVsUWLVouvImknE+H1XKKf766fUQA/2o7P6d1z3RUF8bLECJVKs 5SghD9epDHA1f9l5xdMLJsKjn36wSmlrhL0GJs0Wn6YE77urc9kDR/OlTkiXGMUxQcAy VRnw== X-Gm-Message-State: ABUngvecoSEoBq6BOoKtC/Y4ektYQgNeZAzfxmijUlffG22TnxOr/I6yfAsO48J66WN6IntkSp4pVf7Lg43AuA== X-Received: by 10.107.12.214 with SMTP id 83mr1183415iom.10.1479271656471; Tue, 15 Nov 2016 20:47:36 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.32.10 with HTTP; Tue, 15 Nov 2016 20:47:35 -0800 (PST) Received: by 10.107.32.10 with HTTP; Tue, 15 Nov 2016 20:47:35 -0800 (PST) In-Reply-To: References: <8B558834-4B93-425B-B87C-C3459BF0E759@nohats.ca> <8bd6a71b-d9e5-415b-a105-790e4eba1b12@gmail.com> From: Daniel Migault Date: Tue, 15 Nov 2016 23:47:35 -0500 X-Google-Sender-Auth: Fq77b-sNMq2p8o8HlSPJmNrIfKA Message-ID: To: Yaron Sheffer Content-Type: multipart/alternative; boundary=001a113fc0ee9c4552054163c5a9 Archived-At: Cc: "ipsec@ietf.org WG" , Paul Wouters , Tali & Yoav Nir Subject: Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 04:47:40 -0000 --001a113fc0ee9c4552054163c5a9 Content-Type: text/plain; charset=UTF-8 i would like the same policy - context or no context - applied to both EdDSA algo. ctx prevents cross protocol attacks but may encourage bad practice. Yours, Daniel On Nov 16, 2016 1:35 PM, "Yaron Sheffer" wrote: On 16/11/16 12:41, Paul Wouters wrote: > > > On Nov 16, 2016, at 10:49, Yoav Nir wrote: >> >> So I suggest to add the following paragraph at the end of section 2 of >> the eddsa draft: >> >> The context parameter for Ed448 MUST be set to the empty string. >> > > I agree. Context seems useful for generic crypto but not for something > that is already strongly bound by an IETF transport protocol. > > Additionally, we have a similar problem too when allowing the same key in > IKEv1 and IKEv2 where the key has different security properties. > > Paul > I don't think there's any cost to having a non-empty context string, e.g. "IKEv2", and there's potentially value. TLS cross-protocol attacks show that signatures can be abused even when embedded in a transport protocol. The fact that we have the same problem elsewhere is no reason to propagate it further. Thanks, Yaron _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --001a113fc0ee9c4552054163c5a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

i would like the same policy - context or no context - appli= ed to both EdDSA algo. ctx prevents cross protocol attacks but may encourag= e bad practice.

Yours,
Daniel


On Nov 16, 2016 1= :35 PM, "Yaron Sheffer" <yaronf.ietf@gmail.com> wrote:


On 16/11/16 12:41, Paul Wouters wrote:


On Nov 16, 2016, at 10:49, Yoav Nir <ynir.ietf@gmail.com> wrote:

So I suggest to add the following paragraph at the end of section 2 of the = eddsa draft:

=C2=A0 The context parameter for Ed448 MUST be set to the empty string.

I agree. Context seems useful for generic crypto but not for something that= is already strongly bound by an IETF transport protocol.

Additionally, we have a similar problem too when allowing the same key in I= KEv1 and IKEv2 where the key has different security properties.

Paul

I don't think there's any cost to having a non-empty context string= , e.g. "IKEv2", and there's potentially value. TLS cross-prot= ocol attacks show that signatures can be abused even when embedded in a tra= nsport protocol.

The fact that we have the same problem elsewhere is no reason to propagate = it further.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron


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

--001a113fc0ee9c4552054163c5a9-- From nobody Tue Nov 15 20:59:06 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABEAC129472 for ; Tue, 15 Nov 2016 20:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcPtjDqSY08C for ; Tue, 15 Nov 2016 20:59:03 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4859A129457 for ; Tue, 15 Nov 2016 20:59:03 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id i88so40334294pfk.2 for ; Tue, 15 Nov 2016 20:59:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=/vMAybB+0DfpA5+4h/yrenUl/BJhm1A3tVaqSvXWgyQ=; b=AUf9c3meoUL3zQHsUxXfJ2t6/hvjCLxpfm7+ZssBT7L8XCGEpKVEiY4n7qoVm7i/ck JCNHRP8HzdWDspU5iAEmscADH3dMTQiZhtS5dbm+AgzbUlIGnyNN4/h362dT5BVvQYHa JbrUM1H6qhr79ZvygiWTtieJkCQ9ItzXrHQpsOAoxpTTQTobzE7vLbxPRENesjdx1gd4 fRLlBiiq/oETnE54n/Aa2FVolZDVDrO5vTbWObOIULEXn8enwpIytYQz2kzoW2LNe4If Un6xIRPk1Axa8wRTfoYu0uSaAe3lDxhkgdOE8RIPgUpd+cs5vvZYTpWaJuyYP86ScEeg NIKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=/vMAybB+0DfpA5+4h/yrenUl/BJhm1A3tVaqSvXWgyQ=; b=U/4TTyc82q6CsoBklypDwV2QRId2fw3C+fWuc3w4KcVTqp6Dcy05FPSxOe3bdLSRNG YiB+bKoQwx+EThh67s1bY+ptgFkqoIleYK14aceee2YgIxmNqoYvULlTK2Ewanvs6BW2 hWVTOO94k82h+kTTYYTt/U8nHi/ldoTxRj1DjojzE9DI0mzbKy0csHNOECeoTR3QVKZa vdA61cM9OaY6jn/kgK9szn20vyr+PZaslt2Ag4Mfmt64dDOZ3nq/45D+C3K99/iSi9FP 71b7p8dbxxMO3gRcT8u1H5cb9mqTy0XUAPTC/JK4sBk3o++rH6ALJbpXM51twlHnYd2V OZxw== X-Gm-Message-State: ABUngvcQEDlRrN3Aza0f63eNTo48pKdD50lONdN+gkdGn3nYV648jQvX9+uJet1ENBqNgA== X-Received: by 10.99.131.67 with SMTP id h64mr4002919pge.135.1479272342915; Tue, 15 Nov 2016 20:59:02 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:2c31:83ce:16bd:fd5f? ([2001:67c:370:128:2c31:83ce:16bd:fd5f]) by smtp.gmail.com with ESMTPSA id d29sm31777505pfk.78.2016.11.15.20.58.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 20:59:01 -0800 (PST) To: Daniel Migault References: <8B558834-4B93-425B-B87C-C3459BF0E759@nohats.ca> <8bd6a71b-d9e5-415b-a105-790e4eba1b12@gmail.com> From: Yaron Sheffer Message-ID: <5491a275-aa79-8891-cfc3-2dd5a432925e@gmail.com> Date: Wed, 16 Nov 2016 13:58:54 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "ipsec@ietf.org WG" , Paul Wouters , Tali & Yoav Nir Subject: Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 04:59:05 -0000 If you mean the same policy for IPsec and TLS, I fully agree. Context prevents cross-protocol attacks, and I wouldn't worry about "encouraging bad behavior". Users will behave badly whether we encourage them or not :-) Thanks, Yaron On 16/11/16 13:47, Daniel Migault wrote: > i would like the same policy - context or no context - applied to both > EdDSA algo. ctx prevents cross protocol attacks but may encourage bad > practice. > > Yours, > Daniel > > > On Nov 16, 2016 1:35 PM, "Yaron Sheffer" > wrote: > > > > On 16/11/16 12:41, Paul Wouters wrote: > > > > On Nov 16, 2016, at 10:49, Yoav Nir > wrote: > > So I suggest to add the following paragraph at the end of > section 2 of the eddsa draft: > > The context parameter for Ed448 MUST be set to the empty > string. > > > I agree. Context seems useful for generic crypto but not for > something that is already strongly bound by an IETF transport > protocol. > > Additionally, we have a similar problem too when allowing the > same key in IKEv1 and IKEv2 where the key has different security > properties. > > Paul > > > I don't think there's any cost to having a non-empty context string, > e.g. "IKEv2", and there's potentially value. TLS cross-protocol > attacks show that signatures can be abused even when embedded in a > transport protocol. > > The fact that we have the same problem elsewhere is no reason to > propagate it further. > > Thanks, > Yaron > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > From nobody Tue Nov 15 22:32:35 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679D3129692 for ; Tue, 15 Nov 2016 22:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbEB2Z-EPpVj for ; Tue, 15 Nov 2016 22:32:32 -0800 (PST) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 18A00129498 for ; Tue, 15 Nov 2016 22:32:32 -0800 (PST) Received: by mail-pf0-x242.google.com with SMTP id c4so6677815pfb.3 for ; Tue, 15 Nov 2016 22:32:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/t+DI2u0fnIoepWFLiX2USAJNeCTj0RdcVW2XVCP3r4=; b=sMPSQJJgxwMaRCOQEamMNuUVVPibjIzo5MQBoOTSjObQudZQRslPTG9r16kwBUr9H7 tcgRku++h9o/CoLZuOaGkQWsQ7Qh10zeM7BI1qO0Thtbqp1TjaGvXYi0Qah2Ei1Js6qI QewGpwHDsQ+iieTdIDulAvDt89CXlHZW0dhMxh0Ny9KQuhKSkMlOAu0N3uJFBuyn0HOH 3mK98NWHguEFaAlg9nWO43xuJiVB6pELGeYv7VluocdwePdqNieREmsLfYrENRdw9pZk 1Yrs4VeuT2X7czMLsRSjxdh0wIiMhtpc2AFgeeCroWTdt2HR5grcv7wSoyUN6Lg7y+Ta VpYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/t+DI2u0fnIoepWFLiX2USAJNeCTj0RdcVW2XVCP3r4=; b=Lz0Pl9D9E63+S7xEMvBx2guMTzj5+AoaA9EUvKB+hR3rGS6mfu3e0ndbYxqRxjJyIq 0sHGd10q9HhhPRXyt+Yb0P7ZlN5q9UFX5ZBrtkt7RnjWJZLT/IpzU3u27M8CK9zV9y4T dm5VdHL6d6cGrNN+kJ0WqC+A94kOBC9GO+tkVGlgONYxYNvJuJrgbWcimYVELGoH7Xx1 4PpVuehs6Xjy/z3XWParcjtx04k6b20ZtwUYDUpVGIz4vh/9enXg5pCpD6BNtHraJkkF N5UG9dbCjN12u2tZpWQMAPA4ZV8bwRVG47LQCBNLJ1jCC5FLDlSrnq/15jgi+uTm/mmt kPZQ== X-Gm-Message-State: ABUngvdT5Ns3czBQQOfnJEtqaUUin6gwQ+vFdJHvAQ0xKSyS+RCjtWPMz9fZv1K/17hllA== X-Received: by 10.99.36.65 with SMTP id k62mr4782608pgk.88.1479277951716; Tue, 15 Nov 2016 22:32:31 -0800 (PST) Received: from t2001067c03700128f8f4c150dd302f54.v6.meeting.ietf.org ([2001:67c:370:128:f8f4:c150:dd30:2f54]) by smtp.gmail.com with ESMTPSA id s3sm49215251pfg.14.2016.11.15.22.32.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 22:32:30 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Yoav Nir In-Reply-To: <5491a275-aa79-8891-cfc3-2dd5a432925e@gmail.com> Date: Wed, 16 Nov 2016 15:32:25 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <9A32290A-2514-458A-9CF1-7E45D4147DF1@gmail.com> References: <8B558834-4B93-425B-B87C-C3459BF0E759@nohats.ca> <8bd6a71b-d9e5-415b-a105-790e4eba1b12@gmail.com> <5491a275-aa79-8891-cfc3-2dd5a432925e@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "ipsec@ietf.org WG" , Daniel Migault , Paul Wouters Subject: Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 06:32:33 -0000 No, I think he means Ed448 and Ed25519.=20 Adding context to Ed25519 (so using Ed25519ctx) requires using a = different function than the one available in several implementations = such as libsodium. If we choose the no context option it doesn=E2=80=99t matter: Ed25519ctx = with empty context =3D=3D Ed25519ctx Yoav > On 16 Nov 2016, at 13:58, Yaron Sheffer wrote: >=20 > If you mean the same policy for IPsec and TLS, I fully agree. >=20 > Context prevents cross-protocol attacks, and I wouldn't worry about = "encouraging bad behavior". Users will behave badly whether we encourage = them or not :-) >=20 > Thanks, > Yaron >=20 > On 16/11/16 13:47, Daniel Migault wrote: >> i would like the same policy - context or no context - applied to = both >> EdDSA algo. ctx prevents cross protocol attacks but may encourage bad >> practice. >>=20 >> Yours, >> Daniel >>=20 >>=20 >> On Nov 16, 2016 1:35 PM, "Yaron Sheffer" > > wrote: >>=20 >>=20 >>=20 >> On 16/11/16 12:41, Paul Wouters wrote: >>=20 >>=20 >>=20 >> On Nov 16, 2016, at 10:49, Yoav Nir > > wrote: >>=20 >> So I suggest to add the following paragraph at the end of >> section 2 of the eddsa draft: >>=20 >> The context parameter for Ed448 MUST be set to the empty >> string. >>=20 >>=20 >> I agree. Context seems useful for generic crypto but not for >> something that is already strongly bound by an IETF transport >> protocol. >>=20 >> Additionally, we have a similar problem too when allowing the >> same key in IKEv1 and IKEv2 where the key has different = security >> properties. >>=20 >> Paul >>=20 >>=20 >> I don't think there's any cost to having a non-empty context = string, >> e.g. "IKEv2", and there's potentially value. TLS cross-protocol >> attacks show that signatures can be abused even when embedded in a >> transport protocol. >>=20 >> The fact that we have the same problem elsewhere is no reason to >> propagate it further. >>=20 >> Thanks, >> Yaron >>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >>=20 >>=20 From nobody Tue Nov 15 22:33:56 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01A01295A8 for ; Tue, 15 Nov 2016 22:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6XKfTCh_2Da for ; Tue, 15 Nov 2016 22:33:53 -0800 (PST) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 75BFE1294C7 for ; Tue, 15 Nov 2016 22:33:53 -0800 (PST) Received: by mail-pg0-x241.google.com with SMTP id x23so13826163pgx.3 for ; Tue, 15 Nov 2016 22:33:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZuFCCNa8RAsAOyNypShPbCfOhqr/JcRM2Lf+stO+Keo=; b=OH6+l1wJSawKkNZeiCgrByt4KZZzFPW77EBGivnOnFCN7GWI29f+ZiuQgV5Axo1adH s1DU1WOc+srA73jA7QWVh0hrvvN1nVwHTJnXFr3lK1qDpauWq7x0ZqHDwd+Oue0lIxgw kT+NOlGkiJexWXikVFIJvf/Z28x9cd2LVZisxaMPZxoPIIMrAWDdrUeRJCeQZu+jJtsB YSyDjLdmo6bJn2pWt541aAJfKicXsz2SBueQwswGvbLo5KpQmcv1E1U+E9+UMzQ1Srpq upVLMCXkm4N0ZZCsOl2ruFnx6BVJY/aZJVK2vqa7aBiuOsTCcgsWAbFrP+kLBpcx8Eup nm0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZuFCCNa8RAsAOyNypShPbCfOhqr/JcRM2Lf+stO+Keo=; b=ctAJNmfaM5JC2VXHl2WUhozxj3k3MEmZObrxqIpb3OiltJKS29csM8xa4qmZZ93wHs b/C/RQg+k8P5oKeaj6EX+nNZ/++QIKtD+Z44OOKe+ayZflXlxlUYh4PQlk1a5jYN29BQ dcSfQtDmbQyY8jj0C9f8J4TsS6Ot5dfq3sCjJ2h3nflGxj2cTG6RiC27rhnNBvhv5m/m /fHZSiPriQ+Zj50JTfDvv+3vLK1VJ2KDu7rhrEsDLCU5cl03ZUcaSNK0YE5GVT9AwYWk xoQmF1A4tZCfzwUwi/4pIVltHpg0NXFIx/TIT3yAl73sikl7UIccQ5G61qH7sGlhZjHM 07Dg== X-Gm-Message-State: ABUngve+OoUq9CHxya6/vZqTP31PZsh6EqB2YQRuePaUlXrAf1y0lVjadd0m+vT4BtUkYA== X-Received: by 10.99.52.10 with SMTP id b10mr4795706pga.42.1479278033110; Tue, 15 Nov 2016 22:33:53 -0800 (PST) Received: from t2001067c03700128f8f4c150dd302f54.v6.meeting.ietf.org ([2001:67c:370:128:f8f4:c150:dd30:2f54]) by smtp.gmail.com with ESMTPSA id t21sm25141739pfa.1.2016.11.15.22.33.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 22:33:52 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Yoav Nir In-Reply-To: <9A32290A-2514-458A-9CF1-7E45D4147DF1@gmail.com> Date: Wed, 16 Nov 2016 15:33:46 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <1450A23C-BD3F-4588-9EBC-908C80DBEBED@gmail.com> References: <8B558834-4B93-425B-B87C-C3459BF0E759@nohats.ca> <8bd6a71b-d9e5-415b-a105-790e4eba1b12@gmail.com> <5491a275-aa79-8891-cfc3-2dd5a432925e@gmail.com> <9A32290A-2514-458A-9CF1-7E45D4147DF1@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "ipsec@ietf.org WG" , Daniel Migault , Paul Wouters Subject: Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 06:33:55 -0000 But yes, I agree that IPsec, TLS and Curdle should come to the same = conclusion either way. And I think that in light of existing deployment, Ed25519ctx *with* = context is a very hard sell. Yoav > On 16 Nov 2016, at 15:32, Yoav Nir wrote: >=20 > No, I think he means Ed448 and Ed25519.=20 >=20 > Adding context to Ed25519 (so using Ed25519ctx) requires using a = different function than the one available in several implementations = such as libsodium. >=20 > If we choose the no context option it doesn=E2=80=99t matter: = Ed25519ctx with empty context =3D=3D Ed25519ctx >=20 > Yoav >=20 >> On 16 Nov 2016, at 13:58, Yaron Sheffer = wrote: >>=20 >> If you mean the same policy for IPsec and TLS, I fully agree. >>=20 >> Context prevents cross-protocol attacks, and I wouldn't worry about = "encouraging bad behavior". Users will behave badly whether we encourage = them or not :-) >>=20 >> Thanks, >> Yaron >>=20 >> On 16/11/16 13:47, Daniel Migault wrote: >>> i would like the same policy - context or no context - applied to = both >>> EdDSA algo. ctx prevents cross protocol attacks but may encourage = bad >>> practice. >>>=20 >>> Yours, >>> Daniel >>>=20 >>>=20 >>> On Nov 16, 2016 1:35 PM, "Yaron Sheffer" >> > wrote: >>>=20 >>>=20 >>>=20 >>> On 16/11/16 12:41, Paul Wouters wrote: >>>=20 >>>=20 >>>=20 >>> On Nov 16, 2016, at 10:49, Yoav Nir >> > wrote: >>>=20 >>> So I suggest to add the following paragraph at the end of >>> section 2 of the eddsa draft: >>>=20 >>> The context parameter for Ed448 MUST be set to the empty >>> string. >>>=20 >>>=20 >>> I agree. Context seems useful for generic crypto but not for >>> something that is already strongly bound by an IETF transport >>> protocol. >>>=20 >>> Additionally, we have a similar problem too when allowing the >>> same key in IKEv1 and IKEv2 where the key has different = security >>> properties. >>>=20 >>> Paul >>>=20 >>>=20 >>> I don't think there's any cost to having a non-empty context = string, >>> e.g. "IKEv2", and there's potentially value. TLS cross-protocol >>> attacks show that signatures can be abused even when embedded in a >>> transport protocol. >>>=20 >>> The fact that we have the same problem elsewhere is no reason to >>> propagate it further. >>>=20 >>> Thanks, >>> Yaron >>>=20 >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>>=20 >>>=20 >=20 From nobody Tue Nov 15 22:56:24 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55DEE1295F8 for ; Tue, 15 Nov 2016 22:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eh8FSOECZ7XI for ; Tue, 15 Nov 2016 22:56:19 -0800 (PST) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A8D1129658 for ; Tue, 15 Nov 2016 22:56:19 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id o1so39629586ito.1 for ; Tue, 15 Nov 2016 22:56:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=LKhIuD7k0Idw32mXF26BZE1Exxpcoa7tQZsTw4gU3xg=; b=NNGHhmLYozicoqXKj3T8tSpI9DrdSZwn6ZaoA4SKuP9UPRTatvj5yk6kbm7Hgd+XhE SU6+aQRjjuYYMKvdFVi9V88aKrvOm3YOhgRp4YnEv6KVfPUJ03uPkVPZVb0hADV6CbB+ ptgJeH/p5fC5quoaQDf/jW66OrsrbBs6waIAKS83Zcm5IzFEok7oOGQeJFMg277ruejr dhUnko0knrKQ4IiC+dbnqBsRw9Hq2FL2RBXOVuJSvZnNQkYlkEjL4lzkCNereoH87+Hd 1su+4aEIN+5r5kK37UspLon5jUSl2qS2kKc/TOi3STwtXopjEzjInTPEPzGMYiLeaBDM cIMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=LKhIuD7k0Idw32mXF26BZE1Exxpcoa7tQZsTw4gU3xg=; b=UOSIRHrPRROwl34lcfhfhyVeeUjOe4Y1lr45MBlmxbjKhqEJjxEkh2svGDb95juiAJ URsZEDY88P5q5ZtAW2dGcXLAtCFjKMF1X0J25N0pOHdF1KLbcrzIUCRXUaxV6yAD1R6H J/EFvmXjCI5BKDSuubU/aXz5KMNZd5of4Io2KzXT7ewKd2dZYXIixQw50mmyri7FayBP ym9IIliKm63gsx9FYxCLX2K99VSrZGyYmAgY66EnnY59ca80KdPvxOxkPxBP7PTXNFZP AeyZRkAFGM41O3VBLnL6onO8DGPvQMBd05JZ4+6CcNqFDQtXQ7hKyVQ3Bq7RymQp82s3 mqzg== X-Gm-Message-State: ABUngvezO8nuKUbcBftzSqUVeQXMK0G7mLJrab44nGts59KVJmbQ7mvDRMWcJCMi5hv3ShNKfhcUkNzYdzdVMw== X-Received: by 10.107.18.39 with SMTP id a39mr1374952ioj.45.1479279378806; Tue, 15 Nov 2016 22:56:18 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.32.10 with HTTP; Tue, 15 Nov 2016 22:56:17 -0800 (PST) Received: by 10.107.32.10 with HTTP; Tue, 15 Nov 2016 22:56:17 -0800 (PST) In-Reply-To: References: <8B558834-4B93-425B-B87C-C3459BF0E759@nohats.ca> <8bd6a71b-d9e5-415b-a105-790e4eba1b12@gmail.com> <5491a275-aa79-8891-cfc3-2dd5a432925e@gmail.com> <9A32290A-2514-458A-9CF1-7E45D4147DF1@gmail.com> <1450A23C-BD3F-4588-9EBC-908C80DBEBED@gmail.com> From: Daniel Migault Date: Wed, 16 Nov 2016 01:56:17 -0500 X-Google-Sender-Auth: drsa3uswu_uurtGkHcy__hwZeNs Message-ID: To: "Tali & Yoav Nir" Content-Type: multipart/alternative; boundary=001a113ff17ce5bf22054165913e Archived-At: Cc: "ipsec@ietf.org WG" , Paul Wouters Subject: Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 06:56:21 -0000 --001a113ff17ce5bf22054165913e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Given the discussions on curdle. the trend is to use an empty context with a clear security recommendation of using dedicated keys for each usage. Yours Daniel On Nov 16, 2016 3:34 PM, "Yoav Nir" wrote: But yes, I agree that IPsec, TLS and Curdle should come to the same conclusion either way. And I think that in light of existing deployment, Ed25519ctx *with* context is a very hard sell. Yoav > On 16 Nov 2016, at 15:32, Yoav Nir wrote: > > No, I think he means Ed448 and Ed25519. > > Adding context to Ed25519 (so using Ed25519ctx) requires using a different function than the one available in several implementations such as libsodium. > > If we choose the no context option it doesn=E2=80=99t matter: Ed25519ctx = with empty context =3D=3D Ed25519ctx > > Yoav > >> On 16 Nov 2016, at 13:58, Yaron Sheffer wrote: >> >> If you mean the same policy for IPsec and TLS, I fully agree. >> >> Context prevents cross-protocol attacks, and I wouldn't worry about "encouraging bad behavior". Users will behave badly whether we encourage them or not :-) >> >> Thanks, >> Yaron >> >> On 16/11/16 13:47, Daniel Migault wrote: >>> i would like the same policy - context or no context - applied to both >>> EdDSA algo. ctx prevents cross protocol attacks but may encourage bad >>> practice. >>> >>> Yours, >>> Daniel >>> >>> >>> On Nov 16, 2016 1:35 PM, "Yaron Sheffer" >> > wrote: >>> >>> >>> >>> On 16/11/16 12:41, Paul Wouters wrote: >>> >>> >>> >>> On Nov 16, 2016, at 10:49, Yoav Nir >> > wrote: >>> >>> So I suggest to add the following paragraph at the end of >>> section 2 of the eddsa draft: >>> >>> The context parameter for Ed448 MUST be set to the empty >>> string. >>> >>> >>> I agree. Context seems useful for generic crypto but not for >>> something that is already strongly bound by an IETF transport >>> protocol. >>> >>> Additionally, we have a similar problem too when allowing the >>> same key in IKEv1 and IKEv2 where the key has different security >>> properties. >>> >>> Paul >>> >>> >>> I don't think there's any cost to having a non-empty context string, >>> e.g. "IKEv2", and there's potentially value. TLS cross-protocol >>> attacks show that signatures can be abused even when embedded in a >>> transport protocol. >>> >>> The fact that we have the same problem elsewhere is no reason to >>> propagate it further. >>> >>> Thanks, >>> Yaron >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> >>> > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --001a113ff17ce5bf22054165913e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Given the discussions on curdle. the trend is to use an empt= y context with a clear security recommendation of using dedicated keys for = each usage.
Yours
Daniel


On Nov 16, 2016 3= :34 PM, "Yoav Nir" <yni= r.ietf@gmail.com> wrote:
But yes, I agree that IPsec, TLS and Curdle should come to the same= conclusion either way.

And I think that in light of existing deployment, Ed25519ctx *with* context= is a very hard sell.

Yoav

> On 16 Nov 2016, at 15:32, Yoav Nir <ynir.ietf@gmail.com> wrote:
>
> No, I think he means Ed448 and Ed25519.
>
> Adding context to Ed25519 (so using Ed25519ctx) requires using a diffe= rent function than the one available in several implementations such as lib= sodium.
>
> If we choose the no context option it doesn=E2=80=99t matter: Ed25519c= tx with empty context =3D=3D Ed25519ctx
>
> Yoav
>
>> On 16 Nov 2016, at 13:58, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
>>
>> If you mean the same policy for IPsec and TLS, I fully agree.
>>
>> Context prevents cross-protocol attacks, and I wouldn't worry = about "encouraging bad behavior". Users will behave badly whether= we encourage them or not :-)
>>
>> Thanks,
>>=C2=A0 =C2=A0 =C2=A0 Yaron
>>
>> On 16/11/16 13:47, Daniel Migault wrote:
>>> i would like the same policy - context or no context - applied= to both
>>> EdDSA algo. ctx prevents cross protocol attacks but may encour= age bad
>>> practice.
>>>
>>> Yours,
>>> Daniel
>>>
>>>
>>> On Nov 16, 2016 1:35 PM, "Yaron Sheffer" <yaronf.ietf@gmail.com
>>> <mailto:yaronf.iet= f@gmail.com>> wrote:
>>>
>>>
>>>
>>>=C2=A0 =C2=A0On 16/11/16 12:41, Paul Wouters wrote:
>>>
>>>
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Nov 16, 2016, at 10= :49, Yoav Nir <ynir.ietf@gmail.co= m
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:ynir.ietf@gmail.com>> wrote:
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0So I suggest to add th= e following paragraph at the end of
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0section 2 of the eddsa= draft:
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The context par= ameter for Ed448 MUST be set to the empty
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string.
>>>
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0I agree. Context seems useful for ge= neric crypto but not for
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0something that is already strongly b= ound by an IETF transport
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0protocol.
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Additionally, we have a similar prob= lem too when allowing the
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0same key in IKEv1 and IKEv2 where th= e key has different security
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0properties.
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Paul
>>>
>>>
>>>=C2=A0 =C2=A0I don't think there's any cost to having a= non-empty context string,
>>>=C2=A0 =C2=A0e.g. "IKEv2", and there's potentiall= y value. TLS cross-protocol
>>>=C2=A0 =C2=A0attacks show that signatures can be abused even wh= en embedded in a
>>>=C2=A0 =C2=A0transport protocol.
>>>
>>>=C2=A0 =C2=A0The fact that we have the same problem elsewhere i= s no reason to
>>>=C2=A0 =C2=A0propagate it further.
>>>
>>>=C2=A0 =C2=A0Thanks,
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Yaron
>>>
>>>
>>>=C2=A0 =C2=A0_____________________________________________= __
>>>=C2=A0 =C2=A0IPsec mailing list
>>>=C2=A0 =C2=A0IPsec@ietf.org <mailto:IPsec@ietf.org>
>>>=C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/ipsec
>>>=C2=A0 =C2=A0<https://www.ietf.org/mailman= /listinfo/ipsec>
>>>
>>>
>

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

--001a113ff17ce5bf22054165913e-- From nobody Tue Nov 15 22:59:30 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3FF129677; Tue, 15 Nov 2016 22:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.699 X-Spam-Level: X-Spam-Status: No, score=-105.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 rKnOwAbRBbL6; Tue, 15 Nov 2016 22:59:25 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 214B0129663; Tue, 15 Nov 2016 22:59:25 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 19FCEB800C4; Tue, 15 Nov 2016 22:59:25 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20161116065925.19FCEB800C4@rfc-editor.org> Date: Tue, 15 Nov 2016 22:59:25 -0800 (PST) Archived-At: Cc: ipsec@ietf.org, drafts-update-ref@iana.org, rfc-editor@rfc-editor.org Subject: [IPsec] RFC 8019 on Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 06:59:28 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8019 Title: Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks Author: Y. Nir, V. Smyslov Status: Standards Track Stream: IETF Date: November 2016 Mailbox: ynir.ietf@gmail.com, svan@elvis.ru Pages: 32 Characters: 78293 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsecme-ddos-protection-10.txt URL: https://www.rfc-editor.org/info/rfc8019 DOI: http://dx.doi.org/10.17487/RFC8019 This document recommends implementation and configuration best practices for Internet Key Exchange Protocol version 2 (IKEv2) Responders, to allow them to resist Denial-of-Service and Distributed Denial-of-Service attacks. Additionally, the document introduces a new mechanism called "Client Puzzles" that helps accomplish this task. This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Nov 15 23:00:21 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF63129663 for ; Tue, 15 Nov 2016 23:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 i0s6u7MdKmNX for ; Tue, 15 Nov 2016 23:00:04 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26791296A4 for ; Tue, 15 Nov 2016 22:59:53 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id uAG6xnjQ019009 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 16 Nov 2016 08:59:49 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uAG6xnnm012808; Wed, 16 Nov 2016 08:59:49 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22572.997.213956.145117@fireball.acr.fi> Date: Wed, 16 Nov 2016 08:59:49 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 3 min Archived-At: Cc: "ipsec@ietf.org WG" Subject: [IPsec] IETF97 meeting raw notes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 07:00:05 -0000 Paul Wouters writes: > Tero: Agenda talk > Tero: ddos and safecurves in AUTH48 ... Thanks for writing the minutes. I cleaned them up a bit, and posted them the datatracker. If there are any more comments or corrections to the minutes, please send them to me. Minutes can be found from the end of this email and from . ---------------------------------------------------------------------- Tero: Agenda talk Tero: ddos and safecurves in AUTH48 Tero: 4307/7321 bis documents David: any concerns with 7321bis for WGLC =3F none from room Tero: encaps edDSA adopted Tero: Split dns, implicit itv, waiting for adoption [split dns presentation] Some push to get early code point done by Tommy, Paul and Valery [tcp encaps presentation] Yoav: why mention anything but TCP (http, quick) Tommy: we kind of want to tell people this works for other transports Yoav: I'd need a new document anyway for SCTP or something else Valery: You must specify more precisely to ensure interop Tommy: TCP is opened by initiator. Server should accept any tcp connect= ions (with sane limit) Valery: so you need to support multiple TCP connections for a single SA= I think more specifics [Hu Jun]: Which TCP session to use=3F what is the use case to support =09 multiple TCP connections. Tero: can me mandate MOBIKE=3F various people including Yoav, Paul and Tommy: please do not Tommy: TCP 3way handshake gives some guarantee, so MOBIKE not really re= quired Paul: Be careful of ignoring retransmits over new NAT mapping. When initiating new TCP connection, resend last IKE packet, so responder can determine which TCP session to use. [Yoav edDSA draft, implicit IV draft presentation] Paul: context isn't really needed, IKE/IPsec very specific Tero: Its far fatched, but CRFG says protect against it anyway Dan Harkins: mic: the answer is that it's a signing oracle and that =09 is a bad (if not good) thing. Context is easy fix. mcr: maybe an HSM could be tricked like that=3F Tero: Attacker can also only use half of it (send or receive). Lots of = random things are there not under control of attacker Yoav: This same question comes up in curdle and TLS :) Dan Harkins: mic: not clear, is ipseme's decision based upon what curdl= e does=3F [Valery presentation Ambiguity in IKEv2] Paul: why not move into IKE=5FAUTH, and send different IKE=5FAUTH after= failure=3F Valery: spec does not allow that - must start with new IKE=5FINIT Yoav: [missed what he said] Tero: Not a big problem - AUTH is mostly preconfigured/provisioned Dan Harkins: waiting for "will be gone" is not right=E2=80=94 given IKE= v1's =09 tenaciousness=E2=80=94 so if something hurries up -PSS adop= tion =09 we should do it. Size of message seems to be a small =09 price to pay.=20 [Hu Jun] Not a big problem [David presentation QR] Dan Harkins: mic: since the child SAs use KEYMAT to generate IPsec =09 keys and KEYMAT has the PPK then why mix in the PPK again =09 to generate child SAs=3F=20 David: Don't have a good answer right now. Scott Fluhrer: Because we want to give an implementor the option of =09 protecting the IKE traffic=20 mcr: I asked for identity protection. Interesting child SAs would be protected, what I would like to have is an architecture that leads us towards ID protection even if we dont get it right now. Eg use pseudonyms on first round to bound them on second round. site-to-site doesnt have this problem. On mobile site it is increasingly important, see for example TLS 1.3. Eg if we have a bit for ID protection would work.=20 Dan: A future QR replacement for DH could help give us the identity protection.=20 Paul: Isn't PPK ID an anonymous ID anyway Tero: Could add new identity type to use in the initial IKE=5FAUTH,=20 and then send some new psuedonyms in the next rekey once the channel is safe. We don't need to do this as part of the QR draft, but can add it later in a separate identity protection document.=20 Tero: Agree to not have ppk management now, but we could use the ppk notify payload for some value later. Outside of IKE SA, just used to identify the ppk=20 Debbie: the long term goal is not to have this. Its an interim. Paul: PPK identifier can lead to privately convey ID Tero: it is good enough that we can do WG adoption call [compact format of IKEv2 payloads presentation by Valery] Paul: Isn't it greedy to ask for 3 reserved bits=3F Tero: Reserved field we only use critical bit. Using them is not a prob= lem will people really use this=3F IoT does a lot of weird tricks. Other forms of compression might work better. For IoT, we can reduce SA packet to 1 byte :) Maybe something completely different would be better=20 Valery: for IoT, things split in 128 byte blocks. So a few bytes might =09actually gain you a lot. Tero: Actually, it is 11 + 3 bytes extra depending on mode..... Tommy: Goal of compressing is great for IoT. I am worried with complexi= ty. You can already reduce transforms if you know what you want/need. You could rather have a new format with "profiles" where you send a profile number that maps to [a proposal]=20 mcr: you need to compare work against generalised header compression which does a good job at removing 0's. Can prob get close to lzh. Worth comparing that. If ioT is already using [=3F=3F=3F=3F]. Use = a encryption algorithm transform to signal this=3F Same as diet ESP,= is this really going to be used=3F I dont think it will be used. I= don't think it is worth spending time on now. Maybe in 5 years=3F=20= Brian Weis Cisco: Rather see a completely different that would achieve =09 =09 more.=20 [Enapsulating ESP in UDP for load balancing presentation] Dan Harkins: SPI already identifies a flow. No need for any other =09 field for flow identification. Any LB decision made by =09 the destination MUST be transparent to the source. =20 Tero/Paul: source port can be anything already, does not need to be =09 4500, so use that=3F Lorenzto: Use flow label in ipv6 =3F=3F=3F=3F: Tommy: if there is a NAT too, how would this work=3F Presentor: We assume there is no NAT [GDOI groupkey presentation] Valery: messages can be lost. it is not reliable and can be dangerous Kathleen: please feedback on the list Tero: and CC msec list --=20 kivinen@iki.fi From nobody Wed Nov 16 00:01:55 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568D712964E for ; Wed, 16 Nov 2016 00:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KnK950X5MFi for ; Wed, 16 Nov 2016 00:01:51 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6327212965E for ; Wed, 16 Nov 2016 00:01:50 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id x23so73832502pgx.1 for ; Wed, 16 Nov 2016 00:01:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ovg/B4EULDtfVtXig4gkTjNe78EIOqojKCwNVQ9bGLo=; b=Cg/2NbNIJKi4ivtVjsghT5df1wD3NeDDTLZwbAwbv+HwYWGtYTmcLlt0hoT5hD/jXA hWmHXTzZpTPTKrZt/fZ2HMRI751POMaverLylT6N34vZe0x8p7Mm17xKwiyPi9Gkd5gN r4scxJ/aCt9rrPBHuLsiU9nC2zBDI5ga8l7DJDo6DUvuQt1Jyf/6ecS8iwO+X+paUSZy KTfJ8a7Tu2F1Lh+r28V8lh1b59sWWGbN6mJX8TZrbwkmv9IF7ui6HvEEsMV6Q9cJP0dV zPbPoRaSc00HUyiFWKvsfZFQZrM5uNCpALEG0pPyeNrvm+DxTRoQ5DXgt7MNlO7iRasm 4KYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ovg/B4EULDtfVtXig4gkTjNe78EIOqojKCwNVQ9bGLo=; b=d6D0I0pEm3iRoY6tyBRKHaon7/LfbXJIRcFZ9lHnRdEr+up6QeN3ZJUGLggjl7csah jcUTrDCbZX7Cz0Ot8f5Ak6VsHOrTGOSFu7jsDRgp0KlABa3kyKRwOV/OY2DLm11p26od ZVzLXkZk5SZmpO8agnwH3hpS6pF9N3xh5bkZj+C6jgoUWpxuLSGUc7zJ7FBfS9o/jkdZ 4iwhbUmG+kzM71fL6Xl4r9UM3AvUXnEwh0zv3+Go1QlH8duiFBpKPjeCBdugt9lR0Nx9 rrdioTLONdNGoDRuVZKXBufw9kvIkedyvvZiQ+gWTYGJUMSbkbcXKHzJZmtM8KF5neLl XoAQ== X-Gm-Message-State: ABUngvdBKWRSfuWZjdCn9Iyx0KHEJ+Kd8ZQ0whtnfb03Pzlc6S2dWE9lTdibRKq2asKpkg== X-Received: by 10.99.111.78 with SMTP id k75mr5520527pgc.114.1479283309992; Wed, 16 Nov 2016 00:01:49 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:2c31:83ce:16bd:fd5f? (t2001067c037001282c3183ce16bdfd5f.v6.meeting.ietf.org. [2001:67c:370:128:2c31:83ce:16bd:fd5f]) by smtp.gmail.com with ESMTPSA id f14sm37212511pfk.5.2016.11.16.00.01.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Nov 2016 00:01:48 -0800 (PST) To: Daniel Migault , Tali & Yoav Nir References: <8B558834-4B93-425B-B87C-C3459BF0E759@nohats.ca> <8bd6a71b-d9e5-415b-a105-790e4eba1b12@gmail.com> <5491a275-aa79-8891-cfc3-2dd5a432925e@gmail.com> <9A32290A-2514-458A-9CF1-7E45D4147DF1@gmail.com> <1450A23C-BD3F-4588-9EBC-908C80DBEBED@gmail.com> From: Yaron Sheffer Message-ID: <2e288a44-6d93-a88f-8c48-186318638a1f@gmail.com> Date: Wed, 16 Nov 2016 17:01:43 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "ipsec@ietf.org WG" , Paul Wouters Subject: Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 08:01:53 -0000 Once again, we are moving the responsibility over security best practices from vendors into users. We should know better by now. Thanks, Yaron On 16/11/16 15:56, Daniel Migault wrote: > Given the discussions on curdle. the trend is to use an empty context > with a clear security recommendation of using dedicated keys for each usage. > Yours > Daniel > > > On Nov 16, 2016 3:34 PM, "Yoav Nir" > wrote: > > But yes, I agree that IPsec, TLS and Curdle should come to the same > conclusion either way. > > And I think that in light of existing deployment, Ed25519ctx *with* > context is a very hard sell. > > Yoav > > > On 16 Nov 2016, at 15:32, Yoav Nir > wrote: > > > > No, I think he means Ed448 and Ed25519. > > > > Adding context to Ed25519 (so using Ed25519ctx) requires using a > different function than the one available in several implementations > such as libsodium. > > > > If we choose the no context option it doesn’t matter: Ed25519ctx > with empty context == Ed25519ctx > > > > Yoav > > > >> On 16 Nov 2016, at 13:58, Yaron Sheffer > wrote: > >> > >> If you mean the same policy for IPsec and TLS, I fully agree. > >> > >> Context prevents cross-protocol attacks, and I wouldn't worry > about "encouraging bad behavior". Users will behave badly whether we > encourage them or not :-) > >> > >> Thanks, > >> Yaron > >> > >> On 16/11/16 13:47, Daniel Migault wrote: > >>> i would like the same policy - context or no context - applied > to both > >>> EdDSA algo. ctx prevents cross protocol attacks but may > encourage bad > >>> practice. > >>> > >>> Yours, > >>> Daniel > >>> > >>> > >>> On Nov 16, 2016 1:35 PM, "Yaron Sheffer" > >>> >> > wrote: > >>> > >>> > >>> > >>> On 16/11/16 12:41, Paul Wouters wrote: > >>> > >>> > >>> > >>> On Nov 16, 2016, at 10:49, Yoav Nir > > >>> >> wrote: > >>> > >>> So I suggest to add the following paragraph at the end of > >>> section 2 of the eddsa draft: > >>> > >>> The context parameter for Ed448 MUST be set to the empty > >>> string. > >>> > >>> > >>> I agree. Context seems useful for generic crypto but not for > >>> something that is already strongly bound by an IETF transport > >>> protocol. > >>> > >>> Additionally, we have a similar problem too when allowing the > >>> same key in IKEv1 and IKEv2 where the key has different > security > >>> properties. > >>> > >>> Paul > >>> > >>> > >>> I don't think there's any cost to having a non-empty context > string, > >>> e.g. "IKEv2", and there's potentially value. TLS cross-protocol > >>> attacks show that signatures can be abused even when embedded in a > >>> transport protocol. > >>> > >>> The fact that we have the same problem elsewhere is no reason to > >>> propagate it further. > >>> > >>> Thanks, > >>> Yaron > >>> > >>> > >>> _______________________________________________ > >>> IPsec mailing list > >>> IPsec@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/ipsec > > >>> > > >>> > >>> > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > From nobody Wed Nov 16 17:37:01 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FAA1295F3 for ; Wed, 16 Nov 2016 17:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CtNld9aRrjwv for ; Wed, 16 Nov 2016 17:37:00 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C9881295EB for ; Wed, 16 Nov 2016 17:36:59 -0800 (PST) Received: from dooku.sandelman.ca (dhcp-8d96.meeting.ietf.org [31.133.141.150]) by relay.sandelman.ca (Postfix) with ESMTPS id 349B51F8EF for ; Thu, 17 Nov 2016 01:36:58 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 247D533DC; Thu, 17 Nov 2016 10:36:56 +0900 (KST) From: Michael Richardson To: "ipsec\@ietf.org WG" In-reply-to: <2e288a44-6d93-a88f-8c48-186318638a1f@gmail.com> References: <8B558834-4B93-425B-B87C-C3459BF0E759@nohats.ca> <8bd6a71b-d9e5-415b-a105-790e4eba1b12@gmail.com> <5491a275-aa79-8891-cfc3-2dd5a432925e@gmail.com> <9A32290A-2514-458A-9CF1-7E45D4147DF1@gmail.com> <1450A23C-BD3F-4588-9EBC-908C80DBEBED@gmail.com> <2e288a44-6d93-a88f-8c48-186318638a1f@gmail.com> Comments: In-reply-to Yaron Sheffer message dated "Wed, 16 Nov 2016 17:01:43 +0900." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 17 Nov 2016 10:36:56 +0900 Message-ID: <14047.1479346616@dooku.sandelman.ca> Archived-At: Subject: Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 01:37:01 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Yaron Sheffer wrote: > Once again, we are moving the responsibility over security best > practices from vendors into users. We should know better by now. yeah, I still don't really understand this. Why can't we put a security context into a new algorithm. Yoav explained to me offline that the argument against doing is, is that users might think they are safe to re-use keys, and might start doing that. But it isn't safe to do that with old RSA, ECDSA, DSA, etc. methods, and th= ey might be surprised. okay, I follow this logic... but... either they listen, or they don't.=20=20 Isn't this "solved" by putting the security context in, and simply not talking about it? We still tell users not to share keys, which is what we plan to do anyway. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYLQm3AAoJEJVM4Vb9/EKQeSwH/3FMg89nxk5Cvt7FWS5mW7gZ 2tAFHYsBn+NT9xiYUGq5HAHO25LwFZ3DayVd9ElmHZYzptAo5VI/1WiD9Dm3lXMi /sXTp/sephdh5oHtgkfyhFlGWnivVkFEuriQR/rrY9piIvnHl6XS5OL30u5r+rgl gn6XYHk2RkWJrBpyuESxIsd5kfltMQm/1DuBnmzAnR3tu85RZiFLFLongfEZnTfQ LGn1RtQqxk0ygJ2BlGjvehlMlFEyNSqnxgB/QyzvdNBcqAIFl9W4MqpP8F7Z86vc USynapviUThzPX+lgR0otM84khfZQlA73/7ZvEwZnUhfoF+SdWK6D2efAizc5KY= =7+b0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 17 16:18:55 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0051295F9 for ; Thu, 17 Nov 2016 16:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTowqQX-StWz for ; Thu, 17 Nov 2016 16:18:43 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 231D01295A5 for ; Thu, 17 Nov 2016 16:18:43 -0800 (PST) Received: by mail-vk0-x22d.google.com with SMTP id 137so156422970vkl.0 for ; Thu, 17 Nov 2016 16:18:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=IdlPjVgB8yeF8yQJsHEHhWkP+vlnALYR6XRjXDHVp90=; b=mONBelfPAYFqpsJ775mFyx94vkpbFY8aMIG7cxEpCoFWLfc+F5AaLpGSYjDlkyJPLA pGR5b/HyGOs5roIVgT8LSkfAUfllIsSu2qpN001J+TQ0+ZaBrzcw6nyNOh8AOpMf1Hh5 qZCdIeBukrUh+3uVv0iU2xwXirl0sPoN2krnhoOmoaHfUg7yRL18jXvAS8joOp971SaR cFb1tOTsdc5FkrcSBOtny11+5kaSrgnfzVFilV1LXTSgTPTXKKeVe4QzoxAAPUHTeWzX AKx5qDBr3saRnLy29QoZmn+HHrc6fWvonGNfg09nVOx77auMwwDghP0rck2Cxc/8cn+o NLig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=IdlPjVgB8yeF8yQJsHEHhWkP+vlnALYR6XRjXDHVp90=; b=Uuq/Tx+dp/tZ0yySV2Qq4vbkSim0gASHYbcOPkiprvQ+jH/P6W+NlxtxuzmthQsymE /gp1iGUkcVLeFUQVfM+Vki1d6UWFVXiRQoMQL2mi8S/5KbgYydfku5jvdOMwW5+9uOXl 1dAO/fQsSFz8QwoSQEgrL1F8SQlvWiC6gCWAgcbataJXF7R4t22QsP+lR9BV9B71rsS7 9QKLyH9sqVC2vixY9XG1Rb69q9oga3z1k6L3pejqw3RrM4TX2nQv853yXqTFeqlhbrzL g5X9a1jBq4fVw6yN8Xz1522LrU4ZECJXGjImNwXCMVL3II7MAcdhZNM6AFeUd8j8Ry2X ToQw== X-Gm-Message-State: AKaTC02TEReeHRjO/gzr49uRjz90YA7OjrCVmQkPE3MC3aFl1VWoV1Wu+QEWMvKnJFFbrlIztBgzoVUDUHcQUA== X-Received: by 10.31.14.206 with SMTP id 197mr3797133vko.38.1479428322096; Thu, 17 Nov 2016 16:18:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.85.18 with HTTP; Thu, 17 Nov 2016 16:18:41 -0800 (PST) From: Watson Ladd Date: Thu, 17 Nov 2016 16:18:41 -0800 Message-ID: To: "ipsec@ietf.org WG" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [IPsec] Take a stand for key hygine X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 00:18:44 -0000 Dear all, In reviewing the proceedings now online I noticed that someone is proposing to support using the same key with multiple signature algorithms. This is a bad idea that makes everyone sad. Showing that a signature under one algorithm cannot be abused to obtain another signature with a different algorithm is not something that is done. Sincerely, Watson Ladd From nobody Thu Nov 17 18:31:44 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3214F129552 for ; Thu, 17 Nov 2016 18:31:44 -0800 (PST) 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 TvO727KYreX4 for ; Thu, 17 Nov 2016 18:31:42 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34731299E6 for ; Thu, 17 Nov 2016 18:31:42 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id f188so97353705pgc.3 for ; Thu, 17 Nov 2016 18:31:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=s6mC2Y3r/TxB5B/FUL6+gG+s49CDAmA7/54xSQRDlIs=; b=O/SvA/U+DexQzvPhlaiMu4TxMyAtufrQx3WpljHYQVeZf+ENpLWwMNpFf6wt5ZHWoN au3LYrPnTqog8QudnbD1dOTjJpio7mNGSpn+FFbZLC8NcbXvf/G+qpIK5vi4iYHvaxIt smXtN5NOZDvmJw+uXLFpgZqXJ9Hv28nji061qU8UZI/V2i9B6T9p15DnlwB3ntNN4f7C 1gMsj8HO+4VwY9k160wJzOhQcBgU4KJlQiSxJQC9DisZyoerYq0qtv0budPRzImNFvLM w/2laggg0SKN8Bu+haD84KsCbl7aVROZMSmi0rpu6am2ptXi3bnhGFnNGHHGy4g47H7x eGPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=s6mC2Y3r/TxB5B/FUL6+gG+s49CDAmA7/54xSQRDlIs=; b=DDP5RJ8wcUvFoRN8/FFyRjN364507BTT3XfaDn2Uh67dNkMCBohmBEe2rTw1GHztpQ 7iaiD/TatWnBBf8nxUAvvSvNfJOd9SCvbfTcYbXJ/1MPFv5Eo4BhuWheOYU9H4hVwRAI /Lz2x610ASelyl03ACDoWFVfntn1trlaD2s4kZeHMMGNVecQYyWyGreMikBFm/N64Z7i McFIAyPibYDo90H4JvRQK0tpF8GhsnrEPIoHLlh0Nzcbg/5dOFpp05jkVLwkl2SQ1rk4 chF7Bkyl01SN7aTlnRAt6Yn6RjHv2j6rB0/do4wb0Nx7BuAtOdXqWH1tJuk7RUGwsZEJ xy3Q== X-Gm-Message-State: ABUngvdnmakIN9DuEJt1DsFbxP8IImw9FFHxmJAVqhMka4mPiTHNaKpMeue8EP83o2jREQ== X-Received: by 10.99.106.200 with SMTP id f191mr13814186pgc.143.1479436302298; Thu, 17 Nov 2016 18:31:42 -0800 (PST) Received: from [10.56.26.202] ([116.84.110.38]) by smtp.gmail.com with ESMTPSA id m66sm11600713pfm.3.2016.11.17.18.31.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Nov 2016 18:31:41 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Yoav Nir In-Reply-To: Date: Fri, 18 Nov 2016 11:31:37 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <27A96107-FEE5-4453-8321-4F3402E66590@gmail.com> References: To: Watson Ladd X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Take a stand for key hygine X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 02:31:44 -0000 Hi, Watson On 18 Nov 2016, at 9:18, Watson Ladd wrote: > Dear all, >=20 > In reviewing the proceedings now online I noticed that someone is > proposing to support using the same key with multiple signature > algorithms. This is a bad idea that makes everyone sad. Showing that a > signature under one algorithm cannot be abused to obtain another > signature with a different algorithm is not something that is done. I don=E2=80=99t know where you got that, but I haven=E2=80=99t reviewed = the proceedings. I believe you mean what I said about contexts in Ed448 = (and possibly Ed25519ctx) from the CFRG draft. The question raised in IPsec (and TLS and in 30 minutes also in Curdle) = was whether to specify a non-empty context string fro Ed448 (like = =E2=80=9CIKEv2=E2=80=9D), or whether to just use the empty string.=20 The argument for adding the string is that people use the same keys for = different purposes (not different algorithms) anyway, even if we tell = them not to, and by adding a context string we=E2=80=99re preventing = signing oracles between IKEv2 and other protocols.=20 The argument against is that this encourages the bad practice of using = the same key for different purposes. We could end up with people = regularly re-using keys and then they do it with RSA. Or EDCSA. Or any = algorithm that does not feature contexts. At no point did anyone propose support for the same key with multiple = signature algorithms or even for multiple purposes. HTH Yoav From nobody Thu Nov 17 19:03:03 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C621299F9 for ; Thu, 17 Nov 2016 19:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSW3W-eGQxuU for ; Thu, 17 Nov 2016 19:03:00 -0800 (PST) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 511C11296BC for ; Thu, 17 Nov 2016 19:03:00 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id x23so95157416pgx.1 for ; Thu, 17 Nov 2016 19:03:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:to:cc:from:subject:date:importance :in-reply-to:references; bh=/3zU5slcOLjU6FKjFs5bBICbnK6ejfbkRbagvdvahrI=; b=dMP9hmeQoT8zi7r11Ni7oduFqbGvVM3G5Jv5yPceUkq6WkM3AEeBuqHiU9Qmh6DDHl C3+UeIc7nRNVsuAgh/TOuE4UL3hnSwENk9YKldZD6Ug9NCqSGdVjNwao6y23j/MgdLIF TfUXAHCi5HjbfBVNkSfZ1WZSHPmEhViAadNyQBpG892425Wko4BgivlXSTg/zl9zApSo U+3UypPBr0ADly3jHidAyUYli9W79fqKwmMIKOH5ZU44M/Af7N9xB8LWxkroUp8gTOQ/ 7QAshOTXdBLm/1wGDxz9aSgAcTZRKZ193VFF5Fx4LrAZ+9nScvGOj2fk9M7odTHRQOX9 Kt+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:mime-version:to:cc:from:subject:date :importance:in-reply-to:references; bh=/3zU5slcOLjU6FKjFs5bBICbnK6ejfbkRbagvdvahrI=; b=hCjRrVH3fSrVfHihlBJ2wLpilPoznNngWomirWgASfkv6fj8DAcZIlbkz5nURqY+I6 v/ZDrsG2oqwAqXa+ehKoHRj0f83tc+ZOz/XQ/iST8bpDIhyqT+wS9Nfpf3Ihcs7NKAvW fy18ooEup4OziEeC20JQLmBFi178BweHUqbE07H9rPQ5i31xKDfVg8+I7IM4WYq8FkP7 Dk1yYxY+ms/AHYG5zYWKwaFf5M1A1qxjEU0ea8Q2Oov8CyqtsnqCfo70yCkPPI2mzios 0I1Vp/RT26YLEXyrKmrhyPOsQqes6V6u/SrrR4W31MVHsx6aMlSqopjqZAIHFckoU6Kq aiSg== X-Gm-Message-State: ABUngvegCbZoG+V4vrsHIPkSLb2lqzcnH0wC5ilxPqv7dhGVq/Kj0exIYkA8xzAu7VuVlQ== X-Received: by 10.99.121.69 with SMTP id u66mr13671263pgc.96.1479438179651; Thu, 17 Nov 2016 19:02:59 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:d192:f4da:62df:954b? ([2001:67c:370:128:d192:f4da:62df:954b]) by smtp.gmail.com with ESMTPSA id q9sm11724575pfg.47.2016.11.17.19.02.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Nov 2016 19:02:58 -0800 (PST) Message-ID: <582e6f62.09d3620a.41bb6.2fe4@mx.google.com> MIME-Version: 1.0 To: Yoav Nir , Watson Ladd From: Valery Smyslov Date: Fri, 18 Nov 2016 12:03:05 +0900 Importance: normal X-Priority: 3 In-Reply-To: <27A96107-FEE5-4453-8321-4F3402E66590@gmail.com> References: <27A96107-FEE5-4453-8321-4F3402E66590@gmail.com> Content-Type: multipart/alternative; boundary="_DA0FE88F-3456-41C9-A205-A832B501BBED_" Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Take a stand for key hygine X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 03:03:02 -0000 --_DA0FE88F-3456-41C9-A205-A832B501BBED_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Watson, I also wonder where did you come to such a conclusion from. Besides discussion about contexts in EdDSA, there was a slide in my presentation that was about signature formats ambiguity in IKEv2, that may be interpreted as a promotion for using the same key with different signature algorithms. This interpretation is wrong, the purpose of the slide was to show, that the same, say RSA key can be used either in RSASSA-PKCS1 scheme, or in RSASSA-PSS scheme and there are some interoperability issues with that in IKEv2.=20 By no means this slide meant that the key is used in both schemes. Regards, Valery Smyslov.=20 From: Yoav Nir Sent: 18 =D0=BD=D0=BE=D1=8F=D0=B1=D1=80=D1=8F 2016 =D0=B3. 11:31 To: Watson Ladd Cc: ipsec@ietf.org WG Subject: Re: [IPsec] Take a stand for key hygine Hi, Watson On 18 Nov 2016, at 9:18, Watson Ladd wrote: > Dear all, >=20 > In reviewing the proceedings now online I noticed that someone is > proposing to support using the same key with multiple signature > algorithms. This is a bad idea that makes everyone sad. Showing that a > signature under one algorithm cannot be abused to obtain another > signature with a different algorithm is not something that is done. I don=E2=80=99t know where you got that, but I haven=E2=80=99t reviewed the= proceedings. I believe you mean what I said about contexts in Ed448 (and p= ossibly Ed25519ctx) from the CFRG draft. The question raised in IPsec (and TLS and in 30 minutes also in Curdle) was= whether to specify a non-empty context string fro Ed448 (like =E2=80=9CIKE= v2=E2=80=9D), or whether to just use the empty string.=20 The argument for adding the string is that people use the same keys for dif= ferent purposes (not different algorithms) anyway, even if we tell them not= to, and by adding a context string we=E2=80=99re preventing signing oracle= s between IKEv2 and other protocols.=20 The argument against is that this encourages the bad practice of using the = same key for different purposes. We could end up with people regularly re-u= sing keys and then they do it with RSA. Or EDCSA. Or any algorithm that doe= s not feature contexts. At no point did anyone propose support for the same key with multiple signa= ture algorithms or even for multiple purposes. HTH Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_DA0FE88F-3456-41C9-A205-A832B501BBED_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

Hi Watson,

 

I also wonder where did you come to such a conclusion from.

 

Besides discussion about co= ntexts in EdDSA, there was a slide

in my presentation that was about signature formats am= biguity

in IKE= v2, that may be interpreted as a promotion for using the same

key with different signatur= e algorithms. This interpretation is wrong,

the purpose of the slide was to show, that = the same, say RSA key can

be used either in RSASSA-PKCS1 scheme, or in RSASSA-PSS scheme<= o:p>

and there are = some interoperability issues with that in IKEv2.

By no means this slide meant that the k= ey is used in both schemes.

 

Regards,

Valery Smyslov.

 <= /o:p>

 

&nbs= p;

From: Yoav Nir
Sent: 18 =D0=BD=D0=BE=D1=8F=D0=B1=D1=80= =D1=8F 2016 =D0=B3. 11:31
To: Watson Ladd
Cc: ipsec= @ietf.org WG
Subject: Re: [IPsec] Take a stand for key hygine=

 

H= i, Watson

 

On 18 Nov 2016, at 9:18, Watson Ladd <watsonbladd@gmail.com> wrote:<= /p>

 

> Dear= all,

>

> In reviewi= ng the proceedings now online I noticed that someone is

> proposing to support using the same key with multiple signature

> algorithms. This is a bad idea that makes every= one sad. Showing that a

> signature under one al= gorithm cannot be abused to obtain another

> sig= nature with a different algorithm is not something that is done.

 

I don=E2=80=99t kno= w where you got that, but I haven=E2=80=99t reviewed the proceedings. I bel= ieve you mean what I said about contexts in Ed448 (and possibly Ed25519ctx)= from the CFRG draft.

 

The question raised in IPsec (and TLS and in 30 minutes also i= n Curdle) was whether to specify a non-empty context string fro Ed448 (like= =E2=80=9CIKEv2=E2=80=9D), or whether to just use the empty string.

 

The argument fo= r adding the string is that people use the same keys for different purposes= (not different algorithms) anyway, even if we tell them not to, and by add= ing a context string we=E2=80=99re preventing signing oracles between IKEv2= and other protocols.

 

The argument against is that this encourages the bad practice= of using the same key for different purposes. We could end up with people = regularly re-using keys and then they do it with RSA. Or EDCSA. Or any algo= rithm that does not feature contexts.

 

At no point did anyone propose support for the= same key with multiple signature algorithms or even for multiple purposes.=

 

HTH

<= p class=3DMsoNormal> 

Yoav

 

_________________= ______________________________

IPsec mailing list

IPsec@ietf.org

https://www.i= etf.org/mailman/listinfo/ipsec

 

= --_DA0FE88F-3456-41C9-A205-A832B501BBED_-- From nobody Thu Nov 17 19:05:56 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBB01297AB for ; Thu, 17 Nov 2016 19:05:54 -0800 (PST) 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 KWvSqltqRPaZ for ; Thu, 17 Nov 2016 19:05:52 -0800 (PST) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87323129784 for ; Thu, 17 Nov 2016 19:05:52 -0800 (PST) Received: by mail-ua0-x230.google.com with SMTP id 51so160148159uai.1 for ; Thu, 17 Nov 2016 19:05:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QOt8CpDY+mrkJRhF52yrFVRadMqpap2rpOVWWzxFHAU=; b=mnwV4owlhGQTS0OWAG1BrlKZUywzaL0deBKA9bCGTkP4IYuOMCVxX/5ryeuFinnbGy FDWoNGYv45vXX6utjcMeNain7ww7qjkpsFseGKecAxdSJu4SOVhg+o+iv1ZaJGtWgiBs d5c/lV5JM+F6fC5YxxnZ44MG4M3TGZ65Vr0mvWuCSwRAqmSQnVXg2UHeni6L4pImOPgP /NVb8sYB3Ism/HNGrehTiMeLeiDubRTTgWRNONmDZZJR3zwE5huTH/uYSswVRW2F2OYF Moq5nmJRUQ17Pgz01LEHymVvFFtXRM3X/f2Px45nZcR0A5QOleoOsqB+Zo1HzhD3vP/l p8GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QOt8CpDY+mrkJRhF52yrFVRadMqpap2rpOVWWzxFHAU=; b=UlHGtTiHNSUKgUDFoK66fSM06+pXLo/WUrcxf2B08Yy0VBtwLFLQpbn+wettNZN7zY wWjavq1XGIFNu4rSY2CIgJYzLh8Bf4MGwGfh0L6xhGp/tj3qgtWchd8r46P9Hn5x1SCc Xid4UPXHL0qiQxvSZw8u0zI0wP7TDu3Uh6alPvMLVRmHx/uagQqpA/Vg1hZwnJx+awMt MGbbip0zehlM+d0ys/7yTN87tvf9ZU+HTll7H82+SUsQptMdZ0kIkF/XRfsIknWBEAgG V1wa5OmBXoYuSOrao1qau/AhxXk1dV/m+N8iQGHgXMkL3jyHMHrAVpJzkIwCYAUdhSZq JHwg== X-Gm-Message-State: ABUngvesiSqGKP7RMUs4BeJwdt3995gL7yU36Z8izMG9nKWcQbs5fEd20RYQAm0U4Bw+OhetKEcD9mTTsF1kuQ== X-Received: by 10.159.38.228 with SMTP id 91mr4507410uay.102.1479438351612; Thu, 17 Nov 2016 19:05:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.85.18 with HTTP; Thu, 17 Nov 2016 19:05:51 -0800 (PST) In-Reply-To: <27A96107-FEE5-4453-8321-4F3402E66590@gmail.com> References: <27A96107-FEE5-4453-8321-4F3402E66590@gmail.com> From: Watson Ladd Date: Thu, 17 Nov 2016 19:05:51 -0800 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Take a stand for key hygine X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 03:05:55 -0000 On Thu, Nov 17, 2016 at 6:31 PM, Yoav Nir wrote: > Hi, Watson > > On 18 Nov 2016, at 9:18, Watson Ladd wrote: > >> Dear all, >> >> In reviewing the proceedings now online I noticed that someone is >> proposing to support using the same key with multiple signature >> algorithms. This is a bad idea that makes everyone sad. Showing that a >> signature under one algorithm cannot be abused to obtain another >> signature with a different algorithm is not something that is done. > > I don=E2=80=99t know where you got that, but I haven=E2=80=99t reviewed t= he proceedings. I believe you mean what I said about contexts in Ed448 (and= possibly Ed25519ctx) from the CFRG draft. > > The question raised in IPsec (and TLS and in 30 minutes also in Curdle) w= as whether to specify a non-empty context string fro Ed448 (like =E2=80=9CI= KEv2=E2=80=9D), or whether to just use the empty string. > > The argument for adding the string is that people use the same keys for d= ifferent purposes (not different algorithms) anyway, even if we tell them n= ot to, and by adding a context string we=E2=80=99re preventing signing orac= les between IKEv2 and other protocols. > > The argument against is that this encourages the bad practice of using th= e same key for different purposes. We could end up with people regularly re= -using keys and then they do it with RSA. Or EDCSA. Or any algorithm that d= oes not feature contexts. > > At no point did anyone propose support for the same key with multiple sig= nature algorithms or even for multiple purposes. I might be confused, but the slides in https://www.ietf.org/proceedings/97/slides/slides-97-ipsecme-signature-form= s-ambiguity-in-ikev2-00.pdf seem to very clearly want something else. Apologies for my insufficient context inclusion. > > HTH > > Yoav > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Thu Nov 17 19:38:18 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDF61294B9 for ; Thu, 17 Nov 2016 19:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 PbtBHK_VgZcT for ; Thu, 17 Nov 2016 19:38:15 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3313E1293D6 for ; Thu, 17 Nov 2016 19:38:15 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id uAI3cB3C029605 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 18 Nov 2016 05:38:11 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uAI3cBOl014614; Fri, 18 Nov 2016 05:38:11 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22574.30627.388793.378538@fireball.acr.fi> Date: Fri, 18 Nov 2016 05:38:11 +0200 From: Tero Kivinen To: Watson Ladd In-Reply-To: References: <27A96107-FEE5-4453-8321-4F3402E66590@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 3 min Archived-At: Cc: "ipsec@ietf.org WG" , Yoav Nir Subject: Re: [IPsec] Take a stand for key hygine X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 03:38:16 -0000 Watson Ladd writes: > I might be confused, but the slides in > https://www.ietf.org/proceedings/97/slides/slides-97-ipsecme-signature-forms-ambiguity-in-ikev2-00.pdf > seem to very clearly want something else. Apologies for my > insufficient context inclusion. Yes, with RSA I think it might be quite common for people to use same key for both RSA PKCS#1 v1.5 and RSA-PSS, and there is not really anything we can do for that. On the other hand the interoperability issue we have now does not really care whether you have one or two RSA private keys, as long as initiator can use either RSA-PSS or RSA PKCS#1 v1.5, and do not know which one responder will accept. I think we might want to add text in the rfc4307bis saying that same key should not be used with both RSA-PSS and PKCS#1 v1.5. The rfc4307bis will be in IETF Last Call soon, so if you can read that and see what it says about the signature algorithms and see if there is something we need to add there, that would be great. -- kivinen@iki.fi From nobody Thu Nov 17 20:01:32 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E075A129613 for ; Thu, 17 Nov 2016 20:01:29 -0800 (PST) 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, 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 9AbFY8WAe7Gt for ; Thu, 17 Nov 2016 20:01:28 -0800 (PST) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (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 52330129516 for ; Thu, 17 Nov 2016 20:01:28 -0800 (PST) Received: by mail-ua0-x229.google.com with SMTP id 51so160920086uai.1 for ; Thu, 17 Nov 2016 20:01:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pgTJh60xzUSf5F/MH9d+eSoZxM2z/lUR+cW6g4iO++4=; b=BSaOVOKvZS9Jtl/1pzKk7QTg6X5i9A4+ZAG+6JChiRwIoJ96Zxr3RkB0Cko5g/OtxA BpCN0z3FOGT4/ao7bR9g2ZOB0UEqXaM7CeDw1QRzHcS7apQm0E4zZPO76kP8TOW4KRRa KjGafr+/6FSOiRSKETIxz1DllyVNK3AqVd3d9R+cY0jpTPZGd65/47+sJjgxSTEPYDMI LOQh9atJuQTqzVFS+8V9AY6z8jeTiok+ePOJsiyQ58eyiVYcfzoyJVPKo2WHxNRYxIHp MuVhPz+9JlSSjeLWq8eJqwJO0T2IjmkSHKPq9Hmz4ts8SmU3XwSeoM0Q8Csx6LE+37LD HAcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pgTJh60xzUSf5F/MH9d+eSoZxM2z/lUR+cW6g4iO++4=; b=ABZG908MKzhphr8E3AgCq4hVMJwezv2/X1Cmn2OWXAcTGD8Zqozknd8RCwVpmlV1+m mtDNkJ1W750oguGFvK1+KmWV0cH5lapmQD5p2P4Qa+DVpGbkIM3KW1Y4lxCKDHpBKp73 jwRfdOTh6gxpevrjXKLvlhDZyoUqVbqnkClPPAxmzQT67ujLV9JCARMzkaoRrehHdIJZ y7UlSDUcPDiZPitQ1qDR0h5iDsbux24mhqA64aZXNhNp+SD3wLw2QJ9Cm7wAh8VPhFbU axf+AAhnJhbSKxVn469fOebTBkStpBMyUDcFRhasS980uEPK4+ElU0mtbYCYjMthpNkF W3ng== X-Gm-Message-State: ABUngvfwKaPpZsKb6VOQ0Ztf3UQdIMQ8Aiqw0OJEDGQL+N9eC1LKrU9h1ehHaWp40waIwagFIdgw8VYrIh30NQ== X-Received: by 10.159.38.228 with SMTP id 91mr4621578uay.102.1479441687425; Thu, 17 Nov 2016 20:01:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.85.18 with HTTP; Thu, 17 Nov 2016 20:01:27 -0800 (PST) In-Reply-To: <22574.30627.388793.378538@fireball.acr.fi> References: <27A96107-FEE5-4453-8321-4F3402E66590@gmail.com> <22574.30627.388793.378538@fireball.acr.fi> From: Watson Ladd Date: Thu, 17 Nov 2016 20:01:27 -0800 Message-ID: To: Tero Kivinen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "ipsec@ietf.org WG" , Yoav Nir Subject: Re: [IPsec] Take a stand for key hygine X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 04:01:30 -0000 On Thu, Nov 17, 2016 at 7:38 PM, Tero Kivinen wrote: > Watson Ladd writes: >> I might be confused, but the slides in >> https://www.ietf.org/proceedings/97/slides/slides-97-ipsecme-signature-forms-ambiguity-in-ikev2-00.pdf >> seem to very clearly want something else. Apologies for my >> insufficient context inclusion. > > Yes, with RSA I think it might be quite common for people to use same > key for both RSA PKCS#1 v1.5 and RSA-PSS, and there is not really > anything we can do for that. > > On the other hand the interoperability issue we have now does not > really care whether you have one or two RSA private keys, as long as > initiator can use either RSA-PSS or RSA PKCS#1 v1.5, and do not know > which one responder will accept. What about the approach of treating these as different authentication methods? Or am I misunderstanding the scope of the problem? I'm not that familiar with IKE2. > > I think we might want to add text in the rfc4307bis saying that same > key should not be used with both RSA-PSS and PKCS#1 v1.5. > > The rfc4307bis will be in IETF Last Call soon, so if you can read that > and see what it says about the signature algorithms and see if there > is something we need to add there, that would be great. I will look over it. > -- > kivinen@iki.fi -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Fri Nov 18 14:21:31 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06541294E6 for ; Fri, 18 Nov 2016 14:21:29 -0800 (PST) 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, 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 ipVhis3irhM5 for ; Fri, 18 Nov 2016 14:21:28 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 7DAC1129437 for ; Fri, 18 Nov 2016 14:21:28 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id a197so65064204wmd.0 for ; Fri, 18 Nov 2016 14:21:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ChCH/jthYObkFQ4f0tK2wd6fJ9ytwEU6+vliVNGyCYQ=; b=O7CAcyx6EQu7J+fmVPcPb37y1u3l/Azry9l07glgG0tEhrLa0JSuYQyVfiGVnlioFs qfoDYoq8h7JUK9SX2UlbsfRRvWYRFh/87+jPz0rBZK75Bg6WKZaLZkG2Aizj1oMtVYTM 96E8VpIZwhOdxm73yWSjtc6CKkasA7GGBC4wz3xZIPSR5VCpjYNZ58R75j5sNMCFCQkY efbvOYc5v01Q7vArzMuOgkL4OX0MjUgTy7RNaMttV1VWGKfq8fbTEheqioRUpqTPYzIT ixJTKgilgiv5FfGEYJZCAJ5pGKuKW1UJ83sIW3gQ7t+Zdcy+PzeIM2Tvo3Y1FktNIcSR SVdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ChCH/jthYObkFQ4f0tK2wd6fJ9ytwEU6+vliVNGyCYQ=; b=iLLinzm4Hu23gMiguaMWr2NXWvONIUsGb+QN1nBPP1n+KNv2wPumib7YrFdTDWlpBk hA3NbaatHBlpxCjl+bwXYOu6k5Art44QT0BFXVGEhZQ2Lrk2z072kBI3Pb1HB6mGOccl 0XrQU0veD4kKJGbDBgP01zvvtUKYDJFOBWPicYHUZh/gsjJlZX54k3gkEO9sTMrKZP1G ySm/GE+2d+C/PWk9gAM9/JGbGZG1kKjmKTnt5kELcgIhwQdV8jCQGINtDuai192KtjSi FKYb/eEZf+x+saXK6GR3lasBsG0pYHCWFHy7/FkUSt2t5oVEdUBXlI3bEBEjxuHrBds1 W91g== X-Gm-Message-State: AKaTC0224RGc1MR5lssXctNZWTXXmmoaGaIUSfslaesgzEqVl1W3aBKDy6aNoNGUy6Zvvg== X-Received: by 10.28.141.18 with SMTP id p18mr579469wmd.31.1479507687098; Fri, 18 Nov 2016 14:21:27 -0800 (PST) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id k2sm11042570wjv.11.2016.11.18.14.21.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Nov 2016 14:21:26 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Yoav Nir In-Reply-To: <22574.30627.388793.378538@fireball.acr.fi> Date: Sat, 19 Nov 2016 00:21:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <27A96107-FEE5-4453-8321-4F3402E66590@gmail.com> <22574.30627.388793.378538@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "ipsec@ietf.org WG" , Watson Ladd Subject: Re: [IPsec] Take a stand for key hygine X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 22:21:30 -0000 > On 18 Nov 2016, at 5:38, Tero Kivinen wrote: >=20 > Watson Ladd writes: >> I might be confused, but the slides in >> = https://www.ietf.org/proceedings/97/slides/slides-97-ipsecme-signature-for= ms-ambiguity-in-ikev2-00.pdf >> seem to very clearly want something else. Apologies for my >> insufficient context inclusion. >=20 > Yes, with RSA I think it might be quite common for people to use same > key for both RSA PKCS#1 v1.5 and RSA-PSS, and there is not really > anything we can do for that. If that is a problem, then it is more serious for TLS. TLS 1.2 has only = PKCS#1. TLS 1.3 has only PSS. So a server that uses a single = certificate with RSA for both versions (probably most servers in 1-2 = years) will be producing both kinds of signatures from the same key. If that=E2=80=99s a problem, it should be raised during WGLC of TLS 1.3 = (which si now) Yoav =20= From nobody Fri Nov 18 15:38:33 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33C412947F for ; Fri, 18 Nov 2016 15:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSlpbkjVjA-G for ; Fri, 18 Nov 2016 15:38:30 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BF1512946E for ; Fri, 18 Nov 2016 15:38:30 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id a197so67406441wmd.0 for ; Fri, 18 Nov 2016 15:38:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:to:cc:from:subject:date:importance :in-reply-to:references; bh=4rfFHAh3a6U/jUWg85pVeEGrq0IFVkDx4AQYvkuGTDw=; b=RDlv5eiA39Rr0VR0iERZvdGQORieCfR8o3BWKkanPNLaCTR/Im0vWS5kZt90KYpqlA SC2KtKjfbpTpRXHhoCdzzEu08hs68ELlfg7D66PiGVUTNmVRopnpSvqy4T/axK2QpIaq 2nIN12nys66VvTUCzoqsR+ti0R+J/AetFPocxAlmWiekPNahqRZSIgwWyP9CKxPxd8cm nfLj6hzdAifaTsm/mwo4Og4zgxl/3QyAJxEdXTbHIbKDrpRy/SzdHs244DJo0xrkHdqx bjS1Kp/iEiGdRGHIO3Q+oyWGdjsd9bjvvk1AWyIzHgi8iYMWhWLX+2q2U1XnSgbvjbz9 nHgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:mime-version:to:cc:from:subject:date :importance:in-reply-to:references; bh=4rfFHAh3a6U/jUWg85pVeEGrq0IFVkDx4AQYvkuGTDw=; b=EPfrUEP2MEftliuH4dd4i/Tv/ig/aqQ+PgAAWBuPkaB2PyaGTvzddhOn6qy/2oZy5Q bgcrHhG8pto2BttXv8GEuLAx/8wRv4MuAMpEFTKu/hj38bUHBTc8ALFXe7K7oj9rX4uT TbTgyOi84WLjt5TBOOCnzohT4KgT+3qfOJqbZWYt6GyxXwLDDFxrq4t8aVoZ/AbUD2cH nc0ukTFm7UYzCugIzmh7JdnBtZ7LaVJlpPLL4XTyHftKKvk/jcC6PpwaW51SC+uDdg9L NYq9A7dueXHolrOosuhLa/N4xxD68niSE2oGWlojuBggvhKlj/Yw+H3zkfyt5FOexlao 2lpA== X-Gm-Message-State: AKaTC02tcMVUqAB4ZngijwCybZXtZqPmklGtl0yCLuTfb0mzu9PUnIirx8/4/d4qnAbG3g== X-Received: by 10.25.192.1 with SMTP id q1mr543219lff.143.1479512308626; Fri, 18 Nov 2016 15:38:28 -0800 (PST) Received: from ?IPv6:::ffff:192.168.0.34? ([175.193.211.25]) by smtp.gmail.com with ESMTPSA id d135sm2871708lfg.12.2016.11.18.15.38.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Nov 2016 15:38:27 -0800 (PST) Message-ID: <582f90f3.8dcd190a.4fa62.a960@mx.google.com> MIME-Version: 1.0 To: Yoav Nir , Tero Kivinen From: Valery Smyslov Date: Sat, 19 Nov 2016 08:38:34 +0900 Importance: normal X-Priority: 3 In-Reply-To: References: <27A96107-FEE5-4453-8321-4F3402E66590@gmail.com> <22574.30627.388793.378538@fireball.acr.fi> Content-Type: multipart/alternative; boundary="_5104FA4B-8D77-40BD-8FFD-45814EED107D_" Archived-At: Cc: "ipsec@ietf.org WG" , Watson Ladd Subject: Re: [IPsec] Take a stand for key hygine X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 23:38:32 -0000 --_5104FA4B-8D77-40BD-8FFD-45814EED107D_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Yoav, or the servers must be provided with two certificates =E2=80=93 one for TLS= 1.2 and the other for TLS 1.3, that won=E2=80=99t make server owners happy. I think it is a good idea to raise this issue in TLS WG. Regards, Valery. From: Yoav Nir Sent: 19 =D0=BD=D0=BE=D1=8F=D0=B1=D1=80=D1=8F 2016 =D0=B3. 7:21 To: Tero Kivinen Cc: ipsec@ietf.org WG; Watson Ladd Subject: Re: [IPsec] Take a stand for key hygine > On 18 Nov 2016, at 5:38, Tero Kivinen wrote: >=20 > Watson Ladd writes: >> I might be confused, but the slides in >> https://www.ietf.org/proceedings/97/slides/slides-97-ipsecme-signature-f= orms-ambiguity-in-ikev2-00.pdf >> seem to very clearly want something else. Apologies for my >> insufficient context inclusion. >=20 > Yes, with RSA I think it might be quite common for people to use same > key for both RSA PKCS#1 v1.5 and RSA-PSS, and there is not really > anything we can do for that. If that is a problem, then it is more serious for TLS. TLS 1.2 has only PKC= S#1. TLS 1.3 has only PSS. So a server that uses a single certificate with= RSA for both versions (probably most servers in 1-2 years) will be produci= ng both kinds of signatures from the same key. If that=E2=80=99s a problem, it should be raised during WGLC of TLS 1.3 (wh= ich si now) Yoav =20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_5104FA4B-8D77-40BD-8FFD-45814EED107D_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

Hi Yoav,

=

 

or the servers must be provided with two certificates =E2=80=93 on= e for TLS 1.2

= and the other for TLS 1.3, that won=E2=80=99t make server owners happy.

 =

I think it is a good ide= a to raise this issue in TLS WG.

=  

Regards,

Valery.

 

 

 

From: Yoav Nir
Sent: 19 =D0=BD=D0=BE=D1=8F=D0=B1=D1=80=D1= =8F 2016 =D0=B3. 7:21
To: Tero = Kivinen
Cc: ipsec@ietf.org = WG; Watson Ladd
Subj= ect: Re: [IPsec] Take a stand for key hygine

 

 

> On 18 Nov 2016, at 5:38, Tero Kivinen <kivinen@iki.fi= > wrote:

>

> Wats= on Ladd writes:

>> I might be confused, but t= he slides in

>> https://www.ietf.org/proceedi= ngs/97/slides/slides-97-ipsecme-signature-forms-ambiguity-in-ikev2-00.pdf

>> seem to very clearly want something else. A= pologies for my

>> insufficient context inclu= sion.

>

> Yes, with = RSA I think it might be quite common for people to use same

> key for both RSA PKCS#1 v1.5 and RSA-PSS, and there is not re= ally

> anything we can do for that.

 

If that is a problem= , then it is more serious for TLS. TLS 1.2 has only PKCS#1. TLS 1.3 has onl= y PSS.=C2=A0 So a server that uses a single certificate with RSA for both v= ersions (probably most servers in 1-2 years) will be producing both kinds o= f signatures from the same key.

 

If that=E2=80=99s a problem, it should be raised dur= ing WGLC of TLS 1.3 (which si now)

 

Yoav

_______________________________________________

IPsec mailing list

IPsec@ietf.org

https://www.ietf.org/mailman/listinfo/ipsec

 

= --_5104FA4B-8D77-40BD-8FFD-45814EED107D_-- From nobody Fri Nov 18 15:42:53 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73A1129438 for ; Fri, 18 Nov 2016 15:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYI5skh7_dQn for ; Fri, 18 Nov 2016 15:42:50 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA57126BF7 for ; Fri, 18 Nov 2016 15:34:20 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id u144so9456144wmu.1 for ; Fri, 18 Nov 2016 15:34:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:to:cc:from:subject:date:importance :in-reply-to:references; bh=GZOUC/uMnKFxFR4Fo0X6xYCqbF6IoxZtSKhlPGcG8RE=; b=B7InS6aTVlNPZOfii+WHw4KoFkZKk75rGs9KC+ulXtuATQvCvgF6DWLmIbQwS0gyPM ljUm/aXOOuGAAcbiOuza+2/viPPxWJrsjGozlDVwYpaGd5JuTgykDguw8een6wq3PJ7z 7A2mN3UVMn/h/lwbUdPzOMjAOACjEgAIyRZDtu+eOZJKMgvI+nLBRF1IyZUl1mCtPlUV f4YA0sr8ilkmVN93oVwX6HTIkgcNifqW537mZrj2mfTpGSPwh0lv9qFi9A2hnFkvznns mC5wA5D9BDoLryrXNZB6FEqDQBEwQFjXr0z8QIWKM/keGw43mt4qN3luRuNpYiwP+nAN NhoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:mime-version:to:cc:from:subject:date :importance:in-reply-to:references; bh=GZOUC/uMnKFxFR4Fo0X6xYCqbF6IoxZtSKhlPGcG8RE=; b=Xv5klI2eyeU5vpVuo5/nhg+uJcBFDtvsJjYxG+Pi54sEknpYfqq+0qJLaXNk2F11mi 3Fnmw7SQrSLu1yPbJPh4mk1fXldrjDkQu+r8tjwqUjQvzhwlSagYsAT4CeOi/54f/A18 3KqX66108HAnOkdPDs+RZK3tI2DGQDbfiGorarnM4OMGnw7YkWFbadFHPbJNED2ff1vr 3QToq3eQSMMQXTnAe76DvFP/6nsNYU5jlI06FDhw1RrtDpOrY5tYcZaz6M52ii7o0go0 +TK5XQFyS3+bmSD3B0yn0IRxBJVz03VJn0XajkAqJKVA8aTOuCtUUOvUW9tqE5fba73s HCGw== X-Gm-Message-State: AKaTC03QDVQCAFgwwKXYWgYKOKZHcNsENvJlpcrJDGYXnFqknxjxHkhgxgvqoEmOZIprRA== X-Received: by 10.46.32.26 with SMTP id g26mr1345616ljg.22.1479512059470; Fri, 18 Nov 2016 15:34:19 -0800 (PST) Received: from ?IPv6:::ffff:192.168.0.34? ([175.193.211.25]) by smtp.gmail.com with ESMTPSA id 23sm2870006ljf.48.2016.11.18.15.34.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Nov 2016 15:34:18 -0800 (PST) Message-ID: <582f8ffa.17052e0a.75161.aaeb@mx.google.com> MIME-Version: 1.0 To: Watson Ladd , Tero Kivinen From: Valery Smyslov Date: Sat, 19 Nov 2016 08:34:20 +0900 Importance: normal X-Priority: 3 In-Reply-To: References: <27A96107-FEE5-4453-8321-4F3402E66590@gmail.com> <22574.30627.388793.378538@fireball.acr.fi> Content-Type: multipart/alternative; boundary="_C2EE3CBF-6EE2-4634-A9CC-3EDF627EAC36_" Archived-At: Cc: "ipsec@ietf.org WG" , Yoav Nir Subject: Re: [IPsec] Take a stand for key hygine X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 23:42:52 -0000 --_C2EE3CBF-6EE2-4634-A9CC-3EDF627EAC36_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Watson, the problem is not that the host cannot deduce from received AUTH payload what kind of signature was used =E2=80=93 the AUTH payload includes Algorit= hmIdentifier, so these signatures are treated differently. The problem is that host canno= t guess what kind of signatures the peer supports, that can lead to SA setup = failure. This is not a cryptographic problem, this is IKEv2 protocol problem. And it was probably not very precise text in my presentation =E2=80=93=20 it meant that we have a problem if the same kind of key (say RSA) can be used with different signature schemes (say RSA-PKCS and RSA-PSS), not necessary the same key. Regards, Valery. From: Watson Ladd Sent: 18 =D0=BD=D0=BE=D1=8F=D0=B1=D1=80=D1=8F 2016 =D0=B3. 13:01 To: Tero Kivinen Cc: ipsec@ietf.org WG; Yoav Nir Subject: Re: [IPsec] Take a stand for key hygine On Thu, Nov 17, 2016 at 7:38 PM, Tero Kivinen wrote: > Watson Ladd writes: >> I might be confused, but the slides in >> https://www.ietf.org/proceedings/97/slides/slides-97-ipsecme-signature-f= orms-ambiguity-in-ikev2-00.pdf >> seem to very clearly want something else. Apologies for my >> insufficient context inclusion. > > Yes, with RSA I think it might be quite common for people to use same > key for both RSA PKCS#1 v1.5 and RSA-PSS, and there is not really > anything we can do for that. > > On the other hand the interoperability issue we have now does not > really care whether you have one or two RSA private keys, as long as > initiator can use either RSA-PSS or RSA PKCS#1 v1.5, and do not know > which one responder will accept. What about the approach of treating these as different authentication methods? Or am I misunderstanding the scope of the problem? I'm not that familiar with IKE2. > > I think we might want to add text in the rfc4307bis saying that same > key should not be used with both RSA-PSS and PKCS#1 v1.5. > > The rfc4307bis will be in IETF Last Call soon, so if you can read that > and see what it says about the signature algorithms and see if there > is something we need to add there, that would be great. I will look over it. > -- > kivinen@iki.fi --=20 "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_C2EE3CBF-6EE2-4634-A9CC-3EDF627EAC36_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

Hi Watson,

 

the problem is not that the host cannot deduce from rec= eived AUTH payload

what kind of signature was used =E2=80=93 the AUTH payload includes Al= gorithmIdentifier,

so these signatures are treated differently. The problem is that host = cannot

guess w= hat kind of signatures the peer supports, that can lead to SA setup failure= .

This is not = a cryptographic problem, this is IKEv2 protocol problem.<= /p>

 

And it was probably not very precise te= xt in my presentation =E2=80=93

= it meant that we have a problem if the same kind of key = (say RSA)

can = be used with different signature schemes (say RSA-PKCS and RSA-PSS),

not necessary the sa= me key.

&= nbsp;

Regards,=

Valery.

=

 

From: Watson Ladd
Sent: 18 = =D0=BD=D0=BE=D1=8F=D0=B1=D1=80=D1=8F 2016 =D0=B3. 13:01
To: Tero Kivinen
Cc: ipsec@ietf.org WG; Yoav Nir
Subject: Re: [IPsec] Take a stand for key hygi= ne

 

On Thu, Nov 17, 2016 at 7:38 PM, Tero Kivinen <kivinen@iki.fi> wrote= :

> Watson Ladd writes:

= >> I might be confused, but the slides in

>= ;> https://www.ietf.org/proceedings/97/slides/slides-97-ipsecme-signatur= e-forms-ambiguity-in-ikev2-00.pdf

>> seem to = very clearly want something else. Apologies for my

= >> insufficient context inclusion.

>&= nbsp;

> Yes, with RSA I think it might be = quite common for people to use same

> key for bo= th RSA PKCS#1 v1.5 and RSA-PSS, and there is not really

> anything we can do for that.

>&nb= sp;

> On the other hand the interoperabili= ty issue we have now does not

> really care whet= her you have one or two RSA private keys, as long as

> initiator can use either RSA-PSS or RSA PKCS#1 v1.5, and do not know=

> which one responder will accept.

 

What about the appro= ach of treating these as different authentication

m= ethods? Or am I misunderstanding the scope of the problem? I'm not

that familiar with IKE2.

 = ;

> 

> I think we might want to add text in the rfc4307bis saying that sam= e

> key should not be used with both RSA-PSS and= PKCS#1 v1.5.

> 

> The rfc4307bis will be in IETF Last Call soon, so if you can = read that

> and see what it says about the signa= ture algorithms and see if there

> is something = we need to add there, that would be great.

&nb= sp;

I will look over it.

> --

> kivinen@iki.fi

 

 

 

--

"Man is born free, but everywhere he is in chains".

<= p class=3DMsoNormal>--Rousseau.

 

_______________________________________________

<= p class=3DMsoNormal>IPsec mailing list

IPsec@ietf.o= rg

https://www.ietf.org/mailman/listinfo/ipsec

<= p class=3DMsoNormal> 

= --_C2EE3CBF-6EE2-4634-A9CC-3EDF627EAC36_-- From nobody Sat Nov 19 00:32:39 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E1A12959C for ; Sat, 19 Nov 2016 00:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3K9Vphy_Kbvz for ; Sat, 19 Nov 2016 00:32:35 -0800 (PST) Received: from mail-qt0-x243.google.com (mail-qt0-x243.google.com [IPv6:2607:f8b0:400d:c0d::243]) (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 37B5B1294BB for ; Sat, 19 Nov 2016 00:32:35 -0800 (PST) Received: by mail-qt0-x243.google.com with SMTP id n34so20457215qtb.3 for ; Sat, 19 Nov 2016 00:32:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=tr0lUC1w1ZPS3CgMLlF/HpG0q1FP47cqEXSy6UIeuZ8=; b=lPIcFHFEiZ++Uj4dNDcE0dMJrKVwHdP5NoFrsWG9XTPYa/WCPyxMn+1yWOCbldJTb7 1BQbe/Ic4BuGiqAwXFIqgu6W7vOqfJiFsEr49u/OcbkoPs/VVQK883gdZc8hsh0q3r4G gcj2e6NaKH975pxNt0x38jqzmKTn4Ivs8Xk77YLlFqRXsg5BljmJ2LQwNxdC+DC3qQG+ nXIZODAofVoxAWCi1XhIa58TGWRi/KaCZADzYehUT+xZ4O6qzMwPQnMmwA0EYWCxsufF J6GJL4otecLpdkjR5QT2CyitvgJIhFj2A1T3mn7+0K4uomIbpmgrahhJYHJjlhDhdxfH i3Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=tr0lUC1w1ZPS3CgMLlF/HpG0q1FP47cqEXSy6UIeuZ8=; b=T8hDCiOHwXRj8ouwneIlV/GUh1RWuDWbaJWDUp4f5ntxGKiXC8wy8DjVE1UvpXlBRr UWQ9suSms/XbwVdXQzli6NPAOYgnQwNasyjsQ1svhFZNRsC6BFBx7ZYatsjeR0fj0gEx 8FGxvA1AlmBYrPrHN6/ZMSlF3mCRRzNRoTdJAkx2ExT36UCs8rjQxpXjFW3ebT1NXSfq ojBu1QL9TmvZaG2NhRwWQ560quAvqemIe6fhJkLsGN98W0PrKx/DTLvUBKwDo/O5u6GQ LxcsFJbCG8Y68BN/muYrvCbBz1onaPmAnyeFBVOoV2qclPUpLBM0roNRnGhQSCi8JDuV BKvw== X-Gm-Message-State: AKaTC01sOi69GcnFf2SF/SyK74EcA8CFRzPjukT3XMxbVJ7UiXjnI0H9PM+q/xDM6kMFsA== X-Received: by 10.28.16.65 with SMTP id 62mr2531884wmq.81.1479544354222; Sat, 19 Nov 2016 00:32:34 -0800 (PST) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id l67sm8114480wmf.0.2016.11.19.00.32.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Nov 2016 00:32:33 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_6D3A2B0C-F80A-4048-8D21-943C6A63FCDC" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Yoav Nir X-Priority: 3 In-Reply-To: <582f90f3.8dcd190a.4fa62.a960@mx.google.com> Date: Sat, 19 Nov 2016 10:32:31 +0200 Message-Id: <138393D5-4E95-4276-9DC9-E8A1BA4F8571@gmail.com> References: <27A96107-FEE5-4453-8321-4F3402E66590@gmail.com> <22574.30627.388793.378538@fireball.acr.fi> <582f90f3.8dcd190a.4fa62.a960@mx.google.com> To: Valery Smyslov X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "ipsec@ietf.org WG" , Watson Ladd , Tero Kivinen Subject: Re: [IPsec] Take a stand for key hygine X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2016 08:32:37 -0000 --Apple-Mail=_6D3A2B0C-F80A-4048-8D21-943C6A63FCDC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Definitely won=E2=80=99t, but I first want to know if this is actually a = problem. I=E2=80=99ll ask on the CFRG list. Yoav > On 19 Nov 2016, at 1:38, Valery Smyslov wrote: >=20 > Hi Yoav, > =20 > or the servers must be provided with two certificates =E2=80=93 one = for TLS 1.2 > and the other for TLS 1.3, that won=E2=80=99t make server owners = happy. > =20 > I think it is a good idea to raise this issue in TLS WG. > =20 > Regards, > Valery. > =20 > =20 > =20 > From: Yoav Nir > Sent: 19 =D0=BD=D0=BE=D1=8F=D0=B1=D1=80=D1=8F 2016 =D0=B3. 7:21 > To: Tero Kivinen > Cc: ipsec@ietf.org WG ; Watson Ladd = > Subject: Re: [IPsec] Take a stand for key hygine > =20 > =20 > > On 18 Nov 2016, at 5:38, Tero Kivinen wrote: > > > > Watson Ladd writes: > >> I might be confused, but the slides in > >> = https://www.ietf.org/proceedings/97/slides/slides-97-ipsecme-signature-for= ms-ambiguity-in-ikev2-00.pdf > >> seem to very clearly want something else. Apologies for my > >> insufficient context inclusion. > > > > Yes, with RSA I think it might be quite common for people to use = same > > key for both RSA PKCS#1 v1.5 and RSA-PSS, and there is not really > > anything we can do for that. > =20 > If that is a problem, then it is more serious for TLS. TLS 1.2 has = only PKCS#1. TLS 1.3 has only PSS. So a server that uses a single = certificate with RSA for both versions (probably most servers in 1-2 = years) will be producing both kinds of signatures from the same key. > =20 > If that=E2=80=99s a problem, it should be raised during WGLC of TLS = 1.3 (which si now) > =20 > Yoav > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = --Apple-Mail=_6D3A2B0C-F80A-4048-8D21-943C6A63FCDC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Definitely won=E2=80=99t, but I first want to know if this is = actually a problem.

I=E2=80=99ll ask on the CFRG list.

Yoav

On = 19 Nov 2016, at 1:38, Valery Smyslov <svanru@gmail.com> = wrote:

Hi Yoav,
 
or the servers must be provided with two = certificates =E2=80=93 one for TLS 1.2
and the other for TLS 1.3, that won=E2=80=99t = make server owners happy.
 
I think it is a good idea to = raise this issue in TLS WG.
 
Regards,
Valery.
 
 
 
From: Yoav Nir
Sent: 19 = =D0=BD=D0=BE=D1=8F=D0=B1=D1=80=D1=8F 2016 =D0=B3. 7:21
To: Tero Kivinen
Cc: ipsec@ietf.org WG; Watson Ladd
Subject: Re: [IPsec] Take a = stand for key hygine
 
 
> On 18 Nov 2016, at 5:38, Tero Kivinen <kivinen@iki.fi> = wrote:
>
> Watson Ladd writes:
>> I might be confused, but the = slides in
>> https://www.ietf.org/proceedings/97/slides/slides-97-ipsecme-si= gnature-forms-ambiguity-in-ikev2-00.pdf
>> seem to very clearly want something else. Apologies = for my
>> insufficient = context inclusion.
>
> Yes, with RSA I = think it might be quite common for people to use same
> key for both RSA PKCS#1 v1.5 and = RSA-PSS, and there is not really
> anything we can do for that.
 
If that is a problem, then it is more serious for TLS. TLS = 1.2 has only PKCS#1. TLS 1.3 has only PSS.  So a server that uses a = single certificate with RSA for both versions (probably most servers in = 1-2 years) will be producing both kinds of signatures from the same = key.
 
If = that=E2=80=99s a problem, it should be raised during WGLC of TLS 1.3 = (which si now)
 
Yoav

_______________________________________________
IPsec mailing list
IPsec@ietf.org

= --Apple-Mail=_6D3A2B0C-F80A-4048-8D21-943C6A63FCDC-- From nobody Sun Nov 20 23:39:53 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D8B1293D6 for ; Sun, 20 Nov 2016 23:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 uyAx7MJny4Rb for ; Sun, 20 Nov 2016 23:39:50 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 A143D1295A5 for ; Sun, 20 Nov 2016 23:39:49 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tMgVB6vflz1jF; Mon, 21 Nov 2016 08:39:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1479713987; bh=0UcqXst0M4G+DkqQYWOyluDa0Tj++2uGohdfRiGsjuk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Vh12i3LFxGhukjsTUrUSzCqUC8QROcVidyXwrmNwpCF2M81I07oMJr8M0toWfYfrJ icMve8gR5x/e0Xl6eorTkW0B3/qmq8c0sUw/nk7l0fzcSaQBSCcoomCP2xzhAdWE7z FWXDyTonMOPM24VVTSDOrpMfEIq6amedHRtojXDE= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id EPILChHj3nIB; Mon, 21 Nov 2016 08:39:27 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 21 Nov 2016 08:39:27 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 3DC8C3797CE; Mon, 21 Nov 2016 02:39:25 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 3DC8C3797CE Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2329240D3581; Mon, 21 Nov 2016 02:39:25 -0500 (EST) Date: Mon, 21 Nov 2016 02:39:24 -0500 (EST) From: Paul Wouters To: Watson Ladd In-Reply-To: Message-ID: References: <27A96107-FEE5-4453-8321-4F3402E66590@gmail.com> <22574.30627.388793.378538@fireball.acr.fi> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org WG" , Yoav Nir , Tero Kivinen Subject: Re: [IPsec] Take a stand for key hygine X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 07:39:51 -0000 On Thu, 17 Nov 2016, Watson Ladd wrote: >> Yes, with RSA I think it might be quite common for people to use same >> key for both RSA PKCS#1 v1.5 and RSA-PSS, and there is not really >> anything we can do for that. >> >> On the other hand the interoperability issue we have now does not >> really care whether you have one or two RSA private keys, as long as >> initiator can use either RSA-PSS or RSA PKCS#1 v1.5, and do not know >> which one responder will accept. > > What about the approach of treating these as different authentication > methods? Or am I misunderstanding the scope of the problem? I'm not > that familiar with IKE2. The AUTH signature include data that is unique to each connection. For IKEv2, both sides generate a randomized SPI number that is included in the data to sign as well as a nonce. So an attacker would have to trick an endpoint in using one RSA version and then resend the IKE_AUTH packet to try and do the other RSA version. It's not allowed by protocol AFAIK. https://tools.ietf.org/html/rfc7296#section-2.15 So I don't think it is a concern, but I think we should indeed look at TLS as well, and agree on whether or not to use a context. Paul >> >> I think we might want to add text in the rfc4307bis saying that same >> key should not be used with both RSA-PSS and PKCS#1 v1.5. >> >> The rfc4307bis will be in IETF Last Call soon, so if you can read that >> and see what it says about the signature algorithms and see if there >> is something we need to add there, that would be great. > > I will look over it. >> -- >> kivinen@iki.fi > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Tue Nov 22 21:41:25 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39D3129458 for ; Tue, 22 Nov 2016 21:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 gnT0sx-Rr0Z9 for ; Tue, 22 Nov 2016 21:41:24 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 E201A129401 for ; Tue, 22 Nov 2016 21:41:23 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tNrmb4gQnzCFJ for ; Wed, 23 Nov 2016 06:41:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1479879679; bh=hLmG2AcuzlHzGkGuXtXqbDOckh21ikSvgIWqlgEIt7Q=; h=Date:From:To:Subject; b=qs4MlRYPazyl20Ts3xNIljMWbkZ5wa9h3fknGqy3eaujVIpogRdjbVzx5eNeOTrj+ 9n2CmoMs38qSIh2OVdrZEOPLm5H+QwxxXqkCO1RiuxKzUEl3vTNYXDls5dJpb2ibOV n/5J+OvAW6X8uBELzsDRv+mRbdX9A4VbBsBxZccE= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ZB3J4kVAny6v for ; Wed, 23 Nov 2016 06:41:17 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 23 Nov 2016 06:41:17 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 4712936FF3; Wed, 23 Nov 2016 00:41:16 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 4712936FF3 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 31E0740D3586 for ; Wed, 23 Nov 2016 00:41:16 -0500 (EST) Date: Wed, 23 Nov 2016 00:41:15 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] IKE and SCTP IPsec support (RFC3554) ? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 05:41:25 -0000 Has anyone done support for SCTP in IKEv2 ? (or even in IKEv1?) If so, how are the SA's negotiated? a matrix of src/dst addresses as seperate CREATE_CHILD_SA's ? Or multiple traffic selector payloads in a single CHILD SA? It seems IKEv1 ID_LIST is not present in IKEv2 anymore? Paul From nobody Wed Nov 23 05:24:54 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17071299E8 for ; Wed, 23 Nov 2016 05:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MV6G1Rj_Z_d1 for ; Wed, 23 Nov 2016 05:24:51 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 175C0129442 for ; Wed, 23 Nov 2016 05:24:50 -0800 (PST) X-AuditID: c1b4fb30-96c1b98000001942-3d-583598a18eea Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id 61.78.06466.1A895385; Wed, 23 Nov 2016 14:24:49 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.62]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0319.002; Wed, 23 Nov 2016 14:23:49 +0100 From: John Mattsson To: "ipsec@ietf.org" Thread-Topic: Updated 3GPP Profile for IKEv2 Thread-Index: AQHSRYzTEsOSDJ+NrU2UvErAk1emDQ== Date: Wed, 23 Nov 2016 13:23:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="utf-8" Content-ID: <81CDF3895237EB4AA2E2D72EB48553DF@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM2K7h+7CGaYRBjcXK1rs3/KCzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGVO/WRQsY6t4urKVuYFxAlsXIyeHhICJxJpJ71i6GLk4hATW MUpcWnSMFcJZzChxYcYMFpAqNgEDibl7GsA6RARUJU4tm84KYgsLqEvs+3odqIYDKK4jse6w EoSpJ9E3tRKkggWo+s6LrYwgNq+AuUT7xwlgExkFxCS+n1rDBGIzC4hL3HoynwniHgGJJXvO M0PYohIvH/9jBRkpCjRyzf0wEFNCQFFieb8ciMksoCmxfpc+xBBriZ0nZrJD2IoSU7ofskMs FZQ4OfMJywRGkVlIds1C6J6FpHsWku5ZSLoXMLKuYhQtTi1Oyk03MtJLLcpMLi7Oz9PLSy3Z xAiMg4NbfhvsYHz53PEQowAHoxIPb0GsSYQQa2JZcWXuIUYJDmYlEd5F00wjhHhTEiurUovy 44tKc1KLDzFKc7AoifOarbwfLiSQnliSmp2aWpBaBJNl4uCUamBM0+xZl6OTVlL6n3frl/2/ F/N77lC9wyP4NZEnfp7IGvmj1s7d3Sfi9y9SKOuobf4ov2xSF9vlFJ+LHtEf3Nttm+tiTb0D NY59WNFd4Xzy9sRnVTrpbgu0d3sUKDIk8cRNzTP7zjJx1Z2WG7NMr539+3CJt1PvXI09DQqZ 7/inWe1qLL31RUmJpTgj0VCLuag4EQCFb7pofwIAAA== Archived-At: Subject: [IPsec] Updated 3GPP Profile for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 13:24:53 -0000 SGksDQoNCkZZSSwgM0dQUCByZWNlbnRseSB1cGRhdGVkIGl0cyBJS0V2MiBwcm9maWxlLiBUaGUg Y3VycmVudCBwcm9maWxlcyBmb3INCklLRXYyIGFuZCBFU1AgbG9va3MgbGlrZSB0aGlzIChvbmx5 IHRoZSByZWxldmFudCBwYXJ0IG9mIDNHUFAgVFMgMzMuMjEwDQphbmQgVFMgMzMuMzEwKToNCg0K aHR0cHM6Ly93d3cuc2NyaWJkLmNvbS9kb2N1bWVudC8zMzIwNTc5ODQvM0dQUC1JUHNlYy1Qcm9m aWxlLU5vdi0yMDE2DQoNCg0KTWFpbiBjaGFuZ2VzIGFyZToNCg0KLSBTSEEtMSBzaWduYXR1cmVz IG9mIGFsbCBraW5kcyBhcmUgZm9yYmlkZGVuLg0KLSBEaWdpdGFsIFNpZ25hdHVyZXMgYW5kIEhh c2ggQWxnb3JpdGhtIE5vdGlmaWNhdGlvbiBbUkZDNzQyN10gYXJlDQptYW5kYXRvcnkgdG8gc3Vw cG9ydC4NCg0KQ29tbWVudHMgb2YgYW55IGtpbmQgZnJvbSB0aGUgSVBTRUNNRSBXRyBhcmUgdmVy eSB3ZWxjb21lLg0KDQpJIHdpbGwgZHJpdmUgYW5vdGhlciB1cGRhdGUgb2YgdGhlIDNHUFAgcHJv ZmlsZXMgYXMgc29vbiBhcyA0MzA3YmlzIGFuZA0KNzMyMWJpcyBhcmUgcHVibGlzaGVkLg0KDQpD aGVlcnMsDQpKb2huDQoNCg== From nobody Wed Nov 23 05:35:41 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D921712958E for ; Wed, 23 Nov 2016 05:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbhMOsKsKNSM for ; Wed, 23 Nov 2016 05:35:38 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 074CC129DC4 for ; Wed, 23 Nov 2016 05:35:37 -0800 (PST) X-AuditID: c1b4fb2d-0bbff70000000994-00-58359b271d23 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 6A.AA.02452.72B95385; Wed, 23 Nov 2016 14:35:36 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.62]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0319.002; Wed, 23 Nov 2016 14:35:35 +0100 From: John Mattsson To: "ipsec@ietf.org" Thread-Topic: SHA-1 signatures in IKEv2 Thread-Index: AQHSRY5455ve1NjVUkm/WXQ7UOSvAw== Date: Wed, 23 Nov 2016 13:35:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-ID: <360B3B6C33CB734A9B5C1DE1358FC5B7@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM2K7tK7GbNMIg39HZS32b3nB5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujN0HTjMWvGCteLf6OFMD4xXWLkZODgkBE4l1344D2VwcQgLr GCU6925kB0kICSxmlHjXpgViswkYSMzd08AGYosIqEqcWjYdrFlYQEli9uHVTBBxdYkpy9Yy Q9h6Es3/l7F0MXJwsADVd1/zBQnzCphLdP4+DFbCKCAm8f3UGrBWZgFxiVtP5jNB3CMgsWTP eWYIW1Ti5eN/rCBjRIFGrrkfBhFWlLg6fTkTSJhZQFNi/S59iCnWEt+uPWOGsBUlpnQ/ZIfY KihxcuYTlgmMIrOQLJuF0D0LSfcsJN2zkHQvYGRdxShanFpcnJtuZKyXWpSZXFycn6eXl1qy iREYCwe3/Nbdwbj6teMhRgEORiUe3oJYkwgh1sSy4srcQ4wSHMxKIryLpplGCPGmJFZWpRbl xxeV5qQWH2KU5mBREuc1W3k/XEggPbEkNTs1tSC1CCbLxMEp1cAoeph9YeUdFTszzU+PBT16 jCx7v5y+f2jaTB63Y+ydXMoWMy32Z2el3Hx0kTUhz2B30YuF5qcdinJPZ5l0NJyeIOWdkqv2 9vOz2phtjswKi522BZRpPz10pvm4k6zJ0wOMdUueyKy457/XcsL0+DaOnGith6n3Pruln8hJ ucQseOpHF1+2D68SS3FGoqEWc1FxIgBlTBpIgQIAAA== Archived-At: Subject: [IPsec] SHA-1 signatures in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 13:35:40 -0000 T25lIHF1ZXN0aW9uLCBjdXJyZW50bHkgU0hBLTEgc2lnbmF0dXJlIGFyZSBub3Qgb25seSBhbGxv d2VkIGJ5IFJGQzcyOTYsDQpidXQgZXZlbiAiU0hPVUxEIHVzZSBhcyBkZWZhdWx04oCdLiA0MzA3 YmlzIGRvZXMgbm90IGNoYW5nZSB0aGlzLiBTaG91bGRu4oCZdA0Kc29tZXRoaW5nIGJlIGRvbmUg YWJvdXQgdGhpcy4gUmlnaHQgbm93IChhbmQgZXZlbiB3aXRoIDQzMDdiaXMpOg0KDQpSU0FTU0Et UEtDUzEtdjEuNSB3aXRoIFNIQS0xIGlzIE1VU1Qgc3VwcG9ydCBhbmQgZXZlcnl0aGluZyBlbHNl DQooUFNTK1NIQS0yLCBFQ1NEQStTSEEtMikgaXMganVzdCBTSE9VTEQgKG5vdCBldmVuIFNIT1VM RCspIGFuZA0KUEtDUzEtdjEuNStTSEEtMiBpcyBNQVkuDQoNClRoaXMgZG9lcyBub3Qgc2VlbSBn b29kIGV2ZW4gc2hvcnQgdGVybS4uLiBGZWVscyBsaWtlIGF0IGEgbWluaW11bSwgc29tZQ0KYXV0 aGVudGljYXRpb24gbWV0aG9kIHdpdGggU0hBLTIgc2hvdWxkIGJlIG1hbmRhdG9yeSB0byBzdXBw b3J0Lg0KDQpDaGVlcnMsDQpKb2huDQoNCg0KDQo= From nobody Wed Nov 23 07:16:31 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2C8129A10 for ; Wed, 23 Nov 2016 07:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 bKGA4yujgWrA for ; Wed, 23 Nov 2016 07:16:29 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E655129A07 for ; Wed, 23 Nov 2016 07:16:28 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id uANFGP5m012777 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 23 Nov 2016 17:16:25 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uANFGPhR026081; Wed, 23 Nov 2016 17:16:25 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22581.45769.364015.455860@fireball.acr.fi> Date: Wed, 23 Nov 2016 17:16:25 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 16 min X-Total-Time: 11 min Archived-At: Cc: "ipsec@ietf.org WG" Subject: [IPsec] IKE and SCTP IPsec support (RFC3554) ? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 15:16:30 -0000 Paul Wouters writes: > Has anyone done support for SCTP in IKEv2 ? (or even in IKEv1?) > > If so, how are the SA's negotiated? a matrix of src/dst addresses > as seperate CREATE_CHILD_SA's ? Or multiple traffic selector payloads > in a single CHILD SA? > > It seems IKEv1 ID_LIST is not present in IKEv2 anymore? There is no need for ID_LIST, as traffic selector payload can have multiple traffic selectors in it, similarly what ID_LIST did. I.e., you can have each ip-addresses as separate traffic selector in traffic selector payload and create one Child SA for SCTP. If you need to add more addresses later, you can rekey the Child SA and add more traffic selectors to the same Child SA. You cannot remove IP-address in this way as section 2.9.2 says you MUST NOT propose narrower selectors when rekeying, so in that case you need to create new Child SA, and remove old one. -- kivinen@iki.fi From nobody Sun Nov 27 06:32:10 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F0912957F for ; Sun, 27 Nov 2016 06:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 AZgtFUWI3vc2 for ; Sun, 27 Nov 2016 06:32:08 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 22C1412957D for ; Sun, 27 Nov 2016 06:32:08 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tRXM94shHz35D; Sun, 27 Nov 2016 15:32:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1480257125; bh=pzdB4t8XtcW581A0/dA/S4W36QVAv2ccKU82EofXnW8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=LZmetILdoLzXRQQ2+0oKTAX+1YwDszOP48lTCjOoSzDh5x6uHM6xcv6kCF+hNbuKF 2OYrFsHTcP1+havLlz0fN7YuEAI3jyRDDhvdx2jCwTA8na3SNsnRmxXZ529vL6J8NS ocZAvW83zoAIP8hvN8+rv+LBgM4EDI7zk5TQUz2I= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id RCpp2dQLUV5i; Sun, 27 Nov 2016 15:32:04 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 27 Nov 2016 15:32:03 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6269B35296A; Sun, 27 Nov 2016 09:31:59 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 6269B35296A Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 489FF40C9783; Sun, 27 Nov 2016 09:31:59 -0500 (EST) Date: Sun, 27 Nov 2016 09:31:59 -0500 (EST) From: Paul Wouters To: John Mattsson In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] SHA-1 signatures in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2016 14:32:09 -0000 On Wed, 23 Nov 2016, John Mattsson wrote: > One question, currently SHA-1 signature are not only allowed by RFC7296, > but even "SHOULD use as default”. 4307bis does not change this. Shouldn’t > something be done about this. Right now (and even with 4307bis): >From Section 4 of the bis document: IKEv2 authentication may involve a signatures verification. Signatures may be used to validate a certificate or to check the signature of the AUTH value. Cryptographic recommendations regarding certificate validation are out of scope of this document. What is mandatory to implement is provided by the PKIX Community. This document is mostly concerned on signature verification and generation for the authentication. > RSASSA-PKCS1-v1.5 with SHA-1 is MUST support and everything else > (PSS+SHA-2, ECSDA+SHA-2) is just SHOULD (not even SHOULD+) and > PKCS1-v1.5+SHA-2 is MAY. Because we are hoping to obsolete everything for Digital Signatures as per RFC7427. We did not make that a SHOULD+ because it has not yet seen wide deployment. > This does not seem good even short term... Feels like at a minimum, some > authentication method with SHA-2 should be mandatory to support. Perhaps we should make it SHOULD+ and make RSA MUST- to make that more clear? But I'd like to hear from others before doing that. Paul From nobody Mon Nov 28 22:04:14 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FF5129533 for ; Mon, 28 Nov 2016 22:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-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 kcXY96rWH32O for ; Mon, 28 Nov 2016 22:04:11 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 35219129503 for ; Mon, 28 Nov 2016 22:04:11 -0800 (PST) Received: from thinny.local (69-12-173-8.static.dsltransport.net [69.12.173.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id F3B66A88811A for ; Mon, 28 Nov 2016 22:04:10 -0800 (PST) To: "ipsec@ietf.org" From: Dan Harkins Message-ID: <11dd40e1-93fe-d5d7-26de-02803c12f224@lounge.org> Date: Mon, 28 Nov 2016 22:04:09 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [IPsec] OIDs for IKE DH groups X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 06:04:12 -0000 Greetings, Are there defined OIDs for IKE DH groups 14 to 18 (from RFC 3526)? If so, does anyone know what they are? Thanks in advance, Dan.