From nobody Fri Mar 1 08:41:13 2019 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 64797130EAE; Fri, 1 Mar 2019 08:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 goi2bFW1hYEK; Fri, 1 Mar 2019 08:41:03 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D24B3130E90; Fri, 1 Mar 2019 08:41:02 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 449wCb2r0vz9qB; Fri, 1 Mar 2019 17:40:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1551458459; bh=POKvRdokEQd4/jucoywKSXn1AtyrMkW+yT80nw7RhUI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Scaa+g11QQGfqAFGcgupyXb96mIJ9U5jipqDirhCVuPGPQ2YeQdIEU20NIKo2YHcd ZtNQjcpAnXCKW7MeYLDnWeriICgKKp46W/5VM7MfobfHW3zX4yF+Uws/XsUGeFG1Q8 UQ1rI/p0SP0juQyadqZv0WDbg8nBsib/7xYRN++I= 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 oFFfmOYA7iRg; Fri, 1 Mar 2019 17:40:57 +0100 (CET) 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; Fri, 1 Mar 2019 17:40:56 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 200AB5C848; Fri, 1 Mar 2019 11:40:56 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 200AB5C848 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1434340D358A; Fri, 1 Mar 2019 11:40:56 -0500 (EST) Date: Fri, 1 Mar 2019 11:40:56 -0500 (EST) From: Paul Wouters To: Linda Dunbar cc: Rafa Marin-Lopez , "i2nsf@ietf.org" , =?ISO-8859-15?Q?Fernando_Pere=F1=EDguez_Garc=EDa?= , Gabriel Lopez , Yoav Nir , "ipsec@ietf.org WG" In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66B2C7CC3@sjceml521-mbs.china.huawei.com> Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F66B2C71AA@sjceml521-mbs.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F66B2C7CC3@sjceml521-mbs.china.huawei.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] [I2nsf] Let's try to draw closure for sdn-ipsec-flow-protection ( RE: Reviewing sdn-ipsec-flow-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 16:41:06 -0000 > During IETF103, authors of draft-carrel-ipsecme-controller-ike stated that 3rd case (Controller-IKE) should be added > to the document. > > We thought it was still an open debate. In fact, I mentioned in the last meeting that between case 1 and case 3, I would prefer > case 1 (IKE case) since as I said ( minute 1:05:03) I do not see any advantage provided by Controller-IKE. Any feature included > in Controller-IKE is already in case 1. Therefore, the question about what are the advantages of Controller-IKE vs case 1 has not > been answered yet, in my humble opinion. I'm concerned about draft-carrel-ipsecme-controller-ike. I think it would be good that before anything is decided here, is that the authors of that draft present their idea at the IPsecME WG first. It's a bit scary that large parts of IKEv2 (eg authentication) is left out, and KEYMAT generation is modified from the original IKE version, and that SPI number generation is used as a shorthand for confirming policy negotiation. Paul From nobody Fri Mar 1 13:15:09 2019 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 61427130F03; Fri, 1 Mar 2019 13:10:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ipsec@ietf.org, ekr@rtfm.com X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155147460839.6101.12805476128758372538.idtracker@ietfa.amsl.com> Date: Fri, 01 Mar 2019 13:10:08 -0800 Archived-At: Subject: [IPsec] ipsecme - Requested session has been scheduled for IETF 104 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 21:10:21 -0000 Dear Tero Kivinen, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ipsecme Session 1 (1:30 requested) Thursday, 28 March 2019, Morning Session II 1050-1220 Room Name: Karlin 1/2 size: 150 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/104/sessions/ipsecme.ics Request Information: --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: sacm mile tcpinc curdle tls saag cfrg i2nsf Second Priority: 6tisch lwig ace Third Priority: uta 6lo tcpm netmod People who must be present: Eric Rescorla Tero Kivinen David Waltermire Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Mar 3 20:20:11 2019 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 CB2EE129A85; Sun, 3 Mar 2019 20:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJ79xx5b-svI; Sun, 3 Mar 2019 20:20:06 -0800 (PST) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 7CA7B129284; Sun, 3 Mar 2019 20:20:06 -0800 (PST) Received: by mail-ua1-x92e.google.com with SMTP id f88so3223830uaf.2; Sun, 03 Mar 2019 20:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=vnEZcniDw5UdBRRt+Lh7pAwzNZ78koxz+Ziud//m92w=; b=LSiGfjcuf93Pt//IJvj9GOZYf+Fsc4GDrsDcfFWjZgauwG9d3p09sLUysRjUTg7jmv Thm9kfS4v44MOujsNXaZGBqWClyIMJ7QzaLf7Y6huvsMK7nnDzY+tiY4uWR9nv3QyH8K 6d+u3yZr1WC0qAAXVRmp5j4Mt7Bpuac1Z9zqQOWG9yp4MmmVCh4YKatn5j9oLk+Cy+YX rQWfup/JpnnahNclS8wXZPyQDonvRXZyqlWNhzaHFILDMYMYarFLpADlKXh5FlVZjzBo aGLOv8Ciyd2WZzpV9Q9teBN0NWfWMA4MOfhndEBqO+EN3r7LfelwbG6kIJSDtv0j9bkM Ec1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vnEZcniDw5UdBRRt+Lh7pAwzNZ78koxz+Ziud//m92w=; b=MQBnVIZbIA2fYCRr/7PTrRTwFOskx9rS9/11nn9MQVORg3BRmrhTGsGZpEeRIwqKCp ZK3yndb0GTsFrazmXdbBNrQ2AHq7UsBYrmAPnD7NCTJ1+P6/3Rkl9z7ADaiBb4uNi9M3 n0GltxIBj6AquN7rJhDnS9I80f5a4WAHPa377x0yKVWYmirN3DZuGBmUrUNXvss6g9nw CLAAdeJInhCcLPVlnaD4bLCKfQTUkAjAxIAHiWrv2cgdGb28Jtsc91YPDvya34pWTlkc RsxkO9MPiT5ZaRl+Fcs0GQS9NAX8Xz9N38PgGnAg52D3ya2VhJCh4tFo1p4ZvsEMPjiu q8YA== X-Gm-Message-State: APjAAAUI1l0aZ6p2GZZO3JlWJikTyHWgzKVPYzVe9Bo236BmV7sHSA3S bUN54KL+ZiIZmRIKyru3XgjZl3fVweypUUprMJr/u2IE X-Google-Smtp-Source: APXvYqzWdaPt4eVR6x1A/4nz1vgYzhgkvzrlalduGePlyIwkInbVCp1LrIkFdkoywYTT8eNRXdMThLmBancz1eG3/ro= X-Received: by 2002:ab0:69da:: with SMTP id u26mr8425783uaq.1.1551673204949; Sun, 03 Mar 2019 20:20:04 -0800 (PST) MIME-Version: 1.0 From: Bharath Meduri Date: Mon, 4 Mar 2019 09:49:49 +0530 Message-ID: To: ipsec@ietf.org, ipsec-request@ietf.org Content-Type: multipart/alternative; boundary="00000000000030463305833d129e" Archived-At: Subject: [IPsec] Reply to the comments by Paul: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 04:20:10 -0000 --00000000000030463305833d129e Content-Type: text/plain; charset="UTF-8" Thanks Paul, We wil change and post again by fixing all your comments. Please find our opinion on your comments below. 1) Omitting the TS payload in ESP transport mode for rekeying seems okay as well,but does seem to be a bit of a corner case to optimize for. But I can't come up with a strong reason not to do it. There is an issue when there are multiple IPsec SA's - you need the TS to see which one is being rekeyed. So when omitted, you need to send the old SPI? -------> The SA can be identified by old SPI , the exchange shown might be taken from Normal Child SA Creation we can update with new diagram for IPSEC SA Rekey by Child Exchange Initiator Responder ------------------------------------------------------------------- HDR, SK {N(REKEY_SA), N(NEW_SPI), Ni} --> <-- HDR, SK {N(NEW_SPI), Nr} The REKEY_SA notification MUST be included in a CREATE_CHILD_SA exchange if the purpose of the exchange is to replace an existing ESP or AH SA. The SA being rekeyed is identified by the SPI field in the Notify payload; this is the SPI the exchange initiator would expect in inbound ESP or AH packets. There is no data associated with this Notify message type. The Protocol ID field of the REKEY_SA notification is set to match the protocol of the SA we are rekeying, for example, 3 for ESP and 2 for AH. 2)Instead of sending IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED in IKE_INIT, it should be send in IKE_AUTH because we can fragment in IKE_AUTH and not in IKE_INIT. It also reduces what a passive attacker can see and fingerprint users/implementations on. -------> this sugg is OK This can be avoided in INIT and Once Auth is getting Success it will be more appropriate as we are supporting for the authenticated peer. 3)I'd also prefer a shorter name than IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED, perhaps call it MINIMAL_REKEY_SUPPORTED ? (we don't prefix with IKEV2 in https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-16 -------> Ok , Just referred IKEV2_MESSAGE_ID_SYNC something like this But can always make Short names . we will change 4)Section 3.1 should clarify the payload length is 0? It should clarify the setting of the Critical flag (off) Some clarification should be needed on whether sending the notify means the rekeys MAY or MUST use this new feature. The NEW_SPI should probably have the critical flag set? ---> This point we can discuss , Critical bit is not required as per my understanding as Initially only we negotiated for this Optional Support. What is the chance that in middle of the operation peer stop supporting it. The example talks about there being a KEi payload, but if there is no PFS for an IPsec SA rekey, there is no KEi payload. (oh, this only covers ike rekey, so then this is right. maybe clarify :) ---> Ok our intention there is for IKE rekey we can make more specific the text states "initiator will send initiator IKE SPI" but that is only true for IKE rekey, not IPsec rekey where it needs to send the IPsec SPI. ---> yes we can make specific If there is more than one IPsec SA, then omiting the TS would lead to the responder no longer knowing which IPsec SA is being rekeyed. So perhaps sending the old SPI would be needed. Or if we decide this is too much of a corner case, perhaps we should not allow omittig the TS? --> we go with old SPI inclusion , and it is normal convention to find old SA for Rekey I think 3.2.1 should named better, eg "IKE SA rekey without SA" and 3.2.3. should be baned "Child SA rekey without SA and TS". 3.2.2 is a bit odd. ---> Ok I think a more clear split between ike/child rekey is needed. Currently 3.2.1 is about IKE, 3.2.2. about both? --> ok separate heading and separate procedures Section 4 needs work :) But in a way it is more secure agains accidental downgrade of cryptographic strength. But also it prevents upgrade of cryptographic strength. -------> ok , preventing downgrade is a kind of good option :) from security prespective. Prevents Upgrade for better algorithams this part how to support we will see but usually our thought is that smaller devices or iot devices should have a initial config with best cryptographic strength and cannot change so frequently. Thanks&Rgs Bharath M On Fri, Feb 22, 2019 at 1:32 AM wrote: > Send IPsec mailing list submissions to > ipsec@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/ipsec > or, via email, send a message with subject or body 'help' to > ipsec-request@ietf.org > > You can reach the person managing the list at > ipsec-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of IPsec digest..." > > > Today's Topics: > > 1. Re: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00.txt > (Paul Wouters) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 20 Feb 2019 15:40:11 -0500 (EST) > From: Paul Wouters > To: Sandeep Kampati > Cc: "ipsec@ietf.org" > Subject: Re: [IPsec] > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00.txt > Message-ID: > Content-Type: text/plain; charset=ISO-8859-15; format=flowed > > On Wed, 20 Feb 2019, Sandeep Kampati wrote: > > > Htmlized:?? > https://tools.ietf.org/html/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00 > ?? > > I read the draft and I think it has some good ideas, and a few things I > don't like as much :) > > The idea of not including the SA when rekeying for the identical > IPsec or IKE SA looks good to me. > > Omitting the TS payload in ESP transport mode for rekeying seems okay as > well, > but does seem to be a bit of a corner case to optimize for. But I can't > come up with a strong reason not to do it. There is an issue when there > are multiple IPsec SA's - you need the TS to see which one is being > rekeyed. So when omitted, you need to send the old SPI? > > Instead of sending IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED in IKE_INIT, > it should be send in IKE_AUTH because we can fragment in IKE_AUTH and > not in IKE_INIT. It also reduces what a passive attacker can see and > fingerprint users/implementations on. > > I'd also prefer a shorter name than IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED, > perhaps call it MINIMAL_REKEY_SUPPORTED ? (we don't prefix with IKEV2 in > > https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-16 > > Section 3.1 should clarify the payload length is 0? > > It should clarify the setting of the Critical flag (off) > > Some clarification should be needed on whether sending the notify means > the rekeys MAY or MUST use this new feature. > > > The NEW_SPI should probably have the critical flag set? > > The example talks about there being a KEi payload, but if there is no > PFS for an IPsec SA rekey, there is no KEi payload. (oh, this only > covers ike rekey, so then this is right. maybe clarify :) > > > the text states "initiator will send initiator IKE SPI" but that is only > true for IKE rekey, not IPsec rekey where it needs to send the IPsec > SPI. > > > If there is more than one IPsec SA, then omiting the TS would lead to > the responder no longer knowing which IPsec SA is being rekeyed. So > perhaps sending the old SPI would be needed. Or if we decide this is > too much of a corner case, perhaps we should not allow omittig the TS? > > > I think 3.2.1 should named better, eg "IKE SA rekey without SA" and > 3.2.3. should be baned "Child SA rekey without SA and TS". 3.2.2 is > a bit odd. > > (i misread 3.2.1 making assumptions about child sa) > > I think a more clear split between ike/child rekey is needed. Currently > 3.2.1 is about IKE, 3.2.2. about both? > > > 3.3 again ensure to tell critical flag must be set. > > I think an OLD_SPI() payload is needed here too. > > > Section 4 needs work :) But in a way it is more secure agains accidental > downgrade of cryptographic strength. But also it prevents upgrade of > cryptographic strength. > > > Paul > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > ------------------------------ > > End of IPsec Digest, Vol 178, Issue 7 > ************************************* > -- with regards Bharath.Meduri --00000000000030463305833d129e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Paul,=C2=A0

We wil change and post again b= y fixing all your comments.=C2=A0
Please find our opi= nion on your comments below.=C2=A0

1) Omitting the TS payload in ESP transport mode for rekeying seems okay as= well,but does seem to be a bit of a corner case to optimize for. But I can= 't
come up with a strong reason not to do it. There is an issue when there are= multiple IPsec SA's - you need the TS to see which one is being
rekeyed. So when omitted, you need to send the old SPI?

-------> The SA can be identified by old SPI , the exchan= ge shown might be taken from Normal Child SA Creation=C2=A0
we can update with new diagram for IPSEC SA Rekey by Child Exchange

Initiator=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Responder
=C2=A0=C2=A0 --------------------------------------------------------------= -----
=C2=A0=C2=A0 HDR, SK {N(REKEY_SA), N(NEW_SPI), Ni}=C2=A0=C2=A0 -->

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <--=C2=A0 HDR, SK {N(NEW_SPI), Nr}
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0 The REKEY_SA notification MUST be included in a CREATE_CHILD_S= A
=C2=A0=C2=A0 exchange if the purpose of the exchange is to replace an exist= ing ESP
=C2=A0=C2=A0 or AH SA.=C2=A0 The SA being rekeyed is identified by the SPI = field in the
=C2=A0=C2=A0 Notify payload; this is the SPI the exchange initiator would e= xpect
=C2=A0=C2=A0 in inbound ESP or AH packets.=C2=A0 There is no data associate= d with this
=C2=A0=C2=A0 Notify message type.=C2=A0 The Protocol ID field of the REKEY_= SA
=C2=A0=C2=A0 notification is set to match the protocol of the SA we are rek= eying,
=C2=A0=C2=A0 for example, 3 for ESP and 2 for AH.

2)Instead of sending IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED = in IKE_INIT, it should be send in IKE_AUTH because we can fragment in IKE_A= UTH and
not in IKE_INIT. It also reduces what a passive attacker can see and finger= print users/implementations on.

-------> this sugg is OK
This can be avoided in INIT and Once Auth is getting Success it will be mor= e appropriate as we are supporting for the authenticated peer.

3)I'd also prefer a shorter name than IKEV2_REKEY_OPTION= AL_PAYLOAD_SUPPORTED, perhaps call it MINIMAL_REKEY_SUPPORTED ? (we don'= ;t prefix with IKEV2 in
https://www.iana.org/assignments/ikev2-parame= ters/ikev2-parameters.xhtml#ikev2-parameters-16

-------> Ok , Just referred IKEV2_MESSAGE_ID_SYNC somethi= ng like this But can always make Short names . we will change

4)Section 3.1

should clarify the payload length is 0?

It should clarify the setting of the Critical flag (off)

Some clarification should be needed on whether sending the n= otify means the rekeys MAY or MUST use this new feature.

The NEW_SPI should probably have the critical flag set?

---> This point we can discuss , Critical bit is not requ= ired as per my understanding as Initially only we negotiated for this Optio= nal Support.
What is the chance that in middle of the operation peer stop supporting it.= =C2=A0

The example talks about there being a KEi payload, but if th= ere is no
PFS for an IPsec SA rekey, there is no KEi payload. (oh, this only
covers ike rekey, so then this is right. maybe clarify :)=C2=A0

---> Ok our intention there is for IKE rekey we can make = more specific

the text states "initiator will send initiator IKE SPI&= quot; but that is only
true for IKE rekey, not IPsec rekey where it needs to send the IPsec
SPI.

---> yes we can make specific

If there is more than one IPsec SA, then omiting the TS woul= d lead to
the responder no longer knowing which IPsec SA is being rekeyed. So
perhaps sending the old SPI would be needed. Or if we decide this is
too much of a corner case, perhaps we should not allow omittig the TS?

--> we go with old SPI inclusion , and it is normal conve= ntion=C2=A0 to find old SA for Rekey

I think 3.2.1 should named better, eg "IKE SA rekey wit= hout SA" and
3.2.3. should be baned "Child SA rekey without SA and TS". 3.2.2 = is
a bit odd.

---> Ok

I think a more clear split between ike/child rekey is needed= . Currently
3.2.1 is about IKE, 3.2.2. about both?

--> ok separate heading and separate procedures

Section 4 needs work :) But in a way it is more secure again= s accidental
downgrade of cryptographic strength. But also it prevents upgrade of
cryptographic strength.

-------> ok , preventing downgrade is a kind of good opti= on :) from security prespective.
Prevents Upgrade for better algorithams this part how to support=C2=A0=C2= =A0 we will see but usually our thought is that smaller devices or iot devi= ces
should have a initial config with best cryptographic strength and cannot ch= ange so frequently.


Thanks&Rgs= =C2=A0

Bharath M



=
On Fri, Fe= b 22, 2019 at 1:32 AM <ipsec-request@ietf.org> wrote:
Send IPsec mailing lis= t submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ipsec@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.o= rg/mailman/listinfo/ipsec
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ipsec-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ipsec-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of IPsec digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00.txt =C2=A0 =C2=A0 =C2=A0 (Paul Wouters)


----------------------------------------------------------------------

Message: 1
Date: Wed, 20 Feb 2019 15:40:11 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: Sandeep Kampati <sandeepkampati@huawei.com>
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: Re: [IPsec]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-= 00.txt
Message-ID: <alpine.LRH.2.21.19022015052= 70.12605@bofh.nohats.ca>
Content-Type: text/plain; charset=3DISO-8859-15; format=3Dflowed

On Wed, 20 Feb 2019, Sandeep Kampati wrote:

> Htmlized:?? https://tools.ietf.org/html/draft-kampati-ipsecme-ikev2-sa-ts-payloads= -opt-00??

I read the draft and I think it has some good ideas, and a few things I
don't like as much :)

The idea of not including the SA when rekeying for the identical
IPsec or IKE SA looks good to me.

Omitting the TS payload in ESP transport mode for rekeying seems okay as we= ll,
but does seem to be a bit of a corner case to optimize for. But I can't=
come up with a strong reason not to do it. There is an issue when there
are multiple IPsec SA's - you need the TS to see which one is being
rekeyed. So when omitted, you need to send the old SPI?

Instead of sending IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPORTED in IKE_INIT,
it should be send in IKE_AUTH because we can fragment in IKE_AUTH and
not in IKE_INIT. It also reduces what a passive attacker can see and
fingerprint users/implementations on.

I'd also prefer a shorter name than IKEV2_REKEY_OPTIONAL_PAYLOAD_SUPPOR= TED,
perhaps call it MINIMAL_REKEY_SUPPORTED ? (we don't prefix with IKEV2 i= n
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml= #ikev2-parameters-16

Section 3.1 should clarify the payload length is 0?

It should clarify the setting of the Critical flag (off)

Some clarification should be needed on whether sending the notify means
the rekeys MAY or MUST use this new feature.


The NEW_SPI should probably have the critical flag set?

The example talks about there being a KEi payload, but if there is no
PFS for an IPsec SA rekey, there is no KEi payload. (oh, this only
covers ike rekey, so then this is right. maybe clarify :)


the text states "initiator will send initiator IKE SPI" but that = is only
true for IKE rekey, not IPsec rekey where it needs to send the IPsec
SPI.


If there is more than one IPsec SA, then omiting the TS would lead to
the responder no longer knowing which IPsec SA is being rekeyed. So
perhaps sending the old SPI would be needed. Or if we decide this is
too much of a corner case, perhaps we should not allow omittig the TS?


I think 3.2.1 should named better, eg "IKE SA rekey without SA" a= nd
3.2.3. should be baned "Child SA rekey without SA and TS". 3.2.2 = is
a bit odd.

(i misread 3.2.1 making assumptions about child sa)

I think a more clear split between ike/child rekey is needed. Currently
3.2.1 is about IKE, 3.2.2. about both?


3.3 again ensure to tell critical flag must be set.

I think an OLD_SPI() payload is needed here too.


Section 4 needs work :) But in a way it is more secure agains accidental downgrade of cryptographic strength. But also it prevents upgrade of
cryptographic strength.


Paul



------------------------------

Subject: Digest Footer

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


------------------------------

End of IPsec Digest, Vol 178, Issue 7
*************************************


--





with regards
Bharath.Meduri


--00000000000030463305833d129e-- From nobody Wed Mar 6 06:22:28 2019 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 5CB52126DFA for ; Wed, 6 Mar 2019 06:22:26 -0800 (PST) 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=[RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 IFxb2mWWJy6T for ; Wed, 6 Mar 2019 06:22:24 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B78126C87 for ; Wed, 6 Mar 2019 06:22:23 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 44DwvL2t9QzCrS9; Wed, 6 Mar 2019 15:22:22 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 44DwvL26G3z8sYY; Wed, 6 Mar 2019 15:22:22 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM41.corporate.adroot.infra.ftgroup ([fe80::857d:4f67:b0a7:10d7%21]) with mapi id 14.03.0435.000; Wed, 6 Mar 2019 15:22:22 +0100 From: To: Tero Kivinen CC: IPsecME WG Thread-Topic: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-02.txt Thread-Index: AQHUt93vkjK8YIf+HEWKhvCwg/8K86XGTTbQgAA1goCAAPj2EIAAvHAAgACvqQCANfdQ4A== Date: Wed, 6 Mar 2019 14:22:21 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA2992D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <154168245580.31150.9462703520955536832@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302E04234B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <23632.24934.655381.307535@fireball.acr.fi> <787AE7BB302AE849A7480A190F8B93302EA0ED4F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <23632.40263.252953.62010@fireball.acr.fi> <787AE7BB302AE849A7480A190F8B93302EA0F6C9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <23634.3122.644454.54601@fireball.acr.fi> <787AE7BB302AE849A7480A190F8B93302EA0FE43@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA0FE43@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 14:22:26 -0000 Hi Tero, all,=20 Any chance to conclude this issue? In particular, is there a benefit in fol= lowing your proposal compared to the current approach in the draft? Thank you. Cheers, Med > -----Message d'origine----- > De=A0: IPsec [mailto:ipsec-bounces@ietf.org] De la part de > mohamed.boucadair@orange.com > Envoy=E9=A0: jeudi 31 janvier 2019 08:17 > =C0=A0: Tero Kivinen > Cc=A0: IPsecME WG > Objet=A0: Re: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-= 02.txt >=20 > Hi Tero, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Tero Kivinen [mailto:kivinen@iki.fi] > > Envoy=E9=A0: mercredi 30 janvier 2019 21:42 > > =C0=A0: BOUCADAIR Mohamed TGI/OLN > > Cc=A0: IPsecME WG > > Objet=A0: RE: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-code= s- > 02.txt > > > > mohamed.boucadair@orange.com writes: > > > > > [Med] This is more complicated compared to the current design in = the > > > > > draft which allows to return a status code. The initiator will th= en > > > > > know whether it has to retry with another address family. > > > > > > > > I do no see any difference here. > > > > > > [Med] The difference is that the status codes in the draft reflect > > > the capabilities of the responder independently of the address > > > assignment. > > > > That would be fine, if the responder could return this information > > before the initiator would do configuration request, so initiator > > could adjusts its request accordingly, but that would require moving > > those status notifications to IKE_SA_INIT, and for various reasons we > > try to keep that as small as possible, so I do not think that is > > correct place for those notifications. >=20 > [Med] That wasn't my point. My comment is that the codes are static even = if > they are made during address configuration. That is: > (1) An IPv4-only responder will always include IP4_ONLY_ALLOWED independe= ntly > of the request (IPv4, IPv6, IPv4 and IPv6). > (2) An IPv6-only responder will always include IP6_ONLY_ALLOWED independe= ntly > of the request. > (3) A dual-stack responder configured with an IPv4 preference will always > include IP4_ONLY_ALLOWED in a response to a dual-stack request. > (4) A dual-stack responder configured with an IPv6 preference will always > include IP6_ONLY_ALLOWED in a response to a dual-stack request. >=20 > The behavior of the initiator is more deterministic, e.g., when case (1) = is > encountered: > - An IPv6 initiator will stop trying asking for IPv6 addresses. > - A dual-stack initiator who asked for both won't try with a separate > request for IPv6 > - A dual-stack initiator who asked first for IPv4 won't sent a reques= t > for IPv6 > - A dual-stack initiator who asked first for IPv6 will send a request= for > IPv4 >=20 > Now consider that ADDITIONAL_ADDRESS_FAMILY_POSSIBLE is to be defined, th= is > code will returned with the following conditions: >=20 > (a) An IPv4-only responder will include ADDITIONAL_ADDRESS_FAMILY_POSSIBL= E > only if the initiator asked for IPv6. > (b) An IPv6-only responder will include ADDITIONAL_ADDRESS_FAMILY_POSSIBL= E > only if the initiator asked for IPv4. > (c) A dual-stack responder will include ADDITIONAL_ADDRESS_FAMILY_POSSIBL= E if > the initiator asked for both, but for policy matters only one AF can be > assigned per request. >=20 > The behavior of the initiator is less deterministic, e.g., case (c): A du= al- > stack initiator who asked for both but got only IPv6 or IPv4 does not kno= w > why the other address is not assigned. It will then send a request to try= to > get an address. >=20 > Protocols with rich error codes makes it easier to adjust the behavior, t= o > diagnostic, etc. >=20 > > > > > > > > 2) Initiator is dual stack and requests both address families. = If > > > > > > responder support both in same IKE SA, it will return address f= or > > > > > > both. > > > > > > > > > > [Med] Yes, but we need also to cover this case: > > > > > > > > > > o An initiator asks for both IPv4 and IPv6 addresses, but onl= y > one > > > > > address family can be assigned by the responder for policy > > > > > reasons. > > > > > > > > > > The initiator needs to know why only one address is assigned so t= hat > > > > > it does not retry; hence the two separate codes. > > > > > > > > Initiator will know that it can get the address from the family tha= t > > > > the responder returned. If there is no > > > > ADDITIONAL_ADDRESS_FAMILY_POSSIBLE status notification, that means = no > > > > other family is possible, thus there is no point of trying to retry= . > > > > > > [Med] Isn't odd to return ADDITIONAL_ADDRESS_FAMILY_POSSIBLE for a > > > request which already asked for both AFs? > > > > Nope. We do that with other cases too. I.e., initiator did request for > > both address families, but responder said he want to do those as > > separate IKE SAs, and returned addresses for only one address family. >=20 > [Med] OK, I see, this is doing the same job as what we used to have in -0= 1: >=20 > o SINGLE_AF_SUPPORTED: This status type indicates that only a single > address family can be assigned per request, not both. This status > type is returned when an initiator requested both IPv4 and IPv6 > addresses/prefixes in the same request, but only a single address > family can be assigned per request by the responder. >=20 > The address family preference is defined by a policy that is local > to the responder. >=20 > If a responder receives a request for both IPv4 and IPv6 address > families, it replies with the preferred address family and > includes SINGLE_AF_SUPPORTED notification status type. Upon > receipt of this status type, the initiator MAY re-issue another > configuration request to ask for an additional address family. >=20 > I have removed that code because the message I got from the working group= is > to reduce the number of codes. >=20 > > The status notification indicates that initiator might create another > > IKE SA and request another address family in there. > > > > If it is not there, it will just have to cope with the address family > > it got in the response. > > > > This is same as what we do with ADDITIONAL_TS_POSSIBLE. > > > > > > > > Also I do not think making it MUST to include those notificatio= ns > is > > > > > > something we want to do here. > > > > > > > > > > [Med] From an interoperability standpoint, MUST is justified here= . > No? > > > > > > > > No, as current implementations do not do that, thus this would make > > > > all existing implementations not conforming to this, and would most > > > > likely also require version number upgrade from the 2.0 to somethin= g > > > > larger, so other end would know whether other end supports this > > > > new MUST or not. > > > > > > > > Anyways we always leave that kind of decisions to the policy, i.e., > > > > even if the implementation is dual-stack, it might not want to requ= est > > > > both addresses, if it only needs one. > > > > > > > > Also you cannot really have MUST do xxx, except yyy. That would be > > > > SHOULD, but in this case I think MAY is better. > > > > > > [Med] If we want more deterministic behaviors of initiators and more > > > interoperability, MAY is too weak. SHOULD would be OK. > > > > I would expect this is something that will be dictated by policy > > anyways, and unless policy says otherwise implementation that will > > support both address families always asks for both (I mean why not). > > So I do not think there is any real difference in MAY or SHOULD. > > Neither one of them can give any suggestion to the adminstrator making > > the policy, he will decided what to configure regardless what we do > > here in our documents. > > > > I still think MAY would be correct, but I do not complain if people in > > the WG think SHOULD is better. > > -- > > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Mar 11 07:32:52 2019 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 7F95A131074; Mon, 11 Mar 2019 07:32:51 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 4NWShyeMb7kU; Mon, 11 Mar 2019 07:32:49 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id A7B2D131055; Mon, 11 Mar 2019 07:32:49 -0700 (PDT) Received: from tops.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPS id 2B49E604D0; Mon, 11 Mar 2019 10:32:49 -0400 (EDT) References: <155231377348.23058.4682503726354987752@ietfa.amsl.com> User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: ipsec@ietf.org Cc: chopps@chopps.org, ipsecme-chairs@ietf.org Date: Mon, 11 Mar 2019 10:32:48 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 14:32:51 -0000 --=-=-= Content-Type: text/plain; format=flowed Hi ipsecme folks, Here's some new work on improving IP traffic flow security. I've requested a presentation slot from the chairs for the upcoming ipsecme WG meeting @ IETF 104, and will hopefully be able to present this work at that time as well. Thanks, Chris. internet-drafts@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IP Traffic Flow Security > Author : Christian Hopps > Filename : draft-hopps-ipsecme-iptfs-00.txt > Pages : 22 > Date : 2019-03-11 > > Abstract: > This document describes a mechanism to enhance IPsec traffic flow > security by adding traffic flow confidentiality to encrypted IP > encapsulated traffic. Traffic flow confidentiality is provided by > obscuring the size and frequency of IP traffic using a fixed-sized, > constant-send-rate IPsec tunnel. The solution allows for congestion > control as well. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-hopps-ipsecme-iptfs/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-hopps-ipsecme-iptfs-00 > https://datatracker.ietf.org/doc/html/draft-hopps-ipsecme-iptfs-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIyBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlyGcZAACgkQLh2DDte4 MCU6OA/4oJ6dYm3TDEZnVlGwnlzo6XzHPXnrLyEIriW5mAYmXMgXNm5sqVaI+kfp kMsQri7yfiF6AcGEA1y6Z6VlYvw96jqbi8vaZFHUtuAoX7mulF8npvlvXvOetabv BWYDRcbLngcWU6SqW0ie8SNz9keLztHUDzFCacfuOqO0t97Wuh26JRt/rQQ5Wwfx KgOOjhmpxvmLMKU4NidxItjy0Mf6b+AaQKOwiRRCx6L+lxe9CCZwXv3qwEcy46+A PXu40bW+dKmxQ9fFq+Og0SCv0yH08cnLusy41k2gMKjKWZhzPP5s/i8Il099uWDG nfpa8bM7GG6Kqp2aZpFTROZECJXBwTsvvzIDnd559TNeNMssPDR0yRgixqX54L1J b9OPlE3vTcCgm8bgBmHlcUVDS4+PlK/+PVlrDtLSRFebityH4ta02imrt8rbPZcl bRO2aaSUir7S/WaV7qjOmLy2DYq/1BbYncSAKzNKxNwqmlZFsk3Fc4OtjSr6wwUC bg1dptY/Y1X1OKkeNRIhWmgCiLCMKrKEUEl/wllwd6ZZoPK2PTHsOdx6Uc7QxA8L 8Q2NsyvFT9ot0V63Tcf+a7fNUi/ZRXBRM5kQMpXjBNi+mRzQHyTBQN7jsz80xWAM qTvWSsjOSBYPRNK87UWcTdcPFwgaM6kquyTkhp5WLOHixlrzaA== =AAkG -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 11 07:51:32 2019 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 A1C881310BE for ; Mon, 11 Mar 2019 07:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 GoI41YggXeyf for ; Mon, 11 Mar 2019 07:51:28 -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 381621310AB for ; Mon, 11 Mar 2019 07:51:28 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44J1JY207wzK6h; Mon, 11 Mar 2019 15:51:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1552315885; bh=iJY7Q5qHaAg2QPNQh5T45CWXGRIobtYo78A9DNX2pDQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=hfy8IDBCynsaEZVzzf2Sv1yuowaHq2EroPWUEks517gsiDs5HS8xw716O80+BUMpO gHXd1mJAslISdauYr1oOg++b0UZWrAvI1J+4rFNzcaQ0sNo1xJVONRyaoT4RfltTsa 3uBSKsVA8bkmRxkd0uxFq4yPZXzp6kPxeTf0ORvQ= 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 2yj7S73X7R86; Mon, 11 Mar 2019 15:51:24 +0100 (CET) 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; Mon, 11 Mar 2019 15:51:23 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 73C6B36FBA; Mon, 11 Mar 2019 10:51:22 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 73C6B36FBA Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 68A7840C9627; Mon, 11 Mar 2019 10:51:22 -0400 (EDT) Date: Mon, 11 Mar 2019 10:51:22 -0400 (EDT) From: Paul Wouters To: Christian Hopps cc: "ipsec@ietf.org WG" In-Reply-To: Message-ID: References: <155231377348.23058.4682503726354987752@ietfa.amsl.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 14:51:31 -0000 On Mon, 11 Mar 2019, Christian Hopps wrote: > Here's some new work on improving IP traffic flow security. I've requested a > presentation slot from the chairs for the upcoming ipsecme WG meeting @ IETF > 104, and will hopefully be able to present this work at that time as well. Thanks. I did a quick read and I'm still digesting this, but one thing seems a concern: We utilize a send only (i.e., no response expected) IKEv2 INFORMATIONAL exchange (37) to transmit the congestion information using a notification payload of type TFS_CONGEST_INFO (TBD). The The Response bit should be set to 0. As no response is expected the only payload should be the congestion information in the notification payload. This very much violates the state machine model of IKEv2, and I would not be in favour of this without strong arguments of why requiring a response (even if empty) is harmful. Paul From nobody Mon Mar 11 08:43:57 2019 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 08BAE124B0C for ; Mon, 11 Mar 2019 08:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 WmmkwAyJ5NMW for ; Mon, 11 Mar 2019 08:43:53 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 8BFA1127962 for ; Mon, 11 Mar 2019 08:43:53 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id i16so5625135wrs.13 for ; Mon, 11 Mar 2019 08:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=QOfNddUR6XrGy2tA7adpn94Fn1BGV2bTQb8mBk1FeRw=; b=lsTrulLhgx+QSOvnCsEKHdjaNtwRFrbcoBo3VivbVVGnykT+8ZMb8c15DJ86OT0qDf Y+zh1M2nQxQ2Va1ASblUc9B+KzdJl25VZkCJF2Qd7biLkEg5F+LI21PRguwYQoRrKtDC 08VWWtsx3glJl31PLPlaMwzwS2B49y/az/YYy884vEz/7H2LggZKzarMjfsBVWa8822F v0GUT0SqU9pYa/S5LAUYZwV9dnj029D/qtraEoDjdfFYLHdArIHl9LntakxeOwRq1W2V Is4/PPtDnInjfPdrTZiwO1k6mTuzAiEj+e507dyBn0G4eNlu18pNxblZcHh5QZs/LDug r9Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=QOfNddUR6XrGy2tA7adpn94Fn1BGV2bTQb8mBk1FeRw=; b=cEPELe6tXfwC8x6RAiY9q+0OeMUnHlORobN/4urqmXKk2SyMjc7s1mVPtP4VpAlglH 6c2s/k4RyxBYgODanSauOIQNnyhp/J1MjhWWFoo9KFHH6+wCk6xZnJWHPr04JoUkpd8f KOt6vC1n74kNT6G2u8miXhpimhWLmkWEmuL2cu2zw2bNvNh/f87030pZI64wJu3HvRlV LRLxMgCU50bC+5w83qcwaKYg4t2iE7yfqyThbdo8UfHW2240W7cGeuNBTKG6fKzYLkui x8vbrKIsuMlYeldTu+6Q5eFQCKYZp7XxzC2OWYo6Fti4FTwf6ifbsKueqgX425696zOx 4ndg== X-Gm-Message-State: APjAAAUY89XvAzQayQSDV0I4w7dwBdYEExPYKiCFVyJQt75hgDkO5lSm z30Xr7YJ+mjT6CFjMQbDCqDG6djZ9pg= X-Google-Smtp-Source: APXvYqzXAqsiia4auqdbeeY6A7QhtdkyP1j6Pg5zo5F0p6zkDF4B0/G/1mTcIhobYQz55h3fFE8gDQ== X-Received: by 2002:adf:ed48:: with SMTP id u8mr13225034wro.185.1552319032093; Mon, 11 Mar 2019 08:43:52 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id x6sm23280692wmg.0.2019.03.11.08.43.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 11 Mar 2019 08:43:51 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" , "'Christian Hopps'" Cc: References: <155231377348.23058.4682503726354987752@ietfa.amsl.com> In-Reply-To: Date: Mon, 11 Mar 2019 18:43:49 +0300 Message-ID: <00f601d4d821$393286c0$ab979440$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHDC2i80LRgGX+akLu0yxdYVb2DCQJ2/jYBALrj5fimEJs5EA== Content-Language: ru Archived-At: Subject: Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 15:43:56 -0000 Hi, > We utilize a send only (i.e., no response expected) IKEv2 > INFORMATIONAL exchange (37) to transmit the congestion information > using a notification payload of type TFS_CONGEST_INFO (TBD). The The > Response bit should be set to 0. As no response is expected the only > payload should be the congestion information in the notification > payload. > > This very much violates the state machine model of IKEv2, and I would > not be in favour of this without strong arguments of why requiring a > response (even if empty) is harmful. Strongly agree. Actually, one-way notifications are only defined in IKEv2 for unprotected error notifications when no IKE SA exists (like INVALID_IKE_SPI notifications). They simply don't work for regular IKEv2 traffic. Regards, Valery. > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Mar 11 09:21:05 2019 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 0B3E712008A for ; Mon, 11 Mar 2019 09:21:04 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 6XKsKkIz8R2K for ; Mon, 11 Mar 2019 09:21:02 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id A3CBB131170 for ; Mon, 11 Mar 2019 09:20:44 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id C13AA604D0; Mon, 11 Mar 2019 12:20:43 -0400 (EDT) From: Christian Hopps Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_B93A3DC2-7C58-4CE9-8A5F-0DC683CE423D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 11 Mar 2019 12:20:42 -0400 In-Reply-To: <00f601d4d821$393286c0$ab979440$@gmail.com> Cc: Christian Hopps , Paul Wouters , ipsec@ietf.org To: Valery Smyslov References: <155231377348.23058.4682503726354987752@ietfa.amsl.com> <00f601d4d821$393286c0$ab979440$@gmail.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 16:21:04 -0000 --Apple-Mail=_B93A3DC2-7C58-4CE9-8A5F-0DC683CE423D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sure, I'm definitely open to changes, and in particular with the = congestion info report. This is just the first draft. :) So my reading of IKEv2 indicated that one way notifications were = supported, not that they were *only* to be used for unprotected error = notification though. Yes, they are currently only used for errors, but = again I didn't read they were restricted to that use alone. The reason I did not want to make the report sending reliable is that = they are continuously sent on an relatively short interval. It didn't = make a lot of sense to be re-sending a possibly growing queue of reports = repeatedly, when the latest one would do. Thanks, Chris. > On Mar 11, 2019, at 11:43 AM, Valery Smyslov = wrote: >=20 > Hi, >=20 >> We utilize a send only (i.e., no response expected) IKEv2 >> INFORMATIONAL exchange (37) to transmit the congestion information >> using a notification payload of type TFS_CONGEST_INFO (TBD). The = The >> Response bit should be set to 0. As no response is expected the = only >> payload should be the congestion information in the notification >> payload. >>=20 >> This very much violates the state machine model of IKEv2, and I would >> not be in favour of this without strong arguments of why requiring a >> response (even if empty) is harmful. >=20 > Strongly agree. Actually, one-way notifications are only defined > in IKEv2 for unprotected error notifications when no IKE SA exists > (like INVALID_IKE_SPI notifications). They simply don't work > for regular IKEv2 traffic. >=20 > Regards, > Valery. >=20 >> Paul >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 --Apple-Mail=_B93A3DC2-7C58-4CE9-8A5F-0DC683CE423D 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----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlyGitoACgkQLh2DDte4 MCUQvA/+IPTOepyYVvMoMan+6iA7ZrNGULet/oDifjTYq0qDynS6hfOfmH/BK7B7 X1jRMXzyQSNUkBC1nmf3HccsuJ3PvIzFlpEkGhw318LX7wGwA5+kjmV9kcHQsOOX wBpKtSUtPRDZB6NIEh300JqAzP77nKk0LqhXSXv/Bag3XBPqltnjKuSQUDIEJsQd lHMHEgnO6ZbnWl4C7Fp6gzPxAlOy1RiGBxDLO8u0bPk8peVBsRgM54OK4d7nXqAm wzmLS0WWxE2X3X1zq8AYtxfTz6eMRBZAlVbJaMLRY840ltZglOpyKHmLMls2zW2P GY6pSHkDAjGONGL27lWFDPGWNwvwtCtXdZPzNLQsZs8W7F3IGccAcb9LmelZ+Rx6 ezIer/oeSbAUiNtNYqWWi4Mc16AIOMMDC5i1S7ukfu6DM1JW6KbbyEXyufsR90ri qsoImue8CfpDF/rIoZwes/8fv3ZKeo0b5A6HNp45mSonagcRXq3YCPxVBKigDMM4 Omh8h6esx6gItbnpbxTcp8dtCI3uLP9LF/PhCC7XYn/+CCYY5yHd6F1t2jLgGaR/ NjuMigAIlxzZkwBTy9murde2aS72jhQ3M5yJCSDRDLqEcZap/mIrMO/ULZNEmiAo N8OaJT608rs/f567fApQ2Sd5+JVmNSEoy6YcE8XRaOMXag69sv0= =yoSe -----END PGP SIGNATURE----- --Apple-Mail=_B93A3DC2-7C58-4CE9-8A5F-0DC683CE423D-- From nobody Mon Mar 11 09:32:51 2019 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 B958412787D for ; Mon, 11 Mar 2019 09:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 flAdXZqRE-Ta for ; Mon, 11 Mar 2019 09:32:48 -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 6CAB7127962 for ; Mon, 11 Mar 2019 09:32:48 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44J3YT6QrXzK6g; Mon, 11 Mar 2019 17:32:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1552321965; bh=2hCzPoiooOVzfQC77AxPqXrvNxJo2dRUrAtx7ES5d2U=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=YxT30yFazeUp+rpuM2zpbkbaEMp7Ulpl43+f57PXHyaVFChzOxBJtaRPsZ/EdR9G6 a9R+wXxTo60qM63MEBxw9Sf0BVA2iBzodaS1MZqBQjTH3birG58Mhcz/dnicuBNfQs wdb2v8KB+ZsJ6RT+R/Ebg/Lv+fMww9rzAki6/GHQ= 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 pL0PLt9Ab8rK; Mon, 11 Mar 2019 17:32:43 +0100 (CET) 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; Mon, 11 Mar 2019 17:32:43 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 302A236FBA; Mon, 11 Mar 2019 12:32:42 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 302A236FBA Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 23D2340C96E4; Mon, 11 Mar 2019 12:32:42 -0400 (EDT) Date: Mon, 11 Mar 2019 12:32:42 -0400 (EDT) From: Paul Wouters To: Christian Hopps cc: Valery Smyslov , ipsec@ietf.org In-Reply-To: Message-ID: References: <155231377348.23058.4682503726354987752@ietfa.amsl.com> <00f601d4d821$393286c0$ab979440$@gmail.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 16:32:51 -0000 On Mon, 11 Mar 2019, Christian Hopps wrote: > Sure, I'm definitely open to changes, and in particular with the congestion info report. This is just the first draft. :) > > So my reading of IKEv2 indicated that one way notifications were supported, not that they were *only* to be used for unprotected error notification though. Yes, they are currently only used for errors, but again I didn't read they were restricted to that use alone. Note that even those errors are in reply to an IKE request, so you still have a request and reply message. > The reason I did not want to make the report sending reliable is that they are continuously sent on an relatively short interval. It didn't make a lot of sense to be re-sending a possibly growing queue of reports repeatedly, when the latest one would do. You might find previous discussion about MSGID and liveness probes interesting then. That runs into similar issues and we don't have a fix for this yet, although it has come up a few times that we sould write a clarifying draft on MSGID. For example, if you send a liveness probe and receive no answer, you cannot send a delete notification because the liveness answer is still pending. If you send many of these kind of IKE packets, then you would run into similar problems. Paul From nobody Mon Mar 11 09:35:45 2019 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 9C165131164 for ; Mon, 11 Mar 2019 09:35:43 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 xzVhyPaJnFey for ; Mon, 11 Mar 2019 09:35:41 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 78FF3130EBC for ; Mon, 11 Mar 2019 09:35:41 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id E1EDC604D0; Mon, 11 Mar 2019 12:35:40 -0400 (EDT) From: Christian Hopps Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_72508B6F-A24E-4F25-B3C5-79F6411F668F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 11 Mar 2019 12:35:39 -0400 In-Reply-To: Cc: Christian Hopps , "ipsec@ietf.org WG" To: Paul Wouters References: <155231377348.23058.4682503726354987752@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 16:35:44 -0000 --Apple-Mail=_72508B6F-A24E-4F25-B3C5-79F6411F668F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 11, 2019, at 10:51 AM, Paul Wouters wrote: >=20 > On Mon, 11 Mar 2019, Christian Hopps wrote: >=20 >> Here's some new work on improving IP traffic flow security. I've = requested a presentation slot from the chairs for the upcoming ipsecme = WG meeting @ IETF 104, and will hopefully be able to present this work = at that time as well. >=20 > Thanks. I did a quick read and I'm still digesting this, but one thing > seems a concern: >=20 > We utilize a send only (i.e., no response expected) IKEv2 > INFORMATIONAL exchange (37) to transmit the congestion information > using a notification payload of type TFS_CONGEST_INFO (TBD). The = The > Response bit should be set to 0. As no response is expected the = only > payload should be the congestion information in the notification > payload. >=20 > This very much violates the state machine model of IKEv2, and I would > not be in favour of this without strong arguments of why requiring a > response (even if empty) is harmful. The strongest case I can give is that this data represents "telemetry" = and is sent at a constant rate, there's no need to make it reliable (and = resending queues of them seems bad if they aren't being ack'd). There are other ways to skin this cat though. :) One option is that instead of sending a new CC info report on the = interval timer expiry if we haven't received a response "ack" yet, we = simply update the data (last seq num seen, drop count and timestamp) we = sent previously to be current, keep the message ID the same and resend = the message. Would changing the data in the message prior to resending = be preferable? Thanks, Chris. >=20 > Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 --Apple-Mail=_72508B6F-A24E-4F25-B3C5-79F6411F668F 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----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlyGjlsACgkQLh2DDte4 MCX4Dg//cn5r4ok9UjBnavBY7uKUS/+Me44UTsm2ILUDsp7jt8gWYot/WmFFhIdd vUqSIrMLlWNS1T5JWJIw17k7Q6ONeXey5FoYauJawgdbgUKSiOQKGoa9TuJxFj7p X5G21Knw7IoeX0J/X5TF+DjsXYnXqZw7nI1jc77be4FRBRuUgXQa9TSP/Lut7z4P KaL+8dXzzqAdFU8V9bXfPYVtmOTgdbtKHYlADni6ZVWwvkvtvV6GgDf6AtEo1iHe 5DSqC9MSN1X6eSWgm6S1y2U7o2GrcsM4UDHch5phdmhWg9NmebPg9Gh3RFxncj5M +kmtvMzxGns5P46hJcf0uPsm/yDfsYjLh7YcP1gxYo5lK0HuHBgvW8tueASQD5iT OfdmAxfqlbnx53X0v0RG8KGAVPRJxOXXUkLUa79DyMx7EOrYCusOsErxIAPKVXRK ciVmmTEOMB35yIngl/nf6y7l/l1d7gtO68ZWFr+j0v7f28w8y9c+1N16KZuZ+OMw /lCMRYyw3MdEA4aRND0wvf4VLMUCla1q29WOMSIZvjjT5/VPzJVDv6KQ3rNh/QkR 0AufTkrcSqIDDmoI8cEJzVU30egtw4DkRvKJLqj3wj1ZLDolYwWDuQSDVcUNEaUN IfmllhZVOwpZZTmpliA9tgYRX5N3xFreYygj+B9aMMsx5L5YbqU= =Pliz -----END PGP SIGNATURE----- --Apple-Mail=_72508B6F-A24E-4F25-B3C5-79F6411F668F-- From nobody Mon Mar 11 09:40:04 2019 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 91F4D1311EE; Mon, 11 Mar 2019 09:39:56 -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.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <155232239653.23082.5184210085859437561@ietfa.amsl.com> Date: Mon, 11 Mar 2019 09:39:56 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-labeled-ipsec-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 16:40:03 -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 WG of the IETF. Title : Labeled IPsec Traffic Selector support for IKEv2 Authors : Paul Wouters Sahana Prasad Filename : draft-ietf-ipsecme-labeled-ipsec-00.txt Pages : 7 Date : 2019-03-10 Abstract: This document defines two new Traffic Selector (TS) Types for Internet Key Exchange version 2 to add support for Mandatory Access Control (MAC) security labels, also known as "Labeled IPsec". The two new TS Types are TS_IPV4_ADDR_RANGE_SECLABEL and TS_IPV6_ADDR_RANGE_SECLABEL, which are identical to their non- seclabel namesakes except for the addition of a variable length opaque field specifying the security label. These new Traffic Selector Types facilitate negotiating security labels as an additional selector of the Security Policy Database to further restrict the type of traffic allowed to be send and received over the IPsec SA. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-labeled-ipsec/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-labeled-ipsec-00 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-labeled-ipsec-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 10:22:40 2019 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 CBF5E1311B1; Mon, 11 Mar 2019 10:22:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, iesg-secretary@ietf.org, Tero Kivinen , kivinen@iki.fi Message-ID: <155232493282.23211.9953254323515575155.idtracker@ietfa.amsl.com> Date: Mon, 11 Mar 2019 10:22:12 -0700 Archived-At: Subject: [IPsec] Publication has been requested for draft-ietf-ipsecme-implicit-iv-06 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 17:22:14 -0000 Tero Kivinen has requested publication of draft-ietf-ipsecme-implicit-iv-06 as Proposed Standard on behalf of the IPSECME working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ From nobody Mon Mar 11 10:28:55 2019 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 893BF131168; Mon, 11 Mar 2019 10:28:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <155232532950.23207.9497630358764449438@ietfa.amsl.com> Date: Mon, 11 Mar 2019 10:28:49 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-17.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 17:28:54 -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 WG of the IETF. Title : Split DNS Configuration for IKEv2 Authors : Tommy Pauly Paul Wouters Filename : draft-ietf-ipsecme-split-dns-17.txt Pages : 16 Date : 2019-03-11 Abstract: This document defines two Configuration Payload Attribute Types (INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA) for the Internet Key Exchange Protocol Version 2 (IKEv2). These payloads add support for private (internal-only) DNS domains. These domains are intended to be resolved using non-public DNS servers that are only reachable through the IPsec connection. DNS resolution for other domains remains unchanged. These Configuration Payloads only apply to split tunnel configurations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-17 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-split-dns-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 11:39:17 2019 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 DB755127971 for ; Mon, 11 Mar 2019 11:39:15 -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, URIBL_BLOCKED=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 hnZdqY5sU6OD for ; Mon, 11 Mar 2019 11:39:13 -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 5B4F3124BF6 for ; Mon, 11 Mar 2019 11:39:08 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44J6MG44fwzK6v for ; Mon, 11 Mar 2019 19:39:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1552329546; bh=QkQdwLDyNAhbv/oy7/5jxTlG4fujA8XX5q2KQFh8a1U=; h=Date:From:To:Subject; b=DAGlLxNUiW8hQcgFVAoiTAZGEJd7WKn4NFZJzuO5OMT3hrTr+oKikM6ozD+e27w4p VR3OUKNN7Eb0DrfYNHktAker3ow4J5mfXcWHI7jS+wtbLfkRc9ttrDutb5b1PZZr6k 767vnjzCQCjYMzdcMrXgsOjAB6kOvXmTkJ5orwW4= 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 kfbLs5nvQLK6 for ; Mon, 11 Mar 2019 19:39:05 +0100 (CET) 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 ; Mon, 11 Mar 2019 19:39:04 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8F81D36FBA; Mon, 11 Mar 2019 14:39:03 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8F81D36FBA Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 85CB640C96E4 for ; Mon, 11 Mar 2019 14:39:03 -0400 (EDT) Date: Mon, 11 Mar 2019 14:39:03 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; CHARSET=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: [IPsec] Fwd: New Version Notification for draft-pwouters-ikev1-ipsec-graveyard-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 18:39:16 -0000 As we discussed on the list and in Bangkok, we were going to submit a document to deprecrate IKEv1 and various old skool algorithms using a [DEPRECATED] column in the IANA registry. I wrote a first draft to do this... Paul ---------- Forwarded message --------- From: Date: Mon, Mar 11, 2019 at 2:35 PM Subject: New Version Notification for draft-pwouters-ikev1-ipsec-graveyard-00.txt To: Paul Wouters A new version of I-D, draft-pwouters-ikev1-ipsec-graveyard-00.txt has been successfully submitted by Paul Wouters and posted to the IETF repository. Name:           draft-pwouters-ikev1-ipsec-graveyard Revision:       00 Title:          Deprecation of IKEv1 and obsoleted algorithms Document date:  2019-03-11 Group:          Individual Submission Pages:          6 URL:            https://www.ietf.org/internet-drafts/draft-pwouters-ikev1-ipsec-graveyard-00.txt Status:         https://datatracker.ietf.org/doc/draft-pwouters-ikev1-ipsec-graveyard/ Htmlized:       https://tools.ietf.org/html/draft-pwouters-ikev1-ipsec-graveyard-00 Htmlized:       https://datatracker.ietf.org/doc/html/draft-pwouters-ikev1-ipsec-graveyard Abstract:    This document deprecates Internet Key Exchange version 1 (IKEv1) and    additionally deprecates a number of algorithms that are obsolete. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Mar 12 07:34:33 2019 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 E1717131071 for ; Tue, 12 Mar 2019 07:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 QLyFNGg4Cxl7 for ; Tue, 12 Mar 2019 07:34:30 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DF1E13106D for ; Tue, 12 Mar 2019 07:34:30 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id x13so2517697ljj.5 for ; Tue, 12 Mar 2019 07:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=SNk0soVKLHM5S9Ct6llVsmX33rg2swuD10a5rH/joCs=; b=OqyEJSh3WTQmHsRsSpy5EkQZSUg7Ou/kMs4ZGhnKOiREU4XrtACe5Xy6rcIjGDHNF3 ys9+U1fRect/khdiYBUX76y/k8gpSu2+7ABsjkf3PdqBNeJRY4IRKwOnd1VaJzcS6gCz QdNfXje3Qm6d8zjnuADvSE0sU2ZSc0LEP8gf8n6ZgYwy8Oe65jWJKDW32Jd5Fo971hYf jE5uSdvEWNIQZC+PjaAU43OuswI8W4T57JS4Ip1Mj+0Lzf+u6ZT4KXfQAmuRtAvMoybY MZORQ8X08NKPoRE1cEhw4asNEd462iF9oS4uuLSjUT8+D+uCgov78LfXcMib476X/sjQ lrPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=SNk0soVKLHM5S9Ct6llVsmX33rg2swuD10a5rH/joCs=; b=hqXz+v6oKyG6Fma9nJPBQgrc1N+/SpCMXje7mYQnkQhl/YY1lY4uoKRhoDSSycaPGK znDsSR5qi6GElVOsKGBUzBLJyhMlUU7JaNFerY8/qbpbTjBH+IAOQHtI5pIe66CYJtgI TM+kwPJTuzZMH7pjh/SWQ0uYxsSNRfntZnJsbWQ11U7836tp9D+FR+o8nCR4BxLM1X8n COX9+bFPwnmOD9KNoqxzzHrCYNeosjU9ofN43igR81nrkLh5RFcXqsO4PO49PyKH1Wic FVNtkIXnm8/4b7Xf2CQ0/gV/3myEZTNX85+DCHTZqJEueS2H7s2QzFNqNTdrkT74AhYk l9iQ== X-Gm-Message-State: APjAAAVrFUfvIBCaE1fCciHsVK8qstb+XsflSrPVWLvNy957D2ZI+8b7 eIYRKcw95G4CdMXQJeTuj/fA2mfu X-Google-Smtp-Source: APXvYqykYMcquJpKLo2bSqiNpbBuU34lBiIFK/Wytww6bj/O2oKgIDeVXybzFjOBlMkJKqHeg5KD0A== X-Received: by 2002:a2e:80cd:: with SMTP id r13mr19865114ljg.34.1552401268390; Tue, 12 Mar 2019 07:34:28 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id q1sm1591134lfe.12.2019.03.12.07.34.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Mar 2019 07:34:27 -0700 (PDT) From: "Valery Smyslov" To: "'Christian Hopps'" Cc: "'Paul Wouters'" , References: <155231377348.23058.4682503726354987752@ietfa.amsl.com> <00f601d4d821$393286c0$ab979440$@gmail.com> In-Reply-To: Date: Tue, 12 Mar 2019 17:34:25 +0300 Message-ID: <01e601d4d8e0$b1ff4ec0$15fdec40$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHDC2i80LRgGX+akLu0yxdYVb2DCQJ2/jYBALrj5fgCiRnizgHARUNwpe/KhdA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 14:34:32 -0000 Hi Chris, > Sure, I'm definitely open to changes, and in particular with the congestion info report. This is just the first > draft. :) > > So my reading of IKEv2 indicated that one way notifications were supported, not that they were *only* to be > used for unprotected error notification though. Yes, they are currently only used for errors, but again I didn't > read they were restricted to that use alone. No, unidirectional notifications cannot be used in regular IKE SAs. The reason is that both peers must have common view on the next Message ID to be used in each direction. If unidirectional message with Message ID N is lost, its sender will never know that and think he can safely use Message ID N+1 for the next exchange, while the receiver will discard N+1, since N is not received yet (I assume for simplicity that IKE window size is 1). This simply won't work. In current IKEv2 unidirectional messages are exceptions and can only be sent unencrypted outside any existing IKE SA. > The reason I did not want to make the report sending reliable is that they are continuously sent on an > relatively short interval. It didn't make a lot of sense to be re-sending a possibly growing queue of reports > repeatedly, when the latest one would do. Then send them over IPsec. Regards, Valery. > Thanks, > Chris. > > > > > On Mar 11, 2019, at 11:43 AM, Valery Smyslov wrote: > > > > Hi, > > > >> We utilize a send only (i.e., no response expected) IKEv2 > >> INFORMATIONAL exchange (37) to transmit the congestion information > >> using a notification payload of type TFS_CONGEST_INFO (TBD). The The > >> Response bit should be set to 0. As no response is expected the only > >> payload should be the congestion information in the notification > >> payload. > >> > >> This very much violates the state machine model of IKEv2, and I would > >> not be in favour of this without strong arguments of why requiring a > >> response (even if empty) is harmful. > > > > Strongly agree. Actually, one-way notifications are only defined > > in IKEv2 for unprotected error notifications when no IKE SA exists > > (like INVALID_IKE_SPI notifications). They simply don't work > > for regular IKEv2 traffic. > > > > Regards, > > Valery. > > > >> Paul > >> > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > From nobody Tue Mar 12 07:39:13 2019 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 B1329129AA0 for ; Tue, 12 Mar 2019 07:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L--N7ocO484V for ; Tue, 12 Mar 2019 07:39:10 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD101275F3 for ; Tue, 12 Mar 2019 07:39:10 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id q128so2494889ljb.11 for ; Tue, 12 Mar 2019 07:39:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=FyLlzkt6NjI6Bt5BvW263Ypf3H3hWnBFxt6XnmUb78g=; b=dnY1VfrZRrsTTsR1HZBFfM5PtCJPKhsVRpzI5j07DiYslf5Bqf2xfE7GSY5JTeMBz/ m80qioRBUUorzoLyqayHEdQwT2fwO5dvxjMdsdd7XfYxWiBOHJpVhTUPoyedboJiFyrY nUZ7TKYe/moHE1x2rJC4YncsGyRxDkTVKkMWtZqn58RtIXyY/gKOOLLH//blcUT47smD 0KhUf37TlRNbfGNVX/9PnXaE83H/GiybHp1v5hU2dRTtw1/mP+5bcymkQppowiMZvAvq 4ZSpZxdQYuXS+E2UCwzdhHnLzh66jNVZBbCiA31CQAabhr7lqfHr73vivQqSGGP+b02Z yA4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=FyLlzkt6NjI6Bt5BvW263Ypf3H3hWnBFxt6XnmUb78g=; b=otQG7Y7GBYGj1oVZTU6KCknGmZli0UqmMZeadwzD3d0ZrlsEVAKRotMCkrY7o1RNwM tL8RBRRuBXaFGoEvFIWZyT3rQ9OXeA3dB9Lr8mVPdRuWb0bwTN/m7ekbdZg0VfVF1noh aRIIPTcIm+zbVVBTB/RnUB30AW0V3PSeUmiHQXLMj0Oo5Siowycr8U7SsUZp0L6woc/j KKI/bStMaHPFk0PrDXpSqZiLC9m52Nqm55zlr0EguJxmjdPnkkWbMeDr6b7tc7Psifj5 DmemD758yF4CVvMjph9YESLsEtdmJoVzDZ2mRRHYPT3TyLRfYqd7QOZdc7XQzJMpg4uj K0Cg== X-Gm-Message-State: APjAAAWlcrsDTufK2warP89AlGnGMtDFEg87cFSsRnOfvb5CKz7sy2MJ PiSKX83f/f1nXWpxVbzNhAw= X-Google-Smtp-Source: APXvYqz/lsqk77hE+0rDCtwzXr/EaBvpJ4nS1T/clZ8lsZo4cs/RneaSul7/glX+5WtpMtrYBIhKlQ== X-Received: by 2002:a05:651c:82:: with SMTP id 2mr1847149ljq.39.1552401548303; Tue, 12 Mar 2019 07:39:08 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id t24sm476876lji.21.2019.03.12.07.39.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Mar 2019 07:39:07 -0700 (PDT) From: "Valery Smyslov" To: "'Christian Hopps'" , "'Paul Wouters'" Cc: References: <155231377348.23058.4682503726354987752@ietfa.amsl.com> In-Reply-To: Date: Tue, 12 Mar 2019 17:39:06 +0300 Message-ID: <01f401d4d8e1$58fcc9f0$0af65dd0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHDC2i80LRgGX+akLu0yxdYVb2DCQJ2/jYBALrj5fgCexdAJ6X+Q2Wg Content-Language: ru Archived-At: Subject: Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 14:39:12 -0000 Hi Chris, > There are other ways to skin this cat though. :) > > One option is that instead of sending a new CC info report on the interval timer expiry if we haven't received a > response "ack" yet, we simply update the data (last seq num seen, drop count and timestamp) we sent > previously to be current, keep the message ID the same and resend the message. Would changing the data in > the message prior to resending be preferable? No, all retransmissions of IKE message with the same Message ID must be binary identical. Regards, Valery. > Thanks, > Chris. From nobody Tue Mar 12 08:42:57 2019 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 08DE01312BB for ; Tue, 12 Mar 2019 08:42:49 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 gJW8qFtyzJMZ for ; Tue, 12 Mar 2019 08:42:47 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 78B7C1312A1 for ; Tue, 12 Mar 2019 08:42:46 -0700 (PDT) Received: from dex.int.chopps.org (172-222-100-236.dhcp.chtrptr.net [172.222.100.236]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id C0C6F604EB; Tue, 12 Mar 2019 11:42:45 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Christian Hopps In-Reply-To: <01e601d4d8e0$b1ff4ec0$15fdec40$@gmail.com> Date: Tue, 12 Mar 2019 11:42:44 -0400 Cc: Christian Hopps , ipsec@ietf.org, Paul Wouters Content-Transfer-Encoding: quoted-printable Message-Id: References: <155231377348.23058.4682503726354987752@ietfa.amsl.com> <00f601d4d821$393286c0$ab979440$@gmail.com> <01e601d4d8e0$b1ff4ec0$15fdec40$@gmail.com> To: Valery Smyslov X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [IPsec] I-D Action: draft-hopps-ipsecme-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 15:42:56 -0000 > On Mar 12, 2019, at 10:34, Valery Smyslov = wrote: >=20 > Hi Chris, >=20 >> Sure, I'm definitely open to changes, and in particular with the = congestion info report. This is just the first >> draft. :) >>=20 >> So my reading of IKEv2 indicated that one way notifications were = supported, not that they were *only* to be >> used for unprotected error notification though. Yes, they are = currently only used for errors, but again I didn't >> read they were restricted to that use alone. >=20 > No, unidirectional notifications cannot be used in regular IKE SAs. = The reason is that both peers must have common view=20 > on the next Message ID to be used in each direction. If unidirectional = message with Message ID N is lost, its sender will never know > that > and think he can safely use Message ID N+1 for the next exchange, = while the receiver will discard N+1, since > N is not received yet (I assume for simplicity that IKE window size is = 1). This simply won't work. >=20 > In current IKEv2 unidirectional messages are exceptions and can only = be sent unencrypted outside=20 > any existing IKE SA. Ok. Perhaps we could look into extending their usefulness? >> The reason I did not want to make the report sending reliable is that = they are continuously sent on an >> relatively short interval. It didn't make a lot of sense to be = re-sending a possibly growing queue of reports >> repeatedly, when the latest one would do. >=20 > Then send them over IPsec. Unfortunately this would require bi-directional tunnels, which we = don=E2=80=99t want to require. More in the reply to the other email... Thanks, Chris. >=20 > Regards, > Valery. >=20 >> Thanks, >> Chris. >>=20 >>=20 >>=20 >>> On Mar 11, 2019, at 11:43 AM, Valery Smyslov = wrote: >>>=20 >>> Hi, >>>=20 >>>> We utilize a send only (i.e., no response expected) IKEv2 >>>> INFORMATIONAL exchange (37) to transmit the congestion = information >>>> using a notification payload of type TFS_CONGEST_INFO (TBD). The = The >>>> Response bit should be set to 0. As no response is expected the = only >>>> payload should be the congestion information in the notification >>>> payload. >>>>=20 >>>> This very much violates the state machine model of IKEv2, and I = would >>>> not be in favour of this without strong arguments of why requiring = a >>>> response (even if empty) is harmful. >>>=20 >>> Strongly agree. Actually, one-way notifications are only defined >>> in IKEv2 for unprotected error notifications when no IKE SA exists >>> (like INVALID_IKE_SPI notifications). They simply don't work >>> for regular IKEv2 traffic. >>>=20 >>> Regards, >>> Valery. >>>=20 >>>> Paul >>>>=20 >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>>=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 From nobody Tue Mar 12 08:54:56 2019 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 24262131063 for ; Tue, 12 Mar 2019 08:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 LgnVfrx_3JbO for ; Tue, 12 Mar 2019 08:54:46 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7425B130FE5 for ; Tue, 12 Mar 2019 08:54:46 -0700 (PDT) Received: from dex.int.chopps.org (172-222-100-236.dhcp.chtrptr.net [172.222.100.236]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id A701E604EB; Tue, 12 Mar 2019 11:54:45 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Christian Hopps In-Reply-To: <01f401d4d8e1$58fcc9f0$0af65dd0$@gmail.com> Date: Tue, 12 Mar 2019 11:54:44 -0400 Cc: Christian Hopps , Paul Wouters , ipsec@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <155231377348.23058.4682503726354987752@ietfa.amsl.com> <01f401d4d8e1$58fcc9f0$0af65dd0$@gmail.com> To: Valery Smyslov X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [IPsec] I-D Action: draft-hopps-ipsecme-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 15:54:53 -0000 > On Mar 12, 2019, at 10:39, Valery Smyslov = wrote: >=20 > Hi Chris, >=20 >> There are other ways to skin this cat though. :) >>=20 >> One option is that instead of sending a new CC info report on the = interval timer expiry if we haven't received a >> response "ack" yet, we simply update the data (last seq num seen, = drop count and timestamp) we sent >> previously to be current, keep the message ID the same and resend the = message. Would changing the data in >> the message prior to resending be preferable? >=20 > No, all retransmissions of IKE message with the same Message ID must = be binary identical. Perhaps we could relax this requirement for this particular message = though. This seems like a simple tightly-focused semantic change which = gets us past the roadblock.=20 FWIW, regarding retransmission and message IDs, one thing I considered = was not even using the message ID at all (e.g., let it be 0) but this = seemed too radical as a first approach. :) If there really is no way to work around this, I suppose we just require = retransmissions of CC info reports until they are ACKd or things are = torn down b/c of drops (i.e., normal INFO exchange). It does feel like = we are adding fragility here that isn=E2=80=99t really needed though. It = makes the functioning of the unidirectional tunnel depend more heavily = on the reverse direction traffic working when that isn=E2=80=99t = actually needed for the tunnel to operate. Thanks, Chris. >=20 > Regards, > Valery. >=20 >> Thanks, >> Chris. >=20 From nobody Tue Mar 12 09:19:52 2019 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 D2C50124B91 for ; Tue, 12 Mar 2019 09:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 QwSfG0TIHOcz for ; Tue, 12 Mar 2019 09:19:47 -0700 (PDT) Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.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 C5F681200B3 for ; Tue, 12 Mar 2019 09:19:47 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x2CGCeGb006490; Tue, 12 Mar 2019 09:19:47 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : subject : from : in-reply-to : date : cc : message-id : references : to; s=20180706; bh=Bq8acdRNz/J2zYH5igBCTGUCDD2jN8oKwNLFmexnR6I=; b=E80ZIAbJN0ZfPv7RwbeHZ0J5I0jPeBUaJC1hFQ9BCalbFjJHU1IYDVd/mccyyT4jwe15 AjWYNHTGoXykvklxQmjL2Humn1u3FOAEJZqU4O97X5KTQfbCYsLa0Oixl65SmLCKOXY8 qR4uFs9UzLJSbHN+1lWKBlt7mfSdPpuLWhxa6BE+rFH641Y8S0gEbk4bFbdqja3qaY0I j2xK7M7M5muEGdY9kAvHQGFbcEidUpbTLe4KMjVhiMxcnWB3uoTLyQqm2UpS5TNNi6Eh FkqlejSXJEaYErtoi6SMYKA9EWbijMipUJCqEdcDmWyaEIJniqAwwQVJHuEKlGTrZGDO ng== Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2r4x1305x0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 12 Mar 2019 09:19:47 -0700 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PO90036BHCOY280@ma1-mtap-s01.corp.apple.com>; Tue, 12 Mar 2019 09:19:37 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PO900000GWQU900@nwk-mmpp-sz11.apple.com>; Tue, 12 Mar 2019 09:19:36 -0700 (PDT) X-Va-A: X-Va-T-CD: 0ffb4ba06162e7d0023839378ebed949 X-Va-E-CD: 87c4c69dd8be1fad8a4339bb4cc36b9b X-Va-R-CD: 67278a92431b5d7d0d9767cbfbd82a92 X-Va-CD: 0 X-Va-ID: 698e3d34-7d28-4549-a98a-e93c7f3ca9b3 X-V-A: X-V-T-CD: 0ffb4ba06162e7d0023839378ebed949 X-V-E-CD: 87c4c69dd8be1fad8a4339bb4cc36b9b X-V-R-CD: 67278a92431b5d7d0d9767cbfbd82a92 X-V-CD: 0 X-V-ID: a2c849a6-8092-4d20-b5af-1ccdedc39356 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-03-12_09:,, signatures=0 Received: from tpauly.scv.apple.com (tpauly.scv.apple.com [17.192.171.37]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PO900GD3HCNT410@nwk-mmpp-sz11.apple.com>; Tue, 12 Mar 2019 09:19:35 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: Date: Tue, 12 Mar 2019 09:19:35 -0700 Cc: "ipsec@ietf.org WG" Message-id: <64D1977A-3A60-41DC-8A9D-980F4174F003@apple.com> References: To: Paul Wouters X-Mailer: Apple Mail (2.3526.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-12_09:, , signatures=0 Archived-At: Subject: Re: [IPsec] New Version Notification for draft-pwouters-ikev1-ipsec-graveyard-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 16:19:51 -0000 Thanks for writing this up! Glad to get rid of IKEv1 =) I do have a question regarding whether the deprecations for the IKEv2 registry are appropriate for this document. RFC 8247 contains the recommendations for the which algorithms and DH groups are going away (SHOULD NOT, MUST NOT, etc), and it seems like an update to that document or similar would be more appropriate to discuss marking deprecation. Best, Tommy > On Mar 11, 2019, at 11:39 AM, Paul Wouters wrote: > > > As we discussed on the list and in Bangkok, we were going to submit a > document to deprecrate IKEv1 and various old skool algorithms using > a [DEPRECATED] column in the IANA registry. > > I wrote a first draft to do this... > > Paul > > ---------- Forwarded message --------- > From: > Date: Mon, Mar 11, 2019 at 2:35 PM > Subject: New Version Notification for draft-pwouters-ikev1-ipsec-graveyard-00.txt > To: Paul Wouters > > > > A new version of I-D, draft-pwouters-ikev1-ipsec-graveyard-00.txt > has been successfully submitted by Paul Wouters and posted to the > IETF repository. > > Name: draft-pwouters-ikev1-ipsec-graveyard > Revision: 00 > Title: Deprecation of IKEv1 and obsoleted algorithms > Document date: 2019-03-11 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft-pwouters-ikev1-ipsec-graveyard-00.txt > Status: https://datatracker.ietf.org/doc/draft-pwouters-ikev1-ipsec-graveyard/ > Htmlized: https://tools.ietf.org/html/draft-pwouters-ikev1-ipsec-graveyard-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-pwouters-ikev1-ipsec-graveyard > > > Abstract: > This document deprecates Internet Key Exchange version 1 (IKEv1) and > additionally deprecates a number of algorithms that are obsolete. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Mar 12 20:26:55 2019 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 21FB612797C; Tue, 12 Mar 2019 20:26:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155244761313.5509.12204315922788817338.idtracker@ietfa.amsl.com> Date: Tue, 12 Mar 2019 20:26:53 -0700 Archived-At: Subject: [IPsec] The IPSECME WG has placed draft-smyslov-ipsecme-ikev2-aux in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 03:26:53 -0000 The IPSECME WG has placed draft-smyslov-ipsecme-ikev2-aux in state Call For Adoption By WG Issued (entered by Tero Kivinen) The document is available at https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-aux/ From nobody Tue Mar 12 20:30:36 2019 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 16E45127598 for ; Tue, 12 Mar 2019 20:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, 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 4FN8b2hkClUx for ; Tue, 12 Mar 2019 20:30:33 -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 A3E0612705F for ; Tue, 12 Mar 2019 20:30:32 -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 x2D3UUvd021319 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 13 Mar 2019 05:30:30 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x2D3UUAo022352; Wed, 13 Mar 2019 05:30:30 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23688.31062.426962.985107@fireball.acr.fi> Date: Wed, 13 Mar 2019 05:30:30 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 2 min Archived-At: Subject: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 03:30:34 -0000 This document has been stable for some time, and I think it is ready to go forward. Because of that I will start one week long WG adoptation call for this draft which will expire end of next week (2019-03-22). If you have any reasons why this should not be adopted as WG document, send email to the list as soon as possible. -- kivinen@iki.fi From nobody Tue Mar 12 20:50:19 2019 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 DC0111277DB for ; Tue, 12 Mar 2019 20:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, 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 Cdg8ca6lhNGQ for ; Tue, 12 Mar 2019 20:50: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 15E23127598 for ; Tue, 12 Mar 2019 20:50:15 -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 x2D3oD2X012403 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 13 Mar 2019 05:50:13 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x2D3oCag008099; Wed, 13 Mar 2019 05:50:12 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23688.32244.947267.849036@fireball.acr.fi> Date: Wed, 13 Mar 2019 05:50:12 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 2 min Archived-At: Subject: [IPsec] IETF 104 presentations X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 03:50:18 -0000 I am now setting up the agenda for IETF 104, so if you have any presentation etc you want to present there (and I have not yet sent email to you about it), send requests to us chairs as soon as possible (i.e., before the end of THIS week i.e., before 2019-03-15). -- kivinen@iki.fi From nobody Tue Mar 12 21:04:57 2019 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 07411129BBF for ; Tue, 12 Mar 2019 21:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LN_Lihmi1hWP for ; Tue, 12 Mar 2019 21:04:54 -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 F2C3F129570 for ; Tue, 12 Mar 2019 21:04:53 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44Jys212LZzDby; Wed, 13 Mar 2019 05:04:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1552449862; bh=0epFSPubEgCsIN5fxUnOS4wn2QDf6Fx/2NVfTn+ckAo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Yuik1yEUHYSna9ABe4reaODO8lnFSjEvW43RCMaB4Wg073N99treYuXm7+Sa+ayWW DPVw4YWWjeQJ3i188jnU2ZUeToZbtiJeHppwMMdlAwdxsvJPbTUSPiD9ysmtbzge7a MPrXGBDd4QdXW5AAnxWCBscKkZSHb9OQpaYvUWzU= 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 EJ8XkwrfVpDb; Wed, 13 Mar 2019 05:04:21 +0100 (CET) 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; Wed, 13 Mar 2019 05:04:20 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E85122FCD9; Wed, 13 Mar 2019 00:04:19 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca E85122FCD9 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E0F7140D35BD; Wed, 13 Mar 2019 00:04:19 -0400 (EDT) Date: Wed, 13 Mar 2019 00:04:19 -0400 (EDT) From: Paul Wouters To: Tommy Pauly cc: "ipsec@ietf.org WG" In-Reply-To: <64D1977A-3A60-41DC-8A9D-980F4174F003@apple.com> Message-ID: References: <64D1977A-3A60-41DC-8A9D-980F4174F003@apple.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] New Version Notification for draft-pwouters-ikev1-ipsec-graveyard-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 04:04:55 -0000 On Tue, 12 Mar 2019, Tommy Pauly wrote: > Thanks for writing this up! Glad to get rid of IKEv1 =) We just need PPK and Labeled IPsec as RFC and then we are go :) > I do have a question regarding whether the deprecations for the IKEv2 registry are appropriate for this document. RFC 8247 contains the recommendations for the which algorithms and DH groups are going away (SHOULD NOT, MUST NOT, etc), and it seems like an update to that document or similar would be more appropriate to discuss marking deprecation. I might have misunderstood Tero, but this what we said before: Paul: > I'm happy to write a separate diediedie document, but it would sort of Paul: > break the cycle of our IKE and ESP/AH document updates? Tero: Writing separate die-die-die document would be faster, and I do not Tero: think we have yet any pending changes for the algorithms we have in Tero: 8221 and 8247 waiting to be done. While it should update 8221/8247 (I'll add it for the next revision), I think Tero is right that this isn't the regular cycle of algorithm update using bis documents. It would be a bit overkill to already replace those two documents, especially because the "diff" would really not be very informative, because it would only show what are currently MAY algorithms that are not shown in 8221/8247 at all because they didn't change. And since we are not changing anything else, we wouldn't show anything else in the columns. So I think doing this "out of series" is a better solution. But I didn't instruct IANA to put [this document] in the ESP and IKEv2 reference columns for those algorithms, which we should do as well as adding the DEPRECATED column [insert Tero sitting at a table with "An extra column is wrong - CHANGE MY MIND"] poster. Paul From nobody Thu Mar 14 01:34:13 2019 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 8E82D127918 for ; Thu, 14 Mar 2019 01:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GdU4DnIdhuJ for ; Thu, 14 Mar 2019 01:34:11 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 47BE21277DB for ; Thu, 14 Mar 2019 01:34:11 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id t5so4834397wri.7 for ; Thu, 14 Mar 2019 01:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=/USuNnl9mwNcNv9NTeGgyoPb8svR3DzIOZuO5JOERwY=; b=q9RWEIR8Z7s4Ny5SPsTuUP6L67snIdABcPQo7nt/Nf/5weFTKOLGJI3BHmkNHQHm/q X2AQdv/S+xMKMdHVUC/9oTtfgJqY/1A6Q9QjbAQoM/2HW7O36zZFaj2/w4VacIAwQ2fK 6Je2ai5z+hwpIWMHYR67AO0q5WVldqCwjI+lg7MNq3F5VefBrBubH8VHUfOzLbNIUDyx FqonWcVw7nu5Ak0uBpi2o5lDT0P3KlpWtvq3X0uVf99sAT+Cr7SnpaQwUT5kMBjHwfaf kH75fuEMPklatlBopxQ8nBNorOPQ/8UsxmTYzh9QJrmEI24cNah99UNEkOn3kISs3OCf W+9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=/USuNnl9mwNcNv9NTeGgyoPb8svR3DzIOZuO5JOERwY=; b=T0YxVxt4ZXBSjxOxUhahPNc3TF/DJqUFsfqcua6pxixkJ9C084kfFQL7lcjId/2fJ4 oUmFS29V6YQ1C4wbWXHNT9R+DySD+MfqnAMNxwCqdob9aS5tqE6SpORxycllX0ajoiQ3 ji7KSrm9GKzYp9L/wtYEFDatwiWB6fgHxw/0aWIdW6o6ct0HpYf2TzAOcYACh/ikcWay civGf2yhtfA+IRTAyqrStlAOtw2pk3xFlM7qY65lAT/J3qLex855CAgQS4lu4U75AmCv 8sZRl6gIGOkNl7pMVqyZDBOAoE855mBVNBpcHp61d0QzNuJkF0KazFsqgrI1DimvfCsm 6skw== X-Gm-Message-State: APjAAAWcPp+1cVwAPJsr2DeJEoiA8EJenQXoHdtaKp4g67Cl2ryc2t6j 2Mb8YnCsMjaCNy2We1jSX81Zk6ZF X-Google-Smtp-Source: APXvYqx0jpg2shtg3Rw+6TOUTQzlhYQcv0ZuNcAH1B6LPa3w7wVbQh4TtDGaxYdTs3YXmCUMpMB0rg== X-Received: by 2002:adf:90af:: with SMTP id i44mr30057000wri.222.1552552449670; Thu, 14 Mar 2019 01:34:09 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 132sm2167804wmd.30.2019.03.14.01.34.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 14 Mar 2019 01:34:08 -0700 (PDT) From: "Valery Smyslov" To: "'Christian Hopps'" Cc: "'Paul Wouters'" , References: <155231377348.23058.4682503726354987752@ietfa.amsl.com> <01f401d4d8e1$58fcc9f0$0af65dd0$@gmail.com> In-Reply-To: Date: Thu, 14 Mar 2019 11:34:01 +0300 Message-ID: <01c601d4da40$ae0740a0$0a15c1e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHDC2i80LRgGX+akLu0yxdYVb2DCQJ2/jYBALrj5fgCexdAJwMINuEdAkPkK8el1qBHEA== Content-Language: ru Archived-At: Subject: Re: [IPsec] I-D Action: draft-hopps-ipsecme-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 08:34:12 -0000 > > No, all retransmissions of IKE message with the same Message ID must = be binary identical. >=20 > Perhaps we could relax this requirement for this particular message = though. This seems like a simple tightly- > focused semantic change which gets us past the roadblock. No, we cannot. Retransmissions are sent when no response is received. = You don't know whether request=20 or response was lost. If you retransmit packet not equal to original, = then you don't know which packet the responder received - first or second. I guess in your case = you don't care, but in general it's not appropriate. > FWIW, regarding retransmission and message IDs, one thing I considered = was not even using the message ID > at all (e.g., let it be 0) but this seemed too radical as a first = approach. :) >=20 > If there really is no way to work around this, I suppose we just = require retransmissions of CC info reports until > they are ACKd or things are torn down b/c of drops (i.e., normal INFO = exchange). It does feel like we are > adding fragility here that isn=E2=80=99t really needed though. It = makes the functioning of the unidirectional tunnel > depend more heavily on the reverse direction traffic working when that = isn=E2=80=99t actually needed for the tunnel to > operate. Yes, don't break IKE core things. Regards, Valery. > Thanks, > Chris. >=20 >=20 >=20 > > > > Regards, > > Valery. > > > >> Thanks, > >> Chris. > > From nobody Thu Mar 14 01:38:13 2019 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 90F751277DB for ; Thu, 14 Mar 2019 01:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 YFavT5Qg-nQn for ; Thu, 14 Mar 2019 01:38:10 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 404631277C9 for ; Thu, 14 Mar 2019 01:38:10 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id x10so1786486wmg.2 for ; Thu, 14 Mar 2019 01:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=y/iVtH4t42XvBSt09msHKGFS0ZhgcXFVR0PHUs3NAB0=; b=ca06f4iE8xHv95fbOJxY/KkdIsgf/NuIegrGopSZ45l/R3CToIYYlX88td/RVUSoTK QjOgpkV8rwWS3zn9tYHL4NBOZSZklWi0Doesz881AOzUkOjb2ExKzXhBlmTDg/x/ZJ+2 7mc5jIaBnU3IdDmAhhQQB5aV5ZC8rDkSeKiZTe7OUUEPedxJnlbFhhpOoDJe+FL2NJqk cb9BbQSiUmnKlol2Tkt/p6TJzvN4xIZOfhbAthRp6ygk5WGmTokaiy54wNPDqpzBZDTS Tl1yDqNoS0wfzugucBk8omp7PjWermT3witpPx6YsXmePzuRHawFaPMTeu1sAOOYjarn ZJgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=y/iVtH4t42XvBSt09msHKGFS0ZhgcXFVR0PHUs3NAB0=; b=gDLns869bTwTpRri6TXcm0ZCwI11FQs1ldQRdTTYGV637qes7ZacQMyt4MSjDqkIol f4R3Rqp+yOde6mRWXiWzNQWx4gy0AOp3Z3wEBQxixSvjjyd6IeqEkAQPEbEF5rwqPOoe cldEo4+CAmNUOF6IgAtT7dhh3JWYiIp5KMEgIS+J/urrR/suCkGecFALrO9zlwmB/ywZ Cn82vvsD/nVy/Ltrxi5h+Pnz+MDG82IlohBEIa1lP2CAmGQrN+dzFndqqxl9/e8CRSWT wD/+Kxk68yksYGEqSUTNc5rb5+Xj5ocnclU34x5g3GTl7Ae3MC+KLVholr6huLBw4a0W Cn1g== X-Gm-Message-State: APjAAAXtm4Ec6ENIlbsdRNC5W7S5zfBamIajS432CJapEBLChkFGlD0P 0gBxD/d0UzMNSGVlr7sCPZ2n8QZz X-Google-Smtp-Source: APXvYqycBaSfPz/Fvt36Xf8VI6dgevLnwbNfzpCvxgLQRI8ZT/FNn+pRgeS3rYEfdtuAq8CNFJHm1A== X-Received: by 2002:a1c:cc0c:: with SMTP id h12mr1743745wmb.140.1552552688318; Thu, 14 Mar 2019 01:38:08 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id d9sm30426279wrn.72.2019.03.14.01.38.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 14 Mar 2019 01:38:07 -0700 (PDT) From: "Valery Smyslov" To: "'Tero Kivinen'" , References: <23688.31062.426962.985107@fireball.acr.fi> In-Reply-To: <23688.31062.426962.985107@fireball.acr.fi> Date: Thu, 14 Mar 2019 11:38:01 +0300 Message-ID: <01c701d4da41$3c61f890$b525e9b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQICh2VSFjkuY0eSQrYh6iGxPAV2+KWvcutw Content-Language: ru Archived-At: Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 08:38:12 -0000 Hi, as author of the document I (obviously) support its adoption. It's a building block for QSKE solution (at least how the WG sees it now) so I think we should adopt it. Regards, Valery. > This document has been stable for some time, and I think it is ready > to go forward. Because of that I will start one week long WG > adoptation call for this draft which will expire end of next week > (2019-03-22). > > If you have any reasons why this should not be adopted as WG document, > send email to the list as soon as possible. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Mar 14 02:37:49 2019 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 8B2F0128B36 for ; Thu, 14 Mar 2019 02:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 TNqrjyMZJgjY for ; Thu, 14 Mar 2019 02:37:46 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id CC327128701 for ; Thu, 14 Mar 2019 02:37:45 -0700 (PDT) Received: from tops.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPS id 2898360516; Thu, 14 Mar 2019 05:37:45 -0400 (EDT) References: <155231377348.23058.4682503726354987752@ietfa.amsl.com> <01f401d4d8e1$58fcc9f0$0af65dd0$@gmail.com> <01c601d4da40$ae0740a0$0a15c1e0$@gmail.com> User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: Valery Smyslov Cc: 'Christian Hopps' , 'Paul Wouters' , ipsec@ietf.org In-reply-to: <01c601d4da40$ae0740a0$0a15c1e0$@gmail.com> Date: Thu, 14 Mar 2019 05:37:44 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [IPsec] I-D Action: draft-hopps-ipsecme-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 09:37:48 -0000 --=-=-= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Valery Smyslov writes: >> If there really is no way to work around this, I suppose we just require= retransmissions of CC info reports until >> they are ACKd or things are torn down b/c of drops (i.e., normal INFO ex= change). It does feel like we are >> adding fragility here that isn=E2=80=99t really needed though. It makes = the functioning of the unidirectional tunnel >> depend more heavily on the reverse direction traffic working when that i= sn=E2=80=99t actually needed for the tunnel to >> operate. > > Yes, don't break IKE core things. I was hoping there would be an openness to possible improvements, and wasn'= t looking to just break well established protocols. An earlier mail from Pa= ul made it sound like other use-cases have wanted for expanded functionalit= y as well. This isn't a blocker for this work, so if other people agree that it's not = worth trying to improve IKE to support this use case, we can just conform r= ather than try to improve things. Thanks, Chris. > > Regards, > Valery. > >> Thanks, >> Chris. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlyKIOgACgkQLh2DDte4 MCWeLA/+JUM8alFRPijiWIM9hrRaz5AeBszmiJshQiy7On17r3Q64e/DaPjz9thi Yp15QrknY1yI4mfAvpH4jJf7ATApfpB+KqkO7GpxfE4VPgHZsnR9ND8fM/ZK95ys 1fpdyTxjOyduZdxJdnmlT7YW8px7wBQAWl9ygQPQZn2PwIJ+v/imOn5iuHcp95SX pg+d7FAh6QbK3HePDGcdUGkMHZi5EC7ZLhapWAEcIChG9fUGZ8d0sT+n2o9nipbz Nx9XPwe8KVkMFrkuR3RNuK+r+LoY17lSig9OWghYygmFlqUfDP4meDVE2Mj8lJlr ODovyqGG34KM+yLOKtufxx/FG1eUgR71XR2hu0S37ZRJTtkhHnobnjJ6q+BZphel N7S/vn3RegJA/K/yO5jHXv+cvRBwMslnNh5BJbswMarsITABUhvagHrzHD59OlIj XtQx9MzabQEwPZkW8+mlHY88NxxBlGNXg1yRogr0z6/199b0l2WjYvIUSAOkFPNj uY8EehFx7JmIl1iICdl1fdr43oG08A/G8lN5oCJ20t53l5SZqJcD5vTgCvidTWUN JrccA7Pf0CpnXarVVOqD5VfHE56z6YHU2aUZOFLEv1Pcc7IHjFUME9i5xzxdJnqn +abB8HbK/zTpY3vh/dHtT9aEYbSKRCoDl0UG7LO+d8QJ/rDtpME= =9TEs -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 14 12:06:58 2019 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 96A3A130EF2 for ; Thu, 14 Mar 2019 12:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 FsF-ebqOQiq0 for ; Thu, 14 Mar 2019 12:06:55 -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 036A4130EFB for ; Thu, 14 Mar 2019 12:06:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1168; q=dns/txt; s=iport; t=1552590415; x=1553800015; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=mUM6LH0nmxdYAF9cFUkMtWUgkJBVup+l7o/1usM97GU=; b=ds2mhrNyhOen2BJnWkL3qylymSlJOTES9rF+C+PSI/n//JQ1fm8TtSDP u6KYb82Yaacp3Y2viLtX4yOGeJDsnCR6BGv96H1qbbfedZBMJZJra2M+L 1WdYnToLnj2PpI92bT3mpzAxBIjX9yfK5zgHjvaSnOQQYu6x1pemJ7J1W o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAADEpYpc/4oNJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGCD2iBAycKjB2LIoINgzeUeRSBZwsBARgLhEk?= =?us-ascii?q?ChFAiNAkNAQEDAQEJAQMCbRwMhUoBAQEDAQEBGx00EAcEAgEIEQQBAR8QJws?= =?us-ascii?q?dCAIEARIIE4MIgW0ID68Gii4FgS8BiywXgUA/gRGDEoMeAQGBLgESAYYAA6R?= =?us-ascii?q?ACQKTFSGTTIp/kmgCERWBKB84KD1xcBU7gmyLDIU/QTGNegcIF4EIgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.58,479,1544486400"; d="scan'208";a="245082946" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Mar 2019 19:06:54 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x2EJ6rjU016448 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Mar 2019 19:06:54 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 14 Mar 2019 14:06:53 -0500 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1473.003; Thu, 14 Mar 2019 14:06:53 -0500 From: "Panos Kampanakis (pkampana)" To: "'Tero Kivinen'" , "ipsec@ietf.org" Thread-Topic: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02 Thread-Index: AQICh2VSFjkuY0eSQrYh6iGxPAV2+KWvcutwgACwI2A= Date: Thu, 14 Mar 2019 19:06:53 +0000 Message-ID: <6454f07af680410e918431971f3489f2@XCH-ALN-010.cisco.com> References: <23688.31062.426962.985107@fireball.acr.fi> <01c701d4da41$3c61f890$b525e9b0$@gmail.com> In-Reply-To: <01c701d4da41$3c61f890$b525e9b0$@gmail.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.82.182.136] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 19:06:57 -0000 +1 on adopting this draft.=20 -----Original Message----- From: IPsec On Behalf Of Valery Smyslov Sent: Thursday, March 14, 2019 4:38 AM To: 'Tero Kivinen' ; ipsec@ietf.org Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux= -02 Hi, as author of the document I (obviously) support its adoption. It's a building block for QSKE solution (at least how the WG sees it now) s= o I think we should adopt it. Regards, Valery. > This document has been stable for some time, and I think it is ready=20 > to go forward. Because of that I will start one week long WG=20 > adoptation call for this draft which will expire end of next week=20 > (2019-03-22). >=20 > If you have any reasons why this should not be adopted as WG document,=20 > send email to the list as soon as possible. > -- > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Mar 15 08:50:36 2019 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 69E18130E3F for ; Fri, 15 Mar 2019 08:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] 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 WizfYxlFM1CZ for ; Fri, 15 Mar 2019 08:50:31 -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 D0062129BBF for ; Fri, 15 Mar 2019 08:50:30 -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 x2FFoQFA005766 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 15 Mar 2019 17:50:26 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x2FFoQCd020856; Fri, 15 Mar 2019 17:50:26 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23691.51650.284782.490797@fireball.acr.fi> Date: Fri, 15 Mar 2019 17:50:26 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 3 min Archived-At: Subject: [IPsec] IPsecME IETF 104 agenda X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 15:50:34 -0000 We seem to have full agenda for IETF 104 in Prague. I want all who are going to present in the meeting to provide slides before Friday next week (2019-03-22 23:59 UTC). If we do not have have slides then, then we might have more time on agenda, as we can remove some presentations :-) ---------------------------------------------------------------------- IETF 104 IPsecME WG meeting in Prague Thursday, March 28, 2019 10:50-12:20 Karlin 1/2 - Agenda bashing, Logistics -- Chairs (5 min) - Draft status -- Chairs (15 min) - draft-ietf-ipsecme-split-dns - draft-ietf-ipsecme-qr-ikev2 - draft-ietf-ipsecme-implicit-iv - draft-ietf-ipsecme-ipv6-ipv4-codes - Work items - Intermediate Exchange in the IKEv2 Protocol - Valery Smyslov (10 min) - draft-smyslov-ipsecme-ikev2-aux-02 - ESP Header Compression and Diet-ESP - Tobias Guggemos (10 min) - draft-mglt-ipsecme-diet-esp-07 - An implementor's view on Hybrid PQKE in IKEv2 - Tobias Heider (15 min) - Labeled IPsec - Paul Wouters (10 min) - draft-ietf-ipsecme-labeled-ipsec - IKEv1 Graveyard - Paul Wouters (5 min) - draft-pwouters-ikev1-ipsec-graveyard - Other presentations - IP Traffic Flow Security - Christian Hopps (15 min) - draft-hopps-ipsecme-iptfs-00 - PQC for IKEv2 in strongSwan - Leonie Bruckert (5 min) -- kivinen@iki.fi From nobody Fri Mar 15 09:52:09 2019 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 3957912D4EC for ; Fri, 15 Mar 2019 09:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, 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 4HYhpaqfyr11 for ; Fri, 15 Mar 2019 09:52:05 -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 C70D112705F for ; Fri, 15 Mar 2019 09:52:04 -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 x2FGq2uI023322 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 15 Mar 2019 18:52:02 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x2FGq28r001052; Fri, 15 Mar 2019 18:52:02 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23691.55346.597679.896308@fireball.acr.fi> Date: Fri, 15 Mar 2019 18:52:02 +0200 From: Tero Kivinen To: ipsec@ietf.org In-Reply-To: <23691.51650.284782.490797@fireball.acr.fi> References: <23691.51650.284782.490797@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 3 min Archived-At: Subject: [IPsec] IPsecME IETF 104 agenda X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 16:52:08 -0000 Tero Kivinen writes: > We seem to have full agenda for IETF 104 in Prague. And I had forgotten one presentation from the list (hybrid-qske), so now our agenda has too many items. We will be talking to presenters so which ones will be shortened or skipped. > I want all who are going to present in the meeting to provide slides > before Friday next week (2019-03-22 23:59 UTC). If we do not have have > slides then, then we might have more time on agenda, as we can remove > some presentations :-) Sending in your slides early will of course help your odds at staying in the agenda :-) > ---------------------------------------------------------------------- > IETF 104 IPsecME WG meeting in Prague > Thursday, March 28, 2019 > 10:50-12:20 Karlin 1/2 > > - Agenda bashing, Logistics -- Chairs (5 min) > - Draft status -- Chairs (15 min) > - draft-ietf-ipsecme-split-dns > - draft-ietf-ipsecme-qr-ikev2 > - draft-ietf-ipsecme-implicit-iv > - draft-ietf-ipsecme-ipv6-ipv4-codes > - Work items > - Intermediate Exchange in the IKEv2 Protocol - Valery Smyslov (10 min) > - draft-smyslov-ipsecme-ikev2-aux-02 > - ESP Header Compression and Diet-ESP - Tobias Guggemos (10 min) > - draft-mglt-ipsecme-diet-esp-07 > - An implementor's view on Hybrid PQKE in IKEv2 - Tobias Heider (15 min) > - Labeled IPsec - Paul Wouters (10 min) > - draft-ietf-ipsecme-labeled-ipsec > - IKEv1 Graveyard - Paul Wouters (5 min) > - draft-pwouters-ikev1-ipsec-graveyard > - Other presentations > - IP Traffic Flow Security - Christian Hopps (15 min) > - draft-hopps-ipsecme-iptfs-00 > - PQC for IKEv2 in strongSwan - Leonie Bruckert (5 min) > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec -- kivinen@iki.fi From nobody Mon Mar 18 10:02:23 2019 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 E17121311D2 for ; Mon, 18 Mar 2019 10:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGcI92qSV0Pb for ; Mon, 18 Mar 2019 10:02:18 -0700 (PDT) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FE031311A2 for ; Mon, 18 Mar 2019 10:02:14 -0700 (PDT) Received: from DESKTOP58DFL8T (ObiWan2.nm.ifi.lmu.de [141.84.218.130]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: guggemos) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id BD23E35CE91; Mon, 18 Mar 2019 18:02:11 +0100 (CET) From: "Tobias Guggemos" To: "'Tero Kivinen'" , References: <23688.31062.426962.985107@fireball.acr.fi> <01c701d4da41$3c61f890$b525e9b0$@gmail.com> <6454f07af680410e918431971f3489f2@XCH-ALN-010.cisco.com> In-Reply-To: <6454f07af680410e918431971f3489f2@XCH-ALN-010.cisco.com> Date: Mon, 18 Mar 2019 18:02:12 +0100 Message-ID: <001e01d4ddac$5502d770$ff088650$@nm.ifi.lmu.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHU2U0s6M7rbXuBv0SBwRv3SEEfn6YKvxmAgACvtICABiKNQA== Content-Language: de Archived-At: Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 17:02:22 -0000 Hey all, we have implemented the draft and found a few issues. Overall, the separation of IKE_INTERMEDIATE and the draft-tjhai-ipsecme-hybrid-qske-ikev2-03 is not clear in some points.=20 I personally like the idea of having a document on how to add a = "pre-auth" exchange to IKEv2, however we=92ve found that the two documents depend = quite strongly on each other, which we found a bit of an implementation issue: 1. The draft does not say anything about payloads to be carried in the IKE_INTERMEDIATE message (except SK payload), which means it could = either transfer "any payload" or "no payload".=20 >From a security perspective, I'd assume "no payload", which means the = draft specifies how to send an empty SK payload between IKE_INIT and IKE_AUTH, where "empty" means encrypted padding. So basically, we have a (standard-track RFC) document describing a = message which cannot (I'd almost say MUST NOT) be implemented without the requirement to implement an additional document describing the payload.=20 2. On the other hand, IKE_INTERMEDIATE describes how to use previously exchanged keys in order to secure (encrypt) the IKE_INTERMEDIATE = traffic.=20 If IKE_INTERMEDIATE is there to describe the messages and not the key exchange, I think the document should only say that the current key in = the IKE SA should be used. I'm not 100% sure if especially point 1 is an actual issue for an IETF document and if so how to solve it. One idea would be to define a (maybe informational/experimental) = document like "how to add an additional pre-auth exchange in IKEv2", which can = then be used by e.g. draft-tjhai-ipsecme-hybrid-qske-ikev2-03 to define the actual exchange. Another idea would be to define a list of allowed payloads (e.g. by IANA registry). If the WG thinks that this is not an issue or can be solved after = adoption, we support adoption and we were about to show and discuss some details = on that (and other PQKE related stuff) in a presentation in Prague. We just wanted to raise awareness and get a discussion on this = (potential) issue before the adoption call ends. Regards Tobias > -----Urspr=FCngliche Nachricht----- > Von: IPsec Im Auftrag von Panos Kampanakis > (pkampana) > Gesendet: Donnerstag, 14. M=E4rz 2019 20:07 > An: 'Tero Kivinen' ; ipsec@ietf.org > Betreff: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux- > 02 >=20 > +1 on adopting this draft. >=20 > -----Original Message----- > From: IPsec On Behalf Of Valery Smyslov > Sent: Thursday, March 14, 2019 4:38 AM > To: 'Tero Kivinen' ; ipsec@ietf.org > Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux- > 02 >=20 > Hi, >=20 > as author of the document I (obviously) support its adoption. > It's a building block for QSKE solution (at least how the WG sees it = now) so I > think we should adopt it. >=20 > Regards, > Valery. >=20 > > This document has been stable for some time, and I think it is ready > > to go forward. Because of that I will start one week long WG > > adoptation call for this draft which will expire end of next week > > (2019-03-22). > > > > If you have any reasons why this should not be adopted as WG = document, > > send email to the list as soon as possible. > > -- > > kivinen@iki.fi > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Mar 18 10:08:40 2019 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 E6900131135 for ; Mon, 18 Mar 2019 10:08: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, MIME_QP_LONG_LINE=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 MdtEPToe5T5w for ; Mon, 18 Mar 2019 10:08:35 -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 181FA131128 for ; Mon, 18 Mar 2019 10:08:35 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44NN1X11MQzDct; Mon, 18 Mar 2019 18:08:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1552928912; bh=4E+XDVPF0g+0FzEGFNA2MhXljTyTuneI2AZzSrO5FXE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=cZ0iuhdpYi7zYQnXXNod5LVDAGz2vi3Kxaj//QPbXfoAH1grIPH+WcV9aJBI+N905 px62om7X/prOzo7GxLB3l0g2Hgpw5p6Lws5OQxYIP/KQ73Teq+Ih3BE+xi8K+HXYzG rToLqxe6/QBdCpwc7VNjTuuAzBP4vSdHa5M2eTy0= 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 pCIpkM4NhJRm; Mon, 18 Mar 2019 18:08:28 +0100 (CET) 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; Mon, 18 Mar 2019 18:08:27 +0100 (CET) Received: from [10.0.3.59] (unknown [62.168.35.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id DE86B2FCD9; Mon, 18 Mar 2019 13:08:26 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca DE86B2FCD9 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16D57) In-Reply-To: <001e01d4ddac$5502d770$ff088650$@nm.ifi.lmu.de> Date: Mon, 18 Mar 2019 18:08:20 +0100 Cc: Tero Kivinen , ipsec@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5EA6ED83-4654-4A49-B429-D0661791EEBD@nohats.ca> References: <23688.31062.426962.985107@fireball.acr.fi> <01c701d4da41$3c61f890$b525e9b0$@gmail.com> <6454f07af680410e918431971f3489f2@XCH-ALN-010.cisco.com> <001e01d4ddac$5502d770$ff088650$@nm.ifi.lmu.de> To: Tobias Guggemos Archived-At: Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 17:08:39 -0000 Tobias races good points to address, but that can be discussed after adoptio= n too. I=E2=80=99m in favour of adoption and I would like all ambiguity to be resol= ved so that this document can be implemented independently from any other fu= ture documents. Paul Sent from mobile device > On Mar 18, 2019, at 18:02, Tobias Guggemos wrote:= >=20 > Hey all, > we have implemented the draft and found a few issues. > Overall, the separation of IKE_INTERMEDIATE and the > draft-tjhai-ipsecme-hybrid-qske-ikev2-03 is not clear in some points.=20 >=20 > I personally like the idea of having a document on how to add a "pre-auth"= > exchange to IKEv2, however we=E2=80=99ve found that the two documents depe= nd quite > strongly on each other, which we found a bit of an implementation issue: >=20 > 1. The draft does not say anything about payloads to be carried in the > IKE_INTERMEDIATE message (except SK payload), which means it could either > transfer "any payload" or "no payload".=20 >> =46rom a security perspective, I'd assume "no payload", which means the d= raft > specifies how to send an empty SK payload between IKE_INIT and IKE_AUTH, > where "empty" means encrypted padding. > So basically, we have a (standard-track RFC) document describing a message= > which cannot (I'd almost say MUST NOT) be implemented without the > requirement to implement an additional document describing the payload.=20= >=20 > 2. On the other hand, IKE_INTERMEDIATE describes how to use previously > exchanged keys in order to secure (encrypt) the IKE_INTERMEDIATE traffic.=20= > If IKE_INTERMEDIATE is there to describe the messages and not the key > exchange, I think the document should only say that the current key in the= > IKE SA should be used. >=20 > I'm not 100% sure if especially point 1 is an actual issue for an IETF > document and if so how to solve it. > One idea would be to define a (maybe informational/experimental) document > like "how to add an additional pre-auth exchange in IKEv2", which can then= > be used by e.g. draft-tjhai-ipsecme-hybrid-qske-ikev2-03 to define the > actual exchange. > Another idea would be to define a list of allowed payloads (e.g. by IANA > registry). >=20 > If the WG thinks that this is not an issue or can be solved after adoption= , > we support adoption and we were about to show and discuss some details on > that (and other PQKE related stuff) in a presentation in Prague. > We just wanted to raise awareness and get a discussion on this (potential)= > issue before the adoption call ends. >=20 > Regards > Tobias >=20 >> -----Urspr=C3=BCngliche Nachricht----- >> Von: IPsec Im Auftrag von Panos Kampanakis >> (pkampana) >> Gesendet: Donnerstag, 14. M=C3=A4rz 2019 20:07 >> An: 'Tero Kivinen' ; ipsec@ietf.org >> Betreff: Re: [IPsec] WG adoptation call for > draft-smyslov-ipsecme-ikev2-aux- >> 02 >>=20 >> +1 on adopting this draft. >>=20 >> -----Original Message----- >> From: IPsec On Behalf Of Valery Smyslov >> Sent: Thursday, March 14, 2019 4:38 AM >> To: 'Tero Kivinen' ; ipsec@ietf.org >> Subject: Re: [IPsec] WG adoptation call for > draft-smyslov-ipsecme-ikev2-aux- >> 02 >>=20 >> Hi, >>=20 >> as author of the document I (obviously) support its adoption. >> It's a building block for QSKE solution (at least how the WG sees it now)= > so I >> think we should adopt it. >>=20 >> Regards, >> Valery. >>=20 >>> This document has been stable for some time, and I think it is ready >>> to go forward. Because of that I will start one week long WG >>> adoptation call for this draft which will expire end of next week >>> (2019-03-22). >>>=20 >>> If you have any reasons why this should not be adopted as WG document, >>> send email to the list as soon as possible. >>> -- >>> kivinen@iki.fi >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Mar 18 13:00:40 2019 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 7FCAF127987 for ; Mon, 18 Mar 2019 13:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbst81-OZpHR for ; Mon, 18 Mar 2019 13:00:35 -0700 (PDT) Received: from FRA01-PR2-obe.outbound.protection.outlook.com (mail-eopbgr120107.outbound.protection.outlook.com [40.107.12.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77DCB12798C for ; Mon, 18 Mar 2019 13:00:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dcmCpyFAqebivW57XjN1Wrw9PW5n7sU1mrPzGvLlNtE=; b=CziH7qzASS5XeGJ1POrCk5UIW7G5X4WB69RGKxZS6wjVriN96UYaPqTGUndVRIwVdAa3c3GE9PHAS84Wjy71Q1nU6P03Hv12UcwA9Kj9KiPse0GGJRJwnm2Dx93s4WN+iOCSnBK2gkhQtmrRlmkTGBDcG1T00g+Zm7Kp+uufBvo= Received: from PR1PR07MB5755.eurprd07.prod.outlook.com (20.177.210.161) by PR1PR07MB4843.eurprd07.prod.outlook.com (20.177.208.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.16; Mon, 18 Mar 2019 20:00:33 +0000 Received: from PR1PR07MB5755.eurprd07.prod.outlook.com ([fe80::293b:c200:5556:d61e]) by PR1PR07MB5755.eurprd07.prod.outlook.com ([fe80::293b:c200:5556:d61e%4]) with mapi id 15.20.1709.015; Mon, 18 Mar 2019 20:00:33 +0000 From: "Hu, Jun (Nokia - US/Mountain View)" To: Paul Wouters , "ipsec@ietf.org WG" Thread-Topic: [IPsec] Fwd: New Version Notification for draft-pwouters-ikev1-ipsec-graveyard-00.txt Thread-Index: AQHU2DnDFP/VL92Ugk+vi6Ibhaw3tqYR2DgA Date: Mon, 18 Mar 2019 20:00:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.245.20.6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 166a7a28-2ab7-4877-cd45-08d6abdc6130 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:PR1PR07MB4843; x-ms-traffictypediagnostic: PR1PR07MB4843: x-ms-exchange-purlcount: 5 authentication-results: spf=none (sender IP is ) smtp.mailfrom=jun.hu@nokia.com; x-microsoft-antispam-prvs: x-forefront-prvs: 098076C36C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(366004)(346002)(376002)(136003)(199004)(22974007)(13464003)(189003)(11346002)(6306002)(55016002)(66574012)(966005)(186003)(76176011)(446003)(9686003)(478600001)(86362001)(81166006)(6436002)(8936002)(66066001)(476003)(53546011)(6506007)(26005)(68736007)(7696005)(486006)(53936002)(33656002)(105586002)(106356001)(2906002)(6246003)(102836004)(256004)(15650500001)(7736002)(74316002)(71200400001)(71190400001)(6116002)(14444005)(52536014)(3846002)(305945005)(229853002)(5660300002)(316002)(14454004)(110136005)(81156014)(25786009)(8676002)(97736004)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:PR1PR07MB4843; H:PR1PR07MB5755.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: e9vZk3tLg+Zt6J9UGbPW999GD+HS3XfEAuFD/bY7DjGPlorUdn8pKM7gDYcZpCtsLqF8DW6Y9kKcR6NNzoUY63mbwyALtPDHMqttTyKW3y2OWDnxQP72QSBnjDboD4xAqQkunUZf9P/zmZ3TlOPVJG9PS+DjNksT5QVha6SgFq2xRX0qXUCBwGbaTQWl06RqiSHrUBfSumTLPg3H/T7eYRGZiRqWN97WfTvrVsBPdVixoFnldjX12wQvQhQ4GQPX6iswC/gtIb8I4K5c+WQMppbe5Qq1bH+7VZbgrtdTh7lPyEVdBPWyc9vJM8OrOvmbDn4j2Z7fSX3uPbvq+voZz3Bs6WhbtFkiWdI3Qa/gAiuCSFyGmPFqu+mSNZwZkiGrvcjppQ+XXJCTpBPYY4NiuyfCtCwq0NE5HSNUFIpwxbc= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 166a7a28-2ab7-4877-cd45-08d6abdc6130 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2019 20:00:32.9755 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR1PR07MB4843 Archived-At: Subject: Re: [IPsec] Fwd: New Version Notification for draft-pwouters-ikev1-ipsec-graveyard-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 20:00:39 -0000 VGhlIGVhcmxpZXIgd2UgZ2V0IHJpZCBvZiBJS0V2MSwgdGhlIGJldHRlcg0KSnVzdCBvbmUgY29t bWVudCwgcmVnYXJkaW5nICJJS0V2MiBoYXMgbm93IHNlZW4gd2lkZSBkZXBsb3ltZW50IGFuZCBw cm92aWRlcyBhIGZ1bGwgcmVwbGFjZW1lbnQgZm9yIGFsbCBJS0V2MSBmdW5jdGlvbmFsaXR5LiIg LCBJIHRoaW5rIHRoZXJlIGlzIG9uZSBmZWF0dXJlIElLRXYyIGhhc24ndCBwcm92aWRlZCBlcXVp dmFsZW50IHlldCBpcyBncm91cCBrZXkgbWFuYWdlbWVudC4gT2YgY291cnNlLCBJIGRvbid0IHRo aW5rIGl0IGlzIGEgc2hvdyBzdG9wcGVyLCBqdXN0IHRoZXJlIHNob3VsZCBiZSBzb21lIGNsYXJp ZmljYXRpb24gb24gdGhpcyANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElQ c2VjIDxpcHNlYy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgUGF1bCBXb3V0ZXJzDQpT ZW50OiBNb25kYXksIE1hcmNoIDExLCAyMDE5IDExOjM5IEFNDQpUbzogaXBzZWNAaWV0Zi5vcmcg V0cgPGlwc2VjQGlldGYub3JnPg0KU3ViamVjdDogW0lQc2VjXSBGd2Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtcHdvdXRlcnMtaWtldjEtaXBzZWMtZ3JhdmV5YXJkLTAwLnR4 dA0KDQoNCkFzIHdlIGRpc2N1c3NlZCBvbiB0aGUgbGlzdCBhbmQgaW4gQmFuZ2tvaywgd2Ugd2Vy ZSBnb2luZyB0byBzdWJtaXQgYSBkb2N1bWVudCB0byBkZXByZWNyYXRlIElLRXYxIGFuZCB2YXJp b3VzIG9sZCBza29vbCBhbGdvcml0aG1zIHVzaW5nIGEgW0RFUFJFQ0FURURdIGNvbHVtbiBpbiB0 aGUgSUFOQSByZWdpc3RyeS4NCg0KSSB3cm90ZSBhIGZpcnN0IGRyYWZ0IHRvIGRvIHRoaXMuLi4N Cg0KUGF1bA0KDQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLQ0KRnJvbTog PGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCkRhdGU6IE1vbiwgTWFyIDExLCAyMDE5IGF0IDI6 MzUgUE0NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcHdvdXRl cnMtaWtldjEtaXBzZWMtZ3JhdmV5YXJkLTAwLnR4dA0KVG86IFBhdWwgV291dGVycyA8cHdvdXRl cnNAcmVkaGF0LmNvbT4NCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1wd291dGVy cy1pa2V2MS1pcHNlYy1ncmF2ZXlhcmQtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IFBhdWwgV291dGVycyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnku DQoNCk5hbWU6wqAgwqAgwqAgwqAgwqAgwqBkcmFmdC1wd291dGVycy1pa2V2MS1pcHNlYy1ncmF2 ZXlhcmQNClJldmlzaW9uOsKgIMKgIMKgIMKgMDANClRpdGxlOsKgIMKgIMKgIMKgIMKgIERlcHJl Y2F0aW9uIG9mIElLRXYxIGFuZCBvYnNvbGV0ZWQgYWxnb3JpdGhtcyBEb2N1bWVudCBkYXRlOsKg IDIwMTktMDMtMTENCkdyb3VwOsKgIMKgIMKgIMKgIMKgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0K UGFnZXM6wqAgwqAgwqAgwqAgwqAgNg0KVVJMOsKgIMKgIMKgIMKgIMKgIMKgIGh0dHBzOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1wd291dGVycy1pa2V2MS1pcHNlYy1ncmF2 ZXlhcmQtMDAudHh0DQpTdGF0dXM6wqAgwqAgwqAgwqAgwqBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1wd291dGVycy1pa2V2MS1pcHNlYy1ncmF2ZXlhcmQvDQpIdG1saXpl ZDrCoCDCoCDCoCDCoGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wd291dGVycy1p a2V2MS1pcHNlYy1ncmF2ZXlhcmQtMDANCkh0bWxpemVkOsKgIMKgIMKgIMKgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1wd291dGVycy1pa2V2MS1pcHNlYy1ncmF2 ZXlhcmQNCg0KDQpBYnN0cmFjdDoNCsKgIMKgVGhpcyBkb2N1bWVudCBkZXByZWNhdGVzIEludGVy bmV0IEtleSBFeGNoYW5nZSB2ZXJzaW9uIDEgKElLRXYxKSBhbmQNCsKgIMKgYWRkaXRpb25hbGx5 IGRlcHJlY2F0ZXMgYSBudW1iZXIgb2YgYWxnb3JpdGhtcyB0aGF0IGFyZSBvYnNvbGV0ZS4NCg0K DQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRh cmlhdA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpJUHNlYyBtYWlsaW5nIGxpc3QNCklQc2VjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjDQo= From nobody Tue Mar 19 01:30:26 2019 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 6268C1274A1 for ; Tue, 19 Mar 2019 01:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 iAR8wJqyjq1Z for ; Tue, 19 Mar 2019 01:30:22 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86BA01311F6 for ; Tue, 19 Mar 2019 01:30:21 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id y18so13767886lfe.1 for ; Tue, 19 Mar 2019 01:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=Bs5g+WmtCOA8xXRggF7qiYu/e7F5nFqPWCeMWqYxQOE=; b=Z10x1y94c13uydBBN3gniH9ZJfvUO4u9LvOPpGoLkbHKbcN32Og/J9mfFqfFgqjzeR sZ46uVs5nn1nBx3hLJdBUjaBdZ2QNV23ZMUvIJa380e9sGTcU++Rx7mGoxDzwePOOh0N 8wGEC8yG7s3SJfpIARimrnqqlLWkPVcMEBgV37MlQDLMLjQ4YwHO07Wfrioq43z9XaTz 0xolw7ofw5xrqi4B3owT7NoZCE6MCdMuXYVN1M/lWgvU69rhagfQjiCKbXrnZpFEt7fh Dsk5JkdWmYg0RUUke8wsgnVhxA6M9sUp9bhYrsFImG+ZqOJ6ur/qrcyxhVCSYusai5+Y ByMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Bs5g+WmtCOA8xXRggF7qiYu/e7F5nFqPWCeMWqYxQOE=; b=PZs0R8rcN69Fcm8RcL8OJgh4uXVN4OtbW8AirYhcsembE0Gw5tugxR7Zjasnc5HcY1 MiMFFdUX7fx7iPx4VQinmtHKV8vlt971VYLHxyzxXN0HvF13ciL+sJOxjpKakZ3si1aQ iiukeWqKFE8HfwSF41ITDnvFq0iV8NHu+CaxP3Ai41MIKQhwSiBlzz9ces1SAbKkZKf4 PDZ+bZzPjUkmadHvTx2GnK+vTEG+l8gYQcSwXV8/h9ObXK63kGH1mwrR8MoHciR0NuEJ xOXuNhumZvKL8ROuaispb5qYjlLHReCrSLMR3mEr7NVldHaquDtaZF7ti7+ZRP0s8l/I evXQ== X-Gm-Message-State: APjAAAUVWhmtC+gn9ySOar54N6FDj4fBmWoyvXBpOrYYJ/YaxIardOlE wsKazEJAFB64E4JM3xhBP1U= X-Google-Smtp-Source: APXvYqy27Tgx9TVC8Fyv8ho0FIm/d7qZMHb1Go13L5yVgk/w7lMMoHaiKOmlmyikpHc+EJj5MFPvxg== X-Received: by 2002:a19:aacc:: with SMTP id t195mr12251424lfe.153.1552984219696; Tue, 19 Mar 2019 01:30:19 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id f22sm2851154ljk.18.2019.03.19.01.30.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Mar 2019 01:30:18 -0700 (PDT) From: "Valery Smyslov" To: "'Tobias Guggemos'" , "'Tero Kivinen'" , References: <23688.31062.426962.985107@fireball.acr.fi> <01c701d4da41$3c61f890$b525e9b0$@gmail.com> <6454f07af680410e918431971f3489f2@XCH-ALN-010.cisco.com> <001e01d4ddac$5502d770$ff088650$@nm.ifi.lmu.de> In-Reply-To: <001e01d4ddac$5502d770$ff088650$@nm.ifi.lmu.de> Date: Tue, 19 Mar 2019 11:30:15 +0300 Message-ID: <059301d4de2d$faa5a000$eff0e000$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQICh2VSFjkuY0eSQrYh6iGxPAV2+AHuWDWOAmpINo8CGcLbUKWDmyEA Content-Language: ru Archived-At: Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 08:30:24 -0000 Hi Tobias, > Hey all, > we have implemented the draft and found a few issues. Glad to know. We can do an interoperability testing, I guess :-) > Overall, the separation of IKE_INTERMEDIATE and the > draft-tjhai-ipsecme-hybrid-qske-ikev2-03 is not clear in some points. >=20 > I personally like the idea of having a document on how to add a = "pre-auth" > exchange to IKEv2, however we=92ve found that the two documents depend = quite > strongly on each other, which we found a bit of an implementation = issue: The idea is that hybrid-qske document depends on ikev2-aux document and = not vice versa. If this failed in your opinion, that must be fixed. > 1. The draft does not say anything about payloads to be carried in the > IKE_INTERMEDIATE message (except SK payload), which means it could = either > transfer "any payload" or "no payload". True. > >From a security perspective, I'd assume "no payload", which means the = draft > specifies how to send an empty SK payload between IKE_INIT and = IKE_AUTH, > where "empty" means encrypted padding. You are right that the draft doesn't imply any requirements on the = content of=20 SK payloads, so sending empty SK payload is allowed. This is OK, since, = e.g. the response to some payload in request message can be empty (just to = complete exchange).=20 > So basically, we have a (standard-track RFC) document describing a = message > which cannot (I'd almost say MUST NOT) be implemented without the > requirement to implement an additional document describing the = payload. Yes. And the draft explicitly says: The content of the INTERMEDIATE exchange messages depends on the data being transferred and will be defined by specifications utilizing this exchange. Should I add some normative language here to make this even more = explicit? For example: The content of the INTERMEDIATE exchange messages depends on the data being transferred and MUST be defined by specifications utilizing this exchange. Note, that it's a common case with any framework documents - the draft describes only very basic things that must not depend on the content of = the SK payload -=20 how to negotiate INTERMEDIATE exchanges, how to authenticate them,=20 how to handle errors etc. You can implement this draft alone, but it's=20 useless per its own. > 2. On the other hand, IKE_INTERMEDIATE describes how to use previously > exchanged keys in order to secure (encrypt) the IKE_INTERMEDIATE = traffic. > If IKE_INTERMEDIATE is there to describe the messages and not the key > exchange, I think the document should only say that the current key in = the > IKE SA should be used. Sorry, but in my reading the draft currently says exactly this: The keys SK_e[i/r] and SK_a[i/r] for the Encrypted payload in the INTERMEDIATE exchanges are computed in a standard fashion, as defined in the Section 2.14 of [RFC7296]. Every subsequent INTERMEDIATE exchange uses the most recently calculated keys before this exchange is started. The first INTERMEDIATE exchange always uses SK_e[i/r] and SK_a[i/r] keys that were computed as result the IKE_SA_INIT exchange. If this INTERMEDIATE exchange performs additional key exchange resulting in the update of SK_e[i/r] and SK_a[i/r], then these updated keys are used for encryption and authentication of next INTERMEDIATE exchange, otherwise the current keys are used, and so on. In my reading this text says exactly what you want it to say. It doesn't give any hints how the keys are calculated - it says: "use most recently calculated keys". So, if keys are not recalculated after each INTERMEDIATE exchange, then SK_* from IKE_SA_INIT are always used, otherwise the result of recalculation is used. How do you think the text can be improved to make this more clear? > I'm not 100% sure if especially point 1 is an actual issue for an IETF > document and if so how to solve it. > One idea would be to define a (maybe informational/experimental) = document > like "how to add an additional pre-auth exchange in IKEv2", which can = then > be used by e.g. draft-tjhai-ipsecme-hybrid-qske-ikev2-03 to define the > actual exchange. Standards Track RFC generally cannot have Normative reference to lower grade RFCs, like Informational or Experimental (there are = exceptions,=20 but it's a generic rule). So I think that INTERMEDIATE document must be = Standards Track. > Another idea would be to define a list of allowed payloads (e.g. by = IANA > registry). I'd rather to avoid this, as new payloads may appear in future. > If the WG thinks that this is not an issue or can be solved after = adoption, > we support adoption and we were about to show and discuss some details = on > that (and other PQKE related stuff) in a presentation in Prague. > We just wanted to raise awareness and get a discussion on this = (potential) > issue before the adoption call ends. Thank you, Valery. >=20 > Regards > Tobias >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: IPsec Im Auftrag von Panos Kampanakis > > (pkampana) > > Gesendet: Donnerstag, 14. M=E4rz 2019 20:07 > > An: 'Tero Kivinen' ; ipsec@ietf.org > > Betreff: Re: [IPsec] WG adoptation call for > draft-smyslov-ipsecme-ikev2-aux- > > 02 > > > > +1 on adopting this draft. > > > > -----Original Message----- > > From: IPsec On Behalf Of Valery Smyslov > > Sent: Thursday, March 14, 2019 4:38 AM > > To: 'Tero Kivinen' ; ipsec@ietf.org > > Subject: Re: [IPsec] WG adoptation call for > draft-smyslov-ipsecme-ikev2-aux- > > 02 > > > > Hi, > > > > as author of the document I (obviously) support its adoption. > > It's a building block for QSKE solution (at least how the WG sees it = now) > so I > > think we should adopt it. > > > > Regards, > > Valery. > > > > > This document has been stable for some time, and I think it is = ready > > > to go forward. Because of that I will start one week long WG > > > adoptation call for this draft which will expire end of next week > > > (2019-03-22). > > > > > > If you have any reasons why this should not be adopted as WG = document, > > > send email to the list as soon as possible. > > > -- > > > kivinen@iki.fi > > > > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Mar 19 01:34:29 2019 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 67A1313121C for ; Tue, 19 Mar 2019 01:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 aYmqIbVnCk5H for ; Tue, 19 Mar 2019 01:34:14 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30056131217 for ; Tue, 19 Mar 2019 01:34:14 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id t13so16518304lji.2 for ; Tue, 19 Mar 2019 01:34:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=Ak55LnbhaDp4mEyGWBCajzIsxethZdy5iVclGgNH2lE=; b=QcpUvJe9cWu3OR6HifRNW62xjuIBfIBj7EJ9t+UbvTy8mT+kKHf9IIQKUxV4Ayg5g8 8rdgux/AtVLCohKq7XmeWnRs5tQHyN2OCCuax6Dnsqa3fw9bWqfrUyOmdNnU8F1aQ27n 9iANGs62YUW6OUM1jKHD/OvRLmsXXGedfLP4M0FUd+WZxRGYiBmNpkEMFT6zFwB+aC18 IFDlIYzL968zyTfKmBZkjoKQJLIRG/yIQa0xHp7V2GlW3bWS9DPUrlkswoyP+GYjEwMi jnRbZsQwiXwJlI/LG63mq78ou3oVCC/2Eh5YryBv5WMv4B/vSTm4rBjFbKGwDfRUSnKi EoUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Ak55LnbhaDp4mEyGWBCajzIsxethZdy5iVclGgNH2lE=; b=UdiZa9lwfMCO8S/KSoVqhiscuBMNPjsK0kZqHnB/AHL/eMiiJcz3VPHBzh95yvOMdk 4h2UhAO5R42yl8qjA4M5p/Vd2aIN8GUt5om3Eip4003iII0QS9PO/zY0AtN8TnY7xICR zd1/w6ashvxIWFneqgqUYb2W+kUVr50WcxsEqXFIW2mYJMhcX49qXS//hRY3axgPZgQO +IwdOB+KVNVPdkbKyxpaoEhJnBRPzigvYwtpE1C/UbR/i9l9Q63e3ByxHkKDttZhCwFX Drz8HgbQT5FLH38vLQyWEuZZR5GW+MZItZdJXopKpSOz9/0KYMqj4fHFS07arWpYLuG7 joaw== X-Gm-Message-State: APjAAAWdqCYusd38PShBbKzSgoqSdl9Hm6y3TqR9Qf/LzM+3wfg3k/2s 3Lu2jDOTU5SFp7AtxnXu+g9DSjlz X-Google-Smtp-Source: APXvYqwEu/ZcdtTeQuyys5/VlHCxfj5iuuoGCcIMri5XPiBTDlBQdepc9Fr2pF33FQEDjSwTYAjslA== X-Received: by 2002:a2e:5056:: with SMTP id v22mr8084954ljd.153.1552984452142; Tue, 19 Mar 2019 01:34:12 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id v8sm2669131lji.51.2019.03.19.01.34.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Mar 2019 01:34:11 -0700 (PDT) From: "Valery Smyslov" To: "'Hu, Jun \(Nokia - US/Mountain View\)'" , "'Paul Wouters'" , References: In-Reply-To: Date: Tue, 19 Mar 2019 11:34:07 +0300 Message-ID: <059401d4de2e$850e8450$8f2b8cf0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGpSKaxGggsm5/DE3eEa9CXz2744wLKvKqYplNWAUA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Fwd: New Version Notification for draft-pwouters-ikev1-ipsec-graveyard-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 08:34:28 -0000 Hi Jun, > The earlier we get rid of IKEv1, the better > Just one comment, regarding "IKEv2 has now seen wide deployment and provides a full replacement for all > IKEv1 functionality." , I think there is one feature IKEv2 hasn't provided equivalent yet is group key > management. Of course, I don't think it is a show stopper, just there should be some clarification on this The Group Key Management for IKEv2 is on the new ipsecme charter and there is even a candidate document for it: draft-yeung-g-ikev2. Regards, Valery. > -----Original Message----- > From: IPsec On Behalf Of Paul Wouters > Sent: Monday, March 11, 2019 11:39 AM > To: ipsec@ietf.org WG > Subject: [IPsec] Fwd: New Version Notification for draft-pwouters-ikev1-ipsec-graveyard-00.txt > > > As we discussed on the list and in Bangkok, we were going to submit a document to deprecrate IKEv1 and > various old skool algorithms using a [DEPRECATED] column in the IANA registry. > > I wrote a first draft to do this... > > Paul > > ---------- Forwarded message --------- > From: > Date: Mon, Mar 11, 2019 at 2:35 PM > Subject: New Version Notification for draft-pwouters-ikev1-ipsec-graveyard-00.txt > To: Paul Wouters > > > > A new version of I-D, draft-pwouters-ikev1-ipsec-graveyard-00.txt > has been successfully submitted by Paul Wouters and posted to the IETF repository. > > Name: draft-pwouters-ikev1-ipsec-graveyard > Revision: 00 > Title: Deprecation of IKEv1 and obsoleted algorithms Document date: 2019-03-11 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft-pwouters-ikev1-ipsec-graveyard-00.txt > Status: https://datatracker.ietf.org/doc/draft-pwouters-ikev1-ipsec-graveyard/ > Htmlized: https://tools.ietf.org/html/draft-pwouters-ikev1-ipsec-graveyard-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-pwouters-ikev1-ipsec-graveyard > > > Abstract: > This document deprecates Internet Key Exchange version 1 (IKEv1) and > additionally deprecates a number of algorithms that are obsolete. > > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and > diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Mar 19 10:28:59 2019 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 E023B131562 for ; Tue, 19 Mar 2019 10:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jznyKFgG_Zsu for ; Tue, 19 Mar 2019 10:28:51 -0700 (PDT) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEF58128B36 for ; Tue, 19 Mar 2019 10:28:42 -0700 (PDT) Received: from DESKTOP58DFL8T (ObiWan2.nm.ifi.lmu.de [141.84.218.130]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: guggemos) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id A68273600C4; Tue, 19 Mar 2019 18:28:40 +0100 (CET) From: "Tobias Guggemos" To: "'Valery Smyslov'" , "'Tero Kivinen'" , References: <23688.31062.426962.985107@fireball.acr.fi> <01c701d4da41$3c61f890$b525e9b0$@gmail.com> <6454f07af680410e918431971f3489f2@XCH-ALN-010.cisco.com> <001e01d4ddac$5502d770$ff088650$@nm.ifi.lmu.de> <059301d4de2d$faa5a000$eff0e000$@gmail.com> In-Reply-To: <059301d4de2d$faa5a000$eff0e000$@gmail.com> Date: Tue, 19 Mar 2019 18:28:40 +0100 MIME-Version: 1.0 Message-ID: <000a01d4de79$31d3cc00$957b6400$@nm.ifi.lmu.de> X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHU2U0s6M7rbXuBv0SBwRv3SEEfn6YKvxmAgACvtICABiKNQIABBzyAgABckXA= Content-Language: de Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha256; boundary="=-=24Cjxmfapt+igW=-=" Archived-At: Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 17:28:58 -0000 This is a multipart message in MIME format. --=-=24Cjxmfapt+igW=-= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >=20 > Hi Tobias, >=20 > > Hey all, > > we have implemented the draft and found a few issues. >=20 > Glad to know. We can do an interoperability testing, I guess :-) Would be great :-) >=20 > > Overall, the separation of IKE_INTERMEDIATE and the > > draft-tjhai-ipsecme-hybrid-qske-ikev2-03 is not clear in some points. > > > > I personally like the idea of having a document on how to add a "pre-au= th" > > exchange to IKEv2, however we=E2=80=99ve found that the two documents d= epend > > quite strongly on each other, which we found a bit of an implementation > issue: >=20 > The idea is that hybrid-qske document depends on ikev2-aux document and > not vice versa. > If this failed in your opinion, that must be fixed. My opinion is, that IKE_INTERMEDIATE should not mention PQKE at all, if it = is meant to be a framework document which is "just" there to define the mes= sage. I know that the main motivation for IKE_INTERMEDIATE is PQKE, but I don't f= eel that we're at a point where we can actually say for sure that this is t= he one and only way for PQKE and, thus, I'd prefer IKE_INTERMEDIATE to be c= ompletely independent of any Key Exchange related stuff! >=20 > > 1. The draft does not say anything about payloads to be carried in the > > IKE_INTERMEDIATE message (except SK payload), which means it could > > either transfer "any payload" or "no payload". >=20 > True. >=20 > > >From a security perspective, I'd assume "no payload", which means the > > >draft > > specifies how to send an empty SK payload between IKE_INIT and > > IKE_AUTH, where "empty" means encrypted padding. >=20 > You are right that the draft doesn't imply any requirements on the conten= t of > SK payloads, so sending empty SK payload is allowed. This is OK, since, e= .g. > the response to some payload in request message can be empty (just to > complete exchange). >=20 > > So basically, we have a (standard-track RFC) document describing a > > message which cannot (I'd almost say MUST NOT) be implemented without > > the requirement to implement an additional document describing the > payload. >=20 > Yes. And the draft explicitly says: >=20 > The content of the INTERMEDIATE exchange messages depends on the > data > being transferred and will be defined by specifications utilizing > this exchange. >=20 > Should I add some normative language here to make this even more explicit? > For example: >=20 > The content of the INTERMEDIATE exchange messages depends on the > data > being transferred and MUST be defined by specifications utilizing > this exchange. >=20 > Note, that it's a common case with any framework documents - the draft > describes only very basic things that must not depend on the content of t= he > SK payload - how to negotiate INTERMEDIATE exchanges, how to > authenticate them, how to handle errors etc. You can implement this draft > alone, but it's useless per its own. I'm not an expert in this kind of (framework) documents at all. My question= is, is an empty IKE_INTERMEDIATE a potential security issue? If there is a chance that this is a potential thread (and I fear it'll be i= mpossible to proof the opposite), my feeling is that the document should sa= y that IKE_INTERMEDIATE MUST NOT be supported without the support of at lea= st one document defining the payload. That would actually remove the necessity to NOTIFY the support of IKE_INTER= MEDIATE, as any exchange utilizing IKE_INTERMEDIATE (e.g. PQKE) would direc= tly infer the necessity to implement IKE_INTERMEDIATE with a detailed descr= iption of the allowed payload. However, I'm happy to learn if (and why) this is not security thread at all= =3D) >=20 > > 2. On the other hand, IKE_INTERMEDIATE describes how to use previously > > exchanged keys in order to secure (encrypt) the IKE_INTERMEDIATE traffi= c. > > If IKE_INTERMEDIATE is there to describe the messages and not the key > > exchange, I think the document should only say that the current key in > > the IKE SA should be used. >=20 > Sorry, but in my reading the draft currently says exactly this: >=20 > The keys SK_e[i/r] and SK_a[i/r] for the Encrypted payload in the > INTERMEDIATE exchanges are computed in a standard fashion, as defined > in the Section 2.14 of [RFC7296]. Every subsequent INTERMEDIATE > exchange uses the most recently calculated keys before this exchange > is started. The first INTERMEDIATE exchange always uses SK_e[i/r] > and SK_a[i/r] keys that were computed as result the IKE_SA_INIT > exchange. If this INTERMEDIATE exchange performs additional key > exchange resulting in the update of SK_e[i/r] and SK_a[i/r], then > these updated keys are used for encryption and authentication of next > INTERMEDIATE exchange, otherwise the current keys are used, and so > on. >=20 > In my reading this text says exactly what you want it to say. > It doesn't give any hints how the keys are calculated - it says: > "use most recently calculated keys". So, if keys are not recalculated aft= er > each INTERMEDIATE exchange, then SK_* from IKE_SA_INIT are always > used, otherwise the result of recalculation is used. >=20 > How do you think the text can be improved to make this more clear? I'd completely remove the second part and only write: The keys SK_e[i/r] and SK_a[i/r] for the Encrypted payload in the INTERMEDIATE exchanges are computed in a standard fashion, as defined in the Section 2.14 of [RFC7296]. Every subsequent INTERMEDIATE exchange uses the most recently calculated keys before this exchange is started. =20 >=20 > > I'm not 100% sure if especially point 1 is an actual issue for an IETF > > document and if so how to solve it. > > One idea would be to define a (maybe informational/experimental) > > document like "how to add an additional pre-auth exchange in IKEv2", > > which can then be used by e.g. > > draft-tjhai-ipsecme-hybrid-qske-ikev2-03 to define the actual exchange. >=20 > Standards Track RFC generally cannot have Normative reference to lower > grade RFCs, like Informational or Experimental (there are exceptions, but= it's > a generic rule). So I think that INTERMEDIATE document must be Standards > Track. The idea about using not standard track would be, that any document using = the IKE_INTERMEDIATE needs to define the actual message. I don't like this idea too much, but it would at least be clean that any me= ssage is defined completely by any future document. >=20 > > Another idea would be to define a list of allowed payloads (e.g. by > > IANA registry). >=20 > I'd rather to avoid this, as new payloads may appear in future. If we had an IANA registry for every payload allowed in IKE_INTERMEDIATE, t= hat could easily be updated by future documents by registering a new value. I don't say this is the only way to go, but I feel it's cleaner than just s= aying it could be anything. I'd actually prefer what I mentioned above, not= allowing IKE_INTERMEDIATE to be implemented without another document defin= ing the actual payload. In any case, if we can discuss/change that after adoption, I'm completely f= ine and support adoption. >=20 > > If the WG thinks that this is not an issue or can be solved after > > adoption, we support adoption and we were about to show and discuss > > some details on that (and other PQKE related stuff) in a presentation in > Prague. > > We just wanted to raise awareness and get a discussion on this > > (potential) issue before the adoption call ends. >=20 > Thank you, > Valery. >=20 > > > > Regards > > Tobias > > > > > -----Urspr=C3=BCngliche Nachricht----- > > > Von: IPsec Im Auftrag von Panos Kampanakis > > > (pkampana) > > > Gesendet: Donnerstag, 14. M=C3=A4rz 2019 20:07 > > > An: 'Tero Kivinen' ; ipsec@ietf.org > > > Betreff: Re: [IPsec] WG adoptation call for > > draft-smyslov-ipsecme-ikev2-aux- > > > 02 > > > > > > +1 on adopting this draft. > > > > > > -----Original Message----- > > > From: IPsec On Behalf Of Valery Smyslov > > > Sent: Thursday, March 14, 2019 4:38 AM > > > To: 'Tero Kivinen' ; ipsec@ietf.org > > > Subject: Re: [IPsec] WG adoptation call for > > draft-smyslov-ipsecme-ikev2-aux- > > > 02 > > > > > > Hi, > > > > > > as author of the document I (obviously) support its adoption. > > > It's a building block for QSKE solution (at least how the WG sees it > > > now) > > so I > > > think we should adopt it. > > > > > > Regards, > > > Valery. > > > > > > > This document has been stable for some time, and I think it is > > > > ready to go forward. Because of that I will start one week long WG > > > > adoptation call for this draft which will expire end of next week > > > > (2019-03-22). > > > > > > > > If you have any reasons why this should not be adopted as WG > > > > document, send email to the list as soon as possible. > > > > -- > > > > kivinen@iki.fi > > > > > > > > _______________________________________________ > > > > IPsec mailing list > > > > IPsec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec --=-=24Cjxmfapt+igW=-= Content-Transfer-Encoding: 7bit Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEyFCRjitB0A1IDrryyEcVbMgzVZ8FAlyRJsQACgkQyEcVbMgz VZ+VWgf/UaFeE9lO8AYOBZ1TfjPbIXRsfshjE+b4oKr1Z4rC/eWOuhsxpu2kNcIq /B/wq2ZFJcg3ihCSFgW+SX73thkyhttDzKA2yZKQimYkDxG3G9EOT5an44B1ZDzC aBThrDemtLEdAzSyxkk+kTOTIbx449WjSbsXf1Mo/kstIndNsBycw5xnRoi57abu tU6n0a/ESCvb1gHaeWoEJhCgtU6hAqBpnHhggLRWftVtZo6YgLn89FIZ/VaRJ5wb qb4z8jEpYUifW3hgcgBNRpvhLezJhuIwRacMPane3PpEc3PKFD0NYAuR4reWHFdp mAjJaZq0n00ie/e3MeDjFoDABXHCzA== =W+9L -----END PGP SIGNATURE----- --=-=24Cjxmfapt+igW=-=-- From nobody Tue Mar 19 11:51:18 2019 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 D63AA13158F; Tue, 19 Mar 2019 11:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 ZI4UpP7z4XZN; Tue, 19 Mar 2019 11:51:05 -0700 (PDT) Received: from xenon42.um.es (xenon42.um.es [IPv6:2001:720:1710:601::42]) by ietfa.amsl.com (Postfix) with ESMTP id 62A511315A3; Tue, 19 Mar 2019 11:51:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon42.um.es (Postfix) with ESMTP id 7735D20D7D; Tue, 19 Mar 2019 19:50:53 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon42.um.es Received: from xenon42.um.es ([127.0.0.1]) by localhost (xenon42.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Uf_8tKiCnlF7; Tue, 19 Mar 2019 19:50:53 +0100 (CET) Received: from [192.168.1.36] (145.red-88-20-136.staticip.rima-tde.net [88.20.136.145]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon42.um.es (Postfix) with ESMTPSA id BAE32204EF; Tue, 19 Mar 2019 19:50:51 +0100 (CET) From: Rafa Marin-Lopez Content-Type: multipart/alternative; boundary="Apple-Mail=_A95A5E8E-82FC-4773-8215-E10AD808B59A" Message-Id: <23D10393-0AC3-4A2E-80C9-A178E19DCED8@um.es> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Tue, 19 Mar 2019 19:50:49 +0100 References: <155233406860.23094.414648929427040457.idtracker@ietfa.amsl.com> Cc: Rafa Marin-Lopez , "ipsec@ietf.org WG" To: i2nsf@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [IPsec] Fwd: New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 18:51:11 -0000 --Apple-Mail=_A95A5E8E-82FC-4773-8215-E10AD808B59A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all: After receiving an extensive review from Paul Wouters, and comments from = Linda and Yoav, we have prepared a new version of = draft-ietf-i2nsf-sdn-ipsec-flow-protection.=20 In order to accomplish the comments and improve the readability of YANG = models, we have defined three parts: ietf-ipsec-common (Appendix A), = ietf-ipsec-ike (Appendix B, IKE case), ietf-ipsec-ikeless (Appendix C, = IKE-less case). The model ietf-ipsec-common has only typedef and = groupings common to the other modules. This is also coherent with the fact that a NSF implementing IKE case = should not be worried about implementing anything about IKE-less case = and viceversa.=20 We would like to have a 10-15 minute slot to explain this new version. = We will participate remotely. Best Regards. > Inicio del mensaje reenviado: >=20 > De: internet-drafts@ietf.org > Asunto: New Version Notification for = draft-ietf-i2nsf-sdn-ipsec-flow-protection-04.txt > Fecha: 11 de marzo de 2019, 20:54:28 CET > Para: "Fernando Pereniguez-Garcia" , = "Rafa Marin-Lopez" , "Rafael Lopez" , "Gabriel = Lopez-Millan" >=20 >=20 > A new version of I-D, = draft-ietf-i2nsf-sdn-ipsec-flow-protection-04.txt > has been successfully submitted by Rafa Marin-Lopez and posted to the > IETF repository. >=20 > Name: draft-ietf-i2nsf-sdn-ipsec-flow-protection > Revision: 04 > Title: Software-Defined Networking (SDN)-based IPsec = Flow Protection > Document date: 2019-03-11 > Group: i2nsf > Pages: 49 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-i2nsf-sdn-ipsec-flow-prote= ction-04.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protectio= n/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-prot= ection > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2nsf-sdn-ipsec-flow-protec= tion-04 >=20 > Abstract: > This document describes how 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. The SDN-based service described in > this document allows the distribution and monitoring of IPsec > information from a Security 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 = IKEv2 > to establish security associations with a reduced intervention of = the > network administrator. >=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 ------------------------------------------------------- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --Apple-Mail=_A95A5E8E-82FC-4773-8215-E10AD808B59A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear = all:

After receiving = an extensive review from Paul Wouters, and comments from Linda and Yoav, = we have prepared a new version of = draft-ietf-i2nsf-sdn-ipsec-flow-protection. 
In order to accomplish the comments = and improve the readability of YANG models, we have defined three parts: = ietf-ipsec-common (Appendix A), ietf-ipsec-ike (Appendix B, IKE case), = ietf-ipsec-ikeless (Appendix C, IKE-less case). The model = ietf-ipsec-common has only typedef and groupings common to the other = modules.

This = is also coherent with the fact that a NSF implementing IKE case should = not be worried about implementing anything about IKE-less case and = viceversa. 

We would like to have a 10-15 minute slot to explain this new = version. We will participate remotely.

Best Regards.

Inicio = del mensaje reenviado:

De: internet-drafts@ietf.org
Asunto: = New Version = Notification for = draft-ietf-i2nsf-sdn-ipsec-flow-protection-04.txt
Fecha: = 11 de marzo de 2019, 20:54:28 = CET
Para: = "Fernando Pereniguez-Garcia" = <fernando.pereniguez@cud.upct.es>, "Rafa Marin-Lopez" = <rafa@um.es>, "Rafael = Lopez" <rafa@um.es>, = "Gabriel Lopez-Millan" <gabilm@um.es>


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

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

Abstract:
  This document describes how 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.  The SDN-based service = described in
  this document allows the = distribution and monitoring of IPsec
=   information from a Security 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 IKEv2
  to establish = security associations with a reduced intervention of the
=   network administrator.




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


-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 Fax: +34868884151 = e-mail: rafa@um.es
-------------------------------------------------------




= --Apple-Mail=_A95A5E8E-82FC-4773-8215-E10AD808B59A-- From nobody Wed Mar 20 00:20:57 2019 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 AFCFB130EFA for ; Wed, 20 Mar 2019 00:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bePYgP-wzBie for ; Wed, 20 Mar 2019 00:20:52 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 32855130F1F for ; Wed, 20 Mar 2019 00:20:52 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id o1so1444022wrs.13 for ; Wed, 20 Mar 2019 00:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=+KQVnMbYn9M60qaM5pAcYwxWoEipd5HRymg/033JZ7Q=; b=iaeCkYNV9LgrYYOvc1i8bScxSeNg6xM6Wxth3ItsZ+pXywNyelLT3mJZ3bkJWAUEfZ 0QgMGo/JD9fg4xx8Fz++J85Voa3pEEdLcI/HnVU7X+Hf5nIfBz3wIw3z3orHfwWSSF88 a/8Bpa8KdDmp8fauQHD/vWiJJSM0TGWeC3pJXX5bVeC17chBeNtjPhq9Wbr0QtOTy5lq j/12y5f9CIF0Xf8Nsh3McRn2R3PWZKWKdX7VeY1nBNQtnV/8q/CULCGpVVN0WMYBDKce FBqv07TyxqCuxqgeF+x77lnaSnPPABSX1HDquhps6f8ov72YY02J/hKmqsRuu64JUc72 Sqfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=+KQVnMbYn9M60qaM5pAcYwxWoEipd5HRymg/033JZ7Q=; b=hhdnmjXzCA506MuoIasGd2Sc8oVjmRONRDfgT7mdLjApFtEC8QcznlOh3zDJlzMUmJ zCP4ZIgFDQ0U37KV6UqWNir2ilEHuGYxa+cWStBdQ2b5SVWCdi/WPfSQaqfNcAcg+yqt fWh99f+C5X5EsI8rwNCS29HCrWQOOCx3/tHPRqIpD89x2/I2GhilZVERA1jzMEAFJeHK 8nqiDClVduBQl/96R7WvHeiay3aPFl6HmFwRfO/Hyg28+FwK5kx+FjOh9w79hWBuw6u7 MLh5fnYs3Dde2eeTTBNmYz+n9DvkOvEE8lOy3UiIeokREEA0bcS19Z3DD5vAlQiRZkAF 4ViA== X-Gm-Message-State: APjAAAXQEag2KoORVGD/ls5I6FSxF+2WgIo0hH0ZN4AkWBtAAJiJ9rZy SG/QkJfAS3/954dhpkhs1No= X-Google-Smtp-Source: APXvYqylLgSNF3LKDJLaEqExKieW3s/F+VCWsbc/gzHhM7qcPA/rk9DFY6DcU2Jnsi1tWPPosS1b6g== X-Received: by 2002:a5d:4f11:: with SMTP id c17mr602809wru.34.1553066450678; Wed, 20 Mar 2019 00:20:50 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id x11sm1293866wmh.2.2019.03.20.00.20.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Mar 2019 00:20:50 -0700 (PDT) From: "Valery Smyslov" To: "'Tobias Guggemos'" , "'Tero Kivinen'" , References: <23688.31062.426962.985107@fireball.acr.fi> <01c701d4da41$3c61f890$b525e9b0$@gmail.com> <6454f07af680410e918431971f3489f2@XCH-ALN-010.cisco.com> <001e01d4ddac$5502d770$ff088650$@nm.ifi.lmu.de> <059301d4de2d$faa5a000$eff0e000$@gmail.com> <000a01d4de79$31d3cc00$957b6400$@nm.ifi.lmu.de> In-Reply-To: <000a01d4de79$31d3cc00$957b6400$@nm.ifi.lmu.de> Date: Wed, 20 Mar 2019 10:20:46 +0300 Message-ID: <06b701d4deed$706f1310$514d3930$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQICh2VSFjkuY0eSQrYh6iGxPAV2+AHuWDWOAmpINo8CGcLbUAMGThUEAw641ZmlVISNcA== Content-Language: ru Archived-At: Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 07:20:56 -0000 Hi Tobias, > > The idea is that hybrid-qske document depends on ikev2-aux document = and > > not vice versa. > > If this failed in your opinion, that must be fixed. >=20 > My opinion is, that IKE_INTERMEDIATE should not mention PQKE at all, = if it is meant to be a framework > document which is "just" there to define the message. It doesn't. There's no reference to QSKE draft and Quantum Safe Key = Exchange=20 is only mentioned as a possible application for the draft in the = Introduction section. > I know that the main motivation for IKE_INTERMEDIATE is PQKE, but I = don't feel that we're at a point where > we can actually say for sure that this is the one and only way for = PQKE and, thus, I'd prefer > IKE_INTERMEDIATE to be completely independent of any Key Exchange = related stuff! That's my intention too, we are in concert here. And in my opinion the draft makes no hint that QSKE is the only application, quite the opposite. > > > So basically, we have a (standard-track RFC) document describing a > > > message which cannot (I'd almost say MUST NOT) be implemented = without > > > the requirement to implement an additional document describing the > > payload. > > > > Yes. And the draft explicitly says: > > > > The content of the INTERMEDIATE exchange messages depends on the > > data > > being transferred and will be defined by specifications utilizing > > this exchange. > > > > Should I add some normative language here to make this even more = explicit? > > For example: > > > > The content of the INTERMEDIATE exchange messages depends on the > > data > > being transferred and MUST be defined by specifications utilizing > > this exchange. > > > > Note, that it's a common case with any framework documents - the = draft > > describes only very basic things that must not depend on the content = of the > > SK payload - how to negotiate INTERMEDIATE exchanges, how to > > authenticate them, how to handle errors etc. You can implement this = draft > > alone, but it's useless per its own. >=20 > I'm not an expert in this kind of (framework) documents at all. My = question is, is an empty IKE_INTERMEDIATE > a potential security issue? Which security issue? Can you please elaborate? > If there is a chance that this is a potential thread (and I fear it'll = be impossible to proof the opposite), my > feeling is that the document should say that IKE_INTERMEDIATE MUST NOT = be supported without the > support of at least one document defining the payload. That is implied. I can make this more explicit, by adding something like = that: Successful exchange of INTERMEDIATE_EXCHANGE_SUPPORTED notification only confirms that both parties support INTERMEDIATE exchange. It is not enough condition to start doing INTERMEDIATE = exchange. A separate documents that utilize this exchange MUST define=20 the conditions in which peers would do INTERMEDIATE exchanges,=20 the conditions for ending the sequence of these exchanges and start = IKE_AUTH, and the payloads these exchanges should carry. Is it OK for you? > That would actually remove the necessity to NOTIFY the support of = IKE_INTERMEDIATE, as any exchange > utilizing IKE_INTERMEDIATE (e.g. PQKE) would directly infer the = necessity to implement IKE_INTERMEDIATE > with a detailed description of the allowed payload. I don't think it's a good idea. Instead of decoupling INTERMEDIATE from = its applications, it would make them more interdependent. > However, I'm happy to learn if (and why) this is not security thread = at all =3D) I'm not sure I understand the security thread you are talking about. If your concern is that someone would use an empty INTERMEDIATE exchange, than the text above would address it. > > Sorry, but in my reading the draft currently says exactly this: > > > > The keys SK_e[i/r] and SK_a[i/r] for the Encrypted payload in the > > INTERMEDIATE exchanges are computed in a standard fashion, as = defined > > in the Section 2.14 of [RFC7296]. Every subsequent INTERMEDIATE > > exchange uses the most recently calculated keys before this = exchange > > is started. The first INTERMEDIATE exchange always uses = SK_e[i/r] > > and SK_a[i/r] keys that were computed as result the IKE_SA_INIT > > exchange. If this INTERMEDIATE exchange performs additional key > > exchange resulting in the update of SK_e[i/r] and SK_a[i/r], then > > these updated keys are used for encryption and authentication of = next > > INTERMEDIATE exchange, otherwise the current keys are used, and = so > > on. > > > > In my reading this text says exactly what you want it to say. > > It doesn't give any hints how the keys are calculated - it says: > > "use most recently calculated keys". So, if keys are not = recalculated after > > each INTERMEDIATE exchange, then SK_* from IKE_SA_INIT are always > > used, otherwise the result of recalculation is used. > > > > How do you think the text can be improved to make this more clear? >=20 >=20 > I'd completely remove the second part and only write: >=20 > The keys SK_e[i/r] and SK_a[i/r] for the Encrypted payload in the > INTERMEDIATE exchanges are computed in a standard fashion, as = defined > in the Section 2.14 of [RFC7296]. Every subsequent INTERMEDIATE > exchange uses the most recently calculated keys before this = exchange > is started. I'm generally OK with this, however I'm a bit concerned here that implementers might get a wrong impression that the keys calculated in IKE_SA_INIT never changes. The text that you snipped has the=20 only purpose to warn implementers that this might not be the case. Don't you think it's a valid concern? > > > I'm not 100% sure if especially point 1 is an actual issue for an = IETF > > > document and if so how to solve it. > > > One idea would be to define a (maybe informational/experimental) > > > document like "how to add an additional pre-auth exchange in = IKEv2", > > > which can then be used by e.g. > > > draft-tjhai-ipsecme-hybrid-qske-ikev2-03 to define the actual = exchange. > > > > Standards Track RFC generally cannot have Normative reference to = lower > > grade RFCs, like Informational or Experimental (there are = exceptions, but it's > > a generic rule). So I think that INTERMEDIATE document must be = Standards > > Track. >=20 > The idea about using not standard track would be, that any document = using the IKE_INTERMEDIATE needs to > define the actual message. > I don't like this idea too much, but it would at least be clean that = any message is defined completely by any > future document. The drawback is that every document would need to redefine a = negotiation, protection, authentication, error handling, interaction with other = extensions etc. > > > Another idea would be to define a list of allowed payloads (e.g. = by > > > IANA registry). > > > > I'd rather to avoid this, as new payloads may appear in future. >=20 > If we had an IANA registry for every payload allowed in = IKE_INTERMEDIATE, that could easily be updated by > future documents by registering a new value. I don't think IANA registry is needed for that. In my opinion it's = enough that every dependent document describes the content of INTERMEDIATE = exchange. Look for example at INFORMATIONAL exchange. It's the same "Swiss army = knife", and is used for a lot of purposes depending on the notifications it = contains. Somehow we managed to deal with that without IANA registry that would list the notifications that could appear in INFORMATIONAL exchange. I don't see a big difference with INTERMEDIATE here, except that=20 instead of notifications the dependent documents will define payload = types for this exchange. > I don't say this is the only way to go, but I feel it's cleaner than = just saying it could be anything. I'd actually > prefer what I mentioned above, not allowing IKE_INTERMEDIATE to be = implemented without another > document defining the actual payload. Exactly, except that I'd s/implemented/used. You can implement a pure = framework (just for the future), but you cannot use it without implementing = another document utilizing it. Regards, Valery. > In any case, if we can discuss/change that after adoption, I'm = completely fine and support adoption. >=20 > > > > > If the WG thinks that this is not an issue or can be solved after > > > adoption, we support adoption and we were about to show and = discuss > > > some details on that (and other PQKE related stuff) in a = presentation in > > Prague. > > > We just wanted to raise awareness and get a discussion on this > > > (potential) issue before the adoption call ends. > > > > Thank you, > > Valery. > > > > > > > > Regards > > > Tobias > > > > > > > -----Urspr=C3=BCngliche Nachricht----- > > > > Von: IPsec Im Auftrag von Panos = Kampanakis > > > > (pkampana) > > > > Gesendet: Donnerstag, 14. M=C3=A4rz 2019 20:07 > > > > An: 'Tero Kivinen' ; ipsec@ietf.org > > > > Betreff: Re: [IPsec] WG adoptation call for > > > draft-smyslov-ipsecme-ikev2-aux- > > > > 02 > > > > > > > > +1 on adopting this draft. > > > > > > > > -----Original Message----- > > > > From: IPsec On Behalf Of Valery Smyslov > > > > Sent: Thursday, March 14, 2019 4:38 AM > > > > To: 'Tero Kivinen' ; ipsec@ietf.org > > > > Subject: Re: [IPsec] WG adoptation call for > > > draft-smyslov-ipsecme-ikev2-aux- > > > > 02 > > > > > > > > Hi, > > > > > > > > as author of the document I (obviously) support its adoption. > > > > It's a building block for QSKE solution (at least how the WG = sees it > > > > now) > > > so I > > > > think we should adopt it. > > > > > > > > Regards, > > > > Valery. > > > > > > > > > This document has been stable for some time, and I think it is > > > > > ready to go forward. Because of that I will start one week = long WG > > > > > adoptation call for this draft which will expire end of next = week > > > > > (2019-03-22). > > > > > > > > > > If you have any reasons why this should not be adopted as WG > > > > > document, send email to the list as soon as possible. > > > > > -- > > > > > kivinen@iki.fi > > > > > > > > > > _______________________________________________ > > > > > IPsec mailing list > > > > > IPsec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > _______________________________________________ > > > > IPsec mailing list > > > > IPsec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > _______________________________________________ > > > > IPsec mailing list > > > > IPsec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Mar 20 03:11:39 2019 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 6AA2D13109F for ; Wed, 20 Mar 2019 03:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcqJkY8h7hQH for ; Wed, 20 Mar 2019 03:11:36 -0700 (PDT) Received: from mail.strongswan.org (sitav-80046.hsr.ch [152.96.80.46]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D0EF130F84 for ; Wed, 20 Mar 2019 03:11:36 -0700 (PDT) Received: from [172.31.97.233] (unknown [195.39.71.253]) by mail.strongswan.org (Postfix) with ESMTPSA id 4C24E4041A; Wed, 20 Mar 2019 11:11:40 +0100 (CET) To: Tero Kivinen , ipsec@ietf.org References: <23688.31062.426962.985107@fireball.acr.fi> From: Andreas Steffen Openpgp: preference=signencrypt Autocrypt: addr=andreas.steffen@strongswan.org; prefer-encrypt=mutual; keydata= xsDNBEoycP0BDACzL8ymURD7gnaNbGx2VGieNQr/gNISWhqgHaeUxuSkrInxl89AClvN7DoF 2cD7slEqIMQh/8t6xVzmh9teu5uyeV1eyG/CuFMUqawXqpn/sYa2SkgXC/qHB2hIbFg2K4k5 LJHxzqHb1OdtOcU6lHg9yrvYcoO+FTVR+rYaVgYbbbziTB/vhAAzvdTdgwMgoQMSXA7FsJ0m ALny4IeiCoi6S6qRVDm4zcu11UFT9g1VmhmeHqtUSQso72bPKKhYvu7ZaQrLhkvY9inWr6m9 dxV8Zgb1ivZGhzsNzrhGAsz9jmiB5POFMfph0hREMiS33ph/YMJducGQHYGEza9mKBdUaaAA EL3fCpde7vRa+c5Gc/Y5RUB7iUsb2KQY+7xTiSUnCHbsMwhndG0dJspVXcz6X+2S3Ty4Gaiq kvxI9KLiwiECNl0IoLX5s/FIW6KW+GnxJTp/3h6vvqm8i0+yIwk+ETM4XfhHMwuPkDyf6km1 ag3nIUw6pSSfnQMPhj5rXIMAEQEAAc0wQW5kcmVhcyBTdGVmZmVuIDxhbmRyZWFzLnN0ZWZm ZW5Ac3Ryb25nc3dhbi5vcmc+wsD3BBMBAgAhBQJKMnD9AhsDBwsJCAcDAgEEFQIIAwQWAgMB Ah4BAheAAAoJEN9CwXCzTbp3t5AL/jrXnnGIHLn8M9rmyoeNe7JQUE5AGSV3UFaZHgHmjbvI HA+dRvh1MPlHuWbaZkHVPtRFvFtEgksc944+XcKoNoExKGKrwLQcUExUiQ0IyNwH70u7f1uF NcbY85Oue5ASzm+wAntnmIlNsN+MHewRWC6f6gYn1aHwsvh09fz0A34v9wdtim2ek/Voxe3A IDIw2MTNmwF61pXEsrH0wqYnGhYLZ7QbthnDnHQaUd3IPSa6uAgOOiCoCbKCvP4u/iVm0rmX N9uzmm/i4Y0cE3DopGsqrR5DfWYJjgP4KBCln0LgWtYI8pcYcmA5E+l+fijNcMidtzWHMW2M j0oZZsO+wlRUYLGh/jRASgq7rXuxV+oGKcBn4RqSHlZ5/BYlvowUxnNFC4tLLlneHidS8Tur jacM3fwRMP5NMmcS5d9sVLG1uxl+/g2cRMtphHiziz+79jDc+tSxqRO5lhqyItAD6LC2GxB3 iC5afnMx49+YWzhUTeL/KfkrD9w3/n7O00kLtM7CTQRKjOHDEAwAxdh8W7j/QhE3KZNmJGsK /QtJ72zZRGRcdUPH6GG//GaAG5hSCjM8q+0MR/G+31uk32RbzRIj1sHQ8fY0znxPmaeD1wow 0hCbDTq+Ep3K8ouaqoqjlP4rd+I94OtxNfXgmllf7BDOZ6lIwUY8ba8cFCPYsv8ZvRXo82Xf wFYevQ9kTLqkJT52mMyPZLwYx4DNwuqFtQQEBLKgIVXVgpK6SE72MFP8vyFsdrL0ORgxoWI6 PIHbnIRY1KiWUzOSrqirZUHH9MPuzFuBR0+jEAajeKoxycn0ILLM5PBAEFXFgBdtNNCtshe1 fR5aPsXcGZsZRjc7mbAHLRqapVhk7oX31WrGqGHkSM/GAnf3aAzsnCkO5+Tje2iyuoG5OhQb HsvMBOtdvQrwnorl56EguzuK1mGDsczNsuAYRcKiasCWpsjoytDH+dGEQmKXydD9r06cxPx+ mWmWKLo4w+k4mMC0lFRYKi83cwTpaMpHOeW4+3d1tJfkCQy+vjUz4aZJ/WSXAAMFDACqmeXA Al7WssHkjVZ/vwQfHLHNMZsGEEucvV7KNqMF4Fe6nRbbE6GJOuz6taeFkJIppBqVxhSNOsf5 soOXfGp0IgYoC37GPI6AAb4UnG5GVcaAMQAXUYcwfDGGuV/EO5pPrEyPjy++GvjhxcKV3HmU uAfcgyhTGhDOVPxU28Roz3+8Eig085v+lyqAsgFduBrf+ZV+lHjIOSXSWmTiT8EVSA3fpN14 /qhltudhdGIZ/pCW303H9Bd9c4Uc9OzYhRr1VpO6lpYfTFNey8KQL4z9Kjt0RPscz2hYDOJ1 cTFWs/4Z+9mBJODwrnIiORLlgV2NlP5EZY4MccVFd9K7E/OPQdt3Uv6+6BjYRntY7wsX617T 5Rmj8n6AhbpngmWg2D6wRfm7TyI0Wtz5icCoJIEHQwB/3EhBzQl7tBc0cClwCYm7nTYRt+SL 2tfylWy9Leail+ayM6zwMW0klV42E4u8DCy/aJrwmEiVwuwGbXL6z46M9EZguof38MTEmLsH ls/CwN8EGAECAAkFAkqM4cMCGwwACgkQ30LBcLNNunffBgv/b/v3eQoZTWgOB5MnXhIrg/Ki kYTYbnEG9wWM7XIST8bpP7f/UKyD44CCVJH7SVTGAXeyjglnuYXy4FwaTdFmm6alW0sCp4rn mADi5BLLzQlCUa5J0iZ+oAZnAH60BezUM+CYz/QBW3NJmP3323PeM4H4MZ0vLv3wgaLkFlaK /eASBoC7KuZWAnvsNOdLQ29L4BYgW2Jwk1+PxszjT369DsMUY3iY6gM9rM71Ajd8x98hd1r2 6LILGntAEEXxs+13Kka7J4GCqf8/J9ZR01dDp8QM+M9EHFLnthpAyUuSXm5Qlglavnf7tU6A A0SFuA0pP5CXVLG1DLT1fJvNOqjdzPsfu/48AM2Lpxj0gKt1yDQc890GxwnOL1iZ6+XMh9/u jWy7Q7dI4M2mthwYFXldWrPSCmMToWfl62BxPdY5FIECXeRwTIO9sI0LQVc2eAG8lDsge05q 1nJFxo9WKr7ewAdFb/fMIr7XMwoMj2SQSy/tZVCBnDXR5Gw5HSxRnIAS Message-ID: Date: Wed, 20 Mar 2019 11:11:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <23688.31062.426962.985107@fireball.acr.fi> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 10:11:38 -0000 +1 on adopting this draft. Kind regards Andreas On 13.03.19 04:30, Tero Kivinen wrote: > This document has been stable for some time, and I think it is ready > to go forward. Because of that I will start one week long WG > adoptation call for this draft which will expire end of next week > (2019-03-22). > > If you have any reasons why this should not be adopted as WG document, > send email to the list as soon as possible. ====================================================================== Andreas Steffen andreas.steffen@strongswan.org strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Networked Solutions HSR University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[INS-HSR]== From nobody Wed Mar 20 10:06:56 2019 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 C32FC12426A for ; Wed, 20 Mar 2019 10:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gH8MKSgN0ZGN for ; Wed, 20 Mar 2019 10:06:47 -0700 (PDT) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A6651311AA for ; Wed, 20 Mar 2019 10:06:42 -0700 (PDT) Received: from DESKTOP58DFL8T (ObiWan2.nm.ifi.lmu.de [141.84.218.130]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: guggemos) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id 9918C35D9DE; Wed, 20 Mar 2019 18:06:40 +0100 (CET) From: "Tobias Guggemos" To: "'Valery Smyslov'" , "'Tero Kivinen'" , References: <23688.31062.426962.985107@fireball.acr.fi> <01c701d4da41$3c61f890$b525e9b0$@gmail.com> <6454f07af680410e918431971f3489f2@XCH-ALN-010.cisco.com> <001e01d4ddac$5502d770$ff088650$@nm.ifi.lmu.de> <059301d4de2d$faa5a000$eff0e000$@gmail.com> <000a01d4de79$31d3cc00$957b6400$@nm.ifi.lmu.de> <06b701d4deed$706f1310$514d3930$@gmail.com> In-Reply-To: <06b701d4deed$706f1310$514d3930$@gmail.com> Date: Wed, 20 Mar 2019 18:06:40 +0100 MIME-Version: 1.0 Message-ID: <014001d4df3f$492fcc70$db8f6550$@nm.ifi.lmu.de> X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHU2U0s6M7rbXuBv0SBwRv3SEEfn6YKvxmAgACvtICABiKNQIABBzyAgABckXCAASJaAIAATTlQ Content-Language: de Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha256; boundary="=-=MA/gNHKf0qaDLZ=-=" Archived-At: Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 17:06:55 -0000 This is a multipart message in MIME format. --=-=MA/gNHKf0qaDLZ=-= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey >=20 > Hi Tobias, >=20 > > > The idea is that hybrid-qske document depends on ikev2-aux document > > > and not vice versa. > > > If this failed in your opinion, that must be fixed. > > > > My opinion is, that IKE_INTERMEDIATE should not mention PQKE at all, > > if it is meant to be a framework document which is "just" there to defi= ne > the message. >=20 > It doesn't. There's no reference to QSKE draft and Quantum Safe Key > Exchange is only mentioned as a possible application for the draft in the > Introduction section. That's now really a discussion of details, but do we really need this as ab= out 1/3 of the introduction? I just don't like that the draft goes back to this use case during the desc= ription of the used keys. However, my feelings about this are not so strong, that I see it as a show-= stopper. >=20 > > I know that the main motivation for IKE_INTERMEDIATE is PQKE, but I > > don't feel that we're at a point where we can actually say for sure > > that this is the one and only way for PQKE and, thus, I'd prefer > IKE_INTERMEDIATE to be completely independent of any Key Exchange > related stuff! >=20 > That's my intention too, we are in concert here. > And in my opinion the draft makes no hint that QSKE is the only applicati= on, > quite the opposite. You're right it doesn't, but it leaves the impression that it's designed fo= r the use case. >=20 > > > > So basically, we have a (standard-track RFC) document describing a > > > > message which cannot (I'd almost say MUST NOT) be implemented > > > > without the requirement to implement an additional document > > > > describing the > > > payload. > > > > > > Yes. And the draft explicitly says: > > > > > > The content of the INTERMEDIATE exchange messages depends on the > > > data > > > being transferred and will be defined by specifications utilizing > > > this exchange. > > > > > > Should I add some normative language here to make this even more > explicit? > > > For example: > > > > > > The content of the INTERMEDIATE exchange messages depends on the > > > data > > > being transferred and MUST be defined by specifications utilizing > > > this exchange. > > > > > > Note, that it's a common case with any framework documents - the > > > draft describes only very basic things that must not depend on the > > > content of the SK payload - how to negotiate INTERMEDIATE exchanges, > > > how to authenticate them, how to handle errors etc. You can > > > implement this draft alone, but it's useless per its own. > > > > I'm not an expert in this kind of (framework) documents at all. My > > question is, is an empty IKE_INTERMEDIATE a potential security issue? >=20 > Which security issue? Can you please elaborate? >=20 Ok, I'm basically only speculating now: 1) What about an attacker who just sends empty messages to an responder sup= porting IKE_INTERMEDIATE?=20 The state machine will never leave the state of waiting for an IKE_AUTH.=20 2) What about a quantum attacker who breaks the IKE_INIT (in real-time) and= just floods the responder with empty IKE_INTERMEDIATE. This might not be a very realistic attack, but my question is, can you make= sure that it is not an issue?=20 The important thing I'd like to mention: I think, if we can avoid an issue by design - by excluding an option we don= 't necessarily need - we should do that and not the other way around. > > If there is a chance that this is a potential thread (and I fear it'll > > be impossible to proof the opposite), my feeling is that the document > > should say that IKE_INTERMEDIATE MUST NOT be supported without the > support of at least one document defining the payload. >=20 > That is implied. I can make this more explicit, by adding something like = that: >=20 > Successful exchange of INTERMEDIATE_EXCHANGE_SUPPORTED notification > only confirms that both parties support INTERMEDIATE exchange. It is not > enough condition to start doing INTERMEDIATE exchange. > A separate documents that utilize this exchange MUST define the conditions > in which peers would do INTERMEDIATE exchanges, the conditions for > ending the sequence of these exchanges and start IKE_AUTH, and the > payloads these exchanges should carry. >=20 > Is it OK for you? At least, it makes it clearer! I personally would like to make it explicitly impossible to support IKE_INT= ERMEDIATE with an empty payload. (unless there is an application using an e= mpty payload as some kind of a response) The current wording says: The implementation MAY support IKE_INTERMEDIATE b= ut MUST NOT use it without an application. My preferred approach would be: The implementation MUST NOT support IKE_INT= ERMEDIATE without an application.=20 My thinking is, you'd like to negotiate an application (e.g. PQKE) which n= eeds IKE_INTERMEDIATE, so it's all about the application anyway. So if the application needs IKE_INTERMEDIATE, it wouldn't work if IKE_INTER= MEDIATE is not supported anyways. > > That would actually remove the necessity to NOTIFY the support of > > IKE_INTERMEDIATE, as any exchange utilizing IKE_INTERMEDIATE (e.g. > > PQKE) would directly infer the necessity to implement IKE_INTERMEDIATE > with a detailed description of the allowed payload. >=20 > I don't think it's a good idea. Instead of decoupling INTERMEDIATE from i= ts > applications, it would make them more interdependent. >=20 > > However, I'm happy to learn if (and why) this is not security thread > > at all =3D) >=20 > I'm not sure I understand the security thread you are talking about. > If your concern is that someone would use an empty INTERMEDIATE > exchange, than the text above would address it. >=20 > > > Sorry, but in my reading the draft currently says exactly this: > > > > > > The keys SK_e[i/r] and SK_a[i/r] for the Encrypted payload in the > > > INTERMEDIATE exchanges are computed in a standard fashion, as > defined > > > in the Section 2.14 of [RFC7296]. Every subsequent INTERMEDIATE > > > exchange uses the most recently calculated keys before this exchan= ge > > > is started. The first INTERMEDIATE exchange always uses SK_e[i/r] > > > and SK_a[i/r] keys that were computed as result the IKE_SA_INIT > > > exchange. If this INTERMEDIATE exchange performs additional key > > > exchange resulting in the update of SK_e[i/r] and SK_a[i/r], then > > > these updated keys are used for encryption and authentication of n= ext > > > INTERMEDIATE exchange, otherwise the current keys are used, and so > > > on. > > > > > > In my reading this text says exactly what you want it to say. > > > It doesn't give any hints how the keys are calculated - it says: > > > "use most recently calculated keys". So, if keys are not > > > recalculated after each INTERMEDIATE exchange, then SK_* from > > > IKE_SA_INIT are always used, otherwise the result of recalculation is > used. > > > > > > How do you think the text can be improved to make this more clear? > > > > > > I'd completely remove the second part and only write: > > > > The keys SK_e[i/r] and SK_a[i/r] for the Encrypted payload in the > > INTERMEDIATE exchanges are computed in a standard fashion, as > defined > > in the Section 2.14 of [RFC7296]. Every subsequent INTERMEDIATE > > exchange uses the most recently calculated keys before this exchange > > is started. >=20 > I'm generally OK with this, however I'm a bit concerned here that > implementers might get a wrong impression that the keys calculated in > IKE_SA_INIT never changes. The text that you snipped has the only purpose > to warn implementers that this might not be the case. > Don't you think it's a valid concern? >=20 It's a valid concern, but a concern which should be addressed by the docume= nt describing the key update. On the other hand, what if the additional Key Exchange would say that you s= hould not do that for any reason, which would be the ruling document? That would be even more confusing (although I admit the chances for this ca= se are quite low). > > > > I'm not 100% sure if especially point 1 is an actual issue for an > > > > IETF document and if so how to solve it. > > > > One idea would be to define a (maybe informational/experimental) > > > > document like "how to add an additional pre-auth exchange in > > > > IKEv2", which can then be used by e.g. > > > > draft-tjhai-ipsecme-hybrid-qske-ikev2-03 to define the actual > exchange. > > > > > > Standards Track RFC generally cannot have Normative reference to > > > lower grade RFCs, like Informational or Experimental (there are > > > exceptions, but it's a generic rule). So I think that INTERMEDIATE > > > document must be Standards Track. > > > > The idea about using not standard track would be, that any document > > using the IKE_INTERMEDIATE needs to define the actual message. > > I don't like this idea too much, but it would at least be clean that > > any message is defined completely by any future document. >=20 > The drawback is that every document would need to redefine a negotiation, > protection, authentication, error handling, interaction with other extens= ions > etc. >=20 True! > > > > Another idea would be to define a list of allowed payloads (e.g. > > > > by IANA registry). > > > > > > I'd rather to avoid this, as new payloads may appear in future. > > > > If we had an IANA registry for every payload allowed in > > IKE_INTERMEDIATE, that could easily be updated by future documents by > registering a new value. >=20 > I don't think IANA registry is needed for that. In my opinion it's enough= that > every dependent document describes the content of INTERMEDIATE > exchange. >=20 > Look for example at INFORMATIONAL exchange. It's the same "Swiss army > knife", and is used for a lot of purposes depending on the notifications = it > contains. > Somehow we managed to deal with that without IANA registry that would > list the notifications that could appear in INFORMATIONAL exchange. > I don't see a big difference with INTERMEDIATE here, except that instead = of > notifications the dependent documents will define payload types for this > exchange. >=20 The difference with INFORMATIONAL is, that you have a secured channel.=20 At the time of INTERMEDIATE, you still build this channel and, thus, I thin= k a more conservative approach of white-listing is better.=20 That doesn't mean that an IANA registry is the right way to go, it's just o= ne.=20 I'd just like to prevent any miss-use of INTERMEDIATE, as I beliebe it's a = highly security critical step. There are definitely multiple ways of doing that, but I think that should b= e the goal. > > I don't say this is the only way to go, but I feel it's cleaner than > > just saying it could be anything. I'd actually prefer what I mentioned > > above, not allowing IKE_INTERMEDIATE to be implemented without > another document defining the actual payload. >=20 > Exactly, except that I'd s/implemented/used. You can implement a pure > framework (just for the future), but you cannot use it without implementi= ng > another document utilizing it. Maybe we could replace "used" with "supported"? Regards Tobias >=20 > Regards, > Valery. >=20 > > In any case, if we can discuss/change that after adoption, I'm complete= ly > fine and support adoption. > > > > > > > > > If the WG thinks that this is not an issue or can be solved after > > > > adoption, we support adoption and we were about to show and > > > > discuss some details on that (and other PQKE related stuff) in a > > > > presentation in > > > Prague. > > > > We just wanted to raise awareness and get a discussion on this > > > > (potential) issue before the adoption call ends. > > > > > > Thank you, > > > Valery. > > > > > > > > > > > Regards > > > > Tobias > > > > > > > > > -----Urspr=C3=BCngliche Nachricht----- > > > > > Von: IPsec Im Auftrag von Panos > > > > > Kampanakis > > > > > (pkampana) > > > > > Gesendet: Donnerstag, 14. M=C3=A4rz 2019 20:07 > > > > > An: 'Tero Kivinen' ; ipsec@ietf.org > > > > > Betreff: Re: [IPsec] WG adoptation call for > > > > draft-smyslov-ipsecme-ikev2-aux- > > > > > 02 > > > > > > > > > > +1 on adopting this draft. > > > > > > > > > > -----Original Message----- > > > > > From: IPsec On Behalf Of Valery Smyslov > > > > > Sent: Thursday, March 14, 2019 4:38 AM > > > > > To: 'Tero Kivinen' ; ipsec@ietf.org > > > > > Subject: Re: [IPsec] WG adoptation call for > > > > draft-smyslov-ipsecme-ikev2-aux- > > > > > 02 > > > > > > > > > > Hi, > > > > > > > > > > as author of the document I (obviously) support its adoption. > > > > > It's a building block for QSKE solution (at least how the WG > > > > > sees it > > > > > now) > > > > so I > > > > > think we should adopt it. > > > > > > > > > > Regards, > > > > > Valery. > > > > > > > > > > > This document has been stable for some time, and I think it is > > > > > > ready to go forward. Because of that I will start one week > > > > > > long WG adoptation call for this draft which will expire end > > > > > > of next week (2019-03-22). > > > > > > > > > > > > If you have any reasons why this should not be adopted as WG > > > > > > document, send email to the list as soon as possible. > > > > > > -- > > > > > > kivinen@iki.fi > > > > > > > > > > > > _______________________________________________ > > > > > > IPsec mailing list > > > > > > IPsec@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > > > _______________________________________________ > > > > > IPsec mailing list > > > > > IPsec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > > > _______________________________________________ > > > > > IPsec mailing list > > > > > IPsec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > _______________________________________________ > > > > IPsec mailing list > > > > IPsec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ipsec --=-=MA/gNHKf0qaDLZ=-= Content-Transfer-Encoding: 7bit Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEyFCRjitB0A1IDrryyEcVbMgzVZ8FAlyScxwACgkQyEcVbMgz VZ/lFAf/WWNS+Y6BiAB01rJJ1kVhBKb/oz2IqhMivee/SKeCZ0eLkPLNAGmsupXV W+wrt7WNj768CeaExpJQl5W3mcfcNv6SWf1iWbA0vGkEFqWdsr3e7HDEglaVMSXR +anlCTPfzrY/D7MEAJVY9eJJrbkU13ucODfRlg+hMZcyCh+4gcCy57Y7HFEUxOmy 1fPsXjXefN6ubJDYdFVM7QkAxjjYwQ3A/Qg5Z1X3P8KxjgHt6FdDHTtadcrgw6kv +OhD/FffWbIZB2d5HFVD/Dv+hH+KJ/PTL3Dy4SXuKJoMRrxzycJh8nzbOgsfPwsl NbYN4dOvAyTWpt2OYptfrqfPzBNaYg== =7BOY -----END PGP SIGNATURE----- --=-=MA/gNHKf0qaDLZ=-=-- From nobody Wed Mar 20 13:48:38 2019 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 855B912796D for ; Wed, 20 Mar 2019 13:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YWBwYFML2hY for ; Wed, 20 Mar 2019 13:48:35 -0700 (PDT) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 485EB124BF6 for ; Wed, 20 Mar 2019 13:48:35 -0700 (PDT) Received: from [192.168.1.144] (r099168.stusta.swh.mhn.de [10.150.99.168]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: heidert) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id B3E16360D60 for ; Wed, 20 Mar 2019 21:48:32 +0100 (CET) From: Tobias Heider To: ipsec@ietf.org References: <23688.31062.426962.985107@fireball.acr.fi> <01c701d4da41$3c61f890$b525e9b0$@gmail.com> <6454f07af680410e918431971f3489f2@XCH-ALN-010.cisco.com> <001e01d4ddac$5502d770$ff088650$@nm.ifi.lmu.de> <059301d4de2d$faa5a000$eff0e000$@gmail.com> <000a01d4de79$31d3cc00$957b6400$@nm.ifi.lmu.de> <06b701d4deed$706f1310$514d3930$@gmail.com> Message-ID: <78b108b7-ab63-3a25-f0e3-9a934a3692a7@nm.ifi.lmu.de> Date: Wed, 20 Mar 2019 21:48:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <06b701d4deed$706f1310$514d3930$@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US-large Archived-At: Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 20:48:37 -0000 Hi Valery, >> If there is a chance that this is a potential thread (and I fear >> it'll be impossible to proof the opposite), my >> feeling is that the document should say that IKE_INTERMEDIATE MUST >> NOT be supported without the >> support of at least one document defining the payload. > That is implied. I can make this more explicit, by adding something > like that: > > Successful exchange of INTERMEDIATE_EXCHANGE_SUPPORTED > notification only confirms that both parties support INTERMEDIATE > exchange. It is not enough condition to start doing INTERMEDIATE exchange. > A separate documents that utilize this exchange MUST define the > conditions in which peers would do INTERMEDIATE exchanges, the > conditions for ending the sequence of these exchanges and start IKE_AUTH, > and the payloads these exchanges should carry. > > Is it OK for you? I was wondering about what happens when multiple documents utilize the IKE_INTERMEDIATE exchange at the same time. Can two different documents utilize a single exchange of IKE_INTERMEDIATE messages, or must every document add an additional exchange of IKE_INTERMEDIATE messages? Currently the only "user" is the Hybrid PQKE draft which adds up to seven INTERMEDIATE exchanges before the IKE_AUTH, could i just define a draft that includes an additional payload in the first INTERMEDIATE exchange (not knowing whether Hybrid KE is used or not) or would i have to add an eighth INTERMEDIATE exchange? I couldn't find any info on this in the current draft and i feel like this is quite relevant for future users of the exchange. Regards, (another) Tobias From nobody Thu Mar 21 00:48:32 2019 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 25E96130F39 for ; Thu, 21 Mar 2019 00:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBH-8kzZR9rj for ; Thu, 21 Mar 2019 00:48:28 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 DA4AC127287 for ; Thu, 21 Mar 2019 00:48:27 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id j9so5446363wrn.6 for ; Thu, 21 Mar 2019 00:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=b00LSgwPVIXXX8mGyqWDF6ZXt4mBscXfyvcPPH/P16Q=; b=ZsaAkDQ7ZlWkAhrQDY3G8h+q3RXp99ryQaubbESPVD++qxiHZbKY+BAF+yqh7/TWQi Fu8hp/fM3k1x+fllQj3tQUQZDHmBRrGYQ/Z4YrLAT1id/zqHLCD8mX6HMPCVmWdeOa4Y +uvqCrX2zhwLfYdxAnX1lXgzgT5fvvqKeZJ+bZoDictxcL1Av+UKvGdn6Lp1Ww7SpsAB obB4t7ZOH2jA+yeHNyL50KX8eM1P3N4gqC7c1AnEtlAN1hnz3FThTSKtprKAoxUeD+hJ ZdPJVE3PXL8xjJVWlxV9Syh3WejEnH/2ro4WXkNJHUxBBLPLNxwZnVeYLx+0ozkow4DM iIVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=b00LSgwPVIXXX8mGyqWDF6ZXt4mBscXfyvcPPH/P16Q=; b=fWFjw1JRarGIpfKJmU3/lDRTYdkOsry5ejkU3RSUVOf/P7cCs82fVMdmvQ4uD+79Yk qNnrvrPJS8wg6l8K9MgH7oLhQFlW2aHNRvqQFSx8M4o50XNenxnT7IdP49VHeti+Dds0 O5Qeit/RrUzEq2+AW5zb6HNOKTjkWG0J8X0PTxnnuvY6iGwHfSQwl3WjYVspbU4R4kpk UPgsdElUTyz6xHx2ySENG2jLqUkVhb7Fq0L5UwniNC6Lky0UqgqCoISrlZYrkuXnOM+o pQ1DJsHsPZuUSTFVzDKgA7E+TM1NrUJxHX2UYHw8gBQas3Z10+GyY5C6CFoX6vqjttBV xySg== X-Gm-Message-State: APjAAAWV+vZ82sqLwNKW3STGnWUVQM+SpMX+k3rtDp7UDfQJonTwHW+Q mSC2xsNWu1bd62lixyO4CG4= X-Google-Smtp-Source: APXvYqw05svK8cplxAoKZlnLrm3MhxewWNBR2JlnywiVuJ+S0B604WZAntTA7+Cev6K64ACNSNXZzw== X-Received: by 2002:adf:e547:: with SMTP id z7mr1393152wrm.295.1553154506317; Thu, 21 Mar 2019 00:48:26 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id m6sm7199265wrr.53.2019.03.21.00.48.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Mar 2019 00:48:25 -0700 (PDT) From: "Valery Smyslov" To: "'Tobias Guggemos'" , "'Tero Kivinen'" , References: <23688.31062.426962.985107@fireball.acr.fi> <01c701d4da41$3c61f890$b525e9b0$@gmail.com> <6454f07af680410e918431971f3489f2@XCH-ALN-010.cisco.com> <001e01d4ddac$5502d770$ff088650$@nm.ifi.lmu.de> <059301d4de2d$faa5a000$eff0e000$@gmail.com> <000a01d4de79$31d3cc00$957b6400$@nm.ifi.lmu.de> <06b701d4deed$706f1310$514d3930$@gmail.com> <014001d4df3f$492fcc70$db8f6550$@nm.ifi.lmu.de> In-Reply-To: <014001d4df3f$492fcc70$db8f6550$@nm.ifi.lmu.de> Date: Thu, 21 Mar 2019 10:48:22 +0300 Message-ID: <077201d4dfba$75e80cc0$61b82640$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQICh2VSFjkuY0eSQrYh6iGxPAV2+AHuWDWOAmpINo8CGcLbUAMGThUEAw641ZkCdcCrbQDsH4oopTr6xRA= Content-Language: ru Archived-At: Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 07:48:30 -0000 [I snipped some text to make message more readable] > > > I know that the main motivation for IKE_INTERMEDIATE is PQKE, but I > > > don't feel that we're at a point where we can actually say for sure > > > that this is the one and only way for PQKE and, thus, I'd prefer > > IKE_INTERMEDIATE to be completely independent of any Key Exchange > > related stuff! > > > > That's my intention too, we are in concert here. > > And in my opinion the draft makes no hint that QSKE is the only application, > > quite the opposite. > > You're right it doesn't, but it leaves the impression that it's designed for the use case. It's a false impression :-) > > > I'm not an expert in this kind of (framework) documents at all. My > > > question is, is an empty IKE_INTERMEDIATE a potential security issue? > > > > Which security issue? Can you please elaborate? > > Ok, I'm basically only speculating now: > 1) What about an attacker who just sends empty messages to an responder supporting IKE_INTERMEDIATE? > The state machine will never leave the state of waiting for an IKE_AUTH. > 2) What about a quantum attacker who breaks the IKE_INIT (in real-time) and just floods the responder with > empty IKE_INTERMEDIATE. > > This might not be a very realistic attack, but my question is, can you make sure that it is not an issue? In my view it's not how INTERMEDIATE should be dealt with. Firstly, sole exchange of INTERMEDIATE_EXCHANGE_SUPPORTED notifications is not enough condition for INTERMEDIATE exchange to happen. There must be some other conditions, that must be defined in the documents utilizing this exchange. Moreover, both peers must have common view on how many such exchanges should be done and in what order. Secondly, I cannot see any relevance to empty SK payload in the examples you provided. The same attacks can happen regardless on whether the content of SK is empty or not. For example, in hybrid-qske the initiator could initiate more INTERMEDIATE exchanges than the number of negotiated PQ methods, so that the responder would receive the unexpected request. And thirdly, the similar situation could also take place even with core IKEv2, if the initiator sends, say INFORMATIONAL instead of IKE_AUTH. So, in your examples above, the responder would treat unexpected INTERMEDIATE as inappropriate exchange (as it would treat there any exchange except for IKE_AUTH). Since ICV is verified, there is a clear protocol error and responder would silently delete half-created SA. However, if your implementation is smart enough and you are concerned about Quantum Computers breaking initial DH (your example 2), then you can just ignore unexpected exchange and continue to wait some (short period of) time for a proper one. If it wouldn't come - delete SA. > The important thing I'd like to mention: > I think, if we can avoid an issue by design - by excluding an option we don't necessarily need - we should do > that and not the other way around. I don't see it's an issue. More precisely, I can see it as a generic issue, not particularly concerned with empty INTERMEDIATE messages. > > Successful exchange of INTERMEDIATE_EXCHANGE_SUPPORTED notification > > only confirms that both parties support INTERMEDIATE exchange. It is not > > enough condition to start doing INTERMEDIATE exchange. > > A separate documents that utilize this exchange MUST define the conditions > > in which peers would do INTERMEDIATE exchanges, the conditions for > > ending the sequence of these exchanges and start IKE_AUTH, and the > > payloads these exchanges should carry. > > > > Is it OK for you? > > At least, it makes it clearer! OK. > I personally would like to make it explicitly impossible to support IKE_INTERMEDIATE with an empty payload. > (unless there is an application using an empty payload as some kind of a response) See above. > The current wording says: The implementation MAY support IKE_INTERMEDIATE but MUST NOT use it > without an application. > My preferred approach would be: The implementation MUST NOT support IKE_INTERMEDIATE without an > application. OK, how about: The implementation MUST NOT negotiate support for INTERMEDIATE without an application. > My thinking is, you'd like to negotiate an application (e.g. PQKE) which needs IKE_INTERMEDIATE, so it's all > about the application anyway. > So if the application needs IKE_INTERMEDIATE, it wouldn't work if IKE_INTERMEDIATE is not supported > anyways. It depends. I can imagine extensions that can run w/o INTERMEDIATE, but can benefit if it is supported... > > > I'd completely remove the second part and only write: > > > > > > The keys SK_e[i/r] and SK_a[i/r] for the Encrypted payload in the > > > INTERMEDIATE exchanges are computed in a standard fashion, as > > defined > > > in the Section 2.14 of [RFC7296]. Every subsequent INTERMEDIATE > > > exchange uses the most recently calculated keys before this exchange > > > is started. > > > > I'm generally OK with this, however I'm a bit concerned here that > > implementers might get a wrong impression that the keys calculated in > > IKE_SA_INIT never changes. The text that you snipped has the only purpose > > to warn implementers that this might not be the case. > > Don't you think it's a valid concern? > > > > It's a valid concern, but a concern which should be addressed by the document describing the key update. > On the other hand, what if the additional Key Exchange would say that you should not do that for any reason, > which would be the ruling document? > That would be even more confusing (although I admit the chances for this case are quite low). I think it's enough to add some text to this draft that warns implementers that the IKE SA keys may change as a result of INTERMEDIATE exchanges. > > > If we had an IANA registry for every payload allowed in > > > IKE_INTERMEDIATE, that could easily be updated by future documents by > > registering a new value. > > > > I don't think IANA registry is needed for that. In my opinion it's enough that > > every dependent document describes the content of INTERMEDIATE > > exchange. > > > > Look for example at INFORMATIONAL exchange. It's the same "Swiss army > > knife", and is used for a lot of purposes depending on the notifications it > > contains. > > Somehow we managed to deal with that without IANA registry that would > > list the notifications that could appear in INFORMATIONAL exchange. > > I don't see a big difference with INTERMEDIATE here, except that instead of > > notifications the dependent documents will define payload types for this > > exchange. > > > > The difference with INFORMATIONAL is, that you have a secured channel. > At the time of INTERMEDIATE, you still build this channel and, thus, I think a more conservative approach of > white-listing is better. > > That doesn't mean that an IANA registry is the right way to go, it's just one. > I'd just like to prevent any miss-use of INTERMEDIATE, as I beliebe it's a highly security critical step. > There are definitely multiple ways of doing that, but I think that should be the goal. In my opinion it's enough if dependent document define the content. > > > I don't say this is the only way to go, but I feel it's cleaner than > > > just saying it could be anything. I'd actually prefer what I mentioned > > > above, not allowing IKE_INTERMEDIATE to be implemented without > > another document defining the actual payload. > > > > Exactly, except that I'd s/implemented/used. You can implement a pure > > framework (just for the future), but you cannot use it without implementing > > another document utilizing it. > > Maybe we could replace "used" with "supported"? is "negotiated" or "advertised support for" OK here? Regards, Valery. > Regards > Tobias From nobody Thu Mar 21 01:02:18 2019 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 2675913103B for ; Thu, 21 Mar 2019 01:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-ezXpOaWUxI for ; Thu, 21 Mar 2019 01:02:10 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 1F951130F82 for ; Thu, 21 Mar 2019 01:02:10 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id p10so5518027wrq.1 for ; Thu, 21 Mar 2019 01:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=uU4HOfCxEkyAQ4rOcxZ9E9v3ATvhHFyiiB2CsEnKvwE=; b=RFRV5W62WyQo3aSI6yu1KH63JXQCLNNiSqLhGDdrUGMC6ii4r9iwncJDbxV2gK4xyO Pt4Mw1jrVtnyC6gsxT6DUY9/7DmDVOq/LCAsckz2iZ/KnEq1y6dX7o3pBWM+lZBNnTkK W+c07eQdf2r0PajYFX+lKVQinPH7T/VXA86KpnaECPiyfdf+TkVdZb1sCnPQ30qmpMyH gCJx2eYMmTdIMbSGfLnuyfs52P/enZmgRbn3Sl0aPtVh0nFPq91rlMaVoHOGXvYHHdwc Nd0u/t8mo+gcZtXbq7/OIpqG6yn+yI4hHNJm7kSq6HbC42ZIS2GFwc+LFknOcu6KxKAa NZBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=uU4HOfCxEkyAQ4rOcxZ9E9v3ATvhHFyiiB2CsEnKvwE=; b=HJHuTkeqDXpb7cROyoqHq1svFz1eiWXJhzzAoQUj0XlR+8c57He5mChj0NcMMCgZGt watHhVfcZKiI+r3zOMmqwYUpMvLRr1IpGVomZC2UxsQzLCwilx7k1huiidikdIxjGrjJ 7ZKcWYruMINcMOXtFtnVnBlqLrvQ8re8Q5fDZivIMTel6oPOo+WoFVLT+Wx/u+pF09yQ T+mDGN2S48yS2morVni2b/fe7P/IAOGS05kBR1GMqf4823Uae9RKBwUg94q1KYp+j1EK ZHguh6isKcfs1nErXSG6ENDAT1mGqJQz7aKFMxiozVlDcgSYgAMSJEwY9vQheWDjTjLD Q+Hg== X-Gm-Message-State: APjAAAW+MU4GcnXq0C+lbBGM3bl7QpNZOBFRJ0RSKCuvxHZAJEQB+CLk x1QSZnO6id2SIqqPSwo1wcE= X-Google-Smtp-Source: APXvYqySMGWjtwMjVsRmdDR7URJTx+hkgROxm7trGsvIuHmYtMC43VTdTnlmhDxICGz/JPjFWw492g== X-Received: by 2002:adf:dd4a:: with SMTP id u10mr1625857wrm.322.1553155328627; Thu, 21 Mar 2019 01:02:08 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id g10sm3204973wrq.61.2019.03.21.01.02.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Mar 2019 01:02:07 -0700 (PDT) From: "Valery Smyslov" To: "'Tobias Heider'" , "'Tobias Guggemos'" , "'Tero Kivinen'" , References: <23688.31062.426962.985107@fireball.acr.fi> <01c701d4da41$3c61f890$b525e9b0$@gmail.com> <6454f07af680410e918431971f3489f2@XCH-ALN-010.cisco.com> <001e01d4ddac$5502d770$ff088650$@nm.ifi.lmu.de> <059301d4de2d$faa5a000$eff0e000$@gmail.com> <000a01d4de79$31d3cc00$957b6400$@nm.ifi.lmu.de> <06b701d4deed$706f1310$514d3930$@gmail.com> In-Reply-To: Date: Thu, 21 Mar 2019 11:02:04 +0300 Message-ID: <077301d4dfbc$60031f10$20095d30$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQICh2VSFjkuY0eSQrYh6iGxPAV2+AHuWDWOAmpINo8CGcLbUAMGThUEAw641ZkCdcCrbQH6yHdxpTKaF/A= Content-Language: ru Archived-At: Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 08:02:17 -0000 Hi Tobias, > Hi Valery, > > >> If there is a chance that this is a potential thread (and I fear it'll be impossible to proof the opposite), my > >> feeling is that the document should say that IKE_INTERMEDIATE MUST NOT be supported without the > >> support of at least one document defining the payload. > > That is implied. I can make this more explicit, by adding something like that: > > > > Successful exchange of INTERMEDIATE_EXCHANGE_SUPPORTED > > notification only confirms that both parties support INTERMEDIATE > > exchange. It is not enough condition to start doing INTERMEDIATE exchange. > > A separate documents that utilize this exchange MUST define > > the conditions in which peers would do INTERMEDIATE exchanges, > > the conditions for ending the sequence of these exchanges and start IKE_AUTH, > > and the payloads these exchanges should carry. > > > > Is it OK for you? > I was wondering about what happens when multiple documents utilize the > IKE_INTERMEDIATE exchange > at the same time. > Can two different documents utilize a single exchange of > IKE_INTERMEDIATE messages, > or must every document add an additional exchange of IKE_INTERMEDIATE > messages? It's a good question. My idea is that each application document must define this, as well as the order of INTERMEDIATE exchanges, if it matters. So, I assume that by default each application will utilize its own INTERMEDIATE , but some applications could benefit from piggybacking. But this must be clearly described in corresponding document. > Currently the only "user" is the Hybrid PQKE draft which adds up to > seven INTERMEDIATE exchanges before the IKE_AUTH, > could i just define a draft that includes an additional payload in the > first INTERMEDIATE exchange (not knowing whether Hybrid KE is used or not) > or would i have to add an eighth INTERMEDIATE exchange? I think that corresponding application document must define this. QSKE exchanges would most probably take place before any other INTERMEDIATE exchange, since they update the keys and increase IKE SA protection, but again, it must be defined in the application documents. > I couldn't find any info on this in the current draft and i feel like > this is quite relevant for future users of the exchange. I don't think it must be defined in this draft. Instead, it must be defined in the documents utilizing this exchange. Note, that these documents will appear one by one, so every next published document must have a section describing how this application of INTERMEDIATE should deal with the already defined applications (whether it is OK to combine payloads or not, what is the relative order etc.) Regards, Valery. > Regards, > (another) Tobias From nobody Thu Mar 21 02:12:13 2019 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 8D5C51277CE for ; Thu, 21 Mar 2019 02:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 hVEma2KRls3t for ; Thu, 21 Mar 2019 02:12:10 -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 A0F08126C01 for ; Thu, 21 Mar 2019 02:12:10 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44Q1JR1FpNz358 for ; Thu, 21 Mar 2019 10:12:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1553159527; bh=y4s49ztM5vl5IaSNGomXsmJOpoj/KVgkxYRhUntcLGg=; h=Date:From:To:Subject:In-Reply-To:References; b=tVRpdoCXsRtMowtpAxvBCa8wVKrbnMff+NrF8du+Auwmjgt7ovuy0oVmDYaB/W5jS IGERceHzyhOqbE5NO5Pt1Wey+tmDZsU+EKJdFdrmKgjmw5vVs+rzx543dKON6xNwig qAcRDvd+JMvQQJj2hLRlcuNKG2EG9IQIauuYyg80= 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 Xl8fbu_8wMju for ; Thu, 21 Mar 2019 10:12:05 +0100 (CET) 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, 21 Mar 2019 10:12:04 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 9BA8631941D; Thu, 21 Mar 2019 05:12:03 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 9BA8631941D Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 926E340D358A for ; Thu, 21 Mar 2019 05:12:03 -0400 (EDT) Date: Thu, 21 Mar 2019 05:12:03 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <077301d4dfbc$60031f10$20095d30$@gmail.com> Message-ID: References: <23688.31062.426962.985107@fireball.acr.fi> <01c701d4da41$3c61f890$b525e9b0$@gmail.com> <6454f07af680410e918431971f3489f2@XCH-ALN-010.cisco.com> <001e01d4ddac$5502d770$ff088650$@nm.ifi.lmu.de> <059301d4de2d$faa5a000$eff0e000$@gmail.com> <000a01d4de79$31d3cc00$957b6400$@nm.ifi.lmu.de> <06b701d4deed$706f1310$514d3930$@gmail.com> <077301d4dfbc$60031f10$20095d30$@gmail.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 09:12:12 -0000 On Thu, 21 Mar 2019, Valery Smyslov wrote: > It's a good question. My idea is that each application document > must define this, as well as the order of INTERMEDIATE exchanges, > if it matters. So, I assume that by default each application > will utilize its own INTERMEDIATE , but some applications could > benefit from piggybacking. But this must be clearly described > in corresponding document. I would think it quite differently. Each protocol extension just puts payloads in the IKE_SA_INIT and once that one becomes too big, the IKE daemon starts to split it up in an IKE_SA_INIT and IKE_INTERMEDIATE. This document defines what goes into IKE_SA_INIT, so the rest (eg new stuff) ca ngo into IKE_INTERMEDIATE. > I think that corresponding application document must define this. I don't see why they would need to do that? For example, imagine I add a large notify payload that would cause IKE_SA_INIT fragmentation, the IKE daemon looks what payloads to put in IKE_SA_INIT and the non-listed Notify payload would be put into one or more IKE_INTERMEDIATE exchanges. Paul From nobody Thu Mar 21 02:16:10 2019 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 481361277CE for ; Thu, 21 Mar 2019 02:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RSdCyyRgt1r for ; Thu, 21 Mar 2019 02:16:05 -0700 (PDT) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB2A2126C01 for ; Thu, 21 Mar 2019 02:16:04 -0700 (PDT) Received: from [192.168.17.134] (unknown [83.135.23.200]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: heidert) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id C61D13683F0; Thu, 21 Mar 2019 10:16:02 +0100 (CET) To: Valery Smyslov , 'Tobias Guggemos' , 'Tero Kivinen' , ipsec@ietf.org References: <23688.31062.426962.985107@fireball.acr.fi> <01c701d4da41$3c61f890$b525e9b0$@gmail.com> <6454f07af680410e918431971f3489f2@XCH-ALN-010.cisco.com> <001e01d4ddac$5502d770$ff088650$@nm.ifi.lmu.de> <059301d4de2d$faa5a000$eff0e000$@gmail.com> <000a01d4de79$31d3cc00$957b6400$@nm.ifi.lmu.de> <06b701d4deed$706f1310$514d3930$@gmail.com> <077301d4dfbc$60031f10$20095d30$@gmail.com> From: Tobias Heider Message-ID: <2f35bfb4-1d83-fb5e-c686-76c34f1424a5@nm.ifi.lmu.de> Date: Thu, 21 Mar 2019 10:16:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <077301d4dfbc$60031f10$20095d30$@gmail.com> Content-Type: multipart/alternative; boundary="------------FD7A48888080A6985DA32EC7" Content-Language: en-US-large Archived-At: Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 09:16:09 -0000 This is a multi-part message in MIME format. --------------FD7A48888080A6985DA32EC7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit >>>> If there is a chance that this is a potential thread (and I >>>> fear it'll be impossible to proof the opposite), my feeling is >>>> that the document should say that IKE_INTERMEDIATE MUST NOT be >>>> supported without the support of at least one document defining >>>> the payload. >>> That is implied. I can make this more explicit, by adding >>> something like that: >>> >>> Successful exchange of INTERMEDIATE_EXCHANGE_SUPPORTED >>> notification only confirms that both parties support >>> INTERMEDIATE exchange. It is not enough condition to start doing >>> INTERMEDIATE exchange. A separate documents that utilize this >>> exchange MUST define the conditions in which peers would do >>> INTERMEDIATE exchanges, the conditions for ending the sequence of >>> these exchanges and start IKE_AUTH, and the payloads these >>> exchanges should carry. >>> >>> Is it OK for you? >> I was wondering about what happens when multiple documents utilize >> the IKE_INTERMEDIATE exchange at the same time. Can two different >> documents utilize a single exchange of IKE_INTERMEDIATE messages, >> or must every document add an additional exchange of >> IKE_INTERMEDIATE messages? > > It's a good question. My idea is that each application document must > define this, as well as the order of INTERMEDIATE exchanges, if it > matters. So, I assume that by default each application will utilize > its own INTERMEDIATE , but some applications could benefit from > piggybacking. But this must be clearly described in corresponding > document In that case, wouldn't it be better to not have a single IKE_INTERMEDIATE exchange type ID but one for each document and use-case. That way an implementation could easily check the exchange type, check if the SA is in a state to accept this specific type of exchange, and then check if the exchange type and contained payloads match. IMO this would allow packet handling and parsing implementations a lot more robust and allow to filter corrupt/unexpected packets early. >> Currently the only "user" is the Hybrid PQKE draft which adds up >> to seven INTERMEDIATE exchanges before the IKE_AUTH, could i just >> define a draft that includes an additional payload in the first >> INTERMEDIATE exchange (not knowing whether Hybrid KE is used or >> not) or would i have to add an eighth INTERMEDIATE exchange? > > I think that corresponding application document must define this. > QSKE exchanges would most probably take place before any other > INTERMEDIATE exchange, since they update the keys and increase IKE SA > protection, but again, it must be defined in the application > documents. >> I couldn't find any info on this in the current draft and i feel >> like this is quite relevant for future users of the exchange. > > I don't think it must be defined in this draft. Instead, it must be > defined in the documents utilizing this exchange. Note, that these > documents will appear one by one, so every next published document > must have a section describing how this application of INTERMEDIATE > should deal with the already defined applications (whether it is OK > to combine payloads or not, what is the relative order etc.) Then we must be incredibly cautious that every document using IKE_INTERMEDIATE specifies explicitly what happens if other known users are used in conjunction, as well as what happens for every possible combination of other known users. If one document for example would specify to always be the first INTERMEDIATE exchange, it would block any following document from doing the same without losing compatibility, as there clearly can't be two first INTERMEDIATE exchanges. In that case, isn't the effort of having to explicitly specify every single case actually the same as if every of these documents would simply specify it's own exchange that takes place between IKE_SA_INIT and IKE_AUTH? What is the advantage of using INTERMEDIATE then, instead of just rolling your own solution? Regards, Tobias --------------FD7A48888080A6985DA32EC7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit >>>> If there is a chance that this is a potential thread (and I >>>> fear it'll be impossible to proof the opposite), my feeling is >>>> that the document should say that IKE_INTERMEDIATE MUST NOT be >>>> supported without the support of at least one document defining >>>> the payload. >>> That is implied. I can make this more explicit, by adding >>> something like that: >>> >>> Successful exchange of INTERMEDIATE_EXCHANGE_SUPPORTED >>> notification only confirms that both parties support >>> INTERMEDIATE exchange. It is not enough condition to start doing >>> INTERMEDIATE exchange. A separate documents that utilize this >>> exchange MUST define the conditions in which peers would do >>> INTERMEDIATE exchanges, the conditions for ending the sequence of >>> these exchanges and start IKE_AUTH, and the payloads these >>> exchanges should carry. >>> >>> Is it OK for you? >> I was wondering about what happens when multiple documents utilize >> the IKE_INTERMEDIATE exchange at the same time. Can two different >> documents utilize a single exchange of IKE_INTERMEDIATE messages, >> or must every document add an additional exchange of >> IKE_INTERMEDIATE messages? > > It's a good question. My idea is that each application document must > define this, as well as the order of INTERMEDIATE exchanges, if it > matters. So, I assume that by default each application will utilize > its own INTERMEDIATE , but some applications could benefit from > piggybacking. But this must be clearly described in corresponding > document
In that case, wouldn't it be better to not have a single IKE_INTERMEDIATE exchange type
ID but one for each document and use-case.
That way an implementation could easily check the exchange type, check if the SA is in
a state to accept this specific type of exchange, and then check if the exchange type and
contained payloads match. IMO this would allow packet handling and parsing
implementations a lot more robust and allow to filter corrupt/unexpected packets early.

>> Currently the only "user" is the Hybrid PQKE draft which adds up >> to seven INTERMEDIATE exchanges before the IKE_AUTH, could i just >> define a draft that includes an additional payload in the first >> INTERMEDIATE exchange (not knowing whether Hybrid KE is used or >> not) or would i have to add an eighth INTERMEDIATE exchange? > > I think that corresponding application document must define this. > QSKE exchanges would most probably take place before any other > INTERMEDIATE exchange, since they update the keys and increase IKE SA > protection, but again, it must be defined in the application > documents. >> I couldn't find any info on this in the current draft and i feel >> like this is quite relevant for future users of the exchange. > > I don't think it must be defined in this draft. Instead, it must be > defined in the documents utilizing this exchange. Note, that these > documents will appear one by one, so every next published document > must have a section describing how this application of INTERMEDIATE > should deal with the already defined applications (whether it is OK > to combine payloads or not, what is the relative order etc.) Then we must be incredibly cautious that every document using IKE_INTERMEDIATE
specifies explicitly what happens if other known users are used in conjunction, as well as
what happens for every possible combination of other known users.
If one document for example would specify to always be the first INTERMEDIATE
exchange, it would block any following document from doing the same without losing compatibility, as there clearly can't be two first INTERMEDIATE exchanges.

In that case, isn't the effort of having to explicitly specify every single case actually the
same as if every of these documents would simply specify it's own exchange that
takes place between IKE_SA_INIT and IKE_AUTH?
What is the advantage of using INTERMEDIATE then, instead of just rolling your own
solution?

Regards,
Tobias

--------------FD7A48888080A6985DA32EC7-- From nobody Thu Mar 21 02:26:02 2019 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 E1493130EAB for ; Thu, 21 Mar 2019 02:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93ihn-qnulHd for ; Thu, 21 Mar 2019 02:25:59 -0700 (PDT) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CD921277CE for ; Thu, 21 Mar 2019 02:25:59 -0700 (PDT) Received: from [192.168.17.134] (unknown [83.135.23.200]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: heidert) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id 81D5C36159B; Thu, 21 Mar 2019 10:25:57 +0100 (CET) To: Paul Wouters , "ipsec@ietf.org WG" References: <23688.31062.426962.985107@fireball.acr.fi> <01c701d4da41$3c61f890$b525e9b0$@gmail.com> <6454f07af680410e918431971f3489f2@XCH-ALN-010.cisco.com> <001e01d4ddac$5502d770$ff088650$@nm.ifi.lmu.de> <059301d4de2d$faa5a000$eff0e000$@gmail.com> <000a01d4de79$31d3cc00$957b6400$@nm.ifi.lmu.de> <06b701d4deed$706f1310$514d3930$@gmail.com> <077301d4dfbc$60031f10$20095d30$@gmail.com> From: Tobias Heider Message-ID: Date: Thu, 21 Mar 2019 10:25:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US-large Archived-At: Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 09:26:01 -0000 >> It's a good question. My idea is that each application document >> must define this, as well as the order of INTERMEDIATE exchanges, >> if it matters. So, I assume that by default each application >> will utilize its own INTERMEDIATE , but some applications could >> benefit from piggybacking. But this must be clearly described >> in corresponding document. > > I would think it quite differently. Each protocol extension just puts > payloads in the IKE_SA_INIT and once that one becomes too big, the > IKE daemon starts to split it up in an IKE_SA_INIT and IKE_INTERMEDIATE. > This document defines what goes into IKE_SA_INIT, so the rest (eg new > stuff) ca ngo into IKE_INTERMEDIATE. > I like that idea actually. It would be nice though to have some fixed order for additional payloads, as we always had a fixed order for expected payloads. >> I think that corresponding application document must define this. > > I don't see why they would need to do that? For example, imagine I > add a large notify payload that would cause IKE_SA_INIT fragmentation, > the IKE daemon looks what payloads to put in IKE_SA_INIT and the > non-listed Notify payload would be put into one or more > IKE_INTERMEDIATE exchanges. Indeed. I think the main advantage of IKE_INTERMEDIATE could be that specific "users" would not have to take care of this in their documents because it is solved once in a generic way. Regards, Tobias From nobody Thu Mar 21 03:13:44 2019 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 2F642130F63; Thu, 21 Mar 2019 03:13:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Cc: David Waltermire , The IESG , ipsecme-chairs@ietf.org, ekr@rtfm.com, ipsec@ietf.org, david.waltermire@nist.gov, draft-ietf-ipsecme-split-dns@ietf.org, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155316320918.10009.13657421622656796922.idtracker@ietfa.amsl.com> Date: Thu, 21 Mar 2019 03:13:29 -0700 Archived-At: Subject: [IPsec] Protocol Action: 'Split DNS Configuration for IKEv2' to Proposed Standard (draft-ietf-ipsecme-split-dns-17.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 10:13:29 -0000 The IESG has approved the following document: - 'Split DNS Configuration for IKEv2' (draft-ietf-ipsecme-split-dns-17.txt) as Proposed Standard This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Benjamin Kaduk and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ Technical Summary The IPsecME working group has obsoleted the IKEv1 protocol in favor of the IKEv2 protocol many years ago. However, IKEv2 never had an option to send one or more DNS domains from a Remote Access VPN server to the VPN clients. IKEv1 did have that option via XAUTH/ModeCFG. This document defines two Configuration Payload Attribute Types for the IKEv2 protocol that add support for private DNS domains. These domains are intended to be resolved using DNS servers reachable through an IPsec connection, while leaving all other DNS resolution unchanged. This approach of resolving a subset of domains using non- public DNS servers is referred to as "Split DNS". Working Group Summary The draft had no controversy. The draft has been discussed frequently on the mailing list and a lot of comments have been provided on list by people other than the authors, to include implementors. In addition to mailing list discussions, the draft has been presented and discussed during the last 3 IETF (98, 99, 100) meetings. The draft has been supported by the participants in the room on various hums for the specific design decisions made in the document. Document Quality\ The document is supported by implementors, and authors also represent a subset of implementors. Interoperability of the DNS domain has been confirmed by at least three independent implementations. DNSSEC TA support has not seen an implementation or interoperability test, but the format is sufficiently simple that no one is worried. Personnel The Document Shepherd is David Waltermire. The responsible Area Director is Eric Rescorla. From nobody Thu Mar 21 04:37:12 2019 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 9E8B0128661 for ; Thu, 21 Mar 2019 04:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 It2qQBSQHKVA for ; Thu, 21 Mar 2019 04:37:08 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 ADD81127964 for ; Thu, 21 Mar 2019 04:37:07 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id z11so2383157wmi.0 for ; Thu, 21 Mar 2019 04:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=8o1+G0L9a5Kv+urnwU1u1ZNalqEsav9SPT6EA32TNLA=; b=t3T2aKaAFa3nnAj9izAJNFzqn4lL2aDRmz1WkrRQOP1uStHMMBXbiKRK4HSfVtEOLE ijjsNIOQ1iCzFOEv5fNXQxVtcdbj+saBXJjpHV7185ZrJCeB6xUbpQVl2ucgBnvmFfPH KMm0oXWcjBGGBkPXsmZF5D5w1uOkJcfJO8wKJgGi7MfsoczsPJVOJpsob1TGDmLywHrv fa5b6AKzjJtmWIBwzOw+l//qCGVJ38pr+BO0duT8wUve9UQuZIsNqH7wR8do920KgOYI miMooTyeBqitQf/qHUTLh3SDotOa3vU7FEyMm0QuznPi4snbIv1Yp0WRH4d015qm4PVT Lryg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=8o1+G0L9a5Kv+urnwU1u1ZNalqEsav9SPT6EA32TNLA=; b=cLZFZWBf5ZjtRZs8WyAkBtJ2fW8fUBDgoxQvoDcBY4T6JVloR1OKMitV+R6sQC7lUk lC0hPK8zLGqxVxhw6Hy/VpuMQnsf5Etb8urUecycpfglAlZUOZv2FgETzzTWTcAFqPts PZWMGARabJ5vbvNinE5yhcBk+RwONNJXGyqJUeaovIu13byGwdF78whw0x7t664Sb3wW DHSTWYBgwU44IaDNvA92F3mjTgqOInOv23WIMgM09pcYi61DHVRPLyAvKTMgKiGuxU1Q rUqb7ZCngcv7PrjijrBCWJBrOsgsnNdecs5wFoKrhqxpb8ntzI0UuEIONC9gFePhbN82 ev5A== X-Gm-Message-State: APjAAAXfoVKp0k9c40gRFlk35i2nC8fkoyoBKO0E5JW93g/r0EvvIDqB /dfxRUjHpU3OaUHzyhsz+oNnYSMe X-Google-Smtp-Source: APXvYqxM51wvVqf2VgTA58rkBS+vqF52y0yPOTqI3NHVdBrWOZwJk9owQlT6LKG7S80+BwDeqFcF8w== X-Received: by 2002:a1c:7918:: with SMTP id l24mr1988121wme.29.1553168225764; Thu, 21 Mar 2019 04:37:05 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id q19sm5957251wmq.23.2019.03.21.04.37.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Mar 2019 04:37:04 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" , References: <23688.31062.426962.985107@fireball.acr.fi> <01c701d4da41$3c61f890$b525e9b0$@gmail.com> <6454f07af680410e918431971f3489f2@XCH-ALN-010.cisco.com> <001e01d4ddac$5502d770$ff088650$@nm.ifi.lmu.de> <059301d4de2d$faa5a000$eff0e000$@gmail.com> <000a01d4de79$31d3cc00$957b6400$@nm.ifi.lmu.de> <06b701d4deed$706f1310$514d3930$@gmail.com> <077301d4dfbc$60031f10$20095d30$@gmail.com> In-Reply-To: Date: Thu, 21 Mar 2019 14:37:01 +0300 Message-ID: <079d01d4dfda$67159800$3540c800$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQICh2VSFjkuY0eSQrYh6iGxPAV2+AHuWDWOAmpINo8CGcLbUAMGThUEAw641ZkCdcCrbQH6yHdxAYDYIUoBRdt7SqUcrbfw Content-Language: ru Archived-At: Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 11:37:10 -0000 Hi Paul, > > It's a good question. My idea is that each application document > > must define this, as well as the order of INTERMEDIATE exchanges, > > if it matters. So, I assume that by default each application > > will utilize its own INTERMEDIATE , but some applications could > > benefit from piggybacking. But this must be clearly described > > in corresponding document. > > I would think it quite differently. Each protocol extension just puts > payloads in the IKE_SA_INIT and once that one becomes too big, the > IKE daemon starts to split it up in an IKE_SA_INIT and IKE_INTERMEDIATE. > This document defines what goes into IKE_SA_INIT, so the rest (eg new > stuff) ca ngo into IKE_INTERMEDIATE. >From implementer's point of view it's better if the possible content of each message be clearly defined. It simplifies parsing message and state machine... > > I think that corresponding application document must define this. > > I don't see why they would need to do that? For example, imagine I > add a large notify payload that would cause IKE_SA_INIT fragmentation, > the IKE daemon looks what payloads to put in IKE_SA_INIT and the > non-listed Notify payload would be put into one or more > IKE_INTERMEDIATE exchanges. I don't see any problem here. You can write an application document saying that once INTERMEDIATE is negotiated (and some other thing happened, indicating mutual support for the following), the peers may offload there whatever they want (and makes sense) from IKE_SA_INIT. I just don't want such things take place sporadically, by sole fact that INTERMEDIATE is supported. Otherwise Tobias G.'s concerns are applied. Regards, Valery. > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Mar 21 04:44:45 2019 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 185A3128661 for ; Thu, 21 Mar 2019 04:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZv00yss82Zu for ; Thu, 21 Mar 2019 04:44:42 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 258AE127964 for ; Thu, 21 Mar 2019 04:44:42 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id a184so2366688wma.2 for ; Thu, 21 Mar 2019 04:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=QeyBWLb/W2U7eN8wwnuAC+yXp/UuI+9/71s0WyfgW54=; b=k8Hnyp+P0E+mKtQKO2hEcygJsw1KH1GBVT0sqV2orHCubVBself/g7foukURqmDC2d EmM6msRkc9w2tF/TI5M+h5p+nTyYI8MG4nhX0l4cL7O4+JYMlAko2lhGn2XLk341M+C3 7xlQ2Hl/5wzyUGonA9ex/2rkRNK0Y5VTgvuyPNVgYfxSO6wQodT/q5z9S8O6amBtaWIu Q+u70UqJMo5ZFQLZtWQ9n8i6xQ+DvkkY4l/GVqfisgPYLjTUzH1lYeDA7KUzKeiDWuE7 xYR9g0QSZZFAkC0fIK2YzZoTvxgGYAgJP1lTXaPNWZ7Zocp7cy7lHB7cJ8OTZrJZ5BvW tf6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=QeyBWLb/W2U7eN8wwnuAC+yXp/UuI+9/71s0WyfgW54=; b=erUR7yCcRRFUn4kDg/OwnMGEad+OBEKpEhb24vs4UeLD/OfYF2Bap1g4ZvF9NNk3hz Zpb3al9mO6O4rkGMA+qjUrUMt/yuPLdIHFlrZ9RLLD5j1KLE+CoeFWqXG+oVUeK6v1og WNS/M0zy7Do1NikOPOx/5aC2BpMRGsaQGlC1dgvg1a041wPohK+8rS6wr1QzowzALeGj syztboZ59Edxw/y/n9FmXskrT9hfxLrpGe174ju4/jd46n3s5aSgPgL+enCG6+muRjCP mhX/1wWXumF5mlYrvezG4my/h9Wz7NnOmmWobtTaNKT0agQ19IEHnuuRwYRk4OTmp0fr 3CIA== X-Gm-Message-State: APjAAAVP3uVPnFblJHI3sWbHArEi5OoTMfuBmrZK4A7RnzETLY+VfnMc ZjecsLDR45DsljLXu9twuhs= X-Google-Smtp-Source: APXvYqzHo+YVxzy3IBizNtC8sZH4pJ/dw+23V11xpiYTeY73ZWQIuMLGEUIiTptKqz7pFjtfjywwqQ== X-Received: by 2002:a1c:7dd7:: with SMTP id y206mr2202871wmc.81.1553168680737; Thu, 21 Mar 2019 04:44:40 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id b3sm5942902wrx.57.2019.03.21.04.44.39 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Mar 2019 04:44:39 -0700 (PDT) From: "Valery Smyslov" To: "'Tobias Heider'" , "'Tobias Guggemos'" , "'Tero Kivinen'" , References: <23688.31062.426962.985107@fireball.acr.fi> <01c701d4da41$3c61f890$b525e9b0$@gmail.com> <6454f07af680410e918431971f3489f2@XCH-ALN-010.cisco.com> <001e01d4ddac$5502d770$ff088650$@nm.ifi.lmu.de> <059301d4de2d$faa5a000$eff0e000$@gmail.com> <000a01d4de79$31d3cc00$957b6400$@nm.ifi.lmu.de> <06b701d4deed$706f1310$514d3930$@gmail.com> <077301d4dfbc$60031f10$20095d30$@gmail.com> <2f35bfb4-1d83-fb5e-c686-76c34f1424a5@nm.ifi.lmu.de> In-Reply-To: <2f35bfb4-1d83-fb5e-c686-76c34f1424a5@nm.ifi.lmu.de> Date: Thu, 21 Mar 2019 14:44:36 +0300 Message-ID: <079e01d4dfdb$767889f0$63699dd0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_079F_01D4DFF4.9BC74890" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQICh2VSFjkuY0eSQrYh6iGxPAV2+AHuWDWOAmpINo8CGcLbUAMGThUEAw641ZkCdcCrbQH6yHdxAYDYIUoBeY1yhaUbE0NQ Content-Language: ru Archived-At: Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 11:44:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_079F_01D4DFF4.9BC74890 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable In that case, isn't the effort of having to explicitly specify every = single case actually the=20 same as if every of these documents would simply specify it's own = exchange that takes place between IKE_SA_INIT and IKE_AUTH? What is the advantage of using INTERMEDIATE then, instead of just = rolling your own solution? The advantage is that some common things (like authentication of the intermediate exchange, its protection, error handling = etc.) remain the same. So you don=E2=80=99t need to specify this = again and you can have a single piece of code for this. Note, that we don=E2=80=99t have separate exchanges for e.g. = deleting SAs, reporting errors, liveness checking, - it=E2=80=99s a single = INFORMATIONAL that is used for all these (and many other) purposes. Regards, Valery Regards, Tobias ------=_NextPart_000_079F_01D4DFF4.9BC74890 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

In = that case, isn't the effort of having to explicitly specify every single = case actually the
same as if every of these documents would simply = specify it's own exchange that
takes place between IKE_SA_INIT and = IKE_AUTH?
What is the advantage of using INTERMEDIATE then, = instead of just rolling your own
solution?

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The advantage = is that some common things (like = authentication
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = of the intermediate exchange, its protection, error handling = etc.)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 remain = the same. So you don=E2=80=99t need to specify this = again
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and you = can have a single piece of code for = this.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Note, that we don=E2=80=99t have separate exchanges for e.g. deleting = SAs,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 reporting = errors, liveness checking, - it=E2=80=99s a single = INFORMATIONAL
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = that is used for all these (and many other) = purposes.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Regards,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Valery


Regards,
Tobias

------=_NextPart_000_079F_01D4DFF4.9BC74890-- From nobody Thu Mar 21 04:47:13 2019 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 91852127964 for ; Thu, 21 Mar 2019 04:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 roK4r30T5hFu for ; Thu, 21 Mar 2019 04:47:10 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 D4F1C12795E for ; Thu, 21 Mar 2019 04:47:09 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id j9so6214868wrn.6 for ; Thu, 21 Mar 2019 04:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=st/hQhXxdil/1sCFWX6eHUexcJv5QpfTjn6Dw3F30uA=; b=HXJ9Vv6yW9silGmwJwh+0l3XFmZlYnQ3WXaq+dwCOdhcn42nsWjWPNtzxEKmeqj97E qzKZkGVDdUUKhXn5fWktLbO9Cov4vSEY9V2xvZA5KR3AJnKeOob3RFDj0DV4Xpv4V/JE XqDyMBzy4F/FVF1VJbo2deWQQR2ZDn8o35HTMY9HlhArA8fJNLX3MCaWJ60qjcLZjYck rsnjn3b+ro7N3biW8kz5ToTYUCuFhBG9KXSU8DaOU54FA6nrJ1/ley53gECfaKDBAyEZ nl6uYjeRbDYMimE8IHmPvVNye1br0zq5KiZwQV+hk+a/5SBLgmC2o5YARMXthPZIe5qT Hdbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=st/hQhXxdil/1sCFWX6eHUexcJv5QpfTjn6Dw3F30uA=; b=VHjV1O+fcs/RAvnw6flNgQV4D9zW8XTx/falB6PRWPA6+UmvrcvAS02ATSg1r6agj4 6RX2LVY4gUsrul4B1HjwI9PAkhv8M9HroXfnV21pudtWXhcBg0DNXcQmpQX+KDxG1PHV jGeVKG4vAlVt+8vCWm9SZmyCsw82OW8ZeRpBOiFpvYBsLMLo16jCeQzlf5COjLcYfivK 9fmRrSglg/6oKD3kwkM0aBR2U/KtjnQtb0K+mOa4f/VV3xdfVfrz1fr1nMgJfXWfQ80F D9Uuxn/ME1/puPBdSUL7AYOCBt53LMv55si5pR/K9w+O7H6AxJ46cuerApH5JRJU6kV+ 1dlQ== X-Gm-Message-State: APjAAAW+sZx54bzwAZloNJ03xyeJZsal0r1IJ7S2JQUlh+90IWasFIbK rwDmp88E12gGkOkUKHzTQ2w= X-Google-Smtp-Source: APXvYqyzW6bhkehlpU72fPidZlx/hYWbCnKNhRSv2nsLFpCjBFF29+JZrrsV8zSzvkwhFb2a22jy0g== X-Received: by 2002:a5d:5111:: with SMTP id s17mr2172111wrt.159.1553168828425; Thu, 21 Mar 2019 04:47:08 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id a20sm8014661wmb.17.2019.03.21.04.47.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Mar 2019 04:47:06 -0700 (PDT) From: "Valery Smyslov" To: "'Tobias Heider'" , "'Paul Wouters'" , References: <23688.31062.426962.985107@fireball.acr.fi> <01c701d4da41$3c61f890$b525e9b0$@gmail.com> <6454f07af680410e918431971f3489f2@XCH-ALN-010.cisco.com> <001e01d4ddac$5502d770$ff088650$@nm.ifi.lmu.de> <059301d4de2d$faa5a000$eff0e000$@gmail.com> <000a01d4de79$31d3cc00$957b6400$@nm.ifi.lmu.de> <06b701d4deed$706f1310$514d3930$@gmail.com> <077301d4dfbc$60031f10$20095d30$@gmail.com> In-Reply-To: Date: Thu, 21 Mar 2019 14:47:04 +0300 Message-ID: <07a601d4dfdb$ce2c5230$6a84f690$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQICh2VSFjkuY0eSQrYh6iGxPAV2+AHuWDWOAmpINo8CGcLbUAMGThUEAw641ZkCdcCrbQH6yHdxAYDYIUoBRdt7SgIfEFY1pQu6epA= Content-Language: ru Archived-At: Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 11:47:12 -0000 > > I would think it quite differently. Each protocol extension just puts > > payloads in the IKE_SA_INIT and once that one becomes too big, the > > IKE daemon starts to split it up in an IKE_SA_INIT and IKE_INTERMEDIATE. > > This document defines what goes into IKE_SA_INIT, so the rest (eg new > > stuff) ca ngo into IKE_INTERMEDIATE. > > > I like that idea actually. It would be nice though to have some fixed > order for > additional payloads, as we always had a fixed order for expected payloads. IKEv2 has no restrictions on payloads order. > >> I think that corresponding application document must define this. > > > > I don't see why they would need to do that? For example, imagine I > > add a large notify payload that would cause IKE_SA_INIT fragmentation, > > the IKE daemon looks what payloads to put in IKE_SA_INIT and the > > non-listed Notify payload would be put into one or more > > IKE_INTERMEDIATE exchanges. > Indeed. > I think the main advantage of IKE_INTERMEDIATE could be that specific > "users" would not have to take care of this in their documents because it is > solved once in a generic way. True. Besides specification, there is an advantage that a single piece of code will take care of some INTERMEDIATE core functions (like its authentication etc.) Regards, Valery. > Regards, > Tobias > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Mar 21 05:53:16 2019 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 0FE17131170 for ; Thu, 21 Mar 2019 05:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPlELpXsVu0t for ; Thu, 21 Mar 2019 05:53:12 -0700 (PDT) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6361312E1 for ; Thu, 21 Mar 2019 05:23:37 -0700 (PDT) Received: from [192.168.17.134] (unknown [83.135.23.200]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: heidert) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id D32C535C138; Thu, 21 Mar 2019 13:23:35 +0100 (CET) To: Valery Smyslov , 'Paul Wouters' , ipsec@ietf.org References: <23688.31062.426962.985107@fireball.acr.fi> <01c701d4da41$3c61f890$b525e9b0$@gmail.com> <6454f07af680410e918431971f3489f2@XCH-ALN-010.cisco.com> <001e01d4ddac$5502d770$ff088650$@nm.ifi.lmu.de> <059301d4de2d$faa5a000$eff0e000$@gmail.com> <000a01d4de79$31d3cc00$957b6400$@nm.ifi.lmu.de> <06b701d4deed$706f1310$514d3930$@gmail.com> <077301d4dfbc$60031f10$20095d30$@gmail.com> <07a601d4dfdb$ce2c5230$6a84f690$@gmail.com> From: Tobias Heider Message-ID: <62307254-c35e-8cef-8c57-bf2f13ffdfcf@nm.ifi.lmu.de> Date: Thu, 21 Mar 2019 13:23:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <07a601d4dfdb$ce2c5230$6a84f690$@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US-large Archived-At: Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 12:53:15 -0000 >>> I would think it quite differently. Each protocol extension just puts >>> payloads in the IKE_SA_INIT and once that one becomes too big, the >>> IKE daemon starts to split it up in an IKE_SA_INIT and IKE_INTERMEDIATE. >>> This document defines what goes into IKE_SA_INIT, so the rest (eg new >>> stuff) ca ngo into IKE_INTERMEDIATE. >>> >> I like that idea actually. It would be nice though to have some fixed >> order for >> additional payloads, as we always had a fixed order for expected payloads. > IKEv2 has no restrictions on payloads order. Right. It would have to have some if it was working the way Paul said though, because you would have to make sure at least SA, KEx, and Nx stay in the IKE_SA_INIT message or otherwise you can't use SK in the IKE_INTERMEDIATE. From nobody Thu Mar 21 08:19:59 2019 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 659C513124F for ; Thu, 21 Mar 2019 08:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbnHV4EABm6s for ; Thu, 21 Mar 2019 08:19:45 -0700 (PDT) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A670F1311C1 for ; Thu, 21 Mar 2019 08:19:44 -0700 (PDT) Received: from DESKTOP58DFL8T (unknown [IPv6:2001:4ca0:0:f297:c153:9934:5383:c5e4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: guggemos) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id EE1B135D39F; Thu, 21 Mar 2019 16:19:42 +0100 (CET) From: "Tobias Guggemos" To: "'Valery Smyslov'" , "'Tero Kivinen'" , References: <23688.31062.426962.985107@fireball.acr.fi> <01c701d4da41$3c61f890$b525e9b0$@gmail.com> <6454f07af680410e918431971f3489f2@XCH-ALN-010.cisco.com> <001e01d4ddac$5502d770$ff088650$@nm.ifi.lmu.de> <059301d4de2d$faa5a000$eff0e000$@gmail.com> <000a01d4de79$31d3cc00$957b6400$@nm.ifi.lmu.de> <06b701d4deed$706f1310$514d3930$@gmail.com> <014001d4df3f$492fcc70$db8f6550$@nm.ifi.lmu.de> <077201d4dfba$75e80cc0$61b82640$@gmail.com> In-Reply-To: <077201d4dfba$75e80cc0$61b82640$@gmail.com> Date: Thu, 21 Mar 2019 16:19:42 +0100 MIME-Version: 1.0 Message-ID: <001b01d4dff9$823fd860$86bf8920$@nm.ifi.lmu.de> X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHU2U0s6M7rbXuBv0SBwRv3SEEfn6YKvxmAgACvtICABiKNQIABBzyAgABckXCAASJaAIAATTlQgAFM0gCAAHtY0A== Content-Language: de Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha256; boundary="=-=7zCfYwSakUOxF+=-=" Archived-At: Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 15:19:57 -0000 This is a multipart message in MIME format. --=-=7zCfYwSakUOxF+=-= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >=20 > [I snipped some text to make message more readable] >=20 Same here :-) > > The important thing I'd like to mention: > > I think, if we can avoid an issue by design - by excluding an option > > we don't necessarily need - we should do that and not the other way > around. >=20 > I don't see it's an issue. More precisely, I can see it as a generic issu= e, not > particularly concerned with empty INTERMEDIATE messages. >=20 I see your point and I think making explicitly sure that support/negotitati= on of IKE_INTERMEDIATE without an application addresses the comment anyway! =20 > > The current wording says: The implementation MAY support > > IKE_INTERMEDIATE but MUST NOT use it without an application. > > My preferred approach would be: The implementation MUST NOT support > > IKE_INTERMEDIATE without an application. >=20 > OK, how about: >=20 > The implementation MUST NOT negotiate support for INTERMEDIATE > without an application. >=20 That sounds good for me.=20 The question remains if it is than necessary to negotiate INTERMEDIATE expl= icitly, but that this is something I really don't care too much! :-) > > My thinking is, you'd like to negotiate an application (e.g. PQKE) > > which needs IKE_INTERMEDIATE, so it's all about the application anyway. > > So if the application needs IKE_INTERMEDIATE, it wouldn't work if > > IKE_INTERMEDIATE is not supported anyways. >=20 > It depends. I can imagine extensions that can run w/o INTERMEDIATE, but > can benefit if it is supported... >=20 Good point! > > > > I don't say this is the only way to go, but I feel it's cleaner > > > > than just saying it could be anything. I'd actually prefer what I > > > > mentioned above, not allowing IKE_INTERMEDIATE to be implemented > > > > without > > > another document defining the actual payload. > > > > > > Exactly, except that I'd s/implemented/used. You can implement a > > > pure framework (just for the future), but you cannot use it without > > > implementing another document utilizing it. > > > > Maybe we could replace "used" with "supported"? >=20 > is "negotiated" or "advertised support for" OK here? I think I like negotiated! >=20 > Regards, > Valery. >=20 > > Regards > > Tobias --=-=7zCfYwSakUOxF+=-= Content-Transfer-Encoding: 7bit Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEyFCRjitB0A1IDrryyEcVbMgzVZ8FAlyTq40ACgkQyEcVbMgz VZ/oGggAnOy95PApeWsiUNDJpib6FjuwhobWgMRTXJ5GZKFMH7I7onvJEikeQmGi io0lGldWwEk3NP3/ml9NRaopgvIiBfc4OZkD7E+NGoAbl8BAVtZeeiQb9ktCdVDQ dSPuabKMZQzjAuLtLUdnHhgG343XlwCWPdY/Cea2O3ZYXsaje/lAqc4s1QKPssFC zflsQSMQSOeUVldpd0EGT8VxeJX6/k0ATtADtr5Jw7Lki5FAUR5/8mPhjqy3QLCG AHXmEDkI1TqUHrB42Xwp4GvtJBz5wQra9zwTFRn/f9tezM8QiS5DV9lPPmz4GImm BpLCC1HUePUuaPp381Sl9TTCJH3puQ== =3JYy -----END PGP SIGNATURE----- --=-=7zCfYwSakUOxF+=-=-- From nobody Fri Mar 22 01:49:43 2019 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 BF7CA130F32 for ; Fri, 22 Mar 2019 01:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLCAUqcG05lR for ; Fri, 22 Mar 2019 01:49:27 -0700 (PDT) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981321315F4 for ; Fri, 22 Mar 2019 01:49:26 -0700 (PDT) Received: from DESKTOP58DFL8T (ObiWan2.nm.ifi.lmu.de [141.84.218.130]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: guggemos) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id A5A74368011; Fri, 22 Mar 2019 09:49:24 +0100 (CET) From: "Tobias Guggemos" To: "'Valery Smyslov'" , "'Paul Wouters'" , References: <23688.31062.426962.985107@fireball.acr.fi> <01c701d4da41$3c61f890$b525e9b0$@gmail.com> <6454f07af680410e918431971f3489f2@XCH-ALN-010.cisco.com> <001e01d4ddac$5502d770$ff088650$@nm.ifi.lmu.de> <059301d4de2d$faa5a000$eff0e000$@gmail.com> <000a01d4de79$31d3cc00$957b6400$@nm.ifi.lmu.de> <06b701d4deed$706f1310$514d3930$@gmail.com> <077301d4dfbc$60031f10$20095d30$@gmail.com> <079d01d4dfda$67159800$3540c800$@gmail.com> In-Reply-To: <079d01d4dfda$67159800$3540c800$@gmail.com> Date: Fri, 22 Mar 2019 09:49:23 +0100 MIME-Version: 1.0 Message-ID: <002401d4e08c$25d953b0$718bfb10$@nm.ifi.lmu.de> X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHU2U0s6M7rbXuBv0SBwRv3SEEfn6YKvxmAgACvtICABiKNQIABBzyAgABckXCAASJaAIAA10YAgADGmACAABOOgIAAKIGAgAFvdeA= Content-Language: de Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha256; boundary="=-=xmfapt+igWS0/5=-=" Archived-At: Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 08:49:42 -0000 This is a multipart message in MIME format. --=-=xmfapt+igWS0/5=-= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey Paul and Valery, > Hi Paul, >=20 > > > It's a good question. My idea is that each application document must > > > define this, as well as the order of INTERMEDIATE exchanges, if it > > > matters. So, I assume that by default each application will utilize > > > its own INTERMEDIATE , but some applications could benefit from > > > piggybacking. But this must be clearly described in corresponding > > > document. > > > > I would think it quite differently. Each protocol extension just puts > > payloads in the IKE_SA_INIT and once that one becomes too big, the IKE > > daemon starts to split it up in an IKE_SA_INIT and IKE_INTERMEDIATE. > > This document defines what goes into IKE_SA_INIT, so the rest (eg new > > stuff) ca ngo into IKE_INTERMEDIATE. >=20 > From implementer's point of view it's better if the possible content > of each message be clearly defined. It simplifies parsing message and sta= te > machine... >=20 I think I go with Valery here.=20 Otherwise it feels like fragmenting IKE_SA_INIT, which was (as far as I rem= ember) not what the WG wanted and the main reason for the original IKE_AUX = draft. On the other hand, I'd also prefer if not every application uses a new INTE= RMEDIATE message, but putting all information which can be transported wit= hin one INTERMEDIATE in one single message. I think IKE_INTERMEDIATE should be to define the message and the applicatio= n should define the INTERMDIATE's payload.=20 If any application needs several consecutive IKE_INTERMEDIATE's, it needs t= o be defined there, but the default case should be *one* INTERMEDIATE. But that might be a discussion for the application's drafts and not for IKE= _INTERMEDIATE. > > > I think that corresponding application document must define this. > > > > I don't see why they would need to do that? For example, imagine I add > > a large notify payload that would cause IKE_SA_INIT fragmentation, the > > IKE daemon looks what payloads to put in IKE_SA_INIT and the > > non-listed Notify payload would be put into one or more > > IKE_INTERMEDIATE exchanges. >=20 > I don't see any problem here. You can write an application document saying > that once INTERMEDIATE is negotiated (and some other thing happened, > indicating mutual support for the following), the peers may offload there > whatever they want (and makes sense) from IKE_SA_INIT. I just don't want > such things take place sporadically, by sole fact that INTERMEDIATE is > supported. Otherwise Tobias G.'s concerns are applied. >=20 > Regards, > Valery. >=20 > > Paul > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --=-=xmfapt+igWS0/5=-= Content-Transfer-Encoding: 7bit Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEyFCRjitB0A1IDrryyEcVbMgzVZ8FAlyUoY8ACgkQyEcVbMgz VZ/eZQgAvevVzEJU7kMtLLNLx3ZQKP46iE+z65YHfKCNZexT/JNNDdYkE/93Us+r SwZetheJz0KjYJhpXkC9Y9LkQzrY54GKPQmSjzYo+U+pnoP/M5mYxfNYPF8tqCeS S9352gfdFv6BoNzRk7R35vasUyD1XREaLLl6Uoqb7ujIGOZWbcFohD2dXVDqC0Ks yyb3uEtP+icQOwljFT0WztzURZn0HT7suREnv1SV8YR0e9jVNWSypbnsmWlSoIPV v17KNrFV/l9LU2eGxJs38GNz0RxCb5U9joF3ZZ1tlgUad1nKR+lka/Iwh8pJqn8n xKFMBpmdOh1E6GireQKvcQQk38eJRQ== =Fypa -----END PGP SIGNATURE----- --=-=xmfapt+igWS0/5=-=-- From nobody Sun Mar 24 01:16:58 2019 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 6B5DD127961 for ; Sun, 24 Mar 2019 01:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 8OqiiS2HccOR for ; Sun, 24 Mar 2019 01:16:54 -0700 (PDT) Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-dm2gcc01on070b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fd01::70b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F0601224E8 for ; Sun, 24 Mar 2019 01:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cLocNMzSGEH19lf1A4lQk1wZeKGNj/WlOwmW5viuymw=; b=WmiJmkx3NAzAak0+rks+QfZhK6ep1K0slDs0vKYuj8t+rmaDKwStGWNE+RvYT/mLYyVH7MKMJDiIhUYQX+iJAMg0mGeTeY6VDsIGF5WZ0NgTfBnALqsttKQkfCg5Ailg0e3gYW1gL9GL5fdyHSlZFybpauZQ2fUQ5Sc5r7cDs7Q= Received: from SN6PR09MB3264.namprd09.prod.outlook.com (20.177.251.21) by SN6PR09MB3261.namprd09.prod.outlook.com (20.177.251.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.16; Sun, 24 Mar 2019 08:16:52 +0000 Received: from SN6PR09MB3264.namprd09.prod.outlook.com ([fe80::7011:7810:8741:71]) by SN6PR09MB3264.namprd09.prod.outlook.com ([fe80::7011:7810:8741:71%5]) with mapi id 15.20.1730.017; Sun, 24 Mar 2019 08:16:52 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: Implementations of draft-ietf-ipsecme-qr-ikev2-07 Thread-Index: AQHU4hmF1QQcrRI8bkykqO1OfSBXZw== Date: Sun, 24 Mar 2019 08:16:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [2610:20:6005:223::65] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fbbec5d9-d77f-48dd-c357-08d6b031126d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:SN6PR09MB3261; x-ms-traffictypediagnostic: SN6PR09MB3261: x-microsoft-antispam-prvs: x-forefront-prvs: 09860C2161 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(376002)(39850400004)(396003)(346002)(199004)(189003)(102836004)(486006)(97736004)(71200400001)(256004)(316002)(25786009)(7736002)(52536014)(33656002)(86362001)(71190400001)(5660300002)(14454004)(476003)(558084003)(478600001)(7696005)(6506007)(68736007)(46003)(6436002)(74316002)(4743002)(2906002)(186003)(6116002)(99286004)(19627405001)(55016002)(53936002)(6606003)(9686003)(54896002)(106356001)(81156014)(8936002)(105586002)(81166006)(8676002)(6916009); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR09MB3261; H:SN6PR09MB3264.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: d6Pd25x4uWZw9oyzEjKo1vV9EdC7OVNWIsSK/kwrlvl+jj8hw5IF/KLTwld8anFhcvLamSbUJYVIPDdsDK75tycy8MfmqL+zKjOIm5Wwfz7SR2XsmVv133933ItPhRPH/7/+VB/V06ytX4lHPYQaQwrbtdjonZNh/DPm9gl42md+Yw0ajuI0OWc8z7UPCLAYS2cdsraNOuWWEf64V8mZA7/QMaAy9TjGSpB0S0pGeW2Z8AIqxbmFH0zixQZaKlWfUXXzwnadThlqmDLwMLjMAAJym9uZ23uqPibwbmRXeVpLjcdaIyLetD71Yft3UOLQoQJ4UWx92EvSdI+vj9FNXiI8yuJoKyI14fhVcw7JWxfol2OTIhGr9+v+ac9whUOQcGjNIkZe6kDuFn8VKAIWvabJiIJr1FGfVjNuQWeGsyk= Content-Type: multipart/alternative; boundary="_000_SN6PR09MB3264D7D2D16C5C53BDCD8AF8F05D0SN6PR09MB3264namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: fbbec5d9-d77f-48dd-c357-08d6b031126d X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2019 08:16:52.7142 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR09MB3261 Archived-At: Subject: [IPsec] Implementations of draft-ietf-ipsecme-qr-ikev2-07 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 08:16:56 -0000 --_000_SN6PR09MB3264D7D2D16C5C53BDCD8AF8F05D0SN6PR09MB3264namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am working on the IESG writeup for draft-ietf-ipsecme-qr-ikev2. I'd like = to include a note about any implementations of the -07 draft. Anyone have a= n implementation? Also, have you done any interoperability testing with oth= er implementations? Thanks, Dave --_000_SN6PR09MB3264D7D2D16C5C53BDCD8AF8F05D0SN6PR09MB3264namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I am working on the IESG writeup = for draft-ietf-ipsecme-qr-ikev2. I'd like to include a no= te about any implementations of the -07 draft. Anyone have an implementatio= n? Also, have you done any interoperability testing with other implementations?


Thanks,

Dave

--_000_SN6PR09MB3264D7D2D16C5C53BDCD8AF8F05D0SN6PR09MB3264namp_-- From nobody Sun Mar 24 01:29:48 2019 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 474EB127979 for ; Sun, 24 Mar 2019 01:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQ6wYwQM4DDv for ; Sun, 24 Mar 2019 01:29:44 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 A56441277D8 for ; Sun, 24 Mar 2019 01:29:43 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id q16so5894476wmj.3 for ; Sun, 24 Mar 2019 01:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=+GpquhK+0NiSLpYsh5BkPaEbGfOnfgRanXE/eKFg31g=; b=FuiU4t5AG9ZQBHpG2kDhTCV+VvGswPBjAOMK4mbmZ4RB3azn++pNDkr9xDGUYogevM R1txB8E6wnPxPfZoLqNQtc7CzIWFYBYmsYTQtFC02uaWVsVWuxiPNxxo1bw3UclcEOyy Mq9CZqhrnzZXMc4mK72HY4WqSBvmuKwyf7/2YPjr/B6CN0tCGVaEA/Wwmw6UAtdju9vp 0yNGJcPreXXfo5cV+PUoXN/4X9zJw+9p4lSm+u08iikKdjuNyIxkZFlmiD9PD3v5AHyu qrHJbRWtCB2sA01+gbNOKtCY1BdxgL7ChITyhoQJi/XHetXHZrslpcvqUK943Ly6vb9v LSug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=+GpquhK+0NiSLpYsh5BkPaEbGfOnfgRanXE/eKFg31g=; b=IKia4i7Q1k1lbUgfFhl7aAEpAMTTLMohQqqkwaIt8lw/6iBInuqEhuHi6B0Kq1Nn9L /Yfh9kOqiRxSc6WR0esEPdt/o8p30w7CvQWM0R+d5nht7bcWtuq3Jbby7E+4uA6P4Aa+ s1OtEMcXSnzEO8mi6KbVgJjXMCgqboqscQOP18N/4gjH84ANQGNcJUA1S0EqJSxXVk3a 5BJpqw2bv/YxIKib53tvJrUxdx8tQuU57fGGRsljQmhrJQukH6qecHssz8pXi6nA5Uyr 2oEf4qJ8hCQA67MGBj62/p9cu3x9xrBGl9bMSpqhdiNwxz7mgKXx679J35QiHE2LexYN O4oQ== X-Gm-Message-State: APjAAAULHfU7Ty/p1WFnaOeq/56kwm2ozXkEuJf0BIr2S7M1YmmfmbUa AVMr5hG6RIjbQMqQiJvQ/kevLYk/Rjg= X-Google-Smtp-Source: APXvYqxN/DPwSCMqynyiOBe9GI/dXd8HXq4WW9xzOdM9Z3ilHII7gygOqelUXSO/9UqnnU0B4y8W+g== X-Received: by 2002:a1c:4844:: with SMTP id v65mr798137wma.139.1553416182134; Sun, 24 Mar 2019 01:29:42 -0700 (PDT) Received: from svannotebook ([81.0.251.129]) by smtp.gmail.com with ESMTPSA id c20sm12963121wre.28.2019.03.24.01.29.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Mar 2019 01:29:41 -0700 (PDT) From: "Valery Smyslov" To: "'Waltermire, David A. \(Fed\)'" , "'IPsecME WG'" References: In-Reply-To: Date: Sun, 24 Mar 2019 11:29:38 +0300 Message-ID: <05b901d4e21b$b8c10980$2a431c80$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05BA_01D4E234.DE10B280" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIy9hAIbu3rDBEafccfsfunw2JFnqVeSiAA Content-Language: ru Archived-At: Subject: Re: [IPsec] Implementations of draft-ietf-ipsecme-qr-ikev2-07 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 08:29:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05BA_01D4E234.DE10B280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Dave, as far as I know there are at least 4 interoperable independent implementations - from Cisco, Apple, libreswan and ELVIS-PLUS. Last time we run interoperability tests was almost a year ago, probably more implementations appeared since that. Regards, Valery. From: IPsec On Behalf Of Waltermire, David A. (Fed) Sent: Sunday, March 24, 2019 11:17 AM To: IPsecME WG Subject: [IPsec] Implementations of draft-ietf-ipsecme-qr-ikev2-07 I am working on the IESG writeup for draft-ietf-ipsecme-qr-ikev2. I'd like to include a note about any implementations of the -07 draft. Anyone have an implementation? Also, have you done any interoperability testing with other implementations? Thanks, Dave ------=_NextPart_000_05BA_01D4E234.DE10B280 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Dave,

 

as far as I know = there are at least 4 interoperable independent implementations - =

from Cisco, Apple, = libreswan and ELVIS-PLUS. Last time we run = interoperability

tests = was almost a year ago, probably more implementations appeared since = that.

 

Regards,=

Valery.<= /span>

 

From: IPsec = <ipsec-bounces@ietf.org> On Behalf Of Waltermire, David A. = (Fed)
Sent: Sunday, March 24, 2019 11:17 AM
To: = IPsecME WG <ipsec@ietf.org>
Subject: [IPsec] = Implementations of = draft-ietf-ipsecme-qr-ikev2-07

 

I am working on the IESG writeup = for draft-ietf-ipsecme-qr-ikev2. I'd like to include a note about = any implementations of the -07 draft. Anyone have an implementation? = Also, have you done any interoperability testing with other = implementations?

 

Thanks,

Dave

------=_NextPart_000_05BA_01D4E234.DE10B280-- From nobody Sun Mar 24 06:55:32 2019 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 805A8127AC2 for ; Sun, 24 Mar 2019 06:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 ZzBxPcoodfAm for ; Sun, 24 Mar 2019 06:55:28 -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 670D612788C for ; Sun, 24 Mar 2019 06:55:28 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44RzRx6y4Qz4x6; Sun, 24 Mar 2019 14:55:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1553435725; bh=VhXAOx+G6e+dGy+JuAF0Bhw3CI51f0CcMa8OrAfR0hA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=GnkpKl1xiZAAAwRSpKAKgA0EoTUbET6y499KWzHTlXiYwXLYU8lRFiy2Chc6DN9MK NAhECPfiF4DNkE/6lKmOD2OYetefKmtEhrdgV2sj19VuMV8kBWwZV6rr8Ewg8Rsvu+ HRJCgy1KZxKMUbIvDfjUTp679Ql5x/Pr4D2CyBLQ= 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 tOZz0ircD4ub; Sun, 24 Mar 2019 14:55:24 +0100 (CET) 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; Sun, 24 Mar 2019 14:55:24 +0100 (CET) Received: from [10.0.2.228] (unknown [62.168.35.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 999BC2FCD9; Sun, 24 Mar 2019 09:55:23 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 999BC2FCD9 Content-Type: multipart/alternative; boundary=Apple-Mail-55F9B2CB-EFE9-4637-8147-62477810676E Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Sun, 24 Mar 2019 14:55:21 +0100 Cc: IPsecME WG Content-Transfer-Encoding: 7bit Message-Id: References: To: "Waltermire, David A. (Fed)" Archived-At: Subject: Re: [IPsec] Implementations of draft-ietf-ipsecme-qr-ikev2-07 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2019 13:55:30 -0000 --Apple-Mail-55F9B2CB-EFE9-4637-8147-62477810676E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Isn=E2=80=99t there an Implementations Section in the draft ? Libreswan has interop tested with strongswan, Cisco, ELVIS+ and Apple. We ar= e pretty confident at this point the implementations have it correct now. Paul Sent from mobile device > On Mar 24, 2019, at 09:16, Waltermire, David A. (Fed) wrote: >=20 > I am working on the IESG writeup for draft-ietf-ipsecme-qr-ikev2. I'd like= to include a note about any implementations of the -07 draft. Anyone have a= n implementation? Also, have you done any interoperability testing with othe= r implementations? >=20 > Thanks, > Dave > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail-55F9B2CB-EFE9-4637-8147-62477810676E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Isn=E2=80=99t there an Implementations Sect= ion in the draft ?

Libreswan has interop tested with stro= ngswan, Cisco, ELVIS+ and Apple. We are pretty confident at this point the i= mplementations have it correct now.

Paul

Sent from mobile device

On Mar 24, 2019, at 09:16, Waltermire, David A. (Fed) <david.waltermire@nist.gov> w= rote:

I am working on the IESG writeup f= or draft-ietf-ipsecme-qr-ikev2. I'd like to include a note= about any implementations of the -07 draft. Anyone have an implementation? A= lso, have you done any interoperability testing with other implementations?


Thanks,

Dave

________= _______________________________________
IPsec mailing list
IPsec@ietf.orghttps://www.= ietf.org/mailman/listinfo/ipsec
= --Apple-Mail-55F9B2CB-EFE9-4637-8147-62477810676E-- From nobody Wed Mar 27 01:21:17 2019 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 084C2120276 for ; Wed, 27 Mar 2019 01:21:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155367487603.10357.1276462825108451997.idtracker@ietfa.amsl.com> Date: Wed, 27 Mar 2019 01:21:16 -0700 From: IETF Secretariat Archived-At: Subject: [IPsec] Milestones changed for ipsecme WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 08:21:16 -0000 Changed milestone "IETF Last Call on Split-DNS Configuration for IKEv2", resolved as "Done". URL: https://datatracker.ietf.org/wg/ipsecme/about/ From nobody Wed Mar 27 05:21:54 2019 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 41EE81202AA for ; Wed, 27 Mar 2019 05:21:53 -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, URIBL_BLOCKED=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 4Ws0p1Ad3PBD for ; Wed, 27 Mar 2019 05:21:50 -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 C303B120047 for ; Wed, 27 Mar 2019 05:21:50 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44TnDX2C13zKHL; Wed, 27 Mar 2019 13:21:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1553689308; bh=dVLCiEeE5u8VAtltBxkQMM6N2r9IQDlPT/hA43YNRlI=; h=Date:From:To:cc:Subject; b=A+rrrc3nuaooS1kn+HD2EGkE062CmI6T+Wo4LW3q9XJ9B1i+XwZ87JzYToEug2K0y w9jfEdBQYBno7+whHEgp6tAbi5dUmC/i+KnXvMdJuq7oEJYmg3WN+PHQKv2dpuiXc9 UuvsTt2CKB0Ku4UtseSv87tlFkOJboEtDQnrzvuo= 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 pxTXNlTtQYOO; Wed, 27 Mar 2019 13:21:46 +0100 (CET) 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; Wed, 27 Mar 2019 13:21:45 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1D3845C856; Wed, 27 Mar 2019 08:21:45 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 1D3845C856 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 12D3140D358A; Wed, 27 Mar 2019 08:21:45 -0400 (EDT) Date: Wed, 27 Mar 2019 08:21:45 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" cc: "Xialiang (Frank, Network Standard & Patent Dept)" Message-ID: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: [IPsec] initial quick review of draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 12:21:53 -0000 I was pointed to a new draft: https://tools.ietf.org/html/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00 It's goal is to minimize the payloads for rekeying for IKE SA's and IPsec SA's. The use case is like 3gpp use of large amounts of IKEv2 sessions. I think the idea is fine, but I think I would to see it differently implemented. I think the support notify's for this should be exchanged in IKE_AUTH, not in CREATE_CHILD_SA, because otherwise the first rekey will run into issues or has to use the old model, or would be asymmetric wit initiator sending all payloads anyway but responder could omit them. I see two options: Still use the SA payload but use a Traffic Selector Type (eg TS_UMCHANGED) to be able to distinguish between a mistakenly omited TSi/TSr and a purposefully one from this doucment. Completely change the payloads of CREATE_CHILD_SA and make it more generally with some new payload type (eg CHILD_SA_UNCHANGED) that would cover more things that are unchanged (like USE_TRANSPORT, COMPRESS, TFC/padding etc). This format would be so different to also ensure it cannot be confused with regular processing. I would need to think a bit more about the gains and complexity of each of these solutions. I do like the fact that it allows a rekey without allowing to modify anything about the SA other than fresh keys. Paul From nobody Wed Mar 27 10:29:45 2019 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 B43DF12027A; Wed, 27 Mar 2019 10:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVTMiUyW_r-i; Wed, 27 Mar 2019 10:29:40 -0700 (PDT) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CDC1120381; Wed, 27 Mar 2019 10:29:40 -0700 (PDT) Received: from [IPv6:2001:67c:1232:144:e08f:7ce8:fb50:addb] (unknown [IPv6:2001:67c:1232:144:e08f:7ce8:fb50:addb]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: heidert) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id BE2E635C30E; Wed, 27 Mar 2019 18:29:37 +0100 (CET) To: IPsecME WG Cc: draft-tjhai-ipsecme-hybrid-qske-ikev2@ietf.org, stefan@gazdag.de References: <154748799416.9552.17299073748247797491.idtracker@ietfa.amsl.com> <000101d4ad6b$4a790ca0$df6b25e0$@gmail.com> From: Tobias Heider Message-ID: <13654392-83f1-6995-6ca5-f72b2b0be7eb@nm.ifi.lmu.de> Date: Wed, 27 Mar 2019 18:29:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <000101d4ad6b$4a790ca0$df6b25e0$@gmail.com> Content-Type: multipart/alternative; boundary="------------2CA9297EC284C1F3E128AAD0" Content-Language: en-US-large Archived-At: Subject: Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 17:29:44 -0000 This is a multi-part message in MIME format. --------------2CA9297EC284C1F3E128AAD0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi, we had a side meeting today where some of us shared our experiences implementing this draft and we had the chance to discuss the future of this draft with the authors. Here's what we have talked about and our results: #1 Nonces in IKE_INTERMEDIATE and CHILD_SA exchanges: The current draft proposes to send a pair of new nonces in every subsequent IKE_INTERMEDIATE exchange. We agreed that none of us sees any obvious security problems with only using the nonces exchanged in IKE_SA_INIT, but we should try to get this confirmed by cryptologists (maybe CFRG can help). #2 Using a single IKE_INTERMEDIATE to transport all additional keys One single big IKE_INTERMEDIATE message that transports all additional key exchanges would be enough to allow big keys to be fragmented. The main problem of this approach is that fragmentation handles lost fragments by resending all fragments. There is no way of requesting retransmission of a single fragment. This may turn out to be a problem, which is why each new key is sent in a separate IKE_INTERMEDIATE. Another solution might be to change fragmentation to allow retransmission of single fragments. #3 Using a reserved field to avoid 7 new transform types It was discussed whether it makes sense to use a reserved field in the transform substructure header to combine transforms of the same transform type (e.g. Diffie-Hellman group) with logical AND instead of OR. We agreed that the current solution is less work to implement and using the reserved field offers no functional benefit. #4 Big Keys (e.G. Classic McEliece) In general there was consensus that we should find a way to enable the use of McEliece keys. The problem is that McEliece keys are >1MB in size and thus can not fit into the KE payload (which has a 16 bit size field). The solution we came up with is fragmenting a single key over several KE payloads which are transmitted in a single IKE_INTERMEDIATE message that can be fragmented over several udp datagrams using IKEv2 fragmentation: HDR, SK {KE(Fragment 1), KE(Fragment 2), KE(Fragment 3)} --> <-- HDR, SK {KE(Fragment 1), KE(Fragment 2), KE(Fragment 3)} This approach is only limited by the size field of the IKEv2 header, which is 32 bit. #5 Rekeying and CREATE_CHILD_SA Nonces should be handled as said in #1. The draft does not yet specify how the new SKEYSEED is generated. We agreed that the best way would be to do this in a single prf (different than in the INTERMEDIATE exchanges which are "rekeying" incrementally), e.G. :     SKEYSEED = prf(SK_d(old), KE1result | KE2result | ... | Ni |Nr) The use of INFORMATIONAL exchange for the additional key exchanges was criticized. Several alternative designs were discussed, here's the most important ones: Design 1: Sending all in a single exchange: HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi, KEi2, KEi3, KEi4} -->     <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, KEr2, KEr3, KEr4} Problems include that the initiator might generate keys that are then not accepted by the responder. Also the message would probably be very big, so the same problems as in #2 apply here. It was discussed what happens if the responder does not accept the proposal. As in normal IKEv2 the INVALID_KE notify can be sent by the responder and that CREATE_CHILD_SA has to be redone with the new knowledge of what the responder supports. Design 2: Single additional INFORMATIONAL HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} -->     <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, N(ADDITIONAL_KE)(link1)} HDR(INFORMATIONAL), SK {KEi2, KEi3, KEi4, N(ADDITIONAL_KE)(link1)} -->     <-- HDR(INFORMATIONAL), SK {KEr2, KEr3, KEr4} Implementers might have problems with the complexity of using the (link1) cookie values as well as with the use of INFORMATIONAL for yet another thing. Feel free to correct us or comment if we made a mistake or missed something important! Thanks to everyone for joining the conversation! Regards, Tobias and Stefan --------------2CA9297EC284C1F3E128AAD0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

we had a side meeting today where some of us shared our experiences implementing this
draft and we had the chance to discuss the future of this draft with the authors.
Here's what we have talked about and our results:

#1 Nonces in IKE_INTERMEDIATE and CHILD_SA exchanges:

The current draft proposes to send a pair of new nonces in every subsequent IKE_INTERMEDIATE exchange.
We agreed that none of us sees any obvious security problems with only using the nonces exchanged in
IKE_SA_INIT, but we should try to get this confirmed by cryptologists (maybe CFRG can help).

#2 Using a single IKE_INTERMEDIATE to transport all additional keys

One single big IKE_INTERMEDIATE message that transports all additional key exchanges would be enough to
allow big keys to be fragmented. The main problem of this approach is that fragmentation handles lost
fragments by resending all fragments. There is no way of requesting retransmission of a single fragment.
This may turn out to be a problem, which is why each new key is sent in a separate IKE_INTERMEDIATE.
Another solution might be to change fragmentation to allow retransmission of single fragments.

#3 Using a reserved field to avoid 7 new transform types

It was discussed whether it makes sense to use a reserved field in the transform substructure header
to combine transforms of the same transform type (e.g. Diffie-Hellman group) with logical AND instead of OR.
We agreed that the current solution is less work to implement and using the reserved field offers no
functional benefit.

#4 Big Keys (e.G. Classic McEliece)

In general there was consensus that we should find a way to enable the use of McEliece keys.
The problem is that McEliece keys are >1MB in size and thus can not fit into the KE payload
(which has a 16 bit size field).

The solution we came up with is fragmenting a single key over several KE payloads which are transmitted
in a single IKE_INTERMEDIATE message that can be fragmented over several udp datagrams using
IKEv2 fragmentation:
HDR, SK {KE(Fragment 1), KE(Fragment 2), KE(Fragment 3)} -->
	<-- HDR, SK {KE(Fragment 1), KE(Fragment 2), KE(Fragment 3)}
This approach is only limited by the size field of the IKEv2 header, which is 32 bit.

#5 Rekeying and CREATE_CHILD_SA

Nonces should be handled as said in #1.
The draft does not yet specify how the new SKEYSEED is generated.
We agreed that the best way would be to do this in a single prf (different than in the INTERMEDIATE
exchanges which are "rekeying" incrementally), e.G. :

    SKEYSEED = prf(SK_d(old), KE1result | KE2result | ... | Ni |Nr)

The use of INFORMATIONAL exchange for the additional key exchanges was criticized.
Several alternative designs were discussed, here's the most important ones:

Design 1: Sending all in a single exchange:

HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi, KEi2, KEi3, KEi4} -->
    <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, KEr2, KEr3, KEr4}

Problems include that the initiator might generate keys that are then not accepted by the responder.
Also the message would probably be very big, so the same problems as in #2 apply here.
It was discussed what happens if the responder does not accept the proposal.
As in normal IKEv2 the INVALID_KE notify can be sent by the responder and that CREATE_CHILD_SA
has to be redone with the new knowledge of what the responder supports.

Design 2: Single additional INFORMATIONAL

HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} -->
    <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, N(ADDITIONAL_KE)(link1)}

HDR(INFORMATIONAL), SK {KEi2, KEi3, KEi4, N(ADDITIONAL_KE)(link1)} -->
    <-- HDR(INFORMATIONAL), SK {KEr2, KEr3, KEr4}

Implementers might have problems with the complexity of using the (link1) cookie
values as well as with the use of INFORMATIONAL for yet another thing.

Feel free to correct us or comment if we made a mistake or missed something important!
Thanks to everyone for joining the conversation!

Regards,
Tobias and Stefan
--------------2CA9297EC284C1F3E128AAD0-- From nobody Wed Mar 27 19:53:08 2019 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 E3978120189; Wed, 27 Mar 2019 19:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.49 X-Spam-Level: X-Spam-Status: No, score=-14.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 reN5SUjgTV8X; Wed, 27 Mar 2019 19:53:01 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91142120192; Wed, 27 Mar 2019 19:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19374; q=dns/txt; s=iport; t=1553741581; x=1554951181; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=75Xkwd+oiiDxBS8RV3bd0WC4zXBnXM8gpKSNe5XZtm0=; b=Qh+SCxJFMElRQh5Qd63SYfty8upkQ/HlLSqq6Cu1hKRVGUErgAV/KHCo IHMowv8oUeJPzlQol0OhcpzKpuMXTVUCtMBgOAu3yTAJSpzB1Zijy1HjZ j9buPfwI4b4hQDUWAbqDtK3H0gPjoJYo4I2vxS1QW/SUdtAnphiDymFWA g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAAAyNpxc/5hdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUgMBAQEBAQsBgQ5TL2iBAycKhASVT5JFhXeBew0BAYR?= =?us-ascii?q?sAheFFyI1CA0BAQMBAQkBAwJtKIVKAQEBBCMEBkoCEAIBCBEEAQErAgICMB0?= =?us-ascii?q?IAgQBDQUIE4MIgRFkqi98Mx+KFoEvAYsxF4FAP4ERgxI+hB2DMYJXA4ogITG?= =?us-ascii?q?CB4QilBAJApM9IpQMiyyTOgIRFYEuIQMzKIEucBWDJ4IWFxOOC0ExjSiBLoE?= =?us-ascii?q?fAQE?= X-IronPort-AV: E=Sophos;i="5.60,278,1549929600"; d="scan'208,217";a="540461946" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Mar 2019 02:53:00 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x2S2r0Rx004478 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Mar 2019 02:53:00 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 27 Mar 2019 21:52:59 -0500 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1473.003; Wed, 27 Mar 2019 21:52:59 -0500 From: "Panos Kampanakis (pkampana)" To: Tobias Heider , IPsecME WG CC: "draft-tjhai-ipsecme-hybrid-qske-ikev2@ietf.org" , "stefan@gazdag.de" Thread-Topic: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt Thread-Index: AQHU5MKzwokFFDmjq0KUYKKplIZSzqYgVeeA Date: Thu, 28 Mar 2019 02:52:59 +0000 Message-ID: References: <154748799416.9552.17299073748247797491.idtracker@ietfa.amsl.com> <000101d4ad6b$4a790ca0$df6b25e0$@gmail.com> <13654392-83f1-6995-6ca5-f72b2b0be7eb@nm.ifi.lmu.de> In-Reply-To: <13654392-83f1-6995-6ca5-f72b2b0be7eb@nm.ifi.lmu.de> 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.82.230.81] Content-Type: multipart/alternative; boundary="_000_f1510df032fb4588be527ee0f0871d35XCHALN010ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 02:53:07 -0000 --_000_f1510df032fb4588be527ee0f0871d35XCHALN010ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiAjNCBCaWcgS2V5cyAoZS5HLiBDbGFzc2ljIE1jRWxpZWNlKQ0KPiBJbiBnZW5lcmFsIHRoZXJl IHdhcyBjb25zZW5zdXMgdGhhdCB3ZSBzaG91bGQgZmluZCBhIHdheSB0byBlbmFibGUgdGhlIHVz ZSBvZiBNY0VsaWVjZSBrZXlzLg0KPiBUaGUgcHJvYmxlbSBpcyB0aGF0IE1jRWxpZWNlIGtleXMg YXJlID4xTUIgaW4gc2l6ZSBhbmQgdGh1cyBjYW4gbm90IGZpdCBpbnRvIHRoZSBLRSBwYXlsb2Fk DQo+ICh3aGljaCBoYXMgYSAxNiBiaXQgc2l6ZSBmaWVsZCkuDQoNCkV4Y2hhbmdpbmcgc3VjaCBi aWcga2V5cyB3b3VsZCB1bm5lY2Vzc2FyaWx5IHNsb3cgZG93biBJS0V2MiB0byBhIGNyYXdsLiBU aGVyZSBhcmUgbXVsdGlwbGUgY2FuZGlkYXRlcyBpbiB0aGUgTklTVCBQUSBQcm9qZWN0IHRoYXQg b2ZmZXIgcGsrY3Qgc2l6ZXMgb2YgYSBmZXcga2lsb2J5dGVzLiBJdCBpcyBsaWtlbHkgdGhhdCBz b21lIHdpbGwgYmUgc3RhbmRhcmRpemVkLiBDbGFzc2ljIE1jRWxpZWNlIHBlcmZvcm1hbmNlIHNl ZW1zIG11Y2ggc2xvd2VyIHRoYW4gb3RoZXIgY2FuZGlkYXRlcyBhcyB3ZWxsLiBTb3JyeSBJIG1p c3NlZCBpdCwgYnV0IHdoeSB3YXMgaXQgZGVjaWRlZCB0aGF0IHN1cHBvcnRpbmcgQ2xhc3NpYyBN Y0VsaWVjZSBpcyBhIG11c3Q/DQoNClBhbm9zDQoNCg0KRnJvbTogSVBzZWMgPGlwc2VjLWJvdW5j ZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBUb2JpYXMgSGVpZGVyDQpTZW50OiBXZWRuZXNkYXks IE1hcmNoIDI3LCAyMDE5IDE6MzAgUE0NClRvOiBJUHNlY01FIFdHIDxpcHNlY0BpZXRmLm9yZz4N CkNjOiBkcmFmdC10amhhaS1pcHNlY21lLWh5YnJpZC1xc2tlLWlrZXYyQGlldGYub3JnOyBzdGVm YW5AZ2F6ZGFnLmRlDQpTdWJqZWN0OiBSZTogW0lQc2VjXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LXRqaGFpLWlwc2VjbWUtaHlicmlkLXFza2UtaWtldjItMDMudHh0DQoNCkhp LA0KDQp3ZSBoYWQgYSBzaWRlIG1lZXRpbmcgdG9kYXkgd2hlcmUgc29tZSBvZiB1cyBzaGFyZWQg b3VyIGV4cGVyaWVuY2VzIGltcGxlbWVudGluZyB0aGlzDQpkcmFmdCBhbmQgd2UgaGFkIHRoZSBj aGFuY2UgdG8gZGlzY3VzcyB0aGUgZnV0dXJlIG9mIHRoaXMgZHJhZnQgd2l0aCB0aGUgYXV0aG9y cy4NCkhlcmUncyB3aGF0IHdlIGhhdmUgdGFsa2VkIGFib3V0IGFuZCBvdXIgcmVzdWx0czoNCg0K IzEgTm9uY2VzIGluIElLRV9JTlRFUk1FRElBVEUgYW5kIENISUxEX1NBIGV4Y2hhbmdlczoNCg0K VGhlIGN1cnJlbnQgZHJhZnQgcHJvcG9zZXMgdG8gc2VuZCBhIHBhaXIgb2YgbmV3IG5vbmNlcyBp biBldmVyeSBzdWJzZXF1ZW50IElLRV9JTlRFUk1FRElBVEUgZXhjaGFuZ2UuDQpXZSBhZ3JlZWQg dGhhdCBub25lIG9mIHVzIHNlZXMgYW55IG9idmlvdXMgc2VjdXJpdHkgcHJvYmxlbXMgd2l0aCBv bmx5IHVzaW5nIHRoZSBub25jZXMgZXhjaGFuZ2VkIGluDQpJS0VfU0FfSU5JVCwgYnV0IHdlIHNo b3VsZCB0cnkgdG8gZ2V0IHRoaXMgY29uZmlybWVkIGJ5IGNyeXB0b2xvZ2lzdHMgKG1heWJlIENG UkcgY2FuIGhlbHApLg0KDQojMiBVc2luZyBhIHNpbmdsZSBJS0VfSU5URVJNRURJQVRFIHRvIHRy YW5zcG9ydCBhbGwgYWRkaXRpb25hbCBrZXlzDQoNCk9uZSBzaW5nbGUgYmlnIElLRV9JTlRFUk1F RElBVEUgbWVzc2FnZSB0aGF0IHRyYW5zcG9ydHMgYWxsIGFkZGl0aW9uYWwga2V5IGV4Y2hhbmdl cyB3b3VsZCBiZSBlbm91Z2ggdG8NCmFsbG93IGJpZyBrZXlzIHRvIGJlIGZyYWdtZW50ZWQuIFRo ZSBtYWluIHByb2JsZW0gb2YgdGhpcyBhcHByb2FjaCBpcyB0aGF0IGZyYWdtZW50YXRpb24gaGFu ZGxlcyBsb3N0DQpmcmFnbWVudHMgYnkgcmVzZW5kaW5nIGFsbCBmcmFnbWVudHMuIFRoZXJlIGlz IG5vIHdheSBvZiByZXF1ZXN0aW5nIHJldHJhbnNtaXNzaW9uIG9mIGEgc2luZ2xlIGZyYWdtZW50 Lg0KVGhpcyBtYXkgdHVybiBvdXQgdG8gYmUgYSBwcm9ibGVtLCB3aGljaCBpcyB3aHkgZWFjaCBu ZXcga2V5IGlzIHNlbnQgaW4gYSBzZXBhcmF0ZSBJS0VfSU5URVJNRURJQVRFLg0KQW5vdGhlciBz b2x1dGlvbiBtaWdodCBiZSB0byBjaGFuZ2UgZnJhZ21lbnRhdGlvbiB0byBhbGxvdyByZXRyYW5z bWlzc2lvbiBvZiBzaW5nbGUgZnJhZ21lbnRzLg0KDQojMyBVc2luZyBhIHJlc2VydmVkIGZpZWxk IHRvIGF2b2lkIDcgbmV3IHRyYW5zZm9ybSB0eXBlcw0KDQpJdCB3YXMgZGlzY3Vzc2VkIHdoZXRo ZXIgaXQgbWFrZXMgc2Vuc2UgdG8gdXNlIGEgcmVzZXJ2ZWQgZmllbGQgaW4gdGhlIHRyYW5zZm9y bSBzdWJzdHJ1Y3R1cmUgaGVhZGVyDQp0byBjb21iaW5lIHRyYW5zZm9ybXMgb2YgdGhlIHNhbWUg dHJhbnNmb3JtIHR5cGUgKGUuZy4gRGlmZmllLUhlbGxtYW4gZ3JvdXApIHdpdGggbG9naWNhbCBB TkQgaW5zdGVhZCBvZiBPUi4NCldlIGFncmVlZCB0aGF0IHRoZSBjdXJyZW50IHNvbHV0aW9uIGlz IGxlc3Mgd29yayB0byBpbXBsZW1lbnQgYW5kIHVzaW5nIHRoZSByZXNlcnZlZCBmaWVsZCBvZmZl cnMgbm8NCmZ1bmN0aW9uYWwgYmVuZWZpdC4NCg0KIzQgQmlnIEtleXMgKGUuRy4gQ2xhc3NpYyBN Y0VsaWVjZSkNCg0KSW4gZ2VuZXJhbCB0aGVyZSB3YXMgY29uc2Vuc3VzIHRoYXQgd2Ugc2hvdWxk IGZpbmQgYSB3YXkgdG8gZW5hYmxlIHRoZSB1c2Ugb2YgTWNFbGllY2Uga2V5cy4NClRoZSBwcm9i bGVtIGlzIHRoYXQgTWNFbGllY2Uga2V5cyBhcmUgPjFNQiBpbiBzaXplIGFuZCB0aHVzIGNhbiBu b3QgZml0IGludG8gdGhlIEtFIHBheWxvYWQNCih3aGljaCBoYXMgYSAxNiBiaXQgc2l6ZSBmaWVs ZCkuDQoNClRoZSBzb2x1dGlvbiB3ZSBjYW1lIHVwIHdpdGggaXMgZnJhZ21lbnRpbmcgYSBzaW5n bGUga2V5IG92ZXIgc2V2ZXJhbCBLRSBwYXlsb2FkcyB3aGljaCBhcmUgdHJhbnNtaXR0ZWQNCmlu IGEgc2luZ2xlIElLRV9JTlRFUk1FRElBVEUgbWVzc2FnZSB0aGF0IGNhbiBiZSBmcmFnbWVudGVk IG92ZXIgc2V2ZXJhbCB1ZHAgZGF0YWdyYW1zIHVzaW5nDQpJS0V2MiBmcmFnbWVudGF0aW9uOg0K DQpIRFIsIFNLIHtLRShGcmFnbWVudCAxKSwgS0UoRnJhZ21lbnQgMiksIEtFKEZyYWdtZW50IDMp fSAtLT4NCg0KICAgICAgICA8LS0gSERSLCBTSyB7S0UoRnJhZ21lbnQgMSksIEtFKEZyYWdtZW50 IDIpLCBLRShGcmFnbWVudCAzKX0NCg0KDQpUaGlzIGFwcHJvYWNoIGlzIG9ubHkgbGltaXRlZCBi eSB0aGUgc2l6ZSBmaWVsZCBvZiB0aGUgSUtFdjIgaGVhZGVyLCB3aGljaCBpcyAzMiBiaXQuDQoN CiM1IFJla2V5aW5nIGFuZCBDUkVBVEVfQ0hJTERfU0ENCg0KTm9uY2VzIHNob3VsZCBiZSBoYW5k bGVkIGFzIHNhaWQgaW4gIzEuDQpUaGUgZHJhZnQgZG9lcyBub3QgeWV0IHNwZWNpZnkgaG93IHRo ZSBuZXcgU0tFWVNFRUQgaXMgZ2VuZXJhdGVkLg0KV2UgYWdyZWVkIHRoYXQgdGhlIGJlc3Qgd2F5 IHdvdWxkIGJlIHRvIGRvIHRoaXMgaW4gYSBzaW5nbGUgcHJmIChkaWZmZXJlbnQgdGhhbiBpbiB0 aGUgSU5URVJNRURJQVRFDQpleGNoYW5nZXMgd2hpY2ggYXJlICJyZWtleWluZyIgaW5jcmVtZW50 YWxseSksIGUuRy4gOg0KDQogICAgU0tFWVNFRUQgPSBwcmYoU0tfZChvbGQpLCBLRTFyZXN1bHQg fCBLRTJyZXN1bHQgfCAuLi4gfCBOaSB8TnIpDQoNClRoZSB1c2Ugb2YgSU5GT1JNQVRJT05BTCBl eGNoYW5nZSBmb3IgdGhlIGFkZGl0aW9uYWwga2V5IGV4Y2hhbmdlcyB3YXMgY3JpdGljaXplZC4N ClNldmVyYWwgYWx0ZXJuYXRpdmUgZGVzaWducyB3ZXJlIGRpc2N1c3NlZCwgaGVyZSdzIHRoZSBt b3N0IGltcG9ydGFudCBvbmVzOg0KDQpEZXNpZ24gMTogU2VuZGluZyBhbGwgaW4gYSBzaW5nbGUg ZXhjaGFuZ2U6DQoNCkhEUihDUkVBVEVfQ0hJTERfU0EpLCBTSyB7U0EsIE5pLCBLRWksIEtFaTIs IEtFaTMsIEtFaTR9IC0tPg0KICAgIDwtLSBIRFIoQ1JFQVRFX0NISUxEX1NBKSwgU0sge1NBLCBO ciwgS0VyLCBLRXIyLCBLRXIzLCBLRXI0fQ0KDQpQcm9ibGVtcyBpbmNsdWRlIHRoYXQgdGhlIGlu aXRpYXRvciBtaWdodCBnZW5lcmF0ZSBrZXlzIHRoYXQgYXJlIHRoZW4gbm90IGFjY2VwdGVkIGJ5 IHRoZSByZXNwb25kZXIuDQpBbHNvIHRoZSBtZXNzYWdlIHdvdWxkIHByb2JhYmx5IGJlIHZlcnkg YmlnLCBzbyB0aGUgc2FtZSBwcm9ibGVtcyBhcyBpbiAjMiBhcHBseSBoZXJlLg0KSXQgd2FzIGRp c2N1c3NlZCB3aGF0IGhhcHBlbnMgaWYgdGhlIHJlc3BvbmRlciBkb2VzIG5vdCBhY2NlcHQgdGhl IHByb3Bvc2FsLg0KQXMgaW4gbm9ybWFsIElLRXYyIHRoZSBJTlZBTElEX0tFIG5vdGlmeSBjYW4g YmUgc2VudCBieSB0aGUgcmVzcG9uZGVyIGFuZCB0aGF0IENSRUFURV9DSElMRF9TQQ0KaGFzIHRv IGJlIHJlZG9uZSB3aXRoIHRoZSBuZXcga25vd2xlZGdlIG9mIHdoYXQgdGhlIHJlc3BvbmRlciBz dXBwb3J0cy4NCg0KRGVzaWduIDI6IFNpbmdsZSBhZGRpdGlvbmFsIElORk9STUFUSU9OQUwNCg0K SERSKENSRUFURV9DSElMRF9TQSksIFNLIHtTQSwgTmksIEtFaX0gLS0+DQogICAgPC0tIEhEUihD UkVBVEVfQ0hJTERfU0EpLCBTSyB7U0EsIE5yLCBLRXIsIE4oQURESVRJT05BTF9LRSkobGluazEp fQ0KDQpIRFIoSU5GT1JNQVRJT05BTCksIFNLIHtLRWkyLCBLRWkzLCBLRWk0LCBOKEFERElUSU9O QUxfS0UpKGxpbmsxKX0gLS0+DQogICAgPC0tIEhEUihJTkZPUk1BVElPTkFMKSwgU0sge0tFcjIs IEtFcjMsIEtFcjR9DQoNCkltcGxlbWVudGVycyBtaWdodCBoYXZlIHByb2JsZW1zIHdpdGggdGhl IGNvbXBsZXhpdHkgb2YgdXNpbmcgdGhlIChsaW5rMSkgY29va2llDQp2YWx1ZXMgYXMgd2VsbCBh cyB3aXRoIHRoZSB1c2Ugb2YgSU5GT1JNQVRJT05BTCBmb3IgeWV0IGFub3RoZXIgdGhpbmcuDQoN CkZlZWwgZnJlZSB0byBjb3JyZWN0IHVzIG9yIGNvbW1lbnQgaWYgd2UgbWFkZSBhIG1pc3Rha2Ug b3IgbWlzc2VkIHNvbWV0aGluZyBpbXBvcnRhbnQhDQpUaGFua3MgdG8gZXZlcnlvbmUgZm9yIGpv aW5pbmcgdGhlIGNvbnZlcnNhdGlvbiENCg0KUmVnYXJkcywNClRvYmlhcyBhbmQgU3RlZmFuDQo= --_000_f1510df032fb4588be527ee0f0871d35XCHALN010ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAy IDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmOw0K CWNvbG9yOmJsYWNrO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0K CXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1m YW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6IzFGNDk3RDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHls ZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYz QzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0OyA8L3NwYW4+IzQg QmlnIEtleXMgKGUuRy4gQ2xhc3NpYyBNY0VsaWVjZSk8YnI+DQomZ3Q7IEluIGdlbmVyYWwgdGhl cmUgd2FzIGNvbnNlbnN1cyB0aGF0IHdlIHNob3VsZCBmaW5kIGEgd2F5IHRvIGVuYWJsZSB0aGUg dXNlIG9mIE1jRWxpZWNlIGtleXMuPGJyPg0KJmd0OyBUaGUgcHJvYmxlbSBpcyB0aGF0IE1jRWxp ZWNlIGtleXMgYXJlICZndDsxTUIgaW4gc2l6ZSBhbmQgdGh1cyBjYW4gbm90IGZpdCBpbnRvIHRo ZSBLRSBwYXlsb2FkPGJyPg0KJmd0OyAod2hpY2ggaGFzIGEgMTYgYml0IHNpemUgZmllbGQpLjxi cj4NCjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RXhj aGFuZ2luZyBzdWNoIGJpZyBrZXlzIHdvdWxkIHVubmVjZXNzYXJpbHkgc2xvdyBkb3duIElLRXYy IHRvIGEgY3Jhd2wuIFRoZXJlIGFyZSBtdWx0aXBsZSBjYW5kaWRhdGVzIGluIHRoZSBOSVNUIFBR IFByb2plY3QgdGhhdCBvZmZlciBwayYjNDM7Y3Qgc2l6ZXMgb2YgYSBmZXcga2lsb2J5dGVzLiBJ dCBpcyBsaWtlbHkgdGhhdCBzb21lIHdpbGwgYmUgc3RhbmRhcmRpemVkLjwvc3Bhbj4NCjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5DbGFzc2ljIE1jRWxpZWNlIHBlcmZvcm1hbmNlIHNlZW1z IG11Y2ggc2xvd2VyIHRoYW4gb3RoZXIgY2FuZGlkYXRlcyBhcyB3ZWxsLiBTb3JyeSBJIG1pc3Nl ZCBpdCwgYnV0IHdoeSB3YXMgaXQgZGVjaWRlZCB0aGF0IHN1cHBvcnRpbmcgQ2xhc3NpYyBNY0Vs aWVjZSBpcyBhIG11c3Q/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlBh bm9zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+IElQc2VjICZsdDtpcHNlYy1ib3Vu Y2VzQGlldGYub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5Ub2JpYXMgSGVpZGVyPGJyPg0K PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWFyY2ggMjcsIDIwMTkgMTozMCBQTTxicj4NCjxiPlRv OjwvYj4gSVBzZWNNRSBXRyAmbHQ7aXBzZWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBk cmFmdC10amhhaS1pcHNlY21lLWh5YnJpZC1xc2tlLWlrZXYyQGlldGYub3JnOyBzdGVmYW5AZ2F6 ZGFnLmRlPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSVBzZWNdIE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtdGpoYWktaXBzZWNtZS1oeWJyaWQtcXNrZS1pa2V2Mi0wMy50eHQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8YnI+DQo8 YnI+DQp3ZSBoYWQgYSBzaWRlIG1lZXRpbmcgdG9kYXkgd2hlcmUgc29tZSBvZiB1cyBzaGFyZWQg b3VyIGV4cGVyaWVuY2VzIGltcGxlbWVudGluZyB0aGlzPGJyPg0KZHJhZnQgYW5kIHdlIGhhZCB0 aGUgY2hhbmNlIHRvIGRpc2N1c3MgdGhlIGZ1dHVyZSBvZiB0aGlzIGRyYWZ0IHdpdGggdGhlIGF1 dGhvcnMuPGJyPg0KSGVyZSdzIHdoYXQgd2UgaGF2ZSB0YWxrZWQgYWJvdXQgYW5kIG91ciByZXN1 bHRzOjxicj4NCjxicj4NCiMxIE5vbmNlcyBpbiBJS0VfSU5URVJNRURJQVRFIGFuZCBDSElMRF9T QSBleGNoYW5nZXM6PGJyPg0KPGJyPg0KVGhlIGN1cnJlbnQgZHJhZnQgcHJvcG9zZXMgdG8gc2Vu ZCBhIHBhaXIgb2YgbmV3IG5vbmNlcyBpbiBldmVyeSBzdWJzZXF1ZW50IElLRV9JTlRFUk1FRElB VEUgZXhjaGFuZ2UuPGJyPg0KV2UgYWdyZWVkIHRoYXQgbm9uZSBvZiB1cyBzZWVzIGFueSBvYnZp b3VzIHNlY3VyaXR5IHByb2JsZW1zIHdpdGggb25seSB1c2luZyB0aGUgbm9uY2VzIGV4Y2hhbmdl ZCBpbg0KPGJyPg0KSUtFX1NBX0lOSVQsIGJ1dCB3ZSBzaG91bGQgdHJ5IHRvIGdldCB0aGlzIGNv bmZpcm1lZCBieSBjcnlwdG9sb2dpc3RzIChtYXliZSBDRlJHIGNhbiBoZWxwKS48YnI+DQo8YnI+ DQojMiBVc2luZyBhIHNpbmdsZSBJS0VfSU5URVJNRURJQVRFIHRvIHRyYW5zcG9ydCBhbGwgYWRk aXRpb25hbCBrZXlzPGJyPg0KPGJyPg0KT25lIHNpbmdsZSBiaWcgSUtFX0lOVEVSTUVESUFURSBt ZXNzYWdlIHRoYXQgdHJhbnNwb3J0cyBhbGwgYWRkaXRpb25hbCBrZXkgZXhjaGFuZ2VzIHdvdWxk IGJlIGVub3VnaCB0bzxicj4NCmFsbG93IGJpZyBrZXlzIHRvIGJlIGZyYWdtZW50ZWQuIFRoZSBt YWluIHByb2JsZW0gb2YgdGhpcyBhcHByb2FjaCBpcyB0aGF0IGZyYWdtZW50YXRpb24gaGFuZGxl cyBsb3N0DQo8YnI+DQpmcmFnbWVudHMgYnkgcmVzZW5kaW5nIGFsbCBmcmFnbWVudHMuIFRoZXJl IGlzIG5vIHdheSBvZiByZXF1ZXN0aW5nIHJldHJhbnNtaXNzaW9uIG9mIGEgc2luZ2xlIGZyYWdt ZW50Ljxicj4NClRoaXMgbWF5IHR1cm4gb3V0IHRvIGJlIGEgcHJvYmxlbSwgd2hpY2ggaXMgd2h5 IGVhY2ggbmV3IGtleSBpcyBzZW50IGluIGEgc2VwYXJhdGUgSUtFX0lOVEVSTUVESUFURS48YnI+ DQpBbm90aGVyIHNvbHV0aW9uIG1pZ2h0IGJlIHRvIGNoYW5nZSBmcmFnbWVudGF0aW9uIHRvIGFs bG93IHJldHJhbnNtaXNzaW9uIG9mIHNpbmdsZSBmcmFnbWVudHMuPGJyPg0KPGJyPg0KIzMgVXNp bmcgYSByZXNlcnZlZCBmaWVsZCB0byBhdm9pZCA3IG5ldyB0cmFuc2Zvcm0gdHlwZXM8YnI+DQo8 YnI+DQpJdCB3YXMgZGlzY3Vzc2VkIHdoZXRoZXIgaXQgbWFrZXMgc2Vuc2UgdG8gdXNlIGEgcmVz ZXJ2ZWQgZmllbGQgaW4gdGhlIHRyYW5zZm9ybSBzdWJzdHJ1Y3R1cmUgaGVhZGVyPGJyPg0KdG8g Y29tYmluZSB0cmFuc2Zvcm1zIG9mIHRoZSBzYW1lIHRyYW5zZm9ybSB0eXBlIChlLmcuIERpZmZp ZS1IZWxsbWFuIGdyb3VwKSB3aXRoIGxvZ2ljYWwgQU5EIGluc3RlYWQgb2YgT1IuPGJyPg0KV2Ug YWdyZWVkIHRoYXQgdGhlIGN1cnJlbnQgc29sdXRpb24gaXMgbGVzcyB3b3JrIHRvIGltcGxlbWVu dCBhbmQgdXNpbmcgdGhlIHJlc2VydmVkIGZpZWxkIG9mZmVycyBubzxicj4NCmZ1bmN0aW9uYWwg YmVuZWZpdC48YnI+DQo8YnI+DQojNCBCaWcgS2V5cyAoZS5HLiBDbGFzc2ljIE1jRWxpZWNlKTxi cj4NCjxicj4NCkluIGdlbmVyYWwgdGhlcmUgd2FzIGNvbnNlbnN1cyB0aGF0IHdlIHNob3VsZCBm aW5kIGEgd2F5IHRvIGVuYWJsZSB0aGUgdXNlIG9mIE1jRWxpZWNlIGtleXMuPGJyPg0KVGhlIHBy b2JsZW0gaXMgdGhhdCBNY0VsaWVjZSBrZXlzIGFyZSAmZ3Q7MU1CIGluIHNpemUgYW5kIHRodXMg Y2FuIG5vdCBmaXQgaW50byB0aGUgS0UgcGF5bG9hZDxicj4NCih3aGljaCBoYXMgYSAxNiBiaXQg c2l6ZSBmaWVsZCkuPGJyPg0KPGJyPg0KVGhlIHNvbHV0aW9uIHdlIGNhbWUgdXAgd2l0aCBpcyBm cmFnbWVudGluZyBhIHNpbmdsZSBrZXkgb3ZlciBzZXZlcmFsIEtFIHBheWxvYWRzIHdoaWNoIGFy ZSB0cmFuc21pdHRlZDxicj4NCmluIGEgc2luZ2xlIElLRV9JTlRFUk1FRElBVEUgbWVzc2FnZSB0 aGF0IGNhbiBiZSBmcmFnbWVudGVkIG92ZXIgc2V2ZXJhbCB1ZHAgZGF0YWdyYW1zIHVzaW5nPGJy Pg0KSUtFdjIgZnJhZ21lbnRhdGlvbjo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+SERSLCBTSyB7S0Uo RnJhZ21lbnQgMSksIEtFKEZyYWdtZW50IDIpLCBLRShGcmFnbWVudCAzKX0gLS0mZ3Q7PG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZsdDstLSBIRFIsIFNLIHtLRShGcmFnbWVudCAxKSwgS0UoRnJhZ21lbnQgMiksIEtFKEZy YWdtZW50IDMpfTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGFwcHJvYWNoIGlzIG9ubHkgbGltaXRlZCBieSB0 aGUgc2l6ZSBmaWVsZCBvZiB0aGUgSUtFdjIgaGVhZGVyLCB3aGljaCBpcyAzMiBiaXQuPGJyPg0K PGJyPg0KIzUgUmVrZXlpbmcgYW5kIENSRUFURV9DSElMRF9TQTxicj4NCjxicj4NCk5vbmNlcyBz aG91bGQgYmUgaGFuZGxlZCBhcyBzYWlkIGluICMxLjxicj4NClRoZSBkcmFmdCBkb2VzIG5vdCB5 ZXQgc3BlY2lmeSBob3cgdGhlIG5ldyBTS0VZU0VFRCBpcyBnZW5lcmF0ZWQuPGJyPg0KV2UgYWdy ZWVkIHRoYXQgdGhlIGJlc3Qgd2F5IHdvdWxkIGJlIHRvIGRvIHRoaXMgaW4gYSBzaW5nbGUgcHJm IChkaWZmZXJlbnQgdGhhbiBpbiB0aGUgSU5URVJNRURJQVRFPGJyPg0KZXhjaGFuZ2VzIHdoaWNo IGFyZSAmcXVvdDtyZWtleWluZyZxdW90OyBpbmNyZW1lbnRhbGx5KSwgZS5HLiA6PGJyPg0KPGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IFNLRVlTRUVEID0gcHJmKFNLX2Qob2xkKSwgS0UxcmVzdWx0 IHwgS0UycmVzdWx0IHwgLi4uIHwgTmkgfE5yKTxicj4NCjxicj4NClRoZSB1c2Ugb2YgSU5GT1JN QVRJT05BTCBleGNoYW5nZSBmb3IgdGhlIGFkZGl0aW9uYWwga2V5IGV4Y2hhbmdlcyB3YXMgY3Jp dGljaXplZC48YnI+DQpTZXZlcmFsIGFsdGVybmF0aXZlIGRlc2lnbnMgd2VyZSBkaXNjdXNzZWQs IGhlcmUncyB0aGUgbW9zdCBpbXBvcnRhbnQgb25lczo8YnI+DQo8YnI+DQpEZXNpZ24gMTogU2Vu ZGluZyBhbGwgaW4gYSBzaW5nbGUgZXhjaGFuZ2U6PGJyPg0KPGJyPg0KSERSKENSRUFURV9DSElM RF9TQSksIFNLIHtTQSwgTmksIEtFaSwgS0VpMiwgS0VpMywgS0VpNH0gLS0mZ3Q7PGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7ICZsdDstLSBIRFIoQ1JFQVRFX0NISUxEX1NBKSwgU0sge1NBLCBOciwg S0VyLCBLRXIyLCBLRXIzLCBLRXI0fTxicj4NCjxicj4NClByb2JsZW1zIGluY2x1ZGUgdGhhdCB0 aGUgaW5pdGlhdG9yIG1pZ2h0IGdlbmVyYXRlIGtleXMgdGhhdCBhcmUgdGhlbiBub3QgYWNjZXB0 ZWQgYnkgdGhlIHJlc3BvbmRlci48YnI+DQpBbHNvIHRoZSBtZXNzYWdlIHdvdWxkIHByb2JhYmx5 IGJlIHZlcnkgYmlnLCBzbyB0aGUgc2FtZSBwcm9ibGVtcyBhcyBpbiAjMiBhcHBseSBoZXJlLjxi cj4NCkl0IHdhcyBkaXNjdXNzZWQgd2hhdCBoYXBwZW5zIGlmIHRoZSByZXNwb25kZXIgZG9lcyBu b3QgYWNjZXB0IHRoZSBwcm9wb3NhbC48YnI+DQpBcyBpbiBub3JtYWwgSUtFdjIgdGhlIElOVkFM SURfS0Ugbm90aWZ5IGNhbiBiZSBzZW50IGJ5IHRoZSByZXNwb25kZXIgYW5kIHRoYXQgQ1JFQVRF X0NISUxEX1NBPGJyPg0KaGFzIHRvIGJlIHJlZG9uZSB3aXRoIHRoZSBuZXcga25vd2xlZGdlIG9m IHdoYXQgdGhlIHJlc3BvbmRlciBzdXBwb3J0cy48YnI+DQo8YnI+DQpEZXNpZ24gMjogU2luZ2xl IGFkZGl0aW9uYWwgSU5GT1JNQVRJT05BTDxicj4NCjxicj4NCkhEUihDUkVBVEVfQ0hJTERfU0Ep LCBTSyB7U0EsIE5pLCBLRWl9IC0tJmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7LS0g SERSKENSRUFURV9DSElMRF9TQSksIFNLIHtTQSwgTnIsIEtFciwgTihBRERJVElPTkFMX0tFKShs aW5rMSl9PGJyPg0KPGJyPg0KSERSKElORk9STUFUSU9OQUwpLCBTSyB7S0VpMiwgS0VpMywgS0Vp NCwgTihBRERJVElPTkFMX0tFKShsaW5rMSl9IC0tJmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNw OyAmbHQ7LS0gSERSKElORk9STUFUSU9OQUwpLCBTSyB7S0VyMiwgS0VyMywgS0VyNH08YnI+DQo8 YnI+DQpJbXBsZW1lbnRlcnMgbWlnaHQgaGF2ZSBwcm9ibGVtcyB3aXRoIHRoZSBjb21wbGV4aXR5 IG9mIHVzaW5nIHRoZSAobGluazEpIGNvb2tpZTxicj4NCnZhbHVlcyBhcyB3ZWxsIGFzIHdpdGgg dGhlIHVzZSBvZiBJTkZPUk1BVElPTkFMIGZvciB5ZXQgYW5vdGhlciB0aGluZy48YnI+DQo8YnI+ DQpGZWVsIGZyZWUgdG8gY29ycmVjdCB1cyBvciBjb21tZW50IGlmIHdlIG1hZGUgYSBtaXN0YWtl IG9yIG1pc3NlZCBzb21ldGhpbmcgaW1wb3J0YW50ITxicj4NClRoYW5rcyB0byBldmVyeW9uZSBm b3Igam9pbmluZyB0aGUgY29udmVyc2F0aW9uITxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KVG9i aWFzIGFuZCBTdGVmYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_f1510df032fb4588be527ee0f0871d35XCHALN010ciscocom_-- From nobody Thu Mar 28 01:37:09 2019 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 4F5CF12015E; Thu, 28 Mar 2019 01:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E92Zdcz1VGx3; Thu, 28 Mar 2019 01:37:05 -0700 (PDT) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8A0312014C; Thu, 28 Mar 2019 01:37:05 -0700 (PDT) Received: from DESKTOP58DFL8T (unknown [IPv6:2001:67c:370:128:3426:3a2d:57b2:966f]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: guggemos) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id B2B3035CE3B; Thu, 28 Mar 2019 09:37:03 +0100 (CET) From: "Tobias Guggemos" To: "'Panos Kampanakis \(pkampana\)'" , "Tobias Heider" , "IPsecME WG" Cc: , References: <154748799416.9552.17299073748247797491.idtracker@ietfa.amsl.com> <000101d4ad6b$4a790ca0$df6b25e0$@gmail.com> <13654392-83f1-6995-6ca5-f72b2b0be7eb@nm.ifi.lmu.de> In-Reply-To: Date: Thu, 28 Mar 2019 09:37:02 +0100 MIME-Version: 1.0 Message-ID: <001501d4e541$6b1af230$4150d690$@nm.ifi.lmu.de> X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHua0po1SQdv3p8eF/bRngBUmtvn6V9+0SAgG6isICAAJ1ngIAAboBg Content-Language: de Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha256; boundary="=-=UhN+7FVH7zCfYw=-=" Archived-At: Subject: Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 08:37:08 -0000 This is a multipart message in MIME format. --=-=UhN+7FVH7zCfYw=-= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > > #4 Big Keys (e.G. Classic McEliece) > > In general there was consensus that we should find a way to enable the = use of McEliece keys. > > The problem is that McEliece keys are >1MB in size and thus can not fit= into the KE payload > > (which has a 16 bit size field). > Exchanging such big keys would unnecessarily slow down IKEv2 to a crawl. = There are multiple candidates in the NIST PQ Project that offer pk+ct sizes= of a few kilobytes. It is likely that some will be standardized. Classic M= cEliece performance seems much slower than other candidates as well.=20 > Sorry I missed it, but why was it decided that supporting Classic McEliec= e is a must?=20 There is no decision made on this, at the end this is a question to be disc= ussed and agreed on in the WG. However, with McEliece being the proposal which is most trusted in the cryp= to community, there will be people wanting to support it (let it be governm= ental institutions with strict security requirements). We had "consensus" on: 1) that the draft should support the possibility to exchange McEliece keys = without "breaking" the protocol again.=20 2) we all hope that we won't need it! =3D) Correct me if I'm wrong. > Panos Cheers Tobias --=-=UhN+7FVH7zCfYw=-= Content-Transfer-Encoding: 7bit Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEyFCRjitB0A1IDrryyEcVbMgzVZ8FAlych6kACgkQyEcVbMgz VZ/hhAf/UMcxg1TZo3g/6HAtNu5eMhYTii/LXfl9TxNMu2MRXbYnk7wuXi4MG1WG EHPBGAUlUskOpRsU7RY6X9n2mWvx3/teR2LkHl7yblxH1kKxKO8coqpimFEWof0x rE4Rr+GwqHyXAoSm3Thr2uYBt0IAw3XnjFVJ4khpFPocxP0ERIDCqHxsEoH0F2Aa rCSh/B7gpgiLgXK386ycY5IVfV8CIll0Z6x3Cef6iNFFPPK1CP+bj4bnZHSmtMDD i3Wd6ulpE7U1ASOJukKK3nzXfIWecX0Jh8/Eqc04il9SN+QUAzVv9+UM/3AhsOoe bJrKR00MoWXRWMc6NnDjfcGHrvCCIg== =i9MP -----END PGP SIGNATURE----- --=-=UhN+7FVH7zCfYw=-=-- From nobody Thu Mar 28 01:51:17 2019 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 6D8A5120243; Thu, 28 Mar 2019 01:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dUFS0HkEfVh; Thu, 28 Mar 2019 01:51:13 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 86BB712012B; Thu, 28 Mar 2019 01:51:13 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id o10so6701973wmc.1; Thu, 28 Mar 2019 01:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=yoGBagMczplM/PeBgg+3bvQDGUCPzT1kCgVKjTn73h4=; b=fUx0WA9MW12Hk8RcSsEtHANmCX4vmsXJdR2/6xIaD1/NfJmL8wx52vbm9cg+PYirla UG4WSU9OZghkxL4vwlJlIi8OmvhXgBeVrFqRsiNX2X1GIpDjIgxA8M6pgle3VX6AK0/X ENszir3kDkZUwz1FT2uVf7g2jQn/O4Izv/uhm6aPHEEKWpThqqZKQBsg/zTIVPAv8viy YRCj3lRe+zhEcXn9sccRHS4kFxjcb0QpY1IYFVJI9A6ArhjXPDSbdykgGAXMoaVKRrll VdwOZinLBS2o4Velg4RSe2BAMaIkU7NhKvj9W7cPBtvP5BE3Ht33ELEVKwn1z96WBHer hGbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=yoGBagMczplM/PeBgg+3bvQDGUCPzT1kCgVKjTn73h4=; b=lJjtlpOOLgXIHWR8yjAAA+Ys6+KyGkUnhXj74FRxfRlhj8Ky35ZK4tb0PGl5idXH5Y OsuOQ0TuP7swUE2AbbQgvWLziFH7dk/T14f1SPVom6LXhNIVGw8G0D+rcouF6renhko5 fk0S3nSmV9hvsZQKLbuQCCExIJjng7KbdFhygnnwLw3NBI81N8iq2m3wmWdzQPEAI6Lo WiF8tnYkZMZmUy/JpTmheKp4Wv0U484BLPWcgE7RA9NZDHPdJX+I+/Hp0TypsM3LJRxp 4gub4+EiuaA4z5kC+PsJ5i2nDr9dq09sGEEVXtCg503Qyx379hA0wkEKrEWj2WxzRy2c I+cA== X-Gm-Message-State: APjAAAWWrHodJBvuU0WpNtQVSWVPpp/sM34S/OikVLutQLVXjeUIFEbU 2h0p/79WgNc04pWlIGtoWuOGIcMeHFE= X-Google-Smtp-Source: APXvYqzudkrOTAmLe2KTSCRF/if3eAoxmhC/HEeAhuMhj/kMdKRkZQUgWmo9/NBOJDrTgka19SN8aw== X-Received: by 2002:a1c:1c5:: with SMTP id 188mr14345372wmb.52.1553763071711; Thu, 28 Mar 2019 01:51:11 -0700 (PDT) Received: from svannotebook ([2001:67c:370:128:4cf6:eead:b0ec:3915]) by smtp.gmail.com with ESMTPSA id x17sm55521186wrd.95.2019.03.28.01.51.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 01:51:10 -0700 (PDT) From: "Valery Smyslov" To: "'Tobias Guggemos'" , "'Panos Kampanakis \(pkampana\)'" , "'Tobias Heider'" , "'IPsecME WG'" Cc: , References: <154748799416.9552.17299073748247797491.idtracker@ietfa.amsl.com> <000101d4ad6b$4a790ca0$df6b25e0$@gmail.com> <13654392-83f1-6995-6ca5-f72b2b0be7eb@nm.ifi.lmu.de> <001501d4e541$6b1af230$4150d690$@nm.ifi.lmu.de> In-Reply-To: <001501d4e541$6b1af230$4150d690$@nm.ifi.lmu.de> Date: Thu, 28 Mar 2019 11:51:09 +0300 Message-ID: <01ba01d4e543$644a0890$2cde19b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: ru Thread-Index: AQHua0po1SQdv3p8eF/bRngBUmtvnwHW2sz0Af2jPnsBtmjxfQI6nHUIpa+CjoA= Archived-At: Subject: Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 08:51:16 -0000 Hi, > > > The problem is that McEliece keys are >1MB in size and thus can = not > > > fit into the KE payload (which has a 16 bit size field). > > Exchanging such big keys would unnecessarily slow down IKEv2 to a = crawl. > There are multiple candidates in the NIST PQ Project that offer pk+ct = sizes of a > few kilobytes. It is likely that some will be standardized. Classic = McEliece > performance seems much slower than other candidates as well. > > Sorry I missed it, but why was it decided that supporting Classic = McEliece is a > must? >=20 > There is no decision made on this, at the end this is a question to be = discussed > and agreed on in the WG. > However, with McEliece being the proposal which is most trusted in the = crypto > community, there will be people wanting to support it (let it be = governmental > institutions with strict security requirements). > We had "consensus" on: > 1) that the draft should support the possibility to exchange McEliece = keys > without "breaking" the protocol again. > 2) we all hope that we won't need it! =3D) >=20 > Correct me if I'm wrong. That was my impression too. In other words - make it possible to handle such extremely long keys in probably suboptimal way, but with minimal possible changes to the protocol. So that those who need them could use = them, but no promises that protocol will optimized for them. Regards, Valery. > > Panos >=20 > Cheers Tobias From nobody Thu Mar 28 01:51:42 2019 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 CC49712047C for ; Thu, 28 Mar 2019 01:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 So-yXyL4Rctw for ; Thu, 28 Mar 2019 01:51:29 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) (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 B4E6B120466 for ; Thu, 28 Mar 2019 01:51:28 -0700 (PDT) Received: from [134.119.228.1] (helo=webmailfront-cgn01.ispgateway.de) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.90_1) (envelope-from ) id 1h9Qkv-0000oS-67 for ipsec@ietf.org; Thu, 28 Mar 2019 09:51:25 +0100 Received: from dhcp-8ae8.meeting.ietf.org (dhcp-8ae8.meeting.ietf.org [31.133.138.232]) by webmail.df.eu (Horde Framework) with HTTP; Thu, 28 Mar 2019 09:51:25 +0100 Date: Thu, 28 Mar 2019 09:51:25 +0100 Message-ID: <20190328095125.Horde.okViqVm7l8J7BQ4Jt1gimg1@webmail.df.eu> From: stefan@gazdag.de To: ipsec@ietf.org References: <154748799416.9552.17299073748247797491.idtracker@ietfa.amsl.com> <000101d4ad6b$4a790ca0$df6b25e0$@gmail.com> <13654392-83f1-6995-6ca5-f72b2b0be7eb@nm.ifi.lmu.de> <001501d4e541$6b1af230$4150d690$@nm.ifi.lmu.de> In-Reply-To: <001501d4e541$6b1af230$4150d690$@nm.ifi.lmu.de> User-Agent: Internet Messaging Program (IMP) H5 (6.0.4) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-Df-Sender: c3RlZmFuQGdhemRhZy5kZQ== Archived-At: Subject: Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 08:51:41 -0000 Hi everyone, Quoting Tobias Guggemos : >> > #4 Big Keys (e.G. Classic McEliece) >> > In general there was consensus that we should find a way to >> enable the use of McEliece keys. >> > The problem is that McEliece keys are >1MB in size and thus can >> not fit into the KE payload >> > (which has a 16 bit size field). >> Exchanging such big keys would unnecessarily slow down IKEv2 to a >> crawl. There are multiple candidates in the NIST PQ Project that >> offer pk+ct sizes of a few kilobytes. It is likely that some will >> be standardized. Classic McEliece performance seems much slower >> than other candidates as well. >> Sorry I missed it, but why was it decided that supporting Classic >> McEliece is a must? > > There is no decision made on this, at the end this is a question to > be discussed and agreed on in the WG. > However, with McEliece being the proposal which is most trusted in > the crypto community, there will be people wanting to support it > (let it be governmental institutions with strict security > requirements). > We had "consensus" on: > 1) that the draft should support the possibility to exchange > McEliece keys without "breaking" the protocol again. > 2) we all hope that we won't need it! =) > > Correct me if I'm wrong. Nothing to be corrected here. I'd like to stress that some parties who participated in the discussion yesterday or in personal conversations have told about the demand for using a rather secure version even if it means more work on extending the protocol. Though there's a few quantum-resistant algorithms that I personally like still McEliece is the one cryptographers are most confident to be secure. There's several use cases relevant to companies and agencies where using McEliece (even this in combination with other algorithms) is the way to go and therefore this should definitely be considered for IKEv2. Kind Regards, Stefan Gazdag From nobody Thu Mar 28 05:16:50 2019 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 8694E120296 for ; Thu, 28 Mar 2019 05:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, 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 o__XSrS62plY for ; Thu, 28 Mar 2019 05:16:43 -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 38C5F120052 for ; Thu, 28 Mar 2019 05:16: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 x2SCGbPM023461 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 28 Mar 2019 14:16:37 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x2SCGb37029066; Thu, 28 Mar 2019 14:16:37 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23708.47909.87667.702784@fireball.acr.fi> Date: Thu, 28 Mar 2019 14:16:37 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Subject: [IPsec] IPsecME working group draft status X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 12:16:49 -0000 Document Status: - draft-ietf-ipsecme-split-dns (David) In RFC editor queue. - draft-ietf-ipsecme-qr-ikev2, Quantum Resistance (David) Ready for publication. Waiting for revised version. - draft-mglt-ipsecme-implicit-iv (Tero) Publication requested. - draft-ietf-ipsecme-ipv6-ipv4-codes, IKEv2 Notification Status Types for IPv4/IPv6 Coexistence (David) Almost ready for WGLC. Needs to decide the number of notifications to be used. - draft-ietf-ipsecme-labeled-ipsec, Labeled IPsec Traffic Selector support for IKEv2 (Tero) Still need work. - draft-smyslov-ipsecme-ikev2-aux, Intermediate Exchange in the IKEv2 Protocol (Tero) Adopted as WG draft. Not yet WG drafts: - draft-yeung-g-ikev2, Group Key Management using IKEv2 (Tero) Should be ready, but needs more reviews. - draft-tjhai-ipsecme-hybrid-qske-ikev2, Framework to Integrate Post-quantum Key Exchanges into Internet Key Exchange Protocol Version 2 (IKEv2) (David) Discussion about the negotiation design still ongoing. - draft-mglt-ipsecme-diet-esp, ESP Header Compression and Diet-ESP (Tero) Work ongoing. New work: -- kivinen@iki.fi From nobody Thu Mar 28 05:17:25 2019 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 8630B120463 for ; Thu, 28 Mar 2019 05:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Stmx6fsMfzY for ; Thu, 28 Mar 2019 05:17:18 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 5A8731204A2 for ; Thu, 28 Mar 2019 05:17:18 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id e80so18090391ote.5 for ; Thu, 28 Mar 2019 05:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lz5xy8oCxF5QmfeX832v11aUT81DrrAhXJOuMpOha+g=; b=A0bMSq0TTMsj9y8z6gepTbzU1x7tt1cEaf5bamRdd0BJAm9sq5Ku3FbWDu1xfO8fFY 9w5ywwoRTILcUuj7kIZplUbci9nWRgndoV+Oq3q/5hH0vavNuUzreYfX8ZhmBtlnaH5e cMCgiY3lBsiiCRxkh6eS5GUfQB9vCqrFP3B6fNIM3nJCMegFWLi0VKIqSSdeyXd4n1Js K5FMvyW5/o6CCUotWhAxwu6D5n8/MVb4GNuHvlohTeIe3+PEzeRs7hLiL0n+D+xEpgPc 4s6+uIg6qHNHEwSDaRPlRYzHzCfsLYkyM1u+1b0oC0yg8Q6Frl/TjhkCrRKHLVnlEwqH dnig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lz5xy8oCxF5QmfeX832v11aUT81DrrAhXJOuMpOha+g=; b=IYkLfbmTxMqRKMZ4UR38OOJlF/F78HB2tOYCBMDjVIna7PYZyWnQm98dE5Jf2eaqG/ tFyB7ujJXzH1NVxWDuEY25CPE05S6vk7iNfgRsxde+QiiOQhipCxRw31OnM2BBoFFRZd wn7mFsVH0c5rXSS5SsKd7hy8gtYyQ6xnT5fX9myq/TXuipGnUCfhooazTb7Jwzciiz5H i8EhNuhzB/ipnqw6J0PLqvRtZDEHXZT8MsLgQ2ai+O8Uoj/UUf1d4iqSTiKTZp453d+0 g+dzTx96xnQCG1QqqZIV9ImcU/eCZIQC6ie22U9cZB9i38Xp3Qt12Wb9NS4UV2GmuSKT igWw== X-Gm-Message-State: APjAAAU6+Nij/CwPB+gtanlFbxuXsJYp0mLZFTh6TNrjnHU2z0BAGf9u tRVghIoBTRJDOFOyprQx2YZMpYaWWF8bK7A5iAxp74itdP4= X-Google-Smtp-Source: APXvYqxflnP0OOc7VylJwQGS/lyge7Q4NQxEE4QHGT3g9o+Llj8j2eZ/VNZDPS8CdC8LR8OgEAnjnSkI88fkgyUFtnY= X-Received: by 2002:a05:6830:15d0:: with SMTP id j16mr3005777otr.286.1553775437697; Thu, 28 Mar 2019 05:17:17 -0700 (PDT) MIME-Version: 1.0 References: <154748799416.9552.17299073748247797491.idtracker@ietfa.amsl.com> <000101d4ad6b$4a790ca0$df6b25e0$@gmail.com> <13654392-83f1-6995-6ca5-f72b2b0be7eb@nm.ifi.lmu.de> <001501d4e541$6b1af230$4150d690$@nm.ifi.lmu.de> <20190328095125.Horde.okViqVm7l8J7BQ4Jt1gimg1@webmail.df.eu> In-Reply-To: <20190328095125.Horde.okViqVm7l8J7BQ4Jt1gimg1@webmail.df.eu> From: Vukasin Karadzic Date: Thu, 28 Mar 2019 13:16:51 +0100 Message-ID: To: stefan@gazdag.de Cc: ipsec@ietf.org Content-Type: multipart/alternative; boundary="00000000000006584505852689fe" Archived-At: Subject: Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 12:17:24 -0000 --00000000000006584505852689fe Content-Type: text/plain; charset="UTF-8" Hello all, I'd like to add a couple of remarks. 1. There is one more code-based proposal based on Goppa codes and somewhat on McEliece and that is NTS-KEM, I would suppose one of those two will be one of the final standardized algorithms. NTS-KEM has three sets of parameters, one for each of the security 'levels' that NIST proposed, and the first and second set of parameters (for Level 1 and Level 3 security) have significantly smaller keys (though they are still one of the biggest). There is even a document published by Classic McEliece team that compares all important aspects of the proposal ( https://classic.mceliece.org/nist/vsntskem-20180629.pdf) (there is also a response from NTS-KEM team addressing all points from that document). 2. All NIST proposals are K(ey)E(ncapsulation)M(echanism)s. I don't know if it's possible or if it makes sense, but in some use cases (eg. small client - server) it may be useful for a server to store public key from client, so that client doesn't need to each time (eg. for a rekey) calculate a new public key (and send it?), because key generation can be expensive, in case of Classic McEliece key generation in software takes billions (4-6) of cycles, about 2 seconds in ~6,000,000,000 case on a 'Intel Xeon E3-1220 v3 (Haswell) running at 3.10GHz with 32GB of RAM' platform. Maybe that point can be also addressed in the draft. One more remark regarding KEMs, in case of Classic McEliece/NTS-KEM, the initiator would send MBs (eg, 1357824 bytes) of KE payload, while in the other direction the responder would need to send only couple of hundred of bytes (240 bytes) which contain encapsulated secret key. Regards, Vukasin Karadzic --00000000000006584505852689fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
He= llo all,

I'd like to add a couple of remarks.<= /div>

1. There is one more code-based proposal based on = Goppa codes and somewhat on McEliece and that is NTS-KEM, I would suppose o= ne of those two will be one of the final standardized algorithms. NTS-KEM h= as three sets of parameters, one for each of the security 'levels' = that NIST proposed, and the first and second set of parameters (for Level 1= and Level 3 security) have significantly smaller keys (though they are sti= ll one of the biggest).
There is even a document published by Cla= ssic McEliece team that compares all important aspects of the proposal (https://cl= assic.mceliece.org/nist/vsntskem-20180629.pdf) (there is also a respons= e from NTS-KEM team addressing all points from that document).

2. All NIST proposals are K(ey)E(ncapsulation)M(echanism)s= . I don't know if it's possible or if it makes sense,
but= in some use cases (eg. small client - server) it may be useful for a serve= r to store public key from client, so that client doesn't need to each = time (eg. for a rekey) calculate a new public key (and send it?), because k= ey generation can be expensive, in case of Classic McEliece key generation = in software takes billions (4-6) of cycles, about 2 seconds in ~6,000,000,0= 00 case on a 'Intel Xeon E3-1220 v3 (Haswell) running at 3.10GHz with 3= 2GB of RAM' platform. Maybe that point can be also addressed in the dra= ft.
One more remark regarding KEMs, in case of Classic McEliece/N= TS-KEM, the initiator would send MBs (eg, 1357824 bytes) of KE payload, whi= le in the other direction the responder would need to send only couple of h= undred of bytes (240 bytes) which contain encapsulated secret key.

Regards,
Vukasin Karadzic
<= /div>
--00000000000006584505852689fe-- From nobody Thu Mar 28 05:18:59 2019 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 992CD12049D for ; Thu, 28 Mar 2019 05:18:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155377552962.1577.18200938896148160436.idtracker@ietfa.amsl.com> Date: Thu, 28 Mar 2019 05:18:49 -0700 From: IETF Secretariat Archived-At: Subject: [IPsec] Milestones changed for ipsecme WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 12:18:58 -0000 Changed milestone "The internal address failure indication in IKEv2 to IESG", added draft-ietf-ipsecme-ipv6-ipv4-codes to milestone. Changed milestone "The security labels support for IKEv2 to IESG", added draft-ietf-ipsecme-labeled-ipsec to milestone. URL: https://datatracker.ietf.org/wg/ipsecme/about/ From nobody Thu Mar 28 05:27:54 2019 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 7858E1202C7; Thu, 28 Mar 2019 05:27:45 -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.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <155377606540.1467.2313362932501841582@ietfa.amsl.com> Date: Thu, 28 Mar 2019 05:27:45 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 12:27:46 -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 WG of the IETF. Title : Postquantum Preshared Keys for IKEv2 Authors : Scott Fluhrer David McGrew Panos Kampanakis Valery Smyslov Filename : draft-ietf-ipsecme-qr-ikev2-08.txt Pages : 18 Date : 2019-03-28 Abstract: The possibility of Quantum Computers pose a serious challenge to cryptography algorithms deployed widely today. IKEv2 is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a Quantum Computer is available. It is anticipated that IKEv2 will be extended to support quantum secure key exchange algorithms; however that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a Quantum Computer, by using preshared keys. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-qr-ikev2-08 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-qr-ikev2-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-qr-ikev2-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 28 06:19:15 2019 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 DFD6B1202AE; Thu, 28 Mar 2019 06:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 XMOmghKOIjF2; Thu, 28 Mar 2019 06:19:09 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E899812024A; Thu, 28 Mar 2019 06:19:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2912; q=dns/txt; s=iport; t=1553779149; x=1554988749; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7CWqPnzB/btQV2qMUTVHsB9DyDOiT0DDFTDo1Qdn3aU=; b=jSjvEOcwLkkseqqskdcGbkzBkcm5ZFMx4VFas7bDb8+BVAXrUU1NUU2b BI6E1ZOXG5v2kytWuibNsN+oGC/do94BupsLrguS0TUUGvBsnANS6Rc47 x5qDUEpEUR1b4u/w2HnnsNEzrrJYTPZhkHI4+ZpRWEF9aJmiS70vJFOEh c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABzyZxc/5FdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBghCBaycKhASIHI0vmDyBew0BAYRsAhe?= =?us-ascii?q?FGyI0CQ0BAQMBAQkBAwJtKIVKAQEBAwEjEUMCBQcEAgEIEQQBAQMCJgICAjA?= =?us-ascii?q?VCAgCBAENBQgMhHwIqgOBL4ovgQskAYltgUQXgUA/gRGDEj6HToJXA4x5mDI?= =?us-ascii?q?JApM9IpQMiyyTOgIRFYEuHziBVnAVgyeCQI4LQTGOVoEfAQE?= X-IronPort-AV: E=Sophos;i="5.60,280,1549929600"; d="scan'208";a="251647618" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Mar 2019 13:19:08 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x2SDJ7Pk001884 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Mar 2019 13:19:07 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 28 Mar 2019 08:19:07 -0500 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1473.003; Thu, 28 Mar 2019 08:19:07 -0500 From: "Panos Kampanakis (pkampana)" To: Tobias Guggemos , Tobias Heider , IPsecME WG CC: "draft-tjhai-ipsecme-hybrid-qske-ikev2@ietf.org" , "stefan@gazdag.de" Thread-Topic: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt Thread-Index: AQHua0powokFFDmjq0KUYKKplIZSzqV9+0SAgG6isICAAJ1ngIAAboBggABNmqA= Date: Thu, 28 Mar 2019 13:19:07 +0000 Message-ID: <9a64907bac864d238e81d0d3dcf4c4bb@XCH-ALN-010.cisco.com> References: <154748799416.9552.17299073748247797491.idtracker@ietfa.amsl.com> <000101d4ad6b$4a790ca0$df6b25e0$@gmail.com> <13654392-83f1-6995-6ca5-f72b2b0be7eb@nm.ifi.lmu.de> <001501d4e541$6b1af230$4150d690$@nm.ifi.lmu.de> In-Reply-To: <001501d4e541$6b1af230$4150d690$@nm.ifi.lmu.de> 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.82.230.81] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 13:19:14 -0000 DQpUaGFua3MgVG9iaWFzLCBWYWxlcnkgYW5kIFN0ZWZhbi4gDQoNCkltbyBDbGFzc2ljIE1jRWxp ZWNlIGlzIGltcHJhY3RpY2FsIGZvciB1c2UgaW4gbGl2ZSBrZXkgbmVnb3RpYXRpb25zIGluIHBy b3RvY29scyBsaWtlIFRMUywgSUtFLCBTU0ggZXRjLiBOSVNUIHdpbGwgc3RhbmRhcmRpemUgbW9y ZSBwcmFjdGljYWwgYW5kIHNlY3VyZSBwb3N0cXVhbnR1bSBLRU1zIGFuZCB0aGUgYWRkZWQgY29t cGxleGl0eSBmb3IgTWNFbGllY2UgaXMgbm90IG5lY2Vzc2FyeS4gSSB1bmRlcnN0YW5kIHRoYXQg b3RoZXJzIG1pZ2h0IHdhbnQgTWNFbGllY2UgYmVjYXVzZSB0aGV5IHRydXN0IGl0IG1vcmUuIElu IHRoYXQgY2FzZSwgSSBzdWdnZXN0IHRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluICM2IHRvIGJl IGEgIk1BWSIgaW4gdGhlIGRyYWZ0LiANCg0KUGFub3MNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBUb2JpYXMgR3VnZ2Vtb3MgPGd1Z2dlbW9zQG5tLmlmaS5sbXUuZGU+ IA0KU2VudDogVGh1cnNkYXksIE1hcmNoIDI4LCAyMDE5IDQ6MzcgQU0NClRvOiBQYW5vcyBLYW1w YW5ha2lzIChwa2FtcGFuYSkgPHBrYW1wYW5hQGNpc2NvLmNvbT47IFRvYmlhcyBIZWlkZXIgPGhl aWRlcnRAbm0uaWZpLmxtdS5kZT47IElQc2VjTUUgV0cgPGlwc2VjQGlldGYub3JnPg0KQ2M6IGRy YWZ0LXRqaGFpLWlwc2VjbWUtaHlicmlkLXFza2UtaWtldjJAaWV0Zi5vcmc7IHN0ZWZhbkBnYXpk YWcuZGUNClN1YmplY3Q6IEFXOiBbSVBzZWNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtdGpoYWktaXBzZWNtZS1oeWJyaWQtcXNrZS1pa2V2Mi0wMy50eHQNCg0KKiBQR1AgU2ln bmVkIGJ5IGFuIHVua25vd24ga2V5DQoNCj4gPiAjNCBCaWcgS2V5cyAoZS5HLiBDbGFzc2ljIE1j RWxpZWNlKQ0KPiA+IEluIGdlbmVyYWwgdGhlcmUgd2FzIGNvbnNlbnN1cyB0aGF0IHdlIHNob3Vs ZCBmaW5kIGEgd2F5IHRvIGVuYWJsZSB0aGUgdXNlIG9mIE1jRWxpZWNlIGtleXMuDQo+ID4gVGhl IHByb2JsZW0gaXMgdGhhdCBNY0VsaWVjZSBrZXlzIGFyZSA+MU1CIGluIHNpemUgYW5kIHRodXMg Y2FuIG5vdCANCj4gPiBmaXQgaW50byB0aGUgS0UgcGF5bG9hZCAod2hpY2ggaGFzIGEgMTYgYml0 IHNpemUgZmllbGQpLg0KPiBFeGNoYW5naW5nIHN1Y2ggYmlnIGtleXMgd291bGQgdW5uZWNlc3Nh cmlseSBzbG93IGRvd24gSUtFdjIgdG8gYSBjcmF3bC4gVGhlcmUgYXJlIG11bHRpcGxlIGNhbmRp ZGF0ZXMgaW4gdGhlIE5JU1QgUFEgUHJvamVjdCB0aGF0IG9mZmVyIHBrK2N0IHNpemVzIG9mIGEg ZmV3IGtpbG9ieXRlcy4gSXQgaXMgbGlrZWx5IHRoYXQgc29tZSB3aWxsIGJlIHN0YW5kYXJkaXpl ZC4gQ2xhc3NpYyBNY0VsaWVjZSBwZXJmb3JtYW5jZSBzZWVtcyBtdWNoIHNsb3dlciB0aGFuIG90 aGVyIGNhbmRpZGF0ZXMgYXMgd2VsbC4gDQo+IFNvcnJ5IEkgbWlzc2VkIGl0LCBidXQgd2h5IHdh cyBpdCBkZWNpZGVkIHRoYXQgc3VwcG9ydGluZyBDbGFzc2ljIE1jRWxpZWNlIGlzIGEgbXVzdD8g DQoNClRoZXJlIGlzIG5vIGRlY2lzaW9uIG1hZGUgb24gdGhpcywgYXQgdGhlIGVuZCB0aGlzIGlz IGEgcXVlc3Rpb24gdG8gYmUgZGlzY3Vzc2VkIGFuZCBhZ3JlZWQgb24gaW4gdGhlIFdHLg0KSG93 ZXZlciwgd2l0aCBNY0VsaWVjZSBiZWluZyB0aGUgcHJvcG9zYWwgd2hpY2ggaXMgbW9zdCB0cnVz dGVkIGluIHRoZSBjcnlwdG8gY29tbXVuaXR5LCB0aGVyZSB3aWxsIGJlIHBlb3BsZSB3YW50aW5n IHRvIHN1cHBvcnQgaXQgKGxldCBpdCBiZSBnb3Zlcm5tZW50YWwgaW5zdGl0dXRpb25zIHdpdGgg c3RyaWN0IHNlY3VyaXR5IHJlcXVpcmVtZW50cykuDQpXZSBoYWQgImNvbnNlbnN1cyIgb246DQox KSB0aGF0IHRoZSBkcmFmdCBzaG91bGQgc3VwcG9ydCB0aGUgcG9zc2liaWxpdHkgdG8gZXhjaGFu Z2UgTWNFbGllY2Uga2V5cyB3aXRob3V0ICJicmVha2luZyIgdGhlIHByb3RvY29sIGFnYWluLiAN CjIpIHdlIGFsbCBob3BlIHRoYXQgd2Ugd29uJ3QgbmVlZCBpdCEgPSkNCg0KQ29ycmVjdCBtZSBp ZiBJJ20gd3JvbmcuDQoNCj4gUGFub3MNCg0KQ2hlZXJzIFRvYmlhcw0KDQoqIFVua25vd24gS2V5 DQoqIDB4QzgzMzU1OUYNCg== From nobody Thu Mar 28 06:21:18 2019 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 3B8A91202A3 for ; Thu, 28 Mar 2019 06:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FOzPlMpE1bj for ; Thu, 28 Mar 2019 06:21:15 -0700 (PDT) Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) (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 B8D3812024A for ; Thu, 28 Mar 2019 06:21:14 -0700 (PDT) Received: by mail-lj1-f172.google.com with SMTP id k8so17600070lja.8 for ; Thu, 28 Mar 2019 06:21:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FVKbn3kxEZvLuGttYKasuN4JS/F/3BgnrE+AIF3kCds=; b=BUTw0upsKbKRFkaysffxdez634VNvRvOzfMLHVnjYqLRcPodctwtk+IU7fcHzb5hol HoWPj1dAGZKtDVENhpH9Tg+wKEw4azrBcmAjk0XHn8UttMN2CviKVON0lLChbTQfrddU qVubUKtubMyPgyX1NCn9hIG57QG0jUZNTtP2tl6WfajO5NoL3pJaUqBnjRES8wIyTDi3 RNyGOgL7lCA1Kz1E9dI0/XtO8F2DdrXtGUIIwirDU/CXlYxQNQs7X4XyBibZmWtvQ9UO t5XQ/J6YKVJleIMDtBcH32lXA4eIVcxMwh7RXIZRSCO2H56CAWYuPSm8IkufVS8lF3y/ 9zKA== X-Gm-Message-State: APjAAAXYGsUUh6GTRXx6JUn4iwfY4/LZJ0fgcjy/CafnlKf7n19Uuo1U Qm38JnXAwhpQeMwmQbgNhE9bb4u2NU21oBwiiNNCBHci X-Google-Smtp-Source: APXvYqxpBFkLjw+R7bWtO/n4EHbszrvASctAfPT4qW7vs0yyiUq5/4Z3W2wzzEOvGjTPlBYbsktyFcOPT3DMKgivtdc= X-Received: by 2002:a2e:7806:: with SMTP id t6mr2274975ljc.143.1553779272040; Thu, 28 Mar 2019 06:21:12 -0700 (PDT) MIME-Version: 1.0 From: Daniel Migault Date: Thu, 28 Mar 2019 09:20:59 -0400 Message-ID: To: IPsecME WG Content-Type: multipart/alternative; boundary="00000000000091c3e80585276dfc" Archived-At: Subject: [IPsec] EHC draft on github X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 13:21:16 -0000 --00000000000091c3e80585276dfc Content-Type: text/plain; charset="UTF-8" Hi, After the presentation we were asked the link on github. Feel free to comment using github as well. Unfortunately, that is a xml format. https://github.com/mglt/draft-mglt-ipsecme-diet-esp Yours, Daniel --00000000000091c3e80585276dfc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

After the pr= esentation we were asked the link on github. Feel free to comment using git= hub as well. Unfortunately, that is a xml format.


Y= ours,=C2=A0
Daniel
--00000000000091c3e80585276dfc-- From nobody Thu Mar 28 06:34:32 2019 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 0A2A51204C3; Thu, 28 Mar 2019 06:33:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: David Waltermire via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Cc: ipsec@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, iesg-secretary@ietf.org, david.waltermire@nist.gov Message-ID: <155378001203.1431.17124114279387012562.idtracker@ietfa.amsl.com> Date: Thu, 28 Mar 2019 06:33:32 -0700 Archived-At: Subject: [IPsec] Publication has been requested for draft-ietf-ipsecme-qr-ikev2-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 13:33:38 -0000 David Waltermire has requested publication of draft-ietf-ipsecme-qr-ikev2-08 as Proposed Standard on behalf of the IPSECME working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ From nobody Thu Mar 28 08:00:51 2019 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 45DDA120506; Thu, 28 Mar 2019 08:00:44 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmWsM0o5f9LX; Thu, 28 Mar 2019 08:00:40 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 AEA8A1204EB; Thu, 28 Mar 2019 08:00:39 -0700 (PDT) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D20BE382E8C5CAE7E0C7; Thu, 28 Mar 2019 15:00:37 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 28 Mar 2019 15:00:37 +0000 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.5]) by SJCEML701-CHM.china.huawei.com ([169.254.3.224]) with mapi id 14.03.0439.000; Thu, 28 Mar 2019 08:00:33 -0700 From: Linda Dunbar To: idr wg , "idr-chairs@ietf.org" , Alvaro Retana , Yoav Nir , Roman Danyliw , "i2nsf@ietf.org" , "ipsec@ietf.org WG" , Benjamin Kaduk , "stephane.litkowski@orange.com" CC: Paul Wouters Thread-Topic: using BGP signaling to achieve IPsec Tunnel configuration (draft-hujun-idr-bgp-ipsec): potential conflict with the I2NSF's Controller facilitated IPsec configuration Thread-Index: AdTldVT2DxuuWS8bQw6FDvPhnW1lPw== Date: Thu, 28 Mar 2019 15:00:33 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B33E27F@sjceml521-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.220.70.227] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B33E27Fsjceml521mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [IPsec] using BGP signaling to achieve IPsec Tunnel configuration (draft-hujun-idr-bgp-ipsec): potential conflict with the I2NSF's Controller facilitated IPsec configuration X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 15:00:50 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F66B33E27Fsjceml521mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just to reiterate the concerns and issues I raised during IDR Thurs session= discussion on using BGP signaling to achieve IPsec Tunnel configuration (d= raft-hujun-idr-bgp-ipsec). Copy I2NSF WG because there is similar discussion for over a year. Copy IPsecme WG as the group has many experts on the IPsec configuration. 1. I2NSF WG has an on-going discussion on Controller facilitated IPsec= configuration which has been discussed for over a year. Even though the I= 2NSF's IPsec Configuration is between Controller and devices, whereas the = BGP signaling IPsec Configuration proposed by draft-hujun-idr-bgp-ipsec is = between peers, the configuration parameters to the devices are for the same= purpose, therefore, should be aligned to avoid future conflicts to the ind= ustry. 2. When using IPsec Tunnel between two peers, usually they are separat= ed by untrusted domain. If Router "A" is allowed to gets the IPsec tunnel = configurations from peers across untrusted domain (instead of the today's p= ractice of from administrators), then many issues come up, for example: How can a router "A" trust the Traffic Selection policy from a remote peer = B? If the router "A" already has its Traffic Selection policy configured fo= r a specific IPsec tunnel, but different from the Traffic Selection policy = from remote peer B, which policy should Route A enforce for the IPsec Tunne= l? If the router "A" doesn't have Traffic Selection policy specified, ther= e are two remote nodes B & C signaling the "A" with different Traffic Selec= tion policy, what should A do? 3. RFC5566 only specifies a simple indication of IPsec Encap, but does= n't do any of the IPsec configuration portion. As indicated by BESS WG chair, there are multiple drafts addressing IPsec i= n BESS, IDR, and WGs in Security Area, involved Chairs and ADs may need to = agree where is the home for continuing the discussion to avoid future confl= icts. Cheers, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F66B33E27Fsjceml521mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Just to reiterate the concerns and issues I raised d= uring IDR Thurs session discussion on using BGP signaling to achieve IPsec = Tunnel configuration (draft-hujun-idr-bgp-ipsec).

Copy I2NSF WG because there is similar discussion fo= r over a year.

Copy IPsecme WG as the group has many experts on the= IPsec configuration.

 

1.      I2NSF WG has an on-going discussion on Controller f= acilitated IPsec configuration which has been discussed for over a year. &n= bsp;Even though the I2NSF’s  IPsec Configuration is between Cont= roller and devices, whereas the BGP signaling IPsec Configuration proposed by draft-hujun-idr-bgp-ipsec is between peers, the = configuration parameters to the devices are for the same purpose, therefore= , should be aligned to avoid future conflicts to the industry.  <= /o:p>

 

2.      When using IPsec Tunnel between two peers, usually = they are separated by untrusted domain. If Router “A” is allowe= d to  gets the IPsec tunnel configurations from peers across untrusted= domain (instead of the today’s practice of from administrators), then many issues come up, for example:

 

How can a router “A” trust the Tr= affic Selection policy from a remote peer B? If the router “A” = already has its Traffic Selection policy configured for a specific IPsec tu= nnel, but different from the Traffic Selection policy from remote peer B, which policy should Route A enforce for the IPsec Tunnel? &= nbsp;If the router “A” doesn’t have Traffic Selection pol= icy specified, there are two remote nodes B & C signaling the “A&= #8221; with different Traffic Selection policy, what should A do?

 

3.      RFC5566 only specifies a simple indication of IPsec= Encap, but doesn’t do any of the IPsec configuration portion.

 

 

As indicated by BESS WG chair, there are multiple dr= afts addressing IPsec in BESS, IDR, and WGs in Security Area, involved Chai= rs and ADs may need to agree where is the home for continuing the discussio= n to avoid future conflicts.

 

 

Cheers,

Linda Dunbar

--_000_4A95BA014132FF49AE685FAB4B9F17F66B33E27Fsjceml521mbschi_-- From nobody Thu Mar 28 09:09:10 2019 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 BC49C1204E5; Thu, 28 Mar 2019 09:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0x-BxkCmE8W; Thu, 28 Mar 2019 09:09:06 -0700 (PDT) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03AE31202D6; Thu, 28 Mar 2019 09:09:06 -0700 (PDT) Received: from [IPv6:2001:67c:1232:144:e08f:7ce8:fb50:addb] (unknown [IPv6:2001:67c:1232:144:e08f:7ce8:fb50:addb]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: heidert) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id C6F1E35CC2F; Thu, 28 Mar 2019 17:09:03 +0100 (CET) To: "Panos Kampanakis (pkampana)" Cc: Tobias Guggemos , IPsecME WG , "draft-tjhai-ipsecme-hybrid-qske-ikev2@ietf.org" , "stefan@gazdag.de" References: <154748799416.9552.17299073748247797491.idtracker@ietfa.amsl.com> <000101d4ad6b$4a790ca0$df6b25e0$@gmail.com> <13654392-83f1-6995-6ca5-f72b2b0be7eb@nm.ifi.lmu.de> <001501d4e541$6b1af230$4150d690$@nm.ifi.lmu.de> <9a64907bac864d238e81d0d3dcf4c4bb@XCH-ALN-010.cisco.com> From: Tobias Heider Message-ID: <43644e2e-db7e-78da-0baf-0f26c7668d70@nm.ifi.lmu.de> Date: Thu, 28 Mar 2019 17:09:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <9a64907bac864d238e81d0d3dcf4c4bb@XCH-ALN-010.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US-large Archived-At: Subject: Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 16:09:09 -0000 On 3/28/19 2:19 PM, Panos Kampanakis (pkampana) wrote: > Thanks Tobias, Valery and Stefan. > > Imo Classic McEliece is impractical for use in live key negotiations in protocols like TLS, IKE, SSH etc. NIST will standardize more practical and secure postquantum KEMs and the added complexity for McEliece is not necessary. I understand that others might want McEliece because they trust it more. In that case, I suggest the mechanism described in #6 to be a "MAY" in the draft. > > Panos Hi Panos, as this draft does not specify any new key exchange methods I would not include it in this document at all. Best would probably be in a eventual future draft that also introduces McEliece and/or NTS-KEM transform ID for use with IKEv2. Regards, Tobias From nobody Thu Mar 28 09:18:09 2019 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 1F7C0120096 for ; Thu, 28 Mar 2019 09:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, 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 30hepgPpEcDz for ; Thu, 28 Mar 2019 09:18:04 -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 E9AEB12008A for ; Thu, 28 Mar 2019 09:18:03 -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 x2SGI06K014277 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 28 Mar 2019 18:18:00 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x2SGI0Rr010194; Thu, 28 Mar 2019 18:18:00 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23708.62392.134470.902330@fireball.acr.fi> Date: Thu, 28 Mar 2019 18:18:00 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 2 min Archived-At: Subject: [IPsec] Preliminary minutes for the IPsecME meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 16:18:08 -0000 Here is the preliminary minutes for the todays IPsecME meeting. Thank you for Yoav for taking the notes, and Paul for jabber scribing. If you have any comments, corrections or additions to minutes, post them as soon as possible. I will submit these to the meeting materials early next week. ---------------------------------------------------------------------- IETF 104 IPsecME WG meeting in Prague Thursday, March 28, 2019 10:50-12:20 Karlin 1/2 Agenda: - Agenda bashing, Logistics -- Chairs (5 min) - Draft status -- Chairs (10 min) - draft-ietf-ipsecme-split-dns - draft-ietf-ipsecme-qr-ikev2 - draft-ietf-ipsecme-implicit-iv - draft-ietf-ipsecme-ipv6-ipv4-codes - Work items - Intermediate Exchange in the IKEv2 Protocol - Valery Smyslov (10 min) - draft-smyslov-ipsecme-ikev2-aux-02 - Post-quantum Key Exchanges in IKEv2 - Valery Smyslov (10 min) - draft-tjhai-ipsecme-hybrid-qske-ikev2-03 - An implementor's view on Hybrid PQKE in IKEv2 - Tobias Heider (10 min) - PQC for IKEv2 in strongSwan - Leonie Bruckert (5 min) - ESP Header Compression and Diet-ESP - Tobias Guggemos (10 min) - draft-mglt-ipsecme-diet-esp-07 - Labeled IPsec - Paul Wouters (10 min) - draft-ietf-ipsecme-labeled-ipsec - IKEv1 Graveyard - Paul Wouters (5 min) - draft-pwouters-ikev1-ipsec-graveyard - Other presentations - IP Traffic Flow Security - Christian Hopps (15 min) - draft-hopps-ipsecme-iptfs-00 Agenda bashing, Logistics ========================= Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-chair-slides-04 (no agenda bashing) Draft status ============ draft-ietf-ipsecme-qr-ikev2 has a nit. Waiting for resolution to proceed Valery: Nit is a false positive; will make it go away very soon. Draft-ietf-ipsecme-ipv6-ipv4-codes ================================== Tero talked about draft-ietf-ipsecme-ipv6-ipv4-codes The room was polled about the alternate designs. Valery: Use status notification states rather than error. Prefers Tero's design (over his own) Tero: Not enought people commenting here. Both are acceptable. Will take to the list. Intermediate Exchange in the IKEv2 Protocol =========================================== Valery Smyslov - draft-smyslov-ipsecme-ikev2-aux-02 Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-intermediate-exchange-in-the-ikev2-00 Paul Wouters: Update 7296? Because it changes the msgid of IKE_AUTH Valery: Will check PW: Silly to send an empty intermediate. Need to know what to ef Valery: An accompanying document will define what it goes there. Always need a new one. PW: rename to IKE_INTERMEDIATE, since this applies to IKE only Valery: don't mind. Tommy: Seems fine with msgid. RFC 7296 doesn't require it to be 1 for IKE_AUTH Tobias Heider: ?? Valery: This is just a framework document Tero: It's OK to say this is just a framework. The documents that actually use it will define what goes in it. Tobias Guggemos: You can do PQ in IKE_INIT if you don't need IKE fragmentation. Tero: Too early for hum. Are we only going to ever have one? Tero: Any objection for adoption? (crickets) Tero: So will push the button and make this a WG draft (already asked on the list) Post-quantum Key Exchanges in IKEv2 =================================== Valery Smyslov - draft-tjhai-ipsecme-hybrid-qske-ikev2-03 Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-post-quantum-key-exchanges-in-ikev2-00 Surprisingly, a document using INTERMEDIATE IKE_INTERMEDIATE. What are the odds? Tero: I would hate to see this happening: 7 key exchanges sharing the same type 4. These are complete key exchange - not the same thing as DH. Need a new registry - they'll probably have their own parameters. Valery: They do the same thing as D-H: negotiate a key. Scott: Specifically we wanted to allow doing this group, then this other, then an isogeny group. This construct allows this to be done relatively straightforward. Tobias Heider: Like the idea of combining old (DH, ECDH) and new stuff Martin Fadman: Why the limit 7? Valery: Arbitrary Martin: Maybe this argues for the hierarchical idea. Valery: Scott things that in most cases different types will be used. We have three types, so let's double it Tero: Why negotiate all of this in the first SA payload? Interacts badly with parameters. Maybe negotiate them one-by-one along the way? Valery: What you are proposing will complicate things. Better to negotiate in advance what is going to follow. Maybe the responder doesn't support what you are going to require in the third round Mark ???: Having them all in one place is better Scott: About parameters: transforms can have attributes. Regarding the size of the SA proposal: not a problem with the encoding of IKEv2 proposals, at least for sane policies Tero: will continue on the list (as we're running out of time) Yoav: This is just for CCSA with PFS? We can still do CCSA without PFS Valery: Yes, and for rekeying of IKE SA Mark: Support adoption Tobias Heider: adopt, and rename to hybrid key exchange. Because it can be used with multiple classic D-H. Yoav: if we're adopting this should adopt also intermediate, and no point in adopting intermediate if we're not adopting this. Daniel Migault: Adopt, then make changes An implementor's view on Hybrid PQKE in IKEv2 ============================================= Tobias Heider Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-an-implementors-view-on-hybrid-pqke-00 Still controversy about breaking the PQ exhcnages out. Also with how to accomodate McEliece (large keys) Yoav: Can define a new "extended-size" payload to accomodate >64K key exchanges. PQC for IKEv2 in strongSwan =========================== Leonie Bruckert Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-pqc-for-ikev2-in-strongswan-00 Tobias Guggemos: We have 4 implementations. Maybe do a Hackathon? Tero: You going to organize this? Thanks! Tobias: Yes, if you fly me to Montreal Dave: Will take to the list ESP Header Compression and Diet-ESP =================================== Tobias Guggemos - draft-mglt-ipsecme-diet-esp-07 Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-esp-header-compression-and-diet-esp-00 (discussion on adoption will be done on the list) Labeled IPsec ============= Paul Wouters - draft-ietf-ipsecme-labeled-ipsec Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-labeled-ipsec-00 (already a WG draft. Discussion on Paul's proposed changed in selecting TS types will be done on the list) IKEv1 Graveyard =============== Paul Wouters - draft-pwouters-ikev1-ipsec-graveyard Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-ikev1-graveyard-00 Tero: We don't instruct people what to use. We can't tell people what to use. Dan Harkins: IKEv1 is already obsoleted. What more do we need? PW: We want to tell people not to use it. Smyslov: Support deprecating IKEv1 Benedict: Cannot get rid of 3DES. Used in telephony. PW: Yes, for now, but it's time for CAST IP Traffic Flow Security ======================== Christian Hopps - draft-hopps-ipsecme-iptfs-00 Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-ip-traffic-flow-security-00 Valery: Interesting proposal. You fragment IP packets to arbitrary size and then re-assemble. This complicates IPsec implementation. I'd rather sacrifice some performance (efficiency?) by allowing combining but not fragmenting. Christian: Let's discuss on the list Paul Wouters: Privacy and compressing are different goals. Why do we need the extra things. Christian: the 20,000% overhead. Lou Berger: The present thing is not deployable. We're destroying the available bandwidth with the trimodal distribution of packets. -- discussion to continue on list -- kivinen@iki.fi From nobody Thu Mar 28 10:15:02 2019 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 D530612024A for ; Thu, 28 Mar 2019 10:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 2SGsVrke8ZMU for ; Thu, 28 Mar 2019 10:14:58 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85C6B12002F for ; Thu, 28 Mar 2019 10:14:58 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 44VWhK05J3z8tJh; Thu, 28 Mar 2019 18:14:57 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.51]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 44VWhJ6Fn2z1xp3; Thu, 28 Mar 2019 18:14:56 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM22.corporate.adroot.infra.ftgroup ([fe80::954c:232a:f07d:25af%21]) with mapi id 14.03.0439.000; Thu, 28 Mar 2019 18:14:56 +0100 From: To: Tero Kivinen , "ipsec@ietf.org" Thread-Topic: [IPsec] Preliminary minutes for the IPsecME meeting Thread-Index: AQHU5YHcayZSAlCJfEuRaAsFDU2OLqYhRo7g Date: Thu, 28 Mar 2019 17:14:56 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA4F0BD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <23708.62392.134470.902330@fireball.acr.fi> In-Reply-To: <23708.62392.134470.902330@fireball.acr.fi> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Preliminary minutes for the IPsecME meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 17:15:01 -0000 Hi Tero,=20 Thank you for sharing the minutes.=20 Please see inline a comment to Valery.=20 Cheers, Med > -----Message d'origine----- > De=A0: IPsec [mailto:ipsec-bounces@ietf.org] De la part de Tero Kivinen > Envoy=E9=A0: jeudi 28 mars 2019 17:18 > =C0=A0: ipsec@ietf.org > Objet=A0: [IPsec] Preliminary minutes for the IPsecME meeting >=20 > Here is the preliminary minutes for the todays IPsecME meeting. Thank > you for Yoav for taking the notes, and Paul for jabber scribing. >=20 > If you have any comments, corrections or additions to minutes, post > them as soon as possible. I will submit these to the meeting materials > early next week. > ---------------------------------------------------------------------- > IETF 104 IPsecME WG meeting in Prague > Thursday, March 28, 2019 > 10:50-12:20 Karlin 1/2 >=20 > Agenda: > - Agenda bashing, Logistics -- Chairs (5 min) > - Draft status -- Chairs (10 min) > - draft-ietf-ipsecme-split-dns > - draft-ietf-ipsecme-qr-ikev2 > - draft-ietf-ipsecme-implicit-iv > - draft-ietf-ipsecme-ipv6-ipv4-codes > - Work items > - Intermediate Exchange in the IKEv2 Protocol - Valery Smyslov (10 min) > - draft-smyslov-ipsecme-ikev2-aux-02 > - Post-quantum Key Exchanges in IKEv2 - Valery Smyslov (10 min) > - draft-tjhai-ipsecme-hybrid-qske-ikev2-03 > - An implementor's view on Hybrid PQKE in IKEv2 - Tobias Heider (10 min= ) > - PQC for IKEv2 in strongSwan - Leonie Bruckert (5 min) > - ESP Header Compression and Diet-ESP - Tobias Guggemos (10 min) > - draft-mglt-ipsecme-diet-esp-07 > - Labeled IPsec - Paul Wouters (10 min) > - draft-ietf-ipsecme-labeled-ipsec > - IKEv1 Graveyard - Paul Wouters (5 min) > - draft-pwouters-ikev1-ipsec-graveyard > - Other presentations > - IP Traffic Flow Security - Christian Hopps (15 min) > - draft-hopps-ipsecme-iptfs-00 >=20 > Agenda bashing, Logistics > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104- > ipsecme-chair-slides-04 >=20 > (no agenda bashing) >=20 >=20 > Draft status > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > draft-ietf-ipsecme-qr-ikev2 has a nit. Waiting for resolution to proceed > Valery: Nit is a false positive; will make it go away very soon. >=20 >=20 > Draft-ietf-ipsecme-ipv6-ipv4-codes > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Tero talked about draft-ietf-ipsecme-ipv6-ipv4-codes > The room was polled about the alternate designs. > Valery: Use status notification states rather than error. [Med] The draft does not use error types but notification status types. =20 Prefers > Tero's design (over his own) > Tero: Not enought people commenting here. Both are acceptable. Will > take to the list. > >=20 > Intermediate Exchange in the IKEv2 Protocol > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Valery Smyslov - draft-smyslov-ipsecme-ikev2-aux-02 > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104- > ipsecme-intermediate-exchange-in-the-ikev2-00 >=20 > Paul Wouters: Update 7296? Because it changes the msgid of IKE_AUTH > Valery: Will check > PW: Silly to send an empty intermediate. Need to know what to ef > Valery: An accompanying document will define what it goes there. > Always need a new one. > PW: rename to IKE_INTERMEDIATE, since this applies to IKE only > Valery: don't mind. > Tommy: Seems fine with msgid. RFC 7296 doesn't require it to be 1 for > IKE_AUTH > Tobias Heider: ?? > Valery: This is just a framework document > Tero: It's OK to say this is just a framework. The documents that > actually use it will define what goes in it. > Tobias Guggemos: You can do PQ in IKE_INIT if you don't need IKE > fragmentation. > Tero: Too early for hum. Are we only going to ever have one? > Tero: Any objection for adoption? >=20 > (crickets) >=20 > Tero: So will push the button and make this a WG draft (already asked > on the list) >=20 >=20 > Post-quantum Key Exchanges in IKEv2 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Valery Smyslov - draft-tjhai-ipsecme-hybrid-qske-ikev2-03 > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104- > ipsecme-post-quantum-key-exchanges-in-ikev2-00 >=20 > Surprisingly, a document using INTERMEDIATE IKE_INTERMEDIATE. What > are the odds? >=20 > Tero: I would hate to see this happening: 7 key exchanges sharing the > same type 4. These are complete key exchange - not the same thing a= s > DH. Need a new registry - they'll probably have their own parameter= s. > Valery: They do the same thing as D-H: negotiate a key. > Scott: Specifically we wanted to allow doing this group, then this > other, then an isogeny group. This construct allows this to be > done relatively straightforward. > Tobias Heider: Like the idea of combining old (DH, ECDH) and new stuff > Martin Fadman: Why the limit 7? > Valery: Arbitrary > Martin: Maybe this argues for the hierarchical idea. > Valery: Scott things that in most cases different types will be used. > We have three types, so let's double it > Tero: Why negotiate all of this in the first SA payload? Interacts > badly with parameters. Maybe negotiate them one-by-one along > the way? > Valery: What you are proposing will complicate things. Better to > negotiate in advance what is going to follow. Maybe the > responder doesn't support what you are going to require in the > third round > Mark ???: Having them all in one place is better > Scott: About parameters: transforms can have attributes. Regarding the > size of the SA proposal: not a problem with the encoding of > IKEv2 proposals, at least for sane policies > Tero: will continue on the list (as we're running out of time) > Yoav: This is just for CCSA with PFS? We can still do CCSA without PFS > Valery: Yes, and for rekeying of IKE SA > Mark: Support adoption > Tobias Heider: adopt, and rename to hybrid key exchange. Because it > can be used with multiple classic D-H. > Yoav: if we're adopting this should adopt also intermediate, and no > point in adopting intermediate if we're not adopting this. > Daniel Migault: Adopt, then make changes >=20 >=20 > An implementor's view on Hybrid PQKE in IKEv2 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Tobias Heider > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104- > ipsecme-an-implementors-view-on-hybrid-pqke-00 >=20 > Still controversy about breaking the PQ exhcnages out. Also with how > to accomodate McEliece (large keys) > Yoav: Can define a new "extended-size" payload to accomodate >64K key > exchanges. >=20 >=20 > PQC for IKEv2 in strongSwan > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Leonie Bruckert > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104- > ipsecme-pqc-for-ikev2-in-strongswan-00 >=20 > Tobias Guggemos: We have 4 implementations. Maybe do a Hackathon? > Tero: You going to organize this? Thanks! > Tobias: Yes, if you fly me to Montreal > Dave: Will take to the list >=20 >=20 > ESP Header Compression and Diet-ESP > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Tobias Guggemos - draft-mglt-ipsecme-diet-esp-07 > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104- > ipsecme-esp-header-compression-and-diet-esp-00 >=20 > (discussion on adoption will be done on the list) >=20 >=20 > Labeled IPsec > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Paul Wouters - draft-ietf-ipsecme-labeled-ipsec > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104- > ipsecme-labeled-ipsec-00 >=20 > (already a WG draft. Discussion on Paul's proposed changed in > selecting TS types will be done on the list) >=20 >=20 > IKEv1 Graveyard > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Paul Wouters - draft-pwouters-ikev1-ipsec-graveyard > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104- > ipsecme-ikev1-graveyard-00 >=20 > Tero: We don't instruct people what to use. We can't tell people what > to use. > Dan Harkins: IKEv1 is already obsoleted. What more do we need? > PW: We want to tell people not to use it. > Smyslov: Support deprecating IKEv1 > Benedict: Cannot get rid of 3DES. Used in telephony. > PW: Yes, for now, but it's time for CAST >=20 >=20 > IP Traffic Flow Security > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Christian Hopps - draft-hopps-ipsecme-iptfs-00 > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104- > ipsecme-ip-traffic-flow-security-00 >=20 > Valery: Interesting proposal. You fragment IP packets to arbitrary > size and then re-assemble. This complicates IPsec > implementation. I'd rather sacrifice some performance > (efficiency?) by allowing combining but not fragmenting. > Christian: Let's discuss on the list > Paul Wouters: Privacy and compressing are different goals. Why do we > need the extra things. > Christian: the 20,000% overhead. > Lou Berger: The present thing is not deployable. We're destroying the > available bandwidth with the trimodal distribution of packets. >=20 > -- discussion to continue on list > -- > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Mar 28 10:36:19 2019 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 E54D912031A for ; Thu, 28 Mar 2019 10:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnHpZ5tg8qUH for ; Thu, 28 Mar 2019 10:36:13 -0700 (PDT) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A204A1202C4 for ; Thu, 28 Mar 2019 10:36:13 -0700 (PDT) Received: from [IPv6:2001:67c:1232:144:e08f:7ce8:fb50:addb] (unknown [IPv6:2001:67c:1232:144:e08f:7ce8:fb50:addb]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: heidert) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id 9CC2235D55B for ; Thu, 28 Mar 2019 18:36:11 +0100 (CET) To: ipsec@ietf.org References: <23708.62392.134470.902330@fireball.acr.fi> From: Tobias Heider Message-ID: <0d678659-9be6-fe1f-600a-e9fa79f4db3c@nm.ifi.lmu.de> Date: Thu, 28 Mar 2019 18:36:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <23708.62392.134470.902330@fireball.acr.fi> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US-large Archived-At: Subject: Re: [IPsec] Preliminary minutes for the IPsecME meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 17:36:18 -0000 On 3/28/19 5:18 PM, Tero Kivinen wrote: > Tobias Heider: ?? The question I asked was: The draft already says that INTERMEDIATE can not be used without another document that specifies what payloads are sent in INTERMEDIATE. Why can't that additional document also define it's own exchange ID for that instance of INTERMEDIATE instead of using the same ID for different things. From nobody Thu Mar 28 12:37:03 2019 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 3899112032E for ; Thu, 28 Mar 2019 12:37:03 -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 HsSA3Tdon200 for ; Thu, 28 Mar 2019 12:37:00 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 8768A120282 for ; Thu, 28 Mar 2019 12:36:59 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id q1so24413922wrp.0 for ; Thu, 28 Mar 2019 12:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:content-language:thread-index; bh=rOgG/xwfcTM5wRIETBWFlNIxxhcqerMrRJ1YLJBDlD0=; b=Xh+x8hUT7UPn4C8DnGJLHGXOiU1ZK5CwJlzPN3y1xJrC5EE+Bl+aZyAB57Hr6gjPxE lSqJ11ox6IVom9M8sJJt95rHJVoQE8KvyOYZQBz2FhagE2078tdOayDDuP9EVvPGBbPr 9WHdkbH2PNWky+Tl8TH6AyU7CXTIQ9RZrLDX5xL6Z81NRd6nEQcZMjEXFSJm8QLa11gZ MeexuxSKr3wkGnTR7y1rFE6AXIDQ9vRyPF5+gLmNRwxVyjBgHOqPrpzRZAkWSkx4GVb4 Nm7yKolzsMry6Ns13pSttNVfKQW1u5PetpJuStyGw21ZW86HZNo3B7ahGu9hogJKbonX UWrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=rOgG/xwfcTM5wRIETBWFlNIxxhcqerMrRJ1YLJBDlD0=; b=IgrO4b0FN0eXatBvBDquGzRJJh+unurhaC++7Zg+hO+KwyGX6L+Mnj8dL3r1WUhB0m gojxsPx0lAP65g9MT8wKP4wxn4M6Aty7bDQWPxImiNqHdjbs6vdBxs0Ng1E+k5FJrAqN 48pDKHesh1XtROW6MTL3ZPBLXX53n0OCYnffmmuSMkCZv45Vhfz2h85pxLIPp8HmHl3j A413jTYNcFzAY9w1yDxk2SpnXDiRn1QM8b71mOxdh58e63tV3QBkebjSOS7Bhl1klSF3 u4qSTJDZE1U1H7yh/u5cCOYhx4KRB82PKh+AcH033Jl6/UQy8STTNYXla6oSBkDYvQNX V57A== X-Gm-Message-State: APjAAAUUcdWVGettv1HywH7LAcLCtpYAMN5CxWmatdjvcI543dxpTv3t aIvkVxgAVoYXuw4oAtMyuR4zvEeUqAw= X-Google-Smtp-Source: APXvYqwesL9BlZo0JsG3gnpyD8eoGH7uave6T9e9tmWyJyeO5OIv+3+1PLvkDAwNSv+6NVUgH+bKlw== X-Received: by 2002:adf:8bc5:: with SMTP id w5mr23636212wra.226.1553801817274; Thu, 28 Mar 2019 12:36:57 -0700 (PDT) Received: from svannotebook ([81.0.251.129]) by smtp.gmail.com with ESMTPSA id s18sm3576wmc.41.2019.03.28.12.36.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 12:36:56 -0700 (PDT) From: "Valery Smyslov" To: , "'Tero Kivinen'" , References: <23708.62392.134470.902330@fireball.acr.fi> <787AE7BB302AE849A7480A190F8B93302EA4F0BD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA4F0BD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Thu, 28 Mar 2019 22:36:54 +0300 Message-ID: <02ba01d4e59d$9a3815a0$cea840e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: ru Thread-Index: AQJD+PU9r1T7ZsKwvuYC69+vJUzdJQF0DLzfpTenTyA= Archived-At: Subject: Re: [IPsec] Preliminary minutes for the IPsecME meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 19:37:03 -0000 Hi Med, I know that your current draft doesn't use error type notifications, as it was in its first version. My comment was too concise and thus not clear enough. I just wanted to support Tero's ideas to further simplify the design (and I suggested similar ideas before). So I meant that there are still ways to make the draft simpler, as it was done when you switched from error to status and reduced the number of notifications. Sorry for not being clear. Regards, Valery. > Hi Tero, >=20 > Thank you for sharing the minutes. >=20 > Please see inline a comment to Valery. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: IPsec [mailto:ipsec-bounces@ietf.org] De la part de Tero = Kivinen > > Envoy=E9=A0: jeudi 28 mars 2019 17:18 =C0=A0: ipsec@ietf.org = Objet=A0: [IPsec] > > Preliminary minutes for the IPsecME meeting > > > > Here is the preliminary minutes for the todays IPsecME meeting. = Thank > > you for Yoav for taking the notes, and Paul for jabber scribing. > > > > If you have any comments, corrections or additions to minutes, post > > them as soon as possible. I will submit these to the meeting = materials > > early next week. > > = ---------------------------------------------------------------------- > > IETF 104 IPsecME WG meeting in Prague > > Thursday, March 28, 2019 > > 10:50-12:20 Karlin 1/2 > > > > Agenda: > > - Agenda bashing, Logistics -- Chairs (5 min) > > - Draft status -- Chairs (10 min) > > - draft-ietf-ipsecme-split-dns > > - draft-ietf-ipsecme-qr-ikev2 > > - draft-ietf-ipsecme-implicit-iv > > - draft-ietf-ipsecme-ipv6-ipv4-codes > > - Work items > > - Intermediate Exchange in the IKEv2 Protocol - Valery Smyslov (10 min) > > - draft-smyslov-ipsecme-ikev2-aux-02 > > - Post-quantum Key Exchanges in IKEv2 - Valery Smyslov (10 min) > > - draft-tjhai-ipsecme-hybrid-qske-ikev2-03 > > - An implementor's view on Hybrid PQKE in IKEv2 - Tobias Heider = (10 min) > > - PQC for IKEv2 in strongSwan - Leonie Bruckert (5 min) > > - ESP Header Compression and Diet-ESP - Tobias Guggemos (10 min) > > - draft-mglt-ipsecme-diet-esp-07 > > - Labeled IPsec - Paul Wouters (10 min) > > - draft-ietf-ipsecme-labeled-ipsec > > - IKEv1 Graveyard - Paul Wouters (5 min) > > - draft-pwouters-ikev1-ipsec-graveyard > > - Other presentations > > - IP Traffic Flow Security - Christian Hopps (15 min) > > - draft-hopps-ipsecme-iptfs-00 > > > > Agenda bashing, Logistics > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > > Slides: = https://datatracker.ietf.org/meeting/104/materials/slides-104- > > ipsecme-chair-slides-04 > > > > (no agenda bashing) > > > > > > Draft status > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > draft-ietf-ipsecme-qr-ikev2 has a nit. Waiting for resolution to > > proceed > > Valery: Nit is a false positive; will make it go away very soon. > > > > > > Draft-ietf-ipsecme-ipv6-ipv4-codes > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Tero talked about draft-ietf-ipsecme-ipv6-ipv4-codes > > The room was polled about the alternate designs. > > Valery: Use status notification states rather than error. >=20 > [Med] The draft does not use error types but notification status = types. >=20 > Prefers > > Tero's design (over his own) > > Tero: Not enought people commenting here. Both are acceptable. Will > > take to the list. > > > > > > Intermediate Exchange in the IKEv2 Protocol > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Valery Smyslov - draft-smyslov-ipsecme-ikev2-aux-02 > > Slides: = https://datatracker.ietf.org/meeting/104/materials/slides-104- > > ipsecme-intermediate-exchange-in-the-ikev2-00 > > > > Paul Wouters: Update 7296? Because it changes the msgid of IKE_AUTH > > Valery: Will check > > PW: Silly to send an empty intermediate. Need to know what to ef > > Valery: An accompanying document will define what it goes there. > > Always need a new one. > > PW: rename to IKE_INTERMEDIATE, since this applies to IKE only > > Valery: don't mind. > > Tommy: Seems fine with msgid. RFC 7296 doesn't require it to be 1 = for > > IKE_AUTH > > Tobias Heider: ?? > > Valery: This is just a framework document > > Tero: It's OK to say this is just a framework. The documents that > > actually use it will define what goes in it. > > Tobias Guggemos: You can do PQ in IKE_INIT if you don't need IKE > > fragmentation. > > Tero: Too early for hum. Are we only going to ever have one? > > Tero: Any objection for adoption? > > > > (crickets) > > > > Tero: So will push the button and make this a WG draft (already = asked > > on the list) > > > > > > Post-quantum Key Exchanges in IKEv2 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Valery Smyslov - draft-tjhai-ipsecme-hybrid-qske-ikev2-03 > > Slides: = https://datatracker.ietf.org/meeting/104/materials/slides-104- > > ipsecme-post-quantum-key-exchanges-in-ikev2-00 > > > > Surprisingly, a document using INTERMEDIATE IKE_INTERMEDIATE. What > > are the odds? > > > > Tero: I would hate to see this happening: 7 key exchanges sharing = the > > same type 4. These are complete key exchange - not the same = thing as > > DH. Need a new registry - they'll probably have their own parameters. > > Valery: They do the same thing as D-H: negotiate a key. > > Scott: Specifically we wanted to allow doing this group, then this > > other, then an isogeny group. This construct allows this to = be > > done relatively straightforward. > > Tobias Heider: Like the idea of combining old (DH, ECDH) and new = stuff > > Martin Fadman: Why the limit 7? > > Valery: Arbitrary > > Martin: Maybe this argues for the hierarchical idea. > > Valery: Scott things that in most cases different types will be = used. > > We have three types, so let's double it > > Tero: Why negotiate all of this in the first SA payload? Interacts > > badly with parameters. Maybe negotiate them one-by-one along > > the way? > > Valery: What you are proposing will complicate things. Better to > > negotiate in advance what is going to follow. Maybe the > > responder doesn't support what you are going to require in the > > third round > > Mark ???: Having them all in one place is better > > Scott: About parameters: transforms can have attributes. Regarding = the > > size of the SA proposal: not a problem with the encoding of > > IKEv2 proposals, at least for sane policies > > Tero: will continue on the list (as we're running out of time) > > Yoav: This is just for CCSA with PFS? We can still do CCSA without = PFS > > Valery: Yes, and for rekeying of IKE SA > > Mark: Support adoption > > Tobias Heider: adopt, and rename to hybrid key exchange. Because it > > can be used with multiple classic D-H. > > Yoav: if we're adopting this should adopt also intermediate, and no > > point in adopting intermediate if we're not adopting this. > > Daniel Migault: Adopt, then make changes > > > > > > An implementor's view on Hybrid PQKE in IKEv2 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Tobias Heider > > Slides: = https://datatracker.ietf.org/meeting/104/materials/slides-104- > > ipsecme-an-implementors-view-on-hybrid-pqke-00 > > > > Still controversy about breaking the PQ exhcnages out. Also with how > > to accomodate McEliece (large keys) > > Yoav: Can define a new "extended-size" payload to accomodate >64K = key > > exchanges. > > > > > > PQC for IKEv2 in strongSwan > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > Leonie Bruckert > > Slides: = https://datatracker.ietf.org/meeting/104/materials/slides-104- > > ipsecme-pqc-for-ikev2-in-strongswan-00 > > > > Tobias Guggemos: We have 4 implementations. Maybe do a Hackathon? > > Tero: You going to organize this? Thanks! > > Tobias: Yes, if you fly me to Montreal > > Dave: Will take to the list > > > > > > ESP Header Compression and Diet-ESP > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Tobias Guggemos - draft-mglt-ipsecme-diet-esp-07 > > Slides: = https://datatracker.ietf.org/meeting/104/materials/slides-104- > > ipsecme-esp-header-compression-and-diet-esp-00 > > > > (discussion on adoption will be done on the list) > > > > > > Labeled IPsec > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Paul Wouters - draft-ietf-ipsecme-labeled-ipsec > > Slides: = https://datatracker.ietf.org/meeting/104/materials/slides-104- > > ipsecme-labeled-ipsec-00 > > > > (already a WG draft. Discussion on Paul's proposed changed in > > selecting TS types will be done on the list) > > > > > > IKEv1 Graveyard > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Paul Wouters - draft-pwouters-ikev1-ipsec-graveyard > > Slides: = https://datatracker.ietf.org/meeting/104/materials/slides-104- > > ipsecme-ikev1-graveyard-00 > > > > Tero: We don't instruct people what to use. We can't tell people = what > > to use. > > Dan Harkins: IKEv1 is already obsoleted. What more do we need? > > PW: We want to tell people not to use it. > > Smyslov: Support deprecating IKEv1 > > Benedict: Cannot get rid of 3DES. Used in telephony. > > PW: Yes, for now, but it's time for CAST > > > > > > IP Traffic Flow Security > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Christian Hopps - draft-hopps-ipsecme-iptfs-00 > > Slides: = https://datatracker.ietf.org/meeting/104/materials/slides-104- > > ipsecme-ip-traffic-flow-security-00 > > > > Valery: Interesting proposal. You fragment IP packets to arbitrary > > size and then re-assemble. This complicates IPsec > > implementation. I'd rather sacrifice some performance > > (efficiency?) by allowing combining but not fragmenting. > > Christian: Let's discuss on the list > > Paul Wouters: Privacy and compressing are different goals. Why do we > > need the extra things. > > Christian: the 20,000% overhead. > > Lou Berger: The present thing is not deployable. We're destroying = the > > available bandwidth with the trimodal distribution of packets. > > > > -- discussion to continue on list > > -- > > kivinen@iki.fi > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Mar 28 23:14:36 2019 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 D79581201C6 for ; Thu, 28 Mar 2019 23:14:33 -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 8yC8rWhqcESz for ; Thu, 28 Mar 2019 23:14:32 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 B1AA012015D for ; Thu, 28 Mar 2019 23:14:31 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id t17so1044553wrw.13 for ; Thu, 28 Mar 2019 23:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:content-language:thread-index; bh=zT3w08jZS61S3ZbWhGRaQunEyTK7SgUlul41Sv+HP38=; b=lJZknc3yxrvD6eA2+ogRxakgzWDRHBSMjEKxxpW1cRfPf3HJ1vLCoS6kT8w844dhwD qx4X1bDGYeaO6a2px98DeqZq6MQke8RQVVvYR/zG7AgVfoiw4dpJwIkqIeEV5+ZazCVx 2xxu8x4l0EohCVqyWtNuvPkE8pQGKJqZA0kZ/YRjCYvXb6zqOAGmBFhVVOAat25z5EzO Gz+fPlCF4xpMC500lJAaXwJaVPSqywmm2gni8VDZQY2RiQ4tuNkdiXj22ulKFfJEtwwA 0GHRwQQYNeV0nz6cMLOoM5XRlIHxg87I+AQckH/avjND0FKqYbMDFkHahzYv97ctUTvD Q6Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=zT3w08jZS61S3ZbWhGRaQunEyTK7SgUlul41Sv+HP38=; b=s8FFCEIgoc1XjZhKGrjUkpSNuEH686xAYleu3yWjBHuV6Oj+bh8O9CwQcSKrezWqqO PkwDrXH72LqUVLuFBxgSBGtOC0DfrcHennSJNU+hfezFvkFIya94UhIMMi9wuvZBFTs/ KhWMRp8XICeU1FSIzuiU7hfUmHNGaKDGAJytkPT5HePKgDaDUKn7eqm22LtQnnTrB4sM cSMGFDXzrhho6cAeXJIZYCLZwyMgn1OD9cFo1/WPDM5NlLC3xKBMqJ89MGLfdALB2XuZ WlfX0PiVwe/2zfUnUeos6WaaO7iWxG4zWEkFSOxAAOdDfsL/wO/PqMfq9zdAqKfDeW/2 D+jA== X-Gm-Message-State: APjAAAX1N5G2zkNht/iIaEcLU/CfWtOiLiqF0uTYwRQN0u5hkVF5xD/P xsy/5DA82EYxXowF770ghDEJpLzPlj8= X-Google-Smtp-Source: APXvYqzr8BmY0VHYU+aWsuLEuOjDvJRWkLcm4+Nxgwy1aNIQx796uxfwn1NdddprwXR7G5CykGsVAA== X-Received: by 2002:a5d:5108:: with SMTP id s8mr27173092wrt.99.1553840070225; Thu, 28 Mar 2019 23:14:30 -0700 (PDT) Received: from svannotebook ([81.0.251.129]) by smtp.gmail.com with ESMTPSA id n4sm1628779wrx.39.2019.03.28.23.14.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 23:14:29 -0700 (PDT) From: "Valery Smyslov" To: "'Christian Hopps'" , References: <155231377348.23058.4682503726354987752@ietfa.amsl.com> In-Reply-To: Date: Fri, 29 Mar 2019 09:14:27 +0300 Message-ID: <02fb01d4e5f6$aac3a110$004ae330$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: ru Thread-Index: AQHDC2i80LRgGX+akLu0yxdYVb2DCQJ2/jYBpjIcrKA= Archived-At: Subject: Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 06:14:34 -0000 Hi Christian, having think a bit more about reassembling on a receiving side, I think that there may be some issues. You rely on ESP SN to properly reassemble the IP packets, but there is at least one case when it doesn't work - when IPsec protects multicast traffic and there are several senders in SA. In this case SN will repeat, so your reassembling mechanism won't work (well, there is no any replay protection in this case too). And I really want to make reassembling feature optional and negotiable. Regards, Valery. > Hi ipsecme folks, > > Here's some new work on improving IP traffic flow security. I've requested a > presentation slot from the chairs for the upcoming ipsecme WG meeting @ > IETF 104, and will hopefully be able to present this work at that time as well. > > Thanks, > Chris. > > internet-drafts@ietf.org writes: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > > > Title : IP Traffic Flow Security > > Author : Christian Hopps > > Filename : draft-hopps-ipsecme-iptfs-00.txt > > Pages : 22 > > Date : 2019-03-11 > > > > Abstract: > > This document describes a mechanism to enhance IPsec traffic flow > > security by adding traffic flow confidentiality to encrypted IP > > encapsulated traffic. Traffic flow confidentiality is provided by > > obscuring the size and frequency of IP traffic using a fixed-sized, > > constant-send-rate IPsec tunnel. The solution allows for congestion > > control as well. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-hopps-ipsecme-iptfs/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-hopps-ipsecme-iptfs-00 > > https://datatracker.ietf.org/doc/html/draft-hopps-ipsecme-iptfs-00 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Thu Mar 28 23:43:24 2019 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 B6494120193 for ; Thu, 28 Mar 2019 23:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 NPGWxRbcVRna for ; Thu, 28 Mar 2019 23:43:13 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A21F61201AA for ; Thu, 28 Mar 2019 23:43:12 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 44Vsct5W2mzBs9c; Fri, 29 Mar 2019 07:43:10 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.70]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 44Vsct4YB3z2xC0; Fri, 29 Mar 2019 07:43:10 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM33.corporate.adroot.infra.ftgroup ([fe80::c911:d24e:cc19:afa7%21]) with mapi id 14.03.0439.000; Fri, 29 Mar 2019 07:43:10 +0100 From: To: Valery Smyslov , 'Tero Kivinen' , "ipsec@ietf.org" Thread-Topic: [IPsec] Preliminary minutes for the IPsecME meeting Thread-Index: AQHU5YHcayZSAlCJfEuRaAsFDU2OLqYhRo7ggAAY3ACAAMcakA== Date: Fri, 29 Mar 2019 06:43:09 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA4F6D5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <23708.62392.134470.902330@fireball.acr.fi> <787AE7BB302AE849A7480A190F8B93302EA4F0BD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <02ba01d4e59d$9a3815a0$cea840e0$@gmail.com> In-Reply-To: <02ba01d4e59d$9a3815a0$cea840e0$@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Preliminary minutes for the IPsecME meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 06:43:16 -0000 Hi Valery, Thank you for sharing your thoughts.=20 As shown in the slides presented in the meeting, both approaches are accept= able and simple. There is a difference at the server side though: in the ap= proach currently documented in the I-D, the code is blindly returned (i.e.,= the code is explicit about the capability) while in the other one the code= is returned as a function of the requested address.=20 I personally like explicit codes as this is helpful for troubleshooting at = the initiator side when problems are encountered.=20 That's said, I don't have a problem to make the change if this is what the = WG wants.=20 Cheers, Med > -----Message d'origine----- > De=A0: Valery Smyslov [mailto:smyslov.ietf@gmail.com] > Envoy=E9=A0: jeudi 28 mars 2019 20:37 > =C0=A0: BOUCADAIR Mohamed TGI/OLN; 'Tero Kivinen'; ipsec@ietf.org > Objet=A0: RE: [IPsec] Preliminary minutes for the IPsecME meeting >=20 > Hi Med, >=20 > I know that your current draft doesn't use error type notifications, > as it was in its first version. My comment was too concise and thus > not clear enough. I just wanted to support Tero's ideas > to further simplify the design (and I suggested similar ideas before). > So I meant that there are still ways to make the draft simpler, > as it was done when you switched from error to status and reduced the > number of notifications. Sorry for not being clear. >=20 > Regards, > Valery. >=20 > > Hi Tero, > > > > Thank you for sharing the minutes. > > > > Please see inline a comment to Valery. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: IPsec [mailto:ipsec-bounces@ietf.org] De la part de Tero Kivin= en > > > Envoy=E9=A0: jeudi 28 mars 2019 17:18 =C0=A0: ipsec@ietf.org Objet=A0= : [IPsec] > > > Preliminary minutes for the IPsecME meeting > > > > > > Here is the preliminary minutes for the todays IPsecME meeting. Thank > > > you for Yoav for taking the notes, and Paul for jabber scribing. > > > > > > If you have any comments, corrections or additions to minutes, post > > > them as soon as possible. I will submit these to the meeting material= s > > > early next week. > > > ---------------------------------------------------------------------= - > > > IETF 104 IPsecME WG meeting in Prague > > > Thursday, March 28, 2019 > > > 10:50-12:20 Karlin 1/2 > > > > > > Agenda: > > > - Agenda bashing, Logistics -- Chairs (5 min) > > > - Draft status -- Chairs (10 min) > > > - draft-ietf-ipsecme-split-dns > > > - draft-ietf-ipsecme-qr-ikev2 > > > - draft-ietf-ipsecme-implicit-iv > > > - draft-ietf-ipsecme-ipv6-ipv4-codes > > > - Work items > > > - Intermediate Exchange in the IKEv2 Protocol - Valery Smyslov (10 > min) > > > - draft-smyslov-ipsecme-ikev2-aux-02 > > > - Post-quantum Key Exchanges in IKEv2 - Valery Smyslov (10 min) > > > - draft-tjhai-ipsecme-hybrid-qske-ikev2-03 > > > - An implementor's view on Hybrid PQKE in IKEv2 - Tobias Heider (10 > min) > > > - PQC for IKEv2 in strongSwan - Leonie Bruckert (5 min) > > > - ESP Header Compression and Diet-ESP - Tobias Guggemos (10 min) > > > - draft-mglt-ipsecme-diet-esp-07 > > > - Labeled IPsec - Paul Wouters (10 min) > > > - draft-ietf-ipsecme-labeled-ipsec > > > - IKEv1 Graveyard - Paul Wouters (5 min) > > > - draft-pwouters-ikev1-ipsec-graveyard > > > - Other presentations > > > - IP Traffic Flow Security - Christian Hopps (15 min) > > > - draft-hopps-ipsecme-iptfs-00 > > > > > > Agenda bashing, Logistics > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104= - > > > ipsecme-chair-slides-04 > > > > > > (no agenda bashing) > > > > > > > > > Draft status > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > draft-ietf-ipsecme-qr-ikev2 has a nit. Waiting for resolution to > > > proceed > > > Valery: Nit is a false positive; will make it go away very soon. > > > > > > > > > Draft-ietf-ipsecme-ipv6-ipv4-codes > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > Tero talked about draft-ietf-ipsecme-ipv6-ipv4-codes > > > The room was polled about the alternate designs. > > > Valery: Use status notification states rather than error. > > > > [Med] The draft does not use error types but notification status types. > > > > Prefers > > > Tero's design (over his own) > > > Tero: Not enought people commenting here. Both are acceptable. Will > > > take to the list. > > > > > > > > > Intermediate Exchange in the IKEv2 Protocol > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > Valery Smyslov - draft-smyslov-ipsecme-ikev2-aux-02 > > > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104= - > > > ipsecme-intermediate-exchange-in-the-ikev2-00 > > > > > > Paul Wouters: Update 7296? Because it changes the msgid of IKE_AUTH > > > Valery: Will check > > > PW: Silly to send an empty intermediate. Need to know what to ef > > > Valery: An accompanying document will define what it goes there. > > > Always need a new one. > > > PW: rename to IKE_INTERMEDIATE, since this applies to IKE only > > > Valery: don't mind. > > > Tommy: Seems fine with msgid. RFC 7296 doesn't require it to be 1 for > > > IKE_AUTH > > > Tobias Heider: ?? > > > Valery: This is just a framework document > > > Tero: It's OK to say this is just a framework. The documents that > > > actually use it will define what goes in it. > > > Tobias Guggemos: You can do PQ in IKE_INIT if you don't need IKE > > > fragmentation. > > > Tero: Too early for hum. Are we only going to ever have one? > > > Tero: Any objection for adoption? > > > > > > (crickets) > > > > > > Tero: So will push the button and make this a WG draft (already asked > > > on the list) > > > > > > > > > Post-quantum Key Exchanges in IKEv2 > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > Valery Smyslov - draft-tjhai-ipsecme-hybrid-qske-ikev2-03 > > > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104= - > > > ipsecme-post-quantum-key-exchanges-in-ikev2-00 > > > > > > Surprisingly, a document using INTERMEDIATE IKE_INTERMEDIATE. What > > > are the odds? > > > > > > Tero: I would hate to see this happening: 7 key exchanges sharing the > > > same type 4. These are complete key exchange - not the same thi= ng > as > > > DH. Need a new registry - they'll probably have their own > parameters. > > > Valery: They do the same thing as D-H: negotiate a key. > > > Scott: Specifically we wanted to allow doing this group, then this > > > other, then an isogeny group. This construct allows this to be > > > done relatively straightforward. > > > Tobias Heider: Like the idea of combining old (DH, ECDH) and new stuf= f > > > Martin Fadman: Why the limit 7? > > > Valery: Arbitrary > > > Martin: Maybe this argues for the hierarchical idea. > > > Valery: Scott things that in most cases different types will be used. > > > We have three types, so let's double it > > > Tero: Why negotiate all of this in the first SA payload? Interacts > > > badly with parameters. Maybe negotiate them one-by-one along > > > the way? > > > Valery: What you are proposing will complicate things. Better to > > > negotiate in advance what is going to follow. Maybe the > > > responder doesn't support what you are going to require in the > > > third round > > > Mark ???: Having them all in one place is better > > > Scott: About parameters: transforms can have attributes. Regarding th= e > > > size of the SA proposal: not a problem with the encoding of > > > IKEv2 proposals, at least for sane policies > > > Tero: will continue on the list (as we're running out of time) > > > Yoav: This is just for CCSA with PFS? We can still do CCSA without PF= S > > > Valery: Yes, and for rekeying of IKE SA > > > Mark: Support adoption > > > Tobias Heider: adopt, and rename to hybrid key exchange. Because it > > > can be used with multiple classic D-H. > > > Yoav: if we're adopting this should adopt also intermediate, and no > > > point in adopting intermediate if we're not adopting this. > > > Daniel Migault: Adopt, then make changes > > > > > > > > > An implementor's view on Hybrid PQKE in IKEv2 > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > Tobias Heider > > > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104= - > > > ipsecme-an-implementors-view-on-hybrid-pqke-00 > > > > > > Still controversy about breaking the PQ exhcnages out. Also with how > > > to accomodate McEliece (large keys) > > > Yoav: Can define a new "extended-size" payload to accomodate >64K key > > > exchanges. > > > > > > > > > PQC for IKEv2 in strongSwan > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > Leonie Bruckert > > > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104= - > > > ipsecme-pqc-for-ikev2-in-strongswan-00 > > > > > > Tobias Guggemos: We have 4 implementations. Maybe do a Hackathon? > > > Tero: You going to organize this? Thanks! > > > Tobias: Yes, if you fly me to Montreal > > > Dave: Will take to the list > > > > > > > > > ESP Header Compression and Diet-ESP > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > Tobias Guggemos - draft-mglt-ipsecme-diet-esp-07 > > > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104= - > > > ipsecme-esp-header-compression-and-diet-esp-00 > > > > > > (discussion on adoption will be done on the list) > > > > > > > > > Labeled IPsec > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > Paul Wouters - draft-ietf-ipsecme-labeled-ipsec > > > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104= - > > > ipsecme-labeled-ipsec-00 > > > > > > (already a WG draft. Discussion on Paul's proposed changed in > > > selecting TS types will be done on the list) > > > > > > > > > IKEv1 Graveyard > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > Paul Wouters - draft-pwouters-ikev1-ipsec-graveyard > > > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104= - > > > ipsecme-ikev1-graveyard-00 > > > > > > Tero: We don't instruct people what to use. We can't tell people what > > > to use. > > > Dan Harkins: IKEv1 is already obsoleted. What more do we need? > > > PW: We want to tell people not to use it. > > > Smyslov: Support deprecating IKEv1 > > > Benedict: Cannot get rid of 3DES. Used in telephony. > > > PW: Yes, for now, but it's time for CAST > > > > > > > > > IP Traffic Flow Security > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > > Christian Hopps - draft-hopps-ipsecme-iptfs-00 > > > Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104= - > > > ipsecme-ip-traffic-flow-security-00 > > > > > > Valery: Interesting proposal. You fragment IP packets to arbitrary > > > size and then re-assemble. This complicates IPsec > > > implementation. I'd rather sacrifice some performance > > > (efficiency?) by allowing combining but not fragmenting. > > > Christian: Let's discuss on the list > > > Paul Wouters: Privacy and compressing are different goals. Why do we > > > need the extra things. > > > Christian: the 20,000% overhead. > > > Lou Berger: The present thing is not deployable. We're destroying the > > > available bandwidth with the trimodal distribution of packets. > > > > > > -- discussion to continue on list > > > -- > > > kivinen@iki.fi > > > > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Mar 29 01:39:42 2019 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 85EB31203B6; Fri, 29 Mar 2019 01:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_dQ4qanlgUt; Fri, 29 Mar 2019 01:39:24 -0700 (PDT) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61495120026; Fri, 29 Mar 2019 01:39:24 -0700 (PDT) Received: from [IPv6:2001:67c:1232:144:e08f:7ce8:fb50:addb] (unknown [IPv6:2001:67c:1232:144:e08f:7ce8:fb50:addb]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: heidert) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id 35AEC35DAC6; Fri, 29 Mar 2019 09:39:22 +0100 (CET) From: Tobias Heider To: IPsecME WG Cc: draft-tjhai-ipsecme-hybrid-qske-ikev2@ietf.org, stefan@gazdag.de References: <154748799416.9552.17299073748247797491.idtracker@ietfa.amsl.com> <000101d4ad6b$4a790ca0$df6b25e0$@gmail.com> <13654392-83f1-6995-6ca5-f72b2b0be7eb@nm.ifi.lmu.de> Message-ID: Date: Fri, 29 Mar 2019 09:39:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <13654392-83f1-6995-6ca5-f72b2b0be7eb@nm.ifi.lmu.de> Content-Type: multipart/alternative; boundary="------------FFE6BE6EC2DD7AE8711223B0" Content-Language: en-US-large Archived-At: Subject: Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 08:39:42 -0000 This is a multi-part message in MIME format. --------------FFE6BE6EC2DD7AE8711223B0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi, little update on the nonces: Stefan and I have been asking around the CFRG people what they think about omitting additional nonces and the consensus seems to be that this is not an easy question and that this could probably only be resolved doing formal verification. Also we were strongly advised to get formal verification for the whole protocol including the INTERMEDIATE, and to seek help at CFRG at some point. We're trying to bring people together who are interested in helping with this, If anyone has previous experience with formal verification of secure network protocols and wants to join, feel free to contact me. Regards, Tobias On 3/27/19 6:29 PM, Tobias Heider wrote: > Hi, > > we had a side meeting today where some of us shared our experiences > implementing this > draft and we had the chance to discuss the future of this draft with > the authors. > Here's what we have talked about and our results: > > #1 Nonces in IKE_INTERMEDIATE and CHILD_SA exchanges: > > The current draft proposes to send a pair of new nonces in every > subsequent IKE_INTERMEDIATE exchange. > We agreed that none of us sees any obvious security problems with only > using the nonces exchanged in > IKE_SA_INIT, but we should try to get this confirmed by cryptologists > (maybe CFRG can help). > > #2 Using a single IKE_INTERMEDIATE to transport all additional keys > > One single big IKE_INTERMEDIATE message that transports all additional > key exchanges would be enough to > allow big keys to be fragmented. The main problem of this approach is > that fragmentation handles lost > fragments by resending all fragments. There is no way of requesting > retransmission of a single fragment. > This may turn out to be a problem, which is why each new key is sent > in a separate IKE_INTERMEDIATE. > Another solution might be to change fragmentation to allow > retransmission of single fragments. > > #3 Using a reserved field to avoid 7 new transform types > > It was discussed whether it makes sense to use a reserved field in the > transform substructure header > to combine transforms of the same transform type (e.g. Diffie-Hellman > group) with logical AND instead of OR. > We agreed that the current solution is less work to implement and > using the reserved field offers no > functional benefit. > > #4 Big Keys (e.G. Classic McEliece) > > In general there was consensus that we should find a way to enable the > use of McEliece keys. > The problem is that McEliece keys are >1MB in size and thus can not > fit into the KE payload > (which has a 16 bit size field). > > The solution we came up with is fragmenting a single key over several > KE payloads which are transmitted > in a single IKE_INTERMEDIATE message that can be fragmented over > several udp datagrams using > IKEv2 fragmentation: > HDR, SK {KE(Fragment 1), KE(Fragment 2), KE(Fragment 3)} --> > <-- HDR, SK {KE(Fragment 1), KE(Fragment 2), KE(Fragment 3)} > > This approach is only limited by the size field of the IKEv2 header, > which is 32 bit. > > #5 Rekeying and CREATE_CHILD_SA > > Nonces should be handled as said in #1. > The draft does not yet specify how the new SKEYSEED is generated. > We agreed that the best way would be to do this in a single prf > (different than in the INTERMEDIATE > exchanges which are "rekeying" incrementally), e.G. : > >     SKEYSEED = prf(SK_d(old), KE1result | KE2result | ... | Ni |Nr) > > The use of INFORMATIONAL exchange for the additional key exchanges was > criticized. > Several alternative designs were discussed, here's the most important > ones: > > Design 1: Sending all in a single exchange: > > HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi, KEi2, KEi3, KEi4} --> >     <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, KEr2, KEr3, KEr4} > > Problems include that the initiator might generate keys that are then > not accepted by the responder. > Also the message would probably be very big, so the same problems as > in #2 apply here. > It was discussed what happens if the responder does not accept the > proposal. > As in normal IKEv2 the INVALID_KE notify can be sent by the responder > and that CREATE_CHILD_SA > has to be redone with the new knowledge of what the responder supports. > > Design 2: Single additional INFORMATIONAL > > HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} --> >     <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, N(ADDITIONAL_KE)(link1)} > > HDR(INFORMATIONAL), SK {KEi2, KEi3, KEi4, N(ADDITIONAL_KE)(link1)} --> >     <-- HDR(INFORMATIONAL), SK {KEr2, KEr3, KEr4} > > Implementers might have problems with the complexity of using the > (link1) cookie > values as well as with the use of INFORMATIONAL for yet another thing. > > Feel free to correct us or comment if we made a mistake or missed > something important! > Thanks to everyone for joining the conversation! > > Regards, > Tobias and Stefan > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --------------FFE6BE6EC2DD7AE8711223B0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

little update on the nonces:
Stefan and I have been asking around the CFRG people what they think about omitting
additional nonces and the consensus seems to be that this is not an easy question
and that this could probably only be resolved doing formal verification.

Also we were strongly advised to get formal verification for the whole protocol
including the INTERMEDIATE, and to seek help at CFRG at some point.

We're trying to bring people together who are interested in helping with this,
If anyone has previous experience with formal verification of secure network
protocols and wants to join, feel free to contact me.

Regards,
Tobias

On 3/27/19 6:29 PM, Tobias Heider wrote:
Hi,

we had a side meeting today where some of us shared our experiences implementing this
draft and we had the chance to discuss the future of this draft with the authors.
Here's what we have talked about and our results:

#1 Nonces in IKE_INTERMEDIATE and CHILD_SA exchanges:

The current draft proposes to send a pair of new nonces in every subsequent IKE_INTERMEDIATE exchange.
We agreed that none of us sees any obvious security problems with only using the nonces exchanged in
IKE_SA_INIT, but we should try to get this confirmed by cryptologists (maybe CFRG can help).

#2 Using a single IKE_INTERMEDIATE to transport all additional keys

One single big IKE_INTERMEDIATE message that transports all additional key exchanges would be enough to
allow big keys to be fragmented. The main problem of this approach is that fragmentation handles lost
fragments by resending all fragments. There is no way of requesting retransmission of a single fragment.
This may turn out to be a problem, which is why each new key is sent in a separate IKE_INTERMEDIATE.
Another solution might be to change fragmentation to allow retransmission of single fragments.

#3 Using a reserved field to avoid 7 new transform types

It was discussed whether it makes sense to use a reserved field in the transform substructure header
to combine transforms of the same transform type (e.g. Diffie-Hellman group) with logical AND instead of OR.
We agreed that the current solution is less work to implement and using the reserved field offers no
functional benefit.

#4 Big Keys (e.G. Classic McEliece)

In general there was consensus that we should find a way to enable the use of McEliece keys.
The problem is that McEliece keys are >1MB in size and thus can not fit into the KE payload
(which has a 16 bit size field).

The solution we came up with is fragmenting a single key over several KE payloads which are transmitted
in a single IKE_INTERMEDIATE message that can be fragmented over several udp datagrams using
IKEv2 fragmentation:
HDR, SK {KE(Fragment 1), KE(Fragment 2), KE(Fragment 3)} -->
	<-- HDR, SK {KE(Fragment 1), KE(Fragment 2), KE(Fragment 3)}
This approach is only limited by the size field of the IKEv2 header, which is 32 bit.

#5 Rekeying and CREATE_CHILD_SA

Nonces should be handled as said in #1.
The draft does not yet specify how the new SKEYSEED is generated.
We agreed that the best way would be to do this in a single prf (different than in the INTERMEDIATE
exchanges which are "rekeying" incrementally), e.G. :

    SKEYSEED = prf(SK_d(old), KE1result | KE2result | ... | Ni |Nr)

The use of INFORMATIONAL exchange for the additional key exchanges was criticized.
Several alternative designs were discussed, here's the most important ones:

Design 1: Sending all in a single exchange:

HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi, KEi2, KEi3, KEi4} -->
    <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, KEr2, KEr3, KEr4}

Problems include that the initiator might generate keys that are then not accepted by the responder.
Also the message would probably be very big, so the same problems as in #2 apply here.
It was discussed what happens if the responder does not accept the proposal.
As in normal IKEv2 the INVALID_KE notify can be sent by the responder and that CREATE_CHILD_SA
has to be redone with the new knowledge of what the responder supports.

Design 2: Single additional INFORMATIONAL

HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} -->
    <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, N(ADDITIONAL_KE)(link1)}

HDR(INFORMATIONAL), SK {KEi2, KEi3, KEi4, N(ADDITIONAL_KE)(link1)} -->
    <-- HDR(INFORMATIONAL), SK {KEr2, KEr3, KEr4}

Implementers might have problems with the complexity of using the (link1) cookie
values as well as with the use of INFORMATIONAL for yet another thing.

Feel free to correct us or comment if we made a mistake or missed something important!
Thanks to everyone for joining the conversation!

Regards,
Tobias and Stefan

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

--------------FFE6BE6EC2DD7AE8711223B0-- From nobody Fri Mar 29 02:54:26 2019 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 3B1C012012B; Fri, 29 Mar 2019 02:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, 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 header.b=Vdcxkr1b; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=i1VbInDj 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 2mAr3kFYHePc; Fri, 29 Mar 2019 02:54:20 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A7D8120074; Fri, 29 Mar 2019 02:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9859; q=dns/txt; s=iport; t=1553853259; x=1555062859; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4mAJiiUPnfznWvSD7X1c8mcspGGbNZ4fRG+IV7NuWrs=; b=Vdcxkr1biJiY/SU9YsbbktdT2RWt22lGjYoqHWM335Y9ku961SyZYloU i05MN1yvuCqwLfnD2k8QYq84Ytw5l0/EcpVzbzo2TxN/7GKqrFt982s1o Rdy0QP2rF0JCT5+3EOwfu2wprtPS25L8oVqoLL6TjfGzvSsZkl5JJzkvD 4=; X-Files: smime.p7s : 4990 IronPort-PHdr: =?us-ascii?q?9a23=3A4U8coxV6cfklc0vEAfoT6OuksvbV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank1Bs5LTkNh8lmwMFNeH4D1YFiB6nA=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAA06p1c/4QNJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBPVADaHQECycKhASDRwOEUopfgleXDoEugSQ?= =?us-ascii?q?DVAoDAQEYCwmEQAIghRUiNAkNAQEDAQEJAQMCbRwMhUsBAQMBAQEhGgMBASw?= =?us-ascii?q?LAQ8CAQgONAICAiULJQIEAQ0FCQUNgwcBgV0DDQgBDp5VAooUcYEvgngBAQW?= =?us-ascii?q?BMQEDAg5BQYJAGIIFBwiBLwGBSIlMHReBQD+BOB+CTD6CVgsBAQEBAQGBdBs?= =?us-ascii?q?MgkwxgialLgkChGWCEHWLWxqCA12FJYwHiyyGCYNZiVgCBAIEBQIOAQEFgU0?= =?us-ascii?q?4gVZwFRohKgGCQQmCAYNuhRSFP3IBgSeNLgGBHgEB?= X-IronPort-AV: E=Sophos;i="5.60,284,1549929600"; d="p7s'?scan'208";a="251481072" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Mar 2019 09:54:18 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x2T9sHsb010527 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Mar 2019 09:54:18 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 29 Mar 2019 04:54:16 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 29 Mar 2019 05:54:16 -0400 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 29 Mar 2019 05:54:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=27fJxroTjz7/NQ21Ze+ruuT0iKpIszvbc66AkhpJghE=; b=i1VbInDjqOtnpoac/Gl66ql28fnPv/4iQ1VAiEVKBa32hUpQPpGUjs4tVuNS7wpJ71YyB30JGw2Bg4dGheVfDw4xVA2ATwsGYekYS3eUl64oFfQSe/7f3O3S5jqRTIjXpGy96Na5BBV7PzAfxB9Q3tM32Vdliw2SXlK7Ym7r6aE= Received: from DM5PR11MB1786.namprd11.prod.outlook.com (10.175.91.17) by DM5PR11MB1355.namprd11.prod.outlook.com (10.168.108.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.18; Fri, 29 Mar 2019 09:54:15 +0000 Received: from DM5PR11MB1786.namprd11.prod.outlook.com ([fe80::dc9c:826d:eafb:b8b2]) by DM5PR11MB1786.namprd11.prod.outlook.com ([fe80::dc9c:826d:eafb:b8b2%4]) with mapi id 15.20.1730.019; Fri, 29 Mar 2019 09:54:15 +0000 From: "Graham Bartlett (grbartle)" To: Christian Hopps , "ipsec@ietf.org" CC: "ipsecme-chairs@ietf.org" Thread-Topic: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt Thread-Index: AQHU2BdgklLKcgpU4UaDt5KsQjVkuaYieowA Date: Fri, 29 Mar 2019 09:54:15 +0000 Message-ID: References: <155231377348.23058.4682503726354987752@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=grbartle@cisco.com; x-originating-ip: [173.38.220.55] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b12d7344-f6d2-4f2d-17e8-08d6b42c80fa x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:DM5PR11MB1355; x-ms-traffictypediagnostic: DM5PR11MB1355: x-microsoft-antispam-prvs: x-forefront-prvs: 0991CAB7B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(136003)(376002)(396003)(366004)(189003)(199004)(51914003)(66574012)(97736004)(7736002)(305945005)(316002)(58126008)(99286004)(478600001)(476003)(81156014)(2616005)(966005)(26005)(81166006)(76176011)(11346002)(110136005)(14454004)(66066001)(186003)(102836004)(6246003)(53936002)(446003)(33656002)(6306002)(6506007)(486006)(5660300002)(99936001)(6512007)(6486002)(14444005)(36756003)(2501003)(71200400001)(25786009)(8676002)(83716004)(68736007)(4326008)(82746002)(6116002)(2906002)(71190400001)(6436002)(229853002)(8936002)(106356001)(105586002)(256004)(3846002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1355; H:DM5PR11MB1786.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: W5d2E7yllDM39Y9G7f3Sk8TTlnB/bHZ84vShge0CzMc5miwk/6MunwXr4ETAlWRZZ/d5onSMg9eAHJwb6RGnZY1IaYK6PKnSDFV4HqxVYvC8T1XtvfhyBN+DPconSbNHjme62oPqXllD25cbLKjGuWG0XnKeeE9FRRrKUBmcwqOtsmUcwff2KlBMUmbi5QWMLQWkqKVRwFdDH/4x1zRI44QWdGVPgkVn0mY9jQi7o++d0Muom5Ao+7PAQsG6wJcOCUTTqJJaj0vlfEaRnMOq56eCvHm1gdWM0aeqdfgZOvoUVvigZcXcSIQ1asCc8THrs+gcu0ea/OTBNUBDZldctz5IZEw+GopXd5DiOB8I2Jj1s2YsbpoFFQ1M9mDnYcRXj8hONW8UoT/gGyt45sfEZQ1tQFuHpOZWpbaI1YQQDGc= Content-type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3636698054_1882083182" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b12d7344-f6d2-4f2d-17e8-08d6b42c80fa X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2019 09:54:15.3677 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1355 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.21, xch-aln-011.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 09:54:23 -0000 --B_3636698054_1882083182 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Chris Thanks for the presentation yesterday. I have been thinking about traffic with different DSCP markings. e.g if I have voice, video and web traffic (with their configured DSCP), it= looks like all three flows could be sent in a single encrypted payload and = the DSCP marking in the outer header is ignored. How do you look to address the challenges that this will bring with regards= to traffic prioritisation ? Many thanks =EF=BB=BFOn 11/03/2019, 14:33, "IPsec on behalf of Christian Hopps" wrote: =20 Hi ipsecme folks, =20 Here's some new work on improving IP traffic flow security. I've reques= ted a presentation slot from the chairs for the upcoming ipsecme WG meeting = @ IETF 104, and will hopefully be able to present this work at that time as = well. =20 Thanks, Chris. =20 internet-drafts@ietf.org writes: =20 > A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. > > > Title : IP Traffic Flow Security > Author : Christian Hopps > Filename : draft-hopps-ipsecme-iptfs-00.txt > Pages : 22 > Date : 2019-03-11 > > Abstract: > This document describes a mechanism to enhance IPsec traffic flow > security by adding traffic flow confidentiality to encrypted IP > encapsulated traffic. Traffic flow confidentiality is provided by > obscuring the size and frequency of IP traffic using a fixed-sized= , > constant-send-rate IPsec tunnel. The solution allows for congesti= on > control as well. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-hopps-ipsecme-iptfs/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-hopps-ipsecme-iptfs-00 > https://datatracker.ietf.org/doc/html/draft-hopps-ipsecme-iptfs-00 > > > Please note that it may take a couple of minutes from the time of sub= mission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt =20 =20 --B_3636698054_1882083182 Content-type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITegYJKoZIhvcNAQcCoIITazCCE2cCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghD6MIIFMDCCBBigAwIBAgIRANt/amHBbAccGfNNQCnZKy4wDQYJKoZIhvcNAQELBQAw gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE4MDUy MTAwMDAwMFoXDTE5MDUyMTIzNTk1OVowIzEhMB8GCSqGSIb3DQEJARYSZ3JiYXJ0bGVAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvRs+W1UFSzWjG08ekQlb STJne0QxIugjwOxmlVsWuadzNpHs/9Lolp5hHrgLnFC+tPP+qZqtJX+l9vD9KnrUNyVD7l8O Q+EIFSiLKBF2WA4Qps6znQRJS+Bk5ggfMRo9ni1Or6B5QIgLF1fbRqPitM0TINq+Sj9xnSbq 5vJ8TmEyzU90HNJNtBzZaYxKbHImoXgTpONJtSIt94bDRcI3UXrvHhn9Zn2MmIXqGzIDLUjl RCzkBDx6wqZ9ZZ78vyo+Ewa1so7L+NV/rDpGQQiPCDxd+6QLvUIZkNdl9ViWRR+1LPAq55Rw ZkfFSziuCJwlHz0MHbGiUpKfk+rrmtEiqwIDAQABo4IB6DCCAeQwHwYDVR0jBBgwFoAUgq9s jPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFPBG1SAHV8aiV0IwohMhtCqrdwsaMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBP oE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9j YS5jb20wHQYDVR0RBBYwFIESZ3JiYXJ0bGVAY2lzY28uY29tMA0GCSqGSIb3DQEBCwUAA4IB AQAonuiVei61mvmBh/zsM5gRCZKZrv5CxaOiz1726DZ+zbNY0NFlJ7011HxD1LKWIp3f9AOU ec0GFrTmdYsJPU9+K9GuxtaH1hk3LOM3MwHxyyvm4JONbWfF+VCuRstEA+zPD0hsUn4BMVTc f2IkgoysAb1bmvJdAzwuiswPgIZaCJ12vY9WWcPwZXqgGL72/sUw+XQxKbXH/PtqYcTKhYHS GRTHQJSOi2GeG+faXHjBmo9vrJV3500EcmzATQYuhNl/L4XwPtiFoAqJ74hXvdKE5hgSqbUc B5XCEQYNABPD41fVjm1uCBmGs//8s/5hGm/20zNOe/D9Njoum9HyoRHGMIIF5jCCA86gAwIB AgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n9jR22YRq 2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgzKlWlVJGy K+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikFlgqOtzk0 6kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9tGKTDyUGg 2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK+xS1AgMB AAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4EFgQU gq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29t b2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUF BwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNB QWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAN BgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx 4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDc ZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0 wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85 S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8cz m12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRL RTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8 MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQvdVifC3Ht wlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDNXFnHn9tF pMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIwggXYMIIDwKAD AgECAhBMqvnK22Nv4B/3TthbA4adMA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTAeFw0xMDAxMTkwMDAwMDBaFw0zODAxMTgyMzU5NTlaMIGFMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJHoVJLS ClaxrA0k3cXPRGd0mSs3o30jcABxvFPfxPoqEo9LfxBWvZ9wcrdhf8lLDxenPeOwBGHu/xGX x/SGPgr6Plz5k+Y0etkUa+ecs4Wggnp2r3GQ1+z9DfqcbPrfsIL0FH75vsSmL09/mX+1/GdD cr0MANaJ62ss0+2PmBwUq37l42782KjkkiTaQ2tiuFX96sG8bLaL8w6NmuSbbGmZ+HhIMEXV reENPEVg/DKWUSe8Z8PKLrZr6kbHxyCgsR9l3kgIuqROqfKDRjeE6+jMgUhDZ05yKptcvUwb KIpcInu0q5jZ7uBRg8MJRk5tPpn6lRfafDNXQTyNUe0LtlyvLGMa31fIP7zpXcSbr0WZ4qNa JLS6qVY9z2+q/0lYvvCo//S4rek3+7q49As6+ehDQh6J2ITLE/HZu+GJYLiMKFasFB2cCudx 688O3T2plqFIvTz3r7UNIkzAEYHsVjv206LiW7eyBCJSlYCTaeiOTGXxkQMtcHQC6otnFSlp UgK7199QalVGv6CjKGF/cNDDoqosIapHziicBkV2v4IYJ7TVrrTLUOZr9EyGcTDppt8WhuDY /0Dd+9BCiH+jMzouXB5BEYFjzhhxayvspoq3MVw6akfgw3lZ1iAar/JqmKpyvFdK0kuduxD8 sExB5e0dPV4onZzMv7NR2qdH5YRTAgMBAAGjQjBAMB0GA1UdDgQWBBS7r34CPfqm8TyEjq3u OJjs2TIy1DAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQwF AAOCAgEACvHVRoS3rlG7bLJNQRQAk0ycy+XAVM+gJY4C+f2wog31IJg8Ey2sVqKw1n4Rkuku up4umnKxvRlEbGE1opq0FhJpWozh1z6kGugvA/SuYR0QGyqki3rF/gWm4cDWyP6ero8ruj2Z +NhzCVhGbqac9Ncn05XaN4NyHNNz4KJHmQM4XdVJeQApHMfsmyAcByRpV3iyOfw6hKC1nHyN vy6TYie3OdoXGK69PAlo/4SbPNXWCwPjV54U99HrT8i9hyO3tklDeYVcuuuSC6HG6GioTBax GpkK6FMskruhCRh1DGWoe8sjtxrCKIXDG//QK2LvpHsJkZhnjBQBzWgGamMhdQOAiIpugcaF 8qmkLef0pSQQR4PKzfSNeVixBpvnGirZnQHXlH3tA0rK8NvoqQE+9VaZyR6OST275Qm54E9J kj0WgkDMzFnG5jrtEi5pPGyVsf2qHXt/hr4eDjJG+/sTj3V/TItLRmP+ADRAcMHDuaHdpnDi BLNBvOmAkepknHrhIgOpnG5vDmVPbIeHXvNuoPl1pZtA6FOyJ51KucB3IY3/h/LevIzvF9+3 SQvR8m4wCxoOTnbtEfz16Vayfb/HbQqTjKXQwLYdvjpOlKLXbmwLwop8+iDzxOTlzQ2oy5GS sXyF7LUUaWYOgufNzsgtplF/IcE1U4UGSl2frbsbX3QxggJEMIICQAIBATCBrTCBlzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDbf2phwWwHHBnzTUAp 2SsuMA0GCWCGSAFlAwQCAQUAoGkwLwYJKoZIhvcNAQkEMSIEID7xD4/ikFW26bZK6WTSraA3 EkfvAwJD5hIj4hkRqFFMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTE5MDMyOTA5NTQxNFowDQYJKoZIhvcNAQEBBQAEggEAEIcX+cqUU1kiHAZxcNzJ1/w+ pK9GihdCbHUOVBwAbOb8jxyZd6rtzngDsyryfcibLwyU03g1tZ1A1eVe4v2tYZbF30r20zyj mzq1gk8dlnAh2ZXRUFChfZxBxC+vHmMoi/wASlxha7INJSZKOJlQJjzvE1k5OpPMm9EJP8M+ 50W1wPywHS0ov4rN2D8EicazhMTwg6XJYBubd/7492Hzf9K7qDzG+1P59V4hRXiB7N5qxF8N vNPG4Yd9NYuaEGxAiWZ+PQMBm8wGW+2502i4g6/EL0/prIeYSP9rd/8iTOiGgNFq+DF1C2t8 q6ZetO+9aWX1NpolZMJE8nI9HBj7cg== --B_3636698054_1882083182-- From nobody Fri Mar 29 03:13:42 2019 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 2CB5A120339 for ; Fri, 29 Mar 2019 03:13:41 -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, URIBL_BLOCKED=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 FEacPL_6NLOH for ; Fri, 29 Mar 2019 03:13:39 -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 D85531202ED for ; Fri, 29 Mar 2019 03:13:38 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44VyHh3RY9z37M; Fri, 29 Mar 2019 11:13:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1553854416; bh=GD82BiadYqAz4Xal1LTDH2B3FTo26py7OW0VF1avd2w=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=CiXAhchjY0EFuiu6JYFrpqhhi3Kop3dmhAGr4CnqqxiTk4Woj9028Ph+y5xKb9RYe TnmhgM/N05vcjCrsGNsBDB5V8tty6xPBoAVvacSPylop8Bz/4AZ76/vGAvalyvIaij ndOV1/1Qv+Z5FzXH6K/Q8NY+Y8l9FldSvONNa9gk= 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 4OFZCdjpZdrl; Fri, 29 Mar 2019 11:13:34 +0100 (CET) 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; Fri, 29 Mar 2019 11:13:34 +0100 (CET) Received: from [31.133.142.60] (dhcp-8e3c.meeting.ietf.org [31.133.142.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 038432FCD9; Fri, 29 Mar 2019 06:13:33 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 038432FCD9 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Fri, 29 Mar 2019 11:13:31 +0100 Cc: Valery Smyslov , ipsec@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <68C1787B-4396-462F-98CF-4603D98FA469@nohats.ca> References: <155231377348.23058.4682503726354987752@ietfa.amsl.com> <01f401d4d8e1$58fcc9f0$0af65dd0$@gmail.com> <01c601d4da40$ae0740a0$0a15c1e0$@gmail.com> To: Christian Hopps Archived-At: Subject: Re: [IPsec] I-D Action: draft-hopps-ipsecme-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 10:13:41 -0000 > On Mar 14, 2019, at 10:37, Christian Hopps wrote: >=20 >=20 > Valery Smyslov writes: >=20 >>> If there really is no way to work around this, I suppose we just require= retransmissions of CC info reports until >>> they are ACKd or things are torn down b/c of drops (i.e., normal INFO ex= change). It does feel like we are >>> adding fragility here that isn=E2=80=99t really needed though. It makes t= he functioning of the unidirectional tunnel >>> depend more heavily on the reverse direction traffic working when that i= sn=E2=80=99t actually needed for the tunnel to >>> operate. >>=20 >> Yes, don't break IKE core things. >=20 > I was hoping there would be an openness to possible improvements, and wasn= 't looking to just break well established protocols. An earlier mail from Pa= ul made it sound like other use-cases have wanted for expanded functionality= as well. Just to clarify. It is not that people are not open minded, but that the sug= gested change technically cannot work due to the base model of how IKEv2 wor= ks. The way msgid handling is specified in the core spec cannot support uni-= directional behaviour even if we all wanted to add it. And even the current h= andling has some issues we must clarify in future drafts without the additio= n of uni-directionality. It is too complicated already. Supporting uni-direc= tionality would mean creating IKEv2.1 or IKEv3, which would be years of effo= rts. Paul= From nobody Fri Mar 29 03:25:29 2019 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 B8E6412025E for ; Fri, 29 Mar 2019 03:25:27 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 mFEEOYesQsPx for ; Fri, 29 Mar 2019 03:25:26 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 07F3512025A for ; Fri, 29 Mar 2019 03:25:26 -0700 (PDT) Received: from pip.chopps.org (dhcp-9207.meeting.ietf.org [31.133.146.7]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 83879605A0; Fri, 29 Mar 2019 06:25:24 -0400 (EDT) References: <155231377348.23058.4682503726354987752@ietfa.amsl.com> <01f401d4d8e1$58fcc9f0$0af65dd0$@gmail.com> <01c601d4da40$ae0740a0$0a15c1e0$@gmail.com> <68C1787B-4396-462F-98CF-4603D98FA469@nohats.ca> User-agent: mu4e 1.0; emacs 26.1 From: Christian Hopps To: Paul Wouters Cc: Christian Hopps , Valery Smyslov , ipsec@ietf.org In-reply-to: <68C1787B-4396-462F-98CF-4603D98FA469@nohats.ca> Date: Fri, 29 Mar 2019 11:25:22 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [IPsec] I-D Action: draft-hopps-ipsecme-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 10:25:28 -0000 --=-=-= Content-Type: text/plain; format=flowed Paul Wouters writes: > Just to clarify. It is not that people are not open minded, but that the suggested change technically cannot work due to the base model of how IKEv2 works. The way msgid handling is specified in the core spec cannot support uni-directional behaviour even if we all wanted to add it. And even the current handling has some issues we must clarify in future drafts without the addition of uni-directionality. It is too complicated already. Supporting uni-directionality would mean creating IKEv2.1 or IKEv3, which would be years of efforts. > Indeed. Based on some discussions with folks prior and during the meeting it seems like we may have non-IKE options as well. Thanks, Chris. > Paul --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlyd8pIACgkQLh2DDte4 MCXwBQ//XGWJXw5s4f6x2NBMKM+Lwys9/k22RZh4zfdTeCCI74rUDh5jvwIqygcj c3U2LeyTBsCggTL6jWUChg6VGxdFt+tZCES082UkG01TXFFccxbY19uPSZBrycKl /JmvKWF/tQlaKP1QtW/YRpxrP8qxQt2ysZMZ3KxwUopsG6TPy+8+s8dPei8EVe/n RLyPCn9FbNretSY3L++C3P/yuwTJgUdZe0Jj0a1uLHmC6T75CjsHj+2Ea91Ikgyr t6mNCgv5km0KiByHW7l7biPYDL8iOjJV2igJlssr5riZUSUHZ+5VdHfxeoS1bqH6 wrq85H/uieysE1orKJZRcV/zs5CiNg7RG6t+7q7M3Kaih3XjKrNM9gyelAKhYi4W GitXPH76xS0mrS86lWN/s9fFENRBsHdYnwLs/Gi2QiJ+Ta3RyW8gZwy+X1iJ1XJb qfwUWB9ZA08a5w77nR0o3wMIF6alcEvFw0/Gqu+9h+hkbFTrOFcIjDeL1lrnD8RD GKEWidcigm0lXNCeX4kDfJonDboYFkXaRWqT7GfWNk+A8L82SyiXvbJ0yZFK8gsw 1Q0hmS6sZAkguqyS31G3ZDnpTrhpXfhNAXf6NrrEHmpju9Qz4V4P+HYajdx0SPvi dK7jrGArRW/vbXpvibA1gJnGDxIcn9PCQPFeQAraQum16VrQrWU= =YY6l -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 29 03:35:22 2019 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 87900120391; Fri, 29 Mar 2019 03:35:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 10QsLPC2vtNh; Fri, 29 Mar 2019 03:35:07 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id C0E8B12045D; Fri, 29 Mar 2019 03:35:06 -0700 (PDT) Received: from pip.chopps.org (dhcp-9207.meeting.ietf.org [31.133.146.7]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 4DA77605A0; Fri, 29 Mar 2019 06:35:05 -0400 (EDT) References: <155231377348.23058.4682503726354987752@ietfa.amsl.com> User-agent: mu4e 1.0; emacs 26.1 From: Christian Hopps To: "Graham Bartlett \(grbartle\)" Cc: Christian Hopps , "ipsec\@ietf.org" , "ipsecme-chairs\@ietf.org" In-reply-to: Date: Fri, 29 Mar 2019 11:35:02 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 10:35:20 -0000 --=-=-= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Graham, This is a good question. We currently indicate it's a local configuration d= ecision, but we may want to go deeper into possible options in the draft. Right now we see 3 options: =2D A static configured value for the SA =2D Inherit the "best" value from the encapsulated traffic. =2D Inherit the "worst" value from the encapsulated traffic. Thanks, Chris. Graham Bartlett (grbartle) writes: > Hi Chris > > Thanks for the presentation yesterday. > > I have been thinking about traffic with different DSCP markings. > > e.g if I have voice, video and web traffic (with their configured DSCP), = it looks like all three flows could be sent in a single encrypted payload a= nd the DSCP marking in the outer header is ignored. > > How do you look to address the challenges that this will bring with regar= ds to traffic prioritisation ? > > Many thanks > > =EF=BB=BFOn 11/03/2019, 14:33, "IPsec on behalf of Christian Hopps" wrote: > > > Hi ipsecme folks, > > Here's some new work on improving IP traffic flow security. I've requ= ested a presentation slot from the chairs for the upcoming ipsecme WG meeti= ng @ IETF 104, and will hopefully be able to present this work at that time= as well. > > Thanks, > Chris. > > internet-drafts@ietf.org writes: > > > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > > > > > > Title : IP Traffic Flow Security > > Author : Christian Hopps > > Filename : draft-hopps-ipsecme-iptfs-00.txt > > Pages : 22 > > Date : 2019-03-11 > > > > Abstract: > > This document describes a mechanism to enhance IPsec traffic flow > > security by adding traffic flow confidentiality to encrypted IP > > encapsulated traffic. Traffic flow confidentiality is provided = by > > obscuring the size and frequency of IP traffic using a fixed-siz= ed, > > constant-send-rate IPsec tunnel. The solution allows for conges= tion > > control as well. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-hopps-ipsecme-iptfs/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-hopps-ipsecme-iptfs-00 > > https://datatracker.ietf.org/doc/html/draft-hopps-ipsecme-iptfs-00 > > > > > > Please note that it may take a couple of minutes from the time of s= ubmission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlyd9NYACgkQLh2DDte4 MCUv/xAAl+c7Y10oyv3jcPqgv2gmigKZIKkZArWkibp+95oWNLBAzaxhIcldeTnu 0GQ4anU/pFAhYgwkBMtr2S4DoFl921Rw1VsKjENZ7p6SKCL3agmubKJinZV++CvW 9pZ/vgIQ0KL3/ra+mVSpiEIC6nUso8RyYkTJ7Q7eJuKL/uN+0oiMURr8kDKlqdLP Z7uRsNZdvUlCp+NHW4lFr/xR01A4s0YQrU7J//KqJVVPgDdfnTvxKoUo9Fw4r7Ce LsViAadVwY6UmHWIOQuoV9nGk2U+CrWxp3a3eiN7ftgXivJhb3QVJ8DEzVHlUWav 0GqPU1Ahfr3O8fPCrg4Oo3ojOVjm00AJLbK8Aqr6UEazHIlVpM+U5bYyL+f3g8As micf7Wnk0OvjtNNCFeSjlT3zPKHpXLVYhGgngZHDjqTcaSlEd52A0HHh5XBQ0/KA 6N0jMwaZtpXSn/xbSy1jw6s11Ff37g3cz1g2kQG7dIuOy0KZ/JByNnQsKnuAbPMr kBj0LkuYwLNKP8cA2feg/OK9XMy+sXHZv5U6dhuZ6K7esVADyHUy9P6fcKwPFt3T MzzG3H2y1RKCtW1iJzSUFWgagDJL90/u8bX8fSr3hqYYygfNoHVhiS+Gj/T/2CMS ErxNukt1woMrvJXAl6fMOvY19ZqaU6fHMvPCcHFQsGd4XSKXakg= =6bRP -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 29 05:16:28 2019 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 681F9120294; Fri, 29 Mar 2019 05:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, 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 header.b=gcBv3Kfn; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=kF2awu3w 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 1U6-UBdPfItk; Fri, 29 Mar 2019 05:16:23 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5CB412027F; Fri, 29 Mar 2019 05:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11921; q=dns/txt; s=iport; t=1553861782; x=1555071382; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WAP246ZVQJgdH+Q2JL/4EA9o6If+nyheqcN81rvf9M4=; b=gcBv3KfnGP//Ve2EDyM17smNOPJQ/KoUIDfj2Ah8e5uTf3opN/PxBVNn JJrJiosZxpYuFojBT5YAAeuukjgddDbQj04d9yp14od4y80To3M5pcHy5 prm0DhpiI1cXrd292ajIV96YUhHqt80EvPIEEqGxj2EYfwM+9c5jT6C2w Y=; X-Files: smime.p7s : 4990 IronPort-PHdr: =?us-ascii?q?9a23=3AiKtdYROn+GnF/Dlnu5ol6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBj0NvTjdTA+EexJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAABCDJ5c/49dJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBPSQFJwNodAQLJwqEBINHA4RSil+CV5cOgS6?= =?us-ascii?q?BJANUCgMBARgLCYRAAiCFFyI0CQ0BAQMBAQkBAwJtHAyFSgEBAQMBAQEhGgM?= =?us-ascii?q?BASwLAQQLAgEIDgoqAgICJQslAgQOBQkFDYMHAYFdAw0IAQ6eEAKKFHGBL4J?= =?us-ascii?q?4AQEFgTEBAwIOQUGCPxiCBQcIgS8BgUiJTB0XgUA/gTgfgkw+glYLAQEBAQE?= =?us-ascii?q?BgXQbglgxgialLgkChGWCEHWEDYdOGoIDhgKMB5E1g1mJWAIEAgQFAg4BAQW?= =?us-ascii?q?BTTiBVnAVGiEqAYJBCYIBgSMBB4JDhRSFP3IBgSeNLgGBHgEB?= X-IronPort-AV: E=Sophos;i="5.60,284,1549929600"; d="p7s'?scan'208";a="251531443" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Mar 2019 12:16:21 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x2TCGLaD014237 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Mar 2019 12:16:21 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 29 Mar 2019 07:16:20 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 29 Mar 2019 08:16:19 -0400 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 29 Mar 2019 07:16:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fpye0qACX0rrk0Zt/1lFSJbSPGiNMQg+7pUfri+YlI0=; b=kF2awu3w4Mzk9+FMAKVpOH3DPREaCZLtTISKF+Az8eHcPTYhIixGYMdzOSXvAxwW2IoP2cQnaYCzGb757d3/idoLj1pApVJXV5OgZsTApXeO7J+h9x+hGsTDyPLl7A86ND0rFMkYIO5Hb0ZP+exknYTs1XSSZI5Q/Nh/8wsTioY= Received: from DM5PR11MB1786.namprd11.prod.outlook.com (10.175.91.17) by DM5PR11MB1339.namprd11.prod.outlook.com (10.168.108.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.16; Fri, 29 Mar 2019 12:16:18 +0000 Received: from DM5PR11MB1786.namprd11.prod.outlook.com ([fe80::dc9c:826d:eafb:b8b2]) by DM5PR11MB1786.namprd11.prod.outlook.com ([fe80::dc9c:826d:eafb:b8b2%4]) with mapi id 15.20.1730.019; Fri, 29 Mar 2019 12:16:18 +0000 From: "Graham Bartlett (grbartle)" To: Christian Hopps CC: "ipsec@ietf.org" , "ipsecme-chairs@ietf.org" Thread-Topic: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt Thread-Index: AQHU2BdgklLKcgpU4UaDt5KsQjVkuaYieowAgAALZgCAABxKgA== Date: Fri, 29 Mar 2019 12:16:18 +0000 Message-ID: <6591A593-7E16-49F6-99D5-2D2E5A5D1735@cisco.com> References: <155231377348.23058.4682503726354987752@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=grbartle@cisco.com; x-originating-ip: [173.38.220.55] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ce76d92d-0acd-46b3-1683-08d6b440590c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:DM5PR11MB1339; x-ms-traffictypediagnostic: DM5PR11MB1339: x-microsoft-antispam-prvs: x-forefront-prvs: 0991CAB7B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(396003)(376002)(346002)(366004)(199004)(189003)(51914003)(5660300002)(486006)(81156014)(81166006)(316002)(86362001)(2616005)(11346002)(54906003)(66066001)(3846002)(71190400001)(478600001)(256004)(14444005)(53936002)(71200400001)(58126008)(6116002)(99936001)(68736007)(6916009)(8676002)(186003)(6486002)(99286004)(8936002)(229853002)(6436002)(476003)(102836004)(6506007)(26005)(25786009)(7736002)(33656002)(82746002)(66574012)(446003)(6246003)(76176011)(4326008)(83716004)(97736004)(305945005)(36756003)(2906002)(93886005)(105586002)(6512007)(6306002)(106356001)(966005)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1339; H:DM5PR11MB1786.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: PfaqZXisLaKkNnVlOQxKkikK5ku98iTHCC99T9DC3dhJJHQThHDWZOwXGJIIL3cHUnGK/2mRfLSPBu0x6XhsnxMcDw4On2ixJOY/DWdjPh1eGtZYoksI1EbFXNNt6GZfdIHkJqVq7KFmmzetkhayyaY5cA8DRB6v1xEB4HskiHpQrmAljbcVAdntVa8x+RGFJP1c6vgWA7ut15QlWiHBz3dYyz0Eqj8+aIzcsQTen7bkARK2U32QTm82gwz/9oN9WT+f+PORikG4Az+YQ6RD8heXM4eR0flIOWZaO5gTY6OZUbNqpVtMbrBJC8ji4TrLDvw12CoUKbJV8famwAnHmu+5BtUeE2JvSAE0UQ5aK7aKt/nDhFOgtQavQ5nyBxPYzHggqdfR1kqaOJZAzf3XWc9x49qnPk+O+ADalDZA3ws= Content-type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3636706577_1369520121" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ce76d92d-0acd-46b3-1683-08d6b440590c X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2019 12:16:18.3284 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1339 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 12:16:26 -0000 --B_3636706577_1369520121 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Chris Sorry, I meant to catch you yesterday, but had to leave. I see this as a really hard problem to solve (and don't have a solution). The issue is, if you're mixing different traffic into an encrypted payload = then there's a very good chance your inner flows are going to start becoming= out of order when they are sent encapsulated. So for a mix of DSCP traffic I see the following occurring; - A static configured value for the SA > priority queuing of traffic of priority traffic flows doesn't occur when = it's encrypted as everything is sharing the same DSCP - Inherit the "best" value from the encapsulated traffic. >low priority traffic gets a free ride if it's bundled with traffic of high= priority =20 - Inherit the "worst" value from the encapsulated traffic. >high priority traffic gets a downgrade when it's bundled with low priority= traffic I'd be interested to see testing with various traffic flows and traffic tha= t requires some form of quality of service. I've seen similar solutions brea= k real time traffic. cheers =EF=BB=BFOn 29/03/2019, 10:35, "Christian Hopps" wrote: =20 Hi Graham, =20 This is a good question. We currently indicate it's a local configurati= on decision, but we may want to go deeper into possible options in the draft= . =20 Right now we see 3 options: =20 - A static configured value for the SA - Inherit the "best" value from the encapsulated traffic. - Inherit the "worst" value from the encapsulated traffic. =20 Thanks, Chris. =20 Graham Bartlett (grbartle) writes: =20 > Hi Chris > > Thanks for the presentation yesterday. > > I have been thinking about traffic with different DSCP markings. > > e.g if I have voice, video and web traffic (with their configured DSC= P), it looks like all three flows could be sent in a single encrypted payloa= d and the DSCP marking in the outer header is ignored. > > How do you look to address the challenges that this will bring with r= egards to traffic prioritisation ? > > Many thanks > > =EF=BB=BFOn 11/03/2019, 14:33, "IPsec on behalf of Christian Hopps" wrote: > > > Hi ipsecme folks, > > Here's some new work on improving IP traffic flow security. I've = requested a presentation slot from the chairs for the upcoming ipsecme WG me= eting @ IETF 104, and will hopefully be able to present this work at that ti= me as well. > > Thanks, > Chris. > > internet-drafts@ietf.org writes: > > > A New Internet-Draft is available from the on-line Internet-Dra= fts directories. > > > > > > Title : IP Traffic Flow Security > > Author : Christian Hopps > > Filename : draft-hopps-ipsecme-iptfs-00.txt > > Pages : 22 > > Date : 2019-03-11 > > > > Abstract: > > This document describes a mechanism to enhance IPsec traffic= flow > > security by adding traffic flow confidentiality to encrypted= IP > > encapsulated traffic. Traffic flow confidentiality is provi= ded by > > obscuring the size and frequency of IP traffic using a fixed= -sized, > > constant-send-rate IPsec tunnel. The solution allows for co= ngestion > > control as well. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-hopps-ipsecme-iptfs/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-hopps-ipsecme-iptfs-00 > > https://datatracker.ietf.org/doc/html/draft-hopps-ipsecme-iptfs= -00 > > > > > > Please note that it may take a couple of minutes from the time = of submission > > until the htmlized version and diff are available at tools.ietf= .org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > =20 =20 --B_3636706577_1369520121 Content-type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITegYJKoZIhvcNAQcCoIITazCCE2cCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghD6MIIFMDCCBBigAwIBAgIRANt/amHBbAccGfNNQCnZKy4wDQYJKoZIhvcNAQELBQAw gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE4MDUy MTAwMDAwMFoXDTE5MDUyMTIzNTk1OVowIzEhMB8GCSqGSIb3DQEJARYSZ3JiYXJ0bGVAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvRs+W1UFSzWjG08ekQlb STJne0QxIugjwOxmlVsWuadzNpHs/9Lolp5hHrgLnFC+tPP+qZqtJX+l9vD9KnrUNyVD7l8O Q+EIFSiLKBF2WA4Qps6znQRJS+Bk5ggfMRo9ni1Or6B5QIgLF1fbRqPitM0TINq+Sj9xnSbq 5vJ8TmEyzU90HNJNtBzZaYxKbHImoXgTpONJtSIt94bDRcI3UXrvHhn9Zn2MmIXqGzIDLUjl RCzkBDx6wqZ9ZZ78vyo+Ewa1so7L+NV/rDpGQQiPCDxd+6QLvUIZkNdl9ViWRR+1LPAq55Rw ZkfFSziuCJwlHz0MHbGiUpKfk+rrmtEiqwIDAQABo4IB6DCCAeQwHwYDVR0jBBgwFoAUgq9s jPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFPBG1SAHV8aiV0IwohMhtCqrdwsaMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBP oE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9j YS5jb20wHQYDVR0RBBYwFIESZ3JiYXJ0bGVAY2lzY28uY29tMA0GCSqGSIb3DQEBCwUAA4IB AQAonuiVei61mvmBh/zsM5gRCZKZrv5CxaOiz1726DZ+zbNY0NFlJ7011HxD1LKWIp3f9AOU ec0GFrTmdYsJPU9+K9GuxtaH1hk3LOM3MwHxyyvm4JONbWfF+VCuRstEA+zPD0hsUn4BMVTc f2IkgoysAb1bmvJdAzwuiswPgIZaCJ12vY9WWcPwZXqgGL72/sUw+XQxKbXH/PtqYcTKhYHS GRTHQJSOi2GeG+faXHjBmo9vrJV3500EcmzATQYuhNl/L4XwPtiFoAqJ74hXvdKE5hgSqbUc B5XCEQYNABPD41fVjm1uCBmGs//8s/5hGm/20zNOe/D9Njoum9HyoRHGMIIF5jCCA86gAwIB AgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n9jR22YRq 2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgzKlWlVJGy K+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikFlgqOtzk0 6kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9tGKTDyUGg 2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK+xS1AgMB AAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4EFgQU gq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29t b2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUF BwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNB QWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAN BgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx 4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDc ZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0 wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85 S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8cz m12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRL RTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8 MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQvdVifC3Ht wlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDNXFnHn9tF pMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIwggXYMIIDwKAD AgECAhBMqvnK22Nv4B/3TthbA4adMA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTAeFw0xMDAxMTkwMDAwMDBaFw0zODAxMTgyMzU5NTlaMIGFMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJHoVJLS ClaxrA0k3cXPRGd0mSs3o30jcABxvFPfxPoqEo9LfxBWvZ9wcrdhf8lLDxenPeOwBGHu/xGX x/SGPgr6Plz5k+Y0etkUa+ecs4Wggnp2r3GQ1+z9DfqcbPrfsIL0FH75vsSmL09/mX+1/GdD cr0MANaJ62ss0+2PmBwUq37l42782KjkkiTaQ2tiuFX96sG8bLaL8w6NmuSbbGmZ+HhIMEXV reENPEVg/DKWUSe8Z8PKLrZr6kbHxyCgsR9l3kgIuqROqfKDRjeE6+jMgUhDZ05yKptcvUwb KIpcInu0q5jZ7uBRg8MJRk5tPpn6lRfafDNXQTyNUe0LtlyvLGMa31fIP7zpXcSbr0WZ4qNa JLS6qVY9z2+q/0lYvvCo//S4rek3+7q49As6+ehDQh6J2ITLE/HZu+GJYLiMKFasFB2cCudx 688O3T2plqFIvTz3r7UNIkzAEYHsVjv206LiW7eyBCJSlYCTaeiOTGXxkQMtcHQC6otnFSlp UgK7199QalVGv6CjKGF/cNDDoqosIapHziicBkV2v4IYJ7TVrrTLUOZr9EyGcTDppt8WhuDY /0Dd+9BCiH+jMzouXB5BEYFjzhhxayvspoq3MVw6akfgw3lZ1iAar/JqmKpyvFdK0kuduxD8 sExB5e0dPV4onZzMv7NR2qdH5YRTAgMBAAGjQjBAMB0GA1UdDgQWBBS7r34CPfqm8TyEjq3u OJjs2TIy1DAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQwF AAOCAgEACvHVRoS3rlG7bLJNQRQAk0ycy+XAVM+gJY4C+f2wog31IJg8Ey2sVqKw1n4Rkuku up4umnKxvRlEbGE1opq0FhJpWozh1z6kGugvA/SuYR0QGyqki3rF/gWm4cDWyP6ero8ruj2Z +NhzCVhGbqac9Ncn05XaN4NyHNNz4KJHmQM4XdVJeQApHMfsmyAcByRpV3iyOfw6hKC1nHyN vy6TYie3OdoXGK69PAlo/4SbPNXWCwPjV54U99HrT8i9hyO3tklDeYVcuuuSC6HG6GioTBax GpkK6FMskruhCRh1DGWoe8sjtxrCKIXDG//QK2LvpHsJkZhnjBQBzWgGamMhdQOAiIpugcaF 8qmkLef0pSQQR4PKzfSNeVixBpvnGirZnQHXlH3tA0rK8NvoqQE+9VaZyR6OST275Qm54E9J kj0WgkDMzFnG5jrtEi5pPGyVsf2qHXt/hr4eDjJG+/sTj3V/TItLRmP+ADRAcMHDuaHdpnDi BLNBvOmAkepknHrhIgOpnG5vDmVPbIeHXvNuoPl1pZtA6FOyJ51KucB3IY3/h/LevIzvF9+3 SQvR8m4wCxoOTnbtEfz16Vayfb/HbQqTjKXQwLYdvjpOlKLXbmwLwop8+iDzxOTlzQ2oy5GS sXyF7LUUaWYOgufNzsgtplF/IcE1U4UGSl2frbsbX3QxggJEMIICQAIBATCBrTCBlzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDbf2phwWwHHBnzTUAp 2SsuMA0GCWCGSAFlAwQCAQUAoGkwLwYJKoZIhvcNAQkEMSIEIJZ3wV1cFeveyNVeXZkQhq71 Ew19A4OrpYEs7uN7NtFmMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTE5MDMyOTEyMTYxN1owDQYJKoZIhvcNAQEBBQAEggEAV4Dm+Kcn11IqZSXHw+qhIZlL ewDyQV4xtMTsjXQ77b77NsugS0U4gjQhpTf+y3+SyBQ5l+NmE07daWTT01Fu2+ZgqW7yY9Hb JTd9KusptHfUD460Ze+iq0Xo0iugoBZB35LJWPzjLisbcWUI+ASgFf0Hr6pKCKpk9uz3XjZq QnJziW6z0WEgpxK7Y0t+bhlLgK4k0Qn9EAjF07ujM51UXQlSdi5fsrNSVM3LFFqbQRQUp/9K bZvxJePQhrtLltZm5Ar2zFkVwPUuI0wPiI6dLNNCyXA7rPfQ8siCHq64Tu4vws8FokcZFo/0 Rao4lZ/iFPOOlHKKtsd0IkTUm6Gd4Q== --B_3636706577_1369520121-- From nobody Sat Mar 30 01:54:49 2019 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 C2628120183 for ; Sat, 30 Mar 2019 01:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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=yahoo.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 qh6gwl8YrmHC for ; Sat, 30 Mar 2019 01:54:45 -0700 (PDT) Received: from sonic315-22.consmr.mail.ne1.yahoo.com (sonic315-22.consmr.mail.ne1.yahoo.com [66.163.190.148]) (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 B1A7C12013D for ; Sat, 30 Mar 2019 01:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1553936084; bh=jKYuiAtchZNMmUmJ0x7/KyXE1NraXbRG8FBlssiQK4U=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=lbpwGAeucrngLpkv3qlzLQmDK4A/e+XM93G/m4E6rLn5iROp1qbZ98vDzucfC9t+rCVnU/oS/dzHjKDmJD2e+a7MsPWli5qEcbiB3DiHEGzYr4t8uuSZGDLoEI/+QrdJCfiCGcb1IJqLBArIsx+9iTYaOcjEkO/Qe6fFTMn7s/s0esXwtU14us1BCbDIcvt0O6V0Rcb+6eMu57G4fBJ25QqIJ8nRASdAbJ5Pq7rwZhADOv4iUFJPU8iPov18dCMo1NC+v4T8TGbDt64pTV8+45aZrP+fh7vAvGo3q2z7uDJ5dGSAuqEzbT92Kgg2D/6joecG15FZtTuFlPRJ56dGEg== X-YMail-OSG: KypSK7QVM1nNuLDL2d6BxGZBVgzPZ9mqn.k8piV3fkL7LfJdR4y3h8Xh5GJgKY6 fm1ljlWVGuyLZJlXCzsxAle.FnqXQdgf8kgjNqm4Y9KQ2MV4eTb1DdTO28n1MOrKknDTKzBwLBVd 94P2Sw7S984JRx24SV5jJXt8SjibT5vqC7hDizxoAUGcYDgRmPRFly_uu.q31hou6xgDhVXy1liw Y.JiXCw45r4.d31NzGNYYvS4rZKCjcbmJFSjaVVMoH04rprttFClubYfJ_UtCOB4oarkrYInSi9Z KkCjjHPS57OcmoQGt825Nc7vsjlB1PfkraMx9LObdje8og4hhIyfkAt0aCWK2pOWoqIcACFfd95_ KKPc47rFcABF3H8bkNpbYfMoeOo4qaItvIPOKa.j94Lyk6MWpB9ahjwXsSvSvcKar3ALKdGkD2XN 6gurExvK3hQWKEFduVImzpC4OI6lyAlSzpnpQIyb_2BFv1GYRrjCgVqiK_81XlbyUWBONegjkrx4 7U0EnFTXAQj71lCRiajCYHePeHO2cXsdZ71nycn2dsofor.5ySiEAR8qRXCP9_1B.moS6siQmglu Ifzh3a9ZyKLqCkHYRtJh5_bg.NW2ALe6lurVDMhQR6ASLbQpyarCUtURZrHfrxSHyCSv.Fx3vZa2 r9Z7UEWMTu8KclUg8zXsMmU5x0wDTKALzM_CYD8k_JLbswkVsRAkjIayWLjt38uQypa79iAjf702 sY3zssyjMdhtHinfTjiecDSNJXM2YJ8wPHogDfQghjcs_6je8g9MeHNAu_iwa4JjRbkx7aVMXimH KE7R9X9ZieS1ETY7NiudO5bpC1QnjLpXUZUkE3BqzOAF_QE9i5ieA7JfzhkQ3BPr1kS4wZ8op9xW eAftYQni6PBGq1dIQSQTilcTp3Hhn1k2hMa0vmCcZD4IQD6Fl6Z2viwBDbgzgQcs7wuL3GdKBAYB ixwTXPQBbqC6CVxixIQXaRXzMK_zvXpDySi0E2o4VzzCuZr6w6QvagEVRHZUXdD3_6HRfeCamk6_ JiRRJ4mA90Pp8BS92sSbVKmcVbF6Whqj10ujgmTpAfmPVI0Xu5tV7TE29_yyk05MPigF5nW56gZo FdxDLjxXQWYrGkBpaXJ3S9Dww7C4mloukenzKMZcc_ocI2AdX1x4TmY82 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Sat, 30 Mar 2019 08:54:44 +0000 Date: Sat, 30 Mar 2019 08:54:41 +0000 (UTC) From: Y Sowji Reply-To: Y Sowji To: Cc: sandepp , Message-ID: <1903573815.13936087.1553936081459@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit References: <1903573815.13936087.1553936081459.ref@mail.yahoo.com> X-Mailer: WebService/1.1.13212 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0 Archived-At: Subject: [IPsec] some points to draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 08:54:48 -0000 https://tools.ietf.org/html/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-00 1) In case of IKE or ipsec rekey, when there is a change in cryptographic suite at responder, it is preferabale to send NO_PROPOSAL_CHOSEN payload by responder to the initiator. 2) In case of only ipsec rekey, it is preferable to send TS_UNACCEPTABLE payload by responder to the initiator when there is change in flow configuration(access list) at responder. 3) In the above 2 cases after receiving ERROR notify payload, initiator should perform fresh rekey by including SA and TS payloads. In addition to the suggestions mentioned by Poul, would like to add few more: 4) In case of ipsec rekey, when initiator/responder is not including SA and TS payload it is better to send CHILD_SA_TS_UNCHNGED and include new SPI value. This confirms that we are not including SA and TS payloads explicitly. If possible it is better to include old SPI value as well to avoid REKEY_SA payload. 5) In case of ipsec or IKE rekey, if initiator/responder doesn't include SA payload it is preferable to send CHILD_SA_UNCHNGED payload and include new SPI value. 6) In case of ipsec rekey, if initiator doesn't include TS payload it is preferable to send CHILD_TS_UNCHNGED. Sowjanya yeluri Cisco From nobody Sat Mar 30 18:36:29 2019 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 6C0541200B8 for ; Sat, 30 Mar 2019 18:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rc5ohbLjbPGV for ; Sat, 30 Mar 2019 18:36:25 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A192E120099 for ; Sat, 30 Mar 2019 18:36:25 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [209.171.88.16]) by relay.sandelman.ca (Postfix) with ESMTPS id 2C6871F47C for ; Sun, 31 Mar 2019 01:36:24 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 4C61139D9; Sat, 30 Mar 2019 17:10:36 +0100 (CET) From: Michael Richardson To: "ipsec\@ietf.org" In-reply-to: <6591A593-7E16-49F6-99D5-2D2E5A5D1735@cisco.com> References: <155231377348.23058.4682503726354987752@ietfa.amsl.com> <6591A593-7E16-49F6-99D5-2D2E5A5D1735@cisco.com> Comments: In-reply-to "Graham Bartlett (grbartle)" message dated "Fri, 29 Mar 2019 12:16:18 +0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Sat, 30 Mar 2019 17:10:36 +0100 Message-ID: <27257.1553962236@dooku.sandelman.ca> Archived-At: Subject: Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 01:36:28 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Graham Bartlett (grbartle) wrote: > I see this as a really hard problem to solve (and don't have a > solution). > The issue is, if you're mixing different traffic into an encrypted > payload then there's a very good chance your inner flows are going to > start becoming out of order when they are sent encapsulated. Can you explain why this is an issue? =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAlyflPsACgkQlUzhVv38 QpClLQf7BIUovWhW9h+KKHugxSl42cn/PPFMZqLDl7DU77tAtAsxD4kaaFmyz4GJ JKt+Pl1BxVfbnvXDm9p1qOHvCcw8YiNC3RpU0z2+kfI40kBOr3d3ec0xzNUoo2Ya IZ86yi1vLnqaItKHZw0Nerz0lk/goPPMQz93nq8VfweTfyYnwzTKrsUy4yFWqIpt LUSJS3wTHP+8M2wpUJaRIFjCcNYxe/0Ji+iCVqjCiR0F8pRqe8pruAcSNZnskU3K JEO9Sr+vG4As10PVByGo7h+QvngJdr59wNanI6DukSqEGGsGiqb6CQMJQkk3NwxJ LCz4Wc6zNY6WTDldnJMKlCGLEnLySg== =7Sw5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Mar 30 18:36:37 2019 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 9DD26120099 for ; Sat, 30 Mar 2019 18:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGexyxaCYpkU for ; Sat, 30 Mar 2019 18:36:25 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D7BA120044 for ; Sat, 30 Mar 2019 18:36:25 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [209.171.88.16]) by relay.sandelman.ca (Postfix) with ESMTPS id 3240E1F480 for ; Sun, 31 Mar 2019 01:36:24 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 9976C39A6; Sat, 30 Mar 2019 17:09:32 +0100 (CET) From: Michael Richardson To: "ipsec\@ietf.org" In-reply-to: References: <155231377348.23058.4682503726354987752@ietfa.amsl.com> Comments: In-reply-to Christian Hopps message dated "Fri, 29 Mar 2019 11:35:02 +0100." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Sat, 30 Mar 2019 17:09:32 +0100 Message-ID: <27197.1553962172@dooku.sandelman.ca> Archived-At: Subject: Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 01:36:28 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Christian Hopps wrote: > This is a good question. We currently indicate it's a local > configuration decision, but we may want to go deeper into possible > options in the draft. > Right now we see 3 options: > - A static configured value for the SA > - Inherit the "best" value from the encapsulated traffic. The DSCP value is only meaningful within an AS.=20=20 The end points of the tunnel and the outside of the tunnel are really different diffserv domains. The ECN markings are in the same byte, and we do things with that, but that's not the DSCP. Changing the DSCP would seem to enable traffic analysis. As TFS needs to do congestion control, I think that the ECN markings should be used by TFS, and TFS should do ECN markings upon entry/exit of the tunnel itself, after some processing itself. It might mark congestion seen more often than the outside of the tunnel sees if it needs the users of the tunn= el to back down because they are exceeding the allocation. It might also ignore congestion if the congestion is due to the extra traff= ic. So I think that the DSCP needs to be configured appropriately for the AS that is sending the packets. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAlyflLwACgkQlUzhVv38 QpAiwwf/dUQ24EnBhL6JaMYda92NQC07ONAvufmDyuHr2kQo5ODo35qmPIZgt+9A t1ZrfI3R04JOWIXrUeJf9/nXlXwPHMdmOrfoMD2BnveVmVe5hWNMqawoQaj7Cs+o AYnBH/9KLlO1LHO/ISKfiE1UCd/En+Lsyg4Fy8a91UIYYXyhqLzjVgWqRakKCKi6 e3iBserlQRttbhv4G0nn88AgTCSLRwBy6Uu4qAS/Mmisu1KnkPGFVxQuhifubPu+ UOUSotOtU+Fd8VnNBUmaJdtWjbfhgXfL9w/vryfCik1uArzYbqvisJHkDsMWk+jL 57XqspXfJ7JjhwtRrDQ/iuzifwvMVQ== =Xm3w -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Mar 30 18:36:47 2019 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 BBEB6120044 for ; Sat, 30 Mar 2019 18:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYWDzDEdl1p1 for ; Sat, 30 Mar 2019 18:36:27 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A73B1200B1 for ; Sat, 30 Mar 2019 18:36:26 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [209.171.88.16]) by relay.sandelman.ca (Postfix) with ESMTPS id 2D76B1F47E for ; Sun, 31 Mar 2019 01:36:24 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 663BD356D; Sat, 30 Mar 2019 17:03:13 +0100 (CET) From: Michael Richardson To: ipsec@ietf.org In-reply-to: <02fb01d4e5f6$aac3a110$004ae330$@gmail.com> References: <155231377348.23058.4682503726354987752@ietfa.amsl.com> <02fb01d4e5f6$aac3a110$004ae330$@gmail.com> Comments: In-reply-to "Valery Smyslov" message dated "Fri, 29 Mar 2019 09:14:27 +0300." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Sat, 30 Mar 2019 17:03:13 +0100 Message-ID: <26916.1553961793@dooku.sandelman.ca> Archived-At: Subject: Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 01:36:29 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Valery Smyslov wrote: > having think a bit more about reassembling on a receiving side, I thi= nk > that there may be some issues. You rely on ESP SN to properly > reassemble the IP packets, but there is at least one case when it > doesn't work - when IPsec protects multicast traffic and there are I don't think it is useful to run tfs for multicast traffic. > And I really want to make reassembling feature optional and negotiabl= e. It seems to me that the receiver has to indicate that it supports it or not, (just like we do for compression), and the sender either uses it or does no= t. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAlyfk0AACgkQlUzhVv38 QpDutgf+JBhAJJgJmW8aeMDaY9QO9NWaLgxOR7Ao53Xv1F1iAkLozHciJcGzRQP1 ywVVJFDbo9DbMGrtaRI5m9rdlUUrveP5jCOVc6LuAUpmIpB1pRzpB//3uap3CLX3 yv9jFRVb8QUA/b61kR21y+7CEnIudA/oQsYQHx+7BysC495AgIFMUfcnp7/IydL/ wsp0hCBI2GQuTxfc8F2MDeKYkCDM0ZYMrKJhM2sAZx0d2Fx2Lxr/+xir1SdB1k3e iNy4RC1qeNTJTXGmika2Wv5Zhg4oSJp/qVni/lrZdlYyAC4QzieEA/V5b60pWJls NltcCuVJ15SoGLxNkbl6UCqyscrHeg== =gXAo -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Mar 30 22:56:32 2019 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 0B206120179 for ; Sat, 30 Mar 2019 22:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 F6UJqVThvI1P for ; Sat, 30 Mar 2019 22:56:29 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7B18B120133 for ; Sat, 30 Mar 2019 22:56:29 -0700 (PDT) Received: from tops.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id C8A3E604DC; Sun, 31 Mar 2019 01:56:28 -0400 (EDT) References: <155231377348.23058.4682503726354987752@ietfa.amsl.com> <02fb01d4e5f6$aac3a110$004ae330$@gmail.com> <26916.1553961793@dooku.sandelman.ca> User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: ipsec@ietf.org Cc: chopps@chopps.org In-reply-to: <26916.1553961793@dooku.sandelman.ca> Date: Sun, 31 Mar 2019 01:56:27 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 05:56:31 -0000 --=-=-= Content-Type: text/plain; format=flowed Michael Richardson writes: > Valery Smyslov wrote: > > > And I really want to make reassembling feature optional and negotiable. > > It seems to me that the receiver has to indicate that it supports it or not, > (just like we do for compression), and the sender either uses it or does not. This seems like a good solution. Thanks, Chris. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlygVosACgkQLh2DDte4 MCVwQRAAg3GQ9NIljTS0Jc5PbyaVhBGS/CQCbVRkL8tBEB7XQfcl+4HpTCe+rnRd jSiwgFqPr/AOKYIsb7aKBQ8XwPorQSDomxagw5yRUvC//J+C8Pf1iuMQ8jd2Lg52 fBHSgn5CAJRXUzSiwDnPwbqFKte/ocZRUxelzNL4vu07z2/A4KOdRs19I7BltWoB ZuyFXJUYjpBEzvmh5mdYU86ZJVvtpgnWYmrWwoa5X4BoornRkGcEnsRMqld/sVLU 5ydIp7UZ4i6uVXmYoHZQyNA/TrvGgBaIKeVuROHyp44XueuZKFYLVnmMk03jz8Hd yLqpKFO7NocCSA1cV7e80P2dgVGDjaNV9w/jJAVpEEimogN3YZduN8Ue6O0xRGR+ SFjI+KAOBvUM6gAATW9q9B0wYX6kWQxKeMUBWSHNkqkJWh1n484eNnSXmW49v2J3 rXPDG3fhDfy9JryW1xE5aN7Xe7QEKgUILbMb4Se5iybGSc33U0xNl01wfjyOhCUF fxU493Rb+aLoIxfJlqcr+k8xm22wLwvsCoNw1tuEdQvS1LzPLOF5Xtt4kLAqdikd ZKdyZWfaWPOehUSc6aAR9FvgLchYwc+AuZGeHflkDsQv6Ker5puwXV+JIxj6iGrZ qMtzKO5EtNTfBnGuDTJmMp1HxMMphW4m+EPyYqJCfPnb3LjwcnY= =G94/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Mar 31 15:06:43 2019 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 E71C312022A for ; Sun, 31 Mar 2019 15:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Qit25pxC; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=N46xJSQs 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 bzL07cCi0dXv for ; Sun, 31 Mar 2019 15:06:40 -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 F26651201E4 for ; Sun, 31 Mar 2019 15:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8227; q=dns/txt; s=iport; t=1554069999; x=1555279599; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ELr0qBm8oCTkVgX7vn6o1L6IPvSHPkOgWoyJRSxlkmw=; b=Qit25pxC7de9SsW/ADpDNOK8RjrXwJP/Wr1A3PGD4jQVeUg0f48alRJj HcYgUfHn5xvg4lE1PsqziJGxb+G7OwQHGbg7YOxbf2HZkAaxoX5EKBRyE j30V0mSOPCzA1OAvqHSmeURk+t+9J/VwmjbYkJzptygbmVGBeyA3K0xx/ o=; X-Files: smime.p7s : 4990 IronPort-PHdr: =?us-ascii?q?9a23=3ArqrKlxzMP+yLhDLXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuKE0fyNuLuYgQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAABhOaFc/4ENJK1jGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYE9UANodAQLJwqEBINHA4RSimBKgg2XD4EugSQDVAI?= =?us-ascii?q?JAwEBHw2BS4J1AiCFFyI0CQ0BAQMBAQkBAwJtHAyFSgEBAQMBIxoDAQE4DwI?= =?us-ascii?q?BCBgqAgICMCUCBAESDg2DBwGBXQMNCAEDnVICihRxgS+CeQEBBYJGgjMYggU?= =?us-ascii?q?HCIEvAYFJiUwdF4FAP4E4H4JMPoQdPoJzMYImpU0JAoRnghKFDYdYGpQsiz+?= =?us-ascii?q?TTgIEAgQFAg4BAQWBTTiBVnAVZQGCQQmCAYMaVIpTcoEojGaBLgGBHgEB?= X-IronPort-AV: E=Sophos;i="5.60,294,1549929600"; d="p7s'?scan'208";a="531144876" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Mar 2019 22:06:38 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x2VM6c37025240 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 31 Mar 2019 22:06:38 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 31 Mar 2019 17:06:37 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 31 Mar 2019 18:06:36 -0400 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 31 Mar 2019 18:06:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VBsh89MyMcyX+m+WopRHHP+f2hNrpSZwvzkMd/qQMOI=; b=N46xJSQsrz2w02o3ryEENaUEOyEap3Sa4PDnrYkrobep1K3iY5Ag0MbI6RRX3nUFWwR/gi95JOt4fIrhlMX1TOX2y5Kq7gS64wTdIkW6eVoCyIQsvB59+qldgbUTT3yVFvuEyXbEDW0g9cFqeArsRSEkWoKzMGJJGXiDdLVB1QA= Received: from DM5PR11MB1786.namprd11.prod.outlook.com (10.175.91.17) by DM5PR11MB1433.namprd11.prod.outlook.com (10.172.36.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17; Sun, 31 Mar 2019 22:06:35 +0000 Received: from DM5PR11MB1786.namprd11.prod.outlook.com ([fe80::a44e:3318:25a4:ad3e]) by DM5PR11MB1786.namprd11.prod.outlook.com ([fe80::a44e:3318:25a4:ad3e%8]) with mapi id 15.20.1750.017; Sun, 31 Mar 2019 22:06:35 +0000 From: "Graham Bartlett (grbartle)" To: Michael Richardson , "ipsec@ietf.org" Thread-Topic: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt Thread-Index: AQHU2BdgklLKcgpU4UaDt5KsQjVkuaYieowAgAALZgCAABxKgIAB080AgAIGjIA= Date: Sun, 31 Mar 2019 22:06:35 +0000 Message-ID: <78FA5629-0DBB-470F-AD8D-E69C6EEC9C9D@cisco.com> References: <155231377348.23058.4682503726354987752@ietfa.amsl.com> <6591A593-7E16-49F6-99D5-2D2E5A5D1735@cisco.com> <27257.1553962236@dooku.sandelman.ca> In-Reply-To: <27257.1553962236@dooku.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=grbartle@cisco.com; x-originating-ip: [94.119.64.15] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5ee48f3a-1065-4b23-f256-08d6b6252424 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:DM5PR11MB1433; x-ms-traffictypediagnostic: DM5PR11MB1433: x-microsoft-antispam-prvs: x-forefront-prvs: 0993689CD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(376002)(39860400002)(366004)(136003)(189003)(199004)(33656002)(186003)(102836004)(5660300002)(76176011)(71190400001)(58126008)(6436002)(110136005)(99286004)(4744005)(106356001)(105586002)(2501003)(71200400001)(2906002)(99936001)(8936002)(36756003)(26005)(83716004)(6506007)(6512007)(486006)(68736007)(6246003)(446003)(6116002)(11346002)(476003)(3846002)(2616005)(53936002)(25786009)(86362001)(66066001)(6486002)(316002)(81156014)(8676002)(82746002)(81166006)(229853002)(966005)(93886005)(7736002)(305945005)(14444005)(256004)(97736004)(6306002)(14454004)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1433; H:DM5PR11MB1786.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: z9cSnw5fK+c99H6gSaZDU6FOYm6TGW/lFgnueHr4iWDgAfnZAhgDN8zeHvU+WsvYMdkz+5CteNB9elV3vQVgOtEX0uQP6S/9r9/9D+ChI70eAzY5eeayb5IO5W536xHTxawAtr8DbEZdP17AMMidWWlwva9sqy7z2j2RfDQDDs6N1VT8PSvNcuD4WJ8a3Z0fQQaYRk8CET0XYTrs3KKKWd3vjJwWhQw1EIVuqjapVhRKB2MfMCVZptxnM3Hpr8NQPol+FjgLz4I2yCvE5CiMItrQLQaDP6hQWKHqI8UKmbQoFu/N5aHnUlz9+GURLnVm8Y51b3EkgG8dVkzmrt3m9S3xmUa9ZkVwTFvUExqXjNc3M8TcGON4ssMZaTSfbVIhumsmxCEbefrtKs0yvQvmcqsOYKX1G84cQzSGgr+V6gE= Content-type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3636918393_1958781648" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5ee48f3a-1065-4b23-f256-08d6b6252424 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2019 22:06:35.4839 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1433 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [IPsec] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 22:06:42 -0000 --B_3636918393_1958781648 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Michael >From my limited experience the performance of many applications is degraded= when traffic is received out of order. cheers =EF=BB=BFOn 31/03/2019, 02:37, "IPsec on behalf of Michael Richardson" wrote: =20 Graham Bartlett (grbartle) wrote: > I see this as a really hard problem to solve (and don't have a > solution). =20 > The issue is, if you're mixing different traffic into an encrypte= d > payload then there's a very good chance your inner flows are goin= g to > start becoming out of order when they are sent encapsulated. =20 Can you explain why this is an issue? =20 --=20 ] Never tell me the odds! | ipv6 mesh net= works [=20 ] Michael Richardson, Sandelman Software Works | network archi= tect [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rai= ls [=20 =20 --B_3636918393_1958781648 Content-type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITegYJKoZIhvcNAQcCoIITazCCE2cCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghD6MIIFMDCCBBigAwIBAgIRANt/amHBbAccGfNNQCnZKy4wDQYJKoZIhvcNAQELBQAw gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE4MDUy MTAwMDAwMFoXDTE5MDUyMTIzNTk1OVowIzEhMB8GCSqGSIb3DQEJARYSZ3JiYXJ0bGVAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvRs+W1UFSzWjG08ekQlb STJne0QxIugjwOxmlVsWuadzNpHs/9Lolp5hHrgLnFC+tPP+qZqtJX+l9vD9KnrUNyVD7l8O Q+EIFSiLKBF2WA4Qps6znQRJS+Bk5ggfMRo9ni1Or6B5QIgLF1fbRqPitM0TINq+Sj9xnSbq 5vJ8TmEyzU90HNJNtBzZaYxKbHImoXgTpONJtSIt94bDRcI3UXrvHhn9Zn2MmIXqGzIDLUjl RCzkBDx6wqZ9ZZ78vyo+Ewa1so7L+NV/rDpGQQiPCDxd+6QLvUIZkNdl9ViWRR+1LPAq55Rw ZkfFSziuCJwlHz0MHbGiUpKfk+rrmtEiqwIDAQABo4IB6DCCAeQwHwYDVR0jBBgwFoAUgq9s jPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFPBG1SAHV8aiV0IwohMhtCqrdwsaMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBP oE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9j YS5jb20wHQYDVR0RBBYwFIESZ3JiYXJ0bGVAY2lzY28uY29tMA0GCSqGSIb3DQEBCwUAA4IB AQAonuiVei61mvmBh/zsM5gRCZKZrv5CxaOiz1726DZ+zbNY0NFlJ7011HxD1LKWIp3f9AOU ec0GFrTmdYsJPU9+K9GuxtaH1hk3LOM3MwHxyyvm4JONbWfF+VCuRstEA+zPD0hsUn4BMVTc f2IkgoysAb1bmvJdAzwuiswPgIZaCJ12vY9WWcPwZXqgGL72/sUw+XQxKbXH/PtqYcTKhYHS GRTHQJSOi2GeG+faXHjBmo9vrJV3500EcmzATQYuhNl/L4XwPtiFoAqJ74hXvdKE5hgSqbUc B5XCEQYNABPD41fVjm1uCBmGs//8s/5hGm/20zNOe/D9Njoum9HyoRHGMIIF5jCCA86gAwIB AgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n9jR22YRq 2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgzKlWlVJGy K+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikFlgqOtzk0 6kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9tGKTDyUGg 2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK+xS1AgMB AAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4EFgQU gq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8C AQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29t b2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUF BwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNB QWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAN BgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx 4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDc ZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0 wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85 S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8cz m12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRL RTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8 MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQvdVifC3Ht wlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDNXFnHn9tF pMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIwggXYMIIDwKAD AgECAhBMqvnK22Nv4B/3TthbA4adMA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTAeFw0xMDAxMTkwMDAwMDBaFw0zODAxMTgyMzU5NTlaMIGFMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJHoVJLS ClaxrA0k3cXPRGd0mSs3o30jcABxvFPfxPoqEo9LfxBWvZ9wcrdhf8lLDxenPeOwBGHu/xGX x/SGPgr6Plz5k+Y0etkUa+ecs4Wggnp2r3GQ1+z9DfqcbPrfsIL0FH75vsSmL09/mX+1/GdD cr0MANaJ62ss0+2PmBwUq37l42782KjkkiTaQ2tiuFX96sG8bLaL8w6NmuSbbGmZ+HhIMEXV reENPEVg/DKWUSe8Z8PKLrZr6kbHxyCgsR9l3kgIuqROqfKDRjeE6+jMgUhDZ05yKptcvUwb KIpcInu0q5jZ7uBRg8MJRk5tPpn6lRfafDNXQTyNUe0LtlyvLGMa31fIP7zpXcSbr0WZ4qNa JLS6qVY9z2+q/0lYvvCo//S4rek3+7q49As6+ehDQh6J2ITLE/HZu+GJYLiMKFasFB2cCudx 688O3T2plqFIvTz3r7UNIkzAEYHsVjv206LiW7eyBCJSlYCTaeiOTGXxkQMtcHQC6otnFSlp UgK7199QalVGv6CjKGF/cNDDoqosIapHziicBkV2v4IYJ7TVrrTLUOZr9EyGcTDppt8WhuDY /0Dd+9BCiH+jMzouXB5BEYFjzhhxayvspoq3MVw6akfgw3lZ1iAar/JqmKpyvFdK0kuduxD8 sExB5e0dPV4onZzMv7NR2qdH5YRTAgMBAAGjQjBAMB0GA1UdDgQWBBS7r34CPfqm8TyEjq3u OJjs2TIy1DAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQwF AAOCAgEACvHVRoS3rlG7bLJNQRQAk0ycy+XAVM+gJY4C+f2wog31IJg8Ey2sVqKw1n4Rkuku up4umnKxvRlEbGE1opq0FhJpWozh1z6kGugvA/SuYR0QGyqki3rF/gWm4cDWyP6ero8ruj2Z +NhzCVhGbqac9Ncn05XaN4NyHNNz4KJHmQM4XdVJeQApHMfsmyAcByRpV3iyOfw6hKC1nHyN vy6TYie3OdoXGK69PAlo/4SbPNXWCwPjV54U99HrT8i9hyO3tklDeYVcuuuSC6HG6GioTBax GpkK6FMskruhCRh1DGWoe8sjtxrCKIXDG//QK2LvpHsJkZhnjBQBzWgGamMhdQOAiIpugcaF 8qmkLef0pSQQR4PKzfSNeVixBpvnGirZnQHXlH3tA0rK8NvoqQE+9VaZyR6OST275Qm54E9J kj0WgkDMzFnG5jrtEi5pPGyVsf2qHXt/hr4eDjJG+/sTj3V/TItLRmP+ADRAcMHDuaHdpnDi BLNBvOmAkepknHrhIgOpnG5vDmVPbIeHXvNuoPl1pZtA6FOyJ51KucB3IY3/h/LevIzvF9+3 SQvR8m4wCxoOTnbtEfz16Vayfb/HbQqTjKXQwLYdvjpOlKLXbmwLwop8+iDzxOTlzQ2oy5GS sXyF7LUUaWYOgufNzsgtplF/IcE1U4UGSl2frbsbX3QxggJEMIICQAIBATCBrTCBlzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDbf2phwWwHHBnzTUAp 2SsuMA0GCWCGSAFlAwQCAQUAoGkwLwYJKoZIhvcNAQkEMSIEIGj9Ke/vGLUx9vx75Rx95cXt poul8eeIKrK0cValhEGDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTE5MDMzMTIyMDYzM1owDQYJKoZIhvcNAQEBBQAEggEAQzl0GGv5ZNvSCI6CXG+MlnHy KGj4GJNiP05So3qDYpNl4W+lq8UpT0336ey3Y2Bp2SS/h5JoW/CTbZHE2cy6IdRmhRT9G5QQ P2Di8FWEZd4yd2ISDxpdPZ1HxfIDY8wBa+L8cgPgprQnzFS8OPJZ4DMwGH/HNly7nFe9oQ/o QX0S6lWkrC9CGin/Bes8jFQxXhZJFb8NTL98gjeySl0cLnTz3mfyuS5/JRJFWwQrn2FLP6xm SRJ6Us57BtSN0xtBEhB3YCRltsMKwTV5q48kS/L2aOfWkMnA4Ne4/Ihh9vLJGGW7MdwBD7YX HsBwPKWDLLb+D9gR1JYHd9mjPKj2yA== --B_3636918393_1958781648-- From nobody Sun Mar 31 16:27:32 2019 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 E9846120073 for ; Sun, 31 Mar 2019 16:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLM2kvC5G4n0 for ; Sun, 31 Mar 2019 16:27:29 -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 1AEFF12006E for ; Sun, 31 Mar 2019 16:27:29 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 2FB51380BE; Sun, 31 Mar 2019 19:26:43 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 740A12710; Sun, 31 Mar 2019 19:27:27 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 72A1C21C; Sun, 31 Mar 2019 19:27:27 -0400 (EDT) From: Michael Richardson To: "Graham Bartlett \(grbartle\)" cc: "ipsec\@ietf.org" In-Reply-To: <78FA5629-0DBB-470F-AD8D-E69C6EEC9C9D@cisco.com> References: <155231377348.23058.4682503726354987752@ietfa.amsl.com> <6591A593-7E16-49F6-99D5-2D2E5A5D1735@cisco.com> <27257.1553962236@dooku.sandelman.ca> <78FA5629-0DBB-470F-AD8D-E69C6EEC9C9D@cisco.com> X-Mailer: MH-E 8.6; nmh 1.7+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] Fwd: I-D Action: draft-hopps-ipsecme-iptfs-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 23:27:31 -0000 --=-=-= Content-Type: text/plain Graham Bartlett (grbartle) wrote: > From my limited experience the performance of many applications is > degraded when traffic is received out of order. If the flows are marked differently, then they are from different applications, so it does not matter. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlyhTN8ACgkQgItw+93Q 3WXsEQf+KSW59dvmetOziqQeXwRq0GC5wa4ngFaiQR9p5TgCWLcISQ+VBHqyLab5 cwJjduY52SFWAUE1QdJBHckqOZ69/c/1Twl7SYS9v8dOIsCj/JYt79JM96I0O3Qt oy8lutfg9FHtwApHpgzqoWdwpvtEUy8SY10VBFENitTijY+kzLvQ3kkzCKB9KIrx Bfx9YWh9CYwCm/7t7MEb3qF9r7WHy+2hKFpgXcw4ayVS6xfRLZ5sC5TzAThizgte gYdL+hhzWIAjDr8u9GRZdbkTMK5JfEuzmyqKOe86H1j9A92l02lfPlZ1EAV6eKSp url90RyrzH2gkik8cVSopBOwSnG9yQ== =pDxF -----END PGP SIGNATURE----- --=-=-=--