From conti@math.unipd.it Sat Mar 3 00:13:53 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C133C21E8078 for ; Sat, 3 Mar 2012 00:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.481 X-Spam-Level: ** X-Spam-Status: No, score=2.481 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcmwTO5TQx8j for ; Sat, 3 Mar 2012 00:13:52 -0800 (PST) Received: from server0.math.unipd.it (server0.math.unipd.it [147.162.22.66]) by ietfa.amsl.com (Postfix) with ESMTP id BDBF021E8028 for ; Sat, 3 Mar 2012 00:13:51 -0800 (PST) Received: from [192.168.0.2] (host245-189-dynamic.52-79-r.retail.telecomitalia.it [79.52.189.245]) (authenticated bits=0) by server0.math.unipd.it (8.14.3/8.14.3) with ESMTP id q238Dk7h050954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Mar 2012 08:13:47 GMT Message-ID: <4F51D2B5.1060202@math.unipd.it> Date: Sat, 03 Mar 2012 09:13:41 +0100 From: "Dr. Mauro Conti" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sat, 03 Mar 2012 10:17:29 -0800 Subject: [IPsec] CFP: The 4th International Conference on Security and Privacy in Mobile Information and Communication Systems X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 08:13:53 -0000 (We apologize if you receive multiple copies of this email) CALL FOR PAPERS =============== The 4th International Conference on Security and Privacy in Mobile Information and Communication Systems Mobisec 2012, Frankfurt, Germany 25 - 27 June 2012 http://mobisec.org/2012 KEYNOTE SPEAKERS ================ * Kim Cameron, Distinguished Engineer and Chief Architect, Microsoft * Prof. Dr. Kai Rannenberg, Deutsche Telekom Chair of Mobile Business & Multilateral Security, Goethe University Frankfurt * Amardeo Sarma, Deputy General Manager, NEC Laboratories SCOPE ===== MobiSec's focus is the convergence of information and communication technology in mobile scenarios. This convergence is realised in intelligent mobile devices, accompanied by the advent of next-generation communication networks. Privacy and security aspects need to be covered at all layers of mobile networks, from mobile devices, to privacy respecting credentials and mobile identity management, up to machine-to-machine communications. In particular, mobile devices such as Smartphones and Internet Tablets have been very successful in commercialization. However, their security mechanisms are not always able to deal with the growing trend of information-stealing attacks. As mobile communication and information processing becomes a commodity, economy and society require protection of this precious resource. Mobility and trust in networking go hand in hand for future generations of users, who need privacy and security at all layers of technology. In addition, the introduction of new data collection practices and data-flows (e.g. sensing data) from the mobile device makes it more difficult to understand the new security and privacy threats introduced. MobiSec strives to bring together the leading-edge of academia and industry in mobile systems security, as well as practitioners, standards developers and policymakers. Contributions may range from architecture designs and implementations to cryptographic solutions for mobile and resource-constrained devices. TOPICS ====== Topics of interest include, but are not limited to, the following focus areas: Smartphone Security and Privacy: * Advanced Security Mechanisms * Virtualisation Solutions * Rogue Mobile Application Detection and Protection * Forensic Analysis Machine-to-Machine Secure Communication: * Device Identities and Authentication * Remote Integrity Validation and Remediation * Remote Management and Provisioning * Machine-to-Machine Application Layer Security * Secure Elements and Trusted Environments Privacy and Security in Emerging Mobile Applications and Services: * Privacy-respecting Authentication * Mobile Identity Management * Mobile Wallets, Mobile Payments * Location-based Services and Mobile Sensing Important Dates =============== Submission Date : Mar. 18, 2012 Notification of acceptance: Apr. 23, 2012 Camera Ready submission : May. 4, 2012 Conference dates : June 25-27, 2012 PUBLICATIONS ============ Accepted papers will be published in Springer's LNICST series and will appear in the SpringerLink, one of the largest digital libraries online that covers a variety of scientific disciplines, as well as in the ICST's own EU Digital Library (EUDL). LNICST volumes are submitted for inclusion to leading indexing services, including DBLP, Google Scholar, ACM Digital Library, ISI Proceedings, EI Engineering Index, CrossRef, Scopus. Seehttp://www.springer.com/computer/lncs?SGWID=0-164-6-1068921-0 for more information about indexing. PAPER SUBMISSION Authors are invited to submit papers of up to 12 pages for full papers, 6 pages for short papers. Steering Committee ================== * Imrich Chlamtac (Chair), President, CREATE-NET Research Consortium, Trento, Italy * Ramjee Prasad, Aalborg University, Denmark * Andreas U. Schmidt, Director, Novalyst IT AG, Karben, Germany Organising Committee ==================== General Chair / General Co-Chairs: * Neeli R. Prasad, Aalborg University, Denmark * Andreas U. Schmidt, Novalyst IT AG, Karben, Germany TPC Chair/TPC Co-Chairs: * Ioannis Krontiris, Goethe University Frankfurt, Germany * Giovanni Russello, University of Auckland, New Zealand - Publication Chair: Shiguo Lian, France Telecom R&D, Beijing, China - Publicity Chair(s): Mauro Conti, University of Padua, Italy; Rasmus Hjorth Nielsen, CTIF, Princeton, USA - Workshops Chair(s): Vincent Naessens, KaHo Sint-Lieven, Gent, Belgium - Panels Chair:Dirk Kröselberg, Siemens CERT, Munich, Germany - Web Chair: Andreas Leicher, Novalyst IT AG, Karben, Germany - Conference Coordinator: Justina Senkus, EAI/ICST Trento, Italy Program Committee ================= * Andreas Albers, Goethe University Frankfurt, Germany * Claudio Agostino Ardagna, University of Milan, Italy * Lejla Batina, Radboud University Nijmegen, The Netherlands * Zinaida Benenson, University of Erlangen-Nürnberg, Germany * Rocky Chang, Hong Kong Polytechnic University, China * Mauro Conti, University of Padua, Italy * Bruno Crispo, University of Trento, Italy * Tassos Dimitriou, Athens Information Technology, Greece * Changyu Dong, University of Strathclyde, UK * William Enck, North Carolina State University, USA * Hannes Federrath, University of Hamburg, Germany * Felix Freiling, University of Erlangen-Nürnberg, Germany * Ashish Gehani, SRI International, USA * Seda Gürses, Katholieke Universiteit Leuven, Belgium * Dogan Kesdogan, University of Siegen, Germany * Geir M. Køien, University of Adger, Norway * Marc Langheinrich, University of Lugano, Switzerland * Jiqiang Lu, Institute for Infocomm Research, Singapore * Flaminia Luccio, University Ca' Foscari of Venice, Italy * Emmanouil Magkos, Ionian University, Greece * Marco Casassa Mont, Hewlett Packard Laboratories, Bristol, UK * Raphael C.-W. Phan, Loughborough University, UK * Anand Prasad, NEC Laboratories Japan * Reijo Savola, VTT Technical Research Centre of Finland, Finland * Aubrey-Derrick Schmidt, Technical University Berlin, Germany * Jean-Pierre Seifert, TU-Berlin, T-Labs, Germany * Elaine Shi, UC Berkeley, USA * Claudio Silvestri, University Ca' Foscari of Venice, Italy * Claudio Soriente, Universidad Politecnica de Madrid, Spain * Thorsten Strufe, University of Mannheim, Germany * Allan Tomlinson, Royal Holloway, University of London, UK * Martin Werner, Ludwig-Maximilians-Universität München, Germany -- Mauro Conti, PhD Assistant Professor University of Padua Faculty of Science Department Mathematics Via Trieste, 63 - 35121, Padova, Italy Room : 402 Phone: +39 049 827 1488 Fax : +39 049 827 1479 email: conti@math.unipd.it web : http://www.math.unipd.it/~conti/ -- Mauro Conti, PhD Assistant Professor University of Padua Faculty of Science Department Mathematics Via Trieste, 63 - 35121, Padova, Italy Room : 402 Phone: +39 049 827 1488 Fax : +39 049 827 1479 email: conti@math.unipd.it web : http://www.math.unipd.it/~conti/ From kivinen@iki.fi Mon Mar 5 03:26:35 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA6C21F85AA for ; Mon, 5 Mar 2012 03:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-JjqoYIM-CV for ; Mon, 5 Mar 2012 03:26:35 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFD921F8572 for ; Mon, 5 Mar 2012 03:26:33 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q25BQVRC005920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 Mar 2012 13:26:31 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q25BQVCI012814; Mon, 5 Mar 2012 13:26:31 +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: <20308.41703.180675.466160@fireball.kivinen.iki.fi> Date: Mon, 5 Mar 2012 13:26:31 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Subject: [IPsec] New Version Notification for draft-kivinen-ipsecme-oob-pubkey-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 11:26:35 -0000 I just posted following document. I think I would like to get few minutes in Paris to explain this document, and see wheter there is any comments to it. I think it should be forwarded as individual draft to the RFC, but I am not sure whether it should be informational or standards track document, and this is something I would like to get feedback from the community. This is very similar in ideas than to the tls version (draft-ietf-tls-oob-pubkey-01), i.e. it shares the same format for the raw key. ---------------------------------------------------------------------- From: internet-drafts@ietf.org To: kivinen@iki.fi Cc: hannes.tschofenig@gmx.net, pwouters@redhat.com Subject: New Version Notification for draft-kivinen-ipsecme-oob-pubkey-00.txt Date: Mon, 05 Mar 2012 03:07:42 -0800 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 A new version of I-D, draft-kivinen-ipsecme-oob-pubkey-00.txt has been successfully submitted by Tero Kivinen and posted to the IETF repository. Filename: draft-kivinen-ipsecme-oob-pubkey Revision: 00 Title: More Raw Public Keys for IKEv2 Creation date: 2012-03-05 WG ID: Individual Submission Number of pages: 7 Abstract: The Internet Key Exchange Version 2 (IKEv2) protocol currently only supports raw RSA keys. In some environments it is useful to make use of other types of public keys, such as those based on Elliptic Curve Cryptography. This documents adds support for other types of raw public keys to IKEv2. The IETF Secretariat -- kivinen@iki.fi From paul.hoffman@vpnc.org Mon Mar 5 20:37:55 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1C621F8763 for ; Mon, 5 Mar 2012 20:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.704 X-Spam-Level: X-Spam-Status: No, score=-102.704 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C657qtBY6OkO for ; Mon, 5 Mar 2012 20:37:54 -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 9D81521F8762 for ; Mon, 5 Mar 2012 20:37:54 -0800 (PST) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q264boGU038961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 Mar 2012 21:37:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20308.41703.180675.466160@fireball.kivinen.iki.fi> Date: Mon, 5 Mar 2012 20:37:50 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <20308.41703.180675.466160@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1257) Cc: ipsec@ietf.org Subject: Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-oob-pubkey-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 04:37:55 -0000 On Mar 5, 2012, at 3:26 AM, Tero Kivinen wrote: > I just posted following document. I think I would like to get few > minutes in Paris to explain this document, and see wheter there is any > comments to it. I think it should be forwarded as individual draft to > the RFC, but I am not sure whether it should be informational or > standards track document, and this is something I would like to get > feedback from the community. I see no reason it should not be on standards track. > This is very similar in ideas than to the tls version > (draft-ietf-tls-oob-pubkey-01), i.e. it shares the same format for the > raw key. And this is good. --Paul Hoffman From prbatra@cisco.com Tue Mar 6 03:21:49 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B992D21F87BA for ; Tue, 6 Mar 2012 03:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.598 X-Spam-Level: X-Spam-Status: No, score=-7.598 tagged_above=-999 required=5 tests=[AWL=3.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izqV1b8rVuzg for ; Tue, 6 Mar 2012 03:21:49 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id CC99E21F87C0 for ; Tue, 6 Mar 2012 03:21:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=prbatra@cisco.com; l=3617; q=dns/txt; s=iport; t=1331032909; x=1332242509; h=mime-version:subject:date:message-id:from:to; bh=M/qIROz4wCvfh48nyvDldCR6ykQgQeoEFZbc73tJHgI=; b=kLECSIdh+wAqanZkiy75KOVcCm6Yp4oxs1sz4CyRsEmtVIilvIBl7Fpd m3qyfyKDiFHYcFmHFazPeaKcGGLKXO/3T+gy4ydsjpoUtVYVxViApOvlu PHHWAiX9Ku9VGIQF6g3rzxItwiLY/ggINVVtLJZBp8gi9/SPSx1zPNrL8 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAEjyVU9Io8UY/2dsb2JhbABDgkWzPIF/AQQSAQkRAz4dAQweBhgHVwEECxAah2WZIYEnAZ8WjTyCP2MEiE6dBoJr X-IronPort-AV: E=Sophos;i="4.73,539,1325462400"; d="scan'208,217";a="7211177" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 06 Mar 2012 11:21:47 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q26BLlRi015071 for ; Tue, 6 Mar 2012 11:21:47 GMT Received: from xmb-bgl-419.cisco.com ([72.163.129.215]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 16:51:46 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: BRyP Bkrs CYEG C4rz EdM2 E1OR FIKF GgXr Idep I0Mh JD1q JjZe JshB LH18 LXsJ LaUi; 1; aQBwAHMAZQBjAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {D80CFC16-30D5-45F9-BF87-397258E1232E}; cAByAGIAYQB0AHIAYQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Tue, 06 Mar 2012 11:21:43 GMT; RQBBAFAAIABBAEsAQQAgAG8AbgAgAFUAUwBJAE0A MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFB8B.512310C6" x-cr-puzzleid: {D80CFC16-30D5-45F9-BF87-397258E1232E} Content-class: urn:content-classes:message Date: Tue, 6 Mar 2012 16:51:43 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EAP AKA on USIM Thread-Index: Acz7i09oKDuDu86eS7S/PHcnp76lfQ== From: "Prashant Batra (prbatra)" To: X-OriginalArrivalTime: 06 Mar 2012 11:21:46.0773 (UTC) FILETIME=[512B7450:01CCFB8B] Subject: [IPsec] EAP AKA on USIM X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 11:21:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFB8B.512310C6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 Not sure if this is the right place to ask this, but I am not getting any other mailing list. Can someone point me to a software implementation of EAP-AKA algorithm (calculation of IK/CK/RES/MAC) on USIM,=20 when the sim gets a EAP-Challenge request. =20 Thanks, Prashant =20 ------_=_NextPart_001_01CCFB8B.512310C6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

  Not sure if this is the right place to = ask this, but I am not getting

    any other mailing = list.

    Can someone point me to a = software implementation of EAP-AKA algorithm

    (calculation of = IK/CK/RES/MAC) on USIM,

    when the sim gets a = EAP-Challenge request.

 

    Thanks,

    Prashant

 

------_=_NextPart_001_01CCFB8B.512310C6-- From Internet-Drafts@ietf.org Tue Mar 6 08:00:43 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22D321F89AC; Tue, 6 Mar 2012 08:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-ESOxe5aKa1; Tue, 6 Mar 2012 08:00:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54E621F899E; Tue, 6 Mar 2012 08:00:40 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120306160040.26663.61632.idtracker@ietfa.amsl.com> Date: Tue, 06 Mar 2012 08:00:40 -0800 Cc: ipsec@ietf.org Subject: [IPsec] I-D ACTION:draft-ietf-ipsecme-p2p-vpn-problem-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 16:00:43 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Point to Point VPNs Problem Statement Author(s) : S. Hanna Filename : draft-ietf-ipsecme-p2p-vpn-problem Pages : 13 Date : March 6, 2012 This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. Manual configuration of all possible tunnels is too cumbersome in such cases, so an automated method is needed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-p2p-vpn-problem Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-p2p-vpn-problem"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-03-06080040.I-D@ietf.org> --NextPart-- From andreas.steffen@strongswan.org Tue Mar 6 09:55:16 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A57A21F8690 for ; Tue, 6 Mar 2012 09:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4fznnmPw5HN for ; Tue, 6 Mar 2012 09:55:16 -0800 (PST) Received: from strongswan.org (sitav-80024.hsr.ch [152.96.80.24]) by ietfa.amsl.com (Postfix) with ESMTP id DB30A21F8687 for ; Tue, 6 Mar 2012 09:55:15 -0800 (PST) Received: from [10.10.0.20] by strongswan.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1S4ybQ-0001bV-4l; Tue, 06 Mar 2012 18:55:12 +0100 Message-ID: <4F564F7F.3030500@strongswan.org> Date: Tue, 06 Mar 2012 18:55:11 +0100 From: Andreas Steffen Organization: strongSwan Project User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "Prashant Batra (prbatra)" References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: ipsec@ietf.org Subject: Re: [IPsec] EAP AKA on USIM X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 17:55:16 -0000 Hello Prashant, the strongSwan open source project has a software implementation of the EAP-AKA 3GPP2 algorithm: http://git.strongswan.org/?p=strongswan.git;a=tree;f=src/libcharon/plugins/eap_aka_3gpp2;hb=HEAD Regards Andreas On 06.03.2012 12:21, Prashant Batra (prbatra) wrote: > Hello, > > Not sure if this is the right place to ask this, but I am not getting > > any other mailing list. > > Can someone point me to a software implementation of EAP-AKA algorithm > > (calculation of IK/CK/RES/MAC) on USIM, > > when the sim gets a EAP-Challenge request. > > Thanks, > > Prashant ====================================================================== Andreas Steffen andreas.steffen@strongswan.org strongSwan - the Linux VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[ITA-HSR]== From shanna@juniper.net Tue Mar 6 13:55:02 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669BD21F8593 for ; Tue, 6 Mar 2012 13:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODjoSw0W3o1A for ; Tue, 6 Mar 2012 13:55:01 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9090121F8576 for ; Tue, 6 Mar 2012 13:55:01 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKT1aHtWtlNBrZSXhmamHQVxsCmv8iu5Pv@postini.com; Tue, 06 Mar 2012 13:55:01 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 6 Mar 2012 13:54:34 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 6 Mar 2012 16:54:33 -0500 From: Stephen Hanna To: IPsecme WG Date: Tue, 6 Mar 2012 16:54:31 -0500 Thread-Topic: Please Comment on New P2P VPN Problem Statement Thread-Index: Acz747Yo1NYgaOpATuOZxzqEEjvmww== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 Subject: [IPsec] Please Comment on New P2P VPN Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 21:55:02 -0000 In case you didn't notice, I have posted the -00 version of the P2P VPN problem statement. The URL is below. Please review and comment. I'm especially interested in getting feedback on the use cases in this document. As previously agreed, they are based on the use cases in section 2.2 of the previous problem statement draft. I have tried to clarify those use cases, especially by providing definitions of terms and using those terms consistently throughout the document.=20 After we reach consensus on the use cases, we can move on to defining requirements derived from those use cases. But I see no point in talking about requirements before we've agreed on a clear description of the problems that we are trying to solve. So please review this short document and send comments. Thanks, Steve -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, March 06, 2012 11:01 AM To: i-d-announce@ietf.org Cc: ipsec@ietf.org Subject: I-D ACTION:draft-ietf-ipsecme-p2p-vpn-problem-00.txt 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 Wor= king Group of the IETF. Title : Point to Point VPNs Problem Statement Author(s) : S. Hanna Filename : draft-ietf-ipsecme-p2p-vpn-problem Pages : 13=20 Date : March 6, 2012=20 =20 This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. Manual configuration of all possible tunnels is too cumbersome in such cases, so an automated method is needed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-p2p-vpn-problem Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From vishwas.ietf@gmail.com Tue Mar 6 14:22:37 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B91321E80A9 for ; Tue, 6 Mar 2012 14:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tz5uuvFRsJB1 for ; Tue, 6 Mar 2012 14:22:36 -0800 (PST) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7C24321E8013 for ; Tue, 6 Mar 2012 14:22:36 -0800 (PST) Received: by daec6 with SMTP id c6so8305222dae.27 for ; Tue, 06 Mar 2012 14:22:36 -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=1lOoFuitx1dTKEiueuHa+TsNnXlXHIoClQwYzrDEbQ4=; b=hvTemPLE09VO26hKBFz72zhOlgOrkpVKL2jF0r1mpkLx05pQepQPk3Hcv95LLQv0Ua I5Y9F4Fc3cFMz46ik5iOnQvHtbl0XfJsYHeU4dAlKPUY+3TN6jIZjzJxmtV7KeA/5PPo ZNHkyKFPxS5VqQAm+SbUwB/d3PE+X+O7YWHqdqNbj43i1T0MerwstI24W019w2Ahyk03 j2Ei95q3aJ7SDH33Wc8zTm4yANW0rLvLNnUQhBUySDtcZogOJL3g35TLMRpLhtDjCDwO 6gTMj6AMtnnsu1iM8pZPnZLGy4Fm7jY8F129ozXKcEveOrPLqHtas7KRxQzroddtkUHZ 1f4g== MIME-Version: 1.0 Received: by 10.68.194.65 with SMTP id hu1mr427584pbc.75.1331072556129; Tue, 06 Mar 2012 14:22:36 -0800 (PST) Received: by 10.142.107.7 with HTTP; Tue, 6 Mar 2012 14:22:36 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Mar 2012 14:22:36 -0800 Message-ID: From: Vishwas Manral To: Stephen Hanna Content-Type: multipart/alternative; boundary=047d7b15a959e0def504ba9a7adc Cc: IPsecme WG Subject: Re: [IPsec] Please Comment on New P2P VPN Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 22:22:37 -0000 --047d7b15a959e0def504ba9a7adc Content-Type: text/plain; charset=ISO-8859-1 Hi Steve, I agree to the need of standardization for a large scale point-to-point solution. 1. I guess the problem statement is not just about lessening the number of configuration commands but also the fact that static configuration may not work in some cases. The spokes may get new addresses every time they come up (using DHCP/ PPPoE) and hence the communication end point identifiers change. 2. I am not sure but the use cases do not come out very clearly to me. The most important part of the communication is of end-sites communicating to the gateway hub router. In a typical enterprise deployment that would mean a branches connected to the campus/ data center. This tunnel is permanent. Mainly to access resources at the back end. There could be redundancy here to provide HA. 3. We then optionally require communication between end sites and such communication may be temporary or permanent. For such cases we want to be able to unburden the gateway so as to not cause overload. 4. We could have multiple gateways work in a cluster mode to serve a set of end-sites and to provide HA. 5. The clusters may in turn communicate with each other. We as HP would love to participate in this draft as well as any solution document that is produced. Thanks, Vishwas On Tue, Mar 6, 2012 at 1:54 PM, Stephen Hanna wrote: > In case you didn't notice, I have posted the -00 version > of the P2P VPN problem statement. The URL is below. > Please review and comment. > > I'm especially interested in getting feedback on the > use cases in this document. As previously agreed, they > are based on the use cases in section 2.2 of the > previous problem statement draft. I have tried to > clarify those use cases, especially by providing > definitions of terms and using those terms consistently > throughout the document. > > After we reach consensus on the use cases, we can move > on to defining requirements derived from those use cases. > But I see no point in talking about requirements before > we've agreed on a clear description of the problems > that we are trying to solve. > > So please review this short document and send comments. > > Thanks, > > Steve > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Tuesday, March 06, 2012 11:01 AM > To: i-d-announce@ietf.org > Cc: ipsec@ietf.org > Subject: I-D ACTION:draft-ietf-ipsecme-p2p-vpn-problem-00.txt > > A new Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Security Maintenance and Extensions > Working Group of the IETF. > > Title : Point to Point VPNs Problem Statement > Author(s) : S. Hanna > Filename : draft-ietf-ipsecme-p2p-vpn-problem > Pages : 13 > Date : March 6, 2012 > > This document describes the problem of enabling a large number of > systems to communicate directly using IPsec to protect the traffic > between them. Manual configuration of all possible tunnels is too > cumbersome in such cases, so an automated method is needed. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-p2p-vpn-problem > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --047d7b15a959e0def504ba9a7adc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Steve,

I agree to the need of standardization for a large scale p= oint-to-point solution.

1. I guess the problem statement is not just= about lessening the number of configuration commands but also the fact tha= t static configuration may not work in some cases. The spokes may get new a= ddresses every time they come up (using DHCP/ PPPoE) and hence the communic= ation end point identifiers change.

2. I am not sure but the use cases do not come out very clearly to me. = The most important part of the communication is of end-sites communicating = to the gateway hub router. In a typical enterprise deployment that would me= an a branches connected to the campus/ data center. This tunnel is permanen= t. Mainly to access resources at the back end. There could be redundancy he= re to provide HA.

3. We then optionally require communication between end sites and such = communication may be temporary or permanent. For such cases we want to be a= ble to unburden the gateway so as to not cause overload.

4. We could= have multiple gateways work in a cluster mode to serve a set of end-sites = and to provide HA.

5. The clusters may in turn communicate with each other.

We as H= P would love to participate in this draft as well as any solution document = that is produced.

Thanks,
Vishwas

On Tue, Mar 6, 2012 at 1:54 PM, Stephen Hanna <shanna@juniper.net> wrote:
=
In case you didn't notice, I have posted the -00 version
of the P2P VPN problem statement. The URL is below.
Please review and comment.

I'm especially interested in getting feedback on the
use cases in this document. As previously agreed, they
are based on the use cases in section 2.2 of the
previous problem statement draft. I have tried to
clarify those use cases, especially by providing
definitions of terms and using those terms consistently
throughout the document.

After we reach consensus on the use cases, we can move
on to defining requirements derived from those use cases.
But I see no point in talking about requirements before
we've agreed on a clear description of the problems
that we are trying to solve.

So please review this short document and send comments.

Thanks,

Steve

-----Original Message-----
From: i-d-announce-bounces= @ietf.org [mailto:i-d-= announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org
Sent: Tuesday, March 06, 2012 11:01 AM
To: i-d-announce@ietf.org
Cc: ipsec@ietf.org
Subject: I-D ACTION:draft-ietf-ipsecme-p2p-vpn-problem-00.txt

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 Wor= king Group of the IETF.

=A0 =A0Title =A0 =A0 =A0 =A0 : Point to Point VPNs Problem Statement
=A0 =A0Author(s) =A0 =A0 : S. Hanna
=A0 =A0Filename =A0 =A0 =A0: draft-ietf-ipsecme-p2p-vpn-problem
=A0 =A0Pages =A0 =A0 =A0 =A0 : 13
=A0 =A0Date =A0 =A0 =A0 =A0 =A0: March 6, 2012

=A0 This document describes the problem of enabling a large number of
=A0 systems to communicate directly using IPsec to protect the traffic
=A0 between them. =A0Manual configuration of all possible tunnels is too =A0 cumbersome in such cases, so an automated method is needed.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ip= secme-p2p-vpn-problem

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

--047d7b15a959e0def504ba9a7adc-- From paul.hoffman@vpnc.org Tue Mar 6 14:40:04 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507E421F85E5 for ; Tue, 6 Mar 2012 14:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.702 X-Spam-Level: X-Spam-Status: No, score=-102.702 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQIyAXfdsDKg for ; Tue, 6 Mar 2012 14:40:03 -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 7A6FF21F85D5 for ; Tue, 6 Mar 2012 14:39:50 -0800 (PST) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q26Mdnqu083048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 6 Mar 2012 15:39:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: Date: Tue, 6 Mar 2012 14:39:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4B6AB003-1CA5-4C4B-9FFA-57A975F8312B@vpnc.org> References: To: IPsecme WG X-Mailer: Apple Mail (2.1257) Subject: Re: [IPsec] Please Comment on New P2P VPN Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 22:40:04 -0000 Yes, please do comment on the draft. Before commenting, read the whole = draft. For extra points: start different threads of the comments with = different subject lines. We will discuss this draft at the upcoming IETF meeting in Paris. By = "discuss", I do *not* mean "have the draft introduced to us": I do mean = "talk about issues with the draft and things that should be added". = Given that there are weeks between now and the meeting, Yaron and I will = be somewhat ruthless in preventing Steve from doing much intro in his = presentation, and instead insist that he focus on open issues. This will = give the folks in the room the maximum amount of time to discuss issues. This WG has one active draft in front of it; it is not too much of us to = expect you to read it before coming to the meeting. --Paul Hoffman From paul.hoffman@vpnc.org Tue Mar 6 14:43:29 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE4321F85EE for ; Tue, 6 Mar 2012 14:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.701 X-Spam-Level: X-Spam-Status: No, score=-102.701 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5a-wfQPBDOed for ; Tue, 6 Mar 2012 14:43:29 -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 4330A21F85E6 for ; Tue, 6 Mar 2012 14:43:29 -0800 (PST) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q26MhSBm083138 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 6 Mar 2012 15:43:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Mar 2012 14:43:28 -0800 Message-Id: To: IPsecme WG Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [IPsec] Call for agenda items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 22:43:29 -0000 We have one active draft, and that might take up most of our hour. = However, we have often had time to have short (5 minutes or less) quick = presentations on other topics. A proposed agenda is: 5 min: WG intro 45 min: draft-ietf-ipsecme-p2p-vpn-problem issues 5 min: draft-kivinen-ipsecme-oob-pubkey issues Are there other IPsec-related topics for the meeting? --Paul Hoffman From ynir@checkpoint.com Tue Mar 6 14:54:54 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC5021E803F for ; Tue, 6 Mar 2012 14:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.47 X-Spam-Level: X-Spam-Status: No, score=-10.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HomhcWCqZwvd for ; Tue, 6 Mar 2012 14:54:50 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3A90921F851E for ; Tue, 6 Mar 2012 14:54:49 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q26MsdE1006977; Wed, 7 Mar 2012 00:54:40 +0200 X-CheckPoint: {4F569600-1-1B221DC2-5FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 7 Mar 2012 00:54:39 +0200 From: Yoav Nir To: Stephen Hanna Date: Wed, 7 Mar 2012 00:54:37 +0200 Thread-Topic: P2P VPN Problem Statement - why is this hard? Thread-Index: Acz77BuD3dXJPj8+R5e/zQKwyPPFJA== Message-ID: <1E6FEEF8-6A73-40C4-A617-886D0BE12EB8@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: [IPsec] P2P VPN Problem Statement - why is this hard? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 22:54:54 -0000 Hi Steve On Mar 6, 2012, at 11:54 PM, Stephen Hanna wrote: > So please review this short document and send comments. While the draft does a good job of describing use cases, and certain inadeq= uate solutions, I think it's missing a description of why this is hard. Even if we accept the solution of a star topology, where a satellite needs = only have one single tunnel, there are really two choices: 1. that each satellite know about all the protected networks of all the ga= teways in the configuration, or 2. that satellites send all traffic to the "core" or "hub" gateways. This = includes clear traffic (as in HTTP to facebook.com). This increased the loa= d even more. If you don't want #2, then the satellite still needs to know about every IP= address whether it is protected by some gateway (and therefore needs to go= in the tunnel), or not (and so packets with that destination should go out= in the clear). Since the protected networks change, this requires that inf= ormation to propagate throughout the network, and dynamic updates to SPD If we don't want a star topology, the gateways or endpoints still need to k= now what is or is not encrypted. They also need to either know about all pe= ers, or be able to find the peer and (securely) learn how it should authent= icate. Either way, without a star topology, you need dynamic updates to PAD= . I think the draft should mention this. Yoav From yaronf.ietf@gmail.com Wed Mar 7 13:18:03 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E77F11E809D for ; Wed, 7 Mar 2012 13:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.475 X-Spam-Level: X-Spam-Status: No, score=-103.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVop3xLJE4aQ for ; Wed, 7 Mar 2012 13:18:03 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id A1C8611E809A for ; Wed, 7 Mar 2012 13:18:02 -0800 (PST) Received: by wicr5 with SMTP id r5so3890987wic.31 for ; Wed, 07 Mar 2012 13:18:01 -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=9PUNjscN+vJo7lO+s0+K7Ar1mcgMQg6lw4Np5yWVf5A=; b=AbQFk4hwXxF1pnD9ORsSohaRuZFe0SWoNDrl+ZUUxvLuP5/HQv9myQtl6Kn4CwKA4+ fNfIKiXs9FoTTOscXZ8UFULIekFiZyTvnxXZPCi6Ifr+E2rmQs0PfpWo0yM/WsPCL6cY TjCbBp+AlSOw4L7MQSNupYnpdzPHjMzAneJriWOPUHDYZ47HJrj9l9gTT6R4QMNTtQTh ElCdSVWKAS0c8cvfl/L6XWYCqQ5/7neH2Og/02bjMlviBATQSZn0nUWE22GaQ6x5U4SP NCBY3tfrDRdyENIPunXNEfDBi826SmeNAsX8zMZ0SZ0BzNgK1feDTOmOOiF/KCPLvzFG G3lg== Received: by 10.216.139.143 with SMTP id c15mr1687844wej.39.1331155081849; Wed, 07 Mar 2012 13:18:01 -0800 (PST) Received: from [10.0.0.4] (bzq-79-177-170-132.red.bezeqint.net. [79.177.170.132]) by mx.google.com with ESMTPS id gp8sm38591173wib.5.2012.03.07.13.18.00 (version=SSLv3 cipher=OTHER); Wed, 07 Mar 2012 13:18:00 -0800 (PST) Message-ID: <4F57D087.9030508@gmail.com> Date: Wed, 07 Mar 2012 23:17:59 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] P2P VPN draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 21:18:03 -0000 Hi Steve, a few initial comments. * The draft is short and clear. Thanks for that! * I have a problem with the title (and even more, with the "file name" of the draft). P2P is usually perceived as peer-to-peer, which skews the discussion towards one particular use case, that of endpoint-to-endpoint. I suggest to use "Mesh IPsec VPN" instead. * I am unclear about 2.2: so what if you "suddenly need to exchange a lot of data". How is it different from normal IP traffic load management? The text is simply too vague here. Ideally, should we expect the traffic to migrate to other gateways? To go directly between endpoints? To establish priorities on existing gateways? Thanks, Yaron From yaronf.ietf@gmail.com Wed Mar 7 13:26:02 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BD411E809B for ; Wed, 7 Mar 2012 13:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.493 X-Spam-Level: X-Spam-Status: No, score=-103.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ea4PbY3FgKJc for ; Wed, 7 Mar 2012 13:26:01 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF2611E809A for ; Wed, 7 Mar 2012 13:26:01 -0800 (PST) Received: by werb10 with SMTP id b10so5318289wer.31 for ; Wed, 07 Mar 2012 13:26:00 -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=gfNX/HZDdvKfzhe4Zn12jFNoone+rswub0gm65PGO6M=; b=0HeTr6lZE1hQX3OJMKGA4ER7EHjxFoR8X6ItKDY1OYIsLjmswfrn2PDyVjkZzmew22 maLDXgWSzEUudsWf1URyXPSoM7N2Gsq1dWAy2r61g2aMcH9HRmQZLj8HWAuWvIt5OuNC lHBHTe7bh3Ts5Sz9DMAtDsc4sMJQFDmIZ98XHg3hbtXF71lcDlt8FoqwUIOl+SD6VQSb 4/28TkRwn0RU8BkIOXiE4f+LXO1QgG5i6+T9DoupExsz1VDd/k1C+laB1OJRQ8HFZpkd /Gtx2BuwtS/X1/DLiaFaO2bIEQiUdCuE0oRC79Ck6/bjRNGRCs17OOooZauAsfTcUsNO eEXw== Received: by 10.180.106.9 with SMTP id gq9mr6999846wib.17.1331155560777; Wed, 07 Mar 2012 13:26:00 -0800 (PST) Received: from [10.0.0.4] (bzq-79-177-170-132.red.bezeqint.net. [79.177.170.132]) by mx.google.com with ESMTPS id w10sm86414167wiy.3.2012.03.07.13.25.59 (version=SSLv3 cipher=OTHER); Wed, 07 Mar 2012 13:25:59 -0800 (PST) Message-ID: <4F57D266.7090809@gmail.com> Date: Wed, 07 Mar 2012 23:25:58 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Yoav Nir References: <1E6FEEF8-6A73-40C4-A617-886D0BE12EB8@checkpoint.com> In-Reply-To: <1E6FEEF8-6A73-40C4-A617-886D0BE12EB8@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Stephen Hanna Subject: Re: [IPsec] P2P VPN Problem Statement - why is this hard? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 21:26:02 -0000 Hi Yoav, Steve, I'm not sure that this star-vs-mesh discussion is so important, because even if you choose the simplest star topology, data propagation is still required. Configuration of the satellites is simple: *everything* goes to the hub. But the hub needs to know which satellite to send each packet to, and as the satellites' configuration changes, the hub constantly needs to be reconfigured. So it's really the same problem in a more limited form. Thanks, Yaron On 03/07/2012 12:54 AM, Yoav Nir wrote: > Hi Steve > > On Mar 6, 2012, at 11:54 PM, Stephen Hanna wrote: > >> So please review this short document and send comments. > > While the draft does a good job of describing use cases, and certain inadequate solutions, I think it's missing a description of why this is hard. > > Even if we accept the solution of a star topology, where a satellite needs only have one single tunnel, there are really two choices: > 1. that each satellite know about all the protected networks of all the gateways in the configuration, or > 2. that satellites send all traffic to the "core" or "hub" gateways. This includes clear traffic (as in HTTP to facebook.com). This increased the load even more. > > If you don't want #2, then the satellite still needs to know about every IP address whether it is protected by some gateway (and therefore needs to go in the tunnel), or not (and so packets with that destination should go out in the clear). Since the protected networks change, this requires that information to propagate throughout the network, and dynamic updates to SPD > > If we don't want a star topology, the gateways or endpoints still need to know what is or is not encrypted. They also need to either know about all peers, or be able to find the peer and (securely) learn how it should authenticate. Either way, without a star topology, you need dynamic updates to PAD. > > I think the draft should mention this. > > Yoav > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From Chris.Ulliott@cesg.gsi.gov.uk Wed Mar 7 13:54:26 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54BA921F850F for ; Wed, 7 Mar 2012 13:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Fecb40-AESl for ; Wed, 7 Mar 2012 13:54:25 -0800 (PST) Received: from mail89.messagelabs.com (mail89.messagelabs.com [194.106.220.3]) by ietfa.amsl.com (Postfix) with SMTP id 58FF621F850B for ; Wed, 7 Mar 2012 13:54:24 -0800 (PST) X-Env-Sender: Chris.Ulliott@cesg.gsi.gov.uk X-Msg-Ref: server-13.tower-89.messagelabs.com!1331157263!56601019!1 X-Originating-IP: [62.25.106.208] X-StarScan-Version: 6.5.5; banners=cesg.gsi.gov.uk,-,- X-VirusChecked: Checked Received: (qmail 14098 invoked from network); 7 Mar 2012 21:54:23 -0000 Received: from gateway-102.energis.gsi.gov.uk (HELO mx.hosting-w.gsi.gov.uk) (62.25.106.208) by server-13.tower-89.messagelabs.com with SMTP; 7 Mar 2012 21:54:23 -0000 From: "Ulliott, Chris" To: "'ipsec@ietf.org'" Date: Wed, 7 Mar 2012 21:52:37 +0000 Thread-Topic: [IPsec] P2P VPN draft UNCLASSIFIED Thread-Index: Acz8p5+o4krmmXWQQu6I0/5fzf1hoAABP0b+ Message-ID: <20549DD10769DA47A86F0F0FAF8012DD0349D9EEC6@PIACHEVEX00.GCHQ.GOV.UK> In-Reply-To: <4F57D087.9030508@gmail.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 21:54:26 -0000 Classification:UNCLASSIFIED How about "dynamic mesh VPNs" as a title as I think the dynamic part is ke= y here and probably an important aspect of the use cases. Chris [This message has been sent by a mobile device] ----- Original Message ----- From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] Sent: Wednesday, March 07, 2012 09:17 PM To: IPsecme WG Subject: [IPsec] P2P VPN draft Hi Steve, a few initial comments. * The draft is short and clear. Thanks for that! * I have a problem with the title (and even more, with the "file name" of the draft). P2P is usually perceived as peer-to-peer, which skews the discussion towards one particular use case, that of endpoint-to-endpoint. I suggest to use "Mesh IPsec VPN" instead. * I am unclear about 2.2: so what if you "suddenly need to exchange a lot of data". How is it different from normal IP traffic load management? The text is simply too vague here. Ideally, should we expect the traffic to migrate to other gateways? To go directly between endpoints? To establish priorities on existing gateways? Thanks, Yaron _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec **************************************************************************= ** Communications with GCHQ may be monitored and/or recorded=20 for system efficiency and other lawful purposes. Any views or=20 opinions expressed in this e-mail do not necessarily reflect GCHQ=20 policy. This email, and any attachments, is intended for the=20 attention of the addressee(s) only. Its unauthorised use,=20 disclosure, storage or copying is not permitted. If you are not the intended recipient, please notify postmaster@gchq.gsi.gov.uk. =20 This information is exempt from disclosure under the Freedom of=20 Information Act 2000 and may be subject to exemption under other UK information legislation. Refer disclosure requests to=20 GCHQ on 01242 221491 ext 30306 (non-secure) or email infoleg@gchq.gsi.gov.uk **************************************************************************= ** The original of this email was scanned for viruses by the Government Secur= e Intranet virus scanning service supplied by Cable&Wireless Worldwide in = partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On l= eaving the GSi this email was certified virus free. Communications via the GSi may be automatically logged, monitored and/or r= ecorded for legal purposes. From yaronf.ietf@gmail.com Wed Mar 7 14:30:29 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B731A11E80AF for ; Wed, 7 Mar 2012 14:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.506 X-Spam-Level: X-Spam-Status: No, score=-103.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7roWKnjLoTp for ; Wed, 7 Mar 2012 14:30:28 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id C6B2C11E8074 for ; Wed, 7 Mar 2012 14:30:23 -0800 (PST) Received: by eaaq11 with SMTP id q11so2412342eaa.31 for ; Wed, 07 Mar 2012 14:30:22 -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=Xmrpwuh2QB388l8vrveFgrsILHx3P8fHATJ2XpZxBGI=; b=RJWxP2rwxsRXu++sQQ70ZkZdQ2Y3pGkapuggPLr1Lv5NufmNEl5M6/iGMVEMJOMQKn y1joHknBWqLm+lhHcvpCM6AZl7geGrEK2+hO1lmhhCG0KsWNfB11F3Nhf/BVwHhWdvnr h8/k4Rf+RXbjJkqbWE9QuJT2ELz2mJ2EIq3gGMQr0pQbFqm0G873Vtwxg1Ywm6rth07/ JkAhrsMzt2N7LqusQkGxyD5Z6eK+hLDQ38Pu+l7I4On4XNy+HJtad/IUeY3959CsY/vY wKwzPABPBn1DJ8Bb1xOJ+lL/yyKU+R977SDhl/eI+bsB/4+NYvAEjogwfHFr49mpsPbr RKOA== Received: by 10.14.99.10 with SMTP id w10mr1627606eef.51.1331159422772; Wed, 07 Mar 2012 14:30:22 -0800 (PST) Received: from [10.0.0.4] (bzq-79-177-170-132.red.bezeqint.net. [79.177.170.132]) by mx.google.com with ESMTPS id n55sm52196937eef.6.2012.03.07.14.30.21 (version=SSLv3 cipher=OTHER); Wed, 07 Mar 2012 14:30:22 -0800 (PST) Message-ID: <4F57E17C.5040105@gmail.com> Date: Thu, 08 Mar 2012 00:30:20 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Ulliott, Chris" References: <20549DD10769DA47A86F0F0FAF8012DD0349D9EEC6@PIACHEVEX00.GCHQ.GOV.UK> In-Reply-To: <20549DD10769DA47A86F0F0FAF8012DD0349D9EEC6@PIACHEVEX00.GCHQ.GOV.UK> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'ipsec@ietf.org'" Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 22:30:29 -0000 Fine with me. Yaron On 03/07/2012 11:52 PM, Ulliott, Chris wrote: > Classification:UNCLASSIFIED > > How about "dynamic mesh VPNs" as a title as I think the dynamic part is key here and probably an important aspect of the use cases. > > Chris > > [This message has been sent by a mobile device] > > ----- Original Message ----- > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > Sent: Wednesday, March 07, 2012 09:17 PM > To: IPsecme WG > Subject: [IPsec] P2P VPN draft > > Hi Steve, > > a few initial comments. > > * The draft is short and clear. Thanks for that! > * I have a problem with the title (and even more, with the "file name" > of the draft). P2P is usually perceived as peer-to-peer, which skews > the discussion towards one particular use case, that of > endpoint-to-endpoint. I suggest to use "Mesh IPsec VPN" instead. > * I am unclear about 2.2: so what if you "suddenly need to exchange a > lot of data". How is it different from normal IP traffic load > management? The text is simply too vague here. Ideally, should we > expect the traffic to migrate to other gateways? To go directly > between endpoints? To establish priorities on existing gateways? > > Thanks, > > Yaron > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > **************************************************************************** > Communications with GCHQ may be monitored and/or recorded > for system efficiency and other lawful purposes. Any views or > opinions expressed in this e-mail do not necessarily reflect GCHQ > policy. This email, and any attachments, is intended for the > attention of the addressee(s) only. Its unauthorised use, > disclosure, storage or copying is not permitted. If you are not the > intended recipient, please notify postmaster@gchq.gsi.gov.uk. > > This information is exempt from disclosure under the Freedom of > Information Act 2000 and may be subject to exemption under > other UK information legislation. Refer disclosure requests to > GCHQ on 01242 221491 ext 30306 (non-secure) or email > infoleg@gchq.gsi.gov.uk > > **************************************************************************** > > > The original of this email was scanned for viruses by the Government Secure Intranet virus scanning service supplied by Cable&Wireless Worldwide in partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On leaving the GSi this email was certified virus free. > Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From shanna@juniper.net Wed Mar 7 14:47:54 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF56921F8609 for ; Wed, 7 Mar 2012 14:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ho-q3v+zW9ei for ; Wed, 7 Mar 2012 14:47:50 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 719A021F8608 for ; Wed, 7 Mar 2012 14:47:50 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKT1flle2YRUTKY4c1LZiaNmuJ3yXdBl7i@postini.com; Wed, 07 Mar 2012 14:47:50 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 7 Mar 2012 14:47:23 -0800 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 7 Mar 2012 14:47:23 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 7 Mar 2012 17:47:01 -0500 From: Stephen Hanna To: Vishwas Manral Date: Wed, 7 Mar 2012 17:46:59 -0500 Thread-Topic: [IPsec] Please Comment on New P2P VPN Problem Statement Thread-Index: Acz756YZtPdnflEZRNGZtSlEllZW7QAyUvcg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AC6674AB7BC78549BB231821ABF7A9AEB82CEA7287EMBX01WFjnprn_" MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Please Comment on New P2P VPN Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 22:47:54 -0000 --_000_AC6674AB7BC78549BB231821ABF7A9AEB82CEA7287EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vishwas, Thanks for your comments. I'll respond inline below. 1. I guess the problem statement is not just about lessening the number of = configuration commands but also the fact that static configuration may not = work in some cases. The spokes may get new addresses every time they come u= p (using DHCP/ PPPoE) and hence the communication end point identifiers cha= nge. SH> Yes, the dynamic nature of configuration data is as much a problem as t= he size of that data. 2. I am not sure but the use cases do not come out very clearly to me. The = most important part of the communication is of end-sites communicating to t= he gateway hub router. In a typical enterprise deployment that would mean a= branches connected to the campus/ data center. This tunnel is permanent. M= ainly to access resources at the back end. There could be redundancy here t= o provide HA. 3. We then optionally require communication between end sites and such comm= unication may be temporary or permanent. For such cases we want to be able = to unburden the gateway so as to not cause overload. 4. We could have multiple gateways work in a cluster mode to serve a set of= end-sites and to provide HA. 5. The clusters may in turn communicate with each other. SH> I'm sorry that the use cases are not clear. However, I'm sure we can an= d will improve them. SH> Your description of "The most important part of the communication" seem= s to be focused only on use case 2.2 in the draft. In your example, several= "end-sites" need to establish a direct connection to each other instead of= going through a "gateway hub router". To use the terminology defined in th= e draft, that's a gateway-to-gateway use case. I understand that you consid= er that to be the most important use case but others have previously spoken= out about the importance of use cases 2.1 and 2.3. SH> So I do agree with your description of use case 2.2. Maybe we should ad= d another example under use case 2.2, based on your example. Could you prov= ide more details about why a direct connection between two "end-sites" migh= t be needed? I can add that as an example in the next version of the draft. SH> And thanks for volunteering to participate in formulating the problem s= tatement and the solutions. That's great! Take care, Steve From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Tuesday, March 06, 2012 5:23 PM To: Stephen Hanna Cc: IPsecme WG Subject: Re: [IPsec] Please Comment on New P2P VPN Problem Statement Hi Steve, I agree to the need of standardization for a large scale point-to-point sol= ution. 1. I guess the problem statement is not just about lessening the number of = configuration commands but also the fact that static configuration may not = work in some cases. The spokes may get new addresses every time they come u= p (using DHCP/ PPPoE) and hence the communication end point identifiers cha= nge. 2. I am not sure but the use cases do not come out very clearly to me. The = most important part of the communication is of end-sites communicating to t= he gateway hub router. In a typical enterprise deployment that would mean a= branches connected to the campus/ data center. This tunnel is permanent. M= ainly to access resources at the back end. There could be redundancy here t= o provide HA. 3. We then optionally require communication between end sites and such comm= unication may be temporary or permanent. For such cases we want to be able = to unburden the gateway so as to not cause overload. 4. We could have multiple gateways work in a cluster mode to serve a set of= end-sites and to provide HA. 5. The clusters may in turn communicate with each other. We as HP would love to participate in this draft as well as any solution do= cument that is produced. Thanks, Vishwas On Tue, Mar 6, 2012 at 1:54 PM, Stephen Hanna > wrote: In case you didn't notice, I have posted the -00 version of the P2P VPN problem statement. The URL is below. Please review and comment. I'm especially interested in getting feedback on the use cases in this document. As previously agreed, they are based on the use cases in section 2.2 of the previous problem statement draft. I have tried to clarify those use cases, especially by providing definitions of terms and using those terms consistently throughout the document. After we reach consensus on the use cases, we can move on to defining requirements derived from those use cases. But I see no point in talking about requirements before we've agreed on a clear description of the problems that we are trying to solve. So please review this short document and send comments. Thanks, Steve -----Original Message----- From: i-d-announce-bounces@ietf.org [= mailto:i-d-announce-bounces@ietf.org]= On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, March 06, 2012 11:01 AM To: i-d-announce@ietf.org Cc: ipsec@ietf.org Subject: I-D ACTION:draft-ietf-ipsecme-p2p-vpn-problem-00.txt 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 Wor= king Group of the IETF. Title : Point to Point VPNs Problem Statement Author(s) : S. Hanna Filename : draft-ietf-ipsecme-p2p-vpn-problem Pages : 13 Date : March 6, 2012 This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. Manual configuration of all possible tunnels is too cumbersome in such cases, so an automated method is needed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-p2p-vpn-problem Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_AC6674AB7BC78549BB231821ABF7A9AEB82CEA7287EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Vishwas,<= o:p>

 

Thanks for your comments. I’ll respond = inline below.

 <= /o:p>

1. I guess the problem statement is no= t just about lessening the number of configuration commands but also the fa= ct that static configuration may not work in some cases. The spokes may get= new addresses every time they come up (using DHCP/ PPPoE) and hence the co= mmunication end point identifiers change.

<= /p>

SH> Yes, the dynamic nature of configurat= ion data is as much a problem as the size of that data.

 

2. I am not sure but the use cases do not come out very clearly to me. = The most important part of the communication is of end-sites communicating = to the gateway hub router. In a typical enterprise deployment that would me= an a branches connected to the campus/ data center. This tunnel is permanen= t. Mainly to access resources at the back end. There could be redundancy he= re to provide HA.


3. We then optiona= lly require communication between end sites and such communication may be t= emporary or permanent. For such cases we want to be able to unburden the ga= teway so as to not cause overload.

4. We could have multiple gateway= s work in a cluster mode to serve a set of end-sites and to provide HA.
=
5. The clusters may in turn communicate with each other.

=

SH> I’m sorry th= at the use cases are not clear. However, I’m sure we can and will imp= rove them.

 

SH> Your description of “= The most important part of the communication” seems to be focused onl= y on use case 2.2 in the draft. In your example, several “end-sites&#= 8221; need to establish a direct connection to each other instead of going = through a “gateway hub router”. To use the terminology defined = in the draft, that’s a gateway-to-gateway use case. I understand that= you consider that to be the most important use case but others have previo= usly spoken out about the importance of use cases 2.1 and 2.3.

 

SH> So I do agree with your description of use case = 2.2. Maybe we should add another example under use case 2.2, based on your = example. Could you provide more details about why a direct connection betwe= en two “end-sites” might be needed? I can add that as an exampl= e in the next version of the draft.

 

SH> An= d thanks for volunteering to participate in formulating the problem stateme= nt and the solutions. That’s great!

 

Tak= e care,

 <= /span>

Steve

 

From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Se= nt: Tuesday, March 06, 2012 5:23 PM
To: Stephen Hanna
C= c: IPsecme WG
Subject: Re: [IPsec] Please Comment on New P2P = VPN Problem Statement

 

H= i Steve,

I agree to the need of standardization for a large scale po= int-to-point solution.

1. I guess the problem statement is not just = about lessening the number of configuration commands but also the fact that= static configuration may not work in some cases. The spokes may get new ad= dresses every time they come up (using DHCP/ PPPoE) and hence the communica= tion end point identifiers change.

2. I am not sure but the use case= s do not come out very clearly to me. The most important part of the commun= ication is of end-sites communicating to the gateway hub router. In a typic= al enterprise deployment that would mean a branches connected to the campus= / data center. This tunnel is permanent. Mainly to access resources at the = back end. There could be redundancy here to provide HA.

3. We then o= ptionally require communication between end sites and such communication ma= y be temporary or permanent. For such cases we want to be able to unburden = the gateway so as to not cause overload.

4. We could have multiple g= ateways work in a cluster mode to serve a set of end-sites and to provide H= A.

5. The clusters may in turn communicate with each other.

W= e as HP would love to participate in this draft as well as any solution doc= ument that is produced.

Thanks,
Vishwas

On Tue, Mar 6, 2012 at 1:54 PM, Stephen Hanna <shanna@juniper.net> wrote:

In case you didn't notice, I have posted the -00 vers= ion
of the P2P VPN problem statement. The URL is below.
Please review= and comment.

I'm especially interested in getting feedback on theuse cases in this document. As previously agreed, they
are based on th= e use cases in section 2.2 of the
previous problem statement draft. I ha= ve tried to
clarify those use cases, especially by providing
definiti= ons of terms and using those terms consistently
throughout the document.=

After we reach consensus on the use cases, we can move
on to def= ining requirements derived from those use cases.
But I see no point in t= alking about requirements before
we've agreed on a clear description of = the problems
that we are trying to solve.

So please review this s= hort document and send comments.

Thanks,

Steve

-----Or= iginal Message-----
From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org
Sent: = Tuesday, March 06, 2012 11:01 AM
To: i-d-announce@ietf.org
Cc: ip= sec@ietf.org
Subject: I-D ACTION:draft-ietf-ipsecme-p2p-vpn-problem-= 00.txt

A new Internet-Draft is available from the on-line Internet-D= rafts directories.
This draft is a work item of the IP Security Maintena= nce and Extensions Working Group of the IETF.

   Title &nb= sp;       : Point to Point VPNs Problem Statement
  =  Author(s)     : S. Hanna
   Filename   &n= bsp;  : draft-ietf-ipsecme-p2p-vpn-problem
   Pages  = ;       : 13
   Date        = ;  : March 6, 2012

  This document describes the problem o= f enabling a large number of
  systems to communicate directly usin= g IPsec to protect the traffic
  between them.  Manual configu= ration of all possible tunnels is too
  cumbersome in such cases, s= o an automated method is needed.


A URL for this Internet-Draft i= s:
http://www.ietf.org/internet-drafts/draft-i= etf-ipsecme-p2p-vpn-problem

Internet-Drafts are also available b= y anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the d= ata which will enable a MIME compliant mail reader
implementation to aut= omatically retrieve the ASCII version of the
Internet-Draft.

____= ___________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailm= an/listinfo/ipsec

 <= /o:p>

= --_000_AC6674AB7BC78549BB231821ABF7A9AEB82CEA7287EMBX01WFjnprn_-- From shanna@juniper.net Wed Mar 7 14:52:35 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F7111E808F for ; Wed, 7 Mar 2012 14:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFSuRS7ydD67 for ; Wed, 7 Mar 2012 14:52:34 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 82D0C11E80C1 for ; Wed, 7 Mar 2012 14:52:34 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKT1fmsJe8wYJiSL5/Y/fYW07wITyrPzVT@postini.com; Wed, 07 Mar 2012 14:52:34 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 7 Mar 2012 14:51:53 -0800 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 7 Mar 2012 14:51:53 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 7 Mar 2012 17:51:52 -0500 From: Stephen Hanna To: "Ulliott, Chris" , "'ipsec@ietf.org'" Date: Wed, 7 Mar 2012 17:51:51 -0500 Thread-Topic: [IPsec] P2P VPN draft UNCLASSIFIED Thread-Index: Acz8p5+o4krmmXWQQu6I0/5fzf1hoAABP0b+AAEpgyA= Message-ID: References: <4F57D087.9030508@gmail.com> <20549DD10769DA47A86F0F0FAF8012DD0349D9EEC6@PIACHEVEX00.GCHQ.GOV.UK> In-Reply-To: <20549DD10769DA47A86F0F0FAF8012DD0349D9EEC6@PIACHEVEX00.GCHQ.GOV.UK> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 22:52:35 -0000 Upon reflection, I can see how "Point to Point VPNs" is problematic as a description of the problem. Really it's more about dynamically creating SAs so that any endpoint or gateway can communicate directly with any other, as permitted by policy. And how can we do this in a manageable manner in a large-scale environment where endpoints are mobile and configurations and policies change often? So "Dynamic Mesh VPNs" is fine with me. Whatever the WG feels is best. Thanks, Steve > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Ulliott, Chris > Sent: Wednesday, March 07, 2012 4:53 PM > To: 'ipsec@ietf.org' > Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED >=20 > Classification:UNCLASSIFIED >=20 > How about "dynamic mesh VPNs" as a title as I think the dynamic part is > key here and probably an important aspect of the use cases. >=20 > Chris >=20 > [This message has been sent by a mobile device] >=20 > ----- Original Message ----- > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > Sent: Wednesday, March 07, 2012 09:17 PM > To: IPsecme WG > Subject: [IPsec] P2P VPN draft >=20 > Hi Steve, >=20 > a few initial comments. >=20 > * The draft is short and clear. Thanks for that! > * I have a problem with the title (and even more, with the "file > name" > of the draft). P2P is usually perceived as peer-to-peer, which > skews > the discussion towards one particular use case, that of > endpoint-to-endpoint. I suggest to use "Mesh IPsec VPN" instead. > * I am unclear about 2.2: so what if you "suddenly need to exchange a > lot of data". How is it different from normal IP traffic load > management? The text is simply too vague here. Ideally, should we > expect the traffic to migrate to other gateways? To go directly > between endpoints? To establish priorities on existing gateways? >=20 > Thanks, >=20 > Yaron >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > *********************************************************************** > ***** > Communications with GCHQ may be monitored and/or recorded > for system efficiency and other lawful purposes. Any views or > opinions expressed in this e-mail do not necessarily reflect GCHQ > policy. This email, and any attachments, is intended for the > attention of the addressee(s) only. Its unauthorised use, > disclosure, storage or copying is not permitted. If you are not the > intended recipient, please notify postmaster@gchq.gsi.gov.uk. >=20 > This information is exempt from disclosure under the Freedom of > Information Act 2000 and may be subject to exemption under > other UK information legislation. Refer disclosure requests to > GCHQ on 01242 221491 ext 30306 (non-secure) or email > infoleg@gchq.gsi.gov.uk >=20 > *********************************************************************** > ***** >=20 >=20 > The original of this email was scanned for viruses by the Government > Secure Intranet virus scanning service supplied by Cable&Wireless > Worldwide in partnership with MessageLabs. (CCTM Certificate Number > 2009/09/0052.) On leaving the GSi this email was certified virus free. > Communications via the GSi may be automatically logged, monitored > and/or recorded for legal purposes. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From jcoronel@live.com Wed Mar 7 17:09:46 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3786E21F856C for ; Wed, 7 Mar 2012 17:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id In4XsDQ86QUZ for ; Wed, 7 Mar 2012 17:09:45 -0800 (PST) Received: from snt0-omc1-s39.snt0.hotmail.com (snt0-omc1-s39.snt0.hotmail.com [65.54.61.76]) by ietfa.amsl.com (Postfix) with ESMTP id CAC9E21F844F for ; Wed, 7 Mar 2012 17:09:44 -0800 (PST) Received: from SNT115-W36 ([65.55.90.7]) by snt0-omc1-s39.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Mar 2012 17:09:44 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_6c223cb7-cfe2-4855-85dc-d88350fd6ef4_" X-Originating-IP: [131.107.0.85] From: jorge coronel To: , , Date: Wed, 7 Mar 2012 17:09:44 -0800 Importance: Normal In-Reply-To: References: <4F57D087.9030508@gmail.com>, <20549DD10769DA47A86F0F0FAF8012DD0349D9EEC6@PIACHEVEX00.GCHQ.GOV.UK>, MIME-Version: 1.0 X-OriginalArrivalTime: 08 Mar 2012 01:09:44.0418 (UTC) FILETIME=[25C44420:01CCFCC8] Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 01:09:46 -0000 --_6c223cb7-cfe2-4855-85dc-d88350fd6ef4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes=2C that is fine. Although one could argue that the 1st Use case is P2P = in its nature=3B as only some signaling would need to traverse an actual VP= N tunnel and the connection between the 2 clients would be P2P.Should we ad= d a standard Gaps section=2C where we don't necessarily list the requiremen= ts but start building a list of gaps that will help clarify the problem sta= tement:It seems that we at least have a partial list already=2C like:- Dyna= mic discovery/configuration- Optimal path for high performance.- Ability to= select the closest entry point. ThanksJC> From: shanna@juniper.net > To: Chris.Ulliott@cesg.gsi.gov.uk=3B ipsec@ietf.org > Date: Wed=2C 7 Mar 2012 17:51:51 -0500 > Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED >=20 > Upon reflection=2C I can see how "Point to Point VPNs" is problematic > as a description of the problem. Really it's more about dynamically > creating SAs so that any endpoint or gateway can communicate directly > with any other=2C as permitted by policy. And how can we do this in a > manageable manner in a large-scale environment where endpoints are > mobile and configurations and policies change often? >=20 > So "Dynamic Mesh VPNs" is fine with me. Whatever the WG feels is best. >=20 > Thanks=2C >=20 > Steve >=20 > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > > Of Ulliott=2C Chris > > Sent: Wednesday=2C March 07=2C 2012 4:53 PM > > To: 'ipsec@ietf.org' > > Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED > >=20 > > Classification:UNCLASSIFIED > >=20 > > How about "dynamic mesh VPNs" as a title as I think the dynamic part is > > key here and probably an important aspect of the use cases. > >=20 > > Chris > >=20 > > [This message has been sent by a mobile device] > >=20 > > ----- Original Message ----- > > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > > Sent: Wednesday=2C March 07=2C 2012 09:17 PM > > To: IPsecme WG > > Subject: [IPsec] P2P VPN draft > >=20 > > Hi Steve=2C > >=20 > > a few initial comments. > >=20 > > * The draft is short and clear. Thanks for that! > > * I have a problem with the title (and even more=2C with the "file > > name" > > of the draft). P2P is usually perceived as peer-to-peer=2C which > > skews > > the discussion towards one particular use case=2C that of > > endpoint-to-endpoint. I suggest to use "Mesh IPsec VPN" instead. > > * I am unclear about 2.2: so what if you "suddenly need to exchange a > > lot of data". How is it different from normal IP traffic load > > management? The text is simply too vague here. Ideally=2C should we > > expect the traffic to migrate to other gateways? To go directly > > between endpoints? To establish priorities on existing gateways? > >=20 > > Thanks=2C > >=20 > > Yaron > >=20 > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > >=20 > > *********************************************************************** > > ***** > > Communications with GCHQ may be monitored and/or recorded > > for system efficiency and other lawful purposes. Any views or > > opinions expressed in this e-mail do not necessarily reflect GCHQ > > policy. This email=2C and any attachments=2C is intended for the > > attention of the addressee(s) only. Its unauthorised use=2C > > disclosure=2C storage or copying is not permitted. If you are not the > > intended recipient=2C please notify postmaster@gchq.gsi.gov.uk. > >=20 > > This information is exempt from disclosure under the Freedom of > > Information Act 2000 and may be subject to exemption under > > other UK information legislation. Refer disclosure requests to > > GCHQ on 01242 221491 ext 30306 (non-secure) or email > > infoleg@gchq.gsi.gov.uk > >=20 > > *********************************************************************** > > ***** > >=20 > >=20 > > The original of this email was scanned for viruses by the Government > > Secure Intranet virus scanning service supplied by Cable&Wireless > > Worldwide in partnership with MessageLabs. (CCTM Certificate Number > > 2009/09/0052.) On leaving the GSi this email was certified virus free. > > Communications via the GSi may be automatically logged=2C monitored > > and/or recorded for legal purposes. > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = --_6c223cb7-cfe2-4855-85dc-d88350fd6ef4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yes=2C that is fine.
 =3B
Although one could argue that the 1st U= se case is P2P in its nature=3B =3Bas only some signaling would need to= traverse an actual VPN tunnel and the connection between the 2 clients wou= ld be P2P.
Should we add a standard Gaps section=2C where we don't neces= sarily list the requirements but start building a list of gaps =3Bthat = will help clarify the problem statement:
It seems that we at least have = a partial list already=2C like:
- Dynamic discovery/configuration
- O= ptimal path for high performance.
- Ability to select the closest entry = point.
 =3B
Thanks
JC
>=3B From: shanna@juniper.net<= br>>=3B To: Chris.Ulliott@cesg.gsi.gov.uk=3B ipsec@ietf.org
>=3B Dat= e: Wed=2C 7 Mar 2012 17:51:51 -0500
>=3B Subject: Re: [IPsec] P2P VPN = draft UNCLASSIFIED
>=3B
>=3B Upon reflection=2C I can see how "P= oint to Point VPNs" is problematic
>=3B as a description of the proble= m. Really it's more about dynamically
>=3B creating SAs so that any en= dpoint or gateway can communicate directly
>=3B with any other=2C as p= ermitted by policy. And how can we do this in a
>=3B manageable manner= in a large-scale environment where endpoints are
>=3B mobile and conf= igurations and policies change often?
>=3B
>=3B So "Dynamic Mesh= VPNs" is fine with me. Whatever the WG feels is best.
>=3B
>=3B= Thanks=2C
>=3B
>=3B Steve
>=3B
>=3B >=3B -----Orig= inal Message-----
>=3B >=3B From: ipsec-bounces@ietf.org [mailto:ips= ec-bounces@ietf.org] On Behalf
>=3B >=3B Of Ulliott=2C Chris
>= =3B >=3B Sent: Wednesday=2C March 07=2C 2012 4:53 PM
>=3B >=3B To:= 'ipsec@ietf.org'
>=3B >=3B Subject: Re: [IPsec] P2P VPN draft UNCLA= SSIFIED
>=3B >=3B
>=3B >=3B Classification:UNCLASSIFIED
&= gt=3B >=3B
>=3B >=3B How about "dynamic mesh VPNs" as a title as = I think the dynamic part is
>=3B >=3B key here and probably an impor= tant aspect of the use cases.
>=3B >=3B
>=3B >=3B Chris
&= gt=3B >=3B
>=3B >=3B [This message has been sent by a mobile devi= ce]
>=3B >=3B
>=3B >=3B ----- Original Message -----
>= =3B >=3B From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
>=3B >= =3B Sent: Wednesday=2C March 07=2C 2012 09:17 PM
>=3B >=3B To: IPsec= me WG <=3Bipsec@ietf.org>=3B
>=3B >=3B Subject: [IPsec] P2P VPN = draft
>=3B >=3B
>=3B >=3B Hi Steve=2C
>=3B >=3B
&= gt=3B >=3B a few initial comments.
>=3B >=3B
>=3B >=3B *= The draft is short and clear. Thanks for that!
>=3B >=3B * I have= a problem with the title (and even more=2C with the "file
>=3B >=3B= name"
>=3B >=3B of the draft). P2P is usually perceived as peer= -to-peer=2C which
>=3B >=3B skews
>=3B >=3B the discussio= n towards one particular use case=2C that of
>=3B >=3B endpoint-= to-endpoint. I suggest to use "Mesh IPsec VPN" instead.
>=3B >=3B = * I am unclear about 2.2: so what if you "suddenly need to exchange a
&g= t=3B >=3B lot of data". How is it different from normal IP traffic lo= ad
>=3B >=3B management? The text is simply too vague here. Idea= lly=2C should we
>=3B >=3B expect the traffic to migrate to othe= r gateways? To go directly
>=3B >=3B between endpoints? To estab= lish priorities on existing gateways?
>=3B >=3B
>=3B >=3B Th= anks=2C
>=3B >=3B
>=3B >=3B Yaron
>=3B >=3B
= >=3B >=3B _______________________________________________
>=3B >= =3B IPsec mailing list
>=3B >=3B IPsec@ietf.org
>=3B >=3B htt= ps://www.ietf.org/mailman/listinfo/ipsec
>=3B >=3B
>=3B >=3B= ***********************************************************************>=3B >=3B *****
>=3B >=3B Communications with GCHQ may be monit= ored and/or recorded
>=3B >=3B for system efficiency and other lawfu= l purposes. Any views or
>=3B >=3B opinions expressed in this e-mail= do not necessarily reflect GCHQ
>=3B >=3B policy. This email=2C an= d any attachments=2C is intended for the
>=3B >=3B attention of the = addressee(s) only. Its unauthorised use=2C
>=3B >=3B disclosure=2C s= torage or copying is not permitted. If you are not the
>=3B >=3B in= tended recipient=2C please notify postmaster@gchq.gsi.gov.uk.
>=3B >= =3B
>=3B >=3B This information is exempt from disclosure under the = Freedom of
>=3B >=3B Information Act 2000 and may be subject to exem= ption under
>=3B >=3B other UK information legislation. Refer disclo= sure requests to
>=3B >=3B GCHQ on 01242 221491 ext 30306 (non-secur= e) or email
>=3B >=3B infoleg@gchq.gsi.gov.uk
>=3B >=3B
&= gt=3B >=3B **************************************************************= *********
>=3B >=3B *****
>=3B >=3B
>=3B >=3B
>= =3B >=3B The original of this email was scanned for viruses by the Govern= ment
>=3B >=3B Secure Intranet virus scanning service supplied by Ca= ble&=3BWireless
>=3B >=3B Worldwide in partnership with MessageLa= bs. (CCTM Certificate Number
>=3B >=3B 2009/09/0052.) On leaving the= GSi this email was certified virus free.
>=3B >=3B Communications v= ia the GSi may be automatically logged=2C monitored
>=3B >=3B and/or= recorded for legal purposes.
>=3B >=3B ____________________________= ___________________
>=3B >=3B IPsec mailing list
>=3B >=3B IP= sec@ietf.org
>=3B >=3B https://www.ietf.org/mailman/listinfo/ipsec>=3B _______________________________________________
>=3B IPsec ma= iling list
>=3B IPsec@ietf.org
>=3B https://www.ietf.org/mailman/= listinfo/ipsec
= --_6c223cb7-cfe2-4855-85dc-d88350fd6ef4_-- From ynir@checkpoint.com Wed Mar 7 21:46:22 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E754221F84BD for ; Wed, 7 Mar 2012 21:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.474 X-Spam-Level: X-Spam-Status: No, score=-10.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ra3ZEMUm6RIB for ; Wed, 7 Mar 2012 21:46:21 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 094C521F84A0 for ; Wed, 7 Mar 2012 21:46:12 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q285k83m017088; Thu, 8 Mar 2012 07:46:08 +0200 X-CheckPoint: {4F5847DE-0-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 8 Mar 2012 07:46:08 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 8 Mar 2012 07:46:07 +0200 From: Yoav Nir To: Yaron Sheffer Date: Thu, 8 Mar 2012 07:46:10 +0200 Thread-Topic: [IPsec] P2P VPN Problem Statement - why is this hard? Thread-Index: Acz87sI1fttWhZr1Qc6l88WaAFtsdQ== Message-ID: <846C2871-3280-4D87-AA5A-D59B07755441@checkpoint.com> References: <1E6FEEF8-6A73-40C4-A617-886D0BE12EB8@checkpoint.com> <4F57D266.7090809@gmail.com> In-Reply-To: <4F57D266.7090809@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: IPsecme WG , Stephen Hanna Subject: Re: [IPsec] P2P VPN Problem Statement - why is this hard? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 05:46:22 -0000 There's actually two types of stars.=20 One is where the satellite forwards *everything* to the hub, even some user= behind the satellite checking their Facebook account. That kind of satelli= te really needs very little configuration. The other is where the satellite forwards only traffic going to an address = that is behind *some* satellite or hub gateway. This requires that it parti= tion the Internet into a "protected" and a "non-protected" parts. Stars vs Mesh is IMO important, because with stars you only need to propaga= te SPDs while with mesh you also need to propagate PADs. The mechanisms for= propagating each kind of information may be different when the time comes = to discuss solutions. Yoav On Mar 7, 2012, at 11:25 PM, Yaron Sheffer wrote: > Hi Yoav, Steve, >=20 > I'm not sure that this star-vs-mesh discussion is so important, because=20 > even if you choose the simplest star topology, data propagation is still= =20 > required. Configuration of the satellites is simple: *everything* goes=20 > to the hub. But the hub needs to know which satellite to send each=20 > packet to, and as the satellites' configuration changes, the hub=20 > constantly needs to be reconfigured. So it's really the same problem in=20 > a more limited form. >=20 > Thanks, > Yaron >=20 > On 03/07/2012 12:54 AM, Yoav Nir wrote: >> Hi Steve >>=20 >> On Mar 6, 2012, at 11:54 PM, Stephen Hanna wrote: >>=20 >>> So please review this short document and send comments. >>=20 >> While the draft does a good job of describing use cases, and certain ina= dequate solutions, I think it's missing a description of why this is hard. >>=20 >> Even if we accept the solution of a star topology, where a satellite nee= ds only have one single tunnel, there are really two choices: >> 1. that each satellite know about all the protected networks of all the= gateways in the configuration, or >> 2. that satellites send all traffic to the "core" or "hub" gateways. Th= is includes clear traffic (as in HTTP to facebook.com). This increased the = load even more. >>=20 >> If you don't want #2, then the satellite still needs to know about every= IP address whether it is protected by some gateway (and therefore needs to= go in the tunnel), or not (and so packets with that destination should go = out in the clear). Since the protected networks change, this requires that = information to propagate throughout the network, and dynamic updates to SPD >>=20 >> If we don't want a star topology, the gateways or endpoints still need t= o know what is or is not encrypted. They also need to either know about all= peers, or be able to find the peer and (securely) learn how it should auth= enticate. Either way, without a star topology, you need dynamic updates to = PAD. >>=20 >> I think the draft should mention this. >>=20 >> Yoav >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From ynir@checkpoint.com Wed Mar 7 23:09:02 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384EC21E8024 for ; Wed, 7 Mar 2012 23:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.476 X-Spam-Level: X-Spam-Status: No, score=-10.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9odzAY2HkVk0 for ; Wed, 7 Mar 2012 23:09:01 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 146C721F8629 for ; Wed, 7 Mar 2012 23:09:00 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2878vk4028551; Thu, 8 Mar 2012 09:08:57 +0200 X-CheckPoint: {4F585B46-0-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 8 Mar 2012 09:08:57 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 8 Mar 2012 09:08:56 +0200 From: Yoav Nir To: "Ulliott, Chris" Date: Thu, 8 Mar 2012 09:08:59 +0200 Thread-Topic: [IPsec] P2P VPN draft Thread-Index: Acz8+lOjmaKbqmBtQai3HKzilch/rw== Message-ID: <8B9F6374-1FF0-41CF-8A38-D070F2D47CE5@checkpoint.com> References: <20549DD10769DA47A86F0F0FAF8012DD0349D9EEC6@PIACHEVEX00.GCHQ.GOV.UK> In-Reply-To: <20549DD10769DA47A86F0F0FAF8012DD0349D9EEC6@PIACHEVEX00.GCHQ.GOV.UK> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "ipsec@ietf.org" Subject: Re: [IPsec] P2P VPN draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 07:09:02 -0000 I like it. On Mar 7, 2012, at 11:52 PM, Ulliott, Chris wrote: > Classification:UNCLASSIFIED >=20 > How about "dynamic mesh VPNs" as a title as I think the dynamic part is k= ey here and probably an important aspect of the use cases. >=20 > Chris >=20 > [This message has been sent by a mobile device] >=20 > ----- Original Message ----- > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > Sent: Wednesday, March 07, 2012 09:17 PM > To: IPsecme WG > Subject: [IPsec] P2P VPN draft >=20 > Hi Steve, >=20 > a few initial comments. >=20 > * The draft is short and clear. Thanks for that! > * I have a problem with the title (and even more, with the "file name" > of the draft). P2P is usually perceived as peer-to-peer, which skews > the discussion towards one particular use case, that of > endpoint-to-endpoint. I suggest to use "Mesh IPsec VPN" instead. > * I am unclear about 2.2: so what if you "suddenly need to exchange a > lot of data". How is it different from normal IP traffic load > management? The text is simply too vague here. Ideally, should we > expect the traffic to migrate to other gateways? To go directly > between endpoints? To establish priorities on existing gateways? >=20 > Thanks, >=20 > Yaron >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > *************************************************************************= *** > Communications with GCHQ may be monitored and/or recorded=20 > for system efficiency and other lawful purposes. Any views or=20 > opinions expressed in this e-mail do not necessarily reflect GCHQ=20 > policy. This email, and any attachments, is intended for the=20 > attention of the addressee(s) only. Its unauthorised use,=20 > disclosure, storage or copying is not permitted. If you are not the > intended recipient, please notify postmaster@gchq.gsi.gov.uk. =20 >=20 > This information is exempt from disclosure under the Freedom of=20 > Information Act 2000 and may be subject to exemption under > other UK information legislation. Refer disclosure requests to=20 > GCHQ on 01242 221491 ext 30306 (non-secure) or email > infoleg@gchq.gsi.gov.uk >=20 > *************************************************************************= *** >=20 >=20 > The original of this email was scanned for viruses by the Government Secu= re Intranet virus scanning service supplied by Cable&Wireless Worldwide in = partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On le= aving the GSi this email was certified virus free. > Communications via the GSi may be automatically logged, monitored and/or = recorded for legal purposes. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From tjcarlin@iol.unh.edu Mon Mar 12 08:19:46 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED0221F8773 for ; Mon, 12 Mar 2012 08:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sq2Fkq9Q2gen for ; Mon, 12 Mar 2012 08:19:46 -0700 (PDT) Received: from exprod5og111.obsmtp.com (exprod5og111.obsmtp.com [64.18.0.22]) by ietfa.amsl.com (Postfix) with SMTP id A558921F875B for ; Mon, 12 Mar 2012 08:19:45 -0700 (PDT) Received: from postal.iol.unh.edu ([132.177.123.84]) by exprod5ob111.postini.com ([64.18.4.12]) with SMTP ID DSNKT14UEES9DsL6JBZgjy7Yut9f1ra1z5gX@postini.com; Mon, 12 Mar 2012 08:19:45 PDT Received: from patriot.iol.unh.edu (patriot.iol.unh.edu [132.177.118.220]) by postal.iol.unh.edu (Postfix) with ESMTP id 714F38F0067; Mon, 12 Mar 2012 11:19:44 -0400 (EDT) From: Timothy Carlin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Mar 2012 11:19:44 -0400 To: IPsecme WG Message-Id: <55DE56DE-B652-47C7-B42C-4C76014FFE9F@iol.unh.edu> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [IPsec] Security Gateway PMTU Discovery X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 15:19:46 -0000 Hello, The UNH-IOL would like to ask the Working Group for feedback regarding = an issue we've observed. This issue concerns how a Security Gateway handles IPv6 MTU restrictions = and fragmentations. Specifically, how should a SGW handle a received = Packet Too Big message, for an ESP packet which it transmitted? =46rom RFC 4301, Section 6.1.1, there are two options: "If an ICMP PMTU message passes the checks above and the system is configured to accept it, then there are two possibilities. If the implementation applies fragmentation on the ciphertext side of the boundary, then the accepted PMTU information is passed to the forwarding module (outside of the IPsec implementation), which uses it to manage outbound packet fragmentation. If the implementation is configured to effect plaintext side fragmentation, then the PMTU information is passed to the plaintext side and processed as described in Section 8.2." The first option, applying fragmentation on the ciphertext side of the = boundary seems to be optional, although it's not clear to us if it only = applies to IPv4, according to RFC 4303, Section 3.3.4: "Thus, an ESP implementation MAY choose to not support fragmentation and may mark transmitted packets with the DF bit, to facilitate Path MTU (PMTU) discovery." The second option is describe in RFC 4301, Section 8.2.1, which is to = propagate the PMTU information via a synthesized Packet Too Big message. So, there are two questions we would like to raise. First, if ciphertext side fragmentation is indeed optional, and an IPv6 = SGW implementation should choose to not support it, MUST it support = generating the synthesized PTB message? Second, the SGW can set the MTU to 1280 bytes, or less, in the = synthesized Packet Too Big message, however, the originator is not = required to reduce the size of fragments to less than 1280 bytes, but by = adding the ESP header the resulting packets will be larger than 1280 = bytes. So, if the upstream MTU is 1280 bytes, and an SGW implementation = chooses to not to support ciphertext side fragmentation, what is the = correct behavior? Regards, Timothy Carlin ---- Timothy Carlin UNH-IOL= From yaronf.ietf@gmail.com Mon Mar 12 14:06:31 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9453B11E812F for ; Mon, 12 Mar 2012 14:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxafLKFu+-AV for ; Mon, 12 Mar 2012 14:06:27 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3849E11E812D for ; Mon, 12 Mar 2012 14:06:26 -0700 (PDT) Received: by werb10 with SMTP id b10so4628418wer.31 for ; Mon, 12 Mar 2012 14:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=PTnklp+m9LkZnB6fC4si72uHQHgpsg7YK6YdMZ6g+Uo=; b=TiqY8CrN6nF9lEv2V3HLsmU4zus9TCEpcTXmKjeTJjoh3wSy/d4Dr9dvoKB2gJpimP 5rFWKarKzjVIDNfPgi2jyUJME5WYxeRw1TpKg/fmQF89rEJxX65rLXqiyt3h93gXuhu9 9fHbK6kSf44RWwgLkA8XZrVa1RXA8bexfZ8JUZ1/YtwziVpsC38BMFW74u3dzFNTl0On 2Wl3xfDPIFQTw+u0gH0npcoSTCX2amz0epVnvMcv0Kv8xn+tqQkS8FCNEFTvv/irIFxi pRV6jRUkUAAW2+VfEPZAjgutzHU6y9RDTS55oCBnCQkD+vNlfnpnkCWxt8B4/viul8ni 6zXQ== Received: by 10.180.93.4 with SMTP id cq4mr1170876wib.21.1331586384852; Mon, 12 Mar 2012 14:06:24 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-179-165-28.red.bezeqint.net. [79.179.165.28]) by mx.google.com with ESMTPS id t20sm63093167wiv.0.2012.03.12.14.06.23 (version=SSLv3 cipher=OTHER); Mon, 12 Mar 2012 14:06:24 -0700 (PDT) Message-ID: <4F5E654E.1070002@gmail.com> Date: Mon, 12 Mar 2012 23:06:22 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Please comment on Steve's P2P draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 21:06:31 -0000 Hi, Steve's document http://tools.ietf.org/html/draft-ietf-ipsecme-p2p-vpn-problem-00 happens to be (almost) the only thing on our agenda for Paris. I am sure once you've read it you will have some comments to discuss on this list: do the use cases make sense? Are there additional ones? Are they presented in sufficient depth to derive requirements? And so on. We would prefer to get this discussion going *before* Paris, so that we can use the F2F meeting to focus on the most thorny issues. Thanks, Yaron From MLS@Cisco.COM Mon Mar 12 14:57:00 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A209021E80F3 for ; Mon, 12 Mar 2012 14:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZrLaC43WRWH for ; Mon, 12 Mar 2012 14:57:00 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 108B921E80ED for ; Mon, 12 Mar 2012 14:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=MLS@cisco.com; l=2652; q=dns/txt; s=iport; t=1331589419; x=1332799019; h=date:from:subject:to:cc:message-id:mime-version; bh=EIcvk617yhX6ee69FlgJ89esh4zMj1Uylu0Xx2TrKF8=; b=lpvxxjCxbjPIlHZCYIGbLrZZZjD9D9oYwagjxUwo94SbkZXu3RsH2JLt hpKo8ciyoDLUu6rvxZRSJ2xXpJPm803HGiE51ym1rvcNpR97y2FcZtoO1 hinRCb3y6LNFJuVJQHEZPpWBEjSiZRq1ehnsOyrK6+mPcCDMpTfgbaN6G s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFADlwXk+tJV2b/2dsb2JhbABDpDiRHYEHggkBAQEWAWYMDxEEAQEoFxEcCQkhIodonRIBnn+JRIQbgyIEiFSMeIsrhHiDBA X-IronPort-AV: E=Sophos;i="4.73,573,1325462400"; d="scan'208";a="65799743" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 12 Mar 2012 21:56:58 +0000 Received: from Magno.Cisco.COM (magno.cisco.com [172.16.177.227]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2CLuvpP010202 for ; Mon, 12 Mar 2012 21:56:58 GMT Received: from Cisco.COM by Cisco.COM (PMDF V5.1-7 #12361) id <01OD167DRHJG9AMI66@Cisco.COM> for ipsec@ietf.org; Mon, 12 Mar 2012 14:56:56 PST Date: Mon, 12 Mar 2012 14:56:56 -0800 (PST) From: Mike Sullenberger To: shanna@juniper.net Message-id: <01OD167DRHJI9AMI66@Cisco.COM> X-VMS-To: IN%"shanna@juniper.net" X-VMS-Cc: IN%"ipsec@ietf.org",IN%"Chris.Ulliott@cesg.gsi.gov.uk" MIME-version: 1.0 Cc: ipsec@ietf.org, Chris.Ulliott@cesg.gsi.gov.uk Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 21:57:00 -0000 Steve, I do not think changing the name to "Dynamic Mesh VPN" is a good idea. The first thing that is going to happen is that it is going to be shortened to "DMVPN" and then we have conflict with Cisco DMVPN, which would be confusing and also "DMVPN" is a registered trademark. It would be best to use some other synonym for "Dynamic Mesh". Mike. >Upon reflection, I can see how "Point to Point VPNs" is problematic >as a description of the problem. Really it's more about dynamically >creating SAs so that any endpoint or gateway can communicate directly >with any other, as permitted by policy. And how can we do this in a >manageable manner in a large-scale environment where endpoints are >mobile and configurations and policies change often? > >So "Dynamic Mesh VPNs" is fine with me. Whatever the WG feels is best. > >Thanks, > >Steve > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of Ulliott, Chris >> Sent: Wednesday, March 07, 2012 4:53 PM >> To: 'ipsec@ietf.org' >> Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED >> >> Classification:UNCLASSIFIED >> >> How about "dynamic mesh VPNs" as a title as I think the dynamic part is >> key here and probably an important aspect of the use cases. >> >> Chris >> >> [This message has been sent by a mobile device] >> >> ----- Original Message ----- >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >> Sent: Wednesday, March 07, 2012 09:17 PM >> To: IPsecme WG >> Subject: [IPsec] P2P VPN draft >> >> Hi Steve, >> >> a few initial comments. >> >> * The draft is short and clear. Thanks for that! >> * I have a problem with the title (and even more, with the "file >> name" of the draft). P2P is usually perceived as peer-to-peer, >> which skews the discussion towards one particular use case, that >> of endpoint-to-endpoint. I suggest to use "Mesh IPsec VPN" instead. >> * I am unclear about 2.2: so what if you "suddenly need to exchange a >> lot of data". How is it different from normal IP traffic load >> management? The text is simply too vague here. Ideally, should we >> expect the traffic to migrate to other gateways? To go directly >> between endpoints? To establish priorities on existing gateways? >> >> Thanks, >> >> Yaron +------------------------------------------------+ | Mike Sullenberger; DSE | | mls@cisco.com .:|:.:|:. | | Customer Advocacy CISCO | +------------------------------------------------+ From vishwas.ietf@gmail.com Mon Mar 12 16:11:57 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7659821E806D for ; Mon, 12 Mar 2012 16:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.94 X-Spam-Level: X-Spam-Status: No, score=-3.94 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdwUu6RIuaeJ for ; Mon, 12 Mar 2012 16:11:56 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id BCDE621E80FD for ; Mon, 12 Mar 2012 16:11:55 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3596795ghb.31 for ; Mon, 12 Mar 2012 16:11:55 -0700 (PDT) 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=Q1KCsxPe2ApusT6vVMD55Jhf8U9DYyYSGIQyDHJWtog=; b=WP/sqK+rXqLKANen+043MaBydf7KLKEtYtRu9hhqy13eqCQAEDRcP0pITz6qMS9oiF odNtkQ+athiydBrAlpPJ3IO7PycF7GVrrjL2mfIbXcxDVwUbOLrFd6JYpd0qFm2wIFcM JpjhdSO/YM8gnZqEtlGb4YNYI5d09qVqzjXj6iBY4ypX+i3tYlR1bCYiPECNtPh1SPFx iYhgV9NFZKdc0Ql9fmys1Nmde03hDkeoUvX0Pp+sy8dINzqj5Fms8FZIX8yVXNsP6RDq OhXh99oR3SYAK6OBDPEnwEbRBEOuY5nD6lzhpe2spVpnk9B//8L3Zk4PLQpf0xnxPkjM slzw== MIME-Version: 1.0 Received: by 10.182.121.101 with SMTP id lj5mr9773145obb.39.1331593915013; Mon, 12 Mar 2012 16:11:55 -0700 (PDT) Received: by 10.182.134.73 with HTTP; Mon, 12 Mar 2012 16:11:54 -0700 (PDT) In-Reply-To: References: Date: Mon, 12 Mar 2012 16:11:54 -0700 Message-ID: From: Vishwas Manral To: Stephen Hanna Content-Type: multipart/alternative; boundary=14dae93998f74a1abe04bb13def4 Cc: IPsecme WG Subject: Re: [IPsec] Please Comment on New P2P VPN Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:11:57 -0000 --14dae93998f74a1abe04bb13def4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Steve, ** ** > > 1. I guess the problem statement is not just about lessening the number o= f > configuration commands but also the fact that static configuration may no= t > work in some cases. The spokes may get new addresses every time they come > up (using DHCP/ PPPoE) and hence the communication end point identifiers > change. > > **** > > SH> Yes, the dynamic nature of configuration data is as much a problem as > the size of that data. > Great. This is a critical factor for even smaller deployments and not just about the amount of configuration but the fact the configuration cannot be done. **** > > ** ** > > 2. I am not sure but the use cases do not come out very clearly to me. Th= e > most important part of the communication is of end-sites communicating to > the gateway hub router. In a typical enterprise deployment that would mea= n > a branches connected to the campus/ data center. This tunnel is permanent= . > Mainly to access resources at the back end. There could be redundancy her= e > to provide HA.**** > > > 3. We then optionally require communication between end sites and such > communication may be temporary or permanent. For such cases we want to be > able to unburden the gateway so as to not cause overload. > > 4. We could have multiple gateways work in a cluster mode to serve a set > of end-sites and to provide HA. > > 5. The clusters may in turn communicate with each other. > > **** > > SH> I=92m sorry that the use cases are not clear. However, I=92m sure we = can > and will improve them.**** > > ** ** > > SH> Your description of =93The most important part of the communication= =94 > seems to be focused only on use case 2.2 in the draft. In your example, > several =93end-sites=94 need to establish a direct connection to each oth= er > instead of going through a =93gateway hub router=94. To use the terminolo= gy > defined in the draft, that=92s a gateway-to-gateway use case. I understan= d > that you consider that to be the most important use case but others have > previously spoken out about the importance of use cases 2.1 and 2.3. > I meant 2.2 is most important from our perspective as HP. I agree 2.1 and 2.3 are important too and could be realized the same way, where an IPsec tunnel could terminate on a gateway/ load balancer. > **** > > ** ** > > SH> So I do agree with your description of use case 2.2. Maybe we should > add another example under use case 2.2, based on your example. Could you > provide more details about why a direct connection between two =93end-sit= es=94 > might be needed? I can add that as an example in the next version of the > draft.**** > > ** > In a simple use case we want hub and spoke topology for say the DC and the branches. This would also be true of ATM's connecting to their DC. However for scalability reasons we would not want all traffic to go through the hub. In the ATM example we could want VoIP session to bypass the DC and have a direct connectivity between themselves. There are multiple other uses cases for the same. These new sessions however are temporary, when compared to permanent branch to hub connections. > ** > > SH> And thanks for volunteering to participate in formulating the problem > statement and the solutions. That=92s great! > Absolutely. Let me know if you need the exact text for the same and I can help provide it. Thanks, Vishwas > **** > > Take care,**** > > ** ** > > Steve**** > > ** ** > > *From:* Vishwas Manral [mailto:vishwas.ietf@gmail.com] > *Sent:* Tuesday, March 06, 2012 5:23 PM > *To:* Stephen Hanna > *Cc:* IPsecme WG > *Subject:* Re: [IPsec] Please Comment on New P2P VPN Problem Statement***= * > > ** ** > > Hi Steve, > > I agree to the need of standardization for a large scale point-to-point > solution. > > 1. I guess the problem statement is not just about lessening the number o= f > configuration commands but also the fact that static configuration may no= t > work in some cases. The spokes may get new addresses every time they come > up (using DHCP/ PPPoE) and hence the communication end point identifiers > change. > > 2. I am not sure but the use cases do not come out very clearly to me. Th= e > most important part of the communication is of end-sites communicating to > the gateway hub router. In a typical enterprise deployment that would mea= n > a branches connected to the campus/ data center. This tunnel is permanent= . > Mainly to access resources at the back end. There could be redundancy her= e > to provide HA. > > 3. We then optionally require communication between end sites and such > communication may be temporary or permanent. For such cases we want to be > able to unburden the gateway so as to not cause overload. > > 4. We could have multiple gateways work in a cluster mode to serve a set > of end-sites and to provide HA. > > 5. The clusters may in turn communicate with each other. > > We as HP would love to participate in this draft as well as any solution > document that is produced. > > Thanks, > Vishwas**** > > On Tue, Mar 6, 2012 at 1:54 PM, Stephen Hanna wrote:= * > *** > > In case you didn't notice, I have posted the -00 version > of the P2P VPN problem statement. The URL is below. > Please review and comment. > > I'm especially interested in getting feedback on the > use cases in this document. As previously agreed, they > are based on the use cases in section 2.2 of the > previous problem statement draft. I have tried to > clarify those use cases, especially by providing > definitions of terms and using those terms consistently > throughout the document. > > After we reach consensus on the use cases, we can move > on to defining requirements derived from those use cases. > But I see no point in talking about requirements before > we've agreed on a clear description of the problems > that we are trying to solve. > > So please review this short document and send comments. > > Thanks, > > Steve > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] > On Behalf Of Internet-Drafts@ietf.org > Sent: Tuesday, March 06, 2012 11:01 AM > To: i-d-announce@ietf.org > Cc: ipsec@ietf.org > Subject: I-D ACTION:draft-ietf-ipsecme-p2p-vpn-problem-00.txt > > A new Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Security Maintenance and Extensions > Working Group of the IETF. > > Title : Point to Point VPNs Problem Statement > Author(s) : S. Hanna > Filename : draft-ietf-ipsecme-p2p-vpn-problem > Pages : 13 > Date : March 6, 2012 > > This document describes the problem of enabling a large number of > systems to communicate directly using IPsec to protect the traffic > between them. Manual configuration of all possible tunnels is too > cumbersome in such cases, so an automated method is needed. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-p2p-vpn-problem > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec**** > > ** ** > --14dae93998f74a1abe04bb13def4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Steve,


=A0

1. I guess the problem statement is not just about lessening the number = of configuration commands but also the fact that static configuration may n= ot work in some cases. The spokes may get new addresses every time they com= e up (using DHCP/ PPPoE) and hence the communication end point identifiers = change.

SH> Yes, the dynamic nature of conf= iguration data is as much a problem as the size of that data.

Great. This is a critical factor for even sma= ller deployments and not just about the amount of configuration but the fac= t the configuration cannot be done.

=A0

2. I am not sure but the use cases do not come out very clearly to me. T= he most important part of the communication is of end-sites communicating t= o the gateway hub router. In a typical enterprise deployment that would mea= n a branches connected to the campus/ data center. This tunnel is permanent= . Mainly to access resources at the back end. There could be redundancy her= e to provide HA.


3. We then optionally require communication betw= een end sites and such communication may be temporary or permanent. For suc= h cases we want to be able to unburden the gateway so as to not cause overl= oad.

4. We could have multiple gateways work in a cluster mode to serve a se= t of end-sites and to provide HA.

5. The clusters may in turn commun= icate with each other.

SH> I=92m sorry = that the use cases are not clear. However, I=92m sure we can and will impro= ve them.

=A0<= /p>

SH> Your descriptio= n of =93The most important part of the communication=94 seems to be focused= only on use case 2.2 in the draft. In your example, several =93end-sites= =94 need to establish a direct connection to each other instead of going th= rough a =93gateway hub router=94. To use the terminology defined in the dra= ft, that=92s a gateway-to-gateway use case. I understand that you consider = that to be the most important use case but others have previously spoken ou= t about the importance of use cases 2.1 and 2.3.

I meant 2.2 is most important from our perspe= ctive as HP.

I agree 2.1 and 2.3 are important too and could be real= ized the same way, where an IPsec tunnel could terminate on a gateway/ load= balancer.
=A0

=A0<= /p>

SH> So I do agree w= ith your description of use case 2.2. Maybe we should add another example u= nder use case 2.2, based on your example. Could you provide more details ab= out why a direct connection between two =93end-sites=94 might be needed? I = can add that as an example in the next version of the draft.<= /span>

=A0

In a simple use case we want hub and spoke topolo= gy for say the DC and the branches. This would also be true of ATM's co= nnecting to their DC.

However for scalability reasons we would not want all traffic to go thr= ough the hub. In the ATM example we could want VoIP session to bypass the D= C and have a direct connectivity between themselves. There are multiple oth= er uses cases for the same. These new sessions however are temporary, when = compared to permanent branch to hub connections.
=A0

SH> And thanks for vol= unteering to participate in formulating the problem statement and the solut= ions. That=92s great!

Absolutely. Let me know if you need the exact= text for the same and I can help provide it.

Thanks,
Vishwas
= =A0

Take care,

=A0

Steve

=A0

From:= Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Tuesday, March 06, 2012 5:23 PM
To: Stephen HannaCc: IPsecme WG
Subject: Re: [IPsec] Please Comment on New= P2P VPN Problem Statement

=A0

Hi Steve,

I agree to the need of standardizat= ion for a large scale point-to-point solution.

1. I guess the proble= m statement is not just about lessening the number of configuration command= s but also the fact that static configuration may not work in some cases. T= he spokes may get new addresses every time they come up (using DHCP/ PPPoE)= and hence the communication end point identifiers change.

2. I am not sure but the use cases do not come out very clearly to me. = The most important part of the communication is of end-sites communicating = to the gateway hub router. In a typical enterprise deployment that would me= an a branches connected to the campus/ data center. This tunnel is permanen= t. Mainly to access resources at the back end. There could be redundancy he= re to provide HA.

3. We then optionally require communication between end sites and such = communication may be temporary or permanent. For such cases we want to be a= ble to unburden the gateway so as to not cause overload.

4. We could= have multiple gateways work in a cluster mode to serve a set of end-sites = and to provide HA.

5. The clusters may in turn communicate with each other.

We as H= P would love to participate in this draft as well as any solution document = that is produced.

Thanks,
Vishwas

On Tue, Mar 6, 2012 at 1:54 PM, Stephen Hanna <shanna@juniper.net> wrote:<= /u>

In case you didn't notice, I have posted = the -00 version
of the P2P VPN problem statement. The URL is below.
Please review and co= mment.

I'm especially interested in getting feedback on the
u= se cases in this document. As previously agreed, they
are based on the u= se cases in section 2.2 of the
previous problem statement draft. I have tried to
clarify those use case= s, especially by providing
definitions of terms and using those terms co= nsistently
throughout the document.

After we reach consensus on t= he use cases, we can move
on to defining requirements derived from those use cases.
But I see no p= oint in talking about requirements before
we've agreed on a clear de= scription of the problems
that we are trying to solve.

So please = review this short document and send comments.

Thanks,

Steve

-----Original Message-----
From: i-d-announce-bo= unces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf= .org
Sent: Tuesday, March 06, 2012 11:01 AM
To: i-d-announce@ietf.org
Cc: ipsec@ietf.org
Subject: I-D = ACTION:draft-ietf-ipsecme-p2p-vpn-problem-00.txt

A new Internet-Draft is available from the on-line Internet-Drafts dire= ctories.
This draft is a work item of the IP Security Maintenance and Ex= tensions Working Group of the IETF.

=A0 =A0Title =A0 =A0 =A0 =A0 : P= oint to Point VPNs Problem Statement
=A0 =A0Author(s) =A0 =A0 : S. Hanna
=A0 =A0Filename =A0 =A0 =A0: draft-i= etf-ipsecme-p2p-vpn-problem
=A0 =A0Pages =A0 =A0 =A0 =A0 : 13
=A0 =A0= Date =A0 =A0 =A0 =A0 =A0: March 6, 2012

=A0 This document describes = the problem of enabling a large number of
=A0 systems to communicate directly using IPsec to protect the traffic
= =A0 between them. =A0Manual configuration of all possible tunnels is too=A0 cumbersome in such cases, so an automated method is needed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ip= secme-p2p-vpn-problem

Internet-Drafts are also available by anon= ymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

Below is the data which will enable a= MIME compliant mail reader
implementation to automatically retrieve the= ASCII version of the
Internet-Draft.

_______________________________________________
I= Psec mailing list
IP= sec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

=A0

<= /div>

--14dae93998f74a1abe04bb13def4-- From Chris.Ulliott@cesg.gsi.gov.uk Mon Mar 12 16:17:03 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4597E21F8AEC for ; Mon, 12 Mar 2012 16:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPln9w-brGCM for ; Mon, 12 Mar 2012 16:17:02 -0700 (PDT) Received: from mail185.messagelabs.com (mail185.messagelabs.com [85.158.143.19]) by ietfa.amsl.com (Postfix) with SMTP id B8B4F21F8AE2 for ; Mon, 12 Mar 2012 16:16:59 -0700 (PDT) X-Env-Sender: Chris.Ulliott@cesg.gsi.gov.uk X-Msg-Ref: server-8.tower-185.messagelabs.com!1331594218!18587503!1 X-Originating-IP: [62.25.106.208] X-StarScan-Version: 6.5.5; banners=cesg.gsi.gov.uk,-,- X-VirusChecked: Checked Received: (qmail 11230 invoked from network); 12 Mar 2012 23:16:58 -0000 Received: from gateway-102.energis.gsi.gov.uk (HELO mx.hosting-w.gsi.gov.uk) (62.25.106.208) by server-8.tower-185.messagelabs.com with SMTP; 12 Mar 2012 23:16:58 -0000 From: "Ulliott, Chris" To: "'MLS@cisco.com'" , "'shanna@juniper.net'" Date: Mon, 12 Mar 2012 23:16:02 +0000 Thread-Topic: [IPsec] P2P VPN draft UNCLASSIFIED Thread-Index: Ac0Amya31KLkhnqiRf2Nx4AFogqU6QACvE/w Message-ID: <20549DD10769DA47A86F0F0FAF8012DD03554E292F@PIACHEVEX00.GCHQ.GOV.UK> In-Reply-To: <01OD167DRHJI9AMI66@Cisco.COM> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'ipsec@ietf.org'" Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:17:03 -0000 Classification:UNCLASSIFIED Good catch!=20 I've also thought of an additional use case, as I extend / change a networ= k within a data centre etc, it would be helpful if the crypto gateway coul= d learn of the new networks (through routing perhaps) and make them availa= ble through the encrypted tunnels. Chris [This message has been sent by a mobile device] ----- Original Message ----- From: Mike Sullenberger [mailto:MLS@cisco.com] Sent: Monday, March 12, 2012 10:56 PM To: shanna@juniper.net Cc: ipsec@ietf.org ; Ulliott, Chris Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED Steve, I do not think changing the name to "Dynamic Mesh VPN" is a good idea. The first thing that is going to happen is that it is going to be=20 shortened to "DMVPN" and then we have conflict with Cisco DMVPN, which would be confusing and also "DMVPN" is a registered trademark. It would be best to use some other synonym for "Dynamic Mesh". Mike. >Upon reflection, I can see how "Point to Point VPNs" is problematic >as a description of the problem. Really it's more about dynamically >creating SAs so that any endpoint or gateway can communicate directly >with any other, as permitted by policy. And how can we do this in a >manageable manner in a large-scale environment where endpoints are >mobile and configurations and policies change often? > >So "Dynamic Mesh VPNs" is fine with me. Whatever the WG feels is best. > >Thanks, > >Steve > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of Ulliott, Chris >> Sent: Wednesday, March 07, 2012 4:53 PM >> To: 'ipsec@ietf.org' >> Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED >>=20 >> Classification:UNCLASSIFIED >>=20 >> How about "dynamic mesh VPNs" as a title as I think the dynamic part is= >> key here and probably an important aspect of the use cases. >>=20 >> Chris >>=20 >> [This message has been sent by a mobile device] >>=20 >> ----- Original Message ----- >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >> Sent: Wednesday, March 07, 2012 09:17 PM >> To: IPsecme WG >> Subject: [IPsec] P2P VPN draft >>=20 >> Hi Steve, >>=20 >> a few initial comments. >>=20 >> * The draft is short and clear. Thanks for that! >> * I have a problem with the title (and even more, with the "file >> name" of the draft). P2P is usually perceived as peer-to-peer, >> which skews the discussion towards one particular use case, that >> of endpoint-to-endpoint. I suggest to use "Mesh IPsec VPN" instead.= >> * I am unclear about 2.2: so what if you "suddenly need to exchange a= >> lot of data". How is it different from normal IP traffic load >> management? The text is simply too vague here. Ideally, should we >> expect the traffic to migrate to other gateways? To go directly >> between endpoints? To establish priorities on existing gateways? >>=20 >> Thanks, >>=20 >> Yaron +------------------------------------------------+ | Mike Sullenberger; DSE | | mls@cisco.com =20 .:|:.:|:. | | Customer Advocacy CISCO | +------------------------------------------------+ **************************************************************************= ** Communications with GCHQ may be monitored and/or recorded=20 for system efficiency and other lawful purposes. Any views or=20 opinions expressed in this e-mail do not necessarily reflect GCHQ=20 policy. This email, and any attachments, is intended for the=20 attention of the addressee(s) only. Its unauthorised use,=20 disclosure, storage or copying is not permitted. If you are not the intended recipient, please notify postmaster@gchq.gsi.gov.uk. =20 This information is exempt from disclosure under the Freedom of=20 Information Act 2000 and may be subject to exemption under other UK information legislation. Refer disclosure requests to=20 GCHQ on 01242 221491 ext 30306 (non-secure) or email infoleg@gchq.gsi.gov.uk **************************************************************************= ** The original of this email was scanned for viruses by the Government Secur= e Intranet virus scanning service supplied by Cable&Wireless Worldwide in = partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On l= eaving the GSi this email was certified virus free. Communications via the GSi may be automatically logged, monitored and/or r= ecorded for legal purposes. From shanna@juniper.net Mon Mar 12 17:22:16 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFF821F89FE for ; Mon, 12 Mar 2012 17:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfZp+ao53p2E for ; Mon, 12 Mar 2012 17:22:15 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id C407B21E8026 for ; Mon, 12 Mar 2012 17:22:14 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKT16TNABkf7PRnfeBZ4vnz3UKDjn6efxe@postini.com; Mon, 12 Mar 2012 17:22:15 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 12 Mar 2012 17:22:02 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 12 Mar 2012 20:22:01 -0400 From: Stephen Hanna To: Mike Sullenberger Date: Mon, 12 Mar 2012 20:22:00 -0400 Thread-Topic: [IPsec] P2P VPN draft UNCLASSIFIED Thread-Index: Ac0Amw3Ai2t5jnEaSaigY2vDQWdCfgAE8FcQ Message-ID: References: <01OD167DRHJI9AMI66@Cisco.COM> In-Reply-To: <01OD167DRHJI9AMI66@Cisco.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 Cc: "ipsec@ietf.org" , "Chris.Ulliott@cesg.gsi.gov.uk" Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 00:22:16 -0000 Of course, you're right. The acronym DMVPN makes this a very bad choice. Thanks for pointing that out. I'll throw out a few ideas here: Dynamic Direct VPN (DDVPN) Shortcut VPN (SVPN) Dynamic Scalable VPN (DSVPN) Dynamic Efficient VPN (DEVPN) Other ideas or comments on these are most welcome. Thanks, Steve > -----Original Message----- > From: Mike Sullenberger [mailto:MLS@Cisco.COM] > Sent: Monday, March 12, 2012 6:57 PM > To: Stephen Hanna > Cc: ipsec@ietf.org; Chris.Ulliott@cesg.gsi.gov.uk > Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED >=20 > Steve, >=20 > I do not think changing the name to "Dynamic Mesh VPN" is a good idea. > The first thing that is going to happen is that it is going to be > shortened to "DMVPN" and then we have conflict with Cisco DMVPN, which > would be confusing and also "DMVPN" is a registered trademark. It > would be best to use some other synonym for "Dynamic Mesh". >=20 > Mike. >=20 > >Upon reflection, I can see how "Point to Point VPNs" is problematic > >as a description of the problem. Really it's more about dynamically > >creating SAs so that any endpoint or gateway can communicate directly > >with any other, as permitted by policy. And how can we do this in a > >manageable manner in a large-scale environment where endpoints are > >mobile and configurations and policies change often? > > > >So "Dynamic Mesh VPNs" is fine with me. Whatever the WG feels is best. > > > >Thanks, > > > >Steve > > > >> -----Original Message----- > >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > Behalf > >> Of Ulliott, Chris > >> Sent: Wednesday, March 07, 2012 4:53 PM > >> To: 'ipsec@ietf.org' > >> Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED > >> > >> Classification:UNCLASSIFIED > >> > >> How about "dynamic mesh VPNs" as a title as I think the dynamic part > is > >> key here and probably an important aspect of the use cases. > >> > >> Chris > >> > >> [This message has been sent by a mobile device] > >> > >> ----- Original Message ----- > >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > >> Sent: Wednesday, March 07, 2012 09:17 PM > >> To: IPsecme WG > >> Subject: [IPsec] P2P VPN draft > >> > >> Hi Steve, > >> > >> a few initial comments. > >> > >> * The draft is short and clear. Thanks for that! > >> * I have a problem with the title (and even more, with the "file > >> name" of the draft). P2P is usually perceived as peer-to-peer, > >> which skews the discussion towards one particular use case, that > >> of endpoint-to-endpoint. I suggest to use "Mesh IPsec VPN" > instead. > >> * I am unclear about 2.2: so what if you "suddenly need to > exchange a > >> lot of data". How is it different from normal IP traffic load > >> management? The text is simply too vague here. Ideally, should > we > >> expect the traffic to migrate to other gateways? To go directly > >> between endpoints? To establish priorities on existing gateways? > >> > >> Thanks, > >> > >> Yaron >=20 >=20 > +------------------------------------------------+ > | Mike Sullenberger; DSE | > | mls@cisco.com .:|:.:|:. | > | Customer Advocacy CISCO | > +------------------------------------------------+ From shanna@juniper.net Mon Mar 12 17:30:07 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E38821E8026 for ; Mon, 12 Mar 2012 17:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3w31lDp+eUwH for ; Mon, 12 Mar 2012 17:30:06 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 915D021E8011 for ; Mon, 12 Mar 2012 17:30:06 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKT16VC00VZc3AVr8fCSI+8J1XArlwqn73@postini.com; Mon, 12 Mar 2012 17:30:06 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 12 Mar 2012 17:28:07 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 12 Mar 2012 17:28:06 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 12 Mar 2012 20:28:05 -0400 From: Stephen Hanna To: "Ulliott, Chris" , "'MLS@cisco.com'" Date: Mon, 12 Mar 2012 20:28:03 -0400 Thread-Topic: [IPsec] P2P VPN draft UNCLASSIFIED Thread-Index: Ac0Amya31KLkhnqiRf2Nx4AFogqU6QACvE/wAAJv/5A= Message-ID: References: <01OD167DRHJI9AMI66@Cisco.COM> <20549DD10769DA47A86F0F0FAF8012DD03554E292F@PIACHEVEX00.GCHQ.GOV.UK> In-Reply-To: <20549DD10769DA47A86F0F0FAF8012DD03554E292F@PIACHEVEX00.GCHQ.GOV.UK> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 Cc: "'ipsec@ietf.org'" Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 00:30:07 -0000 On Chris' new use case, I don't think that's a new use case. I think it's a requirement that spans all the use cases. The solution must be able to handle network topology changes. But we're not into requirements yet. Use cases first. Thanks, Steve > -----Original Message----- > From: Ulliott, Chris [mailto:Chris.Ulliott@cesg.gsi.gov.uk] > Sent: Monday, March 12, 2012 7:16 PM > To: 'MLS@cisco.com'; Stephen Hanna > Cc: 'ipsec@ietf.org' > Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED >=20 > Classification:UNCLASSIFIED >=20 > Good catch! >=20 > I've also thought of an additional use case, as I extend / change a > network within a data centre etc, it would be helpful if the crypto > gateway could learn of the new networks (through routing perhaps) and > make them available through the encrypted tunnels. >=20 > Chris >=20 > [This message has been sent by a mobile device] >=20 > ----- Original Message ----- > From: Mike Sullenberger [mailto:MLS@cisco.com] > Sent: Monday, March 12, 2012 10:56 PM > To: shanna@juniper.net > Cc: ipsec@ietf.org ; Ulliott, Chris > Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED >=20 > Steve, >=20 > I do not think changing the name to "Dynamic Mesh VPN" is a good idea. > The first thing that is going to happen is that it is going to be > shortened to "DMVPN" and then we have conflict with Cisco DMVPN, which > would be confusing and also "DMVPN" is a registered trademark. It > would be best to use some other synonym for "Dynamic Mesh". >=20 > Mike. >=20 > >Upon reflection, I can see how "Point to Point VPNs" is problematic > >as a description of the problem. Really it's more about dynamically > >creating SAs so that any endpoint or gateway can communicate directly > >with any other, as permitted by policy. And how can we do this in a > >manageable manner in a large-scale environment where endpoints are > >mobile and configurations and policies change often? > > > >So "Dynamic Mesh VPNs" is fine with me. Whatever the WG feels is best. > > > >Thanks, > > > >Steve > > > >> -----Original Message----- > >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > Behalf > >> Of Ulliott, Chris > >> Sent: Wednesday, March 07, 2012 4:53 PM > >> To: 'ipsec@ietf.org' > >> Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED > >> > >> Classification:UNCLASSIFIED > >> > >> How about "dynamic mesh VPNs" as a title as I think the dynamic part > is > >> key here and probably an important aspect of the use cases. > >> > >> Chris > >> > >> [This message has been sent by a mobile device] > >> > >> ----- Original Message ----- > >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > >> Sent: Wednesday, March 07, 2012 09:17 PM > >> To: IPsecme WG > >> Subject: [IPsec] P2P VPN draft > >> > >> Hi Steve, > >> > >> a few initial comments. > >> > >> * The draft is short and clear. Thanks for that! > >> * I have a problem with the title (and even more, with the "file > >> name" of the draft). P2P is usually perceived as peer-to-peer, > >> which skews the discussion towards one particular use case, that > >> of endpoint-to-endpoint. I suggest to use "Mesh IPsec VPN" > instead. > >> * I am unclear about 2.2: so what if you "suddenly need to > exchange a > >> lot of data". How is it different from normal IP traffic load > >> management? The text is simply too vague here. Ideally, should > we > >> expect the traffic to migrate to other gateways? To go directly > >> between endpoints? To establish priorities on existing gateways? > >> > >> Thanks, > >> > >> Yaron >=20 >=20 > +------------------------------------------------+ > | Mike Sullenberger; DSE | > | mls@cisco.com .:|:.:|:. | > | Customer Advocacy CISCO | > +------------------------------------------------+ >=20 > *********************************************************************** > ***** > Communications with GCHQ may be monitored and/or recorded > for system efficiency and other lawful purposes. Any views or > opinions expressed in this e-mail do not necessarily reflect GCHQ > policy. This email, and any attachments, is intended for the > attention of the addressee(s) only. Its unauthorised use, > disclosure, storage or copying is not permitted. If you are not the > intended recipient, please notify postmaster@gchq.gsi.gov.uk. >=20 > This information is exempt from disclosure under the Freedom of > Information Act 2000 and may be subject to exemption under > other UK information legislation. Refer disclosure requests to > GCHQ on 01242 221491 ext 30306 (non-secure) or email > infoleg@gchq.gsi.gov.uk >=20 > *********************************************************************** > ***** >=20 >=20 > The original of this email was scanned for viruses by the Government > Secure Intranet virus scanning service supplied by Cable&Wireless > Worldwide in partnership with MessageLabs. (CCTM Certificate Number > 2009/09/0052.) On leaving the GSi this email was certified virus free. > Communications via the GSi may be automatically logged, monitored > and/or recorded for legal purposes. From mcr@sandelman.ca Mon Mar 12 18:19:29 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7815B21F8832 for ; Mon, 12 Mar 2012 18:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kOuUdvnVM8U for ; Mon, 12 Mar 2012 18:19:29 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0650121F8808 for ; Mon, 12 Mar 2012 18:19:27 -0700 (PDT) Received: from marajade.sandelman.ca (wlan205.sandelman.ca [209.87.252.205]) by relay.sandelman.ca (Postfix) with ESMTPS id F3DEF344DC for ; Mon, 12 Mar 2012 21:16:51 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 9967A98282; Mon, 12 Mar 2012 21:19:25 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 8E43C98182 for ; Mon, 12 Mar 2012 21:19:25 -0400 (EDT) From: Michael Richardson To: IPsecme WG In-Reply-To: <4F5E654E.1070002@gmail.com> References: <4F5E654E.1070002@gmail.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 12 Mar 2012 21:19:25 -0400 Message-ID: <1883.1331601565@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] Please comment on Steve's P2P draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 01:19:29 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I read the draft yesterday. I wasn't surprised. That in itself was a surprise. It's exactly what I thought the problem is from the beginning.=20=20 There was no big mystery requirement that I didn't understand.=20 The only thing I found weird was the belief that RFC4301 SPD configuration had to be "hard". There are certainly lots of hard to use products with really poor user interfaces, which perhaps suggest that the underlying mechanisms are really difficult to work with, but that doesn't mean this is a hard problem.=20=20=20 The dual trunk scenario should perhaps be further motivated and clarified. Are there some situations where a spoke should not contact another spoke directly, but in fact should contact a hub closer to the other spoke. I can see some solutions where a hub would not have complete knowledge of the mesh, and so would in fact simply punt a connection closer. Another thing that I would like clarified is whether or not traffic should flow through the hub while the connection to the spoke is brought up.=20=20 Finally, say my laptop is normally part of such a mesh (as a /32,/128 subnet). When I'm "trapped" behind a NAPT, I naturally use NAT-traversal to get out and join the MESH.=20=20 Now, what happens if I come to the office, which is itself part of the MESH. This is not a new problem, btw, but normally I have only a single tunnel to bring up or down. Now that I have all these tunnels and policy. Should any of this MESH continue to be used?=20=20 Are there some non-convex topologies where this can be important (should some traffic be double encrypted as a result?), or is it all just out of scope. (We dealt with these things as implementation challenges when combining an extruded IPsec tunnel with RFC4322. We had=20 co-terminal tunnels of the near kind, which was solved, and co-terminal tunnels of the far kind, which we did not manage to implement) For the above, consider a laptop/tablet which might now have multiple exit routes via 3G+wifi+wired... and that it's moving. I saw nothing at all that prevents it from being solved with RFC4322, using software that has been out there for over ten years. And I've implemented this in the past. There are some IKEv2 enhancements (involving traffic selectors) that would be nice to have, and perhaps for some situations could become critical due to resource constraints. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT16gnYqHRg3pndX9AQIXsQQAh/VWy1WKpVqRyxvvDbN8QIF566IxJaKu M6YAZEmxY9zJ+dhwL2CORy8aZ5oF3gdbAsAI2RYK6awonfCMqNAcv3bhbNx1Hop0 06qQL1FtX80CuJJdinjmMAPGUStmcdLn2yLlFUkGIrJse88Xm0kAqNn9tS7EWL34 3j+9C4+LaYM= =vt98 -----END PGP SIGNATURE----- --=-=-=-- From jun.hu@alcatel-lucent.com Tue Mar 13 11:14:11 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D93721F8814 for ; Tue, 13 Mar 2012 11:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hp6DqejDwmSC for ; Tue, 13 Mar 2012 11:14:10 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 32D3621F870A for ; Tue, 13 Mar 2012 11:14:09 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q2DIDA8b012878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Mar 2012 13:13:16 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2DID9jr010942 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 13 Mar 2012 13:13:09 -0500 Received: from USNAVSXCHMBSC1.ndc.alcatel-lucent.com ([135.3.39.146]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Tue, 13 Mar 2012 13:13:10 -0500 From: "Hu, Jun (Jun)" To: Stephen Hanna , Mike Sullenberger Date: Tue, 13 Mar 2012 13:13:08 -0500 Thread-Topic: [IPsec] P2P VPN draft UNCLASSIFIED Thread-Index: Ac0Amw3Ai2t5jnEaSaigY2vDQWdCfgAE8FcQACVacCA= Message-ID: <098C866D3766674B95CCF197E1C2489B0BA074042E@USNAVSXCHMBSC1.ndc.alcatel-lucent.com> References: <01OD167DRHJI9AMI66@Cisco.COM> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "ipsec@ietf.org" , "Chris.Ulliott@cesg.gsi.gov.uk" Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 18:14:11 -0000 How about Dynamic Secure VPN(DSVPN) or Dynamic Secure Mesh VPN(DSMVPN)?=20 -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= tephen Hanna Sent: Monday, March 12, 2012 5:22 PM To: Mike Sullenberger Cc: ipsec@ietf.org; Chris.Ulliott@cesg.gsi.gov.uk Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED Of course, you're right. The acronym DMVPN makes this a very bad choice. Th= anks for pointing that out. I'll throw out a few ideas here: Dynamic Direct VPN (DDVPN) Shortcut VPN (SVPN) Dynamic Scalable VPN (DSVPN) Dynamic Efficient VPN (DEVPN) Other ideas or comments on these are most welcome. Thanks, Steve > -----Original Message----- > From: Mike Sullenberger [mailto:MLS@Cisco.COM] > Sent: Monday, March 12, 2012 6:57 PM > To: Stephen Hanna > Cc: ipsec@ietf.org; Chris.Ulliott@cesg.gsi.gov.uk > Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED >=20 > Steve, >=20 > I do not think changing the name to "Dynamic Mesh VPN" is a good idea. > The first thing that is going to happen is that it is going to be=20 > shortened to "DMVPN" and then we have conflict with Cisco DMVPN, which=20 > would be confusing and also "DMVPN" is a registered trademark. It=20 > would be best to use some other synonym for "Dynamic Mesh". >=20 > Mike. >=20 > >Upon reflection, I can see how "Point to Point VPNs" is problematic=20 > >as a description of the problem. Really it's more about dynamically=20 > >creating SAs so that any endpoint or gateway can communicate directly=20 > >with any other, as permitted by policy. And how can we do this in a=20 > >manageable manner in a large-scale environment where endpoints are=20 > >mobile and configurations and policies change often? > > > >So "Dynamic Mesh VPNs" is fine with me. Whatever the WG feels is best. > > > >Thanks, > > > >Steve > > > >> -----Original Message----- > >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > Behalf > >> Of Ulliott, Chris > >> Sent: Wednesday, March 07, 2012 4:53 PM > >> To: 'ipsec@ietf.org' > >> Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED > >> > >> Classification:UNCLASSIFIED > >> > >> How about "dynamic mesh VPNs" as a title as I think the dynamic=20 > >> part > is > >> key here and probably an important aspect of the use cases. > >> > >> Chris > >> > >> [This message has been sent by a mobile device] > >> > >> ----- Original Message ----- > >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > >> Sent: Wednesday, March 07, 2012 09:17 PM > >> To: IPsecme WG > >> Subject: [IPsec] P2P VPN draft > >> > >> Hi Steve, > >> > >> a few initial comments. > >> > >> * The draft is short and clear. Thanks for that! > >> * I have a problem with the title (and even more, with the "file > >> name" of the draft). P2P is usually perceived as peer-to-peer, > >> which skews the discussion towards one particular use case, that > >> of endpoint-to-endpoint. I suggest to use "Mesh IPsec VPN" > instead. > >> * I am unclear about 2.2: so what if you "suddenly need to > exchange a > >> lot of data". How is it different from normal IP traffic load > >> management? The text is simply too vague here. Ideally, should > we > >> expect the traffic to migrate to other gateways? To go directly > >> between endpoints? To establish priorities on existing gateways? > >> > >> Thanks, > >> > >> Yaron >=20 >=20 > +------------------------------------------------+ > | Mike Sullenberger; DSE | > | mls@cisco.com .:|:.:|:. | > | Customer Advocacy CISCO | > +------------------------------------------------+ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From praveenys@juniper.net Tue Mar 13 13:24:22 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15EB021F8634 for ; Tue, 13 Mar 2012 13:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfv7cwml1AbX for ; Tue, 13 Mar 2012 13:24:21 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id E112121F862A for ; Tue, 13 Mar 2012 13:24:20 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKT1+s9Ix9Eu6akcBTu6C3DMBO7Ek2uFPt@postini.com; Tue, 13 Mar 2012 13:24:20 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 13 Mar 2012 13:24:05 -0700 From: Praveen Sathyanarayan To: Stephen Hanna Date: Tue, 13 Mar 2012 13:24:04 -0700 Thread-Topic: [IPsec] P2P VPN draft UNCLASSIFIED Thread-Index: Ac0BVzvhNfEZXzaBQROZSwnTmL/XOQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 20:24:22 -0000 Few of my suggestions here 1.) Cut through VPN 2.) Auto mesh VPN Thanks, Praveen On 3/12/12 5:22 PM, "Stephen Hanna" wrote: Of course, you're right. The acronym DMVPN makes this a very bad choice. Thanks for pointing that out. I'll throw out a few ideas here: Dynamic Direct VPN (DDVPN) Shortcut VPN (SVPN) Dynamic Scalable VPN (DSVPN) Dynamic Efficient VPN (DEVPN) Other ideas or comments on these are most welcome. Thanks, Steve > -----Original Message----- > From: Mike Sullenberger [mailto:MLS@Cisco.COM] > Sent: Monday, March 12, 2012 6:57 PM > To: Stephen Hanna > Cc: ipsec@ietf.org; Chris.Ulliott@cesg.gsi.gov.uk > Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED >=20 > Steve, >=20 > I do not think changing the name to "Dynamic Mesh VPN" is a good idea. > The first thing that is going to happen is that it is going to be > shortened to "DMVPN" and then we have conflict with Cisco DMVPN, which > would be confusing and also "DMVPN" is a registered trademark. It > would be best to use some other synonym for "Dynamic Mesh". >=20 > Mike. >=20 > >Upon reflection, I can see how "Point to Point VPNs" is problematic > >as a description of the problem. Really it's more about dynamically > >creating SAs so that any endpoint or gateway can communicate directly > >with any other, as permitted by policy. And how can we do this in a > >manageable manner in a large-scale environment where endpoints are > >mobile and configurations and policies change often? > > > >So "Dynamic Mesh VPNs" is fine with me. Whatever the WG feels is best. > > > >Thanks, > > > >Steve > > > >> -----Original Message----- > >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > Behalf > >> Of Ulliott, Chris > >> Sent: Wednesday, March 07, 2012 4:53 PM > >> To: 'ipsec@ietf.org' > >> Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED > >> > >> Classification:UNCLASSIFIED > >> > >> How about "dynamic mesh VPNs" as a title as I think the dynamic part > is > >> key here and probably an important aspect of the use cases. > >> > >> Chris > >> > >> [This message has been sent by a mobile device] > >> > >> ----- Original Message ----- > >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > >> Sent: Wednesday, March 07, 2012 09:17 PM > >> To: IPsecme WG > >> Subject: [IPsec] P2P VPN draft > >> > >> Hi Steve, > >> > >> a few initial comments. > >> > >> * The draft is short and clear. Thanks for that! > >> * I have a problem with the title (and even more, with the "file > >> name" of the draft). P2P is usually perceived as peer-to-peer, > >> which skews the discussion towards one particular use case, that > >> of endpoint-to-endpoint. I suggest to use "Mesh IPsec VPN" > instead. > >> * I am unclear about 2.2: so what if you "suddenly need to > exchange a > >> lot of data". How is it different from normal IP traffic load > >> management? The text is simply too vague here. Ideally, should > we > >> expect the traffic to migrate to other gateways? To go directly > >> between endpoints? To establish priorities on existing gateways? > >> > >> Thanks, > >> > >> Yaron >=20 >=20 > +------------------------------------------------+ > | Mike Sullenberger; DSE | > | mls@cisco.com .:|:.:|:. | > | Customer Advocacy CISCO | > +------------------------------------------------+ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From mark.boltz@stonesoft.com Tue Mar 13 15:05:21 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0000E21E8012 for ; Tue, 13 Mar 2012 15:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05E-zJE2-NO0 for ; Tue, 13 Mar 2012 15:05:19 -0700 (PDT) Received: from hki-smtp-1b.stonesoft.com (hki-smtp-1b.stonesoft.com [84.34.144.100]) by ietfa.amsl.com (Postfix) with ESMTP id D092521F8604 for ; Tue, 13 Mar 2012 15:05:18 -0700 (PDT) Received: from hki-smtp-1b.stonesoft.com (localhost.localdomain [127.0.0.1]) by localhost.stonesoft.com (Postfix) with ESMTP id 914C739F0132 for ; Wed, 14 Mar 2012 00:05:13 +0200 (EET) Received: from outlook.stonesoft.com (unknown [172.16.40.22]) by hki-smtp-1b.stonesoft.com (Postfix) with ESMTP id 839D439F00BA for ; Wed, 14 Mar 2012 00:05:13 +0200 (EET) Received: from HKI-EXC-1.stonesoft.com ([fe80::b914:799e:5fe4:7c73]) by HKI-EXC-2.stonesoft.com ([fe80::400e:df46:3369:4741%14]) with mapi id 14.01.0355.002; Wed, 14 Mar 2012 00:05:16 +0200 From: Mark Boltz To: "ipsec@ietf.org" Thread-Topic: [IPsec] P2P VPN draft UNCLASSIFIED Thread-Index: AQHNAJs8UxRHtLTEIkuwZ7rof2uRj5ZnO98AgAErRQCAAEDWgA== Date: Tue, 13 Mar 2012 22:05:15 +0000 Message-ID: <7A969D71-DD9A-43C9-ABB2-9380C8B97AB3@stonesoft.com> References: <01OD167DRHJI9AMI66@Cisco.COM> <098C866D3766674B95CCF197E1C2489B0BA074042E@USNAVSXCHMBSC1.ndc.alcatel-lucent.com> In-Reply-To: <098C866D3766674B95CCF197E1C2489B0BA074042E@USNAVSXCHMBSC1.ndc.alcatel-lucent.com> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.16.31.154] Content-Type: multipart/related; boundary="_008_7A969D71DD9A43C9ABB29380C8B97AB3stonesoftcom_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 22:05:21 -0000 --_008_7A969D71DD9A43C9ABB29380C8B97AB3stonesoftcom_ Content-Type: multipart/alternative; boundary="_000_7A969D71DD9A43C9ABB29380C8B97AB3stonesoftcom_" --_000_7A969D71DD9A43C9ABB29380C8B97AB3stonesoftcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like Juniper's suggestion of "auto mesh VPNs", although other options may= be available. I think that dynamic is a good word, but I'd rather anything= that can distill to an acronym that would be too ambiguous with DMVPN. Or = any other term currently used for proprietary vendor alternatives. The goal here is to create a vendor-agnostic standards-based solution, righ= t? :-) -- Mark Boltz, CISSP, CISA, NSA-IEM, CSGI Director, Federal and Mid-Atlantic cell: 571.246.2233 office: 202.434.8963 toll free: 866.869.4075 e-mail: mark.boltz@stonesoft.com fax: 202.= 318.2333 e-mail: federal@stonesoft.com [cid:E73E5D0D-0F71-4D= DB-9B79-12A5B649A69E@no-dns-available.example.com] Stonesoft Inc. 1200 G St. NW, Suite 800 Washington, DC 20005-6705 [cid:4E195463-5011-4073-B6E5-59680BC2EA89@no-dns-available.example.com][cid:199A7F02-3023-454D-8AD3-AB64E3629E73@no-d= ns-available.example.com][cid:AEFEAA= 7C-B5B8-40B3-86FC-AF0E1C490A3C@no-dns-available.example.com][cid:B0EE3400-0301-4D91-B8D0-D076C9D7FFE7@no-dn= s-available.example.com] Stonesoft: Network Security. Simplified. On Mar 13, 2012, at 2:13 PM, Hu, Jun (Jun) wrote: How about Dynamic Secure VPN(DSVPN) or Dynamic Secure Mesh VPN(DSMVPN)? -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-b= ounces@ietf.org] On Behalf Of Stephen Hanna Sent: Monday, March 12, 2012 5:22 PM To: Mike Sullenberger Cc: ipsec@ietf.org; Chris.Ulliott@cesg.gsi.gov.uk Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED Of course, you're right. The acronym DMVPN makes this a very bad choice. Th= anks for pointing that out. I'll throw out a few ideas here: Dynamic Direct VPN (DDVPN) Shortcut VPN (SVPN) Dynamic Scalable VPN (DSVPN) Dynamic Efficient VPN (DEVPN) Other ideas or comments on these are most welcome. Thanks, Steve -----Original Message----- From: Mike Sullenberger [mailto:MLS@Cisco.COM] Sent: Monday, March 12, 2012 6:57 PM To: Stephen Hanna Cc: ipsec@ietf.org; Chris.Ulliott@cesg.gsi.gov.uk Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED Steve, I do not think changing the name to "Dynamic Mesh VPN" is a good idea. The first thing that is going to happen is that it is going to be shortened to "DMVPN" and then we have conflict with Cisco DMVPN, which would be confusing and also "DMVPN" is a registered trademark. It would be best to use some other synonym for "Dynamic Mesh". Mike. Upon reflection, I can see how "Point to Point VPNs" is problematic as a description of the problem. Really it's more about dynamically creating SAs so that any endpoint or gateway can communicate directly with any other, as permitted by policy. And how can we do this in a manageable manner in a large-scale environment where endpoints are mobile and configurations and policies change often? So "Dynamic Mesh VPNs" is fine with me. Whatever the WG feels is best. Thanks, Steve -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-b= ounces@ietf.org] On Behalf Of Ulliott, Chris Sent: Wednesday, March 07, 2012 4:53 PM To: 'ipsec@ietf.org' Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED Classification:UNCLASSIFIED How about "dynamic mesh VPNs" as a title as I think the dynamic part is key here and probably an important aspect of the use cases. Chris [This message has been sent by a mobile device] ----- Original Message ----- From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] Sent: Wednesday, March 07, 2012 09:17 PM To: IPsecme WG > Subject: [IPsec] P2P VPN draft Hi Steve, a few initial comments. * The draft is short and clear. Thanks for that! * I have a problem with the title (and even more, with the "file name" of the draft). P2P is usually perceived as peer-to-peer, which skews the discussion towards one particular use case, that of endpoint-to-endpoint. I suggest to use "Mesh IPsec VPN" instead. * I am unclear about 2.2: so what if you "suddenly need to exchange a lot of data". How is it different from normal IP traffic load management? The text is simply too vague here. Ideally, should we expect the traffic to migrate to other gateways? To go directly between endpoints? To establish priorities on existing gateways? Thanks, Yaron +------------------------------------------------+ | Mike Sullenberger; DSE | | mls@cisco.com .:|:.:|:. | | Customer Advocacy CISCO | +------------------------------------------------+ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_7A969D71DD9A43C9ABB29380C8B97AB3stonesoftcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <20B89E0E8BDFB24491725C0C01F9FC2A@stonesoft.com> Content-Transfer-Encoding: quoted-printable I like Juniper's suggestion of "auto mesh VPNs", although other o= ptions may be available. I think that dynamic is a good word, but I'd rathe= r anything that can distill to an acronym that would be too ambiguous with = DMVPN. Or any other term currently used for proprietary vendor alternatives.

The goal here is to create a vendor-agnostic standards-based solution,= right? :-)

<= span class=3D"Apple-style-span" style=3D"border-collapse: separate; color: = rgb(0, 0, 0); font-family: 'ITC Franklin Gothic'; font-style: normal; font-= variant: normal; font-weight: normal; letter-spacing: normal; line-height: = normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: no= rmal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px;= -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: = none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-= size: medium; ">
--
Mark Boltz, CISSP, CISA, NSA-IEM, CSGI
Director, Federal and Mid-Atlantic
cell: 571.246.2233 office: 202.434.8963 toll free: 866.869.4075
e-mail: mark.boltz@stonesoft.com fax: 202.318.2333



Stonesoft Inc.
1200 G St. NW, Suite 800
Washington, DC 20005-6705


<= /span><= /span><= /span>= <= /span>
Stonesoft: Network Security. Simplified.




On Mar 13, 2012, at 2:13 PM, Hu, Jun (Jun) wrote:

How about Dynamic Secure VPN(DSVPN)  or Dynamic Secure Mesh VPN(D= SMVPN)?

-----Original Message-----
From: ipsec-bounces@ietf.org = [mailto:ipsec-bounces@ietf.org] On Behalf Of Stephen Hanna
Sent: Monday, March 12, 2012 5:22 PM
To: Mike Sullenberger
Cc: ipsec@ietf.org; Chris.Ulliott@cesg.gsi.gov.uk
Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED

Of course, you're right. The acronym DMVPN makes this a very bad choice. Th= anks for pointing that out.

I'll throw out a few ideas here:

Dynamic Direct VPN (DDVPN)
Shortcut VPN (SVPN)
Dynamic Scalable VPN (DSVPN)
Dynamic Efficient VPN (DEVPN)

Other ideas or comments on these are most welcome.

Thanks,

Steve

-----Original Message-----
From: Mike Sullenberger [mailto:MLS@Cisco.COM]
Sent: Monday, March 12, 2012 6:57 PM
To: Stephen Hanna
Cc: ipsec@ietf.= org; Chris.Ulliott@cesg.gsi.gov.uk
Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED

Steve,

I do not think changing the name to "Dynamic= Mesh VPN" is a good idea.
The first thing that is going to happen is that i= t is going to be
shortened to "DMVPN" and then we have c= onflict with Cisco DMVPN, which
would be confusing and also "DMVPN" is = a registered trademark.  It
would be best to use some other synonym for "= ;Dynamic Mesh".

Mike.

Upon reflection, I can see how "Point to Poi= nt VPNs" is problematic
as a description of the problem. Really it's more= about dynamically
creating SAs so that any endpoint or gateway can = communicate directly
with any other, as permitted by policy. And how c= an we do this in a
manageable manner in a large-scale environment wh= ere endpoints are
mobile and configurations and policies change oft= en?

So "Dynamic Mesh VPNs" is fine with me.= Whatever the WG feels is best.

Thanks,

Steve

-----Original Message-----
From: i= psec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On
Behalf
Of Ulliott, Chris
Sent: Wednesday, March 07, 2012 4:53 PM
To: 'ipsec@ietf= .org'
Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED

Classification:UNCLASSIFIED

How about "dynamic mesh VPNs" as a titl= e as I think the dynamic
part
is
key here and probably an important aspect of the = use cases.

Chris

[This message has been sent by a mobile device]

----- Original Message -----
From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com= ]
Sent: Wednesday, March 07, 2012 09:17 PM
To: IPsecme WG <ipsec@ietf.org>
Subject: [IPsec] P2P VPN draft

Hi Steve,

a few initial comments.

 * The draft is short and clear. Thanks for = that!
 * I have a problem with the title (and even= more, with the "file
   name" of the draft). P2P i= s usually perceived as peer-to-peer,
   which skews the discussion towa= rds one particular use case, that
   of endpoint-to-endpoint. I sugg= est to use "Mesh IPsec VPN"
instead.
 * I am unclear about 2.2: so what if you &q= uot;suddenly need to
exchange a
   lot of data". How is it di= fferent from normal IP traffic load
   management? The text is simply = too vague here. Ideally, should
we
   expect the traffic to migrate t= o other gateways? To go directly
   between endpoints? To establish= priorities on existing gateways?

Thanks,

    Yaron


+--------------------------------------------= ----+
| Mike Sullenberger; DSE     =             &nb= sp;       |
| mls@cisco.com<= /a>             = ;   .:|:.:|:.        &nbs= p;|
| Customer Advocacy      = ;        CISCO    &n= bsp;      |
+--------------------------------------------= ----+
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--_000_7A969D71DD9A43C9ABB29380C8B97AB3stonesoftcom_-- --_008_7A969D71DD9A43C9ABB29380C8B97AB3stonesoftcom_ Content-Type: image/gif; name="StoneSoft_transparent.gif" Content-Description: StoneSoft_transparent.gif Content-Disposition: inline; filename="StoneSoft_transparent.gif"; size=658; creation-date="Tue, 13 Mar 2012 22:05:15 GMT"; modification-date="Tue, 13 Mar 2012 22:05:15 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhVAAUAMQAAO7z9gBRdABph5S6yQBdfkONo1qYrcvd5Nzp7SmBmqfG0oGwv7nS2m6jtgB1 kf///wBEawAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAABUABQAAAX/4CMyCXQcTqo6hohCUNCKj9PQj5Ee4poOOEQhsKABSrACgDbwtXQ+xwPg gEEWDKtWighoIQWaI7DswRiiL+QmalgTIoDgK6C5tzU1RK4tZNVSBTABBFY8eTN5EGgPamyCVgFt VnMwQA93VlJVjpqHZmtxVgMAhWCgCKCMVowjVgSXD6Y3SHWYMFI4tzAipnC6nGwDg5MQBKC/nKtn OJAEZQ8IVqkKVkt3uTiZaczAMGzYrryKi4rL5WIwiQ/VMTSsu9l2VtwQsemhimzSMDycEJu6wcP3 q1g2Kwri6doFoReuhcFAsWnE7J89ZfVa5RgELZxEhbq2beyGj03EjOSM/2GkiE5cPpD6YM4b1wXG MRwnT7JEY1HLOXqgTBgsyZCkSIYTYyrdqciLz3pAHxygNPRjJqNRH1SCkOrjUnjBvpwTkELbKJgR 7wTYMbMhjT9XiH6teAaSQJJGTNXxGJNvW12VsuVUJ4KfUGWG0Q0MSY8vQpnF3NKAJPhbVbiqRirG +5ZeO0ko/UbGUQpGwZOfi9nCCMDpOY00kDQ0zKPdHsgM326NdRKAlQWlIcxYeee1LgSyw8hK8qBW VbPjTD2U+8Cu9EMrW2/WcsNujK4LXp3FLXKrEpyWCzu1kmjlg2E/LWcS8EkrnZnyRr+HkAB2jh84 vBBDUlDURwAjUQAhjQ8A98Rh13kiNMHCQhLmEgIAOw== --_008_7A969D71DD9A43C9ABB29380C8B97AB3stonesoftcom_ Content-Type: image/jpeg; name="micro_twitter.jpg" Content-Description: micro_twitter.jpg Content-Disposition: inline; filename="micro_twitter.jpg"; size=1836; creation-date="Tue, 13 Mar 2012 22:05:15 GMT"; modification-date="Tue, 13 Mar 2012 22:05:15 GMT" Content-ID: <4E195463-5011-4073-B6E5-59680BC2EA89@no-dns-available.example.com> Content-Transfer-Encoding: base64 /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABQAAD/4QNvaHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjAtYzA2MCA2MS4xMzQ3NzcsIDIwMTAvMDIvMTItMTc6 MzI6MDAgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9 InhtcC5kaWQ6MDE4MDExNzQwNzIwNjgxMThGNjJEMkI3NTYxQzMzNTgiIHhtcE1NOkRvY3VtZW50 SUQ9InhtcC5kaWQ6NDQ1N0E5Njk5MjQ4MTFERjhEM0VEMDBDMTU3Rjk3N0MiIHhtcE1NOkluc3Rh bmNlSUQ9InhtcC5paWQ6NDQ1N0E5Njg5MjQ4MTFERjhEM0VEMDBDMTU3Rjk3N0MiIHhtcDpDcmVh dG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giPiA8eG1wTU06RGVyaXZlZEZy b20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDowMTgwMTE3NDA3MjA2ODExOEY2MkQyQjc1NjFD MzM1OCIgc3RSZWY6ZG9jdW1lbnRJRD0ieG1wLmRpZDowMTgwMTE3NDA3MjA2ODExOEY2MkQyQjc1 NjFDMzM1OCIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gPD94 cGFja2V0IGVuZD0iciI/Pv/uAA5BZG9iZQBkwAAAAAH/2wCEAAICAgICAgICAgIDAgICAwQDAgID BAUEBAQEBAUGBQUFBQUFBgYHBwgHBwYJCQoKCQkMDAwMDAwMDAwMDAwMDAwBAwMDBQQFCQYGCQ0L CQsNDw4ODg4PDwwMDAwMDw8MDAwMDAwPDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEI ABQAFAMBEQACEQEDEQH/xACTAAEBAQAAAAAAAAAAAAAAAAAGBwkBAAMBAQAAAAAAAAAAAAAAAAQF BgcBEAAAAwYCBwQLAAAAAAAAAAABAgMREgQUBQYAEyExQRUWBxdRYYEicZFiIzVlpWYnCCgRAAEC AwQGCAQHAQAAAAAAAAERAhIDBQAhEwQxQWGBFBXwUaEiMkKCFmIjUwZxwVKiJCVFRv/aAAwDAQAC EQMRAD8A1or16X7XOcNV5dW1WULZpdAp8NGRtRl0YhQxVks1Q4lXTUax4pSlK7tER7K7KU/Jyqa3 Nzml7nOIAUjWg0EbSTfbL6nXqnmK8+nZaYJUuWxri6EOKFsTj3g7RcAAmtT1C7xujnrZ8XUc2qx9 SokA4oW4UKbBSp0lAAxTGNKC6xrDadA7cNKfT6RnGNQBrz5S4xKPVfssirFZ+5aa95c9zpTUOIJb ICCiFYLtKHqNm/WGtdIuMJZDf01u1933WZNS2c52s8zupujVif5TK5pwqmBd6QxJ+VrP3LmPb3ME GKibFxMKJP3Ju0WnsfGyX7QX0BDux0fa5IWkINYK8SaDRUIkRrAExgTMwNo6MUGWlYlDlL4RMVx6 mxG/8L77Z9V55lfd2aa3xvy8LB+p+GCGjaUKDWbtNnV0V9WpWHdlPplPrFJriluRwLx1YhlyU8hQ QGZB5pQKYxHipiYGAYQaA4DyuSw83Lc9zHMxGoGER6e7uBSJNS2KzFUbOp06XJZPZPwHxOmhwkju /M1hC4KGRBIiLltIGfzsz58z6ljv+/0+nZl/xXT69rDzg6NcSQfF+dxXkJfDJmZymmyc2V72uPad bMLKTzbBPCrhr8KLrSLtTfZ/9z+2eKbzKHHQJ44kvhXD3wxbUsFqXSiRU3vxvu3y5s5vrI9luZ5f RgmTzeP5cMWzCXsstzPtXDONHBri4mHtutVvxh0w+0vF99vrfb4t78If5XFebGi9UXTcmy1x/Xcu 8nCweiDp6ovit//Z --_008_7A969D71DD9A43C9ABB29380C8B97AB3stonesoftcom_ Content-Type: image/jpeg; name="micro_linkedin.jpg" Content-Description: micro_linkedin.jpg Content-Disposition: inline; filename="micro_linkedin.jpg"; size=1703; creation-date="Tue, 13 Mar 2012 22:05:15 GMT"; modification-date="Tue, 13 Mar 2012 22:05:15 GMT" Content-ID: <199A7F02-3023-454D-8AD3-AB64E3629E73@no-dns-available.example.com> Content-Transfer-Encoding: base64 /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABQAAD/4QNvaHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjAtYzA2MCA2MS4xMzQ3NzcsIDIwMTAvMDIvMTItMTc6 MzI6MDAgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9 InhtcC5kaWQ6MDE4MDExNzQwNzIwNjgxMThGNjJEMkI3NTYxQzMzNTgiIHhtcE1NOkRvY3VtZW50 SUQ9InhtcC5kaWQ6MzUxMEQxQjI5MjQ4MTFERjhEM0VEMDBDMTU3Rjk3N0MiIHhtcE1NOkluc3Rh bmNlSUQ9InhtcC5paWQ6MzUxMEQxQjE5MjQ4MTFERjhEM0VEMDBDMTU3Rjk3N0MiIHhtcDpDcmVh dG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giPiA8eG1wTU06RGVyaXZlZEZy b20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDowMTgwMTE3NDA3MjA2ODExOEY2MkQyQjc1NjFD MzM1OCIgc3RSZWY6ZG9jdW1lbnRJRD0ieG1wLmRpZDowMTgwMTE3NDA3MjA2ODExOEY2MkQyQjc1 NjFDMzM1OCIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gPD94 cGFja2V0IGVuZD0iciI/Pv/uAA5BZG9iZQBkwAAAAAH/2wCEAAICAgICAgICAgIDAgICAwQDAgID BAUEBAQEBAUGBQUFBQUFBgYHBwgHBwYJCQoKCQkMDAwMDAwMDAwMDAwMDAwBAwMDBQQFCQYGCQ0L CQsNDw4ODg4PDwwMDAwMDw8MDAwMDAwPDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEI ABQAFAMBEQACEQEDEQH/xACPAAEBAQEAAAAAAAAAAAAAAAAIBwIJAQEBAQEAAAAAAAAAAAAAAAAF BgADEAAAAwYEAwQLAAAAAAAAAAABAgMREhMEBQYAFAcXITFBFRYIGFFhgWODkyRFZScoEQAABAIG BgcJAAAAAAAAAAABEQIDABIhMUEEFAVRYYGhExXR4TJCgsIkkbFiYyVFFiZG/9oADAMBAAIRAxEA PwDqfqhqlfVN1Fqdm2tWqFb0pQ7dLWpiaq5ikGYMImEUkxORRphAAdAADqLcP3G4Mqu4OOJUoRUV FkSuZ5reG70plpSUglExqt1BQNMG/wA0+rQEMoaZliETADKmPKJABANyEwwuAD68NciuujePTE5+ V3zV7OqExvvVNiNy8vJ9sOQXnvpYsaDE5sZ1Zybie5cnHYekj21HFdzZfLMWQTFsM5euJHf9023a nif1TmblrsjQUajo+WSpa88sVEq02dc4ppJCcQacQARAA44UurDjuXtAhIiTxiWgoKvl4bZzR4XF Ak2CA9J1RlLXOx5u4qXZtQvq25jTqp6QQ7gQXUlTJK14piIFQWmBB8VAREQBMTekWNxhyx4GxcBC uID1FfYrMtB2xgzdgXAaU4jhCxTV26iEdJWRLXR8hDrBblHWdW5lmOn3zxeWOX874fPCb8QHlm7y 07d3sPvbkCQM1CzeSiHhvvcXH33W9XmdcE5dzHhjhppTsqOGs15XxAxck5W1l0VltiB/wz+AZ8HC H1v490F/r/y98Kf9KbLfb9r8p7rJ5Z35bjvswD6jEd7iza5popPS4Xu8GXVLL7ij/9k= --_008_7A969D71DD9A43C9ABB29380C8B97AB3stonesoftcom_ Content-Type: image/jpeg; name="micro_youtube.jpg" Content-Description: micro_youtube.jpg Content-Disposition: inline; filename="micro_youtube.jpg"; size=1657; creation-date="Tue, 13 Mar 2012 22:05:15 GMT"; modification-date="Tue, 13 Mar 2012 22:05:15 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABQAAD/4QNvaHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjAtYzA2MCA2MS4xMzQ3NzcsIDIwMTAvMDIvMTItMTc6 MzI6MDAgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9 InhtcC5kaWQ6MDE4MDExNzQwNzIwNjgxMThGNjJEMkI3NTYxQzMzNTgiIHhtcE1NOkRvY3VtZW50 SUQ9InhtcC5kaWQ6QzNEREFFQzg5MzEwMTFERkE1MTBGQTNBQzgwMkNGRTgiIHhtcE1NOkluc3Rh bmNlSUQ9InhtcC5paWQ6QzNEREFFQzc5MzEwMTFERkE1MTBGQTNBQzgwMkNGRTgiIHhtcDpDcmVh dG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giPiA8eG1wTU06RGVyaXZlZEZy b20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDowNjgwMTE3NDA3MjA2ODExOEY2MkFFRURCREZC MjM4QSIgc3RSZWY6ZG9jdW1lbnRJRD0ieG1wLmRpZDowMTgwMTE3NDA3MjA2ODExOEY2MkQyQjc1 NjFDMzM1OCIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gPD94 cGFja2V0IGVuZD0iciI/Pv/uAA5BZG9iZQBkwAAAAAH/2wCEAAICAgICAgICAgIDAgICAwQDAgID BAUEBAQEBAUGBQUFBQUFBgYHBwgHBwYJCQoKCQkMDAwMDAwMDAwMDAwMDAwBAwMDBQQFCQYGCQ0L CQsNDw4ODg4PDwwMDAwMDw8MDAwMDAwPDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEI ABQAFAMBEQACEQEDEQH/xACGAAACAwAAAAAAAAAAAAAAAAAGBwUICQEAAwADAQAAAAAAAAAAAAAA AAUGAQQHCBAAAAQEBAQFBQEAAAAAAAAAAQIDBBEUBQYAEhMHMUEVCCFhIhYXkTJSRCYZEQABAwID BwIHAAAAAAAAAAABABECEgMxQQQhIjITFAUVUWGRYsLDBhYX/9oADAMBAAIRAxEAPwDRLfDvPouz d6btWdXaK7Zuds7Lp150kxTomG4EKg4kiotAMAiQ5Xhk0PEB8TR4YEKOa9x24VTdXKh7gtC139pU 8tUui16q1euXtKbgimopMrN8iKgkFSA6YDhFc7lc5tyMZ2xQ5IIk4AzLbPgr/Tfi9jpdLeuWdRLq GjAxlbEZTL7sRIGWTbzJrfPqnwb8nT9F1taV6/kc9KhNy03pQ19OHryceUeeNrrx0nPqjhjtpxZ2 xb2Sr9dl5nx9Fx34N3m8NdL8FWT4Ztkqw95WzBNw+43tcuctpvq2zt+5lkrzqDRM526VMQbpVFqW oCUBLog9bJiUD+mIiHEcM1KpEV+p0+k7td2hKm7TYGrNqumVIBccky5Og3EqKMfvMPIAxzvUXI29 XrRItVbID5lhsC9J6DTXNR2XsZtRMqL8ZSbbTESk8peg9ymlpK/5+aWkfVyw0so5o9S/GEcMKT4B vl+pTFcf6C7hub9taO3r0SaRmpydyBnk+OXln5YtQuJoGH29z6zHzy4EBFP8l7S/alpnzmJiP1jH GEL/2Q== --_008_7A969D71DD9A43C9ABB29380C8B97AB3stonesoftcom_ Content-Type: image/jpeg; name="micro_facebook.jpg" Content-Description: micro_facebook.jpg Content-Disposition: inline; filename="micro_facebook.jpg"; size=1716; creation-date="Tue, 13 Mar 2012 22:05:15 GMT"; modification-date="Tue, 13 Mar 2012 22:05:15 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABQAAD/4QNvaHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjAtYzA2MCA2MS4xMzQ3NzcsIDIwMTAvMDIvMTItMTc6 MzI6MDAgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9 InhtcC5kaWQ6MDE4MDExNzQwNzIwNjgxMThGNjJEMkI3NTYxQzMzNTgiIHhtcE1NOkRvY3VtZW50 SUQ9InhtcC5kaWQ6NDQ1N0E5NkQ5MjQ4MTFERjhEM0VEMDBDMTU3Rjk3N0MiIHhtcE1NOkluc3Rh bmNlSUQ9InhtcC5paWQ6NDQ1N0E5NkM5MjQ4MTFERjhEM0VEMDBDMTU3Rjk3N0MiIHhtcDpDcmVh dG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giPiA8eG1wTU06RGVyaXZlZEZy b20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDowMTgwMTE3NDA3MjA2ODExOEY2MkQyQjc1NjFD MzM1OCIgc3RSZWY6ZG9jdW1lbnRJRD0ieG1wLmRpZDowMTgwMTE3NDA3MjA2ODExOEY2MkQyQjc1 NjFDMzM1OCIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gPD94 cGFja2V0IGVuZD0iciI/Pv/uAA5BZG9iZQBkwAAAAAH/2wCEAAICAgICAgICAgIDAgICAwQDAgID BAUEBAQEBAUGBQUFBQUFBgYHBwgHBwYJCQoKCQkMDAwMDAwMDAwMDAwMDAwBAwMDBQQFCQYGCQ0L CQsNDw4ODg4PDwwMDAwMDw8MDAwMDAwPDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEI ABQAFAMBEQACEQEDEQH/xACHAAEBAQAAAAAAAAAAAAAAAAAHCAQBAAIDAAAAAAAAAAAAAAAAAAQF AgMGEAAAAwUGAgkFAQAAAAAAAAABAwURAhIEFAAhEwYWBzEXUWGBMiNDFQgYQbEiciQnEQABAgMG BQMFAQAAAAAAAAABEQIAAwQhQRITFAUxYYGxwWIjFfBRcYLCBv/aAAwDAQACEQMRAD8AuD3N+5vc 3bnc2Zybk2ZkExNTJGVONNNlXJk042ZcxXhETWgAAAgAAAdLW/TX7LstPU0+ZMUkk3pwhDuO4zZM 3AxAAIwbbbyb7Z2yUvbjZj3dyxt9ktAUHEo1VUUcqYEybfAsYICwchDxXAa1oiPC5tpVm3Ucia2S yU57yFQOSz6ERp6uomMMxzw1oKWiHbnyvfHrmXCn6ihpfUMN+hxKmmrMKKKCHxYG9TbJvj2a7Itw r14KniGOqdps2xU6cUXzES+8VEV1HfbMJ8gnnTRLsgmuPGFg0AepXLuPXbU/56a1tG0E3nvCTdWO dUFBcO0NWTs951R/aUpqZOUUM5Zy4vyiMnpcyllmS8xKlBKFgfMkxABpzHhETBFoiADZdUU0p+5B uNyOaSStoNtg+w5QZKnTG0hOEKCiJ+IxYc38NMKn/uqGUkPm1/ch/a5lhlHy63L/ADFqHQc08xQu +nIPUMnzEbqaldbRVONTtHDxqa7phjvZwusuodbgOSuFeXnxBVVpsXuceviC0r466cmcDVOkap2s g9Z9OqvxhxGeFid1jb+FiT8hjuxJ6FTvFQ0mH0/skPP+R8o/L0HhdjPvE3tb12Ve9nX5i9Vg728u 7AnRI//Z --_008_7A969D71DD9A43C9ABB29380C8B97AB3stonesoftcom_-- From ynir@checkpoint.com Tue Mar 13 15:48:11 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF0721E8037 for ; Tue, 13 Mar 2012 15:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.478 X-Spam-Level: X-Spam-Status: No, score=-10.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nqxn6yEcLk7L for ; Tue, 13 Mar 2012 15:48:11 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id CA83821E8033 for ; Tue, 13 Mar 2012 15:48:10 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2DMm3Mc007571; Wed, 14 Mar 2012 00:48:03 +0200 X-CheckPoint: {4F5FCE8E-0-1B221DC2-5FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 14 Mar 2012 00:48:02 +0200 From: Yoav Nir To: Mark Boltz Date: Wed, 14 Mar 2012 00:48:02 +0200 Thread-Topic: [IPsec] P2P VPN draft UNCLASSIFIED Thread-Index: Ac0Ba1i2/nisnKgmT0m5IRjZWL/YWA== Message-ID: <0D0B7A90-113A-4C1E-9A9C-3210D825BD23@checkpoint.com> References: <01OD167DRHJI9AMI66@Cisco.COM> <098C866D3766674B95CCF197E1C2489B0BA074042E@USNAVSXCHMBSC1.ndc.alcatel-lucent.com> <7A969D71-DD9A-43C9-ABB2-9380C8B97AB3@stonesoft.com> In-Reply-To: <7A969D71-DD9A-43C9-ABB2-9380C8B97AB3@stonesoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 22:48:11 -0000 On Mar 14, 2012, at 12:05 AM, Mark Boltz wrote: > I like Juniper's suggestion of "auto mesh VPNs", although other options m= ay be available. I think that dynamic is a good word, but I'd rather anythi= ng that can distill to an acronym that would be too ambiguous with DMVPN. O= r any other term currently used for proprietary vendor alternatives. Yes, I like Praveen's suggestion too. >=20 > The goal here is to create a vendor-agnostic standards-based solution, ri= ght? :-) Well, we make the standards, so anything we make will be standards-based, n= o? I'm also not sure what vendor-agnostic means here. As long as everyone c= an implement it, it doesn't matter how close it is to some vendor's impleme= ntation. What I would not like to see is something that makes requirements = that not all vendors can meet, such as the ability to dynamically set up vi= rtual interfaces, which is something not all platforms and operating system= s provide.= From paul@cypherpunks.ca Tue Mar 13 16:18:54 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CB621E804F for ; Tue, 13 Mar 2012 16:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYTS+6pXf1OL for ; Tue, 13 Mar 2012 16:18:53 -0700 (PDT) Received: from letoams.cypherpunks.ca (unknown [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8943C21E802D for ; Tue, 13 Mar 2012 16:18:52 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 3A0B282449; Tue, 13 Mar 2012 19:18:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 2CAE08198B; Tue, 13 Mar 2012 19:18:51 -0400 (EDT) Date: Tue, 13 Mar 2012 19:18:51 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Praveen Sathyanarayan In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ipsec@ietf.org" , Stephen Hanna Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 23:18:54 -0000 On Tue, 13 Mar 2012, Praveen Sathyanarayan wrote: > Few of my suggestions here > > 1.) Cut through VPN > 2.) Auto mesh VPN Coming from FreeS/WAN and Openswan, I'm tempted to call it OEVPN, where OE stands for Opportunistc Encryption. Paul (still need to read and comment) > On 3/12/12 5:22 PM, "Stephen Hanna" wrote: > > Of course, you're right. The acronym DMVPN makes this > a very bad choice. Thanks for pointing that out. > > I'll throw out a few ideas here: > > Dynamic Direct VPN (DDVPN) > Shortcut VPN (SVPN) > Dynamic Scalable VPN (DSVPN) > Dynamic Efficient VPN (DEVPN) > > Other ideas or comments on these are most welcome. > > Thanks, > > Steve > >> -----Original Message----- >> From: Mike Sullenberger [mailto:MLS@Cisco.COM] >> Sent: Monday, March 12, 2012 6:57 PM >> To: Stephen Hanna >> Cc: ipsec@ietf.org; Chris.Ulliott@cesg.gsi.gov.uk >> Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED >> >> Steve, >> >> I do not think changing the name to "Dynamic Mesh VPN" is a good idea. >> The first thing that is going to happen is that it is going to be >> shortened to "DMVPN" and then we have conflict with Cisco DMVPN, which >> would be confusing and also "DMVPN" is a registered trademark. It >> would be best to use some other synonym for "Dynamic Mesh". >> >> Mike. >> >>> Upon reflection, I can see how "Point to Point VPNs" is problematic >>> as a description of the problem. Really it's more about dynamically >>> creating SAs so that any endpoint or gateway can communicate directly >>> with any other, as permitted by policy. And how can we do this in a >>> manageable manner in a large-scale environment where endpoints are >>> mobile and configurations and policies change often? >>> >>> So "Dynamic Mesh VPNs" is fine with me. Whatever the WG feels is best. >>> >>> Thanks, >>> >>> Steve >>> >>>> -----Original Message----- >>>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >> Behalf >>>> Of Ulliott, Chris >>>> Sent: Wednesday, March 07, 2012 4:53 PM >>>> To: 'ipsec@ietf.org' >>>> Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED >>>> >>>> Classification:UNCLASSIFIED >>>> >>>> How about "dynamic mesh VPNs" as a title as I think the dynamic part >> is >>>> key here and probably an important aspect of the use cases. >>>> >>>> Chris >>>> >>>> [This message has been sent by a mobile device] >>>> >>>> ----- Original Message ----- >>>> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >>>> Sent: Wednesday, March 07, 2012 09:17 PM >>>> To: IPsecme WG >>>> Subject: [IPsec] P2P VPN draft >>>> >>>> Hi Steve, >>>> >>>> a few initial comments. >>>> >>>> * The draft is short and clear. Thanks for that! >>>> * I have a problem with the title (and even more, with the "file >>>> name" of the draft). P2P is usually perceived as peer-to-peer, >>>> which skews the discussion towards one particular use case, that >>>> of endpoint-to-endpoint. I suggest to use "Mesh IPsec VPN" >> instead. >>>> * I am unclear about 2.2: so what if you "suddenly need to >> exchange a >>>> lot of data". How is it different from normal IP traffic load >>>> management? The text is simply too vague here. Ideally, should >> we >>>> expect the traffic to migrate to other gateways? To go directly >>>> between endpoints? To establish priorities on existing gateways? >>>> >>>> Thanks, >>>> >>>> Yaron >> >> >> +------------------------------------------------+ >> | Mike Sullenberger; DSE | >> | mls@cisco.com .:|:.:|:. | >> | Customer Advocacy CISCO | >> +------------------------------------------------+ > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From kivinen@iki.fi Tue Mar 13 23:00:22 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111ED21F85EE for ; Tue, 13 Mar 2012 23:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8ZqFgc-wqe1 for ; Tue, 13 Mar 2012 23:00:21 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA6621F85ED for ; Tue, 13 Mar 2012 23:00:20 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q2E60Har019863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Mar 2012 08:00:17 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q2E60Gdm004093; Wed, 14 Mar 2012 08:00:16 +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: <20320.13296.969392.797484@fireball.kivinen.iki.fi> Date: Wed, 14 Mar 2012 08:00:16 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 18 min X-Total-Time: 18 min Subject: [IPsec] Some comments to the draft-ietf-ipsecme-p2p-vpn-problem-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 06:00:22 -0000 In section 2.1 where there is dicsussion about the endpoint to endpoint vpn use case, it should be noted, that this might require different temporary credentials. Endpoints (especially remote access users) do use passwords or similar credentials which cannot be forwarded. I.e. if the shared secret is used to authenticate the end node to the gateway, that same shared secret cannot be given to the another end point as that would allow it to impersonate the first peer. Also the endpoint most likely cannot access the same AAA server than what security gateway does, so if peer uses EAP to authenticate itself to the security gateway, the endpoint to endpoint vpn cannot use the same credentials. This means that we might need to add creation of temporary credentials to the protocol. In section 3.1 exhaustive configuration I think it is incorrect to claim it does not scale, as if the configuration is pushed to all devices using some kind of out of band configuration tool it is completely possible to make extreamly large setups. Dynamic updates do cause some problems there, as every change might require policy to be pushed to every single node. I think the main problem with this setup is that it requires that out of band configuration system, and those are proprietary which means you cannot use implementations from different vendors. In section 3.2 about star topology it should be noted, that quite often adminstrators do require star topology because they want to do some kind of inspection for all traffic inside the vpn. This kind of policy might make it impossible to do endpoint to endpoint connections, and might limit which kind of gateway to gateway cases are allowed. I do not see how the last paragraph in section 3.2 does not seem to belong there: The challenge is how to build large scale, fully meshed IPsec protected networks that can dynamically change with minimum administrative overhead. The section 3.2 talks about existing star topology solutions, and making large scale fully meshed network is not even in scope for such systems. In section 3.2 we should also mention that with proprietary approaches it is not clear whether they implement all checks required by the IPsec architecture, i.e tunnel exit checks, firewall rules, security policy checks etc. They might do those, or they might skip them... In general the current use case description was quite good, and I think this document is good start. -- kivinen@iki.fi From yaronf.ietf@gmail.com Wed Mar 14 00:14:21 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA5421F850B for ; Wed, 14 Mar 2012 00:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHSxpNKUkRAk for ; Wed, 14 Mar 2012 00:14:20 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id F281621F8501 for ; Wed, 14 Mar 2012 00:14:19 -0700 (PDT) Received: by werb10 with SMTP id b10so1636811wer.31 for ; Wed, 14 Mar 2012 00:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8YfefboI/HVn3nvAoUuyo2THPP8sS6nKmzTS06VnDj8=; b=GoQ9HRNRiCJ6fWxgfNkCouc2XOAYLs1griI24Drzd2z7ue6EPHeBka0tYUWhW7EdKx /nKxyGlPBy3NqlRflxDgWjCGBC8U3o7NHt/UxBegq56ktgGs0sX7Gc2e1cVtqcLN2RRU 7DPf6i07SFvAM8n/ry9NRytsp2XNQpRGD8gqzmkBFMoooApNwNlxS8qU/H5NBuiQ7M2O yVUl4MWC0yFPb3ott3lMwawF5VAPR5cfjemaIHwx3IeR+yBf7sGYzzbEqHTVdZ03XviQ CQw0xpX6JMCrjqixjdBAjNmwISWKjGZHl9bUo0+wQ9hEU2N4n0fs2W2TV6iu+GDfyt77 1Oqg== Received: by 10.180.92.34 with SMTP id cj2mr3569785wib.8.1331709259104; Wed, 14 Mar 2012 00:14:19 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-179-165-28.red.bezeqint.net. [79.179.165.28]) by mx.google.com with ESMTPS id fl2sm13054305wib.4.2012.03.14.00.14.17 (version=SSLv3 cipher=OTHER); Wed, 14 Mar 2012 00:14:17 -0700 (PDT) Message-ID: <4F604548.4050806@gmail.com> Date: Wed, 14 Mar 2012 09:14:16 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Paul Wouters References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , Stephen Hanna , Praveen Sathyanarayan Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 07:14:21 -0000 Hi Paul, the way I read it this is NOT Opportunistic Encryption. The draft makes it clear very early on that "Establishing communications between participants with no established trust relationship is out of scope for this effort." Thanks, Yaron On 03/14/2012 01:18 AM, Paul Wouters wrote: > On Tue, 13 Mar 2012, Praveen Sathyanarayan wrote: > >> Few of my suggestions here >> >> 1.) Cut through VPN >> 2.) Auto mesh VPN > > Coming from FreeS/WAN and Openswan, I'm tempted to call it OEVPN, > where OE stands for Opportunistc Encryption. > > Paul (still need to read and comment) > >> On 3/12/12 5:22 PM, "Stephen Hanna" wrote: >> >> Of course, you're right. The acronym DMVPN makes this >> a very bad choice. Thanks for pointing that out. >> >> I'll throw out a few ideas here: >> >> Dynamic Direct VPN (DDVPN) >> Shortcut VPN (SVPN) >> Dynamic Scalable VPN (DSVPN) >> Dynamic Efficient VPN (DEVPN) >> >> Other ideas or comments on these are most welcome. >> >> Thanks, >> >> Steve >> >>> -----Original Message----- >>> From: Mike Sullenberger [mailto:MLS@Cisco.COM] >>> Sent: Monday, March 12, 2012 6:57 PM >>> To: Stephen Hanna >>> Cc: ipsec@ietf.org; Chris.Ulliott@cesg.gsi.gov.uk >>> Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED >>> >>> Steve, >>> >>> I do not think changing the name to "Dynamic Mesh VPN" is a good idea. >>> The first thing that is going to happen is that it is going to be >>> shortened to "DMVPN" and then we have conflict with Cisco DMVPN, which >>> would be confusing and also "DMVPN" is a registered trademark. It >>> would be best to use some other synonym for "Dynamic Mesh". >>> >>> Mike. >>> >>>> Upon reflection, I can see how "Point to Point VPNs" is problematic >>>> as a description of the problem. Really it's more about dynamically >>>> creating SAs so that any endpoint or gateway can communicate directly >>>> with any other, as permitted by policy. And how can we do this in a >>>> manageable manner in a large-scale environment where endpoints are >>>> mobile and configurations and policies change often? >>>> >>>> So "Dynamic Mesh VPNs" is fine with me. Whatever the WG feels is best. >>>> >>>> Thanks, >>>> >>>> Steve >>>> >>>>> -----Original Message----- >>>>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >>> Behalf >>>>> Of Ulliott, Chris >>>>> Sent: Wednesday, March 07, 2012 4:53 PM >>>>> To: 'ipsec@ietf.org' >>>>> Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED >>>>> >>>>> Classification:UNCLASSIFIED >>>>> >>>>> How about "dynamic mesh VPNs" as a title as I think the dynamic part >>> is >>>>> key here and probably an important aspect of the use cases. >>>>> >>>>> Chris >>>>> >>>>> [This message has been sent by a mobile device] >>>>> >>>>> ----- Original Message ----- >>>>> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >>>>> Sent: Wednesday, March 07, 2012 09:17 PM >>>>> To: IPsecme WG >>>>> Subject: [IPsec] P2P VPN draft >>>>> >>>>> Hi Steve, >>>>> >>>>> a few initial comments. >>>>> >>>>> * The draft is short and clear. Thanks for that! >>>>> * I have a problem with the title (and even more, with the "file >>>>> name" of the draft). P2P is usually perceived as peer-to-peer, >>>>> which skews the discussion towards one particular use case, that >>>>> of endpoint-to-endpoint. I suggest to use "Mesh IPsec VPN" >>> instead. >>>>> * I am unclear about 2.2: so what if you "suddenly need to >>> exchange a >>>>> lot of data". How is it different from normal IP traffic load >>>>> management? The text is simply too vague here. Ideally, should >>> we >>>>> expect the traffic to migrate to other gateways? To go directly >>>>> between endpoints? To establish priorities on existing gateways? >>>>> >>>>> Thanks, >>>>> >>>>> Yaron >>> >>> >>> +------------------------------------------------+ >>> | Mike Sullenberger; DSE | >>> | mls@cisco.com .:|:.:|:. | >>> | Customer Advocacy CISCO | >>> +------------------------------------------------+ >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Wed Mar 14 00:46:47 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D603121F8698 for ; Wed, 14 Mar 2012 00:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.48 X-Spam-Level: X-Spam-Status: No, score=-10.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJO+5yiPE8SP for ; Wed, 14 Mar 2012 00:46:47 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9359621F8629 for ; Wed, 14 Mar 2012 00:46:46 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2E7kewV023377; Wed, 14 Mar 2012 09:46:43 +0200 X-CheckPoint: {4F604CC6-0-1B221DC2-5FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 14 Mar 2012 09:45:39 +0200 From: Yoav Nir To: Tero Kivinen Date: Wed, 14 Mar 2012 09:45:39 +0200 Thread-Topic: [IPsec] Some comments to the draft-ietf-ipsecme-p2p-vpn-problem-00 Thread-Index: Ac0BtnMqlBGwUCGcTDetqSQOLJ+6yg== Message-ID: <49807266-E1FC-423C-9ECC-85E284F6EA50@checkpoint.com> References: <20320.13296.969392.797484@fireball.kivinen.iki.fi> In-Reply-To: <20320.13296.969392.797484@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Some comments to the draft-ietf-ipsecme-p2p-vpn-problem-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 07:46:47 -0000 On Mar 14, 2012, at 8:00 AM, Tero Kivinen wrote: > In section 2.1 where there is dicsussion about the endpoint to > endpoint vpn use case, it should be noted, that this might require > different temporary credentials. Endpoints (especially remote access > users) do use passwords or similar credentials which cannot be > forwarded. I.e. if the shared secret is used to authenticate the end > node to the gateway, that same shared secret cannot be given to the > another end point as that would allow it to impersonate the first > peer. Also the endpoint most likely cannot access the same AAA server > than what security gateway does, so if peer uses EAP to authenticate > itself to the security gateway, the endpoint to endpoint vpn cannot > use the same credentials. Users use passwords, but endpoints can use PSKs and certificates. PSKs shou= ld be pairwise, so they have to be provisioned dynamically. It's all part o= f having to create the PAD entries dynamically. If we anyway have to provis= ion peer's IP address/locator and identity (DN, username) we might as well = also provision a PSK. If we really want to authenticate users, we need to use EAP to authenticate= to some trusted (by whom?) server. Then we can extend that authentication = to other endpoints and gateways that are not connected to the same AAA serv= er, perhaps using some mechanism like tickets or session resumption or ERP,= or by having the gateway provision the shared secrets for the client and t= he other peers. > This means that we might need to add creation of temporary credentials > to the protocol. I think that unless we are going to mandate a system based solely on certif= icates, that's a given. > In section 3.1 exhaustive configuration I think it is incorrect to > claim it does not scale, as if the configuration is pushed to all > devices using some kind of out of band configuration tool it is > completely possible to make extreamly large setups. Dynamic updates > do cause some problems there, as every change might require policy to > be pushed to every single node. I think the main problem with this > setup is that it requires that out of band configuration system, and > those are proprietary which means you cannot use implementations from > different vendors.=20 Take a company the size of IBM. They have 400,000 employees. Probably hundr= eds of thousands of smartphones, hundreds of thousands of PCs, and thousand= s of VPN gateways. It doesn't make sense that each smartphone holds the ent= ire PAD for all this, and we haven't even mentioned partners and customers = yet. You could keep a kind of star topology, where the phones are secondar= y nodes, and they connect to some primary nodes (using IKE or something els= e). When they need to connect to some other primary or secondary node, they= get that information from the primary node. And you can have the primary nodes know everything, or make it hierarchical= or DNS-based or something else entirely. This discovery mechanism is a big= part of the charter item, and I think it should avoid having to push the e= ntire policy to each endpoint. > In section 3.2 about star topology it should be noted, that quite > often adminstrators do require star topology because they want to do > some kind of inspection for all traffic inside the vpn. This kind of > policy might make it impossible to do endpoint to endpoint > connections, and might limit which kind of gateway to gateway cases > are allowed. That's a matter of policy. Sometimes they want to inspect traffic going in = and out of their organizational VPN, but not traffic flowing within it. So = traffic from the Maastricht office can flow freely to the Quebec City offic= e, and doesn't have to go through the New York datacenter. But traffic goin= g to Facebook needs to be scanned, and goes through the datacenter. > I do not see how the last paragraph in section 3.2 does not seem to > belong there: >=20 > The challenge is how to build large scale, fully meshed IPsec > protected networks that can dynamically change with minimum > administrative overhead. >=20 > The section 3.2 talks about existing star topology solutions, and > making large scale fully meshed network is not even in scope for such > systems. I think the point of section 3.2 is that stars are defined partly because t= hey're easier (just one credential to configure on each satellite). The cha= llenge is to overcome the difficulty in defining a mesh. >=20 > In section 3.2 we should also mention that with proprietary approaches > it is not clear whether they implement all checks required by the > IPsec architecture, i.e tunnel exit checks, firewall rules, security > policy checks etc. They might do those, or they might skip them... >=20 >=20 > In general the current use case description was quite good, and I > think this document is good start.=20 From mcr@sandelman.ca Wed Mar 14 08:49:00 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E6421F85B6 for ; Wed, 14 Mar 2012 08:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.583 X-Spam-Level: X-Spam-Status: No, score=-1.583 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzNV8gkeuOOv for ; Wed, 14 Mar 2012 08:49:00 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 48C2121F85A8 for ; Wed, 14 Mar 2012 08:49:00 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [38.102.80.246]) by relay.sandelman.ca (Postfix) with ESMTPS id 72A6EA0079 for ; Wed, 14 Mar 2012 11:46:24 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id E7541983B9; Wed, 14 Mar 2012 11:48:58 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id E418B98281 for ; Wed, 14 Mar 2012 11:48:58 -0400 (EDT) From: Michael Richardson To: "ipsec@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Wed, 14 Mar 2012 11:48:58 -0400 Message-ID: <19313.1331740138@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 15:49:01 -0000 >>>>> "Paul" == Paul Wouters writes: >> Few of my suggestions here >> >> 1.) Cut through VPN 2.) Auto mesh VPN Paul> Coming from FreeS/WAN and Openswan, I'm tempted to call it Paul> OEVPN, where OE stands for Opportunistc Encryption. It's not Opportunistic. It's configured, it's just on-demand. In Openswan terminology that would mean a "routed" policy with a DNS lookup. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From kivinen@iki.fi Wed Mar 14 11:13:42 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A1E21F84EB for ; Wed, 14 Mar 2012 11:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmwAFxLkLFi7 for ; Wed, 14 Mar 2012 11:13:41 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id F206721E8044 for ; Wed, 14 Mar 2012 11:13:40 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q2EIDQP1023719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Mar 2012 20:13:26 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q2EIDMuk014663; Wed, 14 Mar 2012 20:13:22 +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: <20320.57282.282276.502354@fireball.kivinen.iki.fi> Date: Wed, 14 Mar 2012 20:13:22 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: <49807266-E1FC-423C-9ECC-85E284F6EA50@checkpoint.com> References: <20320.13296.969392.797484@fireball.kivinen.iki.fi> <49807266-E1FC-423C-9ECC-85E284F6EA50@checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 8 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Some comments to the draft-ietf-ipsecme-p2p-vpn-problem-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 18:13:42 -0000 Yoav Nir writes: > Users use passwords, but endpoints can use PSKs and certificates. > PSKs should be pairwise, so they have to be provisioned dynamically. > It's all part of having to create the PAD entries dynamically. If we > anyway have to provision peer's IP address/locator and identity (DN, > username) we might as well also provision a PSK. I think this is something that should be pointed out in the use case for endpoint to endpoint scenario. Just to make it clear. Also adding note about that to the security considerations section is also needed. > If we really want to authenticate users, we need to use EAP to > authenticate to some trusted (by whom?) server. Then we can extend > that authentication to other endpoints and gateways that are not > connected to the same AAA server, perhaps using some mechanism like > tickets or session resumption or ERP, or by having the gateway > provision the shared secrets for the client and the other peers. I would actually think short lived certificates would be better and much more scalable way to provide temporary credentials. > > In section 3.1 exhaustive configuration I think it is incorrect to > > claim it does not scale, as if the configuration is pushed to all > > devices using some kind of out of band configuration tool it is > > completely possible to make extreamly large setups. Dynamic updates > > do cause some problems there, as every change might require policy to > > be pushed to every single node. I think the main problem with this > > setup is that it requires that out of band configuration system, and > > those are proprietary which means you cannot use implementations from > > different vendors. > > Take a company the size of IBM. They have 400,000 employees. > Probably hundreds of thousands of smartphones, hundreds of thousands > of PCs, and thousands of VPN gateways. It doesn't make sense that > each smartphone holds the entire PAD for all this, and we haven't > even mentioned partners and customers yet. You could keep a kind of > star topology, where the phones are secondary nodes, and they > connect to some primary nodes (using IKE or something else). When > they need to connect to some other primary or secondary node, they > get that information from the primary node. > > And you can have the primary nodes know everything, or make it > hierarchical or DNS-based or something else entirely. This discovery > mechanism is a big part of the charter item, and I think it should > avoid having to push the entire policy to each endpoint. In most of those big enterprices they already have some kind of tools to push policy and configuration to every single device. They might not even allow device to connect to the network before they can verify that the device has up to date configuration and policy. As far as I understand this is already standard working practices they are doing now, and claiming you cannot do that is bit misleading. But as I sid they do require some out of band policy distribution mechanisms which are not standardized... > > In section 3.2 about star topology it should be noted, that quite > > often adminstrators do require star topology because they want to do > > some kind of inspection for all traffic inside the vpn. This kind of > > policy might make it impossible to do endpoint to endpoint > > connections, and might limit which kind of gateway to gateway cases > > are allowed. > > That's a matter of policy. Sometimes they want to inspect traffic > going in and out of their organizational VPN, but not traffic > flowing within it. So traffic from the Maastricht office can flow > freely to the Quebec City office, and doesn't have to go through the > New York datacenter. But traffic going to Facebook needs to be > scanned, and goes through the datacenter. Yes, and I think the star topology section should point out that in some cases the topology is required because of the policy reason, as this do affect our scope / use cases. > > I do not see how the last paragraph in section 3.2 does not seem to > > belong there: > > > > The challenge is how to build large scale, fully meshed IPsec > > protected networks that can dynamically change with minimum > > administrative overhead. > > > > The section 3.2 talks about existing star topology solutions, and > > making large scale fully meshed network is not even in scope for such > > systems. > > I think the point of section 3.2 is that stars are defined partly > because they're easier (just one credential to configure on each > satellite). The challenge is to overcome the difficulty in defining > a mesh. I think that paragraph should then be modified to say that... -- kivinen@iki.fi From paul@cypherpunks.ca Wed Mar 14 11:20:40 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2100721F84D4 for ; Wed, 14 Mar 2012 11:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wufeCmNlszRc for ; Wed, 14 Mar 2012 11:20:39 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB3D21F84D1 for ; Wed, 14 Mar 2012 11:20:39 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 8870682449; Wed, 14 Mar 2012 14:20:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 7D05B8198B for ; Wed, 14 Mar 2012 14:20:37 -0400 (EDT) Date: Wed, 14 Mar 2012 14:20:37 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: ipsec@ietf.org In-Reply-To: <19313.1331740138@marajade.sandelman.ca> Message-ID: References: <19313.1331740138@marajade.sandelman.ca> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 18:20:40 -0000 On Wed, 14 Mar 2012, Michael Richardson wrote: >>>>>> "Paul" == Paul Wouters writes: > >> Few of my suggestions here > >> > >> 1.) Cut through VPN 2.) Auto mesh VPN > > Paul> Coming from FreeS/WAN and Openswan, I'm tempted to call it > Paul> OEVPN, where OE stands for Opportunistc Encryption. > > It's not Opportunistic. > It's configured, it's just on-demand. In Openswan terminology that > would mean a "routed" policy with a DNS lookup. Guess that's what I get for not fully reading the doument yet. I assumed "P2P" actually meant "peer to peer" which kinda assumes unknown peers and on the fly configuration. Paul From paul.hoffman@vpnc.org Wed Mar 14 12:20:16 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4576921F8782 for ; Wed, 14 Mar 2012 12:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bXOqC3fmMFv for ; Wed, 14 Mar 2012 12:20:15 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BD02421F8732 for ; Wed, 14 Mar 2012 12:20:15 -0700 (PDT) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2EJKElN053315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 14 Mar 2012 12:20:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: Date: Wed, 14 Mar 2012 12:20:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <383BDA11-85C4-4090-AC39-CF4C85A2643D@vpnc.org> References: <19313.1331740138@marajade.sandelman.ca> To: IPsecme WG X-Mailer: Apple Mail (2.1257) Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 19:20:16 -0000 On Mar 14, 2012, at 11:20 AM, Paul Wouters wrote: > Guess that's what I get for not fully reading the doument yet. A note to everyone: reading the document sooner rather than later will = help make our hour in Paris much more useful. > I assumed > "P2P" actually meant "peer to peer" which kinda assumes unknown peers > and on the fly configuration. The term "peer" means no such thing. It means "two parties who = communicate without there being a client-server relationship". There are = numerous other IETF protocols that use "peer" in this context. --Paul Hoffman From mcr@sandelman.ca Thu Mar 15 11:08:12 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0AA21F87FD for ; Thu, 15 Mar 2012 11:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvp4YJSiVYj2 for ; Thu, 15 Mar 2012 11:08:11 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id E8B9F21F87FB for ; Thu, 15 Mar 2012 11:08:09 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.236.41]) by relay.sandelman.ca (Postfix) with ESMTPS id 35547A0079; Thu, 15 Mar 2012 14:05:33 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 0D241983B9; Thu, 15 Mar 2012 14:08:09 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 03A64983B8; Thu, 15 Mar 2012 14:08:09 -0400 (EDT) From: Michael Richardson To: Tero Kivinen In-Reply-To: <20320.13296.969392.797484@fireball.kivinen.iki.fi> References: <20320.13296.969392.797484@fireball.kivinen.iki.fi> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Thu, 15 Mar 2012 14:08:08 -0400 Message-ID: <18444.1331834888@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: ipsec@ietf.org Subject: Re: [IPsec] Some comments to the draft-ietf-ipsecme-p2p-vpn-problem-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 18:08:12 -0000 >>>>> "Tero" == Tero Kivinen writes: Tero> This means that we might need to add creation of temporary Tero> credentials to the protocol. This is an interesting question. I think the requirements document needs to either make this in scope or make it out of scope by requiring re-usable mechanisms of authentication. Tero> In section 3.2 about star topology it should be noted, that Tero> quite often adminstrators do require star topology because Tero> they want to do some kind of inspection for all traffic inside Tero> the vpn. This kind of policy might make it impossible to do Tero> endpoint to endpoint connections, and might limit which kind Tero> of gateway to gateway cases are allowed. So, then don't deploy DMVPN or whatever it's gonna be called. Is this for the applicability statement then? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From kivinen@iki.fi Thu Mar 15 11:49:15 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78A121F8650 for ; Thu, 15 Mar 2012 11:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCzhHEbwDhU4 for ; Thu, 15 Mar 2012 11:49:15 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D0921F863F for ; Thu, 15 Mar 2012 11:49:14 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q2FInBJu012575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Mar 2012 20:49:11 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q2FInA5U019173; Thu, 15 Mar 2012 20:49:10 +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: <20322.14758.877033.207664@fireball.kivinen.iki.fi> Date: Thu, 15 Mar 2012 20:49:10 +0200 From: Tero Kivinen To: Michael Richardson In-Reply-To: <18444.1331834888@marajade.sandelman.ca> References: <20320.13296.969392.797484@fireball.kivinen.iki.fi> <18444.1331834888@marajade.sandelman.ca> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 4 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Some comments to the draft-ietf-ipsecme-p2p-vpn-problem-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 18:49:16 -0000 Michael Richardson writes: > Tero> In section 3.2 about star topology it should be noted, that > Tero> quite often adminstrators do require star topology because > Tero> they want to do some kind of inspection for all traffic inside > Tero> the vpn. This kind of policy might make it impossible to do > Tero> endpoint to endpoint connections, and might limit which kind > Tero> of gateway to gateway cases are allowed. > > So, then don't deploy DMVPN or whatever it's gonna be called. > Is this for the applicability statement then? As this "star topology" section is in "Inadequacy of Existing Solutions" section, so adding note that some people still want to use the existing solution because of these reasons, might be good thing so we do not need to try to solve that in our solution. -- kivinen@iki.fi From kivinen@iki.fi Thu Mar 15 17:17:54 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C4B21E8051 for ; Thu, 15 Mar 2012 17:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_74=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7A8WnEGvDsBW for ; Thu, 15 Mar 2012 17:17:53 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7837721E804C for ; Thu, 15 Mar 2012 17:17:53 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q2G0Hll0005266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Mar 2012 02:17:47 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q2G0HkEE020252; Fri, 16 Mar 2012 02:17:46 +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: <20322.34474.737180.721238@fireball.kivinen.iki.fi> Date: Fri, 16 Mar 2012 02:17:46 +0200 From: Tero Kivinen To: ipsec@ietf.org, tso@zteusa.com X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 20 min X-Total-Time: 19 min Subject: [IPsec] Comments to draft-so-ipsecme-ikev2-cpext-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 00:17:54 -0000 I think I am completely lost with this draft. If I have understood correctly the basic setup is: UE -- FAP -- NAT --- SeGW --- Mobile network ^ ^ | \--- Public IP+Port \-- Private IP and the problem is that the Mobile network needs to know the Public IP+Port assigned by the NAT. It seems to say: 1) SeGW has this information but it cannot pass it forward 2) Reason being that there is no justification to require FAP spcific changes in SeGW 3) And it is outside the scope is document to add interface which could be used to pass on SeGWs knowledge forward 4) I.e. SeGW cannot be modified and this draft tries to fix this by 1) Modify the SeGW to support completely new configuration payload attribute 2) Send this Public IP + Port inside that configuration payload attribute to FAP 3) FAP then probably sends it forward to other side of SeGW? I should point out that quite a many of the security gateways already have ways to find out the public IP address+port of the IKE peer, just because it is usually needed for statistics. Why do you think security gateway vendors would add support to this very FAP specific feature, and not add the much more commonly usable feature of getting information and statistics about the existing IKE and IPsec SAs? I think it would be much better to write document which documents what kind of API is wanted from the SeGW to get this information (and that document does not need to be IETF document). -- kivinen@iki.fi From tso@zteusa.com Thu Mar 15 20:13:50 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBFB21F852E; Thu, 15 Mar 2012 20:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.238 X-Spam-Level: X-Spam-Status: No, score=-1.238 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, J_CHICKENPOX_74=0.6, RCVD_DOUBLE_IP_LOOSE=0.76] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWzTAnt7Uatg; Thu, 15 Mar 2012 20:13:49 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0274221F852D; Thu, 15 Mar 2012 20:13:46 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 52373433787882; Fri, 16 Mar 2012 11:06:17 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 65905.882571590; Fri, 16 Mar 2012 11:13:44 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q2G3DcoU019090; Fri, 16 Mar 2012 11:13:38 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: <20322.34474.737180.721238@fireball.kivinen.iki.fi> References: <20322.34474.737180.721238@fireball.kivinen.iki.fi> To: Tero Kivinen MIME-Version: 1.0 X-KeepSent: CFA548E8:C51A6C5B-882579C3:00097A6F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Thu, 15 Mar 2012 19:10:18 -0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-16 11:13:39, Serialize complete at 2012-03-16 11:13:39 Content-Type: multipart/alternative; boundary="=_alternative 0011B917882579C3_=" X-MAIL: mse01.zte.com.cn q2G3DcoU019090 Cc: ipsec@ietf.org, ipsec-bounces@ietf.org Subject: Re: [IPsec] Comments to draft-so-ipsecme-ikev2-cpext-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 03:13:50 -0000 This is a multipart message in MIME format. --=_alternative 0011B917882579C3_= Content-Type: text/plain; charset="US-ASCII" Dear Tero, Thank you for your interests on my draft. Please see my responses to you inline below. Cheers. Tricci Tero Kivinen Sent by: ipsec-bounces@ietf.org 03/15/2012 05:17 PM To ipsec@ietf.org, tso@zteusa.com cc Subject [IPsec] Comments to draft-so-ipsecme-ikev2-cpext-01 I think I am completely lost with this draft. If I have understood correctly the basic setup is: UE -- FAP -- NAT --- SeGW --- Mobile network ^ ^ | \--- Public IP+Port \-- Private IP and the problem is that the Mobile network needs to know the Public IP+Port assigned by the NAT. Tricci > First of all, hoping that you and I have the common understanding that, the portion of the network that deploys NAT is the fixed network and its corresponding operator is NOT the same operator who runs the mobile network. However, the FAP is attached to the fixed network with IPSec tunnel established over the fixed network which assigns the private-IP to the FAT and assigns the public-IP at the NAT. At the same time, the SeGW is resided at the mobile network and has no direct interface towards the fixed network nor standardized interface connecting to the mobile network (even though it is part of the mobile network). SeGW is operated as the firewall for the mobile network and has absolutely no mobile-standardized interface to communicate with any of the mobile network element. Tricci > It is very important to understand the actual femto deployment today. Hoping that you can accept this. It seems to say: 1) SeGW has this information but it cannot pass it forward Tricci > SeGW has no standardized interface to communicate any mobile network element 2) Reason being that there is no justification to require FAP spcific changes in SeGW Tricci > Yes. Because SeGW is off-the-shelf firewall product and is not specific designed for Femto deployment. 3) And it is outside the scope is document to add interface which could be used to pass on SeGWs knowledge forward Tricci > Yes. It is outside the scope of IETF to define the interface on the Femto for different mobile technologies that deploy Femto 4) I.e. SeGW cannot be modified Tricci > No, this is not what I have described. What I have explained is that, SeGW cannot be modified to standardize a "specific" interface for a specific mobile technology. However, we can modify the SeGW for the standard protocol that it supports, e.g. IKEv2/IPSEC. Hoping that you can understand the differences between interface vs. protocol. and this draft tries to fix this by 1) Modify the SeGW to support completely new configuration payload attribute Tricci > IMHO opinion, configuration is designed to support different types of configuration info as long as it is associated with the IKE-peer. Extending an existing protocol which is designed to be extensible is far more easier to modify an existing network component which is designed to be off-the-shelf, and it is definitely far more simple than to change the existing Femto network architecture just to support this "new" interface. 2) Send this Public IP + Port inside that configuration payload attribute to FAP Tricci > Yes. Please note that, as of today many IPSec deployment, including over the Femto network, the configuration payload has already been used by the SeGW to carry the IKE-client source inner-IP info assigned by the DHCP server back to the IKE-client. Please check RFC-5996. The different between my draft and this existing function is to have the SeGW to carry the "NATed" IKE-client source outer-IP info back to the IKE-client. 3) FAP then probably sends it forward to other side of SeGW? Tricci > Sorry, this is incorrect. The FAP has the standardized interface towards the mobile network. Once the IPSec tunnel is established, all the data and control info are carried within the IPSec-tunnel's payload. They are totally transparent to the SeGW. SeGW is just a firewall pipe and it cannot see inside the IPSec-tunnel's payload. The key point is that, FAP has the standardized interface to its associated mobile network for a given mobile technology and SeGW does not. I should point out that quite a many of the security gateways already have ways to find out the public IP address+port of the IKE peer, just because it is usually needed for statistics. Why do you think security gateway vendors would add support to this very FAP specific feature, and not add the much more commonly usable feature of getting information and statistics about the existing IKE and IPsec SAs? Tricci > Sorry, I respectfully disagree with your assessment. Today IKE/IPSec framework is missing a capability to allow the IKE-client to learn about its NATed IP-address. This problem is well understood and hence, there is another IETF RFC-5389 that I have mentioned in my draft is trying to resolve this issue. Unfortunately, the design of RFC-5389 cannot fit into the Femto network architecture which in general involves two different types of network operators who manage two different parts of the network segment. Tricci > Hence, this NATed issue is generic, however, we don't have a generic solution so far to solve this issue. And I believe that my draft resolve this issue in a generic way. It happens Femto network architecture is the one which breaks the solution offered by RFC-5389. I think it would be much better to write document which documents what kind of API is wanted from the SeGW to get this information (and that document does not need to be IETF document). Tricci > Again, please refer to the existing RFC-5996 for the Configuration Payload support for carrying the source inner-ip of the IKE-client from IKE-server (i.e. SeGW) back to the IKE-client. The idea is nothing new. The different is just the inner vs. outer IP-addr. That's all. Tricci > Thank you very much for your patient to read through this long email responses from me. Cheers. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0011B917882579C3_= Content-Type: text/html; charset="US-ASCII" Dear Tero,

Thank you for your interests on my draft.  

Please see my responses to you inline below.

Cheers.
Tricci




Tero Kivinen <kivinen@iki.fi>
Sent by: ipsec-bounces@ietf.org

03/15/2012 05:17 PM

To
ipsec@ietf.org, tso@zteusa.com
cc
Subject
[IPsec] Comments to draft-so-ipsecme-ikev2-cpext-01





I think I am completely lost with this draft.

If I have understood correctly the basic setup is:

UE -- FAP -- NAT --- SeGW --- Mobile network
                 ^                 ^
                 |                 \--- Public IP+Port
                 \-- Private IP
                 
and the problem is that the Mobile network needs to know the Public
IP+Port assigned by the NAT.

Tricci > First of all, hoping that you and I have the common understanding that, the portion of the network that deploys NAT is the fixed network and its corresponding operator is NOT the same operator who runs the mobile network.  However, the FAP is attached to the fixed network with IPSec tunnel established over the fixed network which assigns the private-IP to the FAT and assigns the public-IP at the NAT.   At the same time, the SeGW is resided at the mobile network and has no direct interface towards the fixed network nor standardized interface connecting to the mobile network (even though it is part of the mobile network).  SeGW is operated as the firewall for the mobile network and has absolutely no mobile-standardized interface to communicate with any of the mobile network element.  

Tricci > It is very important to understand the actual femto deployment today. Hoping that you can accept this.  

It seems to say:

1) SeGW has this information but it cannot pass it forward
Tricci > SeGW has no standardized interface to communicate any mobile network element

2) Reason being that there is no justification to require
  FAP spcific changes in SeGW
Tricci > Yes. Because SeGW is off-the-shelf firewall product and is not specific designed for Femto deployment.  

3) And it is outside the scope is document to add interface which
  could be used to pass on SeGWs knowledge forward
Tricci > Yes. It is outside the scope of IETF to define the interface on the Femto for different mobile technologies that deploy Femto

4) I.e. SeGW cannot be modified
Tricci > No, this is not what I have described. What I have explained is that, SeGW cannot be modified to standardize a "specific" interface for a specific mobile technology.  However, we can modify the SeGW for the standard protocol that it supports, e.g. IKEv2/IPSEC.  Hoping that you can understand the differences between interface vs. protocol.  

and this draft tries to fix this by

1) Modify the SeGW to support completely new configuration payload
  attribute
Tricci > IMHO opinion, configuration is designed to support different types of configuration info as long as it is associated with the IKE-peer.  Extending an existing protocol which is designed to be extensible is far more easier to modify an existing network component which is designed to be off-the-shelf, and it is definitely far more simple than to change the existing Femto network architecture just to support this "new" interface.  

2) Send this Public IP + Port inside that configuration payload
  attribute to FAP
Tricci > Yes.  Please note that, as of today many IPSec deployment, including over the Femto network, the configuration payload has already been used by the SeGW to carry the IKE-client source inner-IP info assigned by the DHCP server back to the IKE-client.  Please check RFC-5996.   The different between my draft and this existing function is to have the SeGW to carry the "NATed" IKE-client source outer-IP info back to the IKE-client.

3) FAP then probably sends it forward to other side of SeGW?
Tricci > Sorry, this is incorrect.  The FAP has the standardized interface towards the mobile network.  Once the IPSec tunnel is established, all the data and control info are carried within the IPSec-tunnel's payload.  They are totally transparent to the SeGW.  SeGW is just a firewall pipe and it cannot see inside the IPSec-tunnel's payload.  The key point is that, FAP has the standardized interface to its associated mobile network for a given mobile technology and SeGW does not.  

I should point out that quite a many of the security gateways already
have ways to find out the public IP address+port of the IKE peer, just
because it is usually needed for statistics.

Why do you think security gateway vendors would add support to this
very FAP specific feature, and not add the much more commonly usable
feature of getting information and statistics about the existing IKE
and IPsec SAs?

Tricci > Sorry, I respectfully disagree with your assessment. Today IKE/IPSec framework is missing a capability to allow the IKE-client to learn about its NATed IP-address.  This problem is well understood and hence, there is another IETF RFC-5389 that I have mentioned in my draft is trying to resolve this issue.  Unfortunately, the design of RFC-5389 cannot fit into the Femto network architecture which in general involves two different types of network operators who manage two different parts of the network segment.  

Tricci > Hence, this NATed issue is generic, however, we don't have a generic solution so far to solve this issue.  And I believe that my draft resolve this issue in a generic way.  It happens Femto network architecture is the one which breaks the solution offered by RFC-5389.  

I think it would be much better to write document which documents what
kind of API is wanted from the SeGW to get this information (and that
document does not need to be IETF document).
Tricci > Again, please refer to the existing RFC-5996 for the Configuration Payload support for carrying the source inner-ip of the IKE-client from IKE-server (i.e. SeGW) back to the IKE-client.  The idea is nothing new.  The different is just the inner vs. outer IP-addr.  That's all.  

Tricci > Thank you very much for your patient to read through this long email responses from me.   Cheers.

--
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0011B917882579C3_=-- From kivinen@iki.fi Thu Mar 15 20:56:35 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2538021E8065 for ; Thu, 15 Mar 2012 20:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Z-hFDFFKEzK for ; Thu, 15 Mar 2012 20:56:34 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3784A21E801B for ; Thu, 15 Mar 2012 20:56:32 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q2G3uQcl010989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Mar 2012 05:56:26 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q2G3uLq1005857; Fri, 16 Mar 2012 05:56:21 +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: <20322.47589.872145.52237@fireball.kivinen.iki.fi> Date: Fri, 16 Mar 2012 05:56:21 +0200 From: Tero Kivinen To: tso@zteusa.com In-Reply-To: References: <20322.34474.737180.721238@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 25 min X-Total-Time: 24 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Comments to draft-so-ipsecme-ikev2-cpext-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 03:56:35 -0000 tso@zteusa.com writes: > Tricci > First of all, hoping that you and I have the common understanding > that, the portion of the network that deploys NAT is the fixed network and > its corresponding operator is NOT the same operator who runs the mobile > network. However, the FAP is attached to the fixed network with IPSec > tunnel established over the fixed network which assigns the private-IP to > the FAT and assigns the public-IP at the NAT. At the same time, the SeGW > is resided at the mobile network and has no direct interface towards the > fixed network nor standardized interface connecting to the mobile network > (even though it is part of the mobile network). SeGW is operated as the > firewall for the mobile network and has absolutely no mobile-standardized > interface to communicate with any of the mobile network element. That was how I understood it. > Tricci > It is very important to understand the actual femto deployment > today. Hoping that you can accept this. > > It seems to say: > > 1) SeGW has this information but it cannot pass it forward > Tricci > SeGW has no standardized interface to communicate any mobile > network element But as I commented most of the product do have non-standard methods of getting that information out, and getting standardized API on those is in the same order of difficulty than getting that configuration payload support added to those products. > 2) Reason being that there is no justification to require > FAP spcific changes in SeGW > Tricci > Yes. Because SeGW is off-the-shelf firewall product and is not > specific designed for Femto deployment. Which means they will not support this feature now, and most likely will not support it in the future, as the only use for it is in the femto deployment, and as you mentioned those are off-the-shelf products not specific to femto.... > 4) I.e. SeGW cannot be modified > Tricci > No, this is not what I have described. What I have explained is > that, SeGW cannot be modified to standardize a "specific" interface for a > specific mobile technology. However, we can modify the SeGW for the > standard protocol that it supports, e.g. IKEv2/IPSEC. Hoping that you can > understand the differences between interface vs. protocol. As an OEM IPsec toolkit vendor I myself would much rather add standardized api to give this information to the mobile network than start adding some hack about configuration payloads. Especially as the standardized api can be used by different deployments, but this configuration payload support is completely femto specific. Also we do have internal apis for getting that information already, so making suitable wrapper to export the apis as needed is not that much work. For example I think in our toolkit you can get the information you need by http statistics interface which has all the open IKEv2 SAs, their addresses, statistics etc. > and this draft tries to fix this by > > 1) Modify the SeGW to support completely new configuration payload > attribute > Tricci > IMHO opinion, configuration is designed to support different > types of configuration info as long as it is associated with the IKE-peer. > Extending an existing protocol which is designed to be extensible is far > more easier to modify an existing network component which is designed to > be off-the-shelf, and it is definitely far more simple than to change the > existing Femto network architecture just to support this "new" interface. All of those do require changes to the code, which means that after that it will nto be off-the-shelf product anymore. I see no reason to add that kind of femto specific hack to general IPsec implementation, especially as there are cleaner ways to do the same thing. Am still not sure what the FAP does with the IP-address and what kind of attacks can malicious FAP do, as if the information about the IP-address is reflected by the FAP and not from the SeGW, the information cannot be trusted. > > > 2) Send this Public IP + Port inside that configuration payload > attribute to FAP > Tricci > Yes. Please note that, as of today many IPSec deployment, > including over the Femto network, the configuration payload has already > been used by the SeGW to carry the IKE-client source inner-IP info > assigned by the DHCP server back to the IKE-client. Please check > RFC-5996. The different between my draft and this existing function is > to have the SeGW to carry the "NATed" IKE-client source outer-IP info back > to the IKE-client. DHCP server address is CONFIOGURATION parameter. IKE client source outer-IP infor is NOT. There is big fundamental difference there. Am not saying it cannot be done, I am saying it should not be done that way. > 3) FAP then probably sends it forward to other side of SeGW? > Tricci > Sorry, this is incorrect. The FAP has the standardized interface So FAP does NOT send that information to the mobile network, but only uses it himself? > towards the mobile network. Once the IPSec tunnel is established, all the > data and control info are carried within the IPSec-tunnel's payload. They > are totally transparent to the SeGW. SeGW is just a firewall pipe and it > cannot see inside the IPSec-tunnel's payload. The key point is that, FAP > has the standardized interface to its associated mobile network for a > given mobile technology and SeGW does not. Here you do seem to indicate that the FAP do send the information through the IPsec tunnel to the other side of SeGW, to the mobile network, which seems to indicate that my original statement was correct. How does the mobile network know that FAP does not fake or lie about the address it is sending? > Why do you think security gateway vendors would add support to this > very FAP specific feature, and not add the much more commonly usable > feature of getting information and statistics about the existing IKE > and IPsec SAs? > > Tricci > Sorry, I respectfully disagree with your assessment. Today > IKE/IPSec framework is missing a capability to allow the IKE-client to > learn about its NATed IP-address. Yes it is missing that feature. It is missing lots of other features (for example it does not know the current phase of the moon). That does not mean we need to add them all, and even when someone thinks it would be good idea. And even when someone writes documentation about that, it does not mean vendors actually implement them. > This problem is well understood and hence, there is another IETF > RFC-5389 that I have mentioned in my draft is trying to resolve this > issue. Unfortunately, the design of RFC-5389 cannot fit into the > Femto network architecture which in general involves two different > types of network operators who manage two different parts of the > network segment. That specific information has no meaning for the IPsec or IKE, so there is no point of adding it as part of IPsec/IKE. > Tricci > Hence, this NATed issue is generic, however, we don't have a > generic solution so far to solve this issue. And I believe that my draft > resolve this issue in a generic way. It happens Femto network > architecture is the one which breaks the solution offered by RFC-5389. I strongly disagree. I do not think this is generic issue, but I consider it very femto specific. > I think it would be much better to write document which documents what > kind of API is wanted from the SeGW to get this information (and that > document does not need to be IETF document). > Tricci > Again, please refer to the existing RFC-5996 for the > Configuration Payload support for carrying the source inner-ip of the > IKE-client from IKE-server (i.e. SeGW) back to the IKE-client. The idea > is nothing new. The different is just the inner vs. outer IP-addr. That's > all. I am very familiar with RFC5996, and there is big fundamental difference bithween the inner vs outer IP-address. Inner address is configuration information transmitted from the SGW to the client, and client itself uses it to create virtual interfaces etc. It is required for certain kinds of setups. Outer address has no use for IPsec or for IKE. It is not configuration information, but just one data readily available in the SGW, and something that is not useful for the client itself. In your cases the FAP client does not need the address, it is the network behind the security gateway which needs it. -- kivinen@iki.fi From tso@zteusa.com Thu Mar 15 21:24:01 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17EEE21E8048; Thu, 15 Mar 2012 21:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.424 X-Spam-Level: X-Spam-Status: No, score=-1.424 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gt9TyizswROL; Thu, 15 Mar 2012 21:23:59 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4D10021F852C; Thu, 15 Mar 2012 21:23:58 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 12280433787882; Fri, 16 Mar 2012 11:49:37 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 69586.882571590; Fri, 16 Mar 2012 12:23:33 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q2G4MmBO099153; Fri, 16 Mar 2012 12:22:48 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: <20322.47589.872145.52237@fireball.kivinen.iki.fi> References: <20322.34474.737180.721238@fireball.kivinen.iki.fi> <20322.47589.872145.52237@fireball.kivinen.iki.fi> To: Tero Kivinen MIME-Version: 1.0 X-KeepSent: CF59508F:88AB4999-882579C3:001682DB; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Thu, 15 Mar 2012 20:19:27 -0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-16 12:22:49, Serialize complete at 2012-03-16 12:22:49 Content-Type: multipart/alternative; boundary="=_alternative 00180E02882579C3_=" X-MAIL: mse01.zte.com.cn q2G4MmBO099153 Cc: ipsec@ietf.org, ipsec-bounces@ietf.org Subject: Re: [IPsec] Comments to draft-so-ipsecme-ikev2-cpext-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 04:24:01 -0000 This is a multipart message in MIME format. --=_alternative 00180E02882579C3_= Content-Type: text/plain; charset="US-ASCII" Dear Tero, Thank you again for your patient to read through my long reply and to provide me your long reply. Please allow me to make a shorter reply to you this time to explain that why your proposal for defining API does NOT work, even though I am happy to further discuss with your email responses below another time. I presume that you are referring to the API to interface with IKE/IPSEC protocol (as you said, you are - As an OEM IPsec toolkit vendor I myself ), correct? Well, unfortunately, the network element which could use this API is the network element that deploys IKE/IPSEC, isn't it? FYI, within the mobile network, other than the SeGW communicates with the FAP, there is no other network element communicate with the SeGW via IPSec. Hence, may I ask you, how could this API can help? If you would like to suggest another protocol to add on an API, could you please clarify which particular protocol that you have in mind? Without a standardized interface between the SeGW with the other network element within the mobile network, I sincerely don't know how could you make it work? If you have a chance, please ask any network operator to give them two choices to solve their problem: (A) Modifying their existing network deployment with an added "new" interface with new protocol, or (B) Modifying an existing protocol with simple software change I am sure that the operator will be happy to give you a right answer - (B) it is.... Please have a great day. Cheers. Tricci Tero Kivinen Sent by: ipsec-bounces@ietf.org 03/15/2012 08:56 PM To tso@zteusa.com cc ipsec@ietf.org Subject Re: [IPsec] Comments to draft-so-ipsecme-ikev2-cpext-01 tso@zteusa.com writes: > Tricci > First of all, hoping that you and I have the common understanding > that, the portion of the network that deploys NAT is the fixed network and > its corresponding operator is NOT the same operator who runs the mobile > network. However, the FAP is attached to the fixed network with IPSec > tunnel established over the fixed network which assigns the private-IP to > the FAT and assigns the public-IP at the NAT. At the same time, the SeGW > is resided at the mobile network and has no direct interface towards the > fixed network nor standardized interface connecting to the mobile network > (even though it is part of the mobile network). SeGW is operated as the > firewall for the mobile network and has absolutely no mobile-standardized > interface to communicate with any of the mobile network element. That was how I understood it. > Tricci > It is very important to understand the actual femto deployment > today. Hoping that you can accept this. > > It seems to say: > > 1) SeGW has this information but it cannot pass it forward > Tricci > SeGW has no standardized interface to communicate any mobile > network element But as I commented most of the product do have non-standard methods of getting that information out, and getting standardized API on those is in the same order of difficulty than getting that configuration payload support added to those products. > 2) Reason being that there is no justification to require > FAP spcific changes in SeGW > Tricci > Yes. Because SeGW is off-the-shelf firewall product and is not > specific designed for Femto deployment. Which means they will not support this feature now, and most likely will not support it in the future, as the only use for it is in the femto deployment, and as you mentioned those are off-the-shelf products not specific to femto.... > 4) I.e. SeGW cannot be modified > Tricci > No, this is not what I have described. What I have explained is > that, SeGW cannot be modified to standardize a "specific" interface for a > specific mobile technology. However, we can modify the SeGW for the > standard protocol that it supports, e.g. IKEv2/IPSEC. Hoping that you can > understand the differences between interface vs. protocol. As an OEM IPsec toolkit vendor I myself would much rather add standardized api to give this information to the mobile network than start adding some hack about configuration payloads. Especially as the standardized api can be used by different deployments, but this configuration payload support is completely femto specific. Also we do have internal apis for getting that information already, so making suitable wrapper to export the apis as needed is not that much work. For example I think in our toolkit you can get the information you need by http statistics interface which has all the open IKEv2 SAs, their addresses, statistics etc. > and this draft tries to fix this by > > 1) Modify the SeGW to support completely new configuration payload > attribute > Tricci > IMHO opinion, configuration is designed to support different > types of configuration info as long as it is associated with the IKE-peer. > Extending an existing protocol which is designed to be extensible is far > more easier to modify an existing network component which is designed to > be off-the-shelf, and it is definitely far more simple than to change the > existing Femto network architecture just to support this "new" interface. All of those do require changes to the code, which means that after that it will nto be off-the-shelf product anymore. I see no reason to add that kind of femto specific hack to general IPsec implementation, especially as there are cleaner ways to do the same thing. Am still not sure what the FAP does with the IP-address and what kind of attacks can malicious FAP do, as if the information about the IP-address is reflected by the FAP and not from the SeGW, the information cannot be trusted. > > > 2) Send this Public IP + Port inside that configuration payload > attribute to FAP > Tricci > Yes. Please note that, as of today many IPSec deployment, > including over the Femto network, the configuration payload has already > been used by the SeGW to carry the IKE-client source inner-IP info > assigned by the DHCP server back to the IKE-client. Please check > RFC-5996. The different between my draft and this existing function is > to have the SeGW to carry the "NATed" IKE-client source outer-IP info back > to the IKE-client. DHCP server address is CONFIOGURATION parameter. IKE client source outer-IP infor is NOT. There is big fundamental difference there. Am not saying it cannot be done, I am saying it should not be done that way. > 3) FAP then probably sends it forward to other side of SeGW? > Tricci > Sorry, this is incorrect. The FAP has the standardized interface So FAP does NOT send that information to the mobile network, but only uses it himself? > towards the mobile network. Once the IPSec tunnel is established, all the > data and control info are carried within the IPSec-tunnel's payload. They > are totally transparent to the SeGW. SeGW is just a firewall pipe and it > cannot see inside the IPSec-tunnel's payload. The key point is that, FAP > has the standardized interface to its associated mobile network for a > given mobile technology and SeGW does not. Here you do seem to indicate that the FAP do send the information through the IPsec tunnel to the other side of SeGW, to the mobile network, which seems to indicate that my original statement was correct. How does the mobile network know that FAP does not fake or lie about the address it is sending? > Why do you think security gateway vendors would add support to this > very FAP specific feature, and not add the much more commonly usable > feature of getting information and statistics about the existing IKE > and IPsec SAs? > > Tricci > Sorry, I respectfully disagree with your assessment. Today > IKE/IPSec framework is missing a capability to allow the IKE-client to > learn about its NATed IP-address. Yes it is missing that feature. It is missing lots of other features (for example it does not know the current phase of the moon). That does not mean we need to add them all, and even when someone thinks it would be good idea. And even when someone writes documentation about that, it does not mean vendors actually implement them. > This problem is well understood and hence, there is another IETF > RFC-5389 that I have mentioned in my draft is trying to resolve this > issue. Unfortunately, the design of RFC-5389 cannot fit into the > Femto network architecture which in general involves two different > types of network operators who manage two different parts of the > network segment. That specific information has no meaning for the IPsec or IKE, so there is no point of adding it as part of IPsec/IKE. > Tricci > Hence, this NATed issue is generic, however, we don't have a > generic solution so far to solve this issue. And I believe that my draft > resolve this issue in a generic way. It happens Femto network > architecture is the one which breaks the solution offered by RFC-5389. I strongly disagree. I do not think this is generic issue, but I consider it very femto specific. > I think it would be much better to write document which documents what > kind of API is wanted from the SeGW to get this information (and that > document does not need to be IETF document). > Tricci > Again, please refer to the existing RFC-5996 for the > Configuration Payload support for carrying the source inner-ip of the > IKE-client from IKE-server (i.e. SeGW) back to the IKE-client. The idea > is nothing new. The different is just the inner vs. outer IP-addr. That's > all. I am very familiar with RFC5996, and there is big fundamental difference bithween the inner vs outer IP-address. Inner address is configuration information transmitted from the SGW to the client, and client itself uses it to create virtual interfaces etc. It is required for certain kinds of setups. Outer address has no use for IPsec or for IKE. It is not configuration information, but just one data readily available in the SGW, and something that is not useful for the client itself. In your cases the FAP client does not need the address, it is the network behind the security gateway which needs it. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00180E02882579C3_= Content-Type: text/html; charset="US-ASCII" Dear Tero,

Thank you again for your patient to read through my long reply and to provide me your long reply.

Please allow me to make a shorter reply to you this time to explain that why your proposal for defining API does NOT work, even though I am happy to further discuss with your email responses below another time.

I presume that you are referring to the API to interface with IKE/IPSEC protocol (as you said, you are - As an OEM IPsec toolkit vendor I myself  ), correct?  Well, unfortunately, the network element which could use this API is the network element that deploys IKE/IPSEC, isn't it?

FYI, within the mobile network, other than the SeGW communicates with the FAP, there is no other network element communicate with the SeGW via IPSec.  Hence, may I ask you, how could this API can help?

If you would like to suggest another protocol to add on an API, could you please clarify which particular protocol that you have in mind?

Without a standardized interface between the SeGW with the other network element within the mobile network, I sincerely don't know how could you make it work?    

If you have a chance, please ask any network operator to give them two choices to solve their problem:
(A) Modifying their existing network deployment with an added "new" interface with new protocol, or
(B) Modifying an existing protocol with simple software change

I am sure that the operator will be happy to give you a right answer - (B) it is....

Please have a great day.  Cheers.
Tricci





Tero Kivinen <kivinen@iki.fi>
Sent by: ipsec-bounces@ietf.org

03/15/2012 08:56 PM

To
tso@zteusa.com
cc
ipsec@ietf.org
Subject
Re: [IPsec] Comments to draft-so-ipsecme-ikev2-cpext-01





tso@zteusa.com writes:
> Tricci > First of all, hoping that you and I have the common understanding
> that, the portion of the network that deploys NAT is the fixed network and
> its corresponding operator is NOT the same operator who runs the mobile
> network.  However, the FAP is attached to the fixed network with IPSec
> tunnel established over the fixed network which assigns the private-IP to
> the FAT and assigns the public-IP at the NAT.   At the same time, the SeGW
> is resided at the mobile network and has no direct interface towards the
> fixed network nor standardized interface connecting to the mobile network
> (even though it is part of the mobile network).  SeGW is operated as the
> firewall for the mobile network and has absolutely no mobile-standardized
> interface to communicate with any of the mobile network element.

That was how I understood it.

> Tricci > It is very important to understand the actual femto deployment
> today. Hoping that you can accept this.  
>
> It seems to say:
>
> 1) SeGW has this information but it cannot pass it forward
> Tricci > SeGW has no standardized interface to communicate any mobile
> network element

But as I commented most of the product do have non-standard methods of
getting that information out, and getting standardized API on those is
in the same order of difficulty than getting that configuration
payload support added to those products.

> 2) Reason being that there is no justification to require
>    FAP spcific changes in SeGW
> Tricci > Yes. Because SeGW is off-the-shelf firewall product and is not
> specific designed for Femto deployment.

Which means they will not support this feature now, and most likely
will not support it in the future, as the only use for it is in the
femto deployment, and as you mentioned those are off-the-shelf
products not specific to femto....

> 4) I.e. SeGW cannot be modified
> Tricci > No, this is not what I have described. What I have explained is
> that, SeGW cannot be modified to standardize a "specific" interface for a
> specific mobile technology.  However, we can modify the SeGW for the
> standard protocol that it supports, e.g. IKEv2/IPSEC.  Hoping that you can
> understand the differences between interface vs. protocol.  

As an OEM IPsec toolkit vendor I myself would much rather add
standardized api to give this information to the mobile network than
start adding some hack about configuration payloads. Especially as the
standardized api can be used by different deployments, but this
configuration payload support is completely femto specific.

Also we do have internal apis for getting that information already, so
making suitable wrapper to export the apis as needed is not that much
work. For example I think in our toolkit you can get the information
you need by http statistics interface which has all the open IKEv2
SAs, their addresses, statistics etc.

> and this draft tries to fix this by
>
> 1) Modify the SeGW to support completely new configuration payload
>    attribute
> Tricci > IMHO opinion, configuration is designed to support different
> types of configuration info as long as it is associated with the IKE-peer.
>  Extending an existing protocol which is designed to be extensible is far
> more easier to modify an existing network component which is designed to
> be off-the-shelf, and it is definitely far more simple than to change the
> existing Femto network architecture just to support this "new" interface.  

All of those do require changes to the code, which means that after
that it will nto be off-the-shelf product anymore. I see no reason to
add that kind of femto specific hack to general IPsec implementation,
especially as there are cleaner ways to do the same thing.

Am still not sure what the FAP does with the IP-address and what kind
of attacks can malicious FAP do, as if the information about the
IP-address is reflected by the FAP and not from the SeGW, the
information cannot be trusted.

>
>
> 2) Send this Public IP + Port inside that configuration payload
>    attribute to FAP
> Tricci > Yes.  Please note that, as of today many IPSec deployment,
> including over the Femto network, the configuration payload has already
> been used by the SeGW to carry the IKE-client source inner-IP info
> assigned by the DHCP server back to the IKE-client.  Please check
> RFC-5996.   The different between my draft and this existing function is
> to have the SeGW to carry the "NATed" IKE-client source outer-IP info back
> to the IKE-client.

DHCP server address is CONFIOGURATION parameter. IKE client source
outer-IP infor is NOT. There is big fundamental difference there.

Am not saying it cannot be done, I am saying it should not be done
that way.

> 3) FAP then probably sends it forward to other side of SeGW?
> Tricci > Sorry, this is incorrect.  The FAP has the standardized interface

So FAP does NOT send that information to the mobile network, but only
uses it himself?

> towards the mobile network.  Once the IPSec tunnel is established, all the
> data and control info are carried within the IPSec-tunnel's payload.  They
> are totally transparent to the SeGW.  SeGW is just a firewall pipe and it
> cannot see inside the IPSec-tunnel's payload.  The key point is that, FAP
> has the standardized interface to its associated mobile network for a
> given mobile technology and SeGW does not.  

Here you do seem to indicate that the FAP do send the information
through the IPsec tunnel to the other side of SeGW, to the mobile
network, which seems to indicate that my original statement was
correct.

How does the mobile network know that FAP does not fake or lie about
the address it is sending?

> Why do you think security gateway vendors would add support to this
> very FAP specific feature, and not add the much more commonly usable
> feature of getting information and statistics about the existing IKE
> and IPsec SAs?
>
> Tricci > Sorry, I respectfully disagree with your assessment. Today
> IKE/IPSec framework is missing a capability to allow the IKE-client to
> learn about its NATed IP-address.

Yes it is missing that feature. It is missing lots of other features
(for example it does not know the current phase of the moon). That
does not mean we need to add them all, and even when someone thinks it
would be good idea. And even when someone writes documentation about
that, it does not mean vendors actually implement them.

> This problem is well understood and hence, there is another IETF
> RFC-5389 that I have mentioned in my draft is trying to resolve this
> issue. Unfortunately, the design of RFC-5389 cannot fit into the
> Femto network architecture which in general involves two different
> types of network operators who manage two different parts of the
> network segment.

That specific information has no meaning for the IPsec or IKE, so
there is no point of adding it as part of IPsec/IKE.

> Tricci > Hence, this NATed issue is generic, however, we don't have a
> generic solution so far to solve this issue.  And I believe that my draft
> resolve this issue in a generic way.  It happens Femto network
> architecture is the one which breaks the solution offered by RFC-5389.  

I strongly disagree. I do not think this is generic issue, but I
consider it very femto specific.

> I think it would be much better to write document which documents what
> kind of API is wanted from the SeGW to get this information (and that
> document does not need to be IETF document).
> Tricci > Again, please refer to the existing RFC-5996 for the
> Configuration Payload support for carrying the source inner-ip of the
> IKE-client from IKE-server (i.e. SeGW) back to the IKE-client.  The idea
> is nothing new.  The different is just the inner vs. outer IP-addr. That's
> all.

I am very familiar with RFC5996, and there is big fundamental
difference bithween the inner vs outer IP-address. Inner address is
configuration information transmitted from the SGW to the client, and
client itself uses it to create virtual interfaces etc. It is required
for certain kinds of setups.

Outer address has no use for IPsec or for IKE. It is not configuration
information, but just one data readily available in the SGW, and
something that is not useful for the client itself. In your cases the
FAP client does not need the address, it is the network behind the
security gateway which needs it.
--
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00180E02882579C3_=-- From jntupal@gmail.com Sun Mar 18 23:18:53 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBB321F84B8 for ; Sun, 18 Mar 2012 23:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nj+GOre8Pxa5 for ; Sun, 18 Mar 2012 23:18:52 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD5A21F84D9 for ; Sun, 18 Mar 2012 23:18:52 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so2926790wib.1 for ; Sun, 18 Mar 2012 23:18:51 -0700 (PDT) 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=sL0FSgPzFSxg2P6iF8pmMZ42unlZ3/wCo8oh2pZcHzM=; b=cHL1o7avW/PW2H3T1ICNRoA9CxEDs1hkkut1AZmLdXIJkFpoqgEomtmQzGq9JVzBS6 //Poa1NuD0NsE9YPbzwU8bNI89rAIr8hE54fv/1HBEbYjJ+Ed1kyQmX4BcHV+sQorDlS O6XqIOMK+oAzANo8W88l/xUJT3LDqYbEnqzHwmwGToe7TG/SfHD5UkIUSj+N3Pq0ucF4 XDvxy06oDyR/D0rLBz5k2A7rkgX2j9x6mNkhdYdRgu2o2rsYhe2bQmhZJ3pQpnbRidXq 7pF+9WBqgao2eu9i+NTOHihv8Ty0Vf4Lyt0CaM/0o7yIGY75ltfpkGAxNfMkkiKcTK2n Twyg== MIME-Version: 1.0 Received: by 10.180.73.143 with SMTP id l15mr16994946wiv.11.1332137931641; Sun, 18 Mar 2012 23:18:51 -0700 (PDT) Received: by 10.216.233.219 with HTTP; Sun, 18 Mar 2012 23:18:51 -0700 (PDT) In-Reply-To: <383BDA11-85C4-4090-AC39-CF4C85A2643D@vpnc.org> References: <19313.1331740138@marajade.sandelman.ca> <383BDA11-85C4-4090-AC39-CF4C85A2643D@vpnc.org> Date: Mon, 19 Mar 2012 11:48:51 +0530 Message-ID: From: yogendra pal To: Paul Hoffman Content-Type: multipart/alternative; boundary=f46d043c06bc35149404bb928826 Cc: IPsecme WG Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 06:18:53 -0000 --f46d043c06bc35149404bb928826 Content-Type: text/plain; charset=ISO-8859-1 Hi All, After going the draft version, I have suggestion to name this as: "Remote unknown mesh VPN", shortform: (RUK-MVPN) Thought behind this name (since Gateway can be configured with its local and let remote be unknown or 0.0.0.0 (wildcard), this will lead to large number of endpoints to connect to this Gateway) Thanks and Regards, Yogendra Pal Ericsson, India +91-9686202644 On Thu, Mar 15, 2012 at 12:50 AM, Paul Hoffman wrote: > On Mar 14, 2012, at 11:20 AM, Paul Wouters wrote: > > > Guess that's what I get for not fully reading the doument yet. > > A note to everyone: reading the document sooner rather than later will > help make our hour in Paris much more useful. > > > I assumed > > "P2P" actually meant "peer to peer" which kinda assumes unknown peers > > and on the fly configuration. > > > The term "peer" means no such thing. It means "two parties who communicate > without there being a client-server relationship". There are numerous other > IETF protocols that use "peer" in this context. > > --Paul Hoffman > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --f46d043c06bc35149404bb928826 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi All,

After going the draft version, I have suggestion= to name this as: "Remote unknown mesh VPN", shortform: (RUK-MVPN= )

Thought behind this name (since Gateway can be c= onfigured with its local and let remote be unknown or 0.0.0.0 (wildcard), t= his will lead to large
number of endpoints to connect to this Gateway)

Thanks and Regards,
Yogendra Pal
Ericsson, India
+91-968= 6202644

On Thu, Mar 15, 2012 at 12:50 AM,= Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Mar 14, 2012, at 11:20 = AM, Paul Wouters wrote:

> Guess that's what I get for not fully reading the doument yet.

A note to everyone: reading the document sooner rather than later wil= l help make our hour in Paris much more useful.

> I assumed
> "P2P" actually meant "peer to peer" which kinda as= sumes unknown peers
> and on the fly configuration.


The term "peer" means no such thing. It means "two par= ties who communicate without there being a client-server relationship"= . There are numerous other IETF protocols that use "peer" in this= context.

--Paul Hoffman

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




--f46d043c06bc35149404bb928826-- From ynir@checkpoint.com Mon Mar 19 00:57:28 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDDD21F8550 for ; Mon, 19 Mar 2012 00:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.491 X-Spam-Level: X-Spam-Status: No, score=-10.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjIal3xfMYcj for ; Mon, 19 Mar 2012 00:57:28 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D947421F853E for ; Mon, 19 Mar 2012 00:57:20 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2J7vIA5018070; Mon, 19 Mar 2012 09:57:18 +0200 X-CheckPoint: {4F66E67B-0-1B221DC2-5FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 19 Mar 2012 09:57:17 +0200 From: Yoav Nir To: IPsecme WG , Paul Hoffman Date: Mon, 19 Mar 2012 09:57:16 +0200 Thread-Topic: [IPsec] P2P VPN draft UNCLASSIFIED Thread-Index: Ac0FmDCrtISyB5vkTRawGtDgN4yl/wADUeug Message-ID: <006FEB08D9C6444AB014105C9AEB133F017A75325A1B@il-ex01.ad.checkpoint.com> References: <19313.1331740138@marajade.sandelman.ca> <383BDA11-85C4-4090-AC39-CF4C85A2643D@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 07:57:28 -0000 As Tero pointed out, some of the use cases don't end up in a full mesh, bec= ause sometimes administrators really want a trunk, so the end result could = be a mesh among nodes in the same organization, and a trunk to another. May= be even a partial mesh (with "secondary nodes" behind particularly bad NAT = devices connecting to one of many "primary nodes") So perhaps the name should not include the word "mesh". How about "dynamic = discovery VPN" (DD-VPN)? From mcr@sandelman.ca Mon Mar 19 07:36:09 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA73121F8814 for ; Mon, 19 Mar 2012 07:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0GaQ9YAT0w0 for ; Mon, 19 Mar 2012 07:36:09 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6705421F87E0 for ; Mon, 19 Mar 2012 07:36:09 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id BEF63344E5; Mon, 19 Mar 2012 10:33:30 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 5AB36983B9; Mon, 19 Mar 2012 10:36:08 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 4F57C983B8; Mon, 19 Mar 2012 10:36:08 -0400 (EDT) From: Michael Richardson To: Yoav Nir In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F017A75325A1B@il-ex01.ad.checkpoint.com> References: <19313.1331740138@marajade.sandelman.ca> <383BDA11-85C4-4090-AC39-CF4C85A2643D@vpnc.org> <006FEB08D9C6444AB014105C9AEB133F017A75325A1B@il-ex01.ad.checkpoint.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Mon, 19 Mar 2012 10:36:08 -0400 Message-ID: <21191.1332167768@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:36:10 -0000 >>>>> "Yoav" == Yoav Nir writes: Yoav> As Tero pointed out, some of the use cases don't end up in a Yoav> full mesh, because sometimes administrators really want a Yoav> trunk, so the end result could be a mesh among nodes in the Yoav> same organization, and a trunk to another. Maybe even a Yoav> partial mesh (with "secondary nodes" behind particularly bad Yoav> NAT devices connecting to one of many "primary nodes") I agree. Yoav> So perhaps the name should not include the word "mesh". How Yoav> about "dynamic discovery VPN" (DD-VPN)? I offer: On-Demand Dynamic VPN = ODD-VPN. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mark.boltz@stonesoft.com Mon Mar 19 11:12:08 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EDE21F88C0 for ; Mon, 19 Mar 2012 11:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efQKA30VaSZ9 for ; Mon, 19 Mar 2012 11:12:08 -0700 (PDT) Received: from hki-smtp-1a.stonesoft.com (hki-smtp-1a.stonesoft.com [192.89.38.178]) by ietfa.amsl.com (Postfix) with ESMTP id A4FC921F88BF for ; Mon, 19 Mar 2012 11:12:07 -0700 (PDT) Received: from hki-smtp-1a.stonesoft.com (localhost.localdomain [127.0.0.1]) by localhost.stonesoft.com (Postfix) with ESMTP id 5038134813A for ; Mon, 19 Mar 2012 20:12:03 +0200 (EET) Received: from outlook.stonesoft.com (unknown [172.16.40.22]) by hki-smtp-1a.stonesoft.com (Postfix) with ESMTP id 43C39348137 for ; Mon, 19 Mar 2012 20:12:03 +0200 (EET) Received: from HKI-EXC-1.stonesoft.com ([fe80::b914:799e:5fe4:7c73]) by HKI-EXC-2.stonesoft.com ([fe80::400e:df46:3369:4741%14]) with mapi id 14.01.0355.002; Mon, 19 Mar 2012 20:12:04 +0200 From: Mark Boltz To: IPsecme WG Thread-Topic: [IPsec] P2P VPN draft UNCLASSIFIED Thread-Index: AQHNAJs8UxRHtLTEIkuwZ7rof2uRj5ZnO98AgAFP2gCAADDWgIABFKMAgAAqXoCAABCngIAHAVmAgAAbfwCAAG9xAIAAPFSA Date: Mon, 19 Mar 2012 18:12:04 +0000 Message-ID: References: <19313.1331740138@marajade.sandelman.ca> <383BDA11-85C4-4090-AC39-CF4C85A2643D@vpnc.org> <006FEB08D9C6444AB014105C9AEB133F017A75325A1B@il-ex01.ad.checkpoint.com> <21191.1332167768@marajade.sandelman.ca> In-Reply-To: <21191.1332167768@marajade.sandelman.ca> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.0.68] Content-Type: multipart/alternative; boundary="_000_BD339637D1144332ACACFE9C2A455860stonesoftcom_" MIME-Version: 1.0 Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 18:12:08 -0000 --_000_BD339637D1144332ACACFE9C2A455860stonesoftcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree that the meshing becomes messy. And thus, Yoav's comment on partial= mesh and such is valid. Since the topology is, in my view, based on the use cases and the problem s= tatement as I have understood them, a somewhat nebulous thing, I would offe= r up a very simple term for the goal: ad hoc VPN As that would thus mean a VPN that is "formed, arranged, or done for a part= icular purpose only". I will endeavor to have more commentary on the draft later this evening. -- Mark Boltz, CISSP, CISA, NSA-IEM, CSGI Director, Federal and Mid-Atlantic e: mark.boltz@stonesoft.com e: federal@s= tonesoft.com p: 866.869.4075 c: 571.246.2233 o: 202.434.8963 f: 703.997.4759 w: http://www.stonesoft.com 1200 G St. NW, Suite 800 Washington, DC 20005-6705 Stonesoft: Network Security. Simplified. On Mar 19, 2012, at 10:36 AM, Michael Richardson wrote: "Yoav" =3D=3D Yoav Nir > wr= ites: Yoav> As Tero pointed out, some of the use cases don't end up in a Yoav> full mesh, because sometimes administrators really want a Yoav> trunk, so the end result could be a mesh among nodes in the Yoav> same organization, and a trunk to another. Maybe even a Yoav> partial mesh (with "secondary nodes" behind particularly bad Yoav> NAT devices connecting to one of many "primary nodes") I agree. Yoav> So perhaps the name should not include the word "mesh". How Yoav> about "dynamic discovery VPN" (DD-VPN)? I offer: On-Demand Dynamic VPN =3D ODD-VPN. -- ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.= sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_BD339637D1144332ACACFE9C2A455860stonesoftcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8148357A14A3DF4DAE016A08A1A5ED8A@stonesoft.com> Content-Transfer-Encoding: quoted-printable I agree that the meshing becomes messy. And thus, Yoav's comment on partial= mesh and such is valid.

Since the topology is, in my view, based on the use cases and the prob= lem statement as I have understood them, a somewhat nebulous thing, I would= offer up a very simple term for the goal:

     ad hoc VPN

As that would thus mean a VPN that is "formed, arranged, or done = for a particular purpose only". 

I will endeavor to have more commentary on the draft later this evenin= g.

--
Mark Boltz, CISSP, CISA, NSA-IEM, CSGI
Director, Federal and Mid-Atlantic
e: mark.boltz@stonesoft.co= m   e: fed= eral@stonesoft.com 
p: 866.869.4075           = ;    c: 571.246.2233
o: 202.434.8963           = ;    f: 703.997.4759
w: http://www.stonesoft.com<= br>
1200 G St. NW, Suite 800
Washington, DC 20005-6705

Stonesoft: Network Security. Simplified.

On Mar 19, 2012, at 10:36 AM, Michael Richardson wrote:


"Yoav" =3D=3D Yoav Nir <ynir@checkpoint.com> writes:
   Yoav> As Tero pointed out, some of the use cases don't= end up in a
   Yoav> full mesh, because sometimes administrators real= ly want a
   Yoav> trunk, so the end result could be a mesh among n= odes in the
   Yoav> same organization, and a trunk to another. Maybe= even a
   Yoav> partial mesh (with "secondary nodes" b= ehind particularly bad
   Yoav> NAT devices connecting to one of many "prim= ary nodes")

I agree.

   Yoav> So perhaps the name should not include the word = "mesh". How
   Yoav> about "dynamic discovery VPN" (DD-VPN)= ?

I offer:
 On-Demand Dynamic VPN  =3D ODD-VPN.

--
]       He who is tired of Weird Al is tired = of life!           | &nbs= p;firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON &nbs= p;  |net architect[
] mcr@sandelman.ottawa.on.ca<= /a> http://www.sandelman.ottawa.on.ca/ |device driver[
  Kyoto Plus: watch the video <http://www.youtube.com/watch?v=3Dkzx1ycLXQSE&= gt;
  = ;            th= en sign the petition.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--_000_BD339637D1144332ACACFE9C2A455860stonesoftcom_-- From shanna@juniper.net Mon Mar 19 11:33:22 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7329521F88D5 for ; Mon, 19 Mar 2012 11:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVN17ZanQBZy for ; Mon, 19 Mar 2012 11:33:20 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id E1E5221F88AA for ; Mon, 19 Mar 2012 11:33:19 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKT2d77AAl0J3oUOh8jPSalGAx1lFKbd/n@postini.com; Mon, 19 Mar 2012 11:33:19 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 19 Mar 2012 11:32:17 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 19 Mar 2012 11:32:17 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 19 Mar 2012 14:32:17 -0400 From: Stephen Hanna To: Mark Boltz , IPsecme WG Date: Mon, 19 Mar 2012 14:32:16 -0400 Thread-Topic: [IPsec] P2P VPN draft UNCLASSIFIED Thread-Index: AQHNAJs8UxRHtLTEIkuwZ7rof2uRj5ZnO98AgAFP2gCAADDWgIABFKMAgAAqXoCAABCngIAHAVmAgAAbfwCAAG9xAIAAPFSAgAAm5ZA= Message-ID: References: <19313.1331740138@marajade.sandelman.ca> <383BDA11-85C4-4090-AC39-CF4C85A2643D@vpnc.org> <006FEB08D9C6444AB014105C9AEB133F017A75325A1B@il-ex01.ad.checkpoint.com> <21191.1332167768@marajade.sandelman.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AC6674AB7BC78549BB231821ABF7A9AEB82D8D6ADDEMBX01WFjnprn_" MIME-Version: 1.0 Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 18:33:23 -0000 --_000_AC6674AB7BC78549BB231821ABF7A9AEB82D8D6ADDEMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm concerned that people expect "ad hoc VPN" to include VPN connections be= tween endpoints with no prior trust relationship. Thanks, Steve From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of M= ark Boltz Sent: Monday, March 19, 2012 2:12 PM To: IPsecme WG Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED I agree that the meshing becomes messy. And thus, Yoav's comment on partial= mesh and such is valid. Since the topology is, in my view, based on the use cases and the problem s= tatement as I have understood them, a somewhat nebulous thing, I would offe= r up a very simple term for the goal: ad hoc VPN As that would thus mean a VPN that is "formed, arranged, or done for a part= icular purpose only". I will endeavor to have more commentary on the draft later this evening. -- Mark Boltz, CISSP, CISA, NSA-IEM, CSGI Director, Federal and Mid-Atlantic e: mark.boltz@stonesoft.com e: federal@s= tonesoft.com p: 866.869.4075 c: 571.246.2233 o: 202.434.8963 f: 703.997.4759 w: http://www.stonesoft.com 1200 G St. NW, Suite 800 Washington, DC 20005-6705 Stonesoft: Network Security. Simplified. On Mar 19, 2012, at 10:36 AM, Michael Richardson wrote: "Yoav" =3D=3D Yoav Nir > wr= ites: Yoav> As Tero pointed out, some of the use cases don't end up in a Yoav> full mesh, because sometimes administrators really want a Yoav> trunk, so the end result could be a mesh among nodes in the Yoav> same organization, and a trunk to another. Maybe even a Yoav> partial mesh (with "secondary nodes" behind particularly bad Yoav> NAT devices connecting to one of many "primary nodes") I agree. Yoav> So perhaps the name should not include the word "mesh". How Yoav> about "dynamic discovery VPN" (DD-VPN)? I offer: On-Demand Dynamic VPN =3D ODD-VPN. -- ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.= sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_AC6674AB7BC78549BB231821ABF7A9AEB82D8D6ADDEMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m= concerned that people expect “ad hoc VPN” to include VPN conne= ctions between endpoints with no prior trust relationship.

 

Thanks,

 

Steve=

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces= @ietf.org] On Behalf Of Mark Boltz
Sent: Monday, March 19,= 2012 2:12 PM
To: IPsecme WG
Subject: Re: [IPsec] P2P V= PN draft UNCLASSIFIED

 

I agree that the meshing becomes= messy. And thus, Yoav's comment on partial mesh and such is valid.

 

Since the topology is, in my view, based on the use cases and = the problem statement as I have understood them, a somewhat nebulous thing,= I would offer up a very simple term for the goal:

 

=      ad hoc VPN

 

As that would thus m= ean a VPN that is "formed, arranged, or done for a particular purpose = only". 

 =

I will endeavor to have more comm= entary on the draft later this evening.

 

--
Mark Boltz, CISSP, CISA, NSA-IEM, CSGI
Director, Federal and= Mid-Atlantic
e: mark.b= oltz@stonesoft.com   e: federal@stonesoft.com 
p: 866.869.4075  &nbs= p;            c= : 571.246.2233
o: 202.434.8963        = ;       f: 703.997.4759
w: http://www.stonesoft.com

1200 G= St. NW, Suite 800
Washington, DC 20005-6705

Stonesoft: Network S= ecurity. Simplified.

<= o:p> 

On Mar 19, 2012, at 10:3= 6 AM, Michael Richardson wrote:




"Yoav" =3D=3D Yoav Nir <ynir@checkpoint.com> writes:<= /p>

   Yoav> As Tero pointed out, some of the use cases don'= t end up in a
   Yoav> full mesh, because sometimes ad= ministrators really want a
   Yoav> trunk, so the end = result could be a mesh among nodes in the
   Yoav> sam= e organization, and a trunk to another. Maybe even a
   Y= oav> partial mesh (with "secondary nodes" behind particularly = bad
   Yoav> NAT devices connecting to one of many &qu= ot;primary nodes")

I agree.

   Yoav> S= o perhaps the name should not include the word "mesh". How
&nb= sp;  Yoav> about "dynamic discovery VPN" (DD-VPN)?
I offer:
 On-Demand Dynamic VPN  =3D ODD-VPN.

-- =
]       He who is tired of Weird Al is ti= red of life!           | =  firewalls  [
]   Michael Richardson, Sandelman Soft= ware Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ = |device driver[
  Kyoto Plus: watch the video <http://www.youtube.com/watch?v= =3Dkzx1ycLXQSE>
        &= nbsp;     then sign the petition.
____________= ___________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec=

 

= --_000_AC6674AB7BC78549BB231821ABF7A9AEB82D8D6ADDEMBX01WFjnprn_-- From mark.boltz@stonesoft.com Mon Mar 19 11:38:08 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF3421F8869 for ; Mon, 19 Mar 2012 11:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08dQsYBqZFCb for ; Mon, 19 Mar 2012 11:38:07 -0700 (PDT) Received: from hki-smtp-1a.stonesoft.com (hki-smtp-1a.stonesoft.com [192.89.38.178]) by ietfa.amsl.com (Postfix) with ESMTP id 27F2021F8842 for ; Mon, 19 Mar 2012 11:38:06 -0700 (PDT) Received: from hki-smtp-1a.stonesoft.com (localhost.localdomain [127.0.0.1]) by localhost.stonesoft.com (Postfix) with ESMTP id 5813E348137 for ; Mon, 19 Mar 2012 20:38:02 +0200 (EET) Received: from outlook.stonesoft.com (unknown [172.16.40.22]) by hki-smtp-1a.stonesoft.com (Postfix) with ESMTP id 4ACDC34812E for ; Mon, 19 Mar 2012 20:38:02 +0200 (EET) Received: from HKI-EXC-1.stonesoft.com ([fe80::b914:799e:5fe4:7c73]) by HKI-EXC-2.stonesoft.com ([fe80::400e:df46:3369:4741%14]) with mapi id 14.01.0355.002; Mon, 19 Mar 2012 20:38:04 +0200 From: Mark Boltz To: IPsecme WG Thread-Topic: [IPsec] P2P VPN draft UNCLASSIFIED Thread-Index: AQHNAJs8UxRHtLTEIkuwZ7rof2uRj5ZnO98AgAFP2gCAADDWgIABFKMAgAAqXoCAABCngIAHAVmAgAAbfwCAAG9xAIAAPFSAgAAm5ZD//+BdAA== Date: Mon, 19 Mar 2012 18:38:03 +0000 Message-ID: <2389BE9A-B50D-486A-B9F5-3EFE213C1B01@stonesoft.com> References: <19313.1331740138@marajade.sandelman.ca> <383BDA11-85C4-4090-AC39-CF4C85A2643D@vpnc.org> <006FEB08D9C6444AB014105C9AEB133F017A75325A1B@il-ex01.ad.checkpoint.com> <21191.1332167768@marajade.sandelman.ca> In-Reply-To: Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.0.68] Content-Type: multipart/alternative; boundary="_000_2389BE9AB50D486AB9F53EFE213C1B01stonesoftcom_" MIME-Version: 1.0 Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 18:38:08 -0000 --_000_2389BE9AB50D486AB9F53EFE213C1B01stonesoftcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Interesting. I always considered the requirement of a trust relationship of= some kind an inherent part of "VPN" (of any kind, SSL, IPsec or otherwise)= , and assumed most people did. In no part is trust suggested or otherwise in the Latin "ad hoc", so it is = technically an incorrect expectation. But if the group feels that somehow the simplest correct term is too confus= ing we can try for something else. :-) -- Mark Boltz, CISSP, CISA, NSA-IEM, CSGI Director, Federal and Mid-Atlantic e: mark.boltz@stonesoft.com e: federal@s= tonesoft.com p: 866.869.4075 c: 571.246.2233 o: 202.434.8963 f: 703.997.4759 w: http://www.stonesoft.com 1200 G St. NW, Suite 800 Washington, DC 20005-6705 Stonesoft: Network Security. Simplified. On Mar 19, 2012, at 2:32 PM, Stephen Hanna wrote: I=92m concerned that people expect =93ad hoc VPN=94 to include VPN connecti= ons between endpoints with no prior trust relationship. Thanks, Steve From: ipsec-bounces@ietf.org [mailto:ipsec-b= ounces@ietf.org] On Behalf Of Mark Boltz Sent: Monday, March 19, 2012 2:12 PM To: IPsecme WG Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED I agree that the meshing becomes messy. And thus, Yoav's comment on partial= mesh and such is valid. Since the topology is, in my view, based on the use cases and the problem s= tatement as I have understood them, a somewhat nebulous thing, I would offe= r up a very simple term for the goal: ad hoc VPN As that would thus mean a VPN that is "formed, arranged, or done for a part= icular purpose only". I will endeavor to have more commentary on the draft later this evening. -- Mark Boltz, CISSP, CISA, NSA-IEM, CSGI Director, Federal and Mid-Atlantic e: mark.boltz@stonesoft.com e: federal@s= tonesoft.com p: 866.869.4075 c: 571.246.2233 o: 202.434.8963 f: 703.997.4759 w: http://www.stonesoft.com 1200 G St. NW, Suite 800 Washington, DC 20005-6705 Stonesoft: Network Security. Simplified. On Mar 19, 2012, at 10:36 AM, Michael Richardson wrote: "Yoav" =3D=3D Yoav Nir > wr= ites: Yoav> As Tero pointed out, some of the use cases don't end up in a Yoav> full mesh, because sometimes administrators really want a Yoav> trunk, so the end result could be a mesh among nodes in the Yoav> same organization, and a trunk to another. Maybe even a Yoav> partial mesh (with "secondary nodes" behind particularly bad Yoav> NAT devices connecting to one of many "primary nodes") I agree. Yoav> So perhaps the name should not include the word "mesh". How Yoav> about "dynamic discovery VPN" (DD-VPN)? I offer: On-Demand Dynamic VPN =3D ODD-VPN. -- ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.= sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_2389BE9AB50D486AB9F53EFE213C1B01stonesoftcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <88DFF4AE32B7C14DB88EC20A93365EE2@stonesoft.com> Content-Transfer-Encoding: quoted-printable Interesting. I always considered the requirement of a trust relationship of= some kind an inherent part of "VPN" (of any kind, SSL, IPsec or = otherwise), and assumed most people did. 

In no part is trust suggested or otherwise in the Latin "ad hoc&q= uot;, so it is technically an incorrect expectation.

But if the group feels that somehow the simplest correct term is too c= onfusing we can try for something else. :-)

--
Mark Boltz, CISSP, CISA, NSA-IEM, CSGI
Director, Federal and Mid-Atlantic
e: mark.boltz@stonesoft.co= m   e: fed= eral@stonesoft.com 
p: 866.869.4075           = ;    c: 571.246.2233
o: 202.434.8963           = ;    f: 703.997.4759
w: http://www.stonesoft.com<= br>
1200 G St. NW, Suite 800
Washington, DC 20005-6705

Stonesoft: Network Security. Simplified.

On Mar 19, 2012, at 2:32 PM, Stephen Hanna wrote:

I=92m concerned that people expect =93ad hoc VPN=94 to in= clude VPN connections between endpoints with no prior trust relationship.
 
Thanks,
 
Steve
 
From:=  ip= sec-bounces@ietf.org = [mailto:ipsec-bounces@ietf.org] = On Behalf Of Mark Boltz=
Sent: Monday, Marc= h 19, 2012 2:12 PM
To: IPsecme WG
Subject: Re: [IPse= c] P2P VPN draft UNCLASSIFIED
 
I agree that the meshing becomes messy. And thus, Yoav's comment on partial= mesh and such is valid.
 
Since the topology is, in my view, based on the use cases and the problem s= tatement as I have understood them, a somewhat nebulous thing, I would offe= r up a very simple term for the goal:
 
     ad hoc VPN
 
As that would thus mean a VPN that is "formed, arranged, or done for a= particular purpose only". 
 
I will endeavor to have more commentary on the draft later this evening.
 
--
Mark Boltz, CISSP, CISA, NSA-IEM, CSGI
Director, Federal and Mid-Atlantic
e: mark.boltz@stonesoft.com   = e: federal@stonesoft.com 
p: 866.869.4075           = ;    c: 571.246.2233
o: 202.434.8963           = ;    f: 703.997.4759
w: http://www.stonesoft.com

1200 G St. NW, Suite 800
Washington, DC 20005-6705

Stonesoft: Network Security. Simplified.
 
On Mar 19, 2012, at 10:36 AM, Michael Richardson wrote:




"Yoav" =3D=3D Yoav Nir <ynir@checkpoint.com> writes:
   Yoav> As Tero pointed out, some of the use cases don't= end up in a
   Yoav> full mesh, because sometimes administrators real= ly want a
   Yoav> trunk, so the end result could be a mesh among n= odes in the
   Yoav> same organization, and a trunk to another. Maybe= even a
   Yoav> partial mesh (with "secondary nodes" b= ehind particularly bad
   Yoav> NAT devices connecting to one of many "prim= ary nodes")

I agree.

   Yoav> So perhaps the name should not include the word = "mesh". How
   Yoav> about "dynamic discovery VPN" (DD-VPN)= ?

I offer:
 On-Demand Dynamic VPN  =3D ODD-VPN.

-- 
]       He who is tired of Weird Al is tired = of life!           | &nbs= p;firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON &nbs= p;  |net architect[
] = mcr@sandelman.ottawa.on.ca <= /span>http://www.sandelman.ottawa.on.ca/ |device driver[
  Kyoto Plus: watch the video < = ;
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipse= c
 

--_000_2389BE9AB50D486AB9F53EFE213C1B01stonesoftcom_-- From paul.hoffman@vpnc.org Mon Mar 19 13:45:44 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066A821F876D for ; Mon, 19 Mar 2012 13:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.682 X-Spam-Level: X-Spam-Status: No, score=-102.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+SoCrGrO-tM for ; Mon, 19 Mar 2012 13:45:43 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9DC21F875B for ; Mon, 19 Mar 2012 13:45:43 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2JKjecT077714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Mar 2012 13:45:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Paul Hoffman In-Reply-To: <2389BE9A-B50D-486A-B9F5-3EFE213C1B01@stonesoft.com> Date: Mon, 19 Mar 2012 13:45:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <201317DB-F8D9-40F3-A527-867812E0E7F4@vpnc.org> References: <19313.1331740138@marajade.sandelman.ca> <383BDA11-85C4-4090-AC39-CF4C85A2643D@vpnc.org> <006FEB08D9C6444AB014105C9AEB133F017A75325A1B@il-ex01.ad.checkpoint.com> <21191.1332167768@marajade.sandelman.ca> <2389BE9A-B50D-486A-B9F5-3EFE213C1B01@stonesoft.com> To: Mark Boltz X-Mailer: Apple Mail (2.1257) Cc: IPsecme WG Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 20:45:44 -0000 On Mar 19, 2012, at 11:38 AM, Mark Boltz wrote: > Interesting. I always considered the requirement of a trust = relationship of some kind an inherent part of "VPN" (of any kind, SSL, = IPsec or otherwise), and assumed most people did.=20 Mark, meet Michael Richardson and friends. :-) > In no part is trust suggested or otherwise in the Latin "ad hoc", so = it is technically an incorrect expectation. >=20 > But if the group feels that somehow the simplest correct term is too = confusing we can try for something else. :-) See earlier in this thread on opportunistic VPNs, which this is not. --Paul Hoffman From mcr@sandelman.ca Mon Mar 19 18:40:37 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A976121E8027 for ; Mon, 19 Mar 2012 18:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.805 X-Spam-Level: X-Spam-Status: No, score=-2.805 tagged_above=-999 required=5 tests=[AWL=1.149, BAYES_00=-2.599, GB_I_LETTER=-2, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5UWWofodaOs for ; Mon, 19 Mar 2012 18:40:36 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id B3C2521E8019 for ; Mon, 19 Mar 2012 18:40:36 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 48DB7343DF; Mon, 19 Mar 2012 21:37:56 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 8E4D1983B9; Mon, 19 Mar 2012 21:40:33 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 853FD983B8; Mon, 19 Mar 2012 21:40:33 -0400 (EDT) From: Michael Richardson To: Paul Hoffman In-Reply-To: <201317DB-F8D9-40F3-A527-867812E0E7F4@vpnc.org> References: <19313.1331740138@marajade.sandelman.ca> <383BDA11-85C4-4090-AC39-CF4C85A2643D@vpnc.org> <006FEB08D9C6444AB014105C9AEB133F017A75325A1B@il-ex01.ad.checkpoint.com> <21191.1332167768@marajade.sandelman.ca> <2389BE9A-B50D-486A-B9F5-3EFE213C1B01@stonesoft.com> <201317DB-F8D9-40F3-A527-867812E0E7F4@vpnc.org> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Mon, 19 Mar 2012 21:40:33 -0400 Message-ID: <19353.1332207633@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: IPsecme WG , Mark Boltz Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 01:40:37 -0000 <#part sign=pgpmime> >>>>> "Paul" == Paul Hoffman writes: >> Interesting. I always considered the requirement of a trust >> relationship of some kind an inherent part of "VPN" (of any kind, >> SSL, IPsec or otherwise), and assumed most people did. Paul> Mark, meet Michael Richardson and friends. :-) Why? A VPN implies trust, and you leverage it. An RFC4322 OE system provides privacy, and we go out of our way to distinguish it from trust. The letters VPN occur three times in RFC4322, and each time to help say, "unlike.." RFC4322 tells you how much to trust the packets (not very much), because you know from which anchor you got the "trust". If your trust anchor is stronger, then you can do more things with them. What I've said repeatedly is that a system that implements RFC4322 OE likely already has all the mechanisms to implement P2PVPN. Here is a section. We are clearly building a configured tunnel. The question is how does the configuration occur. 1.2. Encryption Regimes To aid in understanding the relationship between security processing and IPsec, we divide policies controlling network traffic into four categories. The traffic is categorized by destination address using longest prefix match. Therefore, each category is enumerated by a set of network prefixes. The categories are mutually exclusive; a particular prefix should only occur in one category. * Deny: network prefixes to which traffic is always forbidden. * Permit: network prefixes to which traffic in the clear is permitted. * Opportunistic tunnel: network prefixes to which traffic is encrypted if possible, when it otherwise might be sent in the clear. * Configured tunnel: network prefixes to which traffic must be encrypted, and traffic in the clear is never permitted. A traditionally defined Virtual Private Network (VPN) is a form of configured tunnel. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From shanna@juniper.net Tue Mar 20 18:26:14 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C645621F8567 for ; Tue, 20 Mar 2012 18:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdvYT7jvd5A1 for ; Tue, 20 Mar 2012 18:26:13 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id A31CD21F8559 for ; Tue, 20 Mar 2012 18:26:13 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKT2kuNajlWD3McX4uwkAHGrxT8flhDYfk@postini.com; Tue, 20 Mar 2012 18:26:13 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 20 Mar 2012 18:25:58 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 20 Mar 2012 21:25:57 -0400 From: Stephen Hanna To: IPsecme WG Date: Tue, 20 Mar 2012 21:25:56 -0400 Thread-Topic: [ipsecme] #210: What should we call this effort? Thread-Index: Ac0G6wIGwjiV6+lcSnKtps4ECf33uwAFjxqQ Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [IPsec] [ipsecme] #210: What should we call this effort? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 01:26:14 -0000 SGVyZSdzIHRoZSBmaXJzdCBpc3N1ZS4gU28gZmFyLCBpdCBoYXMgYmVlbiB0aGUgbW9zdA0KY29u dGVudGlvdXMgb25lISBJbnRlcmVzdGluZyB0aGF0IGl0J3MgdGhlIGxlYXN0DQp0ZWNobmljYWwg aXNzdWUuIEhtbW1tLg0KDQpBbnl3YXksIGlmIHlvdSdyZSBub3QgaGFwcHkgd2l0aCB0aGUgcHJv cG9zZWQgcmVzb2x1dGlvbiwNCnBsZWFzZSBzdWdnZXN0IGFub3RoZXIuIEFuZCBpZiB5b3Ugc3Vw cG9ydCB0aGlzIGlkZWEsDQpwbGVhc2Ugc2F5IHNvLg0KDQpUaGFua3MsDQoNClN0ZXZlDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpcHNlY21lIGlzc3VlIHRyYWNrZXIgW21h aWx0bzp0cmFjQHRvb2xzLmlldGYub3JnXSANClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDIwLCAyMDEy IDY6NDQgUE0NClRvOiB5YXJvbmYuaWV0ZkBnbWFpbC5jb207IGRyYWZ0LWlldGYtaXBzZWNtZS1w MnAtdnBuLXByb2JsZW1AdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFtpcHNlY21lXSAjMjEwOiBX aGF0IHNob3VsZCB3ZSBjYWxsIHRoaXMgZWZmb3J0Pw0KDQojMjEwOiBXaGF0IHNob3VsZCB3ZSBj YWxsIHRoaXMgZWZmb3J0Pw0KDQogTWFueSBuYW1lcyB3ZXJlIHN1Z2dlc3RlZCBidXQgbm8gY29u c2Vuc3VzIGhhcyBlbWVyZ2VkLiBUaGUgbW9zdCBwb3B1bGFyDQogY2FuZGlkYXRlIHNvIGZhciBp cyAiQXV0byBNZXNoIFZQTiIuDQoNCiBTdWdnZXN0ZWQgUmVzb2x1dGlvbjogQ2hvb3NlIEF1dG8g TWVzaCBWUE4gdW5sZXNzIGFub3RoZXIgbW9yZSBwb3B1bGFyDQogbmFtZSBlbWVyZ2VzIG9uIHRo ZSBlbWFpbCBsaXN0IGJ5IHRoZSBlbmQgb2YgSUVURiA4My4NCg0KLS0gDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCiBSZXBvcnRlcjogICAgICAgICAgICAgICB8ICAgICAgT3duZXI6ICBkcmFmdC1pZXRm LWlwc2VjbWUtcDJwLXZwbi0NCiAgeWFyb25mLmlldGZA4oCmICAgICAgICAgIHwgIHByb2JsZW1A 4oCmDQogICAgIFR5cGU6ICBkZWZlY3QgICAgICAgfCAgICAgU3RhdHVzOiAgbmV3DQogUHJpb3Jp dHk6ICBub3JtYWwgICAgICAgfCAgTWlsZXN0b25lOg0KQ29tcG9uZW50OiAgcDJwLXZwbi0gICAg IHwgICBTZXZlcml0eTogIC0NCiAgcHJvYmxlbSAgICAgICAgICAgICAgICB8DQogS2V5d29yZHM6 ICAgICAgICAgICAgICAgfA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRpY2tldCBVUkw6IDxodHRw Oi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9pcHNlY21lL3RyYWMvdGlja2V0LzIxMD4NCmlwc2Vj bWUgPGh0dHA6Ly90b29scy5pZXRmLm9yZy9pcHNlY21lLz4NCg0K From shanna@juniper.net Tue Mar 20 18:26:48 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BAA21F8576 for ; Tue, 20 Mar 2012 18:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjuLcpqDL0WI for ; Tue, 20 Mar 2012 18:26:47 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA6421F8559 for ; Tue, 20 Mar 2012 18:26:47 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKT2kuVt1AOhTF97NYWvfYQbEuV214cead@postini.com; Tue, 20 Mar 2012 18:26:47 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 20 Mar 2012 18:23:10 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 20 Mar 2012 18:23:10 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 20 Mar 2012 21:23:09 -0400 From: Stephen Hanna To: IPsecme WG Date: Tue, 20 Mar 2012 21:23:08 -0400 Thread-Topic: First Batch of P2P VPN Issues Thread-Index: Ac0HASwtgODqAeOuSEa5oM1VWZ1k5A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] First Batch of P2P VPN Issues X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 01:26:48 -0000 With Yaron's help, I have reviewed all the email traffic regarding draft-ietf-ipsecme-p2p-vpn-problem-00.txt and created tickets for all the issues in the ipsecme trac database, including a proposed resolution for each issue. Although you can access the issues online through the trac database, the best way to discuss them and reach consensus on an appropriate resolution is via email. Therefore, I will start an email thread for each issue. Please respond on that thread if you have a comment on that issue. If you agree with the proposed resolution, that's good to know also. Let's try to reach consensus on as many issues as possible this week. That will let us focus on the few thorny issues at next week's ipsecme meeting. If we close out all these issues, we can move on to focus on requirements at the meeting. So look out for 12 emails from me, starting new threads on the 12 issues listed in the tracker. I have been warned that mailman may rate limit my emails to the list so if it takes a few hours for my emails to arrive, don't despair. You can respond to the first ones while waiting for the last few. Thanks, Steve From shanna@juniper.net Tue Mar 20 18:29:27 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC8F21F85CF for ; Tue, 20 Mar 2012 18:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qntqXIdWKbEa for ; Tue, 20 Mar 2012 18:29:27 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id D180121F85CC for ; Tue, 20 Mar 2012 18:29:26 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKT2ku9hhZe7iyd0ne2KuXfFxtmq6WtggK@postini.com; Tue, 20 Mar 2012 18:29:26 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 20 Mar 2012 18:27:00 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 20 Mar 2012 18:27:00 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 20 Mar 2012 21:26:59 -0400 From: Stephen Hanna To: IPsecme WG Date: Tue, 20 Mar 2012 21:26:57 -0400 Thread-Topic: [ipsecme] #211: We should talk more about why this is a hard problem. Thread-Index: Ac0G66lItdKoDbfJQ4WfiP8xRPONiAAFfABQ Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [IPsec] FW: [ipsecme] #211: We should talk more about why this is a hard problem. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 01:29:27 -0000 U2Vjb25kIGlzc3VlLiBQbGVhc2UgY29tbWVudCBvbiB0aGUgc3VnZ2VzdGVkIHJlc29sdXRpb24u DQoNClRoYW5rcywNCg0KU3RldmUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IGlwc2VjbWUgaXNzdWUgdHJhY2tlciBbbWFpbHRvOnRyYWNAdG9vbHMuaWV0Zi5vcmddIA0KU2Vu dDogVHVlc2RheSwgTWFyY2ggMjAsIDIwMTIgNjo0OSBQTQ0KVG86IHlhcm9uZi5pZXRmQGdtYWls LmNvbTsgZHJhZnQtaWV0Zi1pcHNlY21lLXAycC12cG4tcHJvYmxlbUB0b29scy5pZXRmLm9yZw0K U3ViamVjdDogW2lwc2VjbWVdICMyMTE6IFdlIHNob3VsZCB0YWxrIG1vcmUgYWJvdXQgd2h5IHRo aXMgaXMgYSBoYXJkIHByb2JsZW0uDQoNCiMyMTE6IFdlIHNob3VsZCB0YWxrIG1vcmUgYWJvdXQg d2h5IHRoaXMgaXMgYSBoYXJkIHByb2JsZW0uDQoNCiBUaGlzIHRvcGljIGNhbWUgdXAgc2V2ZXJh bCB0aW1lcyBpbiBkaWZmZXJlbnQgd2F5czogd2Ugc2hvdWxkIHRhbGsgYWJvdXQNCiBnYXBzLCB3 ZSBzaG91bGQgc2F5IG1vcmUgY2xlYXJseSB3aHkgdGhpcyBpcyBoYXJkLCBldGMuDQoNCiBTdWdn ZXN0ZWQgUmVzb2x1dGlvbjogQWRkIGEgUmVxdWlyZW1lbnRzIHNlY3Rpb24gdGhhdCBsYXlzIG91 dCB0aGUgaGFyZA0KIChvciBub3Qgc28gaGFyZCkgcHJvYmxlbXMgdGhhdCBhbnkgc29sdXRpb24g bXVzdCBhZGRyZXNzLg0KDQotLSANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIFJlcG9ydGVyOiAgICAg ICAgICAgICAgIHwgICAgICBPd25lcjogIGRyYWZ0LWlldGYtaXBzZWNtZS1wMnAtdnBuLQ0KICB5 YXJvbmYuaWV0ZkDigKYgICAgICAgICAgfCAgcHJvYmxlbUDigKYNCiAgICAgVHlwZTogIGRlZmVj dCAgICAgICB8ICAgICBTdGF0dXM6ICBuZXcNCiBQcmlvcml0eTogIG5vcm1hbCAgICAgICB8ICBN aWxlc3RvbmU6DQpDb21wb25lbnQ6ICBwMnAtdnBuLSAgICAgfCAgIFNldmVyaXR5OiAgLQ0KICBw cm9ibGVtICAgICAgICAgICAgICAgIHwNCiBLZXl3b3JkczogICAgICAgICAgICAgICB8DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0KVGlja2V0IFVSTDogPGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3Jn L3dnL2lwc2VjbWUvdHJhYy90aWNrZXQvMjExPg0KaXBzZWNtZSA8aHR0cDovL3Rvb2xzLmlldGYu b3JnL2lwc2VjbWUvPg0KDQo= From shanna@juniper.net Tue Mar 20 18:29:51 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BD621E8037 for ; Tue, 20 Mar 2012 18:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXTvLYaQ7tme for ; Tue, 20 Mar 2012 18:29:51 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id EE63E21E8034 for ; Tue, 20 Mar 2012 18:29:50 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKT2kvDuDfhJniNkJoCiY9IBY4oKaao6BW@postini.com; Tue, 20 Mar 2012 18:29:51 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 20 Mar 2012 18:29:39 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 20 Mar 2012 18:29:38 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 20 Mar 2012 21:29:38 -0400 From: Stephen Hanna To: IPsecme WG Date: Tue, 20 Mar 2012 21:29:36 -0400 Thread-Topic: [ipsecme] #212: Section 2.2 should be more detailed. Thread-Index: Ac0G7NXHi1qQ1spfRlaWtMgIsRB7LgAFOoBw Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [IPsec] [ipsecme] #212: Section 2.2 should be more detailed. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 01:29:51 -0000 VGhpcmQgaXNzdWUuDQoNClN0ZXZlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBpcHNlY21lIGlzc3VlIHRyYWNrZXIgW21haWx0bzp0cmFjQHRvb2xzLmlldGYub3JnXSANClNl bnQ6IFR1ZXNkYXksIE1hcmNoIDIwLCAyMDEyIDY6NTcgUE0NClRvOiB5YXJvbmYuaWV0ZkBnbWFp bC5jb207IGRyYWZ0LWlldGYtaXBzZWNtZS1wMnAtdnBuLXByb2JsZW1AdG9vbHMuaWV0Zi5vcmcN ClN1YmplY3Q6IFtpcHNlY21lXSAjMjEyOiBTZWN0aW9uIDIuMiBzaG91bGQgYmUgbW9yZSBkZXRh aWxlZC4NCg0KIzIxMjogU2VjdGlvbiAyLjIgc2hvdWxkIGJlIG1vcmUgZGV0YWlsZWQuDQoNCiBT dWdnZXN0ZWQgUmVzb2x1dGlvbjogRXhwYW5kIHVzZSBjYXNlIHVzaW5nIHRleHQgc3VwcGxpZWQg YnkNCiBWaXNod2FzIE1hbnJhbCBvZiBIUC4NCg0KIEluIGEgc2ltcGxlIHVzZSBjYXNlIHdlIHdh bnQgaHViIGFuZCBzcG9rZSB0b3BvbG9neSBmb3Igc2F5DQogdGhlIERDIGFuZCB0aGUgYnJhbmNo ZXMuIFRoaXMgd291bGQgYWxzbyBiZSB0cnVlIG9mIEFUTSdzDQogY29ubmVjdGluZyB0byB0aGVp ciBEQy4NCg0KIEhvd2V2ZXIgZm9yIHNjYWxhYmlsaXR5IHJlYXNvbnMgd2Ugd291bGQgbm90IHdh bnQgYWxsIHRyYWZmaWMNCiB0byBnbyB0aHJvdWdoIHRoZSBodWIuIEluIHRoZSBBVE0gZXhhbXBs ZSB3ZSBjb3VsZCB3YW50IFZvSVANCiBzZXNzaW9uIHRvIGJ5cGFzcyB0aGUgREMgYW5kIGhhdmUg YSBkaXJlY3QgY29ubmVjdGl2aXR5IGJldHdlZW4NCiB0aGVtc2VsdmVzLiBUaGVyZSBhcmUgbXVs dGlwbGUgb3RoZXIgdXNlcyBjYXNlcyBmb3IgdGhlIHNhbWUuDQogVGhlc2UgbmV3IHNlc3Npb25z IGhvd2V2ZXIgYXJlIHRlbXBvcmFyeSwgd2hlbiBjb21wYXJlZCB0bw0KIHBlcm1hbmVudCBicmFu Y2ggdG8gaHViIGNvbm5lY3Rpb25zLg0KDQotLSANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICBSZXBv cnRlcjogICAgICAgICAgICAgIHwgICAgICBPd25lcjogIGRyYWZ0LWlldGYtaXBzZWNtZS1wMnAt dnBuLQ0KICB5YXJvbmYuaWV0ZkDigKYgICAgICAgICAgfCAgcHJvYmxlbUDigKYNCiAgICAgIFR5 cGU6ICBkZWZlY3QgICAgICB8ICAgICBTdGF0dXM6ICBuZXcNCiAgUHJpb3JpdHk6ICBub3JtYWwg ICAgICB8ICBNaWxlc3RvbmU6DQogQ29tcG9uZW50OiAgcDJwLXZwbi0gICAgfCAgIFNldmVyaXR5 OiAgLQ0KICBwcm9ibGVtICAgICAgICAgICAgICAgIHwgICBLZXl3b3JkczoNClJlc29sdXRpb246 ICAgICAgICAgICAgICB8DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGlja2V0IFVSTDogPGh0dHA6 Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2lwc2VjbWUvdHJhYy90aWNrZXQvMjEyI2NvbW1lbnQ6 MT4NCmlwc2VjbWUgPGh0dHA6Ly90b29scy5pZXRmLm9yZy9pcHNlY21lLz4NCg0K From shanna@juniper.net Tue Mar 20 18:32:12 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D687121E8056 for ; Tue, 20 Mar 2012 18:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyuwVaKYenfR for ; Tue, 20 Mar 2012 18:32:12 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id E5A6C21E8034 for ; Tue, 20 Mar 2012 18:32:11 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKT2kvmmh4lcuf0AswZC5jTjJi/K+Og7HJ@postini.com; Tue, 20 Mar 2012 18:32:12 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 20 Mar 2012 18:31:55 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 20 Mar 2012 21:31:54 -0400 From: Stephen Hanna To: IPsecme WG Date: Tue, 20 Mar 2012 21:31:53 -0400 Thread-Topic: [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible Thread-Index: Ac0G7PbwW8CLZHBvQ+e1SnB1exP1HgAFSAMA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [IPsec] [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 01:32:12 -0000 QW5vdGhlciBpc3N1ZS4gUGxlYXNlIGNvbW1lbnQgb24gU3VnZ2VzdGVkIFJlc29sdXRpb24uDQoN ClRoYW5rcywNCg0KU3RldmUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlw c2VjbWUgaXNzdWUgdHJhY2tlciBbbWFpbHRvOnRyYWNAdG9vbHMuaWV0Zi5vcmddIA0KU2VudDog VHVlc2RheSwgTWFyY2ggMjAsIDIwMTIgNjo1OCBQTQ0KVG86IHlhcm9uZi5pZXRmQGdtYWlsLmNv bTsgZHJhZnQtaWV0Zi1pcHNlY21lLXAycC12cG4tcHJvYmxlbUB0b29scy5pZXRmLm9yZw0KU3Vi amVjdDogW2lwc2VjbWVdICMyMTM6IEluIHVzZSBjYXNlIDIuMSwgZGlyZWN0IGVuZHBvaW50LXRv LWVuZHBvaW50IGNvbm5lY3Rpdml0eSBtYXkgbm90IGJlIHBvc3NpYmxlDQoNCiMyMTM6IEluIHVz ZSBjYXNlIDIuMSwgZGlyZWN0IGVuZHBvaW50LXRvLWVuZHBvaW50IGNvbm5lY3Rpdml0eSBtYXkg bm90IGJlDQpwb3NzaWJsZQ0KDQogSW4gdXNlIGNhc2UgMi4xLCBkaXJlY3QgZW5kcG9pbnQtdG8t ZW5kcG9pbnQgY29ubmVjdGl2aXR5IG1heSBub3QgYmUgcG9zc2libGUNCiBpZiBib3RoIGVuZHBv aW50cyBhcmUgTkFUZWQuDQoNCiBTdWdnZXN0ZWQgUmVzb2x1dGlvbjogTWVudGlvbiB0aGlzIGlu IHNlY3Rpb24gMi4xLg0KDQotLSANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICBSZXBvcnRlcjogICAg ICAgICAgICAgIHwgICAgICBPd25lcjogIGRyYWZ0LWlldGYtaXBzZWNtZS1wMnAtdnBuLQ0KICB5 YXJvbmYuaWV0ZkDigKYgICAgICAgICAgfCAgcHJvYmxlbUDigKYNCiAgICAgIFR5cGU6ICBkZWZl Y3QgICAgICB8ICAgICBTdGF0dXM6ICBuZXcNCiAgUHJpb3JpdHk6ICBub3JtYWwgICAgICB8ICBN aWxlc3RvbmU6DQogQ29tcG9uZW50OiAgcDJwLXZwbi0gICAgfCAgIFNldmVyaXR5OiAgLQ0KICBw cm9ibGVtICAgICAgICAgICAgICAgIHwgICBLZXl3b3JkczoNClJlc29sdXRpb246ICAgICAgICAg ICAgICB8DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGlja2V0IFVSTDogPGh0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL3dnL2lwc2VjbWUvdHJhYy90aWNrZXQvMjEzI2NvbW1lbnQ6MT4NCmlwc2Vj bWUgPGh0dHA6Ly90b29scy5pZXRmLm9yZy9pcHNlY21lLz4NCg0K From shanna@juniper.net Tue Mar 20 18:35:35 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF9221F8633 for ; Tue, 20 Mar 2012 18:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QepXwDAZk66w for ; Tue, 20 Mar 2012 18:35:34 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id DF49421F8639 for ; Tue, 20 Mar 2012 18:35:33 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKT2kwZb2Tz4SWlUL3nxiBhHKWtmPBEkyQ@postini.com; Tue, 20 Mar 2012 18:35:33 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 20 Mar 2012 18:33:33 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 20 Mar 2012 21:33:33 -0400 From: Stephen Hanna To: IPsecme WG Date: Tue, 20 Mar 2012 21:33:31 -0400 Thread-Topic: [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway? Thread-Index: Ac0G7QqVU9DgtHbQTLS4JCWXsgJUXgAFWAvQ Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 01:35:35 -0000 UGxlYXNlIGNvbW1lbnQgb24gU3VnZ2VzdGVkIFJlc29sdXRpb24uIE5vdGUgdGhhdCBZYXJvbiBo YXMNCmFscmVhZHkgc3VwcGxpZWQgaGlzIGNvbW1lbnQgYmVsb3cuDQoNClN0ZXZlDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpcHNlY21lIGlzc3VlIHRyYWNrZXIgW21haWx0 bzp0cmFjQHRvb2xzLmlldGYub3JnXSANClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDIwLCAyMDEyIDY6 NTkgUE0NClRvOiB5YXJvbmYuaWV0ZkBnbWFpbC5jb207IGRyYWZ0LWlldGYtaXBzZWNtZS1wMnAt dnBuLXByb2JsZW1AdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFtpcHNlY21lXSAjMjE0OiBTaG91 bGQgZ2F0ZXdheXMgZmlndXJlIHRoaW5ncyBvdXQgY29tcGxldGVseSBvciBqdXN0IHB1bnQgZW5k cG9pbnRzIHRvIGEgY2xvc2VyIGdhdGV3YXk/DQoNCiMyMTQ6IFNob3VsZCBnYXRld2F5cyBmaWd1 cmUgdGhpbmdzIG91dCBjb21wbGV0ZWx5IG9yIGp1c3QgcHVudCBlbmRwb2ludHMgdG8gYQ0KY2xv c2VyIGdhdGV3YXk/DQoNCiBTdWdnZXN0ZWQgUmVzb2x1dGlvbjogV2Ugc2hvdWxkIG5vdCBzcGVj aWZ5IHRoaXMgaW4gdGhlIHByb2JsZW0gc3RhdGVtZW50Lg0KIEl0IHNob3VsZCBiZSBzcGVjaWZp ZWQgaW4gdGhlIHNvbHV0aW9uLg0KDQogWVM6IHNvdW5kcyBsaWtlIGEgcmVxdWlyZW1lbnRzLWxl dmVsIHF1ZXN0aW9uIHRvIG1lLg0KDQotLSANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICBSZXBvcnRl cjogICAgICAgICAgICAgIHwgICAgICBPd25lcjogIGRyYWZ0LWlldGYtaXBzZWNtZS1wMnAtdnBu LQ0KICB5YXJvbmYuaWV0ZkDigKYgICAgICAgICAgfCAgcHJvYmxlbUDigKYNCiAgICAgIFR5cGU6 ICBkZWZlY3QgICAgICB8ICAgICBTdGF0dXM6ICBuZXcNCiAgUHJpb3JpdHk6ICBub3JtYWwgICAg ICB8ICBNaWxlc3RvbmU6DQogQ29tcG9uZW50OiAgcDJwLXZwbi0gICAgfCAgIFNldmVyaXR5OiAg LQ0KICBwcm9ibGVtICAgICAgICAgICAgICAgIHwgICBLZXl3b3JkczoNClJlc29sdXRpb246ICAg ICAgICAgICAgICB8DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGlja2V0IFVSTDogPGh0dHA6Ly90 cmFjLnRvb2xzLmlldGYub3JnL3dnL2lwc2VjbWUvdHJhYy90aWNrZXQvMjE0I2NvbW1lbnQ6MT4N Cmlwc2VjbWUgPGh0dHA6Ly90b29scy5pZXRmLm9yZy9pcHNlY21lLz4NCg0K From shanna@juniper.net Tue Mar 20 18:36:18 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F60A21F8646 for ; Tue, 20 Mar 2012 18:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBlu38DPCOEp for ; Tue, 20 Mar 2012 18:36:17 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 7751B21F863E for ; Tue, 20 Mar 2012 18:36:17 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKT2kwka21K3v1oyvDU7w9npS6Tu71r3kz@postini.com; Tue, 20 Mar 2012 18:36:17 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 20 Mar 2012 18:34:47 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 20 Mar 2012 21:34:47 -0400 From: Stephen Hanna To: IPsecme WG Date: Tue, 20 Mar 2012 21:34:43 -0400 Thread-Topic: [ipsecme] #215: Should traffic flow through the gateway while a shortcut is being established? Thread-Index: Ac0G7R8I5etBufIyR1ua+/iURJEF5wAFYOBw Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [IPsec] [ipsecme] #215: Should traffic flow through the gateway while a shortcut is being established? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 01:36:18 -0000 QW5vdGhlciBpc3N1ZS4gUGxlYXNlIGNvbW1lbnQuDQoNClN0ZXZlDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBpcHNlY21lIGlzc3VlIHRyYWNrZXIgW21haWx0bzp0cmFjQHRv b2xzLmlldGYub3JnXSANClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDIwLCAyMDEyIDc6MDAgUE0NClRv OiB5YXJvbmYuaWV0ZkBnbWFpbC5jb207IGRyYWZ0LWlldGYtaXBzZWNtZS1wMnAtdnBuLXByb2Js ZW1AdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbaXBzZWNtZV0gIzIxNTogU2hvdWxkIHRy YWZmaWMgZmxvdyB0aHJvdWdoIHRoZSBnYXRld2F5IHdoaWxlIGEgc2hvcnRjdXQgaXMgYmVpbmcg ZXN0YWJsaXNoZWQ/DQoNCiMyMTU6IFNob3VsZCB0cmFmZmljIGZsb3cgdGhyb3VnaCB0aGUgZ2F0 ZXdheSB3aGlsZSBhIHNob3J0Y3V0IGlzIGJlaW5nDQplc3RhYmxpc2hlZD8NCg0KIFN1Z2dlc3Rl ZCBSZXNvbHV0aW9uOiBXZSBzaG91bGQgbm90IHNwZWNpZnkgdGhpcyBpbiB0aGUgcHJvYmxlbSBz dGF0ZW1lbnQuDQogSXQgc2hvdWxkIGJlIHNwZWNpZmllZCBpbiB0aGUgc29sdXRpb24uDQoNCi0t IA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogIFJlcG9ydGVyOiAgICAgICAgICAgICAgfCAgICAgIE93 bmVyOiAgZHJhZnQtaWV0Zi1pcHNlY21lLXAycC12cG4tDQogIHlhcm9uZi5pZXRmQOKApiAgICAg ICAgICB8ICBwcm9ibGVtQOKApg0KICAgICAgVHlwZTogIGRlZmVjdCAgICAgIHwgICAgIFN0YXR1 czogIG5ldw0KICBQcmlvcml0eTogIG5vcm1hbCAgICAgIHwgIE1pbGVzdG9uZToNCiBDb21wb25l bnQ6ICBwMnAtdnBuLSAgICB8ICAgU2V2ZXJpdHk6ICAtDQogIHByb2JsZW0gICAgICAgICAgICAg ICAgfCAgIEtleXdvcmRzOg0KUmVzb2x1dGlvbjogICAgICAgICAgICAgIHwNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KDQpUaWNrZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvaXBz ZWNtZS90cmFjL3RpY2tldC8yMTUjY29tbWVudDoxPg0KaXBzZWNtZSA8aHR0cDovL3Rvb2xzLmll dGYub3JnL2lwc2VjbWUvPg0KDQo= From shanna@juniper.net Tue Mar 20 18:36:39 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D46521E808C for ; Tue, 20 Mar 2012 18:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wT0+HOiC6UrG for ; Tue, 20 Mar 2012 18:36:39 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id E589B21E8089 for ; Tue, 20 Mar 2012 18:36:38 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKT2kwpm1BTR36VvCjJ2c24D+pY8wjAL9b@postini.com; Tue, 20 Mar 2012 18:36:39 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 20 Mar 2012 18:36:23 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 20 Mar 2012 21:36:22 -0400 From: Stephen Hanna To: IPsecme WG Date: Tue, 20 Mar 2012 21:36:21 -0400 Thread-Topic: [ipsecme] #216: Multiple interfaces or mobile endpoint Thread-Index: Ac0G7LmkTCVTMofbSCiNRy4OOx0qYgAFhZtw Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [IPsec] [ipsecme] #216: Multiple interfaces or mobile endpoint X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 01:36:39 -0000 QW5vdGhlciBpc3N1ZS4gUGxlYXNlIGNvbW1lbnQuDQoNCkFuZCBkb24ndCBtaXNzIFlhcm9uJ3Mg Y29tbWVudCBiZWxvdy4NCg0KVGhhbmtzLA0KDQpTdGV2ZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogaXBzZWNtZSBpc3N1ZSB0cmFja2VyIFttYWlsdG86dHJhY0B0b29scy5p ZXRmLm9yZ10gDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAyMCwgMjAxMiA2OjU3IFBNDQpUbzogeWFy b25mLmlldGZAZ21haWwuY29tOyBkcmFmdC1pZXRmLWlwc2VjbWUtcDJwLXZwbi1wcm9ibGVtQHRv b2xzLmlldGYub3JnDQpTdWJqZWN0OiBbaXBzZWNtZV0gIzIxNjogTXVsdGlwbGUgaW50ZXJmYWNl cyBvciBtb2JpbGUgZW5kcG9pbnQNCg0KIzIxNjogTXVsdGlwbGUgaW50ZXJmYWNlcyBvciBtb2Jp bGUgZW5kcG9pbnQNCg0KIFdoYXQgaWYgYW4gZW5kcG9pbnQgaGFzIG11bHRpcGxlIGludGVyZmFj ZXMgYW5kL29yIGlzIG1vYmlsZT8NCiBXaGljaCB0dW5uZWxzIHNob3VsZCBiZSB0b3JuIGRvd24g YXMgdGhpcyBlbmRwb2ludCBtb3ZlcyBhcm91bmQsDQogc29tZXRpbWVzIGJlaGluZCBhIGdhdGV3 YXkgYW5kIHNvbWV0aW1lcyBub3Q/DQoNCiBTdWdnZXN0ZWQgUmVzb2x1dGlvbjogV2Ugc2hvdWxk IG5vdCBzcGVjaWZ5IHRoaXMgaW4gdGhlIHByb2JsZW0NCiBzdGF0ZW1lbnQuIEl0IHNob3VsZCBi ZSBzcGVjaWZpZWQgaW4gdGhlIHNvbHV0aW9uLg0KDQogWVM6IHNvdW5kcyBsaWtlIGEgcmVxdWly ZW1lbnQgcXVlc3Rpb24gdG8gbWUuIEluIGZhY3Qgd2UgbWF5IGJlDQogYWJsZSB0byBzaW1wbGlm eSB0aGluZ3MgYnkgbWFraW5nIHRoaXMgaXNzdWUgYW4gZXhwbGljaXQgbm9uLWdvYWwuDQoNCi0t IA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogIFJlcG9ydGVyOiAgICAgICAgICAgICAgfCAgICAgIE93 bmVyOiAgZHJhZnQtaWV0Zi1pcHNlY21lLXAycC12cG4tDQogIHlhcm9uZi5pZXRmQOKApiAgICAg ICAgICB8ICBwcm9ibGVtQOKApg0KICAgICAgVHlwZTogIGRlZmVjdCAgICAgIHwgICAgIFN0YXR1 czogIG5ldw0KICBQcmlvcml0eTogIG5vcm1hbCAgICAgIHwgIE1pbGVzdG9uZToNCiBDb21wb25l bnQ6ICBwMnAtdnBuLSAgICB8ICAgU2V2ZXJpdHk6ICAtDQogIHByb2JsZW0gICAgICAgICAgICAg ICAgfCAgIEtleXdvcmRzOg0KUmVzb2x1dGlvbjogICAgICAgICAgICAgIHwNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KDQpUaWNrZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvaXBz ZWNtZS90cmFjL3RpY2tldC8yMTYjY29tbWVudDoxPg0KaXBzZWNtZSA8aHR0cDovL3Rvb2xzLmll dGYub3JnL2lwc2VjbWUvPg0KDQo= From shanna@juniper.net Tue Mar 20 18:37:00 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A578721E808E for ; Tue, 20 Mar 2012 18:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7byolNUVqm-V for ; Tue, 20 Mar 2012 18:37:00 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id E9D0D21E808B for ; Tue, 20 Mar 2012 18:36:59 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKT2kwu3apwO1wE0fonDWTV14JGHn3ZKnK@postini.com; Tue, 20 Mar 2012 18:37:00 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 20 Mar 2012 18:36:45 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 20 Mar 2012 18:36:45 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 20 Mar 2012 21:36:44 -0400 From: Stephen Hanna To: IPsecme WG Date: Tue, 20 Mar 2012 21:36:42 -0400 Thread-Topic: [ipsecme] #217: Temporary credentials Thread-Index: Ac0G7UULQWPG5es9Qge2YPt3ZObSOwAFcOeA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [IPsec] [ipsecme] #217: Temporary credentials X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 01:37:00 -0000 QW5vdGhlciBpc3N1ZSB0byBjb21tZW50IG9uLg0KDQpTdGV2ZQ0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogaXBzZWNtZSBpc3N1ZSB0cmFja2VyIFttYWlsdG86dHJhY0B0b29s cy5pZXRmLm9yZ10gDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAyMCwgMjAxMiA3OjAxIFBNDQpUbzog eWFyb25mLmlldGZAZ21haWwuY29tOyBkcmFmdC1pZXRmLWlwc2VjbWUtcDJwLXZwbi1wcm9ibGVt QHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBbaXBzZWNtZV0gIzIxNzogVGVtcG9yYXJ5IGNyZWRl bnRpYWxzDQoNCiMyMTc6IFRlbXBvcmFyeSBjcmVkZW50aWFscw0KDQogRW5kcG9pbnRzIG1heSBy ZXF1aXJlIHRlbXBvcmFyeSBjcmVkZW50aWFscyBpbiBvcmRlciB0byBlc3RhYmxpc2ggYSBzZWN1 cmUNCiBjb25uZWN0aW9uIHRvIGFub3RoZXIgZW5kcG9pbnQuDQoNCiBTdWdnZXN0ZWQgUmVzb2x1 dGlvbjogUHV0IHRoaXMgaW4gdGhlIHJlcXVpcmVtZW50cyBzZWN0aW9uLg0KDQotLSANCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KIFJlcG9ydGVyOiAgICAgICAgICAgICAgIHwgICAgICBPd25lcjogIGRy YWZ0LWlldGYtaXBzZWNtZS1wMnAtdnBuLQ0KICB5YXJvbmYuaWV0ZkDigKYgICAgICAgICAgfCAg cHJvYmxlbUDigKYNCiAgICAgVHlwZTogIGRlZmVjdCAgICAgICB8ICAgICBTdGF0dXM6ICBuZXcN CiBQcmlvcml0eTogIG5vcm1hbCAgICAgICB8ICBNaWxlc3RvbmU6DQpDb21wb25lbnQ6ICBwMnAt dnBuLSAgICAgfCAgIFNldmVyaXR5OiAgLQ0KICBwcm9ibGVtICAgICAgICAgICAgICAgIHwNCiBL ZXl3b3JkczogICAgICAgICAgICAgICB8DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGlja2V0IFVS TDogPGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2lwc2VjbWUvdHJhYy90aWNrZXQvMjE3 Pg0KaXBzZWNtZSA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2lwc2VjbWUvPg0KDQo= From shanna@juniper.net Tue Mar 20 18:37:49 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BEF21E8091 for ; Tue, 20 Mar 2012 18:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKjYHXovp105 for ; Tue, 20 Mar 2012 18:37:49 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id C540921E8089 for ; Tue, 20 Mar 2012 18:37:48 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKT2kw7Hfu/b+cvLetUM3s4E1H4j9j60P6@postini.com; Tue, 20 Mar 2012 18:37:48 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 20 Mar 2012 18:37:33 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 20 Mar 2012 18:37:33 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 20 Mar 2012 21:37:32 -0400 From: Stephen Hanna To: IPsecme WG Date: Tue, 20 Mar 2012 21:37:30 -0400 Thread-Topic: [ipsecme] #219: Star topology as an admin choice Thread-Index: Ac0G7bz7rqVC7YbzScG4oCkAOkMc1wAFWgHA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [IPsec] [ipsecme] #219: Star topology as an admin choice X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 01:37:49 -0000 UGxlYXNlIGNvbW1lbnQuDQoNClN0ZXZlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBpcHNlY21lIGlzc3VlIHRyYWNrZXIgW21haWx0bzp0cmFjQHRvb2xzLmlldGYub3JnXSAN ClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDIwLCAyMDEyIDc6MDQgUE0NClRvOiB5YXJvbmYuaWV0ZkBn bWFpbC5jb207IGRyYWZ0LWlldGYtaXBzZWNtZS1wMnAtdnBuLXByb2JsZW1AdG9vbHMuaWV0Zi5v cmcNClN1YmplY3Q6IFtpcHNlY21lXSAjMjE5OiBTdGFyIHRvcG9sb2d5IGFzIGFuIGFkbWluIGNo b2ljZQ0KDQojMjE5OiBTdGFyIHRvcG9sb2d5IGFzIGFuIGFkbWluIGNob2ljZQ0KDQogU29tZSBh ZG1pbnMgcHJlZmVyIGEgc3RhciB0b3BvbG9neSBzbyB0aGV5IGNhbiBpbnNwZWN0IHRyYWZmaWMu IFRoZXkgbWF5DQogbm90IHdhbnQgdG8gdXNlIHRoaXMgdGVjaG5vbG9neS4NCg0KIFN1Z2dlc3Rl ZCBSZXNvbHV0aW9uOiBNZW50aW9uIHRoaXMgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25z IHNlY3Rpb24uDQoNCi0tIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogUmVwb3J0ZXI6ICAgICAgICAg ICAgICAgfCAgICAgIE93bmVyOiAgZHJhZnQtaWV0Zi1pcHNlY21lLXAycC12cG4tDQogIHlhcm9u Zi5pZXRmQOKApiAgICAgICAgICB8ICBwcm9ibGVtQOKApg0KICAgICBUeXBlOiAgZGVmZWN0ICAg ICAgIHwgICAgIFN0YXR1czogIG5ldw0KIFByaW9yaXR5OiAgbm9ybWFsICAgICAgIHwgIE1pbGVz dG9uZToNCkNvbXBvbmVudDogIHAycC12cG4tICAgICB8ICAgU2V2ZXJpdHk6ICAtDQogIHByb2Js ZW0gICAgICAgICAgICAgICAgfA0KIEtleXdvcmRzOiAgICAgICAgICAgICAgIHwNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KDQpUaWNrZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cv aXBzZWNtZS90cmFjL3RpY2tldC8yMTk+DQppcHNlY21lIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aXBzZWNtZS8+DQoNCg== From shanna@juniper.net Tue Mar 20 18:38:11 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF1421E8097 for ; Tue, 20 Mar 2012 18:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szj+b+1ngDxt for ; Tue, 20 Mar 2012 18:38:10 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0B921E8089 for ; Tue, 20 Mar 2012 18:38:10 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKT2kxAkJo6GLufnFsF8iKTs5aXkdTA/1G@postini.com; Tue, 20 Mar 2012 18:38:10 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 20 Mar 2012 18:37:49 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 20 Mar 2012 21:37:48 -0400 From: Stephen Hanna To: IPsecme WG Date: Tue, 20 Mar 2012 21:37:46 -0400 Thread-Topic: [ipsecme] #220: Sec. 3.2: dangling paragraph Thread-Index: Ac0G7dbJ7IK39sYJQYm5qMoxHUYJlwAFVmBQ Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [IPsec] [ipsecme] #220: Sec. 3.2: dangling paragraph X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 01:38:11 -0000 QW5vdGhlciBvbmUuDQoNClN0ZXZlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBpcHNlY21lIGlzc3VlIHRyYWNrZXIgW21haWx0bzp0cmFjQHRvb2xzLmlldGYub3JnXSANClNl bnQ6IFR1ZXNkYXksIE1hcmNoIDIwLCAyMDEyIDc6MDUgUE0NClRvOiB5YXJvbmYuaWV0ZkBnbWFp bC5jb207IGRyYWZ0LWlldGYtaXBzZWNtZS1wMnAtdnBuLXByb2JsZW1AdG9vbHMuaWV0Zi5vcmcN ClN1YmplY3Q6IFtpcHNlY21lXSAjMjIwOiBTZWMuIDMuMjogZGFuZ2xpbmcgcGFyYWdyYXBoDQoN CiMyMjA6IFNlYy4gMy4yOiBkYW5nbGluZyBwYXJhZ3JhcGgNCg0KIFRoZSBsYXN0IHBhcmFncmFw aCBvZiBzZWN0aW9uIDMuMiBkb2Vzbid0IGJlbG9uZyBpbiB0aGF0IHNlY3Rpb24uDQoNCiBTdWdn ZXN0ZWQgUmVzb2x1dGlvbjogRGVsZXRlIHRoYXQgcGFyYWdyYXBoLg0KDQotLSANCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KIFJlcG9ydGVyOiAgICAgICAgICAgICAgIHwgICAgICBPd25lcjogIGRyYWZ0 LWlldGYtaXBzZWNtZS1wMnAtdnBuLQ0KICB5YXJvbmYuaWV0ZkDigKYgICAgICAgICAgfCAgcHJv YmxlbUDigKYNCiAgICAgVHlwZTogIGRlZmVjdCAgICAgICB8ICAgICBTdGF0dXM6ICBuZXcNCiBQ cmlvcml0eTogIG5vcm1hbCAgICAgICB8ICBNaWxlc3RvbmU6DQpDb21wb25lbnQ6ICBwMnAtdnBu LSAgICAgfCAgIFNldmVyaXR5OiAgLQ0KICBwcm9ibGVtICAgICAgICAgICAgICAgIHwNCiBLZXl3 b3JkczogICAgICAgICAgICAgICB8DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGlja2V0IFVSTDog PGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2lwc2VjbWUvdHJhYy90aWNrZXQvMjIwPg0K aXBzZWNtZSA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2lwc2VjbWUvPg0KDQo= From shanna@juniper.net Tue Mar 20 18:39:29 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A18E21F8652 for ; Tue, 20 Mar 2012 18:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLfTA0FRi1uy for ; Tue, 20 Mar 2012 18:39:29 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id B42E421F864F for ; Tue, 20 Mar 2012 18:39:28 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKT2kxUG2IEWkZw2F6m1YmSCJHmHDsuuC4@postini.com; Tue, 20 Mar 2012 18:39:28 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 20 Mar 2012 18:37:12 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 20 Mar 2012 21:37:12 -0400 From: Stephen Hanna To: IPsecme WG Date: Tue, 20 Mar 2012 21:37:11 -0400 Thread-Topic: [ipsecme] #218: Exhaustive configuration Thread-Index: Ac0G7ZKB0vi5EO4TRwa/2Yvt92qE9gAFYGrQ Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [IPsec] [ipsecme] #218: Exhaustive configuration X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 01:39:29 -0000 S2VlcGluZyB5b3UgZW50ZXJ0YWluZWQgaW4gdGhlIHdlZWsgYmVmb3JlIElFVEYgODMuLi4NCg0K U3RldmUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlwc2VjbWUgaXNzdWUg dHJhY2tlciBbbWFpbHRvOnRyYWNAdG9vbHMuaWV0Zi5vcmddIA0KU2VudDogVHVlc2RheSwgTWFy Y2ggMjAsIDIwMTIgNzowMyBQTQ0KVG86IHlhcm9uZi5pZXRmQGdtYWlsLmNvbTsgZHJhZnQtaWV0 Zi1pcHNlY21lLXAycC12cG4tcHJvYmxlbUB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogW2lwc2Vj bWVdICMyMTg6IEV4aGF1c3RpdmUgY29uZmlndXJhdGlvbg0KDQojMjE4OiBFeGhhdXN0aXZlIGNv bmZpZ3VyYXRpb24NCg0KIEV4aGF1c3RpdmUgY29uZmlndXJhdGlvbiBjYW4gd29yayBmaW5lIGlm IHRoZXJlIGFyZSBnb29kIGF1dG9tYXRlZA0KIGNvbmZpZ3VyYXRpb24gcHJvdG9jb2xzLg0KDQog U3VnZ2VzdGVkIFJlc29sdXRpb246IEV4aGF1c3RpdmUgY29uZmlndXJhdGlvbiBkb2Vzbid0IHNj YWxlIGZvcg0KIGNvbnN0cmFpbmVkIGRldmljZXMgaW4gbGFyZ2UgbmV0d29ya3MuIEV4cGxhaW4g dGhpcyBpbiBzZWN0aW9uIDMuMS4NCg0KLS0gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBSZXBvcnRl cjogICAgICAgICAgICAgICB8ICAgICAgT3duZXI6ICBkcmFmdC1pZXRmLWlwc2VjbWUtcDJwLXZw bi0NCiAgeWFyb25mLmlldGZA4oCmICAgICAgICAgIHwgIHByb2JsZW1A4oCmDQogICAgIFR5cGU6 ICBkZWZlY3QgICAgICAgfCAgICAgU3RhdHVzOiAgbmV3DQogUHJpb3JpdHk6ICBub3JtYWwgICAg ICAgfCAgTWlsZXN0b25lOg0KQ29tcG9uZW50OiAgcDJwLXZwbi0gICAgIHwgICBTZXZlcml0eTog IC0NCiAgcHJvYmxlbSAgICAgICAgICAgICAgICB8DQogS2V5d29yZHM6ICAgICAgICAgICAgICAg fA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRpY2tldCBVUkw6IDxodHRwOi8vdHJhYy50b29scy5p ZXRmLm9yZy93Zy9pcHNlY21lL3RyYWMvdGlja2V0LzIxOD4NCmlwc2VjbWUgPGh0dHA6Ly90b29s cy5pZXRmLm9yZy9pcHNlY21lLz4NCg0K From shanna@juniper.net Tue Mar 20 18:41:53 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985C821F8658 for ; Tue, 20 Mar 2012 18:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfvE5MC+y+rF for ; Tue, 20 Mar 2012 18:41:53 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id C962A21F864E for ; Tue, 20 Mar 2012 18:41:52 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKT2kx4HvOENxVx5ZNg+idW/OvcOvh8I7q@postini.com; Tue, 20 Mar 2012 18:41:52 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 20 Mar 2012 18:38:28 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 20 Mar 2012 18:38:27 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 20 Mar 2012 21:38:27 -0400 From: Stephen Hanna To: IPsecme WG Date: Tue, 20 Mar 2012 21:38:25 -0400 Thread-Topic: [ipsecme] #221: IPsec architecture and proprietary approaches Thread-Index: Ac0G7fsC1HMqzaV1QSOWH2SNxgVEeQAFUCPg Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [IPsec] [ipsecme] #221: IPsec architecture and proprietary approaches X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 01:41:53 -0000 SGVyZSdzIHRoZSBsYXN0IGlzc3VlIGZvciBub3cuIElmIHlvdSB0aGluayB0aGF0IEkgbWlzc2Vk IGFueSwNCnBsZWFzZSBsZXQgbWUga25vdyBhbmQgd2UnbGwgZ2V0IHRoZW0gYWRkZWQuDQoNClRo YW5rcywNCg0KU3RldmUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlwc2Vj bWUgaXNzdWUgdHJhY2tlciBbbWFpbHRvOnRyYWNAdG9vbHMuaWV0Zi5vcmddIA0KU2VudDogVHVl c2RheSwgTWFyY2ggMjAsIDIwMTIgNzowNiBQTQ0KVG86IHlhcm9uZi5pZXRmQGdtYWlsLmNvbTsg ZHJhZnQtaWV0Zi1pcHNlY21lLXAycC12cG4tcHJvYmxlbUB0b29scy5pZXRmLm9yZw0KU3ViamVj dDogW2lwc2VjbWVdICMyMjE6IElQc2VjIGFyY2hpdGVjdHVyZSBhbmQgcHJvcHJpZXRhcnkgYXBw cm9hY2hlcw0KDQojMjIxOiBJUHNlYyBhcmNoaXRlY3R1cmUgYW5kIHByb3ByaWV0YXJ5IGFwcHJv YWNoZXMNCg0KIEluIHNlY3Rpb24gMy4zLCB3ZSBzaG91bGQgc2F5IHRoYXQgcHJvcHJpZXRhcnkg YXBwcm9hY2hlcyBtYXkgbm90DQogaW1wbGVtZW50IGFsbCB0aGUgY2hlY2tzIGluIHRoZSBJUHNl YyBhcmNoaXRlY3R1cmUuDQoNCiBTdWdnZXN0ZWQgUmVzb2x1dGlvbjogQWRkIHRoaXMgdG8gc2Vj dGlvbiAzLjMuDQoNCi0tIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogUmVwb3J0ZXI6ICAgICAgICAg ICAgICAgfCAgICAgIE93bmVyOiAgZHJhZnQtaWV0Zi1pcHNlY21lLXAycC12cG4tDQogIHlhcm9u Zi5pZXRmQOKApiAgICAgICAgICB8ICBwcm9ibGVtQOKApg0KICAgICBUeXBlOiAgZGVmZWN0ICAg ICAgIHwgICAgIFN0YXR1czogIG5ldw0KIFByaW9yaXR5OiAgbm9ybWFsICAgICAgIHwgIE1pbGVz dG9uZToNCkNvbXBvbmVudDogIHAycC12cG4tICAgICB8ICAgU2V2ZXJpdHk6ICAtDQogIHByb2Js ZW0gICAgICAgICAgICAgICAgfA0KIEtleXdvcmRzOiAgICAgICAgICAgICAgIHwNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KDQpUaWNrZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cv aXBzZWNtZS90cmFjL3RpY2tldC8yMjE+DQppcHNlY21lIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aXBzZWNtZS8+DQoNCg== From ynir@checkpoint.com Wed Mar 21 06:19:59 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D2421F858F for ; Wed, 21 Mar 2012 06:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.495 X-Spam-Level: X-Spam-Status: No, score=-10.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2zE9p8Tq1QY for ; Wed, 21 Mar 2012 06:19:58 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 081FB21F8584 for ; Wed, 21 Mar 2012 06:19:57 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2LDJt8R008808; Wed, 21 Mar 2012 15:19:55 +0200 X-CheckPoint: {4F69D4F8-0-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 21 Mar 2012 15:19:55 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 21 Mar 2012 15:19:54 +0200 From: Yoav Nir To: Stephen Hanna Date: Wed, 21 Mar 2012 15:19:58 +0200 Thread-Topic: [IPsec] [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible Thread-Index: Ac0HZU4DstDPjMuiQ6GgM7nDNUnk7w== Message-ID: <21AAB4E5-7E09-4897-BA67-469C60B7CAA0@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: IPsecme WG Subject: Re: [IPsec] [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 13:19:59 -0000 ImRpcmVjdCBlbmRwb2ludC10by1lbmRwb2ludCBjb25uZWN0aXZpdHkgbWF5IG5vdCBiZSBwb3Nz aWJsZSBpZiBib3RoIGVuZHBvaW50cyBhcmUgTkFUZWQiDQoNCldoeT8gIFRoZXJlIGFyZSBzZXZl cmFsIHByb3RvY29scyAoU0lQL1JUUCBjb21lIHRvIG1pbmQpIHRoYXQgbWFuYWdlIGVuZHBvaW50 LXRvLWVuZHBvaW50IGNvbm5lY3Rpdml0eSBldmVuIHdoZW4gYm90aCBhcmUgYmVoaW5kIE5BVC4g V2h5IHNob3VsZG4ndCBJUHNlYyBlbmRwb2ludHMgZG8gdGhpcz8NCg0KSWYgdGhpcyByZXF1aXJl cyBzb21lIG5ldyBOQVQgdHJhdmVyc2FsIG1lY2hhbmlzbSwgcGVyaGFwcyB1c2luZyBhIGh1YiBn YXRld2F5IGluIHBsYWNlIG9mIHRoZSBTSVAgU0JDLCB0aGVuIHRoaXMgc2hvdWxkIGJlIHBhcnQg b2YgdGhlIHJlcXVpcmVtZW50cy4NCg0KVGhpcyBtZWNoYW5pc20gaXMgbmVlZGVkIGV2ZW4gaWYg b25seSBvbmUgZW5kcG9pbnQgaXMgTkFUdGVkLCBvdGhlcndpc2Ugd2UncmUgY29uc3RyYWluaW5n IHdobyB0aGUgaW5pdGlhdG9yIGhhcyB0byBiZS4NCg0KWW9hdg0KDQpPbiBNYXIgMjEsIDIwMTIs IGF0IDM6MzEgQU0sIFN0ZXBoZW4gSGFubmEgd3JvdGU6DQoNCj4gQW5vdGhlciBpc3N1ZS4gUGxl YXNlIGNvbW1lbnQgb24gU3VnZ2VzdGVkIFJlc29sdXRpb24uDQo+IA0KPiBUaGFua3MsDQo+IA0K PiBTdGV2ZQ0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaXBzZWNt ZSBpc3N1ZSB0cmFja2VyIFttYWlsdG86dHJhY0B0b29scy5pZXRmLm9yZ10gDQo+IFNlbnQ6IFR1 ZXNkYXksIE1hcmNoIDIwLCAyMDEyIDY6NTggUE0NCj4gVG86IHlhcm9uZi5pZXRmQGdtYWlsLmNv bTsgZHJhZnQtaWV0Zi1pcHNlY21lLXAycC12cG4tcHJvYmxlbUB0b29scy5pZXRmLm9yZw0KPiBT dWJqZWN0OiBbaXBzZWNtZV0gIzIxMzogSW4gdXNlIGNhc2UgMi4xLCBkaXJlY3QgZW5kcG9pbnQt dG8tZW5kcG9pbnQgY29ubmVjdGl2aXR5IG1heSBub3QgYmUgcG9zc2libGUNCj4gDQo+ICMyMTM6 IEluIHVzZSBjYXNlIDIuMSwgZGlyZWN0IGVuZHBvaW50LXRvLWVuZHBvaW50IGNvbm5lY3Rpdml0 eSBtYXkgbm90IGJlDQo+IHBvc3NpYmxlDQo+IA0KPiBJbiB1c2UgY2FzZSAyLjEsIGRpcmVjdCBl bmRwb2ludC10by1lbmRwb2ludCBjb25uZWN0aXZpdHkgbWF5IG5vdCBiZSBwb3NzaWJsZQ0KPiBp ZiBib3RoIGVuZHBvaW50cyBhcmUgTkFUZWQuDQo+IA0KPiBTdWdnZXN0ZWQgUmVzb2x1dGlvbjog TWVudGlvbiB0aGlzIGluIHNlY3Rpb24gMi4xLg0KPiANCj4gLS0gDQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiAgUmVwb3J0ZXI6ICAgICAgICAgICAgICB8ICAgICAgT3duZXI6ICBkcmFmdC1pZXRm LWlwc2VjbWUtcDJwLXZwbi0NCj4gIHlhcm9uZi5pZXRmQOKApiAgICAgICAgICB8ICBwcm9ibGVt QOKApg0KPiAgICAgIFR5cGU6ICBkZWZlY3QgICAgICB8ICAgICBTdGF0dXM6ICBuZXcNCj4gIFBy aW9yaXR5OiAgbm9ybWFsICAgICAgfCAgTWlsZXN0b25lOg0KPiBDb21wb25lbnQ6ICBwMnAtdnBu LSAgICB8ICAgU2V2ZXJpdHk6ICAtDQo+ICBwcm9ibGVtICAgICAgICAgICAgICAgIHwgICBLZXl3 b3JkczoNCj4gUmVzb2x1dGlvbjogICAgICAgICAgICAgIHwNCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+IA0KPiBUaWNrZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvaXBzZWNt ZS90cmFjL3RpY2tldC8yMTMjY29tbWVudDoxPg0KPiBpcHNlY21lIDxodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaXBzZWNtZS8+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBJUHNlYyBtYWlsaW5nIGxpc3QNCj4gSVBzZWNAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYw0KPiBJxqfvv73vv71b 77+9KF5yQ++/vXtT77+91qVJ77+9Lu+/vStyGe+/vV7vv73vv70NCg0K From jntupal@gmail.com Wed Mar 21 07:14:23 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F2B21F86F3 for ; Wed, 21 Mar 2012 07:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osa0yz1XxvkN for ; Wed, 21 Mar 2012 07:14:22 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4114121F86E4 for ; Wed, 21 Mar 2012 07:14:22 -0700 (PDT) Received: by werb10 with SMTP id b10so1163271wer.31 for ; Wed, 21 Mar 2012 07:14:20 -0700 (PDT) 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=feC/RC7fdvMz4Uhs9VFttekIpG6q2ExqWDmdVgaisnw=; b=oxyu9Ssm0Lf4qgTm8To7FFWBIN5WxLbqpWV4ZBjL0RYoyii3s6BNv9ypKptN31JTuY LIw1eL4kg6icRqukxC97vYEjtBjxjk46Ay62bS/JUkaPLQDlfzB8t94qBAaezq4aFP1v exr1PWrl0buUiiuyJPK7nfLg+/KQ8IsUm9iyfSBXgxz2OP6U8VCnO7ZdqKMZyH3XtGJ8 DTyKTs8LwxyvwSbCa1qnc9T7KbuuESzOow781HZIoknW8992TQLZTEWA0pih5SVQMwU5 KIYGcXVv3v82v0PMNBclK+7XM7mFtCcZiot858REHU2CtXWx7IoLUuCghwAbJydvZRyR BEFA== MIME-Version: 1.0 Received: by 10.180.107.162 with SMTP id hd2mr38446119wib.8.1332339260363; Wed, 21 Mar 2012 07:14:20 -0700 (PDT) Received: by 10.216.233.219 with HTTP; Wed, 21 Mar 2012 07:14:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Mar 2012 19:44:20 +0530 Message-ID: From: yogendra pal To: Stephen Hanna Content-Type: multipart/alternative; boundary=e89a8f23529755954a04bbc16847 Cc: IPsecme WG Subject: Re: [IPsec] [ipsecme] #210: What should we call this effort? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 14:14:23 -0000 --e89a8f23529755954a04bbc16847 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I am ok to any of two names which make sense: Remote unknown VPN ( RUK-VPN) or On-demand VPN Thanks and Regards, Yogendra Pal Ericsson, India +919686202644 On Wed, Mar 21, 2012 at 6:55 AM, Stephen Hanna wrote: > Here's the first issue. So far, it has been the most > contentious one! Interesting that it's the least > technical issue. Hmmmm. > > Anyway, if you're not happy with the proposed resolution, > please suggest another. And if you support this idea, > please say so. > > Thanks, > > Steve > > -----Original Message----- > From: ipsecme issue tracker [mailto:trac@tools.ietf.org] > Sent: Tuesday, March 20, 2012 6:44 PM > To: yaronf.ietf@gmail.com; > draft-ietf-ipsecme-p2p-vpn-problem@tools.ietf.org > Subject: [ipsecme] #210: What should we call this effort? > > #210: What should we call this effort? > > Many names were suggested but no consensus has emerged. The most popular > candidate so far is "Auto Mesh VPN". > > Suggested Resolution: Choose Auto Mesh VPN unless another more popular > name emerges on the email list by the end of IETF 83. > > -- > -------------------------+-----------------------------------------------= -- > Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn- > yaronf.ietf@=85 | problem@=85 > Type: defect | Status: new > Priority: normal | Milestone: > Component: p2p-vpn- | Severity: - > problem | > Keywords: | > -------------------------+-----------------------------------------------= -- > > Ticket URL: > ipsecme > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- --e89a8f23529755954a04bbc16847 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I am ok to any of two names which make sense:
Remote unknown VPN ( RUK-= VPN)=A0or On-demand VPN

Thanks and Regards,
Yog= endra Pal
Ericsson, India
+919686202644

On Wed, Mar 21, 2012 at 6:55 AM, Stephen Hanna <shanna@juniper.net> wrote:
Here's the first issue. So far, it has been the most
contentious one! Interesting that it's the least
technical issue. Hmmmm.

Anyway, if you're not happy with the proposed resolution,
please suggest another. And if you support this idea,
please say so.

Thanks,

Steve

-----Original Message-----
From: ipsecme issue tracker [mailto:= trac@tools.ietf.org]
Sent: Tuesday, March 20, 2012 6:44 PM
To: yaronf.ietf@gmail.com; draft-iet= f-ipsecme-p2p-vpn-problem@tools.ietf.org
Subject: [ipsecme] #210: What should we call this effort?

#210: What should we call this effort?

=A0Many names were suggested but no consensus has emerged. The most popular=
=A0candidate so far is "Auto Mesh VPN".

=A0Suggested Resolution: Choose Auto Mesh VPN unless another more popular =A0name emerges on the email list by the end of IETF 83.

--
-------------------------+-------------------------------------------------=
=A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Owner: =A0draft-ietf-= ipsecme-p2p-vpn-
=A0yaronf.ietf@=85 =A0 =A0 =A0 =A0 =A0| =A0problem@=85
=A0 =A0 Type: =A0defect =A0 =A0 =A0 | =A0 =A0 Status: =A0new
=A0Priority: =A0normal =A0 =A0 =A0 | =A0Milestone:
Component: =A0p2p-vpn- =A0 =A0 | =A0 Severity: =A0-
=A0problem =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
-------------------------+-------------------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/= 210>
ipsecme <ht= tp://tools.ietf.org/ipsecme/>

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



--

--e89a8f23529755954a04bbc16847-- From manishkr@cisco.com Wed Mar 21 07:50:28 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB2921F8704 for ; Wed, 21 Mar 2012 07:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ste3T3ghV58 for ; Wed, 21 Mar 2012 07:50:27 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id EDD7621F8703 for ; Wed, 21 Mar 2012 07:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=manishkr@cisco.com; l=875; q=dns/txt; s=iport; t=1332341427; x=1333551027; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=3Bs0VtsVP4Fi4K0gPY8n9Fb0Q2F5py5q0At+6LfKl5s=; b=On+YeHBY1fID0kb+XTIM7g/XToS0a5tXkS8GYhz4Gwn0Hvf7/ZrLKKxD phadhcu8PMsJHBIo1Ka70vLN+oIK5BjsRPOnfu6dqaTDK8YI15ppSkekl 2bthzMZHnlhWBOMXIApNGuzAlt9On6hKbTrw8dkIYlyfXS2U9oIiZ2h6e Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAPfpaU9Io8UY/2dsb2JhbABEuAKCCQEBAQMBAQEBDwEnAgExEA0BCA5fMAEBBAEKCCKHYwULmH6fEwSRAQSIVI0Ljj+BaIJv X-IronPort-AV: E=Sophos;i="4.73,623,1325462400"; d="scan'208";a="8340184" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 21 Mar 2012 14:50:25 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2LEoPev002393; Wed, 21 Mar 2012 14:50:25 GMT Received: from xmb-bgl-419.cisco.com ([72.163.129.215]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Mar 2012 20:20:24 +0530 Received: from 10.65.78.243 ([10.65.78.243]) by XMB-BGL-419.cisco.com ([72.163.129.215]) via Exchange Front-End Server email.cisco.com ([72.163.129.199]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Mar 2012 14:50:24 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 21 Mar 2012 20:20:23 +0530 From: Manish Kumar To: Yoav Nir , IPsecme WG , Paul Hoffman Message-ID: Thread-Topic: [IPsec] P2P VPN draft UNCLASSIFIED Thread-Index: Ac0FmDCrtISyB5vkTRawGtDgN4yl/wADUeugAHMeUZw= In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F017A75325A1B@il-ex01.ad.checkpoint.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Mar 2012 14:50:24.0937 (UTC) FILETIME=[F2C5F190:01CD0771] Subject: Re: [IPsec] P2P VPN draft UNCLASSIFIED X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 14:50:28 -0000 Although I prefer it over some of the other names, "discovery" isn't making too good an adjective here. How about "Dynamic Secure VPN" without over qualifying dynamic ? Thanks, Manish On 19/03/12 1:27 PM, "Yoav Nir" wrote: > As Tero pointed out, some of the use cases don't end up in a full mesh, > because sometimes administrators really want a trunk, so the end result could > be a mesh among nodes in the same organization, and a trunk to another. Maybe > even a partial mesh (with "secondary nodes" behind particularly bad NAT > devices connecting to one of many "primary nodes") > > So perhaps the name should not include the word "mesh". How about "dynamic > discovery VPN" (DD-VPN)? > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From manishkr@cisco.com Wed Mar 21 07:51:28 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFF321F8716 for ; Wed, 21 Mar 2012 07:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkYyymSsIBIP for ; Wed, 21 Mar 2012 07:51:27 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 04C1421F870E for ; Wed, 21 Mar 2012 07:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=manishkr@cisco.com; l=1011; q=dns/txt; s=iport; t=1332341487; x=1333551087; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=IxfvUb3W5Fey8qA3cZPuZCv5vuQSJV6oeRe377742+0=; b=cjV0UNELcwaiFFPVGg0vLAOP/VjOdnRF0Ulkau8P2O5iSdD0uBzMOpRO Pi5g708/EJipJ8d3L37VWmQfijghxlIOwOj9s7iiGyP2v3GZCChRKdtRe ke7p0BO0gPz3/nH1FniW8pw5TnncgJ5Sg1CjRl2d5H9VYlqgBxI+MYJNv c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAPfpaU9Io8UY/2dsb2JhbABEuAKCCQEBAQMBEgEnAgFBBwYBCA4DBAEBKCglCQgBAQQBCggih2MFmQmfF4lshxUEiFSNC4sugxGBaIJvgVQ X-IronPort-AV: E=Sophos;i="4.73,623,1325462400"; d="scan'208";a="8340229" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 21 Mar 2012 14:51:25 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2LEpPqU026150; Wed, 21 Mar 2012 14:51:25 GMT Received: from xmb-bgl-419.cisco.com ([72.163.129.215]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Mar 2012 20:21:25 +0530 Received: from 10.65.78.243 ([10.65.78.243]) by XMB-BGL-419.cisco.com ([72.163.129.215]) via Exchange Front-End Server email.cisco.com ([72.163.129.199]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Mar 2012 14:51:24 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 21 Mar 2012 20:21:23 +0530 From: Manish Kumar To: Stephen Hanna , IPsecme WG Message-ID: Thread-Topic: [IPsec] [ipsecme] #210: What should we call this effort? Thread-Index: Ac0G6wIGwjiV6+lcSnKtps4ECf33uwAFjxqQABw1vK0= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Mar 2012 14:51:25.0110 (UTC) FILETIME=[16A39D60:01CD0772] Subject: Re: [IPsec] [ipsecme] #210: What should we call this effort? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 14:51:28 -0000 How about "Dynamic Secure VPN" ? Thanks, Manish On 21/03/12 6:55 AM, "Stephen Hanna" wrote: > Here's the first issue. So far, it has been the most > contentious one! Interesting that it's the least > technical issue. Hmmmm. > > Anyway, if you're not happy with the proposed resolution, > please suggest another. And if you support this idea, > please say so. > > Thanks, > > Steve > > -----Original Message----- > From: ipsecme issue tracker [mailto:trac@tools.ietf.org] > Sent: Tuesday, March 20, 2012 6:44 PM > To: yaronf.ietf@gmail.com; draft-ietf-ipsecme-p2p-vpn-problem@tools.ietf.org > Subject: [ipsecme] #210: What should we call this effort? > > #210: What should we call this effort? > > Many names were suggested but no consensus has emerged. The most popular > candidate so far is "Auto Mesh VPN". > > Suggested Resolution: Choose Auto Mesh VPN unless another more popular > name emerges on the email list by the end of IETF 83. From paul.hoffman@vpnc.org Wed Mar 21 07:55:59 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076EF21F8722 for ; Wed, 21 Mar 2012 07:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.671 X-Spam-Level: X-Spam-Status: No, score=-102.671 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-LBMdeC9Ez4 for ; Wed, 21 Mar 2012 07:55:58 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9695021F85E5 for ; Wed, 21 Mar 2012 07:55:58 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2LEtvYS066139 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 21 Mar 2012 07:55:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: Date: Wed, 21 Mar 2012 07:55:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4DDE268F-5A1E-44E6-98C3-15FE30433802@vpnc.org> References: To: IPsecme WG X-Mailer: Apple Mail (2.1257) Subject: [IPsec] SUSPENSION OF THREAD #210: What should we call this effort? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 14:55:59 -0000 Steve posted a large number of interesting technical questions that have = been asked about the document. Spending energy on those is *much* more = important to the WG than deciding the name. Further, some of the answers = of those questions will help choose the "best" name. I will resume the discussion of #210 after we have answers on the other = issues. --Paul Hoffman From jntupal@gmail.com Wed Mar 21 08:53:06 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8405921F872B for ; Wed, 21 Mar 2012 08:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJ89oqrWSmiP for ; Wed, 21 Mar 2012 08:53:04 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id F380D21F86F0 for ; Wed, 21 Mar 2012 08:53:02 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so5381188wib.13 for ; Wed, 21 Mar 2012 08:53:02 -0700 (PDT) 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=2S4EI7fbx/nFhcpFEE6rat+q7ZNdyAW9sxuku0l5gK4=; b=1CrwYRxudBbiZhRn9pRyz6IaQOd3fEV+rykENNksaZNz6S0zT2RYR1DMPDSkQrlMXY j/gtqzLeiCxd5gOH3TFixtwxzn7oOpGLP46sHSoD1H92dUV1k6sYDAZirqU3G/LDU32K AXHbZN6ETxId687keu7wK2kUFOwQuF89trpJn+Etfwxs4PJHppiE/L57hHFu3zWtGn16 yF82fapWMKqT89DoK//mT7hfg7VHoaSg+hACxMCXN8THOFt0AEIFnoEz2dC2kzxsDxdT G7pAFeePfgobY/idAB09Tr6nbpy8DpNg1ALuI5GoTLGj6E0/XU8lEaV399NA5WpieVNP WFtw== MIME-Version: 1.0 Received: by 10.216.132.151 with SMTP id o23mr2474591wei.120.1332345182110; Wed, 21 Mar 2012 08:53:02 -0700 (PDT) Received: by 10.216.233.219 with HTTP; Wed, 21 Mar 2012 08:53:02 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Mar 2012 21:23:02 +0530 Message-ID: From: yogendra pal To: Stephen Hanna Content-Type: multipart/alternative; boundary=0016e6d9a1f94c44a204bbc2c9a2 Cc: IPsecme WG Subject: Re: [IPsec] FW: [ipsecme] #211: We should talk more about why this is a hard problem. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 15:53:06 -0000 --0016e6d9a1f94c44a204bbc2c9a2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 1. Let us not say this is a hard problem, it sounds like NP hard problem (which indeed it's not) Just rephrasing it, Suggested Resolution: Add a Requirements section that lays out the problems that any solution must address. >"#211: We should talk more about why this is a hard problem." > >This topic came up several times in different ways: we should talk about >gaps, we should say more clearly why this is hard, etc. >Suggested Resolution: Add a Requirements section that lays out the hard >(or not so hard) problems that any solution must address. Thanks and Regards, Yogendra Pal Ericsson, India +919686202644 On Wed, Mar 21, 2012 at 6:56 AM, Stephen Hanna wrote: > Second issue. Please comment on the suggested resolution. > > Thanks, > > Steve > > -----Original Message----- > From: ipsecme issue tracker [mailto:trac@tools.ietf.org] > Sent: Tuesday, March 20, 2012 6:49 PM > To: yaronf.ietf@gmail.com; > draft-ietf-ipsecme-p2p-vpn-problem@tools.ietf.org > Subject: [ipsecme] #211: We should talk more about why this is a hard > problem. > > #211: We should talk more about why this is a hard problem. > > This topic came up several times in different ways: we should talk about > gaps, we should say more clearly why this is hard, etc. > > Suggested Resolution: Add a Requirements section that lays out the hard > (or not so hard) problems that any solution must address. > > -- > -------------------------+-----------------------------------------------= -- > Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn- > yaronf.ietf@=85 | problem@=85 > Type: defect | Status: new > Priority: normal | Milestone: > Component: p2p-vpn- | Severity: - > problem | > Keywords: | > -------------------------+-----------------------------------------------= -- > > Ticket URL: > ipsecme > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- --0016e6d9a1f94c44a204bbc2c9a2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
1. Let us not say this is a hard problem, it sounds like NP hard probl= em (which indeed it's not)
Just rephrasing it, Suggested Resolution= :=A0Add a Requirements section that lays out the=A0problems that any soluti= on must address.=A0


>"#211: We should talk mor= e about why this is a hard problem."
>
>This topic came up= several times in different ways: we should talk about
>gaps, we shou= ld say more clearly why this is hard, etc.

>Suggested Resolution: Add a Requirements section that lays out the = hard
>(or not so hard) problems that any solution must address.
Thanks and Regards,
Yogendra Pal
Ericsson, India
+919686202644

On Wed, Mar 21, 2012 at 6= :56 AM, Stephen Hanna <shanna@juniper.net> wrote:
Second issue. Please comment on the suggested resolution.

Thanks,

Steve

-----Original Message-----
From: ipsecme issue tracker [mailto:= trac@tools.ietf.org]
Sent: Tuesday, March 20, 2012 6:49 PM
To: yaronf.ietf@gmail.com; draft-iet= f-ipsecme-p2p-vpn-problem@tools.ietf.org
Subject: [ipsecme] #211: We should talk more about why this is a hard probl= em.

#211: We should talk more about why this is a hard problem.

=A0This topic came up several times in different ways: we should talk about=
=A0gaps, we should say more clearly why this is hard, etc.

=A0Suggested Resolution: Add a Requirements section that lays out the hard<= br> =A0(or not so hard) problems that any solution must address.

--
-------------------------+-------------------------------------------------=
=A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Owner: =A0draft-ietf-= ipsecme-p2p-vpn-
=A0yaronf.ietf@=85 =A0 =A0 =A0 =A0 =A0| =A0problem@=85
=A0 =A0 Type: =A0defect =A0 =A0 =A0 | =A0 =A0 Status: =A0new
=A0Priority: =A0normal =A0 =A0 =A0 | =A0Milestone:
Component: =A0p2p-vpn- =A0 =A0 | =A0 Severity: =A0-
=A0problem =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
-------------------------+-------------------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/= 211>
ipsecme <ht= tp://tools.ietf.org/ipsecme/>

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



--

--0016e6d9a1f94c44a204bbc2c9a2-- From vishwas.ietf@gmail.com Wed Mar 21 12:14:27 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B5521E805A for ; Wed, 21 Mar 2012 12:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.904 X-Spam-Level: X-Spam-Status: No, score=-3.904 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09o7pS1BrCWW for ; Wed, 21 Mar 2012 12:14:26 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A626121E80AD for ; Wed, 21 Mar 2012 12:14:26 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1033668obb.31 for ; Wed, 21 Mar 2012 12:14:26 -0700 (PDT) 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=720UjVm9I7P8PNM5T4Apx+C93GZGk8cSVdwQtPw0bxQ=; b=EBf7QRrISJ3KWZBT3b0PkD3o+IHVSvERimp0GZn1H7spQ2DGsFuc7o7QVKchk+0Isi v/g+Ev0aIjzcvsDvotSQFwhIndaPQI01amEvIKYNvQLvOYiPTs2jn85hJd4qMGBNlmcW uIpGSwEQkVjSDJCxri6Gwui/d3Nu2P8BNbxaLkDIG9ljP7liI0Fpt42udUEgojOYYsSc WUkg9CKGaTzeJQ/MW4JF9KBNKn7GU/sEM2MdoKGGesqkOUFFkP2tE4tW6i7WgHu82bkO JGu61zQnGxRlcILEtafd4HaMSTiEP+TmwQxv2Hnxs9t551fMsoqsLdm9teZ04/8e58gp 7M1g== MIME-Version: 1.0 Received: by 10.182.53.66 with SMTP id z2mr6277746obo.3.1332357266317; Wed, 21 Mar 2012 12:14:26 -0700 (PDT) Received: by 10.182.134.73 with HTTP; Wed, 21 Mar 2012 12:14:26 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Mar 2012 12:14:26 -0700 Message-ID: From: Vishwas Manral To: Stephen Hanna Content-Type: multipart/alternative; boundary=f46d0447a02b929f6004bbc5997b Cc: IPsecme WG Subject: Re: [IPsec] [ipsecme] #212: Section 2.2 should be more detailed. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 19:14:27 -0000 --f46d0447a02b929f6004bbc5997b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Stephen, Sounds good to me. Thanks, Vishwas On Tue, Mar 20, 2012 at 6:29 PM, Stephen Hanna wrote: > Third issue. > > Steve > > -----Original Message----- > From: ipsecme issue tracker [mailto:trac@tools.ietf.org] > Sent: Tuesday, March 20, 2012 6:57 PM > To: yaronf.ietf@gmail.com; > draft-ietf-ipsecme-p2p-vpn-problem@tools.ietf.org > Subject: [ipsecme] #212: Section 2.2 should be more detailed. > > #212: Section 2.2 should be more detailed. > > Suggested Resolution: Expand use case using text supplied by > Vishwas Manral of HP. > > In a simple use case we want hub and spoke topology for say > the DC and the branches. This would also be true of ATM's > connecting to their DC. > > However for scalability reasons we would not want all traffic > to go through the hub. In the ATM example we could want VoIP > session to bypass the DC and have a direct connectivity between > themselves. There are multiple other uses cases for the same. > These new sessions however are temporary, when compared to > permanent branch to hub connections. > > -- > -------------------------+-----------------------------------------------= -- > Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn- > yaronf.ietf@=85 | problem@=85 > Type: defect | Status: new > Priority: normal | Milestone: > Component: p2p-vpn- | Severity: - > problem | Keywords: > Resolution: | > -------------------------+-----------------------------------------------= -- > > Ticket URL: < > http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/212#comment:1> > ipsecme > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --f46d0447a02b929f6004bbc5997b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Stephen,

Sounds good to me.

Thanks,
Vishwas

On Tue, Mar 20, 2012 at 6:29 PM, Stephen Hanna <shanna@juniper.net> wrote:
Third issue.

Steve

-----Original Message-----
From: ipsecme issue tracker [mailto:= trac@tools.ietf.org]
Sent: Tuesday, March 20, 2012 6:57 PM
To: yaronf.ietf@gmail.com; draft-iet= f-ipsecme-p2p-vpn-problem@tools.ietf.org
Subject: [ipsecme] #212: Section 2.2 should be more detailed.

#212: Section 2.2 should be more detailed.

=A0Suggested Resolution: Expand use case using text supplied by
=A0Vishwas Manral of HP.

=A0In a simple use case we want hub and spoke topology for say
=A0the DC and the branches. This would also be true of ATM's
=A0connecting to their DC.

=A0However for scalability reasons we would not want all traffic
=A0to go through the hub. In the ATM example we could want VoIP
=A0session to bypass the DC and have a direct connectivity between
=A0themselves. There are multiple other uses cases for the same.
=A0These new sessions however are temporary, when compared to
=A0permanent branch to hub connections.

--
-------------------------+-------------------------------------------------=
=A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0Owner: =A0draft-ietf-= ipsecme-p2p-vpn-
=A0yaronf.ietf@=85 =A0 =A0 =A0 =A0 =A0| =A0problem@=85
=A0 =A0 =A0Type: =A0defect =A0 =A0 =A0| =A0 =A0 Status: =A0new
=A0Priority: =A0normal =A0 =A0 =A0| =A0Milestone:
=A0Component: =A0p2p-vpn- =A0 =A0| =A0 Severity: =A0-
=A0problem =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Keywords:
Resolution: =A0 =A0 =A0 =A0 =A0 =A0 =A0|
-------------------------+-------------------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/ipsecme/tr= ac/ticket/212#comment:1>
ipsecme <ht= tp://tools.ietf.org/ipsecme/>

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

--f46d0447a02b929f6004bbc5997b-- From vishwas.ietf@gmail.com Wed Mar 21 12:18:12 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F29721E80B7 for ; Wed, 21 Mar 2012 12:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.896 X-Spam-Level: X-Spam-Status: No, score=-3.896 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rS8UQEhSGg1x for ; Wed, 21 Mar 2012 12:18:11 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5520621E80AD for ; Wed, 21 Mar 2012 12:18:11 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1035720obb.31 for ; Wed, 21 Mar 2012 12:18:11 -0700 (PDT) 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=f5hUBGmx9RC7HLJAc+9tAeNT0PqCDuIzCKd3/75Ya18=; b=TancyHsU1UfVBIp088X75RS7OYsbskW4OWa60W7VfdAoB9mEEz1flpJb93mQtH+lyC 6LfzeiLLCb+3bGQ/1Rgqja9k9NkK5P1PcB4A79HLooF08rpJ3xqzkhun9jhNRBYJEmgd rBPny4mF8GQhXoxz69jSjPnTQ6qYcRJt4jmzAFOoT23ecyTXjw68FyPXAXa3IexgJS2r 5rvnaMLhAMFJy/7YM8ZVObVESX71/Ga2Hq4J2nMIAr0jIdSh8Eb1zvzr1M09K34ce5xi XZ9mEM+OmO2k2d0KHkvb0WcGfXtJvLoJi0T64ovJypGvgDgGhc532hGd1pbRqVybwzQr Xa5A== MIME-Version: 1.0 Received: by 10.182.179.68 with SMTP id de4mr6356700obc.13.1332357490936; Wed, 21 Mar 2012 12:18:10 -0700 (PDT) Received: by 10.182.134.73 with HTTP; Wed, 21 Mar 2012 12:18:10 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Mar 2012 12:18:10 -0700 Message-ID: From: Vishwas Manral To: Stephen Hanna Content-Type: multipart/alternative; boundary=e89a8f6433a0f60aeb04bbc5a6d1 Cc: IPsecme WG Subject: Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 19:18:12 -0000 --e89a8f6433a0f60aeb04bbc5a6d1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Steve, This is unclear to me. Isn't it routing that we send a packet across to a closer gateway/ router? What does everything mean in the question below? If we are talking about say security and routing, I think that is true. The "logical" gateway (could be multiple interactions and devices) should be able to provide the functionality. Thanks, Vishwas On Tue, Mar 20, 2012 at 6:33 PM, Stephen Hanna wrote: > Please comment on Suggested Resolution. Note that Yaron has > already supplied his comment below. > > Steve > > -----Original Message----- > From: ipsecme issue tracker [mailto:trac@tools.ietf.org] > Sent: Tuesday, March 20, 2012 6:59 PM > To: yaronf.ietf@gmail.com; > draft-ietf-ipsecme-p2p-vpn-problem@tools.ietf.org > Subject: [ipsecme] #214: Should gateways figure things out completely or > just punt endpoints to a closer gateway? > > #214: Should gateways figure things out completely or just punt endpoints > to a > closer gateway? > > Suggested Resolution: We should not specify this in the problem statemen= t. > It should be specified in the solution. > > YS: sounds like a requirements-level question to me. > > -- > -------------------------+-----------------------------------------------= -- > Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn- > yaronf.ietf@=85 | problem@=85 > Type: defect | Status: new > Priority: normal | Milestone: > Component: p2p-vpn- | Severity: - > problem | Keywords: > Resolution: | > -------------------------+-----------------------------------------------= -- > > Ticket URL: < > http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/214#comment:1> > ipsecme > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --e89a8f6433a0f60aeb04bbc5a6d1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Steve,

This is unclear to me. Isn't it routing that we send a= packet across to a closer gateway/ router? What does everything mean in th= e question below?

If we are talking about say security and routing, = I think that is true. The "logical" gateway (could be multiple in= teractions and devices) should be able to provide the functionality.

Thanks,
Vishwas

On Tue, Mar 20, 2012 a= t 6:33 PM, Stephen Hanna <shanna@juniper.net> wrote:
Please comment on Suggested Resolution. Note that Yaron has
already supplied his comment below.

Steve

-----Original Message-----
From: ipsecme issue tracker [mailto:= trac@tools.ietf.org]
Sent: Tuesday, March 20, 2012 6:59 PM
To: yaronf.ietf@gmail.com; draft-iet= f-ipsecme-p2p-vpn-problem@tools.ietf.org
Subject: [ipsecme] #214: Should gateways figure things out completely or ju= st punt endpoints to a closer gateway?

#214: Should gateways figure things out completely or just punt endpoints t= o a
closer gateway?

=A0Suggested Resolution: We should not specify this in the problem statemen= t.
=A0It should be specified in the solution.

=A0YS: sounds like a requirements-level question to me.

--
-------------------------+-------------------------------------------------=
=A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0Owner: =A0draft-ietf-= ipsecme-p2p-vpn-
=A0yaronf.ietf@=85 =A0 =A0 =A0 =A0 =A0| =A0problem@=85
=A0 =A0 =A0Type: =A0defect =A0 =A0 =A0| =A0 =A0 Status: =A0new
=A0Priority: =A0normal =A0 =A0 =A0| =A0Milestone:
=A0Component: =A0p2p-vpn- =A0 =A0| =A0 Severity: =A0-
=A0problem =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Keywords:
Resolution: =A0 =A0 =A0 =A0 =A0 =A0 =A0|
-------------------------+-------------------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/ipsecme/tr= ac/ticket/214#comment:1>
ipsecme <ht= tp://tools.ietf.org/ipsecme/>

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

--e89a8f6433a0f60aeb04bbc5a6d1-- From vishwas.ietf@gmail.com Wed Mar 21 12:22:53 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DABD21F85D1 for ; Wed, 21 Mar 2012 12:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHu603K5UgIH for ; Wed, 21 Mar 2012 12:22:52 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C341421F85CF for ; Wed, 21 Mar 2012 12:22:51 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1409027ghb.31 for ; Wed, 21 Mar 2012 12:22:51 -0700 (PDT) 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=ifIzODzz4Yx1uxGKNeHT8qNHfqqz6zR+8COwFmgah8o=; b=MbG8Sr7J+kWxQ912x5WlC8xbcHag+b0H4aWsDWcubIgHRvBYIuuy0x3EZRFB5bywas mjddyClUypLCNuD3s2VNQi0EfETBUTYMHnTwlrGjIqjoXPYuc/LTBEn4otc/CzLa4kdQ 5doZu2KO2U61Itfvh6rvZZgycZuMVk8VbrDSkkwIscCsiaJ7/2Vx8Ge4DGyD3jyp1oAg innO1hnn6rYQk7I+nSxKH3bytFyTdoRK+BueHYCtFtOgIWgAoS/T30HQFmArZbKCh0Qw rijIs6Cd662RUNDCTl/9yz7ZbWR1jQgt/vxDxT00kqjEtmT2vnkM6Mbx6QWQLpHB6WcP DV7w== MIME-Version: 1.0 Received: by 10.60.20.10 with SMTP id j10mr6547096oee.33.1332357771368; Wed, 21 Mar 2012 12:22:51 -0700 (PDT) Received: by 10.182.134.73 with HTTP; Wed, 21 Mar 2012 12:22:51 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Mar 2012 12:22:51 -0700 Message-ID: From: Vishwas Manral To: Stephen Hanna Content-Type: multipart/alternative; boundary=e89a8fb205bcad1a5304bbc5b770 Cc: IPsecme WG Subject: Re: [IPsec] [ipsecme] #216: Multiple interfaces or mobile endpoint X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 19:22:54 -0000 --e89a8fb205bcad1a5304bbc5b770 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Steve, Branch routers have 3G/ 4G interfaces as backups for the primary interface and sometimes even multiple 3G/ 4G interfaces with no wired interface at all to the backend. I however do not see any issue that occurs as a result of this. Currently if an interface goes down the tunnel is torn down. Is the question about bonding the multiple interfaces instead? Thanks, Vishwas On Tue, Mar 20, 2012 at 6:36 PM, Stephen Hanna wrote: > Another issue. Please comment. > > And don't miss Yaron's comment below. > > Thanks, > > Steve > > -----Original Message----- > From: ipsecme issue tracker [mailto:trac@tools.ietf.org] > Sent: Tuesday, March 20, 2012 6:57 PM > To: yaronf.ietf@gmail.com; > draft-ietf-ipsecme-p2p-vpn-problem@tools.ietf.org > Subject: [ipsecme] #216: Multiple interfaces or mobile endpoint > > #216: Multiple interfaces or mobile endpoint > > What if an endpoint has multiple interfaces and/or is mobile? > Which tunnels should be torn down as this endpoint moves around, > sometimes behind a gateway and sometimes not? > > Suggested Resolution: We should not specify this in the problem > statement. It should be specified in the solution. > > YS: sounds like a requirement question to me. In fact we may be > able to simplify things by making this issue an explicit non-goal. > > -- > -------------------------+-----------------------------------------------= -- > Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn- > yaronf.ietf@=85 | problem@=85 > Type: defect | Status: new > Priority: normal | Milestone: > Component: p2p-vpn- | Severity: - > problem | Keywords: > Resolution: | > -------------------------+-----------------------------------------------= -- > > Ticket URL: < > http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/216#comment:1> > ipsecme > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --e89a8fb205bcad1a5304bbc5b770 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Steve,

Branch routers have 3G/ 4G interfaces as backups for the p= rimary interface and sometimes even multiple 3G/ 4G interfaces with no wire= d interface at all to the backend.

I however do not see any issue th= at occurs as a result of this. Currently if an interface goes down the tunn= el is torn down. Is the question about bonding the multiple interfaces inst= ead?

Thanks,
Vishwas

On Tue, Mar 20, 20= 12 at 6:36 PM, Stephen Hanna <shanna@juniper.net> wrote:
Another issue. Please comment.

And don't miss Yaron's comment below.

Thanks,

Steve

-----Original Message-----
From: ipsecme issue tracker [mailto:= trac@tools.ietf.org]
Sent: Tuesday, March 20, 2012 6:57 PM
To: yaronf.ietf@gmail.com; draft-iet= f-ipsecme-p2p-vpn-problem@tools.ietf.org
Subject: [ipsecme] #216: Multiple interfaces or mobile endpoint

#216: Multiple interfaces or mobile endpoint

=A0What if an endpoint has multiple interfaces and/or is mobile?
=A0Which tunnels should be torn down as this endpoint moves around,
=A0sometimes behind a gateway and sometimes not?

=A0Suggested Resolution: We should not specify this in the problem
=A0statement. It should be specified in the solution.

=A0YS: sounds like a requirement question to me. In fact we may be
=A0able to simplify things by making this issue an explicit non-goal.

--
-------------------------+-------------------------------------------------=
=A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0Owner: =A0draft-ietf-= ipsecme-p2p-vpn-
=A0yaronf.ietf@=85 =A0 =A0 =A0 =A0 =A0| =A0problem@=85
=A0 =A0 =A0Type: =A0defect =A0 =A0 =A0| =A0 =A0 Status: =A0new
=A0Priority: =A0normal =A0 =A0 =A0| =A0Milestone:
=A0Component: =A0p2p-vpn- =A0 =A0| =A0 Severity: =A0-
=A0problem =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Keywords:
Resolution: =A0 =A0 =A0 =A0 =A0 =A0 =A0|
-------------------------+-------------------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/ipsecme/tr= ac/ticket/216#comment:1>
ipsecme <ht= tp://tools.ietf.org/ipsecme/>

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

--e89a8fb205bcad1a5304bbc5b770-- From vishwas.ietf@gmail.com Wed Mar 21 12:24:15 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7282821E80AD for ; Wed, 21 Mar 2012 12:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.881 X-Spam-Level: X-Spam-Status: No, score=-3.881 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOcmWftWnT1o for ; Wed, 21 Mar 2012 12:24:09 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 42ABA21E80AC for ; Wed, 21 Mar 2012 12:24:09 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1039673obb.31 for ; Wed, 21 Mar 2012 12:24:08 -0700 (PDT) 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=GNTc6S/AZR2PaRTRWUIXtFkqjJmoWDPwN7PXYfM9Pro=; b=jlsCREE0iwqMjH3igGF4B1+IalZuhbAjIKwAXWstSJoY+0Se0SmZDD42lv5HutPOqX J1fUtKOA4iGJ06ZXs9LuovVZVuv6W5LCGgpqBxyHyvGtRB3E04s6V6cOHcesTlpkXEhq JWs7wPc0KpOiHOsj0a4jgS9OSNZqYEkpSibskAJcboc2V2JT1cixo8xIkop6BIcTHcbu H+G6GcP7PC5dugUsc12vfFrKJt2zliCejsUWEWsE3ee95jTl8hjARnkhI97LjipSGzzF ZxznkBgej/vHvoZ2EqEdeFH0Bx1deO1/c9CxTAmbKJBmzBFuP3zDclC8owq9Bsi8+3pK AqIg== MIME-Version: 1.0 Received: by 10.182.53.66 with SMTP id z2mr6315573obo.3.1332357848950; Wed, 21 Mar 2012 12:24:08 -0700 (PDT) Received: by 10.182.134.73 with HTTP; Wed, 21 Mar 2012 12:24:08 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Mar 2012 12:24:08 -0700 Message-ID: From: Vishwas Manral To: Stephen Hanna Content-Type: multipart/alternative; boundary=f46d0447a02b4ce87104bbc5bc65 Cc: IPsecme WG Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 19:24:16 -0000 --f46d0447a02b4ce87104bbc5bc65 Content-Type: text/plain; charset=ISO-8859-1 Hi Steve, I think this is an important requirement for sure. Thanks, Vishwas On Tue, Mar 20, 2012 at 6:36 PM, Stephen Hanna wrote: > Another issue to comment on. > > Steve > > -----Original Message----- > From: ipsecme issue tracker [mailto:trac@tools.ietf.org] > Sent: Tuesday, March 20, 2012 7:01 PM > To: yaronf.ietf@gmail.com; > draft-ietf-ipsecme-p2p-vpn-problem@tools.ietf.org > Subject: [ipsecme] #217: Temporary credentials > > #217: Temporary credentials > > Endpoints may require temporary credentials in order to establish a secure > connection to another endpoint. > > Suggested Resolution: Put this in the requirements section. > > -- > --f46d0447a02b4ce87104bbc5bc65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Steve,

I think this is an important requirement for sure.

= Thanks,
Vishwas

On Tue, Mar 20, 2012 a= t 6:36 PM, Stephen Hanna <shanna@juniper.net> wrote:
Another issue to comment on.

Steve

-----Original Message-----
From: ipsecme issue tracker [mailto:= trac@tools.ietf.org]
Sent: Tuesday, March 20, 2012 7:01 PM
To: yaronf.ietf@gmail.com; draft-iet= f-ipsecme-p2p-vpn-problem@tools.ietf.org
Subject: [ipsecme] #217: Temporary credentials

#217: Temporary credentials

=A0Endpoints may require temporary credentials in order to establish a secu= re
=A0connection to another endpoint.

=A0Suggested Resolution: Put this in the requirements section.

--

--f46d0447a02b4ce87104bbc5bc65-- From vishwas.ietf@gmail.com Wed Mar 21 12:26:59 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE30321E80C3 for ; Wed, 21 Mar 2012 12:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.874 X-Spam-Level: X-Spam-Status: No, score=-3.874 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psm6n1c3VaBi for ; Wed, 21 Mar 2012 12:26:59 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id F366321E80C5 for ; Wed, 21 Mar 2012 12:26:58 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1413107ghb.31 for ; Wed, 21 Mar 2012 12:26:58 -0700 (PDT) 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=SMbuNlZ/+8KrUxtHqIVBtHO+lswEnUFIQQz+BcrmjL4=; b=G9mxBH/AStLV05N5hxd5gCSQHjiUGpS38EDWBV8Oz0EszpDSCTrs18fWaCLwercyUH SCKSFQ9MAu0Ix1x/m84ipblqdDXyRBBAzBKb1VK3dXo2R++1AztPUlu+HT2IUBQX6cp8 UtMaFoSml+GHBT/qOPGD3rdf5gzhCKoiHg/J5yy37vqeVZSZRd18mF87EVF5bKGygV8o jtLhpmyxCAkC7k349DiZE3QSnWVDyw7onavwT4WgD0kOF3yIZezezGmXakZcd3uWKC2c PRR4+74mtCHAxHq4MNr6qqZZxIZllrUiiUTLIGZJgpJeRMeQv5t49ijA3SW8bq3Jt5UL p5RQ== MIME-Version: 1.0 Received: by 10.182.179.68 with SMTP id de4mr6390440obc.13.1332358018494; Wed, 21 Mar 2012 12:26:58 -0700 (PDT) Received: by 10.182.134.73 with HTTP; Wed, 21 Mar 2012 12:26:58 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Mar 2012 12:26:58 -0700 Message-ID: From: Vishwas Manral To: Stephen Hanna Content-Type: multipart/alternative; boundary=e89a8f6433a067f02504bbc5c68a Cc: IPsecme WG Subject: Re: [IPsec] [ipsecme] #218: Exhaustive configuration X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 19:26:59 -0000 --e89a8f6433a067f02504bbc5c68a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Steve, Like I mentioned the problem is not just exhaustive configuration but also the fact that configuration parameters like IP address change. I agree we should expand the section you mention below. Thanks, Vishwas On Tue, Mar 20, 2012 at 6:37 PM, Stephen Hanna wrote: > Keeping you entertained in the week before IETF 83... > > Steve > > -----Original Message----- > From: ipsecme issue tracker [mailto:trac@tools.ietf.org] > Sent: Tuesday, March 20, 2012 7:03 PM > To: yaronf.ietf@gmail.com; > draft-ietf-ipsecme-p2p-vpn-problem@tools.ietf.org > Subject: [ipsecme] #218: Exhaustive configuration > > #218: Exhaustive configuration > > Exhaustive configuration can work fine if there are good automated > configuration protocols. > > Suggested Resolution: Exhaustive configuration doesn't scale for > constrained devices in large networks. Explain this in section 3.1. > > -- > -------------------------+-----------------------------------------------= -- > Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn- > yaronf.ietf@=85 | problem@=85 > Type: defect | Status: new > Priority: normal | Milestone: > Component: p2p-vpn- | Severity: - > problem | > Keywords: | > -------------------------+-----------------------------------------------= -- > > Ticket URL: > ipsecme > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --e89a8f6433a067f02504bbc5c68a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Steve,

Like I mentioned the problem is not just exhaustive config= uration but also the fact that configuration parameters like IP address cha= nge.

I agree we should expand the section you mention below.

Thanks,
Vishwas

On Tue, Mar 20, 2012 a= t 6:37 PM, Stephen Hanna <shanna@juniper.net> wrote:
Keeping you entertained in the week before IETF 83...

Steve

-----Original Message-----
From: ipsecme issue tracker [mailto:= trac@tools.ietf.org]
Sent: Tuesday, March 20, 2012 7:03 PM
To: yaronf.ietf@gmail.com; draft-iet= f-ipsecme-p2p-vpn-problem@tools.ietf.org
Subject: [ipsecme] #218: Exhaustive configuration

#218: Exhaustive configuration

=A0Exhaustive configuration can work fine if there are good automated
=A0configuration protocols.

=A0Suggested Resolution: Exhaustive configuration doesn't scale for
=A0constrained devices in large networks. Explain this in section 3.1.

--
-------------------------+-------------------------------------------------=
=A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Owner: =A0draft-ietf-= ipsecme-p2p-vpn-
=A0yaronf.ietf@=85 =A0 =A0 =A0 =A0 =A0| =A0problem@=85
=A0 =A0 Type: =A0defect =A0 =A0 =A0 | =A0 =A0 Status: =A0new
=A0Priority: =A0normal =A0 =A0 =A0 | =A0Milestone:
Component: =A0p2p-vpn- =A0 =A0 | =A0 Severity: =A0-
=A0problem =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
-------------------------+-------------------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/= 218>
ipsecme <ht= tp://tools.ietf.org/ipsecme/>

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

--e89a8f6433a067f02504bbc5c68a-- From shanna@juniper.net Wed Mar 21 12:39:55 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CF821E80E2 for ; Wed, 21 Mar 2012 12:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SX+h0ZOpJtpG for ; Wed, 21 Mar 2012 12:39:52 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC3C21E80D7 for ; Wed, 21 Mar 2012 12:39:52 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKT2ouh8SIoZD/BgR01nTG1+MVw4H6BlEb@postini.com; Wed, 21 Mar 2012 12:39:52 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 21 Mar 2012 12:37:20 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 21 Mar 2012 12:37:19 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 21 Mar 2012 15:36:42 -0400 From: Stephen Hanna To: Vishwas Manral Date: Wed, 21 Mar 2012 15:36:39 -0400 Thread-Topic: [IPsec] [ipsecme] #216: Multiple interfaces or mobile endpoint Thread-Index: Ac0HmAPEPWwh+9aGSPG0RJBHZSES7AAAMdxA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AC6674AB7BC78549BB231821ABF7A9AEB82D99D685EMBX01WFjnprn_" MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] [ipsecme] #216: Multiple interfaces or mobile endpoint X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 19:39:55 -0000 --_000_AC6674AB7BC78549BB231821ABF7A9AEB82D99D685EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This issue was based on Michael Richardson's March 12, 2012 email where he = said: Finally, say my laptop is normally part of such a mesh (as a /32,/128 subnet). When I'm "trapped" behind a NAPT, I naturally use NAT-traversal to get out and join the MESH. Now, what happens if I come to the office, which is itself part of the MESH. This is not a new problem, btw, but normally I have only a single tunnel to bring up or down. Now that I have all these tunnels and policy. Should any of this MESH continue to be used? Are there some non-convex topologies where this can be important (should some traffic be double encrypted as a result?), or is it all just out of scope. (We dealt with these things as implementation challenges when combining an extruded IPsec tunnel with RFC4322. We had co-terminal tunnels of the near kind, which was solved, and co-terminal tunnels of the far kind, which we did not manage to implement) For the above, consider a laptop/tablet which might now have multiple exit routes via 3G+wifi+wired... and that it's moving. I hope that helps clarify the issue. If not, perhaps you and Michael can cl= arify and discuss it further. Thanks, Steve From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Wednesday, March 21, 2012 3:23 PM To: Stephen Hanna Cc: IPsecme WG Subject: Re: [IPsec] [ipsecme] #216: Multiple interfaces or mobile endpoint Hi Steve, Branch routers have 3G/ 4G interfaces as backups for the primary interface = and sometimes even multiple 3G/ 4G interfaces with no wired interface at al= l to the backend. I however do not see any issue that occurs as a result of this. Currently i= f an interface goes down the tunnel is torn down. Is the question about bon= ding the multiple interfaces instead? Thanks, Vishwas On Tue, Mar 20, 2012 at 6:36 PM, Stephen Hanna > wrote: Another issue. Please comment. And don't miss Yaron's comment below. Thanks, Steve -----Original Message----- From: ipsecme issue tracker [mailto:trac@tools.ietf.org] Sent: Tuesday, March 20, 2012 6:57 PM To: yaronf.ietf@gmail.com; draft-ietf-ipsecme= -p2p-vpn-problem@tools.ietf.org Subject: [ipsecme] #216: Multiple interfaces or mobile endpoint #216: Multiple interfaces or mobile endpoint What if an endpoint has multiple interfaces and/or is mobile? Which tunnels should be torn down as this endpoint moves around, sometimes behind a gateway and sometimes not? Suggested Resolution: We should not specify this in the problem statement. It should be specified in the solution. YS: sounds like a requirement question to me. In fact we may be able to simplify things by making this issue an explicit non-goal. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn- yaronf.ietf@... | problem@... Type: defect | Status: new Priority: normal | Milestone: Component: p2p-vpn- | Severity: - problem | Keywords: Resolution: | -------------------------+------------------------------------------------- Ticket URL: ipsecme _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_AC6674AB7BC78549BB231821ABF7A9AEB82D99D685EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This issu= e was based on Michael Richardson’s March 12, 2012 email where he sai= d:

 

Finally, say my laptop is normally part of such a mesh (as a /32,= /128

subnet).  When I'm "trapped" = behind a NAPT, I naturally use

NAT-traversal to g= et out and join the MESH. 

=  

Now, what happens if I come to the office, which is itself= part of the

MESH. This is not a new problem, btw= , but normally I have only a single

tunnel to bri= ng up or down.  Now that I have all these tunnels and

policy.  Should any of this MESH continue to be used?  =

Are there some non-convex topologies where this = can be important (should

some traffic be double e= ncrypted as a result?), or is it all just out of

= scope.   (We dealt with these things as implementation challenges= when

combining an extruded IPsec tunnel with RFC= 4322.  We had

co-terminal tunnels of the = near kind, which was solved, and co-terminal

tun= nels of the far kind, which we did not manage to implement)

 

For the above, consider a lapto= p/tablet which might now have multiple

exit route= s via 3G+wifi+wired...  and that it's moving.

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>I hope that helps clarify the issue. If not, perhaps you and Michael = can clarify and discuss it further.

 

Thanks,

 

Steve

 

F= rom: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Wed= nesday, March 21, 2012 3:23 PM
To: Stephen Hanna
Cc: IP= secme WG
Subject: Re: [IPsec] [ipsecme] #216: Multiple interfaces= or mobile endpoint

<= o:p> 

Hi = Steve,

Branch routers have 3G/ 4G interfaces as backups for the prim= ary interface and sometimes even multiple 3G/ 4G interfaces with no wired i= nterface at all to the backend.

I however do not see any issue that = occurs as a result of this. Currently if an interface goes down the tunnel = is torn down. Is the question about bonding the multiple interfaces instead= ?

Thanks,
Vishwas

On Tue,= Mar 20, 2012 at 6:36 PM, Stephen Hanna <shanna@juniper.net> wrote:

Another issue. Please comment.

And don't miss Yaron's comment below= .

Thanks,

Steve

-----Original Message-----
From: ip= secme issue tracker [mailto:trac@too= ls.ietf.org]
Sent: Tuesday, March 20, 2012 6:57 PM
To: yaronf.ietf@gmail.com; draft-ietf-ipsecme-p2p-= vpn-problem@tools.ietf.org
Subject: [ipsecme] #216: Multiple interfa= ces or mobile endpoint

#216: Multiple interfaces or mobile endpoint<= br>
 What if an endpoint has multiple interfaces and/or is mobile?<= br> Which tunnels should be torn down as this endpoint moves around, sometimes behind a gateway and sometimes not?

 Suggeste= d Resolution: We should not specify this in the problem
 statement.= It should be specified in the solution.

 YS: sounds like a req= uirement question to me. In fact we may be
 able to simplify things= by making this issue an explicit non-goal.

--
------------------= -------+-------------------------------------------------
 Reporter= :              |      Own= er:  draft-ietf-ipsecme-p2p-vpn-
 yaronf.ietf@…   &= nbsp;      |  problem@…
     Ty= pe:  defect      |     Status:  new
&= nbsp;Priority:  normal      |  Milestone:
 = ;Component:  p2p-vpn-    |   Severity:  -
 = ;problem                |   Ke= ywords:
Resolution:              |-------------------------+------------------------------------------------= -

Ticket URL: <http://trac.tools.ietf.org/wg/i= psecme/trac/ticket/216#comment:1>
ipsecme <http://tools.ietf.org/ipsecme/>

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

 

= --_000_AC6674AB7BC78549BB231821ABF7A9AEB82D99D685EMBX01WFjnprn_-- From shanna@juniper.net Wed Mar 21 13:01:43 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2612521E80C8 for ; Wed, 21 Mar 2012 13:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoHiC86U8Syk for ; Wed, 21 Mar 2012 13:01:40 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 176A821E80BB for ; Wed, 21 Mar 2012 13:01:39 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKT2ozov7bEQqhiA8bxkZkCIBo593JaZ0B@postini.com; Wed, 21 Mar 2012 13:01:39 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 21 Mar 2012 13:00:24 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 21 Mar 2012 15:59:28 -0400 From: Stephen Hanna To: Vishwas Manral Date: Wed, 21 Mar 2012 15:59:26 -0400 Thread-Topic: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway? Thread-Index: Ac0Hl17wcpcxX7pITXijq3/q/v7hwwAAWDkw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AC6674AB7BC78549BB231821ABF7A9AEB82D99D6FBEMBX01WFjnprn_" MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 20:01:43 -0000 --_000_AC6674AB7BC78549BB231821ABF7A9AEB82D99D6FBEMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Again, this issue was based on Michael Richardson's March 12 email, which s= aid: The dual trunk scenario should perhaps be further motivated and clarified. Are there some situations where a spoke should not contact another spoke directly, but in fact should contact a hub closer to the other spoke. I can see some solutions where a hub would not have complete knowledge of the mesh, and so would in fact simply punt a connection closer. I hope this clarifies the issue for you. I think that Michael is asking an important question. There are many ways t= o solve the P2P VPN problem. One way is to have satellites with little conf= iguration that connect to core gateways with lots of dynamic information. A= core gateway (a "hub" in Michael's parlance) can download things to a sate= llite (maybe a new SPD and PAD, credentials, etc.), thus causing some traff= ic from the satellite to be sent to a different core gateway or satellite. = In that circumstance, I think Michael's question is about whether the core = gateway that a satellite initially connects (which I'll call the "initial c= ore gateway") to should be expected to have or obtain all the information n= eeded to configure the satellite or whether the initial core gateway can se= nd the satellite to another core gateway where it can get more information.= At least, that's how I understand Michael's question. Perhaps he can affir= m or deny this interpretation. Personally, I think that this question is premature. It presupposes too muc= h about the eventual solution. That's why I think it should be answered in = the solution not included in the problem statement. Apparently, Yaron doesn= 't agree with me. I'd like to hear more from him on this matter. Does he be= lieve that all solutions to this problem (or at least all the good ones) mu= st necessarily employ the model that I described above? What about a soluti= on that doesn't rely on core gateways to refer satellites but instead has s= atellites querying for the information that they need? Or one that has some= external entity (not the core gateway) configuring the satellites? In my v= iew, there may be many possible P2P VPN solutions. However, I'm not an IPse= c expert. Maybe this is the only practical approach. I'd like to hear views= from Yaron and from others on this topic. Thanks, Steve From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of V= ishwas Manral Sent: Wednesday, March 21, 2012 3:18 PM To: Stephen Hanna Cc: IPsecme WG Subject: Re: [IPsec] [ipsecme] #214: Should gateways figure things out comp= letely or just punt endpoints to a closer gateway? Hi Steve, This is unclear to me. Isn't it routing that we send a packet across to a c= loser gateway/ router? What does everything mean in the question below? If we are talking about say security and routing, I think that is true. The= "logical" gateway (could be multiple interactions and devices) should be a= ble to provide the functionality. Thanks, Vishwas On Tue, Mar 20, 2012 at 6:33 PM, Stephen Hanna > wrote: Please comment on Suggested Resolution. Note that Yaron has already supplied his comment below. Steve -----Original Message----- From: ipsecme issue tracker [mailto:trac@tools.ietf.org] Sent: Tuesday, March 20, 2012 6:59 PM To: yaronf.ietf@gmail.com; draft-ietf-ipsecme= -p2p-vpn-problem@tools.ietf.org Subject: [ipsecme] #214: Should gateways figure things out completely or ju= st punt endpoints to a closer gateway? #214: Should gateways figure things out completely or just punt endpoints t= o a closer gateway? Suggested Resolution: We should not specify this in the problem statement. It should be specified in the solution. YS: sounds like a requirements-level question to me. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn- yaronf.ietf@... | problem@... Type: defect | Status: new Priority: normal | Milestone: Component: p2p-vpn- | Severity: - problem | Keywords: Resolution: | -------------------------+------------------------------------------------- Ticket URL: ipsecme _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_AC6674AB7BC78549BB231821ABF7A9AEB82D99D6FBEMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Again, th= is issue was based on Michael Richardson’s March 12 email, which said= :

 =

The dual trunk scenario should perhaps be further motivated and

clarified.  Are there some situations where a = spoke should not contact

another spoke directly, = but in fact should contact a hub closer to the

ot= her spoke.  I can see some solutions where a hub would not have

complete knowledge of the mesh, and so would in fact si= mply punt a

connection closer.<= /p>

 

I hope this clarifies the issue for you.

<= p class=3DMsoNormal> 

I think that Michael is asking an important question. There are man= y ways to solve the P2P VPN problem. One way is to have satellites with lit= tle configuration that connect to core gateways with lots of dynamic inform= ation. A core gateway (a “hub” in Michael’s parlance) can= download things to a satellite (maybe a new SPD and PAD, credentials, etc.= ), thus causing some traffic from the satellite to be sent to a different c= ore gateway or satellite. In that circumstance, I think Michael’s que= stion is about whether the core gateway that a satellite initially connects= (which I’ll call the “initial core gateway”) to should b= e expected to have or obtain all the information needed to configure the sa= tellite or whether the initial core gateway can send the satellite to anoth= er core gateway where it can get more information. At least, that’s h= ow I understand Michael’s question. Perhaps he can affirm or deny thi= s interpretation.

&nb= sp;

Personally, I think that th= is question is premature. It presupposes too much about the eventual soluti= on. That’s why I think it should be answered in the solution not incl= uded in the problem statement. Apparently, Yaron doesn’t agree with m= e. I’d like to hear more from him on this matter. Does he believe tha= t all solutions to this problem (or at least all the good ones) must necess= arily employ the model that I described above? What about a solution that d= oesn’t rely on core gateways to refer satellites but instead has sate= llites querying for the information that they need? Or one that has some ex= ternal entity (not the core gateway) configuring the satellites? In my view= , there may be many possible P2P VPN solutions. However, I’m not an I= Psec expert. Maybe this is the only practical approach. I’d like to h= ear views from Yaron and from others on this topic.

 

= Thanks,

 =

Steve

 

<= p class=3DMsoNormal>From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.o= rg] On Behalf Of Vishwas Manral
Sent: Wednesday, March 21,= 2012 3:18 PM
To: Stephen Hanna
Cc: IPsecme WG
Su= bject: Re: [IPsec] [ipsecme] #214: Should gateways figure things out co= mpletely or just punt endpoints to a closer gateway?

<= /div>

 

Hi Steve,

This is unclear to me. Isn't= it routing that we send a packet across to a closer gateway/ router? What = does everything mean in the question below?

If we are talking about = say security and routing, I think that is true. The "logical" gat= eway (could be multiple interactions and devices) should be able to provide= the functionality.

Thanks,
Vishwas

On Tue, Mar 20, 2012 at 6:33 PM, Stephen Hanna <shanna@juniper.net> wrote:

=

Please comment on Suggested Resolution. Note that Yaro= n has
already supplied his comment below.

Steve

-----Origi= nal Message-----
From: ipsecme issue tracker [mailto:trac@tools.ietf.org]
Sent: Tuesday, March 20, 20= 12 6:59 PM
To: yaronf.ietf@gmai= l.com; draft-ietf-ipsecme-p2p-vpn-problem@tools.ietf.org
Subject: [ips= ecme] #214: Should gateways figure things out completely or just punt endpo= ints to a closer gateway?

#214: Should gateways figure things out co= mpletely or just punt endpoints to a
closer gateway?

 Sugges= ted Resolution: We should not specify this in the problem statement.
&nb= sp;It should be specified in the solution.

 YS: sounds like a r= equirements-level question to me.

--
-------------------------+--= -----------------------------------------------
 Reporter:   &= nbsp;          |      Owner:  = draft-ietf-ipsecme-p2p-vpn-
 yaronf.ietf@…     &nbs= p;    |  problem@…
     Type:  = defect      |     Status:  new
 Prior= ity:  normal      |  Milestone:
 Component= :  p2p-vpn-    |   Severity:  -
 problem &= nbsp;              |   Keywords:Resolution:              |
---------= ----------------+-------------------------------------------------

T= icket URL: <http://trac.tools.ietf.org/wg/ipsecme/tra= c/ticket/214#comment:1>
ipsecme <http://tools.ietf.org/ipsecme/>
<= br>_______________________________________________
IPsec mailing listIPsec@ietf.org
https://www.ietf.or= g/mailman/listinfo/ipsec

=  

= --_000_AC6674AB7BC78549BB231821ABF7A9AEB82D99D6FBEMBX01WFjnprn_-- From ghuang@juniper.net Wed Mar 21 13:39:47 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC7D21F8629 for ; Wed, 21 Mar 2012 13:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6OBL2wHar-r for ; Wed, 21 Mar 2012 13:39:46 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7231821F871B for ; Wed, 21 Mar 2012 13:39:46 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKT2o8iptStloSNGWAIzoOYEu++5ncf+gy@postini.com; Wed, 21 Mar 2012 13:39:46 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 21 Mar 2012 13:38:39 -0700 From: Geoffrey Huang To: Vishwas Manral , Stephen Hanna Date: Wed, 21 Mar 2012 13:38:34 -0700 Thread-Topic: [IPsec] [ipsecme] #212: Section 2.2 should be more detailed. Thread-Index: Ac0HopjCZIbDBFi7Sa2cuaB0BJlYJQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] [ipsecme] #212: Section 2.2 should be more detailed. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 20:39:47 -0000 I agree. I believe this is a common use case. -geoff From: Vishwas Manral = > Date: Wed, 21 Mar 2012 12:14:26 -0700 To: Steve Hanna > Cc: "ipsec@ietf.org" > Subject: Re: [IPsec] [ipsecme] #212: Section 2.2 should be more detailed. Hi Stephen, Sounds good to me. Thanks, Vishwas On Tue, Mar 20, 2012 at 6:29 PM, Stephen Hanna > wrote: Third issue. Steve -----Original Message----- From: ipsecme issue tracker [mailto:trac@tools.ietf.org] Sent: Tuesday, March 20, 2012 6:57 PM To: yaronf.ietf@gmail.com; draft-ietf-ipsecme= -p2p-vpn-problem@tools.ietf.org Subject: [ipsecme] #212: Section 2.2 should be more detailed. #212: Section 2.2 should be more detailed. Suggested Resolution: Expand use case using text supplied by Vishwas Manral of HP. In a simple use case we want hub and spoke topology for say the DC and the branches. This would also be true of ATM's connecting to their DC. However for scalability reasons we would not want all traffic to go through the hub. In the ATM example we could want VoIP session to bypass the DC and have a direct connectivity between themselves. There are multiple other uses cases for the same. These new sessions however are temporary, when compared to permanent branch to hub connections. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn- yaronf.ietf@=85 | problem@=85 Type: defect | Status: new Priority: normal | Milestone: Component: p2p-vpn- | Severity: - problem | Keywords: Resolution: | -------------------------+------------------------------------------------- Ticket URL: ipsecme _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ghuang@juniper.net Wed Mar 21 13:44:38 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6875421E8119 for ; Wed, 21 Mar 2012 13:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-janMKqBLz9 for ; Wed, 21 Mar 2012 13:44:38 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id A8FEF21E8101 for ; Wed, 21 Mar 2012 13:44:37 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKT2o9tOEZiSSWKnz2YTIpIvmwPh/3/o0u@postini.com; Wed, 21 Mar 2012 13:44:37 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 21 Mar 2012 13:43:19 -0700 From: Geoffrey Huang To: Vishwas Manral , Stephen Hanna Date: Wed, 21 Mar 2012 13:43:16 -0700 Thread-Topic: [IPsec] [ipsecme] #217: Temporary credentials Thread-Index: Ac0Hoz+Bi7m8y/zBSVug1m2BptxClA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 20:44:38 -0000 I don't understand what "temporary credentials" means. If the intent is to= have some transitive authentication (or redirection of trust hierarchy, at= least) between a gateway and two spoke devices, which are trying to establ= ish an ad-hoc connection, then I agree this would be important to have. -geoff From: Vishwas Manral = > Date: Wed, 21 Mar 2012 12:24:08 -0700 To: Steve Hanna > Cc: "ipsec@ietf.org" > Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials Hi Steve, I think this is an important requirement for sure. Thanks, Vishwas On Tue, Mar 20, 2012 at 6:36 PM, Stephen Hanna > wrote: Another issue to comment on. Steve -----Original Message----- From: ipsecme issue tracker [mailto:trac@tools.ietf.org] Sent: Tuesday, March 20, 2012 7:01 PM To: yaronf.ietf@gmail.com; draft-ietf-ipsecme= -p2p-vpn-problem@tools.ietf.org Subject: [ipsecme] #217: Temporary credentials #217: Temporary credentials Endpoints may require temporary credentials in order to establish a secure connection to another endpoint. Suggested Resolution: Put this in the requirements section. -- From yaronf.ietf@gmail.com Wed Mar 21 14:24:49 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9365C21E8029 for ; Wed, 21 Mar 2012 14:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+1vM-quvnAa for ; Wed, 21 Mar 2012 14:24:49 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id BF3F021E8013 for ; Wed, 21 Mar 2012 14:24:48 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so3817wib.1 for ; Wed, 21 Mar 2012 14:24:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=EXTE26i6O3OoAv+IIWmkGnC3c0UXnQi5k/NHl7uO8ao=; b=S5aVesHBFEdqhCoSF6UhW/fyrlXP/H2W3oUfwWFcyLgbF0Fw/nu+38YHsVVimideb4 Om9R59jLqE2Dc/+QPmH9hv2Mw8Os+AA4y6tNo6vq+9USNyFgjJcp1Ni5FVgZm0a7Vjau x4OBuuCjuONjdiHfU95d8O9GKDBj4UV1/sFKXcAkQbMh6kov/o3K1MceogdrzUB9UQMy eh9rnC/kQCNJTNENVeNV+wJ8Mpl0eR7uOqk7Fac9mpUpN0ZkWKq5XA7tTl5vHXRrnoyV uF5FddghDpGd1cjjSznu58GZG89CFw9y7q8yPpbRqd1gklcEXXc1MutNk2gpHnZvNavi cCRA== Received: by 10.216.135.196 with SMTP id u46mr3031468wei.114.1332365087642; Wed, 21 Mar 2012 14:24:47 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-182-168-20.red.bezeqint.net. [79.182.168.20]) by mx.google.com with ESMTPS id 17sm71627wis.0.2012.03.21.14.24.46 (version=SSLv3 cipher=OTHER); Wed, 21 Mar 2012 14:24:47 -0700 (PDT) Message-ID: <4F6A471D.8090606@gmail.com> Date: Wed, 21 Mar 2012 23:24:45 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Geoffrey Huang References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , Stephen Hanna Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:24:49 -0000 The point of "temporary credentials" is that if these spokes normally use EAP or PSK to authenticate to the gateway, they cannot use these same credentials to auth to one another (because that would expose each spoke to impersonation by the other one). So to support this scenario we must have some other means of authentication. This raises an interesting question: if the spokes are authenticating with certificates, they could in principle use the same credentials to authenticate to one another. So the "temporary credentials" now become *authorization* tokens, basically conveying to gateway's policy. Do we really want to go down this path? Thanks, Yaron On 03/21/2012 10:43 PM, Geoffrey Huang wrote: > I don't understand what "temporary credentials" means. If the intent is to have some transitive authentication (or redirection of trust hierarchy, at least) between a gateway and two spoke devices, which are trying to establish an ad-hoc connection, then I agree this would be important to have. > > -geoff > > From: Vishwas Manral> > Date: Wed, 21 Mar 2012 12:24:08 -0700 > To: Steve Hanna> > Cc: "ipsec@ietf.org"> > Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials > > Hi Steve, > > I think this is an important requirement for sure. > > Thanks, > Vishwas > > On Tue, Mar 20, 2012 at 6:36 PM, Stephen Hanna> wrote: > Another issue to comment on. > > Steve > > -----Original Message----- > From: ipsecme issue tracker [mailto:trac@tools.ietf.org] > Sent: Tuesday, March 20, 2012 7:01 PM > To: yaronf.ietf@gmail.com; draft-ietf-ipsecme-p2p-vpn-problem@tools.ietf.org > Subject: [ipsecme] #217: Temporary credentials > > #217: Temporary credentials > > Endpoints may require temporary credentials in order to establish a secure > connection to another endpoint. > > Suggested Resolution: Put this in the requirements section. > > -- > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From praveenys@juniper.net Wed Mar 21 14:31:29 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABFE21F851B for ; Wed, 21 Mar 2012 14:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TG7RbdvWnvIG for ; Wed, 21 Mar 2012 14:31:29 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id B127A21F8514 for ; Wed, 21 Mar 2012 14:31:28 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKT2pIrztnbRf1OFPq6UWeXvRoIVORuJP3@postini.com; Wed, 21 Mar 2012 14:31:28 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 21 Mar 2012 14:30:38 -0700 From: Praveen Sathyanarayan To: Yaron Sheffer , Geoffrey Huang Date: Wed, 21 Mar 2012 14:30:37 -0700 Thread-Topic: [IPsec] [ipsecme] #217: Temporary credentials Thread-Index: Ac0HqducSVBV63IWTMWEuBWnOecBAw== Message-ID: In-Reply-To: <4F6A471D.8090606@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Stephen Hanna Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:31:29 -0000 Yes. If certificate based authentication was used in the network, there is no need of new credentials. But if pre-shared key based was used, then we need this "temporary credentials". Also, it is required to define the lifetime of this "temporary credentials". For example, if tunnel between spokes are stays beyond lifetime of SA, then can the same "temporary credentials" can be used for rekey? Or new "temporary credentials" should be received from Hub? Thanks, Praveen On 3/21/12 2:24 PM, "Yaron Sheffer" wrote: The point of "temporary credentials" is that if these spokes normally use EAP or PSK to authenticate to the gateway, they cannot use these same credentials to auth to one another (because that would expose each spoke to impersonation by the other one). So to support this scenario we must have some other means of authentication. This raises an interesting question: if the spokes are authenticating with certificates, they could in principle use the same credentials to authenticate to one another. So the "temporary credentials" now become *authorization* tokens, basically conveying to gateway's policy. Do we really want to go down this path? Thanks, Yaron On 03/21/2012 10:43 PM, Geoffrey Huang wrote: > I don't understand what "temporary credentials" means. If the intent is >to have some transitive authentication (or redirection of trust >hierarchy, at least) between a gateway and two spoke devices, which are >trying to establish an ad-hoc connection, then I agree this would be >important to have. > > -geoff > > From: Vishwas=20 >Manral> > Date: Wed, 21 Mar 2012 12:24:08 -0700 > To: Steve Hanna> > Cc:=20 >"ipsec@ietf.org"rg>> > Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials > > Hi Steve, > > I think this is an important requirement for sure. > > Thanks, > Vishwas > > On Tue, Mar 20, 2012 at 6:36 PM, Stephen >Hanna> wrote: > Another issue to comment on. > > Steve > > -----Original Message----- > From: ipsecme issue tracker >[mailto:trac@tools.ietf.org] > Sent: Tuesday, March 20, 2012 7:01 PM > To: yaronf.ietf@gmail.com; >draft-ietf-ipsecme-p2p-vpn-problem@tools.ietf.orge-p2p-vpn-problem@tools.ietf.org> > Subject: [ipsecme] #217: Temporary credentials > > #217: Temporary credentials > > Endpoints may require temporary credentials in order to establish a >secure > connection to another endpoint. > > Suggested Resolution: Put this in the requirements section. > > -- > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Wed Mar 21 14:34:03 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D5921E8115 for ; Wed, 21 Mar 2012 14:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.346 X-Spam-Level: X-Spam-Status: No, score=-9.346 tagged_above=-999 required=5 tests=[AWL=-1.048, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_PREMTR=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLIPP3sqCT+y for ; Wed, 21 Mar 2012 14:34:01 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 960C721F8573 for ; Wed, 21 Mar 2012 14:34:00 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2LLXu5s001747; Wed, 21 Mar 2012 23:33:56 +0200 X-CheckPoint: {4F6A48BB-0-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 21 Mar 2012 23:33:55 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 21 Mar 2012 23:33:55 +0200 From: Yoav Nir To: Stephen Hanna Date: Wed, 21 Mar 2012 23:33:53 +0200 Thread-Topic: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway? Thread-Index: Ac0HqlEq9KoJcHB2RtqaBm80rx2gUg== Message-ID: <3AD5BF8C-ABC5-40F1-8F6D-2C730C70B8E4@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_3AD5BF8CABC540F18F6D2C730C70B8E4checkpointcom_" MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: IPsecme WG Subject: Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:34:03 -0000 --_000_3AD5BF8CABC540F18F6D2C730C70B8E4checkpointcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree that this pre-supposes that the solution will involve "gateways" fi= guring things out for "endpoints" in either one step or more than one step.= It pre-supposes a two-tier system. We've had a presentation in Taipei that did not involve gateways, but rathe= r specialized servers carrying authoritative information, with all the IPse= c hosts, whether gateways or endpoints querying those servers. Those server= s could be specialized IPsec information servers, dispensing PAD and SPD en= tries through a web service, or they could be the DNS system. Either way, t= his is a different model to the one that has the information flowing throug= h the overlay network. So I agree that answering this question is pre-mature. Whatever the model, = there will be an equivalent question, but I think it's too early now. Yoav On Mar 21, 2012, at 9:59 PM, Stephen Hanna wrote: Again, this issue was based on Michael Richardson=92s March 12 email, which= said: The dual trunk scenario should perhaps be further motivated and clarified. Are there some situations where a spoke should not contact another spoke directly, but in fact should contact a hub closer to the other spoke. I can see some solutions where a hub would not have complete knowledge of the mesh, and so would in fact simply punt a connection closer. I hope this clarifies the issue for you. I think that Michael is asking an important question. There are many ways t= o solve the P2P VPN problem. One way is to have satellites with little conf= iguration that connect to core gateways with lots of dynamic information. A= core gateway (a =93hub=94 in Michael=92s parlance) can download things to = a satellite (maybe a new SPD and PAD, credentials, etc.), thus causing some= traffic from the satellite to be sent to a different core gateway or satel= lite. In that circumstance, I think Michael=92s question is about whether t= he core gateway that a satellite initially connects (which I=92ll call the = =93initial core gateway=94) to should be expected to have or obtain all the= information needed to configure the satellite or whether the initial core = gateway can send the satellite to another core gateway where it can get mor= e information. At least, that=92s how I understand Michael=92s question. Pe= rhaps he can affirm or deny this interpretation. Personally, I think that this question is premature. It presupposes too muc= h about the eventual solution. That=92s why I think it should be answered i= n the solution not included in the problem statement. Apparently, Yaron doe= sn=92t agree with me. I=92d like to hear more from him on this matter. Does= he believe that all solutions to this problem (or at least all the good on= es) must necessarily employ the model that I described above? What about a = solution that doesn=92t rely on core gateways to refer satellites but inste= ad has satellites querying for the information that they need? Or one that = has some external entity (not the core gateway) configuring the satellites?= In my view, there may be many possible P2P VPN solutions. However, I=92m n= ot an IPsec expert. Maybe this is the only practical approach. I=92d like t= o hear views from Yaron and from others on this topic. Thanks, Steve From: ipsec-bounces@ietf.org [mailto:ipsec-b= ounces@ietf.org] On Behalf Of Vishwas Manral Sent: Wednesday, March 21, 2012 3:18 PM To: Stephen Hanna Cc: IPsecme WG Subject: Re: [IPsec] [ipsecme] #214: Should gateways figure things out comp= letely or just punt endpoints to a closer gateway? Hi Steve, This is unclear to me. Isn't it routing that we send a packet across to a c= loser gateway/ router? What does everything mean in the question below? If we are talking about say security and routing, I think that is true. The= "logical" gateway (could be multiple interactions and devices) should be a= ble to provide the functionality. Thanks, Vishwas On Tue, Mar 20, 2012 at 6:33 PM, Stephen Hanna > wrote: Please comment on Suggested Resolution. Note that Yaron has already supplied his comment below. Steve -----Original Message----- From: ipsecme issue tracker [mailto:trac@tools.ietf.org] Sent: Tuesday, March 20, 2012 6:59 PM To: yaronf.ietf@gmail.com; draft-ietf-ipsecme= -p2p-vpn-problem@tools.ietf.org Subject: [ipsecme] #214: Should gateways figure things out completely or ju= st punt endpoints to a closer gateway? #214: Should gateways figure things out completely or just punt endpoints t= o a closer gateway? Suggested Resolution: We should not specify this in the problem statement. It should be specified in the solution. YS: sounds like a requirements-level question to me. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn- yaronf.ietf@=85 | problem@=85 Type: defect | Status: new Priority: normal | Milestone: Component: p2p-vpn- | Severity: - problem | Keywords: Resolution: | -------------------------+------------------------------------------------- Ticket URL: ipsecme _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_3AD5BF8CABC540F18F6D2C730C70B8E4checkpointcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree that this pre-supposes that the solution will involve "gateways" f= iguring things out for "endpoints" in either one step or more than one step= . It pre-supposes a two-tier system.

We've had a present= ation in Taipei that did not involve gateways, but rather specialized serve= rs carrying authoritative information, with all the IPsec hosts, whether ga= teways or endpoints querying those servers. Those servers could be speciali= zed IPsec information servers, dispensing PAD and SPD entries through a web= service, or they could be the DNS system. Either way, this is a different = model to the one that has the information flowing through the overlay netwo= rk.

So I agree that answering this question is pre= -mature. Whatever the model, there will be an equivalent question, but I th= ink it's too early now.

Yoav

On Mar 21, 2012, at 9:59 PM, Stephen Hanna wrote:

Again, this issue was based on Michael R= ichardson=92s March 12 email, which said:
 
The dual trunk scenario should perhaps be furthe= r motivated and
clarified.  Are there some situations where= a spoke should not contact
another spoke directly, but in fact = should contact a hub closer to the
other spoke.  I can see = some solutions where a hub would not have
complete knowledge of = the mesh, and so would in fact simply punt a
connection closer.<= o:p>
 
I hope this clarifies the issue for you.<= /div>
 
I = think that Michael is asking an important question. There are many ways to = solve the P2P VPN problem. One way is to have satellites with little config= uration that connect to core gateways with lots of dynamic information. A c= ore gateway (a =93hub=94 in Michael=92s parlance) can download things to a = satellite (maybe a new SPD and PAD, credentials, etc.), thus causing some t= raffic from the satellite to be sent to a different core gateway or satelli= te. In that circumstance, I think Michael=92s question is about whether the= core gateway that a satellite initially connects (which I=92ll call the = =93initial core gateway=94) to should be expected to have or obtain all the= information needed to configure the satellite or whether the initial core = gateway can send the satellite to another core gateway where it can get mor= e information. At least, that=92s how I understand Michael=92s question. Pe= rhaps he can affirm or deny this interpretation.
 
Personally= , I think that this question is premature. It presupposes too much about th= e eventual solution. That=92s why I think it should be answered in the solu= tion not included in the problem statement. Apparently, Yaron doesn=92t agr= ee with me. I=92d like to hear more from him on this matter. Does he believ= e that all solutions to this problem (or at least all the good ones) must n= ecessarily employ the model that I described above? What about a solution t= hat doesn=92t rely on core gateways to refer satellites but instead has sat= ellites querying for the information that they need? Or one that has some e= xternal entity (not the core gateway) configuring the satellites? In my vie= w, there may be many possible P2P VPN solutions. However, I=92m not an IPse= c expert. Maybe this is the only practical approach. I=92d like to hear vie= ws from Yaron and from others on this topic.
 
Thanks,
 
Steve
 =
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Vishwas Manral
Sent: Wednesday, March 21, 2012 3:18 PM
To: Stephen Hanna
Cc:=  IPsecme WG
Subject= : Re: [IPsec] [ipsecm= e] #214: Should gateways figure things out completely or just punt endpoint= s to a closer gateway?
 

Hi Steve,

This is unclear to me. Isn't it rout= ing that we send a packet across to a closer gateway/ router? What does eve= rything mean in the question below?

If we are talking about say secu= rity and routing, I think that is true. The "logical" gateway (could be mul= tiple interactions and devices) should be able to provide the functionality= .

Thanks,
Vishwas

On Tue, Mar 20, 2012 at 6:3= 3 PM, Stephen Hanna <shanna@juniper.net> wrote:
Please comment on Suggested Resolution. Note that Yaron has<= br>already supplied his comment below.

Steve

-----Original Me= ssage-----
From: ipsecme issue tracker [mailto:trac@tool= s.ietf.org]
Sent: Tuesday, March 20, 2012 6:59 PM
To: yaronf.ietf@gmail= .com; draft-ietf-ipsecme-p2p-vpn-problem@tools.iet= f.org
Subject: [ipsecme] #214: Should gateways figure things out com= pletely or just punt endpoints to a closer gateway?

#214: Should gat= eways figure things out completely or just punt endpoints to a
closer ga= teway?

 Suggested Resolution: We should not specify this in the= problem statement.
 It should be specified in the solution.
 YS: sounds like a requirements-level question to me.

--
--= -----------------------+------------------------------------------------- Reporter:              |   =    Owner:  draft-ietf-ipsecme-p2p-vpn-
 yaronf.ietf@= =85          |  problem@=85
    =  Type:  defect      |     Status:  = new
 Priority:  normal      |  Milestone:<= br> Component:  p2p-vpn-    |   Severity:  -<= br> problem                | &= nbsp; Keywords:
Resolution:             &n= bsp;|
-------------------------+----------------------------------------= ---------

Ticket URL: <http://trac.tools.ietf.org/wg/ipsecme/trac/tic= ket/214#comment:1>
ipsecme <http://tools.ietf.org/ipsecme/>

_________________________= ______________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.o= rg/mailman/listinfo/ipsec
 
_______________________________________________
IPsec maili= ng list
IPsec@ietf.org
, Stephen Hanna Subject: Re: [IPsec] [ipsecme] #218: Exhaustive configuration X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:35:58 -0000 --_000_814D508F8D8D46AEBE9FC9CB9CA578ECcheckpointcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 Not only IP addresses, but actual peers may come and go. A user database ch= anges every day as employees (for example) come and go. On Mar 21, 2012, at 9:26 PM, Vishwas Manral wrote: Hi Steve, Like I mentioned the problem is not just exhaustive configuration but also = the fact that configuration parameters like IP address change. I agree we should expand the section you mention below. Thanks, Vishwas On Tue, Mar 20, 2012 at 6:37 PM, Stephen Hanna > wrote: Keeping you entertained in the week before IETF 83... Steve -----Original Message----- From: ipsecme issue tracker [mailto:trac@tools.ietf.org] Sent: Tuesday, March 20, 2012 7:03 PM To: yaronf.ietf@gmail.com; draft-ietf-ipsecme= -p2p-vpn-problem@tools.ietf.org Subject: [ipsecme] #218: Exhaustive configuration #218: Exhaustive configuration Exhaustive configuration can work fine if there are good automated configuration protocols. Suggested Resolution: Exhaustive configuration doesn't scale for constrained devices in large networks. Explain this in section 3.1. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn- yaronf.ietf@=85 | problem@=85 Type: defect | Status: new Priority: normal | Milestone: Component: p2p-vpn- | Severity: - problem | Keywords: | -------------------------+------------------------------------------------- Ticket URL: ipsecme _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_814D508F8D8D46AEBE9FC9CB9CA578ECcheckpointcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1

Not = only IP addresses, but actual peers may come and go. A user database change= s every day as employees (for example) come and go.

On Mar 21, 2012, at 9:26 PM, Vishwas Manral wrote:

Hi Steve,

Like I men= tioned the problem is not just exhaustive configuration but also the fact t= hat configuration parameters like IP address change.

I agree we shou= ld expand the section you mention below.

Thanks,
Vishwas

On Tue, Mar 20, 2012 a= t 6:37 PM, Stephen Hanna <shanna@juniper.net> wrote:
Keeping you entertained in the week before IETF 83...

Steve

-----Original Message-----
From: ipsecme issue tracker [mailto:= trac@tools.ietf.org]
Sent: Tuesday, March 20, 2012 7:03 PM
To: yaronf.ietf@gmail.com; draft-iet= f-ipsecme-p2p-vpn-problem@tools.ietf.org
Subject: [ipsecme] #218: Exhaustive configuration

#218: Exhaustive configuration

 Exhaustive configuration can work fine if there are good automated  configuration protocols.

 Suggested Resolution: Exhaustive configuration doesn't scale for
 constrained devices in large networks. Explain this in section 3.1.
--
-------------------------+-------------------------------------------------=
 Reporter:               |   &= nbsp;  Owner:  draft-ietf-ipsecme-p2p-vpn-
 yaronf.ietf@=85          |  problem@= =85
    Type:  defect       |     Stat= us:  new
 Priority:  normal       |  Milestone:
Component:  p2p-vpn-     |   Severity:  -
 problem                |
 Keywords:               |
-------------------------+-------------------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/= 218>
ipsecme <ht= tp://tools.ietf.org/ipsecme/>

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

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

= --_000_814D508F8D8D46AEBE9FC9CB9CA578ECcheckpointcom_-- From ynir@checkpoint.com Wed Mar 21 14:48:13 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC53C21E80F8 for ; Wed, 21 Mar 2012 14:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.485 X-Spam-Level: X-Spam-Status: No, score=-10.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ioq59hA+i4FF for ; Wed, 21 Mar 2012 14:48:13 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C5B4021E801E for ; Wed, 21 Mar 2012 14:48:12 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2LLmA3M003778; Wed, 21 Mar 2012 23:48:10 +0200 X-CheckPoint: {4F6A4C11-0-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 21 Mar 2012 23:48:09 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 21 Mar 2012 23:48:09 +0200 From: Yoav Nir To: Yaron Sheffer Date: Wed, 21 Mar 2012 23:48:09 +0200 Thread-Topic: [IPsec] [ipsecme] #217: Temporary credentials Thread-Index: Ac0HrE5jokjtNklYTSKVmS+jGhzN3Q== Message-ID: References: <4F6A471D.8090606@gmail.com> In-Reply-To: <4F6A471D.8090606@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "ipsec@ietf.org" , Geoffrey Huang , Stephen Hanna Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:48:13 -0000 I don't think there need to be authorization tokens, as authorization can b= e left to local policy. But there always needs to be some kind of "introduction" process, and it ca= n take many forms: - Yaron, Yoav is at 192.168.1.3. Use c80273f0f7dd5bdc10c38234616fde22 as P= SK - Yaron, Yoav is at 192.168.1.3. His certificate has DN: "CN=3Dynir,OU=3Ds= omething" In the first case, the "system" actually invented the credential, while in = the second case it just tells you about it. So temporary credentials are no= t strictly necessary, but previous attempts to rely on pure PKI have been l= ess than successful. Yoav On Mar 21, 2012, at 11:24 PM, Yaron Sheffer wrote: > The point of "temporary credentials" is that if these spokes normally=20 > use EAP or PSK to authenticate to the gateway, they cannot use these=20 > same credentials to auth to one another (because that would expose each=20 > spoke to impersonation by the other one). So to support this scenario we= =20 > must have some other means of authentication. >=20 > This raises an interesting question: if the spokes are authenticating=20 > with certificates, they could in principle use the same credentials to=20 > authenticate to one another. So the "temporary credentials" now become=20 > *authorization* tokens, basically conveying to gateway's policy. Do we=20 > really want to go down this path? >=20 > Thanks, > Yaron >=20 > On 03/21/2012 10:43 PM, Geoffrey Huang wrote: >> I don't understand what "temporary credentials" means. If the intent is= to have some transitive authentication (or redirection of trust hierarchy,= at least) between a gateway and two spoke devices, which are trying to est= ablish an ad-hoc connection, then I agree this would be important to have. >>=20 >> -geoff >>=20 >> From: Vishwas Manral> >> Date: Wed, 21 Mar 2012 12:24:08 -0700 >> To: Steve Hanna> >> Cc: "ipsec@ietf.org"> >> Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials >>=20 >> Hi Steve, >>=20 >> I think this is an important requirement for sure. >>=20 >> Thanks, >> Vishwas >>=20 >> On Tue, Mar 20, 2012 at 6:36 PM, Stephen Hanna> wrote: >> Another issue to comment on. >>=20 >> Steve >>=20 >> -----Original Message----- >> From: ipsecme issue tracker [mailto:trac@tools.ietf.org] >> Sent: Tuesday, March 20, 2012 7:01 PM >> To: yaronf.ietf@gmail.com; draft-ietf-ipse= cme-p2p-vpn-problem@tools.ietf.org >> Subject: [ipsecme] #217: Temporary credentials >>=20 >> #217: Temporary credentials >>=20 >> Endpoints may require temporary credentials in order to establish a sec= ure >> connection to another endpoint. >>=20 >> Suggested Resolution: Put this in the requirements section. >>=20 From yaronf.ietf@gmail.com Wed Mar 21 15:26:06 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2742A21E8142 for ; Wed, 21 Mar 2012 15:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQ2ScNiiOXm1 for ; Wed, 21 Mar 2012 15:26:05 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5F821E80F1 for ; Wed, 21 Mar 2012 15:26:05 -0700 (PDT) Received: by werb10 with SMTP id b10so1592449wer.31 for ; Wed, 21 Mar 2012 15:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=K9nFs5/U4/CF98Y9iErJ6CJycYGs9ziGj4cSGjg+edo=; b=MB0XfPsI/tOuxpUBVIfmgh649m1JEqU7AgLqBrwjU5D0lNLxvg5jtZi36iCXxXm+0t 3msTYTu329x+FYnW0qUhbrUctq19xcQxckR3y7f9FgNaLRK0UEZTGtRB6X65gSkLrZF0 A8+DCJ+0e7NU/AB9LvqqwT2ALEQdow0sdhsFA5rrKYvrAgPtTVdcVfb5jPbTwn1s7Su5 kzxKzhISpoTLfeBUqkLlhZYhtnz48B0VHBE1wapFByKRBFef/mEFNO4HY2yF7MYxxlvx 7F9UjNgUuB0hW53KJjxRG9rIlbbFP8f9jjjX4HycG6K0cbKvNKEL6lw0qb/2Gwo0kLHU 3ipw== Received: by 10.216.135.196 with SMTP id u46mr3111909wei.114.1332368764338; Wed, 21 Mar 2012 15:26:04 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-182-168-20.red.bezeqint.net. [79.182.168.20]) by mx.google.com with ESMTPS id gg2sm207752wib.7.2012.03.21.15.26.03 (version=SSLv3 cipher=OTHER); Wed, 21 Mar 2012 15:26:03 -0700 (PDT) Message-ID: <4F6A557A.1030604@gmail.com> Date: Thu, 22 Mar 2012 00:26:02 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Yoav Nir References: <4F6A471D.8090606@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , Geoffrey Huang , Stephen Hanna Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 22:26:06 -0000 Hi Yoav, When you say "local policy" you assume that spokes are smart enough (or well enough provisioned) to have such policy. My assumption OTOH was that the gateway is smarter, e.g. it knows what spokes are allowed to communicate directly or what kind of traffic is allowed to flow directly between spokes. It may just be a semantic discussion, but the second bullet of your "introduction" is to me indistinguishable from authorization. Thanks, Yaron On 03/21/2012 11:48 PM, Yoav Nir wrote: > I don't think there need to be authorization tokens, as authorization can be left to local policy. > > But there always needs to be some kind of "introduction" process, and it can take many forms: > - Yaron, Yoav is at 192.168.1.3. Use c80273f0f7dd5bdc10c38234616fde22 as PSK > - Yaron, Yoav is at 192.168.1.3. His certificate has DN: "CN=ynir,OU=something" > > In the first case, the "system" actually invented the credential, while in the second case it just tells you about it. So temporary credentials are not strictly necessary, but previous attempts to rely on pure PKI have been less than successful. > > Yoav > > On Mar 21, 2012, at 11:24 PM, Yaron Sheffer wrote: > >> The point of "temporary credentials" is that if these spokes normally >> use EAP or PSK to authenticate to the gateway, they cannot use these >> same credentials to auth to one another (because that would expose each >> spoke to impersonation by the other one). So to support this scenario we >> must have some other means of authentication. >> >> This raises an interesting question: if the spokes are authenticating >> with certificates, they could in principle use the same credentials to >> authenticate to one another. So the "temporary credentials" now become >> *authorization* tokens, basically conveying to gateway's policy. Do we >> really want to go down this path? >> >> Thanks, >> Yaron >> >> On 03/21/2012 10:43 PM, Geoffrey Huang wrote: >>> I don't understand what "temporary credentials" means. If the intent is to have some transitive authentication (or redirection of trust hierarchy, at least) between a gateway and two spoke devices, which are trying to establish an ad-hoc connection, then I agree this would be important to have. >>> >>> -geoff >>> >>> From: Vishwas Manral> >>> Date: Wed, 21 Mar 2012 12:24:08 -0700 >>> To: Steve Hanna> >>> Cc: "ipsec@ietf.org"> >>> Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials >>> >>> Hi Steve, >>> >>> I think this is an important requirement for sure. >>> >>> Thanks, >>> Vishwas >>> >>> On Tue, Mar 20, 2012 at 6:36 PM, Stephen Hanna> wrote: >>> Another issue to comment on. >>> >>> Steve >>> >>> -----Original Message----- >>> From: ipsecme issue tracker [mailto:trac@tools.ietf.org] >>> Sent: Tuesday, March 20, 2012 7:01 PM >>> To: yaronf.ietf@gmail.com; draft-ietf-ipsecme-p2p-vpn-problem@tools.ietf.org >>> Subject: [ipsecme] #217: Temporary credentials >>> >>> #217: Temporary credentials >>> >>> Endpoints may require temporary credentials in order to establish a secure >>> connection to another endpoint. >>> >>> Suggested Resolution: Put this in the requirements section. >>> > From yaronf.ietf@gmail.com Wed Mar 21 16:04:26 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87EAA21F85AD for ; Wed, 21 Mar 2012 16:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, MANGLED_PREMTR=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRePOUuEpxIk for ; Wed, 21 Mar 2012 16:04:25 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6414921F8650 for ; Wed, 21 Mar 2012 16:04:25 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so27577wib.13 for ; Wed, 21 Mar 2012 16:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qVgm0i4AXK4bgtZMVn0RwHua6/S5q4JrJQIgR0VFbM8=; b=u59DxBz3QujSDbxhOYTogZaSQGspsqQRnl9LIq3DseqlPUjIC7Ec7BcBeiFZ85j2Rk 7PfzeIubL7hrxfdagSE4lM2q3rBlyNC56bqQuyz0zTNVCIxzkyxBivsHEEu3M/MaVndS VxMF+94QqzjNlElROCQc7bPLsFlOvkcMb0TKCRoDddyFrYRWJDK5dzMGQl2gSXbpZErd fIWONHqnfUJFtJswaNqqUWUIqwNi+Ls4Ecc2fJrl22Wt1M7+Hj96bs1RjM2M0uEjxwRC FwMdsUCC2EuaaC0rX7CO70fO8ByNvUId1nZCTIzd91j+w0tASV+6xIqpzVth6ab4Pcg5 P/cQ== Received: by 10.216.139.79 with SMTP id b57mr3104275wej.37.1332371064468; Wed, 21 Mar 2012 16:04:24 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-182-168-20.red.bezeqint.net. [79.182.168.20]) by mx.google.com with ESMTPS id fw5sm441109wib.0.2012.03.21.16.04.22 (version=SSLv3 cipher=OTHER); Wed, 21 Mar 2012 16:04:23 -0700 (PDT) Message-ID: <4F6A5E76.7040605@gmail.com> Date: Thu, 22 Mar 2012 01:04:22 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Yoav Nir References: <3AD5BF8C-ABC5-40F1-8F6D-2C730C70B8E4@checkpoint.com> In-Reply-To: <3AD5BF8C-ABC5-40F1-8F6D-2C730C70B8E4@checkpoint.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: IPsecme WG , Stephen Hanna Subject: Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 23:04:26 -0000 Hi Steve, Yoav, I don't want to speak for MCR, but I think you are taking his question too far towards the implementation aspects. What I read in the question is, do we allow for a situation where (by policy and/or because of limitations in the solution) an endpoint cannot connect directly to the ultimate peer, but needs instead to go through some sort of relay. Given this reading of the issue, I think this is something that's still at the requirements level and we should agree whether we want it as an actual requirement. Thanks, Yaron On 03/21/2012 11:33 PM, Yoav Nir wrote: > I agree that this pre-supposes that the solution will involve "gateways" > figuring things out for "endpoints" in either one step or more than one > step. It pre-supposes a two-tier system. > > We've had a presentation in Taipei that did not involve gateways, but > rather specialized servers carrying authoritative information, with all > the IPsec hosts, whether gateways or endpoints querying those servers. > Those servers could be specialized IPsec information servers, dispensing > PAD and SPD entries through a web service, or they could be the DNS > system. Either way, this is a different model to the one that has the > information flowing through the overlay network. > > So I agree that answering this question is pre-mature. Whatever the > model, there will be an equivalent question, but I think it's too early now. > > Yoav > > On Mar 21, 2012, at 9:59 PM, Stephen Hanna wrote: > >> Again, this issue was based on Michael Richardson’s March 12 email, >> which said: >> The dual trunk scenario should perhaps be further motivated and >> clarified. Are there some situations where a spoke should not contact >> another spoke directly, but in fact should contact a hub closer to the >> other spoke. I can see some solutions where a hub would not have >> complete knowledge of the mesh, and so would in fact simply punt a >> connection closer. >> I hope this clarifies the issue for you. >> I think that Michael is asking an important question. There are many >> ways to solve the P2P VPN problem. One way is to have satellites with >> little configuration that connect to core gateways with lots of >> dynamic information. A core gateway (a “hub” in Michael’s parlance) >> can download things to a satellite (maybe a new SPD and PAD, >> credentials, etc.), thus causing some traffic from the satellite to be >> sent to a different core gateway or satellite. In that circumstance, I >> think Michael’s question is about whether the core gateway that a >> satellite initially connects (which I’ll call the “initial core >> gateway”) to should be expected to have or obtain all the information >> needed to configure the satellite or whether the initial core gateway >> can send the satellite to another core gateway where it can get more >> information. At least, that’s how I understand Michael’s question. >> Perhaps he can affirm or deny this interpretation. >> Personally, I think that this question is premature. It presupposes >> too much about the eventual solution. That’s why I think it should be >> answered in the solution not included in the problem statement. >> Apparently, Yaron doesn’t agree with me. I’d like to hear more from >> him on this matter. Does he believe that all solutions to this problem >> (or at least all the good ones) must necessarily employ the model that >> I described above? What about a solution that doesn’t rely on core >> gateways to refer satellites but instead has satellites querying for >> the information that they need? Or one that has some external entity >> (not the core gateway) configuring the satellites? In my view, there >> may be many possible P2P VPN solutions. However, I’m not an IPsec >> expert. Maybe this is the only practical approach. I’d like to hear >> views from Yaron and from others on this topic. >> Thanks, >> Steve >> *From:*ipsec-bounces@ietf.org >> [mailto:ipsec-bounces@ietf.org]*On >> Behalf Of*Vishwas Manral >> *Sent:*Wednesday, March 21, 2012 3:18 PM >> *To:*Stephen Hanna >> *Cc:*IPsecme WG >> *Subject:*Re: [IPsec] [ipsecme] #214: Should gateways figure things >> out completely or just punt endpoints to a closer gateway? >> >> Hi Steve, >> >> This is unclear to me. Isn't it routing that we send a packet across >> to a closer gateway/ router? What does everything mean in the question >> below? >> >> If we are talking about say security and routing, I think that is >> true. The "logical" gateway (could be multiple interactions and >> devices) should be able to provide the functionality. >> >> Thanks, >> Vishwas >> >> On Tue, Mar 20, 2012 at 6:33 PM, Stephen Hanna > > wrote: >> Please comment on Suggested Resolution. Note that Yaron has >> already supplied his comment below. >> >> Steve >> >> -----Original Message----- >> From: ipsecme issue tracker [mailto:trac@tools.ietf.org >> ] >> Sent: Tuesday, March 20, 2012 6:59 PM >> To:yaronf.ietf@gmail.com >> ;draft-ietf-ipsecme-p2p-vpn-problem@tools.ietf.org >> >> Subject: [ipsecme] #214: Should gateways figure things out completely >> or just punt endpoints to a closer gateway? >> >> #214: Should gateways figure things out completely or just punt >> endpoints to a >> closer gateway? >> >> Suggested Resolution: We should not specify this in the problem statement. >> It should be specified in the solution. >> >> YS: sounds like a requirements-level question to me. >> >> -- >> -------------------------+------------------------------------------------- >> Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn- >> yaronf.ietf@… | problem@… >> Type: defect | Status: new >> Priority: normal | Milestone: >> Component: p2p-vpn- | Severity: - >> problem | Keywords: >> Resolution: | >> -------------------------+------------------------------------------------- >> >> Ticket URL: >> >> ipsecme >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From shanna@juniper.net Wed Mar 21 18:02:22 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C969921E8029 for ; Wed, 21 Mar 2012 18:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.149 X-Spam-Level: X-Spam-Status: No, score=-105.149 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, MANGLED_PREMTR=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q93IFQULC0sG for ; Wed, 21 Mar 2012 18:02:22 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id EE79421E8017 for ; Wed, 21 Mar 2012 18:02:13 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKT2p6FQ/9m7Oz2WBwBQGmME+zcRHv3xS0@postini.com; Wed, 21 Mar 2012 18:02:21 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 21 Mar 2012 18:01:25 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 21 Mar 2012 21:01:25 -0400 From: Stephen Hanna To: Yaron Sheffer , Yoav Nir Date: Wed, 21 Mar 2012 21:01:24 -0400 Thread-Topic: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway? Thread-Index: Ac0HtvfbzSb2WIKFTOSqA8xCQ/CcxAACO7gg Message-ID: References: <3AD5BF8C-ABC5-40F1-8F6D-2C730C70B8E4@checkpoint.com> <4F6A5E76.7040605@gmail.com> In-Reply-To: <4F6A5E76.7040605@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 01:02:22 -0000 If that's the topic, we already have an issue (#213) for it. Let's see if MCR will clarify what he meant here. Thanks, Steve > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > Sent: Wednesday, March 21, 2012 7:04 PM > To: Yoav Nir > Cc: Stephen Hanna; IPsecme WG > Subject: Re: [IPsec] [ipsecme] #214: Should gateways figure things out > completely or just punt endpoints to a closer gateway? >=20 > Hi Steve, Yoav, >=20 > I don't want to speak for MCR, but I think you are taking his question > too far towards the implementation aspects. What I read in the question > is, do we allow for a situation where (by policy and/or because of > limitations in the solution) an endpoint cannot connect directly to the > ultimate peer, but needs instead to go through some sort of relay. >=20 > Given this reading of the issue, I think this is something that's still > at the requirements level and we should agree whether we want it as an > actual requirement. >=20 > Thanks, > Yaron >=20 > On 03/21/2012 11:33 PM, Yoav Nir wrote: > > I agree that this pre-supposes that the solution will involve > "gateways" > > figuring things out for "endpoints" in either one step or more than > one > > step. It pre-supposes a two-tier system. > > > > We've had a presentation in Taipei that did not involve gateways, but > > rather specialized servers carrying authoritative information, with > all > > the IPsec hosts, whether gateways or endpoints querying those > servers. > > Those servers could be specialized IPsec information servers, > dispensing > > PAD and SPD entries through a web service, or they could be the DNS > > system. Either way, this is a different model to the one that has the > > information flowing through the overlay network. > > > > So I agree that answering this question is pre-mature. Whatever the > > model, there will be an equivalent question, but I think it's too > early now. > > > > Yoav > > > > On Mar 21, 2012, at 9:59 PM, Stephen Hanna wrote: > > > >> Again, this issue was based on Michael Richardson's March 12 email, > >> which said: > >> The dual trunk scenario should perhaps be further motivated and > >> clarified. Are there some situations where a spoke should not > contact > >> another spoke directly, but in fact should contact a hub closer to > the > >> other spoke. I can see some solutions where a hub would not have > >> complete knowledge of the mesh, and so would in fact simply punt a > >> connection closer. > >> I hope this clarifies the issue for you. > >> I think that Michael is asking an important question. There are many > >> ways to solve the P2P VPN problem. One way is to have satellites > with > >> little configuration that connect to core gateways with lots of > >> dynamic information. A core gateway (a "hub" in Michael's parlance) > >> can download things to a satellite (maybe a new SPD and PAD, > >> credentials, etc.), thus causing some traffic from the satellite to > be > >> sent to a different core gateway or satellite. In that circumstance, > I > >> think Michael's question is about whether the core gateway that a > >> satellite initially connects (which I'll call the "initial core > >> gateway") to should be expected to have or obtain all the > information > >> needed to configure the satellite or whether the initial core > gateway > >> can send the satellite to another core gateway where it can get more > >> information. At least, that's how I understand Michael's question. > >> Perhaps he can affirm or deny this interpretation. > >> Personally, I think that this question is premature. It presupposes > >> too much about the eventual solution. That's why I think it should > be > >> answered in the solution not included in the problem statement. > >> Apparently, Yaron doesn't agree with me. I'd like to hear more from > >> him on this matter. Does he believe that all solutions to this > problem > >> (or at least all the good ones) must necessarily employ the model > that > >> I described above? What about a solution that doesn't rely on core > >> gateways to refer satellites but instead has satellites querying for > >> the information that they need? Or one that has some external entity > >> (not the core gateway) configuring the satellites? In my view, there > >> may be many possible P2P VPN solutions. However, I'm not an IPsec > >> expert. Maybe this is the only practical approach. I'd like to hear > >> views from Yaron and from others on this topic. > >> Thanks, > >> Steve > >> *From:*ipsec-bounces@ietf.org > >> [mailto:ipsec-bounces@ietf.org]*On > >> Behalf Of*Vishwas Manral > >> *Sent:*Wednesday, March 21, 2012 3:18 PM > >> *To:*Stephen Hanna > >> *Cc:*IPsecme WG > >> *Subject:*Re: [IPsec] [ipsecme] #214: Should gateways figure things > >> out completely or just punt endpoints to a closer gateway? > >> > >> Hi Steve, > >> > >> This is unclear to me. Isn't it routing that we send a packet across > >> to a closer gateway/ router? What does everything mean in the > question > >> below? > >> > >> If we are talking about say security and routing, I think that is > >> true. The "logical" gateway (could be multiple interactions and > >> devices) should be able to provide the functionality. > >> > >> Thanks, > >> Vishwas > >> > >> On Tue, Mar 20, 2012 at 6:33 PM, Stephen Hanna >> > wrote: > >> Please comment on Suggested Resolution. Note that Yaron has > >> already supplied his comment below. > >> > >> Steve > >> > >> -----Original Message----- > >> From: ipsecme issue tracker [mailto:trac@tools.ietf.org > >> ] > >> Sent: Tuesday, March 20, 2012 6:59 PM > >> To:yaronf.ietf@gmail.com > >> ;draft-ietf-ipsecme-p2p-vpn- > problem@tools.ietf.org > >> > >> Subject: [ipsecme] #214: Should gateways figure things out > completely > >> or just punt endpoints to a closer gateway? > >> > >> #214: Should gateways figure things out completely or just punt > >> endpoints to a > >> closer gateway? > >> > >> Suggested Resolution: We should not specify this in the problem > statement. > >> It should be specified in the solution. > >> > >> YS: sounds like a requirements-level question to me. > >> > >> -- > >> -------------------------+------------------------------------------ > ------- > >> Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn- > >> yaronf.ietf@... | problem@... > >> Type: defect | Status: new > >> Priority: normal | Milestone: > >> Component: p2p-vpn- | Severity: - > >> problem | Keywords: > >> Resolution: | > >> -------------------------+------------------------------------------ > ------- > >> > >> Ticket URL: > >> > >> ipsecme > >> > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec From jntupal@gmail.com Wed Mar 21 22:58:49 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09AC21F854C for ; Wed, 21 Mar 2012 22:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgCQPaV93eGc for ; Wed, 21 Mar 2012 22:58:48 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6018021F854B for ; Wed, 21 Mar 2012 22:58:48 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so220426wib.13 for ; Wed, 21 Mar 2012 22:58:47 -0700 (PDT) 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=2q903zX6LoT+dBfVwCK5KjALyJb0et0Dxkoa859N4/c=; b=k4OfyH+VzQM/TPmpjTw5/4SaY0tr288yeZIrYDsdqVgc4sj+zSGcZCAA0VFJe6iBQ9 b5Meii+DL/eKt8fGtLCTMEBEwC60dSDEFhw43oCb3W4np0hN6BFOkKGHC9dCr00moy47 b8Vu8LTPRucJuE+ONvx2L77BU2dc2Ls185nB/L7bDSx4xkZbGO+12aobxq2iimwWExgV nxRO1DM4M7aNBpTi1LKr74i/Pv4lp+4uXqQEQRcL6+1zmInDNcSenm9bilPXPvy7RfZc k8zfdJBUiHbQj1tQHrxOf04+KaX+7SRtfX+/stJMOkmVIUXbZ1iSnBnrlY9gWjisgGtI bU1A== MIME-Version: 1.0 Received: by 10.180.89.9 with SMTP id bk9mr2068172wib.11.1332395927380; Wed, 21 Mar 2012 22:58:47 -0700 (PDT) Received: by 10.216.233.219 with HTTP; Wed, 21 Mar 2012 22:58:47 -0700 (PDT) In-Reply-To: <21AAB4E5-7E09-4897-BA67-469C60B7CAA0@checkpoint.com> References: <21AAB4E5-7E09-4897-BA67-469C60B7CAA0@checkpoint.com> Date: Thu, 22 Mar 2012 11:28:47 +0530 Message-ID: From: yogendra pal To: Yoav Nir Content-Type: multipart/alternative; boundary=f46d0444812df3a11004bbce99b9 Cc: IPsecme WG , Stephen Hanna Subject: Re: [IPsec] [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 05:58:49 -0000 --f46d0444812df3a11004bbce99b9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree to what Yoav stated, that signalling part (SIP) and media part (RTP) both SHOULD work even if there is NAT in the configuration today. However, I could not get why we need to have new NAT traversal mechanism using hub gateway, can you elaborate on this... Thanks and Regards, Yogendra Pal Ericsson, India +91-9686202644 On Wed, Mar 21, 2012 at 6:49 PM, Yoav Nir wrote: > "direct endpoint-to-endpoint connectivity may not be possible if both > endpoints are NATed" > > Why? There are several protocols (SIP/RTP come to mind) that manage > endpoint-to-endpoint connectivity even when both are behind NAT. Why > shouldn't IPsec endpoints do this? > > If this requires some new NAT traversal mechanism, perhaps using a hub > gateway in place of the SIP SBC, then this should be part of the > requirements. > > This mechanism is needed even if only one endpoint is NATted, otherwise > we're constraining who the initiator has to be. > > Yoav > > On Mar 21, 2012, at 3:31 AM, Stephen Hanna wrote: > > > Another issue. Please comment on Suggested Resolution. > > > > Thanks, > > > > Steve > > > > -----Original Message----- > > From: ipsecme issue tracker [mailto:trac@tools.ietf.org] > > Sent: Tuesday, March 20, 2012 6:58 PM > > To: yaronf.ietf@gmail.com; > draft-ietf-ipsecme-p2p-vpn-problem@tools.ietf.org > > Subject: [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint > connectivity may not be possible > > > > #213: In use case 2.1, direct endpoint-to-endpoint connectivity may not > be > > possible > > > > In use case 2.1, direct endpoint-to-endpoint connectivity may not be > possible > > if both endpoints are NATed. > > > > Suggested Resolution: Mention this in section 2.1. > > > > -- > > > -------------------------+-----------------------------------------------= -- > > Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn- > > yaronf.ietf@=E2=80=A6 | problem@=E2=80=A6 > > Type: defect | Status: new > > Priority: normal | Milestone: > > Component: p2p-vpn- | Severity: - > > problem | Keywords: > > Resolution: | > > > -------------------------+-----------------------------------------------= -- > > > > Ticket URL: < > http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/213#comment:1> > > ipsecme > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > I=C6=A7=EF=BF=BD=EF=BF=BD[=EF=BF=BD(^rC=EF=BF=BD{S=EF=BF=BD=D6=A5I=EF= =BF=BD.=EF=BF=BD+r =EF=BF=BD^=EF=BF=BD=EF=BF=BD > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- --f46d0444812df3a11004bbce99b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree to what Yoav stated, that signalling part (SIP) and media part (RTP= ) both SHOULD work even if there is NAT in the configuration today. However= ,=C2=A0I could not get why we need to have new NAT traversal mechanism usin= g hub gateway, can you=C2=A0elaborate=C2=A0on this...

Thanks and Regards,
Yogendra Pal
Ericsson, Indi= a
+91-9686202644
=C2=A0=C2=A0

On Wed, Mar 21, 2012 at 6:49 PM, Yoav Nir <ynir@checkpoint.com> wrote:
"direct endpoint-to-e= ndpoint connectivity may not be possible if both endpoints are NATed"<= br>
Why? =C2=A0There are several protocols (SIP/RTP come to mind) that ma= nage endpoint-to-endpoint connectivity even when both are behind NAT. Why s= houldn't IPsec endpoints do this?

If this requires some new NAT traversal mechanism, perhaps using a hub gate= way in place of the SIP SBC, then this should be part of the requirements.<= br>
This mechanism is needed even if only one endpoint is NATted, otherwise we&= #39;re constraining who the initiator has to be.

Yoav

On Mar 21, 2012, at 3:31 AM, Stephen Hanna wrote:

> Another issue. Please comment on Suggested Resolution.
>
> Thanks,
>
> Steve
>
> -----Original Message-----
> From: ipsecme issue tracker [mailto:trac@tools.ietf.org]
> Sent: Tuesday, March 20, 2012 6:58 PM
> To: yaronf.ietf@gmail.com= ; draf= t-ietf-ipsecme-p2p-vpn-problem@tools.ietf.org
> Subject: [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint = connectivity may not be possible
>
> #213: In use case 2.1, direct endpoint-to-endpoint connectivity may no= t be
> possible
>
> In use case 2.1, direct endpoint-to-endpoint connectivity may not be p= ossible
> if both endpoints are NATed.
>
> Suggested Resolution: Mention this in section 2.1.
>
> --
> -------------------------+--------------------------------------------= -----
> =C2=A0Reporter: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0Owner: =C2=A0draft-ietf-ipsecme-p2p-vpn-
> =C2=A0yaronf.ietf@=E2=80=A6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0= problem@=E2=80=A6
> =C2=A0 =C2=A0 =C2=A0Type: =C2=A0defect =C2=A0 =C2=A0 =C2=A0| =C2=A0 = =C2=A0 Status: =C2=A0new
> =C2=A0Priority: =C2=A0normal =C2=A0 =C2=A0 =C2=A0| =C2=A0Milestone: > Component: =C2=A0p2p-vpn- =C2=A0 =C2=A0| =C2=A0 Severity: =C2=A0-
> =C2=A0problem =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 Keywords:
> Resolution: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> -------------------------+--------------------------------------------= -----
>
> Ticket URL: <http://trac.tools.ietf.org/wg/ipsec= me/trac/ticket/213#comment:1>
> ipsecme <http://tools.ietf.org/ipsecme/>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
> I=C6=A7=EF=BF=BD=EF=BF=BD[=EF=BF=BD(^rC=EF=BF=BD{S=EF=BF= =BD=D6=A5I=EF=BF=BD.=EF=BF=BD+r =EF=BF=BD^=EF=BF=BD=EF=BF=BD

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



--
=
--f46d0444812df3a11004bbce99b9-- From jntupal@gmail.com Wed Mar 21 23:45:19 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCF121E8036 for ; Wed, 21 Mar 2012 23:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBjhDFtPK4no for ; Wed, 21 Mar 2012 23:45:18 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EA48621E800E for ; Wed, 21 Mar 2012 23:45:17 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so782596wgb.13 for ; Wed, 21 Mar 2012 23:45:17 -0700 (PDT) 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=C0IpWuSl/Rep5S2c5skPh73B8RT7j656cZQW249nvCM=; b=VE6Nm8YfnJ+Vo+2XSzdzYTEFrRTx+BrBm4ySbU4JRvTWNxaEeQsTrmS6S+yn4VxQ4z Yl3MIm0px/ZBZGDFWjQEqbOgvHzUf0CtQD1+JLCUDgu8gZ1C58PmMIlFqn89kSP0YE2a gTYs+EDGEvjAee0mbWvU22Crrl1jNSAlGqEczWkqk72iffDDR1E9KPSX+18i6cxMVSav WH4rEV0F/5Yf2OqN0j6uzfNVClqLQ0pdVvGuMdGLL8xQA+rc7BCcJ2ImG7mMtujUO5L8 7CYh37mjFSkPtUpem17olllZn4y17X+eaoN1dqI0T7BE4YTzMOtJWShTujZUcqlEEqen rSQw== MIME-Version: 1.0 Received: by 10.180.107.162 with SMTP id hd2mr2207519wib.8.1332398716916; Wed, 21 Mar 2012 23:45:16 -0700 (PDT) Received: by 10.216.233.219 with HTTP; Wed, 21 Mar 2012 23:45:16 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 Mar 2012 12:15:16 +0530 Message-ID: From: yogendra pal To: Stephen Hanna Content-Type: multipart/alternative; boundary=e89a8f23529738940204bbcf4089 Cc: IPsecme WG Subject: Re: [IPsec] [ipsecme] #219: Star topology as an admin choice X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 06:45:19 -0000 --e89a8f23529738940204bbcf4089 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Why they may not use this technology ? Even today irrespective of the topology, traffic is intercepted by lawful agencies by using different mechanism (port mirroring, etc...) Thanks, Yogendra Pal Ericsson, India On Wed, Mar 21, 2012 at 7:07 AM, Stephen Hanna wrote: > Please comment. > > Steve > > -----Original Message----- > From: ipsecme issue tracker [mailto:trac@tools.ietf.org] > Sent: Tuesday, March 20, 2012 7:04 PM > To: yaronf.ietf@gmail.com; > draft-ietf-ipsecme-p2p-vpn-problem@tools.ietf.org > Subject: [ipsecme] #219: Star topology as an admin choice > > #219: Star topology as an admin choice > > Some admins prefer a star topology so they can inspect traffic. They may > not want to use this technology. > > Suggested Resolution: Mention this in the Security Considerations sectio= n. > > -- > -------------------------+-----------------------------------------------= -- > Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn- > yaronf.ietf@=85 | problem@=85 > Type: defect | Status: new > Priority: normal | Milestone: > Component: p2p-vpn- | Severity: - > problem | > Keywords: | > -------------------------+-----------------------------------------------= -- > > Ticket URL: > ipsecme > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- --e89a8f23529738940204bbcf4089 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Why they may not use this technology ? Even today irrespective of the topol= ogy, traffic is intercepted by lawful agencies by using different mechanism= (port mirroring, etc...)

Thanks,
Yogendra Pal
Ericsson, Indi= a

On Wed, Mar 21, 2012 at 7:07 AM, Stephen Han= na <shanna@junip= er.net> wrote:
Please comment.

Steve

-----Original Message-----
From: ipsecme issue tracker [mailto:= trac@tools.ietf.org]
Sent: Tuesday, March 20, 2012 7:04 PM
To: yaronf.ietf@gmail.com; draft-iet= f-ipsecme-p2p-vpn-problem@tools.ietf.org
Subject: [ipsecme] #219: Star topology as an admin choice

#219: Star topology as an admin choice

=A0Some admins prefer a star topology so they can inspect traffic. They may=
=A0not want to use this technology.

=A0Suggested Resolution: Mention this in the Security Considerations sectio= n.

--
-------------------------+-------------------------------------------------=
=A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Owner: =A0draft-ietf-= ipsecme-p2p-vpn-
=A0yaronf.ietf@=85 =A0 =A0 =A0 =A0 =A0| =A0problem@=85
=A0 =A0 Type: =A0defect =A0 =A0 =A0 | =A0 =A0 Status: =A0new
=A0Priority: =A0normal =A0 =A0 =A0 | =A0Milestone:
Component: =A0p2p-vpn- =A0 =A0 | =A0 Severity: =A0-
=A0problem =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
-------------------------+-------------------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/= 219>
ipsecme <ht= tp://tools.ietf.org/ipsecme/>

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



--

--e89a8f23529738940204bbcf4089-- From ynir@checkpoint.com Thu Mar 22 00:30:41 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1756121F85D8 for ; Thu, 22 Mar 2012 00:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.486 X-Spam-Level: X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-3WUTLKhayB for ; Thu, 22 Mar 2012 00:30:40 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4F28A21F85D6 for ; Thu, 22 Mar 2012 00:30:38 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2M7UZ5D028792; Thu, 22 Mar 2012 09:30:35 +0200 X-CheckPoint: {4F6AD48C-0-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 22 Mar 2012 09:30:34 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 22 Mar 2012 09:30:34 +0200 From: Yoav Nir To: yogendra pal Date: Thu, 22 Mar 2012 09:30:35 +0200 Thread-Topic: [IPsec] [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible Thread-Index: Ac0H/aqgvoAuVgG8Tcywwplja/0dyw== Message-ID: <8D8F1D71-D221-4AEB-AB25-62651315ACC9@checkpoint.com> References: <21AAB4E5-7E09-4897-BA67-469C60B7CAA0@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_8D8F1D71D2214AEBAB2562651315ACC9checkpointcom_" MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: IPsecme WG , Stephen Hanna Subject: Re: [IPsec] [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 07:30:41 -0000 --_000_8D8F1D71D2214AEBAB2562651315ACC9checkpointcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VyZS4gQSBWUE4gaG9zdCAod2hldGhlciBjbGllbnQgb3IgZ2F0ZXdheSkgdGhhdCBpcyBiZWhp bmQgTkFUIGlzIGdlbmVyYWxseSB1bnJlYWNoYWJsZSBmcm9tIGEgcmFuZG9tIGhvc3QuDQoNClRv IGFsbG93IHJhbmRvbSBob3N0cyB0byBnZXQgdGhlcmUsIHRoZSBWUE4gaG9zdCBuZWVkcyB0byAi cHVuY2ggYSBob2xlIiBpbiB0aGUgTkFUIGJ5IHNlbmRpbmcgYSBiaW5kaW5nIHJlcXVlc3QgdG8g YSBTVFVOIHNlcnZlci4gVGhlIElQIHJvdXRhYmxlIElQIGFkZHJlc3MgYW5kIHBvcnQgdGhhdCBp dCB1c2VzIHNob3VsZCBiZSBzdG9yZWQgc29tZXdoZXJlLCBpbiBjYXNlIHNvbWUgcmFuZG9tIFZQ TiBob3N0IHdhbnRzIHRvIGNvbnRhY3QgaXQuIEl0IGhhcyB0byBiZSBzdG9yZWQgb3V0c2lkZSB0 aGUgVlBOIGhvc3QgaXRzZWxmLCBiZWNhdXNlIHRoYXQgaG9zdCBpcyB1bnJlYWNoYWJsZS4NCg0K U28gaWYgb25lIG9yIGJvdGggb2YgdGhlIFZQTiBwZWVycyBhcmUgYmVoaW5kIE5BVCwgd2UgbmVl ZCBzb21lIDNyZC1wYXJ0eSBvciBwYXJ0aWVzIHRvIGJyb2tlbiB0aGUgTkFUIHRyYXZlcnNhbC4g V2UgbmVlZDoNCiAtIGEgU1RVTiAob3IgU1RVTi1saWtlKSBzZXJ2ZXIgZm9yIHB1bmNoaW5nIHRo ZSBob2xlDQogLSBzdG9yYWdlIGZvciB0aGUgZGlzY292ZXJlZCBhZGRyZXNzIGFuZCBwb3J0DQoN CkluIFNJUCB0aGVzZSBmdW5jdGlvbnMgYXJlIGRvbmUgYnkgdGhlIFNCQy4NCg0KU28ganVzdCBs aWtlIHRoZSAjMjE0IGFuZCAjMjE3IGlzc3Vlcywgd2UgbmVlZCBhIDNyZCBwYXJ0eSB0byBicm9r ZXIgdGhlIGhvc3QtMi1ob3N0IHR1bm5lbCB0aGF0IHdlIHdhbnQgdG8gc2V0IHVwLiBJdCdzIHRl bXB0aW5nIHRvIGFzc2lnbiB0aGlzIGZ1bmN0aW9uIHRvIGEgaHViIGdhdGV3YXkgYXMgdGhlIFZQ TiBob3N0IGFscmVhZHkgaGFzIHRoZSBhYmlsaXR5IHRvIGF1dGhlbnRpY2F0ZSB0byBpdCwgYnV0 IHRoYXQgc2hvdWxkIGJlIHBhcnQgb2YgdGhlIGRlc2lnbiwgbm90IHRoZSByZXF1aXJlbWVudHMN Cg0KWW9hdg0KDQpQLlM6IFNvcnJ5IGlmIG15IFNJUC9SVFAgdGVybWlub2xvZ3kgaXMgb2ZmLiBJ dCdzIGFsbCBiYXNlZCBvbiBhIGN1cnNvcnkgcmVhZGluZyBvZiBhIFdpa2lwZWRpYSBhcnRpY2xl Lg0KDQpPbiBNYXIgMjIsIDIwMTIsIGF0IDc6NTggQU0sIHlvZ2VuZHJhIHBhbCB3cm90ZToNCg0K SSBhZ3JlZSB0byB3aGF0IFlvYXYgc3RhdGVkLCB0aGF0IHNpZ25hbGxpbmcgcGFydCAoU0lQKSBh bmQgbWVkaWEgcGFydCAoUlRQKSBib3RoIFNIT1VMRCB3b3JrIGV2ZW4gaWYgdGhlcmUgaXMgTkFU IGluIHRoZSBjb25maWd1cmF0aW9uIHRvZGF5LiBIb3dldmVyLCBJIGNvdWxkIG5vdCBnZXQgd2h5 IHdlIG5lZWQgdG8gaGF2ZSBuZXcgTkFUIHRyYXZlcnNhbCBtZWNoYW5pc20gdXNpbmcgaHViIGdh dGV3YXksIGNhbiB5b3UgZWxhYm9yYXRlIG9uIHRoaXMuLi4NCg0KVGhhbmtzIGFuZCBSZWdhcmRz LA0KWW9nZW5kcmEgUGFsDQpFcmljc3NvbiwgSW5kaWENCis5MS05Njg2MjAyNjQ0DQoNCg0KT24g V2VkLCBNYXIgMjEsIDIwMTIgYXQgNjo0OSBQTSwgWW9hdiBOaXIgPHluaXJAY2hlY2twb2ludC5j b208bWFpbHRvOnluaXJAY2hlY2twb2ludC5jb20+PiB3cm90ZToNCiJkaXJlY3QgZW5kcG9pbnQt dG8tZW5kcG9pbnQgY29ubmVjdGl2aXR5IG1heSBub3QgYmUgcG9zc2libGUgaWYgYm90aCBlbmRw b2ludHMgYXJlIE5BVGVkIg0KDQpXaHk/ICBUaGVyZSBhcmUgc2V2ZXJhbCBwcm90b2NvbHMgKFNJ UC9SVFAgY29tZSB0byBtaW5kKSB0aGF0IG1hbmFnZSBlbmRwb2ludC10by1lbmRwb2ludCBjb25u ZWN0aXZpdHkgZXZlbiB3aGVuIGJvdGggYXJlIGJlaGluZCBOQVQuIFdoeSBzaG91bGRuJ3QgSVBz ZWMgZW5kcG9pbnRzIGRvIHRoaXM/DQoNCklmIHRoaXMgcmVxdWlyZXMgc29tZSBuZXcgTkFUIHRy YXZlcnNhbCBtZWNoYW5pc20sIHBlcmhhcHMgdXNpbmcgYSBodWIgZ2F0ZXdheSBpbiBwbGFjZSBv ZiB0aGUgU0lQIFNCQywgdGhlbiB0aGlzIHNob3VsZCBiZSBwYXJ0IG9mIHRoZSByZXF1aXJlbWVu dHMuDQoNClRoaXMgbWVjaGFuaXNtIGlzIG5lZWRlZCBldmVuIGlmIG9ubHkgb25lIGVuZHBvaW50 IGlzIE5BVHRlZCwgb3RoZXJ3aXNlIHdlJ3JlIGNvbnN0cmFpbmluZyB3aG8gdGhlIGluaXRpYXRv ciBoYXMgdG8gYmUuDQoNCllvYXYNCg0KT24gTWFyIDIxLCAyMDEyLCBhdCAzOjMxIEFNLCBTdGVw aGVuIEhhbm5hIHdyb3RlOg0KDQo+IEFub3RoZXIgaXNzdWUuIFBsZWFzZSBjb21tZW50IG9uIFN1 Z2dlc3RlZCBSZXNvbHV0aW9uLg0KPg0KPiBUaGFua3MsDQo+DQo+IFN0ZXZlDQo+DQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGlwc2VjbWUgaXNzdWUgdHJhY2tlciBbbWFp bHRvOnRyYWNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOnRyYWNAdG9vbHMuaWV0Zi5vcmc+XQ0KPiBT ZW50OiBUdWVzZGF5LCBNYXJjaCAyMCwgMjAxMiA2OjU4IFBNDQo+IFRvOiB5YXJvbmYuaWV0ZkBn bWFpbC5jb208bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbT47IGRyYWZ0LWlldGYtaXBzZWNt ZS1wMnAtdnBuLXByb2JsZW1AdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtaXBzZWNt ZS1wMnAtdnBuLXByb2JsZW1AdG9vbHMuaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFtpcHNlY21lXSAj MjEzOiBJbiB1c2UgY2FzZSAyLjEsIGRpcmVjdCBlbmRwb2ludC10by1lbmRwb2ludCBjb25uZWN0 aXZpdHkgbWF5IG5vdCBiZSBwb3NzaWJsZQ0KPg0KPiAjMjEzOiBJbiB1c2UgY2FzZSAyLjEsIGRp cmVjdCBlbmRwb2ludC10by1lbmRwb2ludCBjb25uZWN0aXZpdHkgbWF5IG5vdCBiZQ0KPiBwb3Nz aWJsZQ0KPg0KPiBJbiB1c2UgY2FzZSAyLjEsIGRpcmVjdCBlbmRwb2ludC10by1lbmRwb2ludCBj b25uZWN0aXZpdHkgbWF5IG5vdCBiZSBwb3NzaWJsZQ0KPiBpZiBib3RoIGVuZHBvaW50cyBhcmUg TkFUZWQuDQo+DQo+IFN1Z2dlc3RlZCBSZXNvbHV0aW9uOiBNZW50aW9uIHRoaXMgaW4gc2VjdGlv biAyLjEuDQo+DQo+IC0tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgUmVwb3J0ZXI6ICAgICAg ICAgICAgICB8ICAgICAgT3duZXI6ICBkcmFmdC1pZXRmLWlwc2VjbWUtcDJwLXZwbi0NCj4gIHlh cm9uZi5pZXRmQOKApiAgICAgICAgICB8ICBwcm9ibGVtQOKApg0KPiAgICAgIFR5cGU6ICBkZWZl Y3QgICAgICB8ICAgICBTdGF0dXM6ICBuZXcNCj4gIFByaW9yaXR5OiAgbm9ybWFsICAgICAgfCAg TWlsZXN0b25lOg0KPiBDb21wb25lbnQ6ICBwMnAtdnBuLSAgICB8ICAgU2V2ZXJpdHk6ICAtDQo+ ICBwcm9ibGVtICAgICAgICAgICAgICAgIHwgICBLZXl3b3JkczoNCj4gUmVzb2x1dGlvbjogICAg ICAgICAgICAgIHwNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+IFRpY2tldCBVUkw6IDxodHRw Oi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9pcHNlY21lL3RyYWMvdGlja2V0LzIxMyNjb21tZW50 OjE+DQo+IGlwc2VjbWUgPGh0dHA6Ly90b29scy5pZXRmLm9yZy9pcHNlY21lLz4NCj4NCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSVBzZWMgbWFp bGluZyBsaXN0DQo+IElQc2VjQGlldGYub3JnPG1haWx0bzpJUHNlY0BpZXRmLm9yZz4NCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYw0KPiBJxqfvv73vv71b77+9 KF5yQ++/vXtT77+91qVJ77+9Lu+/vStyIO+/vV7vv73vv70NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklQc2VjIG1haWxpbmcgbGlzdA0KSVBzZWNA aWV0Zi5vcmc8bWFpbHRvOklQc2VjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pcHNlYw0KDQoNCg0KLS0NCg0KDQo= --_000_8D8F1D71D2214AEBAB2562651315ACC9checkpointcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsgIj5TdXJlLiBBIFZQTiBob3N0ICh3aGV0aGVyIGNsaWVudCBvciBnYXRld2F5KSB0aGF0 IGlzIGJlaGluZCBOQVQgaXMgZ2VuZXJhbGx5IHVucmVhY2hhYmxlIGZyb20gYSByYW5kb20gaG9z dC48ZGl2Pjxicj48L2Rpdj48ZGl2PlRvIGFsbG93IHJhbmRvbSBob3N0cyB0byBnZXQgdGhlcmUs IHRoZSBWUE4gaG9zdCBuZWVkcyB0byAicHVuY2ggYSBob2xlIiBpbiB0aGUgTkFUIGJ5IHNlbmRp bmcgYSBiaW5kaW5nIHJlcXVlc3QgdG8gYSBTVFVOIHNlcnZlci4gVGhlIElQIHJvdXRhYmxlIElQ IGFkZHJlc3MgYW5kIHBvcnQgdGhhdCBpdCB1c2VzIHNob3VsZCBiZSBzdG9yZWQgc29tZXdoZXJl LCBpbiBjYXNlIHNvbWUgcmFuZG9tIFZQTiBob3N0IHdhbnRzIHRvIGNvbnRhY3QgaXQuIEl0IGhh cyB0byBiZSBzdG9yZWQgb3V0c2lkZSB0aGUgVlBOIGhvc3QgaXRzZWxmLCBiZWNhdXNlIHRoYXQg aG9zdCBpcyB1bnJlYWNoYWJsZS4mbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlNvIGlm IG9uZSBvciBib3RoIG9mIHRoZSBWUE4gcGVlcnMgYXJlIGJlaGluZCBOQVQsIHdlIG5lZWQgc29t ZSAzcmQtcGFydHkgb3IgcGFydGllcyB0byBicm9rZW4gdGhlIE5BVCB0cmF2ZXJzYWwuIFdlIG5l ZWQ6PC9kaXY+PGRpdj4mbmJzcDstIGEgU1RVTiAob3IgU1RVTi1saWtlKSBzZXJ2ZXIgZm9yIHB1 bmNoaW5nIHRoZSBob2xlPC9kaXY+PGRpdj4mbmJzcDstIHN0b3JhZ2UgZm9yIHRoZSBkaXNjb3Zl cmVkIGFkZHJlc3MgYW5kIHBvcnQ8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkluIFNJUCB0aGVz ZSBmdW5jdGlvbnMgYXJlIGRvbmUgYnkgdGhlIFNCQy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 PlNvIGp1c3QgbGlrZSB0aGUgIzIxNCBhbmQgIzIxNyBpc3N1ZXMsIHdlIG5lZWQgYSAzcmQgcGFy dHkgdG8gYnJva2VyIHRoZSBob3N0LTItaG9zdCB0dW5uZWwgdGhhdCB3ZSB3YW50IHRvIHNldCB1 cC4gSXQncyB0ZW1wdGluZyB0byBhc3NpZ24gdGhpcyBmdW5jdGlvbiB0byBhIGh1YiBnYXRld2F5 IGFzIHRoZSBWUE4gaG9zdCBhbHJlYWR5IGhhcyB0aGUgYWJpbGl0eSB0byBhdXRoZW50aWNhdGUg dG8gaXQsIGJ1dCB0aGF0IHNob3VsZCBiZSBwYXJ0IG9mIHRoZSBkZXNpZ24sIG5vdCB0aGUgcmVx dWlyZW1lbnRzPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Zb2F2PC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj5QLlM6IFNvcnJ5IGlmIG15IFNJUC9SVFAgdGVybWlub2xvZ3kgaXMgb2ZmLiBJdCdz IGFsbCBiYXNlZCBvbiBhIGN1cnNvcnkgcmVhZGluZyBvZiBhIFdpa2lwZWRpYSBhcnRpY2xlLjwv ZGl2PjxkaXY+PGJyPjxkaXY+PGRpdj5PbiBNYXIgMjIsIDIwMTIsIGF0IDc6NTggQU0sIHlvZ2Vu ZHJhIHBhbCB3cm90ZTo8L2Rpdj48YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUi PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPkkgYWdyZWUgdG8gd2hhdCBZb2F2IHN0YXRlZCwgdGhh dCBzaWduYWxsaW5nIHBhcnQgKFNJUCkgYW5kIG1lZGlhIHBhcnQgKFJUUCkgYm90aCBTSE9VTEQg d29yayBldmVuIGlmIHRoZXJlIGlzIE5BVCBpbiB0aGUgY29uZmlndXJhdGlvbiB0b2RheS4gSG93 ZXZlciwmbmJzcDtJIGNvdWxkIG5vdCBnZXQgd2h5IHdlIG5lZWQgdG8gaGF2ZSBuZXcgTkFUIHRy YXZlcnNhbCBtZWNoYW5pc20gdXNpbmcgaHViIGdhdGV3YXksIGNhbiB5b3UmbmJzcDtlbGFib3Jh dGUmbmJzcDtvbiB0aGlzLi4uPGRpdj4NCjxicj48L2Rpdj48ZGl2PlRoYW5rcyBhbmQgUmVnYXJk cyw8YnI+WW9nZW5kcmEgUGFsPC9kaXY+PGRpdj5Fcmljc3NvbiwgSW5kaWE8YnI+KzkxLTk2ODYy MDI2NDQ8L2Rpdj48ZGl2PiZuYnNwOyZuYnNwOzxicj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVv dGUiPk9uIFdlZCwgTWFyIDIxLCAyMDEyIGF0IDY6NDkgUE0sIFlvYXYgTmlyIDxzcGFuIGRpcj0i bHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnluaXJAY2hlY2twb2ludC5jb20iPnluaXJAY2hlY2tw b2ludC5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mg c29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBjbGFzcz0iaW0iPiJkaXJlY3QgZW5kcG9pbnQt dG8tZW5kcG9pbnQgY29ubmVjdGl2aXR5IG1heSBub3QgYmUgcG9zc2libGUgaWYgYm90aCBlbmRw b2ludHMgYXJlIE5BVGVkIjxicj4NCg0KPGJyPg0KPC9kaXY+V2h5PyAmbmJzcDtUaGVyZSBhcmUg c2V2ZXJhbCBwcm90b2NvbHMgKFNJUC9SVFAgY29tZSB0byBtaW5kKSB0aGF0IG1hbmFnZSBlbmRw b2ludC10by1lbmRwb2ludCBjb25uZWN0aXZpdHkgZXZlbiB3aGVuIGJvdGggYXJlIGJlaGluZCBO QVQuIFdoeSBzaG91bGRuJ3QgSVBzZWMgZW5kcG9pbnRzIGRvIHRoaXM/PGJyPg0KPGJyPg0KSWYg dGhpcyByZXF1aXJlcyBzb21lIG5ldyBOQVQgdHJhdmVyc2FsIG1lY2hhbmlzbSwgcGVyaGFwcyB1 c2luZyBhIGh1YiBnYXRld2F5IGluIHBsYWNlIG9mIHRoZSBTSVAgU0JDLCB0aGVuIHRoaXMgc2hv dWxkIGJlIHBhcnQgb2YgdGhlIHJlcXVpcmVtZW50cy48YnI+DQo8YnI+DQpUaGlzIG1lY2hhbmlz bSBpcyBuZWVkZWQgZXZlbiBpZiBvbmx5IG9uZSBlbmRwb2ludCBpcyBOQVR0ZWQsIG90aGVyd2lz ZSB3ZSdyZSBjb25zdHJhaW5pbmcgd2hvIHRoZSBpbml0aWF0b3IgaGFzIHRvIGJlLjxicj4NCjxi cj4NCllvYXY8YnI+DQo8ZGl2PjxkaXY+PC9kaXY+PGRpdiBjbGFzcz0iaDUiPjxicj4NCk9uIE1h ciAyMSwgMjAxMiwgYXQgMzozMSBBTSwgU3RlcGhlbiBIYW5uYSB3cm90ZTo8YnI+DQo8YnI+DQom Z3Q7IEFub3RoZXIgaXNzdWUuIFBsZWFzZSBjb21tZW50IG9uIFN1Z2dlc3RlZCBSZXNvbHV0aW9u Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBTdGV2ZTxi cj4NCiZndDs8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBG cm9tOiBpcHNlY21lIGlzc3VlIHRyYWNrZXIgW21haWx0bzo8YSBocmVmPSJtYWlsdG86dHJhY0B0 b29scy5pZXRmLm9yZyI+dHJhY0B0b29scy5pZXRmLm9yZzwvYT5dPGJyPg0KJmd0OyBTZW50OiBU dWVzZGF5LCBNYXJjaCAyMCwgMjAxMiA2OjU4IFBNPGJyPg0KJmd0OyBUbzogPGEgaHJlZj0ibWFp bHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSI+eWFyb25mLmlldGZAZ21haWwuY29tPC9hPjsgPGEg aHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtaXBzZWNtZS1wMnAtdnBuLXByb2JsZW1AdG9vbHMuaWV0 Zi5vcmciPmRyYWZ0LWlldGYtaXBzZWNtZS1wMnAtdnBuLXByb2JsZW1AdG9vbHMuaWV0Zi5vcmc8 L2E+PGJyPg0KJmd0OyBTdWJqZWN0OiBbaXBzZWNtZV0gIzIxMzogSW4gdXNlIGNhc2UgMi4xLCBk aXJlY3QgZW5kcG9pbnQtdG8tZW5kcG9pbnQgY29ubmVjdGl2aXR5IG1heSBub3QgYmUgcG9zc2li bGU8YnI+DQomZ3Q7PGJyPg0KJmd0OyAjMjEzOiBJbiB1c2UgY2FzZSAyLjEsIGRpcmVjdCBlbmRw b2ludC10by1lbmRwb2ludCBjb25uZWN0aXZpdHkgbWF5IG5vdCBiZTxicj4NCiZndDsgcG9zc2li bGU8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJbiB1c2UgY2FzZSAyLjEsIGRpcmVjdCBlbmRwb2ludC10 by1lbmRwb2ludCBjb25uZWN0aXZpdHkgbWF5IG5vdCBiZSBwb3NzaWJsZTxicj4NCiZndDsgaWYg Ym90aCBlbmRwb2ludHMgYXJlIE5BVGVkLjxicj4NCiZndDs8YnI+DQomZ3Q7IFN1Z2dlc3RlZCBS ZXNvbHV0aW9uOiBNZW50aW9uIHRoaXMgaW4gc2VjdGlvbiAyLjEuPGJyPg0KJmd0Ozxicj4NCiZn dDsgLS08YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgJm5ic3A7UmVwb3J0 ZXI6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5i c3A7ICZuYnNwOyAmbmJzcDtPd25lcjogJm5ic3A7ZHJhZnQtaWV0Zi1pcHNlY21lLXAycC12cG4t PGJyPg0KJmd0OyAmbmJzcDt5YXJvbmYuaWV0ZkDigKYgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3wgJm5ic3A7cHJvYmxlbUDigKY8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7VHlwZTogJm5ic3A7ZGVmZWN0ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7 IFN0YXR1czogJm5ic3A7bmV3PGJyPg0KJmd0OyAmbmJzcDtQcmlvcml0eTogJm5ic3A7bm9ybWFs ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDtNaWxlc3RvbmU6PGJyPg0KJmd0OyBDb21wb25l bnQ6ICZuYnNwO3AycC12cG4tICZuYnNwOyAmbmJzcDt8ICZuYnNwOyBTZXZlcml0eTogJm5ic3A7 LTxicj4NCiZndDsgJm5ic3A7cHJvYmxlbSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgS2V5d29yZHM6PGJyPg0KJmd0OyBSZXNv bHV0aW9uOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8 PGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaWNrZXQg VVJMOiAmbHQ7PGEgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvaXBzZWNtZS90 cmFjL3RpY2tldC8yMTMjY29tbWVudDoxIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3RyYWMudG9v bHMuaWV0Zi5vcmcvd2cvaXBzZWNtZS90cmFjL3RpY2tldC8yMTMjY29tbWVudDoxPC9hPiZndDs8 YnI+DQomZ3Q7IGlwc2VjbWUgJmx0OzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9pcHNl Y21lLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9pcHNlY21lLzwvYT4m Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7IElQc2VjIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEg aHJlZj0ibWFpbHRvOklQc2VjQGlldGYub3JnIj5JUHNlY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7 IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2Vj PC9hPjxicj4NCjwvZGl2PjwvZGl2PiZndDsgScan77+977+9W++/vSheckPvv717U++/vdalSe+/ vS7vv70rciDvv71e77+977+9PGJyPg0KPGRpdj48ZGl2PjwvZGl2PjxkaXYgY2xhc3M9Img1Ij48 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CklQc2VjIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJUHNlY0BpZXRmLm9yZyI+ SVBzZWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pcHNlYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaXBzZWM8L2E+PGJyPg0KPC9kaXY+PC9kaXY+PC9ibG9ja3F1b3Rl PjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+PGRpdj48YnI+PC9kaXY+LS0gPGJyPjxicj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_8D8F1D71D2214AEBAB2562651315ACC9checkpointcom_-- From ynir@checkpoint.com Thu Mar 22 00:33:46 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D7621F856F for ; Thu, 22 Mar 2012 00:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.488 X-Spam-Level: X-Spam-Status: No, score=-10.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ids7a82w3xWu for ; Thu, 22 Mar 2012 00:33:45 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2917321F8532 for ; Thu, 22 Mar 2012 00:33:44 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2M7XgrY029460; Thu, 22 Mar 2012 09:33:42 +0200 X-CheckPoint: {4F6AD547-0-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 22 Mar 2012 09:33:41 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 22 Mar 2012 09:33:41 +0200 From: Yoav Nir To: Stephen Hanna Date: Thu, 22 Mar 2012 09:33:43 +0200 Thread-Topic: [IPsec] [ipsecme] #219: Star topology as an admin choice Thread-Index: Ac0H/hqNguwDGXumQ2+RjHhMfHO23g== Message-ID: <7F1EC58E-CD16-4468-8F6C-D827EDA0F8B9@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: IPsecme WG Subject: Re: [IPsec] [ipsecme] #219: Star topology as an admin choice X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 07:33:46 -0000 SSBkb24ndCB0aGluayB0aGlzIGlzIGFuIGFsbC1vci1ub3RoaW5nIGNob2ljZS4gWW91IG1pZ2h0 IHdhbnQgYSBtZXNoIGZvciBWb0lQLCBidXQgYSBzdGFyIGZvciBIVFRQLCBGVFAgYW5kIG1haWwg cHJvdG9jb2xzLiBPciB5b3UgbWF5IHdhbnQgYSBtZXNoIHdpdGhpbiB5b3VyIG9yZ2FuaXphdGlv biwgYnV0IHRvIHRydW5rIGFuZCBpbnNwZWN0IGFsbCB0cmFmZmljIGdvaW5nIHNvbWV3aGVyZSBl bHNlLg0KDQpPbiBNYXIgMjEsIDIwMTIsIGF0IDM6MzcgQU0sIFN0ZXBoZW4gSGFubmEgd3JvdGU6 DQoNCj4gUGxlYXNlIGNvbW1lbnQuDQo+IA0KPiBTdGV2ZQ0KPiANCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogaXBzZWNtZSBpc3N1ZSB0cmFja2VyIFttYWlsdG86dHJhY0B0 b29scy5pZXRmLm9yZ10gDQo+IFNlbnQ6IFR1ZXNkYXksIE1hcmNoIDIwLCAyMDEyIDc6MDQgUE0N Cj4gVG86IHlhcm9uZi5pZXRmQGdtYWlsLmNvbTsgZHJhZnQtaWV0Zi1pcHNlY21lLXAycC12cG4t cHJvYmxlbUB0b29scy5pZXRmLm9yZw0KPiBTdWJqZWN0OiBbaXBzZWNtZV0gIzIxOTogU3RhciB0 b3BvbG9neSBhcyBhbiBhZG1pbiBjaG9pY2UNCj4gDQo+ICMyMTk6IFN0YXIgdG9wb2xvZ3kgYXMg YW4gYWRtaW4gY2hvaWNlDQo+IA0KPiBTb21lIGFkbWlucyBwcmVmZXIgYSBzdGFyIHRvcG9sb2d5 IHNvIHRoZXkgY2FuIGluc3BlY3QgdHJhZmZpYy4gVGhleSBtYXkNCj4gbm90IHdhbnQgdG8gdXNl IHRoaXMgdGVjaG5vbG9neS4NCj4gDQo+IFN1Z2dlc3RlZCBSZXNvbHV0aW9uOiBNZW50aW9uIHRo aXMgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24uDQo+IA0KPiAtLSANCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IFJlcG9ydGVyOiAgICAgICAgICAgICAgIHwgICAgICBPd25l cjogIGRyYWZ0LWlldGYtaXBzZWNtZS1wMnAtdnBuLQ0KPiAgeWFyb25mLmlldGZA4oCmICAgICAg ICAgIHwgIHByb2JsZW1A4oCmDQo+ICAgICBUeXBlOiAgZGVmZWN0ICAgICAgIHwgICAgIFN0YXR1 czogIG5ldw0KPiBQcmlvcml0eTogIG5vcm1hbCAgICAgICB8ICBNaWxlc3RvbmU6DQo+IENvbXBv bmVudDogIHAycC12cG4tICAgICB8ICAgU2V2ZXJpdHk6ICAtDQo+ICBwcm9ibGVtICAgICAgICAg ICAgICAgIHwNCj4gS2V5d29yZHM6ICAgICAgICAgICAgICAgfA0KPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gDQo+IFRpY2tldCBVUkw6IDxodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9pcHNl Y21lL3RyYWMvdGlja2V0LzIxOT4NCj4gaXBzZWNtZSA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2lw c2VjbWUvPg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gSVBzZWMgbWFpbGluZyBsaXN0DQo+IElQc2VjQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCj4gBO+/vWp577+9de+/ve+/ve+/ ve+/vSQ+77+977+977+9Oi1qVO+/vXLvv73vv70h77+977+977+9Gg0KDQo= From Chris.Ulliott@cesg.gsi.gov.uk Thu Mar 22 02:27:38 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC2C21F8611 for ; Thu, 22 Mar 2012 02:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyC9Y2cNgKVk for ; Thu, 22 Mar 2012 02:27:38 -0700 (PDT) Received: from mail185.messagelabs.com (mail185.messagelabs.com [85.158.143.19]) by ietfa.amsl.com (Postfix) with SMTP id 70A2B21F860B for ; Thu, 22 Mar 2012 02:27:36 -0700 (PDT) X-Env-Sender: Chris.Ulliott@cesg.gsi.gov.uk X-Msg-Ref: server-5.tower-185.messagelabs.com!1332408456!13618632!1 X-Originating-IP: [62.25.106.208] X-StarScan-Version: 6.5.7; banners=cesg.gsi.gov.uk,-,- X-VirusChecked: Checked Received: (qmail 6308 invoked from network); 22 Mar 2012 09:27:36 -0000 Received: from gateway-102.energis.gsi.gov.uk (HELO mx22.hosting-w.gsi.gov.uk) (62.25.106.208) by server-5.tower-185.messagelabs.com with SMTP; 22 Mar 2012 09:27:36 -0000 From: "Ulliott, Chris" To: 'Yoav Nir' , Stephen Hanna Date: Thu, 22 Mar 2012 09:26:40 +0000 Thread-Topic: [IPsec] [ipsecme] #219: Star topology as an admin choice Thread-Index: Ac0H/hqNguwDGXumQ2+RjHhMfHO23gAD2nDA Message-ID: <20549DD10769DA47A86F0F0FAF8012DD037C60A6BA@PIACHEVEX00.GCHQ.GOV.UK> In-Reply-To: <7F1EC58E-CD16-4468-8F6C-D827EDA0F8B9@checkpoint.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] [ipsecme] #219: Star topology as an admin choice X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 09:27:38 -0000 UHJvdGVjdGl2ZSBNYXJraW5nOiBVTkNMQVNTSUZJRUQKCkkgdGhpbmsgdGhlIGltcG9ydGFudCBw b2ludCBoZXJlIGlzIHRoYXQgeW91IHNob3VsZCBiZSBhYmxlIHRvIHNldCBhIHBvbGljeSB0byBk ZXRlcm1pbmUgd2hpY2ggZ2F0ZXdheXMsIGEgZ2l2ZW4gZ2F0ZXdheSBpcyAob3IgaXNuJ3QpIHBl cm1pdHRlZCB0byBjb21tdW5pY2F0ZSB3aXRoLiAgVGhlIGludGVyZXN0aW5nIHF1ZXN0aW9uIGlz IGhvdyBncmFudWxhciB0aGF0IHBvbGljeSBzaG91bGQgYmUgKGFsbCBvciBub3RoaW5nIC12LSBi eSBwcm90b2NvbCwgcG9ydCBldGMpLi4uIFRoaXMgdGhlbiBsZWFkcyBvbnRvIGFuIGFkZGl0aW9u YWwgcmVxdWlyZW1lbnQgKEkgYmVsaWV2ZSkgZm9yIGEgcHJvY2VzcyBmb3IgZGlzdHJpYnV0aW5n IHBvbGljeSB0byBnYXRld2F5cy4uLi4KCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCkZyb206 IGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppcHNlYy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgWW9hdiBOaXIKU2VudDogVGh1cnNkYXksIE1hcmNoIDIyLCAyMDEyIDc6MzQg QU0KVG86IFN0ZXBoZW4gSGFubmEKQ2M6IElQc2VjbWUgV0cKU3ViamVjdDogUmU6IFtJUHNlY10g W2lwc2VjbWVdICMyMTk6IFN0YXIgdG9wb2xvZ3kgYXMgYW4gYWRtaW4gY2hvaWNlCgpJIGRvbid0 IHRoaW5rIHRoaXMgaXMgYW4gYWxsLW9yLW5vdGhpbmcgY2hvaWNlLiBZb3UgbWlnaHQgd2FudCBh IG1lc2ggZm9yIFZvSVAsIGJ1dCBhIHN0YXIgZm9yIEhUVFAsIEZUUCBhbmQgbWFpbCBwcm90b2Nv bHMuIE9yIHlvdSBtYXkgd2FudCBhIG1lc2ggd2l0aGluIHlvdXIgb3JnYW5pemF0aW9uLCBidXQg dG8gdHJ1bmsgYW5kIGluc3BlY3QgYWxsIHRyYWZmaWMgZ29pbmcgc29tZXdoZXJlIGVsc2UuCgpP biBNYXIgMjEsIDIwMTIsIGF0IDM6MzcgQU0sIFN0ZXBoZW4gSGFubmEgd3JvdGU6Cgo+IFBsZWFz ZSBjb21tZW50Lgo+Cj4gU3RldmUKPgo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gRnJv bTogaXBzZWNtZSBpc3N1ZSB0cmFja2VyIFttYWlsdG86dHJhY0B0b29scy5pZXRmLm9yZ10KPiBT ZW50OiBUdWVzZGF5LCBNYXJjaCAyMCwgMjAxMiA3OjA0IFBNCj4gVG86IHlhcm9uZi5pZXRmQGdt YWlsLmNvbTsgZHJhZnQtaWV0Zi1pcHNlY21lLXAycC12cG4tcHJvYmxlbUB0b29scy5pZXRmLm9y Zwo+IFN1YmplY3Q6IFtpcHNlY21lXSAjMjE5OiBTdGFyIHRvcG9sb2d5IGFzIGFuIGFkbWluIGNo b2ljZQo+Cj4gIzIxOTogU3RhciB0b3BvbG9neSBhcyBhbiBhZG1pbiBjaG9pY2UKPgo+IFNvbWUg YWRtaW5zIHByZWZlciBhIHN0YXIgdG9wb2xvZ3kgc28gdGhleSBjYW4gaW5zcGVjdCB0cmFmZmlj LiBUaGV5IG1heQo+IG5vdCB3YW50IHRvIHVzZSB0aGlzIHRlY2hub2xvZ3kuCj4KPiBTdWdnZXN0 ZWQgUmVzb2x1dGlvbjogTWVudGlvbiB0aGlzIGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9u cyBzZWN0aW9uLgo+Cj4gLS0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBSZXBvcnRlcjogICAgICAg ICAgICAgICB8ICAgICAgT3duZXI6ICBkcmFmdC1pZXRmLWlwc2VjbWUtcDJwLXZwbi0KPiAgeWFy b25mLmlldGZA4oCmICAgICAgICAgIHwgIHByb2JsZW1A4oCmCj4gICAgIFR5cGU6ICBkZWZlY3Qg ICAgICAgfCAgICAgU3RhdHVzOiAgbmV3Cj4gUHJpb3JpdHk6ICBub3JtYWwgICAgICAgfCAgTWls ZXN0b25lOgo+IENvbXBvbmVudDogIHAycC12cG4tICAgICB8ICAgU2V2ZXJpdHk6ICAtCj4gIHBy b2JsZW0gICAgICAgICAgICAgICAgfAo+IEtleXdvcmRzOiAgICAgICAgICAgICAgIHwKPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KPgo+IFRpY2tldCBVUkw6IDxodHRwOi8vdHJhYy50b29scy5pZXRmLm9y Zy93Zy9pcHNlY21lL3RyYWMvdGlja2V0LzIxOT4KPiBpcHNlY21lIDxodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaXBzZWNtZS8+Cj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwo+IElQc2VjIG1haWxpbmcgbGlzdAo+IElQc2VjQGlldGYub3JnCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYwo+IATvv71qee+/vXXvv73vv73v v73vv70kPu+/ve+/ve+/vTotalTvv71y77+977+9Ie+/ve+/ve+/vRoKCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCklQc2VjIG1haWxpbmcgbGlzdApJUHNl Y0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjCgpU aGlzIGVtYWlsIHdhcyByZWNlaXZlZCBmcm9tIHRoZSBJTlRFUk5FVCBhbmQgc2Nhbm5lZCBieSB0 aGUgR292ZXJubWVudCBTZWN1cmUgSW50cmFuZXQgYW50aS12aXJ1cyBzZXJ2aWNlIHN1cHBsaWVk IGJ5IENhYmxlJldpcmVsZXNzIFdvcmxkd2lkZSBpbiBwYXJ0bmVyc2hpcCB3aXRoIE1lc3NhZ2VM YWJzLiAoQ0NUTSBDZXJ0aWZpY2F0ZSBOdW1iZXIgMjAwOS8wOS8wMDUyLikgSW4gY2FzZSBvZiBw cm9ibGVtcywgcGxlYXNlIGNhbGwgeW91ciBvcmdhbmlzYXRpb27igJlzIElUIEhlbHBkZXNrLgpD b21tdW5pY2F0aW9ucyB2aWEgdGhlIEdTaSBtYXkgYmUgYXV0b21hdGljYWxseSBsb2dnZWQsIG1v bml0b3JlZCBhbmQvb3IgcmVjb3JkZWQgZm9yIGxlZ2FsIHB1cnBvc2VzLgoKKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKgpDb21tdW5pY2F0aW9ucyB3aXRoIEdDSFEgbWF5IGJlIG1vbml0b3JlZCBhbmQvb3Ig cmVjb3JkZWQgCmZvciBzeXN0ZW0gZWZmaWNpZW5jeSBhbmQgb3RoZXIgbGF3ZnVsIHB1cnBvc2Vz LiBBbnkgdmlld3Mgb3IgCm9waW5pb25zIGV4cHJlc3NlZCBpbiB0aGlzIGUtbWFpbCBkbyBub3Qg bmVjZXNzYXJpbHkgcmVmbGVjdCBHQ0hRIApwb2xpY3kuICBUaGlzIGVtYWlsLCBhbmQgYW55IGF0 dGFjaG1lbnRzLCBpcyBpbnRlbmRlZCBmb3IgdGhlIAphdHRlbnRpb24gb2YgdGhlIGFkZHJlc3Nl ZShzKSBvbmx5LiBJdHMgdW5hdXRob3Jpc2VkIHVzZSwgCmRpc2Nsb3N1cmUsIHN0b3JhZ2Ugb3Ig Y29weWluZyBpcyBub3QgcGVybWl0dGVkLiAgSWYgeW91IGFyZSBub3QgdGhlCmludGVuZGVkIHJl Y2lwaWVudCwgcGxlYXNlIG5vdGlmeSBwb3N0bWFzdGVyQGdjaHEuZ3NpLmdvdi51ay4gIAoKVGhp cyBpbmZvcm1hdGlvbiBpcyBleGVtcHQgZnJvbSBkaXNjbG9zdXJlIHVuZGVyIHRoZSBGcmVlZG9t IG9mIApJbmZvcm1hdGlvbiBBY3QgMjAwMCBhbmQgbWF5IGJlIHN1YmplY3QgdG8gZXhlbXB0aW9u IHVuZGVyCm90aGVyIFVLIGluZm9ybWF0aW9uIGxlZ2lzbGF0aW9uLiBSZWZlciBkaXNjbG9zdXJl IHJlcXVlc3RzIHRvIApHQ0hRIG9uIDAxMjQyIDIyMTQ5MSBleHQgMzAzMDYgKG5vbi1zZWN1cmUp IG9yIGVtYWlsCmluZm9sZWdAZ2NocS5nc2kuZ292LnVrCgoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCgoK VGhlIG9yaWdpbmFsIG9mIHRoaXMgZW1haWwgd2FzIHNjYW5uZWQgZm9yIHZpcnVzZXMgYnkgdGhl IEdvdmVybm1lbnQgU2VjdXJlIEludHJhbmV0IHZpcnVzIHNjYW5uaW5nIHNlcnZpY2Ugc3VwcGxp ZWQgYnkgQ2FibGUmV2lyZWxlc3MgV29ybGR3aWRlIGluIHBhcnRuZXJzaGlwIHdpdGggTWVzc2Fn ZUxhYnMuIChDQ1RNIENlcnRpZmljYXRlIE51bWJlciAyMDA5LzA5LzAwNTIuKSBPbiBsZWF2aW5n IHRoZSBHU2kgdGhpcyBlbWFpbCB3YXMgY2VydGlmaWVkIHZpcnVzIGZyZWUuCkNvbW11bmljYXRp b25zIHZpYSB0aGUgR1NpIG1heSBiZSBhdXRvbWF0aWNhbGx5IGxvZ2dlZCwgbW9uaXRvcmVkIGFu ZC9vciByZWNvcmRlZCBmb3IgbGVnYWwgcHVycG9zZXMuCg== From jntupal@gmail.com Thu Mar 22 09:25:37 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1693621F85C0 for ; Thu, 22 Mar 2012 09:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oigsDNzo7VKh for ; Thu, 22 Mar 2012 09:25:36 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 99BEF21F8624 for ; Thu, 22 Mar 2012 09:25:35 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so814137wib.13 for ; Thu, 22 Mar 2012 09:25:34 -0700 (PDT) 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=WObxi42Pofz7S/H6KAD3fjwLfl2eb7H5Lt6ONkNmYgY=; b=0CLugzEQSVwDjf5K5NZRbk50YbJcDnMa+HBhpZTZP4GbtqU7xKsCkZMAwOKDvx0c17 EiD0yKHH22pgTh3k5vaZkbTEU+nWB/jJwGrGaMthv8kZgjXmw56FXzzvuean2d2ivdRh WUR7hdpQVFgnotBRVIGqqIqIWVNym/tZCM9GigTKUYE9U/5Li+Q48XuuWGBOQhiU+cVU mflAE2ln5gIaIAsRSQx8XzMPeuIQbxbd43Uscri1U5Eux8yLJusocLcu8Pp4hyRe69Ht cweS5eGdTsrQWhL/mljFeyEDJuFBxZk7BD2OyU2JGu2gDkC4cIZPvfZYxxTeOazBYKJ7 5Low== MIME-Version: 1.0 Received: by 10.216.134.205 with SMTP id s55mr4918964wei.100.1332433534496; Thu, 22 Mar 2012 09:25:34 -0700 (PDT) Received: by 10.216.2.79 with HTTP; Thu, 22 Mar 2012 09:25:34 -0700 (PDT) In-Reply-To: <8D8F1D71-D221-4AEB-AB25-62651315ACC9@checkpoint.com> References: <21AAB4E5-7E09-4897-BA67-469C60B7CAA0@checkpoint.com> <8D8F1D71-D221-4AEB-AB25-62651315ACC9@checkpoint.com> Date: Thu, 22 Mar 2012 21:55:34 +0530 Message-ID: From: yogendra pal To: Yoav Nir Content-Type: multipart/alternative; boundary=001636eeece682af6404bbd75bcc Cc: IPsecme WG , Stephen Hanna Subject: Re: [IPsec] [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 16:25:37 -0000 --001636eeece682af6404bbd75bcc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Yoav for elaborating it. I was just thinking around this 3rd party broker to setup host-2-host tunnel. This broker can part of any private cloud or mixed cloud in Cloud network (Can be added to solution). Stephen, To make p2p vpn scaleable, I think we should have simple solution with light weight implementation ( i.e. using minimal implementation of IKEv2 and IPsec). Do you think this SHOULD become the part of requirement. Thanks, Yogendra Pal Ericsson, India On Thu, Mar 22, 2012 at 1:00 PM, Yoav Nir wrote: > Sure. A VPN host (whether client or gateway) that is behind NAT is > generally unreachable from a random host. > > To allow random hosts to get there, the VPN host needs to "punch a hole" > in the NAT by sending a binding request to a STUN server. The IP routable > IP address and port that it uses should be stored somewhere, in case some > random VPN host wants to contact it. It has to be stored outside the VPN > host itself, because that host is unreachable. > > So if one or both of the VPN peers are behind NAT, we need some 3rd-party > or parties to broken the NAT traversal. We need: > - a STUN (or STUN-like) server for punching the hole > - storage for the discovered address and port > > In SIP these functions are done by the SBC. > > So just like the #214 and #217 issues, we need a 3rd party to broker the > host-2-host tunnel that we want to set up. It's tempting to assign this > function to a hub gateway as the VPN host already has the ability to > authenticate to it, but that should be part of the design, not the > requirements > > Yoav > > P.S: Sorry if my SIP/RTP terminology is off. It's all based on a cursory > reading of a Wikipedia article. > > On Mar 22, 2012, at 7:58 AM, yogendra pal wrote: > > I agree to what Yoav stated, that signalling part (SIP) and media part > (RTP) both SHOULD work even if there is NAT in the configuration today. > However, I could not get why we need to have new NAT traversal mechanism > using hub gateway, can you elaborate on this... > > Thanks and Regards, > Yogendra Pal > Ericsson, India > +91-9686202644 > > > On Wed, Mar 21, 2012 at 6:49 PM, Yoav Nir wrote: > >> "direct endpoint-to-endpoint connectivity may not be possible if both >> endpoints are NATed" >> >> Why? There are several protocols (SIP/RTP come to mind) that manage >> endpoint-to-endpoint connectivity even when both are behind NAT. Why >> shouldn't IPsec endpoints do this? >> >> If this requires some new NAT traversal mechanism, perhaps using a hub >> gateway in place of the SIP SBC, then this should be part of the >> requirements. >> >> This mechanism is needed even if only one endpoint is NATted, otherwise >> we're constraining who the initiator has to be. >> >> Yoav >> >> On Mar 21, 2012, at 3:31 AM, Stephen Hanna wrote: >> >> > Another issue. Please comment on Suggested Resolution. >> > >> > Thanks, >> > >> > Steve >> > >> > -----Original Message----- >> > From: ipsecme issue tracker [mailto:trac@tools.ietf.org] >> > Sent: Tuesday, March 20, 2012 6:58 PM >> > To: yaronf.ietf@gmail.com; >> draft-ietf-ipsecme-p2p-vpn-problem@tools.ietf.org >> > Subject: [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint >> connectivity may not be possible >> > >> > #213: In use case 2.1, direct endpoint-to-endpoint connectivity may no= t >> be >> > possible >> > >> > In use case 2.1, direct endpoint-to-endpoint connectivity may not be >> possible >> > if both endpoints are NATed. >> > >> > Suggested Resolution: Mention this in section 2.1. >> > >> > -- >> > >> -------------------------+----------------------------------------------= --- >> > Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn- >> > yaronf.ietf@=E2=80=A6 | problem@=E2=80=A6 >> > Type: defect | Status: new >> > Priority: normal | Milestone: >> > Component: p2p-vpn- | Severity: - >> > problem | Keywords: >> > Resolution: | >> > >> -------------------------+----------------------------------------------= --- >> > >> > Ticket URL: < >> http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/213#comment:1> >> > ipsecme >> > >> > _______________________________________________ >> > IPsec mailing list >> > IPsec@ietf.org >> > https://www.ietf.org/mailman/listinfo/ipsec >> > I=C6=A7=EF=BF=BD=EF=BF=BD[=EF=BF=BD(^rC=EF=BF=BD{S=EF=BF=BD=D6=A5I=EF= =BF=BD.=EF=BF=BD+r =EF=BF=BD^=EF=BF=BD=EF=BF=BD >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > > > -- > > > --001636eeece682af6404bbd75bcc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Yoav for=C2=A0elaborating it. I was just thinking around this 3rd pa= rty=C2=A0broker to setup host-2-host tunnel. This broker can part of any pr= ivate cloud or mixed cloud in Cloud network (Can be added to solution).
Stephen,

To make p2p vpn scaleable, I think w= e should have simple solution with light weight implementation =C2=A0( i.e.= using minimal implementation of IKEv2 and IPsec). Do you think this SHOULD= become the part of requirement.

=C2=A0
Thanks,
Yogendra Pal
Ericsson, I= ndia

On Thu, Mar 22, 2012 at 1= :00 PM, Yoav Nir <ynir@checkpoint.com> wrote:
Sure. A = VPN host (whether client or gateway) that is behind NAT is generally unreac= hable from a random host.

To allow random hosts to get there, the VPN host needs to &q= uot;punch a hole" in the NAT by sending a binding request to a STUN se= rver. The IP routable IP address and port that it uses should be stored som= ewhere, in case some random VPN host wants to contact it. It has to be stor= ed outside the VPN host itself, because that host is unreachable.=C2=A0

So if one or both of the VPN peers are behind NAT, we n= eed some 3rd-party or parties to broken the NAT traversal. We need:
=C2=A0- a STUN (or STUN-like) server for punching the hole
=C2= =A0- storage for the discovered address and port

In SIP these functions are done by the SBC.
<= br>
So just like the #214 and #217 issues, we need a 3rd party to= broker the host-2-host tunnel that we want to set up. It's tempting to= assign this function to a hub gateway as the VPN host already has the abil= ity to authenticate to it, but that should be part of the design, not the r= equirements

Yoav

P.S: Sorry if my SIP/RTP terminology is off. It's all based on a = cursory reading of a Wikipedia article.

On Mar 22, 2012, at 7:58 AM, yogendra pal wrote:
I agree to what Yoav stated, that signalling pa= rt (SIP) and media part (RTP) both SHOULD work even if there is NAT in the = configuration today. However,=C2=A0I could not get why we need to have new = NAT traversal mechanism using hub gateway, can you=C2=A0elaborate=C2=A0on t= his...

Thanks and Regards,
Yogendra Pal
Ericsson, Indi= a
+91-9686202644
=C2=A0=C2=A0

On Wed, Mar 21, 2012 at 6:49 PM, Yoav Nir <ynir@checkpoint.com&g= t; wrote:
"direct endpoint-to-endpoint conne= ctivity may not be possible if both endpoints are NATed"

Why? =C2=A0There are several protocols (SIP/RTP come to mind) that ma= nage endpoint-to-endpoint connectivity even when both are behind NAT. Why s= houldn't IPsec endpoints do this?

If this requires some new NAT traversal mechanism, perhaps using a hub gate= way in place of the SIP SBC, then this should be part of the requirements.<= br>
This mechanism is needed even if only one endpoint is NATted, otherwise we&= #39;re constraining who the initiator has to be.

Yoav

On Mar 21, 2012, at 3:31 AM, Stephen Hanna wrote:

> Another issue. Please comment on Suggested Resolution.
>
> Thanks,
>
> Steve
>
> -----Original Message-----
> From: ipsecme issue tracker [mailto:trac@tools.ietf.org]
> Sent: Tuesday, March 20, 2012 6:58 PM
> To: yaronf.= ietf@gmail.com; draft-ietf-ipsecme-p2p-vpn-problem@tools.ie= tf.org
> Subject: [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint = connectivity may not be possible
>
> #213: In use case 2.1, direct endpoint-to-endpoint connectivity may no= t be
> possible
>
> In use case 2.1, direct endpoint-to-endpoint connectivity may not be p= ossible
> if both endpoints are NATed.
>
> Suggested Resolution: Mention this in section 2.1.
>
> --
> -------------------------+--------------------------------------------= -----
> =C2=A0Reporter: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0Owner: =C2=A0draft-ietf-ipsecme-p2p-vpn-
> =C2=A0yaronf.ietf@=E2=80=A6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0= problem@=E2=80=A6
> =C2=A0 =C2=A0 =C2=A0Type: =C2=A0defect =C2=A0 =C2=A0 =C2=A0| =C2=A0 = =C2=A0 Status: =C2=A0new
> =C2=A0Priority: =C2=A0normal =C2=A0 =C2=A0 =C2=A0| =C2=A0Milestone: > Component: =C2=A0p2p-vpn- =C2=A0 =C2=A0| =C2=A0 Severity: =C2=A0-
> =C2=A0problem =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 Keywords:
> Resolution: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> -------------------------+--------------------------------------------= -----
>
> Ticket URL: <http://trac.tools.ietf.org/wg/ipsec= me/trac/ticket/213#comment:1>
> ipsecme <http://tools.ietf.org/ipsecme/>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org=
> https://www.ietf.org/mailman/listinfo/ipsec
> I=C6=A7=EF=BF=BD=EF=BF=BD[=EF=BF=BD(^rC=EF=BF=BD{S=EF=BF= =BD=D6=A5I=EF=BF=BD.=EF=BF=BD+r =EF=BF=BD^=EF=BF=BD=EF=BF=BD

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



--
=




--001636eeece682af6404bbd75bcc-- From vishwas.ietf@gmail.com Thu Mar 22 10:24:12 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8606121F8518 for ; Thu, 22 Mar 2012 10:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.896 X-Spam-Level: X-Spam-Status: No, score=-3.896 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUIT+j-4tPGk for ; Thu, 22 Mar 2012 10:24:11 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B92DD21F8516 for ; Thu, 22 Mar 2012 10:24:11 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2213393ggm.31 for ; Thu, 22 Mar 2012 10:24:11 -0700 (PDT) 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=H1nDhJ+2GnMSOMAUJsHKQmwBtPFtYxc0ElOzr0UDIAw=; b=U9PDqJVyO9+KrkWAotHZK5RgW29hZAUYGtqAhopYQetfAa3f/98pCp+Kkfu54S8Vd0 g6n95Hvm+fkgyt0f8DweTOj8jDLfPKgqLa38lDyH4NJjmxRR3mVDNQXNcCvWn/VXad+A kEwMwZvVNI9OXOjEsyvo3Jd5W3Au3vWTdJRXRtT5kLEeETRFUhbGtdCBngaK8Hxiqh/L aMWMZysSOZF+Gjm2xcyMXa3ueDi4fF1Ng3XngpRX67FzGfERbXl86XjQ88b3PJfj37pW /umnDHNNKHs3Oiw074udATvTetnMAIgJcnnwchro/a+8KIjqsbrn0zMxhqeP4cUqNrWe R2sw== MIME-Version: 1.0 Received: by 10.60.4.162 with SMTP id l2mr11541434oel.3.1332437051083; Thu, 22 Mar 2012 10:24:11 -0700 (PDT) Received: by 10.182.134.73 with HTTP; Thu, 22 Mar 2012 10:24:11 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 Mar 2012 10:24:11 -0700 Message-ID: From: Vishwas Manral To: yogendra pal Content-Type: multipart/alternative; boundary=e89a8ff1c5ae1d8b8804bbd82db0 Cc: IPsecme WG , Stephen Hanna Subject: Re: [IPsec] [ipsecme] #219: Star topology as an admin choice X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 17:24:12 -0000 --e89a8ff1c5ae1d8b8804bbd82db0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Yogendra, I guess the question being raised here is slightly different. The question is should all traffic be first sent to a central point (Campus/ DC etc) inspected (IDS/ IPS/ Firewall) and then allowed to pass to others peers or should there be a direct connection between the peers too - in which case we would need to have distributed security appliances? In my view it is up to the security administrator to prefer a particular topology for particular communication. We could have some traffic always being sent through the hub (say over the MPLs backbone) while another is just sent directly over the Internet. Thanks, Vishwas On Wed, Mar 21, 2012 at 11:45 PM, yogendra pal wrote: > Why they may not use this technology ? Even today irrespective of the > topology, traffic is intercepted by lawful agencies by using different > mechanism (port mirroring, etc...) > > Thanks, > Yogendra Pal > Ericsson, India > > > On Wed, Mar 21, 2012 at 7:07 AM, Stephen Hanna wrote= : > >> Please comment. >> >> Steve >> >> -----Original Message----- >> From: ipsecme issue tracker [mailto:trac@tools.ietf.org] >> Sent: Tuesday, March 20, 2012 7:04 PM >> To: yaronf.ietf@gmail.com; >> draft-ietf-ipsecme-p2p-vpn-problem@tools.ietf.org >> Subject: [ipsecme] #219: Star topology as an admin choice >> >> #219: Star topology as an admin choice >> >> Some admins prefer a star topology so they can inspect traffic. They ma= y >> not want to use this technology. >> >> Suggested Resolution: Mention this in the Security Considerations >> section. >> >> -- >> >> -------------------------+----------------------------------------------= --- >> Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn- >> yaronf.ietf@=85 | problem@=85 >> Type: defect | Status: new >> Priority: normal | Milestone: >> Component: p2p-vpn- | Severity: - >> problem | >> Keywords: | >> >> -------------------------+----------------------------------------------= --- >> >> Ticket URL: >> ipsecme >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > > > -- > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --e89a8ff1c5ae1d8b8804bbd82db0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Yogendra,

I guess the question being raised here is slightly diff= erent.

The question is should all traffic be first sent to a centra= l point (Campus/ DC etc) inspected (IDS/ IPS/ Firewall) and then allowed to= pass to others peers or should there be a direct connection between the pe= ers too - in which case we would need to have distributed security applianc= es?

In my view it is up to the security administrator to prefer a particula= r topology for particular communication. We could have some traffic always = being sent through the hub (say over the MPLs backbone) while another is ju= st sent directly over the Internet.

Thanks,
Vishwas

On Wed, Mar 21, 20= 12 at 11:45 PM, yogendra pal <jntupal@gmail.com> wrote:
Why they may not use this technology ? Even today irrespective of the topol= ogy, traffic is intercepted by lawful agencies by using different mechanism= (port mirroring, etc...)

Thanks,
Yogendra Pal
Ericsson, Indi= a


On Wed, Mar 21, 2012 at 7:07 AM, Stephen Han= na <shanna@juniper.net> wrote:
Please comment.

Steve

-----Original Message-----
From: ipsecme issue tracker [mailto:trac@tools.ietf.org]
Sent: Tuesday, March 20, 2012 7:04 PM
To: yaronf.ietf@= gmail.com; draft-ietf-ipsecme-p2p-vpn-problem@tools.ietf.or= g
Subject: [ipsecme] #219: Star topology as an admin choice

#219: Star topology as an admin choice

=A0Some admins prefer a star topology so they can inspect traffic. They may=
=A0not want to use this technology.

=A0Suggested Resolution: Mention this in the Security Considerations sectio= n.

--
-------------------------+-------------------------------------------------=
=A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Owner: =A0draft-ietf-= ipsecme-p2p-vpn-
=A0yaronf.ietf@=85 =A0 =A0 =A0 =A0 =A0| =A0problem@=85
=A0 =A0 Type: =A0defect =A0 =A0 =A0 | =A0 =A0 Status: =A0new
=A0Priority: =A0normal =A0 =A0 =A0 | =A0Milestone:
Component: =A0p2p-vpn- =A0 =A0 | =A0 Severity: =A0-
=A0problem =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
-------------------------+-------------------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/= 219>
ipsecme <ht= tp://tools.ietf.org/ipsecme/>

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



--
=

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


--e89a8ff1c5ae1d8b8804bbd82db0-- From melinda.shore@gmail.com Thu Mar 22 11:46:01 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F67F21F8531 for ; Thu, 22 Mar 2012 11:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYRI7wgvAozR for ; Thu, 22 Mar 2012 11:46:00 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B80BF21F8526 for ; Thu, 22 Mar 2012 11:46:00 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1934985pbb.31 for ; Thu, 22 Mar 2012 11:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=I5CijsYdEDgFIhCTA7ASm7pxd24fJydMAt8JHQ3cX08=; b=tSYPTAPoL6EJaVUakoF4bMg6tI6xHKri+T5YuXD934S0/i9AsC8C1mqc8PkNqJQFhL PY8xRcgE/3JYj0rPOgzCA2LkHM+Ng1+CL5sGLuD7/0yRVe8kfNeNRYG7Tfqen2/YpLEs MKD7rwmKrHAxfqZGKyFBsHwxAVBLZ5nGnAQv1FTYpFN9GRjm/wl9EnYW9WSV/p6CLZUU r3r88dzSqqQ+RhmP8x9YfkdjMrUtSIwR63snzdHQkaSp5Eik6qMUPhoySsPRP5SwJloq XuUohL5T8ag5DFUJM/Fc59c9QSlJxESsGE9SfwN811tyqOF8wBvnSuTtxb71CXTUUkzV qSyQ== Received: by 10.68.237.194 with SMTP id ve2mr22484089pbc.60.1332441960613; Thu, 22 Mar 2012 11:46:00 -0700 (PDT) Received: from polypro.local (66-230-81-245-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.81.245]) by mx.google.com with ESMTPS id b10sm4243086pbr.46.2012.03.22.11.45.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Mar 2012 11:45:59 -0700 (PDT) Message-ID: <4F6B7365.9050904@gmail.com> Date: Thu, 22 Mar 2012 10:45:57 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.27) Gecko/20120216 Lightning/1.0b2 Thunderbird/3.1.19 MIME-Version: 1.0 To: ipsec@ietf.org References: <21AAB4E5-7E09-4897-BA67-469C60B7CAA0@checkpoint.com> <8D8F1D71-D221-4AEB-AB25-62651315ACC9@checkpoint.com> In-Reply-To: <8D8F1D71-D221-4AEB-AB25-62651315ACC9@checkpoint.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 18:46:01 -0000 On 3/21/12 11:30 PM, Yoav Nir wrote: > So if one or both of the VPN peers are behind NAT, we need some > 3rd-party or parties to broken the NAT traversal. We need: > - a STUN (or STUN-like) server for punching the hole > - storage for the discovered address and port > In SIP these functions are done by the SBC. To be clear, NAT traversal mechanisms are not part of SIP, per se, although they're frequently deployed in telephony environments. The STUN mechanism was originally developed by some folks at ?Atari? to support gaming, and STUN is not coupled to SIP - it can be used by other protocols, as well. That said, it's a pretty ghastly protocols as protocols go, and provides no protections itself against spoofed responses. There's a dependence on peer authentication by the application that invokes STUN, which is a pretty safe bet in the VPN context and probably isn't a show-stopper even if it is a little ill-making. However, STUN is not the only approach (just the cheesiest). midcom and nsis provide the means to do direct requests between an endpoint and a middlebox (NAT/firewall). pcp is currently working on something similar. This is arguably a more robust, secure approach but it does require support from the firewalls/NAT, not just the application. Melinda From kivinen@iki.fi Sat Mar 24 03:04:58 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23FE821F86AF for ; Sat, 24 Mar 2012 03:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5m5+pMclZN9U for ; Sat, 24 Mar 2012 03:04:57 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E9521F8589 for ; Sat, 24 Mar 2012 03:04:56 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q2OA4nnE013864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Mar 2012 12:04:49 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q2OA4lt4003319; Sat, 24 Mar 2012 12:04:47 +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: <20333.39999.849571.817083@fireball.kivinen.iki.fi> Date: Sat, 24 Mar 2012 12:04:47 +0200 From: Tero Kivinen To: Praveen Sathyanarayan In-Reply-To: References: <4F6A471D.8090606@gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 4 min Cc: "ipsec@ietf.org" , Geoffrey Huang , Stephen Hanna Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 10:04:58 -0000 Praveen Sathyanarayan writes: > Yes. If certificate based authentication was used in the network, there is > no need of new credentials. But if pre-shared key based was used, then we > need this "temporary credentials". Also, it is required to define the > lifetime of this "temporary credentials". For example, if tunnel between > spokes are stays beyond lifetime of SA, then can the same "temporary > credentials" can be used for rekey? Or new "temporary credentials" should > be received from Hub? That starts to sound like certificates... One of the ways to do this is to always use certificates in the on-demand direct vpn connections. I.e if the peer A normally authenticates itself with PSK to the hub, it would then create private key, give it to the hub, which would sign it with hub-only configuration trust anchor, and then other peers could use that key. Or another way would be to use raw public keys, but then we do not have the things like validity periods etc. As X.509 certificate authentication support is already MANDATORY to support in all implementations, that could be the easiest way forward. -- kivinen@iki.fi From ghuang@juniper.net Sat Mar 24 09:36:03 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA5321F8615 for ; Sat, 24 Mar 2012 09:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmjguEqG4zEg for ; Sat, 24 Mar 2012 09:36:02 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 9810821F857D for ; Sat, 24 Mar 2012 09:36:02 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKT2337R3ATYrjAOCN39Z0tz2RhPSNT8Ex@postini.com; Sat, 24 Mar 2012 09:36:02 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Sat, 24 Mar 2012 09:34:56 -0700 From: Geoffrey Huang To: Tero Kivinen Date: Sat, 24 Mar 2012 09:34:56 -0700 Thread-Topic: [IPsec] [ipsecme] #217: Temporary credentials Thread-Index: Ac0J3AvSlSStWXkwSTO8kurUdTKuew== Message-ID: <74EE053E-185C-42E0-9B7E-504DCBB53B2A@juniper.net> References: <4F6A471D.8090606@gmail.com> <20333.39999.849571.817083@fireball.kivinen.iki.fi> In-Reply-To: <20333.39999.849571.817083@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Stephen Hanna , Praveen Sathyanarayan Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 16:36:03 -0000 My initial inclination is to say that won't fly: that many deployments stil= l require preshared key authentication. Rather, they would object to certi= ficates because of perceived complexity. That said, I could see arguments t= hat what we're discussing are already fairly sophisticated topologies, so p= erhaps the certificate allergy doesn't hold? -Geoff On Mar 24, 2012, at 3:05 AM, "Tero Kivinen" wrote: > Praveen Sathyanarayan writes: >> Yes. If certificate based authentication was used in the network, there = is >> no need of new credentials. But if pre-shared key based was used, then w= e >> need this "temporary credentials". Also, it is required to define the >> lifetime of this "temporary credentials". For example, if tunnel between >> spokes are stays beyond lifetime of SA, then can the same "temporary >> credentials" can be used for rekey? Or new "temporary credentials" shoul= d >> be received from Hub? >=20 > That starts to sound like certificates... One of the ways to do this > is to always use certificates in the on-demand direct vpn connections. > I.e if the peer A normally authenticates itself with PSK to the hub, > it would then create private key, give it to the hub, which would sign > it with hub-only configuration trust anchor, and then other peers > could use that key. >=20 > Or another way would be to use raw public keys, but then we do not > have the things like validity periods etc. >=20 > As X.509 certificate authentication support is already MANDATORY to > support in all implementations, that could be the easiest way forward.=20 > --=20 > kivinen@iki.fi From kivinen@iki.fi Sat Mar 24 09:47:54 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C610021F8622 for ; Sat, 24 Mar 2012 09:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgOwV25A-vOr for ; Sat, 24 Mar 2012 09:47:54 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFE921F8615 for ; Sat, 24 Mar 2012 09:47:53 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q2OGlmnd017435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Mar 2012 18:47:48 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q2OGlmT4016337; Sat, 24 Mar 2012 18:47:48 +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: <20333.64180.239547.457765@fireball.kivinen.iki.fi> Date: Sat, 24 Mar 2012 18:47:48 +0200 From: Tero Kivinen To: Geoffrey Huang In-Reply-To: <74EE053E-185C-42E0-9B7E-504DCBB53B2A@juniper.net> References: <4F6A471D.8090606@gmail.com> <20333.39999.849571.817083@fireball.kivinen.iki.fi> <74EE053E-185C-42E0-9B7E-504DCBB53B2A@juniper.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 4 min Cc: "ipsec@ietf.org" , Stephen Hanna , Praveen Sathyanarayan Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 16:47:54 -0000 Geoffrey Huang writes: > My initial inclination is to say that won't fly: that many > deployments still require preshared key authentication. Rather, > they would object to certificates because of perceived complexity. > That said, I could see arguments that what we're discussing are > already fairly sophisticated topologies, so perhaps the certificate > allergy doesn't hold? As we are talking about temporary certificates enrolled by the local trust anchor most of the issues people have with certificates do not apply. Adminstrators etc will never even see those certificates. The vendor implementing this needs to implement fetching the temporary credentials, but that code needs to be written anyways regardless whether we use pre-shared keys or certificates. I would actually except that most of this kind of setups already use certificates as their credentials as if we are talking big networks with possibly "hundreds of thousands of gateways", I do not think anybody even thinks of deploying such networks with pre-shared keys even with hub and spoke model... -- kivinen@iki.fi From paul.hoffman@vpnc.org Sun Mar 25 02:23:09 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3096E21F8459 for ; Sun, 25 Mar 2012 02:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4DQvV-90wOD for ; Sun, 25 Mar 2012 02:23:08 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id F0FF321F8453 for ; Sun, 25 Mar 2012 02:23:06 -0700 (PDT) Received: from dhcp-2121.meeting.ietf.org (dhcp-2121.meeting.ietf.org [130.129.33.33]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2P9N39o025860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 25 Mar 2012 02:23:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 25 Mar 2012 11:23:06 +0200 Message-Id: <0E3B4434-53CC-466E-810A-9FEAD5CC6747@vpnc.org> To: IPsecme WG Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [IPsec] Remote participation in the IPsecME WG meeting tomorrow X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 09:23:09 -0000 Greetings again. Remote participants have two choices for getting the = audio and slides for tomorrow's meeting: Meetecho: Regular IETF tools: Audio: Slides: For contributing to the discussion, you need to send messages to the = Jabber room that will be relayed to the mic. In the Jabber room, prepend = "mic:" to any message you want read at the mic. --Paul Hoffman From paul.hoffman@vpnc.org Sun Mar 25 02:47:42 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051B621F8581 for ; Sun, 25 Mar 2012 02:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISUGJEgyTJuT for ; Sun, 25 Mar 2012 02:47:41 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 85DEB21F8578 for ; Sun, 25 Mar 2012 02:47:41 -0700 (PDT) Received: from dhcp-179c.meeting.ietf.org (dhcp-179c.meeting.ietf.org [130.129.23.156]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2P9lasc026497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 25 Mar 2012 02:47:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: Date: Sun, 25 Mar 2012 11:47:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <29301DF6-DD10-473A-B157-000FDFE5ACAE@vpnc.org> References: To: IPsecme WG X-Mailer: Apple Mail (2.1257) Subject: Re: [IPsec] [ipsecme] #212: Section 2.2 should be more detailed. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 09:47:42 -0000 On Mar 21, 2012, at 2:29 AM, Stephen Hanna wrote: > In a simple use case we want hub and spoke topology for say > the DC and the branches. This would also be true of ATM's > connecting to their DC. >=20 > However for scalability reasons we would not want all traffic > to go through the hub. In the ATM example we could want VoIP > session to bypass the DC and have a direct connectivity between > themselves. There are multiple other uses cases for the same. > These new sessions however are temporary, when compared to > permanent branch to hub connections. Neither ATM nor DC are defined in the current document. It would be = better not to introduce new acronyms for a single use case. --Paul Hoffman From shanna@juniper.net Sun Mar 25 02:49:19 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F29721F8555 for ; Sun, 25 Mar 2012 02:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.572 X-Spam-Level: X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ql+5blPotk0e for ; Sun, 25 Mar 2012 02:49:18 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 865B321F8532 for ; Sun, 25 Mar 2012 02:49:17 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKT27qHMaQmNF9irr5XVj6KqURcCaXbTXg@postini.com; Sun, 25 Mar 2012 02:49:18 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 25 Mar 2012 02:49:06 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Sun, 25 Mar 2012 05:49:05 -0400 From: Stephen Hanna To: Paul Hoffman , IPsecme WG Date: Sun, 25 Mar 2012 05:49:03 -0400 Thread-Topic: [IPsec] [ipsecme] #212: Section 2.2 should be more detailed. Thread-Index: Ac0KbFnQThDtNio5S7aQB1GCqkpxMAAAA5kQ Message-ID: References: <29301DF6-DD10-473A-B157-000FDFE5ACAE@vpnc.org> In-Reply-To: <29301DF6-DD10-473A-B157-000FDFE5ACAE@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] [ipsecme] #212: Section 2.2 should be more detailed. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 09:49:19 -0000 Yes, I agree. I'll rewrite the text to remove acronyms and make the style match the rest of the document. Thanks, Steve=20 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Paul Hoffman > Sent: Sunday, March 25, 2012 5:48 AM > To: IPsecme WG > Subject: Re: [IPsec] [ipsecme] #212: Section 2.2 should be more > detailed. >=20 > On Mar 21, 2012, at 2:29 AM, Stephen Hanna wrote: >=20 > > In a simple use case we want hub and spoke topology for say > > the DC and the branches. This would also be true of ATM's > > connecting to their DC. > > > > However for scalability reasons we would not want all traffic > > to go through the hub. In the ATM example we could want VoIP > > session to bypass the DC and have a direct connectivity between > > themselves. There are multiple other uses cases for the same. > > These new sessions however are temporary, when compared to > > permanent branch to hub connections. >=20 >=20 > Neither ATM nor DC are defined in the current document. It would be > better not to introduce new acronyms for a single use case. >=20 > --Paul Hoffman >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From praveenys@juniper.net Sun Mar 25 15:14:10 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FF621E802D for ; Sun, 25 Mar 2012 15:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sb3vjRzOhgmF for ; Sun, 25 Mar 2012 15:14:09 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 61B6121E800C for ; Sun, 25 Mar 2012 15:14:09 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKT2+YrJga0UoX2KPY/qWo351XSJ17MSb5@postini.com; Sun, 25 Mar 2012 15:14:09 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Sun, 25 Mar 2012 15:13:57 -0700 From: Praveen Sathyanarayan To: Tero Kivinen Date: Sun, 25 Mar 2012 15:10:17 -0700 Thread-Topic: [IPsec] [ipsecme] #217: Temporary credentials Thread-Index: Ac0JpZN7gb3dNcl2TQy3p6RtYv04FwBLnvpa Message-ID: <84600D05C20FF943918238042D7670FD48BFDC8D81@EMBX01-HQ.jnpr.net> References: <4F6A471D.8090606@gmail.com> , <20333.39999.849571.817083@fireball.kivinen.iki.fi> In-Reply-To: <20333.39999.849571.817083@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Geoffrey Huang , Stephen Hanna Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 22:14:10 -0000 This works if there is only one Hub in the network. Scenario where multiple= hubs in hierarchy or multiple Hub's that don't have hierarchical relation,= this will not work. =20 -- Praveen ________________________________________ From: Tero Kivinen [kivinen@iki.fi] Sent: Saturday, March 24, 2012 3:04 AM To: Praveen Sathyanarayan Cc: Yaron Sheffer; Geoffrey Huang; ipsec@ietf.org; Stephen Hanna Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials Praveen Sathyanarayan writes: > Yes. If certificate based authentication was used in the network, there i= s > no need of new credentials. But if pre-shared key based was used, then we > need this "temporary credentials". Also, it is required to define the > lifetime of this "temporary credentials". For example, if tunnel between > spokes are stays beyond lifetime of SA, then can the same "temporary > credentials" can be used for rekey? Or new "temporary credentials" should > be received from Hub? That starts to sound like certificates... One of the ways to do this is to always use certificates in the on-demand direct vpn connections. I.e if the peer A normally authenticates itself with PSK to the hub, it would then create private key, give it to the hub, which would sign it with hub-only configuration trust anchor, and then other peers could use that key. Or another way would be to use raw public keys, but then we do not have the things like validity periods etc. As X.509 certificate authentication support is already MANDATORY to support in all implementations, that could be the easiest way forward. -- kivinen@iki.fi From mcr@sandelman.ca Mon Mar 26 00:52:32 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FEB21F8505 for ; Mon, 26 Mar 2012 00:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.351 X-Spam-Level: X-Spam-Status: No, score=-1.351 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpFWZJdvLoBu for ; Mon, 26 Mar 2012 00:52:31 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 78CD521F84FE for ; Mon, 26 Mar 2012 00:52:31 -0700 (PDT) Received: from marajade.sandelman.ca (dhcp-10ed.meeting.ietf.org [130.129.16.237]) by relay.sandelman.ca (Postfix) with ESMTPS id 4058D34359 for ; Mon, 26 Mar 2012 03:49:48 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id A070198281; Mon, 26 Mar 2012 03:52:28 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 5948598182 for ; Mon, 26 Mar 2012 09:52:28 +0200 (CEST) From: Michael Richardson To: "ipsec@ietf.org" In-Reply-To: <74EE053E-185C-42E0-9B7E-504DCBB53B2A@juniper.net> References: <4F6A471D.8090606@gmail.com> <20333.39999.849571.817083@fireball.kivinen.iki.fi> <74EE053E-185C-42E0-9B7E-504DCBB53B2A@juniper.net> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 26 Mar 2012 09:52:27 +0200 Message-ID: <21602.1332748347@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 07:52:32 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Geoffrey" =3D=3D Geoffrey Huang writes: Geoffrey> My initial inclination is to say that won't fly: that many Geoffrey> deployments still require preshared key authentication. Geoffrey> Rather, they would object to certificates because of Geoffrey> perceived complexity. That said, I could see arguments Geoffrey> that what we're discussing are already fairly Geoffrey> sophisticated topologies, so perhaps the certificate Geoffrey> allergy doesn't hold?=20 Tero isn't proposing using certificates. Tero is proposing that the gateway/hub provides each leaf node with a gateway mediated, ASN.1 encoded, scalable, asymmetric, transitive proofs of identity. It would be used only for the leaf to leaf connection.=20=20 It would be retained for a convenient period of time and then destroyed. End users and leaf systems would continue to "authenticate" to the gateway using the insecure legacy mechanisms that CTOs seem to prefer. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCUAwUAT3AgO4qHRg3pndX9AQKnwAP4vBIRTc71hwn9nO5S28YgQcwsG8IWO3Ym Hj2T9HEtD9UhsJCCVPK5P4TDteMjgD+FdwNbWMJmbwxtDjAq05loMq0a2gkdUWtk DCRAr/t9U0M8Ni1QdPokjo0bnfL5aByLycAZ1JMzyKI7y6Ukz9ksYIzbDtQYa+op fd3caBpIzA== =eekI -----END PGP SIGNATURE----- --=-=-=-- From kivinen@iki.fi Mon Mar 26 01:02:51 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6196721F848F for ; Mon, 26 Mar 2012 01:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOyxXbBIuU3d for ; Mon, 26 Mar 2012 01:02:50 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB0121F8498 for ; Mon, 26 Mar 2012 01:02:49 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q2Q82grO018209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Mar 2012 11:02:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q2Q82f74029634; Mon, 26 Mar 2012 11:02:41 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20336.8865.835279.820688@fireball.kivinen.iki.fi> Date: Mon, 26 Mar 2012 11:02:41 +0300 From: Tero Kivinen To: Praveen Sathyanarayan In-Reply-To: <84600D05C20FF943918238042D7670FD48BFDC8D81@EMBX01-HQ.jnpr.net> References: <4F6A471D.8090606@gmail.com> <20333.39999.849571.817083@fireball.kivinen.iki.fi> <84600D05C20FF943918238042D7670FD48BFDC8D81@EMBX01-HQ.jnpr.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 5 min Cc: "ipsec@ietf.org" , Geoffrey Huang , Stephen Hanna Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 08:02:51 -0000 Praveen Sathyanarayan writes: > This works if there is only one Hub in the network. Scenario where > multiple hubs in hierarchy or multiple Hub's that don't have > hierarchical relation, this will not work. I see no problems even if there is multiple hubs. There are lots of different ways to do things, and we do not need to go to solution space yet (one trust anchor per hub, sub-ca per hub, shared trust anchor between the hubs etc). On the other hand all of the solutions needs to take account the fact that if there are multiple hubs. All depends also what kind of trust relationship the hubs have etc. With certificates there is a way to setup system so that hubs do not need real time policy communications between them. With shared keys the hubs needs to have real time policy communication, as the temporary shared key generated by one hub, needs to be distributed to other hubs needing it. -- kivinen@iki.fi From ynir@checkpoint.com Mon Mar 26 01:08:34 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6881321F85E7 for ; Mon, 26 Mar 2012 01:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.489 X-Spam-Level: X-Spam-Status: No, score=-10.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEgwYZaZ1+gl for ; Mon, 26 Mar 2012 01:08:33 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 770FD21F854B for ; Mon, 26 Mar 2012 01:08:33 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2Q88SIY015027; Mon, 26 Mar 2012 10:08:30 +0200 X-CheckPoint: {4F702333-1-1B221DC2-5FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 26 Mar 2012 10:07:59 +0200 From: Yoav Nir To: Michael Richardson Date: Mon, 26 Mar 2012 10:07:57 +0200 Thread-Topic: [IPsec] [ipsecme] #217: Temporary credentials Thread-Index: Ac0LJ43eB+4vFlYgSXCXczqhkiYyLA== Message-ID: <7A541B0C-EB5A-45A3-B5AF-4C5C7802F98B@checkpoint.com> References: <4F6A471D.8090606@gmail.com> <20333.39999.849571.817083@fireball.kivinen.iki.fi> <74EE053E-185C-42E0-9B7E-504DCBB53B2A@juniper.net> <21602.1332748347@marajade.sandelman.ca> In-Reply-To: <21602.1332748347@marajade.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 08:08:34 -0000 On Mar 26, 2012, at 9:52 AM, Michael Richardson wrote: >=20 >>>>>> "Geoffrey" =3D=3D Geoffrey Huang writes: > Geoffrey> My initial inclination is to say that won't fly: that many > Geoffrey> deployments still require preshared key authentication. > Geoffrey> Rather, they would object to certificates because of > Geoffrey> perceived complexity. That said, I could see arguments > Geoffrey> that what we're discussing are already fairly > Geoffrey> sophisticated topologies, so perhaps the certificate > Geoffrey> allergy doesn't hold?=20 >=20 > Tero isn't proposing using certificates. >=20 > Tero is proposing that the gateway/hub provides each leaf node with a > gateway mediated, ASN.1 encoded, scalable, asymmetric, transitive proofs > of identity. It would be used only for the leaf to leaf connection. =20 > It would be retained for a convenient period of time and then destroyed. Not just leaf-to-leaf, but also leaf to any other node, even if it's not a = real leaf. This is beginning to look a lot like Kerberos, no? Yoav From mcr@sandelman.ca Mon Mar 26 01:12:22 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C32E21F842A for ; Mon, 26 Mar 2012 01:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.362 X-Spam-Level: X-Spam-Status: No, score=0.362 tagged_above=-999 required=5 tests=[AWL=2.317, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uraJz9VUIGoT for ; Mon, 26 Mar 2012 01:12:21 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCCF21F844D for ; Mon, 26 Mar 2012 01:12:19 -0700 (PDT) Received: from marajade.sandelman.ca (dhcp-10ed.meeting.ietf.org [130.129.16.237]) by relay.sandelman.ca (Postfix) with ESMTPS id 784CA34430 for ; Mon, 26 Mar 2012 04:09:36 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id AFC7098182; Mon, 26 Mar 2012 04:12:17 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id AE8A098180 for ; Mon, 26 Mar 2012 10:12:17 +0200 (CEST) From: Michael Richardson To: IPsecme WG In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 26 Mar 2012 10:12:17 +0200 Message-ID: <25363.1332749537@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] FW: [ipsecme] #211: We should talk more about why this is a hard problem. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 08:12:22 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I agree: it's not a "hard problem". It's an annoying problem, and the lack of a dynamic solution causes poor experiences for users. For a relatively static group of non-moving leaf gateways, even a very large group, a bit of scripting could generate most of the full mesh policy, and normal IKEv2 on-demand keying of links would bring up tunnels as needed. The reason to have an automatic system is because: 1) we have mobile nodes that we want to include (roadwarriors) 2) we have gateways behind NAT that can be hard to find. 3) we have machines/gateways that have non-transtive authentication mechanisms, and it would be very annoying to setup each leaf system with a trusted connection to the AAA system for authentication. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT3Ak4YqHRg3pndX9AQLSSwP/UfKCDYf7l/pNQwix1ywP1JHVRnLIhRYR 1USdZ53YFMbPUImuyQCfJID0p0JO9Q2p0f39Zh9h5Vu/JFa1kVZIdZbETBewqkZ/ 3HjM0pBZYZDmD6/kbmildjB53CgZZJ22kst59lN+MZiXWhQgy/PvevToH9meJ0FN vhaCiJCKOKs= =1rOG -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Mon Mar 26 01:22:16 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FF821F84F0 for ; Mon, 26 Mar 2012 01:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.796 X-Spam-Level: X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[AWL=1.158, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3MBRhE5Az86 for ; Mon, 26 Mar 2012 01:22:13 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id EF95321F84E2 for ; Mon, 26 Mar 2012 01:22:12 -0700 (PDT) Received: from marajade.sandelman.ca (dhcp-10ed.meeting.ietf.org [130.129.16.237]) by relay.sandelman.ca (Postfix) with ESMTPS id 4CEE2344E1; Mon, 26 Mar 2012 04:19:30 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 6BD1598182; Mon, 26 Mar 2012 04:22:11 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 676A798180; Mon, 26 Mar 2012 10:22:11 +0200 (CEST) From: Michael Richardson To: Yoav Nir In-Reply-To: <21AAB4E5-7E09-4897-BA67-469C60B7CAA0@checkpoint.com> References: <21AAB4E5-7E09-4897-BA67-469C60B7CAA0@checkpoint.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 26 Mar 2012 10:22:11 +0200 Message-ID: <27015.1332750131@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: IPsecme WG , Stephen Hanna Subject: Re: [IPsec] [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 08:22:16 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Yoav" =3D=3D Yoav Nir writes: Yoav> "direct endpoint-to-endpoint connectivity may not be possible Yoav> if both endpoints are NATed"=20 Yoav> Why? There are several protocols (SIP/RTP come to mind) that Yoav> manage endpoint-to-endpoint connectivity even when both are Yoav> behind NAT. Why shouldn't IPsec endpoints do this?=20 yes, sorta. 1) lots of SIP things actually fail through NATs, even when the entire path is under VoIP/IP provider's control. (For instance Busy-Light Indicators are sent async).=20=20 2) SIP with STUN fails to using the STUN (or TURN) gateway to relay all tra= ffic when it discovers a restricted-cone NAT. That means that SIP "works" by sending all traffic to a "data centre" (DC to use the terms in this ticket) I think that this issue needs enumerate the kinds of reasons why an endpoint may be unable to receive connections. In particular, we may in fact have to detect the various situations and automatically work around them. (One work around is sometimes to have the captive node initiate the connection, something that we have the control mechanisms to do) --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT3AnM4qHRg3pndX9AQK6UQQAhZxdfZ171QJCJfJroo7L0SayQDazv916 hNRWqy/vLHecxSchMWJnDrKC+Vtl54zzD9fgv/el1tegaqQNseWmmiUuIZeR6LCE RNV3bK6mcRx4kovmMhHRxQUP2KmwqXPJDA9aPeAAI593256j40B6VhAEC4tSaWvM euMp+CVTNaE= =WbhG -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Mon Mar 26 01:37:35 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B5021F84D2 for ; Mon, 26 Mar 2012 01:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.882 X-Spam-Level: X-Spam-Status: No, score=-0.882 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1L45LjBvJ8A for ; Mon, 26 Mar 2012 01:37:34 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEA721F84D8 for ; Mon, 26 Mar 2012 01:37:34 -0700 (PDT) Received: from marajade.sandelman.ca (dhcp-10ed.meeting.ietf.org [130.129.16.237]) by relay.sandelman.ca (Postfix) with ESMTPS id D9A7A344FD for ; Mon, 26 Mar 2012 04:34:50 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id EECAE98182; Mon, 26 Mar 2012 04:37:31 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id EAD8498180 for ; Mon, 26 Mar 2012 10:37:31 +0200 (CEST) From: Michael Richardson To: oIPsecme WG In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Content-type: text/plain; format=fixed Date: Mon, 26 Mar 2012 10:37:31 +0200 Message-ID: <29671.1332751051@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 08:37:35 -0000 >>>>> "Stephen" == Stephen Hanna writes: Stephen> I think that Michael is asking an important question. There Stephen> are many ways to solve the P2P VPN problem. One way is to Stephen> have satellites with little configuration that connect to Stephen> core gateways with lots of dynamic information. A core Stephen> gateway (a "hub" in Michael's parlance) can download things Stephen> to a satellite (maybe a new SPD and PAD, credentials, Stephen> etc.), thus causing some traffic from the satellite to be Stephen> sent to a different core gateway or satellite. In that Stephen> circumstance, I think Michael's question is about whether Stephen> the core gateway that a satellite initially connects (which Stephen> I'll call the "initial core gateway") to should be expected Stephen> to have or obtain all the information needed to configure Stephen> the satellite or whether the initial core gateway can send Stephen> the satellite to another core gateway where it can get more Stephen> information. At least, that's how I understand Michael's Stephen> question. Perhaps he can affirm or deny this Stephen> interpretation. You got my question correctly. I'm gonna add a diagram so that everyone can agree. (Those of you with mailers that ignore text/plain; format=fixed, you need to copy this email to Wordpad/vi, or it will be munged by your RFC-ignorant vendor) In the requirements document, I think that we need establish some nomenclature, such as "hub". and "initial hub", or "core", as you wish. Given that goal of this is to go from hub+spoke (generalized to trunk+feeder.. In my spare time I'm actually a transit expert. True story) A B \ / \ / \ / +----+ trunk1 +------+ trunk2 +-----+ | H1 |==============| H2 |===============| H3 | +----+ +------+ +-----+ / \ / \ C D Leaf A has traffic of leaf B. It would otherwise go via Hub1(H1), Hub2, and Hub3. Thanks to our new Private Elastic Cloud On-Demand (PECOD) protocol, magic will happen. The question, *AT THE REQUIREMENTS* phase, is whether a solution such as: step1, H1 tells A that H2 is closer: A B \..................... / \ \ / \ \ / +----+ trunk1 +------+ trunk2 +-----+ | H1 |==============| H2 |===============| H3 | +----+ +------+ +-----+ / \ / \ C D step2, H2 tells A where B is: A........................................................B \..................... / \ \ / \ \ / +----+ trunk1 +------+ trunk2 +-----+ | H1 |==============| H2 |===============| H3 | +----+ +------+ +-----+ / \ / \ C D pti Stephen> Personally, I think that this question is premature. It Stephen> presupposes too much about the eventual solution. That's Stephen> why I think it should be answered in the solution not Stephen> included in the problem statement. Apparently, Yaron Stephen> doesn't agree with me. I'd like to hear more from him on Stephen> this matter. Does he believe that all solutions to this Stephen> problem (or at least all the good ones) must necessarily Stephen> employ the model that I described above? What about a Stephen> solution that doesn't rely on core gateways to refer Stephen> satellites but instead has satellites querying for the Stephen> information that they need? Or one that has some external Stephen> entity (not the core gateway) configuring the satellites? Stephen> In my view, there may be many possible P2P VPN Stephen> solutions. However, I'm not an IPsec expert. Maybe this is Stephen> the only practical approach. I'd like to hear views from Stephen> Yaron and from others on this topic. From mcr@sandelman.ca Mon Mar 26 01:42:57 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9366021F85A4 for ; Mon, 26 Mar 2012 01:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsAKm6iSpKoR for ; Mon, 26 Mar 2012 01:42:56 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAF621F84F7 for ; Mon, 26 Mar 2012 01:42:56 -0700 (PDT) Received: from marajade.sandelman.ca (dhcp-10ed.meeting.ietf.org [130.129.16.237]) by relay.sandelman.ca (Postfix) with ESMTPS id 6F88C34430 for ; Mon, 26 Mar 2012 04:40:13 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 2F25D98182; Mon, 26 Mar 2012 04:42:54 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 28DB398180 for ; Mon, 26 Mar 2012 10:42:54 +0200 (CEST) From: Michael Richardson To: IPsecme WG In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 26 Mar 2012 10:42:54 +0200 Message-ID: <30595.1332751374@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 08:42:58 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable {fat fingers let previous email got away too soon, ignore} >>>>> "Stephen" =3D=3D Stephen Hanna writes: Stephen> I think that Michael is asking an important question. There Stephen> are many ways to solve the P2P VPN problem. One way is to Stephen> have satellites with little configuration that connect to Stephen> core gateways with lots of dynamic information. A core Stephen> gateway (a "hub" in Michael's parlance) can download things Stephen> to a satellite (maybe a new SPD and PAD, credentials, Stephen> etc.), thus causing some traffic from the satellite to be Stephen> sent to a different core gateway or satellite. In that Stephen> circumstance, I think Michael's question is about whether Stephen> the core gateway that a satellite initially connects (which Stephen> I'll call the "initial core gateway") to should be expected Stephen> to have or obtain all the information needed to configure Stephen> the satellite or whether the initial core gateway can send Stephen> the satellite to another core gateway where it can get more Stephen> information. At least, that's how I understand Michael's Stephen> question. Perhaps he can affirm or deny this Stephen> interpretation. You got my question correctly. I'm gonna add a diagram so that everyone can agree. (Those of you with mailers that ignore text/plain; format=3Dfixed, you need to copy this email to Wordpad/vi, or it will be munged by your RFC-ignorant vendor. Oh, I'll paste it into the ticket too) In the requirements document, I think that we need establish some nomenclature, such as "hub". and "initial hub", or "core", as you wish. Given that goal of this is to go from hub+spoke (generalized to trunk+feeder.. In my spare time I'm actually a transit expert. True story) A B \ / \ / \ / +----+ trunk1 +------+ trunk2 +-----+ | H1 |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| H2 |=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| H3 | +----+ +------+ +-----+ / \ / \ C D Leaf A has traffic of leaf B. It would otherwise go via Hub1(H1), Hub2, and Hub3. Thanks to our new Private Elastic Cloud On-Demand (PECOD) protocol, magic will happen. The question, *AT THE REQUIREMENTS* phase, is whether a solution such as: step1, H1 tells A that H2 is closer: A B \..................... / \ \ / \ \ / +----+ trunk1 +------+ trunk2 +-----+ | H1 |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| H2 |=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| H3 | +----+ +------+ +-----+ / \ / \ C D step2, H2 tells A where B is: A........................................................B \..................... / \ \ / \ \ / +----+ trunk1 +------+ trunk2 +-----+ | H1 |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| H2 |=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| H3 | +----+ +------+ +-----+ / \ / \ C D open question whether when H1 told A about H2, whether it in fact told=20 A about *all* of the topology that H1 knew about H2, or just about A. Would traffic from A to D go via H2 after step1, or would traffic to D continue to go via H1/H2? This speaks to requirements, because if H1 needs to know where B is, then we need to have a protocol along trunk1 and trunk2 that permits the information about where B is to be communicated.=20=20 =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT3AsDYqHRg3pndX9AQIsZwP9EHsoAuZOklCYsIAJuRVnmcTTcPP821/h 9vN8522Wk0IuBQ2FJz2NRaMSUGM+TjWwRqb5yWUnOHw7UWSJKeNrnjYYRkR+lGQy ktXnlJXfW7aPwVi6Ugg27Y9aPWEMryd5jiksg1eIBqAeWxA+uJxUuiQkJpBqnBUy iwnl8D4WCu0= =tn4x -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Mon Mar 26 01:47:15 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02FA21F84A5 for ; Mon, 26 Mar 2012 01:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.371 X-Spam-Level: X-Spam-Status: No, score=-1.371 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0P57BNXQPSK for ; Mon, 26 Mar 2012 01:47:15 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3436F21F849B for ; Mon, 26 Mar 2012 01:47:15 -0700 (PDT) Received: from marajade.sandelman.ca (dhcp-10ed.meeting.ietf.org [130.129.16.237]) by relay.sandelman.ca (Postfix) with ESMTPS id 72BA6344E3 for ; Mon, 26 Mar 2012 04:44:32 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 715CF98182; Mon, 26 Mar 2012 04:47:13 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 6848698180 for ; Mon, 26 Mar 2012 10:47:13 +0200 (CEST) From: Michael Richardson To: IPsecme WG In-Reply-To: <4F6A5E76.7040605@gmail.com> References: <3AD5BF8C-ABC5-40F1-8F6D-2C730C70B8E4@checkpoint.com> <4F6A5E76.7040605@gmail.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 26 Mar 2012 10:47:13 +0200 Message-ID: <31348.1332751633@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 08:47:16 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Yaron" =3D=3D Yaron Sheffer writes: Yaron> I don't want to speak for MCR, but I think you are taking his Yaron> question too far towards the implementation aspects. What I Yaron> read in the question is, do we allow for a situation where Yaron> (by policy and/or because of limitations in the solution) an Yaron> endpoint cannot connect directly to the ultimate peer, but Yaron> needs instead to go through some sort of relay. You didn't take my comments too far; I think you realized that I was in fact saying two things: 1) when traffic is redirected, MUST it be redirected directly to the real endpoint? (There might be issues of in-band double NAT that matter if the traffic doesn't get all the way there... I dunno, IPv6 RFC6145 is my answer to double NAT) 2) when traffic is redirected, MAY it be redirected more than once? =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT3AtEYqHRg3pndX9AQKzxAP8D5+iePWlKpX3Yj52ie71c8PdHEwDDSiR +Sfi9B53xsrsZrsR1IOqmywX36nszPZ4nnDEacTz8/Pc1wUFElR2je84XI+FvrJq f37gDwItKk80CoR4GXyklzXAbeHVw3k//6QqvIkYKSi+6Jt4Zw5w7OhJngBR6JW8 465yykrfa7E= =EjDb -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Mon Mar 26 01:49:08 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BB921F85C0 for ; Mon, 26 Mar 2012 01:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.468 X-Spam-Level: X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAJsblG5tNaj for ; Mon, 26 Mar 2012 01:49:07 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id AD33D21F85AA for ; Mon, 26 Mar 2012 01:49:07 -0700 (PDT) Received: from marajade.sandelman.ca (dhcp-10ed.meeting.ietf.org [130.129.16.237]) by relay.sandelman.ca (Postfix) with ESMTPS id 09010344DA for ; Mon, 26 Mar 2012 04:46:25 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 2D0C898182; Mon, 26 Mar 2012 04:49:06 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 2810398180 for ; Mon, 26 Mar 2012 10:49:06 +0200 (CEST) From: Michael Richardson To: IPsecme WG In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 26 Mar 2012 10:49:06 +0200 Message-ID: <31672.1332751746@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] [ipsecme] #215: Should traffic flow through the gateway while a shortcut is being established? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 08:49:08 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Stephen" =3D=3D Stephen Hanna writes: Stephen> #215: Should traffic flow through the gateway while a Stephen> shortcut is being=20 Stephen> established? Yes. No traffic should be delayed or dropped if it can be delivered. This entire system is an optional *optimization*!=20=20 It may be *required* in order to get a sufficiently high quality path for some services (VoIP), but, from a layer-3 point of view, it's optional. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT3AtgoqHRg3pndX9AQI/7wP/dO218JjlpU70oEvwu54qlkaIaHNzrhJb jh7xqaV8a2GwA/nw9phAHhQkWCxHGNpv6IDS3uS7kGL1QimuK87M9NugpmCxgBfa G2cm2qw/mKmAqWK7MqJtaiJ3FJgChHwNS0FADvnNNzqEMYDONDPIES8NYm0vdcCN YjZbHGhthkY= =/oMJ -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Mon Mar 26 01:58:00 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A941521F853B for ; Mon, 26 Mar 2012 01:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_BACKHAIR_12=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dtx5iKMdxdvM for ; Mon, 26 Mar 2012 01:58:00 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 15E9321F84B6 for ; Mon, 26 Mar 2012 01:58:00 -0700 (PDT) Received: from marajade.sandelman.ca (dhcp-10ed.meeting.ietf.org [130.129.16.237]) by relay.sandelman.ca (Postfix) with ESMTPS id 04AF334430 for ; Mon, 26 Mar 2012 04:55:17 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 2475798182; Mon, 26 Mar 2012 04:57:58 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 1F17198180 for ; Mon, 26 Mar 2012 10:57:58 +0200 (CEST) From: Michael Richardson To: IPsecme WG In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 26 Mar 2012 10:57:58 +0200 Message-ID: <690.1332752278@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] [ipsecme] #216: Multiple interfaces or mobile endpoint X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 08:58:00 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I think that whenever a node moves from the point of view of it's "primary" connection, that it should tear down all "auxiliary" tunnels. Due to the movement of the node, it may be impossible to communicate with the end-points of the auxiliary tunnels (due to NAT restricted-cone at one end or the other), so we will need a way to send tear down notices (and/or I've moved notices) via the "hub" systems.=20=20 There are many ways to do this (various ways inside IKEv2, via IP routing...), but it's really important that the auxiliary tunnels for "A" get destroyed on node "B" when "A" moves, reboots, updates it's NAT address, etc. This is not exclusively about MOBIKE: there are lots of other ways in which the A<-->H1 connection can change which would affect "B". =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT3AvlYqHRg3pndX9AQIwHgP+MArlFJgERIEHsdi2inzboZlnnH6nHj6O l3GRlXOsBEDG/EZIrzEiJYgfssftZsAJePt/Ro4zVo6uJJOmupQHA19yWq2irIbv m5OSC9D/kwuq3z2NZWwMwysF737VRSeNPNlwsBg0Kz8c+Ekbfgq9APfF/gDFShCU lrMAGVDjJKU= =JB0Q -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Mon Mar 26 02:04:09 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC4A21F84F3 for ; Mon, 26 Mar 2012 02:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.782 X-Spam-Level: X-Spam-Status: No, score=-0.782 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_05=-1.11, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyYxzFmu7VDK for ; Mon, 26 Mar 2012 02:04:08 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id AC2BC21F84DE for ; Mon, 26 Mar 2012 02:04:08 -0700 (PDT) Received: from marajade.sandelman.ca (dhcp-10ed.meeting.ietf.org [130.129.16.237]) by relay.sandelman.ca (Postfix) with ESMTPS id 058E5344E3 for ; Mon, 26 Mar 2012 05:01:26 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 147C198182; Mon, 26 Mar 2012 05:04:07 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 0EC7798180 for ; Mon, 26 Mar 2012 11:04:07 +0200 (CEST) From: Michael Richardson To: IPsecme WG In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 26 Mar 2012 11:04:07 +0200 Message-ID: <1789.1332752647@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] [ipsecme] #216: Multiple interfaces or mobile endpoint X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 09:04:09 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Vishwas" =3D=3D Vishwas Manral writes: Vishwas> Branch routers have 3G/ 4G interfaces as backups for the Vishwas> primary interface=20 Vishwas> and sometimes even multiple 3G/ 4G interfaces with no wired Vishwas> interface at=20 Vishwas> all to the backend. Vishwas, it's not about requirements on immobile branch offices, or *they* connect to the internet. It's about laptops/smartphones which are typically "remote" on various interfaces (including 3G and wifi going up/down regularly), and what happens when such a device is now *inside* a branch office. (A laptop with an ethernet is more likely to be 'inside' the branch office than a laptop/smartphone with wifi at the office, depending whether the WIFI is bridged to LAN, or the wifi is considered untrusted) How does this device learn that it should now rely in the branch office's MESH membership, rather than it's own MESH membership? I don't think that the title of this ticket is well chosen. I can do a diagram. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT3AxBoqHRg3pndX9AQLBTwQAwqvg6Enn+ajUFOCZwLVDDNGLojSN9AZw TT3u9V5S2Me+L31zusv5Xj5cctTcRdHjtXm/t2jwR4nxdKaKRkFq5Qd84k4s5fup b50BbPRjNT2cQxvzYP3sC65Cs2UUfZzxt3z6Y1WttaQOWdW/2BZ0yGAD7IRXM6Qh z45Qo2N4Z/o= =+Zdl -----END PGP SIGNATURE----- --=-=-=-- From ynir@checkpoint.com Mon Mar 26 02:04:34 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D1021F8516 for ; Mon, 26 Mar 2012 02:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.49 X-Spam-Level: X-Spam-Status: No, score=-10.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUyT+2FR4y60 for ; Mon, 26 Mar 2012 02:04:33 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 00E1821F84DE for ; Mon, 26 Mar 2012 02:04:32 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2Q94VU0028864; Mon, 26 Mar 2012 11:04:31 +0200 X-CheckPoint: {4F703056-0-1B221DC2-5FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 26 Mar 2012 11:04:31 +0200 From: Yoav Nir To: Michael Richardson Date: Mon, 26 Mar 2012 11:04:29 +0200 Thread-Topic: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway? Thread-Index: Ac0LL3QUy8hBNb2lRPiz9l5dfMfY0g== Message-ID: <33A8579A-8813-4D9D-A676-7FDA51823333@checkpoint.com> References: <3AD5BF8C-ABC5-40F1-8F6D-2C730C70B8E4@checkpoint.com> <4F6A5E76.7040605@gmail.com> <31348.1332751633@marajade.sandelman.ca> In-Reply-To: <31348.1332751633@marajade.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 09:04:34 -0000 On Mar 26, 2012, at 10:47 AM, Michael Richardson wrote: >=20 >>>>>> "Yaron" =3D=3D Yaron Sheffer writes: > Yaron> I don't want to speak for MCR, but I think you are taking his > Yaron> question too far towards the implementation aspects. What I > Yaron> read in the question is, do we allow for a situation where > Yaron> (by policy and/or because of limitations in the solution) an > Yaron> endpoint cannot connect directly to the ultimate peer, but > Yaron> needs instead to go through some sort of relay. >=20 > You didn't take my comments too far; I think you realized that I was in > fact saying two things: >=20 > 1) when traffic is redirected, MUST it be redirected directly to the > real endpoint? (There might be issues of in-band double NAT that > matter if the traffic doesn't get all the way there... I dunno, IPv6 > RFC6145 is my answer to double NAT) >=20 > 2) when traffic is redirected, MAY it be redirected more than once? Aren't these really the same question? =20 My answer is that it's OK for redirection to happen more than once, but it'= s better to have less redirections than more. IOW it should be a requirement that H1 (in the diagram of your previous mai= l) be able to send more information about the topology behind H2 than just = "B is behind H2", such as "D and H3 are also behind H2". But A should be re= quired to not expect it. So H1 MUST be able to tell A that B is behind H2. It MAY be able to tell A = that D is also behind H2, or that B is actually behind H3, or the actual ad= dress of B. Yoav= From mglt.ietf@gmail.com Mon Mar 26 02:14:27 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A4421F85AD for ; Mon, 26 Mar 2012 02:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zr7cssEp5pHT for ; Mon, 26 Mar 2012 02:14:26 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 68FE521F85A5 for ; Mon, 26 Mar 2012 02:14:26 -0700 (PDT) Received: by iazz13 with SMTP id z13so9414485iaz.31 for ; Mon, 26 Mar 2012 02:14:26 -0700 (PDT) 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=vWVil1LJcO9OvXYxaZ9eDwBCLeuBJN71AdouLrPzWlc=; b=ko6URzcaZsCrG6vgryM+ORE+dpPlnlRP5Blsnu8xZp7a46DCl3JLBNorBbmaESZblm pVTT1qAUXbArj3X/tpDUOOqbnsjJMHJCY0N93IyoA5zUWWw+FLBpQJ+o5wJBmhE+3bQr 4YITt/DojYHrsBYEUg42+iIF04YvDJuh7leI3q+EmHJhrqis6alrinHK/HVji1EZWQte ruavCrVjE5MvhLe6SiWPIgcaNY3eBnw7metUocxTkoUuqKoGOM67zfAGtG/ZNcxiAqJJ /yN+lVScXoBsfYelquYTrW6W7M2LRyVTXMdaRLC051f1IE5BGv0RxileU3kM9UB9bvfJ qFIw== MIME-Version: 1.0 Received: by 10.50.45.231 with SMTP id q7mr5014122igm.42.1332753266133; Mon, 26 Mar 2012 02:14:26 -0700 (PDT) Received: by 10.231.170.138 with HTTP; Mon, 26 Mar 2012 02:14:26 -0700 (PDT) In-Reply-To: References: <20308.41703.180675.466160@fireball.kivinen.iki.fi> Date: Mon, 26 Mar 2012 11:14:26 +0200 Message-ID: From: Daniel Migault To: Paul Hoffman Content-Type: multipart/alternative; boundary=14dae9340621004b7e04bc21cd52 Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-oob-pubkey-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 09:14:27 -0000 --14dae9340621004b7e04bc21cd52 Content-Type: text/plain; charset=ISO-8859-1 I also support the draft Daniel On Tue, Mar 6, 2012 at 5:37 AM, Paul Hoffman wrote: > On Mar 5, 2012, at 3:26 AM, Tero Kivinen wrote: > > > I just posted following document. I think I would like to get few > > minutes in Paris to explain this document, and see wheter there is any > > comments to it. I think it should be forwarded as individual draft to > > the RFC, but I am not sure whether it should be informational or > > standards track document, and this is something I would like to get > > feedback from the community. > > I see no reason it should not be on standards track. > > > This is very similar in ideas than to the tls version > > (draft-ietf-tls-oob-pubkey-01), i.e. it shares the same format for the > > raw key. > > And this is good. > > --Paul Hoffman > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --14dae9340621004b7e04bc21cd52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I also support the draft
Daniel

On Tue= , Mar 6, 2012 at 5:37 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
On Mar 5, 2012, at 3:26 AM, Tero Kivinen wrote:

> I just posted following document. I think I would like to get few
> minutes in Paris to explain this document, and see wheter there is any=
> comments to it. I think it should be forwarded as individual draft to<= br> > the RFC, but I am not sure whether it should be informational or
> standards track document, and this is something I would like to get > feedback from the community.

I see no reason it should not be on standards track.

> This is very similar in ideas than to the tls version
> (draft-ietf-tls-oob-pubkey-01), i.e. it shares the same format for the=
> raw key.

And this is good.

--Paul Hoffman

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



--
Daniel Miga= ult
Orange Labs -- Security
+33 6 70 72 69 58
--14dae9340621004b7e04bc21cd52-- From mcr@sandelman.ca Mon Mar 26 02:23:53 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC1621F85AE for ; Mon, 26 Mar 2012 02:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.008 X-Spam-Level: X-Spam-Status: No, score=0.008 tagged_above=-999 required=5 tests=[AWL=-1.038, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_BACKHAIR_12=1, J_BACKHAIR_21=1, J_BACKHAIR_22=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l76CK5IQA-Eh for ; Mon, 26 Mar 2012 02:23:53 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id ED2CF21F859E for ; Mon, 26 Mar 2012 02:23:52 -0700 (PDT) Received: from marajade.sandelman.ca (dhcp-10ed.meeting.ietf.org [130.129.16.237]) by relay.sandelman.ca (Postfix) with ESMTPS id BFA68344E1; Mon, 26 Mar 2012 05:21:09 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id DF05698182; Mon, 26 Mar 2012 05:23:50 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id CD10498180; Mon, 26 Mar 2012 11:23:50 +0200 (CEST) From: Michael Richardson To: Yoav Nir In-Reply-To: <33A8579A-8813-4D9D-A676-7FDA51823333@checkpoint.com> References: <3AD5BF8C-ABC5-40F1-8F6D-2C730C70B8E4@checkpoint.com> <4F6A5E76.7040605@gmail.com> <31348.1332751633@marajade.sandelman.ca> <33A8579A-8813-4D9D-A676-7FDA51823333@checkpoint.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 26 Mar 2012 11:23:50 +0200 Message-ID: <5443.1332753830@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: IPsecme WG Subject: Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 09:23:53 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Yoav" =3D=3D Yoav Nir writes: >> You didn't take my comments too far; I think you realized that I was= in >> fact saying two things: >>=20 >> 1) when traffic is redirected, MUST it be redirected directly to the >> real endpoint? (There might be issues of in-band double NAT that >> 2) when traffic is redirected, MAY it be redirected more than once? Yoav> Aren't these really the same question?=20=20 case1: Q1:yes, Q2: yes.=20=20 Must redirect to final end point, but it is okay for redirection to occur multiple times. This implies that when A is redirected to H2, that no SA is created with H2, but rather there is an immediate redirection to H3, and again to B. case2: Q1:yes, Q2: no Must redirect to final end point, but redirection not permitted. H1 must get address of B via "magic" and tell A about it. case3: Q1:no, Q2: yes. final end point not required, multiple redirection. H1 can redirect to H2. A sends traffic to H2. H2 can decide to send a new redirect to H3 based upon seeing what traffic is arriving.=20=20 (Note that B might get redirected by H2 for traffic for A to H2, and now we have A<-->H2<-->B, and now H2 actually knows about=20 both A and B, and either easily link them directly, or realize that neither are directly reachable, and since H2 has plentiful bandwidth, it doesn't care...) =20=20=20=20=20=20=20=20 case4: Q1:no, Q2: no. H1 should either redirect to B directly, or can redirect to H3, but H1 has to know whether or not B is directly reachable. At the same time, H3 might be redirecting B to H1 if A is not=20 reachable, and we might have asymmetric routing.=20=20 This might screw the SPD on A and B if your SPD is strict 4301. Yoav> IOW it should be a requirement that H1 (in the diagram of your Yoav> previous mail) be able to send more information about the Yoav> topology behind H2 than just "B is behind H2", such as "D and Yoav> H3 are also behind H2". But A should be required to not expect Yoav> it.=20 Yoav> So H1 MUST be able to tell A that B is behind H2. It MAY be Yoav> able to tell A that D is also behind H2, or that B is actually Yoav> behind H3, or the actual address of B.=20 So, you just created a requirement for H1<->H2 communication :-) --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT3A1poqHRg3pndX9AQLdcwQAhot+uEaFowTI2H986cZl8nBiK+v6wbtt B6zZBFzVLTsK91ZjpB+kRGx7ZVlFhWUuE4L23bPfYViDvSHVqoikfJtFeZIY+dS2 n1X7RgQo82qH7vFcohvZyCZ8PuXiQ34v7UuA0CjM0j+rUBqa+l5tS0OlrSuBpiSI 8F4n9O4wny8= =zfch -----END PGP SIGNATURE----- --=-=-=-- From vishwas.ietf@gmail.com Mon Mar 26 04:15:58 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E3121F85F9 for ; Mon, 26 Mar 2012 04:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.883 X-Spam-Level: X-Spam-Status: No, score=-3.883 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5wPfOO32WC3 for ; Mon, 26 Mar 2012 04:15:57 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9753A21F85E3 for ; Mon, 26 Mar 2012 04:15:57 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so6002776obb.31 for ; Mon, 26 Mar 2012 04:15:57 -0700 (PDT) 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=zctY/gscBTBwz+aqkgWEz+3TXW72dTrS9uBor7h7oxU=; b=MOARSWhJppSZDXR9Q9av1b9q0xOzuumfZL4Jsdv1ut8J0ZGduhwR+EENloIoybIlay lgjRmTftIYnZHapVGTD5o+5G6RxtE9TXgewfD2K1Mqyvp+oxYlbzzV4xCqh+rpjlYb/y vZAwpqiPyTg0soYMV3KTxSSF/Sq9lQHhHEnKw8M/11gpf6c+OR9YzQjQV8BgZIZVVqZ9 eIuTCIxlIy5GJs1VbCCGWdjveq6q8j9vaKjTLTHog+Y+PDjteMHDOu7PnZC+y1lLwsXp 0TZbzaxMO5MbFEp24h1UECZ9uXf8doBztKMJRG/NykvSZBxVXQS0UDnolbbsM0owwn5N oiYQ== MIME-Version: 1.0 Received: by 10.182.144.71 with SMTP id sk7mr19018111obb.3.1332760556973; Mon, 26 Mar 2012 04:15:56 -0700 (PDT) Received: by 10.182.134.73 with HTTP; Mon, 26 Mar 2012 04:15:56 -0700 (PDT) In-Reply-To: <25363.1332749537@marajade.sandelman.ca> References: <25363.1332749537@marajade.sandelman.ca> Date: Mon, 26 Mar 2012 04:15:56 -0700 Message-ID: From: Vishwas Manral To: Michael Richardson Content-Type: multipart/alternative; boundary=14dae9399e1591acdf04bc237f17 Cc: IPsecme WG Subject: Re: [IPsec] FW: [ipsecme] #211: We should talk more about why this is a hard problem. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 11:15:58 -0000 --14dae9399e1591acdf04bc237f17 Content-Type: text/plain; charset=ISO-8859-1 I agree. -Vishwas On Mon, Mar 26, 2012 at 1:12 AM, Michael Richardson wrote: > > I agree: it's not a "hard problem". It's an annoying problem, and the > lack of a dynamic solution causes poor experiences for users. > > For a relatively static group of non-moving leaf gateways, even a very > large group, a bit of scripting could generate most of the full mesh > policy, and normal IKEv2 on-demand keying of links would bring up > tunnels as needed. > > The reason to have an automatic system is because: > 1) we have mobile nodes that we want to include (roadwarriors) > > 2) we have gateways behind NAT that can be hard to find. > > 3) we have machines/gateways that have non-transtive authentication > mechanisms, and it would be very annoying to setup each leaf > system with a trusted connection to the AAA system for > authentication. > > -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device > driver[ > Kyoto Plus: watch the video > then sign the petition. > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --14dae9399e1591acdf04bc237f17 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree.

-Vishwas

On Mon, Mar 26, = 2012 at 1:12 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

I agree: it's not a "hard problem". It's an annoying prob= lem, and the
lack of a dynamic solution causes poor experiences for users.

For a relatively static group of non-moving leaf gateways, even a very
large group, a bit of scripting could generate most of the full mesh
policy, and normal IKEv2 on-demand keying of links would bring up
tunnels as needed.

The reason to have an automatic system is because:
=A0 =A01) we have mobile nodes that we want to include (roadwarriors)

=A0 =A02) we have gateways behind NAT that can be hard to find.

=A0 =A03) we have machines/gateways that have non-transtive authentication=
=A0 =A0 =A0 mechanisms, and it would be very annoying to setup each leaf =A0 =A0 =A0 system with a trusted connection to the AAA system for
=A0 =A0 =A0 authentication.

--
] =A0 =A0 =A0 He who is tired of Weird Al is tired of life! =A0 =A0 =A0 =A0= =A0 | =A0firewalls =A0[
] =A0 Michael Richardson, Sandelman Software Works, Ottawa, ON =A0 =A0|net = architect[
] mcr@sandelman.ottawa.on.ca<= /a> http:/= /www.sandelman.ottawa.on.ca/ |device driver[
=A0 Kyoto Plus: watch the video <http://www.youtube.com/watch?v=3Dkzx1y= cLXQSE>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 then sign the petition.


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


--14dae9399e1591acdf04bc237f17-- From mglt.ietf@gmail.com Mon Mar 26 04:19:57 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE4821F8631 for ; Mon, 26 Mar 2012 04:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLq5slDSeLjm for ; Mon, 26 Mar 2012 04:19:57 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0134021F8628 for ; Mon, 26 Mar 2012 04:19:56 -0700 (PDT) Received: by iazz13 with SMTP id z13so9597035iaz.31 for ; Mon, 26 Mar 2012 04:19:56 -0700 (PDT) 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=BZ5BMfslPk9vhVrcNHqi//RF5jAK2/7RHnpjxf9HkD8=; b=ZB0d/V/2Hh4Iyb3e5MCXan8Ib9NUI4dcD/7381ZFyY1MRQl4ZWhKxV96Mtsly9cjAd w5qsx8uS49AqyggWhkouPb9CnvKtftoz9zl+0T6NxJFV6B59eMDju89XakYTJ4fB+zQC tQj3y48K3VFWQPcOqo4D+4Nq110n/1B8j6Vp3H4d33++zDd3HRQjeK+YH4s5PqjZN1DH vGjU3NqAc2trg70oqsz4fQ+Fygfz7kgYy5TRgDSK8RYEpuaIzNPi45YDEHWecDDTb2zw kwN/Z1sp+SHevKrvORmGh3S8vqirWlv5ZrSLx9XrNwlin8JAo++kLQsY2X+e/DPaIAv0 4IeQ== MIME-Version: 1.0 Received: by 10.50.195.131 with SMTP id ie3mr5181370igc.52.1332760796682; Mon, 26 Mar 2012 04:19:56 -0700 (PDT) Received: by 10.231.170.138 with HTTP; Mon, 26 Mar 2012 04:19:56 -0700 (PDT) In-Reply-To: <1789.1332752647@marajade.sandelman.ca> References: <1789.1332752647@marajade.sandelman.ca> Date: Mon, 26 Mar 2012 13:19:56 +0200 Message-ID: From: Daniel Migault To: Michael Richardson Content-Type: multipart/alternative; boundary=14dae9340fc9db59a404bc238d8c Cc: IPsecme WG Subject: Re: [IPsec] [ipsecme] #216: Multiple interfaces or mobile endpoint X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 11:19:58 -0000 --14dae9340fc9db59a404bc238d8c Content-Type: text/plain; charset=ISO-8859-1 My understanding is that there are two things, that may be considered independently: - configuring IPsec layer - defining which route the communication should take I don't understand why only one tunnel should be used. A mobile node, when it detects a new interface, should be able to "add" this Interface on the already existing tunnel. It looks to me as a limitation of MOBIKE. * This would would allow the mobile node to use multiple tunnels. Which tunnel to choose depends on other inputs. The important thing is that the mobile can can use multiple tunnels. ** * "adding" could mean deriving a new SA from the old tunnel. This important thing here seems to avoid re-doing an IKE exchange. ** this would require that SPD-O is derived per interface. Since a single SPD is ordered and will always provide the same first match. I am not sure how that can be implemented and would appreciate feed backs on that point. Regards, Daniel On Mon, Mar 26, 2012 at 11:04 AM, Michael Richardson wrote: > > >>>>> "Vishwas" == Vishwas Manral writes: > Vishwas> Branch routers have 3G/ 4G interfaces as backups for the > Vishwas> primary interface > Vishwas> and sometimes even multiple 3G/ 4G interfaces with no wired > Vishwas> interface at > Vishwas> all to the backend. > > Vishwas, it's not about requirements on immobile branch offices, or > *they* connect to the internet. > > It's about laptops/smartphones which are typically "remote" on various > interfaces (including 3G and wifi going up/down regularly), and what > happens when such a device is now *inside* a branch office. > > (A laptop with an ethernet is more likely to be 'inside' the branch > office than a laptop/smartphone with wifi at the office, depending > whether the WIFI is bridged to LAN, or the wifi is considered untrusted) > > How does this device learn that it should now rely in the branch > office's MESH membership, rather than it's own MESH membership? > > I don't think that the title of this ticket is well chosen. > I can do a diagram. > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --14dae9340fc9db59a404bc238d8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My understanding is that there are two things, that may be considered indep= endently:
=A0=A0=A0 - configuring IPsec layer
=A0=A0=A0 - defining which route the communication should take

I don't understand why only one tunnel should be used. A mobile node,= =20 when it detects a new interface, should be able to "add" this Int= erface=20 on the already existing tunnel. It looks to me as a limitation of=20 MOBIKE. * This would would allow the mobile node to use multiple=20 tunnels. Which tunnel to choose depends on other inputs. The important=20 thing is that the mobile can can use multiple tunnels. **


* "adding" could mean deriving a new SA from the old tunnel. = This=20 important thing here seems to avoid re-doing an IKE exchange. =A0

** this would require that SPD-O is derived per interface. Since a=20 single SPD is ordered and will always provide the same first match. I am no= t sure how that can be implemented and would appreciate feed backs on that = point.

Regards,

Daniel


On Mon, Mar 26, 2012 at 11:04 AM, Michae= l Richardson <mcr+ietf@sandelman.ca> wrote:

>>>>> "Vishwas" =3D=3D Vishwas Manral <vishwas.ietf@gmail.com> writes: =A0 =A0Vishwas> Branch routers have 3G/ 4G interfaces as backups for th= e
=A0 =A0Vishwas> primary interface
=A0 =A0Vishwas> and sometimes even multiple 3G/ 4G interfaces with no w= ired
=A0 =A0Vishwas> interface at
=A0 =A0Vishwas> all to the backend.

Vishwas, it's not about requirements on immobile branch offices, or
*they* connect to the internet.

It's about laptops/smartphones which are typically "remote" o= n various
interfaces (including 3G and wifi going up/down regularly), and what
happens when such a device is now *inside* a branch office.

(A laptop with an ethernet is more likely to be 'inside' the branch=
office than a laptop/smartphone with wifi at the office, depending
whether the WIFI is bridged to LAN, or the wifi is considered untrusted)
How does this device learn that it should now rely in the branch
office's MESH membership, rather than it's own MESH membership?

I don't think that the title of this ticket is well chosen.
I can do a diagram.




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




--
Daniel Migault
O= range Labs -- Security
+33 6 70 72 69 58
--14dae9340fc9db59a404bc238d8c-- From mcr@sandelman.ca Mon Mar 26 04:27:48 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552CD21F85EF for ; Mon, 26 Mar 2012 04:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6w5-EmoNTRDU for ; Mon, 26 Mar 2012 04:27:47 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id B667721F8496 for ; Mon, 26 Mar 2012 04:27:47 -0700 (PDT) Received: from marajade.sandelman.ca (dhcp-10ed.meeting.ietf.org [130.129.16.237]) by relay.sandelman.ca (Postfix) with ESMTPS id 9545734430 for ; Mon, 26 Mar 2012 07:25:03 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 9CC2698182; Mon, 26 Mar 2012 07:27:43 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 5DF979800D for ; Mon, 26 Mar 2012 13:27:43 +0200 (CEST) From: Michael Richardson To: IPsecme WG In-Reply-To: <30595.1332751374@marajade.sandelman.ca> References: <30595.1332751374@marajade.sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Mon, 26 Mar 2012 13:27:43 +0200 Message-ID: <13052.1332761263@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 11:27:48 -0000 <#part sign=pgpmime> Actually, in my haste, I skipped a possible step: step1, H1 tells A that H2 is closer: A B \ / \..................... / \ \ / +----+ trunk1 +------+ trunk2 +-----+ | H1 |==============| H2 |===============| H3 | +----+ +------+ +-----+ / \ / \ C D step2, H2 tells A where H3 is: A B \............................................ / \..................... \ / \ \ \ / +----+ trunk1 +------+ trunk2 +-----+ | H1 |==============| H2 |===============| H3 | +----+ +------+ +-----+ / \ / \ C D step3, H3 tells A where B is: A........................................................B \............................................ / \..................... \ / \ \ \ / +----+ trunk1 +------+ trunk2 +-----+ | H1 |==============| H2 |===============| H3 | +----+ +------+ +-----+ / \ / \ C D -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From kivinen@iki.fi Mon Mar 26 05:16:23 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103A821F8637 for ; Mon, 26 Mar 2012 05:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2HG-GEeARX9 for ; Mon, 26 Mar 2012 05:16:22 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F7F21F8624 for ; Mon, 26 Mar 2012 05:16:21 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q2QCGFSJ029192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Mar 2012 15:16:15 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q2QCGF9O009846; Mon, 26 Mar 2012 15:16:15 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20336.24079.363476.505515@fireball.kivinen.iki.fi> Date: Mon, 26 Mar 2012 15:16:15 +0300 From: Tero Kivinen To: Daniel Migault In-Reply-To: References: <1789.1332752647@marajade.sandelman.ca> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 4 min Cc: IPsecme WG , Michael Richardson Subject: Re: [IPsec] [ipsecme] #216: Multiple interfaces or mobile endpoint X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 12:16:23 -0000 Daniel Migault writes: > My understanding is that there are two things, that may be considered > independently: > - configuring IPsec layer > - defining which route the communication should take > > I don't understand why only one tunnel should be used. A mobile node, when > it detects a new interface, should be able to "add" this Interface on the > already existing tunnel. It looks to me as a limitation of MOBIKE. * This > would would allow the mobile node to use multiple tunnels. Which tunnel to > choose depends on other inputs. The important thing is that the mobile can > can use multiple tunnels. ** > > > * "adding" could mean deriving a new SA from the old tunnel. This important > thing here seems to avoid re-doing an IKE exchange. MOBIKE already does that. I.e. when it detects another interface (IP-address) it will send ADDITIINAL_IP{4,6}_ADDRESS notifications and then new IP-addess is also one of the address which can be used. With MOBIKE we still only use one address, but we can change which address we use easily. On the other hand I do not think MOBIKE is really applicable in this case, as I think in most of the cases the tunnel end points are NOT going to be same. I.e. we do not try to create multiple tunnels between same endpoints, but create multiple tunnels between different endpoints, and in that case MOBIKE cannot be used. -- kivinen@iki.fi From ynir@checkpoint.com Mon Mar 26 09:09:03 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E957B21E8097 for ; Mon, 26 Mar 2012 09:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.494 X-Spam-Level: X-Spam-Status: No, score=-10.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haZ10bWbdIw0 for ; Mon, 26 Mar 2012 09:09:02 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9696C21E809A for ; Mon, 26 Mar 2012 09:09:01 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2QG90F4013556 for ; Mon, 26 Mar 2012 18:09:00 +0200 X-CheckPoint: {4F7093CE-2-1B221DC2-5FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 26 Mar 2012 18:08:59 +0200 From: Yoav Nir To: IPsecme WG Date: Mon, 26 Mar 2012 18:08:58 +0200 Thread-Topic: draft-nir-ipsecme-erx Thread-Index: Ac0LasCXOPXncyxeS+GPsbE67aG5DA== Message-ID: <378BA5F2-C1F3-4752-93AA-48AC3EF3AA12@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] draft-nir-ipsecme-erx X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 16:09:03 -0000 Hi This is about my presentation from the IPsecME meeting today (which for som= e reason is not on the website) Anyways, RFC 5266 mentions that "RFC 4306 must be updated to carry ERP mess= ages". This caused some controversy a year ago, but regardless, I did think= of a use case, so I partnered with Qin Wu and wrote the draft. The use case is being able to seamlessly move between two networks were net= work access is granted or denied based on EAP. Examples are 802.1x and IKEv= 2. IEEE has already revised 802.1x so that moving between two 802.1x access= points can use ERP to be seamless, but IKEv2 has not. a mobile device coul= d use 802.1x within the corporate network and move to IPsec as soon as it l= eaves the building. MCR has called this the "Elvis" use case, but it actual= ly should work seamlessly in the other direction, when the mobile node ente= rs the building, detects the 802.1x network, establishes an association, an= d deletes the no-longer-needed IKE and child SAs. My first priority is for this to become a WG item. It probably needs some w= ork, and there is an open question about whether there is any use case for = multiple AAA domains. If not, I'm also fine with taking this directly to Sean. Yoav= From kivinen@iki.fi Mon Mar 26 09:44:17 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5798A21E80CF for ; Mon, 26 Mar 2012 09:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDxDsKeiZFAz for ; Mon, 26 Mar 2012 09:44:16 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id E134921E80D1 for ; Mon, 26 Mar 2012 09:44:13 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q2QGhx4h029405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Mar 2012 19:43:59 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q2QGhxTH026657; Mon, 26 Mar 2012 19:43:59 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20336.40143.209820.16068@fireball.kivinen.iki.fi> Date: Mon, 26 Mar 2012 19:43:59 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <378BA5F2-C1F3-4752-93AA-48AC3EF3AA12@checkpoint.com> References: <378BA5F2-C1F3-4752-93AA-48AC3EF3AA12@checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 8 min Cc: IPsecme WG Subject: [IPsec] draft-nir-ipsecme-erx X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 16:44:17 -0000 Yoav Nir writes: > This is about my presentation from the IPsecME meeting today (which > for some reason is not on the website) > > Anyways, RFC 5266 mentions that "RFC 4306 must be updated to carry > ERP messages". This caused some controversy a year ago, but > regardless, I did think of a use case, so I partnered with Qin Wu > and wrote the draft. RFC5996 says: While this document references [EAP] with the intent that new methods can be added in the future without updating this specification, some simpler variations are documented here. [EAP] defines an authentication protocol requiring a variable number of messages. and A short summary of the EAP format is included here for clarity. So my take there is that the EAP description in the RFC5996 is just for clarity, and is not meant to be exhaustive, meaning it does not limit codes we can use in the EAP messages. On the other hand RFC5996 also says that: Following such an extended exchange, the EAP AUTH payloads MUST be included in the two messages following the one containing the EAP Success message. which means that as ERX uses different message to finish the authentication, update to the RFC5996 is needed (i.e. not to allow codes 5 and 6, but to say we can have EAP payloads in exchanges where they normally do not be and tell that EAP exchange can finish with these other codes too). > My first priority is for this to become a WG item. It probably needs > some work, and there is an open question about whether there is any > use case for multiple AAA domains. I agree it could be WG item. On the other hand I also think it might be quite fast document, so getting it out as individual rfc might be faster. -- kivinen@iki.fi From kivinen@iki.fi Mon Mar 26 09:49:44 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A9C21E80FF for ; Mon, 26 Mar 2012 09:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrS4N0hIuNSk for ; Mon, 26 Mar 2012 09:49:44 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B2F21E80FB for ; Mon, 26 Mar 2012 09:49:43 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q2QGngmE001098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Mar 2012 19:49:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q2QGnggj018412; Mon, 26 Mar 2012 19:49:42 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20336.40486.516402.44061@fireball.kivinen.iki.fi> Date: Mon, 26 Mar 2012 19:49:42 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 4 min Subject: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 16:49:44 -0000 As described in the IPsecME WG meeting I propose that we change the registration policy for the IPSEC Authentication Methods (Value 3) of ipsec-registry from the "Standard-Track RFC" to "IETF Review" (From RFC5226): ---------------------------------------------------------------------- IETF Review - (Formerly called "IETF Consensus" in [IANA-CONSIDERATIONS]) New values are assigned only through RFCs that have been shepherded through the IESG as AD- Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The intention is that the document and proposed assignment will be reviewed by the IESG and appropriate IETF WGs (or experts, if suitable working groups no longer exist) to ensure that the proposed assignment will not negatively impact interoperability or otherwise extend IETF protocols in an inappropriate or damaging manner. To ensure adequate community review, such documents are shepherded through the IESG as AD-sponsored (or WG) documents with an IETF Last Call. Examples: IPSECKEY Algorithm Types [RFC4025], Accounting-Auth-Method AVP values in DIAMETER [RFC4005], TLS Handshake Hello Extensions [RFC4366]. ---------------------------------------------------------------------- I will ask IANA to make the change at the 2012-04-15, unless I get some objections here in the list. -- kivinen@iki.fi From ynir@checkpoint.com Mon Mar 26 10:12:01 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCCA21E811E for ; Mon, 26 Mar 2012 10:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.495 X-Spam-Level: X-Spam-Status: No, score=-10.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECTKiRJTd1E7 for ; Mon, 26 Mar 2012 10:12:01 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id AA8BC21E8107 for ; Mon, 26 Mar 2012 10:12:00 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2QHBxoL027966; Mon, 26 Mar 2012 19:11:59 +0200 X-CheckPoint: {4F70A290-3-1B221DC2-5FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 26 Mar 2012 19:11:58 +0200 From: Yoav Nir To: Tero Kivinen Date: Mon, 26 Mar 2012 19:11:57 +0200 Thread-Topic: [IPsec] draft-nir-ipsecme-erx Thread-Index: Ac0Lc40UODXNiU1rQLq/chCgdq4lRw== Message-ID: <235A8104-43DC-427D-9B10-02F6198F0A4B@checkpoint.com> References: <378BA5F2-C1F3-4752-93AA-48AC3EF3AA12@checkpoint.com> <20336.40143.209820.16068@fireball.kivinen.iki.fi> In-Reply-To: <20336.40143.209820.16068@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] draft-nir-ipsecme-erx X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 17:12:01 -0000 On Mar 26, 2012, at 6:43 PM, Tero Kivinen wrote: > Yoav Nir writes: >> This is about my presentation from the IPsecME meeting today (which >> for some reason is not on the website)=20 >>=20 >> Anyways, RFC 5266 mentions that "RFC 4306 must be updated to carry >> ERP messages". This caused some controversy a year ago, but >> regardless, I did think of a use case, so I partnered with Qin Wu >> and wrote the draft.=20 >=20 > RFC5996 says: >=20 > While this document references [EAP] with the intent that new methods > can be added in the future without updating this specification, some > simpler variations are documented here. [EAP] defines an > authentication protocol requiring a variable number of messages. >=20 > and >=20 > A short summary of the EAP format is included here > for clarity. >=20 > So my take there is that the EAP description in the RFC5996 is just > for clarity, and is not meant to be exhaustive, meaning it does not > limit codes we can use in the EAP messages.=20 Agree. That's why my draft calls it "clarification" >=20 > On the other hand RFC5996 also says that: >=20 > Following such an extended exchange, the EAP AUTH payloads MUST be > included in the two messages following the one containing the EAP > Success message. >=20 > which means that as ERX uses different message to finish the > authentication, update to the RFC5996 is needed (i.e. not to allow > codes 5 and 6, but to say we can have EAP payloads in exchanges where > they normally do not be and tell that EAP exchange can finish with > these other codes too). >=20 >> My first priority is for this to become a WG item. It probably needs >> some work, and there is an open question about whether there is any >> use case for multiple AAA domains.=20 >=20 > I agree it could be WG item. On the other hand I also think it might > be quite fast document, so getting it out as individual rfc might be > faster. They're not necessarily faster. What the draft needs is review, especially = regarding the assumption that multiple AAA domains are not needed. I think = WG documents get better review, but even that is not really clear. Yoav From ghuang@juniper.net Mon Mar 26 11:22:01 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED2F21E80EE for ; Mon, 26 Mar 2012 11:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOetB0IntdKa for ; Mon, 26 Mar 2012 11:22:00 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id ACD1321E80E5 for ; Mon, 26 Mar 2012 11:22:00 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKT3CzvwC4CGPnkwPdIIlz/AYTaKmrcEqQ@postini.com; Mon, 26 Mar 2012 11:22:00 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 26 Mar 2012 11:21:24 -0700 From: Geoffrey Huang To: Yoav Nir , "mcr@sandelman.ca" Date: Mon, 26 Mar 2012 11:21:21 -0700 Thread-Topic: [IPsec] [ipsecme] #217: Temporary credentials Thread-Index: Ac0LfUAHhP9jqtgRSWWQLSlFBeJBjw== Message-ID: In-Reply-To: <7A541B0C-EB5A-45A3-B5AF-4C5C7802F98B@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 18:22:01 -0000 It's starting to sound like existing methods, to be sure. I'm skeptical of introducing yet another form of authentication. This would add to the complexity of the overall system. To frame it in terms of a requirement, I propose that any leaf-to-leaf communication has to be done with existing (already defined) authentication methods: for instance, either certificates or pre shared key. -geoff On 3/26/12 1:07 AM, "Yoav Nir" wrote: > >On Mar 26, 2012, at 9:52 AM, Michael Richardson wrote: > >>=20 >>>>>>> "Geoffrey" =3D=3D Geoffrey Huang writes: >> Geoffrey> My initial inclination is to say that won't fly: that many >> Geoffrey> deployments still require preshared key authentication. >> Geoffrey> Rather, they would object to certificates because of >> Geoffrey> perceived complexity. That said, I could see arguments >> Geoffrey> that what we're discussing are already fairly >> Geoffrey> sophisticated topologies, so perhaps the certificate >> Geoffrey> allergy doesn't hold? >>=20 >> Tero isn't proposing using certificates. >>=20 >> Tero is proposing that the gateway/hub provides each leaf node with a >> gateway mediated, ASN.1 encoded, scalable, asymmetric, transitive proofs >> of identity. It would be used only for the leaf to leaf connection. >> It would be retained for a convenient period of time and then destroyed. > >Not just leaf-to-leaf, but also leaf to any other node, even if it's not >a real leaf. > >This is beginning to look a lot like Kerberos, no? > >Yoav > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Mon Mar 26 13:24:55 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3275521E8011 for ; Mon, 26 Mar 2012 13:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXdg5LxVMycp for ; Mon, 26 Mar 2012 13:24:54 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D7021E800E for ; Mon, 26 Mar 2012 13:24:53 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q2QKOdbn024098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Mar 2012 23:24:40 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q2QKObYo021674; Mon, 26 Mar 2012 23:24:37 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20336.53381.855594.485351@fireball.kivinen.iki.fi> Date: Mon, 26 Mar 2012 23:24:37 +0300 From: Tero Kivinen To: Geoffrey Huang In-Reply-To: References: <7A541B0C-EB5A-45A3-B5AF-4C5C7802F98B@checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 34 min Cc: "ipsec@ietf.org" , Yoav Nir , "mcr@sandelman.ca" Subject: Re: [IPsec] [ipsecme] #217: Temporary credentials X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 20:24:55 -0000 Geoffrey Huang writes: > It's starting to sound like existing methods, to be sure. I'm skeptical > of introducing yet another form of authentication. This would add to the > complexity of the overall system. To frame it in terms of a requirement, > I propose that any leaf-to-leaf communication has to be done with existing > (already defined) authentication methods: for instance, either > certificates or pre shared key. Yes, we do want to use existing authentication methods. The question is can we use existing credentials. We cannot securely reuse existing pre-shared keys, as that would require sharing keys between peers who normally do not share keys. We cannot easily reuse EAP crendentials, as most of the leafs (especially the road warrior cases) do not have trust relationship with the EAP server, so they cannot verify other ends EAP credentials. We can reuse existing certificates and public/private key pairs, but if any other authentication methods are needed, we need to provide solution how peers can get some kind of temporary credentials they can use with the existing authentication methods to authenticate them to another peer. For that the private/public key pair (with or without certificates) is the most convinient one. -- kivinen@iki.fi From dharkins@lounge.org Tue Mar 27 02:05:25 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC2F21E80CA for ; Tue, 27 Mar 2012 02:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOYyRF5S5RTU for ; Tue, 27 Mar 2012 02:05:25 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6BA21E8094 for ; Tue, 27 Mar 2012 02:05:25 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 1F9F3A88810E; Tue, 27 Mar 2012 02:05:24 -0700 (PDT) Received: from 130.129.82.190 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 27 Mar 2012 02:05:24 -0700 (PDT) Message-ID: In-Reply-To: <20336.40486.516402.44061@fireball.kivinen.iki.fi> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> Date: Tue, 27 Mar 2012 02:05:24 -0700 (PDT) From: "Dan Harkins" To: "Tero Kivinen" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 09:05:25 -0000 Hi Tero, I guess I'd like to register an objection. I wrote a draft a few months ago to address this: http://www.ietf.org/id/draft-harkins-ike-iana-update-00.txt That suggested making it "Specification Required". You mentioned that someone was opposed to it being "Specification Required" but didn't say who or what the rationale was behind that opposition. So I'd like to discuss this a bit. I prefer "Specification Required" and would like to know what the problem someone has with it is. thanks, Dan. On Mon, March 26, 2012 9:49 am, Tero Kivinen wrote: > As described in the IPsecME WG meeting I propose that we change the > registration policy for the IPSEC Authentication Methods (Value 3) of > ipsec-registry from the "Standard-Track RFC" to "IETF Review" (From > RFC5226): > > ---------------------------------------------------------------------- > IETF Review - (Formerly called "IETF Consensus" in > [IANA-CONSIDERATIONS]) New values are assigned only through > RFCs that have been shepherded through the IESG as AD- > Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The > intention is that the document and proposed assignment will > be reviewed by the IESG and appropriate IETF WGs (or > experts, if suitable working groups no longer exist) to > ensure that the proposed assignment will not negatively > impact interoperability or otherwise extend IETF protocols > in an inappropriate or damaging manner. > > To ensure adequate community review, such documents are > shepherded through the IESG as AD-sponsored (or WG) > documents with an IETF Last Call. > > Examples: IPSECKEY Algorithm Types [RFC4025], > Accounting-Auth-Method AVP values in DIAMETER [RFC4005], TLS > Handshake Hello Extensions [RFC4366]. > ---------------------------------------------------------------------- > > I will ask IANA to make the change at the 2012-04-15, unless I get > some objections here in the list. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From kivinen@iki.fi Tue Mar 27 02:35:09 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6710621E8138 for ; Tue, 27 Mar 2012 02:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3ixxn7RO-LS for ; Tue, 27 Mar 2012 02:35:08 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0092921F8938 for ; Tue, 27 Mar 2012 02:35:07 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q2R9Z3hv020910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Mar 2012 12:35:03 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q2R9Z3cF027068; Tue, 27 Mar 2012 12:35:03 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20337.35271.746249.402746@fireball.kivinen.iki.fi> Date: Tue, 27 Mar 2012 12:35:03 +0300 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 2 min Cc: ipsec@ietf.org Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 09:35:09 -0000 Dan Harkins writes: > I guess I'd like to register an objection. I wrote a draft a few months > ago to address this: > > http://www.ietf.org/id/draft-harkins-ike-iana-update-00.txt > > That suggested making it "Specification Required". You mentioned that > someone was opposed to it being "Specification Required" but didn't say > who or what the rationale was behind that opposition. > > So I'd like to discuss this a bit. I prefer "Specification Required" > and would like to know what the problem someone has with it is. See the orignal thread in the ipsec-list: http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html What is your objection to the IETF Review? > > IETF Review - (Formerly called "IETF Consensus" in > > [IANA-CONSIDERATIONS]) New values are assigned only through > > RFCs that have been shepherded through the IESG as AD- > > Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The > > intention is that the document and proposed assignment will > > be reviewed by the IESG and appropriate IETF WGs (or > > experts, if suitable working groups no longer exist) to > > ensure that the proposed assignment will not negatively > > impact interoperability or otherwise extend IETF protocols > > in an inappropriate or damaging manner. > > > > To ensure adequate community review, such documents are > > shepherded through the IESG as AD-sponsored (or WG) > > documents with an IETF Last Call. > > > > Examples: IPSECKEY Algorithm Types [RFC4025], > > Accounting-Auth-Method AVP values in DIAMETER [RFC4005], TLS > > Handshake Hello Extensions [RFC4366]. -- kivinen@iki.fi From dharkins@lounge.org Tue Mar 27 07:14:27 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE27A21F87C7 for ; Tue, 27 Mar 2012 07:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.822 X-Spam-Level: X-Spam-Status: No, score=-5.822 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWj2ysLMzCKs for ; Tue, 27 Mar 2012 07:14:26 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id A21E021F8810 for ; Tue, 27 Mar 2012 07:14:22 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 3279DA88810E; Tue, 27 Mar 2012 07:14:22 -0700 (PDT) Received: from 130.129.82.190 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 27 Mar 2012 07:14:22 -0700 (PDT) Message-ID: In-Reply-To: <20337.35271.746249.402746@fireball.kivinen.iki.fi> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> Date: Tue, 27 Mar 2012 07:14:22 -0700 (PDT) From: "Dan Harkins" To: "Tero Kivinen" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org, Dan Harkins Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:14:27 -0000 On Tue, March 27, 2012 2:35 am, Tero Kivinen wrote: > Dan Harkins writes: >> I guess I'd like to register an objection. I wrote a draft a few >> months >> ago to address this: >> >> http://www.ietf.org/id/draft-harkins-ike-iana-update-00.txt >> >> That suggested making it "Specification Required". You mentioned that >> someone was opposed to it being "Specification Required" but didn't say >> who or what the rationale was behind that opposition. >> >> So I'd like to discuss this a bit. I prefer "Specification Required" >> and would like to know what the problem someone has with it is. > > See the orignal thread in the ipsec-list: > > http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html OK, but that says "'Specification Required' or 'IETF Review'", it's not opposition to "Specification Required". > What is your objection to the IETF Review? Well, I feel it is setting the bar too high for what I want to do. I had to remove a chunk of text from my PAKE draft fixed a significant, know, serious, and continuing problem with IKEv1. I was told that I should write another I-D that includes that text and try to see what happens. The issue is that requiring IESG review and AD sponsorship will likely result in me not getting over that bar and getting a code point assigned. It appears that all the PAKE drafts got one "yes" from the sponsoring AD and the remaining votes were "no objection" so it doesn't seem like the IESG is really interested in this topic and, frankly, I think the majority think "that stuff is out of my field of expertise". So my only option is to cajole an AD into sponsoring my draft and hoping that no one else on the IESG objects by saying, "didn't we just do this?" I don't want to burn up what remaining goodwill I might have with our ADs by continuing to push this topic. That said, the problem I want to fix-- IKEv1's susceptibility to dictionary attack, it's binding of a PSK to an IP address, and the prevalence of XAUTH because there's no other option-- should be fixed. We can say, "stop using IKEv1" but giving someone the option of implementing PAKE + IKEv2 versus just implementing PAKE, or more likely just continuing on with a broken XAUTH deployment, we all know what they'll do and it's not doing PAKE + IKEv2. It would be a service to the Internet to provide a fix for this. The IETF has not been successful in forcing people to do things against their will (viz, the history of IPv6) and if we tried here we'd likely fail again. So let me turn it around, what's wrong with "Specification Required"? thanks, Dan. >> > IETF Review - (Formerly called "IETF Consensus" in >> > [IANA-CONSIDERATIONS]) New values are assigned only >> through >> > RFCs that have been shepherded through the IESG as AD- >> > Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The >> > intention is that the document and proposed assignment >> will >> > be reviewed by the IESG and appropriate IETF WGs (or >> > experts, if suitable working groups no longer exist) to >> > ensure that the proposed assignment will not negatively >> > impact interoperability or otherwise extend IETF protocols >> > in an inappropriate or damaging manner. >> > >> > To ensure adequate community review, such documents are >> > shepherded through the IESG as AD-sponsored (or WG) >> > documents with an IETF Last Call. >> > >> > Examples: IPSECKEY Algorithm Types [RFC4025], >> > Accounting-Auth-Method AVP values in DIAMETER [RFC4005], >> TLS >> > Handshake Hello Extensions [RFC4366]. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From kivinen@iki.fi Tue Mar 27 07:39:07 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9C621E8188 for ; Tue, 27 Mar 2012 07:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jrynrpw+NIUj for ; Tue, 27 Mar 2012 07:39:04 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4122521F8512 for ; Tue, 27 Mar 2012 07:39:03 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q2REd0Qh010639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Mar 2012 17:39:00 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q2REd0A2001310; Tue, 27 Mar 2012 17:39:00 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20337.53508.89005.604501@fireball.kivinen.iki.fi> Date: Tue, 27 Mar 2012 17:39:00 +0300 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 8 min Cc: ipsec@ietf.org Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:39:07 -0000 Dan Harkins writes: > That said, the problem I want to fix-- IKEv1's susceptibility to > dictionary attack, it's binding of a PSK to an IP address, and the > prevalence of XAUTH because there's no other option-- should be fixed. All others than the dictionary attack IS ALREADY FIXED. The fixes are in the IKEv2. Also the dictionary attack problem will be fixed by your IKEv2 SPSK draft. > We can say, "stop using IKEv1" but giving someone the option of > implementing PAKE + IKEv2 versus just implementing PAKE, or more likely > just continuing on with a broken XAUTH deployment, we all know what > they'll do and it's not doing PAKE + IKEv2. Yes, we can and should say "Stop using IKEv1". That is the part I agree with you. I do not want to add any new features to IKEv1, as that just makes people to continue use it, and not to update to the IKEv2. If PAKE is the stick that causes people to move from IKEv1 to IKEv2, that is very good. > It would be a service to the Internet to provide a fix for this. The > IETF has not been successful in forcing people to do things against > their will (viz, the history of IPv6) and if we tried here we'd > likely fail again. > > So let me turn it around, what's wrong with "Specification Required"? Read the whole original thread and find out there. I do not really have any objections for Specification Required, that was what I originally proposed. The original thread (I just gave the link to first email in the full thread) has emails which explains why people felt it was not enough. Regardless whether it is Specification Required or not, I am still objecting if someone tries to add new features to IKEv1. Of course my objecting might not have any effect, but I still think it is BAD idea. -- kivinen@iki.fi From david.black@emc.com Tue Mar 27 07:39:37 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F31B21E81B1 for ; Tue, 27 Mar 2012 07:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.756 X-Spam-Level: X-Spam-Status: No, score=-109.756 tagged_above=-999 required=5 tests=[AWL=0.843, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyjjQIZmK6G5 for ; Tue, 27 Mar 2012 07:39:36 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 994A421E81A4 for ; Tue, 27 Mar 2012 07:39:36 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q2REdWSP020704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Mar 2012 10:39:33 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 27 Mar 2012 10:39:14 -0400 Received: from mxhub15.corp.emc.com (mxhub15.corp.emc.com [128.222.70.236]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q2REdDQR016910; Tue, 27 Mar 2012 10:39:13 -0400 Received: from mx14a.corp.emc.com ([169.254.1.70]) by mxhub15.corp.emc.com ([128.222.70.236]) with mapi; Tue, 27 Mar 2012 10:39:12 -0400 From: To: , Date: Tue, 27 Mar 2012 10:39:10 -0400 Thread-Topic: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy Thread-Index: Ac0MJCb0IslOgZtzTC65XAucZlDW2QAApyCw Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFA9DB@MX14A.corp.emc.com> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: ipsec@ietf.org Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:39:37 -0000 Hi Dan, One process note: > It appears that all the PAKE drafts got one "yes" from the sponsoring > AD and the remaining votes were "no objection" so it doesn't seem like > the IESG is really interested in this topic and, frankly, I think the > majority think "that stuff is out of my field of expertise". So my only > option is to cajole an AD into sponsoring my draft and hoping that no one > else on the IESG objects by saying, "didn't we just do this?" Speaking from long experience as a chair of many WGs, that sort of IESG vot= e tally is typical, even for WG docs (although usually both of the responsi= ble Area ADs vote yes, as they're both "sponsoring"). IMHO, you're being o= verly pessimistic. > So let me turn it around, what's wrong with "Specification Required"? While I know that you're competent to design a solid protocol, who does th= e security review of the next 5 j-random authentication mechanisms to make = sure that they don't have security flaws? I'd prefer something like IESG a= pproval that puts the Security Area in the loop to the notion of deferring = to some form of Expert Review (this is not a slam against Tero as the exper= t - wider review usually produces better results). Thanks, --David > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of= Dan Harkins > Sent: Tuesday, March 27, 2012 10:14 AM > To: Tero Kivinen > Cc: ipsec@ietf.org; Dan Harkins > Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Metho= ds (Value 3) registration > policy >=20 >=20 > On Tue, March 27, 2012 2:35 am, Tero Kivinen wrote: > > Dan Harkins writes: > >> I guess I'd like to register an objection. I wrote a draft a few > >> months > >> ago to address this: > >> > >> http://www.ietf.org/id/draft-harkins-ike-iana-update-00.txt > >> > >> That suggested making it "Specification Required". You mentioned that > >> someone was opposed to it being "Specification Required" but didn't sa= y > >> who or what the rationale was behind that opposition. > >> > >> So I'd like to discuss this a bit. I prefer "Specification Required" > >> and would like to know what the problem someone has with it is. > > > > See the orignal thread in the ipsec-list: > > > > http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html >=20 > OK, but that says "'Specification Required' or 'IETF Review'", it's > not opposition to "Specification Required". >=20 > > What is your objection to the IETF Review? >=20 > Well, I feel it is setting the bar too high for what I want to do. > I had to remove a chunk of text from my PAKE draft fixed a significant, > know, serious, and continuing problem with IKEv1. I was told that > I should write another I-D that includes that text and try to see > what happens. The issue is that requiring IESG review and AD sponsorship > will likely result in me not getting over that bar and getting a code > point assigned. >=20 > It appears that all the PAKE drafts got one "yes" from the sponsoring > AD and the remaining votes were "no objection" so it doesn't seem like > the IESG is really interested in this topic and, frankly, I think the > majority think "that stuff is out of my field of expertise". So my only > option is to cajole an AD into sponsoring my draft and hoping that no one > else on the IESG objects by saying, "didn't we just do this?" >=20 > I don't want to burn up what remaining goodwill I might have with > our ADs by continuing to push this topic. >=20 > That said, the problem I want to fix-- IKEv1's susceptibility to > dictionary attack, it's binding of a PSK to an IP address, and the > prevalence of XAUTH because there's no other option-- should be fixed. > We can say, "stop using IKEv1" but giving someone the option of > implementing PAKE + IKEv2 versus just implementing PAKE, or more likely > just continuing on with a broken XAUTH deployment, we all know what > they'll do and it's not doing PAKE + IKEv2. It would be a service to > the Internet to provide a fix for this. The IETF has not been successful > in forcing people to do things against their will (viz, the history of > IPv6) and if we tried here we'd likely fail again. >=20 > So let me turn it around, what's wrong with "Specification Required"? >=20 > thanks, >=20 > Dan. >=20 > >> > IETF Review - (Formerly called "IETF Consensus" in > >> > [IANA-CONSIDERATIONS]) New values are assigned only > >> through > >> > RFCs that have been shepherded through the IESG as AD- > >> > Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The > >> > intention is that the document and proposed assignment > >> will > >> > be reviewed by the IESG and appropriate IETF WGs (or > >> > experts, if suitable working groups no longer exist) to > >> > ensure that the proposed assignment will not negatively > >> > impact interoperability or otherwise extend IETF protoco= ls > >> > in an inappropriate or damaging manner. > >> > > >> > To ensure adequate community review, such documents are > >> > shepherded through the IESG as AD-sponsored (or WG) > >> > documents with an IETF Last Call. > >> > > >> > Examples: IPSECKEY Algorithm Types [RFC4025], > >> > Accounting-Auth-Method AVP values in DIAMETER [RFC4005], > >> TLS > >> > Handshake Hello Extensions [RFC4366]. > > -- > > kivinen@iki.fi > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Tue Mar 27 07:45:06 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36FA221E81FB for ; Tue, 27 Mar 2012 07:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8467xeGYb+8 for ; Tue, 27 Mar 2012 07:45:05 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D28E21E81E5 for ; Tue, 27 Mar 2012 07:45:00 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q2REisLB013893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Mar 2012 17:44:54 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q2REil72000446; Tue, 27 Mar 2012 17:44:47 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20337.53855.954242.315581@fireball.kivinen.iki.fi> Date: Tue, 27 Mar 2012 17:44:47 +0300 From: Tero Kivinen To: In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFA9DB@MX14A.corp.emc.com> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFA9DB@MX14A.corp.emc.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 1 min Cc: ipsec@ietf.org, dharkins@lounge.org Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:45:06 -0000 david.black@emc.com writes: > While I know that you're competent to design a solid protocol, who > does the security review of the next 5 j-random authentication > mechanisms to make sure that they don't have security flaws? I'd > prefer something like IESG approval that puts the Security Area in > the loop to the notion of deferring to some form of Expert Review > (this is not a slam against Tero as the expert - wider review > usually produces better results). None of the IKEv1 iana registries are expert review, so I do not have anything to do with them, except as I am expert for the IKEv2 registries, IANA seems to assume I can help them to solve old issues in the IKEv1 registries too, but I am doing that just as an individual helping them... -- kivinen@iki.fi From dharkins@lounge.org Tue Mar 27 08:39:09 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42A021E8242 for ; Tue, 27 Mar 2012 08:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.842 X-Spam-Level: X-Spam-Status: No, score=-5.842 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XImDAreYP0uz for ; Tue, 27 Mar 2012 08:39:09 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 53A6E21E80A9 for ; Tue, 27 Mar 2012 08:39:09 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 060AEA88810E; Tue, 27 Mar 2012 08:39:08 -0700 (PDT) Received: from 130.129.82.190 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 27 Mar 2012 08:39:09 -0700 (PDT) Message-ID: <7aa224f3b90062aabf6dea821c57d8a4.squirrel@www.trepanning.net> In-Reply-To: <20337.53508.89005.604501@fireball.kivinen.iki.fi> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <20337.53508.89005.604501@fireball.kivinen.iki.fi> Date: Tue, 27 Mar 2012 08:39:09 -0700 (PDT) From: "Dan Harkins" To: "Tero Kivinen" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:39:10 -0000 On Tue, March 27, 2012 7:39 am, Tero Kivinen wrote: > Dan Harkins writes: >> That said, the problem I want to fix-- IKEv1's susceptibility to >> dictionary attack, it's binding of a PSK to an IP address, and the >> prevalence of XAUTH because there's no other option-- should be fixed. > > All others than the dictionary attack IS ALREADY FIXED. The fixes are > in the IKEv2. Also the dictionary attack problem will be fixed by your > IKEv2 SPSK draft. Yet there is still this massive deployment of XAUTH + IKEv1. >> We can say, "stop using IKEv1" but giving someone the option of >> implementing PAKE + IKEv2 versus just implementing PAKE, or more likely >> just continuing on with a broken XAUTH deployment, we all know what >> they'll do and it's not doing PAKE + IKEv2. > > Yes, we can and should say "Stop using IKEv1". Yes we should. But we should not suffer any delusions that we can force anyone to do anything. > That is the part I agree with you. I do not want to add any new > features to IKEv1, as that just makes people to continue use it, and > not to update to the IKEv2. If PAKE is the stick that causes people to > move from IKEv1 to IKEv2, that is very good. We can't always get what we want and we should be reasonable in understanding that. If we could wave a magic wand and grant your wish that would be good; we can't. And given the limits to our power we have to accept that what will happen is people will continue to use IKEv1 + XAUTH because the work to go to IKEv2 is, to them (!), too much. The work to do SPSK in IKEv1 would be less than doing IKEv2 + SPSK though, so it is likely that by adding SPSK to IKEv1 we could get people off of XAUTH and that too would be a good thing. So if we weigh the improbable stretch goal of forcing people to stop using IKEv1 with the probable, more easily attainable, goal of getting people to stop using XAUTH by giving them an alternative that can pretty easily be implemented, I still come down on settling for an achievable goal of goodness and not making that be a victim for an unachievable goal of betterness. >> It would be a service to the Internet to provide a fix for this. The >> IETF has not been successful in forcing people to do things against >> their will (viz, the history of IPv6) and if we tried here we'd >> likely fail again. >> >> So let me turn it around, what's wrong with "Specification Required"? > > Read the whole original thread and find out there. I do not really > have any objections for Specification Required, that was what I > originally proposed. The original thread (I just gave the link to > first email in the full thread) has emails which explains why people > felt it was not enough. > > Regardless whether it is Specification Required or not, I am still > objecting if someone tries to add new features to IKEv1. Of course my > objecting might not have any effect, but I still think it is BAD idea. OK, so we're in agreement: "Specification Required." Dan. From dharkins@lounge.org Tue Mar 27 09:23:07 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17F121E80A6 for ; Tue, 27 Mar 2012 09:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.861 X-Spam-Level: X-Spam-Status: No, score=-5.861 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Puf6GdaICYVt for ; Tue, 27 Mar 2012 09:23:05 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 8688121E80AB for ; Tue, 27 Mar 2012 09:23:04 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 174771022404C; Tue, 27 Mar 2012 09:23:04 -0700 (PDT) Received: from 130.129.82.190 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 27 Mar 2012 09:23:04 -0700 (PDT) Message-ID: <1a942ebf6f49a6569915222f3c660381.squirrel@www.trepanning.net> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFA9DB@MX14A.corp.emc.com> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFA9DB@MX14A.corp.emc.com> Date: Tue, 27 Mar 2012 09:23:04 -0700 (PDT) From: "Dan Harkins" To: david.black@emc.com User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org, dharkins@lounge.org, kivinen@iki.fi Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 16:23:07 -0000 Hi David, On Tue, March 27, 2012 7:39 am, david.black@emc.com wrote: > Hi Dan, > > One process note: > >> It appears that all the PAKE drafts got one "yes" from the sponsoring >> AD and the remaining votes were "no objection" so it doesn't seem like >> the IESG is really interested in this topic and, frankly, I think the >> majority think "that stuff is out of my field of expertise". So my only >> option is to cajole an AD into sponsoring my draft and hoping that no >> one >> else on the IESG objects by saying, "didn't we just do this?" > > Speaking from long experience as a chair of many WGs, that sort of IESG > vote tally is typical, even for WG docs (although usually both of the > responsible Area ADs vote yes, as they're both "sponsoring"). IMHO, > you're being overly pessimistic. > >> So let me turn it around, what's wrong with "Specification Required"? > > While I know that you're competent to design a solid protocol, who does > the security review of the next 5 j-random authentication mechanisms to > make sure that they don't have security flaws? I'd prefer something like > IESG approval that puts the Security Area in the loop to the notion of > deferring to some form of Expert Review (this is not a slam against Tero > as the expert - wider review usually produces better results). That's a really good point. Had it been "Specification Required" all along XAUTH might've gotten an official code point. And who knows maybe one of the j-random proposals might be just that. But IKEv1 really is pretty done. At this point I'm pretty sure that j would be zero. I know IKE's being used wrong and I know the people who are using it wrong don't want to go to IKEv2. They understand what they're doing is broken (a shared PSK for everyone followed by PAP in XAUTH) but they don't want to go to IKEv2 and use EAP to "fix" it, and it doesn't sound like going to IKEv2 with SPSK is much more attractive. I think we can make things better with a simple addition and I just want to be able to do that. regards, Dan. From david.black@emc.com Tue Mar 27 09:41:53 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A650021E8205 for ; Tue, 27 Mar 2012 09:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.762 X-Spam-Level: X-Spam-Status: No, score=-109.762 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHIjLEfOWwSJ for ; Tue, 27 Mar 2012 09:41:51 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id A3F4421E81EE for ; Tue, 27 Mar 2012 09:41:49 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q2RGflsr028513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Mar 2012 12:41:47 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 27 Mar 2012 12:41:32 -0400 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q2RGfVI7007683; Tue, 27 Mar 2012 12:41:31 -0400 Received: from mx14a.corp.emc.com ([169.254.1.70]) by mxhub11.corp.emc.com ([10.254.92.106]) with mapi; Tue, 27 Mar 2012 12:41:31 -0400 From: To: Date: Tue, 27 Mar 2012 12:41:28 -0400 Thread-Topic: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy Thread-Index: Ac0MNeyKZpwOM0TTRuWWUaAAdXXBbQAAjtJA Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFAA94@MX14A.corp.emc.com> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFA9DB@MX14A.corp.emc.com> <1a942ebf6f49a6569915222f3c660381.squirrel@www.trepanning.net> In-Reply-To: <1a942ebf6f49a6569915222f3c660381.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: ipsec@ietf.org Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 16:41:53 -0000 > I think we can make things better with a simple addition and I just > want to be able to do that. To ask bluntly - what is the problem with soliciting AD sponsorship for the= simple addition? IMHO, "Specification Required" by itself is entirely too weak for security = protocols. Thanks, --David > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Tuesday, March 27, 2012 12:23 PM > To: Black, David > Cc: dharkins@lounge.org; kivinen@iki.fi; ipsec@ietf.org > Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Metho= ds (Value 3) registration > policy >=20 >=20 > Hi David, >=20 > On Tue, March 27, 2012 7:39 am, david.black@emc.com wrote: > > Hi Dan, > > > > One process note: > > > >> It appears that all the PAKE drafts got one "yes" from the sponsorin= g > >> AD and the remaining votes were "no objection" so it doesn't seem like > >> the IESG is really interested in this topic and, frankly, I think the > >> majority think "that stuff is out of my field of expertise". So my onl= y > >> option is to cajole an AD into sponsoring my draft and hoping that no > >> one > >> else on the IESG objects by saying, "didn't we just do this?" > > > > Speaking from long experience as a chair of many WGs, that sort of IESG > > vote tally is typical, even for WG docs (although usually both of the > > responsible Area ADs vote yes, as they're both "sponsoring"). IMHO, > > you're being overly pessimistic. > > > >> So let me turn it around, what's wrong with "Specification Required"= ? > > > > While I know that you're competent to design a solid protocol, who doe= s > > the security review of the next 5 j-random authentication mechanisms to > > make sure that they don't have security flaws? I'd prefer something li= ke > > IESG approval that puts the Security Area in the loop to the notion of > > deferring to some form of Expert Review (this is not a slam against Ter= o > > as the expert - wider review usually produces better results). >=20 > That's a really good point. Had it been "Specification Required" all > along XAUTH might've gotten an official code point. And who knows maybe > one of the j-random proposals might be just that. But IKEv1 really is > pretty done. At this point I'm pretty sure that j would be zero. >=20 > I know IKE's being used wrong and I know the people who are using it > wrong don't want to go to IKEv2. They understand what they're doing is > broken (a shared PSK for everyone followed by PAP in XAUTH) but they > don't want to go to IKEv2 and use EAP to "fix" it, and it doesn't sound > like going to IKEv2 with SPSK is much more attractive. >=20 > I think we can make things better with a simple addition and I just > want to be able to do that. >=20 > regards, >=20 > Dan. >=20 >=20 From ietf@meetecho.com Tue Mar 27 12:22:01 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1013D21F87F9 for ; Tue, 27 Mar 2012 12:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.874 X-Spam-Level: X-Spam-Status: No, score=-0.874 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08lxXPGU5nJO for ; Tue, 27 Mar 2012 12:22:00 -0700 (PDT) Received: from smtplq02.aruba.it (smtplqs-out28.aruba.it [62.149.158.68]) by ietfa.amsl.com (Postfix) with SMTP id 0B5BE21F87D3 for ; Tue, 27 Mar 2012 12:21:56 -0700 (PDT) Received: (qmail 31366 invoked by uid 89); 27 Mar 2012 19:21:55 -0000 Received: from unknown (HELO smtp8.aruba.it) (62.149.158.228) by smtplq02.aruba.it with SMTP; 27 Mar 2012 19:21:55 -0000 Received: (qmail 28436 invoked by uid 89); 27 Mar 2012 19:21:55 -0000 Received: from unknown (HELO ?130.129.21.177?) (ietf@meetecho.com@130.129.21.177) by smtp8.ad.aruba.it with SMTP; 27 Mar 2012 19:21:55 -0000 Message-ID: <4F72134F.50205@meetecho.com> Date: Tue, 27 Mar 2012 21:21:51 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: IPsec@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp8.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N Cc: Team Meetecho Subject: [IPsec] Meetecho session recording available X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 19:22:01 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of IPSECME session at IETF-83 is available. You can watch it by either clicking the proper link on the remote participation page (http://www.ietf.org/meeting/83/remote-participation.html#Meetecho), or by directly accessing the following URL: http://www.meetecho.com/ietf83/recordings#IPSECME_IETF83 For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From yaronf.ietf@gmail.com Tue Mar 27 14:13:33 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1187721E80FC for ; Tue, 27 Mar 2012 14:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEKMzc0WfBdC for ; Tue, 27 Mar 2012 14:13:32 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id EABD221E80F0 for ; Tue, 27 Mar 2012 14:13:31 -0700 (PDT) Received: by werb10 with SMTP id b10so255272wer.31 for ; Tue, 27 Mar 2012 14:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ibMagLPrUKO6uMKUE1aB0sIgMWElyROuxiJcnYVeNoo=; b=lZ+f+cw++DoxGXYlykj53Oy4muw0Le6rb3j5jdScryVs+9hjI2IVm4Uw+7JtTiBjnc I46lu1U/cas9+4WLARMW6YndPeE4BCyFl+tjG38IZNi+CKrqrU3rD5tIuMjCYXDdtI95 OalRKp5nbWbYrVdWmZMnlUhF7FKjpg6BtpMh8gticSarE6YgoOm6trNUPjBS5SxENdpE WdQ8UVFyOO/ynRKRuccZOJa5KLB7IXAq9LUTvT/6g50x2Wb78A3Cixuaz3oTodBxig6C dJWNg0jPVMMla6IhP1OdYLdoC8xSNYo2G9/vqN+vNlNzIIFurLAXNe8mxKlVR9z+jFUn pN6A== Received: by 10.180.94.33 with SMTP id cz1mr1128948wib.13.1332882811110; Tue, 27 Mar 2012 14:13:31 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-183-159-173.red.bezeqint.net. [79.183.159.173]) by mx.google.com with ESMTPS id bx13sm52411757wib.10.2012.03.27.14.13.29 (version=SSLv3 cipher=OTHER); Tue, 27 Mar 2012 14:13:30 -0700 (PDT) Message-ID: <4F722D78.7020702@gmail.com> Date: Tue, 27 Mar 2012 23:13:28 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: david.black@emc.com References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFA9DB@MX14A.corp.emc.com> <1a942ebf6f49a6569915222f3c660381.squirrel@www.trepanning.net> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFAA94@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFAA94@MX14A.corp.emc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, dharkins@lounge.org Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 21:13:33 -0000 Hi Dan, I haven't made up my mind yet whether I support the addition of SPSK to IKEv1 or not, because both you and Tero have made some good points. But this very discussion is a strong proof to me that we need to have IETF Review (in the RFC 5226 sense) for this kind of major change to IKEv1. Because this is exactly the community that needs to discuss new authentication methods, and to weigh their security and other properties against the disadvantages of adding yet more stuff to IKEv1. This needs to be an open discussion, and I am sure the ADs will use our input when they decide whether to sponsor any such proposal. Thanks, Yaron On 03/27/2012 06:41 PM, david.black@emc.com wrote: >> I think we can make things better with a simple addition and I just >> want to be able to do that. > > To ask bluntly - what is the problem with soliciting AD sponsorship for the simple addition? > > IMHO, "Specification Required" by itself is entirely too weak for security protocols. > > Thanks, > --David > >> -----Original Message----- >> From: Dan Harkins [mailto:dharkins@lounge.org] >> Sent: Tuesday, March 27, 2012 12:23 PM >> To: Black, David >> Cc: dharkins@lounge.org; kivinen@iki.fi; ipsec@ietf.org >> Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration >> policy >> >> >> Hi David, >> >> On Tue, March 27, 2012 7:39 am, david.black@emc.com wrote: >>> Hi Dan, >>> >>> One process note: >>> >>>> It appears that all the PAKE drafts got one "yes" from the sponsoring >>>> AD and the remaining votes were "no objection" so it doesn't seem like >>>> the IESG is really interested in this topic and, frankly, I think the >>>> majority think "that stuff is out of my field of expertise". So my only >>>> option is to cajole an AD into sponsoring my draft and hoping that no >>>> one >>>> else on the IESG objects by saying, "didn't we just do this?" >>> >>> Speaking from long experience as a chair of many WGs, that sort of IESG >>> vote tally is typical, even for WG docs (although usually both of the >>> responsible Area ADs vote yes, as they're both "sponsoring"). IMHO, >>> you're being overly pessimistic. >>> >>>> So let me turn it around, what's wrong with "Specification Required"? >>> >>> While I know that you're competent to design a solid protocol, who does >>> the security review of the next 5 j-random authentication mechanisms to >>> make sure that they don't have security flaws? I'd prefer something like >>> IESG approval that puts the Security Area in the loop to the notion of >>> deferring to some form of Expert Review (this is not a slam against Tero >>> as the expert - wider review usually produces better results). >> >> That's a really good point. Had it been "Specification Required" all >> along XAUTH might've gotten an official code point. And who knows maybe >> one of the j-random proposals might be just that. But IKEv1 really is >> pretty done. At this point I'm pretty sure that j would be zero. >> >> I know IKE's being used wrong and I know the people who are using it >> wrong don't want to go to IKEv2. They understand what they're doing is >> broken (a shared PSK for everyone followed by PAP in XAUTH) but they >> don't want to go to IKEv2 and use EAP to "fix" it, and it doesn't sound >> like going to IKEv2 with SPSK is much more attractive. >> >> I think we can make things better with a simple addition and I just >> want to be able to do that. >> >> regards, >> >> Dan. >> >> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From dharkins@lounge.org Wed Mar 28 00:49:28 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238F621F88C4 for ; Wed, 28 Mar 2012 00:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.877 X-Spam-Level: X-Spam-Status: No, score=-5.877 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaDMD+SUwvTt for ; Wed, 28 Mar 2012 00:49:27 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6EF21F88A2 for ; Wed, 28 Mar 2012 00:49:27 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id C94131022404A; Wed, 28 Mar 2012 00:49:26 -0700 (PDT) Received: from 130.129.82.190 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 28 Mar 2012 00:49:27 -0700 (PDT) Message-ID: In-Reply-To: <4F722D78.7020702@gmail.com> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFA9DB@MX14A.corp.emc.com> <1a942ebf6f49a6569915222f3c660381.squirrel@www.trepanning.net> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFAA94@MX14A.corp.emc.com> <4F722D78.7020702@gmail.com> Date: Wed, 28 Mar 2012 00:49:27 -0700 (PDT) From: "Dan Harkins" To: "Yaron Sheffer" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org, david.black@emc.com, dharkins@lounge.org Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 07:49:28 -0000 Hi, Let me answer David here in a response to Yaron.... To be equally blunt, it is because this PAKE work became extremely political and I was, and still am, very unhappy with the way it turned out. Repeating it, this time with an obsoleted protocol, would cause (more) people to question my sanity-- i.e. doing the same thing and expecting a different result. I'd like to just get a stable reference for this minor change that has the potential to do good. I don't want to fight over it anymore. regards, Dan. On Tue, March 27, 2012 2:13 pm, Yaron Sheffer wrote: > Hi Dan, > > I haven't made up my mind yet whether I support the addition of SPSK to > IKEv1 or not, because both you and Tero have made some good points. > > But this very discussion is a strong proof to me that we need to have > IETF Review (in the RFC 5226 sense) for this kind of major change to > IKEv1. Because this is exactly the community that needs to discuss new > authentication methods, and to weigh their security and other properties > against the disadvantages of adding yet more stuff to IKEv1. This needs > to be an open discussion, and I am sure the ADs will use our input when > they decide whether to sponsor any such proposal. > > Thanks, > Yaron > > On 03/27/2012 06:41 PM, david.black@emc.com wrote: >>> I think we can make things better with a simple addition and I just >>> want to be able to do that. >> >> To ask bluntly - what is the problem with soliciting AD sponsorship for >> the simple addition? >> >> IMHO, "Specification Required" by itself is entirely too weak for >> security protocols. >> >> Thanks, >> --David >> >>> -----Original Message----- >>> From: Dan Harkins [mailto:dharkins@lounge.org] >>> Sent: Tuesday, March 27, 2012 12:23 PM >>> To: Black, David >>> Cc: dharkins@lounge.org; kivinen@iki.fi; ipsec@ietf.org >>> Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication >>> Methods (Value 3) registration >>> policy >>> >>> >>> Hi David, >>> >>> On Tue, March 27, 2012 7:39 am, david.black@emc.com wrote: >>>> Hi Dan, >>>> >>>> One process note: >>>> >>>>> It appears that all the PAKE drafts got one "yes" from the >>>>> sponsoring >>>>> AD and the remaining votes were "no objection" so it doesn't seem >>>>> like >>>>> the IESG is really interested in this topic and, frankly, I think the >>>>> majority think "that stuff is out of my field of expertise". So my >>>>> only >>>>> option is to cajole an AD into sponsoring my draft and hoping that no >>>>> one >>>>> else on the IESG objects by saying, "didn't we just do this?" >>>> >>>> Speaking from long experience as a chair of many WGs, that sort of >>>> IESG >>>> vote tally is typical, even for WG docs (although usually both of the >>>> responsible Area ADs vote yes, as they're both "sponsoring"). IMHO, >>>> you're being overly pessimistic. >>>> >>>>> So let me turn it around, what's wrong with "Specification >>>>> Required"? >>>> >>>> While I know that you're competent to design a solid protocol, who >>>> does >>>> the security review of the next 5 j-random authentication mechanisms >>>> to >>>> make sure that they don't have security flaws? I'd prefer something >>>> like >>>> IESG approval that puts the Security Area in the loop to the notion of >>>> deferring to some form of Expert Review (this is not a slam against >>>> Tero >>>> as the expert - wider review usually produces better results). >>> >>> That's a really good point. Had it been "Specification Required" all >>> along XAUTH might've gotten an official code point. And who knows maybe >>> one of the j-random proposals might be just that. But IKEv1 really is >>> pretty done. At this point I'm pretty sure that j would be zero. >>> >>> I know IKE's being used wrong and I know the people who are using it >>> wrong don't want to go to IKEv2. They understand what they're doing is >>> broken (a shared PSK for everyone followed by PAP in XAUTH) but they >>> don't want to go to IKEv2 and use EAP to "fix" it, and it doesn't sound >>> like going to IKEv2 with SPSK is much more attractive. >>> >>> I think we can make things better with a simple addition and I just >>> want to be able to do that. >>> >>> regards, >>> >>> Dan. >>> >>> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From ynir@checkpoint.com Wed Mar 28 01:15:04 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6CC21F8952 for ; Wed, 28 Mar 2012 01:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80jsZJGvSUtz for ; Wed, 28 Mar 2012 01:15:03 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 86D5921F8932 for ; Wed, 28 Mar 2012 01:14:56 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2S8Epbc029102; Wed, 28 Mar 2012 10:14:51 +0200 X-CheckPoint: {4F72C795-0-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 28 Mar 2012 10:14:51 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 28 Mar 2012 10:14:50 +0200 From: Yoav Nir To: Dan Harkins Date: Wed, 28 Mar 2012 10:14:51 +0200 Thread-Topic: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy Thread-Index: Ac0Mutgyeu8gk3TaQ5OlXt/UK7Z75w== Message-ID: References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFA9DB@MX14A.corp.emc.com> <1a942ebf6f49a6569915222f3c660381.squirrel@www.trepanning.net> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFAA94@MX14A.corp.emc.com> <4F722D78.7020702@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "ipsec@ietf.org" , "david.black@emc.com" Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:15:04 -0000 Hi Dan I have no opinion about the level of review needed for changes to IKEv1, an= d I share your unhappiness with the way PAKE turned out.=20 If I had to guess the reasons for the slow adoption of IKEv2, I would guess= that it's because IKEv1 (with XAuth/hybrid, Config, odd-numbered messages,= and poor PSK support for mobile peers) just works. The big vendors have at= least server-side support, and Microsoft has a client in Win7. I think EAP= is a hindrance, because XAuth works better with older backend servers. Your proposal will be more secure than XAuth and require less round trips, = but won't integrate with AAA servers. I think anyone who is going to go to= the effort of implementing this (replace or update all IKEv1 endpoints) mi= ght as well move them to IKEv2. The big hurdle to implementing what you sug= gest for remote access is that XAuth works.=20 What doesn't work is a gateway with a dynamic external IP address that does= n't have a certificate. But I don't see how upgrading the gateways to suppo= rt your extension is easier than upgrading them to support IKEv2.=20 Yoav On Mar 28, 2012, at 9:49 AM, Dan Harkins wrote: >=20 > Hi, >=20 > Let me answer David here in a response to Yaron.... >=20 > To be equally blunt, it is because this PAKE work became extremely > political and I was, and still am, very unhappy with the way it turned > out. Repeating it, this time with an obsoleted protocol, would cause > (more) people to question my sanity-- i.e. doing the same thing and > expecting a different result. >=20 > I'd like to just get a stable reference for this minor change that > has the potential to do good. I don't want to fight over it anymore. >=20 > regards, >=20 > Dan. From mcr@sandelman.ca Wed Mar 28 05:12:32 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C479221E8097 for ; Wed, 28 Mar 2012 05:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.528 X-Spam-Level: X-Spam-Status: No, score=-1.528 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+xTxJf3vKAl for ; Wed, 28 Mar 2012 05:12:31 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id A8E9821F8818 for ; Wed, 28 Mar 2012 05:12:28 -0700 (PDT) Received: from marajade.sandelman.ca (dhcp-10ed.meeting.ietf.org [130.129.16.237]) by relay.sandelman.ca (Postfix) with ESMTPS id A27C5344E1 for ; Wed, 28 Mar 2012 08:09:44 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id E600398AAE; Wed, 28 Mar 2012 14:12:26 +0200 (CEST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id D778F98281 for ; Wed, 28 Mar 2012 14:12:26 +0200 (CEST) From: Michael Richardson To: "ipsec@ietf.org" In-Reply-To: References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFA9DB@MX14A.corp.emc.com> <1a942ebf6f49a6569915222f3c660381.squirrel@www.trepanning.net> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFAA94@MX14A.corp.emc.com> <4F722D78.7020702@gmail.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 28 Mar 2012 14:12:26 +0200 Message-ID: <30378.1332936746@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:12:32 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Yoav" =3D=3D Yoav Nir writes: Yoav> If I had to guess the reasons for the slow adoption of IKEv2, Yoav> I would guess that it's because IKEv1 (with XAuth/hybrid, Yoav> Config, odd-numbered messages, and poor PSK support for mobile Yoav> peers) just works. The big vendors have at least server-side Yoav> support, and Microsoft has a client in Win7. I think EAP is a Yoav> hindrance, because XAuth works better with older backend Yoav> servers. Let me suggest that enhancements to IKEv1 are point releases, for which you get with your maintenance. But, IKEv2 is a major release, for which the customer pays again. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT3MAKoqHRg3pndX9AQJ/OAP+MVYdd+7k51hkG7OE2yWUC4cBCgJCP57W UF/zUNdOvwgofhyA83LOU0tUwmCjeI/bKPDCHlo5Wgril8aNqv20rRXySZwtUu9L XM8HOtexZEUx8aA91M47CzvmYU62r2dqBW2S+c0xIxjXveZTFT8Ka/lsQh4yWSqa vP1dQe+qOTE= =9YL4 -----END PGP SIGNATURE----- --=-=-=-- From ynir@checkpoint.com Wed Mar 28 05:43:49 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F71D21E81E6 for ; Wed, 28 Mar 2012 05:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.502 X-Spam-Level: X-Spam-Status: No, score=-10.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taks8PO4Mekr for ; Wed, 28 Mar 2012 05:43:48 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7D46E21E81EC for ; Wed, 28 Mar 2012 05:43:46 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2SCg9Pt001336; Wed, 28 Mar 2012 14:43:43 +0200 X-CheckPoint: {4F730638-2-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 28 Mar 2012 14:43:29 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 28 Mar 2012 14:43:28 +0200 From: Yoav Nir To: Michael Richardson Date: Wed, 28 Mar 2012 14:43:26 +0200 Thread-Topic: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy Thread-Index: Ac0M4F9tVmggy6Z/ScmnheW0AnyJQw== Message-ID: <201BF9D4-195A-4C62-9880-BAA834759656@checkpoint.com> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFA9DB@MX14A.corp.emc.com> <1a942ebf6f49a6569915222f3c660381.squirrel@www.trepanning.net> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFAA94@MX14A.corp.emc.com> <4F722D78.7020702@gmail.com> <30378.1332936746@marajade.sandelman.ca> In-Reply-To: <30378.1332936746@marajade.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "ipsec@ietf.org" Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:43:49 -0000 On Mar 28, 2012, at 2:12 PM, Michael Richardson wrote: >=20 >>>>>> "Yoav" =3D=3D Yoav Nir writes: > Yoav> If I had to guess the reasons for the slow adoption of IKEv2, > Yoav> I would guess that it's because IKEv1 (with XAuth/hybrid, > Yoav> Config, odd-numbered messages, and poor PSK support for mobile > Yoav> peers) just works. The big vendors have at least server-side > Yoav> support, and Microsoft has a client in Win7. I think EAP is a > Yoav> hindrance, because XAuth works better with older backend > Yoav> servers. >=20 > Let me suggest that enhancements to IKEv1 are point releases, for which > you get with your maintenance. > But, IKEv2 is a major release, for which the customer pays again. I don't know about other vendors, but for us IKEv2 was introduced in a vers= ion called R71. Customers eventually do upgrade, whether it's to get IKEv2 = or get one of the other features. Similarly in Windows, customers buy Windo= ws 7 for the 64-bit support, or the aero interface, or for IPv6 support, an= d they also get the IKEv2.=20 I don't think anyone is going to add new enhancements to old releases now, = unless those "enhancements" begin with the words "prevent an attack where= =85"= From kivinen@iki.fi Wed Mar 28 06:04:31 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58E621E81A2 for ; Wed, 28 Mar 2012 06:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljygH9pflp9m for ; Wed, 28 Mar 2012 06:04:30 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id F109321F889F for ; Wed, 28 Mar 2012 06:04:29 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q2SD4PKo009641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Mar 2012 16:04:25 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q2SD4N8K003902; Wed, 28 Mar 2012 16:04:23 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20339.3159.442125.142134@fireball.kivinen.iki.fi> Date: Wed, 28 Mar 2012 16:04:23 +0300 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: <7aa224f3b90062aabf6dea821c57d8a4.squirrel@www.trepanning.net> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <20337.53508.89005.604501@fireball.kivinen.iki.fi> <7aa224f3b90062aabf6dea821c57d8a4.squirrel@www.trepanning.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 5 min Cc: ipsec@ietf.org Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 13:04:31 -0000 Dan Harkins writes: > We can't always get what we want and we should be reasonable in > understanding that. If we could wave a magic wand and grant your wish > that would be good; we can't. And given the limits to our power we > have to accept that what will happen is people will continue to use > IKEv1 + XAUTH because the work to go to IKEv2 is, to them (!), too > much. The work to do SPSK in IKEv1 would be less than doing IKEv2 + SPSK > though, so it is likely that by adding SPSK to IKEv1 we could get people > off of XAUTH and that too would be a good thing. > > So if we weigh the improbable stretch goal of forcing people to stop > using IKEv1 with the probable, more easily attainable, goal of getting > people to stop using XAUTH by giving them an alternative that can pretty > easily be implemented, I still come down on settling for an achievable > goal of goodness and not making that be a victim for an unachievable goal > of betterness. The reason they cannot move to use IKEv1 + SPSK any faster than they can move to use IKEv2 + SPSK is same. Both of them do require new version of both client and server. The client customers always tell that the reason they cannot use IKEv2 as the SGW's they use do not support IKEv2 (or it is not turned on by default). The SGW customers say that the reason they cannot use IKEv2 as they clients do not support it (or it is not turned on by default)... > > Regardless whether it is Specification Required or not, I am still > > objecting if someone tries to add new features to IKEv1. Of course my > > objecting might not have any effect, but I still think it is BAD idea. > > OK, so we're in agreement: "Specification Required." I originally suggested "Specification Required", so yes we are in agreement in that, but we are not only people in the WG, and there has been people saying otherwise. If we do not reach some kind of concensus, then the default action will most likely be "do nothing", which will mean the registry stays what it is now, and I do not want that. I think "IETF Review" would be good compromise for this as it would make it easier than "Standard Track RFC", but would satisfy those who do not want to have it as lower as "Specification Required" is... -- kivinen@iki.fi From kivinen@iki.fi Wed Mar 28 06:06:12 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8835D21E822E for ; Wed, 28 Mar 2012 06:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbAVnfn7Zmu5 for ; Wed, 28 Mar 2012 06:06:12 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45CD21F889F for ; Wed, 28 Mar 2012 06:06:11 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q2SD65Kd004453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Mar 2012 16:06:05 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q2SD65fT014731; Wed, 28 Mar 2012 16:06:05 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20339.3261.388468.541609@fireball.kivinen.iki.fi> Date: Wed, 28 Mar 2012 16:06:05 +0300 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: <1a942ebf6f49a6569915222f3c660381.squirrel@www.trepanning.net> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFA9DB@MX14A.corp.emc.com> <1a942ebf6f49a6569915222f3c660381.squirrel@www.trepanning.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 1 min Cc: ipsec@ietf.org, david.black@emc.com Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 13:06:12 -0000 Dan Harkins writes: > That's a really good point. Had it been "Specification Required" all > along XAUTH might've gotten an official code point. And who knows maybe > one of the j-random proposals might be just that. But IKEv1 really is > pretty done. At this point I'm pretty sure that j would be zero. Most likely not, as all IPsec work had to be stopped so we could ship the IPsec out... IPSRA was supposed to do things like XAUTH and Configuration mode etc, but it failed... -- kivinen@iki.fi From david.black@emc.com Wed Mar 28 06:59:01 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FBD21F89FC for ; Wed, 28 Mar 2012 06:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.778 X-Spam-Level: X-Spam-Status: No, score=-109.778 tagged_above=-999 required=5 tests=[AWL=0.821, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQJm8PyCOe4Y for ; Wed, 28 Mar 2012 06:59:00 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5691521F898D for ; Wed, 28 Mar 2012 06:58:59 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q2SDwvId003562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 28 Mar 2012 09:58:58 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Wed, 28 Mar 2012 09:58:47 -0400 Received: from mxhub17.corp.emc.com (mxhub17.corp.emc.com [10.254.93.46]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q2SDwh1O000492 for ; Wed, 28 Mar 2012 09:58:45 -0400 Received: from mx14a.corp.emc.com ([169.254.1.70]) by mxhub17.corp.emc.com ([10.254.93.46]) with mapi; Wed, 28 Mar 2012 09:58:43 -0400 From: To: Date: Wed, 28 Mar 2012 09:58:41 -0400 Thread-Topic: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy Thread-Index: Ac0M5IBEVOc11UScSqGDt4AKWyRdHwABesGw Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFAD08@MX14A.corp.emc.com> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <20337.53508.89005.604501@fireball.kivinen.iki.fi> <7aa224f3b90062aabf6dea821c57d8a4.squirrel@www.trepanning.net> <20339.3159.442125.142134@fireball.kivinen.iki.fi> In-Reply-To: <20339.3159.442125.142134@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 13:59:01 -0000 > I think "IETF Review" would be good compromise for this as it would > make it easier than "Standard Track RFC", but would satisfy those who > do not want to have it as lower as "Specification Required" is... Summarizing my views: - "Specification Required" is an unacceptably low bar for this sort of security protocol due to the possibility of security flaws. - I prefer "IETF Review" to "Expert Review" for this sort of security protocol as "IETF Review" should yield higher-quality results. Thanks, --David > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of= Tero Kivinen > Sent: Wednesday, March 28, 2012 9:04 AM > To: Dan Harkins > Cc: ipsec@ietf.org > Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Metho= ds (Value 3) registration > policy >=20 > Dan Harkins writes: > > We can't always get what we want and we should be reasonable in > > understanding that. If we could wave a magic wand and grant your wish > > that would be good; we can't. And given the limits to our power we > > have to accept that what will happen is people will continue to use > > IKEv1 + XAUTH because the work to go to IKEv2 is, to them (!), too > > much. The work to do SPSK in IKEv1 would be less than doing IKEv2 + SPS= K > > though, so it is likely that by adding SPSK to IKEv1 we could get peopl= e > > off of XAUTH and that too would be a good thing. > > > > So if we weigh the improbable stretch goal of forcing people to stop > > using IKEv1 with the probable, more easily attainable, goal of getting > > people to stop using XAUTH by giving them an alternative that can prett= y > > easily be implemented, I still come down on settling for an achievable > > goal of goodness and not making that be a victim for an unachievable go= al > > of betterness. >=20 > The reason they cannot move to use IKEv1 + SPSK any faster than they > can move to use IKEv2 + SPSK is same. Both of them do require new > version of both client and server. The client customers always tell > that the reason they cannot use IKEv2 as the SGW's they use do not > support IKEv2 (or it is not turned on by default). The SGW customers > say that the reason they cannot use IKEv2 as they clients do not > support it (or it is not turned on by default)... >=20 > > > Regardless whether it is Specification Required or not, I am still > > > objecting if someone tries to add new features to IKEv1. Of course my > > > objecting might not have any effect, but I still think it is BAD idea= . > > > > OK, so we're in agreement: "Specification Required." >=20 > I originally suggested "Specification Required", so yes we are in > agreement in that, but we are not only people in the WG, and there has > been people saying otherwise. If we do not reach some kind of > concensus, then the default action will most likely be "do nothing", > which will mean the registry stays what it is now, and I do not want > that. >=20 > I think "IETF Review" would be good compromise for this as it would > make it easier than "Standard Track RFC", but would satisfy those who > do not want to have it as lower as "Specification Required" is... > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec