From nobody Tue May 2 02:22:28 2017 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 A8B7612932A; Tue, 2 May 2017 02:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 LfdYg8NSTWsN; Tue, 2 May 2017 02:22:25 -0700 (PDT) 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 1E1D413150F; Tue, 2 May 2017 02:17:49 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v429He8W023627 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 2 May 2017 12:17:40 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v429Her7028745; Tue, 2 May 2017 12:17:40 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22792.20148.255067.132946@fireball.acr.fi> Date: Tue, 2 May 2017 12:17:40 +0300 From: Tero Kivinen To: Tommy Pauly Cc: Spencer Dawkins at IETF , Eric Rescorla , ipsecme-chairs@ietf.org, IPsecME WG , Mirja Kuehlewind , The IESG , draft-ietf-ipsecme-tcp-encaps@ietf.org In-Reply-To: <853700CB-D5DD-4BC7-A1F5-5AB61330E70D@apple.com> References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> <22785.64570.259658.376130@fireball.acr.fi> <277aa94d-5aa1-7a28-94c7-81da0966c172@kuehlewind.net> <41594727-9667-42BD-ABB1-4583A3B00EA2@apple.com> <853700CB-D5DD-4BC7-A1F5-5AB61330E70D@apple.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 6 min Archived-At: Subject: Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 09:22:27 -0000 Tommy Pauly writes: > I'll defer to Tero on this one. Tero, what do you prefer to do with the IANA > Considerations text? [Note, that I am just talking as individual here, these IANA actions do not relate the IKEv2 registries where I am IANA Expert] I proposed to change both the UDP and TCP references for the port 4500, as even if the RFC3947 did do the IANA actions, it does not describe the protocol used on the port. RFC3948 and 7296 does. So from my previous email I would suggest following text: ---------------------------------------------------------------------- 14. IANA Considerations This memo includes no request to IANA. TCP port 4500 is already allocated to IPsec for NAT Traversal. This port SHOULD be used for TCP encapsulated IKE and ESP as described in this document. This document updates both TCP and UDP references of the port 4500 to match the current protocols used on those ports: Keyword Decimal Description Reference ------- ------- ----------- --------- ipsec-nat-t 4500/tcp IPsec NAT-Traversal [RFC-this-rfc] ipsec-nat-t 4500/udp IPsec NAT-Traversal [RFC3948], [RFC7296] -- kivinen@iki.fi From nobody Tue May 2 03:12:30 2017 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 674A012EBAD for ; Tue, 2 May 2017 03:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00g1xQyEHo0l for ; Tue, 2 May 2017 03:12:27 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4F28131449 for ; Tue, 2 May 2017 03:08:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=IJmtwIee1WwIe/EOc2Gr/VMIQr4KeNnFgEsw/V4i0EUw6iKLJZlFZIt+RIQeOmxcAYgallc+zdP7amsNhJGUH0tl6yKvaqbo/jgCPnNob1kG/mJQPFkryXubbDJhBAq6G5KlaxWG82wIJ7ySzq5HMIniX1FncH3L9kBneBotRgA=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 25882 invoked from network); 2 May 2017 12:01:35 +0200 Received: from p5dec2bdc.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.43.220) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 2 May 2017 12:01:35 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <22792.20148.255067.132946@fireball.acr.fi> Date: Tue, 2 May 2017 12:01:32 +0200 Cc: Tommy Pauly , Spencer Dawkins at IETF , Eric Rescorla , ipsecme-chairs@ietf.org, IPsecME WG , The IESG , draft-ietf-ipsecme-tcp-encaps@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <82B5E72F-C518-420B-B941-E4CE4DD1BF87@kuehlewind.net> References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> <22785.64570.259658.376130@fireball.acr.fi> <277aa94d-5aa1-7a28-94c7-81da0966c172@kuehlewind.net> <41594727-9667-42BD-ABB1-4583A3B00EA2@apple.com> <853700CB-D5DD-4BC7-A1F5-5AB61330E70D@apple.com> <22792.20148.255067.132946@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170502100135.25871.96870@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 10:12:28 -0000 Hi all, so first updating is a request to IANA, so you have to remove the first = sentence. Then the update of the UPD port should probably be done in a = separate document that potentially also obsoletes 3947 if that was = missed with 7296. Mirja > Am 02.05.2017 um 11:17 schrieb Tero Kivinen : >=20 > Tommy Pauly writes: >> I'll defer to Tero on this one. Tero, what do you prefer to do with = the IANA >> Considerations text? >=20 > [Note, that I am just talking as individual here, these IANA actions > do not relate the IKEv2 registries where I am IANA Expert] >=20 > I proposed to change both the UDP and TCP references for the port > 4500, as even if the RFC3947 did do the IANA actions, it does not > describe the protocol used on the port. RFC3948 and 7296 does. >=20 > So from my previous email I would suggest following text: >=20 > ---------------------------------------------------------------------- > 14. IANA Considerations >=20 > This memo includes no request to IANA. >=20 > TCP port 4500 is already allocated to IPsec for NAT Traversal. > This port SHOULD be used for TCP encapsulated IKE and ESP as > described in this document. >=20 > This document updates both TCP and UDP references of the port 4500 > to match the current protocols used on those ports: >=20 > Keyword Decimal Description Reference > ------- ------- ----------- --------- > ipsec-nat-t 4500/tcp IPsec NAT-Traversal [RFC-this-rfc] > ipsec-nat-t 4500/udp IPsec NAT-Traversal [RFC3948], [RFC7296] >=20 > --=20 > kivinen@iki.fi From nobody Tue May 2 05:28:07 2017 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 F06091314C2; Tue, 2 May 2017 05:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.279 X-Spam-Level: X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 Sc0hFXDeHLcB; Tue, 2 May 2017 05:27:57 -0700 (PDT) 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 35A07131686; Tue, 2 May 2017 05:24:56 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v42COp9v017590 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 2 May 2017 15:24:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v42COoZA015048; Tue, 2 May 2017 15:24:50 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22792.31378.769444.232365@fireball.acr.fi> Date: Tue, 2 May 2017 15:24:50 +0300 From: Tero Kivinen To: "Mirja Kuehlewind \(IETF\)" Cc: Tommy Pauly , Spencer Dawkins at IETF , Eric Rescorla , ipsecme-chairs@ietf.org, IPsecME WG , The IESG , draft-ietf-ipsecme-tcp-encaps@ietf.org In-Reply-To: <82B5E72F-C518-420B-B941-E4CE4DD1BF87@kuehlewind.net> References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> <22785.64570.259658.376130@fireball.acr.fi> <277aa94d-5aa1-7a28-94c7-81da0966c172@kuehlewind.net> <41594727-9667-42BD-ABB1-4583A3B00EA2@apple.com> <853700CB-D5DD-4BC7-A1F5-5AB61330E70D@apple.com> <22792.20148.255067.132946@fireball.acr.fi> <82B5E72F-C518-420B-B941-E4CE4DD1BF87@kuehlewind.net> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 8 min Archived-At: Subject: Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 12:27:59 -0000 Mirja Kuehlewind (IETF) writes: > so first updating is a request to IANA, so you have to remove the > first sentence. Agreed, forgot to remove that. > Then the update of the UPD port should probably be done in a > separate document that potentially also obsoletes 3947 if that was > missed with 7296. No point of doing that. Publishing 1 page document doing IANA updates is just stupid and does not help anybody. If it cannot be done here, we can leave it as it is now, and I talk to IANA and change this thing separately. As this is clearly a error in the IANA registry, they have fixed this kind of mistakes before without any need for documents especially when registry is not RFC required or similar. They do like to get document requests just for keeping track of changes, and thats why I think it would be better to combine the changes in this document, as we are going to change the TCP/4500 anyways, and fixing the UDP/4500 references at the same time would be easy. And yes, RFC7296 did forget to obsolete RFC3947, but this is not the document do that, and thats why I did not suggest this to do anything like that. I suggested just fixing the reference from the RFC3947 to RFC3948, as RFC3948 actually describes the protocol used over the port 4500. RFC3947 does not specify the protocol for port UDP/4500, it just refers to the RFC3948 for protocol details. Adding RFC7296 would be good, as it provides latest information about the IKE interactions for the RFC3948 (i.e., 7296 still uses 3948 defined protocol, but replaces the non port 4500 related details which were in the 3947). This is just to make sure the people reading the RFC3948 also gets pointer to the IKE parts of the protocol (as RFC4306/5996/7296 forgot to obsolete 3947). -- kivinen@iki.fi From nobody Tue May 2 06:31:59 2017 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 7D5A8131580 for ; Tue, 2 May 2017 06:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-3KIMqNmqsp for ; Tue, 2 May 2017 06:31:51 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02200131569 for ; Tue, 2 May 2017 06:27:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=YxxlLT6ng8OckeXiQ3vGPduLyoCvaWja7j0E1+4JC6bUcuKGKp2REXLa9OG5gKA+3oifi1UnSsXr4TOUTqfhWgXoYvg5PkvgkXeWY7Wpyow9WnwC5ELa/PbuIjYLPd5SLJHvTlP2219p8cOA90Opx4KQpkoEBTcyJZENYctgofA=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 15387 invoked from network); 2 May 2017 15:27:25 +0200 Received: from p5dec2bdc.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.43.220) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 2 May 2017 15:27:25 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <22792.31378.769444.232365@fireball.acr.fi> Date: Tue, 2 May 2017 15:27:23 +0200 Cc: ipsecme-chairs@ietf.org, Eric Rescorla , IPsecME WG , Spencer Dawkins at IETF , draft-ietf-ipsecme-tcp-encaps@ietf.org, Tommy Pauly , The IESG Content-Transfer-Encoding: quoted-printable Message-Id: <78A72CF3-E011-4E8D-9F66-63C7918A8236@kuehlewind.net> References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> <22785.64570.259658.376130@fireball.acr.fi> <277aa94d-5aa1-7a28-94c7-81da0966c172@kuehlewind.net> <41594727-9667-42BD-ABB1-4583A3B00EA2@apple.com> <853700CB-D5DD-4BC7-A1F5-5AB61330E70D@apple.com> <22792.20148.255067.132946@fireball.acr.fi> <82B5E72F-C518-420B-B941-E4CE4DD1BF87@kuehlewind.net> <22792.31378.769444.232365@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170502132725.15376.51347@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 13:31:52 -0000 Hi Tero, my thinking was that the main problem is that 3947 was not obsoleted and = I=E2=80=99m assuming we need a document to fix that. In this case that = document could/should also fix the IANA entry for the UDP port. However, = I=E2=80=99m actually not sure what the right processing would be to fix = this forgotten obsolete=E2=80=A6 maybe other ADs know better=E2=80=A6? Otherwise if you don=E2=80=99t want to do this, I don=E2=80=99t think = it=E2=80=99s a good idea to merge kind of unrelated fixes into this = spec. We can also fix that by using the IESG approval process (see = RFC5226). I think that=E2=80=99s the better option! Mirja > Am 02.05.2017 um 14:24 schrieb Tero Kivinen : >=20 > Mirja Kuehlewind (IETF) writes: >> so first updating is a request to IANA, so you have to remove the >> first sentence. >=20 > Agreed, forgot to remove that.=20 >=20 >> Then the update of the UPD port should probably be done in a >> separate document that potentially also obsoletes 3947 if that was >> missed with 7296. >=20 > No point of doing that. Publishing 1 page document doing IANA updates > is just stupid and does not help anybody. If it cannot be done here, > we can leave it as it is now, and I talk to IANA and change this thing > separately. As this is clearly a error in the IANA registry, they have > fixed this kind of mistakes before without any need for documents > especially when registry is not RFC required or similar. They do like > to get document requests just for keeping track of changes, and thats > why I think it would be better to combine the changes in this > document, as we are going to change the TCP/4500 anyways, and fixing > the UDP/4500 references at the same time would be easy. >=20 > And yes, RFC7296 did forget to obsolete RFC3947, but this is not the > document do that, and thats why I did not suggest this to do anything > like that. I suggested just fixing the reference from the RFC3947 to > RFC3948, as RFC3948 actually describes the protocol used over the port > 4500. RFC3947 does not specify the protocol for port UDP/4500, it just > refers to the RFC3948 for protocol details. Adding RFC7296 would be > good, as it provides latest information about the IKE interactions for > the RFC3948 (i.e., 7296 still uses 3948 defined protocol, but replaces > the non port 4500 related details which were in the 3947). This is > just to make sure the people reading the RFC3948 also gets pointer to > the IKE parts of the protocol (as RFC4306/5996/7296 forgot to obsolete > 3947).=20 > --=20 > kivinen@iki.fi >=20 From nobody Tue May 2 15:00:17 2017 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 59A5C12EB46 for ; Tue, 2 May 2017 15:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 VFCljbZYn2BP for ; Tue, 2 May 2017 15:00:13 -0700 (PDT) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD4A129C07 for ; Tue, 2 May 2017 14:57:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 56C5B2116; Tue, 2 May 2017 23:57:20 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id s-3JTck83INs; Tue, 2 May 2017 23:57:20 +0200 (CEST) Received: from [192.168.1.6] (104.red-83-40-108.dynamicip.rima-tde.net [83.40.108.104]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon23.um.es (Postfix) with ESMTPSA id 5DA6D204C; Tue, 2 May 2017 23:57:17 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_2F31010F-39BA-412C-AD60-70C3720A94F9"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Pgp-Agent: GPGMail From: Gabriel Lopez Date: Tue, 2 May 2017 23:57:15 +0200 Cc: Rafa Marin Lopez Message-Id: <3BB2892A-1B7E-40D7-A434-C85D52A4C9F6@um.es> References: <20170502232900.Horde.WZFXdHhx4M0yKP1D7Qh-Wg7@webmail.um.es> To: IPsec@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [IPsec] Fwd: [I2nsf] New Version Notification for draft-abad-i2nsf-sdn-ipsec-flow-protection-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 22:00:16 -0000 --Apple-Mail=_2F31010F-39BA-412C-AD60-70C3720A94F9 Content-Type: multipart/alternative; boundary="Apple-Mail=_51906915-CDB4-490E-A097-2C6916E7494C" --Apple-Mail=_51906915-CDB4-490E-A097-2C6916E7494C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, We have uploaded a new version of the draft Software-Defined Networking = (SDN)-based IPsec Flow Protection (v02). Comments are welcome!. Best regards, Gabi. > Inicio del mensaje reenviado: >=20 > De: GABRIEL LOPEZ MILLAN > Asunto: [I2nsf] Fwd: New Version Notification for = draft-abad-i2nsf-sdn-ipsec-flow-protection-02.txt > Fecha: 2 de mayo de 2017, 23:29:00 CEST > Para: i2nsf@ietf.org > Cc: rafa@um.es, i-d-announce@ietf.org >=20 >=20 > Hi all, >=20 > We have uploaded a new version of the i2nsf-sdn-ipsec-flow-protection. = We have reviewed the main sections and added a first draft of a Yang = model for IPsec management. >=20 > Comments are welcome. >=20 > Regards, Gabi. >=20 > ----- Mensaje reenviado de internet-drafts@ietf.org = ----- > Fecha: Tue, 02 May 2017 09:01:12 -0700 > De: internet-drafts@ietf.org > Asunto: New Version Notification for = draft-abad-i2nsf-sdn-ipsec-flow-protection-02.txt > Para: Rafa Marin-Lopez >, Rafael = Lopez >, Gabriel Lopez-Millan = > >=20 > A new version of I-D, = draft-abad-i2nsf-sdn-ipsec-flow-protection-02.txt > has been successfully submitted by Rafa Marin-Lopez and posted to the > IETF repository. >=20 > Name: draft-abad-i2nsf-sdn-ipsec-flow-protection > Revision: 02 > Title: Software-Defined Networking (SDN)-based IPsec = Flow Protection > Document date: 2017-05-02 > Group: Individual Submission > Pages: 45 > URL: = https://www.ietf.org/internet-drafts/draft-abad-i2nsf-sdn-ipsec-flow-prote= ction-02.txt = > Status: = https://datatracker.ietf.org/doc/draft-abad-i2nsf-sdn-ipsec-flow-protectio= n/ = > Htmlized: = https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-02 = > Htmlized: = https://datatracker.ietf.org/doc/html/draft-abad-i2nsf-sdn-ipsec-flow-prot= ection-02 = > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-abad-i2nsf-sdn-ipsec-flow-protec= tion-02 = >=20 > Abstract: > This document describes the use case of providing IPsec-based flow > protection by means of a Software-Defined Network (SDN) controller > (aka. Security Controller) and establishes the requirements to > support this service. It considers two main well-known scenarios = in > IPsec: (i) gateway-to-gateway and (ii) host-to-host. This document > describes a mechanism based on the SDN paradigm to support the > distribution and monitoring of IPsec information from a SDN > controller to one or several flow-based Network Security Function > (NSF). The NSFs implement IPsec to protect data traffic between > network resources with IPsec. >=20 > The document focuses in the NSF Facing Interface by providing = models > for Configuration and State data model required to allow the = Security > Controller to configure the IPsec databases (SPD, SAD, PAD) and IKE > to establish security associations with a reduced intervention of = the > network administrator. NOTE: State data model will be developed as > part of this work but it is still TBD. >=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 > ----- Terminar mensaje reenviado ----- >=20 > De: internet-drafts@ietf.org > Asunto: New Version Notification for = draft-abad-i2nsf-sdn-ipsec-flow-protection-02.txt > Fecha: 2 de mayo de 2017, 18:01:12 CEST > Para: "Rafa Marin-Lopez" , "Rafael Lopez" , = "Gabriel Lopez-Millan" >=20 >=20 >=20 > A new version of I-D, = draft-abad-i2nsf-sdn-ipsec-flow-protection-02.txt > has been successfully submitted by Rafa Marin-Lopez and posted to the > IETF repository. >=20 > Name: draft-abad-i2nsf-sdn-ipsec-flow-protection > Revision: 02 > Title: Software-Defined Networking (SDN)-based IPsec = Flow Protection > Document date: 2017-05-02 > Group: Individual Submission > Pages: 45 > URL: = https://www.ietf.org/internet-drafts/draft-abad-i2nsf-sdn-ipsec-flow-prote= ction-02.txt > Status: = https://datatracker.ietf.org/doc/draft-abad-i2nsf-sdn-ipsec-flow-protectio= n/ > Htmlized: = https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-02 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-abad-i2nsf-sdn-ipsec-flow-prot= ection-02 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-abad-i2nsf-sdn-ipsec-flow-protec= tion-02 >=20 > Abstract: > This document describes the use case of providing IPsec-based flow > protection by means of a Software-Defined Network (SDN) controller > (aka. Security Controller) and establishes the requirements to > support this service. It considers two main well-known scenarios in > IPsec: (i) gateway-to-gateway and (ii) host-to-host. This document > describes a mechanism based on the SDN paradigm to support the > distribution and monitoring of IPsec information from a SDN > controller to one or several flow-based Network Security Function > (NSF). The NSFs implement IPsec to protect data traffic between > network resources with IPsec. >=20 > The document focuses in the NSF Facing Interface by providing models > for Configuration and State data model required to allow the = Security > Controller to configure the IPsec databases (SPD, SAD, PAD) and IKE > to establish security associations with a reduced intervention of = the > network administrator. NOTE: State data model will be developed as > part of this work but it is still TBD. >=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 >=20 >=20 > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf ----------------------------------------------------------- Gabriel L=C3=B3pez Mill=C3=A1n Departamento de Ingenier=C3=ADa de la Informaci=C3=B3n y las = Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es --Apple-Mail=_51906915-CDB4-490E-A097-2C6916E7494C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Dear all, 

We have uploaded a new = version of the draft Software-Defined Networking (SDN)-based IPsec Flow Protection = (v02).
Comments are welcome!.

Best regards, = Gabi.

Inicio del mensaje = reenviado:

De: GABRIEL LOPEZ MILLAN <gabilm@um.es>
Asunto: = [I2nsf] Fwd: New = Version Notification for = draft-abad-i2nsf-sdn-ipsec-flow-protection-02.txt
Fecha: = 2 de mayo de 2017, 23:29:00 = CEST
Para: = i2nsf@ietf.org
Cc: rafa@um.es, i-d-announce@ietf.org


Hi all,

We have uploaded a new version of the i2nsf-sdn-ipsec-flow-protection. = We have reviewed the main sections and added a first draft of a Yang = model for IPsec management.

Comments are welcome.

Regards, Gabi.

----- Mensaje reenviado de internet-drafts@ietf.org -----
Fecha: Tue, 02 May 2017 09:01:12 -0700
    De: internet-drafts@ietf.org
Asunto: New Version Notification for = draft-abad-i2nsf-sdn-ipsec-flow-protection-02.txt
  Para: Rafa Marin-Lopez <rafa@um.es>, Rafael Lopez <rafa@um.es>, Gabriel = Lopez-Millan <gabilm@um.es>

A new version of I-D, = draft-abad-i2nsf-sdn-ipsec-flow-protection-02.txt
has been successfully submitted by Rafa Marin-Lopez and posted to the
IETF repository.

Name:                = draft-abad-i2nsf-sdn-ipsec-flow-protection
Revision:        02
Title:                = Software-Defined Networking (SDN)-based IPsec Flow Protection
Document date:        2017-05-02
Group:                Individual = Submission
Pages:                45
URL:            https://www.ietf.org/internet-drafts/draft-abad-i2nsf-sdn-ipsec= -flow-protection-02.txt
Status:         https://datatracker.ietf.org/doc/draft-abad-i2nsf-sdn-ipsec-flo= w-protection/
Htmlized:       https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-pro= tection-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-abad-i2nsf-sdn-ipse= c-flow-protection-02
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-abad-i2nsf-sdn-ipsec-= flow-protection-02

Abstract:
   This document describes the use case of providing = IPsec-based flow
   protection by means of a Software-Defined Network (SDN) = controller
   (aka.  Security Controller) and establishes the = requirements to
   support this service.  It considers two main = well-known scenarios in
   IPsec: (i) gateway-to-gateway and (ii) host-to-host.  = This document
   describes a mechanism based on the SDN paradigm to support = the
   distribution and monitoring of IPsec information from a = SDN
   controller to one or several flow-based Network Security = Function
   (NSF).  The NSFs implement IPsec to protect data = traffic between
   network resources with IPsec.

   The document focuses in the NSF Facing Interface by = providing models
   for Configuration and State data model required to allow = the Security
   Controller to configure the IPsec databases (SPD, SAD, PAD) = and IKE
   to establish security associations with a reduced = intervention of the
   network administrator.  NOTE: State data model will be = developed as
   part of this work but it is still TBD.




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

----- Terminar mensaje reenviado -----

De: = internet-drafts@ietf.org
Asunto: = New Version = Notification for = draft-abad-i2nsf-sdn-ipsec-flow-protection-02.txt
Fecha: 2 = de mayo de 2017, 18:01:12 CEST
Para: = "Rafa Marin-Lopez" <rafa@um.es>, "Rafael Lopez" = <rafa@um.es>, = "Gabriel Lopez-Millan" <gabilm@um.es>



A new version of I-D, = draft-abad-i2nsf-sdn-ipsec-flow-protection-02.txt
has been = successfully submitted by Rafa Marin-Lopez and posted to the
IETF repository.

Name: = draft-abad-i2nsf-sdn-ipsec-flow-protection
Revision: 02
Title: = Software-Defined Networking (SDN)-based IPsec Flow Protection
Document date: 2017-05-02
Group:= = Individual Submission
Pages: 45
URL: =            https://www.ietf.org/internet-drafts/draft-abad-i2nsf-sdn-ipsec= -flow-protection-02.txt
Status: =         https://datatracker.ietf.org/doc/draft-abad-i2nsf-sdn-ipsec-flo= w-protection/
Htmlized: =       https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-pro= tection-02
Htmlized: =       https://datatracker.ietf.org/doc/html/draft-abad-i2nsf-sdn-ipse= c-flow-protection-02
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-abad-i2nsf-sdn-ipsec-= flow-protection-02

Abstract:
  This document describes the use case of = providing IPsec-based flow
  protection by = means of a Software-Defined Network (SDN) controller
=   (aka.  Security Controller) and establishes the = requirements to
  support this service. =  It considers two main well-known scenarios in
=   IPsec: (i) gateway-to-gateway and (ii) host-to-host. =  This document
  describes a mechanism = based on the SDN paradigm to support the
=   distribution and monitoring of IPsec information from a = SDN
  controller to one or several flow-based = Network Security Function
  (NSF).  The = NSFs implement IPsec to protect data traffic between
=   network resources with IPsec.

=   The document focuses in the NSF Facing Interface by = providing models
  for Configuration and State = data model required to allow the Security
=   Controller to configure the IPsec databases (SPD, SAD, PAD) = and IKE
  to establish security associations = with a reduced intervention of the
  network = administrator.  NOTE: State data model will be developed as
  part of this work but it is still TBD.




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



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



-----------------------------------------------------------
Gabriel L=C3=B3pez Mill=C3=A1n
Departamento de = Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones
University of Murcia
Spain
Tel: = +34 868888504
Fax: +34 868884151
email: gabilm@um.es




= --Apple-Mail=_51906915-CDB4-490E-A097-2C6916E7494C-- --Apple-Mail=_2F31010F-39BA-412C-AD60-70C3720A94F9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJZCQC8AAoJEMUYqoSNEZFTjBcH/2PF7stCLXQBTTj9Yk8+SycN zzoqoY4FjObJyZek27dL+oOKubTA1EQ6vjBdKUR08r+qkoDal+2B5NO8FegiyqKy 04PK79cKCvFbQ1nnMCeGccxkGor2toe5IP3AnFvmfkUifNMaucqTVQsunddPBULj AzSDjeBMOykDOzqy/EAOCrsWGi+jQH2Lz2Weu0e5PD0T66oWUqNRRsh8ObcPolnS zlUfbAVw9okKcwfu5NrAJSssYsL+yheJ2OEgHHO4AOBxP/rmo7SecvW8M8hrrxyn kibDFSIjtulWZAkSMxb9XIuCYbthx/E527mJaF4fNmPx0rMKtQVFXmiwU/bx+vA= =v1lC -----END PGP SIGNATURE----- --Apple-Mail=_2F31010F-39BA-412C-AD60-70C3720A94F9-- From nobody Wed May 3 02:15:19 2017 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 82E22129479; Wed, 3 May 2017 02:15:18 -0700 (PDT) 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 RUZLdgawzLAn; Wed, 3 May 2017 02:15:16 -0700 (PDT) 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 352AF12955F; Wed, 3 May 2017 02:12:42 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v439Caet007016 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 3 May 2017 12:12:36 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v439CZF3022224; Wed, 3 May 2017 12:12:35 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22793.40707.624092.66793@fireball.acr.fi> Date: Wed, 3 May 2017 12:12:35 +0300 From: Tero Kivinen To: "Mirja Kuehlewind \(IETF\)" Cc: ipsecme-chairs@ietf.org, Eric Rescorla , IPsecME WG , Spencer Dawkins at IETF , draft-ietf-ipsecme-tcp-encaps@ietf.org, Tommy Pauly , The IESG In-Reply-To: <78A72CF3-E011-4E8D-9F66-63C7918A8236@kuehlewind.net> References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> <22785.64570.259658.376130@fireball.acr.fi> <277aa94d-5aa1-7a28-94c7-81da0966c172@kuehlewind.net> <41594727-9667-42BD-ABB1-4583A3B00EA2@apple.com> <853700CB-D5DD-4BC7-A1F5-5AB61330E70D@apple.com> <22792.20148.255067.132946@fireball.acr.fi> <82B5E72F-C518-420B-B941-E4CE4DD1BF87@kuehlewind.net> <22792.31378.769444.232365@fireball.acr.fi> <78A72CF3-E011-4E8D-9F66-63C7918A8236@kuehlewind.net> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 14 min Archived-At: Subject: Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 09:15:19 -0000 Mirja Kuehlewind (IETF) writes: > my thinking was that the main problem is that 3947 was not obsoleted > and I=E2=80=99m assuming we need a document to fix that. This is partly issue, but it is not issue we need to solve here, as this document is not something that should obsolete 3947. Also 3947 only defines extension for the IKEv1 (RFC2409) and that is already obsoleted, so effectively RFC3947 is already obsoleted, as there is no way to implement 3947 without implementing obsoleted protocol... This issue is not not important enough to require RFC now. > In this case that document could/should also fix the IANA entry for > the UDP port. However, I=E2=80=99m actually not sure what the right > processing would be to fix this forgotten obsolete=E2=80=A6 maybe oth= er ADs > know better=E2=80=A6=3F For now I would just leave it as it is, but fix the references in the IANA registry so that document will not be referenced, especially as the original IANA reference was not to the correct RFC in the first place.=20 > Otherwise if you don=E2=80=99t want to do this, I don=E2=80=99t think= it=E2=80=99s a good > idea to merge kind of unrelated fixes into this spec. We can also > fix that by using the IESG approval process (see RFC5226). I think > that=E2=80=99s the better option! That is true, but as this document already modifies the TCP/4500 reference, fixing the UDP/4500 reference at the same time is not completely unrelated fix.=20 Obsoleting RFC3947 would be unrelated fix.=20 --=20 kivinen@iki.fi From nobody Wed May 3 04:03:59 2017 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 76EC112948D for ; Wed, 3 May 2017 04:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jf4G3yuEq2VW for ; Wed, 3 May 2017 04:03:57 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA2512878D for ; Wed, 3 May 2017 04:01:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=clAZ4JIPmbpo6R3wdzMK/ZU1dTDDT5jw1M7id/WGdc7Te2XGrD5GJXC52wm1JsKstiU6zs2jYb8RJ/wGREMvKgVVXUGjYL2PpiCxvxPlJVFW/JRFJCs2FKoi8eL5UmYofkE9yZt9MwgEwhZKc69+gohuHAqP05fHy90qL72Cnqo=; h=Received:Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 31881 invoked from network); 3 May 2017 12:54:42 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 3 May 2017 12:54:42 +0200 To: Tero Kivinen References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> <22785.64570.259658.376130@fireball.acr.fi> <277aa94d-5aa1-7a28-94c7-81da0966c172@kuehlewind.net> <41594727-9667-42BD-ABB1-4583A3B00EA2@apple.com> <853700CB-D5DD-4BC7-A1F5-5AB61330E70D@apple.com> <22792.20148.255067.132946@fireball.acr.fi> <82B5E72F-C518-420B-B941-E4CE4DD1BF87@kuehlewind.net> <22792.31378.769444.232365@fireball.acr.fi> <78A72CF3-E011-4E8D-9F66-63C7918A8236@kuehlewind.net> <22793.40707.624092.66793@fireball.acr.fi> Cc: ipsecme-chairs@ietf.org, Eric Rescorla , IPsecME WG , Spencer Dawkins at IETF , draft-ietf-ipsecme-tcp-encaps@ietf.org, Tommy Pauly , The IESG From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: Date: Wed, 3 May 2017 12:54:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <22793.40707.624092.66793@fireball.acr.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <20170503105442.31870.17949@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 11:03:57 -0000 I didn't propose to obsolete RFC3947 in this document. I guess you can also file an error for this if you don't want to take any further actions. However, for updating the IANA registry, I would say the right action is to do this simply by IESG approval for UDP then. Mirja On 03.05.2017 11:12, Tero Kivinen wrote: > Mirja Kuehlewind (IETF) writes: >> my thinking was that the main problem is that 3947 was not obsoleted >> and I’m assuming we need a document to fix that. > > This is partly issue, but it is not issue we need to solve here, as > this document is not something that should obsolete 3947. > > Also 3947 only defines extension for the IKEv1 (RFC2409) and that is > already obsoleted, so effectively RFC3947 is already obsoleted, as > there is no way to implement 3947 without implementing obsoleted > protocol... > > This issue is not not important enough to require RFC now. > >> In this case that document could/should also fix the IANA entry for >> the UDP port. However, I’m actually not sure what the right >> processing would be to fix this forgotten obsolete… maybe other ADs >> know better…? > > For now I would just leave it as it is, but fix the references in the > IANA registry so that document will not be referenced, especially as > the original IANA reference was not to the correct RFC in the first > place. > >> Otherwise if you don’t want to do this, I don’t think it’s a good >> idea to merge kind of unrelated fixes into this spec. We can also >> fix that by using the IESG approval process (see RFC5226). I think >> that’s the better option! > > That is true, but as this document already modifies the TCP/4500 > reference, fixing the UDP/4500 reference at the same time is not > completely unrelated fix. > > Obsoleting RFC3947 would be unrelated fix. > From nobody Wed May 3 06:14:31 2017 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 95A3612871F; Wed, 3 May 2017 06:14:22 -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 AtGel8d6c8ib; Wed, 3 May 2017 06:14:21 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DEBB129B34; Wed, 3 May 2017 06:11:39 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id u70so84560935ywe.2; Wed, 03 May 2017 06:11:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HxemSsJu2cAiBVMBsws1uqwRQ2knDRRfQeBKA6Iea30=; b=SPYMbcL3YPv7rifHtOHEG1ZE8VmDNAXjTozeTOlTnlfV75jlG2BvM6QfK/RR1JvwWW ht8zU9OaD2Gagy25ozbNpN3l7DMwOf6ohfDRqS6WYxdbEU1E9rde4YdeNN6AawZZmJuh TiBaj0zljWp9wt99jXCPFtfsiiA9G7KDxPzEDFJoC4c3X+fJ0cRlYoOgOanzGEDxUB30 9RVyznB8cZeBOqBSve2ce7h/OAB2ZnrccuRvkPcgvt7uoGkAfgwMHlC5G/9MwElLhFXa cL5m+R2/6uh9UHU7wifjYewtOPvawxRaJZc52yyuldDiB4JUyql8QO49oHfxg4Qhhlr/ buBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HxemSsJu2cAiBVMBsws1uqwRQ2knDRRfQeBKA6Iea30=; b=tKRDS0zqXtCZa1bKuJCYfjwfsmv1a2iH553KMP8H2Jh993auYolv2+MyQzgPqptrkm sSIBprA77HS+VT1O9eaP8ZzSYqRa0/iE0jOxJCqtANm9cThzgjXsPdqcaInwLn0zwUQ1 h8TJMs1SEJhBz1tYgn8wYVifu3IawT0HSaHrF08r5Mdof+iBXbvhdnVdp0evqOGNAu1T EcjeTI8O10RyCYBRrwlAlKp4UojPTZUP6daiuRYOcsHetYo6lO4aMfZyH/4s4c9utWjH nAqJGygQfSelA7ub8AsWvVDqoCsGGVcDNQEQRUoZSswFD3aYl70rC1pqfQPjedh8jlp9 OzLg== X-Gm-Message-State: AN3rC/6xveJ4hO0elIjqEW0S7GV7qi4vfWD4j5btjskOUzUK/xf3otQv EBCc1Qgs3GRMalls6sNN0p/fLnivdQ== X-Received: by 10.129.129.197 with SMTP id r188mr28615465ywf.289.1493817098519; Wed, 03 May 2017 06:11:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.161.198 with HTTP; Wed, 3 May 2017 06:11:37 -0700 (PDT) Received: by 10.37.161.198 with HTTP; Wed, 3 May 2017 06:11:37 -0700 (PDT) In-Reply-To: References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> <22785.64570.259658.376130@fireball.acr.fi> <277aa94d-5aa1-7a28-94c7-81da0966c172@kuehlewind.net> <41594727-9667-42BD-ABB1-4583A3B00EA2@apple.com> <853700CB-D5DD-4BC7-A1F5-5AB61330E70D@apple.com> <22792.20148.255067.132946@fireball.acr.fi> <82B5E72F-C518-420B-B941-E4CE4DD1BF87@kuehlewind.net> <22792.31378.769444.232365@fireball.acr.fi> <78A72CF3-E011-4E8D-9F66-63C7918A8236@kuehlewind.net> <22793.40707.624092.66793@fireball.acr.fi> From: Spencer Dawkins at IETF Date: Wed, 3 May 2017 08:11:37 -0500 Message-ID: To: Mirja Kuehlewind Cc: iesg@ietf.org, ipsecme-chairs@ietf.org, Tommy Pauly , draft-ietf-ipsecme-tcp-encaps@ietf.org, Tero Kivinen , IPsecME WG , Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c0812988460e6054e9e65d9 Archived-At: Subject: Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 13:14:23 -0000 --94eb2c0812988460e6054e9e65d9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On May 3, 2017 05:54, "Mirja K=C3=BChlewind" wrote: I didn't propose to obsolete RFC3947 in this document. I guess you can also file an error for this if you don't want to take any further actions. However, for updating the IANA registry, I would say the right action is to do this simply by IESG approval for UDP then. Fwiw, that would work for me. Spencer Mirja On 03.05.2017 11:12, Tero Kivinen wrote: > Mirja Kuehlewind (IETF) writes: > >> my thinking was that the main problem is that 3947 was not obsoleted >> and I=E2=80=99m assuming we need a document to fix that. >> > > This is partly issue, but it is not issue we need to solve here, as > this document is not something that should obsolete 3947. > > Also 3947 only defines extension for the IKEv1 (RFC2409) and that is > already obsoleted, so effectively RFC3947 is already obsoleted, as > there is no way to implement 3947 without implementing obsoleted > protocol... > > This issue is not not important enough to require RFC now. > > In this case that document could/should also fix the IANA entry for >> the UDP port. However, I=E2=80=99m actually not sure what the right >> processing would be to fix this forgotten obsolete=E2=80=A6 maybe other = ADs >> know better=E2=80=A6? >> > > For now I would just leave it as it is, but fix the references in the > IANA registry so that document will not be referenced, especially as > the original IANA reference was not to the correct RFC in the first > place. > > Otherwise if you don=E2=80=99t want to do this, I don=E2=80=99t think it= =E2=80=99s a good >> idea to merge kind of unrelated fixes into this spec. We can also >> fix that by using the IESG approval process (see RFC5226). I think >> that=E2=80=99s the better option! >> > > That is true, but as this document already modifies the TCP/4500 > reference, fixing the UDP/4500 reference at the same time is not > completely unrelated fix. > > Obsoleting RFC3947 would be unrelated fix. > > --94eb2c0812988460e6054e9e65d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On May 3, 2017 05:54, "Mirja K=C3=BChlewind" <ietf@kuehlewind.net> wrote:
I didn't propose to obsolete = RFC3947 in this document. I guess you can also file an error for this if yo= u don't want to take any further actions. However, for updating the IAN= A registry, I would say the right action is to do this simply by IESG appro= val for UDP then.

Fwiw, that would work for me.
Spencer



Mirja



On 03.05.2017 11:12, Tero Kivinen wrote:
Mirja Kuehlewind (IETF) writes:
my thinking was that the main problem is that 3947 was not obsoleted
and I=E2=80=99m assuming we need a document to fix that.

This is partly issue, but it is not issue we need to solve here, as
this document is not something that should obsolete 3947.

Also 3947 only defines extension for the IKEv1 (RFC2409) and that is
already obsoleted, so effectively RFC3947 is already obsoleted, as
there is no way to implement 3947 without implementing obsoleted
protocol...

This issue is not not important enough to require RFC now.

In this case that document could/should also fix the IANA entry for
the UDP port. However, I=E2=80=99m actually not sure what the right
processing would be to fix this forgotten obsolete=E2=80=A6 maybe other ADs=
know better=E2=80=A6?

For now I would just leave it as it is, but fix the references in the
IANA registry so that document will not be referenced, especially as
the original IANA reference was not to the correct RFC in the first
place.

Otherwise if you don=E2=80=99t want to do this, I don=E2=80=99t think it=E2= =80=99s a good
idea to merge kind of unrelated fixes into this spec. We can also
fix that by using the IESG approval process (see RFC5226). I think
that=E2=80=99s the better option!

That is true, but as this document already modifies the TCP/4500
reference, fixing the UDP/4500 reference at the same time is not
completely unrelated fix.

Obsoleting RFC3947 would be unrelated fix.


--94eb2c0812988460e6054e9e65d9-- From nobody Thu May 4 12:51:30 2017 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 779E01294E0; Thu, 4 May 2017 12:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 rhqPaQUSfTLx; Thu, 4 May 2017 12:51:19 -0700 (PDT) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 41E35128990; Thu, 4 May 2017 12:51:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id B5F8840019; Thu, 4 May 2017 21:51:17 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cMX6+HpXchju; Thu, 4 May 2017 21:51:17 +0200 (CEST) Received: from [192.168.1.6] (104.red-83-40-108.dynamicip.rima-tde.net [83.40.108.104]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon21.um.es (Postfix) with ESMTPSA id E2A163FFDB; Thu, 4 May 2017 21:50:52 +0200 (CEST) From: Gabriel Lopez X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_6D6E29E1-EC76-47CF-B51C-83E1F6CD97E8"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Thu, 4 May 2017 21:50:39 +0200 References: <149392244255.6847.10684032567378751400.idtracker@ietfa.amsl.com> To: i2nsf@ietf.org, IPsecME WG , i-d-announce@ietf.org Message-Id: <4BB84C6E-A1BE-4007-8ED8-43F59D2AC1B2@um.es> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [IPsec] Fwd: New Version Notification for draft-abad-i2nsf-sdn-ipsec-flow-protection-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 19:51:23 -0000 --Apple-Mail=_6D6E29E1-EC76-47CF-B51C-83E1F6CD97E8 Content-Type: multipart/alternative; boundary="Apple-Mail=_8B87A168-8E63-4C27-9393-47CBBC3334EB" --Apple-Mail=_8B87A168-8E63-4C27-9393-47CBBC3334EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, We have uploaded a new version of the draft = i2nsf-sdn-ipsec-flow-protection where we have fixed some yang errors. = Now it is correctly validated. Best regards, Gabi. > Inicio del mensaje reenviado: >=20 > De: internet-drafts@ietf.org > Asunto: New Version Notification for = draft-abad-i2nsf-sdn-ipsec-flow-protection-03.txt > Fecha: 4 de mayo de 2017, 20:27:22 CEST > Para: "Rafa Marin-Lopez" , "Rafael Lopez" , = "Gabriel Lopez-Millan" >=20 >=20 > A new version of I-D, = draft-abad-i2nsf-sdn-ipsec-flow-protection-03.txt > has been successfully submitted by Rafa Marin-Lopez and posted to the > IETF repository. >=20 > Name: draft-abad-i2nsf-sdn-ipsec-flow-protection > Revision: 03 > Title: Software-Defined Networking (SDN)-based IPsec = Flow Protection > Document date: 2017-05-04 > Group: Individual Submission > Pages: 45 > URL: = https://www.ietf.org/internet-drafts/draft-abad-i2nsf-sdn-ipsec-flow-prote= ction-03.txt > Status: = https://datatracker.ietf.org/doc/draft-abad-i2nsf-sdn-ipsec-flow-protectio= n/ > Htmlized: = https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-abad-i2nsf-sdn-ipsec-flow-prot= ection-03 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-abad-i2nsf-sdn-ipsec-flow-protec= tion-03 >=20 > Abstract: > This document describes the use case of providing IPsec-based flow > protection by means of a Software-Defined Network (SDN) controller > (aka. Security Controller) and establishes the requirements to > support this service. It considers two main well-known scenarios in > IPsec: (i) gateway-to-gateway and (ii) host-to-host. This document > describes a mechanism based on the SDN paradigm to support the > distribution and monitoring of IPsec information from a SDN > controller to one or several flow-based Network Security Function > (NSF). The NSFs implement IPsec to protect data traffic between > network resources with IPsec. >=20 > The document focuses in the NSF Facing Interface by providing models > for Configuration and State data model required to allow the = Security > Controller to configure the IPsec databases (SPD, SAD, PAD) and IKE > to establish security associations with a reduced intervention of = the > network administrator. NOTE: State data model will be developed as > part of this work but it is still TBD. >=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 ----------------------------------------------------------- Gabriel L=C3=B3pez Mill=C3=A1n Departamento de Ingenier=C3=ADa de la Informaci=C3=B3n y las = Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es --Apple-Mail=_8B87A168-8E63-4C27-9393-47CBBC3334EB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear all,

We have uploaded a new version of the draft = i2nsf-sdn-ipsec-flow-protection where we have fixed some yang errors. = Now it is correctly validated.

Best regards, Gabi.

Inicio del mensaje reenviado:

De: = internet-drafts@ietf.org
Asunto: = New Version = Notification for = draft-abad-i2nsf-sdn-ipsec-flow-protection-03.txt
Fecha: = 4 de mayo de 2017, 20:27:22 = CEST
Para: = "Rafa Marin-Lopez" <rafa@um.es>, "Rafael Lopez" = <rafa@um.es>, = "Gabriel Lopez-Millan" <gabilm@um.es>


A new version = of I-D, draft-abad-i2nsf-sdn-ipsec-flow-protection-03.txt
has been successfully submitted by Rafa Marin-Lopez and = posted to the
IETF repository.

Name: = = draft-abad-i2nsf-sdn-ipsec-flow-protection
Revision: 03
Title: = Software-Defined Networking (SDN)-based IPsec Flow Protection
Document date: 2017-05-04
Group:= = Individual Submission
Pages: 45
URL: =            https://www.ietf.org/internet-drafts/draft-abad-i2nsf-sdn-ipsec= -flow-protection-03.txt
Status: =         https://datatracker.ietf.org/doc/draft-abad-i2nsf-sdn-ipsec-flo= w-protection/
Htmlized: =       https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-pro= tection-03
Htmlized: =       https://datatracker.ietf.org/doc/html/draft-abad-i2nsf-sdn-ipse= c-flow-protection-03
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-abad-i2nsf-sdn-ipsec-= flow-protection-03

Abstract:
  This document describes the use case of = providing IPsec-based flow
  protection by = means of a Software-Defined Network (SDN) controller
=   (aka.  Security Controller) and establishes the = requirements to
  support this service. =  It considers two main well-known scenarios in
=   IPsec: (i) gateway-to-gateway and (ii) host-to-host. =  This document
  describes a mechanism = based on the SDN paradigm to support the
=   distribution and monitoring of IPsec information from a = SDN
  controller to one or several flow-based = Network Security Function
  (NSF).  The = NSFs implement IPsec to protect data traffic between
=   network resources with IPsec.

=   The document focuses in the NSF Facing Interface by = providing models
  for Configuration and State = data model required to allow the Security
=   Controller to configure the IPsec databases (SPD, SAD, PAD) = and IKE
  to establish security associations = with a reduced intervention of the
  network = administrator.  NOTE: State data model will be developed as
  part of this work but it is still TBD.




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




-----------------------------------------------------------
Gabriel L=C3=B3pez Mill=C3=A1n
Departamento de = Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones
University of Murcia
Spain
Tel: = +34 868888504
Fax: +34 868884151
email: gabilm@um.es




= --Apple-Mail=_8B87A168-8E63-4C27-9393-47CBBC3334EB-- --Apple-Mail=_6D6E29E1-EC76-47CF-B51C-83E1F6CD97E8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJZC4YQAAoJEMUYqoSNEZFTAewH/ioYjnsSSAzB/LvVN1kYcghR VEdnp0Nfk1f7ZzyzbQb0Zg02gILXWwORg/UUKRVoGS3uq8nU9WEB1/aTUBOI/LMQ IqSQU7PUIMQr+ejAKT9Tt0CtWe+rJLxojzzz+TbdBQFG4EExfv4iz2kPyyslFc9p RI/zdy4wcjcTlHfIlvmSmvQkuOJ+9ZpoPH4K58YYzimC4/HhX8ocGUXSWKCS9168 pk/e2lDilSUxVoAJgqgTEUwLPoS/nvOoBaZ2O1fCZ4epOFl4XYeulJ98CbUUTXFZ InY0MzNAhyYHc2TGfU7hlinaQMfbEjZmpmn8/YjcHQ/SZmfL/JxiOnvF0rEwwr8= =nHEX -----END PGP SIGNATURE----- --Apple-Mail=_6D6E29E1-EC76-47CF-B51C-83E1F6CD97E8-- From nobody Fri May 5 14:14:38 2017 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 F3056129442 for ; Fri, 5 May 2017 14:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teaxABQpeB5N for ; Fri, 5 May 2017 14:14:36 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002: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 F234F128ACA for ; Fri, 5 May 2017 14:14:34 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id j17so838125ybj.0 for ; Fri, 05 May 2017 14:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Po7F8M0L3WLW0OirRf/eiz4PcwQoXWPcK/KLn3SUIvs=; b=RTpsvVY5wRIgPVMB8Z12lSlLMGSuG1OyUyuqjQA/ZzZ+2IZNKlfg00Qz7ZI73UOeEw mE43PJyNMG84vOL1KSrCFu3lWSuCSaww5bnosCi0LtYOb3VbhwqTC001GnFjziRX5hld gD/v8F7v7dJrtqkLDSQhKLKjevnuZlJ5qBxkTzZOFCpkEyLFcu1ZasxhC8DBOzMimzeK m+BE1a8Ia+yn+zlTJIQMroE3Vn70KmHnVqbKjuPmIQJdOfRx1w243crQC/PULJeaSyFm 4ekx5uk1q9FtKdkoB3Of2T5IRW4eRNFkXcX9hrXNTmdvqodWe6YoruLWBJUmlel29qwe d7LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Po7F8M0L3WLW0OirRf/eiz4PcwQoXWPcK/KLn3SUIvs=; b=tgVHX9TBRUGKNhPe3lsBWhst1vGL630O83SqeqdP+q/qepWBAPpFF3gqkKIzNp+vC7 Z5CXqB2mmzwiSKP1l+Lov3nSWAFar3s+OVaswwthj/8Ba+rtmJ4FkO2i/S6DGE77ugfE aaIxqWBljdk+UVTDIeYlMm8LnKQlytM+J5uHhBOlON3zb74yDQtBqFy9vZSW4F8YMoEP 2JMjxv1R06k25Qew1rDFT2yO08Ho+pCw046pKSMHpoy7kknK30IEaQDjQNvl6DBL0nkr +Xh6FxcX7fzcntV2W6ZJ6MFrjhdvyo3NaJ2pyeL6k+36he4U1s8PAJumWNEunMuOzu0b MNkA== X-Gm-Message-State: AODbwcCQ3u+IXh/QD13wzOQzmSMjU4QPxFzxZx1KCyg4MMl9obBrVR80 vD7rqxDJH6dx5/ZqyxJAWwX9v2qjkg== X-Received: by 10.37.41.130 with SMTP id p124mr619753ybp.24.1494018874234; Fri, 05 May 2017 14:14:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Fri, 5 May 2017 14:13:53 -0700 (PDT) In-Reply-To: References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> <22785.64570.259658.376130@fireball.acr.fi> <277aa94d-5aa1-7a28-94c7-81da0966c172@kuehlewind.net> <41594727-9667-42BD-ABB1-4583A3B00EA2@apple.com> <853700CB-D5DD-4BC7-A1F5-5AB61330E70D@apple.com> <22792.20148.255067.132946@fireball.acr.fi> <82B5E72F-C518-420B-B941-E4CE4DD1BF87@kuehlewind.net> <22792.31378.769444.232365@fireball.acr.fi> <78A72CF3-E011-4E8D-9F66-63C7918A8236@kuehlewind.net> <22793.40707.624092.66793@fireball.acr.fi> From: Eric Rescorla Date: Fri, 5 May 2017 14:13:53 -0700 Message-ID: To: Spencer Dawkins at IETF Cc: Mirja Kuehlewind , IESG , ipsecme-chairs@ietf.org, Tommy Pauly , draft-ietf-ipsecme-tcp-encaps@ietf.org, Tero Kivinen , IPsecME WG , Mark Nottingham Content-Type: multipart/alternative; boundary=94eb2c14d83449ba1c054ecd6022 Archived-At: Subject: Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 21:14:38 -0000 --94eb2c14d83449ba1c054ecd6022 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It seems like most of the issues are resolved here, except for that of muxing IKE and non-IKE protocols on the same port (especially 443). My understanding is that (although we may not like it) it's nevertheless a common practice, and yet we can't levy the requirement that no other protocol start with IKETCP, so it seems like what we need is a warning note and potentially a request to reserve this string for some set of common protocols (HTTP,...?). Mirja, would that work for you? -Ekr On Wed, May 3, 2017 at 6:11 AM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > > > On May 3, 2017 05:54, "Mirja K=C3=BChlewind" wrote: > > I didn't propose to obsolete RFC3947 in this document. I guess you can > also file an error for this if you don't want to take any further actions= . > However, for updating the IANA registry, I would say the right action is = to > do this simply by IESG approval for UDP then. > > > Fwiw, that would work for me. > > Spencer > > > > Mirja > > > > On 03.05.2017 11:12, Tero Kivinen wrote: > >> Mirja Kuehlewind (IETF) writes: >> >>> my thinking was that the main problem is that 3947 was not obsoleted >>> and I=E2=80=99m assuming we need a document to fix that. >>> >> >> This is partly issue, but it is not issue we need to solve here, as >> this document is not something that should obsolete 3947. >> >> Also 3947 only defines extension for the IKEv1 (RFC2409) and that is >> already obsoleted, so effectively RFC3947 is already obsoleted, as >> there is no way to implement 3947 without implementing obsoleted >> protocol... >> >> This issue is not not important enough to require RFC now. >> >> In this case that document could/should also fix the IANA entry for >>> the UDP port. However, I=E2=80=99m actually not sure what the right >>> processing would be to fix this forgotten obsolete=E2=80=A6 maybe other= ADs >>> know better=E2=80=A6? >>> >> >> For now I would just leave it as it is, but fix the references in the >> IANA registry so that document will not be referenced, especially as >> the original IANA reference was not to the correct RFC in the first >> place. >> >> Otherwise if you don=E2=80=99t want to do this, I don=E2=80=99t think it= =E2=80=99s a good >>> idea to merge kind of unrelated fixes into this spec. We can also >>> fix that by using the IESG approval process (see RFC5226). I think >>> that=E2=80=99s the better option! >>> >> >> That is true, but as this document already modifies the TCP/4500 >> reference, fixing the UDP/4500 reference at the same time is not >> completely unrelated fix. >> >> Obsoleting RFC3947 would be unrelated fix. >> >> > --94eb2c14d83449ba1c054ecd6022 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It seems like most of the issues are resolved here, except= for that of muxing
IKE and non-IKE protocols on the same port (especia= lly 443). My understanding
is that (although we may not like it) = it's nevertheless a common practice, and
yet we can't lev= y the requirement that no other protocol start with IKETCP<whatever>,=
so it seems like what we need is a warning note and potentially = a request to reserve
this string for some set of common protocols= (HTTP,...?).

Mirja, would that work for you?

-Ekr


On Wed, May 3, 2017 at 6:11 AM, Spencer = Dawkins at IETF <spencerdawkins.ietf@gmail.com> = wrote:


On May = 3, 2017 05:54, "Mirja K=C3=BChlewind" <ietf@kuehlewind.net> wrote:
I didn&#= 39;t propose to obsolete RFC3947 in this document. I guess you can also fil= e an error for this if you don't want to take any further actions. Howe= ver, for updating the IANA registry, I would say the right action is to do = this simply by IESG approval for UDP then.

Fwiw, that would work fo= r me.

Spencer



Mirja



On 03.05.2017 11:12, Tero Kivinen wrote:
Mirja Kuehlewind (IETF) writes:
my thinking was that the main problem is that 3947 was not obsoleted
and I=E2=80=99m assuming we need a document to fix that.

This is partly issue, but it is not issue we need to solve here, as
this document is not something that should obsolete 3947.

Also 3947 only defines extension for the IKEv1 (RFC2409) and that is
already obsoleted, so effectively RFC3947 is already obsoleted, as
there is no way to implement 3947 without implementing obsoleted
protocol...

This issue is not not important enough to require RFC now.

In this case that document could/should also fix the IANA entry for
the UDP port. However, I=E2=80=99m actually not sure what the right
processing would be to fix this forgotten obsolete=E2=80=A6 maybe other ADs=
know better=E2=80=A6?

For now I would just leave it as it is, but fix the references in the
IANA registry so that document will not be referenced, especially as
the original IANA reference was not to the correct RFC in the first
place.

Otherwise if you don=E2=80=99t want to do this, I don=E2=80=99t think it=E2= =80=99s a good
idea to merge kind of unrelated fixes into this spec. We can also
fix that by using the IESG approval process (see RFC5226). I think
that=E2=80=99s the better option!

That is true, but as this document already modifies the TCP/4500
reference, fixing the UDP/4500 reference at the same time is not
completely unrelated fix.

Obsoleting RFC3947 would be unrelated fix.



--94eb2c14d83449ba1c054ecd6022-- From nobody Mon May 8 05:49:43 2017 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 36698129461 for ; Mon, 8 May 2017 05:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewaGA7wpcoHY for ; Mon, 8 May 2017 05:49:40 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09AF12945E for ; Mon, 8 May 2017 05:49:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=cO8q+aC0LZDr/SWbOu8rRTQxQV0WdlxrBcxhBwEShDClgBPKN8m4KjORMlzUpR3W+ME5FuVmypIJy0Z+qcXDXknxno3yvyloeywJ7TkmEVO/hM4r2tqcIcErfGX8LnssKfigGqNHy0JlBXbza3WkIwExO2GxJYjExwZltAx0lcs=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 31846 invoked from network); 8 May 2017 14:49:38 +0200 Received: from p5dec259c.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.37.156) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 8 May 2017 14:49:38 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Mon, 8 May 2017 14:49:36 +0200 Cc: Spencer Dawkins at IETF , IESG , ipsecme-chairs@ietf.org, Tommy Pauly , draft-ietf-ipsecme-tcp-encaps@ietf.org, Tero Kivinen , IPsecME WG , Mark Nottingham Content-Transfer-Encoding: quoted-printable Message-Id: References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> <22785.64570.259658.376130@fireball.acr.fi> <277aa94d-5aa1-7a28-94c7-81da0966c172@kuehlewind.net> <41594727-9667-42BD-ABB1-4583A3B00EA2@apple.com> <853700CB-D5DD-4BC7-A1F5-5AB61330E70D@apple.com> <22792.20148.255067.132946@fireball.acr.fi> <82B5E72F-C518-420B-B941-E4CE4DD1BF87@kuehlewind.net> <22792.31378.769444.232365@fireball.acr.fi> <78A72CF3-E011-4E8D-9F66-63C7918A8236@kuehlewind.net> <22793.40707.624092.66793@fireball.acr.fi> To: Eric Rescorla X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170508124938.31834.92503@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 12:49:41 -0000 Does the proposed text changes from Tommy still refer to 443 anywhere = (lost track a bit but I guess the appendix still does right)? Again I think we should talk about using 443 if that=E2=80=99s what=E2=80=99= s done in reality. However my understanding is that real-life = implementation use TCP/TLS which I think could be discussed in the body = rather than the appendix. And I would like to see a recommendation that HTTPS and TCPIKE should = not be multiplexed the same time on the same port. My understanding from = Tero=E2=80=99s feedback was that this is usually not done today and = probably not necessary in future. Mirja > Am 05.05.2017 um 23:13 schrieb Eric Rescorla : >=20 > It seems like most of the issues are resolved here, except for that of = muxing > IKE and non-IKE protocols on the same port (especially 443). My = understanding > is that (although we may not like it) it's nevertheless a common = practice, and > yet we can't levy the requirement that no other protocol start with = IKETCP, > so it seems like what we need is a warning note and potentially a = request to reserve > this string for some set of common protocols (HTTP,...?). >=20 > Mirja, would that work for you? >=20 > -Ekr >=20 >=20 > On Wed, May 3, 2017 at 6:11 AM, Spencer Dawkins at IETF = wrote: >=20 >=20 > On May 3, 2017 05:54, "Mirja K=C3=BChlewind" = wrote: > I didn't propose to obsolete RFC3947 in this document. I guess you can = also file an error for this if you don't want to take any further = actions. However, for updating the IANA registry, I would say the right = action is to do this simply by IESG approval for UDP then. >=20 > Fwiw, that would work for me. >=20 > Spencer >=20 >=20 >=20 > Mirja >=20 >=20 >=20 > On 03.05.2017 11:12, Tero Kivinen wrote: > Mirja Kuehlewind (IETF) writes: > my thinking was that the main problem is that 3947 was not obsoleted > and I=E2=80=99m assuming we need a document to fix that. >=20 > This is partly issue, but it is not issue we need to solve here, as > this document is not something that should obsolete 3947. >=20 > Also 3947 only defines extension for the IKEv1 (RFC2409) and that is > already obsoleted, so effectively RFC3947 is already obsoleted, as > there is no way to implement 3947 without implementing obsoleted > protocol... >=20 > This issue is not not important enough to require RFC now. >=20 > In this case that document could/should also fix the IANA entry for > the UDP port. However, I=E2=80=99m actually not sure what the right > processing would be to fix this forgotten obsolete=E2=80=A6 maybe = other ADs > know better=E2=80=A6? >=20 > For now I would just leave it as it is, but fix the references in the > IANA registry so that document will not be referenced, especially as > the original IANA reference was not to the correct RFC in the first > place. >=20 > Otherwise if you don=E2=80=99t want to do this, I don=E2=80=99t think = it=E2=80=99s a good > idea to merge kind of unrelated fixes into this spec. We can also > fix that by using the IESG approval process (see RFC5226). I think > that=E2=80=99s the better option! >=20 > That is true, but as this document already modifies the TCP/4500 > reference, fixing the UDP/4500 reference at the same time is not > completely unrelated fix. >=20 > Obsoleting RFC3947 would be unrelated fix. >=20 >=20 >=20 From nobody Fri May 12 15:29:13 2017 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 42EEE12EC35 for ; Fri, 12 May 2017 15:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 lgSKjLpdvDnq for ; Fri, 12 May 2017 15:29:10 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.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 5CD7E13088A for ; Fri, 12 May 2017 15:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1494627912; 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=0dpv4ZBwqeQqX75cMlUPzL23Hs/FHcsliivsNlgOo/w=; b=E5dvhWP+5gkvQhbB99TvoPoxtKyHzVUmrxEHv6Dd7/WVdvO4KdFs3jLUrDQvNQPn dsH6YHhDvwXaos/Tj3PKc6joH/J7ruHZoI6jMHrF1EpfasCWv1QzNycXZiR+Cvk9 eACExpPWE1B+isYsVczreUW6ZBAy5UrcNNNN+qLoNeme0Wux2BSVb6t0finIBhYe WBSUHBmulugWkcCPG52/lEkcsDtTOLXjBos4EMAvMtFt5lkZV6fWpI6pNPG10UJ0 ZqDw/0WCtp8cDkAJjluUvy9Ycm88xo8m15A837iu3q6LukxnjRtc2zoPVmwZ2ZfX Bkg9dlFEwbYXnTitHRf+8w==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id EE.BF.26227.64636195; Fri, 12 May 2017 15:25:11 -0700 (PDT) X-AuditID: 11973e15-0b9fb70000006673-fe-59163646cb18 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by relay4.apple.com (Apple SCV relay) with SMTP id 60.25.02523.64636195; Fri, 12 May 2017 15:25:10 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.153.52.242] (unknown [17.153.52.242]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OPV00KN329YTJ40@nwk-mmpp-sz11.apple.com>; Fri, 12 May 2017 15:25:10 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: Date: Fri, 12 May 2017 15:25:09 -0700 Cc: Eric Rescorla , Spencer Dawkins at IETF , IESG , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org, Tero Kivinen , IPsecME WG , Mark Nottingham Content-transfer-encoding: quoted-printable Message-id: References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> <22785.64570.259658.376130@fireball.acr.fi> <277aa94d-5aa1-7a28-94c7-81da0966c172@kuehlewind.net> <41594727-9667-42BD-ABB1-4583A3B00EA2@apple.com> <853700CB-D5DD-4BC7-A1F5-5AB61330E70D@apple.com> <22792.20148.255067.132946@fireball.acr.fi> <82B5E72F-C518-420B-B941-E4CE4DD1BF87@kuehlewind.net> <22792.31378.769444.232365@fireball.acr.fi> <78A72CF3-E011-4E8D-9F66-63C7918A8236@kuehlewind.net> <22793.40707.624092.66793@fireball.acr.fi> To: "Mirja Kuehlewind (IETF)" X-Mailer: Apple Mail (2.3424) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUi2FAYruthJhZpsDba4v2fM4wWK16fY7eY 8Wcis8WL6x+ZLfZvecFmMXPOBxaLo+efs1ms//SY0WLZlD3MDpweO2fdZfdYsuQnk8fhrwtZ PFo+LmT12Lj4O6vH5MdtzAFsUVw2Kak5mWWpRfp2CVwZ5/c+ZS34r1jR8L6dvYGxR7qLkZND QsBEomXyD2YQW0hgNZNE10EFmPjWY9OA4lxA8UOMEo8W7GcFSfAKCEr8mHyPpYuRg4NZQF1i ypRciJqJTBJbZrxnB4kLC0hIbN6TCFIuLJAq8fr+LjYQm01AReL4tw1guzgFnCS6d95lArFZ BFQlvmzawg4yh1lgKpPEm0lLwBLMAtoST95dgNprI3Hzz342iGUHOSRadk1jBEmICBhLHJ78 nRXialmJCes2g10tIXCbTeLMp+3MExiFZyE5fBbC4bOQ7FjAyLyKUSg3MTNHNzPPTC+xoCAn VS85P3cTIyiOptuJ7mA8s8rqEKMAB6MSD6/iWtFIIdbEsuLK3EOM0hwsSuK8bdxAIYH0xJLU 7NTUgtSi+KLSnNTiQ4xMHJxSDYyysb8k7RTf5HPqb+Hzt13cGzPZkolDY9NcUdn1h9ffvbOO g+/b/EC9Pf+mtP/bHFHJ8PSFoO1iIW6/7p/5U9m+Jk4SnffJY/OMyW89F0w/1qCTc6n7ILvA e/fWLQEuoj3W1uEHtX03xDtyz08w25i4ZO3r0OmHtOVvXz7p7TRhhfG2Pyn7dA4osRRnJBpq MRcVJwIA5Jv4ToQCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUi2FA8W9fNTCzSYMkEM4v3f84wWqx4fY7d YsaficwWL65/ZLbYv+UFm8XMOR9YLI6ef85msf7TY0aLZVP2MDtweuycdZfdY8mSn0weh78u ZPFo+biQ1WPj4u+sHpMftzEHsEVx2aSk5mSWpRbp2yVwZZzf+5S14L9iRcP7dvYGxh7pLkZO DgkBE4mtx6YxdzFycQgJHGKUeLRgPytIgldAUOLH5HssXYwcHMwC6hJTpuRC1Exkktgy4z07 SFxYQEJi855EkHJhgVSJ1/d3sYHYbAIqEse/bWAGsTkFnCS6d95lArFZBFQlvmzawg4yh1lg KpPEm0lLwBLMAtoST95dgNprI3Hzz342iGUHOSRadk1jBEmICBhLHJ78nRXialmJCes2M09g FJiF5NZZCLfOQjJ2ASPzKkaBotScxEoTvcSCgpxUveT83E2M4NAvDN/B+G+Z1SFGAQ5GJR7e ivWikUKsiWXFlbnAwOBgVhLhdRIXixTiTUmsrEotyo8vKs1JLT7EKM3BoiTO2/tGJFJIID2x JDU7NbUgtQgmy8TBKdXAOKM+uHxZy7QlsdN/Mu4Jv/5UIG5NYNnO6QEZIkt0bFY/O5185XJS +nWliOrK7uVPk9yO5k84W7yM06v7rsLOpY072E588l+7dV7DodSFE7zlc3uq8jeZJKz//e/A 9xILp/RFll+u+k9kYeuUTl/XHsxu1vku7ihL4eaJXp1i2p9VdguE/t3Kq8RSnJFoqMVcVJwI ANvvRct5AgAA Archived-At: Subject: Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 22:29:11 -0000 > On May 8, 2017, at 5:49 AM, Mirja Kuehlewind (IETF) = wrote: >=20 > Does the proposed text changes from Tommy still refer to 443 anywhere = (lost track a bit but I guess the appendix still does right)? >=20 > Again I think we should talk about using 443 if that=E2=80=99s = what=E2=80=99s done in reality. However my understanding is that = real-life implementation use TCP/TLS which I think could be discussed in = the body rather than the appendix. The current state will not refer to 443 in the body, but specify TCP = 4500, with the option to have both peers mutually agree on another port = to use if necessary. The working group had felt that bringing TLS over = 443 directly into the body would be inappropriate for the standard. We = mention in the discussion of previous solutions that there are "SSL = VPNs", which covers the current reality of how the problem is solved. >=20 > And I would like to see a recommendation that HTTPS and TCPIKE should = not be multiplexed the same time on the same port. My understanding from = Tero=E2=80=99s feedback was that this is usually not done today and = probably not necessary in future. Yes, I think it makes sense to add to the text around the configuration = that it is recommended to not run any other service on the same port as = TCP Encapsulated IPsec. Thanks, Tommy >=20 > Mirja >=20 >=20 >> Am 05.05.2017 um 23:13 schrieb Eric Rescorla : >>=20 >> It seems like most of the issues are resolved here, except for that = of muxing >> IKE and non-IKE protocols on the same port (especially 443). My = understanding >> is that (although we may not like it) it's nevertheless a common = practice, and >> yet we can't levy the requirement that no other protocol start with = IKETCP, >> so it seems like what we need is a warning note and potentially a = request to reserve >> this string for some set of common protocols (HTTP,...?). >>=20 >> Mirja, would that work for you? >>=20 >> -Ekr >>=20 >>=20 >> On Wed, May 3, 2017 at 6:11 AM, Spencer Dawkins at IETF = wrote: >>=20 >>=20 >> On May 3, 2017 05:54, "Mirja K=C3=BChlewind" = wrote: >> I didn't propose to obsolete RFC3947 in this document. I guess you = can also file an error for this if you don't want to take any further = actions. However, for updating the IANA registry, I would say the right = action is to do this simply by IESG approval for UDP then. >>=20 >> Fwiw, that would work for me. >>=20 >> Spencer >>=20 >>=20 >>=20 >> Mirja >>=20 >>=20 >>=20 >> On 03.05.2017 11:12, Tero Kivinen wrote: >> Mirja Kuehlewind (IETF) writes: >> my thinking was that the main problem is that 3947 was not obsoleted >> and I=E2=80=99m assuming we need a document to fix that. >>=20 >> This is partly issue, but it is not issue we need to solve here, as >> this document is not something that should obsolete 3947. >>=20 >> Also 3947 only defines extension for the IKEv1 (RFC2409) and that is >> already obsoleted, so effectively RFC3947 is already obsoleted, as >> there is no way to implement 3947 without implementing obsoleted >> protocol... >>=20 >> This issue is not not important enough to require RFC now. >>=20 >> In this case that document could/should also fix the IANA entry for >> the UDP port. However, I=E2=80=99m actually not sure what the right >> processing would be to fix this forgotten obsolete=E2=80=A6 maybe = other ADs >> know better=E2=80=A6? >>=20 >> For now I would just leave it as it is, but fix the references in the >> IANA registry so that document will not be referenced, especially as >> the original IANA reference was not to the correct RFC in the first >> place. >>=20 >> Otherwise if you don=E2=80=99t want to do this, I don=E2=80=99t think = it=E2=80=99s a good >> idea to merge kind of unrelated fixes into this spec. We can also >> fix that by using the IESG approval process (see RFC5226). I think >> that=E2=80=99s the better option! >>=20 >> That is true, but as this document already modifies the TCP/4500 >> reference, fixing the UDP/4500 reference at the same time is not >> completely unrelated fix. >>=20 >> Obsoleting RFC3947 would be unrelated fix. >>=20 >>=20 >>=20 >=20 From nobody Tue May 16 13:08:22 2017 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 6EA981294E8; Tue, 16 May 2017 13:08:20 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1nrgl85i8tA; Tue, 16 May 2017 13:08:17 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 99AB312EC25; Tue, 16 May 2017 13:04:17 -0700 (PDT) X-AuditID: c6180641-45bff70000000cb9-17-591b14e045b8 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 07.FA.03257.0E41B195; Tue, 16 May 2017 17:04:03 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0339.000; Tue, 16 May 2017 16:04:13 -0400 From: Daniel Migault To: IPsecME WG CC: "lwip@ietf.org" Thread-Topic: New Version Notification for draft-mglt-lwig-minimal-esp-05.txt Thread-Index: AQHSzn4a49LoGHZI5kOeGMDijk5T5qH3X1XA Date: Tue, 16 May 2017 20:04:12 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BDB127@eusaamb107.ericsson.se> References: <149496441144.6631.7172931997134274042.idtracker@ietfa.amsl.com> In-Reply-To: <149496441144.6631.7172931997134274042.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyuXRPrO5jEelIg30rtC32b3nBZjFvn7AD k8eSJT+ZAhijuGxSUnMyy1KL9O0SuDL+nD7OXnAqseJf523GBsaO+C5GTg4JAROJS9+/sXUx cnEICRxllFj5o40ZwlnOKLH96zYmkCo2ASOJtkP97F2MHBwiAvISM29kgoSZBZQlPnTMYAex hQV8JCYe2wBmiwj4Ssx718sCUW4ksfG9DEiYRUBV4lDTKRYQmxeo5OqcOWDlQkCtff8/sIHY nEDxJUdWgW1lFBCT+H5qDRPEKnGJW0/mM0HcLCCxZM95ZghbVOLl43+sELaSxKSl51hB1jIL aEqs36UP0aooMaX7ITvEWkGJkzOfsExgFJ2FZOoshI5ZSDpmIelYwMiyipGjtLggJzfdyHAT IzD0j0mwOe5g3NvreYhRgINRiYf3lpB0pBBrYllxZe4hRgkOZiUR3pJgoBBvSmJlVWpRfnxR aU5q8SFGaQ4WJXHed+UXIoQE0hNLUrNTUwtSi2CyTBycUg2MYm1rT+XqLKvpN0pgERW4d0lk Y8Qq/kkHg3hlale/WuS6cOO63YGJwitDLhxy2V9uXOY2T+RPU9GnSZfvteruF5we4+8s8Ch1 RrPZuoa+nU8lpJYF6ovOVdrLJSa/ceGe2/F7T6RMf8mzy2e20LHVzkaHG363zdfKOzl51wIV 93Y28ZVHHebHK7EUZyQaajEXFScCAJnqPXZ5AgAA Archived-At: Subject: [IPsec] FW: New Version Notification for draft-mglt-lwig-minimal-esp-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 20:08:20 -0000 SGksIA0KDQpUaGFuayB5b3UgZm9yIHRoZSBjb21tZW50cy4gUGxlYXNlIGZpbmQgYW4gdXBkYXRl ZCB2ZXJzaW9uIG9mIHRoZSBtaW5pbWFsIEVTUCBpbXBsZW1lbnRhdGlvbiB3aXRoIGFsbCBjb21t ZW50IHJlY2VpdmVkLiBXZSBiZWxpZXZlZCB3ZSBhZGRyZXNzZWQgdGhlbSBhbGwuIA0KDQpXZSBi ZWxpZXZlIHRoZSBkcmFmdCBoYWQgc3VmZmljaWVudCByZXZpZXdzIGZvciBhZG9wdGlvbiBpbiBM V0lHLiBUaGUgZGlmZiB3aXRoIHRoZSBvbGQgdmVyc2lvbiBjYW4gYmUgZm91bmQgaGVyZTogDQpo dHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbWdsdC1sd2lnLW1pbmltYWwt ZXNwLTA1DQoNClBsZWFzZSBmaW5kIGEgZGV0YWlsZWQgZGVzY3JpcHRpb24gb2YgdGhlIGNvbW1l bnQgYWRkcmVzc2VkOg0KICAgIC0gQSkgQ2xhcmlmeWluZyB0aGUgcHVycG9zZSBvZiBhIG1pbmlt YWwgaW1wbGVtZW50YXRpb24gKFRlcm8sIFNjb3R0KQ0KICAgIC0gQikgU1BJOiAoU2NvdHQsIERh bmllbCkNCiAgICAtIEMpIFBhZGRpbmc6IChTY290dCwgWW9hdiBhbmQgVGVybykNCiAgICAtIEQp IE5leHQgSGVhZGVyOiAoU2NvdHQsIFRlcm8pDQogICAgLSBFKSBJQ1YgKFZhbGVyeSwgb3RoZXIg cGVvcGxlIGluIHRoZSBXRykNCg0KQ29tbWVudHMgYXJlIGFsd2F5cyB3ZWxjb21lLCBwbGVhc2Ug ZmluZCBhIGRldGFpbGVkIGRlc2NyaXB0aW9uIG9mIHRoZSB1cGRhdGUuDQpZb3VycywgDQpEYW5p ZWwNCg0KDQpBKSBDbGFyaWZ5aW5nIHRoZSBwdXJwb3NlIG9mIGEgbWluaW1hbCBpbXBsZW1lbnRh dGlvbjoNCg0KQ29tbWVudHMgZnJvbSBUZXJvIGFuZCBTY290dDoNCg0KVGhlIHNjb3BlIG9mIHRo ZSBtaW5pbWFsIHZlcnNpb24gc2hvdWxkIGJlIGNsYXJpZmllZCwgc28gdGhlIHJlYWRlciBpcyBu b3QgdXBzZXQgc29tZSBvcHRpb25zIGFyZSBtaXNzaW5nLiANCg0KV2UgYmVsaWV2ZSB0aGUgY3Vy cmVudCB0ZXh0IGFkZHJlc3MgdGhpcyBwdXJwb3NlOg0KIiIiDQpUaGlzIGRvY3VtZW50IGRlc2Ny aWJlcyBhIG1pbmltYWwgaW1wbGVtZW50YXRpb24gb2YgdGhlIElQIEVuY2Fwc3VsYXRpb24gU2Vj dXJpdHkgUGF5bG9hZCAoRVNQKSBkZXNjcmliZWQgaW4gUkZDIDQzMDMuIEl0cyBwdXJwb3NlIGlz IHRvIGVuYWJsZSBpbXBsZW1lbnRhdGlvbiBvZiBFU1Agd2l0aCBhIG1pbmltYWwgc2V0IG9mIG9w dGlvbnMgdGhhdCBtYWtlcyB0aGUgbWluaW1hbCBpbXBsZW1lbnRhdGlvbiBjb21wYXRpYmxlIHdp dGggRVNQIGFzIGRlc2NyaWJlZCBpbiBSRkMgNDMwMy4gQSBtaW5pbWFsIHZlcnNpb24gb2YgRVNQ IGlzIG5vdCBpbnRlbmRlZCB0byBiZWNvbWUgYSByZXBsYWNlbWVudCBvZiB0aGUgUkZDIDQzMDMg RVNQLCBidXQgaW5zdGVhZCB0byBlbmFibGUgYSBsaW1pdGVkIGltcGxlbWVudGF0aW9uIHRvIGlu dGVyb3BlcmF0ZSB3aXRoIGltcGxlbWVudGF0aW9ucyBvZiBSRkMgNDMwMyBFU1AuDQpUaGlzIGRv Y3VtZW50IGRlc2NyaWJlcyB3aGF0IGlzIHJlcXVpcmVkIGZyb20gUkZDIDQzMDMgRVNQICBhcyB3 ZWxsIGFzIHZhcmlvdXMgd2F5cyB0byBvcHRpbWl6ZSBjb21wbGlhbmNlIHdpdGggUkZDIDQzMDMg RVNQLg0KVGhpcyBkb2N1bWVudCBkb2VzIG5vdCB1cGRhdGUgb3IgbW9kaWZ5IFJGQyA0MzAzLCBi dXQgcHJvdmlkZXMgYSBjb21wYWN0IGRlc2NyaXB0aW9uIG9mIGhvdyB0byBpbXBsZW1lbnQgdGhl IG1pbmltYWwgdmVyc2lvbiBvZiB0aGUgcHJvdG9jb2wuICBJZiB0aGlzIGRvY3VtZW50IGFuZCBS RkMgNDMwMyBjb25mbGljdHMgdGhlbiBSRkMgNDMwMyBpcyB0aGUgYXV0aG9yaXRhdGl2ZSBkZXNj cmlwdGlvbi4NCiIiIg0KDQoiIiINClRoZSBwcmltYXJ5IHB1cnBvc2Ugb2YgTWluaW1hbCBFU1Ag aXMgdG8gcmVtYWluCWludGVyb3BlcmFibGUgd2l0aCBvdGhlciBub2RlcyBpbXBsZW1lbnRpbmcg UkZDIDQzMDMgRVNQLCB3aGlsZSBsaW1pdGluZyB0aGUgc3RhbmRhcmQgY29tcGxleGl0eSBvZiB0 aGUgaW1wbGVtZW50YXRpb24uDQoiIiINCg0KDQpCKSBTUEk6DQoNCkNvbW1lbnQgZnJvbSBTY290 dCwgRGFuaWVsDQoNClRoZSB0ZXh0IGluIGRyYWZ0IHZlcnNpb24gMDQgcmVwcmVzZW50ZWQgd2hh dCBoYXMgYmVlbiBkaXNjdXNzZWQgb24gdGhlIE1MLiBXZSBpbmNsdWRlZCBzb21lIHJlY29tbWVu ZGF0aW9uIG9uIGhvdyB0byBpbmRleCB0aGUgU0Egd2l0aCB0aGUgU1BJLiBXZSBhbHNvIHByZXNl bnRlZCBkaWZmZXJlbnQgbG9va3VwcyBmb3IgYW55Y2FzdCBhbmQgbXVsdGljYXN0IG5vZGVzLiAN Cg0KVGhlIGRyYWZ0IGRldGFpbHMgaG93IHRvIGF2b2lkIGdlbmVyYXRpbmcgcmFuZG9tIFNQSSwg YW5kIGluc3RlYWQgdXNlIGZpeCBTUEkuIFdlIGFkZGVkIHNvbWUgdGV4dCB0byBhdm9pZCB0aGUg Y3VycmVudCBleHBsYW5hdGlvbiBhcyBiZWluZyBpbnRlcnByZXRlZCBhcyB0aGVyZSBpcyBubyBu ZWVkIGZvciByYW5kb20gZ2VuZXJhdG9ycy4gDQoNCiIiIg0KVGhlIHVzZSBvZiBmaXggU1BJIHNo b3VsZCBub3QgYmUgY29uc2lkZXJlZCBhcyBhIHdheSB0byBhdm9pZCBzdHJvbmcgcmFuZG9tIGdl bmVyYXRvcnMuICBTdWNoIGdlbmVyYXRvciB3aWxsIGJlIHJlcXVpcmVkIGluIG9yZGVyIHRvIHBy b3ZpZGUgc3Ryb25nIGNyeXB0b2dyYXBoaWMgcHJvdGVjdGlvbi4gIEluc3RlYWQsIHRoZSB1c2Ug b2YgYSBmaXggU1BJIHNob3VsZCBvbmx5IGNvbnNpZGVyZWQgYXMgYSB3YXkgdG8gb3ZlcmNvbWUg dGhlIHJlc291cmNlIGxpbWl0YXRpb25zIG9mIHRoZSBub2RlLCB3aGVuIHRoaXMgaXMgZmVhc2li bGUuDQoiIiINCg0KQykgUGFkZGluZzoNCg0KQ29tbWVudCBmcm9tIFNjb3R0LCBZb2F2IGFuZCBU ZXJvDQoNClRoZSBjdXJyZW50IFBhZGRpbmcgc2VjdGlvbiBoYXMgYmVlbiBjb25zZXF1ZW50bHkg dXBkYXRlZC4gDQogICAgLSBQYWRkaW5nIGhhcyBiZWVuIG1lbnRpb25lZCBhcyBtYW5kYXRvcnkg DQogICAgLSBURkMgaGFzIGJlZW4gbWVudGlvbmVkIGFzIG5vdCBiZWluZyBpbXBsZW1lbnRlZCBp biBhIG1pbmltYWwgdmVyc2lvbi4NCiIiIg0KQ2hlY2tpbmcgdGhlIHBhZGRpbmcgc3RydWN0dXJl IGlzIG5vdCBtYW5kYXRvcnksIHNvIHRoZSBjb25zdHJhaW50IGRldmljZSBtYXkgbm90IHByb2Nl ZWQgdG8gc3VjaCBjaGVja3MsIGhvd2V2ZXIsIGluIG9yZGVyIHRvIGludGVyb3BlcmF0ZSB3aXRo IGV4aXN0aW5nIEVTUCBpbXBsZW1lbnRhdGlvbnMsIGl0IE1VU1QgYnVpbGQgdGhlIHBhZGRpbmcg Ynl0ZXMgYXMgcmVjb21tZW5kZWQgYnkgRVNQLg0KIiIiCQ0KDQpUaGUgZm9sbG93aW5nIHRleHQg aGFzIGJlZW4gYWRkZWQgcmVnYXJkaW5nIFRGQzoNCg0KIiIiCQ0KRVNQIDw8UkZDNDMwMz4+IGFs c28gcHJvdmlkZXMgVHJhZmZpYyBGbG93IENvbmZpZGVudGlhbGl0eSAoVEZDKSBhcyBhIHdheSB0 byBwZXJmb3JtIHBhZGRpbmcgdG8gaGlkZSB0cmFmZmljIGNoYXJhY3RlcmlzdGljcywgd2hpY2gg ZGlmZmVycyBmcm9tIHJlc3BlY3RpbmcgYSAzMiBiaXQgYWxpZ25tZW50LiBURkMgaXMgbm90IG1h bmRhdG9yeSBhbmQgTVVTVCBiZSBuZWdvdGlhdGVkIHdpdGggdGhlIFNBIG1hbmFnZW1lbnQgcHJv dG9jb2wuIEFzIGEgcmVzdWx0LCBURkMgaXMgbm90IGV4cGVjdGVkIHRvIGJlIHN1cHBvcnRlZCBi eSBhIG1pbmltYWwgRVNQIGltcGxlbWVudGF0aW9uLiANCk9uIHRoZSBvdGhlciBoYW5kLCBkaXNh YmxpbmcgVEZDIHNob3VsZCBiZSBjYXJlZnVsbHkgbWVhc3VyZWQgYW5kIHVuZGVyc3Rvb2QgYXMg aXQgZXhwb3NlcyB0aGUgbm9kZSB0byB0cmFmZmljIHNoYXBpbmcuIFRoaXMgY291bGQgZXhwb3Nl IHRoZSBhcHBsaWNhdGlvbiBhcyB3ZWxsIGFzIHRoZSBkZXZpY2VzIHVzZWQgdG8gYSBwYXNzaXZl IG1vbml0b3JpbmcgYXR0YWNrZXIuIFN1Y2ggaW5mb3JtYXRpb24gY291bGQgYmUgdXNlZCBieSB0 aGUgYXR0YWNrZXIgaW4gY2FzZSBhIHZ1bG5lcmFiaWxpdHkgaXMgZGlzY2xvc2VkIG9uIHRoZSBz cGVjaWZpYyBkZXZpY2UuIEluIGFkZGl0aW9uLCBzb21lIGFwcGxpY2F0aW9uIHVzZSAtIHN1Y2gg YXMgaGVhbHRoIGFwcGxpY2F0aW9ucyAtIG1heSBhbHNvIHJldmVhbCBpbXBvcnRhbnQgcHJpdmFj eSBvcmllbnRlZCBpbmZvcm1hdGlvbnMuDQoNClNvbWUgY29uc3RyYWludCBub2RlcyB0aGF0IGhh dmUgbGltaXRlZCBiYXR0ZXJ5IGxpZmUgdGltZSBtYXkgYWxzbyBwcmVmZXIgYXZvaWRpbmcgc2Vu ZGluZyBleHRyYSBwYWRkaW5nIGJ5dGVzLiBIb3dldmVyIHRoZSBzYW1lIG5vZGVzIG1heSBhbHNv IGJlIHZlcnkgc3BlY2lmaWMgdG8gYW4gYXBwbGljYXRpb24gYW5kIGRldmljZS4gQXMgYSByZXN1 bHQsIHRoZXkgYXJlIGFsc28gbGlrZWx5IHRvIGJlIHRoZSBtYWluIHRhcmdldCBmb3IgdHJhZmZp YyBzaGFwaW5nLiBJbiBtb3N0IGNhc2VzLCB0aGUgcGF5bG9hZCBjYXJyaWVkIGJ5IHRoZXNlIG5v ZGVzIGlzIHF1aXRlIHNtYWxsLCBhbmQgdGhlIHN0YW5kYXJkIHBhZGRpbmcgbWVjaGFuaXNtIG1h eSBhbHNvIGJlIHVzZWQgYXMgYW4gYWx0ZXJuYXRpdmUgdG8gVEZDLCB3aXRoIGEgc3VmZmljaWVu dCB0cmFkZSBvZmYgYmV0d2VlbiB0aGUgcmVxdWlyZSBlbmVyZ3kgdG8gc2VuZCBhZGRpdGlvbmFs IHBheWxvYWQgYW5kIHRoZSBleHBvc3VyZSB0byB0cmFmZmljIHNoYXBpbmcgYXR0YWNrcy4NCiIi Ig0KCQ0KDQoNCkQpIE5leHQgSGVhZGVyOg0KQ29tbWVudHMgZnJvbSBTY290dCwgVGVybyANCg0K VGhlIE5leHQgSGVhZGVyIHNlY3Rpb24gaGFzIGJlZW4gdXBkYXRlZCBieSBzcGVjaWZ5aW5nIGJl dHRlciBwb3NpdGlvbiB0aGUgbWluaW1hbCBpbXBsZW1lbnRhdGlvbiByZWdhcmRpbmcgdGhlIGR1 bW15IHBhY2tldCBhcyB3ZWxsIGFzIHRoZSBCRUVUIG1vZGUuIFRoZSBhYmlsaXR5IHRvIHJlamVj dCBkdW1teSBwYWNrZXQgaGFzIGJlZW4gYWRkZWQgYXMgYmVpbmcgbWFuZGF0b3J5IGZvciBhIG1p bmltYWwgaW1wbGVtZW50YXRpb24uIA0KDQpUaGUgZm9sbG93aW5nIHRleHQgaGFzIGJlZW4gYWRk ZWQ6DQoNCkFjY29yZGluZyB0byA8PFJGQzQzMDM+PiwgdGhlIE5leHQgSGVhZGVyIGlzIGEgbWFu ZGF0b3J5IDggYml0cyBmaWVsZCBpbiB0aGUgcGFja2V0LiBOZXh0IGhlYWRlciBpcyBpbnRlbmRl ZCB0byBzcGVjaWZ5IHRoZSBkYXRhIGNvbnRhaW5lZCBpbiB0aGUgcGF5bG9hZCBhcyB3ZWxsIGFz IGR1bW15IHBhY2tldC4gSW4gYWRkaXRpb24sIHRoZSBOZXh0IEhlYWRlciBtYXkgYWxzbyBjYXJy eSBhbiBpbmRpY2F0aW9uIG9uIGhvdyB0byBwcm9jZXNzIHRoZSBwYWNrZXQgPDxJLUQubmlrYW5k ZXItZXNwLWJlZXQtbW9kZT4+Lg0KDQpUaGUgYWJpbGl0eSB0byBnZW5lcmF0ZSBhbmQgcmVjZWl2 ZSBkdW1teSBwYWNrZXQgaXMgcmVxdWlyZWQgYnkgPDxSRkM0MzAzPj4uIEZvciBpbnRlcm9wZXJh YmlsaXR5LCBpdCBpcyBSRUNPTU1FTkRFRCBhIG1pbmltYWwgRVNQIGltcGxlbWVudGF0aW9uIGRp c2NhcmRzIGR1bW15IHBhY2tldHMuIE5vdGUgdGhhdCBzdWNoIHJlY29tbWVuZGF0aW9uIG9ubHkg YXBwbGllcyBmb3Igbm9kZXMgcmVjZWl2aW5nIHBhY2tldHMsIGFuZCB0aGF0IG5vZGVzIGRlc2ln bmVkIHRvIG9ubHkgc2VuZCBkYXRhIG1heSBub3QgaW1wbGVtZW50IHRoaXMgY2FwYWJpbGl0eS4g DQoNCkFzIHRoZSBnZW5lcmF0aW9uIG9mIGR1bW15IHBhY2tldHMgaXMgc3ViamVjdCB0byBsb2Nh bCBtYW5hZ2VtZW50IGFuZCBiYXNlZCBvbiBhIHBlci1TQSBiYXNpcywgYSBtaW5pbWFsIEVTUCBp bXBsZW1lbnRhdGlvbiBtYXkgbm90IGdlbmVyYXRlIHN1Y2ggZHVtbXkgcGFja2V0LiBNb3JlIGVz cGVjaWFsbHksIGluIGNvbnN0cmFpbnQgZW52aXJvbm1lbnQgc2VuZGluZyBkdW1teSBwYWNrZXRz IG1heSBoYXZlIHRvbyBtdWNoIGltcGFjdCBvbiB0aGUgZGV2aWNlIGxpZmUgdGltZSwgYW5kIHNv IG1heSBiZSBhdm9pZGVkLiBPbiB0aGUgb3RoZXIgaGFuZCwgY29uc3RyYWludCBub2RlcyBtYXkg YmUgZGVkaWNhdGVkIHRvIHNwZWNpZmljIGFwcGxpY2F0aW9ucywgaW4gd2hpY2ggY2FzZSwgdHJh ZmZpYyBwYXR0ZXJuIG1heSBleHBvc2UgdGhlIGFwcGxpY2F0aW9uIG9yIHRoZSB0eXBlIG9mIG5v ZGUuIEZvciB0aGVzZSBub2Rlcywgbm90IHNlbmRpbmcgZHVtbXkgcGFja2V0IG1heSBoYXZlIHNv bWUgcHJpdmFjeSBpbXBsaWNhdGlvbiB0aGF0IG5lZWRzIHRvIGJlIG1lYXN1cmVkLg0KDQpJbiBz b21lIGNhc2VzLCBkZXZpY2VzIGFyZSBkZWRpY2F0ZWQgdG8gYSBzaW5nbGUgYXBwbGljYXRpb24g b3IgYSBzaW5nbGUgdHJhbnNwb3J0IHByb3RvY29sLCBpbiB3aGljaCBjYXNlLCB0aGUgTmV4dCBI ZWFkZXIgaGFzIGEgZml4IHZhbHVlLiANCg0KU3BlY2lmaWMgcHJvY2Vzc2luZyBpbmRpY2F0aW9u cyBoYXZlIG5vdCBiZWVuIHN0YW5kYXJkaXplZCB5ZXQgPDxJLUQubmlrYW5kZXItZXNwLWJlZXQt bW9kZT4+IGFuZCBpcyBleHBlY3RlZCB0byByZXN1bHQgZnJvbSBhbiBhZ3JlZW1lbnQgYmV0d2Vl biB0aGUgcGVlcnMuIEFzIGEgcmVzdWx0LCBpdCBpcyBub3QgZXhwZWN0ZWQgdG8gYmUgcGFydCBv ZiBhIG1pbmltYWwgaW1wbGVtZW50YXRpb24gb2YgRVNQLg0KDQoNCkUpIElDVg0KDQpDb21tZW50 IGZyb20gVmFsZXJ5LCBvdGhlciBwZW9wbGUgaW4gdGhlIFdHDQpUaGUgcHJldmlvdXMgdGV4dCBn YXZlIHRoZSBpbXByZXNzaW9uIHRoYXQgdGhlIElDViB3YXMgb3B0aW9uYWwuIEkgYmVsaWV2ZSB0 aGUgZm9sbG93aW5nIHRleHQgY2xhcmlmaWVzIHRoZSBjb25jZXJuLg0KDQoiIiINClRoZSBJQ1Yg ZGVwZW5kcyBvbiB0aGUgY3J5cHRvLXN1aXRlIHVzZWQuIEN1cnJlbnRseSByZWNvbW1lbmRlZCA8 PEktRC5pZXRmLWlwc2VjbWUtcmZjNzMyMWJpcz4+IG9ubHkgcmVjb21tZW5kIGNyeXB0by1zdWl0 ZXMgd2l0aCBhbiBJQ1Ygd2hpY2ggbWFrZXMgdGhlIElDViBhIG1hbmRhdG9yeSBmaWVsZC4NCiIi Ig0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFR1 ZXNkYXksIE1heSAxNiwgMjAxNyAzOjU0IFBNDQpUbzogVG9iaWFzIEd1Z2dlbW9zIDxndWdnZW1v c0Btbm0tdGVhbS5vcmc+OyBEYW5pZWwgTWlnYXVsdCA8ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24u Y29tPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1tZ2x0LWx3 aWctbWluaW1hbC1lc3AtMDUudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1n bHQtbHdpZy1taW5pbWFsLWVzcC0wNS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgRGFuaWVsIE1pZ2F1bHQgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0K DQpOYW1lOgkJZHJhZnQtbWdsdC1sd2lnLW1pbmltYWwtZXNwDQpSZXZpc2lvbjoJMDUNClRpdGxl OgkJTWluaW1hbCBFU1ANCkRvY3VtZW50IGRhdGU6CTIwMTctMDUtMTUNCkdyb3VwOgkJSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTEyDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1nbHQtbHdpZy1taW5pbWFsLWVzcC0wNS50 eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1tZ2x0LWx3aWctbWluaW1hbC1lc3AvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LW1nbHQtbHdpZy1taW5pbWFsLWVzcC0wNQ0KSHRtbGl6ZWQ6ICAg ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbWdsdC1sd2ln LW1pbmltYWwtZXNwLTA1DQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LW1nbHQtbHdpZy1taW5pbWFsLWVzcC0wNQ0KDQpBYnN0cmFjdDoNCiAg IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWluaW1hbCBpbXBsZW1lbnRhdGlvbiBvZiB0aGUg SVANCiAgIEVuY2Fwc3VsYXRpb24gU2VjdXJpdHkgUGF5bG9hZCAoRVNQKSBkZXNjcmliZWQgaW4g UkZDIDQzMDMuICBJdHMNCiAgIHB1cnBvc2UgaXMgdG8gZW5hYmxlIGltcGxlbWVudGF0aW9uIG9m IEVTUCB3aXRoIGEgbWluaW1hbCBzZXQgb2YNCiAgIG9wdGlvbnMgdGhhdCBtYWtlcyB0aGUgbWlu aW1hbCBpbXBsZW1lbnRhdGlvbiBjb21wYXRpYmxlIHdpdGggRVNQIGFzDQogICBkZXNjcmliZWQg aW4gUkZDIDQzMDMuICBBIG1pbmltYWwgdmVyc2lvbiBvZiBFU1AgaXMgbm90IGludGVuZGVkIHRv DQogICBiZWNvbWUgYSByZXBsYWNlbWVudCBvZiB0aGUgUkZDIDQzMDMgRVNQLCBidXQgaW5zdGVh ZCB0byBlbmFibGUgYQ0KICAgbGltaXRlZCBpbXBsZW1lbnRhdGlvbiB0byBpbnRlcm9wZXJhdGUg d2l0aCBpbXBsZW1lbnRhdGlvbnMgb2YgUkZDDQogICA0MzAzIEVTUC4NCg0KICAgVGhpcyBkb2N1 bWVudCBkZXNjcmliZXMgd2hhdCBpcyByZXF1aXJlZCBmcm9tIFJGQyA0MzAzIEVTUCBhcyB3ZWxs IGFzDQogICB2YXJpb3VzIHdheXMgdG8gb3B0aW1pemUgY29tcGxpYW5jZSB3aXRoIFJGQyA0MzAz IEVTUC4NCg0KICAgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCB1cGRhdGUgb3IgbW9kaWZ5IFJGQyA0 MzAzLCBidXQgcHJvdmlkZXMgYQ0KICAgY29tcGFjdCBkZXNjcmlwdGlvbiBvZiBob3cgdG8gaW1w bGVtZW50IHRoZSBtaW5pbWFsIHZlcnNpb24gb2YgdGhlDQogICBwcm90b2NvbC4gIElmIHRoaXMg ZG9jdW1lbnQgYW5kIFJGQyA0MzAzIGNvbmZsaWN0cyB0aGVuIFJGQyA0MzAzIGlzDQogICB0aGUg YXV0aG9yaXRhdGl2ZSBkZXNjcmlwdGlvbi4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K DQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJp YXQNCg0K From nobody Wed May 17 10:44:24 2017 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 2C07E12EB84 for ; Wed, 17 May 2017 10:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.623 X-Spam-Level: X-Spam-Status: No, score=-12.623 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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=-0.001, SPF_HELO_PASS=-0.001, 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 BQVXK3-y8LeO for ; Wed, 17 May 2017 10:44:20 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C45C212EBB9 for ; Wed, 17 May 2017 10:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12884; q=dns/txt; s=iport; t=1495042784; x=1496252384; h=from:to:subject:date:message-id:mime-version; bh=ttPD4lLTp+jHQzP5pT11bVR08nfN7ZVo9qAMDS+Oxkc=; b=ZgbUY2pZS+pr1jbce1h8jY5Aav3FUKvXPEvbqPbncn0jqhKnFlf1wdIh B9vKf7N/agqHG65wmEgyGIqLj+f65akJlE9G+CClMTg+BXRuOjA0lyZ+h H1ws8ljDthbdZoYGnuWzWKX/w29XTI2EwcbI2HJvHAbr3t4D7s9nNYoIX Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BHAQC0iRxZ/5hdJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm5nYoETjX6iI4U4gg+MAT8YAQIBAQEBAQEBayiFRgZeAYEAJgEEG4o?= =?us-ascii?q?bnHSRdzqLBAEBAQEGAQEBAQEjhl+BXo1wBZZzhx0BgVqRN5F2lEUBHziBCnAVh?= =?us-ascii?q?TofgWOIUYENAQEB?= X-IronPort-AV: E=Sophos;i="5.38,355,1491264000"; d="scan'208,217";a="424901348" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 May 2017 17:39:43 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v4HHdhre006698 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 17 May 2017 17:39:43 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; Wed, 17 May 2017 13:39:43 -0400 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; Wed, 17 May 2017 13:39:43 -0400 From: "Scott Fluhrer (sfluhrer)" To: "IPsecme WG (ipsec@ietf.org)" Thread-Topic: Question about ipsecme-tcp-encaps Thread-Index: AdLPNI/2pFR/dDPhQiGtKCVpagxlHg== Date: Wed, 17 May 2017 17:39:42 +0000 Message-ID: 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.52] Content-Type: multipart/alternative; boundary="_000_f8bfcad2cf6b41928dcf44aa3a0b8805XCHRTP006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [IPsec] Question about ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 17:44:22 -0000 --_000_f8bfcad2cf6b41928dcf44aa3a0b8805XCHRTP006ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've been looking over the draft, and I think I see a potential DoS attack = that does not appear to be addressed. I'm writing this to see if there is = something I missed (and if there isn't, start discussion on how we might pa= tch things up). This is the scenario I'm looking at: Alice and Bob have a TCP-based IKE/IPs= ec connection established. Then, Eve injects a TCP packet to Bob with Alice's source IP (and with the = appropriate TCP sequence numbers), and whose body consists of a single FF b= yte. Eve does nothing else than that (other than possibly absorbing the TC= P-ACK that Bob would send out, if that'd confuse Alice's TCP stack...) Alice will then send a legitimate packet, consisting of (for example) [Leng= th =3D 0x0124] [ESP Header][Body]. However, Bob's TCP stack thinks it has = already received the first byte, and so it'll ignore it, and so will tell t= he application (IPsec) that it has received [0xff34][ESP Header][Body]. The IPsec packet parsing code would interpret this as an extremely long enc= rypted packet, and so will continue to absorb the next 0xfe00 bytes from Al= ice. It'll then try to decrypt it; it'll fail. That, in itself, is not that big= of a deal; we assume that an attacker who can modify packets at will is ab= le to force a few packets to be dropped. However, look what happens after that; the IPsec stream parsing code will t= hen take the next two bytes of the stream, and try to parse them as 'packet= length'. We stopped at a random location within the TCP stream, and so qu= ite likely, we're in the middle of an encrypted packet, and so the length w= ill be a random value. We'll then try to parse the next bytes as a packet,= and this will keep on going (blocking all Alice -> Bob traffic) until the = end-of-packet the IPsec stream parser assumes just happens to fall on an ac= tual packet boundary - obviously, that might be a while. TLS uses a similar 'record lengths appear in the TCP stream' concept; howev= er in the case of TLS, on decryption failure, you MUST close the connection= (and so this repeated 'get a random sequence of bytes and try to decrypt' = isn't an issue); I didn't see a similar mandate in the IPsec draft. Was there something I missed? The draft does have the text: If either TCP Originator or TCP Responder receives a stream that cannot be parsed correctly (for example, if the TCP Originator stream is missing the stream prefix, or message frames are not parsable as IKE or ESP messages), it MUST close the TCP connection. However: a) That's in a paragraph that starts "If a TCP connection is being use= d to resume a previous IKE session..."; does it apply only in that case? b) An ESP message is of the form [SPI][Sequence number][Random bytes];= unless you happen to get a SPI < 256 or length < 8, it's not clear how you= could get something that is not of that format (unless you mandate that th= e ESP length must be a multiple of 4 bytes; in that case, you should state = that explicitly) Thoughts? --_000_f8bfcad2cf6b41928dcf44aa3a0b8805XCHRTP006ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve been looking over the draft, and I think = I see a potential DoS attack that does not appear to be addressed.  I&= #8217;m writing this to see if there is something I missed (and if there is= n’t, start discussion on how we might patch things up).

 

This is the scenario I’m looking at: Alice and= Bob have a TCP-based IKE/IPsec connection established.

 

Then, Eve injects a TCP packet to Bob with AliceR= 17;s source IP (and with the appropriate TCP sequence numbers), and whose b= ody consists of a single FF byte.  Eve does nothing else than that (ot= her than possibly absorbing the TCP-ACK that Bob would send out, if that’d confuse Alice’s TCP stack…= )

 

Alice will then send a legitimate packet, consisting= of (for example) [Length =3D 0x0124] [ESP Header][Body].  However, Bo= b’s TCP stack thinks it has already received the first byte, and so i= t’ll ignore it, and so will tell the application (IPsec) that it has received [0xff34][ESP Header][Body].

 

The IPsec packet parsing code would interpret this a= s an extremely long encrypted packet, and so will continue to absorb the ne= xt 0xfe00 bytes from Alice.

 

It’ll then try to decrypt it; it’ll fail= .  That, in itself, is not that big of a deal; we assume that an attac= ker who can modify packets at will is able to force a few packets to be dro= pped.

 

However, look what happens after that; the IPsec str= eam parsing code will then take the next two bytes of the stream, and try t= o parse them as ‘packet length’.  We stopped at a random l= ocation within the TCP stream, and so quite likely, we’re in the middle of an encrypted packet, and so the length will b= e a random value.  We’ll then try to parse the next bytes as a p= acket, and this will keep on going (blocking all Alice -> Bob traffic) u= ntil the end-of-packet the IPsec stream parser assumes just happens to fall on an actual packet boundary – obviously, that = might be a while.

 

TLS uses a similar ‘record lengths appear in t= he TCP stream’ concept; however in the case of TLS, on decryption fai= lure, you MUST close the connection (and so this repeated ‘get a rand= om sequence of bytes and try to decrypt’ isn’t an issue); I didn’t see a similar mandate in the IPsec draft.

 

 

Was there something I missed?  The draft does h= ave the text:

 

=    If either TCP Originator or TCP Responder

=    receives a stream that cannot be parsed correctly (for example= , if

=    the TCP Originator stream is missing the stream prefix, or mes= sage

=    frames are not parsable as IKE or ESP messages), it MUST close= the

=    TCP connection.

 

However:

a)      That’s in a paragraph that starts “If a= TCP connection is being used to resume a previous IKE session…”= ;; does it apply only in that case?

b)      An ESP message is of the form [SPI][Sequence number= ][Random bytes]; unless you happen to get a SPI < 256 or length < 8, = it’s not clear how you could get something that is not of that format= (unless you mandate that the ESP length must be a multiple of 4 bytes; in that case, you should state that explicitly)<= o:p>

 =

 

Thoughts?

--_000_f8bfcad2cf6b41928dcf44aa3a0b8805XCHRTP006ciscocom_-- From nobody Wed May 17 11:59:28 2017 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 4AE63129B37 for ; Wed, 17 May 2017 11:59:28 -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 rfyZ5kxTAw4r for ; Wed, 17 May 2017 11:59:26 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 CC86E12EC01 for ; Wed, 17 May 2017 11:53:55 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id 70so20869518wmq.1 for ; Wed, 17 May 2017 11:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=fdMJ/0KoSGEM+XV/7FiXf2j4jalrU1FsMjCPgDjhFuM=; b=UZh/kR+6q8kUrj5MTXfyC/ljJ/iqKFUwd87UA00f85HnK3b/KnK32VPKbPbabS5WNK +OFaJnYOHI9ueb/VXuT214lKhZvvJpzYLemB2NON0obYAXK5FTzPU+zc34I+hnjDyXeG pWbb/tZEmJzMiaHFetRmih825p1rXfzdO91UDS6Sq+yjeeHcnrnKyq57eWrHADzqUHVr 2WM9T6uBQAX9wisrddGWr/jmGQv/+Ym7r8gEnHLtjuFV6fQAsQKklMkq0aTWQZSuHMjS o6TZBvWuUrBpu5E0HW4MJsBaDuP0GRotFln1FEKH2PuEGpRfgTrwbYxCg+6qxSB7kooD dmCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=fdMJ/0KoSGEM+XV/7FiXf2j4jalrU1FsMjCPgDjhFuM=; b=LBH5KC74HNqYtb+SG1XFqFRgLSDD6TzIpPC1HToSigOBqjMa3agwrY5YKfPdIkvR/4 M7UdA08wSWXZU6rplUjm9ourF8Vn1KBkVtMkuBhX5VHo+2zh/Byzhq9lxor3VcTFLUNj TGL5DUoKTn/tD8tGFAzoeixUz+TPW2UvfYnimmzTtlBtLJaf+6pbXG+Bp/b96Nb+CnQl d9+YMkjBUSClW8d8Lk2jph5ahjhcWPjvbQP2QurslnxOOMORl1x5u+Kxw+c2NepFEXsA p/ZmldeAJAywEzs90IMc7Hd3Y6nrvoFdVifUEINmspXIpmq4bz5odz/OyIZZh+OBFJCV BI3w== X-Gm-Message-State: AODbwcAB9/pQDOvuqSsOMCq0LknABzH9qUpy/hiVRxHKZTEwc+YnX762 fo2GYdv6eDG6zA== X-Received: by 10.28.197.11 with SMTP id v11mr13147200wmf.84.1495047234310; Wed, 17 May 2017 11:53:54 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id p187sm21983504wmd.24.2017.05.17.11.53.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 May 2017 11:53:53 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_4933EF24-806C-4704-9D31-AB352C6BD5D0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 17 May 2017 21:53:50 +0300 In-Reply-To: Cc: "IPsecme WG (ipsec@ietf.org)" To: "Scott Fluhrer (sfluhrer)" References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] Question about ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 18:59:28 -0000 --Apple-Mail=_4933EF24-806C-4704-9D31-AB352C6BD5D0 Content-Type: multipart/alternative; boundary="Apple-Mail=_6CCA82F1-0263-400A-897A-A0344D2E094E" --Apple-Mail=_6CCA82F1-0263-400A-897A-A0344D2E094E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 17 May 2017, at 20:39, Scott Fluhrer (sfluhrer) = wrote: >=20 > I=E2=80=99ve been looking over the draft, and I think I see a = potential DoS attack that does not appear to be addressed. I=E2=80=99m = writing this to see if there is something I missed (and if there = isn=E2=80=99t, start discussion on how we might patch things up). >=20 > This is the scenario I=E2=80=99m looking at: Alice and Bob have a = TCP-based IKE/IPsec connection established. >=20 > Then, Eve injects a TCP packet to Bob with Alice=E2=80=99s source IP = (and with the appropriate TCP sequence numbers), and whose body consists = of a single FF byte. Eve does nothing else than that (other than = possibly absorbing the TCP-ACK that Bob would send out, if that=E2=80=99d = confuse Alice=E2=80=99s TCP stack=E2=80=A6) >=20 > Alice will then send a legitimate packet, consisting of (for example) = [Length =3D 0x0124] [ESP Header][Body]. However, Bob=E2=80=99s TCP = stack thinks it has already received the first byte, and so it=E2=80=99ll = ignore it, and so will tell the application (IPsec) that it has received = [0xff34][ESP Header][Body]. My TCP may be rusty, but I think Alice=E2=80=99s legitimate packet has = the sequence number to indicate it is retransmitting the byte that Bob = already has. I don=E2=80=99t know if that means that the new data = overwrites the old data, that the old data remains, of that the stack = checks that it matches. > The IPsec packet parsing code would interpret this as an extremely = long encrypted packet, and so will continue to absorb the next 0xfe00 = bytes from Alice. >=20 > It=E2=80=99ll then try to decrypt it; it=E2=80=99ll fail. That, in = itself, is not that big of a deal; we assume that an attacker who can = modify packets at will is able to force a few packets to be dropped. >=20 > However, look what happens after that; the IPsec stream parsing code = will then take the next two bytes of the stream, and try to parse them = as =E2=80=98packet length=E2=80=99. We stopped at a random location = within the TCP stream, and so quite likely, we=E2=80=99re in the middle = of an encrypted packet, and so the length will be a random value. = We=E2=80=99ll then try to parse the next bytes as a packet, and this = will keep on going (blocking all Alice -> Bob traffic) until the = end-of-packet the IPsec stream parser assumes just happens to fall on an = actual packet boundary =E2=80=93 obviously, that might be a while. I agree. Once synchronization is lost, it may as well never be regained. > TLS uses a similar =E2=80=98record lengths appear in the TCP stream=E2=80= =99 concept; however in the case of TLS, on decryption failure, you MUST = close the connection (and so this repeated =E2=80=98get a random = sequence of bytes and try to decrypt=E2=80=99 isn=E2=80=99t an issue); I = didn=E2=80=99t see a similar mandate in the IPsec draft. >=20 >=20 > Was there something I missed? The draft does have the text: >=20 > If either TCP Originator or TCP Responder > receives a stream that cannot be parsed correctly (for example, if > the TCP Originator stream is missing the stream prefix, or message > frames are not parsable as IKE or ESP messages), it MUST close the > TCP connection. >=20 > However: > a) That=E2=80=99s in a paragraph that starts =E2=80=9CIf a TCP = connection is being used to resume a previous IKE session=E2=80=A6=E2=80=9D= ; does it apply only in that case? > b) An ESP message is of the form [SPI][Sequence number][Random = bytes]; unless you happen to get a SPI < 256 or length < 8, it=E2=80=99s = not clear how you could get something that is not of that format (unless = you mandate that the ESP length must be a multiple of 4 bytes; in that = case, you should state that explicitly) >=20 >=20 > Thoughts? I=E2=80=99d like to hear how TCP stacks really behave. That said, most of us feed the IPsec stack with packets generated on = networks with an MTU of 1500. Even if we add the IPsec over head on top = of that, it=E2=80=99s still less than 2.5% of the space afforded by a = 16-bit length field. At least for ESP packets. If the receiver were to break the connection whenever it received some = number (2? 3?) of packets that had a length field that exceeded 1544 = (or whatever the maximum packet is for the particular algorithm) = followed by an ESP field that was not zero, this would fix the problem = without letting Eve break the connection with just one injected byte. But there does seem to be something missing. Yoav --Apple-Mail=_6CCA82F1-0263-400A-897A-A0344D2E094E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 17 May 2017, at 20:39, Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com> = wrote:

I=E2=80=99ve been looking over the draft, and I think I see a = potential DoS attack that does not appear to be addressed.  I=E2=80=99= m writing this to see if there is something I missed (and if there = isn=E2=80=99t, start discussion on how we might patch things up).
 
This is = the scenario I=E2=80=99m looking at: Alice and Bob have a TCP-based = IKE/IPsec connection established.
 
Then, Eve injects a TCP packet to Bob = with Alice=E2=80=99s source IP (and with the appropriate TCP sequence = numbers), and whose body consists of a single FF byte.  Eve does = nothing else than that (other than possibly absorbing the TCP-ACK that = Bob would send out, if that=E2=80=99d confuse Alice=E2=80=99s TCP = stack=E2=80=A6)
 
Alice will then send a legitimate packet, consisting of (for = example) [Length =3D 0x0124] [ESP Header][Body].  However, Bob=E2=80=99= s TCP stack thinks it has already received the first byte, and so = it=E2=80=99ll ignore it, and so will tell the application (IPsec) that = it has received [0xff34][ESP = Header][Body].

My = TCP may be rusty, but I think Alice=E2=80=99s legitimate packet has the = sequence number to indicate it is retransmitting the byte that Bob = already has. I don=E2=80=99t know if that means that the new data = overwrites the old data, that the old data remains, of that the stack = checks that it matches.

The IPsec packet parsing code would = interpret this as an extremely long encrypted packet, and so will = continue to absorb the next 0xfe00 bytes from Alice.
 
It=E2=80=99= ll then try to decrypt it; it=E2=80=99ll fail.  That, in itself, is = not that big of a deal; we assume that an attacker who can modify = packets at will is able to force a few packets to be dropped.
 
However, = look what happens after that; the IPsec stream parsing code will then = take the next two bytes of the stream, and try to parse them as = =E2=80=98packet length=E2=80=99.  We stopped at a random location = within the TCP stream, and so quite likely, we=E2=80=99re in the middle = of an encrypted packet, and so the length will be a random value.  = We=E2=80=99ll then try to parse the next bytes as a packet, and this = will keep on going (blocking all Alice -> Bob traffic) until the = end-of-packet the IPsec stream parser assumes just happens to fall on an = actual packet boundary =E2=80=93 obviously, that might be a = while.

I agree. Once = synchronization is lost, it may as well never be regained.

TLS uses a similar =E2=80=98record lengths appear in the TCP = stream=E2=80=99 concept; however in the case of TLS, on decryption = failure, you MUST close the connection (and so this repeated =E2=80=98get = a random sequence of bytes and try to decrypt=E2=80=99 isn=E2=80=99t an = issue); I didn=E2=80=99t see a similar mandate in the IPsec draft.
 
 
Was there = something I missed?  The draft does have the text:
 
   If either = TCP Originator or TCP Responder
   receives a stream that cannot be parsed = correctly (for example, if
   the TCP Originator stream is missing the = stream prefix, or message
   frames are not parsable as IKE or ESP = messages), it MUST close the
   TCP connection.
 
However:
a)      That=E2=80=99s = in a paragraph that starts =E2=80=9CIf a TCP connection is being used to = resume a previous IKE session=E2=80=A6=E2=80=9D; does it apply only in = that case?
b)      An ESP = message is of the form [SPI][Sequence number][Random bytes]; unless you = happen to get a SPI < 256 or length < 8, it=E2=80=99s not clear = how you could get something that is not of that format (unless you = mandate that the ESP length must be a multiple of 4 bytes; in that case, = you should state that explicitly)
 
 
Thoughts?

I=E2=80=99d like to hear how TCP stacks really = behave.

That said, = most of us feed the IPsec stack with packets generated on networks with = an MTU of 1500. Even if we add the IPsec over head on top of that, = it=E2=80=99s still less than 2.5% of the space afforded by a 16-bit = length field. At least for ESP packets.

If the receiver were to break the = connection whenever it received some number (2?  3?) of packets = that had a length field that exceeded 1544 (or whatever the maximum = packet is for the particular algorithm) followed by an ESP field that = was not zero, this would fix the problem without letting Eve break the = connection with just one injected byte.

But there does seem to be something = missing.

Yoav

= --Apple-Mail=_6CCA82F1-0263-400A-897A-A0344D2E094E-- --Apple-Mail=_4933EF24-806C-4704-9D31-AB352C6BD5D0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZHJw/AAoJELhJCxUKWMyZGAYH/iEbxlYTv42dypnlUtNlUSpm FEaVEGuK3lUzpJkbJ01d0HMNtfk+CKOwVATWVE+EhLLinGgwyJwhlsSdkUSz10Dk PVfXQ2YVJCMOJ+GsQRm1vdGkkwSpTQeZjGtXudsxwxJYVd2YUH74g+EQIbPO4EN4 EgF3RNIml2mklUfT8uAHYo3WQUKr/EJsKtkwkgbbMB8TeFNtGbaznU2RoxNc8Q6q sLiLfwyNrbtEPdbgDbCapxUAd17pXOgfe1xzMVspMN6OHlk4fFQ+Pk7zQkuzN8ce zunjeVv54gT6usFP4QxkseidALnrPKOlOaZ7hDUGFyCR2UFvHIX3HwSEj1c53xs= =z+Py -----END PGP SIGNATURE----- --Apple-Mail=_4933EF24-806C-4704-9D31-AB352C6BD5D0-- From nobody Wed May 17 12:18:02 2017 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 2636A129B37 for ; Wed, 17 May 2017 12:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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=-0.001, SPF_HELO_PASS=-0.001, 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 W7Vn2IaleuBr for ; Wed, 17 May 2017 12:17:57 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86304129B8C for ; Wed, 17 May 2017 12:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31006; q=dns/txt; s=iport; t=1495048340; x=1496257940; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fKBdU4bXEIK2MOE6uxwHAsPi+VU4JEVF8wO/fkK/WN8=; b=T9nK+2iAxmqEgBGvxmI+09AYB7sY00JYVCLsSvPImYtlTSUgSz4SLDhT S3OYbK5nZQjFJGacf3jPax1+2iCGjWooniJMkW81FSwaTgKuw3YaBh8AN PJrcxWsgtQJ5YJjmPP6ZSvnPYAs7LpBRJJMbIz+sfrcwXrS2L0cZxLW0n w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAQANoBxZ/4kNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYoEMB4MgRooYkWeIJo1Pgg+GJAIahUU/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRgBAQEBAwwXBAZMEAIBBgIOAwQBASEHAwICAh8RFAkIAQEEDgUIigMDFY8mn?= =?us-ascii?q?WCBbDqHMQ2DRwEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GX4FegxuCVIFhC1mCXIJ?= =?us-ascii?q?gBZZzhmI7AY5HhEqRdosviRYBHziBCnAVhToDHIFjdoYrgS+BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,355,1491264000"; d="scan'208,217";a="236243320" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 May 2017 19:12:19 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v4HJCJ3d003245 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 May 2017 19:12:19 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 17 May 2017 15:12:18 -0400 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; Wed, 17 May 2017 15:12:18 -0400 From: "Scott Fluhrer (sfluhrer)" To: Yoav Nir CC: "IPsecme WG (ipsec@ietf.org)" Thread-Topic: [IPsec] Question about ipsecme-tcp-encaps Thread-Index: AdLPNI/2pFR/dDPhQiGtKCVpagxlHgAK+MEAAAg/uLA= Date: Wed, 17 May 2017 19:12:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.52] Content-Type: multipart/alternative; boundary="_000_ad741d35261b4ac8aede43c4a3a498c0XCHRTP006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Question about ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 19:18:00 -0000 --_000_ad741d35261b4ac8aede43c4a3a498c0XCHRTP006ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGcm9tOiBZb2F2IE5pciBbbWFpbHRvOnluaXIuaWV0ZkBnbWFpbC5jb21dDQpTZW50OiBXZWRu ZXNkYXksIE1heSAxNywgMjAxNyAyOjU0IFBNDQpUbzogU2NvdHQgRmx1aHJlciAoc2ZsdWhyZXIp DQpDYzogSVBzZWNtZSBXRyAoaXBzZWNAaWV0Zi5vcmcpDQpTdWJqZWN0OiBSZTogW0lQc2VjXSBR dWVzdGlvbiBhYm91dCBpcHNlY21lLXRjcC1lbmNhcHMNCg0KDQpPbiAxNyBNYXkgMjAxNywgYXQg MjA6MzksIFNjb3R0IEZsdWhyZXIgKHNmbHVocmVyKSA8c2ZsdWhyZXJAY2lzY28uY29tPG1haWx0 bzpzZmx1aHJlckBjaXNjby5jb20+PiB3cm90ZToNCg0KSeKAmXZlIGJlZW4gbG9va2luZyBvdmVy IHRoZSBkcmFmdCwgYW5kIEkgdGhpbmsgSSBzZWUgYSBwb3RlbnRpYWwgRG9TIGF0dGFjayB0aGF0 IGRvZXMgbm90IGFwcGVhciB0byBiZSBhZGRyZXNzZWQuICBJ4oCZbSB3cml0aW5nIHRoaXMgdG8g c2VlIGlmIHRoZXJlIGlzIHNvbWV0aGluZyBJIG1pc3NlZCAoYW5kIGlmIHRoZXJlIGlzbuKAmXQs IHN0YXJ0IGRpc2N1c3Npb24gb24gaG93IHdlIG1pZ2h0IHBhdGNoIHRoaW5ncyB1cCkuDQoNClRo aXMgaXMgdGhlIHNjZW5hcmlvIEnigJltIGxvb2tpbmcgYXQ6IEFsaWNlIGFuZCBCb2IgaGF2ZSBh IFRDUC1iYXNlZCBJS0UvSVBzZWMgY29ubmVjdGlvbiBlc3RhYmxpc2hlZC4NCg0KVGhlbiwgRXZl IGluamVjdHMgYSBUQ1AgcGFja2V0IHRvIEJvYiB3aXRoIEFsaWNl4oCZcyBzb3VyY2UgSVAgKGFu ZCB3aXRoIHRoZSBhcHByb3ByaWF0ZSBUQ1Agc2VxdWVuY2UgbnVtYmVycyksIGFuZCB3aG9zZSBi b2R5IGNvbnNpc3RzIG9mIGEgc2luZ2xlIEZGIGJ5dGUuICBFdmUgZG9lcyBub3RoaW5nIGVsc2Ug dGhhbiB0aGF0IChvdGhlciB0aGFuIHBvc3NpYmx5IGFic29yYmluZyB0aGUgVENQLUFDSyB0aGF0 IEJvYiB3b3VsZCBzZW5kIG91dCwgaWYgdGhhdOKAmWQgY29uZnVzZSBBbGljZeKAmXMgVENQIHN0 YWNr4oCmKQ0KDQpBbGljZSB3aWxsIHRoZW4gc2VuZCBhIGxlZ2l0aW1hdGUgcGFja2V0LCBjb25z aXN0aW5nIG9mIChmb3IgZXhhbXBsZSkgW0xlbmd0aCA9IDB4MDEyNF0gW0VTUCBIZWFkZXJdW0Jv ZHldLiAgSG93ZXZlciwgQm9i4oCZcyBUQ1Agc3RhY2sgdGhpbmtzIGl0IGhhcyBhbHJlYWR5IHJl Y2VpdmVkIHRoZSBmaXJzdCBieXRlLCBhbmQgc28gaXTigJlsbCBpZ25vcmUgaXQsIGFuZCBzbyB3 aWxsIHRlbGwgdGhlIGFwcGxpY2F0aW9uIChJUHNlYykgdGhhdCBpdCBoYXMgcmVjZWl2ZWQgWzB4 ZmYzNF1bRVNQIEhlYWRlcl1bQm9keV0uDQoNCk15IFRDUCBtYXkgYmUgcnVzdHksIGJ1dCBJIHRo aW5rIEFsaWNl4oCZcyBsZWdpdGltYXRlIHBhY2tldCBoYXMgdGhlIHNlcXVlbmNlIG51bWJlciB0 byBpbmRpY2F0ZSBpdCBpcyByZXRyYW5zbWl0dGluZyB0aGUgYnl0ZSB0aGF0IEJvYiBhbHJlYWR5 IGhhcy4gSSBkb27igJl0IGtub3cgaWYgdGhhdCBtZWFucyB0aGF0IHRoZSBuZXcgZGF0YSBvdmVy d3JpdGVzIHRoZSBvbGQgZGF0YSwgdGhhdCB0aGUgb2xkIGRhdGEgcmVtYWlucywgb2YgdGhhdCB0 aGUgc3RhY2sgY2hlY2tzIHRoYXQgaXQgbWF0Y2hlcy4NCg0KSSBkb27igJl0IHRoaW5rIGl04oCZ cyBkZWZpbmVkIHdpdGhpbiBUQ1AgKHJhdGhlciwgaXTigJlzIHVwIHRvIHRoZSBpbmRpdmlkdWFs IHN0YWNrKTsgb24gdGhlIG90aGVyIGhhbmQsIGluIGdlbmVyYWwsIHRoZSBUQ1Agc3RhY2sgaGFz IGFscmVhZHkgaGFuZGVkIG9mZiB0aGUgYnl0ZSB0byB0aGUgYXBwbGljYXRpb24gKHRoZSBJUHNl YyBwYWNrZXQgc3RyZWFtIHBhcnNlciksIGFuZCBzbyBpdCAqY2Fu4oCZdCogb3ZlcndyaXRlIGl0 Lg0KDQpPZiBjb3Vyc2UsIHdlIGNvdWxkIHNheSDigJxFdmUgbW9kaWZpZXMgYSB2YWxpZCBUQ1At ZW5jYXBzdWxhdGVkIElQc2VjIHBhY2tldCBzbyB0aGF0IHRoZSBmaXJzdCBieXRlIGlzIDB4Zmbi gJ0sIGFuZCB3ZSBoYXZlIHRoZSBzYW1lIGF0dGFja+KApg0KDQoNClRoZSBJUHNlYyBwYWNrZXQg cGFyc2luZyBjb2RlIHdvdWxkIGludGVycHJldCB0aGlzIGFzIGFuIGV4dHJlbWVseSBsb25nIGVu Y3J5cHRlZCBwYWNrZXQsIGFuZCBzbyB3aWxsIGNvbnRpbnVlIHRvIGFic29yYiB0aGUgbmV4dCAw eGZlMDAgYnl0ZXMgZnJvbSBBbGljZS4NCg0KSXTigJlsbCB0aGVuIHRyeSB0byBkZWNyeXB0IGl0 OyBpdOKAmWxsIGZhaWwuICBUaGF0LCBpbiBpdHNlbGYsIGlzIG5vdCB0aGF0IGJpZyBvZiBhIGRl YWw7IHdlIGFzc3VtZSB0aGF0IGFuIGF0dGFja2VyIHdobyBjYW4gbW9kaWZ5IHBhY2tldHMgYXQg d2lsbCBpcyBhYmxlIHRvIGZvcmNlIGEgZmV3IHBhY2tldHMgdG8gYmUgZHJvcHBlZC4NCg0KSG93 ZXZlciwgbG9vayB3aGF0IGhhcHBlbnMgYWZ0ZXIgdGhhdDsgdGhlIElQc2VjIHN0cmVhbSBwYXJz aW5nIGNvZGUgd2lsbCB0aGVuIHRha2UgdGhlIG5leHQgdHdvIGJ5dGVzIG9mIHRoZSBzdHJlYW0s IGFuZCB0cnkgdG8gcGFyc2UgdGhlbSBhcyDigJhwYWNrZXQgbGVuZ3Ro4oCZLiAgV2Ugc3RvcHBl ZCBhdCBhIHJhbmRvbSBsb2NhdGlvbiB3aXRoaW4gdGhlIFRDUCBzdHJlYW0sIGFuZCBzbyBxdWl0 ZSBsaWtlbHksIHdl4oCZcmUgaW4gdGhlIG1pZGRsZSBvZiBhbiBlbmNyeXB0ZWQgcGFja2V0LCBh bmQgc28gdGhlIGxlbmd0aCB3aWxsIGJlIGEgcmFuZG9tIHZhbHVlLiAgV2XigJlsbCB0aGVuIHRy eSB0byBwYXJzZSB0aGUgbmV4dCBieXRlcyBhcyBhIHBhY2tldCwgYW5kIHRoaXMgd2lsbCBrZWVw IG9uIGdvaW5nIChibG9ja2luZyBhbGwgQWxpY2UgLT4gQm9iIHRyYWZmaWMpIHVudGlsIHRoZSBl bmQtb2YtcGFja2V0IHRoZSBJUHNlYyBzdHJlYW0gcGFyc2VyIGFzc3VtZXMganVzdCBoYXBwZW5z IHRvIGZhbGwgb24gYW4gYWN0dWFsIHBhY2tldCBib3VuZGFyeSDigJMgb2J2aW91c2x5LCB0aGF0 IG1pZ2h0IGJlIGEgd2hpbGUuDQoNCkkgYWdyZWUuIE9uY2Ugc3luY2hyb25pemF0aW9uIGlzIGxv c3QsIGl0IG1heSBhcyB3ZWxsIG5ldmVyIGJlIHJlZ2FpbmVkLg0KDQoNClRMUyB1c2VzIGEgc2lt aWxhciDigJhyZWNvcmQgbGVuZ3RocyBhcHBlYXIgaW4gdGhlIFRDUCBzdHJlYW3igJkgY29uY2Vw dDsgaG93ZXZlciBpbiB0aGUgY2FzZSBvZiBUTFMsIG9uIGRlY3J5cHRpb24gZmFpbHVyZSwgeW91 IE1VU1QgY2xvc2UgdGhlIGNvbm5lY3Rpb24gKGFuZCBzbyB0aGlzIHJlcGVhdGVkIOKAmGdldCBh IHJhbmRvbSBzZXF1ZW5jZSBvZiBieXRlcyBhbmQgdHJ5IHRvIGRlY3J5cHTigJkgaXNu4oCZdCBh biBpc3N1ZSk7IEkgZGlkbuKAmXQgc2VlIGEgc2ltaWxhciBtYW5kYXRlIGluIHRoZSBJUHNlYyBk cmFmdC4NCg0KDQpXYXMgdGhlcmUgc29tZXRoaW5nIEkgbWlzc2VkPyAgVGhlIGRyYWZ0IGRvZXMg aGF2ZSB0aGUgdGV4dDoNCg0KICAgSWYgZWl0aGVyIFRDUCBPcmlnaW5hdG9yIG9yIFRDUCBSZXNw b25kZXINCiAgIHJlY2VpdmVzIGEgc3RyZWFtIHRoYXQgY2Fubm90IGJlIHBhcnNlZCBjb3JyZWN0 bHkgKGZvciBleGFtcGxlLCBpZg0KICAgdGhlIFRDUCBPcmlnaW5hdG9yIHN0cmVhbSBpcyBtaXNz aW5nIHRoZSBzdHJlYW0gcHJlZml4LCBvciBtZXNzYWdlDQogICBmcmFtZXMgYXJlIG5vdCBwYXJz YWJsZSBhcyBJS0Ugb3IgRVNQIG1lc3NhZ2VzKSwgaXQgTVVTVCBjbG9zZSB0aGUNCiAgIFRDUCBj b25uZWN0aW9uLg0KDQpIb3dldmVyOg0KYSkgICAgICBUaGF04oCZcyBpbiBhIHBhcmFncmFwaCB0 aGF0IHN0YXJ0cyDigJxJZiBhIFRDUCBjb25uZWN0aW9uIGlzIGJlaW5nIHVzZWQgdG8gcmVzdW1l IGEgcHJldmlvdXMgSUtFIHNlc3Npb27igKbigJ07IGRvZXMgaXQgYXBwbHkgb25seSBpbiB0aGF0 IGNhc2U/DQpiKSAgICAgIEFuIEVTUCBtZXNzYWdlIGlzIG9mIHRoZSBmb3JtIFtTUEldW1NlcXVl bmNlIG51bWJlcl1bUmFuZG9tIGJ5dGVzXTsgdW5sZXNzIHlvdSBoYXBwZW4gdG8gZ2V0IGEgU1BJ IDwgMjU2IG9yIGxlbmd0aCA8IDgsIGl04oCZcyBub3QgY2xlYXIgaG93IHlvdSBjb3VsZCBnZXQg c29tZXRoaW5nIHRoYXQgaXMgbm90IG9mIHRoYXQgZm9ybWF0ICh1bmxlc3MgeW91IG1hbmRhdGUg dGhhdCB0aGUgRVNQIGxlbmd0aCBtdXN0IGJlIGEgbXVsdGlwbGUgb2YgNCBieXRlczsgaW4gdGhh dCBjYXNlLCB5b3Ugc2hvdWxkIHN0YXRlIHRoYXQgZXhwbGljaXRseSkNCg0KDQpUaG91Z2h0cz8N Cg0KSeKAmWQgbGlrZSB0byBoZWFyIGhvdyBUQ1Agc3RhY2tzIHJlYWxseSBiZWhhdmUuDQoNClRo YXQgc2FpZCwgbW9zdCBvZiB1cyBmZWVkIHRoZSBJUHNlYyBzdGFjayB3aXRoIHBhY2tldHMgZ2Vu ZXJhdGVkIG9uIG5ldHdvcmtzIHdpdGggYW4gTVRVIG9mIDE1MDAuIEV2ZW4gaWYgd2UgYWRkIHRo ZSBJUHNlYyBvdmVyIGhlYWQgb24gdG9wIG9mIHRoYXQsIGl04oCZcyBzdGlsbCBsZXNzIHRoYW4g Mi41JSBvZiB0aGUgc3BhY2UgYWZmb3JkZWQgYnkgYSAxNi1iaXQgbGVuZ3RoIGZpZWxkLiBBdCBs ZWFzdCBmb3IgRVNQIHBhY2tldHMuDQoNCklmIHRoZSByZWNlaXZlciB3ZXJlIHRvIGJyZWFrIHRo ZSBjb25uZWN0aW9uIHdoZW5ldmVyIGl0IHJlY2VpdmVkIHNvbWUgbnVtYmVyICgyPyAgMz8pIG9m IHBhY2tldHMgdGhhdCBoYWQgYSBsZW5ndGggZmllbGQgdGhhdCBleGNlZWRlZCAxNTQ0IChvciB3 aGF0ZXZlciB0aGUgbWF4aW11bSBwYWNrZXQgaXMgZm9yIHRoZSBwYXJ0aWN1bGFyIGFsZ29yaXRo bSkgZm9sbG93ZWQgYnkgYW4gRVNQIGZpZWxkIHRoYXQgd2FzIG5vdCB6ZXJvLA0KDQrigJxFU1Ag ZmllbGTigJ07IGRvIHlvdSBtZWFuIFNQST8NCg0KdGhpcyB3b3VsZCBmaXggdGhlIHByb2JsZW0g d2l0aG91dCBsZXR0aW5nIEV2ZSBicmVhayB0aGUgY29ubmVjdGlvbiB3aXRoIGp1c3Qgb25lIGlu amVjdGVkIGJ5dGUuDQoNCkkgZiB5b3UgZG9u4oCZdOKAmSB1c2UgSUtFIGZyYWdtZW50YXRpb24s IHRoZW4gSSBiZWxpZXZlIElLRSBwYWNrZXRzIGNvdWxkIGJlIG92ZXIgdGhlIGxpbWl0IHdlIHBp Y2tlZCAodW5sZXNzIHdlIHBpY2tlZCBhIHJhdGhlciBjb25zZXJ2YXRpdmUgb25lKTsgd291bGQg dGhhdCBiZSBhbiBpc3N1ZT8gIFNvLCB3YXMgdGhhdCBzb21ldGhpbmcgeW91IHdlcmUgdHJ5aW5n IHRvIGFkZHJlc3Mgd2l0aCB0aGUgRVNQIGZpZWxkIGFib3ZlPw0KDQoNCkJ1dCB0aGVyZSBkb2Vz IHNlZW0gdG8gYmUgc29tZXRoaW5nIG1pc3NpbmcuDQoNCkEgbW9yZSBwcmVkaWN0YWJsZSB3YXMg dG8gZGV0ZWN0IGxvc3Mtb2Ytc3luY2hyb25pemF0aW9uIGJldHdlZW4gdGhlIHNlbmRlciBhbmQg dGhlIHJlY2VpdmVyIHdvdWxkIGJlIHRvIGluY2x1ZGUgb25lIG9yIHR3byBmaXhlZCAob3IgcHJl ZGljdGFibGUpIGJ5dGVzIGluIHRoZSBoZWFkZXIgKGFsb25nIHdpdGggdGhlIExlbmd0aCBmaWVs ZCk7IHRoaXMgd291bGQgbWVhbiB0aGF0IHdlIHdvdWxkIGhhdmUgcXVpdGUgaGlnaCBwcm9iYWJp bGl0eSBvZiBkZXRlY3Rpbmcgc3luYyBsb3NzLCB3aXRob3V0IGhhdmluZyBhbiBhcmJpdHJhcnkg bGVuZ3RoIGxpbWl0IG9uIHRoZSBlbmNyeXB0ZWQgcmVnaW9uLiAgSWYgd2UgcGljayBhIDIgYnl0 ZSB2YWx1ZSwgdGhhdCBtZWFucyB0aGF0IHRoaW5ncyBzdGF5IG9uIDQgYnl0ZSBib3VuZGFyaWVz 4oCmDQoNCllvYXYNCg0K --_000_ad741d35261b4ac8aede43c4a3a498c0XCHRTP006ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uYXBwbGUtY29udmVy dGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFu LkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxs b29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gWW9hdiBOaXIgW21h aWx0bzp5bmlyLmlldGZAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwg TWF5IDE3LCAyMDE3IDI6NTQgUE08YnI+DQo8Yj5Ubzo8L2I+IFNjb3R0IEZsdWhyZXIgKHNmbHVo cmVyKTxicj4NCjxiPkNjOjwvYj4gSVBzZWNtZSBXRyAoaXBzZWNAaWV0Zi5vcmcpPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbSVBzZWNdIFF1ZXN0aW9uIGFib3V0IGlwc2VjbWUtdGNwLWVuY2Fw czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDE3 IE1heSAyMDE3LCBhdCAyMDozOSwgU2NvdHQgRmx1aHJlciAoc2ZsdWhyZXIpICZsdDs8YSBocmVm PSJtYWlsdG86c2ZsdWhyZXJAY2lzY28uY29tIj5zZmx1aHJlckBjaXNjby5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SeKAmXZlIGJlZW4gbG9va2luZyBvdmVyIHRoZSBkcmFm dCwgYW5kIEkgdGhpbmsgSSBzZWUgYSBwb3RlbnRpYWwgRG9TIGF0dGFjayB0aGF0IGRvZXMgbm90 IGFwcGVhciB0byBiZSBhZGRyZXNzZWQuJm5ic3A7IEnigJltIHdyaXRpbmcgdGhpcyB0byBzZWUg aWYgdGhlcmUgaXMgc29tZXRoaW5nIEkgbWlzc2VkIChhbmQNCiBpZiB0aGVyZSBpc27igJl0LCBz dGFydCBkaXNjdXNzaW9uIG9uIGhvdyB3ZSBtaWdodCBwYXRjaCB0aGluZ3MgdXApLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5UaGlzIGlzIHRoZSBzY2VuYXJpbyBJ4oCZbSBsb29raW5nIGF0OiBBbGljZSBhbmQgQm9i IGhhdmUgYSBUQ1AtYmFzZWQgSUtFL0lQc2VjIGNvbm5lY3Rpb24gZXN0YWJsaXNoZWQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPlRoZW4sIEV2ZSBpbmplY3RzIGEgVENQIHBhY2tldCB0byBCb2Igd2l0aCBBbGljZeKA mXMgc291cmNlIElQIChhbmQgd2l0aCB0aGUgYXBwcm9wcmlhdGUgVENQIHNlcXVlbmNlIG51bWJl cnMpLCBhbmQgd2hvc2UgYm9keSBjb25zaXN0cyBvZiBhIHNpbmdsZSBGRiBieXRlLiZuYnNwOyBF dmUgZG9lcyBub3RoaW5nDQogZWxzZSB0aGFuIHRoYXQgKG90aGVyIHRoYW4gcG9zc2libHkgYWJz b3JiaW5nIHRoZSBUQ1AtQUNLIHRoYXQgQm9iIHdvdWxkIHNlbmQgb3V0LCBpZiB0aGF04oCZZCBj b25mdXNlIEFsaWNl4oCZcyBUQ1Agc3RhY2vigKYpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFsaWNlIHdpbGwgdGhl biBzZW5kIGEgbGVnaXRpbWF0ZSBwYWNrZXQsIGNvbnNpc3Rpbmcgb2YgKGZvciBleGFtcGxlKSBb TGVuZ3RoID0gMHgwMTI0XSBbRVNQIEhlYWRlcl1bQm9keV0uJm5ic3A7IEhvd2V2ZXIsIEJvYuKA mXMgVENQIHN0YWNrIHRoaW5rcyBpdCBoYXMgYWxyZWFkeSByZWNlaXZlZCB0aGUgZmlyc3QNCiBi eXRlLCBhbmQgc28gaXTigJlsbCBpZ25vcmUgaXQsIGFuZCBzbyB3aWxsIHRlbGwgdGhlIGFwcGxp Y2F0aW9uIChJUHNlYykgdGhhdCBpdCBoYXMgcmVjZWl2ZWQgWzB4ZmYzNF1bRVNQIEhlYWRlcl1b Qm9keV0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgVENQIG1heSBiZSBydXN0eSwgYnV0IEkgdGhp bmsgQWxpY2XigJlzIGxlZ2l0aW1hdGUgcGFja2V0IGhhcyB0aGUgc2VxdWVuY2UgbnVtYmVyIHRv IGluZGljYXRlIGl0IGlzIHJldHJhbnNtaXR0aW5nIHRoZSBieXRlIHRoYXQgQm9iIGFscmVhZHkg aGFzLiBJIGRvbuKAmXQga25vdyBpZiB0aGF0IG1lYW5zIHRoYXQgdGhlIG5ldyBkYXRhIG92ZXJ3 cml0ZXMgdGhlIG9sZCBkYXRhLCB0aGF0IHRoZSBvbGQgZGF0YSByZW1haW5zLA0KIG9mIHRoYXQg dGhlIHN0YWNrIGNoZWNrcyB0aGF0IGl0IG1hdGNoZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCB0aGluayBpdOKA mXMgZGVmaW5lZCB3aXRoaW4gVENQIChyYXRoZXIsIGl04oCZcyB1cCB0byB0aGUgaW5kaXZpZHVh bCBzdGFjayk7IG9uIHRoZSBvdGhlciBoYW5kLCBpbiBnZW5lcmFsLCB0aGUgVENQIHN0YWNrIGhh cyBhbHJlYWR5IGhhbmRlZCBvZmYgdGhlIGJ5dGUNCiB0byB0aGUgYXBwbGljYXRpb24gKHRoZSBJ UHNlYyBwYWNrZXQgc3RyZWFtIHBhcnNlciksIGFuZCBzbyBpdCAqPGI+Y2Fu4oCZdDwvYj4qIG92 ZXJ3cml0ZSBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9mIGNvdXJzZSwgd2UgY291bGQgc2F5IOKAnEV2ZSBtb2Rp ZmllcyBhIHZhbGlkIFRDUC1lbmNhcHN1bGF0ZWQgSVBzZWMgcGFja2V0IHNvIHRoYXQgdGhlIGZp cnN0IGJ5dGUgaXMgMHhmZuKAnSwgYW5kIHdlIGhhdmUgdGhlIHNhbWUgYXR0YWNr4oCmPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGUgSVBzZWMgcGFja2V0IHBhcnNpbmcgY29kZSB3 b3VsZCBpbnRlcnByZXQgdGhpcyBhcyBhbiBleHRyZW1lbHkgbG9uZyBlbmNyeXB0ZWQgcGFja2V0 LCBhbmQgc28gd2lsbCBjb250aW51ZSB0byBhYnNvcmIgdGhlIG5leHQgMHhmZTAwIGJ5dGVzIGZy b20gQWxpY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkl04oCZbGwgdGhlbiB0cnkgdG8gZGVjcnlwdCBpdDsgaXTi gJlsbCBmYWlsLiZuYnNwOyBUaGF0LCBpbiBpdHNlbGYsIGlzIG5vdCB0aGF0IGJpZyBvZiBhIGRl YWw7IHdlIGFzc3VtZSB0aGF0IGFuIGF0dGFja2VyIHdobyBjYW4gbW9kaWZ5IHBhY2tldHMgYXQg d2lsbCBpcyBhYmxlIHRvIGZvcmNlIGEgZmV3IHBhY2tldHMNCiB0byBiZSBkcm9wcGVkLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Ib3dldmVyLCBsb29rIHdoYXQgaGFwcGVucyBhZnRlciB0aGF0OyB0aGUgSVBzZWMg c3RyZWFtIHBhcnNpbmcgY29kZSB3aWxsIHRoZW4gdGFrZSB0aGUgbmV4dCB0d28gYnl0ZXMgb2Yg dGhlIHN0cmVhbSwgYW5kIHRyeSB0byBwYXJzZSB0aGVtIGFzIOKAmHBhY2tldCBsZW5ndGjigJku Jm5ic3A7IFdlIHN0b3BwZWQNCiBhdCBhIHJhbmRvbSBsb2NhdGlvbiB3aXRoaW4gdGhlIFRDUCBz dHJlYW0sIGFuZCBzbyBxdWl0ZSBsaWtlbHksIHdl4oCZcmUgaW4gdGhlIG1pZGRsZSBvZiBhbiBl bmNyeXB0ZWQgcGFja2V0LCBhbmQgc28gdGhlIGxlbmd0aCB3aWxsIGJlIGEgcmFuZG9tIHZhbHVl LiZuYnNwOyBXZeKAmWxsIHRoZW4gdHJ5IHRvIHBhcnNlIHRoZSBuZXh0IGJ5dGVzIGFzIGEgcGFj a2V0LCBhbmQgdGhpcyB3aWxsIGtlZXAgb24gZ29pbmcgKGJsb2NraW5nIGFsbCBBbGljZSAtJmd0 OyBCb2INCiB0cmFmZmljKSB1bnRpbCB0aGUgZW5kLW9mLXBhY2tldCB0aGUgSVBzZWMgc3RyZWFt IHBhcnNlciBhc3N1bWVzIGp1c3QgaGFwcGVucyB0byBmYWxsIG9uIGFuIGFjdHVhbCBwYWNrZXQg Ym91bmRhcnkg4oCTIG9idmlvdXNseSwgdGhhdCBtaWdodCBiZSBhIHdoaWxlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlLiBPbmNl IHN5bmNocm9uaXphdGlvbiBpcyBsb3N0LCBpdCBtYXkgYXMgd2VsbCBuZXZlciBiZSByZWdhaW5l ZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VExTIHVzZXMgYSBzaW1pbGFyIOKAmHJlY29yZCBs ZW5ndGhzIGFwcGVhciBpbiB0aGUgVENQIHN0cmVhbeKAmSBjb25jZXB0OyBob3dldmVyIGluIHRo ZSBjYXNlIG9mIFRMUywgb24gZGVjcnlwdGlvbiBmYWlsdXJlLCB5b3UgTVVTVCBjbG9zZSB0aGUg Y29ubmVjdGlvbiAoYW5kIHNvIHRoaXMgcmVwZWF0ZWQNCiDigJhnZXQgYSByYW5kb20gc2VxdWVu Y2Ugb2YgYnl0ZXMgYW5kIHRyeSB0byBkZWNyeXB04oCZIGlzbuKAmXQgYW4gaXNzdWUpOyBJIGRp ZG7igJl0IHNlZSBhIHNpbWlsYXIgbWFuZGF0ZSBpbiB0aGUgSVBzZWMgZHJhZnQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+V2FzIHRoZXJlIHNvbWV0 aGluZyBJIG1pc3NlZD8mbmJzcDsgVGhlIGRyYWZ0IGRvZXMgaGF2ZSB0aGUgdGV4dDo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsg SWYgZWl0aGVyIFRDUCBPcmlnaW5hdG9yIG9yIFRDUCBSZXNwb25kZXI8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHJlY2VpdmVzIGEg c3RyZWFtIHRoYXQgY2Fubm90IGJlIHBhcnNlZCBjb3JyZWN0bHkgKGZvciBleGFtcGxlLCBpZjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsgdGhlIFRDUCBPcmlnaW5hdG9yIHN0cmVhbSBpcyBtaXNzaW5nIHRoZSBzdHJlYW0gcHJlZml4 LCBvciBtZXNzYWdlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyBmcmFtZXMgYXJlIG5vdCBwYXJzYWJsZSBhcyBJS0Ugb3IgRVNQIG1l c3NhZ2VzKSwgaXQgTVVTVCBjbG9zZSB0aGU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFRDUCBjb25uZWN0aW9uLjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Ib3dldmVyOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6Ljc1aW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5hKTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ VGhhdOKAmXMNCiBpbiBhIHBhcmFncmFwaCB0aGF0IHN0YXJ0cyDigJxJZiBhIFRDUCBjb25uZWN0 aW9uIGlzIGJlaW5nIHVzZWQgdG8gcmVzdW1lIGEgcHJldmlvdXMgSUtFIHNlc3Npb27igKbigJ07 IGRvZXMgaXQgYXBwbHkgb25seSBpbiB0aGF0IGNhc2U/PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNzVpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPmIpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Bbg0KIEVTUCBtZXNz YWdlIGlzIG9mIHRoZSBmb3JtIFtTUEldW1NlcXVlbmNlIG51bWJlcl1bUmFuZG9tIGJ5dGVzXTsg dW5sZXNzIHlvdSBoYXBwZW4gdG8gZ2V0IGEgU1BJICZsdDsgMjU2IG9yIGxlbmd0aCAmbHQ7IDgs IGl04oCZcyBub3QgY2xlYXIgaG93IHlvdSBjb3VsZCBnZXQgc29tZXRoaW5nIHRoYXQgaXMgbm90 IG9mIHRoYXQgZm9ybWF0ICh1bmxlc3MgeW91IG1hbmRhdGUgdGhhdCB0aGUgRVNQIGxlbmd0aCBt dXN0IGJlIGEgbXVsdGlwbGUgb2YgNCBieXRlczsNCiBpbiB0aGF0IGNhc2UsIHlvdSBzaG91bGQg c3RhdGUgdGhhdCBleHBsaWNpdGx5KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6Ljc1aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhvdWdodHM/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SeKAmWQgbGlrZSB0byBoZWFyIGhvdyBUQ1Agc3RhY2tzIHJlYWxseSBiZWhhdmUuPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IHNhaWQsIG1vc3Qgb2Yg dXMgZmVlZCB0aGUgSVBzZWMgc3RhY2sgd2l0aCBwYWNrZXRzIGdlbmVyYXRlZCBvbiBuZXR3b3Jr cyB3aXRoIGFuIE1UVSBvZiAxNTAwLiBFdmVuIGlmIHdlIGFkZCB0aGUgSVBzZWMgb3ZlciBoZWFk IG9uIHRvcCBvZiB0aGF0LCBpdOKAmXMgc3RpbGwgbGVzcyB0aGFuIDIuNSUgb2YgdGhlIHNwYWNl IGFmZm9yZGVkIGJ5IGEgMTYtYml0IGxlbmd0aCBmaWVsZC4gQXQgbGVhc3QgZm9yDQogRVNQIHBh Y2tldHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPklmIHRoZSByZWNlaXZlciB3ZXJlIHRvIGJyZWFrIHRoZSBjb25uZWN0aW9uIHdoZW5ldmVy IGl0IHJlY2VpdmVkIHNvbWUgbnVtYmVyICgyPyAmbmJzcDszPykgb2YgcGFja2V0cyB0aGF0IGhh ZCBhIGxlbmd0aCBmaWVsZCB0aGF0IGV4Y2VlZGVkIDE1NDQgKG9yIHdoYXRldmVyIHRoZSBtYXhp bXVtIHBhY2tldCBpcyBmb3IgdGhlIHBhcnRpY3VsYXIgYWxnb3JpdGhtKSBmb2xsb3dlZCBieSBh biBFU1AgZmllbGQgdGhhdA0KIHdhcyBub3QgemVybyw8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj7igJxFU1AgZmllbGTigJ07IGRvIHlvdSBtZWFuIFNQST88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+dGhpcyB3b3VsZCBmaXggdGhlIHByb2JsZW0gd2l0aG91dCBsZXR0aW5n IEV2ZSBicmVhayB0aGUgY29ubmVjdGlvbiB3aXRoIGp1c3Qgb25lIGluamVjdGVkIGJ5dGUuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkkgZiB5b3UgZG9u4oCZdOKAmSB1c2UgSUtFIGZyYWdtZW50YXRpb24sIHRoZW4gSSBiZWxpZXZl IElLRSBwYWNrZXRzIGNvdWxkIGJlIG92ZXIgdGhlIGxpbWl0IHdlIHBpY2tlZCAodW5sZXNzIHdl IHBpY2tlZCBhIHJhdGhlciBjb25zZXJ2YXRpdmUgb25lKTsgd291bGQgdGhhdA0KIGJlIGFuIGlz c3VlPyZuYnNwOyBTbywgd2FzIHRoYXQgc29tZXRoaW5nIHlvdSB3ZXJlIHRyeWluZyB0byBhZGRy ZXNzIHdpdGggdGhlIEVTUCBmaWVsZCBhYm92ZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkJ1dCB0aGVyZSBkb2VzIHNlZW0gdG8gYmUgc29tZXRoaW5nIG1pc3NpbmcuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkEg bW9yZSBwcmVkaWN0YWJsZSB3YXMgdG8gZGV0ZWN0IGxvc3Mtb2Ytc3luY2hyb25pemF0aW9uIGJl dHdlZW4gdGhlIHNlbmRlciBhbmQgdGhlIHJlY2VpdmVyIHdvdWxkIGJlIHRvIGluY2x1ZGUgb25l IG9yIHR3byBmaXhlZCAob3IgcHJlZGljdGFibGUpIGJ5dGVzIGluDQogdGhlIGhlYWRlciAoYWxv bmcgd2l0aCB0aGUgTGVuZ3RoIGZpZWxkKTsgdGhpcyB3b3VsZCBtZWFuIHRoYXQgd2Ugd291bGQg aGF2ZSBxdWl0ZSBoaWdoIHByb2JhYmlsaXR5IG9mIGRldGVjdGluZyBzeW5jIGxvc3MsIHdpdGhv dXQgaGF2aW5nIGFuIGFyYml0cmFyeSBsZW5ndGggbGltaXQgb24gdGhlIGVuY3J5cHRlZCByZWdp b24uJm5ic3A7IElmIHdlIHBpY2sgYSAyIGJ5dGUgdmFsdWUsIHRoYXQgbWVhbnMgdGhhdCB0aGlu Z3Mgc3RheSBvbiA0IGJ5dGUNCiBib3VuZGFyaWVz4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb2F2PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_ad741d35261b4ac8aede43c4a3a498c0XCHRTP006ciscocom_-- From nobody Wed May 17 12:45:37 2017 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 109E112009C for ; Wed, 17 May 2017 12:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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=-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=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 fH9ni5GyX1aN for ; Wed, 17 May 2017 12:45:33 -0700 (PDT) Received: from mail-in21.apple.com (mail-out21.apple.com [17.171.2.31]) (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 728D0127342 for ; Wed, 17 May 2017 12:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1495050228; 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=fcKaNNLp95iCMznONWgg9pMCGkWGzHkNbOtz5AR2JzY=; b=bnkWrmZY8+S4FKyfsZcDXp6NxNvd2RgFDThwc6MI8S4xYbskXYKOdmwrbpqTvXxL geppesUErw5hYuJEoJ1tgMq6mtn6xZ1yIaiagtkkGWi0cor0lzCCxFZiKvW2UDmV 8/WQci4p2IcVJ1EC09xeAsp6rtErprOTxxi0KEmu0amPh/k2dV0y58UZYNmwNQMy wsLXvvz/V8G4UY6MMphD7uf8I5ElBT0DbENQ0sh10sbf0VImUHIIqGKGQRezAZVE +83Zijf0lRawUaZxRA0KKC/qcYJgwqMOUQa+X2sr1PY980PHAfBEj6SgihPM2494 yrIwFgyOhansmF6UCrn8hA==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in21.apple.com (Apple Secure Mail Relay) with SMTP id E3.57.07494.3F7AC195; Wed, 17 May 2017 12:43:48 -0700 (PDT) X-AuditID: 11ab0215-5a4039a000001d46-08-591ca7f302a6 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 C8.64.07829.3F7AC195; Wed, 17 May 2017 12:43:47 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_tI/Esrwx1toT1970JctXcg)" Received: from [17.226.23.72] (unknown [17.226.23.72]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OQ400J7Y44Y6G90@nwk-mmpp-sz12.apple.com>; Wed, 17 May 2017 12:43:47 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <12068173-33D1-4D03-B07E-2C84FF012669@apple.com> Date: Wed, 17 May 2017 12:43:46 -0700 In-reply-to: Cc: Yoav Nir , "IPsecme WG (ipsec@ietf.org)" To: "Scott Fluhrer (sfluhrer)" References: X-Mailer: Apple Mail (2.3263) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUi2FDorPtluUykQf8rTov9W16wWUxt8bNY euwDkwOzx5TfG1k9ds66y+6xZMlPpgDmKC6blNSczLLUIn27BK6Msz82sBScXMpUMePjd/YG xvd/GLsYOTkkBEwkpk7uZupi5OIQEljDJPFu/yu4xNZZx1lAbCGBQ4wSnxYIgNi8AoISPybf A4szC4RJnJvUzw7R3M8kcWziAqBmDg5hAQmJzXsSQWrYBFQkjn/bwAzRayMx7/1tsPnCAmYS B3q2gtksAqoS217tYQWxOQVcJbZvPssOMT9EonXRR7C4iICxROeJ32wQuzYxSry/u50J4lBZ ie6F05hBEhICZ9gkZj+7xjqBUWgWkmNnITl2FtB9zALqElOm5EKEtSWevLvACmGrSSz8vYgJ WXwBI9sqRuHcxMwc3cw8I0O9xIKCnFS95PzcTYygGFnNJLqDcf4rw0OMAhyMSjy8G4JkIoVY E8uKK3MPMUpzsCiJ88q4SkcKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYEz6zG/36eCKM061 V+Pcw65bv3Ps2yw/wfjt3jK/2Vf4d914v/pGVMbpJZ/0+o9xH40JXW2aoNBZozjX9mW5w/E3 lopvWrzkC4onaJSFxlzN3XG2r3teZnjcZ8UfN7ji+c+duPjrTP873mmTLz1vldpue9sw0i/e yC8i4cPUmN9e/OlM1genlSmxFGckGmoxFxUnAgDs33igcgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBIsWRmVeSWpSXmKPExsUi2FB8RvfzcplIg56jshb7t7xgs5ja4mex 9NgHJgdmjym/N7J67Jx1l91jyZKfTAHMUVw2Kak5mWWpRfp2CVwZZ39sYCk4uZSpYsbH7+wN jO//MHYxcnJICJhIbJ11nAXEFhI4xCjxaYEAiM0rICjxY/I9sDizQJjEuUn97F2MXEA1/UwS xyYuAGrm4BAWkJDYvCcRpIZNQEXi+LcNzBC9NhLz3t8Gmy8sYCZxoGcrmM0ioCqx7dUeVhCb U8BVYvvms+wQ80MkWhd9BIuLCBhLdJ74zQaxaxOjxPu725kgDpWV6F44jXkCI/8sJPfNQnLf LKCTmAXUJaZMyYUIa0s8eXeBFcJWk1j4exETsvgCRrZVjAJFqTmJlUZ6iQUFOal6yfm5mxjB AV3ovIPx2DKrQ4wCHIxKPLwbgmQihVgTy4orc4FhxMGsJMJbUwEU4k1JrKxKLcqPLyrNSS0+ xDiREejLicxSosn5wHjLK4k3NDExMDE2NjM2Njcxp6Wwkjhv/QrpSCGB9MSS1OzU1ILUIpij mDg4pRoYt82zSPO/6il2rcWP3fDnsfjNkaaB8SdNc554/F3UX5tw2PO39fWsCk9ztfSsuQwr ok1btq0+q9iX2SZYVJklxXTmNeOpA4sbjwnmpE/TPr/fblbyNi8N7y39K49Lf1GaETBnpZtl YEroR+tbJds/Odux2Mp3f2J6s6Xjx1HWq8vKPPac4zFVYinOSDTUYi4qTgQAMquYzNsCAAA= Archived-At: Subject: Re: [IPsec] Question about ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 19:45:36 -0000 --Boundary_(ID_tI/Esrwx1toT1970JctXcg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > On May 17, 2017, at 12:12 PM, Scott Fluhrer (sfluhrer) = wrote: >=20 > =20 > From: Yoav Nir [mailto:ynir.ietf@gmail.com = ]=20 > Sent: Wednesday, May 17, 2017 2:54 PM > To: Scott Fluhrer (sfluhrer) > Cc: IPsecme WG (ipsec@ietf.org ) > Subject: Re: [IPsec] Question about ipsecme-tcp-encaps > =20 > =20 > On 17 May 2017, at 20:39, Scott Fluhrer (sfluhrer) > wrote: > =20 > I=E2=80=99ve been looking over the draft, and I think I see a = potential DoS attack that does not appear to be addressed. I=E2=80=99m = writing this to see if there is something I missed (and if there = isn=E2=80=99t, start discussion on how we might patch things up). > =20 > This is the scenario I=E2=80=99m looking at: Alice and Bob have a = TCP-based IKE/IPsec connection established. > =20 > Then, Eve injects a TCP packet to Bob with Alice=E2=80=99s source IP = (and with the appropriate TCP sequence numbers), and whose body consists = of a single FF byte. Eve does nothing else than that (other than = possibly absorbing the TCP-ACK that Bob would send out, if that=E2=80=99d = confuse Alice=E2=80=99s TCP stack=E2=80=A6) > =20 > Alice will then send a legitimate packet, consisting of (for example) = [Length =3D 0x0124] [ESP Header][Body]. However, Bob=E2=80=99s TCP = stack thinks it has already received the first byte, and so it=E2=80=99ll = ignore it, and so will tell the application (IPsec) that it has received = [0xff34][ESP Header][Body]. > =20 > My TCP may be rusty, but I think Alice=E2=80=99s legitimate packet has = the sequence number to indicate it is retransmitting the byte that Bob = already has. I don=E2=80=99t know if that means that the new data = overwrites the old data, that the old data remains, of that the stack = checks that it matches. > =20 > I don=E2=80=99t think it=E2=80=99s defined within TCP (rather, it=E2=80=99= s up to the individual stack); on the other hand, in general, the TCP = stack has already handed off the byte to the application (the IPsec = packet stream parser), and so it *can=E2=80=99t* overwrite it. > =20 > Of course, we could say =E2=80=9CEve modifies a valid TCP-encapsulated = IPsec packet so that the first byte is 0xff=E2=80=9D, and we have the = same attack=E2=80=A6 >=20 >=20 > The IPsec packet parsing code would interpret this as an extremely = long encrypted packet, and so will continue to absorb the next 0xfe00 = bytes from Alice. > =20 > It=E2=80=99ll then try to decrypt it; it=E2=80=99ll fail. That, in = itself, is not that big of a deal; we assume that an attacker who can = modify packets at will is able to force a few packets to be dropped. > =20 > However, look what happens after that; the IPsec stream parsing code = will then take the next two bytes of the stream, and try to parse them = as =E2=80=98packet length=E2=80=99. We stopped at a random location = within the TCP stream, and so quite likely, we=E2=80=99re in the middle = of an encrypted packet, and so the length will be a random value. = We=E2=80=99ll then try to parse the next bytes as a packet, and this = will keep on going (blocking all Alice -> Bob traffic) until the = end-of-packet the IPsec stream parser assumes just happens to fall on an = actual packet boundary =E2=80=93 obviously, that might be a while. > =20 > I agree. Once synchronization is lost, it may as well never be = regained. >=20 >=20 > TLS uses a similar =E2=80=98record lengths appear in the TCP stream=E2=80= =99 concept; however in the case of TLS, on decryption failure, you MUST = close the connection (and so this repeated =E2=80=98get a random = sequence of bytes and try to decrypt=E2=80=99 isn=E2=80=99t an issue); I = didn=E2=80=99t see a similar mandate in the IPsec draft. > =20 > =20 > Was there something I missed? The draft does have the text: > =20 > If either TCP Originator or TCP Responder > receives a stream that cannot be parsed correctly (for example, if > the TCP Originator stream is missing the stream prefix, or message > frames are not parsable as IKE or ESP messages), it MUST close the > TCP connection. > =20 > However: > a) That=E2=80=99s in a paragraph that starts =E2=80=9CIf a TCP = connection is being used to resume a previous IKE session=E2=80=A6=E2=80=9D= ; does it apply only in that case? No, the MUST close applies for all connections, regardless of = resumption. We could add a paragraph break to make that explicit. > b) An ESP message is of the form [SPI][Sequence number][Random = bytes]; unless you happen to get a SPI < 256 or length < 8, it=E2=80=99s = not clear how you could get something that is not of that format (unless = you mandate that the ESP length must be a multiple of 4 bytes; in that = case, you should state that explicitly) My assumption was that receiving an unknown SPI would automatically = cause the parsing to fail as a valid ESP message. I can add that to the = text. Adding bytes to the stream would shift the valid SPI. Beyond that, = as you mention the packet would not be decryptable, and certainly the = next bytes after the invalid frame's length would not parse as a valid = SPI. The reading would stop by then at least. We can also recommended = that readers enforce a sane limit on frame size. So the attacker can cause one large frame to be read, but after that the = connection will be torn down. Thanks, Tommy > =20 > =20 > Thoughts? > =20 > I=E2=80=99d like to hear how TCP stacks really behave. > =20 > That said, most of us feed the IPsec stack with packets generated on = networks with an MTU of 1500. Even if we add the IPsec over head on top = of that, it=E2=80=99s still less than 2.5% of the space afforded by a = 16-bit length field. At least for ESP packets. > =20 > If the receiver were to break the connection whenever it received some = number (2? 3?) of packets that had a length field that exceeded 1544 = (or whatever the maximum packet is for the particular algorithm) = followed by an ESP field that was not zero, > =20 > =E2=80=9CESP field=E2=80=9D; do you mean SPI? > =20 > this would fix the problem without letting Eve break the connection = with just one injected byte. > =20 > I f you don=E2=80=99t=E2=80=99 use IKE fragmentation, then I believe = IKE packets could be over the limit we picked (unless we picked a rather = conservative one); would that be an issue? So, was that something you = were trying to address with the ESP field above? > =20 > =20 > But there does seem to be something missing. > =20 > A more predictable was to detect loss-of-synchronization between the = sender and the receiver would be to include one or two fixed (or = predictable) bytes in the header (along with the Length field); this = would mean that we would have quite high probability of detecting sync = loss, without having an arbitrary length limit on the encrypted region. = If we pick a 2 byte value, that means that things stay on 4 byte = boundaries=E2=80=A6 > =20 > Yoav > =20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = --Boundary_(ID_tI/Esrwx1toT1970JctXcg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
On May 17, 2017, at 12:12 PM, Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com> = wrote:

 
From: Yoav Nir [mailto:ynir.ietf@gmail.com] 
Sent: Wednesday, May 17, 2017 = 2:54 PM
To: Scott Fluhrer (sfluhrer)
Cc: IPsecme WG (ipsec@ietf.org)
Subject: Re: [IPsec] Question about = ipsecme-tcp-encaps
 
 
On = 17 May 2017, at 20:39, Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com> = wrote:
 
I=E2=80=99ve been looking over the draft, and I think I see a = potential DoS attack that does not appear to be addressed.  I=E2=80=99= m writing this to see if there is something I missed (and if there = isn=E2=80=99t, start discussion on how we might patch things up).
 
This is the scenario I=E2=80=99m looking at: = Alice and Bob have a TCP-based IKE/IPsec connection established.
 
Then, Eve injects a TCP packet to Bob with = Alice=E2=80=99s source IP (and with the appropriate TCP sequence = numbers), and whose body consists of a single FF byte.  Eve does = nothing else than that (other than possibly absorbing the TCP-ACK that = Bob would send out, if that=E2=80=99d confuse Alice=E2=80=99s TCP = stack=E2=80=A6)
 
Alice will then send a legitimate packet, consisting of (for = example) [Length =3D 0x0124] [ESP Header][Body].  However, Bob=E2=80=99= s TCP stack thinks it has already received the first byte, and so = it=E2=80=99ll ignore it, and so will tell the application (IPsec) that = it has received [0xff34][ESP Header][Body].
 
My TCP may be rusty, but I think Alice=E2=80=99s legitimate = packet has the sequence number to indicate it is retransmitting the byte = that Bob already has. I don=E2=80=99t know if that means that the new = data overwrites the old data, that the old data remains, of that the = stack checks that it matches.
 
I don=E2=80=99t think = it=E2=80=99s defined within TCP (rather, it=E2=80=99s up to the = individual stack); on the other hand, in general, the TCP stack has = already handed off the byte to the application (the IPsec packet stream = parser), and so it *can=E2=80=99t* overwrite it.
 
Of course, we could say = =E2=80=9CEve modifies a valid TCP-encapsulated IPsec packet so that the = first byte is 0xff=E2=80=9D, and we have the same attack=E2=80=A6


The IPsec packet parsing code would interpret = this as an extremely long encrypted packet, and so will continue to = absorb the next 0xfe00 bytes from Alice.
 
It=E2=80=99ll then try to decrypt it; it=E2=80=99l= l fail.  That, in itself, is not that big of a deal; we assume that = an attacker who can modify packets at will is able to force a few = packets to be dropped.
 
However, look what happens after that; the IPsec stream = parsing code will then take the next two bytes of the stream, and try to = parse them as =E2=80=98packet length=E2=80=99.  We stopped at a = random location within the TCP stream, and so quite likely, we=E2=80=99re = in the middle of an encrypted packet, and so the length will be a random = value.  We=E2=80=99ll then try to parse the next bytes as a packet, = and this will keep on going (blocking all Alice -> Bob traffic) until = the end-of-packet the IPsec stream parser assumes just happens to fall = on an actual packet boundary =E2=80=93 obviously, that might be a = while.
 
I agree. Once synchronization is lost, it may as well never = be regained.


TLS uses a similar =E2=80=98record lengths = appear in the TCP stream=E2=80=99 concept; however in the case of TLS, = on decryption failure, you MUST close the connection (and so this = repeated =E2=80=98get a random sequence of bytes and try to decrypt=E2=80=99= isn=E2=80=99t an issue); I didn=E2=80=99t see a similar mandate in the = IPsec draft.
 
 
Was there something I missed?  The draft = does have the text:
 
   If either TCP Originator or TCP = Responder
   receives a stream that cannot be parsed = correctly (for example, if
   the TCP Originator stream is missing the = stream prefix, or message
   frames are not parsable as IKE or ESP = messages), it MUST close the
   TCP connection.
 
However:
a)      That=E2=80=99s in a paragraph that starts =E2=80=9CIf a TCP = connection is being used to resume a previous IKE session=E2=80=A6=E2=80=9D= ; does it apply only in that = case?

No, the MUST close applies for all connections, = regardless of resumption. We could add a paragraph break to make that = explicit.

b)      An= ESP message is of the form [SPI][Sequence number][Random bytes]; unless = you happen to get a SPI < 256 or length < 8, it=E2=80=99s not = clear how you could get something that is not of that format (unless you = mandate that the ESP length must be a multiple of 4 bytes; in that case, = you should state that = explicitly)
My assumption was that receiving an unknown SPI = would automatically cause the parsing to fail as a valid ESP message. I = can add that to the text. Adding bytes to the stream would shift the = valid SPI. Beyond that, as you mention the packet would not be = decryptable, and certainly the next bytes after the invalid frame's = length would not parse as a valid SPI. The reading would stop by then at = least. We can also recommended that readers enforce a sane limit on = frame size.

So the attacker can = cause one large frame to be read, but after that the connection will be = torn down.

Thanks,
Tommy

 
 
Thoughts?
 
I=E2=80=99d like to hear how TCP stacks = really behave.
 
That said, most of us feed the IPsec stack with = packets generated on networks with an MTU of 1500. Even if we add the = IPsec over head on top of that, it=E2=80=99s still less than 2.5% of the = space afforded by a 16-bit length field. At least for ESP packets.
 
If the receiver were to break the = connection whenever it received some number (2?  3?) of packets = that had a length field that exceeded 1544 (or whatever the maximum = packet is for the particular algorithm) followed by an ESP field that = was not zero,
 
=E2=80=9CESP field=E2=80=9D= ; do you mean SPI?
 
this would fix the problem without letting Eve break the = connection with just one injected byte.
 
I f you don=E2=80=99t=E2=80= =99 use IKE fragmentation, then I believe IKE packets could be over the = limit we picked (unless we picked a rather conservative one); would that = be an issue?  So, was that something you were trying to address = with the ESP field above?
 
 
But there does seem to be something = missing.
 
A more predictable was = to detect loss-of-synchronization between the sender and the receiver = would be to include one or two fixed (or predictable) bytes in the = header (along with the Length field); this would mean that we would have = quite high probability of detecting sync loss, without having an = arbitrary length limit on the encrypted region.  If we pick a 2 = byte value, that means that things stay on 4 byte boundaries=E2=80=A6
 
Yoav
 
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Boundary_(ID_tI/Esrwx1toT1970JctXcg)-- From nobody Wed May 17 12:58:47 2017 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 D9032120726 for ; Wed, 17 May 2017 12:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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=-0.001, SPF_HELO_PASS=-0.001, 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 33YOQ-VbnQwt for ; Wed, 17 May 2017 12:58:42 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 426621201F8 for ; Wed, 17 May 2017 12:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31080; q=dns/txt; s=iport; t=1495051122; x=1496260722; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=H6Ic5GjLmNt/L2uqVrTJoQ22zcnrOoUAdfYJ6qUKFpA=; b=SF/3oh7PL0hwrB6qhGVzWxdUvlSHKQUfAJ96FIt20L+FyGp05lYLdwI0 sdpz+E2iUFxYWZCp2c3lD2OGUYPyo8HgvwuDVgEEasCAe5DXg7RkSf/oT nCosbGKUX8RGobYBT/TmuD3feC6qtSY11fZzWHlT5uZ05JIiqux7+Tj1P s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlAQCpqhxZ/4oNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYoEMB4NmihiRZ4gmjU+CD4YkAhqFRT8YAQIBAQEBAQEBax0?= =?us-ascii?q?LhRgBAQEBAyMEBkwQAgEGAhEEAQEhBwMCAgIfERQJCAEBBA4FCIoDAxWPJp1gg?= =?us-ascii?q?Ww6hy8Ng0cBAQEBAQEBAQEBAQEBAQEBAQEBAQEdhl+BXoMbglSBbFmCXIJgBZZ?= =?us-ascii?q?zhmI7AY5HhEqCDYkihkeLL4kWAR84gQpwFUaEdB+BY3aGK4EvgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.38,355,1491264000"; d="scan'208,217";a="426136533" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 May 2017 19:58:40 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v4HJwewd013605 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 May 2017 19:58:40 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 17 May 2017 15:58:39 -0400 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; Wed, 17 May 2017 15:58:39 -0400 From: "Scott Fluhrer (sfluhrer)" To: "tpauly@apple.com" CC: Yoav Nir , "IPsecme WG (ipsec@ietf.org)" Thread-Topic: [IPsec] Question about ipsecme-tcp-encaps Thread-Index: AdLPNI/2pFR/dDPhQiGtKCVpagxlHgAK+MEAAAg/uLD//8v1AIAAQg+g Date: Wed, 17 May 2017 19:58:39 +0000 Message-ID: References: <12068173-33D1-4D03-B07E-2C84FF012669@apple.com> In-Reply-To: <12068173-33D1-4D03-B07E-2C84FF012669@apple.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.52] Content-Type: multipart/alternative; boundary="_000_a2536b36f8a34d88b93bf74d7839df54XCHRTP006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Question about ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 19:58:45 -0000 --_000_a2536b36f8a34d88b93bf74d7839df54XCHRTP006ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGcm9tOiB0cGF1bHlAYXBwbGUuY29tIFttYWlsdG86dHBhdWx5QGFwcGxlLmNvbV0NClNlbnQ6 IFdlZG5lc2RheSwgTWF5IDE3LCAyMDE3IDM6NDQgUE0NClRvOiBTY290dCBGbHVocmVyIChzZmx1 aHJlcikNCkNjOiBZb2F2IE5pcjsgSVBzZWNtZSBXRyAoaXBzZWNAaWV0Zi5vcmcpDQpTdWJqZWN0 OiBSZTogW0lQc2VjXSBRdWVzdGlvbiBhYm91dCBpcHNlY21lLXRjcC1lbmNhcHMNCg0KDQpPbiBN YXkgMTcsIDIwMTcsIGF0IDEyOjEyIFBNLCBTY290dCBGbHVocmVyIChzZmx1aHJlcikgPHNmbHVo cmVyQGNpc2NvLmNvbTxtYWlsdG86c2ZsdWhyZXJAY2lzY28uY29tPj4gd3JvdGU6DQoNCg0KRnJv bTogWW9hdiBOaXIgW21haWx0bzp5bmlyLmlldGZAZ21haWwuY29tXQ0KU2VudDogV2VkbmVzZGF5 LCBNYXkgMTcsIDIwMTcgMjo1NCBQTQ0KVG86IFNjb3R0IEZsdWhyZXIgKHNmbHVocmVyKQ0KQ2M6 IElQc2VjbWUgV0cgKGlwc2VjQGlldGYub3JnPG1haWx0bzppcHNlY0BpZXRmLm9yZz4pDQpTdWJq ZWN0OiBSZTogW0lQc2VjXSBRdWVzdGlvbiBhYm91dCBpcHNlY21lLXRjcC1lbmNhcHMNCg0KDQpP biAxNyBNYXkgMjAxNywgYXQgMjA6MzksIFNjb3R0IEZsdWhyZXIgKHNmbHVocmVyKSA8c2ZsdWhy ZXJAY2lzY28uY29tPG1haWx0bzpzZmx1aHJlckBjaXNjby5jb20+PiB3cm90ZToNCg0KSeKAmXZl IGJlZW4gbG9va2luZyBvdmVyIHRoZSBkcmFmdCwgYW5kIEkgdGhpbmsgSSBzZWUgYSBwb3RlbnRp YWwgRG9TIGF0dGFjayB0aGF0IGRvZXMgbm90IGFwcGVhciB0byBiZSBhZGRyZXNzZWQuICBJ4oCZ bSB3cml0aW5nIHRoaXMgdG8gc2VlIGlmIHRoZXJlIGlzIHNvbWV0aGluZyBJIG1pc3NlZCAoYW5k IGlmIHRoZXJlIGlzbuKAmXQsIHN0YXJ0IGRpc2N1c3Npb24gb24gaG93IHdlIG1pZ2h0IHBhdGNo IHRoaW5ncyB1cCkuDQoNClRoaXMgaXMgdGhlIHNjZW5hcmlvIEnigJltIGxvb2tpbmcgYXQ6IEFs aWNlIGFuZCBCb2IgaGF2ZSBhIFRDUC1iYXNlZCBJS0UvSVBzZWMgY29ubmVjdGlvbiBlc3RhYmxp c2hlZC4NCg0KVGhlbiwgRXZlIGluamVjdHMgYSBUQ1AgcGFja2V0IHRvIEJvYiB3aXRoIEFsaWNl 4oCZcyBzb3VyY2UgSVAgKGFuZCB3aXRoIHRoZSBhcHByb3ByaWF0ZSBUQ1Agc2VxdWVuY2UgbnVt YmVycyksIGFuZCB3aG9zZSBib2R5IGNvbnNpc3RzIG9mIGEgc2luZ2xlIEZGIGJ5dGUuICBFdmUg ZG9lcyBub3RoaW5nIGVsc2UgdGhhbiB0aGF0IChvdGhlciB0aGFuIHBvc3NpYmx5IGFic29yYmlu ZyB0aGUgVENQLUFDSyB0aGF0IEJvYiB3b3VsZCBzZW5kIG91dCwgaWYgdGhhdOKAmWQgY29uZnVz ZSBBbGljZeKAmXMgVENQIHN0YWNr4oCmKQ0KDQpBbGljZSB3aWxsIHRoZW4gc2VuZCBhIGxlZ2l0 aW1hdGUgcGFja2V0LCBjb25zaXN0aW5nIG9mIChmb3IgZXhhbXBsZSkgW0xlbmd0aCA9IDB4MDEy NF0gW0VTUCBIZWFkZXJdW0JvZHldLiAgSG93ZXZlciwgQm9i4oCZcyBUQ1Agc3RhY2sgdGhpbmtz IGl0IGhhcyBhbHJlYWR5IHJlY2VpdmVkIHRoZSBmaXJzdCBieXRlLCBhbmQgc28gaXTigJlsbCBp Z25vcmUgaXQsIGFuZCBzbyB3aWxsIHRlbGwgdGhlIGFwcGxpY2F0aW9uIChJUHNlYykgdGhhdCBp dCBoYXMgcmVjZWl2ZWQgWzB4ZmYzNF1bRVNQIEhlYWRlcl1bQm9keV0uDQoNCk15IFRDUCBtYXkg YmUgcnVzdHksIGJ1dCBJIHRoaW5rIEFsaWNl4oCZcyBsZWdpdGltYXRlIHBhY2tldCBoYXMgdGhl IHNlcXVlbmNlIG51bWJlciB0byBpbmRpY2F0ZSBpdCBpcyByZXRyYW5zbWl0dGluZyB0aGUgYnl0 ZSB0aGF0IEJvYiBhbHJlYWR5IGhhcy4gSSBkb27igJl0IGtub3cgaWYgdGhhdCBtZWFucyB0aGF0 IHRoZSBuZXcgZGF0YSBvdmVyd3JpdGVzIHRoZSBvbGQgZGF0YSwgdGhhdCB0aGUgb2xkIGRhdGEg cmVtYWlucywgb2YgdGhhdCB0aGUgc3RhY2sgY2hlY2tzIHRoYXQgaXQgbWF0Y2hlcy4NCg0KSSBk b27igJl0IHRoaW5rIGl04oCZcyBkZWZpbmVkIHdpdGhpbiBUQ1AgKHJhdGhlciwgaXTigJlzIHVw IHRvIHRoZSBpbmRpdmlkdWFsIHN0YWNrKTsgb24gdGhlIG90aGVyIGhhbmQsIGluIGdlbmVyYWws IHRoZSBUQ1Agc3RhY2sgaGFzIGFscmVhZHkgaGFuZGVkIG9mZiB0aGUgYnl0ZSB0byB0aGUgYXBw bGljYXRpb24gKHRoZSBJUHNlYyBwYWNrZXQgc3RyZWFtIHBhcnNlciksIGFuZCBzbyBpdCAqY2Fu 4oCZdCogb3ZlcndyaXRlIGl0Lg0KDQpPZiBjb3Vyc2UsIHdlIGNvdWxkIHNheSDigJxFdmUgbW9k aWZpZXMgYSB2YWxpZCBUQ1AtZW5jYXBzdWxhdGVkIElQc2VjIHBhY2tldCBzbyB0aGF0IHRoZSBm aXJzdCBieXRlIGlzIDB4ZmbigJ0sIGFuZCB3ZSBoYXZlIHRoZSBzYW1lIGF0dGFja+KApg0KDQoN Cg0KVGhlIElQc2VjIHBhY2tldCBwYXJzaW5nIGNvZGUgd291bGQgaW50ZXJwcmV0IHRoaXMgYXMg YW4gZXh0cmVtZWx5IGxvbmcgZW5jcnlwdGVkIHBhY2tldCwgYW5kIHNvIHdpbGwgY29udGludWUg dG8gYWJzb3JiIHRoZSBuZXh0IDB4ZmUwMCBieXRlcyBmcm9tIEFsaWNlLg0KDQpJdOKAmWxsIHRo ZW4gdHJ5IHRvIGRlY3J5cHQgaXQ7IGl04oCZbGwgZmFpbC4gIFRoYXQsIGluIGl0c2VsZiwgaXMg bm90IHRoYXQgYmlnIG9mIGEgZGVhbDsgd2UgYXNzdW1lIHRoYXQgYW4gYXR0YWNrZXIgd2hvIGNh biBtb2RpZnkgcGFja2V0cyBhdCB3aWxsIGlzIGFibGUgdG8gZm9yY2UgYSBmZXcgcGFja2V0cyB0 byBiZSBkcm9wcGVkLg0KDQpIb3dldmVyLCBsb29rIHdoYXQgaGFwcGVucyBhZnRlciB0aGF0OyB0 aGUgSVBzZWMgc3RyZWFtIHBhcnNpbmcgY29kZSB3aWxsIHRoZW4gdGFrZSB0aGUgbmV4dCB0d28g Ynl0ZXMgb2YgdGhlIHN0cmVhbSwgYW5kIHRyeSB0byBwYXJzZSB0aGVtIGFzIOKAmHBhY2tldCBs ZW5ndGjigJkuICBXZSBzdG9wcGVkIGF0IGEgcmFuZG9tIGxvY2F0aW9uIHdpdGhpbiB0aGUgVENQ IHN0cmVhbSwgYW5kIHNvIHF1aXRlIGxpa2VseSwgd2XigJlyZSBpbiB0aGUgbWlkZGxlIG9mIGFu IGVuY3J5cHRlZCBwYWNrZXQsIGFuZCBzbyB0aGUgbGVuZ3RoIHdpbGwgYmUgYSByYW5kb20gdmFs dWUuICBXZeKAmWxsIHRoZW4gdHJ5IHRvIHBhcnNlIHRoZSBuZXh0IGJ5dGVzIGFzIGEgcGFja2V0 LCBhbmQgdGhpcyB3aWxsIGtlZXAgb24gZ29pbmcgKGJsb2NraW5nIGFsbCBBbGljZSAtPiBCb2Ig dHJhZmZpYykgdW50aWwgdGhlIGVuZC1vZi1wYWNrZXQgdGhlIElQc2VjIHN0cmVhbSBwYXJzZXIg YXNzdW1lcyBqdXN0IGhhcHBlbnMgdG8gZmFsbCBvbiBhbiBhY3R1YWwgcGFja2V0IGJvdW5kYXJ5 IOKAkyBvYnZpb3VzbHksIHRoYXQgbWlnaHQgYmUgYSB3aGlsZS4NCg0KSSBhZ3JlZS4gT25jZSBz eW5jaHJvbml6YXRpb24gaXMgbG9zdCwgaXQgbWF5IGFzIHdlbGwgbmV2ZXIgYmUgcmVnYWluZWQu DQoNCg0KDQpUTFMgdXNlcyBhIHNpbWlsYXIg4oCYcmVjb3JkIGxlbmd0aHMgYXBwZWFyIGluIHRo ZSBUQ1Agc3RyZWFt4oCZIGNvbmNlcHQ7IGhvd2V2ZXIgaW4gdGhlIGNhc2Ugb2YgVExTLCBvbiBk ZWNyeXB0aW9uIGZhaWx1cmUsIHlvdSBNVVNUIGNsb3NlIHRoZSBjb25uZWN0aW9uIChhbmQgc28g dGhpcyByZXBlYXRlZCDigJhnZXQgYSByYW5kb20gc2VxdWVuY2Ugb2YgYnl0ZXMgYW5kIHRyeSB0 byBkZWNyeXB04oCZIGlzbuKAmXQgYW4gaXNzdWUpOyBJIGRpZG7igJl0IHNlZSBhIHNpbWlsYXIg bWFuZGF0ZSBpbiB0aGUgSVBzZWMgZHJhZnQuDQoNCg0KV2FzIHRoZXJlIHNvbWV0aGluZyBJIG1p c3NlZD8gIFRoZSBkcmFmdCBkb2VzIGhhdmUgdGhlIHRleHQ6DQoNCiAgIElmIGVpdGhlciBUQ1Ag T3JpZ2luYXRvciBvciBUQ1AgUmVzcG9uZGVyDQogICByZWNlaXZlcyBhIHN0cmVhbSB0aGF0IGNh bm5vdCBiZSBwYXJzZWQgY29ycmVjdGx5IChmb3IgZXhhbXBsZSwgaWYNCiAgIHRoZSBUQ1AgT3Jp Z2luYXRvciBzdHJlYW0gaXMgbWlzc2luZyB0aGUgc3RyZWFtIHByZWZpeCwgb3IgbWVzc2FnZQ0K ICAgZnJhbWVzIGFyZSBub3QgcGFyc2FibGUgYXMgSUtFIG9yIEVTUCBtZXNzYWdlcyksIGl0IE1V U1QgY2xvc2UgdGhlDQogICBUQ1AgY29ubmVjdGlvbi4NCg0KSG93ZXZlcjoNCmEpICAgICAgVGhh dOKAmXMgaW4gYSBwYXJhZ3JhcGggdGhhdCBzdGFydHMg4oCcSWYgYSBUQ1AgY29ubmVjdGlvbiBp cyBiZWluZyB1c2VkIHRvIHJlc3VtZSBhIHByZXZpb3VzIElLRSBzZXNzaW9u4oCm4oCdOyBkb2Vz IGl0IGFwcGx5IG9ubHkgaW4gdGhhdCBjYXNlPw0KDQpObywgdGhlIE1VU1QgY2xvc2UgYXBwbGll cyBmb3IgYWxsIGNvbm5lY3Rpb25zLCByZWdhcmRsZXNzIG9mIHJlc3VtcHRpb24uIFdlIGNvdWxk IGFkZCBhIHBhcmFncmFwaCBicmVhayB0byBtYWtlIHRoYXQgZXhwbGljaXQuDQoNCg0KYikgICAg ICBBbiBFU1AgbWVzc2FnZSBpcyBvZiB0aGUgZm9ybSBbU1BJXVtTZXF1ZW5jZSBudW1iZXJdW1Jh bmRvbSBieXRlc107IHVubGVzcyB5b3UgaGFwcGVuIHRvIGdldCBhIFNQSSA8IDI1NiBvciBsZW5n dGggPCA4LCBpdOKAmXMgbm90IGNsZWFyIGhvdyB5b3UgY291bGQgZ2V0IHNvbWV0aGluZyB0aGF0 IGlzIG5vdCBvZiB0aGF0IGZvcm1hdCAodW5sZXNzIHlvdSBtYW5kYXRlIHRoYXQgdGhlIEVTUCBs ZW5ndGggbXVzdCBiZSBhIG11bHRpcGxlIG9mIDQgYnl0ZXM7IGluIHRoYXQgY2FzZSwgeW91IHNo b3VsZCBzdGF0ZSB0aGF0IGV4cGxpY2l0bHkpDQoNCk15IGFzc3VtcHRpb24gd2FzIHRoYXQgcmVj ZWl2aW5nIGFuIHVua25vd24gU1BJIHdvdWxkIGF1dG9tYXRpY2FsbHkgY2F1c2UgdGhlIHBhcnNp bmcgdG8gZmFpbCBhcyBhIHZhbGlkIEVTUCBtZXNzYWdlLiBJIGNhbiBhZGQgdGhhdCB0byB0aGUg dGV4dC4gQWRkaW5nIGJ5dGVzIHRvIHRoZSBzdHJlYW0gd291bGQgc2hpZnQgdGhlIHZhbGlkIFNQ SS4gQmV5b25kIHRoYXQsIGFzIHlvdSBtZW50aW9uIHRoZSBwYWNrZXQgd291bGQgbm90IGJlIGRl Y3J5cHRhYmxlLCBhbmQgY2VydGFpbmx5IHRoZSBuZXh0IGJ5dGVzIGFmdGVyIHRoZSBpbnZhbGlk IGZyYW1lJ3MgbGVuZ3RoIHdvdWxkIG5vdCBwYXJzZSBhcyBhIHZhbGlkIFNQSS4gVGhlIHJlYWRp bmcgd291bGQgc3RvcCBieSB0aGVuIGF0IGxlYXN0LiBXZSBjYW4gYWxzbyByZWNvbW1lbmRlZCB0 aGF0IHJlYWRlcnMgZW5mb3JjZSBhIHNhbmUgbGltaXQgb24gZnJhbWUgc2l6ZS4NCg0KU28gdGhl IGF0dGFja2VyIGNhbiBjYXVzZSBvbmUgbGFyZ2UgZnJhbWUgdG8gYmUgcmVhZCwgYnV0IGFmdGVy IHRoYXQgdGhlIGNvbm5lY3Rpb24gd2lsbCBiZSB0b3JuIGRvd24uDQoNCk15IGNvbmNlcm4gKGFz IGEgcHJldmlvdXMgSVBzZWMgaW1wbGVtZW50b3IpIGlzIOKAnGFyZSB0aGVyZSB2YWxpZCByZWFz b25zIGZvciB5b3UgdG8gZ2V0IGFuIGludmFsaWQgU1BJ4oCdOyBmb3IgZXhhbXBsZSwgb25lIHNp ZGUgaGFzIHRvcm4gZG93biB0aGUgU0EsIGJ1dCB0aGUgb3RoZXIgc2lkZSBoYXNu4oCZdCBoZWFy ZCB0aGUgZGVsZXRlIG5vdGlmeSB5ZXQ/ICBJIGJlbGlldmUgdGhlcmUgYXJlIHNjZW5hcmlvcyB3 aGVyZSB0aGlzIGNhbiBoYXBwZW4gKG91ciBpbXBsZW1lbnRhdGlvbiBrZXB0IGFyb3VuZCBhIGxp c3Qgb2YgcmVjZW50bHktdG9ybi1kb3duIFNQSXMgdG8gYXZvaWQgc3B1cmlvdXMgZXJyb3IgbG9n cyB3aGVuIHRoaXMgaGFwcGVuZWQ7IGhvd2V2ZXIgSSBkb27igJl0IGJlbGlldmUgd2Ugd2FudCB0 byBtYW5kYXRlIHRoYXQgYXBwcm9hY2ggaW4gZ2VuZXJhbCkuICBPbiB0aGUgb3RoZXIgaGFuZCwg aWYgdGhlIG9ubHkgY29zdCBpcyByZWVzdGFibGlzaGluZyB0aGUgVENQIGNvbm5lY3Rpb24sIGl0 IG1pZ2h0IGJlIHJhcmUgZW5vdWdo4oCmDQo= --_000_a2536b36f8a34d88b93bf74d7839df54XCHRTP006ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFw cGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gdHBhdWx5QGFwcGxlLmNvbSBbbWFpbHRvOnRwYXVseUBhcHBsZS5jb21d DQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXkgMTcsIDIwMTcgMzo0NCBQTTxicj4N CjxiPlRvOjwvYj4gU2NvdHQgRmx1aHJlciAoc2ZsdWhyZXIpPGJyPg0KPGI+Q2M6PC9iPiBZb2F2 IE5pcjsgSVBzZWNtZSBXRyAoaXBzZWNAaWV0Zi5vcmcpPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbSVBzZWNdIFF1ZXN0aW9uIGFib3V0IGlwc2VjbWUtdGNwLWVuY2FwczxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1heSAxNywgMjAxNywgYXQg MTI6MTIgUE0sIFNjb3R0IEZsdWhyZXIgKHNmbHVocmVyKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNm bHVocmVyQGNpc2NvLmNvbSI+c2ZsdWhyZXJAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Zb2F2DQogTmlyIFs8YSBocmVmPSJtYWlsdG86eW5p ci5pZXRmQGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRvOnluaXIu aWV0ZkBnbWFpbC5jb208L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldlZG5lc2RheSwgTWF5IDE3LCAyMDE3IDI6NTQg UE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPlNjb3R0IEZsdWhyZXIgKHNmbHVocmVyKTxicj4NCjxiPkNjOjwvYj48c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+SVBzZWNtZSBXRyAoPGEg aHJlZj0ibWFpbHRvOmlwc2VjQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5p cHNlY0BpZXRmLm9yZzwvc3Bhbj48L2E+KTxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW0lQc2VjXSBRdWVzdGlv biBhYm91dCBpcHNlY21lLXRjcC1lbmNhcHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiAxNyBNYXkgMjAxNywgYXQgMjA6MzksIFNjb3R0IEZsdWhyZXIgKHNmbHVocmVy KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmbHVocmVyQGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+c2ZsdWhyZXJAY2lzY28uY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5J4oCZdmUgYmVlbiBs b29raW5nIG92ZXIgdGhlIGRyYWZ0LCBhbmQgSSB0aGluayBJIHNlZSBhIHBvdGVudGlhbCBEb1Mg YXR0YWNrIHRoYXQgZG9lcyBub3QgYXBwZWFyIHRvIGJlIGFkZHJlc3NlZC4mbmJzcDsgSeKAmW0g d3JpdGluZyB0aGlzIHRvIHNlZSBpZiB0aGVyZSBpcyBzb21ldGhpbmcgSSBtaXNzZWQgKGFuZA0K IGlmIHRoZXJlIGlzbuKAmXQsIHN0YXJ0IGRpc2N1c3Npb24gb24gaG93IHdlIG1pZ2h0IHBhdGNo IHRoaW5ncyB1cCkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRo aXMgaXMgdGhlIHNjZW5hcmlvIEnigJltIGxvb2tpbmcgYXQ6IEFsaWNlIGFuZCBCb2IgaGF2ZSBh IFRDUC1iYXNlZCBJS0UvSVBzZWMgY29ubmVjdGlvbiBlc3RhYmxpc2hlZC48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlbiwgRXZlIGluamVjdHMgYSBUQ1AgcGFj a2V0IHRvIEJvYiB3aXRoIEFsaWNl4oCZcyBzb3VyY2UgSVAgKGFuZCB3aXRoIHRoZSBhcHByb3By aWF0ZSBUQ1Agc2VxdWVuY2UgbnVtYmVycyksIGFuZCB3aG9zZSBib2R5IGNvbnNpc3RzIG9mIGEg c2luZ2xlIEZGIGJ5dGUuJm5ic3A7IEV2ZSBkb2VzIG5vdGhpbmcNCiBlbHNlIHRoYW4gdGhhdCAo b3RoZXIgdGhhbiBwb3NzaWJseSBhYnNvcmJpbmcgdGhlIFRDUC1BQ0sgdGhhdCBCb2Igd291bGQg c2VuZCBvdXQsIGlmIHRoYXTigJlkIGNvbmZ1c2UgQWxpY2XigJlzIFRDUCBzdGFja+KApik8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QWxpY2Ugd2lsbCB0aGVuIHNl bmQgYSBsZWdpdGltYXRlIHBhY2tldCwgY29uc2lzdGluZyBvZiAoZm9yIGV4YW1wbGUpIFtMZW5n dGggPSAweDAxMjRdIFtFU1AgSGVhZGVyXVtCb2R5XS4mbmJzcDsgSG93ZXZlciwgQm9i4oCZcyBU Q1Agc3RhY2sgdGhpbmtzIGl0IGhhcyBhbHJlYWR5IHJlY2VpdmVkIHRoZSBmaXJzdA0KIGJ5dGUs IGFuZCBzbyBpdOKAmWxsIGlnbm9yZSBpdCwgYW5kIHNvIHdpbGwgdGVsbCB0aGUgYXBwbGljYXRp b24gKElQc2VjKSB0aGF0IGl0IGhhcyByZWNlaXZlZCBbMHhmZjM0XVtFU1AgSGVhZGVyXVtCb2R5 XS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBU Q1AgbWF5IGJlIHJ1c3R5LCBidXQgSSB0aGluayBBbGljZeKAmXMgbGVnaXRpbWF0ZSBwYWNrZXQg aGFzIHRoZSBzZXF1ZW5jZSBudW1iZXIgdG8gaW5kaWNhdGUgaXQgaXMgcmV0cmFuc21pdHRpbmcg dGhlIGJ5dGUgdGhhdCBCb2IgYWxyZWFkeSBoYXMuIEkgZG9u4oCZdCBrbm93IGlmIHRoYXQgbWVh bnMgdGhhdCB0aGUgbmV3IGRhdGEgb3ZlcndyaXRlcyB0aGUgb2xkIGRhdGEsIHRoYXQgdGhlIG9s ZCBkYXRhIHJlbWFpbnMsDQogb2YgdGhhdCB0aGUgc3RhY2sgY2hlY2tzIHRoYXQgaXQgbWF0Y2hl cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHRoaW5rIGl04oCZ cyBkZWZpbmVkIHdpdGhpbiBUQ1AgKHJhdGhlciwgaXTigJlzIHVwIHRvIHRoZSBpbmRpdmlkdWFs IHN0YWNrKTsgb24gdGhlIG90aGVyIGhhbmQsIGluIGdlbmVyYWwsIHRoZSBUQ1Agc3RhY2sgaGFz IGFscmVhZHkgaGFuZGVkIG9mZiB0aGUgYnl0ZQ0KIHRvIHRoZSBhcHBsaWNhdGlvbiAodGhlIElQ c2VjIHBhY2tldCBzdHJlYW0gcGFyc2VyKSwgYW5kIHNvIGl0ICo8Yj5jYW7igJl0PC9iPiogb3Zl cndyaXRlIGl0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T2YgY291 cnNlLCB3ZSBjb3VsZCBzYXkg4oCcRXZlIG1vZGlmaWVzIGEgdmFsaWQgVENQLWVuY2Fwc3VsYXRl ZCBJUHNlYyBwYWNrZXQgc28gdGhhdCB0aGUgZmlyc3QgYnl0ZSBpcyAweGZm4oCdLCBhbmQgd2Ug aGF2ZSB0aGUgc2FtZSBhdHRhY2vigKY8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZSBJUHNlYyBwYWNrZXQgcGFyc2lu ZyBjb2RlIHdvdWxkIGludGVycHJldCB0aGlzIGFzIGFuIGV4dHJlbWVseSBsb25nIGVuY3J5cHRl ZCBwYWNrZXQsIGFuZCBzbyB3aWxsIGNvbnRpbnVlIHRvIGFic29yYiB0aGUgbmV4dCAweGZlMDAg Ynl0ZXMgZnJvbSBBbGljZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+SXTigJlsbCB0aGVuIHRyeSB0byBkZWNyeXB0IGl0OyBpdOKAmWxsIGZhaWwuJm5ic3A7IFRo YXQsIGluIGl0c2VsZiwgaXMgbm90IHRoYXQgYmlnIG9mIGEgZGVhbDsgd2UgYXNzdW1lIHRoYXQg YW4gYXR0YWNrZXIgd2hvIGNhbiBtb2RpZnkgcGFja2V0cyBhdCB3aWxsIGlzIGFibGUgdG8gZm9y Y2UgYSBmZXcgcGFja2V0cw0KIHRvIGJlIGRyb3BwZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkhvd2V2ZXIsIGxvb2sgd2hhdCBoYXBwZW5zIGFmdGVyIHRoYXQ7 IHRoZSBJUHNlYyBzdHJlYW0gcGFyc2luZyBjb2RlIHdpbGwgdGhlbiB0YWtlIHRoZSBuZXh0IHR3 byBieXRlcyBvZiB0aGUgc3RyZWFtLCBhbmQgdHJ5IHRvIHBhcnNlIHRoZW0gYXMg4oCYcGFja2V0 IGxlbmd0aOKAmS4mbmJzcDsgV2Ugc3RvcHBlZA0KIGF0IGEgcmFuZG9tIGxvY2F0aW9uIHdpdGhp biB0aGUgVENQIHN0cmVhbSwgYW5kIHNvIHF1aXRlIGxpa2VseSwgd2XigJlyZSBpbiB0aGUgbWlk ZGxlIG9mIGFuIGVuY3J5cHRlZCBwYWNrZXQsIGFuZCBzbyB0aGUgbGVuZ3RoIHdpbGwgYmUgYSBy YW5kb20gdmFsdWUuJm5ic3A7IFdl4oCZbGwgdGhlbiB0cnkgdG8gcGFyc2UgdGhlIG5leHQgYnl0 ZXMgYXMgYSBwYWNrZXQsIGFuZCB0aGlzIHdpbGwga2VlcCBvbiBnb2luZyAoYmxvY2tpbmcgYWxs IEFsaWNlIC0mZ3Q7IEJvYg0KIHRyYWZmaWMpIHVudGlsIHRoZSBlbmQtb2YtcGFja2V0IHRoZSBJ UHNlYyBzdHJlYW0gcGFyc2VyIGFzc3VtZXMganVzdCBoYXBwZW5zIHRvIGZhbGwgb24gYW4gYWN0 dWFsIHBhY2tldCBib3VuZGFyeSDigJMgb2J2aW91c2x5LCB0aGF0IG1pZ2h0IGJlIGEgd2hpbGUu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUuIE9uY2Ugc3luY2hyb25pemF0aW9u IGlzIGxvc3QsIGl0IG1heSBhcyB3ZWxsIG5ldmVyIGJlIHJlZ2FpbmVkLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UTFMgdXNlcyBh IHNpbWlsYXIg4oCYcmVjb3JkIGxlbmd0aHMgYXBwZWFyIGluIHRoZSBUQ1Agc3RyZWFt4oCZIGNv bmNlcHQ7IGhvd2V2ZXIgaW4gdGhlIGNhc2Ugb2YgVExTLCBvbiBkZWNyeXB0aW9uIGZhaWx1cmUs IHlvdSBNVVNUIGNsb3NlIHRoZSBjb25uZWN0aW9uIChhbmQgc28gdGhpcyByZXBlYXRlZA0KIOKA mGdldCBhIHJhbmRvbSBzZXF1ZW5jZSBvZiBieXRlcyBhbmQgdHJ5IHRvIGRlY3J5cHTigJkgaXNu 4oCZdCBhbiBpc3N1ZSk7IEkgZGlkbuKAmXQgc2VlIGEgc2ltaWxhciBtYW5kYXRlIGluIHRoZSBJ UHNlYyBkcmFmdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XYXMgdGhl cmUgc29tZXRoaW5nIEkgbWlzc2VkPyZuYnNwOyBUaGUgZHJhZnQgZG9lcyBoYXZlIHRoZSB0ZXh0 Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBJZiBlaXRoZXIgVENQIE9yaWdp bmF0b3Igb3IgVENQIFJlc3BvbmRlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsgcmVjZWl2ZXMgYSBzdHJlYW0gdGhhdCBjYW5ub3QgYmUgcGFyc2VkIGNvcnJlY3RseSAo Zm9yIGV4YW1wbGUsIGlmPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB0 aGUgVENQIE9yaWdpbmF0b3Igc3RyZWFtIGlzIG1pc3NpbmcgdGhlIHN0cmVhbSBwcmVmaXgsIG9y IG1lc3NhZ2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGZyYW1lcyBh cmUgbm90IHBhcnNhYmxlIGFzIElLRSBvciBFU1AgbWVzc2FnZXMpLCBpdCBNVVNUIGNsb3NlIHRo ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgVENQIGNvbm5lY3Rpb24u PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhvd2V2ZXI6PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi43NWluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6 LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmEpPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGF04oCZcw0KIGluIGEgcGFyYWdyYXBoIHRoYXQgc3RhcnRz IOKAnElmIGEgVENQIGNvbm5lY3Rpb24gaXMgYmVpbmcgdXNlZCB0byByZXN1bWUgYSBwcmV2aW91 cyBJS0Ugc2Vzc2lvbuKApuKAnTsgZG9lcyBpdCBhcHBseSBvbmx5IGluIHRoYXQgY2FzZT88L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm8sIHRoZSBN VVNUIGNsb3NlIGFwcGxpZXMgZm9yIGFsbCBjb25uZWN0aW9ucywgcmVnYXJkbGVzcyBvZiByZXN1 bXB0aW9uLiBXZSBjb3VsZCBhZGQgYSBwYXJhZ3JhcGggYnJlYWsgdG8gbWFrZSB0aGF0IGV4cGxp Y2l0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi43NWluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPmIpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Bbg0KIEVTUCBt ZXNzYWdlIGlzIG9mIHRoZSBmb3JtIFtTUEldW1NlcXVlbmNlIG51bWJlcl1bUmFuZG9tIGJ5dGVz XTsgdW5sZXNzIHlvdSBoYXBwZW4gdG8gZ2V0IGEgU1BJICZsdDsgMjU2IG9yIGxlbmd0aCAmbHQ7 IDgsIGl04oCZcyBub3QgY2xlYXIgaG93IHlvdSBjb3VsZCBnZXQgc29tZXRoaW5nIHRoYXQgaXMg bm90IG9mIHRoYXQgZm9ybWF0ICh1bmxlc3MgeW91IG1hbmRhdGUgdGhhdCB0aGUgRVNQIGxlbmd0 aCBtdXN0IGJlIGEgbXVsdGlwbGUgb2YgNCBieXRlczsNCiBpbiB0aGF0IGNhc2UsIHlvdSBzaG91 bGQgc3RhdGUgdGhhdCBleHBsaWNpdGx5KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5NeSBhc3N1bXB0aW9uIHdhcyB0aGF0IHJlY2VpdmluZyBhbiB1bmtub3duIFNQSSB3b3Vs ZCBhdXRvbWF0aWNhbGx5IGNhdXNlIHRoZSBwYXJzaW5nIHRvIGZhaWwgYXMgYSB2YWxpZCBFU1Ag bWVzc2FnZS4gSSBjYW4gYWRkIHRoYXQgdG8gdGhlIHRleHQuIEFkZGluZyBieXRlcyB0byB0aGUg c3RyZWFtIHdvdWxkIHNoaWZ0IHRoZSB2YWxpZCBTUEkuIEJleW9uZCB0aGF0LCBhcyB5b3UgbWVu dGlvbiB0aGUgcGFja2V0DQogd291bGQgbm90IGJlIGRlY3J5cHRhYmxlLCBhbmQgY2VydGFpbmx5 IHRoZSBuZXh0IGJ5dGVzIGFmdGVyIHRoZSBpbnZhbGlkIGZyYW1lJ3MgbGVuZ3RoIHdvdWxkIG5v dCBwYXJzZSBhcyBhIHZhbGlkIFNQSS4gVGhlIHJlYWRpbmcgd291bGQgc3RvcCBieSB0aGVuIGF0 IGxlYXN0LiBXZSBjYW4gYWxzbyByZWNvbW1lbmRlZCB0aGF0IHJlYWRlcnMgZW5mb3JjZSBhIHNh bmUgbGltaXQgb24gZnJhbWUgc2l6ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gdGhlIGF0dGFja2VyIGNhbiBjYXVzZSBvbmUgbGFyZ2Ug ZnJhbWUgdG8gYmUgcmVhZCwgYnV0IGFmdGVyIHRoYXQgdGhlIGNvbm5lY3Rpb24gd2lsbCBiZSB0 b3JuIGRvd24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TXkgY29uY2VybiAoYXMgYSBwcmV2 aW91cyBJUHNlYyBpbXBsZW1lbnRvcikgaXMg4oCcYXJlIHRoZXJlIHZhbGlkIHJlYXNvbnMgZm9y IHlvdSB0byBnZXQgYW4gaW52YWxpZCBTUEnigJ07IGZvciBleGFtcGxlLCBvbmUgc2lkZSBoYXMg dG9ybiBkb3duIHRoZSBTQSwgYnV0IHRoZSBvdGhlciBzaWRlIGhhc27igJl0IGhlYXJkIHRoZSBk ZWxldGUgbm90aWZ5IHlldD8mbmJzcDsgSSBiZWxpZXZlDQogdGhlcmUgYXJlIHNjZW5hcmlvcyB3 aGVyZSB0aGlzIGNhbiBoYXBwZW4gKG91ciBpbXBsZW1lbnRhdGlvbiBrZXB0IGFyb3VuZCBhIGxp c3Qgb2YgcmVjZW50bHktdG9ybi1kb3duIFNQSXMgdG8gYXZvaWQgc3B1cmlvdXMgZXJyb3IgbG9n cyB3aGVuIHRoaXMgaGFwcGVuZWQ7IGhvd2V2ZXIgSSBkb27igJl0IGJlbGlldmUgd2Ugd2FudCB0 byBtYW5kYXRlIHRoYXQgYXBwcm9hY2ggaW4gZ2VuZXJhbCkuICZuYnNwO09uIHRoZSBvdGhlciBo YW5kLCBpZiB0aGUgb25seQ0KIGNvc3QgaXMgcmVlc3RhYmxpc2hpbmcgdGhlIFRDUCBjb25uZWN0 aW9uLCBpdCBtaWdodCBiZSByYXJlIGVub3VnaOKApjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_a2536b36f8a34d88b93bf74d7839df54XCHRTP006ciscocom_-- From nobody Wed May 17 13:17:13 2017 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 7967E1200CF for ; Wed, 17 May 2017 13:17:11 -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 7C7vlbab_KSs for ; Wed, 17 May 2017 13:17:09 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232C012009C for ; Wed, 17 May 2017 13:17:09 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id v15so6226843wmv.0 for ; Wed, 17 May 2017 13:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=8omzFsCwu8I//xUNV8AHASCihQOgFfCv1hyZ4E1VHRc=; b=TxJzGJbb3rFhkDmi0r3PTWKZvrys4riqxeQeDHaEtYVmJ5/7QElo/mV/PCC0diwiG5 TozjAZqHk6mmRAS78E0e6LJL+2PtxBzyNHFXavE9z4r2PgUzyM0Zd+TqAd0KBEx3LxlH XY3G82rOJAY3rqBRuOG9EMk/zkUF6dGthFEVZX4P5R5/5e1GURm6yANIO0+1q4izI3XM aDugeo352ORLqsAD2s+x85cOcM64jY9UzWRnOrBcXg32lz6IfF9zzbH99c9s0sKQr3I1 sB4yTLN4ysmlgABHrSLpijog2gwxo3QjT/jknLVIjBuMsCzzXIzaPsG0bGly+9Hd1s8o owIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=8omzFsCwu8I//xUNV8AHASCihQOgFfCv1hyZ4E1VHRc=; b=DPxkJ/FvndWh+pIsTL8Sat26SfBlIarPGtS6hmCtUfNcdodm1RXGSLcbSNrtcEu2zi Iap4myrpae0LSXGesd1Zm5Sj1zhWI9EmEVF9M23tlJ2mEUN/Xh8TGHsq2h/RAHxb2wqg qK7NXB+LMxYvSTnPx/V/B2XQIHB5w1PiOJaf2X6gGJS2fAbPv2PiBeHjzE8AzB8RyZPR pOPlVawCtZb/QaSXyoygJ1zvxSyNqmfR5Nu+42Cw/4VqrsCJxQVZ/CKIHtmxMoyYWWoX OWDeTPAKw/ii7381GQkUU0KWEqfzh1Vl8Ylh1OMPWqDgUSU5bTnP+XrD/4l5qvWczEDL lKJA== X-Gm-Message-State: AODbwcBUZfMApu8n212GOAKJRWDjKBmzkQw7lwBPgfAxKfjyI7s9BBuZ cbgliMrzd6lN7Q== X-Received: by 10.28.238.20 with SMTP id m20mr351034wmh.121.1495052227649; Wed, 17 May 2017 13:17:07 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id 17sm20921003wmn.7.2017.05.17.13.17.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 May 2017 13:17:06 -0700 (PDT) From: Yoav Nir Message-Id: <9EA132F7-2390-4D3F-B903-428B6D48FF60@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_76BC6348-1F97-455B-8DC2-D91B3E8B3836"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 17 May 2017 23:17:04 +0300 In-Reply-To: Cc: "IPsecme WG (ipsec@ietf.org)" To: "Scott Fluhrer (sfluhrer)" References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] Question about ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 20:17:11 -0000 --Apple-Mail=_76BC6348-1F97-455B-8DC2-D91B3E8B3836 Content-Type: multipart/alternative; boundary="Apple-Mail=_815BA48A-D4D8-4D9C-B59E-17A85ACE3A8B" --Apple-Mail=_815BA48A-D4D8-4D9C-B59E-17A85ACE3A8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 17 May 2017, at 22:12, Scott Fluhrer (sfluhrer) = wrote: >=20 >=20 >=20 >=20 > My TCP may be rusty, but I think Alice=E2=80=99s legitimate packet has = the sequence number to indicate it is retransmitting the byte that Bob = already has. I don=E2=80=99t know if that means that the new data = overwrites the old data, that the old data remains, of that the stack = checks that it matches. >=20 > I don=E2=80=99t think it=E2=80=99s defined within TCP (rather, it=E2=80=99= s up to the individual stack); on the other hand, in general, the TCP = stack has already handed off the byte to the application (the IPsec = packet stream parser), and so it *can=E2=80=99t* overwrite it. Oh, right. > That said, most of us feed the IPsec stack with packets generated on = networks with an MTU of 1500. Even if we add the IPsec over head on top = of that, it=E2=80=99s still less than 2.5% of the space afforded by a = 16-bit length field. At least for ESP packets. >=20 > If the receiver were to break the connection whenever it received some = number (2? 3?) of packets that had a length field that exceeded 1544 = (or whatever the maximum packet is for the particular algorithm) = followed by an ESP field that was not zero, >=20 > =E2=80=9CESP field=E2=80=9D; do you mean SPI? Yes, sorry. >=20 > this would fix the problem without letting Eve break the connection = with just one injected byte. >=20 > I f you don=E2=80=99t=E2=80=99 use IKE fragmentation, then I believe = IKE packets could be over the limit we picked (unless we picked a rather = conservative one); would that be an issue? So, was that something you = were trying to address with the ESP field above? Yes. A non-zero SPI field means ESP rather than IKE. It=E2=80=99s not always true that IKE can be large but ESP is at most = MTU + header. We used to collect fragments into a large packet and then = encrypt that packet. With regular ESP that created a fragmented ESP = (which caused endless interop problems with Cisco implementations), but = with IKE over TCP the large ESP packet could be sent on the stream. But = in general, most packets are TCP or VoIP so most packets fit within MTU. But since Tommy=E2=80=99s happy with tearing down the connection after = one invalid SPI, that solves the problem nicely. By the way: do we tear it down after one bad MAC as well? Yoav --Apple-Mail=_815BA48A-D4D8-4D9C-B59E-17A85ACE3A8B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 17 May 2017, at 22:12, Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com> = wrote:

 

 
My TCP may be rusty, but I think Alice=E2=80=99s legitimate = packet has the sequence number to indicate it is retransmitting the byte = that Bob already has. I don=E2=80=99t know if that means that the new = data overwrites the old data, that the old data remains, of that the = stack checks that it matches.
 
I don=E2=80=99t think = it=E2=80=99s defined within TCP (rather, it=E2=80=99s up to the = individual stack); on the other hand, in general, the TCP stack has = already handed off the byte to the application (the IPsec packet stream = parser), and so it *can=E2=80=99t* overwrite = it.

Oh, right.

That said, most of us = feed the IPsec stack with packets generated on networks with an MTU of = 1500. Even if we add the IPsec over head on top of that, it=E2=80=99s = still less than 2.5% of the space afforded by a 16-bit length field. At = least for ESP packets.
 
If the receiver were to break the connection whenever = it received some number (2?  3?) of packets that had a length field = that exceeded 1544 (or whatever the maximum packet is for the particular = algorithm) followed by an ESP field that was not zero,
 
=E2=80=9CESP field=E2=80=9D= ; do you mean = SPI?

Yes, sorry.

 
this would fix the problem without letting Eve break the = connection with just one injected byte.
 
I f you don=E2=80=99t=E2=80= =99 use IKE fragmentation, then I believe IKE packets could be over the = limit we picked (unless we picked a rather conservative one); would that = be an issue?  So, was that something you were trying to address = with the ESP field = above?

Yes. A non-zero SPI field means ESP rather than = IKE. 

It=E2=80=99s not always = true that IKE can be large but ESP is at most MTU + header. We used to = collect fragments into a large packet and then encrypt that packet. With = regular ESP that created a fragmented ESP (which caused endless interop = problems with Cisco implementations), but with IKE over TCP the large = ESP packet could be sent on the stream.  But in general, most = packets are TCP or VoIP so most packets fit within MTU.

But since Tommy=E2=80=99s happy with tearing down = the connection after one invalid SPI, that solves the problem = nicely.

By the way: = do we tear it down after one bad MAC as well?

Yoav

= --Apple-Mail=_815BA48A-D4D8-4D9C-B59E-17A85ACE3A8B-- --Apple-Mail=_76BC6348-1F97-455B-8DC2-D91B3E8B3836 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZHK/BAAoJELhJCxUKWMyZ8WQIAM0K7FATyBTg0N/ZSw3FZqtC 44/vjJpmRSZaR0L8BJWapRXC6oeJigfEbI2ciEnZqMhtSai/yD0hyHj5Px8lEDYJ QFHswDqmnR3/rqIGM1hr7GfsAgIgNw1309N47ckJor99B/GDexuA33u/T2/supuF 0ZLgm2ve1qQ/aTi5f2e5by6iyl8JmCM8m1sa2WVZ3EK5480t1LzIJOJdBqaMNSDg CB0/al07B7HdbOVzTN38C6o8Pfz2m1JiAztM54ULN0qp0iqGNJCva1byIQ5xtM2i k59jyU+ru1oY7u9YWI+Z+BJQ0ObHmzfgEPnt23NefvqCdPzr3DvVgJKxhO3ygvs= =gvuN -----END PGP SIGNATURE----- --Apple-Mail=_76BC6348-1F97-455B-8DC2-D91B3E8B3836-- From nobody Thu May 18 03:54:31 2017 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 CB66512EAC6 for ; Thu, 18 May 2017 03:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54ltRaGx6kLP for ; Thu, 18 May 2017 03:54:28 -0700 (PDT) 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 E684812EB02 for ; Thu, 18 May 2017 03:49:28 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v4IAn9ok001250 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 May 2017 13:49:09 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v4IAn8TM005353; Thu, 18 May 2017 13:49:08 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22813.31780.782415.16010@fireball.acr.fi> Date: Thu, 18 May 2017 13:49:08 +0300 From: Tero Kivinen To: Tommy Pauly Cc: "Scott Fluhrer \(sfluhrer\)" , "IPsecme WG \(ipsec\@ietf.org\)" , Yoav Nir In-Reply-To: <12068173-33D1-4D03-B07E-2C84FF012669@apple.com> References: <12068173-33D1-4D03-B07E-2C84FF012669@apple.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 20 min Archived-At: Subject: Re: [IPsec] Question about ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 10:54:31 -0000 Tommy Pauly writes: > However: > a) That=E2=80=99s in a paragraph that starts =E2=80=9CIf a T= CP connection is being > used to resume a previous IKE session=E2=80=A6=E2=80=9D; does it = apply only in that case=3F >=20 > No, the MUST close applies for all connections, regardless of resumpt= ion. We > could add a paragraph break to make that explicit. Yes, adding paragraph break will make it more explicit, so please, do s= o. > b) An ESP message is of the form [SPI][Sequence number][Rand= om > bytes]; unless you happen to get a SPI < 256 or length < 8, it=E2= =80=99s not clear > how you could get something that is not of that format (unless yo= u mandate > that the ESP length must be a multiple of 4 bytes; in that case, = you > should state that explicitly) >=20 > My assumption was that receiving an unknown SPI would automatically c= ause the > parsing to fail as a valid ESP message. I can add that to the text. Actually no. Unknown SPI is something that can happen in normal case too, as there are some race conditions which might cause the one end to install the Child SA before the other end has installed it, thus this might cause message with unknown SPI to come in. On the other hand as TCP is reliable transport, there are less changes of this to happen, but I think it can still happen, as the IKE packets and ESP packets can be reordered inside the processing host, i.e., even if host A sends IKE packet creating the Child SA first, and then immediately followed by the ESP packet using that Child SA, it might be possible that IKE packet is still being processed when the ESP packet arrives, and ESP packet might hit unknown SPI error because of that.=20 On the other hand if you receive several messages where the message authentication failes (i.e., ICV check fails), then that is good indication that something is wrong.=20 > Adding bytes to the stream would shift the valid SPI. Beyond that, > as you mention the packet would not be decryptable, and certainly > the next bytes after the invalid frame's length would not parse as a > valid SPI. The reading would stop by then at least. We can also > recommended that readers enforce a sane limit on frame size. I think it would be good idea to say that if the TCP stream looks like being corrupted, then close the TCP stream and try with new TCP stream. Note, that this is DoS attack we cannot defend against when using IPsec encapsulated in the TCP. Attackers can always do DoS by either deleting packets, or sending RST frames or modifying frames in transit. We should try to recover from easy attacks, like sending one RST frame (we just recreate TCP session), or modifying single byte in transit (skip it, but if too many errors come in, restart TCP). > So the attacker can cause one large frame to be read, but after that = the > connection will be torn down. Also as the frame inside the TCP stream has 16-bit length field, it cannot even cause the other end to read big packet, just less than 64k packet. If we would have 32-bit lenght field this issue would be much bigger, as then we would need to add timer while reading the frame, or add max length checks for the packet. Now, we can safely assume that other end will send enough data that we have the packet specified by the length. If there are enough parsing errors while reading packets, we drop the TCP session.=20 --=20 kivinen@iki.fi From nobody Thu May 18 04:00:01 2017 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 641BD12EB07 for ; Thu, 18 May 2017 03:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.779 X-Spam-Level: X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUpO1UqIUBYm for ; Thu, 18 May 2017 03:59:58 -0700 (PDT) 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 54C9D12946E for ; Thu, 18 May 2017 03:55:09 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v4IAt2NV003527 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 May 2017 13:55:02 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v4IAt23S005625; Thu, 18 May 2017 13:55:02 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22813.32134.898184.482152@fireball.acr.fi> Date: Thu, 18 May 2017 13:55:02 +0300 From: Tero Kivinen To: Yoav Nir Cc: "Scott Fluhrer \(sfluhrer\)" , "IPsecme WG \(ipsec\@ietf.org\)" In-Reply-To: <9EA132F7-2390-4D3F-B903-428B6D48FF60@gmail.com> References: <9EA132F7-2390-4D3F-B903-428B6D48FF60@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min Archived-At: Subject: Re: [IPsec] Question about ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 10:59:59 -0000 Yoav Nir writes: > But since Tommy=E2=80=99s happy with tearing down the connection afte= r one invalid > SPI, that solves the problem nicely. I do not think we want to do that. There are valid cases where we might get unknown SPIs, so tearing connection down after one of those is not good solution.=20 > By the way: do we tear it down after one bad MAC as well=3F We should never get bad MACs for known SPIs unless there is corruption in the packet, thus that always indicates that there is either attacker modifying the packets, or uncorrectable bit errors in transit, or buggy implementation. So tearing it down after one bad MAC would be acceptable, as those should not happen in normal situations. If we get lots of packets with unknown SPIs then we should also tear it down, but not for the first such event, especially if the SPIs are same. So perhaps tear it down when we receive more than n frames with unknown SPIs, or when we receive one frame which fails ESP or IKE authentication MAC checks. --=20 kivinen@iki.fi From nobody Thu May 18 06:11:26 2017 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 81F3E129504 for ; Thu, 18 May 2017 06:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVIWwaIGHW6U for ; Thu, 18 May 2017 06:11:23 -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 23F7A129549 for ; Thu, 18 May 2017 06:04:36 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 09F1DE031 for ; Thu, 18 May 2017 09:31:22 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 47783636E0 for ; Thu, 18 May 2017 09:04:35 -0400 (EDT) From: Michael Richardson To: "IPsecme WG \(ipsec\@ietf.org\)" In-Reply-To: <22813.31780.782415.16010@fireball.acr.fi> References: <12068173-33D1-4D03-B07E-2C84FF012669@apple.com> <22813.31780.782415.16010@fireball.acr.fi> 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: Subject: Re: [IPsec] Question about ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 13:11:24 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: > Actually no. Unknown SPI is something that can happen in normal case > too, as there are some race conditions which might cause the one end > to install the Child SA before the other end has installed it, thus > this might cause message with unknown SPI to come in. On the other > hand as TCP is reliable transport, there are less changes of this to > happen, but I think it can still happen, as the IKE packets and ESP > packets can be reordered inside the processing host, i.e., even if > host A sends IKE packet creating the Child SA first, and then I agree that reording could happen inside the "host" It seems that a reasonable implementation might spawn off many TCP-IKE-ESP daemons (perhaps even via TCP-load balancer proxy) to demux and decapsulate the traffic, turning it into real ESP and real IKE packets, and send it to an existing daemon. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlkdm+MACgkQgItw+93Q 3WXaswf/SXQutspvsz4MlQFd7rfb3S5pAi14eVxKtN5WDoQoyiHHf70S1GGpB2bK Y3pajo61OsinFOgK7xLzTfvqTQhpuNwolsR67whx0p+THu4esG6vUJBvVk4Ri/d+ 4TVeUnHj1B3WdCbBdkWnbzpmfynCiT7xaopjsomnGHFSApAeSOmOyOWTTgEhGata Y3o772JfR7BoluFclvfqHdbSXyg0I9AAUIFdsIYhN4sq5H0iGm/GgNsfaRVhXWR+ 2amVAK3l9JdLeBtR7/AxWLROh9dDB6CKHkcZUzscbaAdhxc4T1/zgXVHvWUBZrqL hMqujhmsKC6wDN5QX3/QQq2NJ3Sk0g== =MoeF -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 18 08:32:11 2017 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 8DCE612EAD5 for ; Thu, 18 May 2017 08:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] 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 EsgAu7efQQuR for ; Thu, 18 May 2017 08:32:08 -0700 (PDT) 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 DF0E4126B71 for ; Thu, 18 May 2017 08:26:39 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3wTFQj0pmSzDbb for ; Thu, 18 May 2017 17:26:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1495121197; bh=6Yrh3mrc0TQ6wjc2TpD6667SBnZp7i134EVEhuLTxmk=; h=Date:From:To:Subject:In-Reply-To:References; b=s7oj5a+2NFCz/lotOnnN2NGmXaa1+hiYh4VhXxqY/obdy6Jdsbgoakvr8p0juc4ie HxqFxWlEXs8ebxF7vlKu3qP6DrU4AWc6Qt4oXmMDIzEuk7IXjFdF6N9j3enoK4Eb0q r9FGWj2UBb4/33gIGK61Zj1yHvuUa1CL1XY9vNkg= 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 epjD_YSWVaT6 for ; Thu, 18 May 2017 17:26:36 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Thu, 18 May 2017 17:26:36 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 7D4AD19C333; Thu, 18 May 2017 11:26:35 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 7D4AD19C333 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 769F8415F95B for ; Thu, 18 May 2017 11:26:35 -0400 (EDT) Date: Thu, 18 May 2017 11:26:35 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <25221.1495112675@obiwan.sandelman.ca> Message-ID: References: <12068173-33D1-4D03-B07E-2C84FF012669@apple.com> <22813.31780.782415.16010@fireball.acr.fi> <25221.1495112675@obiwan.sandelman.ca> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Question about ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 15:32:11 -0000 On Thu, 18 May 2017, Michael Richardson wrote: > It seems that a reasonable implementation might spawn off many > TCP-IKE-ESP daemons (perhaps even via TCP-load balancer proxy) to demux > and decapsulate the traffic, turning it into real ESP and real IKE packets, > and send it to an existing daemon. If it is just TCP without any TLS wrapper, a "reasonable" host would really do this inside the kernel without copying back and forth between userland. Once TLS is involved, things become different, unless you want to build a TLS stack into the kernel :P Paul From nobody Thu May 18 11:45:42 2017 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 C3DBF129423 for ; Thu, 18 May 2017 11:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnoCmrP0YNBE for ; Thu, 18 May 2017 11:45:38 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F720126CF6 for ; Thu, 18 May 2017 11:40:40 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 1AB8A203B5; Thu, 18 May 2017 15:07:27 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 73D77636E0; Thu, 18 May 2017 14:40:39 -0400 (EDT) From: Michael Richardson To: Paul Wouters cc: "ipsec\@ietf.org WG" In-Reply-To: References: <12068173-33D1-4D03-B07E-2C84FF012669@apple.com> <22813.31780.782415.16010@fireball.acr.fi> <25221.1495112675@obiwan.sandelman.ca> 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: Subject: Re: [IPsec] Question about ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 18:45:41 -0000 --=-=-= Content-Type: text/plain Paul Wouters wrote: >> It seems that a reasonable implementation might spawn off many >> TCP-IKE-ESP daemons (perhaps even via TCP-load balancer proxy) to demux >> and decapsulate the traffic, turning it into real ESP and real IKE >> packets, >> and send it to an existing daemon. > If it is just TCP without any TLS wrapper, a "reasonable" host would > really do this inside the kernel without copying back and forth between > userland. Linux XDP can probably do it in a way that can be offloaded. > Once TLS is involved, things become different, unless you want to build > a TLS stack into the kernel :P There are a multitude of TLS accelerators that live "below" the kernel. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlkd6qcACgkQgItw+93Q 3WVpdwf9G/NzDDUYFxfwUOPatVd0Ql/Ih4oWsTdqAlt9vQEn3nBl5UzH3DKNuVOm GmEOcin6mMbB5tBvQbUcrscAoq9JAz1YowQAWhn1/n7qN84koMwZGu+MY4kd33uS iOey0HdoDLhJCc9v3hqSMkcHNyYWi2OczG0aCXwjb0ja9pSfmqauGFH2MIJnkkd/ EXWVt1ppfwCVMXd7g4FB5WB5U5oYMOZZSH9mQPYXp+zGgVZq88PTOlTNB/QebX6I LLJtbpnH20SD+FFyKt7bWSVoFWIYddrh8//VGaEz30iFHDJfhfRC/+2sUAwCsG2Z ZzRFpaESPOd1+y8+mIQFxNgqBMc0yQ== =EAz8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 18 13:40:07 2017 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 1272612E76A for ; Thu, 18 May 2017 13:40:05 -0700 (PDT) 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, 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=-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 BHPvuod54p1k for ; Thu, 18 May 2017 13:40:03 -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 0179D129ACC for ; Thu, 18 May 2017 13:33:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGW74225; Thu, 18 May 2017 20:33:12 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 18 May 2017 21:33:11 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.117]) by SJCEML703-CHM.china.huawei.com ([169.254.5.229]) with mapi id 14.03.0235.001; Thu, 18 May 2017 13:33:06 -0700 From: Linda Dunbar To: "IPsec@ietf.org" Thread-Topic: can IPSec tunnel support multi-tenancy? Thread-Index: AdLQFCiL/SbJhQcZT4ywT+pEdSMoFA== Date: Thu, 18 May 2017 20:33:06 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F6592A3AB5@SJCEML702-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.140] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F6592A3AB5SJCEML702CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.591E0508.012B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 40ac6d685bd3795efca22f0b7abdcf8b Archived-At: Subject: [IPsec] can IPSec tunnel support multi-tenancy? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 20:40:05 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F6592A3AB5SJCEML702CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IPSec experts, When an IPSec tunnel is established between two sites (say, SD-WAN use case= ), is there any fields in the header that can be used to differentiate payl= oad belonging to different tenants? Thank you very much --_000_4A95BA014132FF49AE685FAB4B9F17F6592A3AB5SJCEML702CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

IPSec experts,

 

When an IPSec tunnel is established between two site= s (say, SD-WAN use case), is there any fields in the header that can be use= d to differentiate payload belonging to different tenants?

 

Thank you very much

--_000_4A95BA014132FF49AE685FAB4B9F17F6592A3AB5SJCEML702CHMchi_-- From nobody Thu May 18 14:05:39 2017 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 4973312009C for ; Thu, 18 May 2017 14:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OysLbG23fLnU for ; Thu, 18 May 2017 14:05:36 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 140B612EC02 for ; Thu, 18 May 2017 13:59:11 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id m17so29351036pfg.3 for ; Thu, 18 May 2017 13:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pStNPX7Xr7OSlOmWHs4tXJTLrNFvQulUbPg4ap68qh8=; b=moaiTY4i78e3Iy/5AGzy6qD+VL+OEu5XICPhxu3ioDQaouKIuIH0vxHSnmgWa4Juib 7mA+jcEGUKruUm2LTz32tEAcXgU0WRGtRh7vKhmE29Pscdzj7Xagd9aThefxAAOOJ6UT vaiwo0Jlryl7VdvEgzrDtXmuiF4kgLE2+LpfbC1IDB6akrwwBzrN/x7lG8kGjJpuISo4 xraNOW6HqF2holrwBwTasNXdaGAS3J6H3xDx38o51t2WOO5orzhJPA1z4NnElx175Nlw O2QZ6kXqYNbOywzpeRXWpr4rU4O2r2Baoo9CZgM1P5JP7263f+RKT0k87RJBlmatWK2+ F/HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pStNPX7Xr7OSlOmWHs4tXJTLrNFvQulUbPg4ap68qh8=; b=cDniWxpgTRryehYQMALv4m33vDy22Ly2uqQOUG846MwTYI4hz3XuYmnTvOBqCW2U3L bL5/Wi9GRciQZTh2IUZVLZ0Fn22LTeD3tj0G/daQ2lfN00tnmnlashdkBjXab+Q3Hqha rsvYwQnwwMnFjfTMsptJKcb2i/mwWsvFyeLpG3ye8p+KtjdZHnZ/HNiTazZnD63mvyM+ BXcvdIeTqyUHXObkfxLTjopgwlizbRpR+ezMxdJcEWYm4D8lyf3JOi17kECpOw3sM/09 8cNoWDMtl9XyraxU2Elk36pWQb36t77VAnzjXdpMK0SulXhchsXG3G74FUIOPF+m7pku 5TwQ== X-Gm-Message-State: AODbwcCuO/IrudG56WkoTRHyJYD5x1rPr7EU24a3MewylAYS/VuJmMvD miRP6h6TT51chdeY2J31nTBQcDigvw== X-Received: by 10.99.55.68 with SMTP id g4mr6661750pgn.115.1495141150737; Thu, 18 May 2017 13:59:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.149.130 with HTTP; Thu, 18 May 2017 13:59:10 -0700 (PDT) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6592A3AB5@SJCEML702-CHM.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F6592A3AB5@SJCEML702-CHM.china.huawei.com> From: Vishwas Manral Date: Thu, 18 May 2017 13:59:10 -0700 Message-ID: To: Linda Dunbar Cc: "IPsec@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [IPsec] can IPSec tunnel support multi-tenancy? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 21:05:38 -0000 Lina, I think that is a function of the control plane - so a tunnel is established for a tenant - we do not need to identify tenant after the session is created. Can a tunnel have traffic from different tenants? If so the payload could have some identifiers (GRE with Tenant data). -Vishwas On Thu, May 18, 2017 at 1:33 PM, Linda Dunbar wrote: > > > IPSec experts, > > > > When an IPSec tunnel is established between two sites (say, SD-WAN use > case), is there any fields in the header that can be used to differentiate > payload belonging to different tenants? > > > > Thank you very much > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Thu May 18 14:14:40 2017 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 F343A129B5E for ; Thu, 18 May 2017 14:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 v-fubE0IgpJE for ; Thu, 18 May 2017 14:14:34 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8E6412EB5B for ; Thu, 18 May 2017 14:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4384; q=dns/txt; s=iport; t=1495141688; x=1496351288; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=HYX0Hc6IJT/Y7NAEXPfvqQY5qDY0lXp0uo3PasTJZ+c=; b=UyRcHzIoOmTY79Hb9DhN9o8LryKjV0u6bzH7Yu5OkMkmY0PHpx5tEIta GAev2i1R+AK2WKl6liSrg9KOd3+QHb1MzsUcxIgt7u9+Mu/Iyu4jiO0Io U89guaugk+vmRAvqhyQjq+0OA2Y5EQOYHvdMmDZ3S3VxtgJB/CLXUkDuH M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CcAAAyDB5Z/4MNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYoEMB41+kW6QPoU4gg+GJAKFcD8YAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQEDLT4eAgEIEQQBASgHMhQJCAEBBAESCIobsTmLGgEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2GX4R5hRmFPAWeEwGTEZF3lEUBHziBCnAVhzx2hyWBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,360,1491264000"; d="scan'208,217";a="428527949" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 May 2017 21:08:07 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v4IL87ik010308 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 18 May 2017 21:08:07 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 18 May 2017 17:08:06 -0400 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; Thu, 18 May 2017 17:08:06 -0400 From: "Scott Fluhrer (sfluhrer)" To: Linda Dunbar , "IPsec@ietf.org" Thread-Topic: [IPsec] can IPSec tunnel support multi-tenancy? Thread-Index: AdLQFCiL/SbJhQcZT4ywT+pEdSMoFAABnM3A Date: Thu, 18 May 2017 21:08:06 +0000 Message-ID: <0edff84e3c16497e8de3566ca53aa38f@XCH-RTP-006.cisco.com> References: <4A95BA014132FF49AE685FAB4B9F17F6592A3AB5@SJCEML702-CHM.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6592A3AB5@SJCEML702-CHM.china.huawei.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.52] Content-Type: multipart/alternative; boundary="_000_0edff84e3c16497e8de3566ca53aa38fXCHRTP006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] can IPSec tunnel support multi-tenancy? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 21:14:37 -0000 --_000_0edff84e3c16497e8de3566ca53aa38fXCHRTP006ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You could assign different SPIs to different tenants. From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, May 18, 2017 4:33 PM To: IPsec@ietf.org Subject: [IPsec] can IPSec tunnel support multi-tenancy? IPSec experts, When an IPSec tunnel is established between two sites (say, SD-WAN use case= ), is there any fields in the header that can be used to differentiate payl= oad belonging to different tenants? Thank you very much --_000_0edff84e3c16497e8de3566ca53aa38fXCHRTP006ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You could assign differe= nt SPIs to different tenants.

 

From: IPsec [m= ailto:ipsec-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Thursday, May 18, 2017 4:33 PM
To: IPsec@ietf.org
Subject: [IPsec] can IPSec tunnel support multi-tenancy?<= /span>

 

 

IPSec experts,

 

When an IPSec tunnel is established between two site= s (say, SD-WAN use case), is there any fields in the header that can be use= d to differentiate payload belonging to different tenants?

 

Thank you very much

--_000_0edff84e3c16497e8de3566ca53aa38fXCHRTP006ciscocom_-- From nobody Thu May 18 14:18:33 2017 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 074E0129C36 for ; Thu, 18 May 2017 14:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] 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 7DZVABJkqK6n for ; Thu, 18 May 2017 14:18:30 -0700 (PDT) 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 4BCDB129B53 for ; Thu, 18 May 2017 14:12:09 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3wTP5K15kszF0K; Thu, 18 May 2017 23:12:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1495141925; bh=OLAOlOb7rTUPkI62v260lHCmz9goFGoVsemmtG8FVEg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=aCIvydOdbQcV83y4QFRsqCdUyUQcViWDhtFNmwuQLi6+xAXvSiAKb8aTjSpVg62Kx OTz6U8fLSJnByW3VPUDYtF2769Wz0XL1Loqhev8iXXvd9x12819viN4CZIJBAJ9gn+ 0AN5A928G1sbJzvv+34rPM9r3sQO+UWTboAu7KR0= 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 31cb8sdhAWZt; Thu, 18 May 2017 23:12:03 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 18 May 2017 23:12:02 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 84F4519C333; Thu, 18 May 2017 17:12:01 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 84F4519C333 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6A2A040008A1; Thu, 18 May 2017 17:12:01 -0400 (EDT) Date: Thu, 18 May 2017 17:12:01 -0400 (EDT) From: Paul Wouters To: Linda Dunbar cc: "IPsec@ietf.org" In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6592A3AB5@SJCEML702-CHM.china.huawei.com> Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F6592A3AB5@SJCEML702-CHM.china.huawei.com> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] can IPSec tunnel support multi-tenancy? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 21:18:32 -0000 On Thu, 18 May 2017, Linda Dunbar wrote: > When an IPSec tunnel is established between two sites (say, SD-WAN use case), is there any fields in the header that can be used to > differentiate payload belonging to different tenants? libreswan supports Labeled IPsec that can be used with seperate different IPsec SA's to uniquely label/compartmentalize streams. For instance, you can put an SElinux label on it so only traffic with that label is allowed over such a tunnel. This can be used with MLS based systems. You can have multiple IPsec SA's with the same src/dst and different labels, so that "secret" will go over the "secret" IPsec SA, and "top secret" goes over the "top secret" IPsec SA. Our implementation currently only supports IKEv1 using a private space assignment for the label negotiation. For IKEv2, it would be good if we got a proper IANA allocation and RFC, but I haven't started that process yet. Paul From nobody Thu May 18 15:19:14 2017 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 B9DD0124281 for ; Thu, 18 May 2017 15:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 B43y_jahxgdh for ; Thu, 18 May 2017 15:19:11 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1C5F129C40 for ; Thu, 18 May 2017 15:13:26 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 1E76020051C26; Thu, 18 May 2017 15:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=y2ezAOIASrrDMF T2UWxEutCB22w=; b=JFDxF+UgYPFkz2QmKpYmJgJ1kKKgGlOTE/JnqDIT8hajcj /bvTsIIpx2GItJhnV9660+L3y9+ZWMcujjUYBrSgUFIWhQz50D8o4F2IQYdr3oZv JUPc7USwGF3fBwu7QW7lZQtyyjrkJpO4r8yLPwN7UPBpES2JbIzNXS1TnH6wc= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id CD31A20051C25; Thu, 18 May 2017 15:13:25 -0700 (PDT) Date: Thu, 18 May 2017 17:13:23 -0500 From: Nico Williams To: Linda Dunbar Cc: "IPsec@ietf.org" Message-ID: <20170518221321.GJ10188@localhost> References: <4A95BA014132FF49AE685FAB4B9F17F6592A3AB5@SJCEML702-CHM.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6592A3AB5@SJCEML702-CHM.china.huawei.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [IPsec] can IPSec tunnel support multi-tenancy? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 22:19:13 -0000 On Thu, May 18, 2017 at 08:33:06PM +0000, Linda Dunbar wrote: > IPSec experts, > > When an IPSec tunnel is established between two sites (say, SD-WAN use > case), is there any fields in the header that can be used to > differentiate payload belonging to different tenants? "Yes", but. As others have said, you could have and use different different SA pairs for different users, with selection done via traffic selectors as usual. The protocol suite (ESP, IKEv2) certainly allows for this. And the IPsec security architecture (RFC4301) certainly allows for this too. For bump-in-the-wire (BITW) implementations, provided that each tenant gets a different, static IP address assignment, this is easy enough. Otherwise, for BITW it quickly becomes infeasible to get the semantics you probably want. For bump-in-the-stack (BITS), if it has no way to refer to user processes (which is to be expected of BITS), then what you want is infeasible in the general case. For native IPsec implementations, you might as well use transport mode, naturally, though the question is still relevant. You may or may not find support for multi-tenancy in the sense you gave. You basically want some sort of stateful IPsec machinery. See RFC5660 (by yours truly) for what that might entail. Nico -- From nobody Thu May 18 15:37:00 2017 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 1B2F212EBE2 for ; Thu, 18 May 2017 15:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 K6KyKXPjYbg5 for ; Thu, 18 May 2017 15:36:55 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22578126C7A for ; Thu, 18 May 2017 15:30:44 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id DD63020051C25; Thu, 18 May 2017 15:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=V0/e2fHzMNFyxT TAPzXl8hlbrr4=; b=iT8X5sQqfJTm+dpfy6oteAF1N79e6ZfynKPHnsNbxdnEpz ZFqy8ozvnUGNCYmOxob9Rk7LSk1Sud3LgOVSeIiOIcscc4Bqz/m6InDSSK/6K0Ua 3ejXsiQ13U1rp0IROU7sd8ufT9O6qAi6+Ac81aPVzJwCeXH5BRCdZEqUiGfzI= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id 9AABB20051C23; Thu, 18 May 2017 15:30:43 -0700 (PDT) Date: Thu, 18 May 2017 17:30:41 -0500 From: Nico Williams To: Linda Dunbar Cc: "IPsec@ietf.org" Message-ID: <20170518223039.GK10188@localhost> References: <4A95BA014132FF49AE685FAB4B9F17F6592A3AB5@SJCEML702-CHM.china.huawei.com> <20170518221321.GJ10188@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170518221321.GJ10188@localhost> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [IPsec] can IPSec tunnel support multi-tenancy? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 22:36:56 -0000 On Thu, May 18, 2017 at 05:13:23PM -0500, Nico Williams wrote: > For bump-in-the-wire (BITW) implementations, provided that each tenant > gets a different, static IP address assignment, this is easy enough. > Otherwise, for BITW it quickly becomes infeasible to get the semantics > you probably want. I would also add that for BITW, why would you want this? Nico -- From nobody Wed May 31 11:36:15 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 165F6129AB7; Wed, 31 May 2017 11:36:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149625576504.19877.4838028392528191053@ietfa.amsl.com> Date: Wed, 31 May 2017 11:36:05 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-10.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 18:36:05 -0000 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-10.txt Pages : 23 Date : 2017-05-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 Security Association establishment and ESP packets 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-10 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-tcp-encaps-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 31 11:38:00 2017 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 DBCB5129AB3 for ; Wed, 31 May 2017 11:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 xQdtooESGe1k for ; Wed, 31 May 2017 11:37:52 -0700 (PDT) Received: from mail-in24.apple.com (mail-out24.apple.com [17.171.2.34]) (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 854D1129AAD for ; Wed, 31 May 2017 11:37:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1496255867; 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=zZXO35hIu6h16NwoXFIajJOwdsPrHlGsQrHiuKjCXYw=; b=QC6mjifHT4DFPQIvcg3GEjIxJhkrcpH5DInLuFmrrTpI02lmSWdlnXIO+TCk4hLp QGJU06sBsnuuWSeFBt7gVj2eYhtBW18jIJ7bEVa4T1/boz9AjnD13KeO0EhO0pmx thmMbeGg0gHLX2nOUCeYwaKOggcZCymmcPtTMWzXAqRerycCopgGEBsD23JnlFDk 5bhG6sDbf4x6Hd0ZA3a1k8pd/HebpJBHMklo4bD4IPot02gyT6pVM4Sc/U3IE/jd oOsokTSXNlbiNYk36PlLG7jotrG/kpMzYEv+OoKRAKpOBxxJXhlSan3CYuUVKz/e slJ2curH0tI6/iYdU4xMAw==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in24.apple.com (Apple Secure Mail Relay) with SMTP id 5A.2E.17842.A7D0F295; Wed, 31 May 2017 11:37:47 -0700 (PDT) X-AuditID: 11ab0218-4df929a0000045b2-9a-592f0d7a21ac Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by relay3.apple.com (Apple SCV relay) with SMTP id F0.66.15148.A7D0F295; Wed, 31 May 2017 11:37:46 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_/JGGw0B+ynts9aqbjOaWsQ)" Received: from [17.153.35.59] (unknown [17.153.35.59]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OQT004OOYEW6E30@nwk-mmpp-sz11.apple.com>; Wed, 31 May 2017 11:37:46 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <34C32236-D200-421F-AF6E-F953DA79A869@apple.com> Date: Wed, 31 May 2017 11:37:27 -0700 In-reply-to: Cc: Eric Rescorla , Spencer Dawkins at IETF , IESG , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org, Tero Kivinen , IPsecME WG , Mark Nottingham To: "Mirja Kuehlewind (IETF)" References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> <22785.64570.259658.376130@fireball.acr.fi> <277aa94d-5aa1-7a28-94c7-81da0966c172@kuehlewind.net> <41594727-9667-42BD-ABB1-4583A3B00EA2@apple.com> <853700CB-D5DD-4BC7-A1F5-5AB61330E70D@apple.com> <22792.20148.255067.132946@fireball.acr.fi> <82B5E72F-C518-420B-B941-E4CE4DD1BF87@kuehlewind.net> <22792.31378.769444.232365@fireball.acr.fi> <78A72CF3-E011-4E8D-9F66-63C7918A8236@kuehlewind.net> <22793.40707.624092.66793@fireball.acr.fi> X-Mailer: Apple Mail (2.3430.2) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42IRbCgM1q3m1Y802PpU0uL9nzOMFiten2O3 mPFnIrPFi+sfmS32b3nBZjFzzgcWi6Pnn7NZrP/0mNFi2ZQ9zA6cHjtn3WX3WLLkJ5PH4a8L WTxaPi5k9di4+Durx+THbcwBbFFcNimpOZllqUX6dglcGWt+72cqeBtX0dvxirGB8Zx/FyMn h4SAicSsSW0sXYxcHEICa5gk/myayQqTuLpwJTtE4hCjxKHp8xhBErwCghI/Jt9jAbGZBcIk Lt15zQpR1M8kcfTIaeYuRg4OYQEJic17EkFq2ARUJI5/28AM0WsjsezjGnYQW1ggVeL1/V1s IDaLgKrExN+dYDM5BWwldsx7wAwyk1lgKpPEm0lLmEASIgLGEocnf4da9oVD4vTfRiaIU+Ul tj29zgaSkBCYzi6x9vFL5gmMQrOQXDsLybWzgA5kFlCXmDIlFyKsLfHk3QVWCFtNYuHvRUzI 4gsY2VYxCucmZuboZuYZmeglFhTkpOol5+duYgTF32omiR2MX14bHmIU4GBU4uEVuKgXKcSa WFZcmXuIUZqDRUmc9/o93UghgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjPm7N0Wo+Wa8WPXZ KiYwe4f7+3TN44tjnkbrLYrtCVj5ZcZjrfNiWZk3dK9O+1ngkv3pyockTtu/7+Jt/n5MtU1h tMh6/8ViveaP3N9CS45aOTu6egR/4M4WWXttcfC06QrZz3e9/fBhUrP5gv/ZUmfXHmuf/0Lj ga+PnG4P07Ps7UemHvv1564SS3FGoqEWc1FxIgAghctOoAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUi2FA8W7eKVz/S4P5WSYv3f84wWqx4fY7d YsaficwWL65/ZLbYv+UFm8XMOR9YLI6ef85msf7TY0aLZVP2MDtweuycdZfdY8mSn0weh78u ZPFo+biQ1WPj4u+sHpMftzEHsEVx2aSk5mSWpRbp2yVwZaz5vZ+p4G1cRW/HK8YGxnP+XYyc HBICJhJXF65k72Lk4hASOMQocWj6PEaQBK+AoMSPyfdYQGxmgTCJS3des0IU9TNJHD1ymrmL kYNDWEBCYvOeRJAaNgEViePfNjBD9NpILPu4hh3EFhZIlXh9fxcbiM0ioCox8Xcn2ExOAVuJ HfMeMIPMZBaYyiTxZtISJpCEiICxxOHJ36GWfeGQOP23kQniVHmJbU+vs01g5J+F5MBZSA6c BXQTs4C6xJQpuRBhbYkn7y6wQthqEgt/L2JCFl/AyLaKUaAoNSex0lgvsaAgJ1UvOT93EyM4 WgqDdzD+WWZ1iFGAg1GJh1fgol6kEGtiWXFlLjCUOJiVRHi7mPUjhXhTEiurUovy44tKc1KL DzFOZAR6cyKzlGhyPjCW80riDU1MDEyMjc2Mjc1NzGkprCTOy8oJdJFAemJJanZqakFqEcxR TBycUg2M7DsT9nr2xrzh8290jLzZcfB15C/G9Wcdb8+/1n7n/nO7qwaCm9x5D5T9K2ELuJi8 7PmUEh+bL6U2Am9tlu67qDQhaEFxwBmezexfclsStx4PPb7hb/1zBtEatynFRpdX/PubHTlX a+HKrLlRBnNL9i+Uin76dNK5m5FHFiufvDZlQ7N/pluEixJLcUaioRZzUXEiAEgPd2QJAwAA Archived-At: Subject: Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 18:37:54 -0000 --Boundary_(ID_/JGGw0B+ynts9aqbjOaWsQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hello, I've posted a new version of the draft that incorporates the changes = discussed in this thread. Please review! https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-tcp-encaps-10 = Thanks, Tommy > On May 12, 2017, at 3:25 PM, Tommy Pauly wrote: >=20 >=20 >=20 >> On May 8, 2017, at 5:49 AM, Mirja Kuehlewind (IETF) = wrote: >>=20 >> Does the proposed text changes from Tommy still refer to 443 anywhere = (lost track a bit but I guess the appendix still does right)? >>=20 >> Again I think we should talk about using 443 if that=E2=80=99s = what=E2=80=99s done in reality. However my understanding is that = real-life implementation use TCP/TLS which I think could be discussed in = the body rather than the appendix. >=20 > The current state will not refer to 443 in the body, but specify TCP = 4500, with the option to have both peers mutually agree on another port = to use if necessary. The working group had felt that bringing TLS over = 443 directly into the body would be inappropriate for the standard. We = mention in the discussion of previous solutions that there are "SSL = VPNs", which covers the current reality of how the problem is solved. >=20 >>=20 >> And I would like to see a recommendation that HTTPS and TCPIKE should = not be multiplexed the same time on the same port. My understanding from = Tero=E2=80=99s feedback was that this is usually not done today and = probably not necessary in future. >=20 > Yes, I think it makes sense to add to the text around the = configuration that it is recommended to not run any other service on the = same port as TCP Encapsulated IPsec. >=20 > Thanks, > Tommy >=20 >>=20 >> Mirja >>=20 >>=20 >>> Am 05.05.2017 um 23:13 schrieb Eric Rescorla : >>>=20 >>> It seems like most of the issues are resolved here, except for that = of muxing >>> IKE and non-IKE protocols on the same port (especially 443). My = understanding >>> is that (although we may not like it) it's nevertheless a common = practice, and >>> yet we can't levy the requirement that no other protocol start with = IKETCP, >>> so it seems like what we need is a warning note and potentially a = request to reserve >>> this string for some set of common protocols (HTTP,...?). >>>=20 >>> Mirja, would that work for you? >>>=20 >>> -Ekr >>>=20 >>>=20 >>> On Wed, May 3, 2017 at 6:11 AM, Spencer Dawkins at IETF = wrote: >>>=20 >>>=20 >>> On May 3, 2017 05:54, "Mirja K=C3=BChlewind" = wrote: >>> I didn't propose to obsolete RFC3947 in this document. I guess you = can also file an error for this if you don't want to take any further = actions. However, for updating the IANA registry, I would say the right = action is to do this simply by IESG approval for UDP then. >>>=20 >>> Fwiw, that would work for me. >>>=20 >>> Spencer >>>=20 >>>=20 >>>=20 >>> Mirja >>>=20 >>>=20 >>>=20 >>> On 03.05.2017 11:12, Tero Kivinen wrote: >>> Mirja Kuehlewind (IETF) writes: >>> my thinking was that the main problem is that 3947 was not obsoleted >>> and I=E2=80=99m assuming we need a document to fix that. >>>=20 >>> This is partly issue, but it is not issue we need to solve here, as >>> this document is not something that should obsolete 3947. >>>=20 >>> Also 3947 only defines extension for the IKEv1 (RFC2409) and that is >>> already obsoleted, so effectively RFC3947 is already obsoleted, as >>> there is no way to implement 3947 without implementing obsoleted >>> protocol... >>>=20 >>> This issue is not not important enough to require RFC now. >>>=20 >>> In this case that document could/should also fix the IANA entry for >>> the UDP port. However, I=E2=80=99m actually not sure what the right >>> processing would be to fix this forgotten obsolete=E2=80=A6 maybe = other ADs >>> know better=E2=80=A6? >>>=20 >>> For now I would just leave it as it is, but fix the references in = the >>> IANA registry so that document will not be referenced, especially as >>> the original IANA reference was not to the correct RFC in the first >>> place. >>>=20 >>> Otherwise if you don=E2=80=99t want to do this, I don=E2=80=99t = think it=E2=80=99s a good >>> idea to merge kind of unrelated fixes into this spec. We can also >>> fix that by using the IESG approval process (see RFC5226). I think >>> that=E2=80=99s the better option! >>>=20 >>> That is true, but as this document already modifies the TCP/4500 >>> reference, fixing the UDP/4500 reference at the same time is not >>> completely unrelated fix. >>>=20 >>> Obsoleting RFC3947 would be unrelated fix. >>>=20 >>>=20 >>>=20 >>=20 >=20 --Boundary_(ID_/JGGw0B+ynts9aqbjOaWsQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
Hello,

I've posted a new version of the draft that incorporates the = changes discussed in this thread. Please review!

https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-tcp-en= caps-10

Thanks,
Tommy

On May = 12, 2017, at 3:25 PM, Tommy Pauly <tpauly@apple.com> wrote:



On May 8, = 2017, at 5:49 AM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>= wrote:

Does the proposed text changes from = Tommy still refer to 443 anywhere (lost track a bit but I guess the = appendix still does right)?

Again I think = we should talk about using 443 if that=E2=80=99s what=E2=80=99s done in = reality. However my understanding is that real-life implementation use = TCP/TLS which I think could be discussed in the body rather than the = appendix.

The current state = will not refer to 443 in the body, but specify TCP 4500, with the option = to have both peers mutually agree on another port to use if necessary. = The working group had felt that bringing TLS over 443 directly into the = body would be inappropriate for the standard. We mention in the = discussion of previous solutions that there are "SSL VPNs", which covers = the current reality of how the problem is solved.


And I = would like to see a recommendation that HTTPS and TCPIKE should not be = multiplexed the same time on the same port. My understanding from = Tero=E2=80=99s feedback was that this is usually not done today and = probably not necessary in future.

Yes, I think it makes sense to add to the text around the = configuration that it is recommended to not run any other service on the = same port as TCP Encapsulated IPsec.

Thanks,
Tommy


Mirja


Am 05.05.2017 um 23:13 schrieb Eric Rescorla <ekr@rtfm.com>:

It seems like most of the issues are resolved = here, except for that of muxing
IKE and non-IKE protocols = on the same port (especially 443). My understanding
is = that (although we may not like it) it's nevertheless a common practice, = and
yet we can't levy the requirement that no other = protocol start with IKETCP<whatever>,
so it seems = like what we need is a warning note and potentially a request to = reserve
this string for some set of common protocols = (HTTP,...?).

Mirja, would that work for = you?

-Ekr


On Wed, May 3, 2017 at 6:11 AM, Spencer Dawkins at IETF = <spencerdawkins.ietf@gmail.com> wrote:


On May 3, 2017 05:54, "Mirja K=C3=BChlewind" = <ietf@kuehlewind.net> wrote:
I didn't = propose to obsolete RFC3947 in this document. I guess you can also file = an error for this if you don't want to take any further actions. = However, for updating the IANA registry, I would say the right action is = to do this simply by IESG approval for UDP then.

Fwiw, that would work for me.

Spencer



Mirja



On 03.05.2017 11:12, Tero Kivinen wrote:
Mirja = Kuehlewind (IETF) writes:
my thinking was that the main = problem is that 3947 was not obsoleted
and I=E2=80=99m = assuming we need a document to fix that.

This= is partly issue, but it is not issue we need to solve here, as
this document is not something that should obsolete 3947.

Also 3947 only defines extension for the IKEv1 = (RFC2409) and that is
already obsoleted, so effectively = RFC3947 is already obsoleted, as
there is no way to = implement 3947 without implementing obsoleted
protocol...
This issue is not not important enough to = require RFC now.

In this case that document = could/should also fix the IANA entry for
the UDP port. = However, I=E2=80=99m actually not sure what the right
processing would be to fix this forgotten obsolete=E2=80=A6 = maybe other ADs
know better=E2=80=A6?

For now I would just leave it as it is, but fix the = references in the
IANA registry so that document will not = be referenced, especially as
the original IANA reference = was not to the correct RFC in the first
place.

Otherwise if you don=E2=80=99t want to do = this, I don=E2=80=99t think it=E2=80=99s a good
idea to = merge kind of unrelated fixes into this spec. We can also
fix that by using the IESG approval process (see RFC5226). I = think
that=E2=80=99s the better option!

That is true, but as this document already modifies the = TCP/4500
reference, fixing the UDP/4500 reference at the = same time is not
completely unrelated fix.
Obsoleting RFC3947 would be unrelated fix.






= --Boundary_(ID_/JGGw0B+ynts9aqbjOaWsQ)--