From nobody Mon Jan 15 15:17: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 CA35212D87E for ; Mon, 15 Jan 2018 15:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.11 X-Spam-Level: X-Spam-Status: No, score=-0.11 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 0mWZ1sImA2CO for ; Mon, 15 Jan 2018 15:17:21 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82891275F4 for ; Mon, 15 Jan 2018 15:17:20 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zL8Q417M6z3B1; Tue, 16 Jan 2018 00:17:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1516058236; bh=0OLad+W0LuO8KK2AMugl0oYzxNmOZeU8EL7hxx7oH/M=; h=Date:From:To:cc:Subject; b=cdHvA3oPHnPPqeGSK5qbTPZIsrPebPbj+q31mAZA47zuRIUbD37ksJEyXiW1CYEg4 Gpg7ujruFYaMflr8rinX762k3gv/5F1pWgagmLViHFtGHyXVkwoSMn/bOy4uiJK22Y 9GZIiA21m1xp5zDTqTu1I09zhWZSiMN1Xfc+qpJw= 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 dggHmYfXgbVN; Tue, 16 Jan 2018 00:17:14 +0100 (CET) Received: from bofh.nohats.ca (vpn-ppk.nohats.ca [193.110.157.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 16 Jan 2018 00:17:14 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id CF07461D6F; Mon, 15 Jan 2018 18:17:12 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca CF07461D6F Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C12D340EED6F; Mon, 15 Jan 2018 18:17:12 -0500 (EST) Date: Mon, 15 Jan 2018 18:17:12 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" cc: Vukasin Karadzic Message-ID: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] draft-ietf-ipsecme-qr-ikev2-01 interop 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, 15 Jan 2018 23:17:23 -0000 We have done a successful interop with Valerie for draft-ietf-ipsecme-qr-ikev2-01 If anyone else wants to try: Using the following private use numbers: v2N_USE_PPK = 40960, /* draft-ietf-ipsecme-qr-ikev2-01 */ v2N_PPK_IDENTITY = 40961, /* draft-ietf-ipsecme-qr-ikev2-01 */ v2N_NO_PPK_AUTH = 40962, /* draft-ietf-ipsecme-qr-ikev2-01 */ 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). The server allows both with and without PPK for these connections. It uses CP to hand you an IP address in the 100.64.13.0/24 range. You should have full internet access to ping things (eg 8.8.8.8) Let me know if you succeed or fail to interop. Paul & Vukasin From nobody Sun Jan 21 17:23:48 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 171B6126C19 for ; Sun, 21 Jan 2018 17:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 41TyE-HFfRem for ; Sun, 21 Jan 2018 17:23:43 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F8ED127077 for ; Sun, 21 Jan 2018 17:23:42 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 21 Jan 2018 17:23:40 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Sun, 21 Jan 2018 17:23:40 -0800 From: Paul Hoffman To: "ipsec@ietf.org" Thread-Topic: WG Last Call comments on draft-ietf-ipsecme-split-dns Thread-Index: AQHTkx+ildw4MoEyR0++Rgt3EhjSJg== Date: Mon, 22 Jan 2018 01:23:40 +0000 Message-ID: <85F3BEFC-506E-4A2D-8CB3-19B4C5AB45BA@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [IPsec] WG Last Call comments on draft-ietf-ipsecme-split-dns 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, 22 Jan 2018 01:23:45 -0000 Greetings. This document is still listed as in WG Last Call, although I hav= en't seen anything in the archive about that Last Call closing. The document seems mostly fine, and it certainly seems like a useful IPsec = extension. I have only two concerns: - Section 5 says: An initiator SHOULD ignore INTERNAL_DNS_DOMAIN attributes containing domains that are designated Special Use Domain Names in [RFC6761], such as "local", "localhost", "invalid", etc. Although it may explicitly wish to support some Special Use Domain Names. There is no way that an implementation can easily follow what is in the IAN= A registry for Special Use Domain names. Further, given that that the names= are going to be internal, there isn't a good reason to prevent them from b= eing used beyond the normal "don't make up names that someone else might be= using" argument. The second sentence (fragment) doesn't give enough detail= to help an implementer. I think that this whole paragraph can be safely re= moved. - Section 6 says: The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be passed to another (DNS) program for processing. The content MUST be verified and sanitized before passing it to other software. For example, domain names are limited to alphanumeric characters and the minus ("-") and underscore ("_") symbol and if other other characters are present, the entire payload could be ignored and not passed to DNS software, or the malicious characters could be filtered out before passing the payload to DNS software. That is not correct. *Host* names are limited, but domain names are not. Do= main names can have any octet in them. This is a common misunderstanding in= the DNS; see RFC 7719 for definitions of DNS terms. I suggest that this pa= ragraph be changed to: The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be passed to another (DNS) program for processing. Some DNS programs only handle domain names in host name format, although many are inconsistent about this.=20 --Paul Hoffman= From nobody Sun Jan 21 19:21:08 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 17B1B1241F5 for ; Sun, 21 Jan 2018 19:21:07 -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 aOHAKhPAIQnc for ; Sun, 21 Jan 2018 19:21:05 -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 D1ACE1200F1 for ; Sun, 21 Jan 2018 19:21:04 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zPxXX6nnlzWf; Mon, 22 Jan 2018 04:21:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1516591261; bh=6V9ZriSCoXie0+nQ0rjkavMNoETwxmKLet1AVJ9fg5I=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MM42T5Q5/GmeX92MEhJ0An1ZI7F/CXbiRR+y2jJAHEPnPMPAD55HAbHN3C2/NYakN BfYQuHOXyCu3c/JBiclATvqD26H7Knf4Y6xoHpBj/wRRDzMAd1nUWRSMFL+uCa91Rc jfQz2x+nxmy86Os1ew0VmxxiynatY8vTXHNjo7+4= 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 ljPYQqgcmujG; Mon, 22 Jan 2018 04:20:58 +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, 22 Jan 2018 04:20:57 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 9E9A6A0A; Sun, 21 Jan 2018 22:20:56 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 9E9A6A0A Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 814FC4191BFB; Sun, 21 Jan 2018 22:20:56 -0500 (EST) Date: Sun, 21 Jan 2018 22:20:56 -0500 (EST) From: Paul Wouters To: Paul Hoffman cc: "ipsec@ietf.org" In-Reply-To: <85F3BEFC-506E-4A2D-8CB3-19B4C5AB45BA@icann.org> Message-ID: References: <85F3BEFC-506E-4A2D-8CB3-19B4C5AB45BA@icann.org> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [IPsec] WG Last Call comments on draft-ietf-ipsecme-split-dns 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, 22 Jan 2018 03:21:07 -0000 On Mon, 22 Jan 2018, Paul Hoffman wrote: > Greetings. This document is still listed as in WG Last Call, although I haven't seen anything in the archive about that Last Call closing. Yeah, the WGLC ended Nov 9. I have pinged the chairs a few times already, and requested an early code point for INTERNAL_DNSSEC_TA. (we already have one for INTERNAL_DNS_DOMAIN) > The document seems mostly fine, and it certainly seems like a useful IPsec extension. I have only two concerns: Thanks for the review! > - Section 5 says: > An initiator SHOULD ignore INTERNAL_DNS_DOMAIN attributes containing > domains that are designated Special Use Domain Names in [RFC6761], > such as "local", "localhost", "invalid", etc. Although it may > explicitly wish to support some Special Use Domain Names. > There is no way that an implementation can easily follow what is in the IANA registry for Special Use Domain names. Further, given that that the names are going to be internal, there isn't a good reason to prevent them from being used beyond the normal "don't make up names that someone else might be using" argument. The second sentence (fragment) doesn't give enough detail to help an implementer. I think that this whole paragraph can be safely removed. I think that's fair. Especially if there will be a .internal or something, the advise could at best be "clients should be very careful accepting certain special domains". I will removed the paragraph. > - Section 6 says: > The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be > passed to another (DNS) program for processing. The content MUST be > verified and sanitized before passing it to other software. For > example, domain names are limited to alphanumeric characters and the > minus ("-") and underscore ("_") symbol and if other other characters > are present, the entire payload could be ignored and not passed to > DNS software, or the malicious characters could be filtered out > before passing the payload to DNS software. > That is not correct. *Host* names are limited, but domain names are not. Domain names can have any octet in them. This is a common misunderstanding in the DNS; see RFC 7719 for definitions of DNS terms. I suggest that this paragraph be changed to: That somewhat contradicts 7719 in which document you state: Note that any label in a domain name can contain any octet value; hostnames are generally considered to be domain names where every label follows the rules in the "preferred name syntax" So a hostname - if FQDN - could have a leftmost label with other stuff in it, but everything to the right of the zone cut would have to be compliant to the restrive set. And we were talking about domain names, and not hostnames. > The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be > passed to another (DNS) program for processing. Some DNS programs > only handle domain names in host name format, although many are > inconsistent about this. I would prefer to keep the focus on the security part. If there are weird characters, don't blindly pass those along. Whether something is a legit hostname or domainname is not very relevant to the IKE or IPsec layer. Whoever _receives_ the information can determine that part. We are mostly concerned about passing foo`cat /etc/passswd`.com So how about: The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be passed to another (DNS) program for processing. The content MUST be verified to not contain any malicious characters, before it is passed to other programs for DNS processing. If it contains malicious characters, the payload should be ignored or sanitized. Whether a specific combination of non-malicious characters constitute a valid DNS domain name is best left to be decided by the DNS software that receives the contents of these payloads. Paul From nobody Sun Jan 21 19:29:08 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 DCBF6126CC7 for ; Sun, 21 Jan 2018 19:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 pg3s4JRixBNz for ; Sun, 21 Jan 2018 19:29:04 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7822D1200F1 for ; Sun, 21 Jan 2018 19:29:04 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 21 Jan 2018 19:29:02 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Sun, 21 Jan 2018 19:29:02 -0800 From: Paul Hoffman To: Paul Wouters CC: "ipsec@ietf.org" Thread-Topic: [Ext] Re: [IPsec] WG Last Call comments on draft-ietf-ipsecme-split-dns Thread-Index: AQHTkx+itlcg30/tw0Osc7RdhQ42G6N/v+UAgAACQwA= Date: Mon, 22 Jan 2018 03:29:02 +0000 Message-ID: References: <85F3BEFC-506E-4A2D-8CB3-19B4C5AB45BA@icann.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <21928029BB8ECC4F85968464CDDE2C90@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] [Ext] Re: WG Last Call comments on draft-ietf-ipsecme-split-dns 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, 22 Jan 2018 03:29:06 -0000 On Jan 21, 2018, at 7:20 PM, Paul Wouters wrote: >> - Section 6 says: >> The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be >> passed to another (DNS) program for processing. The content MUST be >> verified and sanitized before passing it to other software. For >> example, domain names are limited to alphanumeric characters and the >> minus ("-") and underscore ("_") symbol and if other other characters >> are present, the entire payload could be ignored and not passed to >> DNS software, or the malicious characters could be filtered out >> before passing the payload to DNS software. >> That is not correct. *Host* names are limited, but domain names are not.= Domain names can have any octet in them. This is a common misunderstanding= in the DNS; see RFC 7719 for definitions of DNS terms. I suggest that this= paragraph be changed to: >=20 > That somewhat contradicts 7719 in which document you state: >=20 > Note that any label in a > domain name can contain any octet value; hostnames are generally > considered to be domain names where every label follows the rules > in the "preferred name syntax" There is no contradiction between what I say above and that. > So a hostname - if FQDN - could have a leftmost label with other stuff > in it, but everything to the right of the zone cut would have to be > compliant to the restrive set. And we were talking about domain names, > and not hostnames. Nonono. Nothing in the definition of domain name or hostname has anything t= o do with label position. >=20 >> The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be >> passed to another (DNS) program for processing. Some DNS programs >> only handle domain names in host name format, although many are >> inconsistent about this. >=20 > I would prefer to keep the focus on the security part. If there are > weird characters, don't blindly pass those along. If you're talking about domain names, there are no "weird characters": they= are just blobs of octets. > Whether something > is a legit hostname or domainname is not very relevant to the IKE > or IPsec layer. Whoever _receives_ the information can determine > that part. We are mostly concerned about passing foo`cat /etc/passswd`.co= m ...which is a valid domain name (assuming an ASCII or UTF-8 encoding for th= e octets). >=20 > So how about: >=20 > The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be > passed to another (DNS) program for processing. The content MUST be > verified to not contain any malicious characters, before it is > passed to other programs for DNS processing. If it contains malicious > characters, the payload should be ignored or sanitized. Whether a > specific combination of non-malicious characters constitute a valid > DNS domain name is best left to be decided by the DNS software that > receives the contents of these payloads. >=20 Unless you can define "malicious", I would disagree. In fact, unless you ca= n define "character", you will also have a problem (some encodings of chara= cters take up multiple octets). If you really want to go down this path, you must say something like "domai= n names where each label consist only of octets which map to the ASCII enco= ding of the following values: A to Z, a to z, 0 to 9, "-", and "_".=20 --Paul Hoffman= From nobody Mon Jan 22 07:31: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 1FF6612426E for ; Mon, 22 Jan 2018 07:31:09 -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, SPF_PASS=-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 reO2jMU87IJg for ; Mon, 22 Jan 2018 07:31:05 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0701.outbound.protection.outlook.com [IPv6:2a01:111:f400:fd00::701]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B6821200C5 for ; Mon, 22 Jan 2018 07:31:05 -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=6zER0BsRYirzME+TIcdIFwtiwHFzjsDePje1UDjFsZo=; b=HR2ucGZ9UPjUPlsSNzd4iesWhm4XukDew3GTp+1QGcC1sODMUZ7BDX4y/l3rypbWhsICS2wQDtXoWEuVvTc52e2cKTBfKnuye068KQ/LYPIXjhy5uVKIhFb4Q+zkMPjK+KoI7lGEDuwmc6XCG0X3q6Yu1M1AVlAgGPBq0TCRAUU= Received: from CY4PR09MB1495.namprd09.prod.outlook.com (10.173.191.141) by CY4PR09MB1493.namprd09.prod.outlook.com (10.173.191.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.17; Mon, 22 Jan 2018 15:31:03 +0000 Received: from CY4PR09MB1495.namprd09.prod.outlook.com ([fe80::c41c:a808:662c:2069]) by CY4PR09MB1495.namprd09.prod.outlook.com ([fe80::c41c:a808:662c:2069%17]) with mapi id 15.20.0428.019; Mon, 22 Jan 2018 15:31:03 +0000 From: "Waltermire, David A. (Fed)" To: Paul Hoffman , "paul@nohats.ca" CC: "ipsec@ietf.org" Thread-Topic: [IPsec] [Ext] Re: WG Last Call comments on draft-ietf-ipsecme-split-dns Thread-Index: AQHTkzE2uwzvMq+DAE+EyOslaKGqMaOAA/kg Date: Mon, 22 Jan 2018 15:31:03 +0000 Message-ID: References: <85F3BEFC-506E-4A2D-8CB3-19B4C5AB45BA@icann.org> 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=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR09MB1493; 7:PuvaM2jP6xisV5ZpL3ZDMZ7R1LBIdJYry84WDeYKb77n4tvbfpz1AuRPkY5xM8QaEUL92B7iouvxmJJvTez6x0+V9hx0ONaxL8NkkQuTIxZC+iwr1ThpBtpuGLOohaU0TP5y5aTNbLcsZTC+3T55hcWTXjyWs7S5OdRfvfN33zqMEOIEu0ydSZJkmVQvo2QLe9aNwTxozS5nx1gdyiIzd7lNDveflZlmvC9voKRrXoYiBD2mgMdPpNesRvhdVzPx x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 873c30f0-6edd-4f70-1f6a-08d561ad25e6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(2017052603307)(7153060)(7193020); SRVR:CY4PR09MB1493; x-ms-traffictypediagnostic: CY4PR09MB1493: x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(189930954265078)(150554046322364)(219752817060721)(10322497157591); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231023)(2400081)(944501161)(6055026)(6041288)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR09MB1493; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR09MB1493; x-forefront-prvs: 0560A2214D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(39380400002)(366004)(39850400004)(13464003)(199004)(189003)(51914003)(8936002)(81156014)(4326008)(8676002)(5660300001)(2501003)(5250100002)(81166006)(68736007)(6246003)(25786009)(575784001)(53936002)(110136005)(97736004)(55016002)(9686003)(6436002)(966005)(6306002)(106356001)(316002)(105586002)(86362001)(59450400001)(7736002)(14454004)(230783001)(45080400002)(478600001)(33656002)(76176011)(2950100002)(229853002)(99286004)(3280700002)(6506007)(53546011)(26005)(305945005)(102836004)(6116002)(3846002)(74316002)(66066001)(2900100001)(3660700001)(7696005)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1493; H:CY4PR09MB1495.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-microsoft-antispam-message-info: 5zcu3g0v1TjwWHSmU9L+jWZd0IUIz/97zlKLUenaChn4jIMH5XDY0rBMpYkLC2HaECB4F3upj5GGaJeIMkeB4w== 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: 873c30f0-6edd-4f70-1f6a-08d561ad25e6 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2018 15:31:03.4618 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1493 Archived-At: Subject: Re: [IPsec] [Ext] Re: WG Last Call comments on draft-ietf-ipsecme-split-dns 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, 22 Jan 2018 15:31:09 -0000 Paul and Paul, Thanks for the additional review and dialog. I am currently reviewing this = document as the shepherd. It would be good to resolve these issues before m= oving the draft forward. I will watch this thread for a resolution before submitting the shepherd wr= iteup. Thanks, Dave > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Hoffman > Sent: Sunday, January 21, 2018 10:29 PM > To: paul@nohats.ca > Cc: ipsec@ietf.org > Subject: Re: [IPsec] [Ext] Re: WG Last Call comments on draft-ietf-ipsecm= e-split- > dns >=20 > On Jan 21, 2018, at 7:20 PM, Paul Wouters wrote: > >> - Section 6 says: > >> The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may > be > >> passed to another (DNS) program for processing. The content MUST be > >> verified and sanitized before passing it to other software. For > >> example, domain names are limited to alphanumeric characters and the > >> minus ("-") and underscore ("_") symbol and if other other characters > >> are present, the entire payload could be ignored and not passed to > >> DNS software, or the malicious characters could be filtered out > >> before passing the payload to DNS software. > >> That is not correct. *Host* names are limited, but domain names are no= t. > Domain names can have any octet in them. This is a common misunderstandin= g > in the DNS; see RFC 7719 for definitions of DNS terms. I suggest that thi= s > paragraph be changed to: > > > > That somewhat contradicts 7719 in which document you state: > > > > Note that any label in a > > domain name can contain any octet value; hostnames are generally > > considered to be domain names where every label follows the rules > > in the "preferred name syntax" >=20 > There is no contradiction between what I say above and that. >=20 > > So a hostname - if FQDN - could have a leftmost label with other stuff > > in it, but everything to the right of the zone cut would have to be > > compliant to the restrive set. And we were talking about domain names, > > and not hostnames. >=20 > Nonono. Nothing in the definition of domain name or hostname has anything= to > do with label position. >=20 > > > >> The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may > be > >> passed to another (DNS) program for processing. Some DNS programs > >> only handle domain names in host name format, although many are > >> inconsistent about this. > > > > I would prefer to keep the focus on the security part. If there are > > weird characters, don't blindly pass those along. >=20 > If you're talking about domain names, there are no "weird characters": th= ey are > just blobs of octets. >=20 > > Whether something > > is a legit hostname or domainname is not very relevant to the IKE or > > IPsec layer. Whoever _receives_ the information can determine that > > part. We are mostly concerned about passing foo`cat /etc/passswd`.com >=20 > ...which is a valid domain name (assuming an ASCII or UTF-8 encoding for = the > octets). >=20 > > > > So how about: > > > > The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA > may be > > passed to another (DNS) program for processing. The content MUST be > > verified to not contain any malicious characters, before it is > > passed to other programs for DNS processing. If it contains malicious > > characters, the payload should be ignored or sanitized. Whether a > > specific combination of non-malicious characters constitute a valid > > DNS domain name is best left to be decided by the DNS software that > > receives the contents of these payloads. > > >=20 > Unless you can define "malicious", I would disagree. In fact, unless you = can > define "character", you will also have a problem (some encodings of chara= cters > take up multiple octets). >=20 > If you really want to go down this path, you must say something like "dom= ain > names where each label consist only of octets which map to the ASCII enco= ding > of the following values: A to Z, a to z, 0 to 9, "-", and "_". >=20 > --Paul Hoffman > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ie= t > f.org%2Fmailman%2Flistinfo%2Fipsec&data=3D02%7C01%7Cdavid.waltermire%4 > 0nist.gov%7Ccb3cb4d514f64ba8e4d908d561484fb5%7C2ab5d82fd8fa4797a > 93e054655c61dec%7C1%7C0%7C636521885562888149&sdata=3DrZ0CDHHaez > tWhdhrNHtkvtMC0X%2F7EZonxF52J0vlLUM%3D&reserved=3D0 From nobody Mon Jan 22 07:36:05 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 9C43912751F for ; Mon, 22 Jan 2018 07:35:50 -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 kYfE9UNy9DTJ for ; Mon, 22 Jan 2018 07:35:48 -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 1A90D127369 for ; Mon, 22 Jan 2018 07:35:47 -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 w0MFZDAd014798 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Jan 2018 17:35:13 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w0MFZDnE024722; Mon, 22 Jan 2018 17:35:13 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23142.1201.707067.352387@fireball.acr.fi> Date: Mon, 22 Jan 2018 17:35:13 +0200 From: Tero Kivinen To: Paul Wouters Cc: Paul Hoffman , "ipsec\@ietf.org" In-Reply-To: References: <85F3BEFC-506E-4A2D-8CB3-19B4C5AB45BA@icann.org> 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] WG Last Call comments on draft-ietf-ipsecme-split-dns 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, 22 Jan 2018 15:35:51 -0000 Paul Wouters writes: > On Mon, 22 Jan 2018, Paul Hoffman wrote: > > > Greetings. This document is still listed as in WG Last Call, although I haven't seen anything in the archive about that Last Call closing. > > Yeah, the WGLC ended Nov 9. I have pinged the chairs a few times > already, and requested an early code point for INTERNAL_DNSSEC_TA. > (we already have one for INTERNAL_DNS_DOMAIN) I have not seen any request come from IANA to me as an expert. WG chairs do not assign code points, IANA does that, and they will only start the process when such request is submitted to them. This will automatically happen during the RFC publication process. You can also submit the request to the IANA at any time, as this is Expert review registry... So make the request through the IANA and then it will come to me (and got tickets assigned which will send me reminders if I do not act on it quickly enough) and then you can get the number allocated. I though I had already explained this year ago when we assigned INTERNAL_DNS_DOMAIN, i.e., for expert registries, there is no need to go through IESG or WG chairs, you can fill in the form in IANA page, and then it will come to the expert for review... -- kivinen@iki.fi From nobody Mon Jan 22 08:36: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 DB63E126DEE; Mon, 22 Jan 2018 08:35:42 -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 rYo6Y9zxxqYJ; Mon, 22 Jan 2018 08:35:40 -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 974AF124207; Mon, 22 Jan 2018 08:35:40 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zQH9P2GLzz32H; Mon, 22 Jan 2018 17:35:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1516638937; bh=DHsBypZQHDVjGqMbBg8hc3rsvQ1pJGy8lvJNdssJcnQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Rgh0uSQz0S/vXxNDP/NJpmIOTqiUmmZmpcHs1dGgZQ71uCVtYgwaeQfK6aSKw3x9z NtnpHIjIeCn+NLVc7Mte4xUGN1DGmMV0GTYh5v9i8czUgPSadBHPfBuHOicv21UwLI cVEzWxe7c5qvhqtxFUEXNAnjG0auX/puPVMI4Bm8= 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 KryBkg0owEfE; Mon, 22 Jan 2018 17:35:35 +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, 22 Jan 2018 17:35:34 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C5C2061CDD; Mon, 22 Jan 2018 11:35:33 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca C5C2061CDD Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BE76E4199C62; Mon, 22 Jan 2018 11:35:33 -0500 (EST) Date: Mon, 22 Jan 2018 11:35:33 -0500 (EST) From: Paul Wouters To: Tero Kivinen cc: "ipsec@ietf.org" , ietf@ietf.org In-Reply-To: <23142.1201.707067.352387@fireball.acr.fi> Message-ID: References: <85F3BEFC-506E-4A2D-8CB3-19B4C5AB45BA@icann.org> <23142.1201.707067.352387@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] WG Last Call comments on draft-ietf-ipsecme-split-dns 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, 22 Jan 2018 16:36:00 -0000 On Mon, 22 Jan 2018, Tero Kivinen wrote: [ added ietf@ietf.org to get a general discussion on this, as it seems this is a procedural issue not specific to the WG ] execsum: I followed RFC 7120 to get an Early Code Point, and there is confusion about the process between me, the chairs and the epxert. > I have not seen any request come from IANA to me as an expert. WG > chairs do not assign code points, IANA does that, and they will only > start the process when such request is submitted to them. This will > automatically happen during the RFC publication process. You can also > submit the request to the IANA at any time, as this is Expert review > registry... > > So make the request through the IANA and then it will come to me (and > got tickets assigned which will send me reminders if I do not act on > it quickly enough) and then you can get the number allocated. I followed https://tools.ietf.org/html/rfc7120#section-3 The process for requesting and obtaining early allocation of code points is as follows: 1. The authors (editors) of the document submit a request for early allocation to the Working Group chairs, specifying which code points require early allocation and to which document they should be assigned. 2. [wg chairs do stuff] Nowhere does it link to or mention a page at IANA where to do this. Nowhere does it state I should not contact the WG chairs. Now, there is a strangeness in section 2: The following conditions must hold before a request for early allocation of code points will be considered by IANA: a. The code points must be from a space designated as "RFC Required", "IETF Review", or "Standards Action". Additionally, requests for early assignment of code points from a "Specification Required" registry are allowed if the specification will be published as an RFC. I don't understand why "Expert review" is not listed here. Is it by design or an error in RFC 7120 ? Additionally, the document does not point to any other instructions for the process in the case of Expert Review. Who to contact where? Paul > Date: Mon, 22 Jan 2018 10:35:13 > From: Tero Kivinen > Cc: "ipsec@ietf.org" , Paul Hoffman > To: Paul Wouters > Subject: Re: [IPsec] WG Last Call comments on draft-ietf-ipsecme-split-dns > > Paul Wouters writes: >> On Mon, 22 Jan 2018, Paul Hoffman wrote: >> >>> Greetings. This document is still listed as in WG Last Call, although I haven't seen anything in the archive about that Last Call closing. >> >> Yeah, the WGLC ended Nov 9. I have pinged the chairs a few times >> already, and requested an early code point for INTERNAL_DNSSEC_TA. >> (we already have one for INTERNAL_DNS_DOMAIN) > > I have not seen any request come from IANA to me as an expert. WG > chairs do not assign code points, IANA does that, and they will only > start the process when such request is submitted to them. This will > automatically happen during the RFC publication process. You can also > submit the request to the IANA at any time, as this is Expert review > registry... > > So make the request through the IANA and then it will come to me (and > got tickets assigned which will send me reminders if I do not act on > it quickly enough) and then you can get the number allocated. > > I though I had already explained this year ago when we assigned > INTERNAL_DNS_DOMAIN, i.e., for expert registries, there is no need to > go through IESG or WG chairs, you can fill in the form in IANA page, > and then it will come to the expert for review... > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Mon Jan 22 08:45:52 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 6767D124B18 for ; Mon, 22 Jan 2018 08:45: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 lnoIDSJgM7lm for ; Mon, 22 Jan 2018 08:45:47 -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 F0B8512708C for ; Mon, 22 Jan 2018 08:45:41 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zQHP00xQNz31X; Mon, 22 Jan 2018 17:45:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1516639540; bh=86Vi7O13F171+951H9XR1r2u2xZrty0zyCgww3FjBNg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MwflyRlaPoJKUybIzHzNBsiIHsSJqmHCzwnFVgxKHhJCidwRXiBlUTY7NLipNmZsB PYMtdB3j+QvNtPKDbKwJ1RDvLhE9mTiEuOyMbE/wmsFaZpTvvdTdI8hhIP9YfpS8iv VQLrmW6xtBpCeAKYq2WJCWJGrm+rPDqQK9Z1+M+Q= 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 xYhIY-P_MyOn; Mon, 22 Jan 2018 17:45: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; Mon, 22 Jan 2018 17:45:38 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 5FB0D61CDD; Mon, 22 Jan 2018 11:45:37 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 5FB0D61CDD Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 529964199C62; Mon, 22 Jan 2018 11:45:37 -0500 (EST) Date: Mon, 22 Jan 2018 11:45:37 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" cc: Paul Hoffman In-Reply-To: Message-ID: References: <85F3BEFC-506E-4A2D-8CB3-19B4C5AB45BA@icann.org> 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] [Ext] Re: WG Last Call comments on draft-ietf-ipsecme-split-dns 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, 22 Jan 2018 16:45:49 -0000 On Sun, 21 Jan 2018, Paul Hoffman wrote: >>> So how about: >>> >>> The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA >> may be >>> passed to another (DNS) program for processing. The content MUST be >>> verified to not contain any malicious characters, before it is >>> passed to other programs for DNS processing. If it contains malicious >>> characters, the payload should be ignored or sanitized. Whether a >>> specific combination of non-malicious characters constitute a valid >>> DNS domain name is best left to be decided by the DNS software that >>> receives the contents of these payloads. >>> >> >> Unless you can define "malicious", I would disagree. In fact, unless you can >> define "character", you will also have a problem (some encodings of characters >> take up multiple octets). >> >> If you really want to go down this path, you must say something like "domain >> names where each label consist only of octets which map to the ASCII encoding >> of the following values: A to Z, a to z, 0 to 9, "-", and "_". I'm trying not to define any DNS terms in this document and stay out of any character/domain/hostname discussion. How about: The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be passed to another (DNS) program for processing. As with any network input, the content should be considered untrusted and handled accordingly. Paul From nobody Mon Jan 22 08:47: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 ED569124B18; Mon, 22 Jan 2018 08:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQ1AuF1uD42X; Mon, 22 Jan 2018 08:47:20 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9216D124207; Mon, 22 Jan 2018 08:47:20 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 22 Jan 2018 08:47:18 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Mon, 22 Jan 2018 08:47:18 -0800 From: Michelle Cotton To: Paul Wouters , Tero Kivinen CC: "ipsec@ietf.org" , "ietf@ietf.org" Thread-Topic: [Ext] Re: [IPsec] WG Last Call comments on draft-ietf-ipsecme-split-dns Thread-Index: AQHTk58i+Sxkgx5AcUmIT+A/6F9QXaOAoDCA Date: Mon, 22 Jan 2018 16:47:18 +0000 Message-ID: References: <85F3BEFC-506E-4A2D-8CB3-19B4C5AB45BA@icann.org> <23142.1201.707067.352387@fireball.acr.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.236] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3599455637_2151437563" MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] [Ext] Re: WG Last Call comments on draft-ietf-ipsecme-split-dns 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, 22 Jan 2018 16:47:23 -0000 --B_3599455637_2151437563 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Paul, Expert review requests don=E2=80=99t generally need early assignment because the = expert can review a request immediately and codepoints can be assigned. The working group chairs normally send the requests to iana@iana.org for ea= rly allocation. See point 5 in section 3.1: 5. If the Area Directors approve step 4), the WG chairs request IANA to make an early allocation. Looks like some improvements are needed to RFC7120 and as I=E2=80=99m the author,= I=E2=80=99ll add that to my list of to-do=E2=80=99s. Let me know if you have any further questions. Best regards, Michelle Cotton Protocol Parameters Engagement Sr. Manager =E2=80=93 IANA Services -----Original Message----- From: ietf on behalf of Paul Wouters Date: Monday, January 22, 2018 at 8:36 AM To: Tero Kivinen Cc: "ipsec@ietf.org" , "ietf@ietf.org" Subject: [Ext] Re: [IPsec] WG Last Call comments on draft-ietf-ipsecme-spli= t-dns On Mon, 22 Jan 2018, Tero Kivinen wrote: =20 [ added ietf@ietf.org to get a general discussion on this, as it seems this is a procedural issue not specific to the WG ] =20 execsum: I followed RFC 7120 to get an Early Code Point, and there is confusion about the process between me, the chairs and the epxert. =20 > I have not seen any request come from IANA to me as an expert. WG > chairs do not assign code points, IANA does that, and they will only > start the process when such request is submitted to them. This will > automatically happen during the RFC publication process. You can also > submit the request to the IANA at any time, as this is Expert review > registry... > > So make the request through the IANA and then it will come to me (and > got tickets assigned which will send me reminders if I do not act on > it quickly enough) and then you can get the number allocated. =20 I followed https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.i= etf.org_html_rfc7120-23section-2D3&d=3DDwIBAg&c=3DFmY1u3PJp6wrcrwll3mSVzgfkbPSS6= sJms7xcl4I5cM&r=3DDtXLhb_G8hD85GLUyK8Z_tHchz8XPohfWYCwPbpStcU&m=3DVPvwZ58pXTamTD= 0lOqjz84Jkf5QVaIlhL2YiYAKqoVg&s=3DLwg0SR9f74E08PQbAyw6awTf6d5NAzlLz4ylvxQXZ10&= e=3D =20 The process for requesting and obtaining early allocation of code points is as follows: =20 1. The authors (editors) of the document submit a request for earl= y allocation to the Working Group chairs, specifying which code points require early allocation and to which document they shou= ld be assigned. =20 2. [wg chairs do stuff] =20 =20 Nowhere does it link to or mention a page at IANA where to do this. Nowhere does it state I should not contact the WG chairs. =20 Now, there is a strangeness in section 2: =20 The following conditions must hold before a request for early allocation of code points will be considered by IANA: =20 a. The code points must be from a space designated as "RFC Required", "IETF Review", or "Standards Action". Additionally, requests for early assignment of code points from a "Specification Required" registry are allowed if the specification will be published as an RFC. =20 I don't understand why "Expert review" is not listed here. Is it by design or an error in RFC 7120 ? =20 Additionally, the document does not point to any other instructions for the process in the case of Expert Review. Who to contact where? =20 Paul =20 > Date: Mon, 22 Jan 2018 10:35:13 > From: Tero Kivinen > Cc: "ipsec@ietf.org" , Paul Hoffman > To: Paul Wouters > Subject: Re: [IPsec] WG Last Call comments on draft-ietf-ipsecme-spli= t-dns >=20 > Paul Wouters writes: >> On Mon, 22 Jan 2018, Paul Hoffman wrote: >> >>> Greetings. This document is still listed as in WG Last Call, althou= gh I haven't seen anything in the archive about that Last Call closing. >> >> Yeah, the WGLC ended Nov 9. I have pinged the chairs a few times >> already, and requested an early code point for INTERNAL_DNSSEC_TA. >> (we already have one for INTERNAL_DNS_DOMAIN) > > I have not seen any request come from IANA to me as an expert. WG > chairs do not assign code points, IANA does that, and they will only > start the process when such request is submitted to them. This will > automatically happen during the RFC publication process. You can also > submit the request to the IANA at any time, as this is Expert review > registry... > > So make the request through the IANA and then it will come to me (and > got tickets assigned which will send me reminders if I do not act on > it quickly enough) and then you can get the number allocated. > > I though I had already explained this year ago when we assigned > INTERNAL_DNS_DOMAIN, i.e., for expert registries, there is no need to > go through IESG or WG chairs, you can fill in the form in IANA page, > and then it will come to the expert for review... > --=20 > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_ipsec&d=3DDwIBAg&c=3DFmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r= =3DDtXLhb_G8hD85GLUyK8Z_tHchz8XPohfWYCwPbpStcU&m=3DVPvwZ58pXTamTD0lOqjz84Jkf5QVa= IlhL2YiYAKqoVg&s=3DalAy_YYi5GXoFXZxPAR6fdo_nMCLOH6SBRm7H0U5Odk&e=3D > =20 =20 --B_3599455637_2151437563 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIISBAYJKoZIhvcNAQcCoIIR9TCCEfECAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg+5MIIFqDCCBJCgAwIBAgIQCuvDwxHaHKymSygUiz0IATANBgkqhkiG9w0BAQsFADBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTYx MDAzMDAwMDAwWhcNMTkxMDAzMTIwMDAwWjCBxTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh bGlmb3JuaWExFDASBgNVBAcTC0xvcyBBbmdlbGVzMTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jw b3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMgYW5kIE51bWJlcnMxJDAiBgNVBAMTG01pY2hl bGxlIENvdHRvbiBJQU5BIDNPY3QxNjEnMCUGCSqGSIb3DQEJARYYbWljaGVsbGUuY290dG9u QGlhbmEub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6V4aMB8RQMy4vQOd nvINsoYARWq26DERE228XVCA7SxnxpHKRAgnpV4iBoL5rgjsiJy5utpRlbCZcV7PVaVp6yxM ozNUSzmiSu+O04PyYWjvJRzSLda6W0hc8B766JDK3V8QVX+5Pnt9E2JxyYL6j5zTrD/kZGTB XpaRNBF5DorhvPEwXNuRyWt5yD3m4vMwinCahC+5DB78PlxvbbEgTLenW8ZnSOunflX11Q8W XkYBAHEWLSDEO8MY4t7b7FBTWoDA6arnmiJApfBm+tfJ9VPto6KX1YWWuUMrmg7PVF6jfiuW ncwVZzed6VBW9Sp1oVKWP3GXraq0glyTutf5MQIDAQABo4IB8TCCAe0wHwYDVR0jBBgwFoAU 5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFD4OJSm8pR0KSROJ2Te94XiGhEJAMAwG A1UdEwEB/wQCMAAwIwYDVR0RBBwwGoEYbWljaGVsbGUuY290dG9uQGlhbmEub3JnMA4GA1Ud DwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4 BgpghkgBhv1sBAECMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9D UFMwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EtZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5j b20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8v Y2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqG SIb3DQEBCwUAA4IBAQCFn08dbc9474OYmBeeFe4I08uzdP/Glg78Au1o7+IhufO+BN/fqn31 VhE7Q2aYCh28LF99PbdJ2IOBsz+BUGlrz7C0UvrHjmbXBTuR/gHez2Hmk6SOu0o4anLJqVFl xMzQtpBQXWM0K8GlyqDlPtiWQDORtUsMOXnL2+smNqb5xoz1SyK30KEMMeq9ZndDuBpM1Gyh 7JdgiLypKnYfRc1c1INCWiDlvpTA+C60BZSv5e/k1GMW0USd7TZTzphQxKmLNRUXUxRjub3H Yiby5y1hTnUyalL6HHbYVJX8bOgmaaOAjLvsJzX0rHRaMYlFbC4CgNlQNExJd4Xt7c39ghay MIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsFADBlMQswCQYD VQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQu Y29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1MTIw MDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEy IEFzc3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q1 78AneRstBYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4i LCv4un7JNTtW8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P 5lB6UB8lRejxia/N/17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqC QQrc6dn1kReOxiGtODwT5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BP y4KKDXEY5KbgiSwb87JzPMGwkp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMB Af8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUH MAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDov L2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0 aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGzBgNVHSAEggGqMIIBpjCCAaIGCmCG SAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABoAGkAcwAg AEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEAYwBj AGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAv AEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABB AGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBs AGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y 17yUC9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG 9w0BAQsFAAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61 +uBiGZmmB5p8Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbO kWDj+aBWDEgQzjNoe82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C 2bBdkbSTh/mWloFVQI5m7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZV PVgSETJuvUMMTTTbe8ZC2+y+q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjCC A7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAw MFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyx h/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wx hCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEb w4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0K yEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+ HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMC AYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYD VR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i 7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfq VsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/ K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9r DDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+l t2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIxggIPMIICCwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQCuvDwxHaHKym SygUiz0IATANBglghkgBZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCCCkxieIbbnkgvgIyzP 2SWcEYGBcdjTB5CGwdzUdrKv8jAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xODAxMjIxNjQ3MTdaMA0GCSqGSIb3DQEBAQUABIIBAOBAAEyVk4y+DyeXQYbj 5MINZaDnyTOXHtoBsIsVWrlpYKYuChQVjEAQI7E5JvTyGo47laEG7iC6LM0OVgW0jIftt/+y Lvk3b3RO7rCWqOoBu+vjH8piJatHGYjaePNQS75z5pM4t+PLDp8PNbsvgsK/fAAAEID+7+qZ LNutKhB2gk17QuydmavMZLxstX/fPKyaCLuNo6E5L/77jngeBRrIIHYwtqc9GiBCjLnCTusa mCQPwrhxtrmZkmPueRlcCODOoiqGJcWO/UKLcedOgA8XI1mfDb48AQhxBpmCLXirns7vAb/n N79gt62fR1tUtXrAdxXM08BX/LGZ0RZ/mSo= --B_3599455637_2151437563-- From nobody Mon Jan 22 08:50: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 33415127601 for ; Mon, 22 Jan 2018 08:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 1DW76j_KxZHv for ; Mon, 22 Jan 2018 08:50:04 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28EE9124207 for ; Mon, 22 Jan 2018 08:50:04 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 22 Jan 2018 08:50:01 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Mon, 22 Jan 2018 08:50:02 -0800 From: Paul Hoffman To: Paul Wouters CC: "ipsec@ietf.org WG" Thread-Topic: [IPsec] [Ext] Re: WG Last Call comments on draft-ietf-ipsecme-split-dns Thread-Index: AQHTk5YSuug1aAPmNkOCfknQpe4MzqOAn8uAgAABO4A= Date: Mon, 22 Jan 2018 16:50:02 +0000 Message-ID: References: <85F3BEFC-506E-4A2D-8CB3-19B4C5AB45BA@icann.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <10CB197B57FD294D9EBCD4CEDBFA0AFF@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] [Ext] Re: WG Last Call comments on draft-ietf-ipsecme-split-dns 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, 22 Jan 2018 16:50:05 -0000 On Jan 22, 2018, at 8:45 AM, Paul Wouters wrote: > I'm trying not to define any DNS terms in this document and stay out of > any character/domain/hostname discussion. How about: >=20 > The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be passed > to another (DNS) program for processing. As with any network input, the > content should be considered untrusted and handled accordingly. Yep, that works for me. With that and the other change you said was fine, I= think this is quite ready for IETF Last Call. --Paul Hoffman= From nobody Mon Jan 22 08:52: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 7D9DC126E64; Mon, 22 Jan 2018 08:52:01 -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.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151663992146.8109.14477590352866908189@ietfa.amsl.com> Date: Mon, 22 Jan 2018 08:52:01 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-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, 22 Jan 2018 16:52: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-04.txt Pages : 11 Date : 2018-01-22 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-split-dns-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 22 10:29: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 93028126E3A; Mon, 22 Jan 2018 10:29: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 moJl9Px9EC8h; Mon, 22 Jan 2018 10:29:06 -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 C25F8124D37; Mon, 22 Jan 2018 10:29:05 -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 w0MISwik003214 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Jan 2018 20:29:02 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w0MISq8N013123; Mon, 22 Jan 2018 20:28:52 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23142.11620.883596.569375@fireball.acr.fi> Date: Mon, 22 Jan 2018 20:28:52 +0200 From: Tero Kivinen To: Paul Wouters Cc: "ipsec\@ietf.org" , ietf@ietf.org In-Reply-To: References: <85F3BEFC-506E-4A2D-8CB3-19B4C5AB45BA@icann.org> <23142.1201.707067.352387@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 16 min X-Total-Time: 15 min Archived-At: Subject: Re: [IPsec] WG Last Call comments on draft-ietf-ipsecme-split-dns 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, 22 Jan 2018 18:29:08 -0000 Paul Wouters writes: > On Mon, 22 Jan 2018, Tero Kivinen wrote: > > [ added ietf@ietf.org to get a general discussion on this, as it seems > this is a procedural issue not specific to the WG ] You are trying to follow wrong procedure. There is NO early allocations for expert review registries. There are only normal allocations for expert review registries, and those can be done at any time. The expert (and registry) might then have other requirements before doing allocation, but as such all allocations are normal allocations. > execsum: I followed RFC 7120 to get an Early Code Point, and there is > confusion about the process between me, the chairs and the epxert. RFC7120 does not apply here. From introduction: This memo addresses the early allocation of code points so that reservations are made in the IANA registries before the publication of an RFC. The early allocation mechanisms are applied only to spaces whose allocation policy is "Specification Required" (where an RFC is used as the stable reference), "RFC Required", "IETF Review", or "Standards Action". For an explanation of these allocation policies, see [RFC5226]. > I followed https://tools.ietf.org/html/rfc7120#section-3 > > > Nowhere does it link to or mention a page at IANA where to do this. > Nowhere does it state I should not contact the WG chairs. That would be true for procedure following RFC7120, but as your request is not for registries specified in RFC7120 you should not even try to follow those rules. > Now, there is a strangeness in section 2: > > The following conditions must hold before a request for early > allocation of code points will be considered by IANA: > > a. The code points must be from a space designated as "RFC > Required", "IETF Review", or "Standards Action". Additionally, > requests for early assignment of code points from a > "Specification Required" registry are allowed if the > specification will be published as an RFC. > > I don't understand why "Expert review" is not listed here. Is it by > design or an error in RFC 7120 ? By design. Expert review assignments can be done at any time and expert will decide whether those are done or not (but might need to follow rules set when registry was created too). It would be possible to get expert to assign you number even before there is internet draft, so there is no need for "Early allocations". When you are trying to allocate things earlier than you normally could, i.e., before the RFC is published for "RFC required" etc, then you need to get approval for that "Early allocation", but not for registries where you can do allocations at any time. > Additionally, the document does not point to any other instructions > for the process in the case of Expert Review. Who to contact where? Go to the iana.org web page and click "Apply for assignment" in the protocol assignments part, and then select "all other protocol registries" from there and fill in the form. This will mean that there will be IANA ticket created for that, and they will then contact the expert to check the request and depending on expert's answer they will do the allocaton or not. -- kivinen@iki.fi From nobody Mon Jan 22 10:49:25 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 BE8BE124D37 for ; Mon, 22 Jan 2018 10:49:23 -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 gpwwqZdPX2HU for ; Mon, 22 Jan 2018 10:49:22 -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 08F66127599 for ; Mon, 22 Jan 2018 10:49:21 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zQL7f2055z34r for ; Mon, 22 Jan 2018 19:49:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1516646958; bh=Ihy7MrsqjCyspoxgs1yAtLVdef6rAXr6LcUd056bGSk=; h=Date:From:To:Subject:In-Reply-To:References; b=akjc/TDmupeMYV9+Ry2oG1JxNtrxcebMsvWqqfuPzlIk9adVCbRJN3h4zP1doHS8R Yv09ZbJsnSrLxDNS2QqdgW++7+fihjvCpM5kQfN0a3L0yGfWftWqO7ZalYfKNWd656 v4Os8WlMiIjjw/+xl/hJd0L8vbfKGr9A01rMbWPs= 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 QHvwlDv4ocYw for ; Mon, 22 Jan 2018 19:49:16 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Mon, 22 Jan 2018 19:49:16 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 023CA61CDD; Mon, 22 Jan 2018 13:49:15 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 023CA61CDD Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EA0A041982E3 for ; Mon, 22 Jan 2018 13:49:15 -0500 (EST) Date: Mon, 22 Jan 2018 13:49:15 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <151663992146.8109.14477590352866908189@ietfa.amsl.com> Message-ID: References: <151663992146.8109.14477590352866908189@ietfa.amsl.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] I-D Action: 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: Mon, 22 Jan 2018 18:49:24 -0000 On Mon, 22 Jan 2018, internet-drafts@ietf.org wrote: > Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-04.txt > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-04 This version addresses the two points raised by Paul Hoffman. I believe this document is ready for IETF LC. Paul From spiriyath@juniper.net Tue Jan 23 02:29:43 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 86471124B17 for ; Tue, 23 Jan 2018 02:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MN1-VkEIO5NA for ; Tue, 23 Jan 2018 02:29:40 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 675691271DF for ; Tue, 23 Jan 2018 02:29:39 -0800 (PST) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0NASYIY015460 for ; Tue, 23 Jan 2018 02:29:38 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=SSIhJf/+aFpRX8XR8d8QUoQMTrYV+ia4PzQQGVTXCp4=; b=pkzm9t7mHPM2ftiITXtuenwKxy4ZVr/nvtUgG5eKy+9CeGU+UcvpfyBg81mrBpjlGLuZ xofFJ3gzZL/xXnMqVugAcegwfuuLX5KZl4wpCj0ifT67hNdPp9S9kXi8r74KMahLcoCC o4GK6qMUeS7LthNIiwS18YwLx3FKuRPZsQhdNnMUHrM2bkCQrM79nZc/X9djd8RideSC sC3+8L53Vt2vrpXnMAN2r56inINkY02k2v7GSXTEtK7qKD7Ct77Ecu1NSJ/gclakS4/K dFIsM6c32kvUGfXBijCLtsKIG1LH2TfOyIIMbLzpGdhhcnRFJy+t0dEb4H1+FBOXlGEy AA== Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0050.outbound.protection.outlook.com [216.32.180.50]) by mx0b-00273201.pphosted.com with ESMTP id 2fp2j3g3hm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 23 Jan 2018 02:29:38 -0800 Received: from CY1PR05MB1867.namprd05.prod.outlook.com (10.162.167.145) by CY1PR05MB1945.namprd05.prod.outlook.com (10.162.216.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.5; Tue, 23 Jan 2018 10:29:36 +0000 Received: from CY1PR05MB1867.namprd05.prod.outlook.com ([10.162.167.145]) by CY1PR05MB1867.namprd05.prod.outlook.com ([10.162.167.145]) with mapi id 15.20.0444.008; Tue, 23 Jan 2018 10:29:36 +0000 From: Shibu Piriyath To: "ipsec@ietf.org" Thread-Topic: Dynamic PMTUD over IKEv2 Thread-Index: AQHTlDRDSN/RXMRCOUiP6QslUXm8sQ== Date: Tue, 23 Jan 2018 10:29:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.13] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR05MB1945; 7:JePIRy/RrK1oV9AmsMY+Ke40TlD2pFbRMYqdNyYBJERt7mgz4MmU5bEWZx6AzN5o3irZuyMdLDGVSGUtwkorNC/x6GU42UT48wq5EjTX3H/jA296/37fZZmsPgrJFMMTnng8qF7U45c4lehL3d3Orlve8QS69oM+Eoeg8vT93YUBSkR4bBbVO5PA76IOYtE8qbBrOW7rUfWF73gPAeAovhK9S+q9+Do3UG9Jm7W0vg1q12ewxcDd9JzOirVLdB39 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 9e315976-8532-41ac-5ffb-08d5624c3392 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:CY1PR05MB1945; x-ms-traffictypediagnostic: CY1PR05MB1945: 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)(3002001)(10201501046)(93006095)(93001095)(3231023)(2400081)(944501161)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:CY1PR05MB1945; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY1PR05MB1945; x-forefront-prvs: 05610E64EE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(346002)(376002)(366004)(396003)(53754006)(199004)(189003)(236005)(25786009)(5640700003)(6506007)(606006)(6436002)(102836004)(55016002)(316002)(66066001)(9686003)(478600001)(54896002)(33656002)(2906002)(2501003)(53936002)(14454004)(966005)(6306002)(8676002)(3660700001)(105586002)(106356001)(1730700003)(8936002)(81156014)(81166006)(2900100001)(74316002)(6116002)(68736007)(3846002)(7696005)(6916009)(2351001)(6606003)(19627405001)(99286004)(86362001)(97736004)(3280700002)(77096007)(5660300001)(561944003)(7736002)(26005)(558084003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB1945; H:CY1PR05MB1867.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: 1v3B8t23DH6dLNATI7GuIx94xbN15ZmZHTfYwa+FV0pij41nAooaAgm3e7lkFPnDECZgja9T0cv3GLJENpomNw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR05MB1867D823D8A05A0D92530830A1E30CY1PR05MB1867namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 9e315976-8532-41ac-5ffb-08d5624c3392 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2018 10:29:36.4591 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB1945 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-23_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=689 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801230144 Archived-At: Subject: [IPsec] Dynamic PMTUD over IKEv2 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, 23 Jan 2018 10:32:03 -0000 --_000_CY1PR05MB1867D823D8A05A0D92530830A1E30CY1PR05MB1867namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, We have come up with a proposal for discovering Path MTU between IPsec head= -ends dynamically using IKEv2 messages. Please review the draft - https://tools.ietf.org/html/draft-spiriyath-ipsec= me-dynamic-ipsec-pmtu-00 and let us know your comments, Thanks, Shibu. --_000_CY1PR05MB1867D823D8A05A0D92530830A1E30CY1PR05MB1867namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi All,


We have come up with a proposal f= or discovering Path MTU between IPsec head-ends dynamically using IKEv2 mes= sages.

Please review the draft - https://tools.ietf.org/html/draft-spiriyath-ipsecme-dynamic-ipsec-pmtu-00 and let us know your comments,


Thanks,

Shibu.


--_000_CY1PR05MB1867D823D8A05A0D92530830A1E30CY1PR05MB1867namp_-- From nobody Tue Jan 23 09:56: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 68F4C1276AF for ; Tue, 23 Jan 2018 09:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaKM_Lf5yrEB for ; Tue, 23 Jan 2018 09:56:41 -0800 (PST) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8CB1275AB for ; Tue, 23 Jan 2018 09:56:40 -0800 (PST) Received: by mail-wr0-x230.google.com with SMTP id v15so1511488wrb.8 for ; Tue, 23 Jan 2018 09:56:40 -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=sSJ7xqh5DPmtbQ11Hh0XlVvMU3PE3Qkxf8TI78u+1dc=; b=HU6Be9VohgiF9sM4kTFS4ehO+vJyqw9aIlWtdQaweS8f0ZKsUkz3n71LE4ezuFvhxN 4a2iSxQBHA4ONRBEy4U9QIz/FwDXoE/2wuZcFKorDc1oUqwXjcwXNp/+gI3mt2T0tXru DQNHe9RVsqtxmTS7lKDQ7glvo7+JjF2ghfAZqUIq2rCr9LNb1rjAycszQf7XsF5SjwFY kvkX0xKRitXeihlGPfTnt3riVkDHAsyy3DIZ4RiRfzVW7R4KmFnTCTtRK2YhOSXm8sUb O0XMlO12st4dx2CIQPo87rrBQu+DEWzRJaPJGu2NIe1GLXM6F5S0pERbup7/tg/muLxD T9Ug== 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=sSJ7xqh5DPmtbQ11Hh0XlVvMU3PE3Qkxf8TI78u+1dc=; b=sXyPgk6XZoid4zGDStt335Rnydqa8xsTOBphyX82B2OJrnM7EcJHvTxTR7VSvfxEsc rn5GlSNcEdJ9l5+M4Lan5iksngSeKFVM0U4uhjIHNqeVGVj/LQP86sBV5M3p8xNIVpw2 E0tSvJdAORCp+fhbUOwwVN1v/yop6sU0Ac87RDZqUxYIJxC7u8xIcvZFrNh7tOILt5Lv OUnVP4mZHRY6TjF1HyVuxOvAQxwaoBDKl7h7Y81BmH7PH26ZVbum3oSnTlvqw7lrATN2 WGoiV+pY0tembhwX/hOQZmLGxkX/fyDrm0IhpsjCZU8DN795IHQCp364lg5F3VDwdgyP 3gIA== X-Gm-Message-State: AKwxytd631Eg3pFhN0HU4jFj5CPD3dw7YFQ6U06bX1AYBKlZzQxYDEHl 4pX1Cd0/LyjYPnSZu+AGxNw= X-Google-Smtp-Source: AH8x225c+5st0Zmbc7Tcqw/KxvcLxRW3ywmj/dzzxBln/WHj3IU4wc/kRcmAy9qwbMLBvdoZ9g8Y+A== X-Received: by 10.223.155.196 with SMTP id e4mr3319951wrc.63.1516730199113; Tue, 23 Jan 2018 09:56:39 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id q13sm1158865wrg.3.2018.01.23.09.56.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jan 2018 09:56:38 -0800 (PST) From: Yoav Nir Message-Id: <9D48AC2A-32B8-42EF-B4DF-4825E4D75A32@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_03A09886-FB8F-4EE4-92E1-DBA0B8F18212" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 23 Jan 2018 19:56:36 +0200 In-Reply-To: Cc: "ipsec@ietf.org" To: Shibu Piriyath References: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [IPsec] Dynamic PMTUD over IKEv2 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, 23 Jan 2018 17:56:43 -0000 --Apple-Mail=_03A09886-FB8F-4EE4-92E1-DBA0B8F18212 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 23 Jan 2018, at 12:29, Shibu Piriyath = wrote: >=20 > Hi All, >=20 > We have come up with a proposal for discovering Path MTU between IPsec = head-ends dynamically using IKEv2 messages. > Please review the draft - = https://tools.ietf.org/html/draft-spiriyath-ipsecme-dynamic-ipsec-pmtu-00 = and let us know your comments, >=20 > Thanks, > Shibu. Hi Shibu. Thank you for working on this. I have some comments. Administrative/political:=20 This document proposes an IPv4-only mechanism. While the IETF has not = (yet?) approved" [1] (see discussion threads [2] and [3]), there needs = to be some justification for why we=E2=80=99re doing an IPv4-only = mechanism. Is this not a problem in IPv6 (Because we assume that PTB = responses propagate correctly in the IPv6 network that in the IPv4 = Internet routers routinely fragment) or is there some other mechanism = for IPv6? Terminology: - I usually encounter the terms ingress and egress for interfaces of a = particular router or host. I think it would be clearer to use =E2=80=9Ctun= nel ingress=E2=80=9D and =E2=80=9Ctunnel egress=E2=80=9D or = =E2=80=9Cencryptor=E2=80=9D and =E2=80=9Cdecryptor=E2=80=9D - "Overhead is the number of bytes required for tunnel encapsulation=E2=80= =9D. Overhead is then used as a number that is subtracted from physical = MTU. However, the overhead is not constant. IPsec requires padding to = some multiple of 4, 8, or 16 depending on the algorithm. I suggest = modifying the definition of overhead to =E2=80=9COverhead is the = *maximum* number of bytes required for tunnel encapsulation=E2=80=9D - "fragmentation within the tunnel is allowed=E2=80=9D - this is about = fragmenting an ESP packet that is too large. I don=E2=80=99t think = =E2=80=9Cwithin the tunnel=E2=80=9D is the best term for this. How about = =E2=80=9Cfragmentation of the ESP packet by intermediate routers is = allowed=E2=80=9D ? Technical: If the packet length is greater than the tunnel MTU and the packet can be fragmented, the ingress node fragments the packet, encapsulates each fragment, and forwards each encapsulated fragment through the tunnel. That=E2=80=99s one way of doing things. Another is to encapsulate the = packet anyway and send the ESP packet out in fragments. This way is also = compatible with IPv6. I know of at least one implementation that does = this. There is an assumption that the egress node knows about the = fragmentation. Usually some layer in the stack will defragment before = handing the IPsec stack a re-assembled IPsec packet to decrypt. Maybe = some implementations are more integrated and the IPsec stack has this = information, but this assumption needs to be stated explicitly. Some routers drop packets that are too big instead of fragmenting them. = Of these, some send back the PTB and some don=E2=80=99t. An active PMTUD = method (ingress sends dummy packets of various sizes and receives = acknowledgements from egress if they arrive) can work with such = intermediate routers. This method cannot. How do you prevent the following attack? The attacker manages to drop or = delay one ESP packet. It captures this packet and retransmits it in = small fragments. This induces the egress to send the notification from = section 3.2 to the ingress, causing it to internally fragment all future = packets. Yoav [1] https://tools.ietf.org/html/draft-ietf-sunset4-ipv6-ietf-01 [2] https://www.ietf.org/mail-archive/web/ietf/current/msg104661.html [3] https://www.ietf.org/mail-archive/web/ietf/current/msg104721.html --Apple-Mail=_03A09886-FB8F-4EE4-92E1-DBA0B8F18212 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = 23 Jan 2018, at 12:29, Shibu Piriyath <spiriyath@juniper.net> wrote:

Hi = All,

We have come up with a proposal for = discovering Path MTU between IPsec head-ends dynamically using IKEv2 = messages.
Please review the draft - https://tools.ietf.org/html/draft-spiriyath-ipsecm= e-dynamic-ipsec-pmtu-00 and let us know your = comments,

Thanks,
Shibu.

Hi = Shibu.

Thank you for working on = this.  I have some comments.


Administrative/political: 
This = document proposes an IPv4-only mechanism.  While the IETF has not = (yet?) approved" [1] (see discussion threads [2] and [3]), there needs = to be some justification for why we=E2=80=99re doing an IPv4-only = mechanism.  Is this not a problem in IPv6 (Because we assume that = PTB responses propagate correctly in the IPv6 network that in the IPv4 = Internet routers routinely fragment) or is there some other mechanism = for IPv6?


Terminology:
- I usually encounter the = terms ingress and egress for interfaces of a particular router or host. = I think it would be clearer to use =E2=80=9Ctunnel ingress=E2=80=9D and = =E2=80=9Ctunnel egress=E2=80=9D or =E2=80=9Cencryptor=E2=80=9D and = =E2=80=9Cdecryptor=E2=80=9D
- "Overhead is the number of bytes required for tunnel = encapsulation=E2=80=9D. Overhead is then used as a number that is = subtracted from physical MTU.  However, the overhead is not = constant. IPsec requires padding to some multiple of 4, 8, or 16 = depending on the algorithm.  I suggest modifying the definition of = overhead to =E2=80=9COverhead is the *maximum* number of = bytes required for tunnel encapsulation=E2=80=9D
- = "fragmentation within the tunnel is allowed=E2=80=9D - this is about fragmenting an ESP packet = that is too large. I don=E2=80=99t think =E2=80=9Cwithin the = tunnel=E2=80=9D is the best term for this. How = about =E2=80=9Cfragmentation of the ESP packet by intermediate = routers is allowed=E2=80=9D ?




Technical:
                                =
                                If the
   packet length is greater than the tunnel MTU and the packet can be
   fragmented, the ingress node fragments the packet, encapsulates each
   fragment, and forwards each encapsulated fragment through the =
tunnel.

That=E2=80=99s one way of doing things. Another is to encapsulate =
the packet anyway and send the ESP packet out in fragments. This way is =
also compatible with IPv6.  I know of at least one implementation that =
does this.


There is an assumption that = the egress node knows about the fragmentation. Usually some layer in the = stack will defragment before handing the IPsec stack a re-assembled = IPsec packet to decrypt.  Maybe some implementations are more = integrated and the IPsec stack has this information, but this assumption = needs to be stated explicitly.


Some = routers drop packets that are too big instead of fragmenting them. Of = these, some send back the PTB and some don=E2=80=99t. An active PMTUD = method (ingress sends dummy packets of various sizes and receives = acknowledgements from egress if they arrive) can work with such = intermediate routers. This method cannot.


How do you prevent the = following attack? The attacker manages to drop or delay one ESP packet. = It captures this packet and retransmits it in small fragments. This = induces the egress to send the notification from section 3.2 to the = ingress, causing it to internally fragment all future = packets.

Yoav


= --Apple-Mail=_03A09886-FB8F-4EE4-92E1-DBA0B8F18212-- From nobody Tue Jan 23 10:52:31 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 16B76128954; Tue, 23 Jan 2018 10:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=W2Z84OxB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=r8wfWaJs Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTRfH8B1Hv66; Tue, 23 Jan 2018 10:52:28 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35DE2127AD4; Tue, 23 Jan 2018 10:52:25 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 70A4A20D12; Tue, 23 Jan 2018 13:52:24 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Tue, 23 Jan 2018 13:52:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=XiJz4gY6WhAzc3mktr5X8vhvg6EEm nhlKoucxOLi+XE=; b=W2Z84OxBVa8iwig1b7DsIxDau9xKQvXX0cSGLNwvmADSt GZi3FxXxZ+YdB15p1maItA8uG8uaBN+DIDKvts107sCDu4cQgncEJsPQEL7iDLJN L4xQq+KQNYEhqV+90kwRIj39wSvlkTTAsw86e6svNTDoO/vWac+XuTsZJmSS8T78 /igYHtkQGvwf2IDDcQD0Svn0Z16XmDRhU/cwJAwbSYsjdRHruA1Z8cac0Hn5MLlh iJ7LYBo6IrMmG7SF5pnOm31ZIpGxogv0/dz9rYo88YmxTmhAu327iNRQXDymPVtd fz3jlL2wGDgj2CQGTG42f5zF5t+XY86W0vriAwW7g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=XiJz4g Y6WhAzc3mktr5X8vhvg6EEmnhlKoucxOLi+XE=; b=r8wfWaJs2ESJyB4Lt3anCG m6pPBpfYkhPhc2SE71R7A0thmva8mXmsDdlkQp54t7CN0SOD2hw1h1syHOi6PIPV RD3zQJ89lxNyayMFqZfD/r2DS4+QVHSKIu/9qNQRajja3AYPkw+86uiZZ+UmLg2X Dk4IxFpBB2AN9+Vknf2vULD4fbxYtvv2AO6MX703uw+WajR4iql2mhgXMy0rX4Vg KbCeaUI6zxaxKUSUH2Rb9/iFAlmxtO1JjBAsGUX8+nwf1J/o4Kad++WJQkw6iVWH MZTtOxFUgF9G61269F3Ss3py6DbhlL/SLyhLl5ooPykGEiEPes4dKORTolTNQuEA == X-ME-Sender: Received: from rtp-vpn1-764.cisco.com (unknown [173.38.117.79]) by mail.messagingengine.com (Postfix) with ESMTPA id EAE457E2E5; Tue, 23 Jan 2018 13:52:23 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <151099196129.9056.6462331514698284743@ietfa.amsl.com> Date: Tue, 23 Jan 2018 13:52:22 -0500 Cc: gen-art , ipsec@ietf.org, draft-ietf-ipsecme-eddsa.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8C61F594-323C-45BF-B32F-87894FB631C1@cooperw.in> References: <151099196129.9056.6462331514698284743@ietfa.amsl.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [IPsec] [Gen-art] Genart last call review of draft-ietf-ipsecme-eddsa-04 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, 23 Jan 2018 18:52:30 -0000 Christer, thanks for your review. I have entered a No Objection ballot. Alissa > On Nov 18, 2017, at 2:59 AM, Christer Holmberg = wrote: >=20 > Reviewer: Christer Holmberg > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-ipsecme-eddsa-04 > Reviewer: Christer Holmberg > Review Date: 2017-11-17 > IETF LC End Date: 2017-12-04 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: The document is well written, and almost ready for = publication. > However, I have some editorial change suggestions that I think would = improve > the readability of the document. >=20 > Major issues: None >=20 > Minor issues: None >=20 > Nits/editorial comments: >=20 > Q1: > ---- >=20 > In the Abstract the text says " Edwards-curve digital signature = algorithm", > without the EdDSA abbreviation, and in the Introduction the text says = "EdDSA" > without the enhancement. >=20 > I suggest to say "Edwards-curve digital signature algorithm (EdDSA)" = in the > first occurrences within the Abstract and the Introduction. >=20 > Q2: > ---- >=20 > In the Introduction the text says "The latter RFC" and "that = document". I > suggest to explicitly use the RFC numbers instead. >=20 > That makes it easier to read, and there is always a theoretical change = that > someone files an errata, or update the text within another RFC, that = changes > the order to the RFCs so that "The latter" etc points to the wrong = RFC... >=20 > Q3: > ---- >=20 > In the Introduction the text says: >=20 > "EdDSA defines the binary format of the signatures that should be = used > in the "Signature Value" field of the Authentication Data Format in > section 3." >=20 > Section 3 of what? I assume you refer section 3 of RFC 8032, so I = suggest to > explicitly say that. Otherwise someone (at least I did) may jump to = section 3 > of the draft and start looking. >=20 > The same thing applies to "Appendix A". Please indicate the RFC = number. >=20 > Q4: > ---- >=20 > In the Introduction the text says: >=20 > "we define a new value" >=20 > I suggest to say "this document defines a new value". >=20 > Or, you could even say "section 2 of this document defines a new = value". >=20 > Q5: > ---- >=20 > In section 3, I suggest to add a reference (URL?) to the hash = algorithm > registry. >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Jan 23 13:04: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 7DF0712AF83 for ; Tue, 23 Jan 2018 13:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxDPN-rCBATU for ; Tue, 23 Jan 2018 13:04:40 -0800 (PST) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C18FF12D7F3 for ; Tue, 23 Jan 2018 13:04:39 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id m136so1127305pga.12 for ; Tue, 23 Jan 2018 13:04:39 -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=HPBAn6/4CveDP6UfsJL44d/ytsf38eAFF2aPrycNKbA=; b=gtJN6rK93yABgSSF1yJHn6mwHq+my6zZquqGDNTHnWOXItDM0kBTgOH1EAvw6pc32X MRMc046/0ZTFOOb2WJj1zoZa32G4ksRQrv9Gwa4fTQXs0GhXUdnqvXM7Ovho6AeiTR0Z Bfky0z8qbGVeiO35190VxpPSbZECZyxj3A0MeJrDvKUXokzxTiio0+GWnTQM6xztTbZo R5QlmpMhZW1SYc4TMhY5V54SeDoMrw2d2dWJsbBoi14vFLiXzSEZs9IJGCZHi+exRXM9 OADvc2p5F6DpRd+U0zx/QwVT9LH7r3fiAwwjGkEZFTjFd+7+7/3cY6AQzDqsQjdxg9WH kJIQ== 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=HPBAn6/4CveDP6UfsJL44d/ytsf38eAFF2aPrycNKbA=; b=muOU4P0kjZaQVmzEyEhOzOSYaFet5+DNBvIEBk7CGU2AJyMLDHGozy4XNgiQkigg0k gdSkEaQPAUXZOJb30rtjZsNC/FOnnUQpzEjaTv7ntv6hy+ZzYqKpipiCHUNvTQVTOgF0 ZTZYwXJoT9joBAYiyxNZbnhSvGR+sOAPPhKIPwZOnJH05Wz4O39KJQd1DyITaGgQhd11 UPBVNvsHiFJkHoW13/CG7szShGrzSCqBmfIUWfePCy/LsjBlfrOliHlj4br8ffK5LS1Y JJV+JMmcI29uTuQabcEDTbq+XJRRJiKQwqARkx/SiY2gHi4AqxDuG+UwV7yxkaq7got6 n8og== X-Gm-Message-State: AKwxytcv/cjhcTVziyh4AgqBdNo3s37zTFOWobEUw7qJSONJsEw9xum5 g5LPiXdvPlULXqG2SDzDG0E= X-Google-Smtp-Source: AH8x224KEhBPO8DK//psN/arJsIWkkcNjoYOuHfJLikOAwlJTJEU8EQGq26ABLEq3tkptpC/DtfHcg== X-Received: by 2002:a17:902:8487:: with SMTP id c7-v6mr6387082plo.410.1516741479240; Tue, 23 Jan 2018 13:04:39 -0800 (PST) Received: from ?IPv6:2600:1010:b02e:b5be:754e:a3ae:abe5:1539? ([2600:1010:b02e:b5be:754e:a3ae:abe5:1539]) by smtp.gmail.com with ESMTPSA id r27sm5916270pfj.75.2018.01.23.13.04.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jan 2018 13:04:37 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Dan Wing In-Reply-To: <9D48AC2A-32B8-42EF-B4DF-4825E4D75A32@gmail.com> Date: Tue, 23 Jan 2018 13:04:30 -0800 Cc: "ipsec@ietf.org" , Yoav Nir Content-Transfer-Encoding: quoted-printable Message-Id: <2064C97D-2E9A-4BEE-851B-5F91D0E08413@gmail.com> References: <9D48AC2A-32B8-42EF-B4DF-4825E4D75A32@gmail.com> To: Shibu Piriyath X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] Dynamic PMTUD over IKEv2 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, 23 Jan 2018 21:04:42 -0000 > On Jan 23, 2018, at 9:56 AM, Yoav Nir wrote: >=20 >=20 >> On 23 Jan 2018, at 12:29, Shibu Piriyath = wrote: >>=20 >> Hi All, >>=20 >> We have come up with a proposal for discovering Path MTU between = IPsec head-ends dynamically using IKEv2 messages. >> Please review the draft - = https://tools.ietf.org/html/draft-spiriyath-ipsecme-dynamic-ipsec-pmtu-00 = and let us know your comments, >>=20 >> Thanks, >> Shibu. >=20 > Hi Shibu. >=20 > Thank you for working on this. I have some comments. >=20 >=20 > Administrative/political:=20 > This document proposes an IPv4-only mechanism. While the IETF has not = (yet?) approved" [1] (see discussion threads [2] and [3]), there needs = to be some justification for why we=E2=80=99re doing an IPv4-only = mechanism. Is this not a problem in IPv6 (Because we assume that PTB = responses propagate correctly in the IPv6 network that in the IPv4 = Internet routers routinely fragment) or is there some other mechanism = for IPv6? >=20 >=20 > Terminology: > - I usually encounter the terms ingress and egress for interfaces of a = particular router or host. I think it would be clearer to use =E2=80=9Ctun= nel ingress=E2=80=9D and =E2=80=9Ctunnel egress=E2=80=9D or = =E2=80=9Cencryptor=E2=80=9D and =E2=80=9Cdecryptor=E2=80=9D > - "Overhead is the number of bytes required for tunnel = encapsulation=E2=80=9D. Overhead is then used as a number that is = subtracted from physical MTU. However, the overhead is not constant. = IPsec requires padding to some multiple of 4, 8, or 16 depending on the = algorithm. I suggest modifying the definition of overhead to = =E2=80=9COverhead is the *maximum* number of bytes required for tunnel = encapsulation=E2=80=9D > - "fragmentation within the tunnel is allowed=E2=80=9D - this is about = fragmenting an ESP packet that is too large. I don=E2=80=99t think = =E2=80=9Cwithin the tunnel=E2=80=9D is the best term for this. How about = =E2=80=9Cfragmentation of the ESP packet by intermediate routers is = allowed=E2=80=9D ? >=20 >=20 >=20 >=20 > Technical: > If the > packet length is greater than the tunnel MTU and the packet can be > fragmented, the ingress node fragments the packet, encapsulates = each > fragment, and forwards each encapsulated fragment through the = tunnel. >=20 >=20 > That=E2=80=99s one way of doing things. Another is to encapsulate the = packet anyway and send the ESP packet out in fragments. This way is also = compatible with IPv6. I know of at least one implementation that does = this. >=20 >=20 > There is an assumption that the egress node knows about the = fragmentation. Usually some layer in the stack will defragment before = handing the IPsec stack a re-assembled IPsec packet to decrypt. Maybe = some implementations are more integrated and the IPsec stack has this = information, but this assumption needs to be stated explicitly. >=20 >=20 > Some routers drop packets that are too big instead of fragmenting = them. Of these, some send back the PTB and some don=E2=80=99t. An active = PMTUD method (ingress sends dummy packets of various sizes and receives = acknowledgements from egress if they arrive) can work with such = intermediate routers. Also known as PLPMTUD (packetization layer path MTU discovery), = https://tools.ietf.org/html/rfc4821. Most similar to IKE is this = presentation that describes PLPMTUD with STUN; IKE could do similar = thing, https://www.ietf.org/proceedings/73/slides/behave-10.pdf. There = is an RFC describing PLPMTUD for TCP, but I don't cite it because TCP. The I-D should also encourage re-setting the path MTU following the same = plateau algorithm described in RFC1191, or explain why that algorithm is = bad and instead the algorithm described in the I-D is superior (the I-D = describes discarding the learned MTU and re-learning, from scratch). -d > This method cannot. >=20 >=20 > How do you prevent the following attack? The attacker manages to drop = or delay one ESP packet. It captures this packet and retransmits it in = small fragments. This induces the egress to send the notification from = section 3.2 to the ingress, causing it to internally fragment all future = packets. >=20 > Yoav >=20 > [1] https://tools.ietf.org/html/draft-ietf-sunset4-ipv6-ietf-01 > [2] https://www.ietf.org/mail-archive/web/ietf/current/msg104661.html > [3] https://www.ietf.org/mail-archive/web/ietf/current/msg104721.html >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Jan 23 13:47: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 EF20E12D848 for ; Tue, 23 Jan 2018 13:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.229 X-Spam-Level: X-Spam-Status: No, score=-4.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhSfV_LqfdcV for ; Tue, 23 Jan 2018 13:47:34 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 045E812D838 for ; Tue, 23 Jan 2018 13:47:34 -0800 (PST) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id DED1782DA5F38 for ; Tue, 23 Jan 2018 21:47:29 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 23 Jan 2018 21:47:31 +0000 Received: from SJCEML521-MBB.china.huawei.com ([169.254.6.91]) by SJCEML702-CHM.china.huawei.com ([169.254.4.179]) with mapi id 14.03.0382.000; Tue, 23 Jan 2018 13:47:28 -0800 From: Linda Dunbar To: Paul Wouters , "ipsec@ietf.org WG" Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-04.txt Thread-Index: AQHTk6FhoWtb2aaILE+Vk3ufGXlH5KOAwkCAgAE44aA= Date: Tue, 23 Jan 2018 21:47:28 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66AFFF712@SJCEML521-MBB.china.huawei.com> References: <151663992146.8109.14477590352866908189@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.98] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66AFFF712SJCEML521MBBchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [IPsec] I-D Action: 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, 23 Jan 2018 21:47:36 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F66AFFF712SJCEML521MBBchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Paul, Sorry for the late comments. A question to your draft: Introduction: Is "Split DNS" less about "configuration for the secure tunnels", but more = about having two zones, one to be used by the internal network, the other u= sed by the external network? Basically Split DNS directs internal hosts to an internal domain name serve= r for name resolution and external hosts are directed to an external domain= name server for name resolution. Is it correct? If yes, the requests from internal network (the network with= in VPN) may not be via tunnel, isn't it? Or your "split DNS" is about one DNS with some domain name resolution reque= sts are from IPSec tunnels and others are not? Linda -----Original Message----- From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Wouters Sent: Monday, January 22, 2018 12:49 PM To: ipsec@ietf.org WG Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-04.txt On Mon, 22 Jan 2018, internet-drafts@ietf.org wrote: > Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-04.txt > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-split-dns-04 This version addresses the two points raised by Paul Hoffman. I believe this document is ready for IETF LC. Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_4A95BA014132FF49AE685FAB4B9F17F66AFFF712SJCEML521MBBchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Paul,
 
Sorry for the late comments.
 
A question to your draft:
 
Introduction:
 
Is "Split DNS" less about "configuration for the secure= tunnels", but more about having two zones, one to be used by the inte= rnal network, the other used by the external network?
Basically Split DNS directs internal hosts to an internal domain name = server for name resolution and external hosts are directed to an external d= omain name server for name resolution.
 
Is it correct? If yes, the requests from internal network (the network= within VPN) may not be via tunnel, isn't it?
 
Or your "split DNS" is about one DNS with some domain name r= esolution requests are from IPSec tunnels and others are not?
 
 
Linda
 
-----Original Message-----
From: IPsec [mailto:ipsec-bounces= @ietf.org] On Behalf Of Paul Wouters
Sent: Monday, January 22, 2018 12:49 PM
To: ipsec@ietf.org WG <ipsec@ietf.org>
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-04.txt
 
On Mon, 22 Jan 2018, inter= net-drafts@ietf.org wrote:
 
> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-04.txt<= /div>
 
> A diff from the previous version is available at:
 
This version addresses the two points raised by Paul Hoffman.
 
I believe this document is ready for IETF LC.
 
Paul
 
_______________________________________________
IPsec mailing list
 
--_000_4A95BA014132FF49AE685FAB4B9F17F66AFFF712SJCEML521MBBchi_-- From nobody Tue Jan 23 14:16: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 DC23A12D860 for ; Tue, 23 Jan 2018 14:16: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 BhKENE7K2qV4 for ; Tue, 23 Jan 2018 14:16:37 -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 EE33112D84E for ; Tue, 23 Jan 2018 14:16:36 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zR2hK4dyxz272; Tue, 23 Jan 2018 23:16:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1516745793; bh=0CP7Yk2aqEPHJZ1Eqk56WFdTF+tbtgBEg7JjW3GV9GM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=FBk6FZMkmudel6slgib1JM/PR8kEteyu97RcT2JzIVbV9HTRC4vm1D61Tti1keszM FbuI8nTjy+5SDpKL8DyoIARMjoOtfeHZ+/UmJFkqPI4QKu7RVvkfMo5Jkx0seIXTrr e4CO/KP0ntX0s8k/r02oz/EEaKc3iBimfqLJBxro= 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 jCG6Fv9TyhRw; Tue, 23 Jan 2018 23:16:32 +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, 23 Jan 2018 23:16:31 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 71E649AD; Tue, 23 Jan 2018 17:16:30 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 71E649AD Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 56365402F26A; Tue, 23 Jan 2018 17:16:30 -0500 (EST) Date: Tue, 23 Jan 2018 17:16:30 -0500 (EST) From: Paul Wouters To: Linda Dunbar cc: "ipsec@ietf.org WG" In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66AFFF712@SJCEML521-MBB.china.huawei.com> Message-ID: References: <151663992146.8109.14477590352866908189@ietfa.amsl.com> <4A95BA014132FF49AE685FAB4B9F17F66AFFF712@SJCEML521-MBB.china.huawei.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] I-D Action: 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, 23 Jan 2018 22:16:40 -0000 On Tue, 23 Jan 2018, Linda Dunbar wrote: Hi Linda, > Introduction: >   > Is "Split DNS" less about "configuration for the secure tunnels", but more about having two zones, one to be used by the > internal network, the other used by the external network? > Basically Split DNS directs internal hosts to an internal domain name server for name resolution and external hosts are directed > to an external domain name server for name resolution. >   > Is it correct? If yes, the requests from internal network (the network within VPN) may not be via tunnel, isn't it? That is correct. The initial draft did have that requirement, but Tero pointed out correctly that you might be setting up multiple tunnels, and in fact one might be _to_ the internal DNS server, which could come up on demand. So we left out any restrictions of the DNS request actually going over the initial tunnel. Image you have a configuration for two remote subnets, 10.0.1.0/24 and 10.0.2.0/24. And your nameserver is on 10.0.1.1. But your initial IKE_INIT/IKE_AUTH requests are triggerd by a packer for 10.0.2.1. You would get the DNS information, but the CHILD SA would not be covering that IP. But if you just send a DNS packet to 10.0.1.1, the existing IKE SA would send a CREATE_CHILD_SA to initiate a second IPsec SA for the other range. > Or your "split DNS" is about one DNS with some domain name resolution requests are from IPSec tunnels and others are not? The split-DNS refers to "internal only" DNS zones, that presumably are only accessable over the remote access VPN, for which the VPN client needs to be told about by the server which domains these are and where to find nameservers for them and what DNSSEC key might sign them. Paul From nobody Tue Jan 23 14:56: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 AE3F112D84E for ; Tue, 23 Jan 2018 14:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwBldGa2ANql for ; Tue, 23 Jan 2018 14:56:08 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 A994B12D883 for ; Tue, 23 Jan 2018 14:56:00 -0800 (PST) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id C8055A6AB62E6 for ; Tue, 23 Jan 2018 22:55:56 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 23 Jan 2018 22:55:58 +0000 Received: from SJCEML521-MBB.china.huawei.com ([169.254.6.91]) by SJCEML702-CHM.china.huawei.com ([169.254.4.179]) with mapi id 14.03.0382.000; Tue, 23 Jan 2018 14:55:53 -0800 From: Linda Dunbar To: Paul Wouters CC: "ipsec@ietf.org WG" Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-04.txt Thread-Index: AQHTk6FhoWtb2aaILE+Vk3ufGXlH5KOAwkCAgAE44aCAAJNbAP//g88g Date: Tue, 23 Jan 2018 22:55:52 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66AFFF900@SJCEML521-MBB.china.huawei.com> References: <151663992146.8109.14477590352866908189@ietfa.amsl.com> <4A95BA014132FF49AE685FAB4B9F17F66AFFF712@SJCEML521-MBB.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.98] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [IPsec] I-D Action: 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, 23 Jan 2018 22:56:11 -0000 Paul,=20 Thank you very much for the explanation.=20 I think the confusion comes from people like me who have been extensively w= orking with MPLS VPN, with "internal network" communication not protected, = whereas your draft assumes "internal network" as the one being interconnect= ed by "IPsec" tunnel. Correct?=20 Since the draft is to be read by general public once it becomes RFC, sugges= t you add a note to explain your "internal network".=20 Linda -----Original Message----- From: Paul Wouters [mailto:paul@nohats.ca]=20 Sent: Tuesday, January 23, 2018 4:17 PM To: Linda Dunbar Cc: ipsec@ietf.org WG Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-04.txt On Tue, 23 Jan 2018, Linda Dunbar wrote: Hi Linda, > Introduction: > =A0 > Is "Split DNS" less about "configuration for the secure tunnels", but=20 > more about having two zones, one to be used by the internal network, the = other used by the external network? > Basically Split DNS directs internal hosts to an internal domain name=20 > server for name resolution and external hosts are directed to an external= domain name server for name resolution. > =A0 > Is it correct? If yes, the requests from internal network (the network wi= thin VPN) may not be via tunnel, isn't it? That is correct. The initial draft did have that requirement, but Tero poin= ted out correctly that you might be setting up multiple tunnels, and in fac= t one might be _to_ the internal DNS server, which could come up on demand.= So we left out any restrictions of the DNS request actually going over the= initial tunnel. Image you have a configuration for two remote subnets, 10.= 0.1.0/24 and 10.0.2.0/24. And your nameserver is on 10.0.1.1. But your init= ial IKE_INIT/IKE_AUTH requests are triggerd by a packer for 10.0.2.1. You w= ould get the DNS information, but the CHILD SA would not be covering that I= P. But if you just send a DNS packet to 10.0.1.1, the existing IKE SA would= send a CREATE_CHILD_SA to initiate a second IPsec SA for the other range. > Or your "split DNS" is about one DNS with some domain name resolution req= uests are from IPSec tunnels and others are not? The split-DNS refers to "internal only" DNS zones, that presumably are only= accessable over the remote access VPN, for which the VPN client needs to b= e told about by the server which domains these are and where to find namese= rvers for them and what DNSSEC key might sign them. Paul From nobody Wed Jan 24 07:01: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 62B81126CBF for ; Wed, 24 Jan 2018 07:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpdtcUXhQMCw for ; Wed, 24 Jan 2018 07:00:57 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61F661250B8 for ; Wed, 24 Jan 2018 07:00:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=References:To:Cc:In-Reply-To:Date:Subject: Mime-Version:Content-Type:Message-Id:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=UrBfHWgzVeX4JxTmCZfBkUl5XrOSmBh5xv1QPqeyTtc=; b=eB5T687N0hLncug9zddUylXBi KZqJAxEjkiDEnGvfvKGjHV4TzqzRcvgB0oJ5vQBf4k2NeDy4/Q48L/09rS0Yy1AIX61auyVqvhQ9v 4XAvEnJ5xxk0R1Bjq/mh93ax6McWP4s6AHQDUYr6jKOKN06DkqHlDKlGwHDjmZvlXhVmntV1jRgTU 2VNS4gEMiFI/5zNLe5ETFuMEO9g4dperchruqBrN46UQMlYbcg7FINi5d+9m0ngGLxoa9QlpHLkRn L3CqvTpRNakFNKGHhQOobw1d+FhjJbmVwq1wz8LLSsFWIRfg0xpYHQiw/+idnAECQGNZ6MlWuXdXQ lTsrZR3sA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:50539 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1eeMXQ-0041N7-Vm; Wed, 24 Jan 2018 10:00:36 -0500 From: Joe Touch Message-Id: <5A10F40C-EC3E-4643-BCDD-6A9B24F4DDF6@strayalpha.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_096A80F5-2EA8-4D0B-9DDB-FB76FAA2020A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 24 Jan 2018 06:59:43 -0800 In-Reply-To: <2064C97D-2E9A-4BEE-851B-5F91D0E08413@gmail.com> Cc: Shibu Piriyath , "ipsec@ietf.org" , Yoav Nir To: Dan Wing References: <9D48AC2A-32B8-42EF-B4DF-4825E4D75A32@gmail.com> <2064C97D-2E9A-4BEE-851B-5F91D0E08413@gmail.com> X-Mailer: Apple Mail (2.3273) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [IPsec] Dynamic PMTUD over IKEv2 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, 24 Jan 2018 15:01:01 -0000 --Apple-Mail=_096A80F5-2EA8-4D0B-9DDB-FB76FAA2020A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, all, FYI - there is also a UDP PLPMTUD draft in process that leverages the = new UDP options I=E2=80=99m currently developing, which might be useful = to take a look at as well: draft-fairhurst-tsvwg-datagram-plpmtud Joe > On Jan 23, 2018, at 1:04 PM, Dan Wing wrote: >=20 >=20 >> On Jan 23, 2018, at 9:56 AM, Yoav Nir wrote: >>=20 >>=20 >>> On 23 Jan 2018, at 12:29, Shibu Piriyath = wrote: >>>=20 >>> Hi All, >>>=20 >>> We have come up with a proposal for discovering Path MTU between = IPsec head-ends dynamically using IKEv2 messages. >>> Please review the draft - = https://tools.ietf.org/html/draft-spiriyath-ipsecme-dynamic-ipsec-pmtu-00 = and let us know your comments, >>>=20 >>> Thanks, >>> Shibu. >>=20 >> Hi Shibu. >>=20 >> Thank you for working on this. I have some comments. >>=20 >>=20 >> Administrative/political:=20 >> This document proposes an IPv4-only mechanism. While the IETF has = not (yet?) approved" [1] (see discussion threads [2] and [3]), there = needs to be some justification for why we=E2=80=99re doing an IPv4-only = mechanism. Is this not a problem in IPv6 (Because we assume that PTB = responses propagate correctly in the IPv6 network that in the IPv4 = Internet routers routinely fragment) or is there some other mechanism = for IPv6? >>=20 >>=20 >> Terminology: >> - I usually encounter the terms ingress and egress for interfaces of = a particular router or host. I think it would be clearer to use = =E2=80=9Ctunnel ingress=E2=80=9D and =E2=80=9Ctunnel egress=E2=80=9D or = =E2=80=9Cencryptor=E2=80=9D and =E2=80=9Cdecryptor=E2=80=9D >> - "Overhead is the number of bytes required for tunnel = encapsulation=E2=80=9D. Overhead is then used as a number that is = subtracted from physical MTU. However, the overhead is not constant. = IPsec requires padding to some multiple of 4, 8, or 16 depending on the = algorithm. I suggest modifying the definition of overhead to = =E2=80=9COverhead is the *maximum* number of bytes required for tunnel = encapsulation=E2=80=9D >> - "fragmentation within the tunnel is allowed=E2=80=9D - this is = about fragmenting an ESP packet that is too large. I don=E2=80=99t think = =E2=80=9Cwithin the tunnel=E2=80=9D is the best term for this. How about = =E2=80=9Cfragmentation of the ESP packet by intermediate routers is = allowed=E2=80=9D ? >>=20 >>=20 >>=20 >>=20 >> Technical: >> If the >> packet length is greater than the tunnel MTU and the packet can be >> fragmented, the ingress node fragments the packet, encapsulates = each >> fragment, and forwards each encapsulated fragment through the = tunnel. >>=20 >>=20 >> That=E2=80=99s one way of doing things. Another is to encapsulate the = packet anyway and send the ESP packet out in fragments. This way is also = compatible with IPv6. I know of at least one implementation that does = this. >>=20 >>=20 >> There is an assumption that the egress node knows about the = fragmentation. Usually some layer in the stack will defragment before = handing the IPsec stack a re-assembled IPsec packet to decrypt. Maybe = some implementations are more integrated and the IPsec stack has this = information, but this assumption needs to be stated explicitly. >>=20 >>=20 >> Some routers drop packets that are too big instead of fragmenting = them. Of these, some send back the PTB and some don=E2=80=99t. An active = PMTUD method (ingress sends dummy packets of various sizes and receives = acknowledgements from egress if they arrive) can work with such = intermediate routers. >=20 > Also known as PLPMTUD (packetization layer path MTU discovery), = https://tools.ietf.org/html/rfc4821. Most similar to IKE is this = presentation that describes PLPMTUD with STUN; IKE could do similar = thing, https://www.ietf.org/proceedings/73/slides/behave-10.pdf. There = is an RFC describing PLPMTUD for TCP, but I don't cite it because TCP. >=20 > The I-D should also encourage re-setting the path MTU following the = same plateau algorithm described in RFC1191, or explain why that = algorithm is bad and instead the algorithm described in the I-D is = superior (the I-D describes discarding the learned MTU and re-learning, = from scratch). >=20 > -d >=20 >> This method cannot. >>=20 >>=20 >> How do you prevent the following attack? The attacker manages to drop = or delay one ESP packet. It captures this packet and retransmits it in = small fragments. This induces the egress to send the notification from = section 3.2 to the ingress, causing it to internally fragment all future = packets. >>=20 >> Yoav >>=20 >> [1] https://tools.ietf.org/html/draft-ietf-sunset4-ipv6-ietf-01 >> [2] https://www.ietf.org/mail-archive/web/ietf/current/msg104661.html >> [3] https://www.ietf.org/mail-archive/web/ietf/current/msg104721.html >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_096A80F5-2EA8-4D0B-9DDB-FB76FAA2020A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, all,

FYI - there is also a UDP PLPMTUD draft in process that = leverages the new UDP options I=E2=80=99m currently developing, which = might be useful to take a look at as well:
draft-fairhurst-tsvwg-datagram-plpmtud

Joe


On = Jan 23, 2018, at 1:04 PM, Dan Wing <danwing@gmail.com> = wrote:


On Jan = 23, 2018, at 9:56 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:


On 23 Jan = 2018, at 12:29, Shibu Piriyath <spiriyath@juniper.net> wrote:

Hi All,

We have come up with a = proposal for discovering Path MTU between IPsec head-ends dynamically = using IKEv2 messages.
Please review the draft - https://tools.ietf.org/html/draft-spiriyath-ipsecme-dynamic-ips= ec-pmtu-00 and let us know your comments,

Thanks,
Shibu.

Hi Shibu.

Thank you for working = on this.  I have some comments.


Administrative/political:
This document = proposes an IPv4-only mechanism.  While the IETF has not (yet?) = approved" [1] (see discussion threads [2] and [3]), there needs to be = some justification for why we=E2=80=99re doing an IPv4-only mechanism. =  Is this not a problem in IPv6 (Because we assume that PTB = responses propagate correctly in the IPv6 network that in the IPv4 = Internet routers routinely fragment) or is there some other mechanism = for IPv6?


Terminology:
- I usually encounter the terms ingress and egress for = interfaces of a particular router or host. I think it would be clearer = to use =E2=80=9Ctunnel ingress=E2=80=9D and =E2=80=9Ctunnel egress=E2=80=9D= or =E2=80=9Cencryptor=E2=80=9D and =E2=80=9Cdecryptor=E2=80=9D
- "Overhead is the number of bytes required for tunnel = encapsulation=E2=80=9D. Overhead is then used as a number that is = subtracted from physical MTU.  However, the overhead is not = constant. IPsec requires padding to some multiple of 4, 8, or 16 = depending on the algorithm.  I suggest modifying the definition of = overhead to =E2=80=9COverhead is the *maximum* number of bytes required = for tunnel encapsulation=E2=80=9D
- "fragmentation within = the tunnel is allowed=E2=80=9D - this is about fragmenting an ESP packet = that is too large. I don=E2=80=99t think =E2=80=9Cwithin the tunnel=E2=80=9D= is the best term for this. How about =E2=80=9Cfragmentation of the ESP = packet by intermediate routers is allowed=E2=80=9D ?




Technical:
=             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p; If the
  packet length is greater than = the tunnel MTU and the packet can be
=   fragmented, the ingress node fragments the packet, = encapsulates each
  fragment, and forwards each = encapsulated fragment through the tunnel.

That=E2=80=99s one way of doing things. Another is to = encapsulate the packet anyway and send the ESP packet out in fragments. = This way is also compatible with IPv6.  I know of at least one = implementation that does this.


There is an assumption that the egress node knows about the = fragmentation. Usually some layer in the stack will defragment before = handing the IPsec stack a re-assembled IPsec packet to decrypt. =  Maybe some implementations are more integrated and the IPsec stack = has this information, but this assumption needs to be stated = explicitly.


Some routers = drop packets that are too big instead of fragmenting them. Of these, = some send back the PTB and some don=E2=80=99t. An active PMTUD method = (ingress sends dummy packets of various sizes and receives = acknowledgements from egress if they arrive) can work with such = intermediate routers.

Also = known as PLPMTUD (packetization layer path MTU discovery), https://tools.ietf.org/html/rfc4821.  Most similar = to IKE is this presentation that describes PLPMTUD with STUN; IKE could = do similar thing, https://www.ietf.org/proceedings/73/slides/behave-10.pdf. =  There is an RFC describing PLPMTUD for TCP, but I don't cite it = because TCP.

The I-D should also encourage = re-setting the path MTU following the same plateau algorithm described = in RFC1191, or explain why that algorithm is bad and instead the = algorithm described in the I-D is superior (the I-D describes discarding = the learned MTU and re-learning, from scratch).

-d

This method cannot.


How do you prevent the following attack? The attacker manages = to drop or delay one ESP packet. It captures this packet and retransmits = it in small fragments. This induces the egress to send the notification = from section 3.2 to the ingress, causing it to internally fragment all = future packets.

Yoav

[1] https://tools.ietf.org/html/draft-ietf-sunset4-ipv6-ietf-01=
[2] https://www.ietf.org/mail-archive/web/ietf/current/msg104661.ht= ml
[3] https://www.ietf.org/mail-archive/web/ietf/current/msg104721.ht= ml

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

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

= --Apple-Mail=_096A80F5-2EA8-4D0B-9DDB-FB76FAA2020A-- From nobody Thu Jan 25 06:42:25 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 B9880124207 for ; Thu, 25 Jan 2018 06:42:22 -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 28Edi0BunuL8 for ; Thu, 25 Jan 2018 06:42:20 -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 E773A1241FC for ; Thu, 25 Jan 2018 06:42:19 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zS4WD2lJpzCr5; Thu, 25 Jan 2018 15:42:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1516891336; bh=RkZmqbxSjcEMLZuO/c5P5fJaDRsk8B1toa0H+77r5Pk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=IFMVGZJDvnEyTAqqyM4RW+UCJTRNmPzG1erRd2kBcPC7m82Lz/PTHuqqqeW5lZTW6 09EDr8bvDFS55ViWX98Geo3DFuquoJPYhqjcDma0QRiwKO/z5CSx2y8V3Xp8Ru8WhC 90OFPyGQc8c+MP26J+PWjUzOXiw+tjsw1Kj0uB0E= 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 yQ0HY9vu4DQi; Thu, 25 Jan 2018 15:42:13 +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; Thu, 25 Jan 2018 15:42:13 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1B81F61CD5; Thu, 25 Jan 2018 09:42:12 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 1B81F61CD5 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1401F41971FD; Thu, 25 Jan 2018 09:42:12 -0500 (EST) Date: Thu, 25 Jan 2018 09:42:12 -0500 (EST) From: Paul Wouters To: Linda Dunbar cc: "ipsec@ietf.org WG" In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66AFFF900@SJCEML521-MBB.china.huawei.com> Message-ID: References: <151663992146.8109.14477590352866908189@ietfa.amsl.com> <4A95BA014132FF49AE685FAB4B9F17F66AFFF712@SJCEML521-MBB.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F66AFFF900@SJCEML521-MBB.china.huawei.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] I-D Action: 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: Thu, 25 Jan 2018 14:42:23 -0000 On Tue, 23 Jan 2018, Linda Dunbar wrote: > Thank you very much for the explanation. > > I think the confusion comes from people like me who have been extensively working with MPLS VPN, with "internal network" communication not protected, whereas your draft assumes "internal network" as the one being interconnected by "IPsec" tunnel. Correct? > > Since the draft is to be read by general public once it becomes RFC, suggest you add a note to explain your "internal network". I will talk to Tommy and see about if we should clarify this some more in the introduction of the document. Thanks, Paul > Linda > > -----Original Message----- > From: Paul Wouters [mailto:paul@nohats.ca] > Sent: Tuesday, January 23, 2018 4:17 PM > To: Linda Dunbar > Cc: ipsec@ietf.org WG > Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-04.txt > > On Tue, 23 Jan 2018, Linda Dunbar wrote: > > Hi Linda, > >> Introduction: >>   >> Is "Split DNS" less about "configuration for the secure tunnels", but >> more about having two zones, one to be used by the internal network, the other used by the external network? >> Basically Split DNS directs internal hosts to an internal domain name >> server for name resolution and external hosts are directed to an external domain name server for name resolution. >>   >> Is it correct? If yes, the requests from internal network (the network within VPN) may not be via tunnel, isn't it? > > That is correct. The initial draft did have that requirement, but Tero pointed out correctly that you might be setting up multiple tunnels, and in fact one might be _to_ the internal DNS server, which could come up on demand. So we left out any restrictions of the DNS request actually going over the initial tunnel. Image you have a configuration for two remote subnets, 10.0.1.0/24 and 10.0.2.0/24. And your nameserver is on 10.0.1.1. But your initial IKE_INIT/IKE_AUTH requests are triggerd by a packer for 10.0.2.1. You would get the DNS information, but the CHILD SA would not be covering that IP. But if you just send a DNS packet to 10.0.1.1, the existing IKE SA would send a CREATE_CHILD_SA to initiate a second IPsec SA for the other range. > >> Or your "split DNS" is about one DNS with some domain name resolution requests are from IPSec tunnels and others are not? > > The split-DNS refers to "internal only" DNS zones, that presumably are only accessable over the remote access VPN, for which the VPN client needs to be told about by the server which domains these are and where to find nameservers for them and what DNSSEC key might sign them. > > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Mon Jan 29 12:48:58 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 5D3681300F0; Mon, 29 Jan 2018 12:48:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, ekr@rtfm.com, kivinen@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151725893535.19478.6222719594139725725.idtracker@ietfa.amsl.com> Date: Mon, 29 Jan 2018 12:48:55 -0800 Archived-At: Subject: [IPsec] ipsecme - New Meeting Session Request 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: Mon, 29 Jan 2018 20:48:55 -0000 A new meeting session request has just been submitted by Tero Kivinen, a Chair of the ipsecme working group. --------------------------------------------------------- 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 Tue Jan 30 13:51: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 D60CD130140 for ; Tue, 30 Jan 2018 13:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXWJW5Hff436 for ; Tue, 30 Jan 2018 13:51:02 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918AE12FEE2 for ; Tue, 30 Jan 2018 13:51:02 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id EE475B80DE5; Tue, 30 Jan 2018 13:50:39 -0800 (PST) To: charliekaufman@outlook.com, paul.hoffman@vpnc.org, nir.ietf@gmail.com, pe@iki.fi, kivinen@iki.fi, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, david.waltermire@nist.gov, kivinen@iki.fi X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: andrew.cagney@gmail.com, ipsec@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180130215039.EE475B80DE5@rfc-editor.org> Date: Tue, 30 Jan 2018 13:50:39 -0800 (PST) Archived-At: Subject: [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: Tue, 30 Jan 2018 21:51:05 -0000 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 can log in to change the status and edit the report, if necessary. -------------------------------------- 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 From nobody Tue Jan 30 21: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 A2096131676 for ; Tue, 30 Jan 2018 21:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpObea7w2mzF for ; Tue, 30 Jan 2018 21:04:16 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEC6A13156C for ; Tue, 30 Jan 2018 21:04:15 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id g1so5441383wmg.2 for ; Tue, 30 Jan 2018 21:04:15 -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=SUccBZZ1bWbwweFpLsnR+tuYToKJuEnzCeRL1CWv6ms=; b=pHjSC4hxSVIqIlKb7viZaDFdyF4uksg+jyKcj6TGcHkzNdOk6vCE7agGmwfzjwivd5 35bprYkh3a8n3ZrvRwNVJsBoY1svuq6VTVB2oBXsO5Jzet5HZIb/L9CRlRp3dgTuApvD QwcfyT2QYnDy8+pyj06o9zZl9ziRTwiuBD6j7Wa2OmlwO22uCfsPUAZPI0/nzvorpYMY DiAsc3UBLk12cuvLpdOVFsBgLoGLiWSYyLCOMpvYryw6RgCZcFRftpqxtVSBnZWXsbYN mJc26ri3iW5lLV5c7+SJ+l07TOn9R0bVjLcZdeDnSZ+JICWBydckoqSw9YBDOtMXwzpG JSHA== 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=SUccBZZ1bWbwweFpLsnR+tuYToKJuEnzCeRL1CWv6ms=; b=mu1QgHKP1wNQNrF0Ajb/ng2tTxbGe0F+goX7LWz9oufvfdUnq2lT/ctT00hD43qF8A wJXYG54xs6cLyOzqnA2HihYYlch03k1HnwnIdWNPR/b7jMwMEAAfkZDqdeB3sB3NMn0k hv5GZ4yXlLUySqOw9h5/ljLKilq3+aMSaGQMT7BadIvNwG1MbDGHP68ACwRJsBr+4NVe XdpUfBNwwxEpQiVCw6T7y7gNdca/GhlXx+TAznF4zU6msLzYZ/BdJ2hjX0T1MpYscACW 7pa2x7Q643t+syPV9rnyevS10wX93kY65OPwQHQWuZs3dRVsoquyNNAOLEi1O+be23ld lm5A== X-Gm-Message-State: AKwxyteSfZc9WSKVMXUGfddwqjAXGi+8VOiQT58glssDlstf4d+zLMWQ hGLg6vGbKBmX2ni3n5fDCmE= X-Google-Smtp-Source: AH8x226w2WDRgBbFaXQaYo33O7ZWck0Ingdwd1dzyPBIFsMlHM/+okgSG6zrecfQ7qDMan3PEPNYnw== X-Received: by 10.28.112.21 with SMTP id l21mr24722263wmc.70.1517375054424; Tue, 30 Jan 2018 21:04:14 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id d73sm16575431wma.16.2018.01.30.21.04.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jan 2018 21:04:13 -0800 (PST) From: Yoav Nir Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6AE9C4C8-79F9-4A7E-9B99-7C3B68E8EB3F" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 31 Jan 2018 07:04:10 +0200 In-Reply-To: <20180130215039.EE475B80DE5@rfc-editor.org> Cc: charliekaufman@outlook.com, Paul Hoffman , nir.ietf@gmail.com, pe@iki.fi, kivinen@iki.fi, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, david.waltermire@nist.gov, ipsec@ietf.org, andrew.cagney@gmail.com To: RFC Errata System References: <20180130215039.EE475B80DE5@rfc-editor.org> X-Mailer: Apple Mail (2.3445.5.20) 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: Wed, 31 Jan 2018 05:04:19 -0000 --Apple-Mail=_6AE9C4C8-79F9-4A7E-9B99-7C3B68E8EB3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 = 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 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. >=20 > 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. >=20 > Notes > ----- > If I assume that the 'Protocol ID' field in the notification payload = 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 'Protocol = ID' don't need > updating as they all explicitly list allowed values, and in no case is = 0 allowed. >=20 > 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 >=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 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_6AE9C4C8-79F9-4A7E-9B99-7C3B68E8EB3F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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> 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.org/errata/eid5247

--------------------------------------
Type: = 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 =             &n= bsp; : 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 =             &n= bsp;: IP Security Maintenance and Extensions
Area =             &n= bsp;  : Security
Stream =             &n= bsp;: IETF
Verifying Party     : = IESG

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

= --Apple-Mail=_6AE9C4C8-79F9-4A7E-9B99-7C3B68E8EB3F-- From nobody Tue Jan 30 21:07: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 CF551131546 for ; Tue, 30 Jan 2018 21:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P67M2Nc1EbTh for ; Tue, 30 Jan 2018 21:07:29 -0800 (PST) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 94330131543 for ; Tue, 30 Jan 2018 21:07:28 -0800 (PST) Received: by mail-wr0-x231.google.com with SMTP id i56so13572677wra.7 for ; Tue, 30 Jan 2018 21:07:28 -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=ICLsPRPHL1leLDjnTeHrsiGDerA/duOTOLzErMx8Pog=; b=NVbbJNoJw2o4+YxWuJeEVZE5CoL1Yix/Tb7e8kkF/ZNFOLFpY+KQqVJu6pWHPuvNKi Idq9KHBPtMCBFJeb0nlhC2Mc6FmjrJ08100EO6s74fOLV5Nj//OH7YCSiKornne2yHtp Ris4OynBWzsY3a9AGsP13bUmK/B3bHoNuIiXv2USHulU5OUlQSzepRNT75UldHGWfSbT HZ0+gzsQBOsaGxzSqhVIrIcqXq/umnxDoDuOhgqwx58HnW0KODY3lEUTPPvyKrLy3KeP g1fX2c3sCtDA3llGwPpZK6KqMb+WfyvMBe6k3EIqqQynB7gV4dUrqSdbQokJ6+setBot TrsA== 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=ICLsPRPHL1leLDjnTeHrsiGDerA/duOTOLzErMx8Pog=; b=izfqPrltC9qksPnkCdjdW0MjIbAAv/0OPj3keBXI+4L6rf7iDxTGBLt1BsyH7UJyH2 KOKFMJfA8aGMEfBiPAnlnu1F48+l0vaKlSq1V4Dw5dYspwb/RMfEorT/b0Fl7hyb4eRH dqDv0r8dA91PHtbPuLuprK9AKnC+zLE45qbHtZ5PjdCoFIGsv7PCNm+PMfeR64pz9EI6 0FiIJcNdJGWRLHUhmxK6fjsoaszuwa1L4yjmcMEfvkDPSrRuj5XroiSjT8QZYzBpSXC3 Vl1HDpfQVvmYjY4Hu8LBDJ7ncAYFjFbet6JnUQRdXxFehXeBHsflAuZ0n17X902YxJgR 9R1g== X-Gm-Message-State: AKwxyteHyynFKF1SzBsmjaF9BDzmoiM9VvP3to/PmLArxiwI6O8VY9cx EcLdhUH5VBvasnqSfTgiBfw= X-Google-Smtp-Source: AH8x225vSqObSi4ul2LlQX61uiCSbgxqO4miU6oMUmXhSWku+jPYkVqmk+DAUgk/r80BHYo2H+49Fg== X-Received: by 10.223.160.51 with SMTP id k48mr3439704wrk.116.1517375247213; Tue, 30 Jan 2018 21:07:27 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id l9sm5830313wrl.1.2018.01.30.21.07.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jan 2018 21:07:26 -0800 (PST) From: Yoav Nir Message-Id: <3380F947-18B4-4DDA-B218-B60E7E2DA460@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0DA6838D-4873-4E82-95CF-1F609A0E462E" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 31 Jan 2018 07:07:23 +0200 In-Reply-To: Cc: charliekaufman , Paul Hoffman , pe , Kathleen.Moriarty.ietf@gmail.com, IPsecME WG To: andrew.cagney@gmail.com, David Waltermire , Tero Kivinen , Eric Rescorla References: <20180130215039.EE475B80DE5@rfc-editor.org> X-Mailer: Apple Mail (2.3445.5.20) 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: Wed, 31 Jan 2018 05:07:32 -0000 --Apple-Mail=_0DA6838D-4873-4E82-95CF-1F609A0E462E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sorry. Resending with the correct To: and CC: lists > On 31 Jan 2018, at 7:04, Yoav Nir 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? >=20 >> 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 = 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. >>=20 >> 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. >>=20 >> Notes >> ----- >> If I assume that the 'Protocol ID' field in the notification payload = 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 = 'Protocol ID' don't need >> updating as they all explicitly list allowed values, and in no case = is 0 allowed. >>=20 >> 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 >>=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 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 --Apple-Mail=_0DA6838D-4873-4E82-95CF-1F609A0E462E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Sorry. Resending with the correct To: and CC: lists

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> 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.org/errata/eid5247

--------------------------------------
Type: = 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 =             &n= bsp; : 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 =             &n= bsp;: IP Security Maintenance and Extensions
Area =             &n= bsp;  : Security
Stream =             &n= bsp;: IETF
Verifying Party     : = IESG

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


= --Apple-Mail=_0DA6838D-4873-4E82-95CF-1F609A0E462E--