From kent@bbn.com Mon Dec 2 06:46:37 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDF31A8028 for ; Mon, 2 Dec 2013 06:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BywcXvif_iWO for ; Mon, 2 Dec 2013 06:46:35 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id DDBE11AE068 for ; Mon, 2 Dec 2013 06:46:30 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:47462 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VnUlY-000OmL-Bk for ipsec@ietf.org; Mon, 02 Dec 2013 09:46:28 -0500 Message-ID: <529C9D43.9010107@bbn.com> Date: Mon, 02 Dec 2013 09:46:27 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: ipsec Content-Type: multipart/alternative; boundary="------------050203030604080308080605" Subject: [IPsec] 4301 questionnaire X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 14:46:37 -0000 This is a multi-part message in MIME format. --------------050203030604080308080605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit For progress to Internet Standard, we need to verify the status of implementations relative to the RFCs. Rather than Going through an exhaustive list of MUST and SHOULD compliance, let's start with a simpler list, suggested by Sean. I request that each implementer complete the following form: *- Which of following databases does your implementation support: - SPD (Security Policy Database) - SAD (Security Association Database) - PAD (Peer Authorization Database) - Which of the processing semantics does your implementation support: - IP Traffic: - ICMP: - Fragment: - Path MTU/DF The following questions document whether interoperability has been achieved as well as other intangibles the IESG will be interested: - What evidence do you have that your implementation can interoperate with other implementations?** ** ** - In your opinion, are there unused features in the RFC that greatly increase implementation complexity?** ** ** - Errata was filed against RFC 4301 and has been incorporated in**https://datatracker.ietf.org/doc/draft-kent-ipsecme-saforip-rfc4301bis/**; are any of the incorporated errata problematic for your implementation?** ** **- Does your implementation support the updates documented in RFC 6401? Additional information (optional):* Thanks, Steve --------------050203030604080308080605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit For progress to Internet Standard, we need to verify the status of implementations
relative to the RFCs.  Rather than Going through an exhaustive list of MUST and
SHOULD compliance, let's start with a simpler list, suggested by Sean.

I request that each implementer complete the following form:
 
- Which of following databases does your implementation support:
	- SPD (Security Policy Database)
	- SAD (Security Association Database)
	- PAD (Peer Authorization Database)
- Which of the processing semantics does your implementation support:
	- IP Traffic:
	- ICMP:
	- Fragment:
	- Path MTU/DF

The following questions document whether interoperability has been achieved as well as other intangibles the IESG will be interested:

- What evidence do you have that your implementation can interoperate with other implementations?

 - In your opinion, are there unused features in the RFC that greatly increase implementation complexity?

 - Errata was filed against RFC 4301 and has been incorporated in https://datatracker.ietf.org/doc/draft-kent-ipsecme-saforip-rfc4301bis/; are any of the incorporated errata problematic for your implementation?

- Does your implementation support the updates documented in RFC 6401?

Additional information (optional):

Thanks,

Steve
--------------050203030604080308080605-- From kent@bbn.com Mon Dec 2 06:47:44 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63FDD1AE434 for ; Mon, 2 Dec 2013 06:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bR5zzjAfbK_W for ; Mon, 2 Dec 2013 06:47:43 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id E4BC61AE474 for ; Mon, 2 Dec 2013 06:47:42 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:47465 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VnUmi-000On7-FF for ipsec@ietf.org; Mon, 02 Dec 2013 09:47:40 -0500 Message-ID: <529C9D8C.50503@bbn.com> Date: Mon, 02 Dec 2013 09:47:40 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: ipsec Content-Type: multipart/alternative; boundary="------------030106050306070008050102" Subject: [IPsec] progressing 4303 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 14:47:44 -0000 This is a multi-part message in MIME format. --------------030106050306070008050102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Same drill for 4303: *The following questions document whether the syntax and semantics of the protocol were implemented: - Which of the following ESP packet formats does your implementation support: - separate encryption and integrity algorithms: - combined mode algorithms: - Which processing semantics does your implementation support: - Transport Mode: - Tunnel Mode: - Auditing: The following questions document whether interoperability has been achieved as well as other intangibles the IESG will be interested: - What evidence do you have that your implementation can interoperate with other implementations? - In your opinion, are there unused features in the RFC that greatly increase implementation complexity? - Errata was filed against RFC 4303 and has been included in**https://datatracker.ietf.org/doc/draft-kent-ipsecme-esp-rfc4303bis/**; are any of the incorporated errata problematic for your implementation? Additional information (optional):* --------------030106050306070008050102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Same drill for 4303:

The following questions document whether the syntax and semantics of the protocol were implemented:

- Which of the following ESP packet formats does your implementation support:
	- separate encryption and integrity algorithms:
	- combined mode algorithms:
- Which processing semantics does your implementation support:
	- Transport Mode:
	- Tunnel Mode:
	- Auditing:

The following questions document whether interoperability has been achieved as well as other intangibles the IESG will be interested:

- What evidence do you have that your implementation can interoperate with other implementations?

- In your opinion, are there unused features in the RFC that greatly increase implementation complexity?

- Errata was filed against RFC 4303 and has been included in https://datatracker.ietf.org/doc/draft-kent-ipsecme-esp-rfc4303bis/; are any of the incorporated errata problematic for your implementation?

Additional information (optional):

--------------030106050306070008050102-- From paul.hoffman@vpnc.org Mon Dec 2 06:48:15 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBEA1AE49E for ; Mon, 2 Dec 2013 06:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3vWMnbCu5PS for ; Mon, 2 Dec 2013 06:48:14 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C9D4F1AE49B for ; Mon, 2 Dec 2013 06:48:13 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rB2EmANI053502 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 2 Dec 2013 07:48:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Dec 2013 06:48:11 -0800 References: <20131202125348.16990.76682.idtracker@ietfa.amsl.com> To: ipsec@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) Subject: [IPsec] Fwd: Last Call: (Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 14:48:15 -0000 This IETF-wide last call should be of definite interest to many = developers in this WG. Please send any review comments to the addresses = below, not to the IPsecME WG mailing list. --Paul Hoffman Begin forwarded message: > From: The IESG > Subject: Last Call: (Virtual = Private Network (VPN) traffic leakages in dual-stack hosts/ networks) to = Informational RFC > Date: December 2, 2013 at 4:53:48 AM PST > To: IETF-Announce > Cc: opsec@ietf.org > Reply-To: ietf@ietf.org >=20 >=20 > The IESG has received a request from the Operational Security > Capabilities for IP Network Infrastructure WG (opsec) to consider the > following document: > - 'Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ > networks' > as Informational RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-12-16. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > The subtle way in which the IPv6 and IPv4 protocols co-exist in > typical networks, together with the lack of proper IPv6 support in > popular Virtual Private Network (VPN) products, may inadvertently > result in VPN traffic leaks. That is, traffic meant to be > transferred over a VPN connection may leak out of such connection and > be transferred in the clear from the local network to the final > destination. This document discusses some scenarios in which such > VPN leakages may occur, either as a side effect of enabling IPv6 on a > local network, or as a result of a deliberate attack from a local > attacker. Additionally, it discusses possible mitigations for the > aforementioned issue. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 From kent@bbn.com Tue Dec 3 07:47:55 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F72F1AE13A for ; Tue, 3 Dec 2013 07:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bctlXvDrKXye for ; Tue, 3 Dec 2013 07:47:52 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D5FCE1AE12A for ; Tue, 3 Dec 2013 07:47:52 -0800 (PST) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49830) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VnsCT-0009VY-Hs for ipsec@ietf.org; Tue, 03 Dec 2013 10:47:49 -0500 Message-ID: <529DFD25.2030704@bbn.com> Date: Tue, 03 Dec 2013 10:47:49 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: ipsec Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] I forgot to mention X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:47:55 -0000 Responses to the 4301 and 4303 questions should be posted to the list. Steve From kent@bbn.com Tue Dec 3 07:52:14 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2EE1AE08C for ; Tue, 3 Dec 2013 07:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7B4Kzrbhrth for ; Tue, 3 Dec 2013 07:52:12 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B40AD1AE05B for ; Tue, 3 Dec 2013 07:52:12 -0800 (PST) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49854) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VnsGf-0009al-V1 for ipsec@ietf.org; Tue, 03 Dec 2013 10:52:10 -0500 Message-ID: <529DFE29.7060403@bbn.com> Date: Tue, 03 Dec 2013 10:52:09 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: ipsec References: <529C9D43.9010107@bbn.com> <529CBE8A.7060504@gmail.com> In-Reply-To: <529CBE8A.7060504@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] another 4301 questionnaire whoops X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:52:14 -0000 Yaron pointed out that the reference to RFC 6401 was in error. The relevant RFC is 6040 (Tunneling of Explicit Congestion Notification). Sorry 'bout that, Steve From TurnerS@ieca.com Tue Dec 3 09:34:09 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281021A1F4E for ; Tue, 3 Dec 2013 09:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.167 X-Spam-Level: X-Spam-Status: No, score=-0.167 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZR6VWEOuNAZI for ; Tue, 3 Dec 2013 09:34:08 -0800 (PST) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [67.18.80.19]) by ietfa.amsl.com (Postfix) with ESMTP id EC29B1AD939 for ; Tue, 3 Dec 2013 09:34:07 -0800 (PST) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 09121B41F3615; Tue, 3 Dec 2013 11:34:05 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway01.websitewelcome.com (Postfix) with ESMTP id B9E20B41F34B9 for ; Tue, 3 Dec 2013 11:34:04 -0600 (CST) Received: from [198.180.150.142] (port=50412 helo=v142.vpn.iad.rg.net) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1VntrG-0006fN-PK for ipsec@ietf.org; Tue, 03 Dec 2013 11:34:03 -0600 From: Sean Turner Content-Type: multipart/signed; boundary="Apple-Mail=_B924512E-9B23-4FF0-918E-DCE8AF6D8AD3"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <33B8DC07-B651-4937-9EE7-845AB0B6509E@ieca.com> Date: Tue, 3 Dec 2013 17:33:58 +0000 To: IPsecme WG Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 198.180.150.142 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (v142.vpn.iad.rg.net) [198.180.150.142]:50412 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Subject: [IPsec] 3948 Questionnaire X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 17:34:09 -0000 --Apple-Mail=_B924512E-9B23-4FF0-918E-DCE8AF6D8AD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Here=92s a proposed set of question for RFC 3948 implementers: The following questions document whether your implementation supports = the syntax and semantics of the protocol: - Which of the following packet formats does your implementation = support: - UDP-Encapsulated ESP Header Format (y/n): - IKE Header Format for Port 4500 (y/n): - NAT-Keepalive Packet Format (y/n): - Which of the following encapsulation and decapsulation processing = rules does your implementation support: - Auxiliary Processing - Tunnel Mode Decapsulation NAT Procedure (y/n): - Transport Mode Decapsulation NAT Procedure (y/n): - Transport Mode ESP Encapsulation (y/n): - Transport Mode ESP Decapsulation (y/n): - Tunnel Mode ESP Encapsulation (y/n): - Tunnel Mode ESP Decapsulation (y/n): - Does your implementation support the NAT keepalive procedure? (y/n): The following questions document whether interoperability has been = achieved as well as other intangibles the IESG will be interested. - What evidence do you have that your implementation can interoperate = with other implementations? - In your opinion, are there unused features in the RFC that greatly = increase implementation complexity? Additional information (optional): spt= --Apple-Mail=_B924512E-9B23-4FF0-918E-DCE8AF6D8AD3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEgDCCBHww ggJkoAMCAQICCQCdWMxKNutUeTANBgkqhkiG9w0BAQsFADAiMQswCQYDVQQGEwJVUzETMBEGA1UE ChMKSUVDQSwgSW5jLjAeFw0xMzA0MDMxNDUxMThaFw0xNDA0MDMxNDUxMThaMDgxCzAJBgNVBAYT AlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuMRQwEgYDVQQDEwtTZWFuIFR1cm5lcjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOpCGCRptT1m+bIpLTmbahZLZ0Qe4X99f8SgTQ7QISvUfpmn tfOD1oA1AttXlOULEERYubzvDnUTXvstFomQx0XTA67IaV+mw9ODRtG1hPN/erdKX6sU6rH4tsEb ba3Drr/I0HT3YVvD3SjWtGXjF12XLvTP6+LfMIIDTCAPiEd9KPG23D7skVu/4BvvmdLFI96OARhg wQ86M+lTIn83KRJlbbfAeIevbRx/rUB7D+uvMdWxOzR0KZJhd6dEeTXVwBXZG4rnQ4uFM+mRSiD4 rxDCyOuIuOzR07tnOyCRio6sRipOZvwQUWttdsgMEs6IxLdWsaTXcs1HjCsxrdedovMCAwEAAaOB njCBmzAOBgNVHQ8BAf8EBAMCBeAwHwYDVR0jBBgwFoAUAHRsSeXJUmFxTVY4q2HJ8uHl+w0wGwYD VR0RBBQwEoEQVHVybmVyU0BpZWNhLmNvbTAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vd3d3Lmll Y2EuY29tL2NybHMvaWVjYS5jcmwwFwYDVR0gBBAwDjAMBgorBgEEAYHXAAAAMA0GCSqGSIb3DQEB CwUAA4ICAQAimDYm77ppTi4vK6qJSUhyvCDMGb8mngiEXEYKxsfdHPWoDO7+06j7dAZ8sDD9/FtE kiUMyoNGSUmKHR+tGperVnNiM/Zk6WwCJv8dYZwhGXNQeEGzeys/UkFv7CFX7uDSn8GQeB8sOAZ1 N1hxV/TvT8qXvcRxP5+aWTAGAq3TKtCQxZjuU74L3st2hZiOhJlhjhqz0K5FIwWzXUK9uwhZe1th GUpDbRustVgmKN2Xa0pzwqI1VUO0jnWt24A4u59xo6DJQXzQVMhCx0xhpemuT9BrsBDTX8eJdI1i Wv9wp3ivSrfHjKXp8y8OGD+usiG40HCjj0W9C+dH0VfbgrB6QOI4vA9+kTg4mANth1cxyxwPYOSJ v0zi1qR0eDIGI//2v2/s6TmGuNqbnRa26Ldv5gGqS7xj32Fiaby6UOXs4+aAIWGZEOH+BXjozcvE eGBwjU/VRQYu6itR28PaNhNVji4D5ITaGxWWiycqK1EUaFraWHtk7W100ROX69xTeFVZP86D2ymi /aohl5Vb1vlYHdqlbgqjDRl9dPbTxVCXEHf+jkexcuwlLTvr7F+5DIN6c/EbCpRqQx3edy193L48 OGyRDh1/Wmzpew0VWWAWOSXGl/P9VzXf3Z6GPt7flN/V9iEJAa3Mo+w+eIdzJkHBWR+yJcqQcCRM MSyishMwLDGCAjgwggI0AgEBMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTAJBgUrDgMCGgUAoIHfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEzMTIwMzE3MzM1OVowIwYJKoZIhvcNAQkEMRYEFEEI/FFkB8lxU1nNyv9Smu30 sY8tMD4GCSsGAQQBgjcQBDExMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTBABgsqhkiG9w0BCRACCzExoC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklF Q0EsIEluYy4CCQCdWMxKNutUeTANBgkqhkiG9w0BAQEFAASCAQC//Kdo6+3baNysQmesY7gkK+wQ gFAD0NQKLoXnzvVdayS8Px45JgbXsn9XSlyPk1yCGb8u7WJp4QMUQ+nZT8twesyvqbFZVFdxW0lJ B4LNIzqwjZPYQc5rurRYBSLlPax4KNnXUhYBy1l+4D/1MKB2xUL9dADQ6f+sayyY2K9cmrZKdJu3 dembLhVlfjySYhmX+9/JUz1or4KnqRn36Jdih/BYXhGF9ToIF9/mp4/Gs9REqMdcYOM1sbpP1hQf 8SnfsrwthSSOKqPffErtNx19xoG1vrnN5/YHKP9ZrJwZMXEGjdnDgVxGd82114ROYa9kel5MV2NT lTGYO/XLAOMzAAAAAAAA --Apple-Mail=_B924512E-9B23-4FF0-918E-DCE8AF6D8AD3-- From TurnerS@ieca.com Tue Dec 3 09:34:12 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC3B1AE0F8 for ; Tue, 3 Dec 2013 09:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.332 X-Spam-Level: X-Spam-Status: No, score=0.332 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imt7SpNzL-O6 for ; Tue, 3 Dec 2013 09:34:10 -0800 (PST) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [67.18.82.10]) by ietfa.amsl.com (Postfix) with ESMTP id C24B71A1F4E for ; Tue, 3 Dec 2013 09:34:10 -0800 (PST) Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id 7AFB01D3D3D20; Tue, 3 Dec 2013 11:34:08 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway15.websitewelcome.com (Postfix) with ESMTP id 5757D1D3D3C7F for ; Tue, 3 Dec 2013 11:34:08 -0600 (CST) Received: from [198.180.150.142] (port=50412 helo=v142.vpn.iad.rg.net) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1VntrL-0006fN-0a for ipsec@ietf.org; Tue, 03 Dec 2013 11:34:07 -0600 From: Sean Turner Content-Type: multipart/signed; boundary="Apple-Mail=_3742813A-A946-44CC-9840-FA385E85F65B"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: Date: Tue, 3 Dec 2013 17:34:02 +0000 To: IPsecme WG Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 198.180.150.142 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (v142.vpn.iad.rg.net) [198.180.150.142]:50412 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 7 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Subject: [IPsec] 5996 Questionnaire X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 17:34:12 -0000 --Apple-Mail=_3742813A-A946-44CC-9840-FA385E85F65B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 After some edits from Tero, here=92s a proposed set of question for RFC = 5996 implementers: - Which of the IKEv2 exchanges you support: - IKE_SA_INIT (includes support for SA, KE, Ni, Nr payloads) - IKE_AUTH (includes support for SK, IDi, IDr, AUTH, TSi, TSr payloads) - CREATE_CHILD_SA - INFORMATIONAL - Which of the IKEv2 payloads your implementation supports - CERT Certificate - CERTREQ Certificate Request - CP Configuration - D Delete - EAP Extensible Authentication - N Notify - V Vendor ID - Which of the following processing semantics does your implementation = support (y/n): - Can your implementation create a new child SAs with the = CREATE_CHILD_SA exchange?: - Can your implementation rekey an IKE SAs with the = CREATE_CHILD_SA Exchange?: - Can your implementation rekey a Child SAs with the = CREATE_CHILD_SA Exchange?: - Does your implementation support the INFORMATIONAL exchange? - Which of the IKEv2 authentication methods you support - PKIX Certificates as specified in section 4 - Shared key authentication as specified in section 4 - Mixed authentication, where responder uses Certificates and initiator uses shared key -- Which of the usage scenarios does your implementation support = (s1.1.1, s1.1.2, and s1.1.3): - What evidence do you have that your implementation can interoperate = with other implementations? - In your opinion, are there unused features in the RFC that greatly = increase implementation complexity? - Errata was filed against RFC 5996 and has been included in = https://datatracker.ietf.org/doc/draft-kivinen-ipsecme-ikev2-rfc5996bis/; = are any of the incorporated errata problematic for your implementation? Additional information (optional): spt= --Apple-Mail=_3742813A-A946-44CC-9840-FA385E85F65B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEgDCCBHww ggJkoAMCAQICCQCdWMxKNutUeTANBgkqhkiG9w0BAQsFADAiMQswCQYDVQQGEwJVUzETMBEGA1UE ChMKSUVDQSwgSW5jLjAeFw0xMzA0MDMxNDUxMThaFw0xNDA0MDMxNDUxMThaMDgxCzAJBgNVBAYT AlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuMRQwEgYDVQQDEwtTZWFuIFR1cm5lcjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOpCGCRptT1m+bIpLTmbahZLZ0Qe4X99f8SgTQ7QISvUfpmn tfOD1oA1AttXlOULEERYubzvDnUTXvstFomQx0XTA67IaV+mw9ODRtG1hPN/erdKX6sU6rH4tsEb ba3Drr/I0HT3YVvD3SjWtGXjF12XLvTP6+LfMIIDTCAPiEd9KPG23D7skVu/4BvvmdLFI96OARhg wQ86M+lTIn83KRJlbbfAeIevbRx/rUB7D+uvMdWxOzR0KZJhd6dEeTXVwBXZG4rnQ4uFM+mRSiD4 rxDCyOuIuOzR07tnOyCRio6sRipOZvwQUWttdsgMEs6IxLdWsaTXcs1HjCsxrdedovMCAwEAAaOB njCBmzAOBgNVHQ8BAf8EBAMCBeAwHwYDVR0jBBgwFoAUAHRsSeXJUmFxTVY4q2HJ8uHl+w0wGwYD VR0RBBQwEoEQVHVybmVyU0BpZWNhLmNvbTAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vd3d3Lmll Y2EuY29tL2NybHMvaWVjYS5jcmwwFwYDVR0gBBAwDjAMBgorBgEEAYHXAAAAMA0GCSqGSIb3DQEB CwUAA4ICAQAimDYm77ppTi4vK6qJSUhyvCDMGb8mngiEXEYKxsfdHPWoDO7+06j7dAZ8sDD9/FtE kiUMyoNGSUmKHR+tGperVnNiM/Zk6WwCJv8dYZwhGXNQeEGzeys/UkFv7CFX7uDSn8GQeB8sOAZ1 N1hxV/TvT8qXvcRxP5+aWTAGAq3TKtCQxZjuU74L3st2hZiOhJlhjhqz0K5FIwWzXUK9uwhZe1th GUpDbRustVgmKN2Xa0pzwqI1VUO0jnWt24A4u59xo6DJQXzQVMhCx0xhpemuT9BrsBDTX8eJdI1i Wv9wp3ivSrfHjKXp8y8OGD+usiG40HCjj0W9C+dH0VfbgrB6QOI4vA9+kTg4mANth1cxyxwPYOSJ v0zi1qR0eDIGI//2v2/s6TmGuNqbnRa26Ldv5gGqS7xj32Fiaby6UOXs4+aAIWGZEOH+BXjozcvE eGBwjU/VRQYu6itR28PaNhNVji4D5ITaGxWWiycqK1EUaFraWHtk7W100ROX69xTeFVZP86D2ymi /aohl5Vb1vlYHdqlbgqjDRl9dPbTxVCXEHf+jkexcuwlLTvr7F+5DIN6c/EbCpRqQx3edy193L48 OGyRDh1/Wmzpew0VWWAWOSXGl/P9VzXf3Z6GPt7flN/V9iEJAa3Mo+w+eIdzJkHBWR+yJcqQcCRM MSyishMwLDGCAjgwggI0AgEBMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTAJBgUrDgMCGgUAoIHfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEzMTIwMzE3MzQwMlowIwYJKoZIhvcNAQkEMRYEFJT8c5PvwWmyNSgMqhScKxSZ o2shMD4GCSsGAQQBgjcQBDExMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTBABgsqhkiG9w0BCRACCzExoC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklF Q0EsIEluYy4CCQCdWMxKNutUeTANBgkqhkiG9w0BAQEFAASCAQCWhjWKiqN4nfF91RH1nsBhnam9 q3dRsElJUS2QRd1rGnkVj3BKkjYLMuwyLzJ7zEOKKUcdEH+qZev08LEbpDWwiI1QDYvYO1aKtyot iJx6oW8chNgH7qi4BejPFOF5K93tf4KzTyQbqOW1F+Sa1IIEoVz4MlJ5Cs7E7V9ia/dw84vYl1cq jlNDCKZocigLHDOdSZFudzxqW435MwXvn6U1HCyOmywGO4XhA1N+x2HQQpRLBc4maB4Z2/XUj3b4 MP2rK1EuA1LjmEcPFBaWbs5BwW1S+cOy8wr4LrPGK+gzZMWFZG2oKel+IygKCtmpjOYVqyCqntYD +TlqXJZoQeUtAAAAAAAA --Apple-Mail=_3742813A-A946-44CC-9840-FA385E85F65B-- From yaronf.ietf@gmail.com Tue Dec 3 09:40:58 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6C61AD8F4 for ; Tue, 3 Dec 2013 09:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSwOZjuWE8CF for ; Tue, 3 Dec 2013 09:40:57 -0800 (PST) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id C8E021A1F1A for ; Tue, 3 Dec 2013 09:40:56 -0800 (PST) Received: by mail-ee0-f41.google.com with SMTP id t10so1774400eei.28 for ; Tue, 03 Dec 2013 09:40:53 -0800 (PST) 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=+PWLw7ARnHxJsj6gsLEoyWuk3P4oC9x/sa4WX1kUB54=; b=YQawtDGCSSdWo3ucpee9boACtlW3FicUGMU4BsKSofckV5PIr7edlyhYk1oUk0aO0j jyNwZZCCsq3HUtr+VQbF+4dSDcz5BP4fOn4GqsQbDmEeIQkP+AYi6HzhVyTKIsMNigO0 VKuNhFyUYEBM8ws0cARN9Za7QKPjtASkM3GmLAb68rGXAR/MqQlt5wVqh2qowdI+j6wm q8cTJCcEQBAO+Z82Vm3RqkmRo5fZshW3jHcoZsV6r5pC9d73QQr+7oWGC1BgUrxHZkAT K+BZ3muwJVtPQ4qEf1ZcbufLSvVDaKdRa8rvHhU4jyEGLVi7VA1JUP1aPClrJJHjw6fV xTBg== X-Received: by 10.14.105.200 with SMTP id k48mr71719155eeg.1.1386092453678; Tue, 03 Dec 2013 09:40:53 -0800 (PST) Received: from [192.168.193.95] (diup-241-234.inter.net.il. [213.8.241.234]) by mx.google.com with ESMTPSA id a45sm84873354eem.6.2013.12.03.09.40.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 09:40:53 -0800 (PST) Message-ID: <529E17A4.8090409@gmail.com> Date: Tue, 03 Dec 2013 19:40:52 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: ipsec References: <529DF852.7080706@gmail.com> <45734D87-7B8D-4739-B98C-408FC64BFAD8@vpnc.org> In-Reply-To: <45734D87-7B8D-4739-B98C-408FC64BFAD8@vpnc.org> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] AD VPN: protocol selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 17:40:59 -0000 Dear IPsecME folks, There is clear working group interest in a standard auto-discovery VPN solution. We have agreed-upon requirements [1]. And we have 3 serious contenders [2] [3] [4] for the solution. It is time to select a protocol to adopt into the working group. We would like to ask people who are *not* authors on any of the solution drafts to send a short message to the list, saying which of the three they prefer, and a few reasons for their choice. Please do *not* send mail saying which of the protocols you do *not* like - this would be far less useful. And please do not think up a new solution proposal, it's too late for that. A quick process reminder: once we adopt a protocol, it becomes the starting point for the working group document. The WG can change the editor team and is free to make material changes to the protocol before it is published as RFC. Thanks, Paul and Yaron [1] http://tools.ietf.org/html/rfc7018 [2] http://tools.ietf.org/html/draft-mao-ipsecme-ad-vpn-protocol-02 [3] http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03 [4] http://tools.ietf.org/html/draft-detienne-dmvpn-00 From mcr@sandelman.ca Tue Dec 3 12:49:58 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67C21AD94A for ; Tue, 3 Dec 2013 12:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cjz6ZRUYmDO6 for ; Tue, 3 Dec 2013 12:49:56 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id BEB3D1ACCFF for ; Tue, 3 Dec 2013 12:49:56 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 072CB20051; Tue, 3 Dec 2013 17:03:09 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 8C01263B87; Tue, 3 Dec 2013 15:49:49 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 71AF763782; Tue, 3 Dec 2013 15:49:49 -0500 (EST) From: Michael Richardson To: Yaron Sheffer In-Reply-To: <529E17A4.8090409@gmail.com> References: <529DF852.7080706@gmail.com> <45734D87-7B8D-4739-B98C-408FC64BFAD8@vpnc.org> <529E17A4.8090409@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: ipsec Subject: Re: [IPsec] AD VPN: protocol selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 20:49:58 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I prefer draft-sathyanarayan-ipsecme-advpn. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUp5D6IqHRg3pndX9AQLhAAP/VJC5ziz2gZv0TQlU3O56IgAzoh9J6cW3 WjW2r4FHTE/vLe7UXETgHgq7ype7IrBS2lq4l74Il9LjwbCA5n7eQTuOiFN6uGVB zWGOHT/rh+UCLuh+x5UAM4TWEKMbGSB8KPqAiCw0Maz6OZyRcfJcvqyWoX268KC7 F77Sao19xIQ= =NBBd -----END PGP SIGNATURE----- --=-=-=-- From paul.hoffman@vpnc.org Tue Dec 3 12:53:51 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3C91ADF48 for ; Tue, 3 Dec 2013 12:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IK4ASCz2XUod for ; Tue, 3 Dec 2013 12:53:50 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AC8801ACCFF for ; Tue, 3 Dec 2013 12:53:50 -0800 (PST) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rB3KrkAC016186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 13:53:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host sn80.proper.com [75.101.18.80] claimed to be [165.227.249.247] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: <9100.1386103789@sandelman.ca> Date: Tue, 3 Dec 2013 12:53:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <57436FF1-ABCE-4E0D-AFD6-C27F5EEC5A73@vpnc.org> References: <529DF852.7080706@gmail.com> <45734D87-7B8D-4739-B98C-408FC64BFAD8@vpnc.org> <529E17A4.8090409@gmail.com> <9100.1386103789@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1822) Cc: ipsec Subject: Re: [IPsec] AD VPN: protocol selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 20:53:51 -0000 On Dec 3, 2013, at 12:49 PM, Michael Richardson = wrote: > I prefer draft-sathyanarayan-ipsecme-advpn. because.... ?= From mcr@sandelman.ca Tue Dec 3 14:11:50 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FCE1ADF71 for ; Tue, 3 Dec 2013 14:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBiiUpzU3JSU for ; Tue, 3 Dec 2013 14:11:48 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 53BEA1AE042 for ; Tue, 3 Dec 2013 14:11:48 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 08B5420030 for ; Tue, 3 Dec 2013 18:24:58 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 523E063B87; Tue, 3 Dec 2013 17:11:37 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 38AFF63782 for ; Tue, 3 Dec 2013 17:11:37 -0500 (EST) From: Michael Richardson To: ipsec In-Reply-To: <57436FF1-ABCE-4E0D-AFD6-C27F5EEC5A73@vpnc.org> References: <529DF852.7080706@gmail.com> <45734D87-7B8D-4739-B98C-408FC64BFAD8@vpnc.org> <529E17A4.8090409@gmail.com> <9100.1386103789@sandelman.ca> <57436FF1-ABCE-4E0D-AFD6-C27F5EEC5A73@vpnc.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [IPsec] AD VPN: protocol selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 22:11:50 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I wrote: "I prefer draft-sathyanarayan-ipsecme-advpn." Paul asked: " because.... ?" Oh.=20 I thought that I wasn't supposed to say why I didn't like other proposals := -)=20 Okay...=20 I prefer it because: 1) it lives inside IKE. 2) it deals with the question of distribution of authentication tokens. 3) it requires no new kernel components, which means that it will run with *just* a modified IKE daemon on many mobile devices. Yes, you need root on Android and a jailbreak on iOS to run a modified IKE, but you don't need a new kernel, and all sorts of other host specific firmware blobs.=20=20 This means that while it might not be end-user-installable, if someone makes the patches, they can tested, and pushed easily into AOSP, and maybe Apple would accept them. 4) it is very specific about what "routing" protocol would be the MTI ("IKE"/RFC4301!) , rather than being "well, whatever you like" 5) it permits port-specific policies to be controlled by HQ. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 =20=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUp5XFoqHRg3pndX9AQJsagP/ToIUyxrS8WEFmkci02Zo5WrurI9Nmbu0 VYBkEFLH0EPVb98w20tR3eeFnsCKRyH7WnSNMc/pzN2Kj7oSJxDLmT68kS9iwbkb HcQjrTAbXO6Vo+DNlYu0I8pk6KDAu2LlNiRJBIpfeRUde71tEbg+27RHY8iSDNUj uxzGtU9x8n4= =kSg1 -----END PGP SIGNATURE----- --=-=-=-- From yaronf.ietf@gmail.com Tue Dec 3 14:27:38 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7C01ADF79 for ; Tue, 3 Dec 2013 14:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHLzfJWY_pQD for ; Tue, 3 Dec 2013 14:27:36 -0800 (PST) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id E9ABB1ADDA0 for ; Tue, 3 Dec 2013 14:27:35 -0800 (PST) Received: by mail-ee0-f53.google.com with SMTP id b57so1867564eek.26 for ; Tue, 03 Dec 2013 14:27:32 -0800 (PST) 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=onsoO8lyO3PybWKvcN1293KsjZ63wZtJWnwUjtAjtpI=; b=Kp7T/ilsxoRo3snNS4jtVy3rQuKdwR4ViyGiaaZtKnwuLjNa02oLPqLP4ciPDhLZFP ihNVvqrq01S+8fFGxD/Hj3vd0R3qWw/ac1CZYhOvThilkoPai+kRWO+Q+kLMUqJdFBE+ ZQ0x1xECr/u/gZSIAjIYmoEhOCFY/8ZYAa9XbIMXRVx2YTMXIYS5zEOmgN57kVX7by7z +zN5/oivxvAfmaik1i3DP5bsbDnB1edDDvz/ZTGqpyHOgF6rWflzbjsaQwvGwuCJR+aP BYuAs9OYP4nW6teCdY8ZUxDoS8xY5Vvv4Jh+bv05bfnvTML+YUjY2K/rLwQRKrQSRe3W YP8Q== X-Received: by 10.15.26.6 with SMTP id m6mr3493973eeu.80.1386109652804; Tue, 03 Dec 2013 14:27:32 -0800 (PST) Received: from [10.0.0.2] ([109.65.142.155]) by mx.google.com with ESMTPSA id z42sm15187166eeo.17.2013.12.03.14.27.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 14:27:32 -0800 (PST) Message-ID: <529E5AD3.6080204@gmail.com> Date: Wed, 04 Dec 2013 00:27:31 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: ipsec Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Internet Standards questionnaires X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 22:27:38 -0000 To clarify (yet again): feel free to post your responses to any of these questionnaires to the list, or to send them privately to Sean. In any case the resulting implementation report will be published openly ( http://www.ietf.org/iesg/implementation-report.html), so you should not include anything confidential. Thanks, Yaron From paul.hoffman@vpnc.org Tue Dec 3 16:16:29 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DD31ADF9A for ; Tue, 3 Dec 2013 16:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHDp2dqdCU8h for ; Tue, 3 Dec 2013 16:16:28 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 201441ADFA9 for ; Tue, 3 Dec 2013 16:16:28 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rB40GN10021649 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 3 Dec 2013 17:16:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: <25486.1386108697@sandelman.ca> Date: Tue, 3 Dec 2013 16:16:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <529DF852.7080706@gmail.com> <45734D87-7B8D-4739-B98C-408FC64BFAD8@vpnc.org> <529E17A4.8090409@gmail.com> <9100.1386103789@sandelman.ca> <57436FF1-ABCE-4E0D-AFD6-C27F5EEC5A73@vpnc.org> <25486.1386108697@sandelman.ca> To: ipsec X-Mailer: Apple Mail (2.1822) Subject: Re: [IPsec] AD VPN: protocol selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 00:16:29 -0000 On Dec 3, 2013, at 2:11 PM, Michael Richardson = wrote: > I wrote: "I prefer draft-sathyanarayan-ipsecme-advpn." >=20 > Paul asked: " because.... ?" >=20 > Oh.=20 > I thought that I wasn't supposed to say why I didn't like other = proposals :-)=20 Correct. We want to hear what anyone (among the non-authors) *likes* = about particular proposals. > Okay...=20 >=20 > I prefer it because: > 1) it lives inside IKE. > 2) it deals with the question of distribution of authentication > tokens. > 3) it requires no new kernel components, which means that it will > run with *just* a modified IKE daemon on many mobile devices. > Yes, you need root on Android and a jailbreak on iOS to run a = modified > IKE, but you don't need a new kernel, and all sorts of other host > specific firmware blobs. =20 > This means that while it might not be end-user-installable, if = someone > makes the patches, they can tested, and pushed easily into AOSP, > and maybe Apple would accept them. >=20 > 4) it is very specific about what "routing" protocol would be the MTI > ("IKE"/RFC4301!) , rather than being "well, whatever you like" >=20 > 5) it permits port-specific policies to be controlled by HQ. Thats the kind of list we are looking for. "It has feature X which I = find useful / important." --Paul Hoffman= From andreas.steffen@strongswan.org Wed Dec 4 01:03:04 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780921ADFFF for ; Wed, 4 Dec 2013 01:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzKsOucj_6so for ; Wed, 4 Dec 2013 01:03:03 -0800 (PST) Received: from strongswan.org (sitav-80024.hsr.ch [152.96.80.24]) by ietfa.amsl.com (Postfix) with ESMTP id AAD201ADFD6 for ; Wed, 4 Dec 2013 01:03:02 -0800 (PST) Received: from [152.96.15.95] by strongswan.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Vo8Jx-00026g-Kt; Wed, 04 Dec 2013 10:00:37 +0100 Message-ID: <529EEF03.9090204@strongswan.org> Date: Wed, 04 Dec 2013 09:59:47 +0100 From: Andreas Steffen User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: ipsec@ietf.org References: <529DF852.7080706@gmail.com> <45734D87-7B8D-4739-B98C-408FC64BFAD8@vpnc.org> <529E17A4.8090409@gmail.com> In-Reply-To: <529E17A4.8090409@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020705020507090600030107" Subject: Re: [IPsec] AD VPN: protocol selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 09:03:04 -0000 This is a cryptographically signed message in MIME format. --------------ms020705020507090600030107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Speaking for the strongSwan project, I'm favoring draft-sathyanarayan-ipsecme-advpn because - The concept is simple but powerful and well embedded into the current IKEv2 message exchange architecture. - No overlay of additional routing protocols is needed. - The proposed solution has a lot of similarity with our Double-NAT IKEv2 Mediation Extension [1] that we proposed a couple of years ago and which has been implemented by strongSwan. Thus the integration of the draft-sathyanarayan-ipsecme-advpn capabilities into our architecture should be rather easy. In the future it might even be possible to extend the SHORTCUT exchange to Double-NAT situations. - The draft is in a very advanced state with all protocol details neatly worked out. It's ready for implementation, so we might give it a try :-) Best regards Andreas [1] http://tools.ietf.org/html/draft-brunner-ikev2-mediation-00 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Andreas Steffen andreas.steffen@strongswan.org strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D[ITA-HSR]=3D=3D --------------ms020705020507090600030107 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMhDCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGSDCCBTCgAwIBAgIDB7KBMA0GCSqGSIb3DQEB CwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTMwOTI4MTIzNDU4 WhcNMTQwOTMwMDMxMjI2WjBYMScwJQYDVQQDDB5hbmRyZWFzLnN0ZWZmZW5Ac3Ryb25nc3dh bi5vcmcxLTArBgkqhkiG9w0BCQEWHmFuZHJlYXMuc3RlZmZlbkBzdHJvbmdzd2FuLm9yZzCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJtxLfnUeESAyEiRlISv6pmUjP1uEd/4 18V5rGVcJbAtzuJfHAlJeHyVaqI8aGjwLN2jHxmPVPJfFi0Z3t/bRAK4u7vnfysSJHTqyrYn 9af2sg59CHvVo9fPEbvX7S+8mi1B2hbWUAVhIO0cmqChBku17gmHdWx+t86gp2v4Ku9ztxC7 D/iNodhHRAofm3RWZSy7VI8W8kifDo2aH2PFG3fw5jFHPxzYNL1DR/ENA2VA1io0x5NA78Mx ZpR6Rgz1jsXp3EgSh+xkcNhY2ugDu1/lIxtvey6JD/BgWIHHh2DI/2gb+HFsDrgVo+A4yf3S u/qv6JHapij26OUCLEYkwdsCAwEAAaOCAuQwggLgMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUp4bQ66T4CmiuI9i9 RewQZ8gFWdgwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwKQYDVR0RBCIwIIEe YW5kcmVhcy5zdGVmZmVuQHN0cm9uZ3N3YW4ub3JnMIIBTAYDVR0gBIIBQzCCAT8wggE7Bgsr BgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRv IHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBD QSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNv bXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0w K6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUF BwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xh c3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tLzANBgkqhkiG9w0BAQsFAAOCAQEAwrFtQfZk5tTb8e//+hSdJGU7Pfq8k6Ip gpzGWIHwy5h/OKJ9mX/4oXWXxIg5L1iyNX44AbnUBRIr7LxfWsKy1O+SxjlraxmeClKD83fJ bbqFg9f14TpF3KvjQULFvNlJf8mdfjO3JCYeswDw3GBjtWYl49zyqiYYG4ovZ+FcPz38cOUT 6VtAjzVe862tsq1mE86WuxMeEt5rDHSf2BorxN+VbG3R9+5ewcl4P6pxbWYjCooHfg4gcplI qMHaggRZvS9c1p85CT5BTIlcLwf1RZz6/TDgCarGqkQnGKovFSotb/6fafq49C5nAtXkyB9X FDQ7lYoldvA387ATO1FTgjGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0ECAweygTAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMzEyMDQwODU5NDdaMCMGCSqGSIb3DQEJBDEWBBRmPaPC sLjBwOJ+r4vs7b9mL1b1bjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO AwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklM MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDB7KBMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMHsoEwDQYJKoZIhvcNAQEBBQAEggEAmpuM VqKVmDOVv3rpIlK5QANelU4oYDP1bZM11emUYgrUqr2TqKag8GnDeQs7EXZxIl+GnYxZBDDa bnXUzChcWpc98ecoWHUwzuAkhv2TgRx7iH0YpkLB1TirvyLIcNy8s0kS0sreSW2oFzMttmny 8FQTV19RbsHF+RyjMxrLZkOl8xUJziSuyW1jZBQJjrTfpYHxJWStbpYookBv/KroX3alMLBZ yqVyIhrJ8r/ybO6/bsFdX+9ApfbTh5UX2gduHqfBg3gpjBUNwOTKiQXjR5/mXZ93X/sPgEY4 TfS7zHWmLcGhvQSRC5EwHWY8dUJfI6ZmognJHCOf5jTISvRFbwAAAAAAAA== --------------ms020705020507090600030107-- From TurnerS@ieca.com Wed Dec 4 03:41:31 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25781AE0D9 for ; Wed, 4 Dec 2013 03:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IB2thR-pMay0 for ; Wed, 4 Dec 2013 03:41:29 -0800 (PST) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [67.18.88.9]) by ietfa.amsl.com (Postfix) with ESMTP id AC0631AE0F3 for ; Wed, 4 Dec 2013 03:41:29 -0800 (PST) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id 9845ECC9104BF; Wed, 4 Dec 2013 05:41:26 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway12.websitewelcome.com (Postfix) with ESMTP id 71EF5CC91046D for ; Wed, 4 Dec 2013 05:41:26 -0600 (CST) Received: from [198.180.150.142] (port=53624 helo=v142.vpn.iad.rg.net) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1VoApY-0006et-Hi for ipsec@ietf.org; Wed, 04 Dec 2013 05:41:25 -0600 From: Sean Turner Content-Type: multipart/signed; boundary="Apple-Mail=_A1A8D903-FA04-4F04-A3D5-4F1F97446461"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <2F864385-06F0-4D96-B84E-E5BE4854E3F2@ieca.com> Date: Wed, 4 Dec 2013 11:41:21 +0000 To: IPsecme WG Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 198.180.150.142 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (v142.vpn.iad.rg.net) [198.180.150.142]:53624 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Subject: [IPsec] Progressing RFCs from PS to IS X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 11:41:31 -0000 --Apple-Mail=_A1A8D903-FA04-4F04-A3D5-4F1F97446461 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Probably best if I lay out the plan that=92s in my mind for progressing = RFCs 3948, 4301, 4303, and 5996 from PS (Proposed Standard) to IS = (Internet Standard). Steps: 1) A request gets sent to IESG to progress RFC(s) from PS to IS. I = think this ought to come from the authors to the WG and then from the WG = to the IESG. But, if the WG thinks it=92s a no-brainer then I=92m happy = to take it directly from the authors. 2) For #1 to not fall on its face, the four questions in RFC 6410 = (copied below) need to be answered: (1) There are at least two independent interoperating implementations with widespread deployment and successful operational experience. To answer this question, somebody (maybe me) needs to create an = interoperability report. The breadth and depth of the report is up to = us, as documented in RFC 5657 (please ignore that the title of that RFC = includes progression to DS (draft standard)). The interoperability = report is either the output of a bake-off or the distillation of a = questionnaire sent to implementers. I figured sending out a = questionnaire was easier than organizing a bake-off and getting the WG = to review the questions I also thought was important. The responses to = the questionnaire are turned in to the interoperability report and that = interoperability report is cited in the WG and IETF LCs and it=92s = posted to:=20 http://www.ietf.org/iesg/implementation-report.html Responses to the questionnaire can be sent to the list or to the person = sending out the questionnaire. Regardless the responses are going to = end up being documented in the interoperability report. I don=92t think = it makes sense to anonymize the responses included in the = interoperability report. I also don=92t think this interoperability = report needs to be exhaustive before we move on. We=92re looking 2-3 = implementations that can claim they interoperate and do some on a wide = scale. (2) There are no errata against the specification that would cause a new implementation to fail to interoperate with deployed ones. For this one we=92re generating new drafts that incorporate errata. Not = all errata has been included and that=92s why the drafts list what was = included and they will be last called to make sure that what got = included is agreed. But, for the RFCs that have errata we=92re = explicitly asking this question in the questionnaire. (3) There are no unused features in the specification that greatly increase implementation complexity. Again, there=92s a specific question in the questionnaire to get an = answer. (4) If the technology required to implement the specification requires patented or otherwise controlled technology, then the set of implementations must demonstrate at least two independent, separate and successful uses of the licensing process. There are IPR filings against RFC 3948 and 5996 so there needs to be = questions added to their questionnaires about this topic. How about: Have the IPR file against RFC XXXX hindered development or deployment? 3) If it=92s going through the WG, the WG LC should include the four = questions making sure the interop report is referenced and calling out = any downrefs. This report can be documented as an internet draft for = this purpose, but there=92s no need to progress it to RFC because it=92s = just published on the interoperability report page. 4) After the AD gets it, the AD will IETF LC the same questions making = sure to also refer to the interop report and include the downrefs. 5) The IESG will review it and we see what happens=85. Make sense? spt= --Apple-Mail=_A1A8D903-FA04-4F04-A3D5-4F1F97446461 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEgDCCBHww ggJkoAMCAQICCQCdWMxKNutUeTANBgkqhkiG9w0BAQsFADAiMQswCQYDVQQGEwJVUzETMBEGA1UE ChMKSUVDQSwgSW5jLjAeFw0xMzA0MDMxNDUxMThaFw0xNDA0MDMxNDUxMThaMDgxCzAJBgNVBAYT AlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuMRQwEgYDVQQDEwtTZWFuIFR1cm5lcjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOpCGCRptT1m+bIpLTmbahZLZ0Qe4X99f8SgTQ7QISvUfpmn tfOD1oA1AttXlOULEERYubzvDnUTXvstFomQx0XTA67IaV+mw9ODRtG1hPN/erdKX6sU6rH4tsEb ba3Drr/I0HT3YVvD3SjWtGXjF12XLvTP6+LfMIIDTCAPiEd9KPG23D7skVu/4BvvmdLFI96OARhg wQ86M+lTIn83KRJlbbfAeIevbRx/rUB7D+uvMdWxOzR0KZJhd6dEeTXVwBXZG4rnQ4uFM+mRSiD4 rxDCyOuIuOzR07tnOyCRio6sRipOZvwQUWttdsgMEs6IxLdWsaTXcs1HjCsxrdedovMCAwEAAaOB njCBmzAOBgNVHQ8BAf8EBAMCBeAwHwYDVR0jBBgwFoAUAHRsSeXJUmFxTVY4q2HJ8uHl+w0wGwYD VR0RBBQwEoEQVHVybmVyU0BpZWNhLmNvbTAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vd3d3Lmll Y2EuY29tL2NybHMvaWVjYS5jcmwwFwYDVR0gBBAwDjAMBgorBgEEAYHXAAAAMA0GCSqGSIb3DQEB CwUAA4ICAQAimDYm77ppTi4vK6qJSUhyvCDMGb8mngiEXEYKxsfdHPWoDO7+06j7dAZ8sDD9/FtE kiUMyoNGSUmKHR+tGperVnNiM/Zk6WwCJv8dYZwhGXNQeEGzeys/UkFv7CFX7uDSn8GQeB8sOAZ1 N1hxV/TvT8qXvcRxP5+aWTAGAq3TKtCQxZjuU74L3st2hZiOhJlhjhqz0K5FIwWzXUK9uwhZe1th GUpDbRustVgmKN2Xa0pzwqI1VUO0jnWt24A4u59xo6DJQXzQVMhCx0xhpemuT9BrsBDTX8eJdI1i Wv9wp3ivSrfHjKXp8y8OGD+usiG40HCjj0W9C+dH0VfbgrB6QOI4vA9+kTg4mANth1cxyxwPYOSJ v0zi1qR0eDIGI//2v2/s6TmGuNqbnRa26Ldv5gGqS7xj32Fiaby6UOXs4+aAIWGZEOH+BXjozcvE eGBwjU/VRQYu6itR28PaNhNVji4D5ITaGxWWiycqK1EUaFraWHtk7W100ROX69xTeFVZP86D2ymi /aohl5Vb1vlYHdqlbgqjDRl9dPbTxVCXEHf+jkexcuwlLTvr7F+5DIN6c/EbCpRqQx3edy193L48 OGyRDh1/Wmzpew0VWWAWOSXGl/P9VzXf3Z6GPt7flN/V9iEJAa3Mo+w+eIdzJkHBWR+yJcqQcCRM MSyishMwLDGCAjgwggI0AgEBMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTAJBgUrDgMCGgUAoIHfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEzMTIwNDExNDEyMVowIwYJKoZIhvcNAQkEMRYEFDobHaM+QV7Sa7nZs6Z8NU95 0J5bMD4GCSsGAQQBgjcQBDExMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTBABgsqhkiG9w0BCRACCzExoC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklF Q0EsIEluYy4CCQCdWMxKNutUeTANBgkqhkiG9w0BAQEFAASCAQC9AdDe3Veu2zwtSgE0AWcyOp5x +Xa+O7W9nPXkD6+cg1n+IfMwi+uuy8oEpr1hjaTfSX/7z2DfmM/mQtpZ1CtLo0NWYcZSTM6IFEhA BW8tFDHBqnA+z28leWHnL9xYKil/uE8rXfmDqQWwLDL3tvuuNCZNlmew3SJgzqXgCEUXlfrBUEqJ UWl73EpOf00Cw6omU7O8ZjrINR8N2jzmDqRlHzAqA7doM3NqukeV23Ru2RLWw/bAHTEgc1KKvgqB MPD5IVpkxySbkY9CarAc40PIMhJh7CXCHQw8RSwW9XCr1VK1GoGa9pu7fykElA7Pj2DARIYfDLQ2 Zi1OW1RflIgzAAAAAAAA --Apple-Mail=_A1A8D903-FA04-4F04-A3D5-4F1F97446461-- From Johannes.Merkle@secunet.com Thu Dec 5 05:04:46 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D251ADFC4 for ; Thu, 5 Dec 2013 05:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ux0A2lrmmiUC for ; Thu, 5 Dec 2013 05:04:44 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3B01ADFC0 for ; Thu, 5 Dec 2013 05:04:44 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 4CABE1A0084; Thu, 5 Dec 2013 14:04:39 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5bTbsFj33Iuk; Thu, 5 Dec 2013 14:04:38 +0100 (CET) Received: from mail-gw-int (unknown [10.53.40.207]) by a.mx.secunet.com (Postfix) with ESMTP id 33F711A006C; Thu, 5 Dec 2013 14:04:38 +0100 (CET) Received: from [10.53.40.200] (port=46211 helo=mail-srv1.secumail.de) by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1VoYZU-0001wZ-1S; Thu, 05 Dec 2013 14:02:24 +0100 Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Dec 2013 14:04:38 +0100 Message-ID: <52A079E5.9060009@secunet.com> Date: Thu, 05 Dec 2013 14:04:37 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: kivinen@iki.fi References: <21124.6276.800771.457943@fireball.kivinen.iki.fi> In-Reply-To: <21124.6276.800771.457943@fireball.kivinen.iki.fi> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Dec 2013 13:04:38.0186 (UTC) FILETIME=[8D9498A0:01CEF1BA] Cc: ipsec@ietf.org Subject: Re: [IPsec] New drafts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 13:04:46 -0000 Tero Kivinen schrieb am 14.11.2013 01:25: > I also updated the signature authentication draft by adding the > section about the public key selection methods, and I also added the > binary objects for the commonly used signature ASN.1 objects. If > someone has any way to verify those (especially the RSASSA-PSS method > with parameters), that would be really good. > Tero, I just had a closer look at the IANA considerations section. Isn't the new auth method Digital Signature missing? -- Johannes From fdetienn@cisco.com Fri Dec 6 08:04:00 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9415A1AE08A for ; Fri, 6 Dec 2013 08:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoqAvzgp2L67 for ; Fri, 6 Dec 2013 08:03:58 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 681221AE084 for ; Fri, 6 Dec 2013 08:03:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1571; q=dns/txt; s=iport; t=1386345835; x=1387555435; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=EdJ69HHPjwcExOlrAPd2XpMDXjqwZ2CiyufOzciLqU0=; b=VqF/V8gHOElNp5AXU07Xr3yvZ619jjMhTXHj8YorRSCxhlK/VgUr0f1Z 6zdRA+lOzU2nlGYLOgtoefBHaP1Tq7QsWka4Mjl0nJ/ad5sjVA9ttmlvq A5+GAsD/XSmsxMIfz7aZJaQWEB+or0gFnOJ03tHxlZeipjVuY8kyzrUUZ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFADr0oVKtJXG8/2dsb2JhbABZgwc4U7kAgSIWdIIlAQEBAwEBAQE3NAsFCwIBCDYQIQYLJQIEDgUbh1UDCQYNuV0NhxoXjH2BQgEBHDMHgyCBEwOWKYFrgTCLKoU5gymBcTk X-IronPort-AV: E=Sophos;i="4.93,841,1378857600"; d="scan'208";a="289932398" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 06 Dec 2013 16:03:54 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB6G3skN011987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Dec 2013 16:03:54 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.67]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Fri, 6 Dec 2013 10:03:54 -0600 From: "Frederic Detienne (fdetienn)" To: Yaron Sheffer Thread-Topic: [IPsec] AD VPN: protocol selection Thread-Index: AQHO8E7a/jMzXRpyKEqstWVWro9PpJpHvXyA Date: Fri, 6 Dec 2013 16:03:53 +0000 Message-ID: <747BB1FB-0DBC-4AEE-AC0E-4CC46300139E@cisco.com> References: <529DF852.7080706@gmail.com> <45734D87-7B8D-4739-B98C-408FC64BFAD8@vpnc.org> <529E17A4.8090409@gmail.com> In-Reply-To: <529E17A4.8090409@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.214.155] Content-Type: text/plain; charset="us-ascii" Content-ID: <427681F9D343394E992B79B8BB2A6BE4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ipsec Subject: Re: [IPsec] AD VPN: protocol selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 16:04:00 -0000 Hi Yaron, Is this an official poll or is it "just to see" ? If this is serious, what = is the deadline ? thanks, fred On 03 Dec 2013, at 18:40, Yaron Sheffer wrote: > Dear IPsecME folks, >=20 > There is clear working group interest in a standard auto-discovery VPN so= lution. We have agreed-upon requirements [1]. And we have 3 serious contend= ers [2] [3] [4] for the solution. It is time to select a protocol to adopt = into the working group. >=20 > We would like to ask people who are *not* authors on any of the solution = drafts to send a short message to the list, saying which of the three they = prefer, and a few reasons for their choice. >=20 > Please do *not* send mail saying which of the protocols you do *not* like= - this would be far less useful. And please do not think up a new solution= proposal, it's too late for that. >=20 > A quick process reminder: once we adopt a protocol, it becomes the starti= ng point for the working group document. The WG can change the editor team = and is free to make material changes to the protocol before it is published= as RFC. >=20 > Thanks, > Paul and Yaron >=20 > [1] http://tools.ietf.org/html/rfc7018 > [2] http://tools.ietf.org/html/draft-mao-ipsecme-ad-vpn-protocol-02 > [3] http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03 > [4] http://tools.ietf.org/html/draft-detienne-dmvpn-00 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From fdetienn@cisco.com Fri Dec 6 08:07:15 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4391AE06F for ; Fri, 6 Dec 2013 08:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCx5ikpY6Y0U for ; Fri, 6 Dec 2013 08:07:13 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4CD1AE054 for ; Fri, 6 Dec 2013 08:07:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=367; q=dns/txt; s=iport; t=1386346030; x=1387555630; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OFZoSKLJ5I4UOlaKLlgB038NZRxOOdxSU6ix9b1dH2E=; b=N3C2/jhcWN8SmyxgsoFf5ejOyyqCnqAbdmnP51hgOlf3zCq6qIhrUcKS vKQILE5b+e6j6rjZ89K43Ig2/199ZzrYeusE1ak4RflHG91JG62Ttb3JM Fx0+SSukpQFvpd+L2SM1nCDdwEEN8HbZHzEZ2cYn2JmsN+6KB1+kiFFDA I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFALX1oVKtJV2c/2dsb2JhbABZgweBC7kAgSIWdIImAQEEeRACAQhGMiUCBA4FiALBDxeOXTMHgyCBEwOJCo8KkhODKYIq X-IronPort-AV: E=Sophos;i="4.93,841,1378857600"; d="scan'208";a="286851876" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 06 Dec 2013 16:07:08 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rB6G78Tk015422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Dec 2013 16:07:08 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.67]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Fri, 6 Dec 2013 10:07:07 -0600 From: "Frederic Detienne (fdetienn)" To: Andreas Steffen Thread-Topic: [IPsec] AD VPN: protocol selection Thread-Index: AQHO8E7a/jMzXRpyKEqstWVWro9PpJpEIlSAgAOcD4A= Date: Fri, 6 Dec 2013 16:07:07 +0000 Message-ID: <40E26A54-7ADF-4B8D-BDC6-9FA8C15D70D1@cisco.com> References: <529DF852.7080706@gmail.com> <45734D87-7B8D-4739-B98C-408FC64BFAD8@vpnc.org> <529E17A4.8090409@gmail.com> <529EEF03.9090204@strongswan.org> In-Reply-To: <529EEF03.9090204@strongswan.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.214.155] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <86588FF5758A9749BEF4C8DC301F8AD0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [IPsec] AD VPN: protocol selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 16:07:15 -0000 Hi Andreas, On 04 Dec 2013, at 09:59, Andreas Steffen = wrote: > ... > - No overlay of additional routing protocols is needed. please note that our proposal does not mandate a routing protocol. We also = support IKEv2 config exchange and treat the protected subnets as "routes" f= or the tunnel. Thanks! fred= From paul.hoffman@vpnc.org Fri Dec 6 08:42:51 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4D21AE342 for ; Fri, 6 Dec 2013 08:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBa4a66JSO5G for ; Fri, 6 Dec 2013 08:42:51 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1005A1ADFFB for ; Fri, 6 Dec 2013 08:42:51 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rB6GghZp072830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Dec 2013 09:42:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: <747BB1FB-0DBC-4AEE-AC0E-4CC46300139E@cisco.com> Date: Fri, 6 Dec 2013 08:42:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <529DF852.7080706@gmail.com> <45734D87-7B8D-4739-B98C-408FC64BFAD8@vpnc.org> <529E17A4.8090409@gmail.com> <747BB1FB-0DBC-4AEE-AC0E-4CC46300139E@cisco.com> To: "Frederic Detienne (fdetienn)" X-Mailer: Apple Mail (2.1822) Cc: ipsec Subject: Re: [IPsec] AD VPN: protocol selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 16:42:52 -0000 On Dec 6, 2013, at 8:03 AM, Frederic Detienne (fdetienn) = wrote: > Is this an official poll or is it "just to see" ? Both. That is, it is official in that the WG chairs asked for it, = because we wanted "just to see". It is a poll, not a vote. > If this is serious, what is the deadline ? When we have enough input to get a sense of the WG. Given the meager = response so far, we're not at all there yet. --Paul Hoffman= From paul.hoffman@vpnc.org Fri Dec 6 08:45:24 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D877A1AE33D for ; Fri, 6 Dec 2013 08:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8mzo6Q3w8Hn for ; Fri, 6 Dec 2013 08:45:24 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 144DF1AE091 for ; Fri, 6 Dec 2013 08:45:24 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rB6GjIwL072919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 6 Dec 2013 09:45:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: <40E26A54-7ADF-4B8D-BDC6-9FA8C15D70D1@cisco.com> Date: Fri, 6 Dec 2013 08:45:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <529DF852.7080706@gmail.com> <45734D87-7B8D-4739-B98C-408FC64BFAD8@vpnc.org> <529E17A4.8090409@gmail.com> <529EEF03.9090204@strongswan.org> <40E26A54-7ADF-4B8D-BDC6-9FA8C15D70D1@cisco.com> To: "" X-Mailer: Apple Mail (2.1822) Subject: Re: [IPsec] AD VPN: protocol selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 16:45:25 -0000 On Dec 6, 2013, at 8:07 AM, Frederic Detienne (fdetienn) = wrote: > please note that our proposal does not mandate a routing protocol. We = also support IKEv2 config exchange and treat the protected subnets as = "routes" for the tunnel. And yet Yaron and I specifically asked: On Dec 3, 2013, at 9:40 AM, Yaron Sheffer wrote: > We would like to ask people who are *not* authors on any of the = solution drafts to send a short message to the list, saying which of the = three they prefer, and a few reasons for their choice. Seriously, authors: please refrain. The WG has heard enough pitches from = you for your proposals and, if not, you are free to update your drafts = to make them clearer. This poll is to hear from the other people in the = WG. --Paul Hoffman= From paul@cypherpunks.ca Fri Dec 6 10:05:53 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540441AE0EB for ; Fri, 6 Dec 2013 10:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaq1x_biGmjO for ; Fri, 6 Dec 2013 10:05:49 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 656FD1AE114 for ; Fri, 6 Dec 2013 10:05:49 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id C300E80A0C; Fri, 6 Dec 2013 13:05:44 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B5A1A80A0B; Fri, 6 Dec 2013 13:05:44 -0500 (EST) Date: Fri, 6 Dec 2013 13:05:44 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Yaron Sheffer In-Reply-To: <529E17A4.8090409@gmail.com> Message-ID: References: <529DF852.7080706@gmail.com> <45734D87-7B8D-4739-B98C-408FC64BFAD8@vpnc.org> <529E17A4.8090409@gmail.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: ipsec Subject: Re: [IPsec] AD VPN: protocol selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 18:05:53 -0000 On Tue, 3 Dec 2013, Yaron Sheffer wrote: > There is clear working group interest in a standard auto-discovery VPN > solution. > We have agreed-upon requirements [1]. I was unfortunately not really active during the requirements phase. While I believe there is a need for auto-discovery without preconfiguration, I do not think the current ideas of merging site-to-site based VPNs using ADVPN proposals really increases security. It seems a compromise for convenience at the expense of the intended security of IPsec, and a continued trend from strict policy range based VPNs to loose routing based VPNs, reducing IPsec to a virtual private untrusted ethernet cable. I think draft-sathyanarayan-ipsecme-advpn-03 comes closest to removing any kind of routing decisions from the IKE/IPsec protocols, leaving the IPsec subsystem as a consumer of the routing decisions made elsewhere. Paul From mcr@sandelman.ca Fri Dec 6 10:41:46 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F661ADF22 for ; Fri, 6 Dec 2013 10:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_MIME_NO_TEXT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtyEv7CJXNiV for ; Fri, 6 Dec 2013 10:41:44 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC351A1F6F for ; Fri, 6 Dec 2013 10:41:44 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 27C9A20050; Fri, 6 Dec 2013 14:55:05 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id E239D63B89; Fri, 6 Dec 2013 13:41:33 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D199463B88; Fri, 6 Dec 2013 13:41:33 -0500 (EST) From: Michael Richardson To: "\" X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "Frederic Detienne \(fdetienn\)" Subject: [IPsec] routing protocols for ADVPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 18:41:47 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable (thread broken intentionally) Frederic Detienne (fdetienn) wrote: >> ... >> - No overlay of additional routing protocols is needed. > please note that our proposal does not mandate a routing protocol. We > also support IKEv2 config exchange and treat the protected subnets as > "routes" for the tunnel.=20 I have no idea how to implement what you described. This is the problem: we have asked questions, and we keep getting "oh, yes, we can do that", but no actual explanation. I'd rather that you had mandated OSPFv2/3 or someso that I could evaluate t= he entire solution. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUqIaXYqHRg3pndX9AQJmyAP/T2Vel3EgaOh4a1SFFrh71qTxOxNUs9lT S1MeRQIVEKb+C90qnpPosdNN0pA1KX3Zw5jj+yjbhrbicwIQ+FoJZ4/YN2RpGmH9 MBei6DydNbeDmyGc8PuyFoQdySu4kReGNZKWr83ETloHbQQelytVWkiLFY2QGPi3 R2SMfjFSlp0= =I4IL -----END PGP SIGNATURE----- --=-=-=-- From saumoh@gmail.com Fri Dec 6 13:01:49 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E938A1AE0FD for ; Fri, 6 Dec 2013 13:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjG7OLXALJV0 for ; Fri, 6 Dec 2013 13:01:47 -0800 (PST) Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 845041AE0E9 for ; Fri, 6 Dec 2013 13:01:47 -0800 (PST) Received: by mail-qe0-f49.google.com with SMTP id w7so945021qeb.8 for ; Fri, 06 Dec 2013 13:01:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U25GubsQiYNmXKINfNRo18Cw0mluaRjuycst0Rh5m6g=; b=jeWlPFbLrzNZOCGNEL9POKXdX3jK2S8VXaBmSaGuwHeZIcoB7cFrOQ6glob5fK/NJZ OCSv8/a+OUOt3fKirwqI8Xb+37aASuygNOSfou/D1o6y0D3ntK5gwv9RAwlwmiD7lDt7 13epawNN9wfoYtRW3FMJpHe8Aaskq1JsVnHiZPnrknzKCnvMkUj+U2zpyTXVls9nKRAx uV26zuYZVM8MsX7/w0JVVPTbCRdG/Jn0c5XZpoe5d4oCXgH5yxrawXhohXE7OOUdUA6p YQLgxejHAA45x0sWNTdQu3h61YcBVhcvxba0bPmTDqjsOS9+aj2jBydnaWNGhTLm3ji0 C23w== MIME-Version: 1.0 X-Received: by 10.224.51.7 with SMTP id b7mr10330453qag.74.1386363703497; Fri, 06 Dec 2013 13:01:43 -0800 (PST) Received: by 10.140.50.240 with HTTP; Fri, 6 Dec 2013 13:01:43 -0800 (PST) In-Reply-To: <529E17A4.8090409@gmail.com> References: <529DF852.7080706@gmail.com> <45734D87-7B8D-4739-B98C-408FC64BFAD8@vpnc.org> <529E17A4.8090409@gmail.com> Date: Fri, 6 Dec 2013 13:01:43 -0800 Message-ID: From: Saurabh M To: Yaron Sheffer Content-Type: multipart/alternative; boundary=047d7beb9dce13b67b04ece3f491 Cc: ipsec , saurabh.mohan@brocade.com Subject: Re: [IPsec] AD VPN: protocol selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 21:01:50 -0000 --047d7beb9dce13b67b04ece3f491 Content-Type: text/plain; charset=ISO-8859-1 Hi, We'd prefer dmvpn( http://tools.ietf.org/html/draft-detienne-dmvpn-00) to become the wg document. The main reason for our recommendation are: - It is what customers are asking for. - We actually prefer that there are 2 separate protocols that co-operate to build the complete solution as it gives us the flexibility for each one to exist without mandating the other. - It was fairly easy to build a solution using open-nhrp and strongswan. Thanks -Saurabh Mohan. On Tue, Dec 3, 2013 at 9:40 AM, Yaron Sheffer wrote: > Dear IPsecME folks, > > There is clear working group interest in a standard auto-discovery VPN > solution. We have agreed-upon requirements [1]. And we have 3 serious > contenders [2] [3] [4] for the solution. It is time to select a protocol to > adopt into the working group. > > We would like to ask people who are *not* authors on any of the solution > drafts to send a short message to the list, saying which of the three they > prefer, and a few reasons for their choice. > > Please do *not* send mail saying which of the protocols you do *not* like > - this would be far less useful. And please do not think up a new solution > proposal, it's too late for that. > > A quick process reminder: once we adopt a protocol, it becomes the > starting point for the working group document. The WG can change the editor > team and is free to make material changes to the protocol before it is > published as RFC. > > Thanks, > Paul and Yaron > > [1] http://tools.ietf.org/html/rfc7018 > [2] http://tools.ietf.org/html/draft-mao-ipsecme-ad-vpn-protocol-02 > [3] http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03 > [4] http://tools.ietf.org/html/draft-detienne-dmvpn-00 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --047d7beb9dce13b67b04ece3f491 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,=20
We'd prefer dmvpn(=A0http://tools.ietf.org/html/draft-detienne-dmvpn-00)=A0to = become the wg document.
=A0

The main reason for our recommendation are:

- It is what customers are asking for.

- We actually prefer that there are 2 separate protocol= s that co-operate to build the complete solution as it gives us the flexibi= lity for each one to exist without mandating the other.

- It was fairly easy to build a solution using open-nhrp and = strongswan.=A0=A0

=A0

Thanks

-Saurabh Mohan.



On Tue, Dec 3, 2013 at 9:40 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
Dear IPsecME folks,

There is c= lear working group interest in a standard auto-discovery VPN solution. We h= ave agreed-upon requirements [1]. And we have 3 serious contenders [2] [3] = [4] for the solution. It is time to select a protocol to adopt into the wor= king group.

We would like to ask people who are *not* authors on any of the solutio= n drafts to send a short message to the list, saying which of the three the= y prefer, and a few reasons for their choice.

Please do *not* send m= ail saying which of the protocols you do *not* like - this would be far les= s useful. And please do not think up a new solution proposal, it's too = late for that.

A quick process reminder: once we adopt a protocol, it becomes the star= ting point for the working group document. The WG can change the editor tea= m and is free to make material changes to the protocol before it is publish= ed as RFC.

Thanks,
=A0 =A0 =A0 =A0 Paul and Yaron

[1] http://tools.ietf.org/html/<= u>rfc7018
[2] http://tools.ietf.org/html/<= /u>draft-mao-ipsecme-ad-vpn-protocol-02
[3] http://tools.ietf.org/html/draft-sathyanaraya= n-ipsecme-advpn-03
[4] http://tools.ietf.org/html/draft-detienne-dmvpn-00
_______________________________________________
IPsec mailing lis= t
IPsec@ietf.org=
https://www.ietf.org/mailman/listinfo/ipsec

--047d7beb9dce13b67b04ece3f491-- From synp71@live.com Fri Dec 6 13:25:47 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4956E1AE0FD for ; Fri, 6 Dec 2013 13:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AemsvavL6wIS for ; Fri, 6 Dec 2013 13:25:45 -0800 (PST) Received: from blu0-omc2-s7.blu0.hotmail.com (blu0-omc2-s7.blu0.hotmail.com [65.55.111.82]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0E31AE09C for ; Fri, 6 Dec 2013 13:25:45 -0800 (PST) Received: from BLU0-SMTP74 ([65.55.111.72]) by blu0-omc2-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Dec 2013 13:25:41 -0800 X-TMN: [HPpve5vdZmBidElPvXb/pl2hYQgi1n0O] X-Originating-Email: [synp71@live.com] Message-ID: Received: from ynir-MBA.local ([84.109.50.18]) by BLU0-SMTP74.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Dec 2013 13:25:40 -0800 Date: Fri, 6 Dec 2013 23:25:42 +0200 From: Yoav Nir User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Paul Wouters References: <529DF852.7080706@gmail.com> <45734D87-7B8D-4739-B98C-408FC64BFAD8@vpnc.org> <529E17A4.8090409@gmail.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020007060806050104000708" X-OriginalArrivalTime: 06 Dec 2013 21:25:40.0387 (UTC) FILETIME=[B6762F30:01CEF2C9] Cc: ipsec Subject: [IPsec] ADVPN vs opportunistic VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 21:25:47 -0000 --------------ms020007060806050104000708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable [Changing the subject to avoid poisoning the protocol selection thread=20 with my author-ness] On 6/12/13 8:05 PM, Paul Wouters wrote: > We have agreed-upon requirements [1]. > > I was unfortunately not really active during the requirements phase. > > While I believe there is a need for auto-discovery without > preconfiguration, I do not think the current ideas of merging=20 > site-to-site > based VPNs using ADVPN proposals really increases security.=20 They're not supposed to. They are supposed to increase efficiency and=20 reliability. The problem we're trying to solve is that the way the=20 standards and products work today, tunnels are configured one at a time. = It's so labor-intensive, that administrators minimize the number of=20 tunnels be defining hub-and-spoke topologies for any VPN that is large=20 enough. There is another problem that stems from the same state of standards and = products - that IPsec is hardly ever used between administrative=20 domains. Solving that would be great, and opportunistic encryption might = be a start. Something with RPKI certificates could make it even better.=20 But that is not the focus of this effort. > It seems > a compromise for convenience at the expense of the intended security > of IPsec, and a continued trend from strict policy range based VPNs to > loose routing based VPNs, reducing IPsec to a virtual private untrusted= > ethernet cable. I don't disagree, but defining the tunnels one at a time sounds more=20 like SNA than TCP/IP. Yoav --------------ms020007060806050104000708 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO4zCC BJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2Ny bC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEB BCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlf sXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5 lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJx ggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRow ggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRo ZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1h aWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFAGpDM J1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq1Gdv IBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg7SQf Oq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWSD//g sWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUswggFH MB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvGeGNk J8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29t L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYB BQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRk VHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3Qu Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1 G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA 8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD 8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxH maWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU 0rD+83X5f27nMIIFIDCCBAigAwIBAgIRAJLy3rLPGBD9qh6TW+ZG9DowDQYJKoZIhvcNAQEF BQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMxMTE3 MDAwMDAwWhcNMTQxMTE3MjM1OTU5WjAgMR4wHAYJKoZIhvcNAQkBFg9zeW5wNzFAbGl2ZS5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCow0TXP0M95fIMY0Fsd3xpZj55 m1mkkKhUWLjVtQcd57MyVmBZNQkAmxp9PrzqdHw5eIIBn1EI9foIoynEnUSZzv6pIEXAqdYu xBH0AdvjoPCzWb9uYrqBtbmxnLh9k9ox1pVJG4hit6WEpK+LZ7uvLj5GUWMdmzghC/+fVEZS W8U62xlhd8Hq8ded9bfqjM4psDgqUubjcCkMIUnkD9yuXhzfzwF0wwtD66vXrUe8T4/m6XHO iIqvvVMjzYyKrdLE7zuPyDcDjkxLCCdi2j4c44anq8Pj/yEh5JGU0XSKSfwm2m0UDHj7P/6u B74JwiAyMtqWzdQBHVOphHKDI0ZTAgMBAAGjggHfMIIB2zAfBgNVHSMEGDAWgBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUq+f5Y55gheJJpWtJDEPf6j2uzhQwDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUC MBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsG AQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBI hkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6 Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJl RW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAaBgNV HREEEzARgQ9zeW5wNzFAbGl2ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBACRvTZSZMhI7HrJr jTpnm5FZXyYwJYVhhc643/94hv8pxAQzIY6vH+BlVwmG4Z0Dt6vWYwaUUYdGmvlH0bti8aql JPe4fUgTxbDlTldhOYfISl3ky9+4CEPg4QvX6tOGIusOrvaIszGUIdvKHzvYM4ZapdTxyFCt oe1RXq/17ifvIklgmuh+QcB1xNBmE3lBNj+Vy8xLvsAQlqf9ZAIcBNL2yQGCaBcr6XoR24/D oCNCTAOCR/J2nN/okuGsEF+kvxP/BCPBnDph9coFLNOEwR4ZataT6H4vq0fwGxm5SROTDYis SUTKc+YYKY2RllEwOxX1NZUSmISuGKrGhr2aCaUxggQcMIIEGAIBATCBqTCBkzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJLy3rLPGBD9qh6TW+ZG9DowCQYF Kw4DAhoFAKCCAkcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMxMjA2MjEyNTQyWjAjBgkqhkiG9w0BCQQxFgQUiEAqT/abBwGj2pO0GxCHVhN2rpswbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB ugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhEAkvLess8YEP2qHpNb5kb0OjCBvAYLKoZIhvcNAQkQAgsxgayggakwgZMxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCS8t6yzxgQ/aoek1vmRvQ6 MA0GCSqGSIb3DQEBAQUABIIBACNmCKyoUXX6b/3brxy55MxQUkE14i7MIjviWKziVaC3DSgv 6mowad5SX1babwQY2v5PQuohbIVQk60Lf6rGG8SEcVdk3bKPQ5ecX7Gal02oUeV1geJzzvkx IMGSmPl3UdEPihneRbj0feTxjxwxyT4yPhMbfkwYgBtvLhpiItpLzed7LsXIG3m30sapuwEC zkqcAnECq2xKy48R87bXjsWAAXclx6HU9mEgqlWhcDREQ6n2K2zlUdwYH1apyDyfDjsqj6jt 5ssCkgFiYtDT3QW5mXbL1WIuwSscrSJI7rbS3BQ9r+2GAtCeNFW0cfztOANJ1mOJHRwJt11p HlyTq9gAAAAAAAA= --------------ms020007060806050104000708-- From fdetienn@cisco.com Fri Dec 6 13:29:26 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643B61AE105 for ; Fri, 6 Dec 2013 13:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmjrzMsAoMA9 for ; Fri, 6 Dec 2013 13:29:23 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7D61AE09C for ; Fri, 6 Dec 2013 13:29:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2691; q=dns/txt; s=iport; t=1386365359; x=1387574959; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SKo2ebocNPsZGXXL0LpzJn/3BA85JKBYwWCP2mGB0Ao=; b=JYHy+nZJvwAHKCtwyMUMPuyJnZNf82e2bTDzewmRk5XwWOxduJRax7GP epVUVV0v1umAMEAzJmacfA4MqtUom+nnu/q39ZK9yIkO6fFNtT6MzdiXm JZHcIHC6Fo0LWxmgXzzsrhb9Jc8kunB4fXBgJgfUB3Pg+qfktNpMI2gxE k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAPhAolKtJXG//2dsb2JhbABZgwc4U7kIgSMWdIIlAQEBBCdSEAIBCBguMiUCBA4FG4dnwGkXji4RAR0zB4MggRMDmBSSE4MpgXE5 X-IronPort-AV: E=Sophos;i="4.93,842,1378857600"; d="scan'208";a="4946086" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-6.cisco.com with ESMTP; 06 Dec 2013 21:29:19 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB6LTJew009365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Dec 2013 21:29:19 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.67]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Fri, 6 Dec 2013 15:29:18 -0600 From: "Frederic Detienne (fdetienn)" To: Michael Richardson Thread-Topic: routing protocols for ADVPN Thread-Index: AQHO8rLOtXCosrwqtkGFSRQjvIGswppIE58A Date: Fri, 6 Dec 2013 21:29:18 +0000 Message-ID: <75B5766D-8A31-4303-8448-7AFC7EFD10D1@cisco.com> References: <19440.1386355293@sandelman.ca> In-Reply-To: <19440.1386355293@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.233.83] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9BB9E1689EA5474A876C88635F665D92@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [IPsec] routing protocols for ADVPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 21:29:26 -0000 Hi Michael, Sorry; I must have missed your email or misunderstood your questions. I fel= t that so far we had received comments asking whether something can be done= but very few on how. I have been traveling and missed a bunch of emails. I= apologize again if I missed them. I will split your answer&questions in multiple pieces. Here is the way we install IKE routes. When a new peer is discovered or when a spoke connects to a hub for the fir= st time, an IKE exchange begins. Assuming certificate authentication here. The exchange roughly looks like this Spoke1 Hub SA prop, KEi, Ni ---> <--- SA, KEr, Nr IDi, cert, SIGi, TSi, TSr, cfg_request (SUBNET_v4,=85) --> <--- IDi, cert, SIGi, TSi, TSr, cfg_reply (SUBNET_v4=3D192.168.0.0/16,= =85) cfg_set (SUBNET_v4=3D192.168.10.0/24) ---> <--- cfg_ack (SUBNET_v4) On the Hub, a dynamic tunnel interface is created on the hub due to authent= ication success. This interface is protected by the IPsec SA negotiated her= e. Assuming this interface gets named Tu1. On the spoke, we can assume the interface preliminary existed since the spo= ke statically knows the hub. Assuming this interface gets named Tu0. This i= nterface is also protected by the IPsec SA's. Notice the SA's have Traffic Selectors protecting GRE traffic from hub to s= poke physical addresses in transport mode (and vice versa). On spoke, IKE installs a prefix in the RIB such that 192.168.0.0 / 16 --> Tu0 On the hub, IKE installs a prefix in the RIB such tat 192.168.10.0 / 24 --> Tu1 I.e. IKE forces the traffic negotiated in the IKE exchange I will add a section to this effect in the draft. best regards, fred >=20 > (thread broken intentionally) >=20 > Frederic Detienne (fdetienn) wrote: >>> ... >>> - No overlay of additional routing protocols is needed. >=20 >=20 >> please note that our proposal does not mandate a routing protocol. We >> also support IKEv2 config exchange and treat the protected subnets as >> "routes" for the tunnel.=20 >=20 > I have no idea how to implement what you described. > This is the problem: we have asked questions, and we keep getting "oh, ye= s, > we can do that", but no actual explanation. >=20 > I'd rather that you had mandated OSPFv2/3 or someso that I could evaluate= the > entire solution. >=20 > --=20 > ] Never tell me the odds! | ipv6 mesh netwo= rks [=20 > ] Michael Richardson, Sandelman Software Works | network archite= ct [=20 > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [=20 > =09 >=20 From fdetienn@cisco.com Fri Dec 6 13:37:50 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD861AE08E for ; Fri, 6 Dec 2013 13:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJVKjDWQSZDH for ; Fri, 6 Dec 2013 13:37:46 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 92E791AE0E0 for ; Fri, 6 Dec 2013 13:37:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1172; q=dns/txt; s=iport; t=1386365861; x=1387575461; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rnsh/HLyYFNdyuqGL7s754RL0Hlh9un0eeEUPNf9ibM=; b=esUbKBVbGJ/lvNbx41gF2hTCuDsj/nsrJK5wBZaZxJVflxNMWEwLF9ox WusZ0Sx8FP2e1V4Jwv6K72jNRDJF+WYxQwPrYLvlgQr8HAi5/trPvpVQ+ XbkQZS/5/jKNOJ9vPkBFVVk41zKPUNM0PUUQWZ7WOpuAlacakQiEDnvyg Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAA1DolKtJXG9/2dsb2JhbABZgwc4U7kIgSMWdIIlAQEBBDo/EAIBCBgeEDIlAgQOBRuHZ8BoF45dMweDIIETA5gUkhODKYIq X-IronPort-AV: E=Sophos;i="4.93,842,1378857600"; d="scan'208";a="4952240" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-7.cisco.com with ESMTP; 06 Dec 2013 21:37:40 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB6Lbejq023660 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Dec 2013 21:37:40 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.67]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Fri, 6 Dec 2013 15:37:39 -0600 From: "Frederic Detienne (fdetienn)" To: Michael Richardson Thread-Topic: routing protocols for ADVPN Thread-Index: AQHO8rLOtXCosrwqtkGFSRQjvIGswppIFfWA Date: Fri, 6 Dec 2013 21:37:39 +0000 Message-ID: <9B680FCE-8C84-4CB0-8772-EA18B853068A@cisco.com> References: <19440.1386355293@sandelman.ca> In-Reply-To: <19440.1386355293@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.233.83] Content-Type: text/plain; charset="us-ascii" Content-ID: <92A1CD8A1783724BAAC8BAE04E2B59A5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [IPsec] routing protocols for ADVPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 21:37:50 -0000 On 06 Dec 2013, at 19:41, Michael Richardson wrote: > ... > I'd rather that you had mandated OSPFv2/3 or someso that I could evaluate= the > entire solution. The point is that we can't mandate that. Each of those protocols have diffe= rent properties and are better suited in various environments. Now to be honest, simple protocols such as BGP work best for scale but many= customers choose their protocol based on what they know best or feel is ea= sier to configure. Now if we impose, say BGP, the many will scream in despair. OTOH, without routing protocol however, those who need 100,000 prefixes to = be routed across their VPN will not easily be served by a pure IKE/IPsec sp= ec. We still have not clarified in the other drafts how to tackle spokes that r= equired hauling several thousand prefixes. thanks, fred > --=20 > ] Never tell me the odds! | ipv6 mesh netwo= rks [=20 > ] Michael Richardson, Sandelman Software Works | network archite= ct [=20 > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [=20 > =09 >=20 From mcr@sandelman.ca Sun Dec 8 10:05:37 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4C81AE05C for ; Sun, 8 Dec 2013 10:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MTg4suxh3P2 for ; Sun, 8 Dec 2013 10:05:36 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 88AB41AE04A for ; Sun, 8 Dec 2013 10:05:36 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0A7542017C for ; Sun, 8 Dec 2013 14:19:05 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 0182C63B89; Sun, 8 Dec 2013 13:05:24 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E6FBE63AEF for ; Sun, 8 Dec 2013 13:05:24 -0500 (EST) From: Michael Richardson To: ipsec@ietf.org In-Reply-To: References: <529DF852.7080706@gmail.com> <45734D87-7B8D-4739-B98C-408FC64BFAD8@vpnc.org> <529E17A4.8090409@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [IPsec] AD VPN: protocol selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 18:05:38 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Saurabh M wrote: > The main reason for our recommendation are: > - It is what customers are asking for. > - We actually prefer that there are 2 separate protocols that co-oper= ate to > build the complete solution as it gives us the flexibility for each o= ne to > exist without mandating the other. 1) If you can can do this as it is, do we actually need to standardize anything? 2) if you can build this in a number of different ways, how will your customer interoperate with another similar solution, should they acquire (or be acquired) another entity that has a similar solution? =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUqS05IqHRg3pndX9AQI09QQAjE9LRBdhui2JeGyaMC4y1VxB64Kklzcx 6x/b8x5kL6DpW5hBdDcziYDqze+FvgWUI/BIe8a5Tv5J/I7Liqa7ZulvUTtCYM8s Y7vW/wrz6S62PiRkaEiVoYyL9Ro833MxrraUSfQKtDhr5I6JRoOxjlzBD7kVK4Oo 1/VWSFsYW04= =IoLp -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Sun Dec 8 10:08:42 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E951AE04A for ; Sun, 8 Dec 2013 10:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cuej_XTyw1h for ; Sun, 8 Dec 2013 10:08:41 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 116941AE03F for ; Sun, 8 Dec 2013 10:08:41 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7EA352017C; Sun, 8 Dec 2013 14:22:06 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 4764163B89; Sun, 8 Dec 2013 13:08:27 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 394F563AEF; Sun, 8 Dec 2013 13:08:27 -0500 (EST) From: Michael Richardson To: "Frederic Detienne \(fdetienn\)" In-Reply-To: <9B680FCE-8C84-4CB0-8772-EA18B853068A@cisco.com> References: <19440.1386355293@sandelman.ca> <9B680FCE-8C84-4CB0-8772-EA18B853068A@cisco.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "" Subject: Re: [IPsec] routing protocols for ADVPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 18:08:43 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Frederic Detienne (fdetienn) wrote: > On 06 Dec 2013, at 19:41, Michael Richardson = wrote: >> ... >> I'd rather that you had mandated OSPFv2/3 or someso that I could eva= luate the >> entire solution. > The point is that we can't mandate that. Each of those protocols have > different properties and are better suited in various environments.=20 So, I should implement all of them the smartphone version? =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUqS1moqHRg3pndX9AQITkQP8Dc1lWn5RFhDRTiAfx3FK5viGq+77mVLB qjPXWI1/Sak0wVeBKk4ktRufyHFeY7XOL+uQ7tJN1Gg0H3ivK0FYjhm7JzxXQ5Eu Uj8DsUyClWcPo3DVaH2MqQTB2Q5HpG7Ct/yN4EhwTSOv/gvt9yNWi2/64gL0V0uN N+f3lI+Qo+w= =2W42 -----END PGP SIGNATURE----- --=-=-=-- From fdetienn@cisco.com Sun Dec 8 10:57:27 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD5C1AE03E for ; Sun, 8 Dec 2013 10:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09ayOf53U8b4 for ; Sun, 8 Dec 2013 10:57:25 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id B08CA1AE021 for ; Sun, 8 Dec 2013 10:57:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1714; q=dns/txt; s=iport; t=1386529041; x=1387738641; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=o2yX0qX2srLrP8nJRJGIdCv/n3vrLDTOA+sYn30RqMs=; b=jiQJlMEHl2nn7caxikIXtoA1mJpYbQQXU0hrG+wg+lu/eeH0tCCElQyR +eBCuW0dH4PpDU9tASFewog/1sVyirP4ak+IvZlFm4HSWRwlU/2sWfikj jQZDv79L77LgAt9a3vWqE+nG+KdQmd8gPCxOWBffbwS9kbl5WJb61piR/ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAE7ApFKtJV2Z/2dsb2JhbABZgwe6G4EXFnSCJQEBAQMBOj8FCwIBCBgeEDIlAgQOBRuHYQbAVxeOOCUzB4MggRMDmBSSE4MpgWg X-IronPort-AV: E=Sophos;i="4.93,852,1378857600"; d="scan'208";a="5219037" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP; 08 Dec 2013 18:57:20 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB8IvKZE031050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 8 Dec 2013 18:57:21 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.67]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Sun, 8 Dec 2013 12:57:20 -0600 From: "Frederic Detienne (fdetienn)" To: Michael Richardson Thread-Topic: routing protocols for ADVPN Thread-Index: AQHO8rLOtXCosrwqtkGFSRQjvIGswppIFfWAgALqNoD//6kSEw== Date: Sun, 8 Dec 2013 18:57:19 +0000 Message-ID: <4DA84062-FA71-4651-9DED-5BAD6FB623BA@cisco.com> References: <19440.1386355293@sandelman.ca> <9B680FCE-8C84-4CB0-8772-EA18B853068A@cisco.com>, <24940.1386526107@sandelman.ca> In-Reply-To: <24940.1386526107@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [IPsec] routing protocols for ADVPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 18:57:27 -0000 > On 08 Dec 2013, at 12:08, "Michael Richardson" wr= ote: >=20 >=20 > Frederic Detienne (fdetienn) wrote: >>> On 06 Dec 2013, at 19:41, Michael Richardson wr= ote: >>> ... >>> I'd rather that you had mandated OSPFv2/3 or someso that I could evalua= te the >>> entire solution. >=20 >=20 >> The point is that we can't mandate that. Each of those protocols have >> different properties and are better suited in various environments. >=20 > So, I should implement all of them the smartphone version? Not at all! This is exactly why the draft does not mandate any routing prot= ocol. The smartphone version can be happily limited to CFG exchange which is part= of IKE. No routing protocol necessary. OTOH, a linux device acting as a router may want to run a routing protocol = over the tunnels if it has to protect a large network (dozens of prefixes o= r more). At this point, what goes into the tunnels is controlled by the rou= ting protocol and DMVPN is simply there to discover the end points, offer s= ecure tunneling or apply additional rules implementing a PAD if sorts (pack= et filters, firewall rules, unicast reverse path checks, ...). Notice the mechanism allows multicast without adding anything to the specif= ication for instance. Whether the branch is a smartphone joining via IGMP or a router relying on = PIM, whether SSM or Sparse or anything else, IKE is free of that. Something that will require further specification in a pure IPsec, selector= -based spec. Thanks, Fred > --=20 > Michael Richardson , Sandelman Software Works=20 >=20 >=20 From paul@cypherpunks.ca Sun Dec 8 11:51:03 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C28B91AE0B9 for ; Sun, 8 Dec 2013 11:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2MUiNgOb2Mk for ; Sun, 8 Dec 2013 11:51:01 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 631D61AE0B5 for ; Sun, 8 Dec 2013 11:51:01 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id E5F7A80A04; Sun, 8 Dec 2013 14:50:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D462F80A03; Sun, 8 Dec 2013 14:50:55 -0500 (EST) Date: Sun, 8 Dec 2013 14:50:55 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Sean Turner In-Reply-To: <33B8DC07-B651-4937-9EE7-845AB0B6509E@ieca.com> Message-ID: References: <33B8DC07-B651-4937-9EE7-845AB0B6509E@ieca.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT Cc: IPsecme WG Subject: Re: [IPsec] 3948 Questionnaire X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 19:51:04 -0000 On Tue, 3 Dec 2013, Sean Turner wrote: > Heres a proposed set of question for RFC 3948 implementers: I'm answering this on behave of The Libreswan Project, a fork of openswan. As the code dealing with 3948 predates the fork, these answers should apply to openswan as well. > The following questions document whether your implementation supports the syntax and semantics of the protocol: > > - Which of the following packet formats does your implementation support: > - UDP-Encapsulated ESP Header Format (y/n): > - IKE Header Format for Port 4500 (y/n): > - NAT-Keepalive Packet Format (y/n): All three are supported. > - Which of the following encapsulation and decapsulation processing rules does your implementation support: > - Auxiliary Processing > - Tunnel Mode Decapsulation NAT Procedure (y/n): > - Transport Mode Decapsulation NAT Procedure (y/n): > - Transport Mode ESP Encapsulation (y/n): > - Transport Mode ESP Decapsulation (y/n): > - Tunnel Mode ESP Encapsulation (y/n): > - Tunnel Mode ESP Decapsulation (y/n): All these are supported. > - Does your implementation support the NAT keepalive procedure? (y/n): Yes > The following questions document whether interoperability has been achieved as well as other intangibles the IESG will be interested. > > - What evidence do you have that your implementation can interoperate with other implementations? We have years of interoperability experience with a wde variety of implementations. Our implemention contains several interoperability fixes for supporting earlier drafts and workarounds for some broken/older devices that we have encountered in the wild. > - In your opinion, are there unused features in the RFC that greatly increase implementation complexity? No there are not, although we do recommend people avoid using transport mode and NAT-T (usually with L2TP) in favour of XAUTH/ModeConfig with tunnel mode. > Additional information (optional): We unfortunately find we still need to support older drafts of this standard for interoperability in the wild, although we will soon cleanup some more of these older versions (specifically the non-floating port version) Paul From mcr@sandelman.ca Sun Dec 8 13:07:45 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8C41AE0F4 for ; Sun, 8 Dec 2013 13:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yB-HE6-TLkmo for ; Sun, 8 Dec 2013 13:07:43 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id BB3771AE0EF for ; Sun, 8 Dec 2013 13:07:43 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1CCE32002D; Sun, 8 Dec 2013 17:21:11 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id B231E63B89; Sun, 8 Dec 2013 16:07:30 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2D1DC63AEF; Sun, 8 Dec 2013 16:07:30 -0500 (EST) From: Michael Richardson To: "\" In-Reply-To: <4DA84062-FA71-4651-9DED-5BAD6FB623BA@cisco.com> References: <19440.1386355293@sandelman.ca> <9B680FCE-8C84-4CB0-8772-EA18B853068A@cisco.com>, <24940.1386526107@sandelman.ca> <4DA84062-FA71-4651-9DED-5BAD6FB623BA@cisco.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "Frederic Detienne \(fdetienn\)" Subject: Re: [IPsec] routing protocols for ADVPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 21:07:45 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Frederic Detienne (fdetienn) wrote: >> On 08 Dec 2013, at 12:08, "Michael Richardson" wrote: >>=20 >>=20 >> Frederic Detienne (fdetienn) wrote: >>>> On 06 Dec 2013, at 19:41, Michael Richardson wrote: >>>> ... >>>> I'd rather that you had mandated OSPFv2/3 or someso that I could e= valuate the >>>> entire solution. >>=20 >>=20 >>> The point is that we can't mandate that. Each of those protocols ha= ve >>> different properties and are better suited in various environments. >>=20 >> So, I should implement all of them the smartphone version? > Not at all! This is exactly why the draft does not mandate any routing > protocol. Again, as I said.=20=20 This protocl is infinitely flexible, which means that there is no interoper= ability.=20 > The smartphone version can be happily limited to CFG exchange which is > part of IKE. No routing protocol necessary.=20 So, how does my smartphone tell your smartphone where it is so that the RTP traffic can flow directly, if neither one of us has a routing protocol, or = if we have different onces? > Whether the branch is a smartphone joining via IGMP or a router relyi= ng > on PIM, whether SSM or Sparse or anything else, IKE is free of that.= =20 I understand that you see modifications of IKE as a challenge. We see modification of anything else as a challenge; and a security threat. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUqTfkYqHRg3pndX9AQLj2wQA0786xb5BG8qP6SvfiTZ0GYFr7iA39FsD xE7fgEWcOOd04/1d7tHcf4D2PyUaI9drvj95BfDH3KCKSnNo9tYaF4VZKuePeq/Q MhSEwZhXgufA3u3BXwQ/jH9G8MK1bWxOUdONJB72lE4HcA5JBZmX+Wo6A4qTmMe/ FUj8Sao93W4= =lG7d -----END PGP SIGNATURE----- --=-=-=-- From fdetienn@cisco.com Sun Dec 8 15:00:14 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3825A1AE159 for ; Sun, 8 Dec 2013 15:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ud3jpf1_LOnP for ; Sun, 8 Dec 2013 15:00:12 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 82AAE1AE153 for ; Sun, 8 Dec 2013 15:00:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3638; q=dns/txt; s=iport; t=1386543608; x=1387753208; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lLxEhyN+gKw9vhUdYdT6rByBk0Gm3JELvmbZwXQysuo=; b=IvM5C+o1cZg7r9LHSe78nhmfAoDZLZgdcu2DKUdGWX/221ZcNCLNhFv5 9hvp3//if/dNGzjGGDoiADTlCppAEmSvW/E+t2hSdi5Ws3Vlfb5+Pl4yC FId/3Pt8jH6HCng4q1kb5FmK+JU9mf686BdKcL+e//d5hFJQDiuWC3E1e Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAHr5pFKtJV2Z/2dsb2JhbABZgweBC7kQgRgWdIIlAQEBAwF5BQsCAQgYLjIlAgQOBRuHYQbAbBeOOCUzB4MggRMDmBSSE4MpgWhC X-IronPort-AV: E=Sophos;i="4.93,853,1378857600"; d="scan'208";a="290272805" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 08 Dec 2013 23:00:07 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB8N06KD016104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 8 Dec 2013 23:00:06 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.67]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Sun, 8 Dec 2013 17:00:06 -0600 From: "Frederic Detienne (fdetienn)" To: Michael Richardson Thread-Topic: routing protocols for ADVPN Thread-Index: AQHO8rLOtXCosrwqtkGFSRQjvIGswppIFfWAgALqNoD//6kSE4AAiPUAgAAfdIA= Date: Sun, 8 Dec 2013 23:00:05 +0000 Message-ID: References: <19440.1386355293@sandelman.ca> <9B680FCE-8C84-4CB0-8772-EA18B853068A@cisco.com>, <24940.1386526107@sandelman.ca> <4DA84062-FA71-4651-9DED-5BAD6FB623BA@cisco.com> <31446.1386536850@sandelman.ca> In-Reply-To: <31446.1386536850@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.115.130] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [IPsec] routing protocols for ADVPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 23:00:14 -0000 On 08 Dec 2013, at 22:07, Michael Richardson wrote: >=20 > Frederic Detienne (fdetienn) wrote: >>> On 08 Dec 2013, at 12:08, "Michael Richardson" = wrote: >>>=20 >>>=20 >>> Frederic Detienne (fdetienn) wrote: >>>>> On 06 Dec 2013, at 19:41, Michael Richardson = wrote: >>>>> ... >>>>> I'd rather that you had mandated OSPFv2/3 or someso that I could eval= uate the >>>>> entire solution. >>>=20 >>>=20 >>>> The point is that we can't mandate that. Each of those protocols have >>>> different properties and are better suited in various environments. >>>=20 >>> So, I should implement all of them the smartphone version? >=20 >> Not at all! This is exactly why the draft does not mandate any routing >> protocol. >=20 > Again, as I said. =20 > This protocl is infinitely flexible, which means that there is no interop= erability.=20 So like=85 everyone implements all the cypher suites in IKE so IKE does no= t work ? or BGP is inflexible and/or there is no interoperability ? Or the= Internet uses a single protocol ? Now if it helps clarifying our position: - no routing protocol is mandatory. It is up to the customer to specify the= adjunction of a routing protocol in their RFP (should they need a routing = protocol) - IKE CFG Exchange MUST be supported as it is defined in IKEv2 and is not s= pecified as optional. >> The smartphone version can be happily limited to CFG exchange which is >> part of IKE. No routing protocol necessary.=20 >=20 > So, how does my smartphone tell your smartphone where it is so that the R= TP > traffic can flow directly, if neither one of us has a routing protocol, o= r if > we have different onces? Because there is no reliance AT ALL on the routing protocol (or IKE CFG pol= icies) between spokes. Between spokes, the only protocols in play are NHRP = and IPsec/IKE as given in draft-detienne. It is NHRP that installs that discovers the shortcut path and the shortcut = policy is installed solely based on that protocol. The routing protocol(s) = (or IKEv2 CFG subnets) is/are irrelevant. >> Whether the branch is a smartphone joining via IGMP or a router relying >> on PIM, whether SSM or Sparse or anything else, IKE is free of that.=20 >=20 > I understand that you see modifications of IKE as a challenge. You are missing the point. We would rather not modify something for the sak= e of it (I do not think any other author would do that). We are however abs= olutely open to discussing a revamp of the encapsulation of our proposal on= the ground of a serious debate. I am politely challenging that draft-sathyanarayan-ipsecme-advpn is called = simple as it misses on many basic things. By the time missing parts are com= pleted, it will be a monster or it will be full of holes and/or quirks. I am just raising to your and the group's attention that draft-detienne cov= ers both the software client and the complex gateway-gateway a finite manne= r. Can someone PLEASE explain me how draft-sathyanarayan covers multicast, sca= lability (more than 256 networks per branch) and dynamic network changes be= hind the spoke ? I will have other questions after that. > We see modification of anything else as a challenge; and a security threa= t. That is another strange point=85 what "else" does draft-detienne "modify" ?= Can you elaborate on that ? thanks, fred > --=20 > Michael Richardson , Sandelman Software Works=20 >=20 >=20 From paul.hoffman@vpnc.org Sun Dec 8 17:04:51 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41AC1AE189 for ; Sun, 8 Dec 2013 17:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4U8LDclNxiJJ for ; Sun, 8 Dec 2013 17:04:50 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BF29D1AE140 for ; Sun, 8 Dec 2013 17:04:50 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rB914fxH073618 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 8 Dec 2013 18:04:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: Date: Sun, 8 Dec 2013 17:04:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6A3A7337-D77F-4CE7-9FE7-60CA0EF0300E@vpnc.org> References: <19440.1386355293@sandelman.ca> <9B680FCE-8C84-4CB0-8772-EA18B853068A@cisco.com>, <24940.1386526107@sandelman.ca> <4DA84062-FA71-4651-9DED-5BAD6FB623BA@cisco.com> <31446.1386536850@sandelman.ca> To: "Frederic Detienne (fdetienn)" X-Mailer: Apple Mail (2.1822) Cc: "" Subject: Re: [IPsec] routing protocols for ADVPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 01:04:52 -0000 On Dec 8, 2013, at 3:00 PM, Frederic Detienne (fdetienn) = wrote: > Now if it helps clarifying our position: Stop this, please. It is rude to hijack a thread that is specifically = for non-authors. If you want to clarify a position, simply update the = draft. To everyone else who is not an author of a draft: please see the first = message in the thread = and = consider voicing your opinion, hopefully without debate from document = authors. --Paul Hoffman= From rsj@cisco.com Mon Dec 9 00:24:36 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916F01AE04C for ; Mon, 9 Dec 2013 00:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5abUTiSqNJJr for ; Mon, 9 Dec 2013 00:24:34 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id C9BBE1ACCF0 for ; Mon, 9 Dec 2013 00:24:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1357; q=dns/txt; s=iport; t=1386577470; x=1387787070; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=G6Gug2CntfBHbuExEEUFUNIN7cefeqeYyzGMZ2XmZwI=; b=e9xjblQ+VaXV/uLsVpl88ZdN9j4R67Ql0aiIXUWLaOsVBSwE160LGXHS XSKRKUvn018yerQO0Dm+cCraejtRmBObAW9c4Fgb76e3j8M0DAojdnliH c34PjGnoeiJFqCaxd+ceRR5HNAPkQIQzEkAJNonsqArmuhNj/Jn5U1qfH 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAC19pVKtJV2Y/2dsb2JhbABZgwc4U7kUgSUWdIIlAQEBAwEBAQE3NAsFBwQCAQgRBAEBCxQJBycLFAkIAgQBDQUIAQuHaAYNwFwXjj8BAR4xAgUGgxqBEwOqJ4MpgXE5 X-IronPort-AV: E=Sophos;i="4.93,856,1378857600"; d="scan'208";a="5315440" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP; 09 Dec 2013 08:24:29 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB98OUcc003986 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Dec 2013 08:24:30 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.23]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 02:24:29 -0600 From: "Rajeshwar Singh Jenwar (rsj)" To: Paul Hoffman , "Frederic Detienne (fdetienn)" Thread-Topic: [IPsec] routing protocols for ADVPN Thread-Index: AQHO9GlF7suMeFOfREyG6skydpkQxJpLcQ0A///Z+8A= Date: Mon, 9 Dec 2013 08:24:28 +0000 Message-ID: References: <19440.1386355293@sandelman.ca> <9B680FCE-8C84-4CB0-8772-EA18B853068A@cisco.com>, <24940.1386526107@sandelman.ca> <4DA84062-FA71-4651-9DED-5BAD6FB623BA@cisco.com> <31446.1386536850@sandelman.ca> <6A3A7337-D77F-4CE7-9FE7-60CA0EF0300E@vpnc.org> In-Reply-To: <6A3A7337-D77F-4CE7-9FE7-60CA0EF0300E@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.64.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [IPsec] routing protocols for ADVPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 08:24:36 -0000 Hi Paul/Community, Discussion on a draft a good thing for whole community and it benefit the= design rationale for future reference. So, discussion on a draft can still go on "in a separate thread" . While people are doing selection on another thread. Most of time, discussion get started with open ended question, revising the= draft may not be equally beneficial. Kind Regards, Raj -----Original Message----- From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Monday, December 09, 2013 6:35 AM To: Frederic Detienne (fdetienn) Cc: Subject: Re: [IPsec] routing protocols for ADVPN On Dec 8, 2013, at 3:00 PM, Frederic Detienne (fdetienn) wrote: > Now if it helps clarifying our position: Stop this, please. It is rude to hijack a thread that is specifically for n= on-authors. If you want to clarify a position, simply update the draft. To everyone else who is not an author of a draft: please see the first mess= age in the thread and consider voicing your opinion, hopefully without debate from = document authors. --Paul Hoffman _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From timo.teras@gmail.com Mon Dec 9 02:02:41 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA001AC403 for ; Mon, 9 Dec 2013 02:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTMMFkpLoTbq for ; Mon, 9 Dec 2013 02:02:39 -0800 (PST) Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 259F81AC3FA for ; Mon, 9 Dec 2013 02:02:38 -0800 (PST) Received: by mail-bk0-f43.google.com with SMTP id mz12so1270000bkb.16 for ; Mon, 09 Dec 2013 02:02:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=Q71D7I7TFA3aiimL1vzQoD7bkqP82D70IsTsM3BYKnQ=; b=i7naoDObqxQVReKmHQwz7DYB9WZEWai+ZX492YTTbuE7cweAwHdRvRNE0ZZvTxHHEk z1wh0+up750e+s/oh39sEG4MOMAuVuyK2Wugp8YAw8NEOseBY02C6LiuUt1du5c0E/5w Vnt8YEO5q/g+8c2Oi8Cz5HlcrO9ELa32/AtITVCZjSikzAkXAG52bU0x29m4geKdVRof KtbyZrK3QC8wYg7B/4LXwUvvqMXLeRhSFJftuw1dDLX4EIv9ZrsuQhkiPflskUE3t0D7 GMTDe3y+cB6GhsQry+n208BR8vUB29JwsKwPJV9ZHttRXpBVfCzCrClL41izYz+rXiqY Vh3w== X-Received: by 10.204.230.197 with SMTP id jn5mr390426bkb.127.1386583353794; Mon, 09 Dec 2013 02:02:33 -0800 (PST) Received: from vostro ([2001:1bc8:101:f402:21c:23ff:fefc:bf0b]) by mx.google.com with ESMTPSA id qg7sm8146411bkb.6.2013.12.09.02.02.33 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Dec 2013 02:02:33 -0800 (PST) Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= Date: Mon, 9 Dec 2013 12:02:26 +0200 From: Timo Teras To: ipsec Message-ID: <20131209120226.71f56ae9@vostro> In-Reply-To: <529E17A4.8090409@gmail.com> References: <529DF852.7080706@gmail.com> <45734D87-7B8D-4739-B98C-408FC64BFAD8@vpnc.org> <529E17A4.8090409@gmail.com> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.20; i486-alpine-linux-uclibc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] AD VPN: protocol selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 10:02:41 -0000 On Tue, 03 Dec 2013 19:40:52 +0200 Yaron Sheffer wrote: > We would like to ask people who are *not* authors on any of the > solution drafts to send a short message to the list, saying which of > the three they prefer, and a few reasons for their choice. > > A quick process reminder: once we adopt a protocol, it becomes the > starting point for the working group document. The WG can change the > editor team and is free to make material changes to the protocol > before it is published as RFC. My preference is on draft-detienne-dmvpn-00 to be used as a BASIS: - The model is layered properly. - It does not try to make IKE a routing protocol, or SPD a full blown routing table. - Existing routing protocols can be used to setup active/backup gateway nodes or multipath routes for given prefix, as well as multicast routing (all these and more without additional IKE extensions) - Dynamic routing of prefixes, allowing simpler and more flexible hub-to-hub configuration. - Multiple inter-operable implementations exists. - Large installations exists, proving scalability. Granted, the current draft misses still a lot of details. Especially useful would be to have exact specification on how "thin" client can work without routing protocols (e.g. mode config push of static routes), how to setup NHS topology, what security measures are needed to make sure nodes cannot impersonate someone else. DMVPN properly addresses the complex requirement in RFC7018 2.2. "[...] the routing implications of gateway-to-gateway communication need to be addressed." which I think is one of the hardest issues here. - Timo PS. Please do not reply to this email. It merely reflects my personal preference and opinion as requested. Non-authors can freely write in reply to the original poll explaining why they like something else; authors can freely update their drafts and publish them on separate thread. And yes, I have bias towards DMVPN having implemented parts of it. But I believe similar bias exists when IKE implementers prefer doing everything in IKE. From kivinen@iki.fi Mon Dec 9 04:31:15 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733061AE291 for ; Mon, 9 Dec 2013 04:31:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDWeZVqxaGBz for ; Mon, 9 Dec 2013 04:31:14 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id A23861AE268 for ; Mon, 9 Dec 2013 04:31:13 -0800 (PST) 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 rB9CV4uA011337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 9 Dec 2013 14:31:04 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id rB9CV4HQ020105; Mon, 9 Dec 2013 14:31:04 +0200 (EET) 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: <21157.47112.206842.416822@fireball.kivinen.iki.fi> Date: Mon, 9 Dec 2013 14:31:04 +0200 From: Tero Kivinen To: Johannes Merkle In-Reply-To: <52A079E5.9060009@secunet.com> References: <21124.6276.800771.457943@fireball.kivinen.iki.fi> <52A079E5.9060009@secunet.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 3 min Cc: ipsec@ietf.org Subject: Re: [IPsec] New drafts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:31:15 -0000 Johannes Merkle writes: > Tero Kivinen schrieb am 14.11.2013 01:25: > > I also updated the signature authentication draft by adding the > > section about the public key selection methods, and I also added the > > binary objects for the commonly used signature ASN.1 objects. If > > someone has any way to verify those (especially the RSASSA-PSS method > > with parameters), that would be really good. > > > > Tero, I just had a closer look at the IANA considerations section. > Isn't the new auth method Digital Signature missing? Ups, missed that, added it now: ---------------------------------------------------------------------- This specification also allocates one new IKEv2 Notify Message Types - Status Types value for the SIGNATURE_HASH_ALGORITHMS, and adds new value "Digital Signature" to the IKEv2 Authentication Method registry. -- kivinen@iki.fi From internet-drafts@ietf.org Mon Dec 9 05:39:32 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12401ADF75; Mon, 9 Dec 2013 05:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8VfpcXJYxOl; Mon, 9 Dec 2013 05:39:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 873E41ADF7B; Mon, 9 Dec 2013 05:39:30 -0800 (PST) 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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131209133930.22096.97904.idtracker@ietfa.amsl.com> Date: Mon, 09 Dec 2013 05:39:30 -0800 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-kivinen-ipsecme-signature-auth-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 13:39:33 -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 : Signature Authentication in IKEv2 Author(s) : Tero Kivinen Filename : draft-kivinen-ipsecme-signature-auth-04.txt Pages : 16 Date : 2013-12-09 Abstract: The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA). The current version only includes support for three Elliptic Curve groups, and there is fixed hash algorithm tied to each curve. This document generalizes the IKEv2 signature support so it can support any signature method supported by the PKIX and also adds signature hash algorithm negotiation. This is generic mechanism, and is not limited to ECDSA, but can also be used with other signature algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-kivinen-ipsecme-signature-auth There's also a htmlized version available at: http://tools.ietf.org/html/draft-kivinen-ipsecme-signature-auth-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-kivinen-ipsecme-signature-auth-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mcr@sandelman.ca Mon Dec 9 05:55:39 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F351A1AE2D3 for ; Mon, 9 Dec 2013 05:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44mcyVeR5dQv for ; Mon, 9 Dec 2013 05:55:36 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9AE1AE2DE for ; Mon, 9 Dec 2013 05:55:35 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8867920038; Mon, 9 Dec 2013 10:09:03 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id E200263B89; Mon, 9 Dec 2013 08:55:20 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CDF5663848; Mon, 9 Dec 2013 08:55:20 -0500 (EST) From: Michael Richardson To: "Frederic Detienne \(fdetienn\)" In-Reply-To: References: <19440.1386355293@sandelman.ca> <9B680FCE-8C84-4CB0-8772-EA18B853068A@cisco.com>, <24940.1386526107@sandelman.ca> <4DA84062-FA71-4651-9DED-5BAD6FB623BA@cisco.com> <31446.1386536850@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "" Subject: Re: [IPsec] routing protocols for ADVPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 13:55:39 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Frederic Detienne (fdetienn) wrote: >> Again, as I said. >> This protocl is infinitely flexible, which means that there is no >>interoperability. > So like=E2=80=A6 everyone implements all the cypher suites in IKE so= IKE does > not work ? or BGP is inflexible and/or there is no interoperability ? > Or the Internet uses a single protocol ? We have specified a number of mandatory to implement cipher protocols. IKE *itself* is mandatory if you are doing automatic keying. IKE performs the operation of getting agreement on various things. This is how the Internet works. > Now if it helps clarifying our position: > - no routing protocol is mandatory. It is up to the customer to speci= fy > the adjunction of a routing protocol in their RFP (should they need a > routing protocol) RFP? I speak regularly about the need for specific profiles or applicability statements so that customers can be very clear in their RFPs. You have just turned over the entire test process to the customer: we might as well go home. > - IKE CFG Exchange MUST be supported as it is defined in IKEv2 and is > not specified as optional. I understand that this is going to specify the IP of the virtual interface = on which the routing is going to occur. I don't know how it is going to automatically tune any of the important things, including the way the routi= ng policy is going to be influenced. I also think that you've completely missed how the software is going to get deployed onto mobile devices: it won't be Cisco or Juniper providing some software that installs on an Android or iOS or WinPhone device, it's going = to be Google/Samsung/Motorola/HTC and Apple and Microsoft. The customer's RFP will be limited by what they can get from those companie= s, and if you don't specify it well enough, please expect to make code changes to your core routing platforms to accomodate interoperability issues there. >>> The smartphone version can be happily limited to CFG exchange which= is >>> part of IKE. No routing protocol necessary. >> >> So, how does my smartphone tell your smartphone where it is so that >> the RTP >> traffic can flow directly, if neither one of us has a routing > >protocol, or if >> we have different onces? > Because there is no reliance AT ALL on the routing protocol (or IKE C= FG > policies) between spokes. Between spokes, the only protocols in play > are NHRP and IPsec/IKE as given in draft-detienne. > It is NHRP that installs that discovers the shortcut path and the > shortcut policy is installed solely based on that protocol. The routi= ng > protocol(s) (or IKEv2 CFG subnets) is/are irrelevant. Ah. I see. I don't need a routing protocol, I just need NHRP on the smartphone. Thank you for this clarification. > Can someone PLEASE explain me how draft-sathyanarayan covers multicas= t, > scalability (more than 256 networks per branch) and dynamic network > changes behind the spoke ? I will have other questions after that. multicast is a good question. I would like to understand why 256 networks per branch is an issue beyond t= he problem of IPv4 RFC1918 address space. >> We see modification of anything else as a challenge; and a security >> threat. > That is another strange point=E2=80=A6 what "else" does draft-detienn= e "modify" > ? Can you elaborate on that ? Routing protocols have been deseperately hard to secure. Many organizations that wish to deploy ADVPN mechanisms want to do so across multiple administrative and jurisdictional domains: a group key based mechanism comm= on in OSPF isn't going to pass the security thread analysis. We will need mechanisms such as SIDR (RPKI) achieve the same level of security with a layered approach as we have with star-topology based IKE. And I'm still unclear which routing protocol lets routes for RTP traffic be redirected, but not port-80 (or port-139!) traffic. So there will have to = be extensions there too. =2D- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUqXLxoqHRg3pndX9AQJJ4QP+NJrSjgplZniIqGBrjIh6v3OER2Hp+Ym6 UyykKdY9O5JLuYLvI8N9DW06Uwk7LRuwJNwbdP1njhgtlCF3Onj4z+LwJ2Gi6Ya7 Se1/241ucMFFmsjiHC1A5gEI7UBtM7Msb9OxjZFuQD7mvzrE9Fj+KIxcbODNTkNk MUJZqwtsjBQ= =DOkr -----END PGP SIGNATURE----- --=-=-=-- From kent@bbn.com Mon Dec 9 06:36:48 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C30B1AE2C7 for ; Mon, 9 Dec 2013 06:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ls7iGTW8I-eN for ; Mon, 9 Dec 2013 06:36:46 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id ED47D1ADF34 for ; Mon, 9 Dec 2013 06:36:45 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:54604 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Vq1wt-0007qW-Vt for ipsec@ietf.org; Mon, 09 Dec 2013 09:36:40 -0500 Message-ID: <52A5D578.5060301@bbn.com> Date: Mon, 09 Dec 2013 09:36:40 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: ipsec@ietf.org References: <529DF852.7080706@gmail.com> <45734D87-7B8D-4739-B98C-408FC64BFAD8@vpnc.org> <529E17A4.8090409@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060408050704080105010005" Subject: Re: [IPsec] AD VPN: protocol selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 14:36:48 -0000 This is a multi-part message in MIME format. --------------060408050704080105010005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Saurabh, > Hi, > We'd prefer > dmvpn(http://tools.ietf.org/html/draft-detienne-dmvpn-00) to become > the wg document. > > The main reason for our recommendation are: > > - It is what customers are asking for. > This statement may represent a lot of skew if the sample set if Cisco customers who are told this is an existing solution they can just enable :-). > > - We actually prefer that there are 2 separate protocols that > co-operate to build the complete solution as it gives us the > flexibility for each one to exist without mandating the other. > I worry that DMVPN allocates too much secruity-relevant contorl to the routing sub-system. Thus I prefer ADVPN. > > - It was fairly easy to build a solution using open-nhrp and strongswan. > I thought prior message exchanges indicated that the NHRP being used here included extensions not in the RFC. I prefer choices based on compliance with existing RFCs, or explicitly-declared, new proposals. Hence, I prefer ADVPN. Steve --------------060408050704080105010005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Saurabh,

Hi,
We'd prefer dmvpn( http://tools.ietf.org/html/draft-detienne-dmvpn-00) to become the wg document.
 

The main reason for our recommendation are:

- It is what customers are asking for.

This statement may represent a lot of skew if the sample set if Cisco  customers who are told this is an existing solution they can just enable :-).

- We actually prefer that there are 2 separate protocols that co-operate to build the complete solution as it gives us the flexibility for each one to exist without mandating the other.

I worry that DMVPN allocates too much secruity-relevant contorl to the routing sub-system.  Thus I prefer ADVPN.

- It was fairly easy to build a solution using open-nhrp and strongswan.

I thought prior message exchanges indicated that the NHRP being used here included extensions not in the RFC.  I prefer choices based on compliance with existing RFCs, or explicitly-declared, new proposals.  Hence, I prefer ADVPN.

Steve
--------------060408050704080105010005-- From manishkr@cisco.com Mon Dec 9 08:00:46 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689EF1AE358 for ; Mon, 9 Dec 2013 08:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGjm8kCR6n4H for ; Mon, 9 Dec 2013 08:00:43 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0991AE355 for ; Mon, 9 Dec 2013 08:00:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7834; q=dns/txt; s=iport; t=1386604838; x=1387814438; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=mywcyScEOcJnEl4rD9Qln/9LX3CLNPSP0Xpi+ZjabLs=; b=fZctcu10/22Zqd97lh333TUMmOYo52utM6lqhejTCbbnejai7cNwnlsf e/CXOK9gRWbJXjSUmtoZJZ/lRJ5JsclAkbXGuHrsVQV2FW8vt3iNt4XDx H5mRGybavtxNDMGIuqBC71WJPNmuUi34g+P+9bhoOymFUS4mCha43aCup A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFANTopVKtJXG9/2dsb2JhbABZgweBC7kVgS8WdIIlAQEBBHkSAQgYYCUCBAENBYgCwVUXjjglMweEMwOYFJITgymBaEI X-IronPort-AV: E=Sophos;i="4.93,858,1378857600"; d="scan'208";a="290343119" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 09 Dec 2013 16:00:37 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB9G0bO7002179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Dec 2013 16:00:37 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.73]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 10:00:36 -0600 From: "Manish Kumar (manishkr)" To: Michael Richardson , "Frederic Detienne (fdetienn)" Thread-Topic: [IPsec] routing protocols for ADVPN Thread-Index: AQHO9GlERQK37mflTEq1G1pNiALIZJpMSFsAgAB/LAA= Date: Mon, 9 Dec 2013 16:00:36 +0000 Message-ID: In-Reply-To: <10325.1386597320@sandelman.ca> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.65.79.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <83DD62957C36274AA6C39973116D56F2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [IPsec] routing protocols for ADVPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 16:00:46 -0000 Hi Paul, I'm assuming it's OK to go ahead with discussion on this thread (different from the selection thread). I believe it's still valuable to have the discussion continue while the protocol selection continues. Hi Mark, Inline [Manish]. Thanks, On 09/12/13 7:25 PM, "Michael Richardson" wrote: > >Frederic Detienne (fdetienn) wrote: > >> Again, as I said. > >> This protocl is infinitely flexible, which means that there is no > >>interoperability. > > > So like=8A everyone implements all the cypher suites in IKE so IKE >does > > not work ? or BGP is inflexible and/or there is no >interoperability ? > > Or the Internet uses a single protocol ? > >We have specified a number of mandatory to implement cipher protocols. >IKE *itself* is mandatory if you are doing automatic keying. IKE performs >the operation of getting agreement on various things. This is how the >Internet works. [Manish]: The packet forwarding on a node relies on the routes present in the routing table irrespective of how it's learnt; the relevant routing information between two IPSec peers could, for example, even be static on one end and dynamically learnt on another. There is no need for a 'mandatory' routing protocol because we don=B9t need one. Different parts o= f the networks might be running different routing protocols or even learn routes from out of band means (like static configuration, etc) and that's just fine, I don't see a need for limiting that. > > > Now if it helps clarifying our position: > > > - no routing protocol is mandatory. It is up to the customer to >specify > > the adjunction of a routing protocol in their RFP (should they need >a > > routing protocol) > >RFP? I speak regularly about the need for specific profiles or >applicability statements so that customers can be very clear in their >RFPs. >You have just turned over the entire test process to the customer: we >might >as well go home. [Manish]: Different routing protocols are suitable for different use cases, otherwise we shouldn't have seen these many coming up and widely adopted. Depending on their environment and the used case, one might be more suitable that the other; there's no need to force. > > > - IKE CFG Exchange MUST be supported as it is defined in IKEv2 and >is > > not specified as optional. > >I understand that this is going to specify the IP of the virtual >interface on >which the routing is going to occur. I don't know how it is going to >automatically tune any of the important things, including the way the >routing >policy is going to be influenced. [Manish]: And possibly subnets behind (for a gateway). I'm not sure if I followed the second part here, but If I did, this depends on a number of other things like longer match better metric, etc. > >I also think that you've completely missed how the software is going to >get >deployed onto mobile devices: it won't be Cisco or Juniper providing some >software that installs on an Android or iOS or WinPhone device, it's >going to >be Google/Samsung/Motorola/HTC and Apple and Microsoft. [Manish]: I understand it could be enticing to implement more and more functionalities(and layers) into a single protocol for light devices despite there being protocols doing that pretty well already. This might have its weight but if we had been doing this all these years we wouldn't have seen the Internet grow to where it's today. Also, as someone pointed out earlier, these devices off late are already much more powerful than some of the low end routers. > >The customer's RFP will be limited by what they can get from those >companies, >and if you don't specify it well enough, please expect to make code >changes >to your core routing platforms to accomodate interoperability issues >there. > > >>> The smartphone version can be happily limited to CFG exchange >which is > >>> part of IKE. No routing protocol necessary. > >> > >> So, how does my smartphone tell your smartphone where it is so that > >> the RTP > >> traffic can flow directly, if neither one of us has a routing > > >protocol, or if > >> we have different onces? > > > Because there is no reliance AT ALL on the routing protocol (or IKE >CFG > > policies) between spokes. Between spokes, the only protocols in play > > are NHRP and IPsec/IKE as given in draft-detienne. > > > It is NHRP that installs that discovers the shortcut path and the > > shortcut policy is installed solely based on that protocol. The >routing > > protocol(s) (or IKEv2 CFG subnets) is/are irrelevant. > >Ah. I see. >I don't need a routing protocol, I just need NHRP on the smartphone. >Thank you for this clarification. [Manish]: Well, it's lighter than IKE itself. Further, If you need a certain functionality, you still need to do it regardless of which protocol it's implemented in. There could be additional overhead but this you always have whenever a new protocol is implemented. Keeping it modular keeps it flexible and avoids the need to reinvent the wheel of having to build similar functionality in many protocols. > > > Can someone PLEASE explain me how draft-sathyanarayan covers >multicast, > > scalability (more than 256 networks per branch) and dynamic network > > changes behind the spoke ? I will have other questions after that. > >multicast is a good question. >I would like to understand why 256 networks per branch is an issue beyond >the >problem of IPv4 RFC1918 address space. [Manish]: More than the address space, I don't see how it caters to dynamic network change unless we build the equivalent of a dynamic routing protocol within IKE. > > >> We see modification of anything else as a challenge; and a security > >> threat. > > > That is another strange point=8A what "else" does draft-detienne >"modify" > > ? Can you elaborate on that ? > >Routing protocols have been deseperately hard to secure. Many >organizations >that wish to deploy ADVPN mechanisms want to do so across multiple >administrative and jurisdictional domains: a group key based mechanism >common >in OSPF isn't going to pass the security thread analysis. [Manish]: The routing protocol on the overlay network that is in play here generally (unless you explicitly differentiate it based on a policy) gets the same treatment as the data packets. So, the routing exchanges go over the same tunnel as the data packets; you don't need he mechanisms typically used in a non-secure environment. Additionally, as mentioned earlier, the semantic of the route distribution at the administrative boundaries is total governed by the policies of the involved administrative domains. > >We will need mechanisms such as SIDR (RPKI) achieve the same level of >security with a layered approach as we have with star-topology based IKE. > >And I'm still unclear which routing protocol lets routes for RTP traffic >be >redirected, but not port-80 (or port-139!) traffic. So there will have >to be >extensions there too. [Manish]: The point here is that it's more a general path selection problem better handled in routing than the 'kind of security treatment' a class of traffic receives. Ask yourself the question, given the topology and your end goal, wouldn't you have the same policy with or without IPSec. In the specific example of the need to monitor a class of traffic on the hub while allowing other directly through, given the same topology, you would have likely wanted the same policy even if all this was not IPSec protected. > >-- >Michael Richardson , Sandelman Software Works > > From jfdive@gmail.com Tue Dec 10 06:50:30 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002C51AE109 for ; Tue, 10 Dec 2013 06:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XO0D_o6cYUHp for ; Tue, 10 Dec 2013 06:50:28 -0800 (PST) Received: from mail-vb0-x236.google.com (mail-vb0-x236.google.com [IPv6:2607:f8b0:400c:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC3E1AE105 for ; Tue, 10 Dec 2013 06:50:28 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id g10so601507vbg.41 for ; Tue, 10 Dec 2013 06:50:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BOtqptYnWszcssFy7rtQYpnQKhFS/XW1K2tFfA/lD2Q=; b=0MrogdV+80AKhnRgiXmEO6eBCrIK+SxMqdYUxGefsIutSmugEMeCuJ8v2Va8qBBXWF aCa+TM7LxW3wYHVipxEJ/3mhMIovJ9Zo9u4Wcre8VK021JPMxVFZ3lvZBDpOGpmhyRTf 887Cm2yzJB055e6iOuWNOnFKp+bF/Phlcs7jT6Lcu8RA0D4k++U9MEcaGFop7YrZaTTx yGKfUzJ+PsxP3zq8rVXdfiOhXpPD+oL25bALkr0cg9k9aKYvqpU932NmKnsFuVjjsYx9 C+zlsOnTgk1CBweFbGD3aiKoY2x4WiIaplt0vcR5Yh4IFLMXLFMx0Ls5eLV728EPqY/B yFTg== MIME-Version: 1.0 X-Received: by 10.220.164.202 with SMTP id f10mr1034995vcy.25.1386687023039; Tue, 10 Dec 2013 06:50:23 -0800 (PST) Received: by 10.221.57.197 with HTTP; Tue, 10 Dec 2013 06:50:22 -0800 (PST) Date: Tue, 10 Dec 2013 15:50:22 +0100 Message-ID: From: Jean-Francois Dive To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 10 Dec 2013 08:49:02 -0800 Subject: Re: [IPsec] AD VPN: protocol selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 14:51:22 -0000 Hello ipsec-me, I wanted to chip in as i am following up the debates on this list on the direction the working group is going for. My personal interest comes from the vendor side (ipsec/ike implementation in previous jobs) as well as deployment and design (user side). Full disclosure: i work for Cisco but very far away from product development/standardization, i therefore speak for myself. I think draft-detienne-dmvpn-00 should be the basis for standardization work. My main arguments are: -> clear layer separation: this project in fact create a layer 2 resolution protocol for NBMA networks, i don't see why this should sit within a protocols that is made for key distribution and peer authentication (and possibly security policy distribution, see next point). -> policy enforcement and distribution should not be a main driver for ipsec/ike: today's requirements for security requires deep inspections and all sort of other services (policy mgmt, enforcement and distribution) to be ran across a vpn tunnel, we should focus on just that: the tunnels. -> the more the solution will be self contained in ike the more proprietary extensions will show in the field so that vendors can add their own features, this could affect interoperability. -> topology discovery and reachability management are 2 different things and i believe this proposal's goal is focused on dynamic topology discovery and establishment. Routing protocols solves reachability management if required (redundancy, fast convergence). -> it can be deployed with today's ike / ipsec implementations (for expl no kernel change in linux). -> it does not require specific support for any non ipv4|6 unicast protocols that could be ran on top of the tunnels (mpls / network virtualization, mcast, etc..). -> sitting outside of ike means it can ran without it over ipsec with manual keying. I know a lot of people disregard this but this means this could be applied to other type of environment (military ipsec for expl) which relies on physical keys. -> Scalability / multi-hubs are taken into account. thanks, regards J. From yaronf.ietf@gmail.com Tue Dec 10 13:45:13 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665501AE0B4 for ; Tue, 10 Dec 2013 13:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HduN9-iO8Ac for ; Tue, 10 Dec 2013 13:45:11 -0800 (PST) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 01F761AE04B for ; Tue, 10 Dec 2013 13:45:10 -0800 (PST) Received: by mail-ee0-f53.google.com with SMTP id b57so2520908eek.40 for ; Tue, 10 Dec 2013 13:45:05 -0800 (PST) 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=yaFpnCic/3wn06rFmYfUp+5isEWugJK5Zfr0KhtITLs=; b=uBlhCGOVlidpt9AsgzWMRHEmmUL7R7zjv6EfDC4cpfidxSgkeI1rwXij4UR2XyGHPt ILZitgZVuAmhhOOMSLTMUdVfYXmpsemq34kmLuh4/ga4SXI9g2SJ3+TKvyxHauGyfoRw mH77mSctOLw5SzmgLx4cBA/S0ns5BmPwxE5W5ypJLhj3UFoaOFhzBpLnQmjKFVY6M2uE 4mHZ0kcdteiipKK1tNrgwujVvVYGIXzqL1gswiW4EWJs34+LKMjkxZNNWQl6ib8u+OuH L5g4CaZc5+QNlArdrppeCl37PIMS20uuCL4XbQNBvBd2j6EE+m5gseqw1wmM1s7gEGgO GwBA== X-Received: by 10.14.218.129 with SMTP id k1mr2706887eep.109.1386711905241; Tue, 10 Dec 2013 13:45:05 -0800 (PST) Received: from [10.0.0.2] ([109.65.142.155]) by mx.google.com with ESMTPSA id z42sm45919187eeo.17.2013.12.10.13.45.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Dec 2013 13:45:04 -0800 (PST) Message-ID: <52A78B5F.8040701@gmail.com> Date: Tue, 10 Dec 2013 23:45:03 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Jean-Francois Dive , ipsec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] AD VPN: protocol selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 21:45:13 -0000 Dear AD VPN authors, friends, relatives and colleagues, Please do not turn this selection process into a lobbying effort. The chairs are trying to determine consensus, and this requires reasoned opinions from as many of the group's participants as possible, with emphasis on our regular contributors. What this is not is a vote. Jean-Francois, this mail is not aimed personally at you, and I look forward to have you contribute to this list. I am trying to make a general point here, based on my understanding of IETF process rules. Now back to our regular program: we have had several useful responses on this thread so far, but still too few to determine the group's consensus. Please keep those responses coming! Thanks, Yaron From jfdive@gmail.com Tue Dec 10 14:00:22 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA361AE203 for ; Tue, 10 Dec 2013 14:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugwyEaY2lVUH for ; Tue, 10 Dec 2013 14:00:21 -0800 (PST) Received: from mail-vb0-x22c.google.com (mail-vb0-x22c.google.com [IPv6:2607:f8b0:400c:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 03F921AE20D for ; Tue, 10 Dec 2013 14:00:20 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id x8so1044484vbf.3 for ; Tue, 10 Dec 2013 14:00:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fZuzgULMVPDNNrPErLrTmx3cC71gcLNB9fXA+JINIhk=; b=l53mIyrd4EfReSwp+H3uCs80qo927VvuE9LBkxmYgTxKXGds+wpcxfIo9bBtuFtUzX i1tonZTJU/yy5ULv23UYrVMFElVxk/zdqXFhyfZ007QO8f6f9Svn1RIIJSgulS6kxSDq /TelzyIFNjDK4EklTsqk/znN6DyzQsUof3DntzDojF3oPofeLD6A/AXJyxo1x9msbf0J cI/rilru9TSlO3E4oWExA4fKrs9kcWO3ilIQ6b102svgog722scmg1mqY85Zgf6CaNpz 4j3QVVbO2q/gsGM81TELo2dOw6OMP4mzlEqcldjFINuTS7sugOVZfYEoAlzJ+oTl3Ck5 COMg== MIME-Version: 1.0 X-Received: by 10.221.19.5 with SMTP id qi5mr14695011vcb.15.1386712815507; Tue, 10 Dec 2013 14:00:15 -0800 (PST) Received: by 10.221.57.197 with HTTP; Tue, 10 Dec 2013 14:00:15 -0800 (PST) In-Reply-To: <52A78B5F.8040701@gmail.com> References: <52A78B5F.8040701@gmail.com> Date: Tue, 10 Dec 2013 23:00:15 +0100 Message-ID: From: Jean-Francois Dive To: Yaron Sheffer Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 11 Dec 2013 08:19:14 -0800 Cc: ipsec@ietf.org Subject: Re: [IPsec] AD VPN: protocol selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 22:00:22 -0000 well yaron, i still stand on what i mentioned on the list. I truely didnt saw my email as a cisco trying to defend cisco type of email but something i personally thought (naively as i see) would be food for brain more than food for market battle. On Tue, Dec 10, 2013 at 10:45 PM, Yaron Sheffer wrote: > Dear AD VPN authors, friends, relatives and colleagues, > > Please do not turn this selection process into a lobbying effort. The chairs > are trying to determine consensus, and this requires reasoned opinions from > as many of the group's participants as possible, with emphasis on our > regular contributors. What this is not is a vote. > > Jean-Francois, this mail is not aimed personally at you, and I look forward > to have you contribute to this list. I am trying to make a general point > here, based on my understanding of IETF process rules. > > Now back to our regular program: we have had several useful responses on > this thread so far, but still too few to determine the group's consensus. > Please keep those responses coming! > > Thanks, > Yaron From bew@cisco.com Wed Dec 11 10:45:20 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E149B1AE109 for ; Wed, 11 Dec 2013 10:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCOkCLdd4xWC for ; Wed, 11 Dec 2013 10:45:19 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6AF1AE121 for ; Wed, 11 Dec 2013 10:45:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=771; q=dns/txt; s=iport; t=1386787514; x=1387997114; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=XHdDUqIdzr8+HX02cNZFStSEFHIaqmP+ZqqEzQtgFCo=; b=hANE3fsnYSbFQB5M6PupolvyUo2YhdAiLExqPw2Q6F039fGnLIw3zGSi WmOHdEr+N0WKo7Anne9cDGohjSHNfocN5tO4ZIK/k7GkJg8dvnKz+lVo6 20uQKzrrL0MhErCaFGjFThgt4uyo+aR6PuPoFjGbodNAQVKFnXzj1mnnD E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAP2xqFKrRDoG/2dsb2JhbABZgwe7QRZ0gmaBfYgUAaNAnnUXkjCBEwSJQo5SkhODSg X-IronPort-AV: E=Sophos;i="4.93,873,1378857600"; d="scan'208";a="97644401" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 11 Dec 2013 18:45:13 +0000 Received: from dhcp-128-107-147-18.cisco.com (dhcp-128-107-147-18.cisco.com [128.107.147.18]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBBIj5eU001203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 11 Dec 2013 18:45:12 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8E5210F4-FA57-420E-92B4-5EF40F2B8D39@cisco.com> Date: Wed, 11 Dec 2013 10:45:05 -0800 To: IPsecme WG Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [IPsec] ADVPN Use Cases & proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 18:45:21 -0000 The ADVPN proposals currently state how they believe they meet the = requirements of RFC 7018, but not how well they match each of the actual = use cases. The minutes of the Vancouver meeting record that Steve Hanna = suggested "it might be helpful to have each of proposal teams describe = in more detail how their proposal would address the 3 use cases". There = was some agreement (including from Sean) that this would be valuable = information for the protocol starting point selection process. Yaron & Paul, do you agree and if so can you give the authors some = guidance on what you think would be most useful? E.g., have each = proposal document how RFC7018's three use cases meet the 16+ RFC7108 = requirements, or something else? Thanks, Brian= From paul.hoffman@vpnc.org Wed Dec 11 18:05:28 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98561AE143 for ; Wed, 11 Dec 2013 18:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTW2paMZ8LTj for ; Wed, 11 Dec 2013 18:05:28 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 230D41AE12C for ; Wed, 11 Dec 2013 18:05:28 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rBC25IdM026685 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Dec 2013 19:05:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: <8E5210F4-FA57-420E-92B4-5EF40F2B8D39@cisco.com> Date: Wed, 11 Dec 2013 18:05:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E5210F4-FA57-420E-92B4-5EF40F2B8D39@cisco.com> To: Brian Weis X-Mailer: Apple Mail (2.1822) Cc: IPsecme WG Subject: Re: [IPsec] ADVPN Use Cases & proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 02:05:29 -0000 On Dec 11, 2013, at 10:45 AM, Brian Weis wrote: > The ADVPN proposals currently state how they believe they meet the = requirements of RFC 7018, but not how well they match each of the actual = use cases. The minutes of the Vancouver meeting record that Steve Hanna = suggested "it might be helpful to have each of proposal teams describe = in more detail how their proposal would address the 3 use cases". There = was some agreement (including from Sean) that this would be valuable = information for the protocol starting point selection process. >=20 > Yaron & Paul, do you agree and if so can you give the authors some = guidance on what you think would be most useful? E.g., have each = proposal document how RFC7018's three use cases meet the 16+ RFC7108 = requirements, or something else? That could indeed be useful for the non-authors who are considering = contributing to the current discussion. However, it feels like the = authors have not been very interested in updating their docs when = clarification has been asked for and given on the mailing list, so I am = hesitant to stop the current discussion in order to wait for those. = Personally, I don't think an author sending a message to the mailing = list with their view of the matches; that feels like more advertising = for the current round of questions. Yaron may have a different view. --Paul Hoffman= From mcr@sandelman.ca Wed Dec 11 18:28:35 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1464B1AE1D9 for ; Wed, 11 Dec 2013 18:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7xOkIn80mDw for ; Wed, 11 Dec 2013 18:28:33 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id AEBB31AE1CF for ; Wed, 11 Dec 2013 18:28:33 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 26CB22024A; Wed, 11 Dec 2013 22:42:12 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 1E16463B89; Wed, 11 Dec 2013 21:28:18 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C0CAC63AEF; Wed, 11 Dec 2013 21:28:18 -0500 (EST) From: Michael Richardson To: Brian Weis In-Reply-To: <8E5210F4-FA57-420E-92B4-5EF40F2B8D39@cisco.com> References: <8E5210F4-FA57-420E-92B4-5EF40F2B8D39@cisco.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: IPsecme WG Subject: Re: [IPsec] ADVPN Use Cases & proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 02:28:35 -0000 --=-=-= Brian Weis wrote: > The ADVPN proposals currently state how they believe they meet the > requirements of RFC 7018, but not how well they match each of the > actual use cases. The minutes of the Vancouver meeting record that > Steve Hanna suggested "it might be helpful to have each of proposal > teams describe in more detail how their proposal would address the 3 > use cases". There was some agreement (including from Sean) that this > would be valuable information for the protocol starting point selection > process. > Yaron & Paul, do you agree and if so can you give the authors some > guidance on what you think would be most useful? E.g., have each > proposal document how RFC7018's three use cases meet the 16+ RFC7108 > requirements, or something else? Yes, please revise their ID, add a compliance section or some such. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUqkfQoqHRg3pndX9AQJ15gQAwBZCYWnUen+NbuIcjORsdhDmJm+JeHcU xbe213fM8h1H2Eqb6FdTz7dOWf5uZgYHBBsO3UWz2hgYDdlLhP4hyfKlVN4PrjhO esV7YW7RW82jBKbgv3NTXq0Kf5dcjt8o3TFvXc24/qaE9YH6LBfN9ZPY3ODLPFfG Ny06AC3KRlA= =Cm0Z -----END PGP SIGNATURE----- --=-=-=-- From paul.hoffman@vpnc.org Fri Dec 13 09:03:30 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E2E1ADF7E for ; Fri, 13 Dec 2013 09:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUtWuSzFOVQA for ; Fri, 13 Dec 2013 09:03:25 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 985A11ADF5E for ; Fri, 13 Dec 2013 09:03:25 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rBDH3Ggd011480 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 13 Dec 2013 10:03:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: <45734D87-7B8D-4739-B98C-408FC64BFAD8@vpnc.org> Date: Fri, 13 Dec 2013 09:03:15 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <17BB728F-4CBE-4CD1-9B80-54D5005003CC@vpnc.org> References: <529DF852.7080706@gmail.com> <45734D87-7B8D-4739-B98C-408FC64BFAD8@vpnc.org> To: ipsec X-Mailer: Apple Mail (2.1822) Subject: [IPsec] AD VPN: protocol selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 17:03:30 -0000 This time coming from the co-chair. We have not gotten enough interest = from non-authors (or the folks who work for vendors sponsoring the = proposals) to feel comfortable declaring consensus. We really want to = hear from more of the hundreds of people on the mailing list before we = declare consensus or give up at this late date. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Dear IPsecME folks, There is clear working group interest in a standard auto-discovery VPN = solution. We have agreed-upon requirements [1]. And we have 3 serious = contenders [2] [3] [4] for the solution. It is time to select a protocol = to adopt into the working group. We would like to ask people who are *not* authors on any of the solution = drafts to send a short message to the list, saying which of the three = they prefer, and a few reasons for their choice. Please do *not* send mail saying which of the protocols you do *not* = like - this would be far less useful. And please do not think up a new = solution proposal, it's too late for that. A quick process reminder: once we adopt a protocol, it becomes the = starting point for the working group document. The WG can change the = editor team and is free to make material changes to the protocol before = it is published as RFC. Thanks, Paul and Yaron [1] http://tools.ietf.org/html/rfc7018 [2] http://tools.ietf.org/html/draft-mao-ipsecme-ad-vpn-protocol-02 [3] http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03 [4] http://tools.ietf.org/html/draft-detienne-dmvpn-00 From yaronf.ietf@gmail.com Wed Dec 18 08:16:10 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018E81AE170 for ; Wed, 18 Dec 2013 08:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSmNj8BOI3zN for ; Wed, 18 Dec 2013 08:16:08 -0800 (PST) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id DA6961ADFAD for ; Wed, 18 Dec 2013 08:16:07 -0800 (PST) Received: by mail-ee0-f42.google.com with SMTP id e53so3604721eek.15 for ; Wed, 18 Dec 2013 08:16:05 -0800 (PST) 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=FDtxb/fstkSCjIuH4FErNk4A3n7m2dY7a1XglDgTp7k=; b=mvI7Hrq4Qk18G0Lw9bV943kEz1aC8fu/hWP+yvHWGzIw7VwG5zmDVkpCnP2xHPq88d zEay5azuPnPnvmwh/dZjEHOPQbZxcvm8NKYE3qRc6JOIhvKrQ14dOFH6UFKKHD/FxVCF cUt2xejwDgVnf8z6G+QXb72oxYm6PQVsBvXdq+dWSfJzgEDx+0QTRn+/iRNt+xhqqtzV HL5S2Y5ZjNVaE0kaSdVFy2d8uGGr+bfc/k/bUiobJYqhbKACUo9x2OycnKnv/7/q6TBK 5Yfvt8SfrVtUM4CmaQxaYd9R5vjZ4aoCCpBlHBiPog4Yf/CIz1cPtmQap2UJHR5tpgdz xEmA== X-Received: by 10.15.75.68 with SMTP id k44mr30062816eey.57.1387383365821; Wed, 18 Dec 2013 08:16:05 -0800 (PST) Received: from [10.0.0.9] (46-116-170-86.bb.netvision.net.il. [46.116.170.86]) by mx.google.com with ESMTPSA id 44sm1336265eek.5.2013.12.18.08.16.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Dec 2013 08:16:05 -0800 (PST) Message-ID: <52B1CA44.3090102@gmail.com> Date: Wed, 18 Dec 2013 18:16:04 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: ipsec References: <529DF852.7080706@gmail.com> <45734D87-7B8D-4739-B98C-408FC64BFAD8@vpnc.org> <529E17A4.8090409@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] AD VPN: protocol selection - we're still not done X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 16:16:10 -0000 Hi, To date we have had several good responses on this thread, but unfortunately not enough to gauge the group's consensus. So before you go on a well deserved vacation, please review the candidate protocols and let us know: - Which one would you want as the starting point for an AD VPN RFC? - What are your reasons? Details and links in my original message: http://www.ietf.org/mail-archive/web/ipsec/current/msg08861.html Thanks, Yaron From ivan.ananich@gmail.com Thu Dec 19 02:03:18 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8901AE2B4 for ; Thu, 19 Dec 2013 02:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WfupUGiXZ4B for ; Thu, 19 Dec 2013 02:03:17 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1211AE2BA for ; Thu, 19 Dec 2013 02:03:16 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id n7so351446lam.35 for ; Thu, 19 Dec 2013 02:03:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:message-id:to:subject:mime-version:content-type :content-transfer-encoding; bh=80bDK/vjd6qLmbXxx/EOeARjhyc8zUkHlZF+baZ3paY=; b=Br7I6P1/Yezr4m/vD5cUOi9xdOUl6CR6/NEBwPkPl8wJbgmJuTSTOqn3zPfs4C3IHw 6d5y0Qu9Y2z/Dz2v46+rKjB692O2mVSuvU0Yv+d7Mat8Rq55MgMJ7q33vJPr/HdbMIcX KfXvTQvCc3jBLS2OGntObCi47+yUm8D8/0XFvfI1GSwoiAauqMgY2LKZCAlH9EcWbdI5 khD3M04yWPI3UwtBwOsnUgYSwUalwYhehbF0l8VeOy3WHfaU33jfjyaBgn0edhpzCuSP UyIjv3/QunjBi/td9AJBk9V62TEOk9xeU264UN20Eqg2/+0BVp5nP2pGTvG/sw1U4AU7 z3dA== X-Received: by 10.152.21.3 with SMTP id r3mr287711lae.15.1387447394727; Thu, 19 Dec 2013 02:03:14 -0800 (PST) Received: from [172.16.5.5] ([193.104.149.129]) by mx.google.com with ESMTPSA id j1sm2005723lbl.10.2013.12.19.02.03.13 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 19 Dec 2013 02:03:14 -0800 (PST) Date: Thu, 19 Dec 2013 14:03:12 +0400 From: "=?windows-1251?B?yOLg7SDA7eDt6Pc=?=" X-Priority: 3 (Normal) Message-ID: <1609549225.20131219140312@gmail.com> To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPsec] AD VPN: protocol selection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 10:03:18 -0000 Hi, Ipsec. My name is Ivan Ananich, I work for Joint Stock Company "Moscow Integrated Power Company" in the customer VPN networking division and we have already chosen that technology over barebone IPsec. We vote for technology Flexible Dynamic Mesh VPN (DMVPN). http://tools.ietf.org/html/draft-detienne-dmvpn-00 We think this this is a superior specification that truly integrates networking and security instead of having a security protocol route packets. Customers have invested man-decades of work and millions of $ in validating this solutn (and we do not want our-customers/tax-payers re-doing this on a future unproven technology) We are not interested in debugging/troubleshooting a new implementation of a new protocol when the existing one does everything and more. We want the IETF to confirm to its guiding principals of "rough consensus and running code" --------------------------- Best Regards, Ivan Ananich mailto:Ivan.Ananich@gmail.com From fd@cisco.com Fri Dec 20 04:46:36 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27251AE256 for ; Fri, 20 Dec 2013 04:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.439 X-Spam-Level: X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dujzskW_AUuj for ; Fri, 20 Dec 2013 04:46:35 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 432C91AE270 for ; Fri, 20 Dec 2013 04:46:33 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rBKCkUjU007485 for ; Fri, 20 Dec 2013 13:46:30 +0100 (CET) Received: from ams-fdetienn-8913.cisco.com (ams-fdetienn-8913.cisco.com [10.60.74.180]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id rBKCkCBG025387 for ; Fri, 20 Dec 2013 13:46:22 +0100 (CET) From: Frederic Detienne Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Dec 2013 13:46:12 +0100 References: <20131220123718.4348.59238.idtracker@ietfa.amsl.com> To: " WG" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [IPsec] Fwd: New Version Notification for draft-detienne-dmvpn-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 12:46:36 -0000 Hi, we have published a new version of draft-detienne-dmvpn. The draft is available here for you to review: http://www.ietf.org/internet-drafts/draft-detienne-dmvpn-01.txt We have answered all the comments the best we could. Notably: - We have entirely reworked the ADVPN requirement section - We have clarified the notion of routing policy - We have clarified the processing flow of GRE/IPsec in the context of = RFC 4301 and other security aspects. Thank you, Frederic Detienne Begin forwarded message: > From: > Subject: New Version Notification for draft-detienne-dmvpn-01.txt > Date: 20 Dec 2013 13:37:18 GMT+01:00 > To: Frederic Detienne , Mike Sullenberger = , Manish Kumar >=20 >=20 > A new version of I-D, draft-detienne-dmvpn-01.txt > has been successfully submitted by Frederic Detienne and posted to the > IETF repository. >=20 > Filename: draft-detienne-dmvpn > Revision: 01 > Title: Flexible Dynamic Mesh VPN > Creation date: 2013-12-20 > Group: Individual Submission > Number of pages: 32 > URL: = http://www.ietf.org/internet-drafts/draft-detienne-dmvpn-01.txt > Status: http://datatracker.ietf.org/doc/draft-detienne-dmvpn > Htmlized: http://tools.ietf.org/html/draft-detienne-dmvpn-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-detienne-dmvpn-01 >=20 > Abstract: > The purpose of a Dynamic Mesh VPN (DMVPN) is to allow IPsec/IKE > Security Gateways administrators to configure the devices in a > partial mesh (often a simple star topology called Hub-Spokes) and = let > the Security Gateways establish direct protected tunnels called > Shortcut Tunnels. These Shortcut Tunnels are dynamically created > when traffic flows and are protected by IPsec. >=20 > To achieve this goal, this document extends NHRP ([RFC2332]) into a > routing policy feed and integrates GRE tunneling with IKEv2 and = IPsec > to provide the necessary cryptographic security. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From svanru@gmail.com Tue Dec 24 05:47:40 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8975D1ADF22 for ; Tue, 24 Dec 2013 05:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.338 X-Spam-Level: X-Spam-Status: No, score=0.338 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GT3rYrm0Bo6v for ; Tue, 24 Dec 2013 05:47:39 -0800 (PST) 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 AA2D71ADF64 for ; Tue, 24 Dec 2013 05:47:38 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id eo20so2881174lab.14 for ; Tue, 24 Dec 2013 05:47:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:subject:date:mime-version:content-type :content-transfer-encoding; bh=fTUsmeo4FFMbChtnCL5U8x0Lkzy3722VKGB5Vqat60Y=; b=xxA4XyqGrI94Rkecp/9vsidovUjvC8BIhvmpM9jCghkANzDea8DSsmjTXY49E0dMqp PmXADT0+aeoXk012WT/o7V09RxFrlZfX/xoMp0fU59j+GHVKin9r3phxrddBNhtYs8PY uGbQDPGot8oacD6D2rfdfnvNYvE0EZ8uRhEmAjOYbes8Ku8CYmyBITpxzDRqVETrtBfg agfOOHP8x7c71JuAGxVijCkYb9BxhY9cpTWQRPanWKW1c8RIUP2sME1xXYlCfnUo8e8x wYFvOQtjwyq8VyTXI0jBvmQFtTwbdKP7FB1obMa1TknYw1f3zYsZ3gVZzZTdGi3H3ld3 TrFw== X-Received: by 10.112.136.99 with SMTP id pz3mr13034895lbb.3.1387892854348; Tue, 24 Dec 2013 05:47:34 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id h11sm14010357lbg.8.2013.12.24.05.47.32 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 24 Dec 2013 05:47:33 -0800 (PST) Message-ID: From: "Valery Smyslov" To: Date: Tue, 24 Dec 2013 17:47:30 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; 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: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 13:47:40 -0000 Hi all, I've just posted a draft, defining NULL Authentication method in IKEv2. This method may be used for anonymous access or in situations, when peers don't have any trust relationship, but still want to get protection at least against passive attacks. Regards, Valery. ----- Original Message ----- From: To: "Valery Smyslov" ; "Valery Smyslov" Sent: Tuesday, December 24, 2013 5:40 PM Subject: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-00.txt A new version of I-D, draft-smyslov-ipsecme-ikev2-null-auth-00.txt has been successfully submitted by Valery Smyslov and posted to the IETF repository. Name: draft-smyslov-ipsecme-ikev2-null-auth Revision: 00 Title: The NULL Authentication Method in IKEv2 Protocol Document date: 2013-12-24 Group: Individual Submission Pages: 8 URL: http://www.ietf.org/internet-drafts/draft-smyslov-ipsecme-ikev2-null-auth-00.txt Status: https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-null-auth/ Htmlized: http://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-null-auth-00 Abstract: This document defines the NULL Authentication Method for IKEv2 Protocol. This method provides a way to omit peer authentication in IKEv2 and to explicitely indicate it in the protocol run. This method may be used to preserve anonymity or in situations, where no trust relationship exists between the parties. 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 rickardbrown@hushmail.com Tue Dec 24 10:24:58 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8021AE02D for ; Tue, 24 Dec 2013 10:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_HELO_NEUTRAL=0.112, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJYEvhrVwBzF for ; Tue, 24 Dec 2013 10:24:56 -0800 (PST) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by ietfa.amsl.com (Postfix) with ESMTP id 7832E1AE03E for ; Tue, 24 Dec 2013 10:24:54 -0800 (PST) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by smtp5.hushmail.com (Postfix) with SMTP id DD54860137 for ; Tue, 24 Dec 2013 17:50:43 +0000 (UTC) X-hush-relay-time: 215 X-hush-relay-id: 473ccb327b891ddac9c92aab03ede216 Received: from smtp.hushmail.com (w6.hushmail.com [65.39.178.92]) by smtp5.hushmail.com (Postfix) with ESMTP for ; Tue, 24 Dec 2013 17:50:43 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id BC98B6020E; Tue, 24 Dec 2013 17:50:43 +0000 (UTC) MIME-Version: 1.0 Date: Tue, 24 Dec 2013 17:50:43 +0000 To: ipsec@ietf.org From: rickardbrown@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20131224175043.BC98B6020E@smtp.hushmail.com> Subject: [IPsec] Fake Conferences CSCI and WORLDCOMP of Hamid Arabnia X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 18:24:58 -0000 Fake Conferences CSCI and WORLDCOMP of Hamid Arabnia Hamid Arabnia from University of Georgia is well known for his fake WORLDCOMP conferences https://sites.google.com/site/dumpconf This website has an open challenge posted sometime in 2012 and it also has comments from several well-known researchers on WORLDCOMP. Hamd Arabnia never responded to these because his conferences are bogus. Hamid Arabnia (the money hungry professor) has recently started 2014 International Conference on Computational Science and Computational Intelligence (CSCI'14) http://www.americancse.org to deceive researchers further. CSCI'14 is started under the title of “American Council on Science and Education” which is a dummy corporation (does not exist anywhere in the world). Hamid Arabnia buried his name in the list of names of other innocent steering and program committee members of CSCI’14 to avoid any special attention. He knows that if his name is given any special attention then researchers immediately notice that the conference is fake due to his “track record” with WORLDCOMP. Hamid Arabnia (Guru of Fake Conferences and champion of academic scam) spoiled the reputations and careers of many authors who submitted papers to his infamous WORLDCOMP for more than a decade and he is now ready to do the same using CSCI. Interestingly, CSCI is scheduled to be held at the same venue where WORLDCOMP was held until 2012. CSCI has no general chair. It has no physical person’s name or physical address or phone number to contact. Only contact address is an email address. Hamid Arabnia and his puppets answer the emails, if needed, using fake names. Do not spoil your resume by submitting your papers in this bogus conference CSCI which will not be held beyond 2014. CSCI will not be indexed by DBLP. Recently, Hamid Arabnia paid money and published few “news articles” claiming him a victim of online harassment and cyber bullying. Now he started posting (using fake names and through his puppets) in various emails, blogs and forums, referring to those “news articles” and trying to get back sympathy and trust of the research community to make his CSCI successful. Hamid Arabnia is a Wolf in a Sheep’s skin. We challenge Hamid Arabnia to openly publish the names and affiliation details of the reviewers for thousands of research papers submitted to WORLDCOMP for the last thirteen years. We also challenge Hamid Arabnia to openly publish all the reviews (after removing authors identification details) for all the thousands of research papers submitted to WORLDCOMP for the last thirteen years. There are more challenges at https://sites.google.com/site/moneycomp1 We know that he never accepts these challenges because there were no reviews and no reviewers and he simply cheated the research community for all these years. We are not surprised if he comes out tomorrow claiming that his computer crashed and he lost the reviews and reviewers’ details. He can play any deceiving trick. See the important website https://sites.google.com/site/worlddump1 for more information on WORLDCOMP, including links to DBLP stop indexing WORLDCOMP proceedings. See http://worldcomp-fake-bogus.blogspot.com for Hamid Arabnia and his puppet’s Anti-Christmas Greetings campaign. We ask Hamid Arabnia and his puppets to address the above issues and challenges before posting any other message. Do not spoil your resume by publishing in the fake conferences of Hamid Arabnia. Sincerely, Many researchers cheated by the conferences of Hamid Arabnia From yaronf.ietf@gmail.com Tue Dec 24 14:42:59 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F131AE0DE for ; Tue, 24 Dec 2013 14:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lv75XVmVOxCB for ; Tue, 24 Dec 2013 14:42:57 -0800 (PST) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC221ADFD4 for ; Tue, 24 Dec 2013 14:42:57 -0800 (PST) Received: by mail-ea0-f182.google.com with SMTP id a15so3085002eae.41 for ; Tue, 24 Dec 2013 14:42:53 -0800 (PST) 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=IJco85wV2andHoDXOivS6nEBdj3gmlXu1S7+YUSOTNM=; b=IR5zIvrlfN+9Sm5yBFTEoZFAZtZz0ujgUkoaulmbI/bSInFi0FHkMJAUvRbIeS0XTt rb/73jiSPONNwHg39yGy7OdxrxkSFhW2n7VlkPdD+bQPSZ2Rm6vaNaONnNGqZbNfYdUB xxVocbq/Zno/jvfc1EcelSBLB6Df7Dns1o6LARyaNU3is8EiQzmDixA8j+4dI0IDNoDc 5GF1dYi6cG2TqP7YPke/7wLIOrfXt16pV+UFREWaxl29rEy/sTqejcMndZZNHKrQN04x VjC5zKVQ+8i4+BkMxoBqAa2we6jKUxKuQ74UEeVSfBpwxzDLoGV0Qcr+MUK5dNroY+tA GChw== X-Received: by 10.15.54.72 with SMTP id s48mr29713655eew.3.1387924973021; Tue, 24 Dec 2013 14:42:53 -0800 (PST) Received: from [10.0.0.6] (bzq-79-180-155-33.red.bezeqint.net. [79.180.155.33]) by mx.google.com with ESMTPSA id 4sm58745797eed.14.2013.12.24.14.42.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Dec 2013 14:42:51 -0800 (PST) Message-ID: <52BA0DEA.8040404@gmail.com> Date: Wed, 25 Dec 2013 00:42:50 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Valery Smyslov , ipsec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 22:42:59 -0000 Hi Valery, Thanks for posting this draft. One quick comment: the interaction of your proposal with EAP is not clear to me, i.e. when one peer uses Null auth and the other uses EAP. There are cases where this should be forbidden (e.g. MSCHAP, where the unauthenticated peer can mount a dictionary attack) and other cases where this is OK. Specifically, for the methods listed as "safe" in Sec. 4 of RFC 5998, I believe this use would be secure. Happy holidays! Yaron On 12/24/2013 03:47 PM, Valery Smyslov wrote: > Hi all, > > I've just posted a draft, defining NULL Authentication method in IKEv2. > This method may be used for anonymous access or in situations, > when peers don't have any trust relationship, but still want > to get protection at least against passive attacks. > > Regards, > Valery. > > > ----- Original Message ----- From: > To: "Valery Smyslov" ; "Valery Smyslov" > Sent: Tuesday, December 24, 2013 5:40 PM > Subject: New Version Notification for > draft-smyslov-ipsecme-ikev2-null-auth-00.txt > > > > A new version of I-D, draft-smyslov-ipsecme-ikev2-null-auth-00.txt > has been successfully submitted by Valery Smyslov and posted to the > IETF repository. > > Name: draft-smyslov-ipsecme-ikev2-null-auth > Revision: 00 > Title: The NULL Authentication Method in IKEv2 Protocol > Document date: 2013-12-24 > Group: Individual Submission > Pages: 8 > URL: > http://www.ietf.org/internet-drafts/draft-smyslov-ipsecme-ikev2-null-auth-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-null-auth/ > Htmlized: > http://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-null-auth-00 > > > Abstract: > This document defines the NULL Authentication Method for IKEv2 > Protocol. This method provides a way to omit peer authentication in > IKEv2 and to explicitely indicate it in the protocol run. This > method may be used to preserve anonymity or in situations, where no > trust relationship exists between the parties. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From svanru@gmail.com Tue Dec 24 21:19:02 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F4D1AE201 for ; Tue, 24 Dec 2013 21:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRkqwuOhjPGb for ; Tue, 24 Dec 2013 21:19:00 -0800 (PST) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id CA9301AE1F9 for ; Tue, 24 Dec 2013 21:18:59 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id n7so3115356lam.2 for ; Tue, 24 Dec 2013 21:18:55 -0800 (PST) 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=LxpcpHmIVj5HdMNcuoVeSEqkXcSHixbwIRq2R53ght8=; b=FGvafPaeXMXbXOq/OBgNcCfOtOiS0DRc560cAKKZRYtlIsfps1W4NWWXwD9PhyTBRN RSHjw9BM1whnF7V+Dsa/cGVYLV9fbJo+FQq/7ak3wzepLNjoI48+ow/BzFKXVdOw/GWw IgwXhjW91ghn/Bq6gKivh31LwIoXR8idnBls4ozzZStrdIOKjHQXzgc/gz/Q5+Xnp6q1 /m2HIgSoSU69GsV6G2BbpBvn5ygTyKtUXJoOnTIDYrkO4ZxGLQRCKQ2LdbUASugT0RpW F0YQkjRQzfA/kTnn1pgoESWippPsx04AJI9mP7iHixrN7CChbQ0NHtve+nkP1hToZiq/ /79A== X-Received: by 10.112.17.39 with SMTP id l7mr112021lbd.51.1387948735339; Tue, 24 Dec 2013 21:18:55 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id r10sm19871572lag.7.2013.12.24.21.18.53 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 24 Dec 2013 21:18:54 -0800 (PST) Message-ID: <01E73A999255430F803315D676238C09@buildpc> From: "Valery Smyslov" To: "Yaron Sheffer" , References: <52BA0DEA.8040404@gmail.com> Date: Wed, 25 Dec 2013 09:18:52 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response 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] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2013 05:19:02 -0000 Hi Yaron, > Hi Valery, > > Thanks for posting this draft. > > One quick comment: the interaction of your proposal with EAP is not clear > to me, i.e. when one peer uses Null auth and the other uses EAP. There are > cases where this should be forbidden (e.g. MSCHAP, where the > unauthenticated peer can mount a dictionary attack) and other cases where > this is OK. Specifically, for the methods listed as "safe" in Sec. 4 of > RFC 5998, I believe this use would be secure. Actually, I think that NULL Auth should not be used with EAP. Section 2.16 of RFC5996 states: In addition to authentication using public key signatures and shared secrets, IKE supports authentication using methods defined in RFC 3748 [EAP]. Typically, these methods are asymmetric (designed for a user authenticating to a server), and they may not be mutual. For this reason, these protocols are typically used to authenticate the initiator to the responder and MUST be used in conjunction with a public-key-signature-based authentication of the responder to the initiator. I agree with you, that in some cases using NULL Auth with EAP might be secure, but as IKEv2 already requires responder to use signature auth with EAP, I don't see any reason to change it. Do you think it's worth to mention that in the draft and provide a reference to the text from RFC5996? > Happy holidays! > Yaron Happy New Year! Valery. > On 12/24/2013 03:47 PM, Valery Smyslov wrote: >> Hi all, >> >> I've just posted a draft, defining NULL Authentication method in IKEv2. >> This method may be used for anonymous access or in situations, >> when peers don't have any trust relationship, but still want >> to get protection at least against passive attacks. >> >> Regards, >> Valery. >> >> >> ----- Original Message ----- From: >> To: "Valery Smyslov" ; "Valery Smyslov" >> Sent: Tuesday, December 24, 2013 5:40 PM >> Subject: New Version Notification for >> draft-smyslov-ipsecme-ikev2-null-auth-00.txt >> >> >> >> A new version of I-D, draft-smyslov-ipsecme-ikev2-null-auth-00.txt >> has been successfully submitted by Valery Smyslov and posted to the >> IETF repository. >> >> Name: draft-smyslov-ipsecme-ikev2-null-auth >> Revision: 00 >> Title: The NULL Authentication Method in IKEv2 Protocol >> Document date: 2013-12-24 >> Group: Individual Submission >> Pages: 8 >> URL: >> http://www.ietf.org/internet-drafts/draft-smyslov-ipsecme-ikev2-null-auth-00.txt >> >> Status: >> https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-null-auth/ >> Htmlized: >> http://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-null-auth-00 >> >> >> Abstract: >> This document defines the NULL Authentication Method for IKEv2 >> Protocol. This method provides a way to omit peer authentication in >> IKEv2 and to explicitely indicate it in the protocol run. This >> method may be used to preserve anonymity or in situations, where no >> trust relationship exists between the parties. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Tue Dec 24 21:41:43 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86541AE21A for ; Tue, 24 Dec 2013 21:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_39=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20yL-Imw85Df for ; Tue, 24 Dec 2013 21:41:41 -0800 (PST) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id EF1E71AE207 for ; Tue, 24 Dec 2013 21:41:40 -0800 (PST) Received: by mail-ea0-f173.google.com with SMTP id o10so3108846eaj.18 for ; Tue, 24 Dec 2013 21:41:36 -0800 (PST) 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=8q78Xvt/9ttVXzH+ljoExXj4NSdqRUli4ckUlVwV8os=; b=RRbZSLSVhvQK+YXnURfFR8h5QROuYU83UrviQZ2e5TIQypJRcDr38Gcj4FV9+mrH0S UNqvk6BjcgCyxq9zV/4OJZlBT7Qn8EF7gdUC1tbCakijoDMI9ZvTUFf6E06dKHL3a+kI cOvwJvuxAj3buktGTa0f7GQiZn5i+pp8s2c9A4piAL9kk+I8h2+zicm7IBMbMnP7PaFm ecIaGcBtBx9j7MrRs6bHMBP3RV2AmFD3JspQcWzJlwPZG/pgEdmo+kuzVAUUTr6+KuUA Q9qj60u4Fu1Zj/3OVVInUJzLq92UDpc8l0sXNoRvFUuBF5oKeGd66HQhcnxgONriVVgA bfyA== X-Received: by 10.14.204.135 with SMTP id h7mr299421eeo.104.1387950096633; Tue, 24 Dec 2013 21:41:36 -0800 (PST) Received: from [10.0.0.6] (bzq-79-180-155-33.red.bezeqint.net. [79.180.155.33]) by mx.google.com with ESMTPSA id l4sm60914715een.13.2013.12.24.21.41.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Dec 2013 21:41:36 -0800 (PST) Message-ID: <52BA700E.5040909@gmail.com> Date: Wed, 25 Dec 2013 07:41:34 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Valery Smyslov , ipsec@ietf.org References: <52BA0DEA.8040404@gmail.com> <01E73A999255430F803315D676238C09@buildpc> In-Reply-To: <01E73A999255430F803315D676238C09@buildpc> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2013 05:41:43 -0000 Hi Valery, Yes, between EAP+signature (RFC 5996) and EAP+EAP (RFC 5998), there's very little justification for EAP+null, and it is very likely to create security issues. I think we should mention EAP, and expressly forbid it in this context (MUST NOT). Thanks, Yaron On 12/25/2013 07:18 AM, Valery Smyslov wrote: > Hi Yaron, > >> Hi Valery, >> >> Thanks for posting this draft. >> >> One quick comment: the interaction of your proposal with EAP is not >> clear to me, i.e. when one peer uses Null auth and the other uses EAP. >> There are cases where this should be forbidden (e.g. MSCHAP, where the >> unauthenticated peer can mount a dictionary attack) and other cases >> where this is OK. Specifically, for the methods listed as "safe" in >> Sec. 4 of RFC 5998, I believe this use would be secure. > > Actually, I think that NULL Auth should not be used with EAP. > Section 2.16 of RFC5996 states: > > In addition to authentication using public key signatures and shared > secrets, IKE supports authentication using methods defined in RFC > 3748 [EAP]. Typically, these methods are asymmetric (designed for a > user authenticating to a server), and they may not be mutual. For > this reason, these protocols are typically used to authenticate the > initiator to the responder and MUST be used in conjunction with a > public-key-signature-based authentication of the responder to the > initiator. > > I agree with you, that in some cases using NULL Auth with EAP > might be secure, but as IKEv2 already requires responder > to use signature auth with EAP, I don't see any reason to change it. > > Do you think it's worth to mention that in the draft and provide > a reference to the text from RFC5996? > >> Happy holidays! > >> Yaron > > Happy New Year! > > Valery. > >> On 12/24/2013 03:47 PM, Valery Smyslov wrote: >>> Hi all, >>> >>> I've just posted a draft, defining NULL Authentication method in IKEv2. >>> This method may be used for anonymous access or in situations, >>> when peers don't have any trust relationship, but still want >>> to get protection at least against passive attacks. >>> >>> Regards, >>> Valery. >>> >>> >>> ----- Original Message ----- From: >>> To: "Valery Smyslov" ; "Valery Smyslov" >>> Sent: Tuesday, December 24, 2013 5:40 PM >>> Subject: New Version Notification for >>> draft-smyslov-ipsecme-ikev2-null-auth-00.txt >>> >>> >>> >>> A new version of I-D, draft-smyslov-ipsecme-ikev2-null-auth-00.txt >>> has been successfully submitted by Valery Smyslov and posted to the >>> IETF repository. >>> >>> Name: draft-smyslov-ipsecme-ikev2-null-auth >>> Revision: 00 >>> Title: The NULL Authentication Method in IKEv2 Protocol >>> Document date: 2013-12-24 >>> Group: Individual Submission >>> Pages: 8 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-smyslov-ipsecme-ikev2-null-auth-00.txt >>> >>> >>> Status: >>> https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-null-auth/ >>> Htmlized: >>> http://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-null-auth-00 >>> >>> >>> Abstract: >>> This document defines the NULL Authentication Method for IKEv2 >>> Protocol. This method provides a way to omit peer authentication in >>> IKEv2 and to explicitely indicate it in the protocol run. This >>> method may be used to preserve anonymity or in situations, where no >>> trust relationship exists between the parties. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec > From paul@nohats.ca Mon Dec 30 16:44:53 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011F61AE332 for ; Mon, 30 Dec 2013 16:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.162 X-Spam-Level: X-Spam-Status: No, score=0.162 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9Khj4sUEGkG for ; Mon, 30 Dec 2013 16:44:50 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDC81AE228 for ; Mon, 30 Dec 2013 16:44:48 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 9138280055; Mon, 30 Dec 2013 19:44:41 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1388450681; bh=Yk/0fzW7BuuS3f3I40ruAVRyc7rd3ni7srBPjoiDVvE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=h9Y91CF5ilM0rEJYE4OLG/q0hh1LhnIhdIh808FhJJTiQxvY/QHCV50kbErhHKuEP 0zsVf849EtCJhCLtU8q4BIVIacfzUyI+OM4jaMOGh3InXcj/z9jgh70mAZqZx/On9b E5Oy7QrJty6qlfOh4ZeuFc518LBje4kqunxsdvXw= Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8160B80048; Mon, 30 Dec 2013 19:44:41 -0500 (EST) Date: Mon, 30 Dec 2013 19:44:41 -0500 (EST) From: Paul Wouters To: Valery Smyslov In-Reply-To: Message-ID: References: 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 Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 00:44:53 -0000 On Tue, 24 Dec 2013, Valery Smyslov wrote: > I've just posted a draft, defining NULL Authentication method in IKEv2. > This method may be used for anonymous access or in situations, > when peers don't have any trust relationship, but still want > to get protection at least against passive attacks. This is what we (libreswan) have started implementing as well, although we called it AUTH_NONE instead of AUTH_NULL. We use private range number 201 for this exchange type. We also followed the PSK exchange method. But we are still looking at some issues and therefor have not yet written out our implementation as draft yet. For those interested, libreswan developers are meeting up in San Francisco in the second and third week of January to work on OE (both anonymous and authenticated). Ping me if you would like to attend. Valery's draft is a start, but we need to address a lot more than just defining a new IKEv2 AUTH method: 1) Use of IDs I don't think we should allow any IDs, as there could be conflicts with other non-anonymous connections. Or possibly a way to detect which non-anonymous IDs are accepted at the remote. I was leaning towards mandating the ID to be "anonymous" to make it extremely clear that this is an anonymous connection. 2) Endpoints Your draft does not state anything about the traffic selectors. I think it is important to specify it for only a single host-to-host connection only. Deployments who want to protect a whole subnet can use similar tricks to load balancers and capture port (4)500 and use the NAT-T capability of IPsec. Allowing subnet-to-subnet is just too dangerous because there are no verifiable claims yet about who owns what IP range. 3) Mode I would like to only support tunnel mode and not transport mode, due to the interaction with NATs - particularly multiple endpoints behind the same NAT router. We would hope this happens a lot if everyone enables OE (anonymous and non-anonymous). Obviously using AH also makes no sense so we should note that this is only valid for ESP. 4) Mandatory PFS It should be mandatory to do PFS with an appropriate DH group. 5) Priority The priority of the SPDs of any anonymous IPsec connection should be lower than the priority of any non-anonymous SPD. This ensures that an anonymous IPsec connection can never steal traffic from an authenticated IPsec connection. non-anonymous with anonymous IPsec Now this only covers anonymous IPsec. While better than plaintext, we do hope servers with stable hostnames will use IPSECKEY records to provide their public key, and that the clients will mostly use this new auth-none, while the server responds with its FQDN ID so the client can verify the connection is not MITMed. In fact, I think it is better for roaming devices to remain as anonymous as possible by not providing the server with an identity (and why I also do not like your proposal of allowing and ignoring the identity). I have not yet solved the issue of two servers and "return traffic". Say host A on public IP initiates anonymously to host B on public IP. Let's say both are mail servers. Host A has authenticated host B. Host A can now send traffic to host B encrypted. Host B can respond to that traffic. While the tunnel is up, host B needs to connect to host A for unrelated traffic. It has an IPsec connection up, but it has not authenticated this connection. It should not initiate traffic to host A. BTNS tried to solve this problem with changing the kernel and doing channel binding, but I don't think that solution has support anywhere. I can think of some methods on Linux to "hack" detection and support, but I'm not happy about it yet. Evil ranges Another unresolved problem of using tunnel mode is if a client uses somebody elses IP range. eg my laptop behind NAT using 8.8.8.8 should not be able to steal the remote's google DNS traffic. Again, I can see linux hacks to implement this but I'm still not happy with this. One way out is to use CP and assign IP addresses but since our clients and servers will have thousands of these of connections there will be clashes. Using IPv6 is possible but I'm not convinced the v6-in-v4 IPsec has seen enough deployment and might not be implemented widely. Other kinds of semi-anonymous connections We are trying to limit the number of different kinds of OE connections possible to make it as easy as possible to represent things back to the user. So we have left things like "ssh style leap of faith" out of this. Paul From yaronf.ietf@gmail.com Tue Dec 31 00:33:16 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B501AE580 for ; Tue, 31 Dec 2013 00:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUVhWegh1ozm for ; Tue, 31 Dec 2013 00:33:14 -0800 (PST) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id A528B1AE1F5 for ; Tue, 31 Dec 2013 00:33:13 -0800 (PST) Received: by mail-ea0-f176.google.com with SMTP id h14so5397496eaj.7 for ; Tue, 31 Dec 2013 00:33:07 -0800 (PST) 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=9jAiGiNzI57vEZvL0TjNlYn70E0ipWJEZfQLGSPw3sM=; b=qyDTF/73KgCQoE9ctnrO8qVd0MJMQT+8AVWxEFLsPs9j/z85Sx9lyroYV+p8VSDA4h MzyF0FFY9NSpUrnkuwSpLQp6kcP4o0IfgykBuGVoywnk+5NJoJQVQF4KzHRh1/NC6IWJ lalRo9kqu8/Y4Uo04CB/4Hv3XpTg162vmPRwKtyvuXoPDLW61ZqOk8ksBCb5ee/zobYp kpl//0gnF+WoFAnAr9h+b3nvoj5+nLnyiFyTU7drU92v5hKKOeSu9ai2maOzUib0eYph C/J4ih2CdM47h8nLXW+LtAHu+TCZQjb82jQ8eCdZv7xh7Qy8C410pDjaXhUQFAsdoo0y jh0A== X-Received: by 10.14.127.132 with SMTP id d4mr5522467eei.66.1388478787125; Tue, 31 Dec 2013 00:33:07 -0800 (PST) Received: from [10.0.0.5] (85-250-26-178.bb.netvision.net.il. [85.250.26.178]) by mx.google.com with ESMTPSA id b41sm116037783eef.16.2013.12.31.00.33.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 31 Dec 2013 00:33:06 -0800 (PST) Message-ID: <52C28141.5090107@gmail.com> Date: Tue, 31 Dec 2013 10:33:05 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Paul Wouters , Valery Smyslov References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 08:33:16 -0000 Hi Paul, Valery, Regarding IDs, there is value in sending them if you are later able to confirm the identity, or at least "bind" it to the connection. For example, if the human owners of the peers make a phone call and exchange fingerprint values. Or (more far fetched) if both sides use raw public keys, instead of a shared secret, and these PKs are later certified by someone that both peers trust. Calling everyone "anonymous" means that you cannot display *anything* to the user. Regarding single endpoint addresses vs. subnets, we should discuss various ways of proving address "ownership" (whatever that means). For example: random reachability tests, BGP with RPKI. Thanks, Yaron On 12/31/2013 02:44 AM, Paul Wouters wrote: > On Tue, 24 Dec 2013, Valery Smyslov wrote: > >> I've just posted a draft, defining NULL Authentication method in IKEv2. >> This method may be used for anonymous access or in situations, >> when peers don't have any trust relationship, but still want >> to get protection at least against passive attacks. > > This is what we (libreswan) have started implementing as well, although we > called it AUTH_NONE instead of AUTH_NULL. We use private range number 201 > for this exchange type. We also followed the PSK exchange method. But > we are still looking at some issues and therefor have not yet written > out our implementation as draft yet. For those interested, libreswan > developers are meeting up in San Francisco in the second and third week > of January to work on OE (both anonymous and authenticated). Ping me if > you would like to attend. > > Valery's draft is a start, but we need to address a lot more than just > defining a new IKEv2 AUTH method: > > 1) Use of IDs > > I don't think we should allow any IDs, as there could be conflicts with > other non-anonymous connections. Or possibly a way to detect which > non-anonymous IDs are accepted at the remote. I was leaning towards > mandating the ID to be "anonymous" to make it extremely clear that this > is an anonymous connection. > > 2) Endpoints > > Your draft does not state anything about the traffic selectors. I think > it is important to specify it for only a single host-to-host connection > only. Deployments who want to protect a whole subnet can use similar > tricks to load balancers and capture port (4)500 and use the NAT-T > capability of IPsec. Allowing subnet-to-subnet is just too dangerous > because there are no verifiable claims yet about who owns what IP range. > > 3) Mode > > I would like to only support tunnel mode and not transport mode, due to > the interaction with NATs - particularly multiple endpoints behind the > same NAT router. We would hope this happens a lot if everyone enables > OE (anonymous and non-anonymous). Obviously using AH also makes no sense > so we should note that this is only valid for ESP. > > 4) Mandatory PFS > > It should be mandatory to do PFS with an appropriate DH group. > > 5) Priority > > The priority of the SPDs of any anonymous IPsec connection should be > lower than the priority of any non-anonymous SPD. This ensures that > an anonymous IPsec connection can never steal traffic from an > authenticated IPsec connection. > > non-anonymous with anonymous IPsec > > Now this only covers anonymous IPsec. While better than plaintext, > we do hope servers with stable hostnames will use IPSECKEY records to > provide their public key, and that the clients will mostly use this new > auth-none, while the server responds with its FQDN ID so the client can > verify the connection is not MITMed. In fact, I think it is better for > roaming devices to remain as anonymous as possible by not providing > the server with an identity (and why I also do not like your proposal > of allowing and ignoring the identity). > > I have not yet solved the issue of two servers and "return traffic". Say > host A on public IP initiates anonymously to host B on public IP. Let's > say both are mail servers. Host A has authenticated host B. Host A > can now send traffic to host B encrypted. Host B can respond to that > traffic. While the tunnel is up, host B needs to connect to host A > for unrelated traffic. It has an IPsec connection up, but it has not > authenticated this connection. It should not initiate traffic to host A. > BTNS tried to solve this problem with changing the kernel and doing > channel binding, but I don't think that solution has support anywhere. > I can think of some methods on Linux to "hack" detection and support, > but I'm not happy about it yet. > > Evil ranges > > Another unresolved problem of using tunnel mode is if a client uses > somebody elses IP range. eg my laptop behind NAT using 8.8.8.8 should > not be able to steal the remote's google DNS traffic. Again, I can > see linux hacks to implement this but I'm still not happy with this. > One way out is to use CP and assign IP addresses but since our clients > and servers will have thousands of these of connections there will be > clashes. Using IPv6 is possible but I'm not convinced the v6-in-v4 IPsec > has seen enough deployment and might not be implemented widely. > > Other kinds of semi-anonymous connections > > We are trying to limit the number of different kinds of OE connections > possible to make it as easy as possible to represent things back to the > user. So we have left things like "ssh style leap of faith" out of this. > > Paul > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec