From nobody Thu Feb 1 05:07:38 2018 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 51D8712E03A for ; Thu, 1 Feb 2018 05:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=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 6PuhOTbgLK1s for ; Thu, 1 Feb 2018 05:07:35 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE13212E87F for ; Thu, 1 Feb 2018 05:07:34 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id x196so26094857lfd.12 for ; Thu, 01 Feb 2018 05:07:34 -0800 (PST) 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:thread-index:content-language; bh=wxpeEjEeyspSQv6IbcINmvvos2eziPqMIFGsJKXnruM=; b=KK7BYkvAaT+xxiq0fraAsMAqnqwJuv1oXvAo+8JthiIT7WZE9oaaNTBRNqAkq/IRni Vocx5EyHnhLFaSM78ETZOzZgTUZZErjD15X3IwMSLGs3jZNCIAoMA13Z9+3dvLqmZLns UpRqeZj/nWsRAZfPyZenEljEc2nedw4D1mw8wQkhxBiRM7sfGKV6jeWQd1yzO6JDBkvb ykcl65shMuGayw48PEk6lD12ixkkfnsmXnf6BiKZVTTWjTjIgs+5xgMgX4j7zPwRfNRQ /rq96QBqDANNpHXi/zEskyNRoRRh0u7yZaQHXDvDhwtlS+hwrbh/SMITmN5/bSl0cGzO /mkQ== 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:thread-index:content-language; bh=wxpeEjEeyspSQv6IbcINmvvos2eziPqMIFGsJKXnruM=; b=n8GS/RT+tRg6rswsMCXqk+r6DC9vJR6yaB5MjQRpjr6+EVM3DQQh8MNiaO86TX1dRX qje0NzmjyEfeq5ymDdd//j+pgbgT4OWCHZTYzJVBm+DVFrozvb5Ojl8vvxQ0m4wB9RMf KHAbOoln6DjqCl8JrCOcxGBUhrYROxm8BqSM7xIg/YGP87dKWniYQ8h3JaMnx9ioyYW+ Ws/WurPYUgV9Ds/OpMymtk1/QY78LY8yFr8uCI2n9jfT2rl6bAO+p542w2I5TZS1yeci +NlU422fEZYDWn0WpzkmdWthQGeSi9wcnqBANdtifILWAjX8XnJWbw7/JdF2MS/ZJyyf HGSA== X-Gm-Message-State: AKwxytcXv4h9ygkjWCCKTy9HwfDOsBslulTgoa23k+iFnu8NwKaW/N9a yyagV6ZzU9gSU4489hSPepo= X-Google-Smtp-Source: AH8x225GC4FPSHDH7+cNRUtH9MQb9jzMmpFJTBKkTLDuwbfK3SbyZ1wn/JaQ5p2GVgbPYaHLhW8RNw== X-Received: by 10.25.198.201 with SMTP id w192mr20467370lff.40.1517490452980; Thu, 01 Feb 2018 05:07:32 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id g133sm4355143lfg.89.2018.02.01.05.07.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 01 Feb 2018 05:07:32 -0800 (PST) From: "Valery Smyslov" To: "'Yoav Nir'" , , "'David Waltermire'" , "'Tero Kivinen'" , "'Eric Rescorla'" Cc: "'pe'" , "'IPsecME WG'" , , "'Paul Hoffman'" , "'charliekaufman'" References: <20180130215039.EE475B80DE5@rfc-editor.org> <3380F947-18B4-4DDA-B218-B60E7E2DA460@gmail.com> In-Reply-To: <3380F947-18B4-4DDA-B218-B60E7E2DA460@gmail.com> Date: Thu, 1 Feb 2018 16:07:32 +0300 Message-ID: <032f01d39b5d$9fadaee0$df090ca0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0330_01D39B76.C4FF7AC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQILz9bOFKZfhNrtFRMnelb5NiK/6AIdhUHyANtqQzSjB1HeUA== Content-Language: ru Archived-At: Subject: Re: [IPsec] [Editorial Errata Reported] RFC7296 (5247) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 13:07:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0330_01D39B76.C4FF7AC0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, =20 I think this erratum should be rejected. First, there is no value NONE in the IANA registry for the Protocol Type. The value 0 is marked = Reserved, note NONE. =20 Then, there are a lot of IPsec documents that require protocol field in = Notify payload to be zero. Should this erratum be accepted, similar errata should be reported for = all these documents. I don=E2=80=99t think it would help implementers in any respect. =20 Regards, Valery. =20 =20 On 31 Jan 2018, at 7:04, Yoav Nir < = ynir.ietf@gmail.com> wrote: =20 Hi. =20 I don=E2=80=99t see anything wrong with the suggestion (it=E2=80=99s = just adding =E2=80=9Cto indicate NONE=E2=80=9D in the last sentence). = However: * A value marked =E2=80=9CReserved=E2=80=9D in IANA just means that IANA = should not assign it. It does not mean that it cannot appear in the = protocol. * Using a zero in a field to indicate no value is common, and IANA = registries are inconsistent about whether such zero values are named or = just reserved. * Unless we want to change the IANA registry, there is no reason to = uppercase =E2=80=98none=E2=80=99 * I don=E2=80=99t think we need to update the IANA registry. =20 =E2=80=9CHold for document update=E2=80=9D? On 30 Jan 2018, at 23:50, RFC Errata System = wrote: =20 The following errata report has been submitted for RFC7296, "Internet Key Exchange Protocol Version 2 (IKEv2)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5247 -------------------------------------- Type: Editorial Reported by: Andrew Cagney Section: 3.10. Original Text ------------- o Protocol ID (1 octet) - If this notification concerns an existing SA whose SPI is given in the SPI field, this field indicates the type of that SA. For notifications concerning Child SAs, this field MUST contain either (2) to indicate AH or (3) to indicate ESP. Of the notifications defined in this document, the SPI is included only with INVALID_SELECTORS, REKEY_SA, and CHILD_SA_NOT_FOUND. If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt. Corrected Text -------------- o Protocol ID (1 octet) - If this notification concerns an existing SA whose SPI is given in the SPI field, this field indicates the type of that SA. For notifications concerning Child SAs, this field MUST contain either (2) to indicate AH or (3) to indicate ESP. Of the notifications defined in this document, the SPI is included only with INVALID_SELECTORS, REKEY_SA, and CHILD_SA_NOT_FOUND. If the SPI field is empty, this field MUST be sent as zero to indicate NONE and MUST be ignored on receipt. Notes ----- If I assume that the 'Protocol ID' field in the notification payload is = specified by: Internet Key Exchange Version 2 (IKEv2) Parameters IKEv2 Security Protocol Identifiers then a notification is using the 'Reserved' value 0. Since the value = is being used, I think it would be better to give it a name. Other uses of 'Protocol = ID' don't need updating as they all explicitly list allowed values, and in no case is 0 = allowed. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party =20 can log in to change the status and edit the report, if necessary.=20 -------------------------------------- RFC7296 (draft-kivinen-ipsecme-ikev2-rfc5996bis-04) -------------------------------------- Title : Internet Key Exchange Protocol Version 2 (IKEv2) Publication Date : October 2014 Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. = Kivinen Category : INTERNET STANDARD Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 =20 ------=_NextPart_000_0330_01D39B76.C4FF7AC0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

I think this erratum should be rejected. First, there is no value = NONE

in the IANA registry for the Protocol Type. The value 0 is marked = Reserved, note NONE.

 

Then, there are a lot of IPsec documents that require protocol field = in Notify payload to be zero.

Should this erratum be accepted, similar errata should be reported = for all =C2=A0these documents.

I don=E2=80=99t think it would help implementers in any = respect.

 

Regards,

Valery.

 

 

On 31 Jan 2018, = at 7:04, Yoav Nir <ynir.ietf@gmail.com> = wrote:

 

Hi.

 

I = don=E2=80=99t see anything wrong with the suggestion (it=E2=80=99s just = adding =E2=80=9Cto indicate NONE=E2=80=9D in the last sentence). = However:

  • A value marked =E2=80=9CReserved=E2=80=9D in IANA just = means that IANA should not assign it. It does not mean that it cannot = appear in the protocol.
  • Using a zero in a field to indicate no value is common, and = IANA registries are inconsistent about whether such zero values are = named or just reserved.
  • Unless we want to change the IANA registry, there is no = reason to uppercase =E2=80=98none=E2=80=99
  • I don=E2=80=99t think we need to update the IANA = registry.

 

=E2=80=9CHold for document = update=E2=80=9D?



On 30 = Jan 2018, at 23:50, RFC Errata System <rfc-editor@rfc-editor.org&g= t; wrote:

 

The following errata report has been submitted for = RFC7296,
"Internet Key Exchange Protocol Version 2 = (IKEv2)".

--------------------------------------
You may = review the report below and at:
http://www.rfc-editor.o= rg/errata/eid5247

--------------------------------------
Ty= pe: Editorial
Reported by: Andrew Cagney <andrew.cagney@gmail.com>
Section: 3.10.

Original = Text
-------------
  o  Protocol ID (1 octet) - If = this notification concerns an = existing
     SA whose SPI is given in the = SPI field, this field indicates = the
     type of that SA.  For = notifications concerning Child SAs, = this
     field MUST contain either (2) to = indicate AH or (3) to indicate
     ESP. =  Of the notifications defined in this document, the SPI = is
     included only with = INVALID_SELECTORS, REKEY_SA, = and
     CHILD_SA_NOT_FOUND.  If the = SPI field is empty, this field MUST = be
     sent as zero and MUST be ignored on = receipt.

Corrected Text
--------------
  o =  Protocol ID (1 octet) - If this notification concerns an = existing
     SA whose SPI is given in the = SPI field, this field indicates = the
     type of that SA.  For = notifications concerning Child SAs, = this
     field MUST contain either (2) to = indicate AH or (3) to indicate
     ESP. =  Of the notifications defined in this document, the SPI = is
     included only with = INVALID_SELECTORS, REKEY_SA, = and
     CHILD_SA_NOT_FOUND.  If the = SPI field is empty, this field MUST = be
     sent as zero to indicate NONE and = MUST be ignored on receipt.

Notes
-----
If I assume that = the 'Protocol ID' field in the notification payload is specified = by:

 Internet Key Exchange Version 2 (IKEv2) = Parameters
 IKEv2 Security Protocol Identifiers

then a = notification is using the 'Reserved' value 0.   Since the = value is being used,
I think it would be better to give it a name. =  Other uses of 'Protocol ID' don't need
updating as they all = explicitly list allowed values, and in no case is 0 = allowed.

Instructions:
-------------
This erratum is = currently posted as "Reported". If necessary, please
use = "Reply All" to discuss whether it should be verified = or
rejected. When a decision is reached, the verifying party =  
can log in to change the status and edit the report, if = necessary.

--------------------------------------
RFC7296 = (draft-kivinen-ipsecme-ikev2-rfc5996bis-04)
--------------------------= ------------
Title =             &= nbsp; : Internet Key Exchange Protocol Version 2 = (IKEv2)
Publication Date    : October = 2014
Author(s) =           : C. = Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen
Category =            : = INTERNET STANDARD
Source =             &= nbsp;: IP Security Maintenance and Extensions
Area =             &= nbsp;  : Security
Stream =             &= nbsp;: IETF
Verifying Party     : = IESG

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

 

 

------=_NextPart_000_0330_01D39B76.C4FF7AC0-- From nobody Thu Feb 1 05:08:33 2018 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 A4C5F131716 for ; Thu, 1 Feb 2018 05:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 p6L7B38A3Pgt for ; Thu, 1 Feb 2018 05:08:28 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1F512EB44 for ; Thu, 1 Feb 2018 05:08:28 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id o89so26100831lfg.10 for ; Thu, 01 Feb 2018 05:08:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=pg2vNmuC3RZbICArdMQA7PKGodh/awXljFak3sypAYw=; b=gMEf9zRYhB1Nf29xXeobyDJ6T1gO/YEwUc6MQzbWbv1wkZGRur/JD+zc7PjiRxcYWT INj3ZbekgWcow+aPsjIwy6IjY5yrmuuMrq/iXLUvW8ZULlEmalOARa2twubMLDlifG75 eiciNsHhIIjfUUnJ1ySWtMevDCn/NftKzGCIEHuIgMiYwA5gFfEdEF+ehNs+bQK6waoU aTTX0J2mvB7Hz+OOXUYZdbhNMVzSSLSRCxnd3Zl3ynZbfnHFCzFPZjunRdNAMO++WlTn SyD6gG6JVhywX0rU9seZ/p8RhUrpU7PBXWw7jxNdthoVDSMmLQYA7O/YmJmKfMW5bUMf 1kzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=pg2vNmuC3RZbICArdMQA7PKGodh/awXljFak3sypAYw=; b=Tqp1AJuUUx03PATS4o+VRDUyBeA6/yu8qXED5kgjhSrlNpIyiCV+QOtL7BTW4nS7J8 o4Qbv0yoUxrP3rvQizn14r3aKJxxeNkz1lGMEP6h8OB/HHvmC0zCm6Kxvq3wSdxo10M2 lhhszIu61pYqb7le9UMJhNTh97i6cY+emh8vGgVZj8m5V+WNrm3Hz4BjHjePzFOHVnPL 7ptpJtAchFslW3YWK7R3ofSsUlQnjmKZp1RlfEiUIfBpDodcalqsUGlQvRfHPFcTbA7E agA3WA+M4FrCWDpNHyeehF3a7SsZohjGP6Mr67Grcc83tnJ9Iprh8Jgs9wEJCHSFEi/l YAsg== X-Gm-Message-State: AKwxytcie0fQb/td1+lAFQ48AHMhH4jKj23NuElYt2eoagc7AjRvT0/e py8PCDrRXo3RZjEwhlo3XFTRUA== X-Google-Smtp-Source: AH8x224tOi0tuNveA22jmSQ89ifOevMVPu0tz+ZKph+jVrHXhG4iU8Bwid8/ABhX73abTj72SLOW+w== X-Received: by 10.25.16.3 with SMTP id f3mr21022506lfi.98.1517490505918; Thu, 01 Feb 2018 05:08:25 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id v11sm915186ljv.11.2018.02.01.05.08.25 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 01 Feb 2018 05:08:25 -0800 (PST) From: "Valery Smyslov" To: Date: Thu, 1 Feb 2018 16:08:26 +0300 Message-ID: <033701d39b5d$bf7f2140$3e7d63c0$@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: AdOZzoJZHdT8osJ7SrSxgJ2i8Y9LDA== Content-Language: ru Archived-At: Subject: [IPsec] draft-tjhai-ipsecme-hybrid-qske-ikev2-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 13:08:31 -0000 Hi, this is a long message... I've looked through the -01 version of the QSKE draft. The draft has been expanded and now it covers such aspects as QSKE negotiation, fragmentation and transferring of payloads larger than 64K. I didn't review the draft in details, however after reading I have concerns over the technical solutions the draft proposes. In particular, I think that the problems of negotiation, fragmentation and representation of large payloads could be solved better. 1. Negotiation. The draft introduces a new negotiation mechanism to be used explicitly with multiple QS key exchanges. While the proposed mechanism looks like an ingenious way to deal with legacy implementations and as a powerful tool to negotiate complex policies, I don't think it is ever needed, since all this can be done using existing mechanism. How it can be achieved: Let's define a bunch of new Transform Types each defining some kind of QSKE: Transform Type 6 - Lattice QSKE Transform Type 7 - Code-based QSKE Transform Type 8 - Isogeny-based QSKE Transform Type 9 - Symmetric QSKE ... Each of these Transform Types must then be populated with Transform IDs for QSKE of corresponding type. It is also important to add NONE into each of these types. The Initiator willing to combine QSKEs of specific types would include corresponding Transform Types populated with the Transform IDs the initiator deems acceptable. If NONE for some Transform Type is included, it means that this Transform Type is optional. IKEv2 requires the responder to select a combination of transforms such that a single Transform ID of each Transform Type is present. It means that the current SA payload syntax is able to represent the policies that the new negotiation mechanism in the draft is designed for. For example: SA: Proposal1: TransformType1: ENCR_AES_CBC TransformType2: PRF_HMAC_SHA2_256 TransformType3: AUTH_HMAC_SHA2_256_128 TransformType4: 2048-bit MODP Group Proposal2: TransformType1: ENCR_AES_CBC TransformType2: PRF_HMAC_SHA2_256 TransformType3: AUTH_HMAC_SHA2_256_128 TransformType4: 2048-bit MODP Group TransformType6: LatticeQSKE_2 TransformType6: CodebasedQSKE_1, CodebasedQSKE_2 Proposal3: TransformType1: ENCR_AES_CBC TransformType2: PRF_HMAC_SHA2_256 TransformType3: AUTH_HMAC_SHA2_256_128 TransformType4: 2048-bit MODP Group TransformType6: LatticeQSKE_1 TransformType6: LatticeQSKE_2, NONE TransformType6: IsogenybasedQSKE_1, IsogenybasedQSKE_2 In this example the Proposal1 is aimed for the legacy responders. Proposals means that the classic MODP_2048 group must be combined with LatticeQSKE_2 and either CodebasedQSKE_1 or CodebasedQSKE_2. Proposal3 means that the classic MODP_2048 group must be combined with either IsogenybasedQSKE_1 or IsogenybasedQSKE_2 and may optionally be combined with LatticeQSKE_2. Legacy responders would ignore Proposals 2 and 3 since they contain unknown Transform Type. However they would pick Proposal1. QSKE-enabled responders would select either Proposal 2 or 3 depending on their policy. Re-using existing mechanism is much easier to implement since the parsing code is already there, as well as the interface with the local policy. This mechanism is flexible enough to express the policies from the draft. It doesn't have a round trip penalty when communicating with legacy responder. It assumes that classic KE is always present, however I can see it as a feature, not as a disadvantage (see the next topic in the message). And in the future it will be possible to add QSKE mechanisms into Transform Type 4, provided their public key are small enough (and their security is proved, of course). In this case no classic KE is more needed. One disadvantage of using SA payload comparing with the new mechanism from the draft is that it is less compact and complex policies can lead to the situation when SA payload size will become too large. However, there is a draft describing compact representation of IKE payloads that allows to significantly decrease SA payload size (https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-compact/) One more consideration. I assume that existing implementations are conformant with RFC 7296, which states (Section 3.3.6): If the responder receives a proposal that contains a Transform Type it does not understand, or a proposal that is missing a mandatory Transform Type, it MUST consider this proposal unacceptable; however, other proposals in the same SA payload are processed as usual. There were a concerns that some implementations could incorrectly reject the whole SA payload if they encountered an unknown Transform Type. To deal with such (crippled) implementations one more round trip and an additional logic would be needed (if we decide to deal with them ever), but I think that it'll be no more complex than the negotiation mechanism from the draft. Am I missing something here? 2. Fragmentation I think that defining a new fragmentation mechanism for IKE_SA_INIT is bad choice. We already have IKE fragmentation and it is more appropriate to re-use existing mechanism. It is possible to do it in a way suggested by Tero: https://www.ietf.org/mail-archive/web/ipsec/current/msg11563.html I've published a draft defining auxiliary exchange for this purpose: https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-aux/ Comparing with a new fragmentation mechanism for IKE_SA_INIT defined in the draft, re-using the existing IKE fragmentation via an auxiliary exchange has the following advantages. - It is easier to implement. The IKE fragmentation is already supported by many vendors and it is easier to add a new simple exchange than to complicate IKE_SA_INIT, that is already quite complex. Note, that with the draft's proposal IKE_SESSION_RESUME exchange would need to be modified as well. With auxiliary exchanges resumption will be supported for free. - It is substantially more secure. The way the draft deals with fragmentation is susceptible to DoS attacks when an attacker injects bogus fragments poisoning reassembly buffer. Adding cookie to the fragments. as the draft suggests to prevent this attack, doesn't help at all: to inject bogus fragments an attacker need to know IKE SPIs, so he/she must be able to view messages from the peers, and if he/she is able to do it, then he/she will also know the cookie. So, the proposed defense never works. This attack is impossible with the standard IKE fragmentation unless an attacker is able to break key exchange in the IKE_SA_INIT in real time. I presume he/she would need QC for that and I hope by the time it is possible we'll already have some QC-proof key exchange with small public keys, so that it can be used in the IKE_SA_INIT and thwart the attack. - It is more robust. The problem with the approach suggested in the draft is that it works very poorly in case of packet loss, because all the fragments are sent simultaneously. If the number of fragments is small enough, then it doesn't cause major problems. However, as the number of fragment grows, single packet loss results in resending the whole bunch of fragments. If the packet loss is caused by congestion, then momentary resending all the fragments would result in more congestion, that would only make things worse. Standard IKE fragmentation is also susceptible to this problem, since it wasn't designed to deal with more than a handful fragments. This is no more true with QC-safe huge public keys. Ideally, each fragment should be acknowledged individually, however in is generally impossible with IKE request-reply paradigm (since reply fragments must also be acknowledged). Fortunately, using several auxiliary exchanges for transferring QC-safe public keys make it possible to at least make this problem less significant. The idea is to perform several QC-safe key exchanges utilizing large public keys one by one: HDR (IKE_SA_INIT, MID=0), SAi1, KEi, Ni, [N(AUX_EXCHANGE_SUPPORTED)] --> <-- HDR (IKE_SA_INIT, MID=0), SAr1, KEr, Nr, [N(AUX_EXCHANGE_SUPPORTED)] HDR (IKE_AUX, MID = 1), SK {QSKE1i} --> <-- HDR (IKE_AUX, MID = 1), SK { QSKE1ir} HDR (IKE_AUX, MID = 2), SK {QSKE2i} --> <-- HDR (IKE_AUX, MID = 2), SK { QSKE2ir} HDR (IKE_AUTH, MID = 3), SK {SA, TSi, TSr} --> <-- HDR (IKE_AUTH, MID = 3), SK { SA, TSi, TSr} So each of negotiated QSKEs is performed in a separate exchange, thus reducing the number of fragments in case it is fragmented. It is even possible to split any single QS key exchange in a several IKE_AUX exchanges if the exchange is DH-like, i.e. if public keys are of the same size and are generated independently. [Actually the same problem with reliable transferring of large number of fragments in case of QSKE will also arise in case of re-keying... There are several possible solutions, but I think they can be discussed separately.] So, I see no advantages of the new IKE_SA_INIT fragmentation mechanism over the re-using of existing one. Again, am I missing something here? 3. Large KE payloads The draft makes it possible to deal with public keys greater than 64K by means of a complex pointer-like system (integrated with proposed fragmentation mechanism). I think that it is too complex. I'd rather use simple approach, that is aligned with the re-using of standard IKE fragmentation described above. I propose that in case the public key is greater than 64K, it is split into several consecutive KE payloads in a single message. If several long public keys are present in the message, then all the payloads each key is split into must be grouped together. An example: HDR (IKE_AUX, MID = 1), SK {QSKE1i, QSKE1i, QSKE1i, QSKE2i, QSKE2i } --> <-- HDR (IKE_AUX, MID = 1), SK { QSKE1ir, QSKE1ir, QSKE1ir, QSKE2ir, QSKE2ir } Here we have 2 large public key in a single message, QSKEi1 is split into 3 payloads and QSKEi2 is split into 2 payloads. Actually, I don't think it is a good idea to send several large public keys in a single message given the problems outlined above, but it is a possible construction. A better way would be: HDR (IKE_AUX, MID = 1), SK {QSKE1i, QSKE1i, QSKE1i} --> <-- HDR (IKE_AUX, MID = 1), SK { QSKE1ir, QSKE1ir, QSKE1ir} HDR (IKE_AUX, MID = 2), SK {QSKE2i, QSKE2i} --> <-- HDR (IKE_AUX, MID = 2), SK { QSKE2ir, QSKE2ir} And even better way would be (provided the QSKEs are DH-like): HDR (IKE_AUX, MID = 1), SK {QSKE1i} --> <-- HDR (IKE_AUX, MID = 1), SK { QSKE1ir} HDR (IKE_AUX, MID = 2), SK {QSKE1i} --> <-- HDR (IKE_AUX, MID = 2), SK { QSKE1ir} HDR (IKE_AUX, MID = 3), SK {QSKE1i} --> <-- HDR (IKE_AUX, MID = 3), SK { QSKE1ir} HDR (IKE_AUX, MID = 4), SK {QSKE2i} --> <-- HDR (IKE_AUX, MID = 4), SK { QSKE2ir} HDR (IKE_AUX, MID = 5), SK {QSKE2i} --> <-- HDR (IKE_AUX, MID = 5), SK { QSKE2ir} [And I still hope that cryptographers won't leave us with only those QC safe key exchange methods that use huge public keys. I really don't want to transfer megabytes of keys just to create an SA to read my one hundred bytes long e-mail...] So, the bottom line. I think that the QSKE draft goes into wrong direction, suggesting over-complicated and insecure solutions and ignoring existing mechanisms that can be used instead. I hope the authors will re-consider this. Regards, Valery. From nobody Fri Feb 2 08:40:44 2018 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 1D40012D862 for ; Fri, 2 Feb 2018 08:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6Qcm1OByrey for ; Fri, 2 Feb 2018 08:40:40 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 0E68212D833 for ; Fri, 2 Feb 2018 08:40:39 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w12GeKQG000488 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 2 Feb 2018 18:40:20 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w12GeI03014572; Fri, 2 Feb 2018 18:40:18 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <23156.38002.598960.33674@fireball.acr.fi> Date: Fri, 2 Feb 2018 18:40:18 +0200 From: Tero Kivinen To: Yoav Nir Cc: RFC Errata System , charliekaufman@outlook.com, Paul Hoffman , nir.ietf@gmail.com, pe@iki.fi, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, david.waltermire@nist.gov, ipsec@ietf.org, andrew.cagney@gmail.com In-Reply-To: References: <20180130215039.EE475B80DE5@rfc-editor.org> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 16 min X-Total-Time: 16 min Archived-At: Subject: Re: [IPsec] [Editorial Errata Reported] RFC7296 (5247) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 16:40:43 -0000 Yoav Nir writes: > I don=E2=80=99t see anything wrong with the suggestion (it=E2=80=99s = just adding =E2=80=9Cto indicate NONE=E2=80=9D in the last > sentence). However: I think it is pointless change, and there is no need to give name for the number we use when we do not have protocol identifier, when it is used in exactly one place.=20 All the text about the IKEv2 Security Protocol Identifiers is wrong. There is no reference to the IANA registry in the Protocol ID fields in the Notify or Delete payloads. Only section 3.3.1 Proposal Substructure refers to the that IANA registry. The sections 3.10 Notify Payload and 3.11 Delete Payload enumerate all possible numbers for Protocol IDs in place, and those registries do not have IANA registry associated with them. Note, that we had discussion about the Protocol ID field of the Notify payload during the RFC5996 update. I.e. the RFC4306 said that the protocol ID for notifications concerning IKE SA was set to 1, and zero was used if the notification didn't concern any SA. It also had text saying rest of the values are left for IANA to allocate. In the RFC5996 update, text about IANA was removed, as was the text about notifications concerning IKE SA, i.e., the only valid values (0, 2, 3) were enumerated in place. I.e., it is not the same IANA registry that is used for the Propsal substructure anymore. Section 7.8 of the RFC4718 explains some of the resons behind the change.=20 > * A value marked =E2=80=9CReserved=E2=80=9D in IANA just means that= IANA should not assign it. It does not mean > that it cannot appear in the protocol. > * Using a zero in a field to indicate no value is common, and IANA = registries are inconsistent > about whether such zero values are named or just reserved. > * Unless we want to change the IANA registry, there is no reason to= uppercase =E2=80=98none=E2=80=99 > * I don=E2=80=99t think we need to update the IANA registry. As this IANA registry is not used here, there is no need to change it. If we ever want to add new protocol ID to Notify or Delete payloads, we most likely need to crete new IANA registry for them. > =E2=80=9CHold for document update=E2=80=9D=3F I think "rejected" would be better. > On 30 Jan 2018, at 23:50, RFC Errata System wrote: > =20 > The following errata report has been submitted for RFC7296, > "Internet Key Exchange Protocol Version 2 (IKEv2)". > =20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5247 > =20 > -------------------------------------- > Type: Editorial > Reported by: Andrew Cagney > =20 > Section: 3.10. > =20 > Original Text > ------------- > o Protocol ID (1 octet) - If this notification concerns an exi= sting > SA whose SPI is given in the SPI field, this field indicates= the > type of that SA. For notifications concerning Child SAs, th= is > field MUST contain either (2) to indicate AH or (3) to indic= ate > ESP. Of the notifications defined in this document, the SPI= is > included only with INVALID=5FSELECTORS, REKEY=5FSA, and > CHILD=5FSA=5FNOT=5FFOUND. If the SPI field is empty, this f= ield MUST be > sent as zero and MUST be ignored on receipt. > =20 > Corrected Text > -------------- > o Protocol ID (1 octet) - If this notification concerns an exi= sting > SA whose SPI is given in the SPI field, this field indicates= the > type of that SA. For notifications concerning Child SAs, th= is > field MUST contain either (2) to indicate AH or (3) to indic= ate > ESP. Of the notifications defined in this document, the SPI= is > included only with INVALID=5FSELECTORS, REKEY=5FSA, and > CHILD=5FSA=5FNOT=5FFOUND. If the SPI field is empty, this f= ield MUST be > sent as zero to indicate NONE and MUST be ignored on receipt= =2E > =20 > Notes > ----- > If I assume that the 'Protocol ID' field in the notification payl= oad is specified by: > =20 > Internet Key Exchange Version 2 (IKEv2) Parameters > IKEv2 Security Protocol Identifiers > =20 > then a notification is using the 'Reserved' value 0. Since the = value is being used, > I think it would be better to give it a name. Other uses of 'Pro= tocol ID' don't need > updating as they all explicitly list allowed values, and in no ca= se is 0 allowed. > =20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, ple= ase > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary= =2E > =20 > -------------------------------------- > RFC7296 (draft-kivinen-ipsecme-ikev2-rfc5996bis-04) > -------------------------------------- > Title : Internet Key Exchange Protocol Version 2 (I= KEv2) > Publication Date : October 2014 > Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, = T. Kivinen > Category : INTERNET STANDARD > Source : IP Security Maintenance and Extensions > Area : Security > Stream : IETF > Verifying Party : IESG > =20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 --=20 kivinen@iki.fi From nobody Tue Feb 6 05:30:03 2018 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 ED890129C6E; Tue, 6 Feb 2018 05:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4W0_HA5nQZn; Tue, 6 Feb 2018 05:30:00 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 5FD9B12DA6A; Tue, 6 Feb 2018 05:29:53 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w16DTlBg001202 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Feb 2018 15:29:47 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w16DTlEH019219; Tue, 6 Feb 2018 15:29:47 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23161.44491.871182.608585@fireball.acr.fi> Date: Tue, 6 Feb 2018 15:29:47 +0200 From: Tero Kivinen To: draft-ietf-ipsecme-split-dns@ietf.org CC: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 19 min X-Total-Time: 21 min Archived-At: Subject: [IPsec] Comments to the draft-ietf-ipsecme-split-dns-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 13:30:03 -0000 While approving the IANA allocations I re-read the document again, and I have some more comments that might make the document more understandable. -- In section 4.1 there is example of example.com, but it would be better to put quotes around it it, i.e., change A Fully Qualified Domain Name used for Split DNS rules, such as example.com, ... with A Fully Qualified Domain Name used for Split DNS rules, such as "example.com", ... as we do in the RFC7296 section 3.5 for ID_FQDN. -- In section 4.2 there is "Digest Type" in the figure, but the list has only item for "DS algorithm". Make those same. -- It is bit misleading to say that "Key Tag", "Algorithm", "DS algoritm" etc can either be 0 or 2/1/1 etc octets long. How does the receiver know what is going to be the length of the "Key Tag" value for example? I assume the intent has been to say that either all the fields are there with fixed lengths, or they are all omitted, meaning the length is 0 for all of them. The current section 4.2 does not clearly indicate that. I would propose following change: ---------------------------------------------------------------------- 4.2. INTERNAL_DNSSEC_TA Configuration Attribute 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-----------------------------+-------------------------------+ |R| Attribute Type | Length | +-+-----------------------------+---------------+---------------+ | | ~ DNSSEC Trust Anchor Data ~ | | +---------------------------------------------------------------+ o Reserved (1 bit) - Defined in IKEv2 RFC [RFC7296]. o Attribute Type (15 bits) [TBD IANA] - INTERNAL_DNSSEC_TA. o Length (2 octets, unsigned integer) - Length of DNSSEC Trust Anchor data. o DNSSEC Trust Anchor Data (0 or more octets) - Either empty or DNSSEC Trust Anchor data in format specified in the the [RFC4034] Section 5.1 (copied here for conveniency): 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+---------------+---------------+ | Key Tag | Algorithm | Digest Type | +-------------------------------+---------------+---------------+ | | ~ Digest ~ | | +---------------------------------------------------------------+ o Key Tag value (2 octets, unsigned integer) - Key Tag as specified in [RFC4034] Section 5.1 o Algorithm (1 octet) - DNSKEY algorithm value from the IANA DNS Security Algorithm Numbers Registry o Digest Type (1 octet) - DS algorithm value from the IANA Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms Registry o Digest (length specified by the Digest Type field octets) - The DNSKEY digest as specified in [RFC4034] Section 5.1 in presentation format. ---------------------------------------------------------------------- I.e., split the figure in two pieces, where first one just says we have the DS RDATA inside (or not in case of request and then the length is 0), and then explain the DS RDATA format after that... -- kivinen@iki.fi From nobody Tue Feb 6 08:18:09 2018 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 183C112D94A; Tue, 6 Feb 2018 08:18:02 -0800 (PST) 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.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151793388204.28166.3238541538218696189@ietfa.amsl.com> Date: Tue, 06 Feb 2018 08:18:02 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 16:18:02 -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-05.txt Pages : 11 Date : 2018-02-06 Abstract: This document defines two Configuration Payload Attribute Types for the IKEv2 protocol that add support for private DNS domains. These domains should 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". 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-split-dns-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-05 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 Tue Feb 6 08:21:33 2018 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 76CBF12D84B for ; Tue, 6 Feb 2018 08:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01, 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 vFAw0mO95HUZ for ; Tue, 6 Feb 2018 08:21:30 -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 E45C7127078 for ; Tue, 6 Feb 2018 08:21:29 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zbV872wtrz1cV; Tue, 6 Feb 2018 17:21:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1517934087; bh=Emd8ZsBfTvSjf5E/M/u4E9CqQvKLDcsDFCDwyDPYuYk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=kj9zmmU8O9HPKqOxQ7u9OyH4JBYCrRRNmJqxjJk24P6AJtTQ5Q829KpeMMwdDJM7b xWW1HwA1CwoDvn2I+biUCAPJ/F4MqIPz1g9BH0JXdaNNOAnjK+/7cwMlyYfjLJnOZS zlKO9q1pQ/Z8NxE+d+Tz1+TGJjvRKQnRZquG3jsE= 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 l29BNPSk2F8b; Tue, 6 Feb 2018 17:21: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; Tue, 6 Feb 2018 17:21:20 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 23EF630B3F6; Tue, 6 Feb 2018 11:21:19 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 23EF630B3F6 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 179BA4505806; Tue, 6 Feb 2018 11:21:19 -0500 (EST) Date: Tue, 6 Feb 2018 11:21:19 -0500 (EST) From: Paul Wouters To: Tero Kivinen , Tommy Pauly cc: "ipsec@ietf.org WG" In-Reply-To: <23161.44491.871182.608585@fireball.acr.fi> Message-ID: References: <23161.44491.871182.608585@fireball.acr.fi> 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] Comments to the draft-ietf-ipsecme-split-dns-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 16:21:32 -0000 On Tue, 6 Feb 2018, Tero Kivinen wrote: > While approving the IANA allocations I re-read the document again, and > I have some more comments that might make the document more > understandable. Thanks! > In section 4.1 there is example of example.com, but it would be better > to put quotes around it it Fixed in -05 > In section 4.2 there is "Digest Type" in the figure, but the > list has only item for "DS algorithm". Make those same. Fixed. > It is bit misleading to say that "Key Tag", "Algorithm", "DS algoritm" > etc can either be 0 or 2/1/1 etc octets long. How does the receiver > know what is going to be the length of the "Key Tag" value for > example? It was actually a mistake (partially induced by my memory of rfc-8078 work and its errata). Those fields are all fixed length. Only the digest itself is variable length, and as per 8078 errata, the shortest representation would be "00", so two octets. > I assume the intent has been to say that either all the fields are > there with fixed lengths, or they are all omitted, meaning the length > is 0 for all of them. That was not at all the intent :) I've submitted -05. My only question now is what to do with the length field of both records. It now says "2 octects, unsigned integer" but perhaps it should say "2 octets in network order" ? https://tools.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-05.txt Paul From nobody Tue Feb 6 09:34:59 2018 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 214B912D811; Tue, 6 Feb 2018 09:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t06h60qAWnCF; Tue, 6 Feb 2018 09:34:55 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 91A93127136; Tue, 6 Feb 2018 09:34:51 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w16HYkPQ002795 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Feb 2018 19:34:46 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w16HYkcq000019; Tue, 6 Feb 2018 19:34:46 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23161.59190.256739.684496@fireball.acr.fi> Date: Tue, 6 Feb 2018 19:34:46 +0200 From: Tero Kivinen To: draft-ietf-ipsecme-qr-ikev2@ietf.org CC: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 11 min X-Total-Time: 33 min Archived-At: Subject: [IPsec] Some comments to the draft-ietf-ipsecme-qr-ikev2-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 17:34:57 -0000 While approving the IANA expert request for this document I noticed some things that might require some fixes to the draft: -- In section 1.1 (which will be removed) there is typo in PPK_SUUPORT. -- In section 3 it would be better to use the same format than what is used in the RFC7296 when using notify payloads with data in it, i.e. replace N(PPK_IDENTITY)(PPK_ID) with N(PPK_IDENTITY, PPK_ID) (see example use in RFC7296 section 2.8.1 or RFC5685). -- In section 4 there is text saying: If the responder has not been upgraded and properly configured, they will both realize it, and in that case, the link will be quantum secure. I think there is something wrong with that. If the responder is not upgraded, then link will not be quantum safe. Same if it is not properly configured. I think it is trying to say that "If the responder has been upgraded and ..." -- In appendix A there is text saying: By limiting our changes to notifications, and translating the nonces, it is hoped that this would be implementable, even on systems that perform much of the IKEv2 processing is in hardware. I think the text "translating the nonces" is leftover from old design and should be changed to reflect the fact that this now changes the SK_d, SK_pi and SK_pr. -- kivinen@iki.fi From nobody Tue Feb 6 10:04:19 2018 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 9713D127241 for ; Tue, 6 Feb 2018 10:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 660ae5xtz58M for ; Tue, 6 Feb 2018 10:04:16 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 1FD4D1270AB for ; Tue, 6 Feb 2018 10:04:15 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w16I4BXc026251 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Feb 2018 20:04:11 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w16I4BI0006329; Tue, 6 Feb 2018 20:04:11 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23161.60955.207264.333654@fireball.acr.fi> Date: Tue, 6 Feb 2018 20:04:11 +0200 From: Tero Kivinen To: Paul Wouters Cc: Tommy Pauly , "ipsec\@ietf.org WG" In-Reply-To: References: <23161.44491.871182.608585@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 6 min Archived-At: Subject: Re: [IPsec] Comments to the draft-ietf-ipsecme-split-dns-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 18:04:17 -0000 Paul Wouters writes: > > It is bit misleading to say that "Key Tag", "Algorithm", "DS algoritm" > > etc can either be 0 or 2/1/1 etc octets long. How does the receiver > > know what is going to be the length of the "Key Tag" value for > > example? > > It was actually a mistake (partially induced by my memory of rfc-8078 > work and its errata). Those fields are all fixed length. Only the digest > itself is variable length, and as per 8078 errata, the shortest > representation would be "00", so two octets. That does not match the section 3. I.e., in section 3 you have examples and text saying that initiator will send empty INTERNAL_DNSSEC_TA attribute in CFG_REQUEST: To indicate support for DNSSEC, an initiator includes one or more INTERNAL_DNSSEC_TA attributes as defined in Section 4 as part of the CFG_REQUEST payload. If an INTERNAL_DNSSEC_TA attriute is included in the CFG_REQUEST, the initiator SHOULD also include one or more INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST. An initiator MAY convey its current DNSSEC trust anchors for the domain specified in the INTERNAL_DNS_DOMAIN attribute. If it does not wish to convey this information, it MUST use a length of 0. but this is not possible with current definition of the section 4.2, where the DNSKEY Key Tag etc fields are mandatory. Thats why my proposal was to make whole DNSSEC Trust Anchor Data optional. > > I assume the intent has been to say that either all the fields are > > there with fixed lengths, or they are all omitted, meaning the length > > is 0 for all of them. > > That was not at all the intent :) > > I've submitted -05. My only question now is what to do with the > length field of both records. It now says "2 octects, unsigned integer" > but perhaps it should say "2 octets in network order" ? In RFC7296 we have: All multi-octet fields representing integers are laid out in big endian order (also known as "most significant byte first", or "network byte order"). which covers everything. You could add similar text here... -- kivinen@iki.fi From nobody Tue Feb 6 10:16:11 2018 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 AFEA4127275 for ; Tue, 6 Feb 2018 10:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 idc5I1ad-1Qx for ; Tue, 6 Feb 2018 10:16:09 -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 D4D81126C25 for ; Tue, 6 Feb 2018 10:16:08 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zbXhN6sV5zDmW; Tue, 6 Feb 2018 19:16:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1517940964; bh=55/FdGb1rh0yDgAtw+/tGY3C7a/LVa8i+9lL4RQbd7I=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=NO2Vt20xERBV32AAkf/0HAFOSgJ8HaZVxhFKbIFc0Cs9GtwnpA4qijbyp+H6I4xJV mzo0eJevyJA9rvjV80cGQVp7MaosdkCzfg2BjTWVkoOEx/cGkmxpQAn7JZSMHQINxT ar/F6oQU1fUB+v9/4ynmaBDeAwyekXHAQMmb3vr0= 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 wqRAc9KLR0gA; Tue, 6 Feb 2018 19:16:03 +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; Tue, 6 Feb 2018 19:16:03 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id CDDE830B3F6; Tue, 6 Feb 2018 13:16:01 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca CDDE830B3F6 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C71B34505810; Tue, 6 Feb 2018 13:16:01 -0500 (EST) Date: Tue, 6 Feb 2018 13:16:01 -0500 (EST) From: Paul Wouters To: Tero Kivinen cc: Tommy Pauly , "ipsec@ietf.org WG" In-Reply-To: <23161.60955.207264.333654@fireball.acr.fi> Message-ID: References: <23161.44491.871182.608585@fireball.acr.fi> <23161.60955.207264.333654@fireball.acr.fi> 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] Comments to the draft-ietf-ipsecme-split-dns-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 18:16:11 -0000 On Tue, 6 Feb 2018, Tero Kivinen wrote: >> >> It was actually a mistake (partially induced by my memory of rfc-8078 >> work and its errata). Those fields are all fixed length. Only the digest >> itself is variable length, and as per 8078 errata, the shortest >> representation would be "00", so two octets. > > That does not match the section 3. > > I.e., in section 3 you have examples and text saying that initiator > will send empty INTERNAL_DNSSEC_TA attribute in CFG_REQUEST: > but this is not possible with current definition of the section 4.2, > where the DNSKEY Key Tag etc fields are mandatory. Thats why my > proposal was to make whole DNSSEC Trust Anchor Data optional. Riiight...I forgot about the CFG_REQUEST item. Ok, I will change it and list both versions in separate packet diagrams. >> I've submitted -05. My only question now is what to do with the >> length field of both records. It now says "2 octects, unsigned integer" >> but perhaps it should say "2 octets in network order" ? > > In RFC7296 we have: > > All multi-octet fields representing integers are laid out in big > endian order (also known as "most significant byte first", or > "network byte order"). > > which covers everything. You could add similar text here... Thanks, will do. Paul From nobody Tue Feb 6 10:30:06 2018 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 83C2E12D963 for ; Tue, 6 Feb 2018 10:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2pZgWwv1_0e for ; Tue, 6 Feb 2018 10:30:04 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 02BDD12D955 for ; Tue, 6 Feb 2018 10:30:03 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w16ITsNX020441 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Feb 2018 20:29:54 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w16ITs12014425; Tue, 6 Feb 2018 20:29:54 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23161.62498.200072.707799@fireball.acr.fi> Date: Tue, 6 Feb 2018 20:29:54 +0200 From: Tero Kivinen To: David Schinazi Cc: "ipsec\@ietf.org" In-Reply-To: <84472A32-CABA-4CFC-AA4D-BCAF070E9959@apple.com> References: <23054.29098.665202.402605@fireball.acr.fi> <787AE7BB302AE849A7480A190F8B93300A07C37A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <84472A32-CABA-4CFC-AA4D-BCAF070E9959@apple.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 1 min Archived-At: Subject: Re: [IPsec] Candidate charter text is now in wiki X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 18:30:06 -0000 David Schinazi writes: > Here is proposed charter text for the "Mitigating privacy concerns" > section: As there has not been any support for this item in the mailing list I do not think we will be adding it in the charter this time. > IKEv2 is currently vulnerable to the two following privacy concerns: > > 1) It's not possible to run a server that obfuscates IKEv2/IPsec > using TLS. Today thanks to RFC 8229 it is possible to run an > IKEv2/IPsec server on TCP port 443 with TLS. However if a > government agent tries to send an SA_INIT over that it will > discover that this server runs IKEv2/IPsec, and may blacklist > it. We should add a mechanism to IKEv2 that allows the server to > only respond to SA_INIT from known entities (e.g. that possess a > shared secret). > > 2) The privacy of the initiator's identity in the presence of a man > in the middle attacker is not protected Today an attacker with > full control of the network can receive the IDi/IDr sent by the > initiator in the first AUTH packet. We should add a mechanism to > IKEv2 that allows the initiator to only send IDi/IDr to known > entities (e.g. that possess a shared secret). -- kivinen@iki.fi From nobody Tue Feb 6 10:36:09 2018 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 301FF12D847 for ; Tue, 6 Feb 2018 10:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9s0OjOYPR4aZ for ; Tue, 6 Feb 2018 10:36:03 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 D2FDE127522 for ; Tue, 6 Feb 2018 10:36:02 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w16IZuNA010270 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Feb 2018 20:36:00 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w16IZpwB019608; Tue, 6 Feb 2018 20:35:51 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23161.62855.158031.367282@fireball.acr.fi> Date: Tue, 6 Feb 2018 20:35:51 +0200 From: Tero Kivinen To: Cc: "ipsec\@ietf.org" In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A07C37A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <23054.29098.665202.402605@fireball.acr.fi> <787AE7BB302AE849A7480A190F8B93300A07C37A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 5 min Archived-At: Subject: Re: [IPsec] Candidate charter text is now in wiki X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 18:36:07 -0000 mohamed.boucadair@orange.com writes: > It seems that you missed this text for the address failure codes (Nov 13): > https://www.ietf.org/mail-archive/web/ipsec/current/msg11724.html Yes, as I wanted to get some more discussion about it in the mailing list first. I have not seen any discussion about it since the IETF, so is there really enough interest for it. The charter in wiki only included items we discussed in the meeting. > I'm resending it fwiw: > > RFC7296 defines a generic notification code that is related to a > failure to handle an internal address failure. That code does not > explicitly allow an initiator to determine why a given address family > is not assigned, nor whether it should try using another address > family. The Working Group will specify a set of more specific > notification codes that will provide sufficient information to the > IKEv2 initiator about the encountered failure. -- kivinen@iki.fi From nobody Tue Feb 6 10:37:30 2018 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 D490E127077 for ; Tue, 6 Feb 2018 10:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiSO4PiIoB46 for ; Tue, 6 Feb 2018 10:37:27 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 8B8F512741D for ; Tue, 6 Feb 2018 10:37:27 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w16IbPIF002294 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Feb 2018 20:37:25 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w16IbPxg016853; Tue, 6 Feb 2018 20:37:25 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23161.62949.524062.825450@fireball.acr.fi> Date: Tue, 6 Feb 2018 20:37:25 +0200 From: Tero Kivinen To: Paul Wouters Cc: "ipsec\@ietf.org WG" In-Reply-To: References: 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] Labeled IPsec for charter X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 18:37:29 -0000 Paul Wouters writes: > > Some systems support security labels (aka security context) as one of the > selectors of the SPD. This label needs to be part of the IKE negotiation > for the IPsec SA. non-standard implementations exist for IKEv1 (formerly > abusing IPSEC Security Association Attribute 10, now using private space > IPSEC Security Association Attribute 32001). The work is to standarize > this for IKEv2. This charter item has also had no discussion since IETF, so I assume there is not much support for this either? -- kivinen@iki.fi From nobody Tue Feb 6 10:40:58 2018 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 C4DD8127599 for ; Tue, 6 Feb 2018 10:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 Wg9CioT5_xfk for ; Tue, 6 Feb 2018 10:40:55 -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 7E97D127077 for ; Tue, 6 Feb 2018 10:40:55 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zbYF15l0mzDmW; Tue, 6 Feb 2018 19:40:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1517942453; bh=fAd3d8bCxBSLADqGqUPPvNKKBTcEk+v0/AbEdKgyCns=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=oJRX3Bn0YwZssy5IY4rRojHaRrIlAPx0LcwThQcvq7RbETnbp4MRcMn6z+25GqcXS zYiKGem+c7OodyZL1jbQ5OPDLzM2pw/UZ0LbxdsiHXzgBH5YJbyqG95x7KBqp+2t07 UZfpbFwFvow+4R+v5BGrb5wNx/I+IXjYTX0/JZsU= 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 uBv8IKHir4zA; Tue, 6 Feb 2018 19:40:52 +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; Tue, 6 Feb 2018 19:40:52 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id BA03661CD5; Tue, 6 Feb 2018 13:40:51 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca BA03661CD5 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B345B4505806; Tue, 6 Feb 2018 13:40:51 -0500 (EST) Date: Tue, 6 Feb 2018 13:40:51 -0500 (EST) From: Paul Wouters To: Tero Kivinen cc: "ipsec@ietf.org WG" In-Reply-To: <23161.62949.524062.825450@fireball.acr.fi> Message-ID: References: <23161.62949.524062.825450@fireball.acr.fi> 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] Labeled IPsec for charter X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 18:40:57 -0000 On Tue, 6 Feb 2018, Tero Kivinen wrote: >> Some systems support security labels (aka security context) as one of the >> selectors of the SPD. This label needs to be part of the IKE negotiation >> for the IPsec SA. non-standard implementations exist for IKEv1 (formerly >> abusing IPSEC Security Association Attribute 10, now using private space >> IPSEC Security Association Attribute 32001). The work is to standarize >> this for IKEv2. > > This charter item has also had no discussion since IETF, so I assume > there is not much support for this either? I plan to submit a draft in time for the London meeting. Red Hat has a clear interest in this. Paul From nobody Tue Feb 6 23:41:32 2018 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 4905E1201FA; Tue, 6 Feb 2018 23:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.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_LOW=-0.7, 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 tOpeYM_6hG82; Tue, 6 Feb 2018 23:41:29 -0800 (PST) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5119C1200C1; Tue, 6 Feb 2018 23:41:29 -0800 (PST) Received: by mail-lf0-x22b.google.com with SMTP id a204so6451180lfa.2; Tue, 06 Feb 2018 23:41:29 -0800 (PST) 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=y68hDmTNgCm1+fZeguVBx0sm1upQit5JqMtWJDSbOYE=; b=mP62dm7tIXPhoyyK2qfvYd8O6eWcS5nTIn5FiA8+WgKewxbFIR2X8+crdO1KzTE5dk 1+CrCBtwKtKvXUXbpT5Qz9QiRGR43+hhwUw2qLKH2B8b05aQaz5NblUeyBp1pUaPnpF7 6yzYlFLjbOolf1Of4dQ0DsvBKbZWdW1ctWrN4PPSxbePCaoPvdULBpOCUzpMHjIkGFdH 4dmrdCN190uFwPAYp1IR+t6y8SRB1GGorqjq2ZW27ekpifo6UsVC9laqPn0QV3eFOGgO F9sYRWCROErGsuTwL0OVu6W0kjAcxgn0kan1UIEcGBQLJ848ztVe+hfMqmneaM7mE48f Eg/g== 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=y68hDmTNgCm1+fZeguVBx0sm1upQit5JqMtWJDSbOYE=; b=YLlmGBtTK+whV5Dc8NqM4UHAGJl+aT3Ux8YmJT+M3guhSc7V0qdbJbSHfTKdbl29lr pLXC7Pjr2FVQC0cu9A0WKJdEoGcK/qT9tlZAGpLopm+YLNssclUSu0deHDux7K4uqMZX RRUlPlNQAKQT8cGxEk3ft+ZQul13jXIIz+ibeZHybZZzHRs14Xz9kNhYQudME4H+31VZ 6O1+JIz2PzH3gElf4RfzX/3/5alWCDzKpRUUxpoi56ll07RLyYlwQfEBMHTLRWDj3OeY AP5tgalmsYbufg0CMSVEme9CYYxm1MBvK4+nGB3AY/+zCz3l4RuFV/oXB6dr2QTcMPrZ Ao8g== X-Gm-Message-State: APf1xPANfKOPCVYibS16i2cG2hmr69Dx3+QyRkcyuLn0/U0Pg0F47fxn zXAgBPLvCDW3B8gCkr1kdYU6+A== X-Google-Smtp-Source: AH8x227Zz40RqWdiBPB2BMMqrh72yiWVTMOVCE1eHOQWDB2ab9MQnDCxkNjWISBrAzpk/KI7JinV7A== X-Received: by 10.25.193.204 with SMTP id r195mr3582973lff.37.1517989287295; Tue, 06 Feb 2018 23:41:27 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id r132sm193642lfe.9.2018.02.06.23.41.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 06 Feb 2018 23:41:26 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" , Cc: References: <23161.59190.256739.684496@fireball.acr.fi> In-Reply-To: <23161.59190.256739.684496@fireball.acr.fi> Date: Wed, 7 Feb 2018 10:41:30 +0300 Message-ID: <06f101d39fe7$122a2510$367e6f30$@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: AQFXTNySIUYc4nTAbmWzAAQaPUqdraSRM2Hg Content-Language: ru Archived-At: Subject: Re: [IPsec] Some comments to the draft-ietf-ipsecme-qr-ikev2-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 07:41:31 -0000 Hi Tero, thank you for the found typos and leftovers. We'll fix them in the next version (there are also a couple clarifications that we want to add to the document). Regards, Valery. > While approving the IANA expert request for this document I noticed > some things that might require some fixes to the draft: > > -- > > In section 1.1 (which will be removed) there is typo in PPK_SUUPORT. > > -- > > In section 3 it would be better to use the same format than what is > used in the RFC7296 when using notify payloads with data in it, i.e. > replace > > N(PPK_IDENTITY)(PPK_ID) > > with > > N(PPK_IDENTITY, PPK_ID) > > (see example use in RFC7296 section 2.8.1 or RFC5685). > > -- > > In section 4 there is text saying: > > If the responder has not been upgraded and properly configured, > they will both realize it, and in that case, the link will be > quantum secure. > > I think there is something wrong with that. If the responder is not > upgraded, then link will not be quantum safe. Same if it is not > properly configured. I think it is trying to say that "If the > responder has been upgraded and ..." > > -- > > In appendix A there is text saying: > > By limiting our changes to notifications, and translating the > nonces, it is hoped that this would be implementable, even on > systems that perform much of the IKEv2 processing is in hardware. > > I think the text "translating the nonces" is leftover from old design > and should be changed to reflect the fact that this now changes the > SK_d, SK_pi and SK_pr. > > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Feb 6 23:48:51 2018 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 458811201FA for ; Tue, 6 Feb 2018 23:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kXfnvU0bRYw for ; Tue, 6 Feb 2018 23:48:48 -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 9B5C71200C1 for ; Tue, 6 Feb 2018 23:48:48 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 50F90A0CC2; Wed, 7 Feb 2018 08:48:47 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 3349020067; Wed, 7 Feb 2018 08:48:47 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0382.000; Wed, 7 Feb 2018 08:48:46 +0100 From: To: Tero Kivinen CC: "ipsec@ietf.org" Thread-Topic: [IPsec] Candidate charter text is now in wiki Thread-Index: AQHTX2PY1LVxwKS2jUO3yJx92UH7bqMYHZYQgIAFf4CAAOrTYA== Date: Wed, 7 Feb 2018 07:48:46 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0CC90D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <23054.29098.665202.402605@fireball.acr.fi> <787AE7BB302AE849A7480A190F8B93300A07C37A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <23161.62855.158031.367282@fireball.acr.fi> In-Reply-To: <23161.62855.158031.367282@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.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Candidate charter text is now in wiki X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 07:48:50 -0000 Hi Tero,=20 Thank you for the update. I was naively expecting a formal call to assess the interest/objections for= each of the proposed items. Perhaps, I'm not the only one in that case. I have one "logistic" question: if this proposed item is not included in th= e charter, does this mean that I can proceed with the code points assignmen= t request (https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ip= v4-codes/) with IANA and the codes will be assigned? For the record, the on= ly comments I received were from Paul (thanks), and an updated version of t= he draft that addresses those comments was released. Cheers, Med > -----Message d'origine----- > De=A0: Tero Kivinen [mailto:kivinen@iki.fi] > Envoy=E9=A0: mardi 6 f=E9vrier 2018 19:36 > =C0=A0: BOUCADAIR Mohamed IMT/OLN > Cc=A0: ipsec@ietf.org > Objet=A0: RE: [IPsec] Candidate charter text is now in wiki >=20 > mohamed.boucadair@orange.com writes: > > It seems that you missed this text for the address failure codes (Nov 1= 3): > > https://www.ietf.org/mail-archive/web/ipsec/current/msg11724.html >=20 > Yes, as I wanted to get some more discussion about it in the mailing > list first. I have not seen any discussion about it since the IETF, so > is there really enough interest for it. The charter in wiki only > included items we discussed in the meeting. >=20 > > I'm resending it fwiw: > > > > RFC7296 defines a generic notification code that is related to a > > failure to handle an internal address failure. That code does not > > explicitly allow an initiator to determine why a given address famil= y > > is not assigned, nor whether it should try using another address > > family. The Working Group will specify a set of more specific > > notification codes that will provide sufficient information to the > > IKEv2 initiator about the encountered failure. > -- > kivinen@iki.fi From nobody Wed Feb 7 02:05:09 2018 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 A683F126CC7 for ; Wed, 7 Feb 2018 02:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rT5vdiTyPGV1 for ; Wed, 7 Feb 2018 02:05:05 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 124BD1243F3 for ; Wed, 7 Feb 2018 02:05:04 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w17A4vmU025282 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Feb 2018 12:04:57 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w17A4vQY024098; Wed, 7 Feb 2018 12:04:57 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23162.53065.405334.393026@fireball.acr.fi> Date: Wed, 7 Feb 2018 12:04:57 +0200 From: Tero Kivinen To: Cc: "ipsec\@ietf.org" In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0CC90D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <23054.29098.665202.402605@fireball.acr.fi> <787AE7BB302AE849A7480A190F8B93300A07C37A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <23161.62855.158031.367282@fireball.acr.fi> <787AE7BB302AE849A7480A190F8B93300A0CC90D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 33 min Archived-At: Subject: Re: [IPsec] Candidate charter text is now in wiki X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 10:05:08 -0000 mohamed.boucadair@orange.com writes: > I was naively expecting a formal call to assess the > interest/objections for each of the proposed items. Perhaps, I'm not > the only one in that case. That could have been another possibility, but as I was so busy between the last IETF and now, I didn't have time to do it. On the other hand if there would have been lots of people really interested in the work they might have already commented on the text... > I have one "logistic" question: if this proposed item is not > included in the charter, does this mean that I can proceed with the > code points assignment request > (https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-codes/) > with IANA and the codes will be assigned? For the record, the only > comments I received were from Paul (thanks), and an updated version > of the draft that addresses those comments was released. It depends. If we do not take the item as official working group chartered item, there are still few different options. You can either get it processed as AD sponsored draft, or you can go individual submission track. To get the IANA numbers is separate from that as those numbers are allocated by expert review. Anyways lets see if there are other people interested to taking this item as charter item or not. -- kivinen@iki.fi From nobody Wed Feb 7 02:09:18 2018 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 B5662126DC2 for ; Wed, 7 Feb 2018 02:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sxu_QvAp1fUH for ; Wed, 7 Feb 2018 02:09:11 -0800 (PST) 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 2601C126CC7 for ; Wed, 7 Feb 2018 02:09:11 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 9FF87160C63; Wed, 7 Feb 2018 11:09:09 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.10]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 12F588007A; Wed, 7 Feb 2018 11:09:09 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0382.000; Wed, 7 Feb 2018 11:09:08 +0100 From: To: Tero Kivinen CC: "ipsec@ietf.org" Thread-Topic: [IPsec] Candidate charter text is now in wiki Thread-Index: AQHTX2PY1LVxwKS2jUO3yJx92UH7bqMYHZYQgIAFf4CAAOrTYIAAGMOAgAAREsA= Date: Wed, 7 Feb 2018 10:09:08 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0CCA53@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <23054.29098.665202.402605@fireball.acr.fi> <787AE7BB302AE849A7480A190F8B93300A07C37A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <23161.62855.158031.367282@fireball.acr.fi> <787AE7BB302AE849A7480A190F8B93300A0CC90D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <23162.53065.405334.393026@fireball.acr.fi> In-Reply-To: <23162.53065.405334.393026@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.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Candidate charter text is now in wiki X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 10:09:18 -0000 Re-, Fair enough. Would it be possible to issue formal calls for each of the proposed items s= o that (hopefully) we get more feedback (support/objection)?=20 Thank you. Cheers, Med > -----Message d'origine----- > De=A0: IPsec [mailto:ipsec-bounces@ietf.org] De la part de Tero Kivinen > Envoy=E9=A0: mercredi 7 f=E9vrier 2018 11:05 > =C0=A0: BOUCADAIR Mohamed IMT/OLN > Cc=A0: ipsec@ietf.org > Objet=A0: Re: [IPsec] Candidate charter text is now in wiki >=20 > mohamed.boucadair@orange.com writes: > > I was naively expecting a formal call to assess the > > interest/objections for each of the proposed items. Perhaps, I'm not > > the only one in that case. >=20 > That could have been another possibility, but as I was so busy between > the last IETF and now, I didn't have time to do it. On the other hand > if there would have been lots of people really interested in the work > they might have already commented on the text... >=20 > > I have one "logistic" question: if this proposed item is not > > included in the charter, does this mean that I can proceed with the > > code points assignment request > > (https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-cod= es/) > > with IANA and the codes will be assigned? For the record, the only > > comments I received were from Paul (thanks), and an updated version > > of the draft that addresses those comments was released. >=20 > It depends. If we do not take the item as official working group > chartered item, there are still few different options. You can either > get it processed as AD sponsored draft, or you can go individual > submission track. >=20 > To get the IANA numbers is separate from that as those numbers are > allocated by expert review. >=20 > Anyways lets see if there are other people interested to taking this > item as charter item or not. > -- > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Feb 7 12:30:11 2018 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 A6BCB1275AB for ; Wed, 7 Feb 2018 12:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 NL6mmCJydyup for ; Wed, 7 Feb 2018 12:30:07 -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 AD267126D05 for ; Wed, 7 Feb 2018 12:30:07 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zcCcW6QZvz77f for ; Wed, 7 Feb 2018 21:30:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1518035403; bh=/lF+ZNSH8TzUvndEC0HHaP3zaO7RTUXKdDbKQsUprEg=; h=Date:From:To:Subject; b=W3Zx0OIDS6ySG6lUW9Umfd71g3/GxBvvCT/wuso0pOgnUGTxNhzw8EO7Dy0zTjbAp Vt++Oa16Pd8Hx6MS1wyUIPT5EHHREHRK/gFRzoY1Enrb4V1g6d4wAzv/VUyZw9eDM9 JNCo1d+t+mrEr20POX/OEaArXnYo+5lNIZ6WJEgk= 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 gBa5LyoV7tEj for ; Wed, 7 Feb 2018 21:30:02 +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 ; Wed, 7 Feb 2018 21:30:02 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E613230B3F6; Wed, 7 Feb 2018 15:30:00 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca E613230B3F6 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DD59A4023308 for ; Wed, 7 Feb 2018 15:30:00 -0500 (EST) Date: Wed, 7 Feb 2018 15:30:00 -0500 (EST) 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=US-ASCII; format=flowed Archived-At: Subject: [IPsec] vpn-ppk.nohats.ca upgraded to draft-ietf-ipsecme-qr-ikev2-01 with IANA code points X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 20:30:10 -0000 Tero assigned the Eerly Code Points for the PPK values. Thanks! We have updated our code to use these, so if you are doing interop testing with vpn-ppk-nohats.ca, use the new allocations: 16435 USE_PPK [draft-ietf-ipsecme-qr-ikev2] 16436 PPK_IDENTITY [draft-ietf-ipsecme-qr-ikev2] 16437 NO_PPK_AUTH [draft-ietf-ipsecme-qr-ikev2] If you want to test certificate (RSA) based authentication using PPK, let me know and I can give you a PKCS#12 to do PPK with RSA. Paul ---------- Forwarded message ---------- Date: Thu, 11 Jan 2018 00:58:45 From: Paul Wouters Cc: 'Vukasin Karadzic' To: Valery Smyslov Subject: vpn-ppk.nohats.ca upgraded to draft-ietf-ipsecme-qr-ikev2-01 It uses the same information as before: server: vpn-ppk.nohats.ca server id ID_FQDN: vpn-ppk.nohats.ca local id (group id): GroupPPK1 PSK: SecretPSK PPK ID: PPKID1 PPK: NotQuantumSafe Please test with the correct PPK ID and the wrong PPK ID (for NO_PPK_AUTH) Currently, our initiator code seems to have a bug in the NO_PPK_AUTH case where it ends up with a different SKEYSEED. We are still investigating. If the draft has no bug, and your client has no bug, then the NO_PPK_AUTH should work for you :) Paul From nobody Thu Feb 8 16:41:21 2018 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 2216E127011 for ; Thu, 8 Feb 2018 16:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=post-quantum-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TA_wgv3p73M for ; Thu, 8 Feb 2018 16:41:16 -0800 (PST) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD7512DA22 for ; Thu, 8 Feb 2018 16:41:16 -0800 (PST) Received: by mail-ot0-x22d.google.com with SMTP id s4so6115337oth.7 for ; Thu, 08 Feb 2018 16:41:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=post-quantum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vJ8U3N5pSMzifXVgxuOB6LhzjZlFoFTWQb6hB+ZBwZU=; b=FDd3I+9l5b04yQqV/g0o4wQRdMSHezF9OOg1Q/wpIy61SA6NfWQFzLwBO8OJe9hDaH ss5YD0S5cFc8NlLUIoXnwyKRE4vg9MR6ABA63DUwezsPumUKnKl+97xle4hdfvssjuTX 11oZbn8lNdJPdqs9YMVeU8CDfiXkj/od99LRyby2AbD6L35G2ud1IDAEDQq8EEKu8qTZ gdWtNttD6m2Fig2JkN8XPAqRNjwcuH0XOvPItxGmnIN1DEHHbZiVx98zFrCAtSmpxKUD rTEI7Ub/7ezadmoFCY70YwYScu0WaIAsa1/oo6bAy1M+jBLv+dvOd2JEL+xZFOBLnaCr 0QVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vJ8U3N5pSMzifXVgxuOB6LhzjZlFoFTWQb6hB+ZBwZU=; b=ayf3EkK/3pOUUEp7py6in6dWqctFqX2HD9t9vmVnGTnXOAKp3V1wqS36QJjUBWcI5M 0y8ueObaAxkynCA35fsJWvgI5s2kUwLi3nlqPFL5qiKJ1eZbNGUvNeRBQmmtGmtdi+fi PveE+LD7ATifTq7QXU/YjsoD2kSdQVPn1as8OtK8dTOnPU6wXgdIDOY2Xc4unzwvDpTA Ujj2f10TJjDpqlRal4CyYgKKUmBrwUosBBuDwH+i2/E9dVNm6KpYttI4gF8IJBG6XVqF KVO4Uzr2bV9txFRzFp9Ij6zRu4ZiUsPO5ftDEAZf6UNRUqG+6R8C/S3pjE5VbTmrEQ1o gthg== X-Gm-Message-State: APf1xPCUe2j52N+o9vc1urEph8YeHqYlp7nL1LogM1X7X83NgrIrB50h qcOeON3HuO2UlyOTrxTI9atbC6p5hm2Sx3gC/w2S0WrfysE= X-Google-Smtp-Source: AH8x226ISruqU3pmGozvK93HvbnsEDfeEhtVYgz8veJbeS79D/cSKykg4evYh/7rPFXIfSBl/M+QHuA3yfdnjbueSlY= X-Received: by 10.157.48.81 with SMTP id w17mr790404otd.283.1518136875415; Thu, 08 Feb 2018 16:41:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.13.20 with HTTP; Thu, 8 Feb 2018 16:41:14 -0800 (PST) In-Reply-To: <033701d39b5d$bf7f2140$3e7d63c0$@gmail.com> References: <033701d39b5d$bf7f2140$3e7d63c0$@gmail.com> From: CJ Tjhai Date: Fri, 9 Feb 2018 00:41:14 +0000 Message-ID: To: Valery Smyslov Cc: ipsec@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [IPsec] draft-tjhai-ipsecme-hybrid-qske-ikev2-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 00:41:20 -0000 Hi Valery, Many thanks for your email and also your interest in our draft. As we explain in detail below, we don't agree with your conclusion that our proposal is overcomplicated, does not take into account what is out there, and insecure. Even if some of the features that we introduce deviate from standard operation, we did so after checking with clients and vendors. One of the features that they are keen on is the possibility of reusing KE payload to negotiate hybrid post-quantum groups or proposals. Please find below our response regarding the points you made. 1. Negotiation We are glad to see that you also appreciate the need to negotiate a hybrid group. As you may remember, we introduced a new Transform Type in our version 00 of our draft and it had not been well-received in IETF 99 Prague. We accept this push-back and it makes sense; since the introduction of IKEv2, there has not been any new Transform Type introduced. In fact, after IETF 99 Prague, we found out that there exists IKEv2 implementations out there that will error out if they receive an unknown Transform Type. As you pointed out, according to RFC 7296, if a responder receives a proposal with Transform Type that it doesn't understand, it MUST reject the proposal. However, we found that this is not true in practice. StrongSwan is a good example; consider you have two peers running StrongSwan where the initiator introduces a proposal containing a new Transform Type: SA: Proposal 1: Transform Type 1: ENCR_AES_CBC Transform Type 2: PRF_HMAC_SHA2_256 Transform Type 3: AUTH_HMAC_SHA2_256_128 Transform Type 4: P-256 Transform Type 6: New Transform Type Proposal 2: Transform Type 1: ENCR_AES_CBC Transform Type 2: PRF_HMAC_SHA2_256 Transform Type 3: AUTH_HMAC_SHA2_256_128 Transform Type 4: MODP-3072 It is assumed that the responder runs StrongSwan implementing standard RFC 7296, hence it does not understand Transform Type 6. Instead of rejecting Proposal 1 and considering Proposal 2, the responder ignores Transform Type 6 (i.e. selecting ENCR_AES_CBC, PRF_HMAC_SHA2_256, AUTH_HMAC_SHA2_256_128, P-256). The initiator clearly does not propose this proposal. This particular case would only be okay if Proposal 2 offers P-256. This is one particular implementation peculiarity, there will be others that behaves oddly. The point is, if we introduce a new Transform Type, it is very likely that backward compatibility can no longer be achieved. Hence, we pick a DH group that denotes a hybrid group and negotiate it using the existing KE payload. On your email, you also mentioned that in the future, we could use KE payload to carry small PQ KE payload. Then, some logic is required to distinguish what is carried in IKE_SA_INIT and what is carried in IKE_AUX; it looks messy. 2. Fragmentation We remember that Tero did suggest to use an intermediary exchange between IKE_SA_INIT and IKE_AUTH. However, after soliciting inputs from a number of parties (both vendors and clients), it appeared that the majority didn't like the idea of having this extra exchange as introduced a considerable deviation from standard IKEv2 flow and felt that we would just be introducing an IKE_SA_INIT fragmentation which could be achieved by other mechanisms. While IKE_AUX would be useful in environment where network is lossy, we also need to consider the requirements for applications such as VPN concentrator where connection rate is important, or peers that have a considerable route trip time. We acknowledge that we have not included any mechanisms to deal with loss packets in version 01 of our draft. This is intentional as we would like to get the WG input on which direction we should take our draft before going deeper. In terms of DoS attacks, we do not mandate the use of cookie mechanism, but when implemented, the responder can check that incoming messages corresponding to the second round of our protocol (note that this is the expensive round in which public-key operations are performed and space is allocated) have been agreed previously in a first round of the protocol. We also believe that your comment that what you propose is substantially more secure is not true. An attacker who can monitor exchange of messages and inject packets, can trivially DoS a connection (e.g. when the initiator sends the initial "HDR, SAi1, KEi, Ni", the attacker immediately responds with a "HDR, SAr1, KEr, Nr" of his choosing before the real responder does). An attacker who can modify the initial packets is not detected until later in the exchange. Of course, this could require a significant amount of resource allocation for post-quantum public data exchange. In our approach, we could detect it before IKE_AUTH phase. 3. Large payload We also hope that we don't end up having PQC ciphers with large public-key. We don't mandate our proposed draft to support payloads larger than 64KB. In fact, it is an added bonus of how we do fragmentation. Best regards, Authors of draft-tjhai-ipsecme-hybrid-qske-ikev2-01 On 1 February 2018 at 13:08, Valery Smyslov wrote: > Hi, this is a long message... > > I've looked through the -01 version of the QSKE draft. The draft has been expanded > and now it covers such aspects as QSKE negotiation, fragmentation and transferring > of payloads larger than 64K. I didn't review the draft in details, however after reading > I have concerns over the technical solutions the draft proposes. In particular, I think that > the problems of negotiation, fragmentation and representation of large payloads > could be solved better. > > 1. Negotiation. > > The draft introduces a new negotiation mechanism to be used explicitly with > multiple QS key exchanges. While the proposed mechanism looks like an ingenious > way to deal with legacy implementations and as a powerful tool to negotiate > complex policies, I don't think it is ever needed, since all this can be done > using existing mechanism. How it can be achieved: > > Let's define a bunch of new Transform Types each defining some kind of QSKE: > > Transform Type 6 - Lattice QSKE > Transform Type 7 - Code-based QSKE > Transform Type 8 - Isogeny-based QSKE > Transform Type 9 - Symmetric QSKE > ... > > Each of these Transform Types must then be populated with Transform IDs > for QSKE of corresponding type. It is also important to add NONE into each of these > types. The Initiator willing to combine QSKEs of specific types would include > corresponding Transform Types populated with the Transform IDs the initiator > deems acceptable. If NONE for some Transform Type is included, it means > that this Transform Type is optional. IKEv2 requires the responder to select > a combination of transforms such that a single Transform ID of each Transform Type > is present. It means that the current SA payload syntax is able to represent the policies > that the new negotiation mechanism in the draft is designed for. For example: > > SA: > Proposal1: > TransformType1: ENCR_AES_CBC > TransformType2: PRF_HMAC_SHA2_256 > TransformType3: AUTH_HMAC_SHA2_256_128 > TransformType4: 2048-bit MODP Group > Proposal2: > TransformType1: ENCR_AES_CBC > TransformType2: PRF_HMAC_SHA2_256 > TransformType3: AUTH_HMAC_SHA2_256_128 > TransformType4: 2048-bit MODP Group > TransformType6: LatticeQSKE_2 > TransformType6: CodebasedQSKE_1, CodebasedQSKE_2 > Proposal3: > TransformType1: ENCR_AES_CBC > TransformType2: PRF_HMAC_SHA2_256 > TransformType3: AUTH_HMAC_SHA2_256_128 > TransformType4: 2048-bit MODP Group > TransformType6: LatticeQSKE_1 > TransformType6: LatticeQSKE_2, NONE > TransformType6: IsogenybasedQSKE_1, IsogenybasedQSKE_2 > > In this example the Proposal1 is aimed for the legacy responders. > Proposals means that the classic MODP_2048 group > must be combined with LatticeQSKE_2 and either CodebasedQSKE_1 or > CodebasedQSKE_2. Proposal3 means that the classic MODP_2048 group must be > combined with either IsogenybasedQSKE_1 or IsogenybasedQSKE_2 and may optionally > be combined with LatticeQSKE_2. > > Legacy responders would ignore Proposals 2 and 3 since they contain > unknown Transform Type. However they would pick Proposal1. > QSKE-enabled responders would select either Proposal 2 or 3 depending > on their policy. > > Re-using existing mechanism is much easier to implement since the parsing > code is already there, as well as the interface with the local policy. > This mechanism is flexible enough to express the policies from the draft. > It doesn't have a round trip penalty when communicating with legacy > responder. It assumes that classic KE is always present, however I can > see it as a feature, not as a disadvantage (see the next topic in the message). > And in the future it will be possible to add QSKE mechanisms into Transform Type 4, > provided their public key are small enough (and their security is proved, of course). > In this case no classic KE is more needed. > > One disadvantage of using SA payload comparing with the new mechanism from > the draft is that it is less compact and complex policies can lead to the situation > when SA payload size will become too large. However, there is a draft describing compact > representation of IKE payloads that allows to significantly decrease SA payload size > (https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-compact/) > > One more consideration. I assume that existing implementations are conformant with > RFC 7296, which states (Section 3.3.6): > > If the responder receives a proposal that contains a Transform Type > it does not understand, or a proposal that is missing a mandatory > Transform Type, it MUST consider this proposal unacceptable; however, > other proposals in the same SA payload are processed as usual. > > There were a concerns that some implementations could incorrectly > reject the whole SA payload if they encountered an unknown Transform Type. > To deal with such (crippled) implementations one more round trip and an > additional logic would be needed (if we decide to deal with them ever), > but I think that it'll be no more complex than the negotiation mechanism from > the draft. > > Am I missing something here? > > 2. Fragmentation > > I think that defining a new fragmentation mechanism for IKE_SA_INIT is bad choice. > We already have IKE fragmentation and it is more appropriate to re-use > existing mechanism. It is possible to do it in a way suggested by Tero: > https://www.ietf.org/mail-archive/web/ipsec/current/msg11563.html > I've published a draft defining auxiliary exchange for this purpose: > https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-aux/ > > Comparing with a new fragmentation mechanism for IKE_SA_INIT defined in the draft, > re-using the existing IKE fragmentation via an auxiliary exchange has the following advantages. > > - It is easier to implement. The IKE fragmentation is already supported by many vendors > and it is easier to add a new simple exchange than to complicate IKE_SA_INIT, that is already > quite complex. Note, that with the draft's proposal IKE_SESSION_RESUME exchange would > need to be modified as well. With auxiliary exchanges resumption will be supported for free. > > - It is substantially more secure. The way the draft deals with fragmentation is susceptible to DoS > attacks when an attacker injects bogus fragments poisoning reassembly buffer. Adding > cookie to the fragments. as the draft suggests to prevent this attack, doesn't help at all: > to inject bogus fragments an attacker need to know IKE SPIs, so he/she must be able > to view messages from the peers, and if he/she is able to do it, then he/she will also > know the cookie. So, the proposed defense never works. This attack is impossible > with the standard IKE fragmentation unless an attacker is able to break key exchange > in the IKE_SA_INIT in real time. I presume he/she would need QC for that and I hope > by the time it is possible we'll already have some QC-proof key exchange with small > public keys, so that it can be used in the IKE_SA_INIT and thwart the attack. > > - It is more robust. The problem with the approach suggested in the draft is that it > works very poorly in case of packet loss, because all the fragments are sent simultaneously. > If the number of fragments is small enough, then it doesn't cause major problems. > However, as the number of fragment grows, single packet loss results in resending > the whole bunch of fragments. If the packet loss is caused by congestion, then > momentary resending all the fragments would result in more congestion, that > would only make things worse. Standard IKE fragmentation is also susceptible > to this problem, since it wasn't designed to deal with more than a handful fragments. > This is no more true with QC-safe huge public keys. Ideally, each fragment > should be acknowledged individually, however in is generally impossible with IKE > request-reply paradigm (since reply fragments must also be acknowledged). > Fortunately, using several auxiliary exchanges for transferring QC-safe public keys > make it possible to at least make this problem less significant. The idea is > to perform several QC-safe key exchanges utilizing large public keys one by one: > > HDR (IKE_SA_INIT, MID=0), SAi1, KEi, Ni, > [N(AUX_EXCHANGE_SUPPORTED)] --> > <-- HDR (IKE_SA_INIT, MID=0), SAr1, KEr, Nr, > [N(AUX_EXCHANGE_SUPPORTED)] > > HDR (IKE_AUX, MID = 1), SK {QSKE1i} --> > <-- HDR (IKE_AUX, MID = 1), SK { QSKE1ir} > > HDR (IKE_AUX, MID = 2), SK {QSKE2i} --> > <-- HDR (IKE_AUX, MID = 2), SK { QSKE2ir} > > HDR (IKE_AUTH, MID = 3), SK {SA, TSi, TSr} --> > <-- HDR (IKE_AUTH, MID = 3), SK { SA, TSi, TSr} > > So each of negotiated QSKEs is performed in a separate exchange, > thus reducing the number of fragments in case it is fragmented. > It is even possible to split any single QS key exchange in a several > IKE_AUX exchanges if the exchange is DH-like, i.e. if public keys are > of the same size and are generated independently. > > [Actually the same problem with reliable transferring of large number > of fragments in case of QSKE will also arise in case of re-keying... > There are several possible solutions, but I think they can be discussed > separately.] > > So, I see no advantages of the new IKE_SA_INIT fragmentation mechanism > over the re-using of existing one. Again, am I missing something here? > > 3. Large KE payloads > > The draft makes it possible to deal with public keys greater than 64K > by means of a complex pointer-like system (integrated with proposed > fragmentation mechanism). I think that it is too complex. I'd rather > use simple approach, that is aligned with the re-using of standard > IKE fragmentation described above. > > I propose that in case the public key is greater than 64K, it is > split into several consecutive KE payloads in a single message. > If several long public keys are present in the message, then > all the payloads each key is split into must be grouped together. > An example: > > HDR (IKE_AUX, MID = 1), SK {QSKE1i, QSKE1i, QSKE1i, QSKE2i, QSKE2i } --> > <-- HDR (IKE_AUX, MID = 1), SK { QSKE1ir, QSKE1ir, QSKE1ir, QSKE2ir, QSKE2ir } > > Here we have 2 large public key in a single message, QSKEi1 is split > into 3 payloads and QSKEi2 is split into 2 payloads. Actually, I don't think > it is a good idea to send several large public keys in a single message given > the problems outlined above, but it is a possible construction. > A better way would be: > > HDR (IKE_AUX, MID = 1), SK {QSKE1i, QSKE1i, QSKE1i} --> > <-- HDR (IKE_AUX, MID = 1), SK { QSKE1ir, QSKE1ir, QSKE1ir} > > HDR (IKE_AUX, MID = 2), SK {QSKE2i, QSKE2i} --> > <-- HDR (IKE_AUX, MID = 2), SK { QSKE2ir, QSKE2ir} > > And even better way would be (provided the QSKEs are DH-like): > > HDR (IKE_AUX, MID = 1), SK {QSKE1i} --> > <-- HDR (IKE_AUX, MID = 1), SK { QSKE1ir} > > HDR (IKE_AUX, MID = 2), SK {QSKE1i} --> > <-- HDR (IKE_AUX, MID = 2), SK { QSKE1ir} > > HDR (IKE_AUX, MID = 3), SK {QSKE1i} --> > <-- HDR (IKE_AUX, MID = 3), SK { QSKE1ir} > > HDR (IKE_AUX, MID = 4), SK {QSKE2i} --> > <-- HDR (IKE_AUX, MID = 4), SK { QSKE2ir} > > HDR (IKE_AUX, MID = 5), SK {QSKE2i} --> > <-- HDR (IKE_AUX, MID = 5), SK { QSKE2ir} > > [And I still hope that cryptographers won't leave us with only > those QC safe key exchange methods that use huge public keys. > I really don't want to transfer megabytes of keys just to create an SA > to read my one hundred bytes long e-mail...] > > So, the bottom line. I think that the QSKE draft goes into wrong > direction, suggesting over-complicated and insecure solutions > and ignoring existing mechanisms that can be used instead. > I hope the authors will re-consider this. > > Regards, > Valery. > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Feb 9 08:40:15 2018 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 E3D07126B72 for ; Fri, 9 Feb 2018 08:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 5HqKc2Ievz3N for ; Fri, 9 Feb 2018 08:40:10 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B054B1200FC for ; Fri, 9 Feb 2018 08:40:10 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zdLQH4TgvzpP; Fri, 9 Feb 2018 17:40:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1518194407; bh=NZjUN1QfEYURsAHgnV9zr+Y66R3B0gYORydzncnTjKY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Ff7ygOtJWy7YHfrFMs9fme05lyxSll4DCsLtMYgNA16CRvxveP+fh2geZrjv3bEcI NoFIlbSx8DJ5NhESkWIi8Y0kv9mTX8HNCElMG9rM1hkTgmJHYHr/OJVv/rRh9zxJY+ crtBNGmXl1f2Ki4lrOC1PGAs8tuxJWt3cqgszTfE= 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 5sbkRionQd8S; Fri, 9 Feb 2018 17:40:06 +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, 9 Feb 2018 17:40:04 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B528C30B3EC; Fri, 9 Feb 2018 11:40:03 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B528C30B3EC Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A75B4402333D; Fri, 9 Feb 2018 11:40:03 -0500 (EST) Date: Fri, 9 Feb 2018 11:40:03 -0500 (EST) From: Paul Wouters To: Tero Kivinen cc: mohamed.boucadair@orange.com, "ipsec@ietf.org" In-Reply-To: <23162.53065.405334.393026@fireball.acr.fi> Message-ID: References: <23054.29098.665202.402605@fireball.acr.fi> <787AE7BB302AE849A7480A190F8B93300A07C37A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <23161.62855.158031.367282@fireball.acr.fi> <787AE7BB302AE849A7480A190F8B93300A0CC90D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <23162.53065.405334.393026@fireball.acr.fi> 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] Candidate charter text is now in wiki X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 16:40:13 -0000 On Wed, 7 Feb 2018, Tero Kivinen wrote: > It depends. If we do not take the item as official working group > chartered item, there are still few different options. You can either > get it processed as AD sponsored draft, or you can go individual > submission track. It is a little strange we don't have an ops group for ipsec. The IPsecME group really functions as such. Maybe something covering ops could be added to the charter to cover these kind of items. Because I do think everyone would prefer this type of work to happen in a WG and not as individual/AD sponsored work. Paul From nobody Fri Feb 9 09:05:03 2018 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 F020D12D82F; Fri, 9 Feb 2018 09:05:00 -0800 (PST) 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.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151819590094.1184.8061989876302125160@ietfa.amsl.com> Date: Fri, 09 Feb 2018 09:05:00 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 17:05:01 -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-06.txt Pages : 11 Date : 2018-02-09 Abstract: This document defines two Configuration Payload Attribute Types for the IKEv2 protocol that add support for private DNS domains. These domains should 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". 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-split-dns-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 9 09:06:47 2018 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 3E4ED129C5D for ; Fri, 9 Feb 2018 09:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 TFlyHcxxCLpZ for ; Fri, 9 Feb 2018 09:06:43 -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 5C14A129515 for ; Fri, 9 Feb 2018 09:06:43 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zdM0w6zngzpP; Fri, 9 Feb 2018 18:06:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1518196000; bh=IZ+ec1vgLeSNvscYppXIpUY7vua+LGtV4a+qiuD2SL8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Sgc/KcQuzd6ktgaTrHVARdQWZmwf4UQ0AKoA2kcVx29pLLqVh7oY8vxKx6LtepYMk Tscf05ynJCWdSH42WOjfJkrdTIB3WHfI/CnKILtqzX9jwlPorCQkUpa2sOIO1LtkoO YCVa8mMqaVfM20hO+RcrERJN/AXY5NlGj56lXQ5s= 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 z8d0Qv0Txzyj; Fri, 9 Feb 2018 18:06:39 +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, 9 Feb 2018 18:06:38 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B0BB430B3EC; Fri, 9 Feb 2018 12:06:37 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B0BB430B3EC Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A1715402333C; Fri, 9 Feb 2018 12:06:37 -0500 (EST) Date: Fri, 9 Feb 2018 12:06:37 -0500 (EST) From: Paul Wouters To: Tero Kivinen cc: Tommy Pauly , "ipsec@ietf.org WG" In-Reply-To: <23161.60955.207264.333654@fireball.acr.fi> Message-ID: References: <23161.44491.871182.608585@fireball.acr.fi> <23161.60955.207264.333654@fireball.acr.fi> 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] Comments to the draft-ietf-ipsecme-split-dns-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 17:06:45 -0000 On Tue, 6 Feb 2018, Tero Kivinen wrote: > but this is not possible with current definition of the section 4.2, > where the DNSKEY Key Tag etc fields are mandatory. Thats why my > proposal was to make whole DNSSEC Trust Anchor Data optional. Fixed in -06 >> I've submitted -05. My only question now is what to do with the >> length field of both records. It now says "2 octects, unsigned integer" >> but perhaps it should say "2 octets in network order" ? > > In RFC7296 we have: > > All multi-octet fields representing integers are laid out in big > endian order (also known as "most significant byte first", or > "network byte order"). Thanks, added to the start of the section. diff at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-06 Paul From nobody Fri Feb 9 09:53:46 2018 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 D0F95120454 for ; Fri, 9 Feb 2018 09:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmrJC-rsG-vL for ; Fri, 9 Feb 2018 09:53:43 -0800 (PST) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32B051201F8 for ; Fri, 9 Feb 2018 09:53:43 -0800 (PST) Received: by mail-wr0-x236.google.com with SMTP id o76so5958526wrb.7 for ; Fri, 09 Feb 2018 09:53:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SVtU7nqN912+ZzMO2laKm3j7nYHN/9IsHCvhdYODP/w=; b=Hz564+bstIorxewZngoYTnPO1scXt4Qmnzxr1Hha6T5L5pATG9+L4rQb+0v8SVtoo5 mW+nq/JOZOoNHHEdK9AAIG6S95p7p5DVYCt2cI8Y+CC1hwGweesM7cw/A1QIez1pC36k dxJDl9cQ4LOmAdsYlE397LIjHIYazsDmwtGyNHUfimgDSY7XQ/PWIN/RXcQlpvSNmN1l Ez8hrCVyn5Lf1Krp/IHJjXY0zD8XJcAxheEeQXX39BOGNMR9IpyBX95heUkjqoVkaLHW NVo0M16VFEUVmMgTcBJbHf7hGluyOIiQXx/jRwIDpMGS2YsNzMQ28ytbhpLUQ6IeZQgv +l0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SVtU7nqN912+ZzMO2laKm3j7nYHN/9IsHCvhdYODP/w=; b=BZdgyty8TMVn+7wDTaBpChZn6rtIIXTqOKcTdL8K7NMbn20EWIdAP77wOIrMJ7Y9bL mYCB7YAs463xw6OxK58vlixN1UFFyA3WanCKEddZoTjYUk/0iSyd9yGG9z9sM5jABlIq fQwt7YuAIGIuRNTkTrqqm+gvUQ9T2r++Xfl8K6dnnyMTbz7LR7CW9j6P9YUBDeiGrzGG 92x7IdunvFs9xlhe6/q8nhdTTlZJhC6f7SAypZkwUoNpEOxZw8XixquLzmgwqehvlEoB oYcWtS1esHQr9q8WPDyf2fUPjBYmbPn+NdLwnQZgjR5cDCpbkyeQteSWl3yBESFwEfa3 Q5Bw== X-Gm-Message-State: APf1xPDTTti8KAhBiXr0KGJvyAX+brzXLbm9vbaqbW9BZp/jkFnIsTy+ CBS9rAVM8uLBhCWqcnGzhgzrgbSS X-Google-Smtp-Source: AH8x225w7hny8bIisWqrYYj84WDzytXJZj8TXihSFR6jVj+5ThdUZXpKjrRhU8bT+Fzgr+6gQw+3YQ== X-Received: by 10.223.169.182 with SMTP id b51mr3022861wrd.244.1518198821743; Fri, 09 Feb 2018 09:53:41 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id 4sm2472386wmz.31.2018.02.09.09.53.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Feb 2018 09:53:40 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Yoav Nir In-Reply-To: Date: Fri, 9 Feb 2018 19:53:38 +0200 Cc: "ipsec@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <23054.29098.665202.402605@fireball.acr.fi> <787AE7BB302AE849A7480A190F8B93300A07C37A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <23161.62855.158031.367282@fireball.acr.fi> <787AE7BB302AE849A7480A190F8B93300A0CC90D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <23162.53065.405334.393026@fireball.acr.fi> To: Paul Wouters X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [IPsec] Candidate charter text is now in wiki X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 17:53:45 -0000 > On 9 Feb 2018, at 18:40, Paul Wouters wrote: >=20 > On Wed, 7 Feb 2018, Tero Kivinen wrote: >=20 >> It depends. If we do not take the item as official working group >> chartered item, there are still few different options. You can either >> get it processed as AD sponsored draft, or you can go individual >> submission track. >=20 > It is a little strange we don't have an ops group for ipsec. The = IPsecME > group really functions as such. Are there any work items to add to the charter of this group or a = dedicated ops group? I don=E2=80=99t remember any draft about how you=E2=80=99d go about = deploying IPsec either in VPN or within a datacenter. Certainly not at = scale.=20 There is the work in I2NSF for the datacenter and there are some = =E2=80=9Csoftware defined WAN=E2=80=9D products that use IPsec for VPN, = but the latter is not standardised. Yoav From nobody Mon Feb 12 05:11:33 2018 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 BAC3C12783A for ; Mon, 12 Feb 2018 05:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.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_LOW=-0.7, 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 2fJDQMSCXkDK for ; Mon, 12 Feb 2018 05:11:31 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 91E8012741D for ; Mon, 12 Feb 2018 05:11:30 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id f136so20350705lff.8 for ; Mon, 12 Feb 2018 05:11:30 -0800 (PST) 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=kTAT/cIIg3XW7XK/JIDZqXxX9HNp98C1xhxQCdUYb4o=; b=Jy8llQWcfirY6fAGQOLv8+UFo78UAW8R40Wj0kbXWduycV58nVZiazEIITERGsZRmv nbVpoghLf3d07pcAo4pqZQmA00OpjtE1M59iQiaxlVevaMvqw6xRJe46SH8qlDC8DqIf OqliDl+5cMd5nym9lT1kHUcj1u6GiEUg5aXrP4FIWKqyYreXIkaqxWLrs+tE9nkxCEsr fXsrzWGHMuAoXoHxb1H7QaU3aP75pV1UzAeLZR+dzB/oD5ekSZwCtvMZt0TDYkt2/aj6 tVDR4Y85JDA6/BLGzDYHc5Nk0qcZUfDKwDx8RMY6i5L+KXxyX0e+ZKg3wp/of30+CU+k s1Fg== 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=kTAT/cIIg3XW7XK/JIDZqXxX9HNp98C1xhxQCdUYb4o=; b=uU/VHjE1zLfqfSYoQhgZi2ajpK4vRkmFdQkpLOqUwB4XbaYshvYq7/RedTVTgteLnw rtXjpgyqgo42ASh2D/jhvab1nmcuYSf4aS0QyupdcaWxRscITNK8w04pDFt/cLBs1mzX AuznRcg3hoBxBD3vg3/G0qGlq2/E6/waNA/euQHPwmlwIggHc6aq8v+USjipxdcGtjYx OIdscfeLQ9BN5VcglWhEzHYqeDn9WbYSw4ai8dMP+yNp9hMbEq0v5aQvA7rwO6bZg08t fa1N+SeReZipbumCS8hDnBBfzMX5TS5ut0djEvovg64B8amfoSukJJamz5TlFvb6kjcn X54g== X-Gm-Message-State: APf1xPBXOYZ1J8AogP6R56FdSl+rj8dA5XqpLmX0g4khd0j+qVhVIm1c MtQQpKBhxKvOx5U4hvGSP4oF/Q== X-Google-Smtp-Source: AH8x225f0NrerEJt9roWgUGBvOPBdOo79aFFM7geT2FEfccowbxUcmxapaprdYKiRAQOysOkKm3SRg== X-Received: by 10.46.23.156 with SMTP id 28mr4845615ljx.29.1518441088573; Mon, 12 Feb 2018 05:11:28 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id c63sm1658108lfg.55.2018.02.12.05.11.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 12 Feb 2018 05:11:27 -0800 (PST) From: "Valery Smyslov" To: "'CJ Tjhai'" Cc: References: <033701d39b5d$bf7f2140$3e7d63c0$@gmail.com> In-Reply-To: Date: Mon, 12 Feb 2018 16:11:27 +0300 Message-ID: <0ab401d3a402$fe205ce0$fa6116a0$@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: AQI9PLZY84Ug9ZhVQ5GFYO3tiZw4GADWihXiosHO7mA= Content-Language: ru Archived-At: Subject: Re: [IPsec] draft-tjhai-ipsecme-hybrid-qske-ikev2-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 13:11:33 -0000 Hi, thank you for the explanation. See my comments inline. > 1. Negotiation > > We are glad to see that you also appreciate the need to negotiate a > hybrid group. As you may remember, we introduced a new Transform Type > in our version 00 of our draft and it had not been well-received in > IETF 99 Prague. We accept this push-back and it makes sense; since the > introduction of IKEv2, there has not been any new Transform Type > introduced. In fact, after IETF 99 Prague, we found out that there > exists IKEv2 implementations out there that will error out if they > receive an unknown Transform Type. I'm not sure it justifies introducing yet another negotiation mechanism. I understand that we live in non-ideal world, however adding one more mechanism for solving exactly the same problem due to existence of buggy implementations looks far too expensive for me. Unless these buggy implementations dominate... > As you pointed out, according to RFC 7296, if a responder receives a > proposal with Transform Type that it doesn't understand, it MUST > reject the proposal. However, we found that this is not true in > practice. StrongSwan is a good example; consider you have two peers > running StrongSwan where the initiator introduces a proposal > containing a new Transform Type: > > SA: > Proposal 1: > Transform Type 1: ENCR_AES_CBC > Transform Type 2: PRF_HMAC_SHA2_256 > Transform Type 3: AUTH_HMAC_SHA2_256_128 > Transform Type 4: P-256 > Transform Type 6: New Transform Type > Proposal 2: > Transform Type 1: ENCR_AES_CBC > Transform Type 2: PRF_HMAC_SHA2_256 > Transform Type 3: AUTH_HMAC_SHA2_256_128 > Transform Type 4: MODP-3072 > > It is assumed that the responder runs StrongSwan implementing standard > RFC 7296, hence it does not understand Transform Type 6. Instead of > rejecting Proposal 1 and considering Proposal 2, the responder ignores > Transform Type 6 (i.e. selecting ENCR_AES_CBC, PRF_HMAC_SHA2_256, > AUTH_HMAC_SHA2_256_128, P-256). The initiator clearly does not propose > this proposal. This particular case would only be okay if Proposal 2 > offers P-256. This behavior is wrong, however I don't think it cannot be dealt with. Just always define your policies so that all PSKE proposals contain the same "classic" transforms, as "classic" proposal. This is an additional requirement for policy, but Is there any reason this is wrong from security point of view? > This is one particular implementation peculiarity, there > will be others that behaves oddly. The point is, if we introduce a new > Transform Type, it is very likely that backward compatibility can no > longer be achieved. Again, it depends. If the majority of implementations immediately crash once they receive unknown transform, then I agree that we need another mechanism... Most of other cases usually can be dealt with. Probably not all and probably not as elegant as we wish, but still I believe they can. > Hence, we pick a DH group that denotes a hybrid group and negotiate it > using the existing KE payload. Well, if you are so determined to deal with buggy implementations, then there are more natural alternatives. For example you may introduce a new SA-like payload, which would have the same syntax as SA payload, but different Payload Type, and put all PSQE stuff there. Since Critical Bit is not set in this payload, the existing implementations must ignore it. And if you find implementations that won't behave correctly even in this case, then put SA-like syntax in a new notify - I'm sure every existing implementation can handle this. So, my main concern is that with your proposal a new code is needed to parse, form, log etc. all the QSQE stuff, since it is presented in a completely new way. It is not a big deal if the amount of negotiation stuff is small (say, you define only one QSKE group). In your case, you want to express a complex combinations of different QSKE methods, which I, as implementer, would need to parse, form, log, match to policy etc. I prefer to reuse existing code for this and I see no reason why it cannot be done. > On your email, you also mentioned that in the future, we could use KE > payload to carry small PQ KE payload. Then, some logic is required to > distinguish what is carried in IKE_SA_INIT and what is carried in > IKE_AUX; it looks messy. It is easy. "Classic" KE is always done in the IKE_SA_INIT. All PQ KEs are done in the IKE_AUX. However, once one (or few) of the PQ KEs is considered cryptographically matured and this PQ KE has small enough public key, we'll add it as a new "classic" one, so that in done in the IKE_SA_INIT. No mess here. > 2. Fragmentation > > We remember that Tero did suggest to use an intermediary exchange > between IKE_SA_INIT and IKE_AUTH. However, after soliciting inputs > from a number of parties (both vendors and clients), it appeared that > the majority didn't like the idea of having this extra exchange as > introduced a considerable deviation from standard IKEv2 flow and felt > that we would just be introducing an IKE_SA_INIT fragmentation which > could be achieved by other mechanisms. I'm puzzled here... The whole idea of QSKE is a considerable deviation from standard IKEv2. Comparing to the amount of needed changes to the protocol, introducing a new exchange that follows standard IKEv2 rules looks like a simple task. I believe it is easier than making all the modifications from the draft to the IKE_SA_INIT (that is already quite complex). > While IKE_AUX would be useful in environment where network is lossy, > we also need to consider the requirements for applications such as VPN > concentrator where connection rate is important, or peers that have a > considerable route trip time. If you put all the QSKE payloads in a single IKE_AUX (and won't do them one by one in a series of IKE_AUX), you'll have the same number of round trips as in your proposal. I see no advantage of your proposal here. Am I missing something? > We acknowledge that we have not included > any mechanisms to deal with loss packets in version 01 of our draft. > This is intentional as we would like to get the WG input on which > direction we should take our draft before going deeper. > > In terms of DoS attacks, we do not mandate the use of cookie > mechanism, but when implemented, the responder can check that incoming > messages corresponding to the second round of our protocol (note that > this is the expensive round in which public-key operations are > performed and space is allocated) have been agreed previously in a > first round of the protocol. It won't help you against poisoning reassembly queue with a bogus packets, since an attacker would know the correct cookie from the first round. And this attack is not possible at all with IKE_AUX (unless an attacker breaks classic DH in a real time). Please, see ipsecme mail archives from 2012-2013 where all these things concerning possible attacks on IKE fragmentation were discussed in detail. > We also believe that your comment that > what you propose is substantially more secure is not true. An attacker > who can monitor exchange of messages and inject packets, can trivially > DoS a connection (e.g. when the initiator sends the initial "HDR, > SAi1, KEi, Ni", the attacker immediately responds with a "HDR, SAr1, > KEr, Nr" of his choosing before the real responder does). An attacker > who can modify the initial packets is not detected until later in the > exchange. This is a different kind of attack and your proposal is susceptible to it as well. Moreover, the attack is described in the RFC7296 (Section 2.4, page 29) and some countermeasures are suggested. > Of course, this could require a significant amount of > resource allocation for post-quantum public data exchange. In our > approach, we could detect it before IKE_AUTH phase. Please, elaborate. Unless you mandate requesting cookie, your proposal is no more secure against this attack than classic IKEv2 or IKE_AUX. And mandating requesting cookie can be an option for all of them. When I was talking about DoS attack on your proposal that are not possible in IKE_AUX approach, I meant an reassembly queue poisoning attacks. Besides your proposal is more complex and less robust... > 3. Large payload > > We also hope that we don't end up having PQC ciphers with large > public-key. We don't mandate our proposed draft to support payloads > larger than 64KB. In fact, it is an added bonus of how we do > fragmentation. Well, with IKE_AUX we have this bonus almost for free too. However I agree that we'd better to avoid such huge KE payloads... > Best regards, > Authors of draft-tjhai-ipsecme-hybrid-qske-ikev2-01 Regards, Valery. From nobody Mon Feb 12 07:26:35 2018 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 A6B0312D0C3 for ; Mon, 12 Feb 2018 07:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 AeaJ5Kow31CK for ; Mon, 12 Feb 2018 07:26:32 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C183012D7EA for ; Mon, 12 Feb 2018 07:26:31 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zg8dx1VFSz3Dr; Mon, 12 Feb 2018 16:26:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1518449189; bh=W//5MR4yMXxT5x2hajfV0+G4VmHW7geoSdrjE3KKLI4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=lDFcSTn/egc2Jr1/xaoTAi7JhJXiOJU+Kse2tG4aoSiA0t9PC1nM2E+bna4oDAOCC /sa/N4N+fo7QJTeY2F7uGopfQ+X1OJo4s6vfHUVS+10EmvEtEQI/qTdNaCX0ekzf4P l5owC4es8tNZzn8f1mhlwNRGEVXmpvhA6Q64PEb4= 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 r9QRvDjAL2Tw; Mon, 12 Feb 2018 16:26: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, 12 Feb 2018 16:26:28 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 58B0B30B3F7; Mon, 12 Feb 2018 10:26:27 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 58B0B30B3F7 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 516484023306; Mon, 12 Feb 2018 10:26:27 -0500 (EST) Date: Mon, 12 Feb 2018 10:26:27 -0500 (EST) From: Paul Wouters To: Valery Smyslov cc: 'CJ Tjhai' , ipsec@ietf.org In-Reply-To: <0ab401d3a402$fe205ce0$fa6116a0$@gmail.com> Message-ID: References: <033701d39b5d$bf7f2140$3e7d63c0$@gmail.com> <0ab401d3a402$fe205ce0$fa6116a0$@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] draft-tjhai-ipsecme-hybrid-qske-ikev2-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 15:26:34 -0000 On Mon, 12 Feb 2018, Valery Smyslov wrote: >> This is one particular implementation peculiarity, there >> will be others that behaves oddly. The point is, if we introduce a new >> Transform Type, it is very likely that backward compatibility can no >> longer be achieved. > > Again, it depends. If the majority of implementations immediately crash once they > receive unknown transform, then I agree that we need another mechanism... > Most of other cases usually can be dealt with. Probably not all and probably > not as elegant as we wish, but still I believe they can. We still have plenty of time to get the word out to those implementations to fix their problem. By the time we have a document ready for post quantum transforms, those implementations should have been fixed. It's a little early now to deem this an unsurmountable problem. > I prefer to reuse existing code for this and I see no reason why it cannot be done. I agree. Paul From nobody Tue Feb 13 14:20:49 2018 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 E732512D964 for ; Tue, 13 Feb 2018 14:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bBppTEdVrjC for ; Tue, 13 Feb 2018 14:20:45 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 E2334127058 for ; Tue, 13 Feb 2018 14:20:44 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w1DMKbrH023455 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 14 Feb 2018 00:20:37 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w1DMKbUF022038; Wed, 14 Feb 2018 00:20:37 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23171.25781.719070.719736@fireball.acr.fi> Date: Wed, 14 Feb 2018 00:20:37 +0200 From: Tero Kivinen To: Paul Wouters Cc: Valery Smyslov , "'CJ Tjhai'" , ipsec@ietf.org In-Reply-To: References: <033701d39b5d$bf7f2140$3e7d63c0$@gmail.com> <0ab401d3a402$fe205ce0$fa6116a0$@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 16 min X-Total-Time: 28 min Archived-At: Subject: Re: [IPsec] draft-tjhai-ipsecme-hybrid-qske-ikev2-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 22:20:48 -0000 Paul Wouters writes: > On Mon, 12 Feb 2018, Valery Smyslov wrote: > > >> This is one particular implementation peculiarity, there > >> will be others that behaves oddly. The point is, if we introduce a new > >> Transform Type, it is very likely that backward compatibility can no > >> longer be achieved. > > > > Again, it depends. If the majority of implementations immediately crash once they > > receive unknown transform, then I agree that we need another mechanism... > > Most of other cases usually can be dealt with. Probably not all and probably > > not as elegant as we wish, but still I believe they can. > > We still have plenty of time to get the word out to those > implementations to fix their problem. By the time we have a > document ready for post quantum transforms, those implementations > should have been fixed. It's a little early now to deem this > an unsurmountable problem. Yes. Also there is big difference in requirements for draft-ietf-ipsecme-qr-ikev2 and requirements for proposal doing proper quantum safe algorithms. The draft-ietf-ipsecme-qr-ikev2 is intended to be deployed now, and should work with existing implementations without fatal interoperability errors with them. As quantum safe algorithms itself are so much in ongoing research now, I do not think we will be having implementations out there using any of the quantum safe algorithms now, and so there will be time for broken implementations to get fixes installed to them. I.e., if you still plan on running completely broken strongswan implementation which do not implement MUSTs in IKEv2 for example in year 2019, then you are not interested in security, thus you are not really going to be even try to use anything like quantum safe algorithms to talk to them... I mean, if you plan not to install security updates to your IPsec products for years to come, it does not matter what we do, you most likely have big security holes in your gateways anyways. Even RFC4306 said you "MUST contain exactly one transform of each type included in the proposal" in section 2.7, so what they are doing has never been allowed in the IKEv2. In the RFC5996 we did add text saying: If the responder receives a proposal that contains a Transform Type it does not understand, or a proposal that is missing a mandatory Transform Type, it MUST consider this proposal unacceptable; however, other proposals in the same SA payload are processed as usual. and if they have not updated IPsec implemenation since 2010, again there will most likely be so many holes in it that there is no point of talking about quantum safe algorithms... We have discussed several times of adding new transform types, and in most cases we have found better ways of doing that. On the other hand there is nothing that would make it impossible to add new transform types. IKEv2 has been designed so that new things can be added without breaking old implementations (provided old implementations actually follow what was written in the IKEv2 RFCs). In this case I think I agree with Valery that adding new transform types might be good option, and we should investigate that option too. > > I prefer to reuse existing code for this and I see no reason why > > it cannot be done. > I agree. Making IKE_SA_INIT more complicated than what is now, is something we do not really want to do. It is first exchange with the peer, it has all kind of denial of service properties which we should try to cope. We do not want to make it so big it will get larger than one kilobyte in size, so it will not get fragmented by the IP layer etc. Doing fragmentation on that layer is very hard if we want to protect that also against DoS. I am very much suprised that some of the vendors really said that they wanted to change the IKE_SA_INIT instead than add new exchange between IKE_SA_INIT and IKE_AUTH. -- kivinen@iki.fi From nobody Fri Feb 16 09:55:32 2018 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 7B93E127698 for ; Fri, 16 Feb 2018 09:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DexIFu7fJIH1 for ; Fri, 16 Feb 2018 09:55:26 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 2A690124C27 for ; Fri, 16 Feb 2018 09:55:25 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w1GHtJn0019696 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 16 Feb 2018 19:55:23 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w1GHtDaA013676; Fri, 16 Feb 2018 19:55:13 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23175.6913.726475.284090@fireball.acr.fi> Date: Fri, 16 Feb 2018 19:55:13 +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: 5 min Archived-At: Subject: [IPsec] Proposed charter text X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 17:55:29 -0000 Here is the current proposed charter text about the items we managed to agree in the IETF 100 meeting. I have left out the items we didn't manage to have consensus, and I will send another email after this to start discussion about them. If you have comments (or objections) adding these new items to the charter send your comments as soon as possible. ---------------------------------------------------------------------- The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to ESP and IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The current work items include: Old items QR IKEv2 (old) IKEv1 using shared secret authentication was partially resistant to quantum computers. IKEv2 removed this feature to make the protocol more usable. The working group will add a mode to IKEv2 or otherwise modify IKEv2 to have similar quantum resistant properties than IKEv1 had. Split DNS (old, almost done == can be removed) Split-DNS is a common configuration for VPN deployments, in which only one or a few private DNS domains are accessible and resolvable via the tunnel. Adding new configuration attributes to IKEv2 for configuring Split-DNS would allow more deployments to adopt IKEv2. This configuration should also allow verification of the domains using DNSSEC. Working group will specify needed configuration attributes for IKEv2. Implicit IV (old, almost done == can be removed) Currently, widely used counter mode based ciphers send both the ESP sequence number and IV in form of counter, as they are very commonly the same. There has been interest to work on a document that will compress the packet and derive IV from the sequence number instead of sending it in separate field. The working group will specify how this compression can be negotiated in the IKEv2, and specify how the encryption algorithm and ESP format is used in this case. New items Group DOI for IKEv2 (new) The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based protocol for negotiating group keys for both multicast and unicast uses. The Working Group will develop an IKEv2-based alternative that will include cryptographic updates. A possible starting point is draft-yeung-g-ikev2 Postquantum cryptography for IKEv2 (new) Postquantum Cryptography brings new key exchange methods. Most of these methods that are known to date have much larger public keys then conventional Diffie-Hellman public keys. Direct using these methods in IKEv2 might lead to a number of problems due to the increased size of initial IKEv2 messages. The working group will analyze the possible problems and develop a solution, that will make adding Postquantum key exchange methods more easy. The solution will allow post quantum key exchange to be performed in parallel with (or instead of) the existing Diffie-Hellman key exchange. Diet-ESP/IKE(new) A growing number of use cases for constraint network - but not limited to - have shown interest in reducing ESP (resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields. The WG will define extensions of ESP and IKEv2 to enable ESP header compression. draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension are expected to be good starting points for ESP compression. draft-smyslov-ipsecme-ikev2-compression and draft-smyslov-ipsecme-ikev2-compact are good starting point for IKEv2 compression. Signature algorithm negotiation (new) RFC7427 allows peers to indicate hash algorithms they support, thus eliminating ambiguity in selecting a hash function for digital signature authentication. However, recent advances in cryptography lead to a situation when some signature algorithms have several signature formats. A prominent example is RSASSA-PKCS#1 and RSASSA-PSS, however it is envisioned that the same situation may repeat in future with other signature algorithms. Currently IKE peers have no explicit way to indicate each other which signature format(s) the support, that leads to ineroperability problems. The WG will investigate the situation and come up with a solution that allows peers to deal with the problem in an interoperable way. -- kivinen@iki.fi From nobody Fri Feb 16 10:01:04 2018 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 3A0C5129C6B for ; Fri, 16 Feb 2018 10:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kavywv2p8dff for ; Fri, 16 Feb 2018 10:01:02 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 A52301200C1 for ; Fri, 16 Feb 2018 10:00:57 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w1GI0tsJ022304 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 16 Feb 2018 20:00:55 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w1GI0qrQ005349; Fri, 16 Feb 2018 20:00:52 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23175.7252.256625.885691@fireball.acr.fi> Date: Fri, 16 Feb 2018 20:00:52 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 5 min Archived-At: Subject: [IPsec] Additional charter items 1/4: Responder MOBIKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 18:01:03 -0000 This is items we did not manage to reach full consensus in the IETF 100 meeting. There were concerns and questions why this is needed and why it cannot be done with already existing methods (mostly redirect etc, or updating the address lists). The proposed charter text is ---------------------------------------------------------------------- MOBIKE protocol [RFC4555] is used to move existing IKE/IPsec SA from one IP address to another. However, in MOBIKE it is the initiator of the IKE SA (i.e. remote access client) that controls this process. If there are several responders each having own IP address and acting together as a load sharing cluster, then it is desirable for them to have ability to request initiator to switch to a particular member. The working group will analyze the possibility to extend MOBIKE protocol or to develop new IKE extension that will allow to build load sharing clusters in an interoperable way. ---------------------------------------------------------------------- It could be also possible that we first start just researching whether we actually need any protocol changes, and if so make specifications for them, and if not, we might still want to publish some kind of informational document describing how those existing mechanisms can be used for this purpose. Send your comments and whether you support adding this to the charter to the ipsec list in next two weeks. -- kivinen@iki.fi From nobody Fri Feb 16 10:04:10 2018 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 98719128959 for ; Fri, 16 Feb 2018 10:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8F5Cq1XR2cO for ; Fri, 16 Feb 2018 10:04:07 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 476001200C1 for ; Fri, 16 Feb 2018 10:04:07 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w1GI45wm018607 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 16 Feb 2018 20:04:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w1GI45S3001344; Fri, 16 Feb 2018 20:04:05 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23175.7445.247642.686611@fireball.acr.fi> Date: Fri, 16 Feb 2018 20:04:05 +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] Additional charter items 2/4: Address Failure Errors X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 18:04:09 -0000 This item has draft (draft-boucadair-ipsecme-ipv6-ipv4-codes) which quite well the needs and why this is to done, and I think we do undestand the item itself, but the charter text was not covered in the IETF 100 meeting, so we did not get consensus call done for it. The proposed charter text is: ---------------------------------------------------------------------- RFC7296 defines a generic notification code that is related to a failure to handle an internal address failure. That code does not explicitly allow an initiator to determine why a given address family is not assigned, nor whether it should try using another address family. The Working Group will specify a set of more specific notification codes that will provide sufficient information to the IKEv2 initiator about the encountered failure. draft-boucadair-ipsecme-ipv6-ipv4-codes will be used as a starting point for this item. ---------------------------------------------------------------------- Send your comments and whether you support adding this to the charter to the ipsec list in next two weeks. -- kivinen@iki.fi From nobody Fri Feb 16 10:06:42 2018 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 2E1FB126CB6 for ; Fri, 16 Feb 2018 10:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpRJAAXkk0-t for ; Fri, 16 Feb 2018 10:06:39 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 146F71200C1 for ; Fri, 16 Feb 2018 10:06:38 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w1GI6bPV015708 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 16 Feb 2018 20:06:37 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w1GI6bl8023986; Fri, 16 Feb 2018 20:06:37 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23175.7597.238297.330233@fireball.acr.fi> Date: Fri, 16 Feb 2018 20:06: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: 3 min X-Total-Time: 2 min Archived-At: Subject: [IPsec] Additional charter items 3/4: Labeled IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 18:06:40 -0000 This charter text was not ready during the IETF 100, we just had very short description about the item, and I think most of the people did not really understand it. The proposed charter text for this item is: ---------------------------------------------------------------------- Some systems support security labels (aka security context) as one of the selectors of the SPD. This label needs to be part of the IKE negotiation for the IPsec SA. non-standard implementations exist for IKEv1 (formerly abusing IPSEC Security Association Attribute 10, now using private space IPSEC Security Association Attribute 32001). The work is to standarize this for IKEv2. ---------------------------------------------------------------------- Is that charter text clear enough? Is there enough people interested in this? Send your comments and whether you support adding this to the charter to the ipsec list in next two weeks. -- kivinen@iki.fi From nobody Fri Feb 16 10:13:24 2018 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 4FE97129C6B for ; Fri, 16 Feb 2018 10:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqU3E8suwbJJ for ; Fri, 16 Feb 2018 10:13:22 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 1889F1200C1 for ; Fri, 16 Feb 2018 10:13:21 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w1GIDKae024242 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 16 Feb 2018 20:13:20 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w1GIDKTx022954; Fri, 16 Feb 2018 20:13:20 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23175.8000.242283.548415@fireball.acr.fi> Date: Fri, 16 Feb 2018 20:13:20 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 6 min Archived-At: Subject: [IPsec] Additional charter items 4/4: Mitigating privacy concerns X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 18:13:23 -0000 This item does not have charter text yet, we do have text which explains what the problem is, but I think it requires some reformatting to fit as charter text. The problem description is: ---------------------------------------------------------------------- IKEv2 is currently vulnerable to the two following privacy concerns: 1) It's not possible to run a server that obfuscates IKEv2/IPsec using TLS. Today thanks to RFC 8229 it is possible to run an IKEv2/IPsec server on TCP port 443 with TLS. However if a government agent tries to send an SA_INIT over that it will discover that this server runs IKEv2/IPsec, and may blacklist it. We should add a mechanism to IKEv2 that allows the server to only respond to SA_INIT from known entities (e.g. that possess a shared secret). 2) The privacy of the initiator's identity in the presence of a man in the middle attacker is not protected. Today an attacker with full control of the network can receive the IDi/IDr sent by the initiator in the first AUTH packet. We should add a mechanism to IKEv2 that allows the initiator to only send IDi/IDr to known entities (e.g. that possess a shared secret). ---------------------------------------------------------------------- Is this something that we should add to charter? Do people understand the issue? Note, that there are multiple ways of solving these issues, for example the 2nd problem can also be solved by using pseudonyms, i.e., sending random one use ID payloads during the IKE_AUTH, and after the peers have authenticated each other, they can do new exchange which will change the pseudonyms for next use. I think the 2nd option should be rewritten in bit more generic ways to allow that kind of option too. Send your comments and whether you support adding this to the charter to the ipsec list in next two weeks. -- kivinen@iki.fi From nobody Fri Feb 16 10:16:04 2018 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 9D243128C0A for ; Fri, 16 Feb 2018 10:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSf4bgEymIFS for ; Fri, 16 Feb 2018 10:16:00 -0800 (PST) Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::244]) (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 B34EE12AF84 for ; Fri, 16 Feb 2018 10:15:57 -0800 (PST) Received: by mail-wr0-x244.google.com with SMTP id n7so3775662wrn.5 for ; Fri, 16 Feb 2018 10:15:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=W8YVeZ9XA8pxwoB3L4iEbHgOh7baTPCwuOtvwgV4Jtk=; b=tWRLjSeHq95dFkKkeqeX13pkb931RrcMq6FDNrEhZ3GRQZr0JbWbiBX+Ds6SnkV6K3 uu5S3mOqscxYkG0tWqoFiIHxtPDsCQOFNbZ3rT5zB1wWkpRga22QIUauCpt1mu1j0kAa 6arFXxXVQ1F5HVikgJBzRsn8NrB40vB/D8a9Nv3EY8ffGj751VYqMlpsGKkSLwNPfG3i mtKSBpHDZID3EE9grddbgALdxVgObQSIsFvlhacV5ldGNAsYwqlZgzIzmmUuHQICyQ9M WH8ZGQCcw1HB2yXV5VSsKcWBQTDee1s9KLak2eYFovOYfZW3hoSrfwo+luRv02xytAam vihw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=W8YVeZ9XA8pxwoB3L4iEbHgOh7baTPCwuOtvwgV4Jtk=; b=ANjz3U0tOCr/LhKqH3ZF6QOgqjeTzQwXmUHbsLzHBOaaElcHy8u9A7niMjJu1dKPy9 8y47oYvV9WIv58ACuJZw+gjdMRQVmucumXm31G8JN62oUwci0998eWQThUbaldNLQoT2 EUiM380T/55F9HAzIfXY+AgoLzwA20wvBCc/n7clNArnerZbdZUmFkaQLjPEspVaW590 QIzRCsDevlEkq1M/oCk7e/PynVzTF/I1J94mbs6OzFu1qK/BMyek5PUV6ERjHQNwoava 63CL/FEeh0edhftSmIV+buxxFLE2cPeXyjlUYs+y1x0+DA5uRsVeXYqdsZhlZxWQI8Cb HVjg== X-Gm-Message-State: APf1xPDIqNq0rbjo8W8zVjOS6LLPG2C8aC3sxASD2metycUALsB5A3lz zT1aRWInKTBMAIwnoSqgRBcRuV6H X-Google-Smtp-Source: AH8x224CW+wQ6JzztAfyRZK8/rfFD1WECuCPawllOOev2nyRnbBRj+/X34XKXhSehcXUJmHIgSydpQ== X-Received: by 10.223.157.71 with SMTP id o7mr7077503wre.248.1518804956177; Fri, 16 Feb 2018 10:15:56 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id b65sm32240402wrd.26.2018.02.16.10.15.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Feb 2018 10:15:55 -0800 (PST) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_0CEBBA75-DE04-4122-BCC5-E596CBD49036"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 16 Feb 2018 20:15:53 +0200 In-Reply-To: <23175.7597.238297.330233@fireball.acr.fi> Cc: ipsec@ietf.org To: Tero Kivinen References: <23175.7597.238297.330233@fireball.acr.fi> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [IPsec] Additional charter items 3/4: Labeled IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 18:16:03 -0000 --Apple-Mail=_0CEBBA75-DE04-4122-BCC5-E596CBD49036 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 16 Feb 2018, at 20:06, Tero Kivinen wrote: >=20 > This charter text was not ready during the IETF 100, we just had very > short description about the item, and I think most of the people did > not really understand it. >=20 > The proposed charter text for this item is: >=20 > ---------------------------------------------------------------------- > Some systems support security labels (aka security context) as one of > the selectors of the SPD. This label needs to be part of the IKE > negotiation for the IPsec SA. non-standard implementations exist for > IKEv1 (formerly abusing IPSEC Security Association Attribute 10, now > using private space IPSEC Security Association Attribute 32001). The > work is to standarize this for IKEv2. > ---------------------------------------------------------------------- >=20 > Is that charter text clear enough? Yeah, I think anyone who=E2=80=99s heard of multilevel security = understands what is proposed here. > Is there enough people interested > in this? I guess, since MLS keeps coming up=E2=80=A6 I=E2=80=99m not, but I=E2=80=99m not opposed to doing this as long as = there=E2=80=99s no burden on non-supporting implementations. >=20 > Send your comments and whether you support adding this to the charter > to the ipsec list in next two weeks. > -- > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_0CEBBA75-DE04-4122-BCC5-E596CBD49036 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----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAlqHH9kACgkQuEkLFQpY zJnFSQgAyW/zOV8nEQsRIGrix0UAEjLftMBzrg0zRggBI5popRux13uFC2CivFGP Bktuj1FxAoYkcevS+rOcsWwD6y3L76f/ZQ8KhRdj3Zianqo7eLVoRsBp306mQ74x NEvMUO4mfn55GlQzRFQVgq4TAgC/u0WOi6kxx9IB0WaO1Ej3RemVQiiG+l1N1faU tvYJkDTEuSumLj7gPu+sivNlderMVMhN3stWwjpIg+/kJ6w3144QqAD+B0vCFKtf eJnJ8InmnlAPx5r55dIbLXXXMK1s9xPok6ry2Wn1oYTDtHXmrTPNMIdUfgcgmkT9 9/EKdms3DSyWdW3CZ/QPi7ZdOl7CWQ== =3wea -----END PGP SIGNATURE----- --Apple-Mail=_0CEBBA75-DE04-4122-BCC5-E596CBD49036-- From nobody Fri Feb 16 10:25:32 2018 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 80232129515 for ; Fri, 16 Feb 2018 10:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VygXK45ZORpA for ; Fri, 16 Feb 2018 10:25:28 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC4CD1200C1 for ; Fri, 16 Feb 2018 10:25:27 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id v71so4692139wmv.2 for ; Fri, 16 Feb 2018 10:25:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=F2NFZrPdl9YrERihEm53QkEWZDYng/mwje1I03se96A=; b=Cu9IeWakXEjBonn2VfnfHsTR+H6Jk8QsZPyUtYBxx8c0DTF8ppZp9d1Va9zx9Jdn6K vb8f74fs6Ro3lu8a36x4NxlI3xmIDLENiqa25sVaEPGv3X/vMiuY7vzM1WzVyVw4M23c uYF4nMDBI81dVS6ERVpYITVj6+XpyBZgZyHdch3qXjRmpy5E6rHSQuEBQpwe8TwCbcJP 9ny/THZqiBHsyOUBdvfcPPAxgicPT7eIbqQLRXAus74eQTyXnLqh1cMtk7mInb6q4GgY zMrPCFYLtm1w0lOISM3zj1geBAYvKlO3R8iK8fNH3PTCUPkpNy3SxsWGyvHljb/I8bBJ 8kMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=F2NFZrPdl9YrERihEm53QkEWZDYng/mwje1I03se96A=; b=Ns4zcaXGvvHfk5NOSKbujNE36OQewZmWEscO/qe0NL0K93JDOx00ujWkX/slQDSKhY WPzmkVSKxqB7bLgSqIFAy+gWubAMPOyW+L3hxb+p98jUJUI2uzEhZpL1cOpurEHC2SyB xQlpiqv2kaQjFydmdzAa7ANL0dSpGHkVB6BBqngkRI6sz+9OWaWJFxOIkAdfJ5ASoEA9 Z50Bs1ek552lCtieMJBJmJLdtT1yxkI3ZbJHND2VVC9Z3sSl8CjTIP/9nkXweLltqzVb +OQUxvydyrk4W5GzSkB0O/AX5IkzBGkbVInq/6SEUe4TjD39Ow6awEaBxDKzhmGACbh0 pISw== X-Gm-Message-State: APf1xPCNYyyM0UcwMweoDgSJ2o5FVJSzCIefK13VoL4A6cB2Z5acUJ3Y SsaMeSS/Wi41/XbshnebTyU= X-Google-Smtp-Source: AH8x224H9C3YgCpymi1rosTtBhjmqgjmHiYxRmmQMPVqKedaPm6QTbh5a/GweHgKy3267oQlEu9THw== X-Received: by 10.28.17.141 with SMTP id 135mr5194715wmr.80.1518805526397; Fri, 16 Feb 2018 10:25:26 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id b136sm13186740wme.34.2018.02.16.10.25.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Feb 2018 10:25:25 -0800 (PST) From: Yoav Nir Message-Id: <97670585-978A-4E58-AC8A-833EB8790754@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_54762FB0-ACE7-46BB-81C8-532C041DB2F5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 16 Feb 2018 20:25:23 +0200 In-Reply-To: <23175.8000.242283.548415@fireball.acr.fi> Cc: ipsec@ietf.org To: Tero Kivinen References: <23175.8000.242283.548415@fireball.acr.fi> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [IPsec] Additional charter items 4/4: Mitigating privacy concerns X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 18:25:31 -0000 --Apple-Mail=_54762FB0-ACE7-46BB-81C8-532C041DB2F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 16 Feb 2018, at 20:13, Tero Kivinen wrote: >=20 > This item does not have charter text yet, we do have text which > explains what the problem is, but I think it requires some > reformatting to fit as charter text. >=20 > The problem description is: >=20 > ---------------------------------------------------------------------- >=20 > IKEv2 is currently vulnerable to the two following privacy concerns: >=20 > 1) It's not possible to run a server that obfuscates IKEv2/IPsec using > TLS. >=20 > Today thanks to RFC 8229 it is possible to run an IKEv2/IPsec > server on TCP port 443 with TLS. However if a government agent > tries to send an SA_INIT over that it will discover that this > server runs IKEv2/IPsec, and may blacklist it. We should add a > mechanism to IKEv2 that allows the server to only respond to > SA_INIT from known entities (e.g. that possess a shared secret). That would require that within the SA_INIT request, the initiator proves = possession of a shared secret and does so in a non-replayable way. Wouldn=E2=80=99t it be better for the initiator to prove identity or = group membership in the TLS handshake? >=20 > 2) The privacy of the initiator's identity in the presence of a man in > the middle attacker is not protected. >=20 > Today an attacker with full control of the network can receive the > IDi/IDr sent by the initiator in the first AUTH packet. We should > add a mechanism to IKEv2 that allows the initiator to only send > IDi/IDr to known entities (e.g. that possess a shared secret). This is more feasible. I understand the issue, but the only use case = where I think it=E2=80=99s important is remote access. It would make = sense in remote access to reverse the order of authentication so that = the responder identifies and authenticates first, but you=E2=80=99d = still need the initiator to send the IDr first. > ---------------------------------------------------------------------- >=20 > Is this something that we should add to charter? Do people understand > the issue? >=20 > Note, that there are multiple ways of solving these issues, for > example the 2nd problem can also be solved by using pseudonyms, i.e., > sending random one use ID payloads during the IKE_AUTH, and after the > peers have authenticated each other, they can do new exchange which > will change the pseudonyms for next use. I think the 2nd option should > be rewritten in bit more generic ways to allow that kind of option > too. >=20 > Send your comments and whether you support adding this to the charter > to the ipsec list in next two weeks. > -- > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_54762FB0-ACE7-46BB-81C8-532C041DB2F5 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----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAlqHIhMACgkQuEkLFQpY zJmOoAgAxllsiUD6ZFBV5D+ltXedmkhNN6uI/bSHz+J6Ou6IT9r4mheWsEXUV1gH L2Rbmd6Ugl6SQcQwIveUPEGXOMdqHGuBFo5x2Osks665O7ZZj9tlkq7XYdHXfmAg HhL8VroIWs6s3mN6Er1BM0pWOzQoZfO30YbaiXDybUoNXXUceaFKGpkNuy7cZH9M 2GpdqrHMWmib63/tdRBdzLRRqr95WuXtGpJl4WHMjM6sWvXCClj0xbuHFQoFPZA3 o4mnqMzlc9jeynVsrzH38tiiGJJe2wVE7eHQr8W9WIIwwvSQNnT9Y7PFwY3Dzo2l vvHZdrJQMs0QzcHsj/WvJBxgd1GVoA== =ZxhX -----END PGP SIGNATURE----- --Apple-Mail=_54762FB0-ACE7-46BB-81C8-532C041DB2F5-- From nobody Fri Feb 16 11:10:15 2018 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 5925D1289B0 for ; Fri, 16 Feb 2018 11:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np13ctjTmzoO for ; Fri, 16 Feb 2018 11:10:03 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 1FF1A126CE8 for ; Fri, 16 Feb 2018 11:10:02 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w1GJA0pE029581 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Feb 2018 21:10:00 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w1GJ9v9C008079; Fri, 16 Feb 2018 21:09:57 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <23175.11397.220795.627967@fireball.acr.fi> Date: Fri, 16 Feb 2018 21:09:57 +0200 From: Tero Kivinen To: Yoav Nir Cc: ipsec@ietf.org In-Reply-To: <97670585-978A-4E58-AC8A-833EB8790754@gmail.com> References: <23175.8000.242283.548415@fireball.acr.fi> <97670585-978A-4E58-AC8A-833EB8790754@gmail.com> 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: Re: [IPsec] Additional charter items 4/4: Mitigating privacy concerns X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 19:10:05 -0000 Yoav Nir writes: > > 2) The privacy of the initiator's identity in the presence of a man= in > > the middle attacker is not protected. > >=20 > > Today an attacker with full control of the network can receive t= he > > IDi/IDr sent by the initiator in the first AUTH packet. We shoul= d > > add a mechanism to IKEv2 that allows the initiator to only send > > IDi/IDr to known entities (e.g. that possess a shared secret). >=20 > This is more feasible. I understand the issue, but the only use case > where I think it=E2=80=99s important is remote access. It would make = sense > in remote access to reverse the order of authentication so that the > responder identifies and authenticates first, but you=E2=80=99d still= need > the initiator to send the IDr first.=20 The reason why we defined IKEv2 so that initiator provides identity first, was that if responder provides identity first, then attackers can make probe attacks and collect identities of the remote peers, even when the IPsec is not currently in use. I.e., like we might run nmap to find out the open ports, this would also provide authenticated (if using certificateS) identity of the peer... --=20 kivinen@iki.fi From nobody Fri Feb 16 11:19:57 2018 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 D940C12AAB6 for ; Fri, 16 Feb 2018 11:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 T2dZ0TPwfRwq for ; Fri, 16 Feb 2018 11:19:54 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 489F71200C1 for ; Fri, 16 Feb 2018 11:19:54 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 22C8D20090 for ; Fri, 16 Feb 2018 14:26:59 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 997CF80B30 for ; Fri, 16 Feb 2018 14:19:53 -0500 (EST) From: Michael Richardson To: ipsec@ietf.org In-Reply-To: <23175.6913.726475.284090@fireball.acr.fi> References: <23175.6913.726475.284090@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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] Proposed charter text X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 19:19:56 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: > Here is the current proposed charter text about the items we managed to > agree in the IETF 100 meeting. I have left out the items we didn't > manage to have consensus, and I will send another email after this to > start discussion about them. > If you have comments (or objections) adding these new items to the > charter send your comments as soon as possible. I've read the new charter, and I think it's reasonable. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqHLtkACgkQgItw+93Q 3WXCOAgAs5spwP/NEjmjRzVqWxb5Xc4P/GVZv9+XsdRiXAGjImcNr7RkRQozSHtm 2Tnmo9mg1L2c4mtiQxhR23kdhGYxhYcIXG1p7fJvWpXK7RySxuBbB/T6CBT+VOOz u1j7hylTZctK+kAS5iHI5yzV3akYoUDJE+6AVLiTKp9KxlmYFhHTzIWPrdtrb/Qa mIhNEKUj761JwAWgcFBgAzMEakU1BZkymHeddRzboHTFlxV3dl24M/ZAdI0Lms+t 1zmxAXD9bpQVMHZUDEU2aRM7ruvvrBxlL4BFDtdf0/Uj0IjxVuRVSHy5SYkNeb7X hLCvralpEenN3653Z1EwDkU+g/BNXA== =e4KY -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 16 11:36:30 2018 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 04EDE1200C1 for ; Fri, 16 Feb 2018 11:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 QDffHnEjuatR for ; Fri, 16 Feb 2018 11:36:26 -0800 (PST) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A9BC12D7EF for ; Fri, 16 Feb 2018 11:36:26 -0800 (PST) Received: by mail-wr0-x22d.google.com with SMTP id b52so3944126wrd.10 for ; Fri, 16 Feb 2018 11:36:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=WMbHrLEblhpskzvxMEd+J88+WVgJ8IK71AefIE+1EnY=; b=tJIFZvdjwxGfEi12rdFU+oiw/dz5sU7bA6/3ypuBATLpLfRR7UPjYE+i5wlrtfhxuD vzu3iktdxc72xfPyIa0Ed/AKax1CXMlpQqBq4uwKJcg68igFelRa4aS1l5cobk7FGdkb /DkHYnjeYRtgBNyp20WGwOdCQSQMDtgzt2aWg4ldEZcXhWaFIyznmi9uu2oKYFjFp3Xp LW0RWKYujEcvG1kV599AhwHYJqO2dzoY9SZ+zE+5Cn9BI9bI7RtTbC9e8phjy9UxsoBu 2LRPrBbEEnrkr6Pyv41rlOVNkbQ0cuR6WbMK4WIpoqwKte0t1DCvWSyMenIDOP5Bv4PP 9Wlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=WMbHrLEblhpskzvxMEd+J88+WVgJ8IK71AefIE+1EnY=; b=StO0UWlvWAMDfl8nr4PE/SvDuTngriJ7E1nGU36dytNezKckPtVAe4RSJxK8amvbMS NkAMEDKEVeR2lHr5D5i19zqxlXb5B6W6Uq2rr7yu5m07eWxnEVKNC42kIOAV7AsgfsV/ QqHZDIjBop8BpLPNKK0RufvcTKKyFzzQdw2brizJZYSd8LgvfMqSVsj0q7IitBQ3DFpX QEXhjkFRMM7yV1viMh85x8+MryNWqZCpJIw+DP6Tl9p5PpsLp3zVH0WzvZeLHhN5gOTn meXUhm/AMvyVhqNrRSaUPu+wVFhQov7nTDAds+KJ2/QMsE+hh9lgiIYbjWoxX6eOkFOM nkhg== X-Gm-Message-State: APf1xPDenTzbUttGbaZ2LedhqCPpBq1iTIh9n1uDHlyodxnbSvOSN9zL 2T3zVBsz18i7bJvVcu7z3ndG/HNX X-Google-Smtp-Source: AH8x225Cy8ELurgfhl18cAh0SFWiiq9wc57iPuui6rw7WQZxNB/HtQrwui4qzoqEc52RRYlmrCcSCw== X-Received: by 10.223.148.37 with SMTP id 34mr7011036wrq.243.1518809785034; Fri, 16 Feb 2018 11:36:25 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id 19sm30565972wrv.0.2018.02.16.11.36.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Feb 2018 11:36:24 -0800 (PST) From: Yoav Nir Message-Id: <2D1FF22A-FD65-4365-BD17-2E434013A339@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_D675D3FB-C68F-4322-A388-B145372859D3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 16 Feb 2018 21:36:22 +0200 In-Reply-To: <23175.11397.220795.627967@fireball.acr.fi> Cc: ipsec@ietf.org To: Tero Kivinen References: <23175.8000.242283.548415@fireball.acr.fi> <97670585-978A-4E58-AC8A-833EB8790754@gmail.com> <23175.11397.220795.627967@fireball.acr.fi> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [IPsec] Additional charter items 4/4: Mitigating privacy concerns X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 19:36:29 -0000 --Apple-Mail=_D675D3FB-C68F-4322-A388-B145372859D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 16 Feb 2018, at 21:09, Tero Kivinen wrote: >=20 > Yoav Nir writes: >>> 2) The privacy of the initiator's identity in the presence of a man = in >>> the middle attacker is not protected. >>>=20 >>> Today an attacker with full control of the network can receive the >>> IDi/IDr sent by the initiator in the first AUTH packet. We should >>> add a mechanism to IKEv2 that allows the initiator to only send >>> IDi/IDr to known entities (e.g. that possess a shared secret). >>=20 >> This is more feasible. I understand the issue, but the only use case >> where I think it=E2=80=99s important is remote access. It would make = sense >> in remote access to reverse the order of authentication so that the >> responder identifies and authenticates first, but you=E2=80=99d still = need >> the initiator to send the IDr first. >=20 > The reason why we defined IKEv2 so that initiator provides identity > first, was that if responder provides identity first, then attackers > can make probe attacks and collect identities of the remote peers, > even when the IPsec is not currently in use. I.e., like we might run > nmap to find out the open ports, this would also provide authenticated > (if using certificateS) identity of the peer=E2=80=A6 I realize this, but one side has to identify itself first, and with = remote access I think it=E2=80=99s more important to protect the = initiator identity than to protect that fact that some organization has = an IPsec remote access concentrator. In fact we can run nmap and find which ports are open, and we can and do = scan for HTTP(S) servers on ports 80 and 443, and we do get their = certificates. --Apple-Mail=_D675D3FB-C68F-4322-A388-B145372859D3 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----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAlqHMrYACgkQuEkLFQpY zJm1igf/fPNG+TszP9BecfH5+Yi9QM86keTT67jpn9qowenEFKit9faDCWGQmrFT 5u2+Hy/yUNd7pO+ycKc1JIeH6zg7zaNorp1rbyeT4UQ7WzM1jubpnxuNNmSsSEkO CS6EAvVg9XMVvdOt5UE64sTE0XICkE8xCS0JYXaGzU2ERZNjGPY0FIUxzMmt72lY /mk0mgeLyjS0wYthwjS8wDG/PMLQ4uCfBXsj4J6M0I2ecDenFi8agkRa6BPA7oAu eW8sobYUxj+NV73S6c0T6rmypzBO5X1RHM8pGviQarkoiBUNP1bfp5r4VbmoEAZx T/Rat84v1OF+4K9PC/HOAk1vNAI5ow== =5zCP -----END PGP SIGNATURE----- --Apple-Mail=_D675D3FB-C68F-4322-A388-B145372859D3-- From nobody Fri Feb 16 11:49:45 2018 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 DBA28128896 for ; Fri, 16 Feb 2018 11:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 wk7W0fP-aiUg for ; Fri, 16 Feb 2018 11:49:41 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2ECF1200C1 for ; Fri, 16 Feb 2018 11:49:41 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zjkHj68ncz4Cc; Fri, 16 Feb 2018 20:49:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1518810577; bh=15e0eoH7+PWMDm1gM/hC9iTUkM1ugjZdkRQxtiR/y3o=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ZKTIORAQI2xQEBp5G8zBNpT1F8yG2vxQuPcO5MglqC2A1aP+sivB1nPZNqTsXSm2+ tNM9WCRbDZWGNgivNtNtUC5VuPUf6SUrnPpI4ay2DpsKhnUV1vgg4WqnwIOmRsYmBr hdJ2KazzMT+m8oXVeablBjyV9vJPxMXg8MxXG/pY= 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 YX97l9qfsAzY; Fri, 16 Feb 2018 20:49:36 +0100 (CET) Received: from bofh.nohats.ca (vpn.nohats.ca [193.110.157.148]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 16 Feb 2018 20:49:36 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id EA6DF30B3EC; Fri, 16 Feb 2018 14:49:33 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca EA6DF30B3EC Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E0BAB411ED37; Fri, 16 Feb 2018 14:49:33 -0500 (EST) Date: Fri, 16 Feb 2018 14:49:33 -0500 (EST) From: Paul Wouters To: Tero Kivinen cc: ipsec@ietf.org In-Reply-To: <23175.7597.238297.330233@fireball.acr.fi> Message-ID: References: <23175.7597.238297.330233@fireball.acr.fi> 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] Additional charter items 3/4: Labeled IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 19:49:44 -0000 On Fri, 16 Feb 2018, Tero Kivinen wrote: > The proposed charter text for this item is: > > ---------------------------------------------------------------------- > Some systems support security labels (aka security context) as one of > the selectors of the SPD. This label needs to be part of the IKE > negotiation for the IPsec SA. non-standard implementations exist for > IKEv1 (formerly abusing IPSEC Security Association Attribute 10, now > using private space IPSEC Security Association Attribute 32001). The > work is to standarize this for IKEv2. > ---------------------------------------------------------------------- > > Is that charter text clear enough? Is there enough people interested > in this? I brought it in, so I do agree it is clear enough. And after talking to some people in the working group, it seems this is ideally done using a new traffic selector. That would also satisfy Yoav's concern that there is no burden on implementations that dont want to support this. I will co-author a draft on this in time for IETF 101 :) Paul From nobody Fri Feb 16 11:51:04 2018 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 4DFED12D7EF for ; Fri, 16 Feb 2018 11:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 S0NbgBlHR4e5 for ; Fri, 16 Feb 2018 11:50:54 -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 01E1C128896 for ; Fri, 16 Feb 2018 11:50:54 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zjkK81XbHz4Cc; Fri, 16 Feb 2018 20:50:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1518810652; bh=bqT8n7NrbdsVNVAGYEzlI9Mm3pOWZM1tfVTd64Dt6gM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=jMAuMCjfqBHlAPiSNh4e8gD2Raiu7cslKI/DDc96826t0PL5j2zKc/C88MMk8FlSl wGCk8J9NiGmVxH+4GB/z1LuvhvYm2SGlVneYFXfaO0ZRd58yXWOqOya0qAYp/UIoas DTKHSJPOUP7ZyFpe/XPmUQCSTOHRMxRS4yQ/Uqtw= 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 Nd2REVCt_Y_F; Fri, 16 Feb 2018 20:50:51 +0100 (CET) Received: from bofh.nohats.ca (vpn.nohats.ca [193.110.157.148]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 16 Feb 2018 20:50:51 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 3EBD230B3EC; Fri, 16 Feb 2018 14:50:50 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 3EBD230B3EC Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 39997411ED37; Fri, 16 Feb 2018 14:50:50 -0500 (EST) Date: Fri, 16 Feb 2018 14:50:50 -0500 (EST) From: Paul Wouters To: Tero Kivinen cc: ipsec@ietf.org In-Reply-To: <23175.7445.247642.686611@fireball.acr.fi> Message-ID: References: <23175.7445.247642.686611@fireball.acr.fi> 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] Additional charter items 2/4: Address Failure Errors X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 19:50:57 -0000 On Fri, 16 Feb 2018, Tero Kivinen wrote: > The proposed charter text is: > > ---------------------------------------------------------------------- > RFC7296 defines a generic notification code that is related to a > failure to handle an internal address failure. That code does not > explicitly allow an initiator to determine why a given address family > is not assigned, nor whether it should try using another address > family. The Working Group will specify a set of more specific > notification codes that will provide sufficient information to the > IKEv2 initiator about the encountered failure. > draft-boucadair-ipsecme-ipv6-ipv4-codes will be used as a starting > point for this item. > ---------------------------------------------------------------------- I support further discussion on this topic to determine if the WG needs to write a document or not using the existing draft as starting point. Paul From nobody Fri Feb 16 11:51:35 2018 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 986CE128896 for ; Fri, 16 Feb 2018 11:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 5Uhyfqpggk7i for ; Fri, 16 Feb 2018 11:51:31 -0800 (PST) Received: from mail-in24.apple.com (mail-out24.apple.com [17.171.2.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABCE71200C1 for ; Fri, 16 Feb 2018 11:51:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1518810690; x=2382724290; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=A8mXm+4FZQd7zE6WiKN63Wg8Xc9AZndr3s73pj0c2ys=; b=qKvnETHOZlsDtB5RhH4ctNi6nSlO621j8nL/HKBH/2xYYr9Kc0B72Un8pv3ZuFq4 kp2kyMI8/XE6W+Xtv+qwVp0RrpaMxTaQjFQjYXCD18aHA48m0TQydjRGIUIR4RjV w3/2q2aocCjCj1J0rYRooVoxlzrGIxGHVfRjktvHWFa68oQZjXIjocNCWnczk02Z lmvi1KNiqgUbD5WhV9ut7LTy99E40tHlxW/+7IQODK4k8nrF+K8VDSyiNzP2cQ8o YUVKCJZX/daihbuLRqChZ2bM9dQ2gQ5d3y/JuZOmFkGe9x0qIpYrr+pKW0X9PB3Q Oqo8a73U0/h66FGw2AuO/w==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in24.apple.com (Apple Secure Mail Relay) with SMTP id 5A.79.10828.246378A5; Fri, 16 Feb 2018 11:51:30 -0800 (PST) X-AuditID: 11ab0218-d2dff70000002a4c-16-5a87364115bb Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by relay5.apple.com (Apple SCV relay) with SMTP id 6B.7B.23499.146378A5; Fri, 16 Feb 2018 11:51:29 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_5S709Pulq8D7azXNJiukLQ)" Received: from [17.234.68.209] (unknown [17.234.68.209]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180130 64bit (built Jan 30 2018)) with ESMTPSA id <0P4900MWZDTS0Q70@nwk-mmpp-sz10.apple.com>; Fri, 16 Feb 2018 11:51:29 -0800 (PST) Sender: dschinazi@apple.com From: David Schinazi Message-id: Date: Fri, 16 Feb 2018 11:51:28 -0800 In-reply-to: <97670585-978A-4E58-AC8A-833EB8790754@gmail.com> Cc: Tero Kivinen , ipsec@ietf.org To: Yoav Nir References: <23175.8000.242283.548415@fireball.acr.fi> <97670585-978A-4E58-AC8A-833EB8790754@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUi2FAYoetk1h5lsH+1msX+LS/YLI6ef85m sfTYByYHZo+ds+6yeyxZ8pPJ4/DXhSwBzFFcNimpOZllqUX6dglcGS/Ohxbs9q+48aqPpYHx i3MXIweHhICJRPvn5C5GLg4hgTVMEgdfrmDtYuQEi9/dcYUdInGIUeL5pOXMIAleAUGJH5Pv sYDYzAJhEltaVzFCFE1kkvjxqhUsISwgLdF14S4ryAY2AS2JA2uMIHptJFq2vIMq8ZOY0XeK HcRmEVCVeLm9nQ3E5hSwlXhxvZEZYr6hRN+SH4wgtoiAksThK1/B4kICmRI9u19BHaokMf37 bTaQGyQElrBJfJp3lmkCo9AsJLfOQnLrLKCTmAXUJaZMyYUIa0s8eXeBFcJWk1j4exETsvgC RrZVjMK5iZk5upl5RiZ6iQUFOal6yfm5mxhB0bGaSWIH45fXhocYBTgYlXh4HzxuixJiTSwr rsw9xCjNwaIkznv1eWOUkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkZ9o8U5qu7ClXETos/9 vPBJ5v5CriC+LcevfuJfenQ5X/3Dy/v3/5BYsPtuUX/qBvvKns1XTl/i+r7t4mWpPgNv1R9f 58drFCx6f2ymgke35csdc1bPk9qyz+9zx7MrsT8X/t3Q9kBtjevjL/Vvu8J+Rjsl7DT+crvy l3Hl86gAsdY3W5tdPObkKLEUZyQaajEXFScCANkGl0NvAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUi2FBcpeto1h5lcPaqjsX+LS/YLI6ef85m sfTYByYHZo+ds+6yeyxZ8pPJ4/DXhSwBzFFcNimpOZllqUX6dglcGS/Ohxbs9q+48aqPpYHx i3MXIyeHhICJxN0dV9i7GLk4hAQOMUo8n7ScGSTBKyAo8WPyPRYQm1kgTGJL6ypGiKKJTBI/ XrWCJYQFpCW6Ltxl7WLk4GAT0JI4sMYIotdGomXLO6gSP4kZfafYQWwWAVWJl9vb2UBsTgFb iRfXG5kh5htK9C35wQhiiwgoSRy+8hUsLiSQKdGz+xUrxKFKEtO/32abwMg/C8l5s5CcNwvo CmYBdYkpU3IhwtoST95dYIWw1SQW/l7EhCy+gJFtFaNAUWpOYqWpXmJBQU6qXnJ+7iZGcDAX Ruxg/L/M6hCjAAejEg/vg8dtUUKsiWXFlbnAMOJgVhLhZTBpjxLiTUmsrEotyo8vKs1JLT7E KM3BoiTO+zS4JUpIID2xJDU7NbUgtQgmy8TBKdXAuODlm3KD+d+WNJWKl4Srp2+ZH1G+UJcz 3OFLw1Up6VvHrE2+XUgWvlo42f3Nvdt/WaZ7XUs50yaas0rg0UrXOR93revzeyvPKOeS+Ijv +tHQNXslmF4eflv1+Ifazzq9+lbpNzvbY3e4f354uvwFw4TrmR7GxbrbXss0bNvGHsky2yiZ K8BCQYmlOCPRUIu5qDgRAN9ifW5iAgAA Archived-At: Subject: Re: [IPsec] Additional charter items 4/4: Mitigating privacy concerns X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 19:51:33 -0000 --Boundary_(ID_5S709Pulq8D7azXNJiukLQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Yoav, responses inline. > On Feb 16, 2018, at 10:25, Yoav Nir wrote: >=20 >> On 16 Feb 2018, at 20:13, Tero Kivinen wrote: >>=20 >> 1) It's not possible to run a server that obfuscates IKEv2/IPsec = using >> TLS. >>=20 >> Today thanks to RFC 8229 it is possible to run an IKEv2/IPsec >> server on TCP port 443 with TLS. However if a government agent >> tries to send an SA_INIT over that it will discover that this >> server runs IKEv2/IPsec, and may blacklist it. We should add a >> mechanism to IKEv2 that allows the server to only respond to >> SA_INIT from known entities (e.g. that possess a shared secret). >=20 > That would require that within the SA_INIT request, the initiator = proves possession of a shared secret and does so in a non-replayable = way. Actually, replay protection is not critical here. In the TLS scenario, = attackers would not be able to observe SA_INITs from trusted peers. In the privacy scenario, replaying the initiator SA_INIT will only get = the SA_INIT of the responder which doesn't include IDi/IDr. One approach to solving this would be to share a secret with the IKEv2 = config to all the clients and have the initiator HMAC its SA_INIT with = that secret. > Wouldn=E2=80=99t it be better for the initiator to prove identity or = group membership in the TLS handshake? As defined in RFC 8229, IKEv2 encapsulation does not rely on any = security properties from TLS. I don't think we should change that. Especially in the case of TLS <=3D = 1.2, the client certificates are not encrypted so this would defeat = privacy gains. >> 2) The privacy of the initiator's identity in the presence of a man = in >> the middle attacker is not protected. >>=20 >> Today an attacker with full control of the network can receive the >> IDi/IDr sent by the initiator in the first AUTH packet. We should >> add a mechanism to IKEv2 that allows the initiator to only send >> IDi/IDr to known entities (e.g. that possess a shared secret). >=20 > This is more feasible. I understand the issue, but the only use case = where I think it=E2=80=99s important is remote access. It would make = sense in remote access to reverse the order of authentication so that = the responder identifies and authenticates first, but you=E2=80=99d = still need the initiator to send the IDr first. Agreed, changing the order would protect the IDi but not the IDr. Thanks, David Schinazi= --Boundary_(ID_5S709Pulq8D7azXNJiukLQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Hi = Yoav, responses inline.

On Feb 16, 2018, at 10:25, Yoav = Nir <ynir.ietf@gmail.com> wrote:

On 16 Feb 2018, at 20:13, = Tero Kivinen <kivinen@iki.fi> wrote:

1) = It's not possible to run a server that obfuscates IKEv2/IPsec using
 TLS.

  Today = thanks to RFC 8229 it is possible to run an IKEv2/IPsec
  server on TCP port 443 with TLS. However if a = government agent
  tries to send an SA_INIT over = that it will discover that this
  server runs = IKEv2/IPsec, and may blacklist it. We should add a
  mechanism to IKEv2 that allows the server to only = respond to
  SA_INIT from known entities (e.g. = that possess a shared secret).

That would require that within the SA_INIT = request, the initiator proves possession of a shared secret and does so = in a non-replayable way.

Actually, = replay protection is not critical here. In the TLS scenario, attackers = would not be able to observe SA_INITs from trusted peers.
In = the privacy scenario, replaying the initiator SA_INIT will only get the = SA_INIT of the responder which doesn't include IDi/IDr.
One = approach to solving this would be to share a secret with the IKEv2 = config to all the clients and have the initiator HMAC its SA_INIT with = that secret.

Wouldn=E2=80=99t it be better for the initiator = to prove identity or group membership in the TLS handshake?

As defined = in RFC 8229, IKEv2 encapsulation does not rely on any security = properties from TLS.
I don't think we should change that. = Especially in the case of TLS <=3D 1.2, the client certificates are = not encrypted so this would defeat privacy gains.

2) The privacy of the = initiator's identity in the presence of a man in
 the = middle attacker is not protected.

  Today an attacker with full control of the = network can receive the
  IDi/IDr sent by the = initiator in the first AUTH packet. We should
  add a mechanism to IKEv2 that allows the = initiator to only send
  IDi/IDr to known = entities (e.g. that possess a shared secret).

This is more feasible. I understand the = issue, but the only use case where I think it=E2=80=99s important is = remote access. It would make sense in remote access to reverse the order = of authentication so that the responder identifies and authenticates = first, but you=E2=80=99d still need the initiator to send the IDr = first.

Agreed, changing the order would protect the IDi but = not the IDr.

Thanks,
David = Schinazi
= --Boundary_(ID_5S709Pulq8D7azXNJiukLQ)-- From nobody Fri Feb 16 11:52:41 2018 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 C82E1128896 for ; Fri, 16 Feb 2018 11:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 AsttFQuNmzzu for ; Fri, 16 Feb 2018 11:52:38 -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 8502E1200C1 for ; Fri, 16 Feb 2018 11:52:38 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zjkM92DHgz4Cc; Fri, 16 Feb 2018 20:52:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1518810757; bh=be7TqpmO+uArlymoGywH3rxoWM23w9GT2Rgvb9jn/7U=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=J31HaoOZYTtrK/GZXEAnoOfBOjQN1B3skBzSxkNDtGaeZCuWfJIolBdtWOrLYuYal thYCHVwYGTbmU8GT4y7z6S6Im0gVHcrfm0jJKcFRxD06O+/g/h3NMNvVxJgfN72CdB OOuqbndFkbRWn21Zgzo3iE6+LAjkQylp3d984yWA= 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 Zo2ljFFisGGd; Fri, 16 Feb 2018 20:52:36 +0100 (CET) Received: from bofh.nohats.ca (vpn.nohats.ca [193.110.157.148]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 16 Feb 2018 20:52:36 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 53D0E30B3EC; Fri, 16 Feb 2018 14:52:35 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 53D0E30B3EC Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4EB6F411ED37; Fri, 16 Feb 2018 14:52:35 -0500 (EST) Date: Fri, 16 Feb 2018 14:52:35 -0500 (EST) From: Paul Wouters To: Tero Kivinen cc: ipsec@ietf.org In-Reply-To: <23175.7252.256625.885691@fireball.acr.fi> Message-ID: References: <23175.7252.256625.885691@fireball.acr.fi> 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] Additional charter items 1/4: Responder MOBIKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 19:52:40 -0000 On Fri, 16 Feb 2018, Tero Kivinen wrote: > The proposed charter text is > > ---------------------------------------------------------------------- > > MOBIKE protocol [RFC4555] is used to move existing IKE/IPsec SA from > one IP address to another. However, in MOBIKE it is the initiator of > the IKE SA (i.e. remote access client) that controls this process. If > there are several responders each having own IP address and acting > together as a load sharing cluster, then it is desirable for them to > have ability to request initiator to switch to a particular member. > The working group will analyze the possibility to extend MOBIKE > protocol or to develop new IKE extension that will allow to build load > sharing clusters in an interoperable way. > > ---------------------------------------------------------------------- > > It could be also possible that we first start just researching whether > we actually need any protocol changes, and if so make specifications > for them, and if not, we might still want to publish some kind of > informational document describing how those existing mechanisms can be > used for this purpose. > > Send your comments and whether you support adding this to the charter > to the ipsec list in next two weeks. I support further discussion on this item, but I would like the discussion to focus first on the goal (failover/redundancy) and then look at solutions (maybe re-using/extending MOBIKE) Paul From nobody Fri Feb 16 11:59:50 2018 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 881BD128896 for ; Fri, 16 Feb 2018 11:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 44D817RfyfHa for ; Fri, 16 Feb 2018 11:59:48 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2291200C1 for ; Fri, 16 Feb 2018 11:59:48 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zjkWN6P3Jz4Cc; Fri, 16 Feb 2018 20:59:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1518811184; bh=lbBVDK/luZKOZh65kV+5BNEiUPUXgr4eN2QDNibcYaA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=WJW2Y+gp/d22RJpEh2PDFECxa4Zv4rrmotrCAjrEjVUCHMMm3HbxQyanPORT5TsFS ogMKnNVIGPSpTNCzABI53zvA8eQljbAXKCevXUl4Jjj1gDWV1NxQL++ZE5/Kna0nLd OROvyGnUkS3z7JNMikGhNJejsixDB3PYEtfEnn4I= 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 6_T6nCVNNEmk; Fri, 16 Feb 2018 20:59:43 +0100 (CET) Received: from bofh.nohats.ca (vpn.nohats.ca [193.110.157.148]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 16 Feb 2018 20:59:43 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 9889330B3EC; Fri, 16 Feb 2018 14:59:41 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 9889330B3EC Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9168E411ED37; Fri, 16 Feb 2018 14:59:41 -0500 (EST) Date: Fri, 16 Feb 2018 14:59:41 -0500 (EST) From: Paul Wouters To: Tero Kivinen cc: ipsec@ietf.org In-Reply-To: <23175.6913.726475.284090@fireball.acr.fi> Message-ID: References: <23175.6913.726475.284090@fireball.acr.fi> 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] Proposed charter text X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 19:59:49 -0000 On Fri, 16 Feb 2018, Tero Kivinen wrote: > The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated > RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), and the IPsec > security architecture (RFC 4301). IPsec is widely deployed in VPN > gateways, VPN remote access clients, and as a substrate for > host-to-host, host-to-network, and network-to-network security. Can we add "mesh" to this, eg: and as a substrate for host-to-host, host-to-network, network-to-network and mesh security. > Postquantum cryptography for IKEv2 (new) > > Postquantum Cryptography brings new key exchange methods. Most of > these methods that are known to date have much larger public keys > then conventional Diffie-Hellman public keys. Direct using these > methods in IKEv2 might lead to a number of problems due to the > increased size of initial IKEv2 messages. The working group will > analyze the possible problems and develop a solution, that will > make adding Postquantum key exchange methods more easy. The > solution will allow post quantum key exchange to be performed in > parallel with (or instead of) the existing Diffie-Hellman key > exchange. I think "develop a solution" is a bit too strong here. I think we are really "developing experiments to gain operational experience" and in a latter stage "focus on providing a single solution". I'm fine with all other charter items listed. Paul From nobody Fri Feb 16 12:09:19 2018 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 6A1D212D574 for ; Fri, 16 Feb 2018 12:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 aTqXx2ZkXyDt for ; Fri, 16 Feb 2018 12:09:17 -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 1331E1200C1 for ; Fri, 16 Feb 2018 12:09:17 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zjkkL2pg3z4Cc; Fri, 16 Feb 2018 21:09:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1518811754; bh=bMgMgDXUeV55IjajV7qHbhhj3FVV0v7GVpcaNtWFi0w=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=JWAz1e2uaoZ9Dko9g5WXn3YCwzpCSR2Isk2oc7P//eqGUl5g+jXgQQZ81lUkVzwr9 R/RxC8nuM+whso5uUKaVuSCqDacf8IZjDSds6yFSJrA4/l+fqxkqegA/SERNdWTLTS HI4HvVpVdoTj9LetlvY5PdGJ2f/3+0vtQ6lopdMQ= 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 0oEYO01_5kqU; Fri, 16 Feb 2018 21:09:13 +0100 (CET) Received: from bofh.nohats.ca (vpn.nohats.ca [193.110.157.148]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 16 Feb 2018 21:09:13 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 720DC30B3EC; Fri, 16 Feb 2018 15:09:11 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 720DC30B3EC Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 66349411ED37; Fri, 16 Feb 2018 15:09:11 -0500 (EST) Date: Fri, 16 Feb 2018 15:09:11 -0500 (EST) From: Paul Wouters To: Tero Kivinen cc: ipsec@ietf.org In-Reply-To: <23175.8000.242283.548415@fireball.acr.fi> Message-ID: References: <23175.8000.242283.548415@fireball.acr.fi> 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] Additional charter items 4/4: Mitigating privacy concerns X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 20:09:18 -0000 On Fri, 16 Feb 2018, Tero Kivinen wrote: > IKEv2 is currently vulnerable to the two following privacy concerns: > > 1) It's not possible to run a server that obfuscates IKEv2/IPsec using > TLS. > 2) The privacy of the initiator's identity in the presence of a man in > the middle attacker is not protected. > Is this something that we should add to charter? Do people understand > the issue? I would be in favour of adding this issue to the charter in some to be written text. Paul From nobody Fri Feb 16 12:15:37 2018 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 1831A12D7F1 for ; Fri, 16 Feb 2018 12:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCaSsDgBl6lv for ; Fri, 16 Feb 2018 12:15:34 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 E11DA129C53 for ; Fri, 16 Feb 2018 12:15:33 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w1GKFPnZ027961 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Feb 2018 22:15:25 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w1GKFOj7021479; Fri, 16 Feb 2018 22:15:24 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <23175.15324.37793.880546@fireball.acr.fi> Date: Fri, 16 Feb 2018 22:15:24 +0200 From: Tero Kivinen To: Yoav Nir Cc: ipsec@ietf.org In-Reply-To: <2D1FF22A-FD65-4365-BD17-2E434013A339@gmail.com> References: <23175.8000.242283.548415@fireball.acr.fi> <97670585-978A-4E58-AC8A-833EB8790754@gmail.com> <23175.11397.220795.627967@fireball.acr.fi> <2D1FF22A-FD65-4365-BD17-2E434013A339@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 5 min Archived-At: Subject: Re: [IPsec] Additional charter items 4/4: Mitigating privacy concerns X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 20:15:36 -0000 Yoav Nir writes: > > The reason why we defined IKEv2 so that initiator provides identity= > > first, was that if responder provides identity first, then attacker= s > > can make probe attacks and collect identities of the remote peers, > > even when the IPsec is not currently in use. I.e., like we might ru= n > > nmap to find out the open ports, this would also provide authentica= ted > > (if using certificateS) identity of the peer=E2=80=A6 >=20 > I realize this, but one side has to identify itself first, and with > remote access I think it=E2=80=99s more important to protect the init= iator > identity than to protect that fact that some organization has an > IPsec remote access concentrator. IKE is not unidirectional, it is not only client and server, it is host to host. I.e., the remote access initiator should also respond to the incoming connections as it might be the restarted remote peer reconnecting etc. There might actually be real IP connection between (i.e., no NAT) which allows remote peer to connect to you too :-) > In fact we can run nmap and find which ports are open, and we can > and do scan for HTTP(S) servers on ports 80 and 443, and we do get > their certificates.=20 For server yes, but my web browser does not listen port 80 or 443, and will not respond to them. My ipsec client will listen port 500 and 4500 and will respond to them. It might not allow incoming IKE=5FSA=5FINITs to them, or might not even implement them, but origina= lly IPsec was seen more host to host than client to server... --=20 kivinen@iki.fi From nobody Fri Feb 16 12:22:16 2018 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 B6F5012D77A for ; Fri, 16 Feb 2018 12:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4cTRIP7ItkB for ; Fri, 16 Feb 2018 12:22:14 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 9BF3C12D574 for ; Fri, 16 Feb 2018 12:22:13 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w1GKM7KH004997 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Feb 2018 22:22:08 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w1GKM7Ad021706; Fri, 16 Feb 2018 22:22:07 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23175.15727.942705.428208@fireball.acr.fi> Date: Fri, 16 Feb 2018 22:22:07 +0200 From: Tero Kivinen To: Paul Wouters Cc: ipsec@ietf.org In-Reply-To: References: <23175.6913.726475.284090@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min Archived-At: Subject: Re: [IPsec] Proposed charter text X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 20:22:14 -0000 Paul Wouters writes: > On Fri, 16 Feb 2018, Tero Kivinen wrote: > > > The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated > > RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), and the IPsec > > security architecture (RFC 4301). IPsec is widely deployed in VPN > > gateways, VPN remote access clients, and as a substrate for > > host-to-host, host-to-network, and network-to-network security. > > Can we add "mesh" to this, eg: > > and as a substrate for host-to-host, host-to-network, > network-to-network and mesh security. We could, but I think mesh is just host to host between lots of hosts pairs. I do not think we currently have anything that would really be directed for mesh security. > > Postquantum cryptography for IKEv2 (new) > > > > Postquantum Cryptography brings new key exchange methods. Most of > > these methods that are known to date have much larger public keys > > then conventional Diffie-Hellman public keys. Direct using these > > methods in IKEv2 might lead to a number of problems due to the > > increased size of initial IKEv2 messages. The working group will > > analyze the possible problems and develop a solution, that will > > make adding Postquantum key exchange methods more easy. The > > solution will allow post quantum key exchange to be performed in > > parallel with (or instead of) the existing Diffie-Hellman key > > exchange. > > I think "develop a solution" is a bit too strong here. We are developing solution to make adding postquantum key exchange methods easier. That does not necessarely mean we are solving the whole issue. > I think we are really "developing experiments to gain operational > experience" and in a latter stage "focus on providing a single > solution". Do you have proposed new text or actual changes for this item? -- kivinen@iki.fi From nobody Fri Feb 16 15:50:35 2018 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 492DE127241 for ; Fri, 16 Feb 2018 15:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 9M2eJitytSK1 for ; Fri, 16 Feb 2018 15:50:32 -0800 (PST) Received: from mail-in23.apple.com (mail-out23.apple.com [17.171.2.33]) (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 803CF1200C1 for ; Fri, 16 Feb 2018 15:50:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1518825031; x=2382738631; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1rKjwb7rvqKR+u3NR/28KROEyEz+JBP9l2+2bCxlbCA=; b=JTx0XvoMzFC0AOcLQwYT6n1/yr9AYdCq9lhUfc+gyXErCiV4SRUrP0cLexIBOQbe Rmylsi+CHW+Tw5mLl19jrpnnnYzWeXouaIlDNrk+7BubEinkLJ+EOKHOSWWAHgK+ J5VSFwLtSbzn2Z8wnJFhQigY/BH2TeX57+SDbMZ4c/WLYwTEGjLjxBkGR8Vrtbys gA/G86Tf/tc4eQC16WbrF64z4mDlRYOj+Gkfn3s31lo5mRGTohwOHo1ySTCPcVVv WPem70YC0YDt7MIY3osff1XNwv1U4NvFsz0bPqPMvclGidlHXlMM8O0+UHEWvgim 87C4MTJe/6dmrDtMFgxAcw==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in23.apple.com (Apple Secure Mail Relay) with SMTP id B2.8E.16187.74E678A5; Fri, 16 Feb 2018 15:50:31 -0800 (PST) X-AuditID: 11ab0217-fc9ff70000003f3b-65-5a876e476d56 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by relay8.apple.com (Apple SCV relay) with SMTP id 7C.7F.10701.64E678A5; Fri, 16 Feb 2018 15:50:30 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.235.14.118] (unknown [17.235.14.118]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180130 64bit (built Jan 30 2018)) with ESMTPSA id <0P49009YWOW5RQ70@nwk-mmpp-sz10.apple.com>; Fri, 16 Feb 2018 15:50:30 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: Date: Fri, 16 Feb 2018 15:50:28 -0800 Cc: Tero Kivinen , ipsec@ietf.org Content-transfer-encoding: quoted-printable Message-id: <8EB4F8E2-F3F9-45F4-AC76-985F900BA0EC@apple.com> References: <23175.8000.242283.548415@fireball.acr.fi> To: Paul Wouters X-Mailer: Apple Mail (2.3458) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUi2FCYpuue1x5l8Oa7vsX+LS/YLI6ef85m 8f7WJSYHZo8lS34yeRz+upDF4/s8pgDmKC6blNSczLLUIn27BK6MD3uXsBY8Yq+YPuU4awPj bLYuRk4OCQETialvXzF1MXJxCAmsZZL4/fIMI0zi4brNjBCJQ4wSPz5tZAVJ8AoISvyYfI+l i5GDg1lAXWLKlFyImolMEq9nf2MDiQsLSEhs3pMIUi4s4Ccxo+8UO4jNJqAicfzbBmaQEk4B R4mjm5VBwiwCqhK7r24DK2EWMJToW/KDEcLWlnjy7gLUVhuJ+UuugNUICeRKfHv1lwXEFhFQ lJh05hELxMmyEitn32UFOUdCYAqbRF/3I9YJjMKzkFw9C+HqWUhWLGBkXsUonJuYmaObmWdk rJdYUJCTqpecn7uJERTqq5nEdzB+fm14iFGAg1GJh7fjYVuUEGtiWXFl7iFGaQ4WJXHea88b o4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwdgV+nK3Dki3jlvvsM8u9dwdeRb4RNc3Yerv5 b6Bi29JH/ud2LWm48c/XeX+brObNZRs04+P6Xj9ey2i8TvDl5hcZ6yse2r81P6jzbNLanH+n XBdYf5daM9ExrtVuXuXtx9PafAK7uD0evXyZafWmNqPfb+rGlKJnBWHa5huNzxasOVi55THL JiWW4oxEQy3mouJEAOVJV9lWAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUi2FBcpeuW1x5lMG2XmcX+LS/YLI6ef85m 8f7WJSYHZo8lS34yeRz+upDF4/s8pgDmKC6blNSczLLUIn27BK6MD3uXsBY8Yq+YPuU4awPj bLYuRk4OCQETiYfrNjN2MXJxCAkcYpT48WkjK0iCV0BQ4sfkeyxdjBwczALqElOm5ELUTGSS eD37GxtIXFhAQmLznkSQcmEBP4kZfafYQWw2ARWJ4982MIOUcAo4ShzdrAwSZhFQldh9dRtY CbOAoUTfkh+MELa2xJN3F6C22kjMX3IFrEZIIFfi26u/LCC2iICixKQzj1ggTpaVWDn7LusE RoFZSA6dhXDoLCRTFzAyr2IUKErNSay00EssKMhJ1UvOz93ECA7MwrQdjE3LrQ4xCnAwKvHw PnjcFiXEmlhWXJkLDAkOZiURXgaT9igh3pTEyqrUovz4otKc1OJDjNIcLErivC+CW6KEBNIT S1KzU1MLUotgskwcnFINjE4zOObd4Dx67NPazOtbbXy8rLjUjsXqee5YU8W65anT52stN6aq Toqba2ak+4bfYMrjatMZd671Jdc6vtXqSVni6i95dqvkfS+16k9fLz15qarx20fpygePHp2a 33vbf9yV8T4RWua8K1UiUe/48oLiiX5fHRxLDnpc+Xto7plJnw8yNW+7cEaJpTgj0VCLuag4 EQBqv1a3SAIAAA== Archived-At: Subject: Re: [IPsec] Additional charter items 4/4: Mitigating privacy concerns X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 23:50:34 -0000 +1 to adding privacy text to the charter. This seems like it will be = increasingly relevant if we=E2=80=99re doing host-to-host communication = and we want to protect the privacy of various peers. =E2=80=94Tommy > On Feb 16, 2018, at 12:09 PM, Paul Wouters wrote: >=20 > On Fri, 16 Feb 2018, Tero Kivinen wrote: >=20 >> IKEv2 is currently vulnerable to the two following privacy concerns: >>=20 >> 1) It's not possible to run a server that obfuscates IKEv2/IPsec = using >> TLS. >=20 >> 2) The privacy of the initiator's identity in the presence of a man = in >> the middle attacker is not protected. >=20 >> Is this something that we should add to charter? Do people understand >> the issue? >=20 > I would be in favour of adding this issue to the charter in some to be > written text. >=20 > Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sun Feb 18 22:16:42 2018 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 AFC10127058 for ; Sun, 18 Feb 2018 22:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wdcqt_gjiSYv for ; Sun, 18 Feb 2018 22:16:39 -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 297A4126C89 for ; Sun, 18 Feb 2018 22:16:39 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 8EFB241558; Mon, 19 Feb 2018 07:16:37 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 777392006A; Mon, 19 Feb 2018 07:16:37 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0382.000; Mon, 19 Feb 2018 07:16:37 +0100 From: To: Tero Kivinen , "ipsec@ietf.org" Thread-Topic: [IPsec] Additional charter items 2/4: Address Failure Errors Thread-Index: AQHTp1CO7c1Gfi5aMUK2SJZZgDO4JaOrQt1A Date: Mon, 19 Feb 2018 06:16:36 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0D41BE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <23175.7445.247642.686611@fireball.acr.fi> In-Reply-To: <23175.7445.247642.686611@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.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Additional charter items 2/4: Address Failure Errors X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 06:16:40 -0000 Hi all,=20 I support this item, obviously.=20 Cheers, Med > -----Message d'origine----- > De=A0: IPsec [mailto:ipsec-bounces@ietf.org] De la part de Tero Kivinen > Envoy=E9=A0: vendredi 16 f=E9vrier 2018 19:04 > =C0=A0: ipsec@ietf.org > Objet=A0: [IPsec] Additional charter items 2/4: Address Failure Errors >=20 > This item has draft (draft-boucadair-ipsecme-ipv6-ipv4-codes) which > quite well the needs and why this is to done, and I think we do > undestand the item itself, but the charter text was not covered in the > IETF 100 meeting, so we did not get consensus call done for it. >=20 > The proposed charter text is: >=20 > ---------------------------------------------------------------------- > RFC7296 defines a generic notification code that is related to a > failure to handle an internal address failure. That code does not > explicitly allow an initiator to determine why a given address family > is not assigned, nor whether it should try using another address > family. The Working Group will specify a set of more specific > notification codes that will provide sufficient information to the > IKEv2 initiator about the encountered failure. > draft-boucadair-ipsecme-ipv6-ipv4-codes will be used as a starting > point for this item. > ---------------------------------------------------------------------- >=20 > Send your comments and whether you support adding this to the charter > to the ipsec list in next two weeks. > -- > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Feb 19 00:50:17 2018 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 789E712426E for ; Mon, 19 Feb 2018 00:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.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_LOW=-0.7, 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 XEi5y-SWhCcF for ; Mon, 19 Feb 2018 00:50:15 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955D4127058 for ; Mon, 19 Feb 2018 00:50:14 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id j193so12014086lfe.0 for ; Mon, 19 Feb 2018 00:50:14 -0800 (PST) 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=opB6G/C7loII3MSGU3vy2XG8hLHrd37JrAkXwVeSgd8=; b=Bf8zpV/aT4Fu/Kn7x63ICVMGWL89NqAHMfYUipqU8K6E64xocBsTC/qMdbwqyhK3im 1h2qoykUJ96pf844koHBoh+9qXtbrTv8SyoDjxNBhyIssCdyO6XyCQa0q0VgBXEhC7xK 5TU5YMKqr1U0wuifepk496XT0ML5l9nF7T7xb0/iLo3kzSql6qh+j8hl1IXPcCZytxHP 6+WwJf2SjTlabTKXX+Rl4pdc8NdcGQmfp1LPo1oZIKZ7zlK2YsGnsdzz7840UX5Cj91z LiiaKPweeG5LphIZfm2Kg+1k4PATlJ9oCkDHJ5mcij1YF0pYzi6aUkrnz6XXD80gP2nz 6isw== 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=opB6G/C7loII3MSGU3vy2XG8hLHrd37JrAkXwVeSgd8=; b=d90AZ0MLFAxCSMhCj8HeUDR32HseqXptjjAZ5BCD1DVVC7GXOE2td1dn99zaFYnz2P p7qYfJcBoy//HArTMJrCtV7ql3vY0a7f6yhczH2KEsIu5kVNln8ZzoC37ejp7hrfB5MR svAHJ8aIu0wcBXZ/kCwF2LTRUaQAZTFKQMXjpSTrc7EyKV7XO5wPafbIRAdggzb/irhq OWChj3kFv7YgBTo7J3KwmAjOdGmoRt09qxwlqOFYoAtgxBaqbMpVgPj8+++EXTQjfYpC 2Z+Sx4FEok3xDA5KIpchb2v5b8W5ehhJxDNFt3V4EEr4Z9Q4/0LJl20p7hdpB/RDVtLN 00cA== X-Gm-Message-State: APf1xPCc8T2qXCdKVsoZSJBH4Uf2zElZocsCtXGtwjGmbb9Ep5sMz2u5 YYe+Yxw/kGB3IrHVQtshoCV10w== X-Google-Smtp-Source: AH8x227nHiPQ63ZsKoU+eR2NUQAIoGRtFD7laG+cJObqf+9eKdJ2A9YKKLDMRmif9uRUSHEsR4lKsQ== X-Received: by 10.46.44.6 with SMTP id s6mr3764963ljs.111.1519030212277; Mon, 19 Feb 2018 00:50:12 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id n143sm4920556lfb.87.2018.02.19.00.50.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 19 Feb 2018 00:50:11 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" , References: <23175.7252.256625.885691@fireball.acr.fi> In-Reply-To: <23175.7252.256625.885691@fireball.acr.fi> Date: Mon, 19 Feb 2018 11:50:08 +0300 Message-ID: <02c501d3a95e$a5d73200$f1859600$@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: AQJXnlQnOgkoKoWaf0xqED6y+ZUK7KKjeP7Q Content-Language: ru Archived-At: Subject: Re: [IPsec] Additional charter items 1/4: Responder MOBIKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 08:50:16 -0000 Hi, > This is items we did not manage to reach full consensus in the IETF > 100 meeting. There were concerns and questions why this is needed and > why it cannot be done with already existing methods (mostly redirect > etc, or updating the address lists). > > The proposed charter text is > > ---------------------------------------------------------------------- > > MOBIKE protocol [RFC4555] is used to move existing IKE/IPsec SA from > one IP address to another. However, in MOBIKE it is the initiator of > the IKE SA (i.e. remote access client) that controls this process. If > there are several responders each having own IP address and acting > together as a load sharing cluster, then it is desirable for them to > have ability to request initiator to switch to a particular member. > The working group will analyze the possibility to extend MOBIKE > protocol or to develop new IKE extension that will allow to build load > sharing clusters in an interoperable way. > > ---------------------------------------------------------------------- > > It could be also possible that we first start just researching whether > we actually need any protocol changes, and if so make specifications > for them, and if not, we might still want to publish some kind of > informational document describing how those existing mechanisms can be > used for this purpose. > > Send your comments and whether you support adding this to the charter > to the ipsec list in next two weeks. I obviously support this item. The whole idea is that currently there is no interoperable way of building load-sharing IPsec clusters. To effectively balance their load the nodes of such cluster must be able to dynamically move clients from one node to another on node's discretion. So, in IKE terms, it is responder who must decide what another responder the initiator should continue to communicate with. What do we have now: 1. IKE redirect. It's the most obvious choice. However, IKE redirect requires that the client creates IKE SA with the node it is redirected to from scratch with full authentication. This is: 1) inefficient from resource consumption point of view 2) causes delays 3) most important - it may require user interaction (EAP authentication, or entering PIN to access user keys) that is completely unexpected to the user 2. IKE Redirect + IKE Resumption. Currently it is assumed that the client resumes to the same server it received the resumption ticket from, so some additional tweaking of IKE resumption is needed. This approach is more efficient than 1, however IPsec SAs still need to be recreated. 3. MOBIKE. In current MOBIKE only initial initiator can initiate change of IP addresses. If this problem is solved, then this is the best choice for load sharing clusters. I think that the problem is important and the WG should address it. I agree that some research would be useful. Regards, Valery. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Feb 19 03:05:29 2018 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 81FD7127286 for ; Mon, 19 Feb 2018 03:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.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_LOW=-0.7, 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 7AN8hd_faxod for ; Mon, 19 Feb 2018 03:05:26 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AD3812706D for ; Mon, 19 Feb 2018 03:05:26 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id h78so12503094lfg.6 for ; Mon, 19 Feb 2018 03:05:26 -0800 (PST) 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=wgy9SEcWprmvpufYVjiF+tQeclKIb2WiODvmC96Ckiw=; b=AcohK+7RUalUFGnoH8oo8Pwk26TXIZB49qc108Y8KPcOj+e2VyjyghAhMjB82mUMQ+ LveHfqWapQo06kq1kIbFUxkeI6nI+V6+Dy5EYjTjW6Q7MUo/TbfBQ9nQCzMNspA3T9Qz pDERqvdUzARwC3ktP0I37rlgdKD9hZaMOISSHtoNTObOU73hBC8iY/ITKSRarI1pgnGO /KsRJKnM9/B3rSbdPAc/TMLYMcW0UMKUsGisuAdhXyqGYWfim7oLagecRLsSIp/yYD+7 ad+xds5CGGUIuByoy9Z12K8esWC/+cwQwLblzwutSMDNhJweIt6+ZPe1LKBunuogfvzf gzjQ== 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=wgy9SEcWprmvpufYVjiF+tQeclKIb2WiODvmC96Ckiw=; b=R59aug9GaYrjmwfW8VnIvkXy2V5Zz5xa4tAbSjnUEtc/NvChhj/pYlX7cpZjQ1BxcB cBoiOQhFHOp8PZgNV45bkZ2Fxup6WDPUf9XB4+cBVtpUVklPiRfFZJCl++cAwS3G1nhM STrk0fA56WFKHf2/22SeGm3oQUVmPJxYGxBggQ6N+jiwP8wOnOFp1bbI4wUsrA9G3w4I nvEL6AMdz40nBLGkgH5SFMHYkbNAfoHX2ldFsY6ACtG74f5gkjK9tYxA/MMwCSSTQAHr BpR4/Gvu2pD0FMCNu16vbv5/4hZ7+gXw0DU6kLk3Vig0OB79XJv9KU06vEg5DLMe32yp D0Pg== X-Gm-Message-State: APf1xPDa5ePosnG6q10CTa+Dcvf9G6EiyJH16JD3AY/YwvXqpCtvZXC3 m97n4/v3Kp8/Wf2oFeS1tOAzBQ== X-Google-Smtp-Source: AH8x226DfNHLa3UPzoBNbXMYgOVdkbQt+8NKTL9M1nELH9WJpqSCm8qUjUli8WBSN9MPmqpLhMpmrg== X-Received: by 10.46.43.219 with SMTP id r88mr3099245ljr.26.1519038324283; Mon, 19 Feb 2018 03:05:24 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id h1sm4838862ljc.40.2018.02.19.03.05.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 19 Feb 2018 03:05:23 -0800 (PST) From: "Valery Smyslov" To: "'Yoav Nir'" , "'Tero Kivinen'" Cc: References: <23175.7597.238297.330233@fireball.acr.fi> In-Reply-To: Date: Mon, 19 Feb 2018 14:05:20 +0300 Message-ID: <02c601d3a971$88f36f10$9ada4d30$@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: AQHArCVmaASM19JtwaAXCstWC7w7QAHfJyvEo8KRUVA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Additional charter items 3/4: Labeled IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 11:05:27 -0000 Hi, > > Is there enough people interested > > in this? >=20 > I guess, since MLS keeps coming up=E2=80=A6 >=20 > I=E2=80=99m not, but I=E2=80=99m not opposed to doing this as long as = there=E2=80=99s no burden on non-supporting implementations. +1 Regards, Valery. From nobody Mon Feb 19 09:52:32 2018 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 B98B912420B for ; Mon, 19 Feb 2018 09:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nq3HrTk3Mymj for ; Mon, 19 Feb 2018 09:52:27 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50107.outbound.protection.outlook.com [40.107.5.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 009BE1241F5 for ; Mon, 19 Feb 2018 09:52:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3V3ZmyARY0BvBRYy7FYuP6IJBS01aSDFRww0rcbfxU4=; b=K69KX7T+Bs9ONGLfyETd0Xi1gp/W5VVIimURvc3fseuxQd3lM0nACmgX7REK9s1/JSOKaN3Jh9Z9KsDz6HFIluVdwfzRgqQL8hLDWyIozC6EPTN5+Po8Ql3b8MQpF/+OiCLdPPsmLwHUW3aPkzqpgo03nXKNCqqCCEps3miqQZI= Received: from AM4PR07MB3153.eurprd07.prod.outlook.com (10.171.188.142) by AM4PR07MB3476.eurprd07.prod.outlook.com (10.171.190.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.527.6; Mon, 19 Feb 2018 17:52:24 +0000 Received: from AM4PR07MB3153.eurprd07.prod.outlook.com ([fe80::296d:e6a1:bfb4:33e1]) by AM4PR07MB3153.eurprd07.prod.outlook.com ([fe80::296d:e6a1:bfb4:33e1%3]) with mapi id 15.20.0527.010; Mon, 19 Feb 2018 17:52:24 +0000 From: "Hu, Jun (Nokia - US/Mountain View)" To: Paul Wouters , Tero Kivinen CC: "ipsec@ietf.org" Thread-Topic: [IPsec] Additional charter items 3/4: Labeled IPsec Thread-Index: AQHTqapkaASM19JtwaAXCstWC7w7QA== Date: Mon, 19 Feb 2018 17:52:24 +0000 Message-ID: References: <23175.7597.238297.330233@fireball.acr.fi> In-Reply-To: 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=jun.hu@nokia.com; x-originating-ip: [135.245.20.30] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB3476; 7:k9g171w5FM00Htyhm8cWFMgE7VleVI51H3CgtUXnxx5MKBnt3mIodvovcBXLM7AMWEhh0rQJjprxxA7dTkaVW6mnrJWaEAi+3c8mCkrjU15OOI+IFtc4nrZmRYMBQd6D/eB3KvPju6IOZofiG2hs6qowQIqzzVrLSpHddEg1d3oMkvGuQ8vHCDTeDU6b1TQX5BbtNLpBTuTaAOXmfPoTlwyU3b2ku5ZDog6c/ft4Z0Afemo7OMpXJYeRamlKnxB1 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 33d5a669-f4d3-4673-ad8f-08d577c1884f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7193020); SRVR:AM4PR07MB3476; x-ms-traffictypediagnostic: AM4PR07MB3476: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(3231101)(11241501184)(806099)(944501161)(10201501046)(93006095)(93001095)(6055026)(6041288)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:AM4PR07MB3476; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB3476; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39380400002)(366004)(396003)(39860400002)(13464003)(189003)(199004)(3280700002)(14454004)(68736007)(33656002)(6246003)(4326008)(25786009)(5660300001)(478600001)(5250100002)(8936002)(8676002)(2900100001)(81166006)(305945005)(3660700001)(81156014)(74316002)(7736002)(66066001)(97736004)(966005)(86362001)(229853002)(59450400001)(102836004)(6506007)(53546011)(316002)(186003)(26005)(6116002)(2906002)(3846002)(105586002)(2950100002)(6436002)(53936002)(99286004)(76176011)(9686003)(55016002)(110136005)(6306002)(106356001)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB3476; H:AM4PR07MB3153.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ejcMP91q7E+3Brx8OL7Rk/8lpU0SscBhq5ZAfn4n8v9MSmnlF/xupVoJHw6EWpIFFBkGb+jGo7pSJWHOG2qfqattZrwwB+eqUDx4mI0A0HrHfymsVuC/k6FkLOGa3lTJOrqFechuz40dj36r4EGqjf8RiIyyDsBmoRwwyC1dN3I9P7Gi6H2JYgxnqj1W5xTS1Pf1HjqNcZGi8L5N/36Vxw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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: 33d5a669-f4d3-4673-ad8f-08d577c1884f X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2018 17:52:24.1172 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3476 Archived-At: Subject: Re: [IPsec] Additional charter items 3/4: Labeled IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 17:52:30 -0000 SSBhbSBhbHNvIGludGVyZXN0ZWQgaW4gdGhpcywgc2luY2UgY3VycmVudGx5IHRoZXJlIGlzIG5v IGdvb2Qgd2F5IHRvIGlkZW50aWZ5IGEgQ0hJTERfU0EsIGN1cnJlbnQgdHJhZmZpYyBzZWxlY3Rv ciBpcyB0b28gY3VtYmVyc29tZSB0byBiZSB1c2VkIGFzIGlkZW50aWZpZXIsIGFuZCBpbiBzb21l IGNhc2VzIGNhbid0IGJlIHVzZWQgYXMgYSBjb25zaXN0ZW50IGlkOyBmb3IgZXhhbXBsZSB0aGVy ZSBhcmUgdHdvIHR5cGVzIG9mIHRyYWZmaWMgKHNhbWUgcHJvdG9jb2wvcG9ydCwgYnV0IGRpZmZl cmVudCByZXNwb25kZXIgYWRkcmVzcykgbmVlZCB0byBiZSBwdXQgaW50byB0d28gZGlmZmVyZW50 IENISUxEX1NBLCBob3dldmVyIGluaXRpYXRvciBkb2Vzbid0IGtub3cgdGhlIHJlc3BvbmRlciBh ZGRyZXNzIHJhbmdlIGluIGFkdmFuY2UsIGN1cnJlbnRseSB0aGVyZSBpcyBubyB3YXkgZm9yIHJl c3BvbmRlciB0byBkaWZmZXJlbnRpYXRlOyANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBJUHNlYyBbbWFpbHRvOmlwc2VjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBQYXVsIFdvdXRlcnMNCj4gU2VudDogRnJpZGF5LCBGZWJydWFyeSAxNiwgMjAxOCAxMTo1 MCBBTQ0KPiBUbzogVGVybyBLaXZpbmVuIDxraXZpbmVuQGlraS5maT4NCj4gQ2M6IGlwc2VjQGll dGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbSVBzZWNdIEFkZGl0aW9uYWwgY2hhcnRlciBpdGVtcyAz LzQ6IExhYmVsZWQgSVBzZWMNCj4gDQo+IE9uIEZyaSwgMTYgRmViIDIwMTgsIFRlcm8gS2l2aW5l biB3cm90ZToNCj4gDQo+ID4gVGhlIHByb3Bvc2VkIGNoYXJ0ZXIgdGV4dCBmb3IgdGhpcyBpdGVt IGlzOg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IFNvbWUgc3lzdGVtcyBzdXBwb3J0IHNl Y3VyaXR5IGxhYmVscyAoYWthIHNlY3VyaXR5IGNvbnRleHQpIGFzIG9uZSBvZg0KPiA+IHRoZSBz ZWxlY3RvcnMgb2YgdGhlIFNQRC4gVGhpcyBsYWJlbCBuZWVkcyB0byBiZSBwYXJ0IG9mIHRoZSBJ S0UNCj4gPiBuZWdvdGlhdGlvbiBmb3IgdGhlIElQc2VjIFNBLiBub24tc3RhbmRhcmQgaW1wbGVt ZW50YXRpb25zIGV4aXN0IGZvcg0KPiA+IElLRXYxIChmb3JtZXJseSBhYnVzaW5nIElQU0VDIFNl Y3VyaXR5IEFzc29jaWF0aW9uIEF0dHJpYnV0ZSAxMCwgbm93DQo+ID4gdXNpbmcgcHJpdmF0ZSBz cGFjZSBJUFNFQyBTZWN1cml0eSBBc3NvY2lhdGlvbiBBdHRyaWJ1dGUgMzIwMDEpLiBUaGUNCj4g PiB3b3JrIGlzIHRvIHN0YW5kYXJpemUgdGhpcyBmb3IgSUtFdjIuDQo+ID4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiA+DQo+ID4gSXMgdGhhdCBjaGFydGVyIHRleHQgY2xlYXIgZW5vdWdoPyBJcyB0aGVyZSBl bm91Z2ggcGVvcGxlIGludGVyZXN0ZWQNCj4gPiBpbiB0aGlzPw0KPiANCj4gSSBicm91Z2h0IGl0 IGluLCBzbyBJIGRvIGFncmVlIGl0IGlzIGNsZWFyIGVub3VnaC4gQW5kIGFmdGVyIHRhbGtpbmcg dG8gc29tZQ0KPiBwZW9wbGUgaW4gdGhlIHdvcmtpbmcgZ3JvdXAsIGl0IHNlZW1zIHRoaXMgaXMg aWRlYWxseSBkb25lIHVzaW5nIGEgbmV3IHRyYWZmaWMNCj4gc2VsZWN0b3IuIFRoYXQgd291bGQg YWxzbyBzYXRpc2Z5IFlvYXYncyBjb25jZXJuIHRoYXQgdGhlcmUgaXMgbm8gYnVyZGVuIG9uDQo+ IGltcGxlbWVudGF0aW9ucyB0aGF0IGRvbnQgd2FudCB0byBzdXBwb3J0IHRoaXMuDQo+IA0KPiBJ IHdpbGwgY28tYXV0aG9yIGEgZHJhZnQgb24gdGhpcyBpbiB0aW1lIGZvciBJRVRGIDEwMSA6KQ0K PiANCj4gUGF1bA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gSVBzZWMgbWFpbGluZyBsaXN0DQo+IElQc2VjQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCg== From nobody Mon Feb 19 10:25:15 2018 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 B0D2A12420B for ; Mon, 19 Feb 2018 10:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koiIBStUYxNC for ; Mon, 19 Feb 2018 10:25:12 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30111.outbound.protection.outlook.com [40.107.3.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 144001204DA for ; Mon, 19 Feb 2018 10:25:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NVMptTFqYo5wxNrIe2LfMtq0yiv3vCK0vi725FYz564=; b=CFnS/Iy5Xxn16CbBIxOhB2eeVUdqIj/5JGnxYAQrjc1bKi24BDxobpFvH8Htt3Ery48Rw2DWKLGVMnuQN+vbMw/NQHefwVOgUpkCyB5TeISzQYVMr9HP7CVa4EC3YDWhTezSmbfbMqH57opnfHTb6JvntqrBzGHimsmM0aobq/A= Received: from AM4PR07MB3153.eurprd07.prod.outlook.com (10.171.188.142) by AM4PR07MB1619.eurprd07.prod.outlook.com (10.166.132.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.527.6; Mon, 19 Feb 2018 18:25:09 +0000 Received: from AM4PR07MB3153.eurprd07.prod.outlook.com ([fe80::296d:e6a1:bfb4:33e1]) by AM4PR07MB3153.eurprd07.prod.outlook.com ([fe80::296d:e6a1:bfb4:33e1%3]) with mapi id 15.20.0527.010; Mon, 19 Feb 2018 18:25:09 +0000 From: "Hu, Jun (Nokia - US/Mountain View)" To: Paul Wouters , Tero Kivinen CC: "ipsec@ietf.org" Thread-Topic: [IPsec] Additional charter items 1/4: Responder MOBIKE Thread-Index: AQHTqa74OgkoKoWaf0xqED6y+ZUK7A== Date: Mon, 19 Feb 2018 18:25:09 +0000 Message-ID: References: <23175.7252.256625.885691@fireball.acr.fi> In-Reply-To: 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=jun.hu@nokia.com; x-originating-ip: [135.245.20.30] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB1619; 7:Kt89HTNy99H+3+8m8n4NTXohr4He0Zm2dloigPnPS6rKL9Cjvs1KeFRQQfXmlxS5+ySdUwBoqvtSVy39x5SRutOR6syEKGIddEj7BoJL+tZSib4+HT+2QFYM6V3BrJXeQlvqns5qsIUHaDRZ6tdJgrCqZ8hXl2EU+mLjQy0MIhX2ckhUcg/VDKSuZcMHAATU0G/DOWh8xwE4rRdIKRJ4sePz+VAqK058jbNI3lvExhL0tiXC5Ns+V5jplT3SbMOW x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: bbd8501b-38bb-4db6-9ed2-08d577c61bd2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7193020); SRVR:AM4PR07MB1619; x-ms-traffictypediagnostic: AM4PR07MB1619: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231101)(11241501184)(806099)(944501161)(3002001)(10201501046)(6055026)(6041288)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:AM4PR07MB1619; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1619; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(366004)(39860400002)(376002)(346002)(396003)(13464003)(199004)(189003)(3280700002)(229853002)(86362001)(97736004)(305945005)(6506007)(53936002)(102836004)(478600001)(6436002)(8676002)(81166006)(26005)(81156014)(110136005)(8936002)(3846002)(2906002)(74316002)(316002)(3660700001)(7736002)(6116002)(186003)(76176011)(106356001)(99286004)(105586002)(14454004)(5660300001)(5250100002)(2950100002)(68736007)(4326008)(55016002)(6246003)(25786009)(6306002)(2900100001)(9686003)(66066001)(7696005)(33656002)(966005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1619; H:AM4PR07MB3153.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: JmXxhMzd6ZfSEO9usQP2N6GmmzAzO0JdqtVpG2GMKgK2pLhhJMr2NBZ/h6jx/waHP3IGg8HePF4uShNtqSZAoDAIsCP2pEeCG1wEVO0+ceVzvqzL8ovxlYhfQdK9zFexwUco0QDuU0W6HxPqxwisrqTbT8xm3ztPeY1A3bobIfTMAKk3iIc0eDpmadtGVJ5iy8GonvvduGovV+KWWz0bfg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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: bbd8501b-38bb-4db6-9ed2-08d577c61bd2 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2018 18:25:09.6186 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1619 Archived-At: Subject: Re: [IPsec] Additional charter items 1/4: Responder MOBIKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 18:25:13 -0000 KzENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJUHNlYyBbbWFpbHRv Omlwc2VjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXVsIFdvdXRlcnMNCg0KPiBJ IHN1cHBvcnQgZnVydGhlciBkaXNjdXNzaW9uIG9uIHRoaXMgaXRlbSwgYnV0IEkgd291bGQgbGlr ZSB0aGUgZGlzY3Vzc2lvbiB0bw0KPiBmb2N1cyBmaXJzdCBvbiB0aGUgZ29hbCAoZmFpbG92ZXIv cmVkdW5kYW5jeSkgYW5kIHRoZW4gbG9vayBhdCBzb2x1dGlvbnMNCj4gKG1heWJlIHJlLXVzaW5n L2V4dGVuZGluZyBNT0JJS0UpDQo+IA0KPiBQYXVsDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJUHNlYyBtYWlsaW5nIGxpc3QNCj4gSVBz ZWNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNl Yw0K From nobody Mon Feb 19 11:13:29 2018 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 720751204DA for ; Mon, 19 Feb 2018 11:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzuLlZp1duPa for ; Mon, 19 Feb 2018 11:13:24 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 67D00126C26 for ; Mon, 19 Feb 2018 11:13:24 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w1JJDKPE003795 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 19 Feb 2018 21:13:20 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w1JJDKur009645; Mon, 19 Feb 2018 21:13:20 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23179.8656.330909.562547@fireball.acr.fi> Date: Mon, 19 Feb 2018 21:13:20 +0200 From: Tero Kivinen To: "Valery Smyslov" Cc: In-Reply-To: <02c501d3a95e$a5d73200$f1859600$@gmail.com> References: <23175.7252.256625.885691@fireball.acr.fi> <02c501d3a95e$a5d73200$f1859600$@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 22 min X-Total-Time: 26 min Archived-At: Subject: Re: [IPsec] Additional charter items 1/4: Responder MOBIKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 19:13:27 -0000 Valery Smyslov writes: > 3. MOBIKE. In current MOBIKE only initial initiator can initiate change of IP addresses. > If this problem is solved, then this is the best choice for load sharing clusters. Mobike is symmetric in IKEv2 level. Either end can have multiple IP addresses and can change the address at will. The problem is that you want something else than that, i.e., you do not want responder to change IP address and start using that as you can with MOBIKE. I think what you are really wanting is to responder to signal and ask for the initiator to change the address because you assume there is NAT between and if the responder just starts sending packets from new source IP address then they do not reach the initiator? Note, the initiator do select the address pair to be used in the IPsec SA, but for the IKEv2 SA the exchange initiator selects which address pair is used. (RFC4555 section 2.1, last sentence of the 2nd paragraph). Also I think this can also already be done using standard RFC4555 mobike. In the section 3.5 says when the initiator should change the address and one of the examples it gives is: o An INFORMATIONAL request containing an ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is received. This means the peer's addresses may have changed. This is particularly important if the announced set of addresses no longer contains the currently used address. The responder can simply do following describined in the RFC4555 section 3.6: There is one additional complication: when the responder wants to update the address set, the currently used addresses may no longer work. In this case, the responder uses the additional address list received from the initiator, and the list of its own addresses, to determine which addresses to use for sending the INFORMATIONAL request. This is the only time the responder uses the additional address list received from the initiator. I.e., if it wants to move initiator from IP_R1 to IP_R2 it simply sends INFORMATIONAL exchange with source address of IP_R2 to IP_Ix and sends ADDITIONAL_*_ADDRESS or NO_ADDITIONAL_ADDRESSES describing the usable addresses and when initiator sees this it will immediately trigger to change the addresses used for IKEv2 SA and IPsec SA. Of course one of the issues that if there is restricted NAT between hosts then packet from IP_R2 will not reach the initiator, unless the initiator has opened that port pair also in the NAT (which it can do by sending probe/keepalive packets out to the responder using all address from the responder). So at least the charter text is misleading, as I think this can already be done without any problems with MOBIKE as long as there is no NATs between, and even if there is NAT, the initiator can simply send keepalives for all responder addresses, and then it works. Note, that even in that case there is no protocol changes with them, and even if the address update from responder never reaches the initiator the MOBIKE still works, as long as the responders stops responding to the IP_R1 address (i.e., the address where it wants the initiator to move away from). I.e., if responder has IP_R1 and IP_R2 addresses, and initiator is using IP_R1, and responder wants it to stop using it and move to IP_R2, then it is simply enough to stop responding to packets coming to the IP_R1. The initiator will detect this and move to use IP_R2... Yes, there will be short delay causing packets to be lost in this case. This delay will be eliminiated if the address update from responder reached initiator, i.e., if the initiator kept the ports open in NAT or if there is no NAT between. -- kivinen@iki.fi From nobody Tue Feb 20 07:24:46 2018 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 471CA127867 for ; Tue, 20 Feb 2018 07:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ve1We8XaxoLU for ; Tue, 20 Feb 2018 07:24:43 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625281242F7 for ; Tue, 20 Feb 2018 07:24:43 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id 70so4751576lfw.2 for ; Tue, 20 Feb 2018 07:24:43 -0800 (PST) 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=kKIZvnl84xHwzkQphlB2CT4IvG4RSL++ADiAZacqCMk=; b=kNOo4fG16YZX4hw2AcxjzMyEGd9ZmDylgJIFjNxVpmMHGCX9NG/d7HyHIF2C+YFBWf jiUXEJ+ojRuMa+i7rU+puV2TEMfz2Q3y4rC/9amOy4hpxi72EBq0ozHdfjQnOlftWUPf NoyxYdYOCEkg6+CqiFxXXYoqeFgu9mvI26z8kgg2ivn0c6LV15mY+pFhU5YX/Q1aqJq6 vNN8H8UgFjkrmXq4qG2/dA0Vb4cZ2/rK/vXMY8GOIyn0eiuMDG7Fgj+pi+/jraJ6fWGY iNEYXeYOuZO9lewuYR8FCmXEsVpvj9XDi0kNlFvdVCvuQ/mF0E+fQIeQmwYC3GB8R2US 92RA== 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=kKIZvnl84xHwzkQphlB2CT4IvG4RSL++ADiAZacqCMk=; b=O37Resq2N5StvbrMro65AsqdNl3n/AdzVwqusmXfNwTBj5mJRpcUocvS+mh4evEoec T1tGFpjPzQr/vc5Ll/6Wx9Ywp/9zIsVjxEcfJmlarG6IochSqcwKFmEiIc/VmfnqRqit v+uvt9X0S6phhglVk2KgqMHDSmnY5nkgf65JV3WKr+7ireR9rTl9FonRv7wcrpHHGlu9 skd+/yh3yTSKGpgC/lLoIU5Zg5lLgwgj+nUdWSj07P5tnYBkNDObfYi1eqdWpS7ge7Tq JWIFzZtJov5XOaEgaI65TNHSPIB20DDS9irX0TsaWP1uw3ic2VIuA9h6up0FmvkhkrfY FPjQ== X-Gm-Message-State: APf1xPCf0hVn0UwZvqAYY932LnB1D1eS25Lu1JHHTsRHj+sUBLGdgGW0 SEHN9DEjTJSPn79zvImvLPfxMQ== X-Google-Smtp-Source: AH8x22782Dj7gyd2gh9dA3F24+B+1ivlJ9IAO3dWtk9kfP2nCIFwByKCoCJzBx+oDYCew7nmVmXy5Q== X-Received: by 10.25.168.141 with SMTP id r135mr3674lfe.80.1519140281206; Tue, 20 Feb 2018 07:24:41 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id m74sm830700lfe.85.2018.02.20.07.24.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 20 Feb 2018 07:24:40 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" Cc: References: <23175.7252.256625.885691@fireball.acr.fi> <02c501d3a95e$a5d73200$f1859600$@gmail.com> <23179.8656.330909.562547@fireball.acr.fi> In-Reply-To: <23179.8656.330909.562547@fireball.acr.fi> Date: Tue, 20 Feb 2018 18:24:38 +0300 Message-ID: <038e01d3aa5e$ec66bc80$c5343580$@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: AQJXnlQnOgkoKoWaf0xqED6y+ZUK7AHZIA6IAi7r5FqihL8fsA== Content-Language: ru Archived-At: Subject: Re: [IPsec] Additional charter items 1/4: Responder MOBIKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 15:24:45 -0000 Hi Tero, > Valery Smyslov writes: > > 3. MOBIKE. In current MOBIKE only initial initiator can initiate change of IP addresses. > > If this problem is solved, then this is the best choice for load sharing clusters. > > Mobike is symmetric in IKEv2 level. Either end can have multiple IP > addresses and can change the address at will. This is true. However, it is the original initiator who decides which addresses to use. The original responder mostly plays passive role, only informing the initiator which addresses are available. > The problem is that you > want something else than that, i.e., you do not want responder to > change IP address and start using that as you can with MOBIKE. I think > what you are really wanting is to responder to signal and ask for the > initiator to change the address because you assume there is NAT > between and if the responder just starts sending packets from new > source IP address then they do not reach the initiator? Yes. > Note, the initiator do select the address pair to be used in the IPsec > SA, but for the IKEv2 SA the exchange initiator selects which address > pair is used. (RFC4555 section 2.1, last sentence of the 2nd > paragraph). It states that " the exchange initiator _can_ decide which addresses are used." While he/she definitely can, the exchange would fail in case of restricted NAT if the responder initiated the exchange from the IP address the NAT box has no mapping for. > Also I think this can also already be done using standard RFC4555 > mobike. In the section 3.5 says when the initiator should change the > address and one of the examples it gives is: > > o An INFORMATIONAL request containing an ADDITIONAL_IP4_ADDRESS, > ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification > is received. This means the peer's addresses may have changed. > This is particularly important if the announced set of addresses > no longer contains the currently used address. > > The responder can simply do following describined in the RFC4555 > section 3.6: > > There is one additional complication: when the responder wants to > update the address set, the currently used addresses may no longer > work. In this case, the responder uses the additional address list > received from the initiator, and the list of its own addresses, to > determine which addresses to use for sending the INFORMATIONAL > request. This is the only time the responder uses the additional > address list received from the initiator. If original responder used its address the NAT box has no mapping for yet, the exchange would fail. > I.e., if it wants to move initiator from IP_R1 to IP_R2 it simply > sends INFORMATIONAL exchange with source address of IP_R2 to IP_Ix and > sends ADDITIONAL_*_ADDRESS or NO_ADDITIONAL_ADDRESSES describing the > usable addresses and when initiator sees this it will immediately > trigger to change the addresses used for IKEv2 SA and IPsec SA. > > Of course one of the issues that if there is restricted NAT between > hosts then packet from IP_R2 will not reach the initiator, unless the > initiator has opened that port pair also in the NAT (which it can do > by sending probe/keepalive packets out to the responder using all > address from the responder). In MOBIKE the initiator is not obliged to do this. Section 3.10: Implementations MAY do path testing even if the path currently being used is working to, for example, detect when a better (but previously unavailable) path becomes available. > So at least the charter text is misleading, as I think this can > already be done without any problems with MOBIKE as long as there is > no NATs between, and even if there is NAT, the initiator can simply > send keepalives for all responder addresses, and then it works. If there is no NAT in between, then there is no problem. In real life there is a NAT in most cases. And while in presence of NAT in theory unmodified MOBIKE _may_ work, there are too many vague places in the RFC that makes this problematic: - the initiator is not obliged to probe addresses other than the currently used ones - even if it probes, it may do it too rarely, so that the created NAT mapping will expire So, there is no guarantee for a cluster that the operation of moving a client from one node to another will succeed. I'd like such operations to be more deterministic. > Note, that even in that case there is no protocol changes with them, and > even if the address update from responder never reaches the initiator > the MOBIKE still works, as long as the responders stops responding to > the IP_R1 address (i.e., the address where it wants the initiator to > move away from). > > I.e., if responder has IP_R1 and IP_R2 addresses, and initiator is > using IP_R1, and responder wants it to stop using it and move to > IP_R2, then it is simply enough to stop responding to packets coming > to the IP_R1. The initiator will detect this and move to use IP_R2... > Yes, there will be short delay causing packets to be lost in this > case. We seem to have different view of what "short" means :-) The initiator doesn't sent liveness checks continuously. It start probing current path if it suspects there is something wrong with it, e.g. there is no IPsec packets from the responder for some period of time. This period cannot be too short, it is usually tens of seconds to minute. Then, when starting probing the current path the initiator performs several retransmissions before giving up. And again, the timeout cannot be too short, it is usually at least ten seconds, more likely about a minute. So your "short" delay is at least about a minute, or even more. I don't think this delay is appropriate for any real-time traffic. Needless to say that this approach also complicates cluster implementation. To move a client from one node to another the cluster needs first to send ADDITIONAL_*_ADDRESS that contains only the address of the node the cluster wants to move client to. Then the IKE SA state must be transferred to a new node and the current node must stop responding to this client. Then the cluster would wait until the client detects the failure and switches itself to a new node. And there is also a chance that there are some IKE exchanges in progress, so if the node stops responding the exchanges could time out the and the IKE SA would be deleted before the movement takes place (in my proposal the MOBIKE is combined with RFC6311 exchange to make this working)... > This delay will be eliminiated if the address update from > responder reached initiator, i.e., if the initiator kept the ports > open in NAT or if there is no NAT between. There is absolutely no guarantee that it will work. I'd like to have something more reliable. Regards, Valery. > -- > kivinen@iki.fi From nobody Tue Feb 20 14:15:15 2018 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 60D7A126DFB for ; Tue, 20 Feb 2018 14:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5-mhTO1okRD for ; Tue, 20 Feb 2018 14:15:12 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 F1E331200B9 for ; Tue, 20 Feb 2018 14:15:09 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w1KMF66T022756 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Feb 2018 00:15:06 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w1KMF6T3004901; Wed, 21 Feb 2018 00:15:06 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23180.40426.204224.108279@fireball.acr.fi> Date: Wed, 21 Feb 2018 00:15:06 +0200 From: Tero Kivinen To: "Valery Smyslov" Cc: In-Reply-To: <038e01d3aa5e$ec66bc80$c5343580$@gmail.com> References: <23175.7252.256625.885691@fireball.acr.fi> <02c501d3a95e$a5d73200$f1859600$@gmail.com> <23179.8656.330909.562547@fireball.acr.fi> <038e01d3aa5e$ec66bc80$c5343580$@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 32 min X-Total-Time: 31 min Archived-At: Subject: Re: [IPsec] Additional charter items 1/4: Responder MOBIKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 22:15:14 -0000 Valery Smyslov writes: > > The responder can simply do following describined in the RFC4555 > > section 3.6: > > > > There is one additional complication: when the responder wants to > > update the address set, the currently used addresses may no longer > > work. In this case, the responder uses the additional address list > > received from the initiator, and the list of its own addresses, to > > determine which addresses to use for sending the INFORMATIONAL > > request. This is the only time the responder uses the additional > > address list received from the initiator. > > If original responder used its address the NAT box has no > mapping for yet, the exchange would fail. True, but there is nothing in the proposed charter text talking about NATs. It seems the issues only appear if there is restricted NAT between, and even then it only fails if the initiator does not keep ports open in NAT. > > I.e., if it wants to move initiator from IP_R1 to IP_R2 it simply > > sends INFORMATIONAL exchange with source address of IP_R2 to IP_Ix and > > sends ADDITIONAL_*_ADDRESS or NO_ADDITIONAL_ADDRESSES describing the > > usable addresses and when initiator sees this it will immediately > > trigger to change the addresses used for IKEv2 SA and IPsec SA. > > > > Of course one of the issues that if there is restricted NAT between > > hosts then packet from IP_R2 will not reach the initiator, unless the > > initiator has opened that port pair also in the NAT (which it can do > > by sending probe/keepalive packets out to the responder using all > > address from the responder). > > In MOBIKE the initiator is not obliged to do this. Section 3.10: > > Implementations MAY do path testing even if > the path currently being used is working to, for example, detect when > a better (but previously unavailable) path becomes available. But it is allowed to do so. If you want to implementations to be able to talk to servers having multiple responder IP address and not cause delays, perhaps your implementation should do what it "MAY" do.... > > So at least the charter text is misleading, as I think this can > > already be done without any problems with MOBIKE as long as there is > > no NATs between, and even if there is NAT, the initiator can simply > > send keepalives for all responder addresses, and then it works. > > If there is no NAT in between, then there is no problem. > > In real life there is a NAT in most cases. Use IPv6 :-) Then there will not be problems with NATs... Firewalls might be another matter though. > And while in presence > of NAT in theory unmodified MOBIKE _may_ work, there are too many > vague places in the RFC that makes this problematic: > - the initiator is not obliged to probe addresses other than the currently used ones > - even if it probes, it may do it too rarely, so that the created NAT mapping > will expire There is no timers in the RFC specified for any of these operations, all of them are implementation details. This is something that will NOT affect interoperability, but will affect how well your implementation works. If this is important matter for your implementation you should research and study the problem and tune the parameters suitable for your normal use case. > So, there is no guarantee for a cluster that the operation > of moving a client from one node to another will succeed. > I'd like such operations to be more deterministic. Even if we make some changes in the protocol, there will be implementations out there which do not implement them, thus there will never be full deterministic behavior of ther prosess for all possible clients. > > Note, that even in that case there is no protocol changes with them, and > > even if the address update from responder never reaches the initiator > > the MOBIKE still works, as long as the responders stops responding to > > the IP_R1 address (i.e., the address where it wants the initiator to > > move away from). > > > > I.e., if responder has IP_R1 and IP_R2 addresses, and initiator is > > using IP_R1, and responder wants it to stop using it and move to > > IP_R2, then it is simply enough to stop responding to packets coming > > to the IP_R1. The initiator will detect this and move to use IP_R2... > > Yes, there will be short delay causing packets to be lost in this > > case. > > We seem to have different view of what "short" means :-) It should detect it in few tens of seconds, and probes should find the working path in tens of seconds more, or so. I.e., this should happen in well under a minute. Of course if you have bad implementation in the client end which for example does not detect that traffic changes to unidirectional, and does not start IKEv2 probe soon after that, then you might have much longer timers. Also if your IKEv2 retransmission timers are in orders of minutes, and MOBIKE probes are using them without changes, then it might take several minutes to fix this issue. > The initiator doesn't sent liveness checks continuously. Initiator SHOULD NEVER send liveness checks continuously. If it does that it is broken. It SHOULD only send liveness checks when there is some reason to belive there is something funny going on. It might for example receive ICMP destination port unreachable or unprotected IKE notify, and that should trigger liveness check (responder can send this message out when it decides to move the client to another peer, as it will not be responding to the port 500 / 4500 UDP messages for that host anymore). It might also detect that traffic changed to be unidirectional, i.e., no reply packets coming back to any of the IPsec SAs, and this should again trigger liveness check. It should not really do any liveness checks on periodic bases, doing so is just plain stupid (and not specified in the RFC7296). Section 2.4 of RFC7296: ---------------------------------------------------------------------- ... If there has only been outgoing traffic on all of the SAs associated with an IKE SA, it is essential to confirm liveness of the other endpoint to avoid black holes. If no cryptographically protected messages have been received on an IKE SA or any of its Child SAs recently, the system needs to perform a liveness check in order to prevent sending messages to a dead peer. ---------------------------------------------------------------------- Section 2.21.4 of RFC7296: ---------------------------------------------------------------------- ... A node should treat such a message (and also a network message like ICMP destination unreachable) as a hint that there might be problems with SAs to that IP address and should initiate a liveness check for any such IKE SA. ---------------------------------------------------------------------- > It start probing current path if it suspects there is something wrong with it, > e.g. there is no IPsec packets from the responder for some period > of time. This period cannot be too short, it is usually tens of seconds > to minute. In normal case having it in ten seconds or so is quite good value, as in most cases the traffic is bidirectional (TCP with acks, UDP with some kind of ACKs / return packets). When traffic changes to be unidirectional then it can do the liveness check, and if it succeeds and even if the traffic still stays unidirectional it does not need to do livenss checks too often, as traffic has not changed to be unidirectional it is still unidirectional, and then once every few minutes is good enough. > Then, when starting probing the current path the initiator > performs several retransmissions before giving up. And again, the timeout > cannot be too short, it is usually at least ten seconds, more likely > about a minute. So your "short" delay is at least about a minute, > or even more. Initial timeout is usually less than a second (0.5 seconds or so), doubling after each packet, will give you 5 retransmissions in 10 seconds, and after that you can move to next address, especially if fast recovery is important for your use case. In most cases you have only one IP address for yourself (or if you have multiple, all of them work), and in this case you would have two for responder, so immediately when you move to 2nd address that will work. The delay should be less than minute. > I don't think this delay is appropriate for any real-time traffic. If you care about real-time traffic, then you should keep your NAT mappings up for all peers, so you will get the address update message, and can move to new address immediately when you receive it. > Needless to say that this approach also complicates cluster implementation. > To move a client from one node to another the cluster needs first to > send ADDITIONAL_*_ADDRESS that contains only the address of the node > the cluster wants to move client to. This is unavoidable. The responder needs to somehow tell the initiator where it wants it to move. Whether it does it using standard MOBIKE message, or some newly defined MOBIKE message, it does not matter. It still needs to do exactly same thing. Except the first one is already defined in the RFC4555. > Then the IKE SA state must be transferred to a new node and the > current node must stop responding to this client. You need to move the IKE SA anyways, and you need to move it before you send any update which says there is another IP address to be used. And both ends MUST be able to process IKE and IPsec SA packets at the same time if we want to make sure no packets are lost during the transition (if you really care about real-time traffic). Again this is something that must be done in both cases. > Then the cluster would wait until the client detects the failure and > switches itself to a new node. And there is also a chance that there > are some IKE exchanges in progress, so if the node stops responding > the exchanges could time out the and the IKE SA would be deleted > before the movement takes place (in my proposal the MOBIKE is > combined with RFC6311 exchange to make this working)... If you are using MOBIKE, then the IKE exchange should not time out before it has tried all possible addresses, thus there is no issue in there. > > This delay will be eliminiated if the address update from > > responder reached initiator, i.e., if the initiator kept the ports > > open in NAT or if there is no NAT between. > > There is absolutely no guarantee that it will work. > I'd like to have something more reliable. Knowing that there are so broken implementations of IPsec and IKE out there that still use periodic liveness checks for example, there will never be any guarantee that any of these will work... Even if we defined some new method for transferring this information to the other end that will not mean that it will get implemented correctly on the clients :-) Anyways as the current proposed charter text does not really describe the problem you are trying to solve, at least it needs to be updated to properly state the problem. I.e., you are not trying to make the responder side MOBIKE, you are trying to get responder MOBIKE messages through restricted NAT / firewall.... -- kivinen@iki.fi From nobody Wed Feb 21 07:35:16 2018 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 1916012D7F4 for ; Wed, 21 Feb 2018 07:35:13 -0800 (PST) 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 uIPmEBEGWf7L for ; Wed, 21 Feb 2018 07:35:11 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB186124B17 for ; Wed, 21 Feb 2018 07:35:10 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id 37so2931843lfs.7 for ; Wed, 21 Feb 2018 07:35:10 -0800 (PST) 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=h5f0PVj0lSb86ZLjx8HmI2Ny8MIPpjO7ErQx9erXlRA=; b=VDLuqyGlge4aycPSHfQYuQnZGzl+Es+G6HIkXd73jPbriH24MUixCQeToN+qkdVaKe tSnH0JHpyxe4Dw3AUGPCeZCQSiEdXRlmHNjp0U+u+Hm4pA9+8SZQWM45T1YZm2Jctr0h eWxG11yVXcTjNpEWn3SqCgxk06dx6Uu/8o+jyCpk+Wlc1YSgQZ9ZjLuBG3rpmUeTxUD9 8ZZix5qbD/cRS4Bc4l11CnkYx3l9HQI+rmFhdpbbMM7Ke02IPC/4Nmfd+CY0uDQijPYS 6TdjTb9efnRTvVo88WD9kQuWSmMIAlcVMpnufCDN6RBjyxIsNz1n79MBpQDI17FAHZXK 0gCg== 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=h5f0PVj0lSb86ZLjx8HmI2Ny8MIPpjO7ErQx9erXlRA=; b=DifU7J9Y4VwM2ex6SugI+Cyzt5Le2lPNSkX+enei5uT7imPFSq0RjzWog0VU0I37ri e4/Q5C7YU2Bmt5rtC7+HqJPpRLBVAUPJz9A7FktCw/228Nv+h6qtHwac1LJJLlEARgMV ZSS8JzQnj8XCeCaOcnormidrDlmNmMQUXtyhU6gaNG7lILL8PPi2251+M6/98OdhNni2 GjJz0yE0hN3YzKn8O02a078HRTvpiVfL18dGB3Tcg0sAkS4wuKWdVi7aiaEPlFf+FO0L vRKfp8Z7mOQVowJQTLKQej2hSA8vMrBcWEHx302g3LossqGclbbfgLV1kG0XPmv81Bfy ttzQ== X-Gm-Message-State: APf1xPCaULmJnKr62loKHCkeSHwH8QYJzIBCLnwXhQQwm5Pzc/pE3Pc/ SNR0mrWMcZjKtybW70KGTFzL7g== X-Google-Smtp-Source: AH8x224Gu/oBcyIeqwTwbDgoFuGR3L+QEc0a633/TY0ixQux9wmrjzgOK8lX1u2yDOYmnPNGZmIRuw== X-Received: by 10.46.112.21 with SMTP id l21mr2505055ljc.45.1519227308362; Wed, 21 Feb 2018 07:35:08 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id t10sm92671ljt.49.2018.02.21.07.35.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 21 Feb 2018 07:35:07 -0800 (PST) From: "Valery Smyslov" To: "'Tero Kivinen'" Cc: References: <23175.7252.256625.885691@fireball.acr.fi> <02c501d3a95e$a5d73200$f1859600$@gmail.com> <23179.8656.330909.562547@fireball.acr.fi> <038e01d3aa5e$ec66bc80$c5343580$@gmail.com> <23180.40426.204224.108279@fireball.acr.fi> In-Reply-To: <23180.40426.204224.108279@fireball.acr.fi> Date: Wed, 21 Feb 2018 18:35:05 +0300 Message-ID: <043901d3ab29$8c980c20$a5c82460$@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: AQJXnlQnOgkoKoWaf0xqED6y+ZUK7AHZIA6IAi7r5FoC17kq+wLRnswoolj5CBA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Additional charter items 1/4: Responder MOBIKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 15:35:13 -0000 > > If original responder used its address the NAT box has no > > mapping for yet, the exchange would fail. > > True, but there is nothing in the proposed charter text talking about > NATs. It seems the issues only appear if there is restricted NAT > between, and even then it only fails if the initiator does not keep > ports open in NAT. The proposed charter text is generic enough, we may make it more specific. > > In MOBIKE the initiator is not obliged to do this. Section 3.10: > > > > Implementations MAY do path testing even if > > the path currently being used is working to, for example, detect when > > a better (but previously unavailable) path becomes available. > > But it is allowed to do so. If you want to implementations to be able > to talk to servers having multiple responder IP address and not cause > delays, perhaps your implementation should do what it "MAY" do.... The cluster never knows if the client does this or not. So "my" implementation in this case is a cluster and I cannot determine if any given client honor this "MAY" or not. > > > So at least the charter text is misleading, as I think this can > > > already be done without any problems with MOBIKE as long as there is > > > no NATs between, and even if there is NAT, the initiator can simply > > > send keepalives for all responder addresses, and then it works. > > > > If there is no NAT in between, then there is no problem. > > > > In real life there is a NAT in most cases. > > Use IPv6 :-) Good advice, cap :-) > Then there will not be problems with NATs... > > Firewalls might be another matter though. Sure. > > And while in presence > > of NAT in theory unmodified MOBIKE _may_ work, there are too many > > vague places in the RFC that makes this problematic: > > - the initiator is not obliged to probe addresses other than the currently used ones > > - even if it probes, it may do it too rarely, so that the created NAT mapping > > will expire > > There is no timers in the RFC specified for any of these operations, > all of them are implementation details. This is something that will > NOT affect interoperability, but will affect how well your > implementation works. If this is important matter for your > implementation you should research and study the problem and tune the > parameters suitable for your normal use case. We are talking about different things. You are trying to convince me that the cluster functionality _can_ be achieved with the current MOBIKE. I don't disagree, but I'm pointing out, that in this case it is relied on completely _optional_ features specified in RFC and there is no indication whether and how peer supports these features. These features don't affect MOBIKE interoperability, but they do affect whether unmodified MOBIKE can be used for cluster scenario. Again, I'm not insisting that my proposal is the only and the best solution. Probably we can use the approach you suggested, but in this case some extension to the MOBIKE should be added that will make these features non optional and will add a negotiation (or announcement) mechanism, so that implementations can rely on peer's behavior. > > So, there is no guarantee for a cluster that the operation > > of moving a client from one node to another will succeed. > > I'd like such operations to be more deterministic. > > Even if we make some changes in the protocol, there will be > implementations out there which do not implement them, thus there will > never be full deterministic behavior of ther prosess for all possible > clients. If we make these changes to the protocol so that the cluster is aware of clients capabilities, then the cluster will always know whether try to move any particular client or let him/her alone. The situation will be more deterministic. > > We seem to have different view of what "short" means :-) > > It should detect it in few tens of seconds, and probes should find the > working path in tens of seconds more, or so. I.e., this should happen > in well under a minute. That was my conclusion too. And I don't think that about a minute is a "short delay". > > The initiator doesn't sent liveness checks continuously. > > Initiator SHOULD NEVER send liveness checks continuously. If it does > that it is broken. It SHOULD only send liveness checks when there is [snip] That's what I said. [snip] > The delay should be less than minute. > > > I don't think this delay is appropriate for any real-time traffic. > > If you care about real-time traffic, then you should keep your NAT > mappings up for all peers, so you will get the address update message, > and can move to new address immediately when you receive it. It won't help much. The MOBIKE client doesn't know that it must switch to a just received additional address once he receives it. The event that usually triggers this movement is an availability of current path. So you still will have a the delay while the client detects that the current path is not working and the new path works. You'll still have about 10-20 seconds delay at best. > > Then the IKE SA state must be transferred to a new node and the > > current node must stop responding to this client. > > You need to move the IKE SA anyways, and you need to move it before > you send any update which says there is another IP address to be used. > And both ends MUST be able to process IKE and IPsec SA packets at the > same time if we want to make sure no packets are lost during the > transition (if you really care about real-time traffic). No, in your case the first node must stop responding to the client, so that client understands that it should switch to the other address. With my proposal the client is explicitly asked to do that, so the whole procedure should take less time and be more reliable. so that it is easier to make the event atomic from cluster point of view. > > Then the cluster would wait until the client detects the failure and > > switches itself to a new node. And there is also a chance that there > > are some IKE exchanges in progress, so if the node stops responding > > the exchanges could time out the and the IKE SA would be deleted > > before the movement takes place (in my proposal the MOBIKE is > > combined with RFC6311 exchange to make this working)... > > If you are using MOBIKE, then the IKE exchange should not time out > before it has tried all possible addresses, thus there is no issue in > there. Can you please point me where RFC4555 requires that _any_ exchange must try all possible addresses before timing out? Path testing is described in Sections 3.10 and 3.12 and these sections only tell about using INFORMATIONAL DPD exchanges for this purpose. > > > This delay will be eliminiated if the address update from > > > responder reached initiator, i.e., if the initiator kept the ports > > > open in NAT or if there is no NAT between. > > > > There is absolutely no guarantee that it will work. > > I'd like to have something more reliable. > > Knowing that there are so broken implementations of IPsec and IKE out > there that still use periodic liveness checks for example, there will > never be any guarantee that any of these will work... Broken implementations is not an issue here (although it is always big issue :-(). The issue is that RFC4555 in its current form is too vague to be used for cluster use case. This use case requires some additions to RFC4555 or some clarifications in any case (if the cluster use case is solved using MOBIKE, that is not the only possible way). > Even if we defined some new method for transferring this information to the other > end that will not mean that it will get implemented correctly on the > clients :-) Alas. But that is unfortunately true for any new standard. Should we shutdown IETF then? :-) > Anyways as the current proposed charter text does not really describe > the problem you are trying to solve, at least it needs to be updated > to properly state the problem. I.e., you are not trying to make the > responder side MOBIKE, you are trying to get responder MOBIKE messages > through restricted NAT / firewall.... OK. How about the following? MOBIKE protocol [RFC4555] is used to move existing IKE/IPsec SA from one IP address to another. However, in MOBIKE it is the initiator of the IKE SA (i.e. remote access client) that controls this process. While the responder can try to instruct the initiator to switch to a different IP address, the whole process is not reliable enough, especially in presence of NAT or firewalls. If there are several responders each having own IP address and acting together as a load sharing cluster, then it is desirable for them to have ability to request initiator to switch to a particular member. The working group will analyze the possibility to extend MOBIKE protocol or to develop new IKE extension that will allow to build load sharing clusters in an interoperable way. Is it better? Regards, Valery. > -- > kivinen@iki.fi From nobody Wed Feb 21 08:42:10 2018 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 AAC121242F7 for ; Wed, 21 Feb 2018 08:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 AjB6G2i_UvyW for ; Wed, 21 Feb 2018 08:42:06 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F7212E89A for ; Wed, 21 Feb 2018 08:42:00 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zmjts2Q8Kz37W; Wed, 21 Feb 2018 17:41:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1519231317; bh=25jmHHQ+AWsPGLvOOEtMdrcgffpyNICWQYBY6he4rbs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MF5QNxSRO32Cx1eCC1vwepFxsxyK+kcxXDOOP6Szvc14Y9+MGekUQsXv4WnyjR32n yp7l8ExohQrndhvZeiUo63vDKd+S6zKe79KAfFJ46qV9E6Kx9RL7vLjqLtvTDXShpT f0S2Gd7aFaDFqqhwQh5kVeD2yJPLTf5zm3wkb7EA= 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 i576GneO9K9a; Wed, 21 Feb 2018 17:41:56 +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, 21 Feb 2018 17:41:56 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id AF665C75; Wed, 21 Feb 2018 11:41:55 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca AF665C75 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A58A1414535C; Wed, 21 Feb 2018 11:41:55 -0500 (EST) Date: Wed, 21 Feb 2018 11:41:55 -0500 (EST) From: Paul Wouters To: Tero Kivinen cc: Valery Smyslov , ipsec@ietf.org In-Reply-To: <23180.40426.204224.108279@fireball.acr.fi> Message-ID: References: <23175.7252.256625.885691@fireball.acr.fi> <02c501d3a95e$a5d73200$f1859600$@gmail.com> <23179.8656.330909.562547@fireball.acr.fi> <038e01d3aa5e$ec66bc80$c5343580$@gmail.com> <23180.40426.204224.108279@fireball.acr.fi> 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] Additional charter items 1/4: Responder MOBIKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 16:42:08 -0000 On Wed, 21 Feb 2018, Tero Kivinen wrote: >> In real life there is a NAT in most cases. > > Use IPv6 :-) > > Then there will not be problems with NATs... Sadly, IPv6 NAT is happening and there is a request to add ESPinUDP support for IPv6 in the Linux kernel :( I think the topic is interesting and we should add it to the charter in some way that does not tie this to MOBIKE. And we can discuss from there. Paul From nobody Sun Feb 25 11:36:12 2018 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 3B265126DFB for ; Sun, 25 Feb 2018 11:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ICmleCp0GNOR for ; Sun, 25 Feb 2018 11:36:09 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C4D1241F8 for ; Sun, 25 Feb 2018 11:36:09 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0161720090 for ; Sun, 25 Feb 2018 14:43:44 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 18EF980D06 for ; Sun, 25 Feb 2018 14:36:08 -0500 (EST) From: Michael Richardson To: ipsec@ietf.org In-Reply-To: <23175.7252.256625.885691@fireball.acr.fi> References: <23175.7252.256625.885691@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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: [IPsec] Additional charter items 1 thu 4 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2018 19:36:11 -0000 --=-=-= Content-Type: text/plain Tero asked about: 1) Responder MOBIKE 2) Address Failure Errors 3) Labeled IPsec 4) Mitigating privacy concerns I read through the discussion about them, and read some of the drafts. I find that 1,2,3 are all well defined and bounded in time and space. I found that #4 is not so well understood; in particular it seems to suggest doing things not just defend against, but subvert government actors. I don't really object to such work occuring, but I want to suggest that this is a case of cat-and-mouse arms race. I suggest that the IETF is too slow a place to do this. Do this in open source. I would not object to seeing a a moderate number (~dozen) of types allocated for experimental use. i.e. details to be provided later. Pretty much all of our tables are Expert Review. Go out there and try some things with real code, and then report back in two years which mechanisms scaled and did the right thing. I have a concern with #3: while I know that redhat delivers this to government customers, are there any other vendors will also implement? If not, then I'm worried we won't have enough interested parties to review, unless some of the actual customers are brought to the table to review. I'd like to prioritize #2 as highest. I think that #1 (Responder MOBIKE) may suffer from lack of actual implementers being involved today. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlqTECcACgkQgItw+93Q 3WXUOQgAgYQDtnyDkTtIrsW0fx2wJxcXzIXfdyVqRBgQX9gRK78yx2YNCZ5nJVqe G//fNsJesR68L0tB8h/E9Jv0oiWmtTylc7hqOjP3OA5qHP1qbbpdkt3ZVwvKVyFI H68r2Fe6G7eVC6UOliwqHlfD66KTao5Uo9L37jFVouR3R9wDewq6C5tZNoNs6XGV d6x5ltYqwVADbb4XYML5Vo7/FNpI8mZ05TQVAIkI90cgZqHtCzEdMt577BKL8GJG s6mqxzd1nsn1qR3q+zapLkT8BKiv85LP2Cg+qKdSViLnwCe59LOa5Vqd3Jx3nqy7 D+Y5qVnkWLVklqTI+4FdsB3SHWu4Sw== =yH2V -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 26 09:01:45 2018 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 5D33A12D876; Mon, 26 Feb 2018 09:01:17 -0800 (PST) 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.72.4 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , ekr@rtfm.com, ipsecme-chairs@ietf.org, kivinen@iki.fi, Tero Kivinen , ipsec@ietf.org, draft-ietf-ipsecme-eddsa@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151966447737.31463.312874035669427995.idtracker@ietfa.amsl.com> Date: Mon, 26 Feb 2018 09:01:17 -0800 Archived-At: Subject: [IPsec] Protocol Action: 'Using Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange (IKEv2)' to Proposed Standard (draft-ietf-ipsecme-eddsa-04.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 17:01:18 -0000 The IESG has approved the following document: - 'Using Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange (IKEv2)' (draft-ietf-ipsecme-eddsa-04.txt) as Proposed Standard This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Kathleen Moriarty and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-eddsa/ Technical Summary This document describes the use of the Edwards-curve digital signature algorithm in the IKEv2 protocol as proposed standard. Working Group Summary Version -01 went through WGLC. Changes suggested by the WG participants were mostly editorial. There were three substantive decisions: (1) That the new value in the hash function registry requested from IANA for "Identity" shall not be zero. (2) That we will not use the pre-hashed version of the EdDSA function (same decision made by TLS and Curdle working groups) (3) That we will use a null context (or context-free Ed25519) for IKE (same decision reached in TLS and Curdle working groups) The resulting document represents WG consensus. The document was reviewed by several regular WG participants. Apple reports a working implementation. Document Quality See above Personnel Author is Yoav Nir. Eric Rescorla is the responsible Area Director. Tero Kivinen is the document shepherd. From nobody Mon Feb 26 11:34:53 2018 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 8DF99127023 for ; Mon, 26 Feb 2018 11:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnG1IxRw05ua for ; Mon, 26 Feb 2018 11:34:50 -0800 (PST) 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 E73011200C1 for ; Mon, 26 Feb 2018 11:34:49 -0800 (PST) Received: from [10.10.0.100] (46-126-238-39.dynamic.hispeed.ch [46.126.238.39]) by mail.strongswan.org (Postfix) with ESMTPSA id B766740108; Mon, 26 Feb 2018 20:34:51 +0100 (CET) To: ipsec@ietf.org References: <151966447737.31463.312874035669427995.idtracker@ietfa.amsl.com> From: Andreas Steffen Message-ID: <0efce678-131a-2c95-dab6-1cebf76de301@strongswan.org> Date: Mon, 26 Feb 2018 20:34:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <151966447737.31463.312874035669427995.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060200010404060003070007" Archived-At: Subject: Re: [IPsec] Protocol Action: 'Using Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange (IKEv2)' to Proposed Standard (draft-ietf-ipsecme-eddsa-04.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 19:34:51 -0000 This is a cryptographically signed message in MIME format. --------------ms060200010404060003070007 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi, strongSwan also has a working implementation of Ed25519. Regards Andreas On 26.02.2018 18:01, The IESG wrote: > Apple reports a working implementation. =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=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 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) =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=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D[INS-HSR]=3D=3D --------------ms060200010404060003070007 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC B7QwggNiMIIC6KADAgECAggwtYJcB7vEnDAKBggqhkjOPQQDAzBSMQswCQYDVQQGEwJFUzEU MBIGA1UECgwLU3RhcnRDb20gQ0ExLTArBgNVBAMMJFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5IEVDQzAeFw0xNzA0MjgwODAwMzVaFw0zNzA0MjgwODAwMzVaMGkxCzAJBgNV BAYTAkVTMRQwEgYDVQQKDAtTdGFydENvbSBDQTEpMCcGA1UECwwgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkxGTAXBgNVBAMMEFN0YXJ0Q29tIENDMiBJQ0EwdjAQBgcqhkjO PQIBBgUrgQQAIgNiAAR7hlYvM7ymfqRetYHdncaz11zCyZQbJofX1jT1FiEsyKH7WFh7k9cN BMbe9RUh7mq6EcCcP7rHdV1yhkx9CNT8KSSDHIIWB1RbmK5XtKvK4BLQ1pLUbzvGVz/YBYro HK+jggFyMIIBbjBtBggrBgEFBQcBAQRhMF8wNQYIKwYBBQUHMAKGKWh0dHA6Ly9haWEuc3Rh cnRjb21jYS5jb20vY2VydHMvY2FjYzIuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5z dGFydGNvbWNhLmNvbTAdBgNVHQ4EFgQUPLfG3okmWlcDidCvMGpGDgzq3GYwEgYDVR0TAQH/ BAgwBgEB/wIBADAfBgNVHSMEGDAWgBSeiMCybDMJy/8hfr/qnwiGu32qGTBBBgNVHSAEOjA4 MDYGBFUdIAAwLjAsBggrBgEFBQcCARYgaHR0cDovL3d3dy5zdGFydGNvbWNhLmNvbS9wb2xp Y3kwNwYDVR0fBDAwLjAsoCqgKIYmaHR0cDovL2NybC5zdGFydGNvbWNhLmNvbS9zZnNjYWNj Mi5jcmwwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAK BggqhkjOPQQDAwNoADBlAjEAxVHjDb7E+HcRO7j3UZg3lyI/6MgNJuD/Fc/5HTtjZc5B0iVz eeERiqV1sGJ/h9h8AjAlmjRwgkRXx8hJVcCzCCBl95zytvLdJdGPrBJHEaFJnsYX8FQZGB86 0clRb9QPXXQwggRKMIID0KADAgECAgg+TA4JQ+pHvTAKBggqhkjOPQQDAzBpMQswCQYDVQQG EwJFUzEUMBIGA1UECgwLU3RhcnRDb20gQ0ExKTAnBgNVBAsMIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MRkwFwYDVQQDDBBTdGFydENvbSBDQzIgSUNBMB4XDTE3MDkxNDEz MDkyM1oXDTE5MDkxNDA1MTkwMFowWDEtMCsGCSqGSIb3DQEJARYeYW5kcmVhcy5zdGVmZmVu QHN0cm9uZ3N3YW4ub3JnMScwJQYDVQQDDB5hbmRyZWFzLnN0ZWZmZW5Ac3Ryb25nc3dhbi5v cmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJMEyWg/QwNXGYCijunT/fc91 p2oIG4IPzuFGqXc/KEPSeqmp/EFkcIeq/LlYEQPbcunbytL1HLj5GIyy/1wp7xX5jMUmKlXD aXlSYfXSayTzv0s8eQCWUZzBHiTiXNPEPE4SzHPPWUHL5ImBgCAaorr1Rd9wbHdjnroxxJX9 EqLTWxvKgLW6v2/08HcYIPiOR2//NB/NgN2EV1PlTbz0o9FLbTkif8f1SUYhF47MKl1sd5pD 6HkVGitD7nNstlwVFJoTh8jLHz2+eyi3dvD66tUIcsehTPxn7LdgIzrmJhRXBgqcYaxNyklq /UoyBFj7VweOaF0Bnu1xgHztj2pxAgMBAAGjggGmMIIBojB0BggrBgEFBQcBAQRoMGYwPAYI KwYBBQUHMAKGMGh0dHA6Ly9haWEuc3RhcnRjb21jYS5jb20vY2VydHMvc2NhLmNsaWVudDIy LmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3Auc3RhcnRjb21jYS5jb20wHQYDVR0OBBYE FEzLAe0+UOOGteImULQlfS7R2iozMAkGA1UdEwQCMAAwHwYDVR0jBBgwFoAUPLfG3okmWlcD idCvMGpGDgzq3GYwSAYDVR0gBEEwPzA9BgsrBgEEAYG1NwICATAuMCwGCCsGAQUFBwIBFiBo dHRwOi8vd3d3LnN0YXJ0Y29tY2EuY29tL3BvbGljeTA7BgNVHR8ENDAyMDCgLqAshipodHRw Oi8vY3JsLnN0YXJ0Y29tY2EuY29tL3NjYS1jbGllbnQyMi5jcmwwDgYDVR0PAQH/BAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDApBgNVHREEIjAggR5hbmRyZWFzLnN0 ZWZmZW5Ac3Ryb25nc3dhbi5vcmcwCgYIKoZIzj0EAwMDaAAwZQIxALntmqK6p1e2YFJVqI04 /Q6tCM/lyRCKMYhsHbOaEI9xxYvFN0lcpbW0LMh8Od5ntgIwNhzjvAf+gd08PHgRIM87ty5S ldy4XYAL6dri38rR+ZM9y7qhl56XAcPT8wCSW2MqMYIDizCCA4cCAQEwdTBpMQswCQYDVQQG EwJFUzEUMBIGA1UECgwLU3RhcnRDb20gQ0ExKTAnBgNVBAsMIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MRkwFwYDVQQDDBBTdGFydENvbSBDQzIgSUNBAgg+TA4JQ+pHvTAN BglghkgBZQMEAgEFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwMjI2MTkzNDQ3WjAvBgkqhkiG9w0BCQQxIgQgJ/aMO6cac/aTXPW/qxu1U3J6 WOm9br0xrUAve1gxUtswbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUD BAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDCBhAYJKwYBBAGCNxAEMXcwdTBpMQswCQYDVQQGEwJFUzEUMBIG A1UECgwLU3RhcnRDb20gQ0ExKTAnBgNVBAsMIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MRkwFwYDVQQDDBBTdGFydENvbSBDQzIgSUNBAgg+TA4JQ+pHvTCBhgYLKoZIhvcN AQkQAgsxd6B1MGkxCzAJBgNVBAYTAkVTMRQwEgYDVQQKDAtTdGFydENvbSBDQTEpMCcGA1UE CwwgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxGTAXBgNVBAMMEFN0YXJ0Q29t IENDMiBJQ0ECCD5MDglD6ke9MA0GCSqGSIb3DQEBAQUABIIBAH1XAkKTlW44xWyOSQKmNww0 gOBfdsjr2vEB+8sG4fIeRcYS0HRKE66XXa2zwqOhecpPWieDD54SvPfCfKGPWuxvDL5LzO1c BnV8pI/JEF8Hoydy8GKbeWpJBt0jQh0v0vE0RW9FRH81j+QTmUqte8fI8wmc/HpYN33f4vhX d7JalLerr2DAtDLm9Ns1ZEZC3Zdp6l8I67viUgGuFD3iehjh4EG0iu4KIUFkP955hZGB9lAI 5ZGvE1CsnpxairLlUaAB8U5ZrQbOKuAZHd6/gu8S0L4f7PfY1x/MpHyt+wtasnIuiCCsLize 5agJ5q0Y33n/W4wj3ddrDkdikT+qaeoAAAAAAAA= --------------ms060200010404060003070007-- From nobody Mon Feb 26 16:52:07 2018 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 6E27012D967; Mon, 26 Feb 2018 16:52:05 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (1024-bit key) header.d=nistgov.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 KrGKCPG3SOfY; Mon, 26 Feb 2018 16:52:03 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0094.outbound.protection.outlook.com [23.103.201.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1BEC124BAC; Mon, 26 Feb 2018 16:51:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=J6itl2WGa2/qS0GqLefVoBl06S1oOMdI14GToH4nmro=; b=JtAQIgu4hjCFaH9CwR4ieDx5nKMib9BPaYxsTBmXd2YZBZTiWCLlrn+TeXtbMcUKXAFX1EwTDU33lhxJL5ogno/LAYWQsNJM3ZguddAr5R4GzYa62zv+o3gKyS6sDf58HPhHUBLNbl643IN+6/itIMAgntC9kAx43s1VTvLEtJ0= Received: from BL0PR0901MB2306.namprd09.prod.outlook.com (52.132.18.148) by BL0PR0901MB2308.namprd09.prod.outlook.com (52.132.18.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Tue, 27 Feb 2018 00:51:57 +0000 Received: from BL0PR0901MB2306.namprd09.prod.outlook.com ([fe80::9aa:3aa4:170a:7073]) by BL0PR0901MB2306.namprd09.prod.outlook.com ([fe80::9aa:3aa4:170a:7073%13]) with mapi id 15.20.0527.021; Tue, 27 Feb 2018 00:51:57 +0000 From: "Waltermire, David A. (Fed)" To: "draft-ietf-ipsecme-split-dns.authors@ietf.org" , IPsecME WG Thread-Topic: Shepherd Review of draft-ietf-ipsecme-split-dns-06 Thread-Index: AdOvZInWFoVQAJXuTMqN+ApYo9CCsQ== Date: Tue, 27 Feb 2018 00:51:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.224.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR0901MB2308; 7:GEtkVYST9mVlAKCMMWR11X13Jz0Fz+dzL/RqjMnBlPdTX7kwUefTyBWWtg8/CrbPjoFXOz7C+IoxlIrCwWhcoeqABK0mVkyLfmwQtHpwte5H3s/kPwWUme4HokuzVaLbF32iV8t8KhoqFiIvS8jhX18Xt47vyxfA76GTc4/cZl86WKOcVU2mS7jjcbUPlYJKCQkCSLi3sC2nCVDKjpQo/+1wtegp0N3sMRmYzPCV32j75bQxk3L7GP92lqMgZINJ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c9ddf51b-1b43-4d7e-3af0-08d57d7c4de4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BL0PR0901MB2308; x-ms-traffictypediagnostic: BL0PR0901MB2308: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231220)(944501161)(52105095)(3002001)(6055026)(6041288)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:BL0PR0901MB2308; BCL:0; PCL:0; RULEID:; SRVR:BL0PR0901MB2308; x-forefront-prvs: 05961EBAFC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(39860400002)(39380400002)(376002)(366004)(189003)(199004)(110136005)(59450400001)(86362001)(68736007)(97736004)(3280700002)(53936002)(74316002)(450100002)(305945005)(33656002)(8936002)(66066001)(8676002)(81156014)(81166006)(5660300001)(99286004)(6116002)(2900100001)(3660700001)(3846002)(7736002)(25786009)(7696005)(478600001)(26005)(5250100002)(186003)(2501003)(2906002)(6346003)(14454004)(106356001)(102836004)(55016002)(105586002)(9686003)(6506007)(316002)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR0901MB2308; H:BL0PR0901MB2306.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-microsoft-antispam-message-info: SOV4XfBoWLqaUfbif6D688vKZ8tVGNKlWciT40P7jcMmyZ69zo4PFn7PPMfGlr8lPBQ2R9HqrJ45eyQA7wNS3jNxIl1iBPnH+jXyTXUdJqYbdCXRZc/6fN+PHcRij1MnM1p2Min3rSMIKmNiRU5a8sL9fVWxX1Me56WmaIZvNhw= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: c9ddf51b-1b43-4d7e-3af0-08d57d7c4de4 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2018 00:51:57.8075 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR0901MB2308 Archived-At: Subject: [IPsec] Shepherd Review of draft-ietf-ipsecme-split-dns-06 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 00:52:05 -0000 Authors, Overall the draft is almost ready to submit to the IESG once the following = few small issues are resolved.=20 Section 1.1: There are a few lowercase instances of must, may, and should in the documen= t. You should use text from RFC8174 to indicate that lowercase versions of = the keywords are not normative. Something like the following would work: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Please double check the lowercase "must", "should", and "may" instances to = be sure they are properly non-capitalized. In section 3.1 the document states: If an INTERNAL_DNSSEC_TA attriute is included in the CFG_REQUEST, the initiator SHOULD also include one or more INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST. The behavior for the responder is not defined in section 3.2 if this "SHOUL= D" is violated. Would it be desireable for the responder to ignore the INTE= RNAL_DNSSEC_TA attribute? This behavior should be defined either way. (nit) s/attriute/attribute/ (I think Tero already found this and we are wai= ting to handle this in AD review/IETF LC.) Section 3.4.2: (nit) s/attributes/attributes/ (nit) s/received in the CFG_REPLY/received in the CFG_REPLY./ "In this example, the initiator has no existing DNSSEC trust anchors would = the requested domain." Should this be 'for the requested domain "example.co= m."'? The following sentence should start with a capitalized letter. The pa= ragraph should end with a period. How about the following as a replacement: In this example, the initiator has no existing DNSSEC trust anchors for the requested domain "example.com". The responder provides DNSSEC trust anchors for the "example.com" domain, but does not configure trust= anchors for the "city.other.com" domain. Section 5: The first sentence of the 6th paragraph contains a lowercase "must", which = I believe should be capitalized. (nit) s/be be/be/ Once this is all fixed I will send the draft to the IESG. I'll complete the= writeup using your text as a starting point in the interim. Regards, Dave From nobody Tue Feb 27 10:49:11 2018 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 3999A120227; Tue, 27 Feb 2018 10:49:06 -0800 (PST) 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.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151975734619.28573.5790957105920678309@ietfa.amsl.com> Date: Tue, 27 Feb 2018 10:49:06 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 18:49:06 -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-02.txt Pages : 18 Date : 2018-02-27 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-02 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-qr-ikev2-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-qr-ikev2-02 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 Tue Feb 27 15:17:33 2018 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 32D0B12EA57; Tue, 27 Feb 2018 15:11:16 -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.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151977307620.5200.2153037408261355903.idtracker@ietfa.amsl.com> Date: Tue, 27 Feb 2018 15:11:16 -0800 Archived-At: Subject: [IPsec] ipsecme - Requested session has been scheduled for IETF 101 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 23:11: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:00) Friday, Afternoon Session I 1150-1320 Room Name: Park Suite size: 100 --------------------------------------------- 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 Wed Feb 28 09:38:12 2018 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 1C0DE124217 for ; Wed, 28 Feb 2018 09:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 h5cEDoVm2o3A for ; Wed, 28 Feb 2018 09:38:08 -0800 (PST) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76C24126BF7 for ; Wed, 28 Feb 2018 09:38:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1519839488; x=2383753088; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=3i39zL1iKJezDq4DcIv0xVyBIxe6ige7SfAShfS+rEo=; b=3DmIzopv29ySG6o55nNRfmZ+uBeD3WdeskknRfBJDstK/CVe8H/DHrq+YGcP1muj YVRgFv8g0BvnxijJ65KNJ0gkSYvFU56FG+AddIbqtoNoEYZwLowrA/Mxk/1f6xkf 5jNEbkwqOu5W9gHm70yZ7sMWaV7Watcu7qGtlJMSI3tyTccphvr7tgWRf6jDszDw XYOB8Q3GCdxledXNdCo+hhwEqgFoxmmMvgVwKct37YMIYcDMLgqb9bYpr/JMyM+q vRPoGtl1WMwBWR3TVS8IAWc6VTMga8RIvhGFprTpCyJvT4ltksx8+c0c7iGm7CLH cI6IrVRGaAndbsqL28qKgA==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id F0.0B.04908.009E69A5; Wed, 28 Feb 2018 09:38:08 -0800 (PST) X-AuditID: 11973e16-446529e00000132c-fd-5a96e9000e29 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by relay8.apple.com (Apple SCV relay) with SMTP id AC.A0.10701.009E69A5; Wed, 28 Feb 2018 09:38:08 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.192.171.234] (unknown [17.192.171.234]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180130 64bit (built Jan 30 2018)) with ESMTPSA id <0P4V00506FNJFT20@nwk-mmpp-sz11.apple.com>; Wed, 28 Feb 2018 09:38:08 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: Date: Wed, 28 Feb 2018 09:38:07 -0800 Cc: "draft-ietf-ipsecme-split-dns.authors@ietf.org" , IPsecME WG Content-transfer-encoding: quoted-printable Message-id: References: To: "Waltermire, David A. (Fed)" X-Mailer: Apple Mail (2.3466) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUi2FCYpsvwclqUwcGr3BYbe/6xWSydVGyx f8sLNgdmjyVLfjJ5XDv5lzWAKYrLJiU1J7MstUjfLoEr48L9BsaC7WIVd5/cZGpgbBPqYuTk kBAwkZi5vJ2xi5GLQ0hgDZPE/AnXmGESPV8WskAkDjFK3L20jQUkwSsgKPFj8j0gm4ODWUBd YsqUXIiayUwSRx7vZwaJCwtISGzekwhhuktsmJED0skmoCJx/NsGsPGcAskSl79tArNZBFQl ulfeZwUZwyzQBLTqyHmwVcwC2hJP3l1ghVhrI7Fj7ilGEFtIIEniwaQjYLYIUPzC5AesEDfL SrR8nws2SEKgg01i3pIutgmMwrOQnD0L4exZSFYsYGRexSiUm5iZo5uZZ66XWFCQk6qXnJ+7 iREU4NPtxHYwPlxldYhRgINRiYd3xsFpUUKsiWXFlbmHGKU5WJTEedXXT4kSEkhPLEnNTk0t SC2KLyrNSS0+xMjEwSnVwKg6m4+xk9XHJMmG/UNh4Qsl148uGdMmtJ+e+/0376rCqy087fuj jANvh/O5amnHhXC+3fbVP1NLd7f2nO8zGrNEf4mHBcdEaK9p7ma6oKHuJRfj3+Zs4v1C5YZj cnrY7/2P+f3Z3zfvrmLytNv1bb11aKwOQ67/qw+vknoV1OfWO1yNfSmjxFKckWioxVxUnAgA rvkszlECAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUi2FA8W5fh5bQog1enOCw29vxjs1g6qdhi /5YXbA7MHkuW/GTyuHbyL2sAUxSXTUpqTmZZapG+XQJXxoX7DYwF28Uq7j65ydTA2CbUxcjJ ISFgItHzZSFLFyMXh5DAIUaJu5e2sYAkeAUEJX5Mvgdkc3AwC6hLTJmSC1EzmUniyOP9zCBx YQEJic17EiFMd4kNM3JAOtkEVCSOf9vADGJzCiRLXP62CcxmEVCV6F55nxVkDLNAE9CqI+fB VjELaEs8eXeBFWKtjcSOuacYQWwhgSSJB5OOgNkiQPELkx+wQtwsK9HyfS7rBEaBWUgunYVw 6SwkUxcwMq9iFChKzUmstNBLLCjISdVLzs/dxAgOyMK0HYxNy60OMQpwMCrx8DrsnxYlxJpY VlyZCwwKDmYlEd7T24FCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeRs9eqOEBNITS1KzU1MLUotg skwcnFINjCV77ITbl758Gibxt/unyKW+srJPeZHbo3d2x0422tL/v1/MUObCm4m/5v3Vj1Z4 lLOPMev7Nt+PZ1iDHx7et4v5227ZzxZ3dWY8U2Lza7rnuPpK2+EPP+P7grJ/tDe6FVg/SfB8 tEu3YFf0/ZvPpI7we67OqmKY6rXU9qW4lewzh21NZ4W2hCixFGckGmoxFxUnAgDaOzYKRAIA AA== Archived-At: Subject: Re: [IPsec] Shepherd Review of draft-ietf-ipsecme-split-dns-06 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 17:38:10 -0000 Hi David, Thanks! I=E2=80=99ll work on this today and send an update. Tommy > On Feb 26, 2018, at 4:51 PM, Waltermire, David A. (Fed) = wrote: >=20 > Authors, >=20 > Overall the draft is almost ready to submit to the IESG once the = following few small issues are resolved.=20 >=20 > Section 1.1: >=20 > There are a few lowercase instances of must, may, and should in the = document. You should use text from RFC8174 to indicate that lowercase = versions of the keywords are not normative. >=20 > Something like the following would work: >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in = BCP > 14 [RFC2119] [RFC8174] when, and only when, they appear in all > capitals, as shown here. >=20 > Please double check the lowercase "must", "should", and "may" = instances to be sure they are properly non-capitalized. >=20 > In section 3.1 the document states: >=20 > If an INTERNAL_DNSSEC_TA attriute is included > in the CFG_REQUEST, the initiator SHOULD also include one or more > INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST. >=20 > The behavior for the responder is not defined in section 3.2 if this = "SHOULD" is violated. Would it be desireable for the responder to ignore = the INTERNAL_DNSSEC_TA attribute? This behavior should be defined either = way. >=20 > (nit) s/attriute/attribute/ (I think Tero already found this and we = are waiting to handle this in AD review/IETF LC.) >=20 > Section 3.4.2: >=20 > (nit) s/attributes/attributes/ >=20 > (nit) s/received in the CFG_REPLY/received in the CFG_REPLY./ >=20 > "In this example, the initiator has no existing DNSSEC trust anchors = would the requested domain." Should this be 'for the requested domain = "example.com."'? The following sentence should start with a capitalized = letter. The paragraph should end with a period. >=20 > How about the following as a replacement: >=20 > In this example, the initiator has no existing DNSSEC trust anchors > for the requested domain "example.com". The responder provides = DNSSEC > trust anchors for the "example.com" domain, but does not configure = trust anchors for the "city.other.com" domain. >=20 > Section 5: >=20 > The first sentence of the 6th paragraph contains a lowercase "must", = which I believe should be capitalized. >=20 > (nit) s/be be/be/ >=20 > Once this is all fixed I will send the draft to the IESG. I'll = complete the writeup using your text as a starting point in the interim. >=20 > Regards, > Dave >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Feb 28 10:11:24 2018 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 EAE3712008A; Wed, 28 Feb 2018 10:11:22 -0800 (PST) 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.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151984148291.5238.12967280150275408134@ietfa.amsl.com> Date: Wed, 28 Feb 2018 10:11:22 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 18:11:23 -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-07.txt Pages : 12 Date : 2018-02-28 Abstract: 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". 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-07 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-split-dns-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 28 10:12:26 2018 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 CD8C7124319 for ; Wed, 28 Feb 2018 10:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kZXVweApABW for ; Wed, 28 Feb 2018 10:12:20 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 2E563126CBF for ; Wed, 28 Feb 2018 10:12:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1519841539; x=2383755139; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=++Vi8nwn2bh8vbQr9xu2bZJkz4NJuBrhXKRKLJv/OGk=; b=nC/3R4ruPxkOJmSMOEeOaFJCzKlnZRpg25syMS0VosXghDFPVGa5et8D3LUuT+ys 2VfJzOdvt+6q1sMSRr5A7AlpeSjoJLPTYwaFPODLIXvLuijLeh93N6d8DF7aACdj +VL4u03TuSB1lt38M7HWDayt/w9+O1PFpm6PW+wYrgpxvo/GTEEvr1naEwGF6jKg lPaHn538MFj8sXPVq0/XqPfFAkzqsM57XUHiMB0i7dh1m9nUknt5H0SwwHQgxqlF NswZiwJD/wNESQlXkz/siGyDehFUvQZCiTmI1qro4hgcEc5L8MdJrMCmfLEwiMot y3U9t8W+pQlLxhmjfui10A==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 7A.19.07147.301F69A5; Wed, 28 Feb 2018 10:12:19 -0800 (PST) X-AuditID: 11973e12-d46b29e000001beb-42-5a96f103b3bb Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by relay5.apple.com (Apple SCV relay) with SMTP id 19.46.23499.301F69A5; Wed, 28 Feb 2018 10:12:19 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_58HXRYgQJZGGEkpmLfwGyA)" Received: from [17.192.171.234] (unknown [17.192.171.234]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180130 64bit (built Jan 30 2018)) with ESMTPSA id <0P4V005PJH8JFT30@nwk-mmpp-sz11.apple.com>; Wed, 28 Feb 2018 10:12:19 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <26997F56-977F-4958-B720-2DDBC811D887@apple.com> Date: Wed, 28 Feb 2018 10:12:19 -0800 In-reply-to: Cc: "draft-ietf-ipsecme-split-dns.authors@ietf.org" , IPsecME WG To: "Waltermire, David A. (Fed)" References: X-Mailer: Apple Mail (2.3466) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUi2FAYocv8cVqUwcN1hhYbe/6xWSydVGyx f8sLNgdmjyVLfjJ5XDv5lzWAKYrLJiU1J7MstUjfLoEr41ebY8FM54rlnz4wNTBusuxi5OCQ EDCR+PHdoouRi0NIYDWTxOKe9+xdjJxg8YtPnjCC2EIChxglVh1NAbF5BQQlfky+xwJiMwuE SXw//48donkyk0TX3zOMIEOFBSQkNu9JBKlhE1CROP5tAzNImFfARmLhxEKICneJDTNyQCpY BFQlnnY1MYGEOQVsJV5ecwMZyCzQxChx98h5sE0iQJ0XJj9ghdg0FeiaYwuhzpSVaPk+Fywh ITCHTeLv1pNMExiFZiE5dRaSU2cBLWEWUJeYMiUXIqwt8eTdBVYIW01i4e9FTMjiCxjZVjEK 5SZm5uhm5pnoJRYU5KTqJefnbmIExcJ0O6EdjKdWWR1iFOBgVOLhnXFwWpQQa2JZcWXuIUZp DhYlcV719VOihATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTAyvG9Kf3/pvyu7Ef/9+mknPBb4 VXaK2OfvVdx1qqeG5WVBqrWpf4LmyXoDpdvTdiwxX6olpJuwbufN0O6HEzbt051yeeIFT76o 5G86UXFb7+w1v6DD+8LK8e2+nhI/3clMpQv2b+X4IGG+pUSeUX/HOY7pUZFbTr5yrwn64uUo eOH47Vv8ZhuUWIozEg21mIuKEwGamq5PZgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUi2FA8W5f547Qog13XdC029vxjs1g6qdhi /5YXbA7MHkuW/GTyuHbyL2sAUxSXTUpqTmZZapG+XQJXxq82x4KZzhXLP31gamDcZNnFyMkh IWAicfHJE0YQW0jgEKPEqqMpIDavgKDEj8n3WEBsZoEwie/n/7F3MXIB1Uxmkuj6ewaogYND WEBCYvOeRJAaNgEViePfNjCDhHkFbCQWTiyEqHCX2DAjB6SCRUBV4mlXExNImFPAVuLlNTeQ gcwCTYwSd4+cB9skAtR5YfIDVohNU4GuObaQHeJMWYmW73NZJzDyz0Jy3Swk180CmsssoC4x ZUouRFhb4sm7C6wQtprEwt+LmJDFFzCyrWIUKErNSaw01UssKMhJ1UvOz93ECA7ewogdjP+X WR1iFOBgVOLhddg/LUqINbGsuDIXGEIczEoivKe3A4V4UxIrq1KL8uOLSnNSiw8xSnOwKInz Nnr0RgkJpCeWpGanphakFsFkmTg4pRoYN1+O3lclsVDnJ9f0hSyXxV8+/JQSNWlFvmbdiydp M+dk6q7r3/DA/8HT2ZsvvfyzqcnllwGf3NtXe/6I599Qi2CwW37gil+ziODU3yalVzzMLnxk 3hDfzji5NfnticnenoYKpoW+7IJHyozk5qzJvJChe621z0S8Qo/jqM2JqSbm85ZEOF1mVWIp zkg01GIuKk4EAPk3/XVaAgAA Archived-At: Subject: Re: [IPsec] Shepherd Review of draft-ietf-ipsecme-split-dns-06 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 18:12:26 -0000 --Boundary_(ID_58HXRYgQJZGGEkpmLfwGyA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi David, I=E2=80=99ve updated the draft with your comments as version -07: = https://www.ietf.org/id/draft-ietf-ipsecme-split-dns-07.txt = Thanks, Tommy > On Feb 28, 2018, at 9:38 AM, Tommy Pauly wrote: >=20 > Hi David, >=20 > Thanks! I=E2=80=99ll work on this today and send an update. >=20 > Tommy >=20 >> On Feb 26, 2018, at 4:51 PM, Waltermire, David A. (Fed) = wrote: >>=20 >> Authors, >>=20 >> Overall the draft is almost ready to submit to the IESG once the = following few small issues are resolved.=20 >>=20 >> Section 1.1: >>=20 >> There are a few lowercase instances of must, may, and should in the = document. You should use text from RFC8174 to indicate that lowercase = versions of the keywords are not normative. >>=20 >> Something like the following would work: >>=20 >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and >> "OPTIONAL" in this document are to be interpreted as described in = BCP >> 14 [RFC2119] [RFC8174] when, and only when, they appear in all >> capitals, as shown here. >>=20 >> Please double check the lowercase "must", "should", and "may" = instances to be sure they are properly non-capitalized. >>=20 >> In section 3.1 the document states: >>=20 >> If an INTERNAL_DNSSEC_TA attriute is included >> in the CFG_REQUEST, the initiator SHOULD also include one or more >> INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST. >>=20 >> The behavior for the responder is not defined in section 3.2 if this = "SHOULD" is violated. Would it be desireable for the responder to ignore = the INTERNAL_DNSSEC_TA attribute? This behavior should be defined either = way. >>=20 >> (nit) s/attriute/attribute/ (I think Tero already found this and we = are waiting to handle this in AD review/IETF LC.) >>=20 >> Section 3.4.2: >>=20 >> (nit) s/attributes/attributes/ >>=20 >> (nit) s/received in the CFG_REPLY/received in the CFG_REPLY./ >>=20 >> "In this example, the initiator has no existing DNSSEC trust anchors = would the requested domain." Should this be 'for the requested domain = "example.com."'? The following sentence should start with a capitalized = letter. The paragraph should end with a period. >>=20 >> How about the following as a replacement: >>=20 >> In this example, the initiator has no existing DNSSEC trust anchors >> for the requested domain "example.com". The responder provides = DNSSEC >> trust anchors for the "example.com" domain, but does not configure = trust anchors for the "city.other.com" domain. >>=20 >> Section 5: >>=20 >> The first sentence of the 6th paragraph contains a lowercase "must", = which I believe should be capitalized. >>=20 >> (nit) s/be be/be/ >>=20 >> Once this is all fixed I will send the draft to the IESG. I'll = complete the writeup using your text as a starting point in the interim. >>=20 >> Regards, >> Dave >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 --Boundary_(ID_58HXRYgQJZGGEkpmLfwGyA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Hi = David,

I=E2=80=99ve = updated the draft with your comments as version -07: https://www.ietf.org/id/draft-ietf-ipsecme-split-dns-07.txt=

Thanks,
Tommy

On Feb = 28, 2018, at 9:38 AM, Tommy Pauly <tpauly@apple.com> wrote:

Hi = David,

Thanks! I=E2=80=99ll work on this = today and send an update.

Tommy

On Feb = 26, 2018, at 4:51 PM, Waltermire, David A. (Fed) <david.waltermire@nist.gov> wrote:

Authors,

Overall the draft is = almost ready to submit to the IESG once the following few small issues = are resolved.

Section 1.1:
There are a few lowercase instances of must, may, and should = in the document. You should use text from RFC8174 to indicate that = lowercase versions of the keywords are not normative.

Something like the following would work:

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", = "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", = "NOT RECOMMENDED", "MAY", and
 "OPTIONAL" in this = document are to be interpreted as described in BCP
=  14 [RFC2119] [RFC8174] when, and only when, they appear in all
 capitals, as shown here.

Please double check the lowercase "must", "should", and "may" = instances to be sure they are properly non-capitalized.

In section 3.1 the document states:

If an INTERNAL_DNSSEC_TA attriute is included
=  in the CFG_REQUEST, the initiator SHOULD also include one or = more
 INTERNAL_DNS_DOMAIN attributes in the = CFG_REQUEST.

The behavior for the responder = is not defined in section 3.2 if this "SHOULD" is violated. Would it be = desireable for the responder to ignore the INTERNAL_DNSSEC_TA attribute? = This behavior should be defined either way.

(nit) s/attriute/attribute/ (I think Tero already found this = and we are waiting to handle this in AD review/IETF LC.)
Section 3.4.2:

(nit) = s/attributes/attributes/

(nit) s/received = in the CFG_REPLY/received in the CFG_REPLY./

"In this example, the initiator has no existing DNSSEC trust = anchors would the requested domain." Should this be 'for the requested = domain "example.com."'? = The following sentence should start with a capitalized letter. The = paragraph should end with a period.

How = about the following as a replacement:

In = this example, the initiator has no existing DNSSEC trust anchors
 for the requested domain "example.com". The responder provides DNSSEC
=  trust anchors for the "example.com" domain, but does not configure trust anchors = for the "city.other.com" = domain.

Section 5:

The first sentence of the 6th paragraph contains a lowercase = "must", which I believe should be capitalized.

(nit) s/be be/be/

Once this is = all fixed I will send the draft to the IESG. I'll complete the writeup = using your text as a starting point in the interim.

Regards,
Dave

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


= --Boundary_(ID_58HXRYgQJZGGEkpmLfwGyA)-- From nobody Wed Feb 28 10:38:00 2018 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 7837212426E; Wed, 28 Feb 2018 10:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 okwyfX8dnpud; Wed, 28 Feb 2018 10:37:56 -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 BA99D1200E5; Wed, 28 Feb 2018 10:37:56 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zs47P6RSwz3H3; Wed, 28 Feb 2018 19:37:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1519843073; bh=It4+B04q1z/AJN61fRZvLEXDXY44+Ge5j/P3C5EOVwU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=s+Fs0hB2jYDEZI0mgH0GdQcMu0wkUCFi1ZYi56uvqwp8963DCqa4CJRrTex2O62Wr kpV3hWEAAWZm5W/+ijPMEW69ZoeZDp135CrfvsucJ6duMcUg05/EGYPrZIJtDnwuUH jdj6oJc9/6y5V2zr1Noz3qg1HB94BCzaL83i+RyY= 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 xJH7w_XLSmUy; Wed, 28 Feb 2018 19:37:51 +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, 28 Feb 2018 19:37:50 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 09C5836670A; Wed, 28 Feb 2018 13:37:50 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 09C5836670A Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0068444DA255; Wed, 28 Feb 2018 13:37:49 -0500 (EST) Date: Wed, 28 Feb 2018 13:37:49 -0500 (EST) From: Paul Wouters To: Tommy Pauly cc: "Waltermire, David A. (Fed)" , IPsecME WG , "draft-ietf-ipsecme-split-dns.authors@ietf.org" In-Reply-To: <26997F56-977F-4958-B720-2DDBC811D887@apple.com> Message-ID: References: <26997F56-977F-4958-B720-2DDBC811D887@apple.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] Shepherd Review of draft-ietf-ipsecme-split-dns-06 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 18:37:58 -0000 On Wed, 28 Feb 2018, Tommy Pauly wrote: > I’ve updated the draft with your comments as version -07: https://www.ietf.org/id/draft-ietf-ipsecme-split-dns-07.txt Thanks for doing this. I would make one change (but it can be done after IETF-LC) [...] the content SHOULD be considered untrusted and handled accordingly. You changed should to SHOULD, but in this case it really is a MUST. Paul