From ynir@checkpoint.com Wed Sep 4 13:09:12 2013 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 AD3D521E8163 for ; Wed, 4 Sep 2013 13:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.63 X-Spam-Level: X-Spam-Status: No, score=-10.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVgkar+-Fcj2 for ; Wed, 4 Sep 2013 13:09:07 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5C89A21E8171 for ; Wed, 4 Sep 2013 13:09:06 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r84K8csX002002; Wed, 4 Sep 2013 23:08:38 +0300 X-CheckPoint: {52279346-12-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Wed, 4 Sep 2013 23:08:38 +0300 From: Yoav Nir To: RFC Errata System Thread-Topic: [Technical Errata Reported] RFC5996 (3718) Thread-Index: AQHOqZypxjqvX/gK7kK47z+6L3jcV5m1z5WA Date: Wed, 4 Sep 2013 20:08:38 +0000 Message-ID: <384EEED2-6652-42BE-9BBE-1723127A7953@checkpoint.com> References: <20130904182317.4646A8E016@rfc-editor.org> In-Reply-To: <20130904182317.4646A8E016@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.182] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: <1BCB69E77FBA064D957FA5DF501CC424@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "" , "" , "" , "" , "" Subject: Re: [IPsec] [Technical Errata Reported] RFC5996 (3718) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 20:09:12 -0000 Hi I believe this report should be rejected. The address returned in the INTER= NAL_IP6_ADDRESS attribute is not a /64 subnet, it is just one address. The = fact that it belongs to a /64 subnet is besides the point, and in fact the = TSi payload in both the original and corrected versions contains but one ad= dress. There is no requirement that TSi and TSr have the same subnet size, and in = fact the selectors shown in the example are rather common for remote access= . The client has but one address, while the gateway might as well protect t= he Internet. This kind of universal tunnel is very convenient, and even mor= e so when the client does not have prior knowledge of the protected domain = behind the gateway. Yoav =20 On Sep 4, 2013, at 9:23 PM, RFC Errata System w= rote: > The following errata report has been submitted for RFC5996, > "Internet Key Exchange Protocol Version 2 (IKEv2)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5996&eid=3D3718 >=20 > -------------------------------------- > Type: Technical > Reported by: Gerald Smith >=20 > Section: 3.15.3 >=20 > Original Text > ------------- > A client can be assigned an IPv6 address using the > INTERNAL_IP6_ADDRESS Configuration payload. A minimal exchange might > look like this: >=20 > CP(CFG_REQUEST) =3D > INTERNAL_IP6_ADDRESS() > INTERNAL_IP6_DNS() > TSi =3D (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) > TSr =3D (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) >=20 > CP(CFG_REPLY) =3D > INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) > INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) > TSi =3D (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) > TSr =3D (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) >=20 > Corrected Text > -------------- > CP(CFG_REPLY) =3D > INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) > INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) > TSi =3D (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) > TSr =3D (0, 0-65535, 2001:DB8:0:1:: - 2001:DB8:0:1:FFFF:FFFF:FFFF:FFFF) >=20 > Notes > ----- > The INTERNAL_IP6_ADDRESS returned in the CFG_REPLY is a 64 bit subnet, bu= t the TSr returned in the CFG_REPLY shows a 0 bit subnet instead of the 64 = bit subnet. >=20 > Instructions: > ------------- > This errata 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 (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5996 (draft-ietf-ipsecme-ikev2bis-11) > -------------------------------------- > Title : Internet Key Exchange Protocol Version 2 (IKEv2) > Publication Date : September 2010 > Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen > Category : PROPOSED STANDARD > Source : IP Security Maintenance and Extensions > Area : Security > Stream : IETF > Verifying Party : IESG >=20 > Email secured by Check Point From wwwrun@rfc-editor.org Wed Sep 4 11:28:55 2013 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 8EF6121E8054 for ; Wed, 4 Sep 2013 11:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kf1bhwCD-s8S for ; Wed, 4 Sep 2013 11:28:55 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1F06621F9AF8 for ; Wed, 4 Sep 2013 11:28:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4646A8E016; Wed, 4 Sep 2013 11:23:17 -0700 (PDT) To: charliek@microsoft.com, paul.hoffman@vpnc.org, ynir@checkpoint.com, pe@iki.fi, stephen.farrell@cs.tcd.ie, turners@ieca.com, paul.hoffman@vpnc.org, yaronf.ietf@gmail.com From: RFC Errata System Message-Id: <20130904182317.4646A8E016@rfc-editor.org> Date: Wed, 4 Sep 2013 11:23:17 -0700 (PDT) X-Mailman-Approved-At: Wed, 04 Sep 2013 13:59:59 -0700 Cc: ipsec@ietf.org, gsmith@sta.samsung.com, rfc-editor@rfc-editor.org Subject: [IPsec] [Technical Errata Reported] RFC5996 (3718) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 18:28:55 -0000 The following errata report has been submitted for RFC5996, "Internet Key Exchange Protocol Version 2 (IKEv2)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5996&eid=3718 -------------------------------------- Type: Technical Reported by: Gerald Smith Section: 3.15.3 Original Text ------------- A client can be assigned an IPv6 address using the INTERNAL_IP6_ADDRESS Configuration payload. A minimal exchange might look like this: CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS() INTERNAL_IP6_DNS() TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) CP(CFG_REPLY) = INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) Corrected Text -------------- CP(CFG_REPLY) = INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) TSr = (0, 0-65535, 2001:DB8:0:1:: - 2001:DB8:0:1:FFFF:FFFF:FFFF:FFFF) Notes ----- The INTERNAL_IP6_ADDRESS returned in the CFG_REPLY is a 64 bit subnet, but the TSr returned in the CFG_REPLY shows a 0 bit subnet instead of the 64 bit subnet. Instructions: ------------- This errata 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 (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5996 (draft-ietf-ipsecme-ikev2bis-11) -------------------------------------- Title : Internet Key Exchange Protocol Version 2 (IKEv2) Publication Date : September 2010 Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen Category : PROPOSED STANDARD Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Wed Sep 4 16:25:34 2013 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 8F93911E81FB; Wed, 4 Sep 2013 16:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.262 X-Spam-Level: X-Spam-Status: No, score=-102.262 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJCJlFIVMMFX; Wed, 4 Sep 2013 16:25:34 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 07C5A11E820B; Wed, 4 Sep 2013 16:25:22 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 060E08E01F; Wed, 4 Sep 2013 16:19:42 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130904231942.060E08E01F@rfc-editor.org> Date: Wed, 4 Sep 2013 16:19:42 -0700 (PDT) Cc: ipsec@ietf.org, drafts-update-ref@iana.org, rfc-editor@rfc-editor.org Subject: [IPsec] RFC 7018 on Auto-Discovery VPN Problem Statement and Requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 23:25:34 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7018 Title: Auto-Discovery VPN Problem Statement and Requirements Author: V. Manral, S. Hanna Status: Informational Stream: IETF Date: September 2013 Mailbox: vishwas.manral@hp.com, shanna@juniper.net Pages: 12 Characters: 27284 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsecme-ad-vpn-problem-09.txt URL: http://www.rfc-editor.org/rfc/rfc7018.txt This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements for such a solution. Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases, the IP addresses of endpoints change, or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto-Discovery VPN solution will address these requirements. This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From sdjugum@yahoo.com Thu Sep 5 12:57:42 2013 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 DA2D211E8258 for ; Thu, 5 Sep 2013 12:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.678 X-Spam-Level: *** X-Spam-Status: No, score=3.678 tagged_above=-999 required=5 tests=[AWL=3.980, BAYES_00=-2.599, FORGED_YAHOO_RCVD=2.297] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqC-r6uXV45T for ; Thu, 5 Sep 2013 12:57:38 -0700 (PDT) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1153E11E81BB for ; Thu, 5 Sep 2013 12:57:34 -0700 (PDT) Received: from tom.nabble.com ([192.168.236.105]) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VHfgL-00022K-QK for ipsec@ietf.org; Thu, 05 Sep 2013 12:57:33 -0700 Date: Thu, 5 Sep 2013 12:57:33 -0700 (PDT) From: sdjugum To: ipsec@ietf.org Message-ID: <1378411053766-383394.post@n7.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 06 Sep 2013 08:44:29 -0700 Subject: [IPsec] Discover IP network type using Configuration Payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 19:57:43 -0000 Hi, I have a question regarding usage of both IPv4 and IPv6 address in CFG_REQUEST payload in IKEv2 message. Could there be any (interoperability) problems with IRAS in general if both types are present, like no support for both stacks or addresses not available for one type? Could IRAC use that mechanism to detect the type of network and select one address/network it prefers if IRAS returns both in reply? Also, would IRAS return traffic selectors of both type? Thanks a lot in advance. Br, Sasa -- View this message in context: http://ietf.10.n7.nabble.com/Discover-IP-network-type-using-Configuration-Payload-tp383394.html Sent from the IETF - Ipsec mailing list archive at Nabble.com. From ynir@checkpoint.com Fri Sep 6 11:02:15 2013 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 AAE8211E81A7 for ; Fri, 6 Sep 2013 11:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.602 X-Spam-Level: X-Spam-Status: No, score=-10.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YV9G-GjnCgou for ; Fri, 6 Sep 2013 11:02:09 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7756811E817F for ; Fri, 6 Sep 2013 11:02:09 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r86I273Q011251; Fri, 6 Sep 2013 21:02:07 +0300 X-CheckPoint: {522A189F-5-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Fri, 6 Sep 2013 21:02:07 +0300 From: Yoav Nir To: sdjugum Thread-Topic: [IPsec] Discover IP network type using Configuration Payload Thread-Index: AQHOqxgCT1b5xTC4lESGpbmP3oYswZm4ze6A Date: Fri, 6 Sep 2013 18:02:07 +0000 Message-ID: <504274E9-1B27-4E4A-B9E8-93AD47E49634@checkpoint.com> References: <1378411053766-383394.post@n7.nabble.com> In-Reply-To: <1378411053766-383394.post@n7.nabble.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.239] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: <5CB950113E4C6B4E8E91BDE9AA18656C@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [IPsec] Discover IP network type using Configuration Payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 18:02:15 -0000 Why not both? Regular network interfaces in most operating systems are dual-atack: they c= an have an IPv4 address and several IPv6 addresses. So it makes sense for t= he client to ask for both, and for the IRAS to offer both, if it runs both = IPv4 and IPv6 traffic. If for example IPv6 is missing from the reply, this = could mean that the IRAS does not support IPv6, or it could mean that it is= n't bothering with assigning IPv6 addresses. Similarly, if the client doesn= 't ask for an IPv6 address, it could mean that it does not support IPv6, or= it could mean that it doesn't need configuration from the IRAS.=20 Anyway, IKEv2 clients are required to understand IPv6 selectors. They might= not use them if they don't support IPv6 traffic, but the IRAS should send = TS payloads according to the specification regardless of whether the IRAC r= equested an IPv6 address. Yoav On Sep 5, 2013, at 10:57 PM, sdjugum wrote: > Hi, >=20 > I have a question regarding usage of both IPv4 and IPv6 address in > CFG_REQUEST payload in IKEv2 message. Could there be any (interoperabilit= y) > problems with IRAS in general if both types are present, like no support = for > both stacks or addresses not available for one type? Could IRAC use that > mechanism to detect the type of network and select one address/network it > prefers if IRAS returns both in reply? > Also, would IRAS return traffic selectors of both type? >=20 > Thanks a lot in advance.=20 >=20 > Br, > Sasa From internet-drafts@ietf.org Fri Sep 6 14:50:35 2013 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 B3B7311E8117; Fri, 6 Sep 2013 14:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3q-z-pofq2nG; Fri, 6 Sep 2013 14:50:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8139F11E8106; Fri, 6 Sep 2013 14:50:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130906215033.26420.38094.idtracker@ietfa.amsl.com> Date: Fri, 06 Sep 2013 14:50:33 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 21:50:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. Title : Cryptographic Algorithm Implementation Requirements and = Usage Guidance for Encapsulating Security Payload (ESP) and Authentication = Header (AH) Author(s) : David McGrew Wajdi Feghali Paul Hoffman Filename : draft-ietf-ipsecme-esp-ah-reqts-01.txt Pages : 11 Date : 2013-09-06 Abstract: This Internet Draft is standards track proposal to update to the Cryptographic Algorithm Implementation Requirements for ESP and AH; it also adds usage guidance to help in the selection of these algorithms. The Encapsulating Security Payload (ESP) and Authentication Header (AH) protocols makes use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-esp-ah-reqts-01 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 praveenys@juniper.net Sun Sep 8 18:15:57 2013 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 DDBD021E8123 for ; Sun, 8 Sep 2013 18:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnPv2AqF-Zgw for ; Sun, 8 Sep 2013 18:15:52 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0251.outbound.messaging.microsoft.com [213.199.154.251]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA7F21E8086 for ; Sun, 8 Sep 2013 18:15:51 -0700 (PDT) Received: from mail125-db9-R.bigfish.com (10.174.16.249) by DB9EHSOBE012.bigfish.com (10.174.14.75) with Microsoft SMTP Server id 14.1.225.22; Mon, 9 Sep 2013 01:15:50 +0000 Received: from mail125-db9 (localhost [127.0.0.1]) by mail125-db9-R.bigfish.com (Postfix) with ESMTP id A36C83A0138; Mon, 9 Sep 2013 01:15:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zzbb2dI98dI9371I936eI1432I4015Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275dhz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail125-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=praveenys@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(479174003)(377424004)(164054003)(24454002)(51704005)(199002)(189002)(81686001)(81816001)(81342001)(65816001)(69226001)(66066001)(63696002)(80022001)(46102001)(51856001)(79102001)(4396001)(76796001)(76786001)(81542001)(47736001)(49866001)(47976001)(50986001)(36756003)(76176001)(83506001)(74366001)(74662001)(74706001)(31966008)(47446002)(74502001)(80976001)(561944002)(74876001)(76482001)(53806001)(83072001)(54356001)(77096001)(56816003)(54316002)(56776001)(83322001)(19580405001)(77982001)(19580395003)(59766001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB057; H:BN1PR05MB153.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail125-db9 (localhost.localdomain [127.0.0.1]) by mail125-db9 (MessageSwitch) id 1378689348918083_32718; Mon, 9 Sep 2013 01:15:48 +0000 (UTC) Received: from DB9EHSMHS018.bigfish.com (unknown [10.174.16.238]) by mail125-db9.bigfish.com (Postfix) with ESMTP id D138B40259; Mon, 9 Sep 2013 01:15:48 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS018.bigfish.com (10.174.14.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 9 Sep 2013 01:15:48 +0000 Received: from BN1PR05MB057.namprd05.prod.outlook.com (10.255.202.139) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.353.4; Mon, 9 Sep 2013 01:15:47 +0000 Received: from BN1PR05MB153.namprd05.prod.outlook.com (10.255.205.18) by BN1PR05MB057.namprd05.prod.outlook.com (10.255.202.139) with Microsoft SMTP Server (TLS) id 15.0.745.25; Mon, 9 Sep 2013 01:15:45 +0000 Received: from BN1PR05MB153.namprd05.prod.outlook.com ([169.254.12.231]) by BN1PR05MB153.namprd05.prod.outlook.com ([169.254.12.179]) with mapi id 15.00.0745.000; Mon, 9 Sep 2013 01:15:45 +0000 From: Praveen Sathyanarayan To: "ipsec@ietf.org" Thread-Topic: New Version Notification for draft-sathyanarayan-ipsecme-advpn-02.txt Thread-Index: AQHOrPi+5laziSvlZkmtLvWs3dfGtZm8JOcA Date: Mon, 9 Sep 2013 01:15:43 +0000 Message-ID: In-Reply-To: <20130909010542.29531.83122.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [66.129.224.36] x-forefront-prvs: 09645BAC66 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Daniel Migault , Konstantinos Pentikousis , Stephen Hanna , Yoav Nir , Suresh Melam Subject: [IPsec] FW: New Version Notification for draft-sathyanarayan-ipsecme-advpn-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 01:15:58 -0000 We have submitted -02 draft for our ADVPN proposal. Following are main changes that we have made in this version - Addressed initial/updated configuration requirement for spokes/endpoints, with trusted suggester capability - Fixed typos and other minor editorial changes Thanks, Praveen On 9/8/13 6:05 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-sathyanarayan-ipsecme-advpn-02.txt >has been successfully submitted by Praveen Sathyanarayan and posted to the >IETF repository. > >Filename: draft-sathyanarayan-ipsecme-advpn >Revision: 02 >Title: Auto Discovery VPN Protocol >Creation date: 2013-09-08 >Group: Individual Submission >Number of pages: 44 >URL: =20 >http://www.ietf.org/internet-drafts/draft-sathyanarayan-ipsecme-advpn-02.t >xt >Status: =20 >http://datatracker.ietf.org/doc/draft-sathyanarayan-ipsecme-advpn >Htmlized: =20 >http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-02 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-sathyanarayan-ipsecme-advpn-02 > >Abstract: > This document defines a protocol for dynamically establishing and >tearing > down IPsec tunnels as needed without requiring non-scalable >configuration. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > > > From internet-drafts@ietf.org Mon Sep 9 05:59:00 2013 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 08BCC21E81BF; Mon, 9 Sep 2013 05:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJK8qIlDSCb2; Mon, 9 Sep 2013 05:58:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 798E921E819D; Mon, 9 Sep 2013 05:56:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130909125609.10604.50605.idtracker@ietfa.amsl.com> Date: Mon, 09 Sep 2013 05:56:09 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 12:59:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. Title : IKEv2 Fragmentation Author(s) : Valery Smyslov Filename : draft-ietf-ipsecme-ikev2-fragmentation-02.txt Pages : 20 Date : 2013-09-09 Abstract: This document describes the way to avoid IP fragmentation of large IKEv2 messages. This allows IKEv2 messages to traverse network devices that don't allow IP fragments to pass through. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-ikev2-fragmentation-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From svanru@gmail.com Mon Sep 9 06:07:19 2013 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 0D61521E81BF for ; Mon, 9 Sep 2013 06:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMN+NhDJtIoX for ; Mon, 9 Sep 2013 06:07:11 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id BC35B21E81A9 for ; Mon, 9 Sep 2013 06:03:44 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id ec20so4978591lab.0 for ; Mon, 09 Sep 2013 06:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=ltNFd4Pp2XbgmV7LFs93XgZ0J+HpRG5jTQ6kKGUZfXQ=; b=R8Z2zmuIAE8MM79qAcBA9aFBJgIqfGRma1+COnz3nr7xsN9SphzfXWMdDdC2wqQ3jQ KHinw8cH37QSm+Snp14Hx5kejt/LMoeOqf8SkZMaTsZwInWK9+O+dKjfvERhWHG4vA9Y T/ABuvgCYnphKeH43VLNdhjUJo8oVMXaKHzASbjW7eL//dfxKiEJrV0hDITNPC/UxI5g MCgN4iNFuWhw0M+2S0YFUAAhFx0k2oNHEYgcfPTpwyxgAm/S6K5fCXvQkcTxH1UyHIA9 PHosibEFc+5pokali9d0E5/nCMRrYQEHFS1/UXI/sxhQUppW2JwvPoIEwxFdbaqmUEop QwgQ== X-Received: by 10.152.7.8 with SMTP id f8mr1646425laa.31.1378731818031; Mon, 09 Sep 2013 06:03:38 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id yl7sm5911631lbb.0.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 09 Sep 2013 06:03:37 -0700 (PDT) Message-ID: <3604DCFECDE249CC88641E43CF140D5C@buildpc> From: "Valery Smyslov" To: References: <20130909125609.10604.50605.idtracker@ietfa.amsl.com> Date: Mon, 9 Sep 2013 17:03:43 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 13:07:19 -0000 Hi all, I've just posted new version of IKEv2 Fragmentation draft. It addresses Yaron's comments on the -01 version. Regards, Valery Smyslov. > 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 > Working Group of the IETF. > > Title : IKEv2 Fragmentation > Author(s) : Valery Smyslov > Filename : draft-ietf-ipsecme-ikev2-fragmentation-02.txt > Pages : 20 > Date : 2013-09-09 > > Abstract: > This document describes the way to avoid IP fragmentation of large > IKEv2 messages. This allows IKEv2 messages to traverse network > devices that don't allow IP fragments to pass through. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-fragmentation-02 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Tue Sep 10 13:36:58 2013 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 254D921F99D5 for ; Tue, 10 Sep 2013 13:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6PSXKanPcHh for ; Tue, 10 Sep 2013 13:36:57 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 65D3C11E8137 for ; Tue, 10 Sep 2013 13:36:56 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id t60so6029608wes.22 for ; Tue, 10 Sep 2013 13:36:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=aLeuY4auMFcrvadmUnHzQSSSE2rc+sMN2un0g8pYa9w=; b=ng2VM7D2vcO0u7Tiz7vfQshREuTomMYY5wBvKOzoD4rZ7dIg2zXAO9AcUvcKiB+03D UtHpV6A548hy1yJ0C/tsUWc6eienHOeZJSNAXcIWspU4rTcQEb+lYhYJUmRh0f9LPVHx sXIGHjo9RQTCLj2Xh6Qv4Lpj/JGHsp7oZWUEzA5yPUJuG46N15sWcl57SxPdZ20FcV4i FojaEvCDRfpmS66Tuvrlq20BMC891r1Y73s4NdlZ6gmGkmbXPVqbtmbx+am8KZEeF0WD RuffzHT6juGTCSlr1YRxhA043ToJnkkpi6/ExP8a7OFaOrSza7XgtQIpd1LZWvudYxiZ vlAg== X-Received: by 10.180.89.147 with SMTP id bo19mr14513674wib.3.1378845415562; Tue, 10 Sep 2013 13:36:55 -0700 (PDT) Received: from [10.0.0.8] (bzq-109-65-190-101.red.bezeqint.net. [109.65.190.101]) by mx.google.com with ESMTPSA id dx7sm6054744wib.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Sep 2013 13:36:54 -0700 (PDT) Message-ID: <522F82E5.6050006@gmail.com> Date: Tue, 10 Sep 2013 23:36:53 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [IPsec] IPsecME virtual interim X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 20:36:58 -0000 Hi, we would like to hold a virtual interim meeting for IPsecME. We propose=20 Tuesday, Oct. 1, at 15:00 UTC (8:00 San Francisco, 17:00 Berlin, 18:00=20 Tel Aviv), for 1:30 hours. Tentative agenda: - Detailed presentations of two AD VPN drafts: draft-detienne-dmvpn-00=20 and http://tools.ietf.org/html/draft-mao-ipsecme-ad-vpn-protocol-02. - A short discussion of draft-ietf-ipsecme-esp-ah-reqts-01. Please let us know if you have any major problem with the date/time,=20 otherwise we will send a formal invitation in a couple of days. Thanks, Paul and Yaron From sdjugum@yahoo.com Wed Sep 11 02:50:51 2013 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 18C2221E809B for ; Wed, 11 Sep 2013 02:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.302 X-Spam-Level: X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FORGED_YAHOO_RCVD=2.297] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LGW3yTOPIDM for ; Wed, 11 Sep 2013 02:50:46 -0700 (PDT) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by ietfa.amsl.com (Postfix) with ESMTP id B318C11E8188 for ; Wed, 11 Sep 2013 02:50:46 -0700 (PDT) Received: from tom.nabble.com ([192.168.236.105]) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VJh4Q-0001ZX-8j for ipsec@ietf.org; Wed, 11 Sep 2013 02:50:46 -0700 Date: Wed, 11 Sep 2013 02:50:46 -0700 (PDT) From: sdjugum To: ipsec@ietf.org Message-ID: <1378893046239-384126.post@n7.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPsec] IPv6 procedures for inner IPv6 addresses (in 6o* IPsec tunnels) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 09:50:51 -0000 Hi, I have some doubt on handling of inner IPv6 addresses on IRAC side in case of e.g. 6o4 IPsec tunnels. As far as I understood from IKEv2 RFC 5996 VPN interfaces do not necessarily have link-local addresses and regular IPv6 procedures (MLD, DAD, NUD) are not done for inner IPv6 addresses by IRAC. Questions: 1. Is it the case only when addresses are obtained via Configuration Payload or also if they are provisioned statically? 2. If IRAC does not handle these procedures for inner IPv6 addresses, then who does? IRAS? 3. What should IRAC do if it receives ICMPv6 messages related to those procedures over tunnel? Is that even possible? Also, is there any documentation/source saying something more about this? I have seen something in the mentioned IKEv2 RFC, and some parts in RFC5739, "IPv6 Configuration in IKEv2" which is experimental and only discusses configuration using CP payload. Thanks a lot in advance. Best regards, Sasa -- View this message in context: http://ietf.10.n7.nabble.com/IPsec-IPv6-procedures-for-inner-IPv6-addresses-in-6o-IPsec-tunnels-tp384126.html Sent from the IETF - Ipsec mailing list archive at Nabble.com. From yaronf.ietf@gmail.com Fri Sep 13 01:05:49 2013 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 AC93C11E817B for ; Fri, 13 Sep 2013 01:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxLmh+K1h8Bd for ; Fri, 13 Sep 2013 01:05:47 -0700 (PDT) Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 065DA11E8179 for ; Fri, 13 Sep 2013 01:05:45 -0700 (PDT) Received: by mail-bk0-f49.google.com with SMTP id r7so315498bkg.8 for ; Fri, 13 Sep 2013 01:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=XVugYeRgMvhd0uGbmkzu9foMa3+3LV5FcvOcePs5edw=; b=aWQ1b5W4WkTyE9mL0UgC3LFPLTy+3eiKlgoBfmL6ow9janPSvfVkCRXj5hRaJ55cHU BWr1cOtIuzGC7aaXVUebu4T4Lwq59n2BdHwMDEazpaIrZvvdRbHHJ5nE1lQoqZkW56c4 e6OhSFEVXHsD4aeAOhkmmF8g9P0UhNycgEwS0h1+8cjc5TYybMkTSyJAa9ThD0jo2rar fmuPezNq5uBcn+mmFHoVTwwR2k4RAMATOFx74FpFfHBLGiedMcZFEaiUP2xJa4KxlGW9 e9jNH8VA3RpRDUcXUkzR1UJCV8Jwj2yAZrkV5RHBCURcqoN0JhAGHaeuER5eNbobh6ZG EQ8A== X-Received: by 10.204.227.70 with SMTP id iz6mr86884bkb.49.1379059545113; Fri, 13 Sep 2013 01:05:45 -0700 (PDT) Received: from [10.0.0.8] (bzq-79-180-176-16.red.bezeqint.net. [79.180.176.16]) by mx.google.com with ESMTPSA id pk7sm2291427bkb.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Sep 2013 01:05:44 -0700 (PDT) Message-ID: <5232C757.4010801@gmail.com> Date: Fri, 13 Sep 2013 11:05:43 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] IPsecME virtual interim - proposing a new date X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 08:05:49 -0000 Hi, The previous date does not work for some of our authors, resending with a new date. We would like to hold a virtual interim meeting for IPsecME. We propose Wednesday, Oct. 9, at 15:00 UTC (8:00 San Francisco, 17:00 Berlin, 18:00 Tel Aviv), for 1:30 hours. Tentative agenda: - Detailed presentations of two AD VPN drafts: draft-detienne-dmvpn-00 and http://tools.ietf.org/html/draft-mao-ipsecme-ad-vpn-protocol-02. - A short discussion of draft-ietf-ipsecme-esp-ah-reqts-01. Please let us know if you have any major problem with the date/time, otherwise we will send a formal invitation in a couple of days. Thanks, Paul and Yaron From ynir@checkpoint.com Sun Sep 15 06:46:05 2013 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 9C48511E80F7 for ; Sun, 15 Sep 2013 06:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.088 X-Spam-Level: X-Spam-Status: No, score=-10.088 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+kVyHhrUwNM for ; Sun, 15 Sep 2013 06:45:59 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 62BCD21F9E28 for ; Sun, 15 Sep 2013 06:45:58 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8FDjv2V011614 for ; Sun, 15 Sep 2013 16:45:57 +0300 X-CheckPoint: {5235BA15-11-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Sun, 15 Sep 2013 16:45:57 +0300 From: Yoav Nir To: " WG" Thread-Topic: Matching certificates in IKEv2 Thread-Index: AQHOshnnlDcvqT4dsU6Dm3cJCfxiMw== Date: Sun, 15 Sep 2013 13:45:57 +0000 Message-ID: <93C680F7-6558-4C3E-AB77-E6CA8EEAD17E@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.71] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: <859708691BC6A848B0EA8D10964A3F5B@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Matching certificates in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 13:46:05 -0000 Hi=20 While working on some text for the AD-VPN document, I came across some weir= dness in the base IKEv2 specification: The IDi and IDr payloads have any of several types: ID_IPV4_ADDR, ID_FQDN, = ID_RFC822_ADDR, ID_IPV6_ADDR, ID_DER_ASN1_DN, ID_DER_ASN1_GN, and ID_KEY_ID= . Section 4 (conformance requirements) says that implementations MUST support= "certificates containing and signed by RSA keys of size 1024 or 2048 bits,= where the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or ID_DE= R_ASN1_DN.". Section 2.15 (authentication of the IKE SA has the following paragraph: Optionally, messages 3 and 4 MAY include a certificate, or certificate chain providing evidence that the key used to compute a digital signature belongs to the name in the ID payload. What I could not find anywhere in the RFC is how to match name in the ID pa= yload to the certificate. In HTTPS we have a requirement that either the CN= or the dNSName alternate name match the domain name in the URL. We don't h= ave similar rules for IKE, do we? Of course, looking at RFC 5280, we have all sorts of alternate names that l= ook suspiciously useful: otherName, rfc822Name, dNSName, directoryName, iPA= ddress. But it is not immediately obvious: 1. Is it enough for the ID payload to match the alternate name? 2. Is it enough for an ID_FQDN to match the CommonName of a certificate su= bject? 3. Is it enough for an ID_DER_ASN1_DN to match the certificate subject? 4. Is it enough if the ID_IPV*_ADDR matches the source IP of the IKE packe= t? I've looked in RFC 4301 and found this in section 4.4.3.2: This document does not require that the IKE ID asserted by a peer be syntactically related to a specific field in an end entity certificate that is employed to authenticate the identity of that peer. However, it often will be appropriate to impose such a requirement, e.g., when a single entry represents a set of peers each of whom may have a distinct SPD entry.=20 The reason this came up in the context of AD-VPN, is that unlike "static" V= PN, in AD-VPN the PAD is populated dynamically, so while we can manually co= nfigure a static VPN implementation that to assert identity "foo", a peer m= ust present a certificate with value "baz" and field "bar", we'd need to ei= ther copy that rule to other peers in AD-VPN (regardless of which solution,= btw), or we'd need a good rule. So do you think it would be appropriate to mandate these matching rules in = rfc5996bis, or should this be left to AD-VPN solutions. IOW, is such a stan= dard rule needed for generic IKE/IPsec? Yoav From srivatsan.raghavan@aricent.com Sun Sep 15 07:32:40 2013 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 D59E921F9FB7 for ; Sun, 15 Sep 2013 07:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0oJY2mzoVPg for ; Sun, 15 Sep 2013 07:32:36 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [180.151.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3264D21F9D7D for ; Sun, 15 Sep 2013 07:32:36 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 5647836B69 for ; Sun, 15 Sep 2013 20:02:13 +0530 (IST) Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id 3FBE736B66 for ; Sun, 15 Sep 2013 20:02:13 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.134]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.136]) with mapi; Sun, 15 Sep 2013 20:02:13 +0530 From: Srivatsan Raghavan To: " WG" Date: Sun, 15 Sep 2013 19:58:06 +0530 Thread-Topic: Internal Address Expiry in IKEv2 Thread-Index: AQHOsiBdc0ekgyrrh0abRZ8pxvyyLQ== Message-ID: References: <93C680F7-6558-4C3E-AB77-E6CA8EEAD17E@checkpoint.com> In-Reply-To: <93C680F7-6558-4C3E-AB77-E6CA8EEAD17E@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: [IPsec] Internal Address Expiry in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 14:32:41 -0000 Hi all How does a Security Gateway specify the validity or duration of an IP Addre= ss via CP ? The INTERNAL_ADDRESS_EXPIRY seems deprecated ? So if the Security Gateway has a notion of lease time, it just has to go an= d delete the tunnel when the address expires and the client sets up the tu= nnel again and requests for an address again? Thx Srivatsan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D From rsj@cisco.com Mon Sep 16 00:01:21 2013 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 910FD11E821A for ; Mon, 16 Sep 2013 00:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5+6hrChuWtq for ; Mon, 16 Sep 2013 00:01:16 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9B311E822E for ; Mon, 16 Sep 2013 00:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2566; q=dns/txt; s=iport; t=1379314876; x=1380524476; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7SKyoRbBwmopWF5kttfwHMJDPN4UmSd3ZK2BwfsTBpg=; b=ICLLSvp1J8y1DDpULg8CqQKyMO0dcpJuqDM6S2xA8lAArpbRzh8ZOqHo 22n8Fd2/oo02CjcD1K5bBXYYNthlAuS68wTrT/BCfm8vfky5DU9JQ46Bq 8D2uytyiqxffKiI/vJDD+WsEHu01UuoMnm6AcEcjknyZ9Pln6/4N4YUJB Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAMarNlKtJV2d/2dsb2JhbABagwc4UoMqvUsXgQEWdIIlAQEBBCMRQwIMBAIBCBEEAQEDAgYdAwICAjAUAQYBAQUDAgQKBAUIARKHaAyoUpE/gSmOGTEHBoJjNYEAA5kqkEWDJIIq X-IronPort-AV: E=Sophos;i="4.90,913,1371081600"; d="scan'208";a="260155336" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 16 Sep 2013 07:01:15 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8G71FG3004040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Sep 2013 07:01:15 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.157]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Mon, 16 Sep 2013 02:01:15 -0500 From: "Rajeshwar Singh Jenwar (rsj)" To: "IPsecme WG (ipsec@ietf.org)" Thread-Topic: New Version Notification for draft-amjads-ipsecme-ikev2-data-channel-00.txt Thread-Index: AQHOsglqQeBxfl6Mm0G94DIwhsqHFZnH74MQ Date: Mon, 16 Sep 2013 07:01:14 +0000 Message-ID: References: <20130915114752.25560.4833.idtracker@ietfa.amsl.com> In-Reply-To: <20130915114752.25560.4833.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.65.190] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mcr@sandelman.ottawa.on.ca" , "kivinen@ike.fi" , "paul.hoffman@vpnc.org" Subject: [IPsec] FW: New Version Notification for draft-amjads-ipsecme-ikev2-data-channel-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 07:01:21 -0000 SGkgQWxsLA0KDQpXZSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCBpbiBJUHNlY01FIFdHIG9u IElLRXYyIGJhc2VkIGxpZ2h0d2VpZ2h0IHNlY3VyZSBkYXRhIGNvbW11bmljYXRpb24uDQpQbGVh c2UgcmV2aWV3Lg0KDQpLaW5kIFJlZ2FyZHMsDQpSYWoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFN1bmRheSwgU2VwdGVtYmVyIDE1LCAyMDEzIDU6MTgg UE0NClRvOiBBbWphZCBJbmFtZGFyIChhbWphZHMpOyBSYWplc2h3YXIgU2luZ2ggSmVud2FyIChy c2opOyBSYWplc2h3YXIgU2luZ2ggSmVud2FyIChyc2opDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWFtamFkcy1pcHNlY21lLWlrZXYyLWRhdGEtY2hhbm5lbC0w MC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYW1qYWRzLWlwc2VjbWUtaWtl djItZGF0YS1jaGFubmVsLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBBbWphZCBTLiBJbmFtZGFyIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0K RmlsZW5hbWU6CSBkcmFmdC1hbWphZHMtaXBzZWNtZS1pa2V2Mi1kYXRhLWNoYW5uZWwNClJldmlz aW9uOgkgMDANClRpdGxlOgkJIElLRXYyIGJhc2VkIGxpZ2h0d2VpZ2h0IHNlY3VyZSBkYXRhIGNv bW11bmljYXRpb24NCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTA5LTE1DQpHcm91cDoJCSBJbmRpdmlk dWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTYNClVSTDogICAgICAgICAgICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYW1qYWRzLWlwc2VjbWUtaWtl djItZGF0YS1jaGFubmVsLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFtamFkcy1pcHNlY21lLWlrZXYyLWRhdGEtY2hhbm5lbA0K SHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hbWphZHMt aXBzZWNtZS1pa2V2Mi1kYXRhLWNoYW5uZWwtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9j dW1lbnQgZGVzY3JpYmVzIGFuIElLRXYyIGJhc2VkIGxpZ2h0d2VpZ2h0IHNlY3VyZSBkYXRhDQog ICBjb21tdW5pY2F0aW9uIG1lY2hhbmlzbSBvdmVyIFVEUCBwb3J0IDQ1MDAsIHRoYXQgc3VwcG9y dHMgcmVsaWFibGUNCiAgIGFuZCB1bnJlbGlhYmxlIGRhdGEgdHJhbnNmZXJzLCBpbnRlZ3JpdHkg cHJvdGVjdGVkIGVuY3J5cHRpb24gYW5kDQogICBpbnRlZ3JpdHktb25seSBwcm90ZWN0aW9uLCBp bi1iYW5kIGFuZCBvdXQtb2YtYmFuZCBrZXlzLA0KICAgZnJhZ21lbnRhdGlvbiBhbmQgcGF5bG9h ZCBpZGVudGlmaWNhdGlvbi4gIFdpdGggdGhpcyBtZWNoYW5pc20sIElLRXYyDQogICBwcm92aWRl cyBhIGNvbXBsZXRlIHNlY3VyZSBjb25uZWN0aXZpdHkgc29sdXRpb24gdGhhdCBhZGRyZXNzZXMg a2V5DQogICBtYW5hZ2VtZW50IGFuZCBzZWN1cmUgZGF0YSBjb21tdW5pY2F0aW9uIG5lZWRzIG9m IGFwcGxpY2F0aW9ucy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From svanru@gmail.com Mon Sep 16 04:02:26 2013 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 A7B2611E8137 for ; Mon, 16 Sep 2013 04:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQp9o6GZ3acg for ; Mon, 16 Sep 2013 04:02:24 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id B719211E81BC for ; Mon, 16 Sep 2013 04:02:22 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id x18so4099644lbi.10 for ; Mon, 16 Sep 2013 04:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=EeMJ2O6Y+NSwmgb+sRRLx5lzMqGFOSDA20yzxF59Gzo=; b=KQ1h/KKwSifwf/VaHMk2xSdDnyoR0o0+xbQYZssAGWApvm/3LbIvvsx7PAAdLOD0nl xycfkUiE9PRUPyhjb4w87l5wLpEBphMKPwl8sVjt83ORYHAJwnwhEOkKl92leFlbJvax d0K58yJJ5q0b8i/ifidaGN9/6uZTVdYleVpv65xwBrWdcDEy5A1cTfKLJgUko6Mm0ITS 1UqHqWLnm28lFy3QRKcsVQ9q8Iu394eKNAIWT+sBt+RO7Txno36IhEoe9MFBl6Lqpftn B8zEsnT3qx5sTnlyV2L1WGy2vktgTYtHTApDP220YDUOlO3afRYu89VeO61FWeSrjF3x CyMw== X-Received: by 10.112.42.68 with SMTP id m4mr25039914lbl.4.1379329341111; Mon, 16 Sep 2013 04:02:21 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id ur6sm12659628lbc.5.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 16 Sep 2013 04:02:20 -0700 (PDT) Message-ID: <1E275AE47A7740CB8179FDC78E02C9AC@buildpc> From: "Valery Smyslov" To: "Yoav Nir" , References: <93C680F7-6558-4C3E-AB77-E6CA8EEAD17E@checkpoint.com> Date: Mon, 16 Sep 2013 15:02:20 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [IPsec] Matching certificates in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 11:02:26 -0000 Hi Yoav, > What I could not find anywhere in the RFC is how to match name in the ID > payload to the certificate. In HTTPS we have a requirement that either the > CN or the dNSName alternate name match the domain name in the URL. We > don't have similar rules for IKE, do we? Yes, we do: RFC4945. > So do you think it would be appropriate to mandate these matching rules in > rfc5996bis, or should this be left to AD-VPN solutions. IOW, is such a > standard rule needed for generic IKE/IPsec? It's definitely worth to mention these rules in RFC5996bis, or at least point to the RFC4945. > Yoav Regards, Valery. From kivinen@iki.fi Mon Sep 16 07:14:32 2013 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 6A4BB11E825E for ; Mon, 16 Sep 2013 07:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMTf5s1P0xty for ; Mon, 16 Sep 2013 07:14:31 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id E455111E8259 for ; Mon, 16 Sep 2013 07:14:30 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r8GEEG2q015445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 16 Sep 2013 17:14:16 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r8GEEF8k012119; Mon, 16 Sep 2013 17:14:15 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21047.4663.527876.51135@fireball.kivinen.iki.fi> Date: Mon, 16 Sep 2013 17:14:15 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <93C680F7-6558-4C3E-AB77-E6CA8EEAD17E@checkpoint.com> References: <93C680F7-6558-4C3E-AB77-E6CA8EEAD17E@checkpoint.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 22 min X-Total-Time: 21 min Cc: " WG" Subject: [IPsec] Matching certificates in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 14:14:32 -0000 Yoav Nir writes: > What I could not find anywhere in the RFC is how to match name in > the ID payload to the certificate. In HTTPS we have a requirement > that either the CN or the dNSName alternate name match the domain > name in the URL. We don't have similar rules for IKE, do we? That is mostly local matter for the CA, cert user and the configuration of the devices. As Valery already pointed out the RFC4945 gives some minimum requirements what implementations need to do. Implementations are free to whatever they feel like to match those rules, for example they might support matching against the sub CAs, or do LDAP lookup or database based on the ID send by the the other end, and then get rules how the cert is matched against the ID. The section 3.5 of the RFC5996 says: ---------------------------------------------------------------------- 3.5. Identification Payloads The Identification payloads, denoted IDi and IDr in this document, allow peers to assert an identity to one another. This identity may be used for policy lookup, but does not necessarily have to match anything in the CERT payload; both fields may be used by an implementation to perform access control decisions. ... The Peer Authorization Database (PAD) as described in RFC 4301 [IPSECARCH] describes the use of the ID payload in IKEv2 and provides a formal model for the binding of identity to policy in addition to providing services that deal more specifically with the details of policy enforcement. The PAD is intended to provide a link between the SPD and the IKE Security Association management. See Section 4.4.3 of RFC 4301 for more details. ---------------------------------------------------------------------- And the section 4.4.3 in RFC4301 has even more text about that. > Of course, looking at RFC 5280, we have all sorts of alternate names > that look suspiciously useful: otherName, rfc822Name, dNSName, > directoryName, iPAddress. But it is not immediately obvious: > > 1. Is it enough for the ID payload to match the alternate name? > 2. Is it enough for an ID_FQDN to match the CommonName of a > certificate subject? > 3. Is it enough for an ID_DER_ASN1_DN to match the certificate subject? Depending on the policy yes. > 4. Is it enough if the ID_IPV*_ADDR matches the source IP of the IKE packet? In the RFC5996 section 3.5 it says: ---------------------------------------------------------------------- When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 does not require this address to match the address in the IP header of IKEv2 packets, or anything in the TSi/TSr payloads. The contents of IDi/IDr are used purely to fetch the policy and authentication data related to the other party. ---------------------------------------------------------------------- Meaning that the IKEv2 implementation might check that, but that check is not required, and depending on the policy and setup it might or might not be done. In most cases it is not useful to do that check, as it does not provide any information. The ID is used to fetch and check the authentication information, i.e. if shared key is found based on the ID and the other end proofs it knows it, that is enough to identify the other end, even if the packets didn't come from that source address. This kind of setup might be useful setup in some environments, for example the enterprice adminstrators might assign each laptop a unique 10.0.x.y address for inside company use, and create certificate or shared key for that specific address. When using the laptop inside the company network the IP address and the ID matches, but when the device is away from the company network it might still be useful to use same ID when connecting the VPN gateway, or servers in the company network, even when the outer IP address might be something completely different. > I've looked in RFC 4301 and found this in section 4.4.3.2: > This document does not require that the IKE ID asserted by a peer be > syntactically related to a specific field in an end entity > certificate that is employed to authenticate the identity of that > peer. However, it often will be appropriate to impose such a > requirement, e.g., when a single entry represents a set of peers each > of whom may have a distinct SPD entry. > > The reason this came up in the context of AD-VPN, is that unlike > "static" VPN, in AD-VPN the PAD is populated dynamically, so while > we can manually configure a static VPN implementation that to assert > identity "foo", a peer must present a certificate with value "baz" > and field "bar", we'd need to either copy that rule to other peers > in AD-VPN (regardless of which solution, btw), or we'd need a good > rule. In the AD-VPN I would expect this kind of things depended a lot about the environment. In some cases the certificates are already there, so they cannot put anything there, thus the AD-VPN implementation needs to be flexible enough to be able to create rules based on that. In some cases the certificates are created on the fly, or specifically for the AD-VPN, so the AD-VPN can dictate what needs to be put and where in the cert, so they will match the policy. > So do you think it would be appropriate to mandate these matching > rules in rfc5996bis, or should this be left to AD-VPN solutions. > IOW, is such a standard rule needed for generic IKE/IPsec? No. The rules are already there in the RFC5996, it says they must match somehow, and leave the details for the different implementations. This is not an interoperability issue for the IKEv2. The PKI profile for IKEv2 gives some minimum requirements that implementations should do, but implementations quite often will do more than just that. If AD-VPN has some specific requirements that are not in the PKI profile for IKEv2 then AD-VPN specification should include those requirements. On the other hand I would expect that different use cases might need different kind of requirements, so I do not expect it to be that simple to put out the exact rules. It might be easy to provide couple of different set of rules which might be needed, but I would still expect that in some cases some implementations might want to implement even more... On the other hand in the AD-VPN this might be interoperability issue, as if the other end does not know what kind of PAD entry it should create, then they cannot talk to each other. -- kivinen@iki.fi From kivinen@iki.fi Mon Sep 16 07:18:36 2013 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 DC4B811E8270 for ; Mon, 16 Sep 2013 07:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzBE9vFSwzj0 for ; Mon, 16 Sep 2013 07:18:36 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id EB4E711E8250 for ; Mon, 16 Sep 2013 07:18:35 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r8GEIPmI012509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 16 Sep 2013 17:18:25 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r8GEIPPb014438; Mon, 16 Sep 2013 17:18:25 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21047.4913.111721.900551@fireball.kivinen.iki.fi> Date: Mon, 16 Sep 2013 17:18:25 +0300 From: Tero Kivinen To: Srivatsan Raghavan In-Reply-To: References: <93C680F7-6558-4C3E-AB77-E6CA8EEAD17E@checkpoint.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 3 min Cc: " WG" Subject: [IPsec] Internal Address Expiry in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 14:18:37 -0000 Srivatsan Raghavan writes: > How does a Security Gateway specify the validity or duration of an > IP Address via CP ? The INTERNAL_ADDRESS_EXPIRY seems deprecated ? It does not. The IP address is valid as long as the IKEv2 SA is valid: RFC5996 section 3.15.1: ---------------------------------------------------------------------- o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the ... The requested address is valid as long as this IKE SA (or its rekeyed successors) requesting the address is valid. ---------------------------------------------------------------------- > So if the Security Gateway has a notion of lease time, it just has > to go and delete the tunnel when the address expires and the client > sets up the tunnel again and requests for an address again? It can do that, but it might be better to just keep the address allocation as long as the IKE SA is up and running. If it got that address from someone else (like from DHCP server or similar), it can do the automatic renewal of the address when it is about to expire, and if that fails, only then delete the IKEv2 SA. -- kivinen@iki.fi From kivinen@iki.fi Mon Sep 16 07:23:02 2013 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 9D4A211E8276 for ; Mon, 16 Sep 2013 07:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMTIJCyK7HVA for ; Mon, 16 Sep 2013 07:23:02 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id C32A411E8124 for ; Mon, 16 Sep 2013 07:23:00 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r8GEMpu3013878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 16 Sep 2013 17:22:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r8GEMprU013587; Mon, 16 Sep 2013 17:22:51 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21047.5179.492194.5267@fireball.kivinen.iki.fi> Date: Mon, 16 Sep 2013 17:22:51 +0300 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <1E275AE47A7740CB8179FDC78E02C9AC@buildpc> References: <93C680F7-6558-4C3E-AB77-E6CA8EEAD17E@checkpoint.com> <1E275AE47A7740CB8179FDC78E02C9AC@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 3 min Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] Matching certificates in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 14:23:02 -0000 Valery Smyslov writes: > > So do you think it would be appropriate to mandate these matching rules in > > rfc5996bis, or should this be left to AD-VPN solutions. IOW, is such a > > standard rule needed for generic IKE/IPsec? > > It's definitely worth to mention these rules in RFC5996bis, or at least > point to the RFC4945. I think adding pointer could be useful, I do not think we should go in to any kind of details about those. Also the RFC4945 is just one profile document, there can also be others. For example some big enterprise or goverment might create their own profile setting different set of rules, and require the implementations they buy to conform to that profile. Most of this is just what kind of policy setups and configurations can be done on the implementation, it does not affect the bits on the wire. -- kivinen@iki.fi From ynir@checkpoint.com Mon Sep 16 11:10:06 2013 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 878BD11E8136 for ; Mon, 16 Sep 2013 11:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.856 X-Spam-Level: X-Spam-Status: No, score=-9.856 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzUDokQmOzCt for ; Mon, 16 Sep 2013 11:10:00 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 560B721F8A38 for ; Mon, 16 Sep 2013 11:10:00 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8GI9sRT015395; Mon, 16 Sep 2013 21:09:54 +0300 X-CheckPoint: {52374972-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Mon, 16 Sep 2013 21:09:54 +0300 From: Yoav Nir To: Valery Smyslov Thread-Topic: [IPsec] Matching certificates in IKEv2 Thread-Index: AQHOshnnlDcvqT4dsU6Dm3cJCfxiM5nINEKVgABFJIA= Date: Mon, 16 Sep 2013 18:09:54 +0000 Message-ID: <44F43840-546B-4CF0-8619-E2EAC60D1A0F@checkpoint.com> References: <93C680F7-6558-4C3E-AB77-E6CA8EEAD17E@checkpoint.com> <1E275AE47A7740CB8179FDC78E02C9AC@buildpc> In-Reply-To: <1E275AE47A7740CB8179FDC78E02C9AC@buildpc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.116] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [IPsec] Matching certificates in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 18:10:06 -0000 On Sep 16, 2013, at 2:02 PM, Valery Smyslov wrote: > Hi Yoav, >=20 >=20 >> What I could not find anywhere in the RFC is how to match name in the ID= payload to the certificate. In HTTPS we have a requirement that either the= CN or the dNSName alternate name match the domain name in the URL. We don'= t have similar rules for IKE, do we? >=20 > Yes, we do: RFC4945. Thanks. I usually search for RFCs by the ipsec or ipsecme working groups, a= nd I totally forgot about pki4ipsec. >> So do you think it would be appropriate to mandate these matching rules = in rfc5996bis, or should this be left to AD-VPN solutions. IOW, is such a s= tandard rule needed for generic IKE/IPsec? >=20 > It's definitely worth to mention these rules in RFC5996bis, or at least p= oint to the RFC4945. Now that I've seen it, I don't think so. Not without updating it. See RFC 5= 996 says in section 4: For an implementation to be called conforming to this specification, it MUST be possible to configure it to accept the following: o Public Key Infrastructure using X.509 (PKIX) Certificates containing and signed by RSA keys of size 1024 or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or ID_DER_ASN1_DN. Note the ID_KEY_ID. But RFC 4945 says this is section 3.1.7: The ID_KEY_ID type used to specify pre-shared keys and thus is out of scope. And in the table in section 3.1: ID type | Support | Correspond | Cert | SPD lookup | for send | PKIX Attrib | matching | rules ------------------------------------------------------------------- | | | | KEY_ID | MUST NOT | n/a | n/a | n/a | | | | From svanru@gmail.com Mon Sep 16 23:00:15 2013 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 F394811E836B for ; Mon, 16 Sep 2013 23:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlRMQzv-gB6P for ; Mon, 16 Sep 2013 23:00:14 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3B311E8361 for ; Mon, 16 Sep 2013 23:00:13 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id eo20so3880240lab.6 for ; Mon, 16 Sep 2013 23:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=/zEsx9n1KTbSRR4tlm4bhIxqmFvWml1HKR+j+OaEHFE=; b=Yd5Mehet0W/ZVL+JAj28BN78Mg2b3Z7eN1gmBnhxnjbxHRKhde+BOlH1iKKVviPgS6 gFNxpv/s6er7UWNNDd41QGvl7Di7aZCHhxLhtPSkRYNKqMTZpk/xkBnzQp6N7HqLreGc KyJNzqAEBCCCYvZ6nZrhX5KXcFUsHT3Vy08bfNGQzJdUpSTdBLZxzgfXf2T+49iMFXS3 wQ0nre87XzxF6PrQQgMD1WvR7Mge8pIN/hsXb1FPKRVUFRulzHE7yJsKj13872HQ+8X7 TixvGvFUA842mqsYkE/qZZGbDEfLsJZglJ2S9EXPfNVkktY5oHkU2me/5sxiLobwPPdo eEPw== X-Received: by 10.152.5.162 with SMTP id t2mr28282592lat.1.1379397612980; Mon, 16 Sep 2013 23:00:12 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id vx8sm14596488lbb.8.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 16 Sep 2013 23:00:12 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Yoav Nir" References: <93C680F7-6558-4C3E-AB77-E6CA8EEAD17E@checkpoint.com> <1E275AE47A7740CB8179FDC78E02C9AC@buildpc> <44F43840-546B-4CF0-8619-E2EAC60D1A0F@checkpoint.com> Date: Tue, 17 Sep 2013 10:00:14 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: ipsec@ietf.org Subject: Re: [IPsec] Matching certificates in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 06:00:15 -0000 > > > So do you think it would be appropriate to mandate these matching > > > rules in rfc5996bis, > > > or should this be left to AD-VPN solutions. IOW, is such a standard > > > rule needed for generic IKE/IPsec? > > > It's definitely worth to mention these rules in RFC5996bis, or at least > > point to the RFC4945. > > Now that I've seen it, I don't think so. Not without updating it. See RFC > 5996 says in section 4: > > For an implementation to be called conforming to this specification, > it MUST be possible to configure it to accept the following: > > o Public Key Infrastructure using X.509 (PKIX) Certificates > containing and signed by RSA keys of size 1024 or 2048 bits, where > the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or > ID_DER_ASN1_DN. > > Note the ID_KEY_ID. But RFC 4945 says this is section 3.1.7: > > The ID_KEY_ID type used to specify pre-shared keys and thus is out of > scope. > > And in the table in section 3.1: > > ID type | Support | Correspond | Cert | SPD lookup > | for send | PKIX Attrib | matching | rules > ------------------------------------------------------------------- > | | | | > KEY_ID | MUST NOT | n/a | n/a | n/a > | | | | Yes, there is no obvious mapping between ID_KEY_ID and certificates and thus ID_KEY_ID is out of scope for RFC4945. And this not the only contradiction between RFC5996 and RFC4945 - the latter requires ID_IPV*_ADDR to match source IP address of IKE packet by default, while the former explicitely allows not to do it in any case. But I still believe that adding a few words about matching ID to certificates, or point to RFC4945 (probably with some explanation text) will still be useful for not so experienced RFC readers as the members of this list. From kivinen@iki.fi Tue Sep 17 05:28:44 2013 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 A5DA211E8220 for ; Tue, 17 Sep 2013 05:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svTUWN1BVFgq for ; Tue, 17 Sep 2013 05:28:44 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 87EF311E840A for ; Tue, 17 Sep 2013 05:28:39 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r8HCSNMP010816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 17 Sep 2013 15:28:23 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r8HCSMMw013309; Tue, 17 Sep 2013 15:28:22 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21048.19174.178525.812957@fireball.kivinen.iki.fi> Date: Tue, 17 Sep 2013 15:28:22 +0300 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: References: <93C680F7-6558-4C3E-AB77-E6CA8EEAD17E@checkpoint.com> <1E275AE47A7740CB8179FDC78E02C9AC@buildpc> <44F43840-546B-4CF0-8619-E2EAC60D1A0F@checkpoint.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 11 min X-Total-Time: 12 min Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] Matching certificates in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 12:28:44 -0000 Valery Smyslov writes: > Yes, there is no obvious mapping between ID_KEY_ID and certificates and > thus ID_KEY_ID is out of scope for RFC4945. As rfc5996 describes ID_KEY_ID as "An opaque octet stream that may be used to pass vendor-specific information necessary to do certain proprietary types of identification." I see no problem that it is not in the RFC4945. It is intended for the vendor-specific information so no standard mapping is provided, vendor will decide one for it. > And this not the only contradiction between RFC5996 and RFC4945 - > the latter requires ID_IPV*_ADDR to match source IP address of IKE > packet by default, while the former explicitely allows not to do it > in any case. RFC4945 requires that implementations "MUST be capable of verifying" the ID_IPV*_ADDR and IP-address of the packet. RFC5996 says that IKEv2 does not require such check. There is no contradiction there. All of that is mostly because in IKEv1 that check was always done, and people considered it important to be done. In IKEv2 we realized that kind of test does not really help, and can cause some problems in some scenarios, so that check was explictly said not to be required anymore. The RFC4945 parts are shared with IKEv1 and IKEv2, thus they set the same requirements for it, but IKEv2 implementation can be conformant with both of them, i.e provide option to disable that check, and make it so that by default the checks are done (to be conformant to RFC4945), but allow those test to be disabled (as is allowed in the RFC5996). > But I still believe that adding a few words about matching ID to > certificates, or point to RFC4945 (probably with some explanation > text) will still be useful for not so experienced RFC readers as the > members of this list. Yes adding reference to the RFC4945 might be useful, it was not done in the RFC4306 as the RFC4945 was not ready at that time. Most likely we should have added it when doing RFC5996 but we didn't. Perhaps adding reference to the RFC4945 at the end of section 3.5. Identification Payloads in the RFC5996bis? -- kivinen@iki.fi From svanru@gmail.com Tue Sep 17 06:31:39 2013 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 D653F11E844C for ; Tue, 17 Sep 2013 06:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TGemTptbe1i for ; Tue, 17 Sep 2013 06:31:39 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9E59311E8446 for ; Tue, 17 Sep 2013 06:31:37 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id u14so5257360lbd.26 for ; Tue, 17 Sep 2013 06:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=0+Pa72wHXSsCGrGOe6h6nKBTPCjDZU/6+nYK8lWj0qc=; b=X11sqCmV+tVxbFOFANTwX8/ZEMAsOZ3VaHiLGE2fC5+IUwWKcID2iAZl2fH5fq1yBN WSSnf++P69t3qATtEbNEoQmuFDsL3p0SPcao6G1XtPbX0qXC8zaYnFus8lUZpMxw0GkC X15TazmreYJS7Wo2TM8p5ezIYbalTGP9ZcrcCsTv4FPpf+VKjFYPMmTnp8nnlpCljRJD 7o8M6utylWpCEBVaTv/UowFdTtYdS6+Khxkrg/dcFMlGDzG087Orw+vquIyoR0AAzL+A o+1yVQqtxspQkV1vvezVqaVXsylhBaKjzXzMxEdfzKzFR86tRJ+fEqNck7Dt3KxPrSNI tq8A== X-Received: by 10.112.167.66 with SMTP id zm2mr1062587lbb.46.1379424696544; Tue, 17 Sep 2013 06:31:36 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id w10sm15551071lbv.6.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 17 Sep 2013 06:31:35 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Tero Kivinen" References: <93C680F7-6558-4C3E-AB77-E6CA8EEAD17E@checkpoint.com><1E275AE47A7740CB8179FDC78E02C9AC@buildpc><44F43840-546B-4CF0-8619-E2EAC60D1A0F@checkpoint.com> <21048.19174.178525.812957@fireball.kivinen.iki.fi> Date: Tue, 17 Sep 2013 17:31:40 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] Matching certificates in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 13:31:39 -0000 >> And this not the only contradiction between RFC5996 and RFC4945 - >> the latter requires ID_IPV*_ADDR to match source IP address of IKE >> packet by default, while the former explicitely allows not to do it >> in any case. > > RFC4945 requires that implementations "MUST be capable of verifying" > the ID_IPV*_ADDR and IP-address of the packet. RFC5996 says that IKEv2 > does not require such check. There is no contradiction there. RFC4945 requires (MUST) this check to be done by default, treats mismatch as an error and allows (MAY) to skip this check only for interoperability purpose. Probably not contradiction, but some inconsistency, in my opinion. > Yes adding reference to the RFC4945 might be useful, it was not done > in the RFC4306 as the RFC4945 was not ready at that time. Most likely > we should have added it when doing RFC5996 but we didn't. > > Perhaps adding reference to the RFC4945 at the end of section 3.5. > Identification Payloads in the RFC5996bis? Yes, and some explanation text about inconsistencies between the approaches to match ID to certificate. From rsj@cisco.com Wed Sep 18 00:02:49 2013 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 0834311E819F for ; Wed, 18 Sep 2013 00:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWrZuHB5Zmn0 for ; Wed, 18 Sep 2013 00:02:43 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C0F8E11E8197 for ; Wed, 18 Sep 2013 00:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3274; q=dns/txt; s=iport; t=1379487763; x=1380697363; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=92YNZpZN8JWt6bbYyLx9rclk/e+Z7a00fALA4Glk0NE=; b=KZNkXLbcgPh5rnLj7Ftc9FzE2MoHSiRSti4xk3AE0Fvlz4vsLCe2FZG8 /Yk7Zdzoj7lq9T6zqx/Kuxq77cuH4NxJY2HSks9XL4E3pLRTx6b5242mj 4kZPiZ0ZdeKinuX8wcG1wyqtwSoR1H4MVL/XzXmOHX/mySJVzIi50Bbhm 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAAZPOVKtJXHB/2dsb2JhbABagwc4TAbBOYEXFnSCJQEBAQMBAQEBNzQQBwQCAQgOAwQBAQsUCQcnCxQJCAIEARIIARKHYgYHBboDjhgQgQ44BoMYgQADmSqQRYMkgWhC X-IronPort-AV: E=Sophos;i="4.90,928,1371081600"; d="scan'208";a="258237562" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 18 Sep 2013 07:02:43 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8I72h4G014025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Sep 2013 07:02:43 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.157]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Wed, 18 Sep 2013 02:02:43 -0500 From: "Rajeshwar Singh Jenwar (rsj)" To: Valery Smyslov , "ipsec@ietf.org" Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-02.txt Thread-Index: AQHOrV2IRog/VtiSg0GBneXirHRZgZnLCYkg Date: Wed, 18 Sep 2013 07:02:42 +0000 Message-ID: References: <20130909125609.10604.50605.idtracker@ietfa.amsl.com> <3604DCFECDE249CC88641E43CF140D5C@buildpc> In-Reply-To: <3604DCFECDE249CC88641E43CF140D5C@buildpc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.66.27] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 07:02:49 -0000 Hi Valery, IKEv2 fragmentation is mostly used for large sized packets. There are use-c= ases when our implementation needs to send huge sized packet over IKEv2 con= trol plane channel.=20 On lossy network if one of the fragment is lost, using current draft, respo= nder will not be able to reassemble IKEv2 packet, so initiator needs to re-= transmit all the fragments again. If we are already going for integrity protected encryption for each fragmen= t, is option of ACK response for each fragment using encrypted fragment pay= load has been investigated ? Using encrypted fragment payload for ACK for fragment, if some fragment are= lost while retransmitting we can retransmit only those fragments for which= we have not received ACK. The solution works well for time critical large size control packets, on th= e down side, it incurs ACK overhead for each fragment on networks where the= re is no packet loss. In constrained devices environment, need of fragmentation will be more as t= hese networks can carry limited size of packet. More re-transmit on lossy and constraint devices will consume more battery = too. At the same time these network are lossy in nature, so having an ACK mechan= ism for fragments make more sense. Kind Regards, Raj -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of V= alery Smyslov Sent: Monday, September 09, 2013 6:34 PM To: ipsec@ietf.org Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-02.= txt Hi all, I've just posted new version of IKEv2 Fragmentation draft. It addresses Yaron's comments on the -01 version. Regards, Valery Smyslov. > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the IP Security Maintenance and=20 > Extensions Working Group of the IETF. > > Title : IKEv2 Fragmentation > Author(s) : Valery Smyslov > Filename : draft-ietf-ipsecme-ikev2-fragmentation-02.txt > Pages : 20 > Date : 2013-09-09 > > Abstract: > This document describes the way to avoid IP fragmentation of large > IKEv2 messages. This allows IKEv2 messages to traverse network > devices that don't allow IP fragments to pass through. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentatio > n > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-ikev2-fragmentatio > n-02 > > > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at=20 > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From svanru@gmail.com Wed Sep 18 04:53:03 2013 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 D4A4F11E822D for ; Wed, 18 Sep 2013 04:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaCJx2uHgISR for ; Wed, 18 Sep 2013 04:53:03 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 43A4511E8226 for ; Wed, 18 Sep 2013 04:52:50 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id w7so6361687lbi.8 for ; Wed, 18 Sep 2013 04:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=lm8saC4ozhVpobNTrvojhc3f62f95GNluBGfgmjTpZY=; b=vydhw39FSXH15jvwnsbVE3+PNQgy4rHY9NRZoqWDvK/PJ3Pzr+JPDrwRFzeAnN2xcy qkyORAW5kHbSQHCfG/sUntRqCgKW9TF6s/d5YqVthjVYtpYLViX5Hb3UG1GQkcAs9Qgn 7JPRHtRfnOON/JJGiggRUqb+VYaTt51/g/xyuCrChlsxnkgwtxbz4wlZHkCOxPROUk9V rwhY+3+bsgkiVgB6WMHR92/rEkz/5wsxWnU8s/XbJtRw64gLxWDv17QKy1ul1GgSBCCy mW+G0lw3hUKLV71UuauIto87Z21q8TLPFemRnciWLOrAtvkhoCZzCkp8hJZ7vmhkuxLr jeag== X-Received: by 10.152.36.98 with SMTP id p2mr34461141laj.14.1379505169893; Wed, 18 Sep 2013 04:52:49 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id b6sm759857lae.0.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 18 Sep 2013 04:52:49 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Rajeshwar Singh Jenwar \(rsj\)" , References: <20130909125609.10604.50605.idtracker@ietfa.amsl.com> <3604DCFECDE249CC88641E43CF140D5C@buildpc> Date: Wed, 18 Sep 2013 15:52:54 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-fragmentation-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 11:53:04 -0000 Hi Raj, > IKEv2 fragmentation is mostly used for large sized packets. There are > use-cases when our > implementation needs to send huge sized packet over IKEv2 control plane > channel. > On lossy network if one of the fragment is lost, using current draft, > responder will not be able > to reassemble IKEv2 packet, so initiator needs to re-transmit all the > fragments again. True. > If we are already going for integrity protected encryption for each > fragment, is option of ACK > response for each fragment using encrypted fragment payload has been > investigated ? I was thinking about ACKs, but rejected this idea for the sake of simplicity. Adding ACKs would have required to change all the underlying request-response logic from simple Request ---> <--- Response to Request ---> <--- ACK(s) <--- Response ACK(s) ---> and this change would have violated some of RFC5996 core statements. For example, in IKEv2 only Initiator is responsible for retransmissions, with ACKs this would have not been true. > Using encrypted fragment payload for ACK for fragment, if some fragment > are lost while > retransmitting we can retransmit only those fragments for which we have > not received ACK. > The solution works well for time critical large size control packets, on > the down side, it incurs > ACK overhead for each fragment on networks where there is no packet loss. > > In constrained devices environment, need of fragmentation will be more as > these networks > can carry limited size of packet. > More re-transmit on lossy and constraint devices will consume more battery > too. > At the same time these network are lossy in nature, so having an ACK > mechanism for fragments make more sense. >From my opinion, it depends. ACKs would have been useful if: - fragments are relatively large - probability of packet loss is relatively small - you want to reach maximum network bandwidth utilization For situation you described, adding ACK might make things even worse, because: - when fragments are small, overhead caused by ACKs becomes significant in terms both network utilization and power consumption. Note, that ACKs must be protected against spoofing, so you should make some cypto operations on each of them (at least calculate ICV). - if network is lossy, ACKs will get lost either, causing unnecessary retransmissions and bandwidth consumption For example. Consider we have network with fragment size 512 bytes and probability of packet loss of 1/100. And consider you want to send 50Kbytes of data in 10 IKE Messages. So, each IKE Message wiil be splitted into 10 fragments, totally 100 fragments. With very high probability one of them will get lost. Without ACKs one entire Message of 10 fragments will be retransmitted, So we have 5Kbytes overhead (10%). With ACKs we have to acknowledge all 100 fragments sending 100 ACKs. With ACK size about 50 bytes (header, ICV) it is 5Kbytes overhead. Again, one fragment will get lost, causing its retransmission. And among 100 ACKs one will also get lost, causing unnecessary retransmission of one fragment. So, total overhead will be 6Kbytes (12%). Of cause, this example is oversimplified, but the idea is clear. I think that if you need to send large amount of data over IKE you'd better to split data on the higher level (if it is possible). IKE Fragmentation will do its best, but it is the last resort for those cases, when splitting is impossible. BTW: thinking of this I came across one simple optimization that is not yet in the draft. If some of response fragments get lost, but Initiator have received at least one of them (meaning, that Responder get received request Message), Initiator may retransmit not all, but only the very first of request fragments to cause Responder to resend its response. This is simple and I will add this optimization (as MAY) to the next version of the draft. Thank you. > Kind Regards, > Raj Regards, Valery. From paul@cypherpunks.ca Wed Sep 18 06:59:03 2013 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 D9B0511E82C3 for ; Wed, 18 Sep 2013 06:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sqn74hpk7kaY for ; Wed, 18 Sep 2013 06:58:57 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id BCF7011E8241 for ; Wed, 18 Sep 2013 06:58:57 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cg2q0407Vz1cQ; Wed, 18 Sep 2013 09:58:52 -0400 (EDT) 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 rkR_Me4hjeeX; Wed, 18 Sep 2013 09:58:51 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Wed, 18 Sep 2013 09:58:51 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 7F5468009E; Wed, 18 Sep 2013 09:58:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7838E80018; Wed, 18 Sep 2013 09:58:51 -0400 (EDT) Date: Wed, 18 Sep 2013 09:58:51 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: "Rajeshwar Singh Jenwar (rsj)" In-Reply-To: Message-ID: References: <20130909125609.10604.50605.idtracker@ietfa.amsl.com> <3604DCFECDE249CC88641E43CF140D5C@buildpc> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ipsec@ietf.org" , Valery Smyslov Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 13:59:04 -0000 On Wed, 18 Sep 2013, Rajeshwar Singh Jenwar (rsj) wrote: > > IKEv2 fragmentation is mostly used for large sized packets. There are use-cases when our implementation needs to send huge sized packet over IKEv2 control plane channel. > On lossy network if one of the fragment is lost, using current draft, responder will not be able to reassemble IKEv2 packet, so initiator needs to re-transmit all the fragments again. > > If we are already going for integrity protected encryption for each fragment, is option of ACK response for each fragment using encrypted fragment payload has been investigated ? > > Using encrypted fragment payload for ACK for fragment, if some fragment are lost while retransmitting we can retransmit only those fragments for which we have not received ACK. > The solution works well for time critical large size control packets, on the down side, it incurs ACK overhead for each fragment on networks where there is no packet loss. Isn't it easier (and cheaper/faster) to jsut send all fragments again? The receiving hasn't thrown away its previosuly received fragments and can just discard the duplicate frames. > In constrained devices environment, need of fragmentation will be more as these networks can carry limited size of packet. > More re-transmit on lossy and constraint devices will consume more battery too. > At the same time these network are lossy in nature, so having an ACK mechanism for fragments make more sense. I'd say it would take more resources to build up a new packet to request particular frames. Also in IKEv2, its really up to the initiator to re-send, so itshould jsut re-send all its frames while the responder just waits on the missing frames. Paul From kivinen@iki.fi Thu Sep 19 04:46:21 2013 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 A26DE21F9998 for ; Thu, 19 Sep 2013 04:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6O+4itA24Z5 for ; Thu, 19 Sep 2013 04:46:21 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6B25921F9223 for ; Thu, 19 Sep 2013 04:46:16 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r8JBk3pG004656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Sep 2013 14:46:03 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r8JBjxE0004710; Thu, 19 Sep 2013 14:45:59 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21050.58359.867144.634633@fireball.kivinen.iki.fi> Date: Thu, 19 Sep 2013 14:45:59 +0300 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: References: <93C680F7-6558-4C3E-AB77-E6CA8EEAD17E@checkpoint.com> <1E275AE47A7740CB8179FDC78E02C9AC@buildpc> <44F43840-546B-4CF0-8619-E2EAC60D1A0F@checkpoint.com> <21048.19174.178525.812957@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 8 min Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] Matching certificates in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 11:46:21 -0000 Valery Smyslov writes: > >> And this not the only contradiction between RFC5996 and RFC4945 - > >> the latter requires ID_IPV*_ADDR to match source IP address of IKE > >> packet by default, while the former explicitely allows not to do it > >> in any case. > > > > RFC4945 requires that implementations "MUST be capable of verifying" > > the ID_IPV*_ADDR and IP-address of the packet. RFC5996 says that IKEv2 > > does not require such check. There is no contradiction there. > > RFC4945 requires (MUST) this check to be done by default, treats mismatch as > an error and allows (MAY) to skip this check only for interoperability > purpose. > Probably not contradiction, but some inconsistency, in my opinion. Not really inconsistency, it just means that the RFC4945 profile requires more features than what is required in IKEv2 in general (i.e. to be able to do the check, and that check is on by default). So RFC4945 is bit more strict than RFC5996. RFC4945 is IPsec PKI profile document so it is intended to limit things more than the basic IKEv2. If someone writes some IPsec XXX Profile document that might add some other restrictions, for example such profile might require that 4096 bit RAW RSA keys must be used for all authentication for that XXX environment. This is again more strict than RFC5996 and there is no contradiction or inconsistency there. There are RFC5996 implementations which do not need to implement RFC4945. > > Perhaps adding reference to the RFC4945 at the end of section 3.5. > > Identification Payloads in the RFC5996bis? > > Yes, and some explanation text about inconsistencies between the approaches > to match ID to certificate. No. I do not think we need such text. RFC5996 text is for general IKEv2 implementation. RFC4945 text is only for those implementations which support that RFC, not for all IKEv2 implementations. RFC4945 is supposed to be stricter than RFC5996. If there is case where RFC4945 requires operations which are not allowed by RFC5996 then we do have inconsistancy. -- kivinen@iki.fi From kivinen@iki.fi Thu Sep 19 04:58:20 2013 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 4423B21F9301 for ; Thu, 19 Sep 2013 04:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0CiJI1Odnm6 for ; Thu, 19 Sep 2013 04:58:19 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3035021F92B8 for ; Thu, 19 Sep 2013 04:58:13 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r8JBw2VH018897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Sep 2013 14:58:02 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r8JBw2qt004914; Thu, 19 Sep 2013 14:58:02 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21050.59081.949626.25045@fireball.kivinen.iki.fi> Date: Thu, 19 Sep 2013 14:58:01 +0300 From: Tero Kivinen To: "Rajeshwar Singh Jenwar \(rsj\)" In-Reply-To: References: <20130909125609.10604.50605.idtracker@ietfa.amsl.com> <3604DCFECDE249CC88641E43CF140D5C@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 7 min Cc: "ipsec@ietf.org" , Valery Smyslov Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 11:58:20 -0000 Rajeshwar Singh Jenwar (rsj) writes: > IKEv2 fragmentation is mostly used for large sized packets. There > are use-cases when our implementation needs to send huge sized > packet over IKEv2 control plane channel. I have understood that the idea for IKEv2 fragmentation is to be used for large packets which cannot be split in to the pieces in the existing exchanges. I.e. when the IKE_AUTH gets too big because the certificate payloads etc. If you are doing some extension over IKEv2 where you know that the data will be large, you should define the protocol so it uses multiple IKEv2 messages. I.e. if you are planning to make policy transport exchange for IKEv2, it would be better to split the data to smaller pieces by the upper level and send them as separate messages. This also allows windowing of the messages, i.e. you can send next message while you are waiting for the IKEv2 acknowledgement of the previous IKEv2 message, and if you are not getting it, you can retransmit the packet normally (all fragments of it). Anyways IKEv2 is not really designed for large data transfers, as it is misssing some key features for that use. For example the policy transport would be much better done as separate TCP stream inside the IKEv2 negotiated ESP SA... > If we are already going for integrity protected encryption for each > fragment, is option of ACK response for each fragment using > encrypted fragment payload has been investigated ? I think the current versions is simplier and better. > In constrained devices environment, need of fragmentation will be > more as these networks can carry limited size of packet. More > re-transmit on lossy and constraint devices will consume more > battery too. At the same time these network are lossy in nature, so > having an ACK mechanism for fragments make more sense. In radio networks there is quite often link layer acks already, so the link layer tries to make sure each fragment reaches its destination and they will do retransmissions at their own. Constrained devices might not have enough resources to actually do any large sized packets anyways, and that makes it even more important to make sure the packets do not get too big and do some upper level splitting of the data. -- kivinen@iki.fi From yaronf.ietf@gmail.com Thu Sep 19 09:44:41 2013 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 DDE4121F95DD for ; Thu, 19 Sep 2013 09:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.649 X-Spam-Level: X-Spam-Status: No, score=-102.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UDEuPfyM-tY for ; Thu, 19 Sep 2013 09:44:40 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id E97AC21F9005 for ; Thu, 19 Sep 2013 09:44:39 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id t60so8142397wes.22 for ; Thu, 19 Sep 2013 09:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5h2R/dUUC5pkzBWp0E4WILKVpraoE/+3PRpjk45m3As=; b=EkPD7ZGm/Yw+j0LXfrV6JZ8NTmBSVgBW4DWSOGvHcUpXNEdXaTkkUZ15qMeoh3Bc5w jG5dpfTfqFtudVG2TNr0shb6Z6LPy7K0ggW7Px75yKxRCA8QXwjgWZaj+iaIG40R4IuD WBxL8Z2q8yuFgscxP/DdQbT94rJHeUcWFQ1CogACciuMrDOi+k9dSX5WVqHHn12l161U DB/xoow1ngpCsjvE8dBujmwQKqNA25AVxjZQc2it4Vj5cAPpRoM+kbGBIAh+TteEBICS uWeQBbw9h9h/kux8cMnWN7sdF0QpEKNKgg7ylevztFfdqvMSwmvvb+Lw+C6bqPOKCr+x 7JIQ== X-Received: by 10.194.123.227 with SMTP id md3mr2190300wjb.17.1379609079090; Thu, 19 Sep 2013 09:44:39 -0700 (PDT) Received: from [10.0.0.8] (bzq-109-64-175-213.red.bezeqint.net. [109.64.175.213]) by mx.google.com with ESMTPSA id dx7sm11109879wib.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Sep 2013 09:44:38 -0700 (PDT) Message-ID: <523B29F4.3000406@gmail.com> Date: Thu, 19 Sep 2013 19:44:36 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Tero Kivinen References: <93C680F7-6558-4C3E-AB77-E6CA8EEAD17E@checkpoint.com> <1E275AE47A7740CB8179FDC78E02C9AC@buildpc> <44F43840-546B-4CF0-8619-E2EAC60D1A0F@checkpoint.com> <21048.19174.178525.812957@fireball.kivinen.iki.fi> <21050.58359.867144.634633@fireball.kivinen.iki.fi> In-Reply-To: <21050.58359.867144.634633@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Valery Smyslov , Yoav Nir Subject: Re: [IPsec] Matching certificates in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 16:44:41 -0000 I just reread the introduction of RFC 4945 and I don't understand its purpose. So I'm not sure it should be referenced from 5996bis. It is definitely not a "profile" in the sense that Tero is alluding to. Tero's own "minimal IKEv2" is a profile for a specific use. RFC 4945 just attempts to fill in the holes (or perceived holes) in RFC 4306 and PKIX docs wrt PKI use in IPsec. Which just happens to be the main use case of IKE/IPsec! Quoting: "This profile of the IKE and PKIX frameworks is intended to provide an agreed-upon standard for using PKI technology in the context of IPsec by profiling the PKIX framework for use with IKE and IPsec, and by documenting the contents of the relevant IKE payloads and further specifying their semantics." Thanks, Yaron On 09/19/2013 02:45 PM, Tero Kivinen wrote: > Valery Smyslov writes: >>>> And this not the only contradiction between RFC5996 and RFC4945 - >>>> the latter requires ID_IPV*_ADDR to match source IP address of IKE >>>> packet by default, while the former explicitely allows not to do it >>>> in any case. >>> [...]> >>> Perhaps adding reference to the RFC4945 at the end of section 3.5. >>> Identification Payloads in the RFC5996bis? >> >> Yes, and some explanation text about inconsistencies between the approaches >> to match ID to certificate. > > No. I do not think we need such text. RFC5996 text is for general > IKEv2 implementation. RFC4945 text is only for those implementations > which support that RFC, not for all IKEv2 implementations. RFC4945 is > supposed to be stricter than RFC5996. > > If there is case where RFC4945 requires operations which are not > allowed by RFC5996 then we do have inconsistancy. > From david.lloyd@fsmail.net Sat Sep 21 04:31:16 2013 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 8D47E11E8152 for ; Sat, 21 Sep 2013 04:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_50=0.001, SARE_FREE_WEBM_NetFs=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhGIa1gS5HQ1 for ; Sat, 21 Sep 2013 04:31:10 -0700 (PDT) Received: from smtpout.wanadoo.co.uk (smtpout5.wanadoo.co.uk [80.12.242.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7F58011E814C for ; Sat, 21 Sep 2013 04:31:09 -0700 (PDT) Received: from wwinf3706 ([10.232.27.33]) by mwinf5d65 with ME id TnX81m0060irfA203nX8S2; Sat, 21 Sep 2013 13:31:08 +0200 Date: Sat, 21 Sep 2013 13:31:08 +0200 From: david.lloyd@fsmail.net To: ipsec@ietf.org, dane@ietf.org Message-ID: <22017290.30831379763068147.JavaMail.www@wwinf3706> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [86.26.3.116] X-Wum-Nature: EMAIL-NATURE X-WUM-FROM: |~| X-WUM-TO: |~||~| X-WUM-REPLYTO: |~| Subject: [IPsec] Bootstrapping IPSec from DNSSSEC/DANE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: david.lloyd@fsmail.net List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 11:31:16 -0000 Hi, I am interested in using a variant of DANE to bootstrap my IPSec IKE root certificate trust. Is anyone aware of any work been done in this area? >From my understanding, it looks as though the is no technical issue with using reverse DNS lookup for the IPSec target machine with DNSSec (although this may be a little unreliable on the "real-world" internet), so returning standard DANE entries for the IPSec certificate. Then I would simply use these as part of the standard IPSec certificate validation algorithm. Looking at similar proposed applications of DANE, such as the draft-ietf-dane-srv, mostly this involves defining an appropriate protocol query name (for example _ipsec.123.123.123.123.in-addr.arpa). Is this something that would fit into an existing document either from the IKE side or the DANE side? Or would it be worth me creating an more extensive proposal? Regards, David L P.S. Sorry for cross-signing two lists! From ynir@checkpoint.com Sat Sep 21 05:59:41 2013 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 4DA5911E81BF; Sat, 21 Sep 2013 05:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.328 X-Spam-Level: X-Spam-Status: No, score=-10.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kmooTmpFSOQ; Sat, 21 Sep 2013 05:59:36 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 393B011E81BB; Sat, 21 Sep 2013 05:59:36 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8LCxP4Y020496; Sat, 21 Sep 2013 15:59:25 +0300 X-CheckPoint: {523D982C-A-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Sat, 21 Sep 2013 15:59:24 +0300 From: Yoav Nir To: "" Thread-Topic: [dane] Bootstrapping IPSec from DNSSSEC/DANE Thread-Index: AQHOtr4iTVR6J9u2QkGzbufPDyXY6JnP9QKA Date: Sat, 21 Sep 2013 12:59:24 +0000 Message-ID: <39C9757C-9E0B-4606-AB6F-5143E913EF95@checkpoint.com> References: <22017290.30831379763068147.JavaMail.www@wwinf3706> In-Reply-To: <22017290.30831379763068147.JavaMail.www@wwinf3706> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.24.10] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [IPsec] [dane] Bootstrapping IPSec from DNSSSEC/DANE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 12:59:41 -0000 Hi David I believe this would require a separate document. But I'm not sure that tyi= ng it to an IP address is appropriate. IKE implementations work from behind= NAT devices and sometimes move around (see MOBIKE), so I think it would be= more appropriate to tie the record to any type of ID payload that we have = in IKE: IP address and FQDN at least, maybe also KEYID and RFC822 address.= =20 You might need to profile the IKE IDs used for this. Yoav On Sep 21, 2013, at 2:31 PM, david.lloyd@fsmail.net wrote: > Hi, >=20 > I am interested in using a variant of DANE to bootstrap my IPSec IKE root= certificate trust. Is anyone aware of any work been done in this area? >=20 > From my understanding, it looks as though the is no technical issue with = using reverse DNS lookup for the IPSec target machine with DNSSec (although= this may be a little unreliable on the "real-world" internet), so returnin= g standard DANE entries for the IPSec certificate. Then I would simply use= these as part of the standard IPSec certificate validation algorithm. >=20 > Looking at similar proposed applications of DANE, such as the draft-ietf-= dane-srv, mostly this involves defining an appropriate protocol query name = (for example _ipsec.123.123.123.123.in-addr.arpa). >=20 > Is this something that would fit into an existing document either from th= e IKE side or the DANE side? Or would it be worth me creating an more exte= nsive proposal? >=20 > Regards, >=20 > David L >=20 > P.S. Sorry for cross-signing two lists! > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From cloos@jhcloos.com Sat Sep 21 07:39:36 2013 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 8B1FA21F9EB8; Sat, 21 Sep 2013 07:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qljzF6T4SFJT; Sat, 21 Sep 2013 07:39:36 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3B521F9EAF; Sat, 21 Sep 2013 07:39:35 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 8963A1DE6D; Sat, 21 Sep 2013 14:39:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1379774373; bh=x0eqD840frbzCOtcc9WTlr/tkBwrUloxl9383/JQ7fc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=lcHqNq+xts2qfacIYjC5i856ExUOvBdLFe+fTNDBp4M3yIhr7ffMm///tisA7ba18 95arnerKREj2aLGygRjR0B1Eth1vp2hU+1Qny565VdwYri1k3+BMKDkCkO9vtxMeUp MRC/Y0Q7j9cjTg0TPCK09TYpsPbvFvG0UYg4pFkowSQ== Received: by carbon.jhcloos.org (Postfix, from userid 500) id CB4A06001E; Sat, 21 Sep 2013 14:36:51 +0000 (UTC) From: James Cloos To: david.lloyd@fsmail.net In-Reply-To: <22017290.30831379763068147.JavaMail.www@wwinf3706> (david lloyd's message of "Sat, 21 Sep 2013 13:31:08 +0200") References: <22017290.30831379763068147.JavaMail.www@wwinf3706> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sat, 21 Sep 2013 10:36:51 -0400 Message-ID: Lines: 8 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:130921:david.lloyd@fsmail.net::ayx3ztgeF1P5uilV:00000000000000000000000000000000000000O5v2U X-Hashcash: 1:28:130921:ipsec@ietf.org::0YzCxo1IZ7OC/nSW:004tjjP X-Hashcash: 1:28:130921:dane@ietf.org::HqYYCod2wEN7g9nU:0003XIT5 Cc: ipsec@ietf.org, dane@ietf.org Subject: Re: [IPsec] [dane] Bootstrapping IPSec from DNSSSEC/DANE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 14:39:36 -0000 > I am interested in using a variant of DANE to bootstrap my IPSec IKE > root certificate trust. Is anyone aware of any work been done in this Start with rfcs 4025 and 4322. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From paul@cypherpunks.ca Sat Sep 21 18:53:55 2013 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 91B9911E81F5; Sat, 21 Sep 2013 18:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0v7k7LXiclHW; Sat, 21 Sep 2013 18:53:49 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id A148E11E81F2; Sat, 21 Sep 2013 18:53:49 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cjBXV16vtz3pK; Sat, 21 Sep 2013 21:53:46 -0400 (EDT) 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 ufzpAEttT5VP; Sat, 21 Sep 2013 21:53:45 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Sat, 21 Sep 2013 21:53:45 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id E881C8009E; Sat, 21 Sep 2013 21:53:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DFA8580018; Sat, 21 Sep 2013 21:53:45 -0400 (EDT) Date: Sat, 21 Sep 2013 21:53:45 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Yoav Nir In-Reply-To: <39C9757C-9E0B-4606-AB6F-5143E913EF95@checkpoint.com> Message-ID: References: <22017290.30831379763068147.JavaMail.www@wwinf3706> <39C9757C-9E0B-4606-AB6F-5143E913EF95@checkpoint.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "" , "" , "" Subject: Re: [IPsec] [dane] Bootstrapping IPSec from DNSSSEC/DANE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 01:53:55 -0000 On Sat, 21 Sep 2013, Yoav Nir wrote: > I believe this would require a separate document. But I'm not sure that tying it to an IP address is appropriate. IKE implementations work from behind NAT devices and sometimes move around (see MOBIKE), so I think it would be more appropriate to tie the record to any type of ID payload that we have in IKE: IP address and FQDN at least, maybe also KEYID and RFC822 address. > > You might need to profile the IKE IDs used for this. > On Sep 21, 2013, at 2:31 PM, david.lloyd@fsmail.net wrote: >> I am interested in using a variant of DANE to bootstrap my IPSec IKE root certificate trust. Is anyone aware of any work been done in this area? >> >> From my understanding, it looks as though the is no technical issue with using reverse DNS lookup for the IPSec target machine with DNSSec (although this may be a little unreliable on the "real-world" internet), so returning standard DANE entries for the IPSec certificate. Then I would simply use these as part of the standard IPSec certificate validation algorithm. >> >> Looking at similar proposed applications of DANE, such as the draft-ietf-dane-srv, mostly this involves defining an appropriate protocol query name (for example _ipsec.123.123.123.123.in-addr.arpa). >> >> Is this something that would fit into an existing document either from the IKE side or the DANE side? Or would it be worth me creating an more extensive proposal? We (freeswan) tried to use the reverse and failed. It's even worse now with IPv6. If you think of clients running a DNSSEC validating resolver themselves, than having a module in the DNS server that looks up IPSECKEY records in the forward, signed by DNSSEC, and then instructs the IKE daemon to setup a tunnel would require no new standards document. Just ensure you ignore the "gateway" property as it is not secure without the coupling to the reverse tree. Paul From iesg-secretary@ietf.org Mon Sep 23 14:40:29 2013 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 C37F121F898A; Mon, 23 Sep 2013 14:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNZZDYilZpnc; Mon, 23 Sep 2013 14:40:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E11AB21F8947; Mon, 23 Sep 2013 14:40:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130923214028.24520.33077.idtracker@ietfa.amsl.com> Date: Mon, 23 Sep 2013 14:40:28 -0700 Cc: ipsec@ietf.org Subject: [IPsec] IPSECME Working Group Virtual Interim Meeting, Ocotber 9, 2013 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Reply-To: iesg-secretary@ietf.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 21:40:29 -0000 The IPsecME Working Group will hold a virtual interim meeting on Wednesday, Oct. 9, 2013 via a phone bridge. The main goal of the meeting will be to advance the auto-discovery VPN solution. The time for the meeting is: 15:00 UTC 8:00 San Francisco 17:00 Berlin 18:00 Tel Aviv Duration: 1:30 hours. Agenda: - Detailed presentations of two AD VPN drafts: draft-detienne-dmvpn-00 and draft-mao-ipsecme-ad-vpn-protocol-02. - A short discussion of draft-ietf-ipsecme-esp-ah-reqts-01. Dial-in information will be posted on the mailing list: http://www.ietf.org/mail-archive/web/ipsec/current/maillist.html From kivinen@iki.fi Tue Sep 24 04:21:38 2013 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 74C9B21F97C7 for ; Tue, 24 Sep 2013 04:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-+vYdWDzH5o for ; Tue, 24 Sep 2013 04:21:38 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA0B21F9D52 for ; Tue, 24 Sep 2013 04:21:32 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r8OBLJK9007135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 24 Sep 2013 14:21:19 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r8OBLGjb016245; Tue, 24 Sep 2013 14:21:16 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21057.30123.835179.577046@fireball.kivinen.iki.fi> Date: Tue, 24 Sep 2013 14:21:15 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <523B29F4.3000406@gmail.com> References: <93C680F7-6558-4C3E-AB77-E6CA8EEAD17E@checkpoint.com> <1E275AE47A7740CB8179FDC78E02C9AC@buildpc> <44F43840-546B-4CF0-8619-E2EAC60D1A0F@checkpoint.com> <21048.19174.178525.812957@fireball.kivinen.iki.fi> <21050.58359.867144.634633@fireball.kivinen.iki.fi> <523B29F4.3000406@gmail.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 6 min Cc: ipsec@ietf.org, Valery Smyslov , Yoav Nir Subject: Re: [IPsec] Matching certificates in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 11:21:38 -0000 Yaron Sheffer writes: > I just reread the introduction of RFC 4945 and I don't understand its > purpose. So I'm not sure it should be referenced from 5996bis. Ok, if there is any disagreement about it, then I think it is better to leave it out from 5996bis. > It is definitely not a "profile" in the sense that Tero is alluding to. > Tero's own "minimal IKEv2" is a profile for a specific use. RFC 4945 > just attempts to fill in the holes (or perceived holes) in RFC 4306 and > PKIX docs wrt PKI use in IPsec. Which just happens to be the main use > case of IKE/IPsec! I have understood that RFC4945 is profile which profiles both PKIX and IPsec, i.e. tell the CA vendors what kind of features might be needed form the PKIX if certificates are used in the IPsec environment, and tell the IPsec vendors what kind of certificates it will receive from the CAs and how those can be used in the IPsec environment. > Quoting: "This profile of the IKE and PKIX frameworks is intended to > provide an agreed-upon standard for using PKI technology in the context > of IPsec by profiling the PKIX framework for use with IKE and IPsec, and > by documenting the contents of the relevant IKE payloads and further > specifying their semantics." This very clearly tells the first part (i.e. the profiling the PKIX), and bit vaguely describes the second part (i.e. "document the contents of relevant IKE payloads and further specifying their semantics" meaning that it profiles the IPsec implementations by specifying more exact contents and semantics to the payloads, when the IPsec specifications usually leave them open). It is profile in such sense that it gives common ground for PKIX and IPsec vendors so they can agree on what kind of certs can be used in IPsec. It is not the only possible way of combining PKIX and IPsec, for example if someone wants to use certificates and IPsec to protect routers, the requirements what kind of certificats and what kind of IKE payloads and their semantics might be different. -- kivinen@iki.fi From svanru@gmail.com Tue Sep 24 05:04:42 2013 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 DA3F321F9AE3 for ; Tue, 24 Sep 2013 05:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q55-R13invpG for ; Tue, 24 Sep 2013 05:04:42 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 19F2E21F9A2D for ; Tue, 24 Sep 2013 05:04:41 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id z5so3721771lbh.14 for ; Tue, 24 Sep 2013 05:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=zciRgY4etA4f1sYZ8SqQVU6yaIw2SjADyGjhqes3ya0=; b=ew5vPwqVmO7CcKYY81BRCAq5V0GjLIgt2WSrd6qgoq8DwLOgdcpJwXf+TxMFddKEmZ vIZA5FJmcW87IUaYf3lBp0kESgK+x9rNn+8GgdQmdtEAdr4cYStJt+NkwOl0NNsCDWuN iWQv3eOV/DhWl3By4OQMMendUJIoFx1BjZXWSRNPC/38QdnKqHqQhTgN6ab9VGdCbkKQ uCwNWsunHHUzp1c6i56lS3k1xNNeSmQOK3z2awzZX0vd3/rMQsf3mh6OASjfZSkhcT1f H3XTme50aQn5uxxlYXsqEYY6HfwOKkPl5tsfHwLNgYu2TJ1luKCy3vegNYSb6mtiyc4b PblA== X-Received: by 10.112.60.104 with SMTP id g8mr1956752lbr.32.1380024279562; Tue, 24 Sep 2013 05:04:39 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id e4sm15125030lba.15.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 24 Sep 2013 05:04:38 -0700 (PDT) Message-ID: <684C4ED6B0984ECD8F4BFAE8688A586B@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" , "Yaron Sheffer" References: <93C680F7-6558-4C3E-AB77-E6CA8EEAD17E@checkpoint.com><1E275AE47A7740CB8179FDC78E02C9AC@buildpc><44F43840-546B-4CF0-8619-E2EAC60D1A0F@checkpoint.com><21048.19174.178525.812957@fireball.kivinen.iki.fi><21050.58359.867144.634633@fireball.kivinen.iki.fi><523B29F4.3000406@gmail.com> <21057.30123.835179.577046@fireball.kivinen.iki.fi> Date: Tue, 24 Sep 2013 16:04:40 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] Matching certificates in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 12:04:43 -0000 >> I just reread the introduction of RFC 4945 and I don't understand its >> purpose. So I'm not sure it should be referenced from 5996bis. > > Ok, if there is any disagreement about it, then I think it is better > to leave it out from 5996bis. If we leave it out, than original Yoav's question "is there anywhere in the RFC description of how to match ID to certificates" will arise from implementers. And not all of them will be able to find RFC4945 without reference. So, what's wrong in referencing it, at least as informative reference? Regards, Valery. > kivinen@iki.fi From ynir@checkpoint.com Tue Sep 24 06:22:04 2013 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 E33E011E812B for ; Tue, 24 Sep 2013 06:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.33 X-Spam-Level: X-Spam-Status: No, score=-10.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyVwA4ioaqA5 for ; Tue, 24 Sep 2013 06:21:59 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 97D3A21F970E for ; Tue, 24 Sep 2013 06:21:51 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8ODLenQ030169; Tue, 24 Sep 2013 16:21:40 +0300 X-CheckPoint: {524191E4-8-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.92]) with mapi id 14.02.0347.000; Tue, 24 Sep 2013 16:21:40 +0300 From: Yoav Nir To: Valery Smyslov Thread-Topic: [IPsec] Matching certificates in IKEv2 Thread-Index: AQHOshnnlDcvqT4dsU6Dm3cJCfxiM5nINEKVgABFJICAAPjHXYAAOiAAgABECFmAAtTKgIAAU28AgAeBUICAAD55Sv//4yaA Date: Tue, 24 Sep 2013 13:21:40 +0000 Message-ID: <3BBAD252-9F02-4A5F-A2E3-7E6A68B8C69A@checkpoint.com> References: <93C680F7-6558-4C3E-AB77-E6CA8EEAD17E@checkpoint.com><1E275AE47A7740CB8179FDC78E02C9AC@buildpc><44F43840-546B-4CF0-8619-E2EAC60D1A0F@checkpoint.com><21048.19174.178525.812957@fireball.kivinen.iki.fi><21050.58359.867144.634633@fireball.kivinen.iki.fi><523B29F4.3000406@gmail.com> <21057.30123.835179.577046@fireball.kivinen.iki.fi> <684C4ED6B0984ECD8F4BFAE8688A586B@buildpc> In-Reply-To: <684C4ED6B0984ECD8F4BFAE8688A586B@buildpc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.19] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="iso-8859-1" Content-ID: <67C8CE8C23325B4C8E67458EC2960D26@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Tero Kivinen Subject: Re: [IPsec] Matching certificates in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 13:22:05 -0000 On Sep 24, 2013, at 3:04 PM, Valery Smyslov wrote: >>> I just reread the introduction of RFC 4945 and I don't understand its >>> purpose. So I'm not sure it should be referenced from 5996bis. >>=20 >> Ok, if there is any disagreement about it, then I think it is better >> to leave it out from 5996bis. >=20 > If we leave it out, than original Yoav's question "is there anywhere in t= he RFC > description of how to match ID to certificates" will arise from implement= ers. > And not all of them will be able to find RFC4945 without reference. > So, what's wrong in referencing it, at least as informative reference? It's really worse than just implementers asking questions. As long as there= 's no definitive profile, any implementer and often any administrator can s= tuff whatever they want in the certificate, and the other implementations h= ave to deal with it.=20 For example, my implementation by default stuffs some internal name into th= e subject common name, and an IP address of the gateway into an alternate n= ame. For interop with other gateways, we have this dialog box called "Cert= ificate Matching Criteria" for each peer gateway, where the administrator c= an specify the subject DN, the IP address (as an alternate name), or an RFC= 822 name (as an alternate name, not an RDN). And because there is no standa= rd way to map ID payloads to certificate fields, we just ignore them (and h= ave a way to configure what we send for interop). For the purposes of ADVPN we (different "we" this time) will create our own= profile, which is actually a reverse profile - we're not specifying what a= certificate should hold, but what the ID payload should hold, given an exi= sting certificate.=20 I don't think we have an answer for the general IKEv2 question, though. Yoav From paul.hoffman@vpnc.org Tue Sep 24 07:00:59 2013 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 B89D821F960A for ; Tue, 24 Sep 2013 07:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbYlcyEcOzFB for ; Tue, 24 Sep 2013 07:00:59 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 703D521F994A for ; Tue, 24 Sep 2013 07:00:57 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8OE0sP7090151 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 24 Sep 2013 07:00:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: <21057.30123.835179.577046@fireball.kivinen.iki.fi> Date: Tue, 24 Sep 2013 07:00:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4E852E0E-CCF2-4087-8122-63BCDD5E74B7@vpnc.org> References: <93C680F7-6558-4C3E-AB77-E6CA8EEAD17E@checkpoint.com> <1E275AE47A7740CB8179FDC78E02C9AC@buildpc> <44F43840-546B-4CF0-8619-E2EAC60D1A0F@checkpoint.com> <21048.19174.178525.812957@fireball.kivinen.iki.fi> <21050.58359.867144.634633@fireball.kivinen.iki.fi> <523B29F4.3000406@gmail.com> <21057.30123.835179.577046@fireball.kivinen.iki.fi> To: ipsec@ietf.org X-Mailer: Apple Mail (2.1510) Subject: Re: [IPsec] Matching certificates in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 14:00:59 -0000 On Sep 24, 2013, at 4:21 AM, Tero Kivinen wrote: > Yaron Sheffer writes: >> I just reread the introduction of RFC 4945 and I don't understand its=20= >> purpose. So I'm not sure it should be referenced from 5996bis. >=20 > Ok, if there is any disagreement about it, then I think it is better > to leave it out from 5996bis.=20 Please do not. It is flawed, but it is the best we have. If you leave it = out, then you will have to reproduce all the valuable matching bits in = 5996bis. That's possible, but likely more work than you expect. >> It is definitely not a "profile" in the sense that Tero is alluding = to.=20 >> Tero's own "minimal IKEv2" is a profile for a specific use. RFC 4945=20= >> just attempts to fill in the holes (or perceived holes) in RFC 4306 = and=20 >> PKIX docs wrt PKI use in IPsec. Which just happens to be the main use=20= >> case of IKE/IPsec! >=20 > I have understood that RFC4945 is profile which profiles both PKIX and > IPsec, i.e. tell the CA vendors what kind of features might be needed > form the PKIX if certificates are used in the IPsec environment, and > tell the IPsec vendors what kind of certificates it will receive from > the CAs and how those can be used in the IPsec environment. Tero's description of what was intended is exactly right. Whether or not = we achieved that goal is a different matter. > It is not the only possible way of combining PKIX and IPsec, for > example if someone wants to use certificates and IPsec to protect > routers, the requirements what kind of certificats and what kind of > IKE payloads and their semantics might be different. ...and therefore cause lack of interop. --Paul Hoffman From yaronf.ietf@gmail.com Tue Sep 24 11:13:03 2013 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 DB75611E80E4 for ; Tue, 24 Sep 2013 11:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmH5fQotH0X8 for ; Tue, 24 Sep 2013 11:13:03 -0700 (PDT) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id C75B211E80E0 for ; Tue, 24 Sep 2013 11:13:02 -0700 (PDT) Received: by mail-ee0-f51.google.com with SMTP id c1so2630133eek.24 for ; Tue, 24 Sep 2013 11:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=xbNM+Qsa27yBBPbNadF5ogkgK/0gAVoyTu83eUZiue0=; b=sn8VKQ+CLGQTjYmphO9Pne9TEXKsdaMMqoNckgHljGYowyJvgYrJrrfkmRnwJimaWz fXsiTsFL7tbEOLug04L4xkF4CIpOfq9O7xrQP0l40b9peQuIO3BecmSBk7Yq5n5ZBXiz pvyAMUJ6IMOcpr+loUGMT1VhLF0fVmaTRqcZ+/MA3mLqD3tieZSB+5qGI1OVZ2TzclBg M7wGppl+G+VkMXTfm6Rq2vOOgAgh343bfkBO45h+XZBLFWVjPHBRvIHX/g5mC1DjMFav etNWfawbE/12hPTCKWSDhHkaJk2XHAcd9QzTV/Hqh5Vw0re1JERY/dUia7tRsx5d8sCS F91w== X-Received: by 10.14.88.65 with SMTP id z41mr47726738eee.38.1380046380783; Tue, 24 Sep 2013 11:13:00 -0700 (PDT) Received: from [10.0.0.8] ([109.64.175.213]) by mx.google.com with ESMTPSA id z12sm55956464eev.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Sep 2013 11:13:00 -0700 (PDT) Message-ID: <5241D62B.1020607@gmail.com> Date: Tue, 24 Sep 2013 21:12:59 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Paul Hoffman , ipsec@ietf.org References: <93C680F7-6558-4C3E-AB77-E6CA8EEAD17E@checkpoint.com> <1E275AE47A7740CB8179FDC78E02C9AC@buildpc> <44F43840-546B-4CF0-8619-E2EAC60D1A0F@checkpoint.com> <21048.19174.178525.812957@fireball.kivinen.iki.fi> <21050.58359.867144.634633@fireball.kivinen.iki.fi> <523B29F4.3000406@gmail.com> <21057.30123.835179.577046@fireball.kivinen.iki.fi> <4E852E0E-CCF2-4087-8122-63BCDD5E74B7@vpnc.org> In-Reply-To: <4E852E0E-CCF2-4087-8122-63BCDD5E74B7@vpnc.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] Matching certificates in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 18:13:04 -0000 I'll defer to Paul on this one. Thanks, Yaron On 09/24/2013 05:00 PM, Paul Hoffman wrote: > > > On Sep 24, 2013, at 4:21 AM, Tero Kivinen wrote: > >> Yaron Sheffer writes: >>> I just reread the introduction of RFC 4945 and I don't understand its >>> purpose. So I'm not sure it should be referenced from 5996bis. >> >> Ok, if there is any disagreement about it, then I think it is better >> to leave it out from 5996bis. > > Please do not. It is flawed, but it is the best we have. If you leave it out, then you will have to reproduce all the valuable matching bits in 5996bis. That's possible, but likely more work than you expect. > From ynir@checkpoint.com Tue Sep 24 11:48:01 2013 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 D3F0421F9C8B for ; Tue, 24 Sep 2013 11:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.338 X-Spam-Level: X-Spam-Status: No, score=-10.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGAld3+avhnS for ; Tue, 24 Sep 2013 11:47:56 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B59DC11E813A for ; Tue, 24 Sep 2013 11:47:34 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8OIlK5N031907; Tue, 24 Sep 2013 21:47:20 +0300 X-CheckPoint: {5241DE38-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.92]) with mapi id 14.02.0347.000; Tue, 24 Sep 2013 21:47:20 +0300 From: Yoav Nir To: Yaron Sheffer Thread-Topic: [IPsec] Matching certificates in IKEv2 Thread-Index: AQHOshnnlDcvqT4dsU6Dm3cJCfxiM5nINEKVgABFJICAAPjHXYAAOiAAgABECFmAAtTKgIAAU28AgAeBUICAACycgIAARm2AgAAJnYA= Date: Tue, 24 Sep 2013 18:47:20 +0000 Message-ID: <64D1B1CF-AB65-4345-A292-65DE9B24C179@checkpoint.com> References: <93C680F7-6558-4C3E-AB77-E6CA8EEAD17E@checkpoint.com> <1E275AE47A7740CB8179FDC78E02C9AC@buildpc> <44F43840-546B-4CF0-8619-E2EAC60D1A0F@checkpoint.com> <21048.19174.178525.812957@fireball.kivinen.iki.fi> <21050.58359.867144.634633@fireball.kivinen.iki.fi> <523B29F4.3000406@gmail.com> <21057.30123.835179.577046@fireball.kivinen.iki.fi> <4E852E0E-CCF2-4087-8122-63BCDD5E74B7@vpnc.org> <5241D62B.1020607@gmail.com> In-Reply-To: <5241D62B.1020607@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.243] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Paul Hoffman Subject: Re: [IPsec] Matching certificates in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 18:48:02 -0000 Still might be worth a document proposing some profile, even if it does not= match current practice. On Sep 24, 2013, at 9:12 PM, Yaron Sheffer wrote: > I'll defer to Paul on this one. >=20 > Thanks, > Yaron >=20 > On 09/24/2013 05:00 PM, Paul Hoffman wrote: >> >>=20 >> On Sep 24, 2013, at 4:21 AM, Tero Kivinen wrote: >>=20 >>> Yaron Sheffer writes: >>>> I just reread the introduction of RFC 4945 and I don't understand its >>>> purpose. So I'm not sure it should be referenced from 5996bis. >>>=20 >>> Ok, if there is any disagreement about it, then I think it is better >>> to leave it out from 5996bis. >>=20 >> Please do not. It is flawed, but it is the best we have. If you leave it= out, then you will have to reproduce all the valuable matching bits in 599= 6bis. That's possible, but likely more work than you expect. >>=20 From paul.hoffman@vpnc.org Sun Sep 29 10:45:25 2013 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 1195C11E8132 for ; Sun, 29 Sep 2013 10:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eemdrowdrhH for ; Sun, 29 Sep 2013 10:45:24 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 99C2211E8112 for ; Sun, 29 Sep 2013 10:45:24 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8THjLqp023258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 29 Sep 2013 10:45:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7DFD0F23-26A3-41CD-B842-B33E07A1148A@vpnc.org> Date: Sun, 29 Sep 2013 10:45:21 -0700 To: "ipsec@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [IPsec] Reviewing the AD VPN drafts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2013 17:45:25 -0000 Greetings again. As we announced, we will be having a virtual interim meeting next = Wednesday, October 9. The agenda is: - Detailed presentations of two AD VPN drafts: draft-detienne-dmvpn-00 = and draft-mao-ipsecme-ad-vpn-protocol-02. [This is the main focus of the = meeting.] - A short discussion of draft-ietf-ipsecme-esp-ah-reqts-01. To ensure an effective discussion, we request WG members to have a quick = review of the two AD VPN drafts. We suggest that you don't review any of = them in detail, instead just consider whether the proposed approach = seems to be technically sound and in line with the AD VPN requirements. = Please send a short email to the list regarding one of the drafts (or, = preferably one email about each) by Wednesday of this week, so we can = start a discussion on the mailing list that will help the discussion at = the virtual interim meeting. Thanks, Paul and Yaron From david.lloyd@fsmail.net Sun Sep 29 13:23:18 2013 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 6ABA021E80BC for ; Sun, 29 Sep 2013 13:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_50=0.001, SARE_FREE_WEBM_NetFs=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2Hx5OpB7Wak for ; Sun, 29 Sep 2013 13:23:13 -0700 (PDT) Received: from smtpout.wanadoo.co.uk (smtpout4.wanadoo.co.uk [80.12.242.68]) by ietfa.amsl.com (Postfix) with ESMTP id 987DE21E80B4 for ; Sun, 29 Sep 2013 13:23:11 -0700 (PDT) Received: from wwinf3715 ([10.232.27.59]) by mwinf5d59 with ME id X8P81m00t1GX7wy038P8Fk; Sun, 29 Sep 2013 22:23:08 +0200 Date: Sun, 29 Sep 2013 22:23:08 +0200 From: david.lloyd@fsmail.net To: ipsec@ietf.org, dane@ietf.org Message-ID: <7039763.53681380486188849.JavaMail.www@wwinf3715> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [86.26.3.116] X-Wum-Nature: EMAIL-NATURE X-WUM-FROM: |~| X-WUM-TO: |~||~| X-WUM-REPLYTO: |~| Subject: [IPsec] Bootstrapping IPSec from DNSSSEC/DANE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: david.lloyd@fsmail.net List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2013 20:23:18 -0000 Hi, Thanks for the various responses. I have also been asked for a little clarification on what I am trying to achieve, so I'll give a quick overview. There's not much to it... Basically, we have three independent groups who have certificate-based IPSec (on IPv6), and now they'd like occasionally to connect to each other. The obvious solution is to cross-sign certificates, but we have also recently implemented DNSSEC, so I was wondering if there was a better/another way. Or maybe: I have a shiny new hammer called DNSSEC, and a lot of things are starting to look like nails. In terms of getting IPSec based off DNSSEC, the two RFCs 4025 and 4322 actually do pretty much what I want (plus or minus that it'll look very different to the way I am configuring TLS DANE). I am going to see if I can get those to work. For the other things that were talked about: Mobile devices and NATs - It is true that reverse lookup is inappropriate for these scenarios, but ultimately this is just a rejig of the problem that the incoming ipaddress is not particularly useful in these scenarios. If a server wishes to verify such connecting clients, it'll have to choose something else as an identifier (and thus it falls back into the traditional CA/Kerebros setup) Reverse DNS being poorly supported by iSPs - To be honest, this is less of a problem for me as I only have an internal deployment, so I can do what I like (in-addr.arpa is ultimately just a convention, anyone could run a reverse DNS system that actually works properly). Most of my ip addresses are not routable from the public internet anyway. It did lead me to the somewhat more philosophical question of what it means to "own" an ipaddress if I can't associate my public keys with a secure central registry... So I think that the answer is that I can do this with existing technology, with some basic restrictions in that I'll need to be running my own reverse DNS lookup for my deployment - which seems entirely sensible as I want to have control over which ip addresses "exist" in my environment. Thanks! DDD From paul@cypherpunks.ca Mon Sep 30 07:52:25 2013 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 F13EB21F9C33; Mon, 30 Sep 2013 07:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJln6KUnqpqc; Mon, 30 Sep 2013 07:52:19 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id B7F7621F9AF0; Mon, 30 Sep 2013 07:52:18 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cpRQp2r58z9Mv; Mon, 30 Sep 2013 10:52:02 -0400 (EDT) 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 V4tdxpOL2kMY; Mon, 30 Sep 2013 10:52:01 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Mon, 30 Sep 2013 10:52:00 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 8EF0E805F2; Mon, 30 Sep 2013 10:51:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 86594805F1; Mon, 30 Sep 2013 10:51:59 -0400 (EDT) Date: Mon, 30 Sep 2013 10:51:59 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: david.lloyd@fsmail.net In-Reply-To: <7039763.53681380486188849.JavaMail.www@wwinf3715> Message-ID: References: <7039763.53681380486188849.JavaMail.www@wwinf3715> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ipsec@ietf.org WG" , dane WG list Subject: Re: [IPsec] Bootstrapping IPSec from DNSSSEC/DANE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 14:52:25 -0000 On Sun, 29 Sep 2013, david.lloyd@fsmail.net wrote: > Thanks for the various responses. I have also been asked for a little clarification on what I am trying to achieve, so I'll give a quick overview. > > There's not much to it... Basically, we have three independent groups who have certificate-based IPSec (on IPv6), and now they'd like occasionally to connect to each other. The obvious solution is to cross-sign certificates, but we have also recently implemented DNSSEC, so I was wondering if there was a better/another way. Or maybe: I have a shiny new hammer called DNSSEC, and a lot of things are starting to look like nails. > > In terms of getting IPSec based off DNSSEC, the two RFCs 4025 and 4322 actually do pretty much what I want (plus or minus that it'll look very different to the way I am configuring TLS DANE). I am going to see if I can get those to work. We have been working on re-doing IPsec OE (which can use DANE/DNSSEC) using IKEv2. We will be writing up our findings in a new draft and implement this in libreswan. The core functionality is not hard. The problem is in cornercases and trying not to get stuck in too many of them like the BTNS work did. > For the other things that were talked about: > > Mobile devices and NATs - It is true that reverse lookup is inappropriate for these scenarios, but ultimately this is just a rejig of the problem that the incoming ipaddress is not particularly useful in these scenarios. If a server wishes to verify such connecting clients, it'll have to choose something else as an identifier (and thus it falls back into the traditional CA/Kerebros setup) Forget the reverse. You either use the forward lookup with DNSSEC using a locally running DNSSEC resolver or you if you don't find anything, you try an anonymous (MITMable) IPsec directly. > > So I think that the answer is that I can do this with existing technology, with some basic restrictions in that I'll need to be running my own reverse DNS lookup for my deployment - which seems entirely sensible as I want to have control over which ip addresses "exist" in my environment. Yes. the problems are mostly in the local implementation. How to deal with NAT and overlapping IP addresses. How to ensure there is no malicious NAT-T pre-NAT IP attempts at traffic stealing (eg 8.8.8.8) How (or if) to present the difference of "anonymous IPsec" versus "one or two sided authenticated IPsec" to the user. What to do when the roles of initiator/responder change and the connection was only authenticated by the original initiator. I hope to have a rough draft and implementation ready in Vancouver, Paul