From owner-ietf-ipsec-failover Mon Dec 18 12:34:43 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBIJYhYF050343; Mon, 18 Dec 2006 12:34:43 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBIJYhOH050342; Mon, 18 Dec 2006 12:34:43 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from [10.20.30.101] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBIJYf2C050328 for ; Mon, 18 Dec 2006 12:34:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 18 Dec 2006 11:34:28 -0800 To: ietf-ipsec-failover@vpnc.org From: Paul Hoffman Subject: The ietf-ipsec-failover mailing list is now active Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ...although there are only a few people on the list, and does not include everyone who was at the dinner in San Diego. People here need to think about when to start producing Internet Drafts, and whether it would be useful or not to tell the main IPsec ex-WG mailing list about this one sooner or later. --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsec-failover Mon Dec 18 17:39:05 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBJ0d5GV082618; Mon, 18 Dec 2006 17:39:05 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBJ0d5iU082617; Mon, 18 Dec 2006 17:39:05 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBJ0d3Jk082604; Mon, 18 Dec 2006 17:39:04 -0700 (MST) (envelope-from vidyan@qualcomm.com) Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kBJ0d3VT029245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 Dec 2006 16:39:03 -0800 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kBJ0d2jd015795; Mon, 18 Dec 2006 16:39:02 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 16:39:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: The ietf-ipsec-failover mailing list is now active Date: Mon, 18 Dec 2006 16:38:57 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The ietf-ipsec-failover mailing list is now active Thread-Index: Acci3W7f4xk2pA8kRtK4GWjKeQEZPgAKHbpQ From: "Narayanan, Vidya" To: "Paul Hoffman" , X-OriginalArrivalTime: 19 Dec 2006 00:39:02.0443 (UTC) FILETIME=[1485AFB0:01C72306] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kBJ0d4Jk082605 Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks, Paul. I will send out the revised PS shortly. Once we submit that, I will send a notice to the IPsec ex-WG ML, with a pointer to the PS draft, so that people will have some background. Regards, Vidya > -----Original Message----- > From: owner-ietf-ipsec-failover@mail.vpnc.org > [mailto:owner-ietf-ipsec-failover@mail.vpnc.org] On Behalf Of > Paul Hoffman > Sent: Monday, December 18, 2006 11:34 AM > To: ietf-ipsec-failover@vpnc.org > Subject: The ietf-ipsec-failover mailing list is now active > > > ...although there are only a few people on the list, and does > not include everyone who was at the dinner in San Diego. > People here need to think about when to start producing > Internet Drafts, and whether it would be useful or not to > tell the main IPsec ex-WG mailing list about this one sooner or later. > > --Paul Hoffman, Director > --VPN Consortium > > From owner-ietf-ipsec-failover Mon Dec 18 17:49:02 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBJ0n2Cp083426; Mon, 18 Dec 2006 17:49:02 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBJ0n2V3083425; Mon, 18 Dec 2006 17:49:02 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBJ0n0uL083411; Mon, 18 Dec 2006 17:49:01 -0700 (MST) (envelope-from vidyan@qualcomm.com) Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kBJ0m7wS028337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 Dec 2006 16:48:08 -0800 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kBJ0m5Ug019397; Mon, 18 Dec 2006 16:48:06 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 16:48:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C72307.57B26105" Subject: Revised PS Draft (RE: IPsec Failover and Redundancy - Problem Statement and Goals) Date: Mon, 18 Dec 2006 16:47:58 -0800 Message-ID: In-Reply-To: <458085D6.8020201@nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revised PS Draft (RE: IPsec Failover and Redundancy - Problem Statement and Goals) Thread-Index: AccfIwcjyjAXYb5rS1KHkgxLFvtx3wD4xWHg From: "Narayanan, Vidya" To: "Marcus Leech" , "Michael Richardson" Cc: "Paul Hoffman" , , "Yaron Sheffer" , , , , , , "Dondeti, Lakshminath" , "Pasi Eronen" , X-OriginalArrivalTime: 19 Dec 2006 00:48:05.0812 (UTC) FILETIME=[58653740:01C72307] Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C72307.57B26105 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I have attached a revised I-D based on the comments received so far. I will plan on submitting this by the end of this week. If you find something that you think must be revised prior to a 00 submission, please do send me your comments by Thursday morning (say, US PST 12 noon). Hopefully, everyone read the first version I sent out - the changes here are only a few. Minor comments/nits can always be revised in an 01 version - so, it is not a problem if you don't do a detailed review at this point. If I don't hear from you by Thursday, I will assume that you are okay with submitting this document.=20 Also, I have included everyone's individual email addresses here, but, I will switch to just using the ietf-ipsec-failover mailing list that Paul just created soon - so, please subscribe yourselves to the list, if you haven't done so already.=20 Thanks in advance for the quick turnaround.=20 Regards, Vidya ------_=_NextPart_001_01C72307.57B26105 Content-Type: text/plain; name="draft-vidya-ipsec-failover-ps-00-02.txt" Content-Transfer-Encoding: base64 Content-Description: draft-vidya-ipsec-failover-ps-00-02.txt Content-Disposition: attachment; filename="draft-vidya-ipsec-failover-ps-00-02.txt" CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFYuIE5hcmF5YW5hbiwgRWQuCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBRdWFsY29tbSwgSW5jLgpJbnRlbmRlZCBzdGF0dXM6IFN0YW5k YXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgRGVjZW1iZXIgMTgsIDIwMDYKRXhwaXJl czogSnVuZSAyMSwgMjAwNwoKCiAgSVBzZWMgR2F0ZXdheSBGYWlsb3ZlciBhbmQgUmVkdW5kYW5j eSAtIFByb2JsZW0gU3RhdGVtZW50IGFuZCBHb2FscwogICAgICAgICAgICAgIGRyYWZ0LXZpZHlh LWlwc2VjLWZhaWxvdmVyLXJlZHVuZGFuY3ktcHMtMDAKClN0YXR1cyBvZiB0aGlzIE1lbW8KCiAg IEJ5IHN1Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVwcmVzZW50 cyB0aGF0IGFueQogICBhcHBsaWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdo aWNoIGhlIG9yIHNoZSBpcyBhd2FyZQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQs IGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXMKICAgYXdhcmUgd2lsbCBiZSBkaXNj bG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDYgb2YgQkNQIDc5LgoKICAgSW50ZXJu ZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJp bmcKICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vw cy4gIE5vdGUgdGhhdAogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5n IGRvY3VtZW50cyBhcyBJbnRlcm5ldC0KICAgRHJhZnRzLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFy ZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFu ZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVu dHMgYXQgYW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1E cmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFu IGFzICJ3b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQt RHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlk LWFic3RyYWN0cy50eHQuCgogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGly ZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93 Lmh0bWwuCgogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEp1bmUgMjEsIDIw MDcuCgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2Np ZXR5ICgyMDA2KS4KCkFic3RyYWN0CgogICBSZWNvdmVyaW5nIGZyb20gZmFpbHVyZSBvZiBJUHNl YyBnYXRld2F5cyBvciBzZXJ2ZXJzIG1haW50YWluaW5nCiAgIGxhcmdlIG51bWJlcnMgb2YgU0Fz IG1heSB0YWtlIHNldmVyYWwgbWludXRlcywgaWYgdGhleSBuZWVkIHRvIHJlLQogICBlc3RhYmxp c2ggdGhlIElQc2VjIFNBcyBieSByZS1ydW5uaW5nIHRoZSBrZXkgbWFuYWdlbWVudCBwcm90b2Nv bCwKICAgSUtFdjIuICBBIHNpbWlsYXIgcHJvYmxlbSBhcmlzZXMgaW4gdGhlIGV2ZW50IG9mIGEg bmV0d29yayBvdXRhZ2UKICAgcmVzdWx0aW5nIGluIHRoZSBmYWlsdXJlIG9mIHNldmVyYWwgZ2F0 ZXdheXMgYW5kIHNlcnZlcnMuICBUaGUKICAgbGF0ZW5jeSBpbnZvbHZlZCBpbiB0aGlzIGFwcHJv YWNoIGlzIHNpZ25pZmljYW50LCBsZWFkaW5nIHRvIGEgbmVlZAogICBmb3IgYSBmYXN0ZXIgYW5k IHlldCBzZWN1cmUgZmFpbG92ZXIgc29sdXRpb24uICBUaGlzIGRvY3VtZW50CiAgIGRlc2NyaWJl cyB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgYW5kIHRoZSBnb2FscyBmb3IgYW4gSVBzZWMvSUtFdjIK CgoKTmFyYXlhbmFuICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bmUgMjEsIDIwMDcgICAgICAg ICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIElQc2VjIEZhaWxvdmVy L1JlZHVuZGFuY3kgUFMgICAgICAgICBEZWNlbWJlciAyMDA2CgoKICAgZ2F0ZXdheSBmYWlsb3Zl ci9yZWR1bmRhbmN5IHNvbHV0aW9uLgoKClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgQ29udHJp YnV0b3JzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDMKICAgMi4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAzCiAgIDMuICBUZXJtaW5vbG9neSAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNAogICA0LiAgQXBwbGljYWJpbGl0eSBh bmQgUHJvYmxlbSBTdGF0ZW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQKICAgNS4g IElQc2VjIEZhaWxvdmVyIFJlZHVuZGFuY3kgU29sdXRpb24gR29hbHMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiA1CiAgIDYuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNwogICA3LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDgKICAgOC4gIEFja25vd2xl ZGdtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA4 CiAgIDkuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gOAogICBBdXRob3IncyBBZGRyZXNzICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDgKICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5 IGFuZCBDb3B5cmlnaHQgU3RhdGVtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiA5CgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKTmFyYXlhbmFuICAgICAgICAgICAgICAgICBFeHBp cmVzIEp1bmUgMjEsIDIwMDcgICAgICAgICAgICAgICAgIFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgIElQc2VjIEZhaWxvdmVyL1JlZHVuZGFuY3kgUFMgICAgICAgICBEZWNlbWJlciAy MDA2CgoKMS4gIENvbnRyaWJ1dG9ycwoKICAgVGhpcyBkb2N1bWVudCByZWZsZWN0cyBjb250cmli dXRpb25zIGZyb20gYW5kIGFjdGl2ZSBkaXNjdXNzaW9ucwogICBhbW9uZyB0aGUgZm9sbG93aW5n IGluZGl2aWR1YWxzIChpbiBhbHBoYWJldGljYWwgb3JkZXIpOgoKICAgICAgTGFrc2htaW5hdGgg RG9uZGV0aSAobGRvbmRldGlAcXVhbGNvbW0uY29tKQoKICAgICAgUGF1bCBIb2ZmbWFuIChwYXVs LmhvZmZtYW5AdnBuYy5vcmcpCgogICAgICBUZXJvIEtpdmluZW4gKGtpdmluZW5AaWtpLmZpKQoK ICAgICAgR3JlZ29yeSBMZWJvdml0eiAoZ3JlZ29yeS5pZXRmQGdtYWlsLmNvbSkKCiAgICAgIE1h cmN1cyBMZWVjaCAobWxlZWNoQG5vcnRlbC5jb20pCgogICAgICBDaGVyeWwgTWFkc29uIChjbWFk c29uQGNpc2NvLmNvbSkKCiAgICAgIE1pY2hhZWwgUmljaGFyZHNvbiAobWNyQHNhbmRlbG1hbi5v dHRhd2Eub24uY2EpCgogICAgICBTaGVlbGEgUm93bGVzIChzcm93bGVzQGNpc2NvLmNvbSkKCiAg ICAgIFlhcm9uIFNoZWZmZXIgKHlhcm9uZkBjaGVja3BvaW50LmNvbSkKCiAgICAgIE1hcmN1cyBT dGVuYmVyZyAobXN0ZW5iZXJAY2lzY28uY29tKQoKICAgICAgQnJpYW4gV2VpcyAoYmV3QGNpc2Nv LmNvbSkKCgoyLiAgSW50cm9kdWN0aW9uCgogICBUaGUgSUtFdjIgcHJvdG9jb2wsIHdoaWxlIG1v cmUgZWZmaWNpZW50IGFuZCBpbnZvbHZlcyBmZXdlciByb3VuZAogICB0cmlwcyBjb21wYXJlZCB0 byBpdHMgcHJlZGVjZXNzb3IgaXMgcXVpdGUgY29tcHV0YXRpb25hbGx5IGludGVuc2l2ZSwKICAg ZXNwZWNpYWxseSB3aGVuIGVudGl0eSBhdXRoZW50aWNhdGlvbiBpcyBieSB3YXkgb2YgcHVibGlj LWtleSBiYXNlZAogICBjZXJ0aWZpY2F0ZXMuICBJS0V2MiBhbHNvIG5lZWRzIDItMyByb3VuZHRy aXBzIHdoZW4gdXNpbmcgUFNLcyBvcgogICBwdWJsaWMga2V5cyBmb3IgYXV0aGVudGljYXRpb24g YW5kIDQgb3IgbW9yZSByb3VuZHRyaXBzIHdoZW4gRUFQIGlzCiAgIHVzZWQgZm9yIGNsaWVudCBh dXRoZW50aWNhdGlvbi4gIFRodXMsIHRoZSBwcm9jZXNzIG9mIHNldHRpbmcgdXAKICAgSVBzZWMg U0FzIGlzIGFuIGV4cGVuc2l2ZSBwcm9jZXNzLCBpbiB0ZXJtcyBvZiB0aGUgbnVtYmVyIG9mIG1l c3NhZ2VzCiAgIGV4Y2hhbmdlZCBiZXR3ZWVuIHRoZSBpbml0aWF0b3IgYW5kIHJlc3BvbmRlci4K CiAgIFdoZW4gYW4gSVBzZWMgZW50aXR5IGhhcyBhIGxhcmdlIG51bWJlciBvZiBTQXMgd2l0aCB2 YXJpb3VzIG90aGVyCiAgIGVuZHBvaW50cywgZXN0YWJsaXNoaW5nIGFsbCB0aGUgU0FzIGFnYWlu IHVwb24gYSBmYWlsdXJlIHJlY292ZXJ5CiAgIGNvbmRpdGlvbiB0YWtlcyBhIGxvbmcgdGltZS4g IEV4YW1wbGVzIG9mIGVudGl0aWVzIHRoYXQgbWFuYWdlIGEKICAgbGFyZ2UgbnVtYmVyIG9mIElQ c2VjIFNBcyBpbmNsdWRlIElQc2VjIHJlbW90ZSBhY2Nlc3MgZ2F0ZXdheXMsIGFuZAogICBhcHBs aWNhdGlvbiBzZXJ2ZXJzIHRoYXQgdXNlIElQc2VjIGZvciBwcm90ZWN0aW9uIG9mIHNpZ25hbGlu ZwogICB0cmFmZmljLiAgRm9yIGVmZmljaWVudCByZWNvdmVyeSBmcm9tIGdhdGV3YXkgb3Igc2Vy dmVyIGZhaWx1cmUsIGl0CiAgIG1pZ2h0IG1ha2Ugc2Vuc2UgdG8gYWxsb3cgdGhvc2UgZW50aXRp ZXMgdG8gbWFpbnRhaW4gY29waWVzIG9mIElQc2VjCiAgIGFuZCBJS0V2MiBzdGF0ZSAoU0FELCBT UEQsIGFuZCBhc3NvY2lhdGVkIHN0YXRlKSBvbiBvdGhlciBzZXJ2ZXJzCiAgIChmb3Igc3RhdGVm dWwgb3BlcmF0aW9uKSBvciBvbiB0aGUgY2xpZW50IGl0c2VsZiAoZm9yIHN0YXRlbGVzcwoKCgpO YXJheWFuYW4gICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVuZSAyMSwgMjAwNyAgICAgICAgICAg ICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgSVBzZWMgRmFpbG92ZXIvUmVk dW5kYW5jeSBQUyAgICAgICAgIERlY2VtYmVyIDIwMDYKCgogICBvcGVyYXRpb24pLiAgRWl0aGVy IHRoZSByZWNvdmVyZWQgSVBzZWMgZW50aXR5IG9yIG90aGVyIGVudGl0aWVzIGluCiAgIHRoZSBz ZXJ2ZXIgcG9vbCBtYXkgcmV0cmlldmUgdGhlIHN0b3JlZCBJUHNlYyBhbmQgSUtFdjIgc3RhdGUg Zm9yCiAgIGZhc3RlciByZWNvdmVyeS4gIFRoZXJlIGlzIGEgbmVlZCBmb3IgYW4gaW50ZXJvcGVy YWJsZSBtZWFucyBvZgogICBwZXJmb3JtaW5nIFNBIHVwbG9hZHMgYW5kIHJldHJpZXZhbCBzbyB0 aGF0IHN1Y2ggSVBzZWMgcmVkdW5kYW5jeSBjYW4KICAgYmUgaW1wbGVtZW50ZWQgaW4gYW4gaW50 ZXJvcGVyYWJsZSBmYXNoaW9uLgoKCjMuICBUZXJtaW5vbG9neQoKICAgVGhlIGtleSB3b3JkcyAi TVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAogICAi U0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05B TCIgaW4gdGhpcwogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVk IGluIFJGQyAyMTE5IFsxXS4KCiAgIFRoaXMgZG9jdW1lbnQgdXNlcyB0ZXJtaW5vbG9neSBkZWZp bmVkIGluIFsyXSwgWzNdLCBhbmQgWzRdLiAgSW4KICAgYWRkaXRpb24sIHRoaXMgZG9jdW1lbnQg dXNlcyB0aGUgZm9sbG93aW5nIHRlcm1zOgoKCgoKNC4gIEFwcGxpY2FiaWxpdHkgYW5kIFByb2Js ZW0gU3RhdGVtZW50CgogICBUaGVyZSBhcmUgYXQgbGVhc3QgdHdvIGNhc2VzIHdoZXJlIGZhc3Qg cmVjb3ZlcnkgZnJvbSBmYWlsdXJlIG9mIGFuCiAgIElQc2VjIGVudGl0eSBpcyBhcHBsaWNhYmxl LgoKICAgICAgSVBzZWMgR2F0ZXdheXMgLS0gVGhlIGZpcnN0IGNhc2UgaXMgdGhhdCBvZiBhbiBJ UHNlYyByZW1vdGUgYWNjZXNzCiAgICAgIGdhdGV3YXkgbWFuYWdpbmcgdHVubmVsIG1vZGUgU0Fz IHdpdGggY2xpZW50cy4gIFRoZSBnYXRld2F5IG1heSBiZQogICAgICBlbmZvcmNpbmcgYWNjZXNz IGNvbnRyb2wgdG8gYW4gZW50ZXJwcmlzZSBuZXR3b3JrOyB0aGlzIGlzIHRoZQogICAgICB0eXBp Y2FsIHJlbW90ZSBhY2Nlc3MgVlBOIHVzZSBjYXNlLiAgVGhlIGdhdGV3YXkgY291bGQgYWxzbyBi ZQogICAgICBlbmZvcmNpbmcgc2VydmljZSBwcm92aWRlciBuZXR3b3JrIGFjY2VzcyBjb250cm9s LiAgSW4gdGhhdCBjYXNlLAogICAgICBjbGllbnRzIHR5cGljYWxseSB1c2UgRUFQIG92ZXIgSUtF djIgdG8gZXN0YWJsaXNoIGFuIElQc2VjIHNlc3Npb24KICAgICAgd2l0aCBhIG5ldHdvcmsgYWNj ZXNzIGdhdGV3YXkuICBJbiBlaXRoZXIgSVBzZWMgR2F0ZXdheSB1c2UgY2FzZSwKICAgICAgdGhl IElQc2VjIHRyYWZmaWMgaXRzZWxmIGZsb3dzIGZyb20gdGhlIFZQTiBjbGllbnRzIG9yIEluaXRp YXRvcnMKICAgICAgdG8gdGhlIFZQTiBnYXRld2F5OyB0aGUgZ2F0ZXdheSBkZWNhcHN1bGF0ZXMg dGhlIElQc2VjIHBhY2tldHMgYW5kCiAgICAgIGZvcndhcmRzIHRoZSBjbGVhcnRleHQgcGFja2V0 cyBiYXNlZCBvbiBpbm5lciBJUCBoZWFkZXJzLiAgSW4gdGhlCiAgICAgIHJldmVyc2UgZGlyZWN0 aW9uLCB0aGUgVlBOIGdhdGV3YXkgdXNlcyB0aGUgc2VjdXJpdHkgcG9saWN5CiAgICAgIGRhdGFi YXNlIChTUEQpIHRvIGxvb2t1cCB0aGUgcmVsZXZhbnQgSVBzZWMsIGVuY2Fwc3VsYXRlcyB0aGUK ICAgICAgcGFja2V0cyBhbmQgc2VuZHMgdG8gdGhlIGFwcHJvcHJpYXRlIFZQTiBjbGllbnQuCgog ICAgICBJUHNlYyBTZXJ2ZXJzIC0tIFRoZSBzZWNvbmQgdXNlIGlzIHRoYXQgb2YgYW4gSVBzZWMg ZW50aXR5IGFjdGluZwogICAgICBhcyBhIHNlcnZlciBmb3IgYW4gYXBwbGljYXRpb24gc3VjaCBh cyBNb2JpbGUgSVAuICBJbiB0aGVzZSBjYXNlcywKICAgICAgTW9iaWxlIElQIG1lc3NhZ2VzIGFy ZSBwcm90ZWN0ZWQgdXNpbmcgSVBzZWMuICBFYWNoIE1vYmlsZSBJUCBIb21lCiAgICAgIEFnZW50 IChIQSkgbWFpbnRhaW5zIGEgbGFyZ2UgbnVtYmVyIG9mIHRyYW5zcG9ydCBvciB0dW5uZWwgbW9k ZQogICAgICBJUHNlYyBzZXNzaW9ucyB3aXRoIHRoZWlyIHJlc3BlY3RpdmUgY2xpZW50cy4gIElu IHRoaXMgY2FzZSwgSVBzZWMKICAgICAgcHJvdGVjdGVkIHNpZ25hbGluZyBtZXNzYWdlcyBhcmUg c2VudCBlbmQtdG8tZW5kLCBiZXR3ZWVuIE1vYmlsZQogICAgICBJUCBjbGllbnQgYW5kIEhBLCBy ZXNwZWN0aXZlbHkuCgogICBJbiB0aGUgc2VjdXJpdHkgZ2F0ZXdheSBtb2RlLCB3aGlsZSB0aGVy ZSBtYXkgYmUgbXVsdGlwbGUgc2VjdXJpdHkKICAgZ2F0ZXdheXMgc2VydmluZyBhIG51bWJlciBv ZiByZW1vdGUgZW5kcG9pbnRzLCBhIGdpdmVuIHJlbW90ZQoKCgpOYXJheWFuYW4gICAgICAgICAg ICAgICAgIEV4cGlyZXMgSnVuZSAyMSwgMjAwNyAgICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgSVBzZWMgRmFpbG92ZXIvUmVkdW5kYW5jeSBQUyAgICAgICAg IERlY2VtYmVyIDIwMDYKCgogICBlbmRwb2ludCBpcyB0eXBpY2FsbHkgc2VydmVkIGJ5IG9uZSBz ZWN1cml0eSBnYXRld2F5LiAgRm9yIGluc3RhbmNlLAogICBhbiBJUHNlYyBWUE4gY2xpZW50IHR5 cGljYWxseSBtYWludGFpbnMgb25lIG9yIG1vcmUgU0FzIGZvciByZW1vdGUKICAgYWNjZXNzIHdp dGggb25lIFZQTiBnYXRld2F5LiAgSG93ZXZlciwgd2hlbiB0aGUgc2VydmluZyBnYXRld2F5CiAg IGZhaWxzLCBpdCBpcyBkZXNpcmFibGUgZm9yIG9uZSBvZiB0aGUgb3RoZXIgZ2F0ZXdheXMgdG8g c2VhbWxlc3NseQogICB0YWtlIG92ZXIgYW5kIHNlcnZlIHRoZSBjbGllbnRzIGFmZmVjdGVkIGJ5 IHRoZSBmYWlsdXJlLiAgSW4gc29tZQogICBkZXBsb3ltZW50cywgdGhlcmUgbWF5IGJlIGEgYmFj a3VwIGdhdGV3YXkgdGhhdCBjYW4gdGFrZSBvdmVyIGZvciB0aGUKICAgcHJpbWFyeSBpbiBjYXNl IG9mIGEgZmFpbHVyZS4gIFN1Y2ggZ2F0ZXdheXMgbWF5IGJlIHJ1bm5pbmcgYSBWUlJQLQogICBs aWtlIHByb3RvY29sIHRvIGFjdHVhbGx5IHNoYXJlIHRoZSBnYXRld2F5IElQIGFkZHJlc3MgYXMg a25vd24gdG8KICAgdGhlIGNsaWVudHMuICBJbiBvdGhlciBkZXBsb3ltZW50cywgYSBjbHVzdGVy IG9mIGdhdGV3YXlzIG1heSBsb2FkCiAgIGJhbGFuY2UgdG8gc2VydmUgYSBudW1iZXIgb2YgY2xp ZW50cy4gIEluIHN1Y2ggYSBjYXNlLCBvbmUgb3IgbW9yZSBvZgogICB0aGUgZ2F0ZXdheXMgaW4g dGhlIGNsdXN0ZXIgbWF5IHRha2Ugb3ZlciBjbGllbnRzIGFzc29jaWF0ZWQgd2l0aAogICBhbm90 aGVyIGdhdGV3YXkgaW4gdGhlIGNsdXN0ZXIgaW4gdGhlIGV2ZW50IG9mIGEgZmFpbHVyZS4KCiAg IFdoZW4gSVBzZWMgaXMgdXNlZCBmb3IgcHJvdGVjdGlvbiBvZiBzaWduYWxpbmcgYmV0d2VlbiBh biBhcHBsaWNhdGlvbgogICBjbGllbnQgYW5kIHNlcnZlciwgc2VydmVyIHJlZHVuZGFuY3kgaXMg b2Z0ZW4gYW4gaW1wb3J0YW50CiAgIGNvbnNpZGVyYXRpb24uICBBcyBpbiB0aGUgZ2F0ZXdheSBt b2RlbCwgaXQgaXMgbmVjZXNzYXJ5IGZvciBhbm90aGVyCiAgIHNlcnZlciB0byBiZSBhYmxlIHRv IHNlYW1sZXNzbHkgdGFrZSBvdmVyIGNsaWVudHMgYmVpbmcgc2VydmVkIGJ5IGEKICAgZmFpbGVk IHNlcnZlci4KCiAgIEluIGFkZGl0aW9uIHRvIHNlcnZlciBmYWlsdXJlcywgbWFzc2l2ZSBuZXR3 b3JrIGZhaWx1cmVzIG9mIGEgc2hvcnQKICAgZHVyYXRpb24gKG1pbnV0ZXMpLCBmb2xsb3dlZCBi eSBuZXR3b3JrIHJlY292ZXJ5IGFyZSBhbHNvIGEgY29uY2Vybi4KICAgVGhlIG5ldHdvcmsgZmFp bHVyZSByZXN1bHRzIGluIGFsbCBjbGllbnRzIGJlaW5nIGRpc2Nvbm5lY3RlZCBmaXJzdAogICAo ZS5nLiBiZWNhdXNlIG9mIGRlYWQtcGVlciBkZXRlY3Rpb24pLCBhbmQgdGhlbiBzaW11bHRhbmVv dXNseQogICBhdHRlbXB0aW5nIHRvIHJlY29ubmVjdC4gIFRoaXMgY2FuIGJlIGNsYXNzaWZpZWQg YXMgYSBzdWJzZXQgb2YgdGhlCiAgIGdhdGV3YXkgZmFpbHVyZSBjYXNlIGZvciB0aGUgcHVycG9z ZSBvZiB0aGlzIGVmZm9ydC4KCiAgIEluIGFsbCB0aGVzZSBjYXNlcyBvdXRsaW5lZCBhYm92ZSwg aXQgaXMgZmVhc2libGUgdG8gcGVyZm9ybSBzZWN1cmUKICAgSVBzZWMgYW5kIElLRXYyIHN0YXRl IHRyYW5zZmVyIGFjcm9zcyBlbmRwb2ludHMgdG8gcHJvdmlkZSBzbW9vdGhlcgogICBmYWlsdXJl IHJlY292ZXJ5LiAgVG9kYXksIHN1Y2ggcmVkdW5kYW5jeSBvcGVyYXRpb25zIGFyZSBwZXJmb3Jt ZWQgaW4KICAgYSB2ZW5kb3Igc3BlY2lmaWMgbWFubmVyIGFuZCBhcmUgbm90IGludGVyb3BlcmFi bGUuICBBbHNvLCBsYWNrIG9mCiAgIGNsaWVudCBpbnZvbHZlbWVudCBpbXBsaWVzIGEgZmFpbG92 ZXIgbW9kZSB0aGF0IGlzIHRyYW5zcGFyZW50IHRvIHRoZQogICBjbGllbnQuICBIb3dldmVyLCBp biB0aGUgYWJvdmUgY2FzZXMsIHRoZSBmYWlsb3ZlciBjYW5ub3QgYWx3YXlzIGJlCiAgIHRyYW5z cGFyZW50IHRvIHRoZSBjbGllbnQgYW5kIGhlbmNlLCBhbiBpbnRlcm9wZXJhYmxlIHByb3RvY29s CiAgIGJlY29tZXMgdmVyeSBpbXBvcnRhbnQuCgoKNS4gIElQc2VjIEZhaWxvdmVyIFJlZHVuZGFu Y3kgU29sdXRpb24gR29hbHMKCiAgIFRoZSBmb2xsb3dpbmcgYXJlIGdvYWxzIGZvciB0aGUgSVBz ZWMvSUtFdjIgRmFpbG92ZXIgUmVkdW5kYW5jeQogICBzb2x1dGlvbi4gIE5vdGUgdGhhdCB0aGUg Z29hbHMgb2YgdGhpcyBlZmZvcnQgYXJlIHN0cmljdGx5IGZhaWxvdmVyCiAgIGFuZCBvdGhlciBm ZWF0dXJlcyBzdWNoIGFzIGxvYWQgYmFsYW5jaW5nLCBldGMuIGFyZSBvdXRzaWRlIHRoZSBzY29w ZQogICBvZiB0aGlzIGVmZm9ydC4KCiAgIG8gIERpc3RyaWJ1dGVkIEZhaWxvdmVyIE1lY2hhbmlz bTogR2F0ZXdheXMgbWF5IGJlIGxvY2F0ZWQgYXQKICAgICAgZGlmZmVyZW50IHNpdGVzIGFuZCBt YXkgbm90IHNoYXJlIHRoZSBzYW1lIElQIGFkZHJlc3Mgb3IgaGF2ZSB0aGUKICAgICAgc2FtZSB2 aWV3IG9mIHRoZSBuZXR3b3JrLiAgRm9yIGluc3RhbmNlLCB0aGUgdmFyaW91cyBkaXN0cmlidXRl ZAogICAgICBnYXRld2F5cyBtYXkgYmUgY29ubmVjdGVkIHRvIGRpZmZlcmVudCBiYWNrZW5kIGVs ZW1lbnRzIHN1Y2ggYXMKICAgICAgRUFQIHNlcnZlcnMsIERIQ1Agc2VydmVycywgZXRjLiAgQSBm YWlsb3ZlciBtZWNoYW5pc20gbXVzdCBiZSBhYmxlCgoKCk5hcmF5YW5hbiAgICAgICAgICAgICAg ICAgRXhwaXJlcyBKdW5lIDIxLCAyMDA3ICAgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICBJUHNlYyBGYWlsb3Zlci9SZWR1bmRhbmN5IFBTICAgICAgICAgRGVj ZW1iZXIgMjAwNgoKCiAgICAgIHRvIGFsbG93IHN1Y2ggZGlzdHJpYnV0ZWQgZ2F0ZXdheXMgdG8g dGFrZSBvdmVyIHRoZSBjbGllbnRzCiAgICAgIGFzc29jaWF0ZWQgd2l0aCBhIGZhaWxlZCBnYXRl d2F5LiAgVGhlIGlkZWEgaGVyZSBpcyB0aGF0IHRoZXJlIGlzCiAgICAgIG5vIG5lZWQgZm9yIGEg ZnVsbHkgcmVkdW5kYW50IGdhdGV3YXkgdGhhdCBvbmx5IHN0YXJ0cyBmdW5jdGlvbmluZwogICAg ICBpbiB0aGUgZXZlbnQgb2YgYSBmYWlsdXJlLiAgSXQgaXMgbW9yZSBjb3N0LWVmZmVjdGl2ZSB0 byBhbGxvdwogICAgICBzdWNoIGZhaWxvdmVyIHRvIGRpc3RyaWJ1dGVkIGdhdGV3YXlzIHRoYXQg bWF5IGJlIGZ1bmN0aW9uYWwgb24KICAgICAgdGhlaXIgb3duLCBzZXJ2aW5nIG90aGVyIGNsaWVu dHMuICBUaGUgdGVtcG9yYXJ5IGluY3JlYXNlIGluIGxvYWQKICAgICAgb24gc29tZSBnYXRld2F5 cyBpbiB0aGUgc3lzdGVtIG1heSBiZSBhY2NlcHRhYmxlIHRvIG1hbnkKICAgICAgZGVwbG95bWVu dHMgaW4gdGhlIGV2ZW50IG9mIGEgZmFpbHVyZS4gIFN1Y2ggYSBtZWNoYW5pc20gYWNyb3NzCiAg ICAgIGRpc3RyaWJ1dGVkIGdhdGV3YXlzIG1heSBhbHNvIGJlIHVzZWQgZm9yIGNsaWVudCBoYW5k b2ZmIHRvIG90aGVyCiAgICAgIGdhdGV3YXlzIGR1ZSB0byBvdGhlciByZWFzb25zLCBlLmcuLCBs b2FkIGJhbGFuY2luZy4gIEdhdGV3YXlzCiAgICAgIGxvY2F0ZWQgb24gdGhlIHNhbWUgbGluayB3 aXRoIHRoZSBzYW1lIHZpZXcgb2YgdGhlIG5ldHdvcmsgbWF5IGJlCiAgICAgIHZpZXdlZCBhcyBh IHN1YnNldC4KCiAgIG8gIENsaWVudCBJbnZvbHZlbWVudDogR2l2ZW4gdGhhdCB0aGUgZ2F0ZXdh eXMgbWF5IGJlIGRpc3RyaWJ1dGVkLAogICAgICB0aGUgZmFpbG92ZXIgaXMgbm90IGludGVuZGVk IHRvIGJlIHRyYW5zcGFyZW50IHRvIHRoZSBjbGllbnQuICBUaGUKICAgICAgZ29hbCBpcyB0byBh bGxvdyB0aGUgY2xpZW50IHRvIGluaXRpYXRlIHRoZSBzd2l0Y2ggdG8gYSBkaWZmZXJlbnQKICAg ICAgZ2F0ZXdheS4KCiAgIG8gIExvdyBMYXRlbmN5IGZhaWxvdmVyOiBPbmUgb2YgdGhlIG1ham9y IGdvYWxzIGlzIHRvIGFsbG93IGEgbG93CiAgICAgIGxhdGVuY3kgZmFpbG92ZXIsIHdpdGhvdXQg aGF2aW5nIHRvIHJlLWVzdGFibGlzaCBhbGwgdGhlIElLRXYyIGFuZAogICAgICBJUHNlYyBzdGF0 ZSBhbGwgb3ZlciBhZ2Fpbi4gIFRoZSBib3R0bGVuZWNrIGhlcmUgaXMgdGhlIG5ldyBJUHNlYwog ICAgICBnYXRld2F5IHRyeWluZyB0byBoYW5kbGUgYSBmbG9vZCBvZiBJS0V2MiBleGNoYW5nZXMg dXBvbiBhCiAgICAgIGZhaWxvdmVyLiAgRnVydGhlciwgZm9yIGFwcGxpY2F0aW9ucyBzdWNoIGFz IE1vYmlsZSBJUHY2IHRoYXQgdXNlCiAgICAgIElLRXYyL0lQc2VjIGZvciBzZWN1cmluZyB0aGUg c2lnbmFsaW5nLCByZS1lc3RhYmxpc2htZW50IG9mIElLRXYyCiAgICAgIG9mdGVuIGFkZHMgdW5h Y2NlcHRhYmxlIGxhdGVuY2llcy4gIElkZWFsbHksIGEgbWVjaGFuaXNtIHRoYXQgZG9lcwogICAg ICBub3QgbmVlZCBhbnkgbmV3IG1lc3NhZ2VzIGlzIGRlc2lyZWQuICBJbiBnZW5lcmFsLCB0aGUg Z29hbCBpcyB0bwogICAgICBoYXZlIHNpZ25pZmljYW50bHkgbG93ZXIgbGF0ZW5jeSBhbmQgdG8g aW5jdXIgYSBsb3dlcgogICAgICBjb21wdXRhdGlvbmFsIG92ZXJoZWFkIHRoYW4gYSByZWd1bGFy IElLRXYyIGV4Y2hhbmdlLiAgSW4gY2FzZXMKICAgICAgd2hlcmUgRUFQIGlzIHVzZWQgZm9yIGNs aWVudCBhdXRoZW50aWNhdGlvbiwgdGhlIGZhaWxvdmVyIG11c3Qgbm90CiAgICAgIHJlcXVpcmUg RUFQIGF1dGhlbnRpY2F0aW9uLCB0byBhdm9pZCBBQUEgb3ZlcmxvYWRpbmcgYW5kIHBvc3NpYmxl CiAgICAgIHVzZXIgaW50ZXJhY3Rpb24uCgogICBvICBBcHBsaWNhdGlvbiBVc2FnZSBvZiBJUHNl YzogV2hlbiBJUHNlYyBpcyB1c2VkIHRvIHByb3RlY3Qgb3RoZXIKICAgICAgcHJvdG9jb2xzLCB0 aGUgZXh0ZW50IG9mIGZhaWxvdmVyIGludGVyb3BlcmFiaWxpdHkgdGhhdCBjYW4gYmUKICAgICAg ZXhwZWN0ZWQgYnkgc3VjaCBwcm90b2NvbHMgZ3JlYXRseSBoaW5nZSBvbiB0aGUgaW50ZXJvcGVy YWJpbGl0eQogICAgICBvZiBJUHNlYyBmYWlsb3ZlciBtZWNoYW5pc21zLiAgRm9yIGUuZy4sIE1v YmlsZSBJUCBIb21lIEFnZW50CiAgICAgIHJlbGlhYmlsaXR5IG1lY2hhbmlzbXMgYXJlIGludGVu ZGVkIHRvIGJlIHN0YW5kYXJkaXplZCBmb3IKICAgICAgaW50ZXJvcGVyYWJpbGl0eS4gIEhvd2V2 ZXIsIGl0IGlzIGluY29tcGxldGUgd2l0aG91dCBJUHNlYwogICAgICBmYWlsb3Zlci4gIFNvLCBp dCBpcyBpbXBvcnRhbnQgdG8gYWxsb3cgYXBwbGljYXRpb25zIHRoYXQgdXNlCiAgICAgIElQc2Vj IHRvIHRha2UgYWR2YW50YWdlIG9mIHRoZSBJUHNlYyBmYWlsb3ZlciBtZWNoYW5pc20uICBJdCBp cwogICAgICBub3QgZXhwZWN0ZWQgdGhhdCB0aGUgSVBzZWMgZmFpbG92ZXIgc29sdXRpb24gd2ls bCBhZGRyZXNzIHRoaXMsCiAgICAgIGJ1dCBhIGd1aWRhbmNlIG5lZWRzIHRvIGJlIHByb3ZpZGVk IHRvIGFsbG93IGFwcGxpY2F0aW9uCiAgICAgIHNwZWNpZmljYXRpb25zIHRvIHNwZWNpZnkgdGhl IGFwcHJvcHJpYXRlIGludGVyZmFjZS9pbnRlcmFjdGlvbgogICAgICBuZWVkZWQgKGUuZy4sIGlm IHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIGFwcGxpY2F0aW9uIHN0YXRlIGFuZAogICAgICBJUHNl YyBzdGF0ZSBpcyBuZWVkZWQpLgoKICAgbyAgSW50ZXJvcGVyYWJpbGl0eTogQ2xpZW50LWdhdGV3 YXkgYW5kIGdhdGV3YXktZ2F0ZXdheQogICAgICBpbnRlcm9wZXJhYmlsaXR5IGlzIHJlcXVpcmVk LiAgVGhpcyBmb2xsb3dzIGZyb20gdGhlIGRpc2N1c3Npb24gb24KCgoKTmFyYXlhbmFuICAgICAg ICAgICAgICAgICBFeHBpcmVzIEp1bmUgMjEsIDIwMDcgICAgICAgICAgICAgICAgIFtQYWdlIDZd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgIElQc2VjIEZhaWxvdmVyL1JlZHVuZGFuY3kgUFMgICAg ICAgICBEZWNlbWJlciAyMDA2CgoKICAgICAgdGhlIG90aGVyIGdvYWxzIHN0YXRlZCBhYm92ZS4K CiAgIG8gIFN0YXRlbGVzcyBHYXRld2F5IE9wZXJhdGlvbjogVGhlIElQc2VjIGZhaWxvdmVyIG1l Y2hhbmlzbSBtdXN0CiAgICAgIHNwZWNpZnkgYSBtb2RlIG9mIG9wZXJhdGlvbiB0aGF0IHdpbGwg YWxsb3cgdGhlIGJhY2t1cCBnYXRld2F5cyB0bwogICAgICByZW1haW4gc3RhdGVsZXNzIHVudGls IGEgZmFpbG92ZXIgb2NjdXJzIG9yIGR1cmluZyBhIHRlbXBvcmFyeQogICAgICBzZXJ2aWNlIGlu dGVycnVwdGlvbi4gIFRoaXMgd2lsbCBhbGxvdyBmb3IgYmV0dGVyIHNjYWxhYmlsaXR5IG9mCiAg ICAgIHRoZSBzb2x1dGlvbiwgc2luY2UgYSBnaXZlbiBnYXRld2F5IG9ubHkgbmVlZHMgdG8gc3Rv cmUgc3RhdGUgZm9yCiAgICAgIGNsaWVudHMgdGhhdCBhcmUgYmVpbmcgc2VydmVkIGJ5IGl0LgoK ICAgbyAgU3VwcG9ydCBmb3IgSVBzZWMgdHJhbnNwb3J0IGFuZCB0dW5uZWwgbW9kZXM6IEFzIG5v dGVkIGluIHRoZQogICAgICBhcHBsaWNhYmlsaXR5IHNlY3Rpb24gb2YgdGhpcyBkb2N1bWVudCwg dGhlIElQc2VjIGluZnJhc3RydWN0dXJlCiAgICAgIGVuZHBvaW50IG1heSBlaXRoZXIgYmUgYW4g SVBzZWMgVlBOIGdhdGV3YXkgZW1wbG95aW5nIHR1bm5lbCBtb2RlCiAgICAgIFNBcyB3aXRoIHRo ZSBjbGllbnQgb3IgYW4gYXBwbGljYXRpb24gc2VydmVyIHRoYXQgdXNlcyBJUHNlYwogICAgICB0 cmFuc3BvcnQgb3IgdHVubmVsIG1vZGUgdG8gcHJvdGVjdCBzaWduYWxpbmcgZXhjaGFuZ2VzIHdp dGggdGhlCiAgICAgIGNsaWVudC4gIEhlbmNlLCBhIHNvbHV0aW9uIGRldmVsb3BlZCBmb3IgZmFp bG92ZXIgbXVzdCBzdXBwb3J0CiAgICAgIGZhaWxvdmVyIG9mIGJvdGggdHJhbnNwb3J0IGFuZCB0 dW5uZWwgbW9kZSBTQXMuCgoKNi4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCgogICBUaGlzIGRv Y3VtZW50IHByb3ZpZGVzIHRoZSBwcm9ibGVtIGRlc2NyaXB0aW9uIGFuZCBnb2FscyBmb3IgYW4g SVBzZWMKICAgZmFpbG92ZXIgc29sdXRpb24uICBUaGUgc29sdXRpb24gbXVzdCBlbnN1cmUgc2Vj dXJlIG9wZXJhdGlvbiBhbmQKICAgdGhlcmUgYXJlIHNldmVyYWwgaW1wb3J0YW50IHBvaW50cyB0 byBjb25zaWRlciBmb3IgdGhhdC4gIFdlCiAgIGhpZ2hsaWdodCBhIGZldyBvZiB0aGUgaW1wb3J0 YW50IG9uZXMgYmVsb3cgOgoKICAgbyAgRmlyc3QsIGFueSBTQSBzdG9yYWdlIGFuZCByZXRyaWV2 YWwgbWVjaGFuaXNtcyBzcGVjaWZpZWQgYmV0d2VlbgogICAgICB0aGUgYmFja2VuZCBlbnRpdGll cyBtdXN0IGJlIHByb3RlY3RlZCB3aXRoIGEgc2VjdXJlIGNoYW5uZWwgdGhhdAogICAgICBoYXMg dGhlIGZvbGxvd2luZyBwcm9wZXJ0aWVzOiBjb25maWRlbnRpYWxpdHksIGludGVncml0eQogICAg ICBwcm90ZWN0aW9uLCBhbmQgcmVwbGF5IHByb3RlY3Rpb24uCgogICBvICBTb2x1dGlvbnMgZm9y IGEgY2xpZW50LXNlcnZlciBtb2RlbCwgd2hlcmUgdGhlIGNsaWVudCBhbHdheXMKICAgICAgaW5p dGlhdGVzIHRoZSBzZWN1cmUgY29tbXVuaWNhdGlvbiBtYXkgYWxsb3cgdGhlIGNsaWVudCB0byBm aW5kCiAgICAgIHRoZSBuZXcgc2VydmVyIGFkZHJlc3MgdGhyb3VnaCBleHRlcm5hbCBtZWFucy4g IFN1YnNlcXVlbnRseSwgdGhlCiAgICAgIGNsaWVudCBtdXN0IGJlIGFibGUgdG8gdmVyaWZ5IHRo ZSBzZXJ2ZXIncyBhZGRyZXNzIGJ5IHZlcmlmeWluZwogICAgICB0aGUgcHJvb2Ygb2YgcG9zc2Vz c2lvbiBvZiB0aGUgSUtFdjIga2V5IG1hdGVyaWFsIGF0IHRoZSBuZXcKICAgICAgc2VydmVyLiAg VW50aWwgdGhlbiB0aGUgY2xpZW50IG11c3QgY29uc2lkZXIgdGhlIG5ldyBzZXJ2ZXIncwogICAg ICBhZGRyZXNzIGFzIGEgInByb3Zpc2lvbmFsIiBhZGRyZXNzIGFuZCBzcGVjaWZpY2FsbHkgaXQg bXVzdCBub3QKICAgICAgdXBkYXRlIHRoZSBJS0V2MiBzZXJ2ZXIgYWRkcmVzcyB1bnRpbCBhZnRl ciBzdWNoIHZlcmlmaWNhdGlvbgogICAgICBzdWNjZWVkcy4KCiAgIG8gIEFueSBzb2x1dGlvbiBt dXN0IGFkZXF1YXRlbHkgZGVzY3JpYmUgdGhlIGNvbnNlcXVlbmNlcyB0byByZXBsYXkKICAgICAg cHJvdGVjdGlvbiBhcyBhIHJlc3VsdCBvZiBJUHNlYyBmYWlsb3Zlci4gIEZvciByZXBsYXkgcHJv dGVjdGlvbiwKICAgICAgaXQgbWF5IGJlIGJlc3QgZm9yIHRoZSByZXBsYWNlbWVudCBzZXJ2ZXIg dG8gYXNzdW1lIHRoYXQgdGhlIElQc2VjCiAgICAgIFNBIHN0YXRlIGlzIG91dGRhdGVkIGFuZCBy ZWVzdGFibGlzaCB0aGUgSVBzZWMgU0EgdXNpbmcgYW4gSUtFdjIKICAgICAgQ1JFQVRFX0NISUxE X1NBIGV4Y2hhbmdlLiAgKFBlcmhhcHMgdGhpcyBjYW4gYmUgcmVsYXhlZCBhZnRlciBhCiAgICAg IG1vcmUgaW4tZGVwdGggYW5hbHlzaXMpLgoKCgoKCk5hcmF5YW5hbiAgICAgICAgICAgICAgICAg RXhwaXJlcyBKdW5lIDIxLCAyMDA3ICAgICAgICAgICAgICAgICBbUGFnZSA3XQoMCkludGVybmV0 LURyYWZ0ICAgICAgICBJUHNlYyBGYWlsb3Zlci9SZWR1bmRhbmN5IFBTICAgICAgICAgRGVjZW1i ZXIgMjAwNgoKCjcuICBJQU5BIENvbnNpZGVyYXRpb25zCgogICBObyBJQU5BIGFjdGlvbiBpcyBy ZXF1aXJlZCBmb3IgdGhpcyBkb2N1bWVudC4KCgo4LiAgQWNrbm93bGVkZ21lbnRzCgoKOS4gIE5v cm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbMV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1 c2UgaW4gUkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJlbWVudAogICAgICAgIExldmVscyIsIEJDUCAx NCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuCgogICBbMl0gIEtlbnQsIFMuIGFuZCBLLiBTZW8sICJT ZWN1cml0eSBBcmNoaXRlY3R1cmUgZm9yIHRoZSBJbnRlcm5ldAogICAgICAgIFByb3RvY29sIiwg UkZDIDQzMDEsIERlY2VtYmVyIDIwMDUuCgogICBbM10gIEthdWZtYW4sIEMuLCAiSW50ZXJuZXQg S2V5IEV4Y2hhbmdlIChJS0V2MikgUHJvdG9jb2wiLCBSRkMgNDMwNiwKICAgICAgICBEZWNlbWJl ciAyMDA1LgoKICAgWzRdICBFcm9uZW4sIFAuLCAiSUtFdjIgTW9iaWxpdHkgYW5kIE11bHRpaG9t aW5nIFByb3RvY29sIChNT0JJS0UpIiwKICAgICAgICBSRkMgNDU1NSwgSnVuZSAyMDA2LgoKCkF1 dGhvcidzIEFkZHJlc3MKCiAgIFZpZHlhIE5hcmF5YW5hbiAoZWRpdG9yKQogICBRdWFsY29tbSwg SW5jLgogICA1Nzc1IE1vcmVob3VzZSBEcgogICBTYW4gRGllZ28sIENBCiAgIFVTQQoKICAgUGhv bmU6ICsxIDg1OC04NDUtMjQ4MwogICBFbWFpbDogdmlkeWFuQHF1YWxjb21tLmNvbQoKCgoKCgoK CgoKCgoKCgoKCgpOYXJheWFuYW4gICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVuZSAyMSwgMjAw NyAgICAgICAgICAgICAgICAgW1BhZ2UgOF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgSVBzZWMg RmFpbG92ZXIvUmVkdW5kYW5jeSBQUyAgICAgICAgIERlY2VtYmVyIDIwMDYKCgpGdWxsIENvcHly aWdodCBTdGF0ZW1lbnQKCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIw MDYpLgoKICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIHRoZSByaWdodHMsIGxpY2Vuc2Vz IGFuZCByZXN0cmljdGlvbnMKICAgY29udGFpbmVkIGluIEJDUCA3OCwgYW5kIGV4Y2VwdCBhcyBz ZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMKICAgcmV0YWluIGFsbCB0aGVpciByaWdodHMu CgogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBh cmUgcHJvdmlkZWQgb24gYW4KICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBU SEUgT1JHQU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRTCiAgIE9SIElTIFNQT05TT1JFRCBCWSAo SUYgQU5ZKSwgVEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVAogICBFTkdJTkVF UklORyBUQVNLIEZPUkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJ RUQsCiAgIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhF IFVTRSBPRiBUSEUKICAgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBS SUdIVFMgT1IgQU5ZIElNUExJRUQKICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1Ig RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuCgoKSW50ZWxsZWN0dWFsIFByb3BlcnR5 CgogICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9y IHNjb3BlIG9mIGFueQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJp Z2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8KICAgcGVydGFpbiB0byB0aGUgaW1wbGVtZW50 YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbgogICB0aGlzIGRvY3Vt ZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMK ICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50 IHRoYXQgaXQgaGFzCiAgIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBh bnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbgogICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJl c3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlCiAgIGZvdW5kIGluIEJDUCA3 OCBhbmQgQkNQIDc5LgoKICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJ RVRGIFNlY3JldGFyaWF0IGFuZCBhbnkKICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBt YWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbgogICBhdHRlbXB0IG1hZGUgdG8gb2J0 YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YKICAgc3Vj aCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMKICAg c3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiBy ZXBvc2l0b3J5IGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLgoKICAgVGhlIElFVEYgaW52 aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQog ICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHBy b3ByaWV0YXJ5CiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJl IHJlcXVpcmVkIHRvIGltcGxlbWVudAogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3Mg dGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0CiAgIGlldGYtaXByQGlldGYub3JnLgoKCkFj a25vd2xlZGdtZW50CgogICBGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5jdGlvbiBpcyBw cm92aWRlZCBieSB0aGUgSUVURgogICBBZG1pbmlzdHJhdGl2ZSBTdXBwb3J0IEFjdGl2aXR5IChJ QVNBKS4KCgoKCgpOYXJheWFuYW4gICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVuZSAyMSwgMjAw NyAgICAgICAgICAgICAgICAgW1BhZ2UgOV0KDAoK ------_=_NextPart_001_01C72307.57B26105-- From owner-ietf-ipsec-failover Thu Dec 21 10:36:57 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBLHauTQ053058; Thu, 21 Dec 2006 10:36:56 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBLHau7t053057; Thu, 21 Dec 2006 10:36:56 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from cod.sandelman.ca (cod.sandelman.ca [192.139.46.42]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBLHasC4053032; Thu, 21 Dec 2006 10:36:55 -0700 (MST) (envelope-from mcr@sandelman.ottawa.on.ca) Received: from sandelman.ottawa.on.ca (unknown [206.47.204.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marajade.sandelman.ca.", Issuer "Michael Richardson" (verified OK)) by cod.sandelman.ca (Postfix) with ESMTP id 6B4D7123DF; Thu, 21 Dec 2006 12:36:52 -0500 (EST) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 3825A4E787; Thu, 21 Dec 2006 10:25:33 -0500 (EST) From: Michael Richardson To: "Narayanan, Vidya" cc: "Marcus Leech" , "Paul Hoffman" , kivinen@iki.fi, "Yaron Sheffer" , mstenber@cisco.com, cmadson@cisco.com, gregory.ietf@gmail.com, bew@cisco.com, srowles@cisco.com, "Dondeti, Lakshminath" , "Pasi Eronen" , ietf-ipsec-failover@vpnc.org Subject: Re: Revised PS Draft (RE: IPsec Failover and Redundancy - Problem Statement and Goals) In-Reply-To: Message from "Narayanan, Vidya" of "Mon, 18 Dec 2006 16:47:58 PST." References: X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 19) Date: Thu, 21 Dec 2006 10:25:33 -0500 Message-ID: <9026.1166714733@sandelman.ottawa.on.ca> Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 {Paul, you are welcome to repost this to the list, when it becomes active} Okay, finally reading the whole document. I am happy that you submit as -00 already. I much prefer to have a document revised in public, myself. First comment, section 2: There is a need for an interoperable means of performing SA uploads and retrieval so that such IPsec redundancy can be implemented in an interoperable fashion. I think that the statement may need a stronger statement. It might be good to say, "this has been done in a proprietary fashion by X, Y, and Z" (with reference to product documentation), but they do not interoperate. I think that we concluded that because the client will have to participate in the operation, that it has to be standard. section 4. "typical remote access VPN use case." I thought that there was the "remove access" use case, and the "VPN" use case, the latter being site-to-site. At least, based upon how our users ask questions, I think that a lot of people think of the two as being seperate cases. (They aren't of course) page 4 - first paragraph, maybe someone whose product currently does VRRP can provide a reference, and someone who has custom extensions or configuration in their client to let it pick among multiple IPs can provide a reference. My thoughts here is that it is good to motivate that the people with custom solutions want to do something. Ditto last paragraph, section 4. section 5, page 4: s,for the IPsec/IKEv2 Failover Redundancy, for a IKEv2 Failover/Redundancy, I think that this is inhierently IKEv2, and a problem statement must assume there might be zero or more solutions. Note that the goals of this effort are strictly failover and other features such as load balancing, etc. are outside the scope of this effort. I didn't think we had consensus about this statement. Do we? I usually prefer hot-failover solutions that look like load balancing, because in particular, it allows for n+1 redundancy rather than 2n. In particular your first point seems to disagree with the above statement: in the event of a failure. It is more cost-effective to allow such failover to distributed gateways that may be functional on their own, serving other clients. The temporary increase in load == o Client Involvement: Given that the gateways may be distributed, the failover is not intended to be transparent to the client. The goal is to allow the client to initiate the switch to a different gateway. I think that this is an important primary goal --- the client is in control. often adds unacceptable latencies. Ideally, a mechanism that does not need any new messages is desired. In general, the goal is to I'm unclear if you mean any new exchanges, or any new message types, or?? I think that the next sentence may be a strong enough goal: In general, the goal is to have significantly lower latency and to incur a lower computational overhead than a regular IKEv2 exchange. also: In cases where EAP is used for client authentication, the failover must not require EAP authentication, to avoid AAA overloading and possible user interaction. I think that you need to weaken this slightly. I think your goal is that in most cases, it SHOULD NOT require a new EAP authentication before a new IPsec SA is created. I think that it is fair that some systems/solutions may want to make the new IPsec SA short-lived, and do a new EAP, or some kind of EAP re-auth for cryptographic hygiene reasons, but to do so concurrently with the new traffic. There are also just some pathological failure cases that might be best handled by starting everything over. (My GSM phone does drop calls, just not daily. My PSTN phone often gets a "bad line" too...) o Application Usage of IPsec: When IPsec is used to protect other protocols, the extent of failover interoperability that can be I think my MIP ignorance is showing. Can you give us some references? o Stateless Gateway Operation: The IPsec failover mechanism must specify a mode of operation that will allow the backup gateways to remain stateless until a failover occurs or during a temporary service interruption. This will allow for better scalability of the solution, since a given gateway only needs to store state for clients that are being served by it. I strongly favour this. I guess you are leaving room for a stateful method as well. I think, it will be simpler to specify a single method. o Solutions for a client-server model, where the client always initiates the secure communication may allow the client to find the new server address through external means. Subsequently, the client must be able to verify the server's address by verifying the proof of possession of the IKEv2 key material at the new server. Until then the client must consider the new server's address as a "provisional" address and specifically it must not update the IKEv2 server address until after such verification succeeds. I think that I would rewrite this in more positive sense: o Solutions for a client-server model, where the client always initiates the secure communication may allow the client to find the new server address through external means. A client must be able to initiate a new IKEv2 PARENT_SA with one or more "auxiliary" servers without interrupting a connection to the currently used primary server. The client must consider the new server's address as a "provisional" address until it has verified a new server is the appropriate replacement for the primary server. ===== wow. shorter than I thought. I think that SC section should perhaps outline what additional security considerations a solution should deal with. A big one might be various kinds of third-party attempts to DoS. Are there competing gateways? Is there ever a financial advantage to making clients move? I know that there are underutilized (and in North America, almost never used) provisions in GSM phones to "prefer" certain networks, due to cost. Do the same kind of considerations apply? I'm thinking about the kind of situation where you have more than gateway "service" provider available. Does it become interesting for one provider to suggest to clients that the other server is "down"? Or is this out of scope for this protocol? - -- ] Bear: "Me, I'm just the shape of a bear." | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRYqnaoCLcPvd0N1lAQLiVwf+Peq/377DoCxBfl1Sw4koFO8MfGJDlAdN Il7jhnnPCq4yoip6m2xii/TeejVBYr08cjzfZhnXi9EWCTBGm+NmnhCpKiogjvFt xRxhCX+B5gHzw6l+/Vn42rAEKlujq/m2iYpE42QVDcOaIl4DYTmo1i7JGMiSTHYQ NNttM1reFxcQ9PZANFxwJadM4K/w4Dm1QKa6BErudKOdZD+DughjH7lCY6GPOt/B /GDeknp8g7pxjMvgMB8U9raME18Zs7s4PyP7mDfkMo89VAk0p0KOt+dh5Rc5OVAc 4zFqXuFwtd/mpUHiXiDCmwpoHPiFeu80HCRK/0vFq8RGtIy+RHZ3mw== =A60l -----END PGP SIGNATURE----- From owner-ietf-ipsec-failover Fri Dec 22 16:57:01 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBMNv10m001965; Fri, 22 Dec 2006 16:57:01 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBMNv1Kx001964; Fri, 22 Dec 2006 16:57:01 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBMNuwsQ001936; Fri, 22 Dec 2006 16:56:59 -0700 (MST) (envelope-from ldondeti@qualcomm.com) Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kBMNtt2t028194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Dec 2006 15:55:55 -0800 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.157]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kBMNtpOO018295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Dec 2006 15:55:53 -0800 (PST) Message-Id: <7.0.1.0.2.20061222150131.066498c0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 22 Dec 2006 15:55:50 -0800 To: Michael Richardson , "Narayanan, Vidya" From: Lakshminath Dondeti Subject: Re: Revised PS Draft (RE: IPsec Failover and Redundancy - Problem Statement and Goals) Cc: "Marcus Leech" , "Paul Hoffman" , kivinen@iki.fi, "Yaron Sheffer" , mstenber@cisco.com, cmadson@cisco.com, gregory.ietf@gmail.com, bew@cisco.com, srowles@cisco.com, "Pasi Eronen" , ietf-ipsec-failover@vpnc.org In-Reply-To: <9026.1166714733@sandelman.ottawa.on.ca> References: <9026.1166714733@sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Michael, I will incorporate most, if not all of your comments in some fashion and submit the revised version. Some notes inline: At 07:25 AM 12/21/2006, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > > > >section 5, page 4: > s,for the IPsec/IKEv2 Failover Redundancy, > for a IKEv2 Failover/Redundancy, > >I think that this is inhierently IKEv2, and a problem statement must >assume there might be zero or more solutions. > > Note that the goals of this effort are strictly failover > and other features such as load balancing, etc. are outside the scope > of this effort. > >I didn't think we had consensus about this statement. Do we? >I usually prefer hot-failover solutions that look like load balancing, >because in particular, it allows for n+1 redundancy rather than 2n. Personally, I think if a failover solution also works for load balancing type of scenarios that's ok. But, facilitating load balancing as part of this effort, for instance standardizing protocols for load balancing I think is best left out of scope. Hope that clarifies! >In particular your first point seems to disagree with the above >statement: > > in the event of a failure. It is more cost-effective to allow > such failover to distributed gateways that may be functional on > their own, serving other clients. The temporary increase in load > > > > often adds unacceptable latencies. Ideally, a mechanism that does > not need any new messages is desired. In general, the goal is to > >I'm unclear if you mean any new exchanges, or any new message types, or?? Hmm, I guess the intent is if existing messages and types work that'd be great. No new protocol design should be necessary (ideally speaking). But, for stateless design it looks like we will need to add new payload types etc. >I think that the next sentence may be a strong enough goal: > > In general, the goal is to > have significantly lower latency and to incur a lower > computational overhead than a regular IKEv2 exchange. > >also: > > In cases > where EAP is used for client authentication, the failover must not > require EAP authentication, to avoid AAA overloading and possible > user interaction. > >I think that you need to weaken this slightly. I think your goal is >that in most cases, it SHOULD NOT require a new EAP authentication >before a new IPsec SA is created. I think that it is fair that some >systems/solutions may want to make the new IPsec SA short-lived, and do >a new EAP, or some kind of EAP re-auth for cryptographic hygiene >reasons, but to do so concurrently with the new traffic. >There are also just some pathological failure cases that might be best >handled by starting everything over. Sure. >(My GSM phone does drop calls, just not daily. My PSTN phone often >gets a "bad line" too...) > > o Application Usage of IPsec: When IPsec is used to protect other > protocols, the extent of failover interoperability that can be > >I think my MIP ignorance is showing. Can you give us some references? > > o Stateless Gateway Operation: The IPsec failover mechanism must > specify a mode of operation that will allow the backup gateways to > remain stateless until a failover occurs or during a temporary > service interruption. This will allow for better scalability of > the solution, since a given gateway only needs to store state for > clients that are being served by it. > >I strongly favour this. I guess you are leaving room for a stateful >method as well. I think, it will be simpler to specify a single method. Yes, we definitely want to support the stateful model also. If it must be a single method, stateful is my preference. Perhaps we should just specify/work on both. > o Solutions for a client-server model, where the client always > initiates the secure communication may allow the client to find > the new server address through external means. Subsequently, the > client must be able to verify the server's address by verifying > the proof of possession of the IKEv2 key material at the new > server. Until then the client must consider the new server's > address as a "provisional" address and specifically it must not > update the IKEv2 server address until after such verification > succeeds. > >I think that I would rewrite this in more positive sense: > > o Solutions for a client-server model, where the client always > initiates the secure communication may allow the client to find > the new server address through external means. > A client must be able to initiate a new IKEv2 PARENT_SA with > one or more "auxiliary" servers without interrupting a > connection to the currently used primary server. > The client must consider the new server's address as a > "provisional" address until it has verified a new server is > the appropriate replacement for the primary server. Ok. >===== wow. shorter than I thought. > >I think that SC section should perhaps outline what additional security >considerations a solution should deal with. A big one might be various >kinds of third-party attempts to DoS. > >Are there competing gateways? Is there ever a financial advantage to >making clients move? This would definitely be out of scope for this effort, in my view. Lakshminath >I know that there are underutilized (and in North America, almost never >used) provisions in GSM phones to "prefer" certain networks, due to >cost. Do the same kind of considerations apply? > >I'm thinking about the kind of situation where you have more than >gateway "service" provider available. Does it become interesting for >one provider to suggest to clients that the other server is "down"? > >Or is this out of scope for this protocol? > >- -- >] Bear: "Me, I'm just the shape of a >bear." | firewalls [ >] Michael Richardson, Xelerance Corporation, Ottawa, ON |net >architect[ >] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ >|device driver[ >] panic("Just another Debian GNU/Linux using, kernel hacking, >security guy"); [ > > > > > > > > > > > > > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.5 (GNU/Linux) >Comment: Finger me for keys > >iQEVAwUBRYqnaoCLcPvd0N1lAQLiVwf+Peq/377DoCxBfl1Sw4koFO8MfGJDlAdN >Il7jhnnPCq4yoip6m2xii/TeejVBYr08cjzfZhnXi9EWCTBGm+NmnhCpKiogjvFt >xRxhCX+B5gHzw6l+/Vn42rAEKlujq/m2iYpE42QVDcOaIl4DYTmo1i7JGMiSTHYQ >NNttM1reFxcQ9PZANFxwJadM4K/w4Dm1QKa6BErudKOdZD+DughjH7lCY6GPOt/B >/GDeknp8g7pxjMvgMB8U9raME18Zs7s4PyP7mDfkMo89VAk0p0KOt+dh5Rc5OVAc >4zFqXuFwtd/mpUHiXiDCmwpoHPiFeu80HCRK/0vFq8RGtIy+RHZ3mw== >=A60l >-----END PGP SIGNATURE----- From owner-ietf-ipsec-failover Fri Dec 22 19:52:40 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBN2qdK9066949; Fri, 22 Dec 2006 19:52:39 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBN2qdMT066948; Fri, 22 Dec 2006 19:52:39 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBN2qYu9066898 for ; Fri, 22 Dec 2006 19:52:39 -0700 (MST) (envelope-from ldondeti@qualcomm.com) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kBN2qYgg006055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 22 Dec 2006 18:52:34 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-39.qualcomm.com [10.50.76.39]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kBN2qXrP026453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Dec 2006 18:52:33 -0800 Message-Id: <7.0.1.0.2.20061222185135.066203d8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 22 Dec 2006 18:52:32 -0800 To: ietf-ipsec-failover@vpnc.org From: Lakshminath Dondeti Subject: IPsec failover PS Cc: "Vidya Narayanan" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi all, I just submitted the version available at http://employees.org/~ldondeti/draft-vidya-ipsec-failover-ps-00.txt to the IETF. regards, Lakshminath From owner-ietf-ipsec-failover Sat Dec 23 12:51:17 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBNJpHte054261; Sat, 23 Dec 2006 12:51:17 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBNJpHrN054260; Sat, 23 Dec 2006 12:51:17 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from cod.sandelman.ca (cod.sandelman.ca [192.139.46.42]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBNJpGWK054236 for ; Sat, 23 Dec 2006 12:51:16 -0700 (MST) (envelope-from mcr@sandelman.ottawa.on.ca) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marajade.sandelman.ca.", Issuer "Michael Richardson" (verified OK)) by cod.sandelman.ca (Postfix) with ESMTP id D805B12422 for ; Sat, 23 Dec 2006 14:51:14 -0500 (EST) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 7A0554E787 for ; Sat, 23 Dec 2006 14:51:13 -0500 (EST) From: Michael Richardson To: ietf-ipsec-failover@vpnc.org Subject: Re: Revised PS Draft (RE: IPsec Failover and Redundancy - Problem Statement and Goals) In-Reply-To: Message from Lakshminath Dondeti of "Fri, 22 Dec 2006 15:55:50 PST." <7.0.1.0.2.20061222150131.066498c0@qualcomm.com> References: <9026.1166714733@sandelman.ottawa.on.ca> <7.0.1.0.2.20061222150131.066498c0@qualcomm.com> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 19) Date: Sat, 23 Dec 2006 14:51:13 -0500 Message-ID: <10063.1166903473@sandelman.ottawa.on.ca> Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Lakshminath" == Lakshminath Dondeti writes: >> (My GSM phone does drop calls, just not daily. My PSTN phone >> often gets a "bad line" too...) >> >> o Application Usage of IPsec: When IPsec is used to protect other >> protocols, the extent of failover interoperability that can be >> >> I think my MIP ignorance is showing. Can you give us some >> references? >> >> o Stateless Gateway Operation: The IPsec failover mechanism must >> specify a mode of operation that will allow the backup gateways >> to remain stateless until a failover occurs or during a temporary >> service interruption. This will allow for better scalability of >> the solution, since a given gateway only needs to store state for >> clients that are being served by it. >> >> I strongly favour this. I guess you are leaving room for a >> stateful method as well. I think, it will be simpler to specify >> a single method. Lakshminath> Yes, we definitely want to support the stateful model Lakshminath> also. If it must be a single method, stateful is my Lakshminath> preference. Perhaps we should just specify/work on Lakshminath> both. That's interesting. A stateless method is easier to make stateful than the converse. Can you tell me why a stateful method would also need to be interoperable? >> ===== wow. shorter than I thought. >> >> I think that SC section should perhaps outline what additional >> security considerations a solution should deal with. A big one >> might be various kinds of third-party attempts to DoS. >> >> Are there competing gateways? Is there ever a financial advantage >> to making clients move? Lakshminath> This would definitely be out of scope for this effort, Lakshminath> in my view. That needs to be stated. "We assume that the gateways are not mutually suspicious, and are not competitors. That the gateways are run by the same enterprise." - -- ] Bear: "Me, I'm just the shape of a bear." | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRY2IsICLcPvd0N1lAQIYJgf9HlOO8b09f24208EXYF/1yVvWZHI3DENb YMWZ5ioCwSZZ6AbZhB+1cdHhdbYDT7i+7C0njfF426HLcQ2G3e2ku/vEx/9aZt7F VrkXys+XMRXY6jn+rYNCQDTDcNm2GujZvQUExi2kNXPfMaC0LemXHH2bTHqgE4JI rFHCYt0Nf/6GJCVRqumlH4HM5KwRAXxlL2O2R1p9i7VV36kg6uRdYfnrsHPEOqvk bF0dNoTubrrYPgecxDqAvhxLnF3vKgy8Snlu//92J3zpIUe8i6/g3d51ViS2xVGw l09b4ompYXHHhnZqe0Km9i7KHTwKuYjqrzqCybIQF3Ds0gFWJ6p6Jw== =THEh -----END PGP SIGNATURE----- From owner-ietf-ipsec-failover Sat Dec 23 19:44:20 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBO2iK2a027390; Sat, 23 Dec 2006 19:44:20 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBO2iKOp027389; Sat, 23 Dec 2006 19:44:20 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBO2iJuX027366 for ; Sat, 23 Dec 2006 19:44:19 -0700 (MST) (envelope-from ldondeti@qualcomm.com) Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kBO2i7da010868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 23 Dec 2006 18:44:08 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-103.qualcomm.com [10.50.76.103]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kBO2i6Fn002819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 23 Dec 2006 18:44:07 -0800 (PST) Message-Id: <7.0.1.0.2.20061223182951.05babe60@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 23 Dec 2006 18:44:03 -0800 To: "Michael Richardson" , From: Lakshminath Dondeti Subject: Re: Revised PS Draft (RE: IPsec Failover and Redundancy - Problem Statement and Goals) In-Reply-To: <10063.1166903473@sandelman.ottawa.on.ca> References: <9026.1166714733@sandelman.ottawa.on.ca> <7.0.1.0.2.20061222150131.066498c0@qualcomm.com> <10063.1166903473@sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:51 AM 12/23/2006, Michael Richardson wrote: > > >> I strongly favour this. I guess you are leaving room for a > >> stateful method as well. I think, it will be simpler to specify > >> a single method. > > Lakshminath> Yes, we definitely want to support the stateful model > Lakshminath> also. If it must be a single method, stateful is my > Lakshminath> preference. Perhaps we should just specify/work on > Lakshminath> both. > > That's interesting. > A stateless method is easier to make stateful than the converse. I looked at a draft that Ekr wrote on stateless methods and there are some interesting intricacies there. For instance, how would servers revoke state maintained at a client. For a comprehensive stateless solution, the client implementation and even the server implementation could be complex. > Can you tell me why a stateful method would also need to be interoperable? From my understanding, mip6 failover is also stateful. We need things like transport mode support in MOBIKE for a stateful method to be supported. So we need an interoperable solution. Let me know if that answers your question. regards, Lakshminath From owner-ietf-ipsec-failover Thu Dec 28 06:54:16 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBSDsGln012142; Thu, 28 Dec 2006 06:54:16 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBSDsGjC012140; Thu, 28 Dec 2006 06:54:16 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from mtaout1.barak.net.il (mtaout1.barak.net.il [212.150.49.171]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBSDs8aG012119 for ; Thu, 28 Dec 2006 06:54:16 -0700 (MST) (envelope-from arikf@cs.technion.ac.il) Received: from arikflap ([89.1.239.73]) by mtaout1.barak.net.il (Sun Java System Messaging Server 6.2-6.02 (built Apr 25 2006)) with ESMTPA id <0JAZ0010EL9V3MC0@mtaout1.barak.net.il> for ietf-ipsec-failover@vpnc.org; Thu, 28 Dec 2006 15:53:57 +0200 (IST) Date: Thu, 28 Dec 2006 15:55:17 +0200 From: Arik Friedman Subject: FW:I-D ACTION:draft-friedman-ike-short-term-certs-01.txt To: ietf-ipsec-failover@vpnc.org, ipsec@ietf.org Message-id: <004101c72a87$d02ed470$0100000a@arikflap> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: Accp/DWIzK3tssGZTsuB7rksI0c3XgAic/PQ Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, We would appreciate any comments you may have regarding the second revision of this draft, either privately or to the mailing list. I appologize if you got this email more than once. Thanks, Arik Friedman. > -----Original Message----- Date: Wed, 27 Dec 2006 15:50:02 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-friedman-ike-short-term-certs-01.txt To: i-d-announce@ietf.org Message-ID: Content-Type: text/plain; charset="us-ascii" A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Short-Term Certificates Author(s) : A. Friedman, et al. Filename : draft-friedman-ike-short-term-certs-01.txt Pages : 12 Date : 2006-12-27 This document describes an extension to IKEv2 that allows an endpoint which has authenticated to a gateway to request a short-term credential, possession of which proves the authentication. This allows it to prove to a security gateway that it was already authenticated by another trusted security gateway, thereby allowing the authentication of the endpoint without user intervention. This credential is a certificate issued by the authenticating gateway for a short period of time, which can be used to authenticate the user with IKE signature based authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-friedman-ike-short-term-certs-01.t xt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-friedman-ike-short-term-certs-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-friedman-ike-short-term-certs-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative ------------------------------ From owner-ietf-ipsec-failover Thu Dec 28 10:41:45 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBSHfjUH036439; Thu, 28 Dec 2006 10:41:45 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBSHfj9E036438; Thu, 28 Dec 2006 10:41:45 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from mx1.grc.nasa.gov (mx1.grc.nasa.gov [128.156.11.68]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBSHffoi036373 for ; Thu, 28 Dec 2006 10:41:43 -0700 (MST) (envelope-from weddy@gr2134391.grc.nasa.gov) Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 684F0C237 for ; Thu, 28 Dec 2006 12:41:40 -0500 (EST) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id kBSHfYKY020005 for ; Thu, 28 Dec 2006 12:41:39 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id kBSHfYCT014964 for ; Thu, 28 Dec 2006 12:41:34 -0500 (EST) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id ybQRtRff8yFn for ;Thu, 28 Dec 2006 12:41:34 -0500 (EST) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id kBSHfVZp014953for ; Thu, 28 Dec 2006 12:41:31 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id A15194FDA9; Thu, 28 Dec 2006 12:39:37 -0500 (EST) Date: Thu, 28 Dec 2006 12:39:37 -0500 From: Wesley Eddy To: ietf-ipsec-failover@vpnc.org Subject: client involvement in draft-vidya-ipsec-failover-ps-00 Message-ID: <20061228173937.GC3980@grc.nasa.gov> Reply-To: weddy@grc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1i X-imss-version: 2.045 X-imss-result: Passed X-imss-scores: Clean:18.32148 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:2 M:2 S:2 R:2 (0.0000 0.0000) Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I have a question on the bullet in section 5 of draft-vidya-ipsec-failover-ps-00 that lists "client involvement" as a goal. This bullet states that failover is not intended to be transparent to the client. Given that the previous section mentions using VRRP for redundant gateways to share an IP address, I had assumed the goal would be to make failover transparent to clients. These parts of the draft seem to conflict, but maybe I'm just misunderstanding. I also think that a mechanism that can only be client-initiated is a big problem because it would require fast dead-peer detection, which implies a high amount of usually worthless signaling. In the tradeoff between fast dead-peer detection and low signaling overhead for constrained aeronautics and space links, low overhead wins out, and an entirely transparent failover solution based on using VRRP or anycast to reach redundant gateways is highly preferable to me. I might say that client involvement MUST NOT be required of a failover solution between redundant gateways, but that a mechanism to exchange SAD/SPD entries between gateways SHOULD also be compatible with other (possibly client-based) mechanisms for selecting between equivalent gateways. -- Wesley M. Eddy Verizon Federal Network Systems From owner-ietf-ipsec-failover Thu Dec 28 12:21:47 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBSJLlRj046343; Thu, 28 Dec 2006 12:21:47 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBSJLlot046342; Thu, 28 Dec 2006 12:21:47 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBSJLjqm046335 for ; Thu, 28 Dec 2006 12:21:45 -0700 (MST) (envelope-from ldondeti@qualcomm.com) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kBSJLe2X015612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Dec 2006 11:21:41 -0800 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.157]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kBSJLdwU030798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Dec 2006 11:21:40 -0800 Message-Id: <7.0.1.0.2.20061228094545.04bce7d0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 28 Dec 2006 11:21:40 -0800 To: weddy@grc.nasa.gov, ietf-ipsec-failover@vpnc.org From: Lakshminath Dondeti Subject: Re: client involvement in draft-vidya-ipsec-failover-ps-00 In-Reply-To: <20061228173937.GC3980@grc.nasa.gov> References: <20061228173937.GC3980@grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This area tends to bring out diametrically opposite viewpoints, but of course I wouldn't expect any less :). Case in point, another person in a related but different discussion commented on "client involvement" by simply saying "Good" and went onto make the case for doing away with server to server interoperability. Please see inline for some thoughts: At 09:39 AM 12/28/2006, Wesley Eddy wrote: >I have a question on the bullet in section 5 of >draft-vidya-ipsec-failover-ps-00 that lists "client involvement" as a >goal. This bullet states that failover is not intended to be >transparent to the client. Given that the previous section mentions >using VRRP for redundant gateways to share an IP address, I had assumed >the goal would be to make failover transparent to clients. These >parts of the draft seem to conflict, but maybe I'm just misunderstanding. The goal is to allow client to server and server to server interoperability in the context of IPsec failover. As you note below, there is definitely a case for making the failover transparent to the client in certain application scenarios. But there are also cases where client involvement is possible and necessary, the MIP6 HA failover case being one of the examples. >I also think that a mechanism that can only be client-initiated is a big >problem because it would require fast dead-peer detection, which implies >a high amount of usually worthless signaling. At least in case of HA failover, we assume that the client knows that the HA has failed and it needs to go to an alternate HA. Please note that we are developing standards to facilitate these various scenarios. In scenarios where a lot of signaling is required to detect GW failure, perhaps client involvement may not be a good idea. Does that sound ok? regards, Lakshminath >In the tradeoff between >fast dead-peer detection and low signaling overhead for constrained >aeronautics and space links, low overhead wins out, and an entirely >transparent failover solution based on using VRRP or anycast to reach >redundant gateways is highly preferable to me. > >I might say that client involvement MUST NOT be required of a failover >solution between redundant gateways, but that a mechanism to exchange >SAD/SPD entries between gateways SHOULD also be compatible with >other (possibly client-based) mechanisms for selecting between >equivalent gateways. > >-- >Wesley M. Eddy >Verizon Federal Network Systems From owner-ietf-ipsec-failover Fri Dec 29 19:46:19 2006 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBU2kJ6S094346; Fri, 29 Dec 2006 19:46:19 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBU2kJTR094345; Fri, 29 Dec 2006 19:46:19 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from mx2.grc.nasa.gov (mx2.grc.nasa.gov [128.156.11.69]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBU2kHnt094335 for ; Fri, 29 Dec 2006 19:46:18 -0700 (MST) (envelope-from weddy@gr2134391.grc.nasa.gov) Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx2.grc.nasa.gov (Postfix) with ESMTP id 28DDCC231 for ; Fri, 29 Dec 2006 21:46:15 -0500 (EST) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id kBU2jiHV026183; Fri, 29 Dec 2006 21:45:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with SMTP id kBU2jiHD022763; Fri, 29 Dec 2006 21:45:44 -0500 (EST) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id uaGVWEl14LDT; Fri, 29 Dec 2006 21:45:31 -0500 (EST) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id kBU2jS3W022701;Fri, 29 Dec 2006 21:45:28 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 007964FDB1; Fri, 29 Dec 2006 21:43:32 -0500 (EST) Date: Fri, 29 Dec 2006 21:43:32 -0500 From: Wesley Eddy To: Lakshminath Dondeti Cc: ietf-ipsec-failover@vpnc.org Subject: Re: client involvement in draft-vidya-ipsec-failover-ps-00 Message-ID: <20061230024332.GA13136@grc.nasa.gov> Reply-To: weddy@grc.nasa.gov References: <20061228173937.GC3980@grc.nasa.gov> <7.0.1.0.2.20061228094545.04bce7d0@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7.0.1.0.2.20061228094545.04bce7d0@qualcomm.com> User-Agent: Mutt/1.5.5.1i X-imss-version: 2.045 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:2 M:2 S:2 R:2 (0.0000 0.0000) Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Dec 28, 2006 at 11:21:40AM -0800, Lakshminath Dondeti wrote: > > >I have a question on the bullet in section 5 of > >draft-vidya-ipsec-failover-ps-00 that lists "client involvement" as a > >goal. This bullet states that failover is not intended to be > >transparent to the client. Given that the previous section mentions > >using VRRP for redundant gateways to share an IP address, I had assumed > >the goal would be to make failover transparent to clients. These > >parts of the draft seem to conflict, but maybe I'm just misunderstanding. > > The goal is to allow client to server and server to server > interoperability in the context of IPsec failover. As you note > below, there is definitely a case for making the failover transparent > to the client in certain application scenarios. But there are also > cases where client involvement is possible and necessary, the MIP6 HA > failover case being one of the examples. > Can you clarify what exactly you mean by MIP6 HA failover? There are a few solutions I know of that have been proposed, that differ a bit. I think draft-jfaizan-mipv6-vhar describes a MIP6 analogue to what I desire for IPsec gateways. The use of the HAHA mechanism with VRRP as discused in drafts/draft-devarapalli-mip6-nemo-local-haha is also a good reference. I think this may be what you're refering to since it allows the HA failover to be triggered either by the mobile node or by the HA. > >I also think that a mechanism that can only be client-initiated is a big > >problem because it would require fast dead-peer detection, which implies > >a high amount of usually worthless signaling. > > At least in case of HA failover, we assume that the client knows that > the HA has failed and it needs to go to an alternate HA. Please note > that we are developing standards to facilitate these various > scenarios. In scenarios where a lot of signaling is required to > detect GW failure, perhaps client involvement may not be a good idea. > > Does that sound ok? > Yes, I think so, if we're talking about something analogous to the HAHA work for MIP6/NEMO, then it should be possible to construct both gateway and client-based failover mechanisms, and I would consider that excellent. -- Wesley M. Eddy Verizon Federal Network Systems From owner-ietf-ipsec-failover Mon Jan 8 08:50:52 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l08Foq3G048981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jan 2007 08:50:52 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l08Foqce048980; Mon, 8 Jan 2007 08:50:52 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from michael.checkpoint.com ([194.29.32.68]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l08Fomcm048955 for ; Mon, 8 Jan 2007 08:50:50 -0700 (MST) (envelope-from yaronf@checkpoint.com) Received: from ysheffer.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id l08FobhJ007771 for ; Mon, 8 Jan 2007 17:50:37 +0200 (IST) Message-Id: <200701081550.l08FobhJ007771@michael.checkpoint.com> Date: Mon, 8 Jan 2007 17:50:36 +0200 From: Yaron Sheffer Subject: Statless IKE session resumption To: ietf-ipsec-failover@vpnc.org MIME-Version: 1.0 X-Mailer: Sun Outlook Connector 7.1.228.0 Content-type: MULTIPART/MIXED; BOUNDARY="23726882-14259-1168271437=:7164" Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --23726882-14259-1168271437=:7164 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="23726882-4673-1168271437=:7164" --23726882-4673-1168271437=:7164 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: QUOTED-PRINTABLE Hi, =20 Stateless session resumption seems to be a nice solution for some (most?) o= f the common IPsec failover cases. I have written the attached draft which = is modeled after the analogous solution for TLS, RFC 4507. I think it is re= asonably complete for a -00 version (other than the non-existent security c= onsiderations) but I'm sure you people will find the holes I have missed. =20 I would appreciate your review of the draft-draft before I submit it as an = I-D. I would be even happier if any of you are willing to join as coauthors= , since there's still a lot to be done. =20 Regards, and happy new year. =20 Yaron --23726882-4673-1168271437=:7164 Content-type: TEXT/HTML; CHARSET=US-ASCII Content-transfer-encoding: QUOTED-PRINTABLE

Hi,

 

Stateless session resumption seems to be a nice solution= for some (most?) of the common IPsec failover cases. I have written the attache= d draft which is modeled after the analogous solution for TLS, RFC 4507. I th= ink it is reasonably complete for a -00 version (other than the non-existent se= curity considerations) but I'm sure you people will find the holes I have missed.<= o:p>

 

I would appreciate your review of the draft-draft before= I submit it as an I-D. I would be even happier if any of you are willing to j= oin as coauthors, since there's still a lot to be done.

 

Regards, and happy new year.

 

         &n= bsp;  Yaron

--23726882-4673-1168271437=:7164-- --23726882-14259-1168271437=:7164 Content-type: TEXT/plain; CHARSET=US-ASCII Content-transfer-encoding: QUOTED-PRINTABLE Content-description: draft-sheffer-ike-session-resumption-00-v1.txt Content-disposition: attachment; filename="draft-sheffer-ike-session-resumption-00-v1.txt" =0A=0A=0ANetwork Working Group Y. S= heffer=0AInternet-Draft Check= Point=0AIntended status: Standards Track January 8= , 2007=0AExpires: July 12, 2007=0A=0A=0A Stateless Session Resump= tion for the IKE Protocol=0A draft-sheffer-ike-session-resum= ption-00=0A=0AStatus of this Memo=0A=0A By submitting this Internet-Draft= , each author represents that any=0A applicable patent or other IPR claim= s of which he or she is aware=0A have been or will be disclosed, and any = of which he or she becomes=0A aware will be disclosed, in accordance with= Section 6 of BCP 79.=0A=0A Internet-Drafts are working documents of the = Internet Engineering=0A Task Force (IETF), its areas, and its working gro= ups. Note that=0A other groups may also distribute working documents as = Internet-=0A Drafts.=0A=0A Internet-Drafts are draft documents valid fo= r a maximum of six months=0A and may be updated, replaced, or obsoleted b= y other documents at any=0A time. It is inappropriate to use Internet-Dr= afts as reference=0A material or to cite them other than as "work in prog= ress."=0A=0A The list of current Internet-Drafts can be accessed at=0A = http://www.ietf.org/ietf/1id-abstracts.txt.=0A=0A The list of Internet-Dr= aft Shadow Directories can be accessed at=0A http://www.ietf.org/shadow.h= tml.=0A=0A This Internet-Draft will expire on July 12, 2007.=0A=0ACopyrig= ht Notice=0A=0A Copyright (C) The Internet Society (2007).=0A=0AAbstract= =0A=0A In many failure cases it is useful to resume an interrupted IKE/IP= sec=0A session. We propose an extension to IKEv2 that allows a client to= =0A establish an IKE SA with a gateway in a highly efficient manner,=0A = utilizing a prior IKE SA. A client can reconnect to a gateway from=0A w= hich it was disconnected, or else it can migrate to another gateway.=0A T= he solution is stateless: no per-client state is required on the=0A gatew= ay until the IKE SA is reestablished. This is done by retaining=0A parts= of the IKE SA in a protected ticket stored on the client.=0A=0A=0A=0ASheff= er Expires July 12, 2007 [Page 1]=0A=0C= =0AInternet-Draft IKE Session Resumption January 2007= =0A=0A=0ATable of Contents=0A=0A 1. Requirements Notation . . . . . . .= . . . . . . . . . . . . . 3=0A 2. Introduction . . . . . . . . . . . .= . . . . . . . . . . . . . 3=0A 2.1. Goals . . . . . . . . . . . . .= . . . . . . . . . . . . . 3=0A 2.2. Non Goals . . . . . . . . . . .= . . . . . . . . . . . . . 3=0A 2.3. Our Approach and Related Work .= . . . . . . . . . . . . . 4=0A 3. Protocol Details . . . . . . . . . .= . . . . . . . . . . . . . 4=0A 3.1. Overview: Acquiring a Ticket . .= . . . . . . . . . . . . . 4=0A 3.2. Overview: Presenting a Ticket .= . . . . . . . . . . . . . 5=0A 3.3. Additional Details: Acquiring a = Ticket . . . . . . . . . . 6=0A 3.4. Additional Details: Presenting a= Ticket . . . . . . . . . 6=0A 3.5. IKE Notifications . . . . . . .= . . . . . . . . . . . . . 7=0A 3.6. The New IKE SA . . . . . . . . .= . . . . . . . . . . . . . 7=0A 3.7. Deriving the AUTH Values . . . .= . . . . . . . . . . . . . 8=0A 3.8. Session Resumption and MOBIKE .= . . . . . . . . . . . . . 8=0A 3.9. IKE Cookies . . . . . . . . . .= . . . . . . . . . . . . . 8=0A 4. The IKE Ticket . . . . . . . . . . .= . . . . . . . . . . . . . 8=0A 4.1. Ticket Contents . . . . . . . .= . . . . . . . . . . . . . 9=0A 4.2. Ticket Format . . . . . . . . .= . . . . . . . . . . . . . 9=0A 4.3. Ticket Identity and Lifecycle .= . . . . . . . . . . . . . 9=0A 5. IANA Considerations . . . . . . . .= . . . . . . . . . . . . . 10=0A 6. Security Considerations . . . . . .= . . . . . . . . . . . . . 10=0A 7. Change Log . . . . . . . . . . . . .= . . . . . . . . . . . . . 10=0A 7.1. -00 . . . . . . . . . . . . . .= . . . . . . . . . . . . . 10=0A 8. Acknowledgements . . . . . . . . . .= . . . . . . . . . . . . . 10=0A 9. References . . . . . . . . . . . . .= . . . . . . . . . . . . . 10=0A 9.1. Normative References . . . . . .= . . . . . . . . . . . . . 10=0A 9.2. Informative References . . . . .= . . . . . . . . . . . . . 11=0A Author's Address . . . . . . . . . . . .= . . . . . . . . . . . . . 11=0A Intellectual Property and Copyright Stat= ements . . . . . . . . . . 12=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A= =0A=0A=0A=0A=0A=0ASheffer Expires July 12, 2007 = [Page 2]=0A=0C=0AInternet-Draft IKE Session Resumption = January 2007=0A=0A=0A1. Requirements Notation=0A=0A The key wor= ds "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A "SHOULD", "SH= OULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A document are t= o be interpreted as described in [RFC2119].=0A=0A=0A2. Introduction=0A=0A2= .1. Goals=0A=0A The high-level goal of this extension is to become a bui= lding block=0A of an overall IPsec failover solution, according to the re= quirements=0A put down in [I-D.vidya-ipsec-failover-ps].=0A=0A Specific= ally, the proposed extension should allow IPsec sessions to=0A recover fr= om failures in the remote access scenario, and do it much=0A more efficie= ntly than the basic IKE solution. This efficiency is=0A primarily on the= gateway side, since the gateway might have to deal=0A with many thousand= s of concurrent requests. We should enable the=0A following cases:=0A=0A= o Failover from one gateway to another, where the two gateways do=0A = not share state (but do have mutual trust). For example, the=0A ga= teways may be located at a geographical distance from one=0A another.= =0A o Recovery from an intermittent connectivity failure ("network=0A = reboot"), where the clients reconnect into the same gateway. In=0A = this case the gateway would typically had detected the clients'=0A ab= sence and removed the state associated with them.=0A o Recovery from a g= ateway restart, where clients reconnect into the=0A same gateway.=0A= =0A The proposed solution should additionally meet the following goals:= =0A=0A o In the normal case, use only symmetric crypto to minimize CPU= =0A consumption.=0A o Be stateless, so that the gateway does not ne= ed to maintain state=0A for clients that may have roamed away.=0A o = Provide crypto agility.=0A o Have no security impact on IKE. Specifica= lly, the solution must=0A not create new DOS risks.=0A=0A2.2. Non Goa= ls=0A=0A The following are non-goals of this solution:=0A=0A=0A=0A=0A=0AS= heffer Expires July 12, 2007 [Page 3]=0A= =0C=0AInternet-Draft IKE Session Resumption January 2= 007=0A=0A=0A o Provide for load balancing among gateways.=0A o Specif= y how the client detects the need for failover.=0A o Allow for trust est= ablishment and/or state synchronization between=0A gateways.=0A=0A2.3.= Our Approach and Related Work=0A=0A We propose to maintain IKEv2 state = in a "ticket", an opaque data=0A structure maintained on the client, but = one which the client cannot=0A read or modify. We extend the IKEv2 proto= col to allow the client to=0A request and/or present the ticket. When tw= o gateways are mutually=0A trusting, one can accept a ticket which was ge= nerated earlier by the=0A other.=0A=0A This approach is similar to the = one taken for TLS session resumption=0A [RFC4507] with the required adapt= ations for IKE, e.g. to accommodate=0A the two-phase protocol structure. = We have borrowed heavily from that=0A specification.=0A=0A An on-going= work [I-D.friedman-ike-short-term-certs] discusses the=0A use of short-t= erm certificates for client re-authentication. This=0A has some similari= ties to the current work, and the following=0A differences. Short-term c= ertificates require a smaller change to IKE=0A compared to stateless tick= ets, since the certificates obtained are=0A valid for any IKE responder a= nd in fact when they are presented, the=0A protocol is the "plain vanilla= " IKEv2. For the same reason, short-=0A term certificates, while elimina= ting the usability issues of user re-=0A authentication, do not reduce th= e amount of effort performed by the=0A gateway in failover situations.=0A= =0A=0A3. Protocol Details=0A=0A We start this section by describing the = two typical cases: obtaining=0A and presenting an IKE ticket. Then we ex= pand on these cases. This=0A is followed by syntactic details and additi= onal considerations.=0A=0A3.1. Overview: Acquiring a Ticket=0A=0A Normal= ly, a client requests a ticket in the third message of IKE (the=0A first = of IKE_AUTH), and receives the ticket when authentication is=0A complete.= =0A=0A Initiator Responder=0A ----------- = -----------=0A --> IDi, N(TICKET/Request), SA, TSi, TSr=0A = <-- IDr, AUTH, EAP=0A = ...=0A=0A=0A=0ASheffer Expires July 12, 2007 = [Page 4]=0A=0C=0AInternet-Draft IKE Session Resumption = January 2007=0A=0A=0A <-- AUTH, N= (TICKET/Opaque), SA, TSi, TSr=0A=0A Note that a large number of optional = notifications are omitted for=0A clarity, see [RFC4718] for details. The= notifications are defined in=0A Section 3.5 below.=0A=0A3.2. Overview: = Presenting a Ticket=0A=0A Following an extended communication failure, th= e client re-initiates=0A an IKE exchange to the same gateway or to a diff= erent one, and=0A includes a ticket in the first message of IKE_SA_INIT.= =0A=0A --> SA, KE, Ni, N(TICKET/Opaque)=0A=0A If the gateway s= upports this extension and is willing to accept the=0A ticket, it respond= s with:=0A=0A <-- SA, Nr, N(TICKET/Ack)= =0A=0A The KE payload is omitted in the response, however Ni and Nr are= =0A still used for freshness.=0A=0A At this point a new IKE SA is creat= ed by both parties (see=0A Section 3.6), and used for the following IKE_A= UTH exchange. This IKE=0A SA is still unauthenticated. Both parties now= sign the exchange:=0A=0A --> IDi, [IDr,] AUTH=0A = <-- IDr, AUTH=0A=0A See Section 3.7 for the derivatio= n of the AUTH values from the=0A message bytes, the ticket and the nonce = values. The gateway and the=0A client MUST verify the AUTH values they r= eceive. The new IKE SA only=0A becomes fully valid once each party has v= erified the other party's=0A signature. If either side receives an incor= rect AUTH value, it MUST=0A terminate the protocol.=0A=0A Alternatively= and more efficiently, the IKE_AUTH exchange can be=0A piggybacked into a= CREATE_CHILD_SA exchange:=0A=0A --> IDi, [IDr,] AUTH, SAi2, Ni2, T= Si, TSr [, CP(CFG_REQUEST)]=0A <-- IDr, AUTH, SAr2, Nr2,= TSi, TSr [, CP(CFG_REPLY)]=0A=0A The Child SA values here (SAi2, Ni2 etc= .) should not be confused with=0A the similar values for the IKE SA. Thi= s document only discusses the=0A values related to the IKE SA.=0A=0A=0A= =0A=0A=0A=0ASheffer Expires July 12, 2007 = [Page 5]=0A=0C=0AInternet-Draft IKE Session Resumption = January 2007=0A=0A=0A3.3. Additional Details: Acquiring a Ticket=0A=0A = A client MAY request a ticket in the following exchanges:=0A=0A o In a= n IKE_AUTH exchange, as described above.=0A o In a CREATE_CHILD_SA excha= nge, when it is used to rekey the IKE=0A SA.=0A o In an Information= al exchange, if the gateway previously replied=0A with an N(TICKET/Ack= ) instead of providing a ticket.=0A o In an Informational exchange, when= the ticket expires.=0A=0A It makes sense to request and use a ticket whe= n IKE is used with non-=0A EAP forms of authentication. These cases are = not defined in the=0A current document.=0A=0A The gateway normally gran= ts a ticket using N(TICKET/Opaque). It may=0A instead use the same messa= ge to reply with:=0A=0A o N(TICKET/Nack), if it refuses to grant a ticke= t for some reason.=0A o N(TICKET/Ack), if it cannot grant a ticket immed= iately, e.g.=0A because that would make the packet too large. In that= case the=0A client MAY request a ticket later using an Informational = exchange,=0A at any time during the lifetime of the IKE SA.=0A=0A3.4. = Additional Details: Presenting a Ticket=0A=0A A client MAY initiate a re= gular (non-ticket) IKE exchange even if it=0A is in possession of a valid= ticket. A client MUST NOT present a=0A ticket after its lifetime has ex= pired.=0A=0A If the gateway does not accept the ticket for any reason, it= MUST=0A respond with an N(TICKET/Nack) notification. If the gateway res= ponds=0A with N(TICKET/Nack), it MUST include the KE payload to allow for= a=0A regular IKE exchange. A client receiving an N(TICKET/Nack)=0A no= tification MUST discard the ticket and continue with a full,=0A regular I= KE exchange. It MAY request a new ticket later in the=0A exchange.=0A=0A= If the gateway responds with a standard IKE_INIT message #2, this may=0A= indicate that the gateway does not implement this extension. In this=0A= case, the client SHOULD NOT discard the ticket.=0A=0A If the gateway r= eceives a ticket for an IKE SA that is still active,=0A it SHOULD silentl= y delete the old SA without sending a DELETE=0A Informational exchange.= =0A=0A If the gateway receives a ticket for an IKE SA that has previously= =0A been terminated on this same gateway, this may indicate inconsistent= =0A=0A=0A=0ASheffer Expires July 12, 2007 = [Page 6]=0A=0C=0AInternet-Draft IKE Session Resumption = January 2007=0A=0A=0A state between the client and the gateway. The g= ateway SHOULD respond=0A with an N(TICKET/Nack) notification and proceed = to a full IKE=0A exchange. A gateway is not required to maintain state f= or terminated=0A sessions.=0A=0A3.5. IKE Notifications=0A=0A We define= a single notification type, TICKET, with a number of=0A subtypes. The n= otification number is TBD by IANA. The subtypes are=0A listed below.=0A= =0A +--------------+---------+-----------+=0A = | Subtype Name | Number | Data |=0A +----------= ----+---------+-----------+=0A | Opaque | 1 | = See below |=0A | Request | 2 | None |=0A = | Ack | 3 | None |=0A = | Nack | 4 | None |=0A | Reserved |= 5-127 | |=0A | Private Use | 128-255 | = |=0A +--------------+---------+-----------+=0A=0A T= he data for the Opaque subtype consists of a lifetime duration in=0A seco= nds (4 octets, denoting the time until the ticket expires),=0A followed b= y the ticket. See Section 4.3 for further guidelines=0A regarding the ti= cket's lifetime, and Section 4.2 for a recommended=0A ticket format.=0A= =0A3.6. The New IKE SA=0A=0A When a ticket is presented, the gateway der= ives the new IKE SA from=0A the information contained in the ticket, and = the client from its=0A local store:=0A=0A o The SA value (transforms e= tc.) is taken directly from the ticket.=0A o The sequence numbers are re= set to 0.=0A o The IDi value is obtained from the new exchange. It must= be=0A unchanged, i.e. the gateway MUST verify that this value is=0A = identical to the value encoded in the ticket.=0A o The IDr value is = obtained from the new exchange. The gateway MAY=0A use the IDr value = in the ticket for policy decisions.=0A o The SPI values are created anew= , similarly to a regular IKE=0A exchange. They are NOT reused from th= e ticket.=0A=0A The cryptographic material is refreshed based on the tick= et and the=0A nonce values. The new value of SKEYSEED is derived as foll= ows:=0A=0A SKEYSEED =3D prf+(SK_d_old, Ni | Nr)=0A=0A=0A=0ASheffer = Expires July 12, 2007 [Page 7]=0A=0C=0AInt= ernet-Draft IKE Session Resumption January 2007=0A=0A= =0A Where SK_d_old is the value retrieved from the ticket.=0A=0A The ke= ys are derived as follows, unchanged from IKEv2:=0A=0A {SK_d | SK_ai = | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} =3D=0A = prf+(SKEYSEED, Ni | Nr | SPIi | SPIr)=0A=0A Where SPIi, SPIr are t= he SPI values created in the new IKE exchange.=0A=0A See [RFC4306] for th= e notation. "prf" is determined from the SA value=0A in the ticket.=0A=0A= 3.7. Deriving the AUTH Values=0A=0A The AUTH value is derived similarly = to the case of a normal IKE pre-=0A shared secret.=0A=0A AUTH = =3D prf(SK_px, )=0A=0A Each of the initiator and responder us= es its own SK_p value, taken=0A from the newly generated IKE SA.=0A=0A = The material to be signed is defined exactly as in Sec. 2.15 of=0A [RFC43= 06]. The notation "IDr'" in RFC 4306 should be applied to the=0A new IDr= value included in the exchange, rather than the value in the=0A ticket.= =0A=0A3.8. Session Resumption and MOBIKE=0A=0A TBD.=0A=0A3.9. IKE Cooki= es=0A=0A The current extension eliminates much of the DOS potential that = the=0A cookie mechanism aims to solve. However memory exhaustion remains= a=0A possible issue. Therefore the cookie mechanism (RFC 4306, Sec. 2.6= )=0A MAY be invoked by the gateway for the modified IKE_INIT exchange=0A = described in Section 3.2 above.=0A=0A=0A4. The IKE Ticket=0A=0A This s= ection lists the required contents of the ticket, and=0A recommends a non= -normative format. This is followed by a discussion=0A of the ticket's l= ifecycle.=0A=0A=0A=0A=0A=0A=0ASheffer Expires July 12, 20= 07 [Page 8]=0A=0C=0AInternet-Draft IKE Session Re= sumption January 2007=0A=0A=0A4.1. Ticket Contents=0A=0A The= ticket MUST encode at least the following state from the IKE SA.=0A Thes= e values MUST be encrypted and authenticated.=0A=0A o IDi, IDr.=0A o = SPIi, SPIr.=0A o SAr (the accepted proposal).=0A o SK_d.=0A=0A In a= ddition, the ticket MUST encode a protected ticket expiration=0A value.= =0A=0A4.2. Ticket Format=0A=0A This document does not specify a ticket f= ormat. The following format=0A (this entire current section) is a RECOMM= ENDED implementation. The=0A client SHOULD NOT attempt to decode the tic= ket.=0A=0A struct {=0A opaque key_name[16]; // ASCII, null-term= inated=0A opaque IV[0..255]; // the length (possibly 0) depends= =0A // on the encryption algorithm=0A = [protected] struct {=0A opaque IDi, IDr; // the full payloads= =0A opaque SPIi, SPIr;=0A opaque SA; // the f= ull payload, returned as SAr=0A opaque SK_d;=0A opaque = expiration; // an absolute time value=0A } ikev2_state; /= / encrypted and authenticated=0A opaque MAC[0..255]; // the leng= th (possibly 0) depends=0A // on the integri= ty algorithm=0A } ticket;=0A=0A=0A Note that the key defined by "key_na= me" determines the encryption and=0A integrity algorithms used for the ti= cket. These are unrelated to the=0A transforms defined by the SA payload= .=0A=0A4.3. Ticket Identity and Lifecycle=0A=0A The ticket is associated= with a single IKE SA. In particular, when=0A the IKE SA is deleted, the= client MUST delete its stored ticket.=0A=0A The ticket is therefore asso= ciated with the tuple (IDi, IDr). The=0A client MAY however use the tick= et to approach other gateways that are=0A likely to accept it. How the c= lient discovers such gateways is=0A outside the scope of this document.= =0A=0A=0A=0ASheffer Expires July 12, 2007 = [Page 9]=0A=0C=0AInternet-Draft IKE Session Resumption = January 2007=0A=0A=0A The lifetime included with the ticket in the N(T= ICKET/Opaque)=0A notification should be the minimum of the IKE SA lifetim= e (per the=0A gateway's local policy) and its re-authentication time, acc= ording to=0A [RFC4478]. Even if neither of these is enforced by the gate= way, a=0A finite lifetime MUST be specified for the ticket and SHOULD be = less=0A than 24 hours.=0A=0A=0A5. IANA Considerations=0A=0A o Notific= ation type (Section 3.5).=0A o Notification subtypes (Section 3.5).=0A= =0A=0A6. Security Considerations=0A=0A TBD. Include at least:=0A o D= OS resistance.=0A o Authentication of identities.=0A o Reuse of ticke= t from a terminated session.=0A o Strength of the ticket protection stro= nger than the protected=0A data.=0A o Time synchronization between = gateways.=0A=0A=0A7. Change Log=0A=0A7.1. -00=0A=0A Initial version.=0A= =0A=0A8. Acknowledgements=0A=0A We would like to thank Pasi Eronen and Y= oav Nir for their review of=0A early drafts.=0A=0A=0A9. References=0A=0A= 9.1. Normative References=0A=0A [RFC2119] Bradner, S., "Key words for u= se in RFCs to Indicate=0A Requirement Levels", BCP 14, RFC 211= 9, March 1997.=0A=0A [RFC4301] Kent, S. and K. Seo, "Security Architectu= re for the=0A Internet Protocol", RFC 4301, December 2005.=0A= =0A=0A=0A=0ASheffer Expires July 12, 2007 = [Page 10]=0A=0C=0AInternet-Draft IKE Session Resumption = January 2007=0A=0A=0A [RFC4306] Kaufman, C., "Internet Key Exchange (= IKEv2) Protocol",=0A RFC 4306, December 2005.=0A=0A9.2. Infor= mative References=0A=0A [I-D.friedman-ike-short-term-certs]=0A = Friedman, A., "Short-Term Certificates",=0A draft-friedman-= ike-short-term-certs-01 (work in progress),=0A December 2006.= =0A=0A [I-D.vidya-ipsec-failover-ps]=0A Narayanan, V., "IPse= c Gateway Failover and Redundancy -=0A Problem Statement and G= oals",=0A draft-vidya-ipsec-failover-ps-00 (work in progress),= =0A December 2006.=0A=0A [RFC4478] Nir, Y., "Repeated Authe= ntication in Internet Key Exchange=0A (IKEv2) Protocol", RFC 4= 478, April 2006.=0A=0A [RFC4507] Salowey, J., Zhou, H., Eronen, P., and = H. Tschofenig,=0A "Transport Layer Security (TLS) Session Resu= mption without=0A Server-Side State", RFC 4507, May 2006.=0A= =0A [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and=0A = Implementation Guidelines", RFC 4718, October 2006.=0A=0A=0AAuth= or's Address=0A=0A Yaron Sheffer=0A Check Point Software Technologies L= td.=0A 3A Jabotinsky St.=0A Ramat Gan 52520=0A Israel=0A=0A Email:= yaronf at checkpoint dot com=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A= =0ASheffer Expires July 12, 2007 [Page 11]= =0A=0C=0AInternet-Draft IKE Session Resumption Januar= y 2007=0A=0A=0AFull Copyright Statement=0A=0A Copyright (C) The Internet = Society (2007).=0A=0A This document is subject to the rights, licenses an= d restrictions=0A contained in BCP 78, and except as set forth therein, t= he authors=0A retain all their rights.=0A=0A This document and the info= rmation contained herein are provided on an=0A "AS IS" basis and THE CONT= RIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0A OR IS SPONSORED BY (IF ANY= ), THE INTERNET SOCIETY AND THE INTERNET=0A ENGINEERING TASK FORCE DISCLA= IM ALL WARRANTIES, EXPRESS OR IMPLIED,=0A INCLUDING BUT NOT LIMITED TO AN= Y WARRANTY THAT THE USE OF THE=0A INFORMATION HEREIN WILL NOT INFRINGE AN= Y RIGHTS OR ANY IMPLIED=0A WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A= PARTICULAR PURPOSE.=0A=0A=0AIntellectual Property=0A=0A The IETF takes n= o position regarding the validity or scope of any=0A Intellectual Propert= y Rights or other rights that might be claimed to=0A pertain to the imple= mentation or use of the technology described in=0A this document or the e= xtent to which any license under such rights=0A might or might not be ava= ilable; nor does it represent that it has=0A made any independent effort = to identify any such rights. Information=0A on the procedures with respe= ct to rights in RFC documents can be=0A found in BCP 78 and BCP 79.=0A=0A= Copies of IPR disclosures made to the IETF Secretariat and any=0A assu= rances of licenses to be made available, or the result of an=0A attempt m= ade to obtain a general license or permission for the use of=0A such prop= rietary rights by implementers or users of this=0A specification can be o= btained from the IETF on-line IPR repository at=0A http://www.ietf.org/ip= r.=0A=0A The IETF invites any interested party to bring to its attention = any=0A copyrights, patents or patent applications, or other proprietary= =0A rights that may cover technology that may be required to implement=0A= this standard. Please address the information to the IETF at=0A ietf-= ipr@ietf.org.=0A=0A=0AAcknowledgment=0A=0A Funding for the RFC Editor fun= ction is provided by the IETF=0A Administrative Support Activity (IASA).= =0A=0A=0A=0A=0A=0ASheffer Expires July 12, 2007 = [Page 12]=0A=0C=0A=0A --23726882-14259-1168271437=:7164 Content-type: TEXT/html; CHARSET=US-ASCII Content-transfer-encoding: QUOTED-PRINTABLE Content-description: draft-sheffer-ike-session-resumption-00-v1.html Content-disposition: attachment; filename="draft-sheffer-ike-session-resumption-00-v1.html" =0AStateless Sess= ion Resumption for the IKE Protocol=0A=0A=0A=0A=0A=0A=0A TOC =0A
=0A= =0A=0A=0A=0A=
Network Working GroupY. Sheffer
Internet-DraftCh= eck Point
Intended status: Standards T= rackJanuary 8, 2007
Expires: July 12, 2007 
=0A


Stateless Session Resumption for the= IKE Protocol
draft-sheffer-ike-session-resumption-00

=0A=0A

St= atus of this Memo

=0A

=0ABy submitting this Internet-Draft,=0Aeach au= thor represents that any applicable patent or other IPR claims of which=0Ah= e or she is aware have been or will be disclosed,=0Aand any of which he or = she becomes aware will be disclosed,=0Ain accordance with Section 6 of= BCP 79.

=0A

=0AInternet-Drafts are working documents of the Inte= rnet Engineering=0ATask Force (IETF), its areas, and its working groups.=0A= Note that other groups may also distribute working documents as=0AInternet-= Drafts.

=0A

=0AInternet-Drafts are draft documents valid for a maximum= of six months=0Aand may be updated, replaced, or obsoleted by other docume= nts at any time.=0AIt is inappropriate to use Internet-Drafts as reference = material or to cite=0Athem other than as “work in progress.”=0A

=0AThe list of current Internet-Drafts can be accessed at=0Ahttp://www.ietf.org/ietf/1i= d-abstracts.txt.

=0A

=0AThe list of Internet-Draft Shadow Director= ies can be accessed at=0Ahttp:/= /www.ietf.org/shadow.html.

=0A

=0AThis Internet-Draft will expire = on July 12, 2007.

=0A=0A

Copyright Notice

=0A

=0ACopyright &cop= y; The Internet Society (2007).

=0A=0A

Abstract

=0A=0A

In many = failure cases it is useful to resume an interrupted IKE/IPsec session.=0A = We propose an extension to IKEv2 that allows a client to establish an= IKE SA with=0A a gateway in a highly efficient manner, utilizing a = prior IKE SA.=0A A client=0A can reconnect to a gateway from = which it was disconnected, or else it can migrate to another gateway. =0A = The solution is stateless: no per-client state is required on the gat= eway=0A until the IKE SA is reestablished. This is=0A done by= retaining parts of the IKE SA in a protected ticket stored on the client.= =0A =0A


=0A

Table of Contents<= /h3>=0A

=0A1. =0ARequirements= Notation
=0A2. =0AIntroduction
=0A=     2.1. =0AGoals
= =0A    2.2. =0ANon Goals<= br />=0A    2.3. =0AOur A= pproach and Related Work
=0A3. =0AProtoc= ol Details
=0A    3.1.&nb= sp;=0AOverview: Acquiring a Ticket
=0A    3.2. =0AOverview: Presenting a Ticket
=0A&nb= sp;   3.3. =0AAdditional Detai= ls: Acquiring a Ticket
=0A    3.4. =0AAdditional Details: Presenting a Ticket
=0A &nb= sp;  3.5. =0AIKE Notification= s
=0A    3.6. =0AThe = New IKE SA
=0A    3.7. =0ADeriving the AUTH Values
=0A    3.8. =0ASession Resumption and MOBIKE
=0A = ;   3.9. =0AIKE Cookies
= =0A4. =0AThe IKE Ticket
=0A  =   4.1. =0ATicket Contents
=0A=     4.2. =0ATicket Format<= br />=0A    4.3. =0ATic= ket Identity and Lifecycle
=0A5. =0AIAN= A Considerations
=0A6. =0ASecurity Cons= iderations
=0A7. =0AChange Log
=0A=     7.1. =0A-00
=0A= 8. =0AAcknowledgements
=0A9. =0AReferences
=0A    <= a href=3D"#rfc.references1">9.1. =0ANormative References
=0A&= nbsp;   9.2. =0AInform= ative References
=0A§ =0AAuthor= 's Address
=0A§ =0AIntellectu= al Property and Copyright Statements
=0A

=0A
=0A= =0A
=0A
 TOC 
=0A

1. =0ARequirements Notation

=0A=0A

T= he key words "MUST", "MUST NOT", "REQUIRED", "SHALL",=0A "SHALL = NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",=0A and "OPTI= ONAL" in this document are to be interpreted as=0A described in = [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement= Levels,” March 1997.).=0A

=0A
=0A
 TOC 
=0A

2. =0AIntroduction

=0A=0A
=0A
 TOC 
=0A=

2.1. =0AGoals

=0A=0A

=0AThe high-level goal of this extensio= n is to become a building block of an overall IPsec failover solution,=0Aac= cording to the requirements put down in [I‑D.vidya‑ipsec‑failover‑ps]<= span> (Narayanan, V., “IPsec Gateway Fail= over and Redundancy - Problem Statement and Goals,” December 200= 6.).=0A=0A

=0A

=0ASpecifically, the proposed e= xtension should allow IPsec sessions to recover from failures=0Ain the remo= te access scenario,=0Aand do it much more efficiently than the basic IKE so= lution.=0AThis efficiency is primarily on the gateway side,=0Asince the gat= eway might have to deal with many thousands of concurrent requests.=0AWe sh= ould enable the following cases:=0A=0A

=0A

=0A

=0A
    =0A
  • Failover from one gateway to another, where the two gateways do no= t share state (but do have mutual trust).=0AFor example, the gateways may b= e located at a geographical distance from one another.=0A
    • =0A
  • Recove= ry from an intermittent connectivity failure ("network reboot"), where the = clients=0Areconnect into the same gateway.=0AIn this case the gateway would= typically had detected the clients' absence and removed the=0Astate associ= ated with them.=0A
    • =0A
  • Recovery from a gateway restart, where client= s reconnect into the same gateway.=0A
    • =0A

=0A=0A

=0A

=0AThe= proposed solution should additionally meet the following goals:=0A=0A

= =0A

=0A

=0A
    =0A
  • In the normal case, use only symm= etric crypto to minimize CPU consumption.=0A
    • =0A
  • Be stateless, so th= at the gateway does not need to maintain state for clients that may have ro= amed away.=0A
    • =0A
  • Provide crypto agility.=0A
    • =0A
  • Have no secu= rity impact on IKE. Specifically, the solution must not create new DOS risk= s.=0A
    • =0A

=0A=0A

=0A
=0A TOC = =0A

2.2. =0AN= on Goals

=0A=0A

=0AThe following are non-goals of this solution:=0A=0A

    =0A
  • Provide for load balancing among gateways.= =0A
    • =0A
  • Specify how the client detects the need for failover.=0A=0A
  • Allow for trust establishment and/or state synchronization between = gateways.=0A
    • =0A

=0A

=0A
= =0A
 TOC&= nbsp;
=0A

2.3. = ;=0AOur Approach and Related Work

=0A=0A

=0A We propose to maintain I= KEv2 state in a "ticket", an opaque data structure maintained on the client= ,=0A but one which the client cannot read or modify. We extend the IKEv2 pr= otocol to allow the client=0A to request and/or present the ticket. When tw= o gateways are mutually trusting,=0A one can accept a ticket which was gene= rated earlier by the other.=0A =0A

=0A

=0A This approach is similar to= the one taken for TLS session resumption [RFC4507] (Salowey, J., Zhou, H., Eron= en, P., and H. Tschofenig, “Transport Layer Security (TLS) Session Re= sumption without Server-Side State,” May 2006.)=0A with the required adaptations for IKE, e.g. to accommodate the t= wo-phase protocol structure.=0A We have borrowed heavily from that specific= ation.=0A =0A

=0A

=0A An on-going work [I‑D.friedman‑ike‑short= 209;term‑certs] (Friedman, A., &ldq= uo;Short-Term Certificates,” December 2006.)= discusses=0A the use of short-term certificates for client re-authenti= cation.=0A This has some similarities to the current work, and the followin= g differences.=0A Short-term certificates require a smaller change to IKE c= ompared to stateless tickets,=0A since the certificates obtained are=0A val= id for any IKE responder and in fact when they are presented,=0A the protoc= ol is the "plain vanilla" IKEv2. For the same reason, short-term certificat= es,=0A while eliminating the usability issues of user re-authentication, do= not reduce the amount of effort=0A performed by the gateway in failover si= tuations.=0A =0A

=0A
=0A
 TOC 
=0A

3. =0AProtocol Details=

=0A=0A

We start this section by describing the two typical cases:=0A= obtaining and presenting an IKE ticket. Then we expand on these cases.=0ATh= is is followed by syntactic details and additional considerations.=0A=0A=0A

=0A
 TOC 
=0A

3.1. =0AOverview: Acquiring a Ticket=0A=0A

Normally, a client requests a ticket in the third message of IK= E=0A(the first of IKE_AUTH), and receives the ticket when authentication is= complete.=0A

=0A        Initiator                Responder=0A  =
     -----------              -----------=0A         --> IDi, N(TICKET/R=
equest), SA, TSi, TSr=0A                                <-- IDr, AUTH, E=
AP=0A                            ...=0A                                <=
-- AUTH, N(TICKET/Opaque), SA, TSi, TSr=0A
=0A

=0ANote that a = large number of optional notifications are omitted for clarity,=0Asee [RFC4718] (Eronen, P. and P. Hoffman, “IKEv2 Clarifications and Implementation = Guidelines,” October 2006.) for details.= The notifications are defined in Section 3.5 (IKE Notifications) below.=0A=0A

=0A
=0A
 = ;TOC 
=0A

3.2.=  =0AOverview: Presenting a Ticket

=0A=0A

Following an extended = communication failure, the client re-initiates an IKE exchange to the=0Asam= e gateway or to a different one, and includes a ticket in the first message= of IKE_SA_INIT.=0A

=0A         --> SA, KE, Ni, N(TICKET/Opaq=
ue)=0A
=0A

=0AIf the gateway supports this extension and is wi= lling to accept the ticket, it responds with:=0A=0A

=0A         =
                       <-- SA, Nr, N(TICKET/Ack)=0A
=0A

=0A= The KE payload is omitted in the response, however Ni and Nr are still used= for freshness.=0A=0A

=0A

=0AAt this point a new IKE SA is created by = both parties (see Section 3.6= (The New IKE SA)),=0Aa= nd used for the following IKE_AUTH exchange. This IKE SA is still unauthent= icated.=0ABoth parties now sign the exchange:=0A=0A

=0A         =
--> IDi, [IDr,] AUTH=0A                                <-- IDr, AUTH=
=0A
=0A

=0ASee Section=  3.7 (Deriving the AUTH Values) for the derivation of the AUTH values from the message = bytes,=0Athe ticket and the nonce values.=0AThe gateway and the client MUST= verify the AUTH values they receive.=0AThe new IKE SA only becomes fully v= alid once each party has verified the other party's signature.=0AIf either = side receives an incorrect AUTH value, it MUST terminate the protocol.=0A= =0A

=0A

=0AAlternatively and more efficiently, the IKE_AUTH exchange c= an be piggybacked=0Ainto a CREATE_CHILD_SA exchange:=0A=0A

=0A  =
    =09 --> IDi, [IDr,] AUTH, SAi2, Ni2, TSi, TSr [, CP(CFG_REQUEST)]=0A=
                    <-- IDr, AUTH, SAr2, Nr2, TSi, TSr [, CP(CFG_REPLY)]=
=0A
=0A

=0AThe Child SA values here (SAi2, Ni2 etc.) should no= t be confused with the similar values for the IKE SA.=0AThis document only = discusses the values related to the IKE SA.=0A=0A

=0A
=0A
 TOC 
=0A=

3.3. =0AAdditional Details: Acquiring a Ticket

=0A=0A

= =0AA client MAY request a ticket in the following exchanges:=0A=0A

=0A=0A

=0A
    =0A
  • In an IKE_AUTH exchange, as described = above.=0A
    • =0A
  • In a CREATE_CHILD_SA exchange, when it is used to reke= y the IKE SA.=0A
    • =0A
  • In an Informational exchange, if the gateway pr= eviously replied with an N(TICKET/Ack)=0Ainstead of providing a ticket.=0A<= /li>=0A
  • In an Informational exchange, when the ticket expires.=0A
    • = =0A

=0A=0A

=0A

=0AIt makes sense to request and use a ticket wh= en IKE is used with non-EAP forms of authentication.=0AThese cases are not = defined in the current document.=0A=0A

=0A

=0AThe gateway normally gra= nts a ticket using N(TICKET/Opaque).=0AIt may instead use the same message = to reply with:=0A=0A

=0A

=0A

=0A
    =0A
  • N(TICKET/= Nack), if it refuses to grant a ticket for some reason.=0A
    • =0A
  • N(TIC= KET/Ack), if it cannot grant a ticket immediately, e.g.=0Abecause that woul= d make the packet too large.=0AIn that case the client MAY request a ticket= later using an Informational exchange,=0Aat any time during the lifetime o= f the IKE SA.=0A
    • =0A

=0A=0A

=0A
=
=0A
&nbs= p;TOC 
=0A

3.4= . =0AAdditional Details: Presenting a Ticket

=0A=0A

=0AA client = MAY initiate a regular (non-ticket) IKE exchange even if it is in possessio= n of a valid ticket.=0AA client MUST NOT present a ticket after its lifetim= e has expired.=0A=0A

=0A

=0AIf the gateway does not accept the ticket = for any reason, it MUST respond with an N(TICKET/Nack) notification.=0AIf t= he gateway responds with N(TICKET/Nack), it MUST include the KE payload to = allow for a regular IKE exchange.=0AA client receiving an N(TICKET/Nack) no= tification MUST discard the ticket and continue with a full,=0Aregular IKE = exchange. It MAY request a new ticket later in the exchange.=0A=0A

=0A=0AIf the gateway responds with a standard IKE_INIT message #2,=0Athis may= indicate that the gateway does not implement this extension.=0AIn this cas= e, the client SHOULD NOT discard the ticket.=0A=0A

=0A

=0AIf the gatew= ay receives a ticket for an IKE SA that is still active,=0Ait SHOULD silent= ly delete the old SA without sending a DELETE Informational exchange.=0A=0A=

=0A

=0AIf the gateway receives a ticket for an IKE SA that has previo= usly been terminated on this same gateway,=0Athis may indicate inconsistent= state between the client and the gateway.=0AThe gateway SHOULD respond wit= h an N(TICKET/Nack) notification and proceed to a full IKE exchange.=0AA ga= teway is not required to maintain state for terminated sessions.=0A=0A

= =0A
=0A TOC 
=0A=

3.5. =0AIKE Notifications

=0A= =0A

=0AWe define a single notification type, TICKET, with a number of sub= types.=0AThe notification number is TBD by IANA. The subtypes are listed be= low.=0A=0A

=0A=0A=0A=0A=0A=0A= =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A5-127=0A=0A=0A= =0A=0A=0A= =0A=0A
Subtype NameNumberData
= Opaque1See below
Request2=0ANone
Ack=0A3None
Nack4None
Reserved 
Private Use128-255 
=0A=0A

=0AThe data for t= he Opaque subtype consists of a lifetime duration in seconds=0A(4 octets, d= enoting the time until the ticket expires), followed by the ticket.=0ASee <= a class=3D'info' href=3D'#lifecycle'>Section 4.3 (Ticket Identity and Lifecycle) for fu= rther guidelines regarding the ticket's lifetime,=0Aand Section 4.2 (Ticket = Format) for a recommended ticket format.=0A=0A

= =0A
=0A
 TOC 
=0A

3.6. =0AThe New IKE SA

=0A=0A

=0AW= hen a ticket is presented, the gateway derives the new IKE SA from the info= rmation contained in the ticket,=0Aand the client from its local store:=0A= =0A

=0A

=0A

=0A
    =0A
  • The SA value (transforms e= tc.) is taken directly from the ticket.=0A
    • =0A
  • The sequence numbers = are reset to 0.=0A
    • =0A
  • The IDi value is obtained from the new exchan= ge. It must be unchanged,=0Ai.e. the gateway MUST verify that this value is= identical to the value encoded in the ticket.=0A
    • =0A
  • The IDr value = is obtained from the new exchange. The gateway MAY use the IDr value in the= ticket=0Afor policy decisions.=0A
    • =0A
  • The SPI values are created an= ew, similarly to a regular IKE exchange. They are NOT reused from the ticke= t.=0A
    • =0A

=0A=0A

=0A

=0AThe cryptographic material is refre= shed based on the ticket and the nonce values.=0AThe new value of SKEYSEED = is derived as follows:=0A=0A

=0A     SKEYSEED =3D prf+(SK_d_old,=
 Ni | Nr)=0A
=0A

=0AWhere SK_d_old is the value retrieved from= the ticket.=0A=0A

=0A

=0AThe keys are derived as follows, unchanged f= rom IKEv2:=0A=0A

=0A     {SK_d | SK_ai | SK_ar | SK_ei | SK_er |=
 SK_pi | SK_pr} =3D=0A                                 prf+(SKEYSEED, Ni | =
Nr | SPIi | SPIr)=0A
=0A

=0AWhere SPIi, SPIr are the SPI value= s created in the new IKE exchange.=0A=0A

=0A

=0ASee [RFC4306] (Kaufman, C.,= “Internet Key Exchange (IKEv2) Protocol,” December 2005.<= /span>) for the notation. "prf" is determined from the SA = value in the ticket.=0A=0A

=0A
= =0A
 TOC&= nbsp;
=0A

3.7. = ;=0ADeriving the AUTH Values

=0A=0A

=0AThe AUTH value is derived simi= larly to the case of a normal IKE pre-shared secret.=0A=0A

=0A  =
       AUTH =3D prf(SK_px, <msg octets>)=0A
=0A

=0AEach = of the initiator and responder uses its own SK_p value, taken from the newl= y generated IKE SA.=0A=0A

=0A

=0AThe material to be signed is defined = exactly as in Sec. 2.15 of [RFC4306] (Kaufman, C., “Internet Key Exchange = (IKEv2) Protocol,” December 2005.).=0ATh= e notation "IDr'" in RFC 4306 should be applied to the new IDr value includ= ed in the exchange,=0Arather than the value in the ticket.=0A=0A

=0A
=0A
 TOC 
=0A

3.8. =0ASession Resumption and MOBIKE

= =0A=0A

=0ATBD.=0A=0A

=0A
=0A TOC = =0A

3.9. =0AIKE C= ookies

=0A=0A

=0AThe current extension eliminates much of the DOS pot= ential that the cookie mechanism aims to solve.=0AHowever memory exhaustion= remains a possible issue.=0ATherefore the cookie mechanism (RFC 4306, Sec.= 2.6) MAY be invoked by the gateway for the=0Amodified IKE_INIT exchange de= scribed in Section 3.2 (<= /span>Overview: Presenting a Ticket) above.=0A=0A

=0A
=0A
 TOC 
=0A

4. =0AThe IKE Tick= et

=0A=0A

=0AThis section lists the required contents of the ticket, = and recommends a non-normative format.=0AThis is followed by a discussion o= f the ticket's lifecycle.=0A=0A

=0A
= =0A
 TOC&= nbsp;
=0A

4.1. = ;=0ATicket Contents

=0A=0A

=0AThe ticket MUST encode at least the fol= lowing state from the IKE SA. These values MUST be=0Aencrypted and authenti= cated.=0A=0A

=0A

=0A

=0A
    =0A
  • IDi, IDr.=0A
    • = =0A
  • SPIi, SPIr.=0A
    • =0A
  • SAr (the accepted proposal).=0A
    • =0ASK_d.=0A=0A

=0A=0A

=0A

In addition, the ticket MUST encod= e a protected ticket expiration value.=0A

=0A
=0A
&n= bsp;TOC 
=0A

4= .2. =0ATicket Format

=0A=0A

=0AThis document does not specify a = ticket format. The following format (this entire current section)=0Ais a RE= COMMENDED implementation. The client SHOULD NOT attempt to decode the ticke= t.=0A=0A

=0Astruct {=0A    opaque key_name[16];     // ASCII, nu=
ll-terminated=0A    opaque IV[0..255];       // the length (possibly 0) dep=
ends=0A                             // on the encryption algorithm=0A    [p=
rotected] struct {=0A        opaque IDi, IDr;     // the full payloads=0A  =
      opaque SPIi, SPIr;=0A        opaque SA;           // the full payload=
, returned as SAr=0A        opaque SK_d;=0A        opaque expiration;   // =
an absolute time value=0A    } ikev2_state;           // encrypted and auth=
enticated=0A    opaque MAC[0..255];      // the length (possibly 0) depends=
=0A                             // on the integrity algorithm=0A} ticket;=
=0A=0A
=0A

=0ANote that the key defined by "key_name" determin= es the encryption and integrity algorithms=0Aused for the ticket. These are= unrelated to the transforms defined by the SA payload.=0A=0A

=0A
=0A
 TOC 
=0A

4.3. =0ATicket Identity and Lifecycle

=0A=0A=

=0AThe ticket is associated with a single IKE SA. In particular, when th= e IKE SA is deleted,=0Athe client MUST delete its stored ticket.=0A=0A

= =0A

=0AThe ticket is therefore associated with the tuple (IDi, IDr).=0ATh= e client MAY however use the ticket to approach other gateways that are lik= ely to accept it.=0AHow the client discovers such gateways is outside the s= cope of this document.=0A=0A

=0A

=0AThe lifetime included with the tic= ket in the N(TICKET/Opaque) notification should be=0Athe minimum of the IKE= SA lifetime (per the gateway's local policy)=0Aand its re-authentication t= ime, according to [RFC4478] (Nir, Y., “Repeated Authentication in Internet= Key Exchange (IKEv2) Protocol,” April 2006.).=0AEven if neither of these is enforced by the gateway,=0Aa finite li= fetime MUST be specified for the ticket and SHOULD be less than 24 hours.= =0A=0A

=0A
=0A=0A

5. =0AIANA Considerations

= =0A=0A

=0A

=0A

=0A=0A

=0A
= =0A
 TOC 
 TOC&= nbsp;
=0A

6. =0A= Security Considerations

=0A=0A

TBD. Include at least:=0A

=0A
    =0A
  • DOS resistance.=0A
    • =0A
  • Authentication of identit= ies.=0A
    • =0A
  • Reuse of ticket from a terminated session.=0A
    • =0AStrength of the ticket protection stronger than the protected data.=0A=0A
  • Time synchronization between gateways.=0A
    • =0A

=0A

= =0A
=0A
 TOC 
=0A

7. =0AChange Log

=0A=0A
=0A
 TOC 
=0A

7.1. =0A-00

=0A=0A

=0A Initial version.=0A = =0A

=0A
=0A=0A

8. =0AAcknowledgements

= =0A=0A

=0AWe would like to thank Pasi Eronen and Yoav Nir for their revie= w of early drafts.=0A=0A

=0A
= =0A
 TOC 
 TOC&= nbsp;
=0A

9. =0A= References

=0A=0A
=0A
 TOC <= /td>
=0A

9.1. Normative References

=0A=0A=0A=0A=0A=0A=0A=0A
[RFC2119]Bradner, S., “Key words for use in RFCs to Indicate Requirement Lev= els,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC4301]Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,&= rdquo; RFC 4301, December 2005.
[RFC4306]Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” RFC 43= 06, December 2005.
=0A=0A
=0A
 TOC 
=0A

9.2. Informative= References

=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A
[I-= D.friedman-ike-short-term-certs]Fried= man, A., “Short-Term Certificates,” draft-f= riedman-ike-short-term-certs-01 (work in progress), December 2006.
[I-D.vidya-ipsec-failover-ps]Narayanan, V., “IPsec Gateway Failover and Redun= dancy - Problem Statement and Goals,” draft-vidya-ipsec-failover-= ps-00 (work in progress), December 2006.
[RFC4478]Nir, Y., “Repeated Authentication in Internet Key Exchange (IKEv2) Protoc= ol,” RFC 4478, April 2006.
[RFC4507]Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, = “Transport Layer S= ecurity (TLS) Session Resumption without Server-Side State,” RFC&= nbsp;4507, May 2006.
[RFC4718]Eronen, P. and P. Hoffman, “IKEv2 Clarifications and Implementation Guidelines,” R= FC 4718, October 2006.
=0A=0A
=0A
 TOC 
=0A

Author's Address<= /h3>=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A
 = Yaron Sheffer
 Check Point Software Technologies Ltd.
 3A Jabot= insky St.
 Ramat Gan 52520
 Israel
Email: <= a href=3D"mailto:yaronf at checkpoint dot com">yaronf at checkpoint dot com=
=0A
=0A TOC = =0A

Full Copyright Statement

=0A

=0ACopyright © The Internet Society (2007).

=0A

=0AThis document is subject to the rights,=0Alicenses and restr= ictions contained in BCP 78,=0Aand except as set forth therein,=0Athe = authors retain all their rights.

=0A

=0AThis docum= ent and the information contained herein are provided=0Aon an “AS IS&= rdquo; basis and THE CONTRIBUTOR,=0ATHE ORGANIZATION HE/SHE REPRESENTS OR I= S SPONSORED BY (IF ANY),=0ATHE INTERNET SOCIETY AND THE INTERNET ENGINEERIN= G TASK FORCE DISCLAIM=0AALL WARRANTIES,=0AEXPRESS OR IMPLIED,=0AINCLUDING B= UT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=0AINFORMATION HEREIN WIL= L NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0AWARRANTIES OF MERCHANTABILITY OR= FITNESS FOR A PARTICULAR PURPOSE.

=0A

Intellectual Property

=0A<= p class=3D'copyright'>=0AThe IETF takes no position regarding the validity = or scope of any=0AIntellectual Property Rights or other rights that might b= e claimed=0Ato pertain to the implementation or use of the technology=0Ades= cribed in this document or the extent to which any license=0Aunder such rig= hts might or might not be available; nor does it=0Arepresent that it has ma= de any independent effort to identify any=0Asuch rights.=0AInformation on t= he procedures with respect to=0Arights in RFC documents can be found in BCP=  78 and BCP 79.

=0A

=0ACopies of IPR dis= closures made to the IETF Secretariat and any=0Aassurances of licenses to b= e made available,=0Aor the result of an attempt made to obtain a general li= cense or=0Apermission for the use of such proprietary rights by implementer= s or=0Ausers of this specification can be obtained from the IETF on-line IP= R=0Arepository at http://www.ietf.org/i= pr.

=0A

=0AThe IETF invites any interested par= ty to bring to its attention=0Aany copyrights,=0Apatents or patent applicat= ions,=0Aor other=0Aproprietary rights that may cover technology that may be= required=0Ato implement this standard.=0APlease address the information to= the IETF at ietf-ipr@ietf.org.=0A

Acknowledgment

=0A

=0AFunding for the RFC= Editor function is provided by=0Athe IETF Administrative Support Activity = (IASA).

=0A=0A=0A --23726882-14259-1168271437=:7164-- From owner-ietf-ipsec-failover Tue Jan 16 20:32:21 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0H3WLvw013044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jan 2007 20:32:21 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l0H3WLXA013043; Tue, 16 Jan 2007 20:32:21 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0H3WKlv013036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 16 Jan 2007 20:32:20 -0700 (MST) (envelope-from vidyan@qualcomm.com) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0H3W0Le021688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Jan 2007 19:32:00 -0800 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0H3VvJd027953; Tue, 16 Jan 2007 19:31:57 -0800 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 19:31:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: [Ipsec] IPsec Failover Problem Statement Date: Tue, 16 Jan 2007 19:31:56 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ipsec] IPsec Failover Problem Statement Thread-Index: Acc0HEec95vmcb7wRwyJFN4cAtWbJQFwgmJg From: "Narayanan, Vidya" To: "Stephen Kent" Cc: , X-OriginalArrivalTime: 17 Jan 2007 03:31:57.0689 (UTC) FILETIME=[0AA15690:01C739E8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l0H3WKlu013037 Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Steve, Thanks for the review and comments. Sorry for the delay in responding. It looks like this email never made it on the list - so, I'll try to summarize your comments and respond to them here. 1. The term IPsec "server" is not defined in 4301, so why is it used here? This term is used to refer to an application server that uses IPsec to protect the application signaling. From an IPsec perspective, this is no different than a host implementation of IPsec. However, availability becomes important due to the entity functioning as an application server. But, we don't need to use this term as such - we can stick with RFC4301 terminology and still clarify this. We'll update the draft accordingly. 2. "In the reverse direction, the VPN gateway uses the security policy database (SPD) or associated caches **[STK_2: as per 4301]** to lookup the relevant IPsec SA, encapsulates the packets and sends to the appropriate VPN client." Okay. 3. "In the security gateway mode, while there may be multiple security gateways serving a number of remote endpoints, a given remote endpoint is typically served by one security gateway." [STK_3: Not typically, ALWAYS. 4301 notes that an SA terminates at one SG to ensure that fragments all arrive at the same place for reassembly.] Will correct the wording. 4. "In all these cases outlined above, it is feasible to perform secure IPsec and IKEv2 state transfer across endpoints to provide smoother failure recovery" [STK_4: Secure relative to what standard? Are these products evaluated under FIPS 140-2, and if so, at what level of evaluation?] The term "secure" is used here in the context of the internet threat model, as documented by RFC3552. We will reword to clarify that. 5. "In cases where EAP is used for client authentication, the failover should not require EAP authentication, to avoid AAA overloading and possible user interaction." [STK_5: The EAP aspects of this problem seem somewhat independent of the IPsec aspects, since the two protocols are largely independent.] It is true that the EAP aspects are different from the IPsec aspects. However, IKEv2 does support client authentication via EAP and since one of the primary goals here is to allow a faster failover, this is a reasonable goal. As stated, this is particularly referring to the case where EAP is used for client authentication in IKEv2 - perhaps clarifying that we are referring to IKEv2 there would help? 6. "Stateless Gateway Operation: The IPsec failover mechanism should specify a mode of operation that will allow the backup gateways to remain stateless until a failover occurs or during a temporary service interruption.This will allow for better scalability of the solution, since a given gateway only needs to store state for clients that are being served by it." [STK_6: If a gateway that fails has not transferred keys and SA data to another gateway, this suggests that the clients will have to effect such a transfer. But, there may be adverse security implications of requiring that a client can effect such transfer.] The basic thought here is to have a solution that allows a server side operation analogous to stateless TLS session resumption (RFC4507). There are definitely more security implications to consider as you say - especially with respect to revocation of the SA, replays of the tickets issued, etc. However, one of the major benefits of this is that it allows for a distributed failover mechanism without the need for storing unnecessary state. We should discuss this further in the context of the solution design. 7. "First, any SA storage and retrieval mechanisms specified between the backend entities must be protected with a secure channel that has the following properties: confidentiality, integrity, and replay protection." [STK_7: How about access control? You need to explain requirements for sync of the SPD among the primary and alternate SGs, and how this works given the SPD cache model defined in 4301.] Yes, most certainly true. I saw that as an essential component of the solution and did not think the problem statement needed to get into that. This particular text is referring to the security considerations on the state transfer itself - that the gateway to gateway communication must be protected. 8. "Subsequently, the client must be able to verify the server's authorization by verifying the proof of possession of the IKEv2 key material at the new server" [STK_8: Clients do not verify the authority of a server based on possession of an IKEv2 key. Authorization for an SG to serve as a peer is defined in the PAD, e.g., based on certificate validation relative to a trust anchor configured in the PAD, or based on a PSK in the PAD. I assume you were not referring to the key bits produced by an IKE exchange. That would conflict with the stateless requirement established earlier, since an alternate SG would not possess the ephemeral D-H key used by the primary SG.] I believe the use of the term "authorization" in that statement is incorrect. It is only intended to refer to verifying the presence of the IPsec SA in the new server. We will reword to reflect that. Thanks, Vidya > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Tuesday, January 09, 2007 10:14 AM > To: Narayanan, Vidya > Subject: comments on your draft > > I sent this to the ipsec list, but it is held up due to the > size of the PDF. > > Steve > From owner-ietf-ipsec-failover Tue Jan 23 02:19:50 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0N9Jn0C095544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jan 2007 02:19:49 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l0N9Jn52095543; Tue, 23 Jan 2007 02:19:49 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from michael.checkpoint.com ([194.29.32.68]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0N9JkuS095520 for ; Tue, 23 Jan 2007 02:19:47 -0700 (MST) (envelope-from yaronf@checkpoint.com) Received: from yaronflap (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id l0N9JJhI000332; Tue, 23 Jan 2007 11:19:19 +0200 (IST) From: "Yaron Sheffer" To: , Subject: FW: I-D ACTION:draft-sheffer-ike-session-resumption-00.txt Date: Tue, 23 Jan 2007 11:19:19 +0200 Message-ID: <00be01c73ecf$90057e60$1e181fac@ad.checkpoint.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BF_01C73EE0.538E4E60" X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acc+Zw8yF8Fo5rOtSraQCMpuPSaPrgAZ1Tmg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_00BF_01C73EE0.538E4E60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I have just published this initial draft, together with Hannes and Tao. The draft relates to the new work (and upcoming BOF) on IPsec failover. We would appreciate your comments on the IPsec mailing list. Thanks, Yaron -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, January 22, 2007 22:50 To: i-d-announce@ietf.org Subject: I-D ACTION:draft-sheffer-ike-session-resumption-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Stateless Session Resumption for the IKE Protocol Author(s) : Y. Sheffer, et al. Filename : draft-sheffer-ike-session-resumption-00.txt Pages : 17 Date : 2007-1-22 The Internet Key Exchange version 2 (IKEv2) protocol is computationally intensive with respect to the number of round-trips required and cryptographic operations involved. In particular the Extensible Authentication Protocol is used for authentication, which adds additional computational intensity. To re-establish security associations (SA) upon a failure recovery condition is time comsuming, especially when an IPsec peer, such as a VPN gateway, needs to re-establish a large number of SAs with various end points. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA restablishment. In many failure cases it would be useful to provide an efficient way to resume an interrupted IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously establied IKE SA. A client can reconnect to a gateway from which it was disconnected, or alternatively migrate to another gateway that is associated with the previous one. The proposed approach conveys IKEv2 state information, in the form of an encrypted ticket, to a VPN client that is later presented to the VPN gateway for re-authentication. An encrypted ticket cannot be decrypted by a VPN client but allows a VPN gateway to restore state for faster session state setup. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sheffer-ike-session-resumption-00. txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-sheffer-ike-session-resumption-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-sheffer-ike-session-resumption-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_00BF_01C73EE0.538E4E60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have just published this initial draft, together with Hannes = and Tao. The draft relates to the new work (and upcoming BOF) on IPsec failover. = We would appreciate your comments on the IPsec mailing = list.

 

Thanks,

      = Yaron

 

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Monday, January 22, 2007 22:50
To: i-d-announce@ietf.org
Subject: I-D ACTION:draft-sheffer-ike-session-resumption-00.txt =

 

A New Internet-Draft is available from the on-line = Internet-Drafts

directories.

 

 

      = Title       : Stateless Session Resumption for the IKE = Protocol

      Author(s)   : Y. = Sheffer, et al.

      Filename    : draft-sheffer-ike-session-resumption-00.txt

      = Pages       : 17

      = Date        : 2007-1-22

     

   The Internet Key Exchange version 2 (IKEv2) = protocol is

   computationally intensive with respect to the = number of round-trips

   required and cryptographic operations = involved.  In particular the

   Extensible Authentication Protocol is used for authentication, which

   adds additional computational = intensity.

 

   To re-establish security associations (SA) upon a = failure recovery

   condition is time comsuming, especially when an = IPsec peer, such as a

   VPN gateway, needs to re-establish a large number = of SAs with various

   end points.  A high number of concurrent = sessions might cause

   additional problems for an IPsec peer during SA restablishment.

 

   In many failure cases it would be useful to provide = an efficient way

   to resume an interrupted IKE/IPsec session.  = This document proposes

   an extension to IKEv2 that allows a client to = re-establish an IKE SA

   with a gateway in a highly efficient manner, = utilizing a previously

   establied IKE SA.

 

   A client can reconnect to a gateway from which it = was disconnected,

   or alternatively migrate to another gateway that is associated with

   the previous one.  The proposed approach = conveys IKEv2 state

   information, in the form of an encrypted ticket, to = a VPN client that

   is later presented to the VPN gateway for re-authentication.  An

   encrypted ticket cannot be decrypted by a VPN = client but allows a VPN

   gateway to restore state for faster session state = setup.

 

 

 

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-sheffer-ike-ses= sion-resumption-00.txt

 

To remove yourself from the I-D Announcement list, send a = message to

i-d-announce-request@ietf.org with the word unsubscribe in the = body of

the message.

You can also visit = https://www1.ietf.org/mailman/listinfo/I-D-announce =

to change your subscription = settings.

 

Internet-Drafts are also available by anonymous FTP. Login with = the

username "anonymous" and a password of your e-mail = address. After

logging in, type "cd internet-drafts" and then =

"get = draft-sheffer-ike-session-resumption-00.txt".

 

A list of Internet-Drafts directories can be found = in

http://www.ietf.org/shadow.html

or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

 

Internet-Drafts can also be obtained by = e-mail.

 

Send a message to:

      = mailserv@ietf.org.

In the body type:

      "FILE /internet-drafts/draft-sheffer-ike-session-resumption-00.txt".<= /o:p>

     

NOTE: The mail server at ietf.org can return the document = in

      MIME-encoded form by using the "mpack" utility.  To use = this

      feature, insert the command "ENCODING mime" before the = "FILE"

      command.  To decode the response(s), you will need "munpack" = or

      a MIME-compliant mail = reader.  Different MIME-compliant mail readers

      exhibit different behavior, = especially when dealing with

      "multipart" MIME = messages (i.e. documents which have been split

      up into multiple messages), so = check your local documentation on

      how to manipulate these = messages.

 

Below is the data which will enable a MIME compliant mail = reader

implementation to automatically retrieve the ASCII version of = the

Internet-Draft.

------=_NextPart_000_00BF_01C73EE0.538E4E60-- From owner-ietf-ipsec-failover Fri Feb 2 15:22:13 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l12MMDqV055405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Feb 2007 15:22:13 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l12MMDnf055404; Fri, 2 Feb 2007 15:22:13 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l12MMBYb055398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 2 Feb 2007 15:22:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 2 Feb 2007 14:22:08 -0800 To: ietf-ipsec-failover@vpnc.org From: Paul Hoffman Subject: Proposed BOF charter and agenda Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greetings again. After talking a bit more with Russ Housley about how we can move forward with this work, I propose the following for a BOF charter: ============= IPsec gateways maintaining SAs with large number of remote access clients may take unacceptably long times to recover from gateway or network failures when all the clients were to use a full IKEv2 exchange to re-establish the SAs. This is especially true if EAP is used for client authentication in IKEv2. This concern particularly applies to application servers such as Mobile IP Home Agents that use IPsec. The SA re-establishment may be with the same gateway (server) from which the client gets disconnected or another gateway that is within the same secure domain as the original gateway. For the scope of this work, it is not assumed that the gateways in the secure domain share the same IP address or the same view of the network (connected to different DHCP servers etc.). Hence, failovers are not transparent to the client. The client may need to acquire a new IP address upon recovery. It is assumed that in this case, the original IKEv2 exchange used the Configuration Payload to acquire configuration information. The purpose of this working group is to define necessary payloads to support: 1) Negotiation of failover recovery capability 2) Server to client state transfer for stateless recovery 3) Client-gateway IKEv2 session resumption 4) IKEv2/IPsec state and corresponding format needed for recovery Support for capabilities beyond those listed above is out of scope: more precisely, specification of a gateway to gateway state transport protocol, protocol or payload extensions or modifications to support load balancing between gateways is out of scope. ============= Note the last paragraph. In Russ' preliminary discussion with the IESG and IAB, there was a lot of concern that a server-to-server part would result in a serious rathole. We have asked for a two-hour BOF slot at the Prague IETF. A proposed agenda would be: 0. Agenda bashing and blue sheets - 10 min 1. Charter discussion - 60 min 2. Problem Statement presentation and discussion - 30 min 3. Questions to the room about forming the Working Group - 20 min How does this sound to everyone? --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsec-failover Mon Feb 5 09:41:04 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l15Gf4Wd069758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Feb 2007 09:41:04 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l15Gf4rP069756; Mon, 5 Feb 2007 09:41:04 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l15Gf3Mk069732; Mon, 5 Feb 2007 09:41:03 -0700 (MST) (envelope-from kent@bbn.com) Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HE6tq-0003Vn-5T; Mon, 05 Feb 2007 11:41:02 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 5 Feb 2007 11:30:28 -0500 To: Paul Hoffman From: Stephen Kent Subject: Re: Proposed BOF charter and agenda Cc: ietf-ipsec-failover@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 2:22 PM -0800 2/2/07, Paul Hoffman wrote: >... >The purpose of this working group is to define necessary payloads to support: > >1) Negotiation of failover recovery capability >2) Server to client state transfer for stateless recovery >3) Client-gateway IKEv2 session resumption >4) IKEv2/IPsec state and corresponding format needed for recovery > >Support for capabilities beyond those listed above is out of scope: >more precisely, specification of a gateway to gateway state >transport protocol, protocol or payload extensions or modifications >to support load balancing between gateways is out of scope. > >============= > >Note the last paragraph. In Russ' preliminary discussion with the >IESG and IAB, there was a lot of concern that a server-to-server >part would result in a serious rathole. Paul, Given the argument cited above about not wanting address server-to-server communications, I am surprised by #2 above, since the use of server-to-client state transfer seems to suggest that had to be a server-to-server transfer of the state! If #2 were client-to-server state transfer, then this issue would not arise. It's not that I personally prefer one over the other, but rather that I don't want to see us adopt an approach that implicitly calls for a capability that we explicitly have chosen to NOT standardize. Steve From owner-ietf-ipsec-failover Mon Feb 5 13:26:32 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l15KQVoT052482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Feb 2007 13:26:32 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l15KQSrK052335; Mon, 5 Feb 2007 13:26:28 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l15KQLbO052084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Feb 2007 13:26:23 -0700 (MST) (envelope-from vidyan@qualcomm.com) Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l15KQ2xq029995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Feb 2007 12:26:02 -0800 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l15KQ01V013985; Mon, 5 Feb 2007 12:26:01 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 12:26:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Proposed BOF charter and agenda Date: Mon, 5 Feb 2007 12:25:55 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed BOF charter and agenda Thread-Index: AcdJTVOPFCOjclVTT6qi24lrPseQTgAClLbw References: From: "Narayanan, Vidya" To: "Stephen Kent" , "Paul Hoffman" Cc: X-OriginalArrivalTime: 05 Feb 2007 20:26:00.0839 (UTC) FILETIME=[D9D28170:01C74963] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l15KQObN052195 Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Steve, > -----Original Message----- > From: owner-ietf-ipsec-failover@mail.vpnc.org > [mailto:owner-ietf-ipsec-failover@mail.vpnc.org] On Behalf Of > Stephen Kent > Sent: Monday, February 05, 2007 8:30 AM > To: Paul Hoffman > Cc: ietf-ipsec-failover@vpnc.org > Subject: Re: Proposed BOF charter and agenda > > > At 2:22 PM -0800 2/2/07, Paul Hoffman wrote: > >... > >The purpose of this working group is to define necessary > payloads to support: > > > >1) Negotiation of failover recovery capability > >2) Server to client state transfer for stateless recovery > >3) Client-gateway IKEv2 session resumption > >4) IKEv2/IPsec state and corresponding format needed for recovery > > > >Support for capabilities beyond those listed above is out of scope: > >more precisely, specification of a gateway to gateway state > transport > >protocol, protocol or payload extensions or modifications to support > >load balancing between gateways is out of scope. > > > >============= > > > >Note the last paragraph. In Russ' preliminary discussion > with the IESG > >and IAB, there was a lot of concern that a server-to-server > part would > >result in a serious rathole. > > Paul, > > Given the argument cited above about not wanting address > server-to-server communications, I am surprised by #2 above, > since the use of server-to-client state transfer seems to > suggest that had to be a server-to-server transfer of the > state! If #2 were client-to-server state transfer, then this > issue would not arise. > > It's not that I personally prefer one over the other, but > rather that I don't want to see us adopt an approach that > implicitly calls for a capability that we explicitly have > chosen to NOT standardize. > #2 is referring to the case where the initial gateway is providing the state to the client that can be presented by the client to a new gateway upon failover. "Stateless" there refers to the backend operation - when the state is stored in the client, the infrastructure can remain stateless for the purpose of failover (i.e., no state needed on backup gateways). Re-reading the charter text, it looks like we have no explanation of what we mean by stateful or stateless in that text. Perhaps, we should clarify that to avoid confusion. Would that address your concern? Vidya > Steve > > From owner-ietf-ipsec-failover Tue Feb 6 01:42:40 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l168gSAa078902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Feb 2007 01:42:40 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l15MMpvt012648; Mon, 5 Feb 2007 15:22:51 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l15MMkvY012474; Mon, 5 Feb 2007 15:22:46 -0700 (MST) (envelope-from kent@bbn.com) Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HECEM-0008Ec-6L; Mon, 05 Feb 2007 17:22:35 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 5 Feb 2007 16:59:48 -0500 To: "Narayanan, Vidya" From: Stephen Kent Subject: RE: Proposed BOF charter and agenda Cc: "Paul Hoffman" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:25 PM -0800 2/5/07, Narayanan, Vidya wrote: > >... > > > >#2 is referring to the case where the initial gateway is providing the >state to the client that can be presented by the client to a new gateway >upon failover. "Stateless" there refers to the backend operation - when >the state is stored in the client, the infrastructure can remain >stateless for the purpose of failover (i.e., no state needed on backup >gateways). Re-reading the charter text, it looks like we have no >explanation of what we mean by stateful or stateless in that text. >Perhaps, we should clarify that to avoid confusion. > >Would that address your concern? > >Vidya Absolutely! The choice of words in the description for #2 gave me the exact opposite impression. I'd glad that what I read was not what was intended. Steve From owner-ietf-ipsec-failover Mon Feb 12 01:44:53 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1C8irdU002061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Feb 2007 01:44:53 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l1C8ir21002060; Mon, 12 Feb 2007 01:44:53 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1C8iq6S002045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Feb 2007 01:44:52 -0700 (MST) (envelope-from vidyan@qualcomm.com) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l1C8iaLi007100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Feb 2007 00:44:37 -0800 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l1C8iY7u011481; Mon, 12 Feb 2007 00:44:34 -0800 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 00:44:34 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Proposed BOF charter and agenda Date: Mon, 12 Feb 2007 00:44:34 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed BOF charter and agenda Thread-Index: AcdJy2oQ2m4DkqqcT7SlpIcVG2apwAEtjCfQ References: From: "Narayanan, Vidya" To: "Stephen Kent" Cc: "Paul Hoffman" , X-OriginalArrivalTime: 12 Feb 2007 08:44:34.0148 (UTC) FILETIME=[05175A40:01C74E82] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l1C8iq6R002048 Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here is the revised text, with the clarification on the stateful/stateless modes of failover. Hope this helps. Thanks, Vidya --------------------------------------------- IPsec gateways maintaining SAs with large number of remote access clients may take unacceptably long times to recover from gateway or network failures when all the clients were to use a full IKEv2 exchange to re-establish the SAs. This is especially true if EAP is used for client authentication in IKEv2. This concern particularly applies to application servers such as Mobile IP Home Agents that use IPsec. The SA re-establishment may be with the same gateway (server) from which the client gets disconnected or another gateway that is within the same secure domain as the original gateway. For the scope of this work, it is not assumed that the gateways in the secure domain share the same IP address or the same view of the network (connected to different DHCP servers etc.). Hence, failovers are not transparent to the client. The client may need to acquire a new IP address upon recovery. It is assumed that in this case, the original IKEv2 exchange used the Configuration Payload to acquire configuration information. The scope of this work involves the specification of statelss and stateful modes of recovery - in the stateless mode, the state is maintained on the client and no state is maintained in the infrastructure except on the serving gateway; in the stateful mode, the state is maintained in the infrastructure, either on a backup gateway or in a state store. The purpose of this working group is to define necessary payloads to support: 1) Negotiation of failover recovery capability 2) Server to client state transfer for stateless recovery 3) Client-gateway IKEv2 session resumption 4) IKEv2/IPsec state and corresponding format needed for recovery Support for capabilities beyond those listed above is out of scope: more precisely, specification of a gateway to gateway state transport protocol, protocol or payload extensions or modifications to support load balancing between gateways is out of scope. ------------------------------------------------------- > -----Original Message----- > From: owner-ietf-ipsec-failover@mail.vpnc.org > [mailto:owner-ietf-ipsec-failover@mail.vpnc.org] On Behalf Of > Stephen Kent > Sent: Monday, February 05, 2007 2:00 PM > To: Narayanan, Vidya > Cc: Paul Hoffman; ietf-ipsec-failover@vpnc.org > Subject: RE: Proposed BOF charter and agenda > > > At 12:25 PM -0800 2/5/07, Narayanan, Vidya wrote: > > > >... > > > > > > >#2 is referring to the case where the initial gateway is > providing the > >state to the client that can be presented by the client to a new > >gateway upon failover. "Stateless" there refers to the backend > >operation - when the state is stored in the client, the > infrastructure > >can remain stateless for the purpose of failover (i.e., no > state needed > >on backup gateways). Re-reading the charter text, it looks > like we have > >no explanation of what we mean by stateful or stateless in that text. > >Perhaps, we should clarify that to avoid confusion. > > > >Would that address your concern? > > > >Vidya > > Absolutely! The choice of words in the description for #2 > gave me the exact opposite impression. I'd glad that what I > read was not what was intended. > > Steve > > From owner-ietf-ipsec-failover Tue Feb 27 22:07:28 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1S57SZF053679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Feb 2007 22:07:28 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l1S57S76053678; Tue, 27 Feb 2007 22:07:28 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l1S57QQC053672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Feb 2007 22:07:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 27 Feb 2007 21:07:20 -0800 To: ietf-ipsec-failover@vpnc.org From: Paul Hoffman Subject: Revised proposed BOF charter, problem statement, and agenda Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greetings again. We want to be sure everyone has a chance to read the charter an associated documents before the face-to-face meeting in Prague, and hopefully have as much discussion as is needed here on the mailing list before that meeting. The following has Vidya's addition for defining stateless and stateful modes. ============= IPsec gateways maintaining SAs with large number of remote access clients may take unacceptably long times to recover from gateway or network failures when all the clients were to use a full IKEv2 exchange to re-establish the SAs. This is especially true if EAP is used for client authentication in IKEv2. This concern particularly applies to application servers such as Mobile IP Home Agents that use IPsec. The SA re-establishment may be with the same gateway (server) from which the client gets disconnected or another gateway that is within the same secure domain as the original gateway. For the scope of this work, it is not assumed that the gateways in the secure domain share the same IP address or the same view of the network (connected to different DHCP servers etc.). Hence, failovers are not transparent to the client. The client may need to acquire a new IP address upon recovery. It is assumed that in this case, the original IKEv2 exchange used the Configuration Payload to acquire configuration information. The scope of this work involves the specification of stateless and stateful modes of recovery - in the stateless mode, the state is maintained on the client and no state is maintained in the infrastructure except on the serving gateway; in the stateful mode, the state is maintained in the infrastructure, either on a backup gateway or in a state store. The purpose of this working group is to define necessary payloads to support: 1) Negotiation of failover recovery capability 2) Server to client state transfer for stateless recovery 3) Client-gateway IKEv2 session resumption 4) IKEv2/IPsec state and corresponding format needed for recovery Support for capabilities beyond those listed above is out of scope: more precisely, specification of a gateway to gateway state transport protocol, protocol or payload extensions or modifications to support load balancing between gateways is out of scope. ============= Getting the requirements to meet that proposed charter correct is pretty important. Vidya Narayanan has just completed a second version of an attempt at a problem statement. I have put a temporary copy at until the real copy shows up in the IETF directories. Questions for the group are whether this is a good enough start on a problem statement, whether it needs major changes, and whether someone else is going to propose a problem statement or requirements document. ============= We currently have a 2.5 hour BOF slot at the Prague IETF, which is probably way more than we need. (The current proposed IETF agenda is at .) Given how little discussion there has been about the charter, I have jiggled the proposed agenda somewhat. Let me know what you think: 0. Agenda bashing and blue sheets - 5 min 1. Charter discussion - 30 min 2. Problem statement presentation and discussion - 30 min 3. Questions to the room about forming the Working Group - 20 min We can certainly talk more if we need to. Thoughts? If so, please change the subject line to be specifc and discuss freely! --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsec-failover Thu Mar 1 18:05:00 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2214xMb083134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Mar 2007 18:04:59 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2214x39083133; Thu, 1 Mar 2007 18:04:59 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2214wOf083126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 Mar 2007 18:04:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 1 Mar 2007 17:04:52 -0800 To: ietf-ipsec-failover@vpnc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-vidya-ipsec-failover-ps-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPsec Gateway Failover and Redundancy - Problem Statement and Goals Author(s) : V. Narayanan Filename : draft-vidya-ipsec-failover-ps-01.txt Pages : 10 Date : 2007-3-1 Recovering from failure of IPsec gateways maintaining large numbers of SAs may take several minutes, if they need to re-establish the IPsec SAs by re-running the key management protocol, IKEv2. A similar problem arises in the event of a network outage resulting in the failure of several gateways and servers. The latency involved in this approach is significant, leading to a need for a faster and yet secure failover solution. This document describes the problem statement and the goals for an IPsec/IKEv2 gateway failover/ redundancy solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vidya-ipsec-failover-ps-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-vidya-ipsec-failover-ps-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-vidya-ipsec-failover-ps-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. [The following attachment must be fetched by mail. Command-click the URL below and send the resulting message to get the attachment.] [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] From owner-ietf-ipsec-failover Fri Mar 2 07:12:27 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l22ECR1d038509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Mar 2007 07:12:27 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l22ECRE3038508; Fri, 2 Mar 2007 07:12:27 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l22ECPSg038500 for ; Fri, 2 Mar 2007 07:12:26 -0700 (MST) (envelope-from jeanmichel.combes@gmail.com) Received: by ug-out-1314.google.com with SMTP id 30so641785ugs for ; Fri, 02 Mar 2007 06:12:24 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=dKToVFVxNgBuHFwgl7rkyiHPZzwwIKEk75n1DY5p4uTglk+vA2CZjgaWjY43EVMNdhZNHmdvsQy232t8g0Z+iM/Jkf9xhzqcLLj+eHnV5YYfQE3QiTlI17eZnGOUoscrsWmgpoHHunI1brqvG6Qa471mzA1c0mZbgjgwz2/Ao8o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=Hl//1uPGFeu9yXrPriwMX3wqZ1HtR9wYPmU5VtJWPMo7ENfA68Y6CbhEVH7GBHEoZsKtAnC593y6sUHl3XiPg6Ra/AtEil6A1LxWvD06H5+wM0OQcTdG24xAXgGEUVDXz6bg+2Qj1rs3HYgSyEZLChRFTorU3f5G5F/KPr4Trzc= Received: by 10.78.166.7 with SMTP id o7mr269134hue.1172844744180; Fri, 02 Mar 2007 06:12:24 -0800 (PST) Received: by 10.78.106.13 with HTTP; Fri, 2 Mar 2007 06:12:23 -0800 (PST) Message-ID: <729b68be0703020612i7ee2e43fh5f99cf85615daec4@mail.gmail.com> Date: Fri, 2 Mar 2007 15:12:23 +0100 From: "Jean-Michel Combes" To: "Paul Hoffman" Subject: Comments/questions about the assumptions [Was: Re: Revised proposed BOF charter, problem statement, and agenda] Cc: ietf-ipsec-failover@vpnc.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, 2007/2/28, Paul Hoffman : > > Greetings again. We want to be sure everyone has a chance to read the > charter an associated documents before the face-to-face meeting in > Prague, and hopefully have as much discussion as is needed here on > the mailing list before that meeting. [snip] > > For the scope of this work, it is not assumed that the gateways in > the secure domain share the same IP address or the same view of the > network (connected to different DHCP servers etc.). Why such an assumption has be done? > Hence, failovers > are not transparent to the client. Are you so sure about this conclusion? IMHO, this assumption is too strong and so may close innovative solutions. Comments ? [snip] Thanks for your help. Best regards. JMC. From owner-ietf-ipsec-failover Fri Mar 2 12:17:29 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l22JHT8d063555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Mar 2007 12:17:29 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l22JHTBO063554; Fri, 2 Mar 2007 12:17:29 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l22JHP00063539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Mar 2007 12:17:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <729b68be0703020612i7ee2e43fh5f99cf85615daec4@mail.gmail.com> References: <729b68be0703020612i7ee2e43fh5f99cf85615daec4@mail.gmail.com> Date: Fri, 2 Mar 2007 11:17:23 -0800 To: "Jean-Michel Combes" From: Paul Hoffman Subject: Re: Comments/questions about the assumptions [Was: Re: Revised proposed BOF charter, problem statement, and agenda] Cc: ietf-ipsec-failover@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 3:12 PM +0100 3/2/07, Jean-Michel Combes wrote: >>For the scope of this work, it is not assumed that the gateways in >>the secure domain share the same IP address or the same view of the >>network (connected to different DHCP servers etc.). > >Why such an assumption has be done? To make the solution more general. If the failed-to gateway had to have the same address configuration as the failed-from gateway, there are more restrictions on who can be the failed-from gateway. >>Hence, failovers >>are not transparent to the client. > >Are you so sure about this conclusion? IMHO, this assumption is too >strong and so may close innovative solutions. Comments ? The conclusion seems to follow the statement. I don't see how the failover could be transparent to the client if the failed-to gateway has different addressing; that gateway is going to have to tell the client to change its addressing. Am I missing something? --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsec-failover Mon Mar 5 03:11:39 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l25ABcks065789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Mar 2007 03:11:38 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l25ABc5Y065788; Mon, 5 Mar 2007 03:11:38 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l25ABaFm065771 for ; Mon, 5 Mar 2007 03:11:38 -0700 (MST) (envelope-from jeanmichel.combes@gmail.com) Received: by ug-out-1314.google.com with SMTP id 30so1095783ugs for ; Mon, 05 Mar 2007 02:11:32 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iETdKtwUxRMGbTIqm8fGy/NFkQ5MZsj7i1dgJ2X5o1JZfVdPuI00w1oI2je7e9G+1nIPgj1m8r+7eOS5esNPv+zNem9X3p5Y3XBwKsGXqEfEPBSGpTXlhcIj0WIpxC9pteG5C0BnBCuIcbxB/y927IOIwkFM+Iik01qJSMj9Vu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Vf8CG+maKPboVD9LpXrbmjv061HynLDj97+b9SlXsyo1jxE+J7BeA1HuR8FTnUcpZaUuoUR7wpO12RGz0AMU2Q20/+5D4kaQIS7OEY3PZ6QuyoRZqbWAdQVPZQCUsyyLFBsOIlHbOYW2cn8+xE65IV9RtqlwGBroBoHRx6TqvHI= Received: by 10.78.138.6 with SMTP id l6mr595365hud.1173089491798; Mon, 05 Mar 2007 02:11:31 -0800 (PST) Received: by 10.78.106.13 with HTTP; Mon, 5 Mar 2007 02:11:31 -0800 (PST) Message-ID: <729b68be0703050211q4f70ec11xa368a05979cf198b@mail.gmail.com> Date: Mon, 5 Mar 2007 11:11:31 +0100 From: "Jean-Michel Combes" To: "Paul Hoffman" Subject: Re: Comments/questions about the assumptions [Was: Re: Revised proposed BOF charter, problem statement, and agenda] Cc: ietf-ipsec-failover@vpnc.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <729b68be0703020612i7ee2e43fh5f99cf85615daec4@mail.gmail.com> Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 2007/3/2, Paul Hoffman : > At 3:12 PM +0100 3/2/07, Jean-Michel Combes wrote: > >>For the scope of this work, it is not assumed that the gateways in > >>the secure domain share the same IP address or the same view of the > >>network (connected to different DHCP servers etc.). > > > >Why such an assumption has be done? > > To make the solution more general. If the failed-to gateway had to > have the same address configuration as the failed-from gateway, there > are more restrictions on who can be the failed-from gateway. Ok. > > >>Hence, failovers > >>are not transparent to the client. > > > >Are you so sure about this conclusion? IMHO, this assumption is too > >strong and so may close innovative solutions. Comments ? > > The conclusion seems to follow the statement. I don't see how the > failover could be transparent to the client if the failed-to gateway > has different addressing; that gateway is going to have to tell the > client to change its addressing. Am I missing something? Yes and no: such a message to the client may be "transparent". We (France Telecom R&D) have such a solution but the specification of this one is not finalized for the moment :( To summarize it shortly: - The solution is strongly based on Mobile IPv6 - The n different SGs, called SGi (i from 1 to n), have two addresses, one called CoAi (with i from 1 to n) and the other one, which is common to all the SGs, called HoA. - The "philosophy" of the solution is the client believes all the SGs are a same MIPv6 Mobile Node moving from one network to another one in using MIPv6 signalling and so the solution is "transparent" to the client. Is such a solution too restrictive from the point of view of the charter (i.e. a common HoA)? Best regards. JMC. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ietf-ipsec-failover Tue Mar 6 13:16:56 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l26KGuRQ069750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Mar 2007 13:16:56 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l26KGuRF069749; Tue, 6 Mar 2007 13:16:56 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l26KGsFr069735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Mar 2007 13:16:55 -0700 (MST) (envelope-from vidyan@qualcomm.com) Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l26KGpEK026126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Mar 2007 12:16:51 -0800 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l26KFvXo027372; Tue, 6 Mar 2007 12:16:41 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 12:16:36 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Comments/questions about the assumptions [Was: Re: Revised proposed BOF charter, problem statement, and agenda] Date: Tue, 6 Mar 2007 12:16:29 -0800 Message-ID: In-Reply-To: <729b68be0703050211q4f70ec11xa368a05979cf198b@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments/questions about the assumptions [Was: Re: Revised proposed BOF charter, problem statement, and agenda] Thread-Index: AcdfD0HPUeMuRZaOQFeUGAce+dG0nABGwbIw References: <729b68be0703020612i7ee2e43fh5f99cf85615daec4@mail.gmail.com> <729b68be0703050211q4f70ec11xa368a05979cf198b@mail.gmail.com> From: "Narayanan, Vidya" To: "Jean-Michel Combes" , "Paul Hoffman" Cc: X-OriginalArrivalTime: 06 Mar 2007 20:16:36.0440 (UTC) FILETIME=[5764CD80:01C7602C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l26KGtFq069737 Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, Please see some responses inline. > -----Original Message----- > From: owner-ietf-ipsec-failover@mail.vpnc.org > [mailto:owner-ietf-ipsec-failover@mail.vpnc.org] On Behalf Of > Jean-Michel Combes > Sent: Monday, March 05, 2007 2:12 AM > To: Paul Hoffman > Cc: ietf-ipsec-failover@vpnc.org > Subject: Re: Comments/questions about the assumptions [Was: > Re: Revised proposed BOF charter, problem statement, and agenda] > > > 2007/3/2, Paul Hoffman : > > At 3:12 PM +0100 3/2/07, Jean-Michel Combes wrote: > > >>For the scope of this work, it is not assumed that the > gateways in > > >>the secure domain share the same IP address or the same > view of the > > >>network (connected to different DHCP servers etc.). > > > > > >Why such an assumption has be done? > > > > To make the solution more general. If the failed-to gateway had to > > have the same address configuration as the failed-from > gateway, there > > are more restrictions on who can be the failed-from gateway. > > Ok. > > > > > >>Hence, failovers > > >>are not transparent to the client. > > > > > >Are you so sure about this conclusion? IMHO, this > assumption is too > > >strong and so may close innovative solutions. Comments ? > > > > The conclusion seems to follow the statement. I don't see how the > > failover could be transparent to the client if the > failed-to gateway > > has different addressing; that gateway is going to have to tell the > > client to change its addressing. Am I missing something? > > Yes and no: such a message to the client may be "transparent". > We (France Telecom R&D) have such a solution but the > specification of this one is not finalized for the moment :( > To summarize it shortly: > - The solution is strongly based on Mobile IPv6 > - The n different SGs, called SGi (i from 1 to n), have two > addresses, one called CoAi (with i from 1 to n) and the other > one, which is common to all the SGs, called HoA. > - The "philosophy" of the solution is the client believes all > the SGs are a same MIPv6 Mobile Node moving from one network > to another one in using MIPv6 signalling and so the solution > is "transparent" to the client. > > Is such a solution too restrictive from the point of view of > the charter (i.e. a common HoA)? > The client in this case, as you say, always sees the HoA (unchanging IP address) and hence, the failover is transparent to the client. In other words, a gateway switch is never known to the client in this case. Since this charter does not cover standardizing an inter-gateway protocol, this would not fall under the scope of this work. For instance, the fact that the security gateways may be running MIP6 for IP address persistence is not something that would fall within the scope of this charter. Hope that helps. Vidya > Best regards. > > JMC. > > > > > --Paul Hoffman, Director > > --VPN Consortium > > > > From owner-ietf-ipsec-failover Tue Mar 6 13:31:42 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l26KVgHQ019516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Mar 2007 13:31:42 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l26KVgRv019515; Tue, 6 Mar 2007 13:31:42 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from mx2.grc.nasa.gov (mx2.grc.nasa.gov [128.156.11.69]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l26KVfEL019501; Tue, 6 Mar 2007 13:31:41 -0700 (MST) (envelope-from weddy@gr2134391.grc.nasa.gov) Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx2.grc.nasa.gov (Postfix) with ESMTP id A94C3C26B; Tue, 6 Mar 2007 15:31:38 -0500 (EST) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l26KVbep016887; Tue, 6 Mar 2007 15:31:37 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l26KVauG027472; Tue, 6 Mar 2007 15:31:37 -0500 (EST) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id hd1AzPqwpKRt; Tue, 6 Mar 2007 15:31:36 -0500 (EST) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l26KVYx8027452;Tue, 6 Mar 2007 15:31:34 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 015D34FE5A; Tue, 6 Mar 2007 15:28:10 -0500 (EST) Date: Tue, 6 Mar 2007 15:28:10 -0500 From: Wesley Eddy To: "Narayanan, Vidya" Cc: Jean-Michel Combes , Paul Hoffman , ietf-ipsec-failover@vpnc.org Subject: Re: Comments/questions about the assumptions [Was: Re: Revised proposed BOF charter, problem statement, and agenda] Message-ID: <20070306202810.GK28150@grc.nasa.gov> Reply-To: weddy@grc.nasa.gov References: <729b68be0703020612i7ee2e43fh5f99cf85615daec4@mail.gmail.com> <729b68be0703050211q4f70ec11xa368a05979cf198b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1i X-imss-version: 2.046 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Mar 06, 2007 at 12:16:29PM -0800, Narayanan, Vidya wrote: > > > Yes and no: such a message to the client may be "transparent". > > We (France Telecom R&D) have such a solution but the > > specification of this one is not finalized for the moment :( > > To summarize it shortly: > > - The solution is strongly based on Mobile IPv6 > > - The n different SGs, called SGi (i from 1 to n), have two > > addresses, one called CoAi (with i from 1 to n) and the other > > one, which is common to all the SGs, called HoA. > > - The "philosophy" of the solution is the client believes all > > the SGs are a same MIPv6 Mobile Node moving from one network > > to another one in using MIPv6 signalling and so the solution > > is "transparent" to the client. > > > > Is such a solution too restrictive from the point of view of > > the charter (i.e. a common HoA)? > > > > The client in this case, as you say, always sees the HoA (unchanging IP > address) and hence, the failover is transparent to the client. In other > words, a gateway switch is never known to the client in this case. Since > this charter does not cover standardizing an inter-gateway protocol, > this would not fall under the scope of this work. For instance, the fact > that the security gateways may be running MIP6 for IP address > persistence is not something that would fall within the scope of this > charter. > I know of environments that need client-transparent solutions. Are there really cases where a client-based solution is favorable to a client-transparent solution? It sure seems like most admins would like to have their servers figure out how to do any failover, load-balancing, etc. and hide all that from the clients, but maybe the perspective from my niche is skewed. -- Wesley M. Eddy Verizon Federal Network Systems From owner-ietf-ipsec-failover Tue Mar 6 14:53:16 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l26LrGm9010607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Mar 2007 14:53:16 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l26LrGpB010606; Tue, 6 Mar 2007 14:53:16 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l26LrF8C010599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Mar 2007 14:53:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20070306202810.GK28150@grc.nasa.gov> References: <729b68be0703020612i7ee2e43fh5f99cf85615daec4@mail.gmail.com> <729b68be0703050211q4f70ec11xa368a05979cf198b@mail.gmail.com> <20070306202810.GK28150@grc.nasa.gov> Date: Tue, 6 Mar 2007 13:53:11 -0800 To: ietf-ipsec-failover@vpnc.org From: Paul Hoffman Subject: Re: Comments/questions about the assumptions [Was: Re: Revised proposed BOF charter, problem statement, and agenda] Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 3:28 PM -0500 3/6/07, Wesley Eddy wrote: >I know of environments that need client-transparent solutions. Are >there really cases where a client-based solution is favorable to a >client-transparent solution? From our pre-list discussions, it seems that the answer is "yes" *if* the only thing the client needs to do is update its address but not re-authenticate. A fully-transparent solution requires that all gateways communicate about which addresses are already handed out (and possibly to whom they were handed), which puts a significant burden on the intra-gateway communication system. > It sure seems like most admins would like >to have their servers figure out how to do any failover, load-balancing, >etc. and hide all that from the clients, but maybe the perspective from >my niche is skewed. Of course that would be nice, but it also has to be completely reliable. The last thing you want is for the client to connect to the failed-to gateway and have the gateway say "go away, someone else is using the address you think is yours". It is much better for the gateway to be able to, in a DHCP-like fashion, say "hi there, here's your new address" or, even better, "hi there, your current address looks fine". --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsec-failover Tue Mar 6 17:20:02 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l270K2ve018460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Mar 2007 17:20:02 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l270K2EG018459; Tue, 6 Mar 2007 17:20:02 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l270K0sg018436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Mar 2007 17:20:01 -0700 (MST) (envelope-from vidyan@qualcomm.com) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l270K0Cr004012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Mar 2007 16:20:00 -0800 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l270Jm6c031293; Tue, 6 Mar 2007 16:19:59 -0800 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 16:19:37 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Comments/questions about the assumptions [Was: Re: Revised proposed BOF charter, problem statement, and agenda] Date: Tue, 6 Mar 2007 16:19:37 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments/questions about the assumptions [Was: Re: Revised proposed BOF charter, problem statement, and agenda] Thread-Index: AcdgOid18FA7dWbJR7mlbHbA3Sh2GQADzxqA References: <729b68be0703020612i7ee2e43fh5f99cf85615daec4@mail.gmail.com> <729b68be0703050211q4f70ec11xa368a05979cf198b@mail.gmail.com> <20070306202810.GK28150@grc.nasa.gov> From: "Narayanan, Vidya" To: "Paul Hoffman" , X-OriginalArrivalTime: 07 Mar 2007 00:19:37.0773 (UTC) FILETIME=[4A8BA5D0:01C7604E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l270K1sf018446 Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In addition to what Paul has said, there is one more point. In the case of solutions that are transparent to the client, there may be one gateway that is actively serving as a "primary" gateway and one or more gateways acting as "backup" gateways; one of the backup gateways takes over for the primary (i.e., assumes the IP address of the primary and acquires all the clients that were being served by the primary) when the primary gateway fails. This essentially leads to the situation where all these gateways are capable of serving the same set of subnets (i.e., have associations with the same DHCP servers) and hence, more or less restricts the geographic distribution of these gateways. The other problem space is one where the gateways are all active and distributed and serving clients of their own - upon failure of one gateway, the clients being served by that gateway may connect to a different gateway within the same secure domain. In this case, it is not feasible for these gateways to have the same IP address or serve the same set of subnets and hence, transparency to the client is not feasible. This scenario allows for having functional gateways that may be serving various sites also be "backup" gateways for other gateways in the domain. In situations like massive network failures that take down an entire site or various Mobile IP home agents (that use IPsec) that the clients may attach to within the secure domain, there is a need for a quick failover that doesn't involve re-establishment of the entire SA, including client authentication and DH exchange, etc. Hope that helps. Regards, Vidya > -----Original Message----- > From: owner-ietf-ipsec-failover@mail.vpnc.org > [mailto:owner-ietf-ipsec-failover@mail.vpnc.org] On Behalf Of > Paul Hoffman > Sent: Tuesday, March 06, 2007 1:53 PM > To: ietf-ipsec-failover@vpnc.org > Subject: Re: Comments/questions about the assumptions [Was: > Re: Revised proposed BOF charter, problem statement, and agenda] > > > At 3:28 PM -0500 3/6/07, Wesley Eddy wrote: > >I know of environments that need client-transparent solutions. Are > >there really cases where a client-based solution is favorable to a > >client-transparent solution? > > From our pre-list discussions, it seems that the answer is > "yes" *if* the only thing the client needs to do is update > its address but not re-authenticate. A fully-transparent > solution requires that all gateways communicate about which > addresses are already handed out (and possibly to whom they > were handed), which puts a significant burden on the > intra-gateway communication system. > > > It sure seems like most admins would like to have their servers > >figure out how to do any failover, load-balancing, etc. and hide all > >that from the clients, but maybe the perspective from my niche is > >skewed. > > Of course that would be nice, but it also has to be > completely reliable. The last thing you want is for the > client to connect to the failed-to gateway and have the > gateway say "go away, someone else is using the address you > think is yours". It is much better for the gateway to be able > to, in a DHCP-like fashion, say "hi there, here's your new > address" or, even better, "hi there, your current address looks fine". > > --Paul Hoffman, Director > --VPN Consortium > > From owner-ietf-ipsec-failover Wed Mar 7 05:03:46 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l27C3kXi056007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Mar 2007 05:03:46 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l27C3kug056006; Wed, 7 Mar 2007 05:03:46 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l27C3g4x055981 for ; Wed, 7 Mar 2007 05:03:45 -0700 (MST) (envelope-from jeanmichel.combes@gmail.com) Received: by nf-out-0910.google.com with SMTP id m19so136982nfc for ; Wed, 07 Mar 2007 04:03:41 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=c/SKp8l7HU0CkOW6HA35+IQZra278XseUiRSh12MyK4zxnZUkM2GYs3qwtcB5hcY2QGehaLRNAyZl9YRB01nGauUzh3Qdspt4hdezHiQzac55RlodHvFYAP6tS0heV0eAtvVPbwwQYP51Q5j04KQO/ETsBF4GqqFKRWwztzs3W0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sWoFUZ6Y+tWH6mJ7K/DLBTnTrlI3s2UGpFGlKM+4pSGbolcvRy54QwWqiwhBF84+QlwPwpDUZgKd7pZYus/1CfmnWG7Om8ykTmNy7GucI7Qba16MWVJfWOMBwzXHCLhot5AD/UGqCr11qEun7H33FQDiPjgE3Fv8lfe/nwWzC8k= Received: by 10.78.47.15 with SMTP id u15mr954847huu.1173269020488; Wed, 07 Mar 2007 04:03:40 -0800 (PST) Received: by 10.78.106.13 with HTTP; Wed, 7 Mar 2007 04:03:40 -0800 (PST) Message-ID: <729b68be0703070403s19b8987ar8ac83787446d55f8@mail.gmail.com> Date: Wed, 7 Mar 2007 13:03:40 +0100 From: "Jean-Michel Combes" To: "Narayanan, Vidya" Subject: Re: Comments/questions about the assumptions [Was: Re: Revised proposed BOF charter, problem statement, and agenda] Cc: "Paul Hoffman" , ietf-ipsec-failover@vpnc.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <729b68be0703020612i7ee2e43fh5f99cf85615daec4@mail.gmail.com> <729b68be0703050211q4f70ec11xa368a05979cf198b@mail.gmail.com> Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, replies in line. [snip] > > > > Yes and no: such a message to the client may be "transparent". > > We (France Telecom R&D) have such a solution but the > > specification of this one is not finalized for the moment :( > > To summarize it shortly: > > - The solution is strongly based on Mobile IPv6 > > - The n different SGs, called SGi (i from 1 to n), have two > > addresses, one called CoAi (with i from 1 to n) and the other > > one, which is common to all the SGs, called HoA. > > - The "philosophy" of the solution is the client believes all > > the SGs are a same MIPv6 Mobile Node moving from one network > > to another one in using MIPv6 signalling and so the solution > > is "transparent" to the client. > > > > Is such a solution too restrictive from the point of view of > > the charter (i.e. a common HoA)? > > > > The client in this case, as you say, always sees the HoA (unchanging IP > address) and hence, the failover is transparent to the client. In other > words, a gateway switch is never known to the client in this case. Since > this charter does not cover standardizing an inter-gateway protocol, But it is said in the charter: "The SA re-establishment may be with the same gateway (server) from which the client gets disconnected or another gateway that is within the same secure domain as the original gateway." For me, the second case (if I've understood correctly) is the stateful case and so you will need a protocol to transfer the state from the backup gateway/state store to the new Security Gateway and the same protocole will be used by the different SGs to store the states they are managing periodicly. So, from my point of view, the entity storing the state can be seen, more or less, like a sort of proxy for the protocol needed before too and so, IMHO, this same protocol can be used directly between 2 SGs. So I think the solution that will be designed in this potential WG may be used too in the SGs swtiching use-case too. That is the reason I don't understand why inter-gateway protocol is out of scope :( > this would not fall under the scope of this work. For instance, the fact > that the security gateways may be running MIP6 for IP address > persistence is not something that would fall within the scope of this > charter. That was just a exemple of solutions regarding the SGs fail-over AND switching :) Best regards. JMC. > > Hope that helps. > > Vidya > > > > Best regards. > > > > JMC. > > > > > > > > --Paul Hoffman, Director > > > --VPN Consortium > > > > > > > > From owner-ietf-ipsec-failover Wed Mar 7 05:28:54 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l27CSslP058790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Mar 2007 05:28:54 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l27CSppl058714; Wed, 7 Mar 2007 05:28:51 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l27CSlu7058615 for ; Wed, 7 Mar 2007 05:28:50 -0700 (MST) (envelope-from jeanmichel.combes@gmail.com) Received: by nf-out-0910.google.com with SMTP id m19so143857nfc for ; Wed, 07 Mar 2007 04:28:41 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KXzc7ZZxobiBimGqoVtsBqheyw2Z7ru3fnMSmGIpZDCYx8vIahjrwWOQPeUUDnOKdgQl8sXjAonH1RYO1eoh4tX1j2qqtxNlFge909F6gc47KyIPnWDWiMNVzIpMrmS+qwi+dlT1sFY3zgOU+510efTqLwOhJs5dWoTqxDiMWv8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GztwZdeCWW88vPEgGp+M8U/9fdfgOUdtURRWc/OnEMfSGhiMjfLaZGFF0+nTKIeJk/zNFEsQDSXDYVCcIMXL04af/wjM4At5736RtvTn8UTL+AeTKkOuop1TxYkYYaXY4ENWsojWmxl2yDcUP2eh9RIz8qoPwHrIxeduHfM5nmA= Received: by 10.78.165.16 with SMTP id n16mr960552hue.1173270520407; Wed, 07 Mar 2007 04:28:40 -0800 (PST) Received: by 10.78.106.13 with HTTP; Wed, 7 Mar 2007 04:28:40 -0800 (PST) Message-ID: <729b68be0703070428r13f49b21t940d66fbe3de186e@mail.gmail.com> Date: Wed, 7 Mar 2007 13:28:40 +0100 From: "Jean-Michel Combes" To: "Paul Hoffman" Subject: Re: Comments/questions about the assumptions [Was: Re: Revised proposed BOF charter, problem statement, and agenda] Cc: ietf-ipsec-failover@vpnc.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <729b68be0703020612i7ee2e43fh5f99cf85615daec4@mail.gmail.com> <729b68be0703050211q4f70ec11xa368a05979cf198b@mail.gmail.com> <20070306202810.GK28150@grc.nasa.gov> Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 2007/3/6, Paul Hoffman : > > At 3:28 PM -0500 3/6/07, Wesley Eddy wrote: > >I know of environments that need client-transparent solutions. Are > >there really cases where a client-based solution is favorable to a > >client-transparent solution? > > From our pre-list discussions, it seems that the answer is "yes" *if* > the only thing the client needs to do is update its address but not > re-authenticate. A fully-transparent solution requires that all > gateways communicate about which addresses are already handed out > (and possibly to whom they were handed), which puts a significant > burden on the intra-gateway communication system. IMHO, this issue is strongly linked to the mechanism which will manage the detection of a fail-over. If this one is based on direct signalling between SGs, such signalling may be completed to answer to your issue. But I agree that there is a lot of chance that will put a significant burden. Other solution is to use the states storing entity (i.e. the entity needed in the stateful case) to centralize such communications. In fact, I think this entity will already do the job: the SGs must periodically sent the states to this entity because (1) a fail-over is not predictable :) (2) the stateful case can only work if this entity has the correct states for a recent down SG. Now, this last solution is strongly subject to the "chicken and egg" problem, i.e. what will happen if the entity storing the states has a fail-over .... Best regards. JMC. > > > It sure seems like most admins would like > >to have their servers figure out how to do any failover, load-balancing, > >etc. and hide all that from the clients, but maybe the perspective from > >my niche is skewed. > > Of course that would be nice, but it also has to be completely > reliable. The last thing you want is for the client to connect to the > failed-to gateway and have the gateway say "go away, someone else is > using the address you think is yours". It is much better for the > gateway to be able to, in a DHCP-like fashion, say "hi there, here's > your new address" or, even better, "hi there, your current address > looks fine". > > --Paul Hoffman, Director > --VPN Consortium > > From owner-ietf-ipsec-failover Wed Mar 7 06:17:22 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l27DHM6O061108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Mar 2007 06:17:22 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l27DHMI3061107; Wed, 7 Mar 2007 06:17:22 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l27DHLl0061099 for ; Wed, 7 Mar 2007 06:17:22 -0700 (MST) (envelope-from jeanmichel.combes@gmail.com) Received: by nf-out-0910.google.com with SMTP id m19so158266nfc for ; Wed, 07 Mar 2007 05:17:19 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qvgYR+KAOP9of5zSE1E8wcq35UCmcke9oZ8brZe5NFTUgPFzNodSzJFe+kiysQC60Q9862exg5r1w1LoFIq9Eclu7/qVo7HZ75BX6CASRpCjPhwXYbxQTI8yKiJ+q2pJBhWVseBaV/Dc9UnS7oUJyWbgIXnv2i51vrbVjD24gG8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hyS/AdLRNOzUG9W+YIHRZwT0dBVgDQrngm9WaPYeZNu9Czu1Ytppxa8zRTfycGEa8HYg+Q9eKSVHGOoU8VvL576Hs0/TaucZ1R2uWD/vtgeqTE7Xe2hG7H4WOtif3vERxZGdbtRzS3ufcS2mmhXilVi3kb+bHfy6GKkyGNDR2LQ= Received: by 10.78.97.7 with SMTP id u7mr971652hub.1173273439283; Wed, 07 Mar 2007 05:17:19 -0800 (PST) Received: by 10.78.106.13 with HTTP; Wed, 7 Mar 2007 05:17:19 -0800 (PST) Message-ID: <729b68be0703070517j176e8d19y7b797b126d0905a@mail.gmail.com> Date: Wed, 7 Mar 2007 14:17:19 +0100 From: "Jean-Michel Combes" To: "Narayanan, Vidya" Subject: Re: Comments/questions about the assumptions [Was: Re: Revised proposed BOF charter, problem statement, and agenda] Cc: "Paul Hoffman" , ietf-ipsec-failover@vpnc.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <729b68be0703020612i7ee2e43fh5f99cf85615daec4@mail.gmail.com> <729b68be0703050211q4f70ec11xa368a05979cf198b@mail.gmail.com> <20070306202810.GK28150@grc.nasa.gov> Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 2007/3/7, Narayanan, Vidya : > > In addition to what Paul has said, there is one more point. In the case > of solutions that are transparent to the client, there may be one > gateway that is actively serving as a "primary" gateway and one or more > gateways acting as "backup" gateways; one of the backup gateways takes > over for the primary (i.e., assumes the IP address of the primary and > acquires all the clients that were being served by the primary) when the > primary gateway fails. This essentially leads to the situation where all > these gateways are capable of serving the same set of subnets (i.e., > have associations with the same DHCP servers) and hence, more or less > restricts the geographic distribution of these gateways. I don't agree with this conclusion: if I take again my example of solution based on MIPv6, the "real" IP addresses of the SGs are the CoA and the SGs may be distributed in a large scale. > > The other problem space is one where the gateways are all active and > distributed and serving clients of their own - upon failure of one > gateway, the clients being served by that gateway may connect to a > different gateway within the same secure domain By the way, I think it would be useful to have a clear definition of a secure domain. IIRC, there is no definition of it in the PS draft. >. In this case, it is not > feasible for these gateways to have the same IP address or serve the > same set of subnets and hence, transparency to the client is not > feasible. Again, I don't agree on your conclusion. And again based on my example of solution based on MIPv6, all the SGs has a same and common IP address, the HoA. Now, maybe, there are others solutions that I don't know allowing the same features :) Best regards. JMC. > This scenario allows for having functional gateways that may > be serving various sites also be "backup" gateways for other gateways in > the domain. In situations like massive network failures that take down > an entire site or various Mobile IP home agents (that use IPsec) that > the clients may attach to within the secure domain, there is a need for > a quick failover that doesn't involve re-establishment of the entire SA, > including client authentication and DH exchange, etc. > > Hope that helps. > > Regards, > Vidya > > > -----Original Message----- > > From: owner-ietf-ipsec-failover@mail.vpnc.org > > [mailto:owner-ietf-ipsec-failover@mail.vpnc.org] On Behalf Of > > Paul Hoffman > > Sent: Tuesday, March 06, 2007 1:53 PM > > To: ietf-ipsec-failover@vpnc.org > > Subject: Re: Comments/questions about the assumptions [Was: > > Re: Revised proposed BOF charter, problem statement, and agenda] > > > > > > At 3:28 PM -0500 3/6/07, Wesley Eddy wrote: > > >I know of environments that need client-transparent solutions. Are > > >there really cases where a client-based solution is favorable to a > > >client-transparent solution? > > > > From our pre-list discussions, it seems that the answer is > > "yes" *if* the only thing the client needs to do is update > > its address but not re-authenticate. A fully-transparent > > solution requires that all gateways communicate about which > > addresses are already handed out (and possibly to whom they > > were handed), which puts a significant burden on the > > intra-gateway communication system. > > > > > It sure seems like most admins would like to have their servers > > >figure out how to do any failover, load-balancing, etc. and hide all > > >that from the clients, but maybe the perspective from my niche is > > >skewed. > > > > Of course that would be nice, but it also has to be > > completely reliable. The last thing you want is for the > > client to connect to the failed-to gateway and have the > > gateway say "go away, someone else is using the address you > > think is yours". It is much better for the gateway to be able > > to, in a DHCP-like fashion, say "hi there, here's your new > > address" or, even better, "hi there, your current address looks fine". > > > > --Paul Hoffman, Director > > --VPN Consortium > > > > > > From owner-ietf-ipsec-failover Wed Mar 7 07:23:48 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l27ENmEk064688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Mar 2007 07:23:48 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l27ENm0f064687; Wed, 7 Mar 2007 07:23:48 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l27ENkRL064671 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Wed, 7 Mar 2007 07:23:47 -0700 (MST) (envelope-from twan@nortel.com) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l27ENW602615; Wed, 7 Mar 2007 09:23:32 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Comments/questions about the assumptions [Was: Re: Revised proposed BOF charter, problem statement, and agenda] Date: Wed, 7 Mar 2007 09:23:31 -0500 Message-ID: In-Reply-To: <729b68be0703070517j176e8d19y7b797b126d0905a@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments/questions about the assumptions [Was: Re: Revised proposed BOF charter, problem statement, and agenda] Thread-Index: Acdgu0EkbJ4NVIoBTRWRBK5gl5mq5gAB1xJg References: <729b68be0703020612i7ee2e43fh5f99cf85615daec4@mail.gmail.com> <729b68be0703050211q4f70ec11xa368a05979cf198b@mail.gmail.com> <20070306202810.GK28150@grc.nasa.gov> <729b68be0703070517j176e8d19y7b797b126d0905a@mail.gmail.com> From: "Tao Wan" To: "Jean-Michel Combes" , "Narayanan, Vidya" Cc: "Paul Hoffman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l27ENmRK064675 Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 2007/3/7, Narayanan, Vidya : > > In addition to what Paul has said, there is one more point. In the > case of solutions that are transparent to the client, there may be > one gateway that is actively serving as a "primary" gateway and one or > more gateways acting as "backup" gateways; one of the backup gateways > takes over for the primary (i.e., assumes the IP address of the > primary and acquires all the clients that were being served by the > primary) when the primary gateway fails. This essentially leads to the > situation where all these gateways are capable of serving the same set > of subnets (i.e., have associations with the same DHCP servers) and > hence, more or less restricts the geographic distribution of these gateways. I don't agree with this conclusion: if I take again my example of solution based on MIPv6, the "real" IP addresses of the SGs are the CoA and the SGs may be distributed in a large scale. [Tao] In addition to MIPv6, anycast routing also allows geographically distributed servers to share common IP addresses. For example, some of the root DNS servers are using this method for load balancing and robustness. From owner-ietf-ipsec-failover Wed Mar 7 10:50:09 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l27Ho9Yl079204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Mar 2007 10:50:09 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l27Ho9Nf079203; Wed, 7 Mar 2007 10:50:09 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l27Ho7fu079195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 Mar 2007 10:50:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <729b68be0703070517j176e8d19y7b797b126d0905a@mail.gmail.com> <729b68be0703070428r13f49b21t940d66fbe3de186e@mail.gmail.com> <729b68be0703070403s19b8987ar8ac83787446d55f8@mail.gmail.com> References: <729b68be0703020612i7ee2e43fh5f99cf85615daec4@mail.gmail.com> <729b68be0703050211q4f70ec11xa368a05979cf198b@mail.gmail.com> <20070306202810.GK28150@grc.nasa.gov> <729b68be0703070517j176e8d19y7b797b126d0905a@mail.gmail.com> <729b68be0703020612i7ee2e43fh5f99cf85615daec4@mail.gmail.com> <729b68be0703050211q4f70ec11xa368a05979cf198b@mail.gmail.com> <20070306202810.GK28150@grc.nasa.gov> <729b68be0703070428r13f49b21t940d66fbe3de186e@mail.gmail.com> <729b68be0703020612i7ee2e43fh5f99cf85615daec4@mail.gmail.com> <729b68be0703050211q4f70ec11xa368a05979cf198b@mail.gmail.com> <729b68be0703070403s19b8987ar8ac83787446d55f8@mail.gmail.com> <729b68be0703020612i7ee2e43fh5f99cf85615daec4@mail.gmail.com> <729b68be0703050211q4f70ec11xa368a05979cf198b@mail.gmail.com> <20070306202810.GK28150@grc.nasa.gov> <729b68be0703070517j176e8d19y7b797b126d0905a@mail.gmail.com> Date: Wed, 7 Mar 2007 09:49:08 -0800 To: ietf-ipsec-failover@vpnc.org From: Paul Hoffman Subject: Re: Comments/questions about the assumptions [Was: Re: Revised proposed BOF charter, problem statement, and agenda] Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 1:03 PM +0100 3/7/07, Jean-Michel Combes wrote: >But it is said in the charter: "The SA re-establishment may >be with the same gateway (server) from which the client gets >disconnected or another gateway that is within the same secure domain >as the original gateway." >For me, the second case (if I've understood correctly) is the stateful >case and so you will need a protocol to transfer the state from the >backup gateway/state store to the new Security Gateway and the same >protocole will be used by the different SGs to store the states they >are managing periodicly. But read a few paragraphs down in the proposed charter: ===== The scope of this work involves the specification of stateless and stateful modes of recovery - in the stateless mode, the state is maintained on the client and no state is maintained in the infrastructure except on the serving gateway; in the stateful mode, the state is maintained in the infrastructure, either on a backup gateway or in a state store. ===== In the stateless case, there is no inter-gateway communication. The client hands the failed-to gateway an authenticated ticket saying "here is my relevant state". In other words, *each* of the cases in the latter paragraph (stateless, stateful) need to cover both of the cases from the earlier paragraph (same-gateway, different-gateway). >So, from my point of view, the entity storing the state can be seen, >more or less, like a sort of proxy for the protocol needed before too >and so, IMHO, this same protocol can be used directly between 2 SGs. That might be the solution that is adopted for the stateful different-gateway scenario. >So I think the solution that will be designed in this potential WG may >be used too in the SGs swtiching use-case too. That is the reason I >don't understand why inter-gateway protocol is out of scope :( No one said that inter-gateway protocol is out of scope! (I hope; I just reviewed the archives, but I could have missed it.) What is being said is that it is definitely not the entire scope. That is, a solution that only consists of an inter-gateway protocol misses both of the stateless scenarios. At 1:28 PM +0100 3/7/07, Jean-Michel Combes wrote: >IMHO, this issue is strongly linked to the mechanism which will manage >the detection of a fail-over. But we are still only talking about the scenarios and requirements, not yet the mechanism. Maybe this is where you (and others?) are getting tripped up. This should not be one of those IETF WGs that makes up the requirements document after they have decided on a protocol. To me, that's a complete waste of time and effort. At 2:17 PM +0100 3/7/07, Jean-Michel Combes wrote: >2007/3/7, Narayanan, Vidya : > >>In addition to what Paul has said, there is one more point. In the case >>of solutions that are transparent to the client, there may be one >...snip... >>have associations with the same DHCP servers) and hence, more or less >>restricts the geographic distribution of these gateways. > >I don't agree with this conclusion: if I take again my example of >solution based on MIPv6, the "real" IP addresses of the SGs are the >CoA and the SGs may be distributed in a large scale. If you believe that the only solution must run MIPv6 or something like it, that's fine, but it does not meet the requirements of other WGs who want this protocol. --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsec-failover Tue Mar 20 02:57:16 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2K9vGCe040627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Mar 2007 02:57:16 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2K9vGUX040626; Tue, 20 Mar 2007 02:57:16 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2K9uqOE040599 for ; Tue, 20 Mar 2007 02:57:15 -0700 (MST) (envelope-from Francis.Dupont@fdupont.fr) Received: from tao.fdupont.fr (tao.fdupont.fr [82.236.136.93]) by smtp4-g19.free.fr (Postfix) with ESMTP id 4105967549 for ; Tue, 20 Mar 2007 10:56:47 +0100 (CET) Received: from tao.fdupont.fr (localhost [127.0.0.1]) by tao.fdupont.fr (8.13.5/8.13.5) with ESMTP id l2K9ujgR023939 for ; Tue, 20 Mar 2007 10:56:45 +0100 (CET) Received: from tao.fdupont.fr (dupont@localhost) by tao.fdupont.fr (8.13.5/8.13.5/Submit) with ESMTP id l2K9uhcl023938 for ; Tue, 20 Mar 2007 10:56:44 +0100 (CET) Message-Id: <200703200956.l2K9uhcl023938@tao.fdupont.fr> From: Francis Dupont To: Brian Haley cc: Basavaraj Patil , mip6@ietf.org, ietf-ipsec-failover@vpnc.org Subject: Re: [Mip6] WG LC: draft-ietf-mip6-ha-switch-02.txt In-reply-to: Your message of Mon, 19 Mar 2007 14:48:48 -0400. <45FEDB10.2080201@hp.com> Date: Tue, 20 Mar 2007 10:00:58 +0100 Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In your previous mail you wrote: Hi Francis, Just re-reading emails before the WG meeting tomorrow and decided I should comment on this. First, thanks for the comments, I do have a few questions. Francis Dupont wrote: > Comments about draft-ietf-mip6-ha-switch-03.txt: > > - I really like the draft as I believe the service it provides is needed > and is a major missing piece for MIPv6 in the real world but I have > a critical concern with it: it collides with the IPsec failover > activity, i.e., we could get two competiting mechanisms for the same > thing. So this issue must be solved before going further: > * obviously the basic mechanisms are the same: the server sends to the > client a "look-somewhere-else" message with a list of potential "better" > servers. > * when the message is delivered to the MIPv6 stack the information > must be propagated IKE, when it is deliveded to IKE (for instance by > a new notification) it must be propagated to the MIPv6 stack: in all > cases there must be an API between both. > * when the two mechanisms overlap they don't handle exactly the same > cases so we'll need a way to extend the coverage of the chosen one. > * IKE has a little advantage for the security because it has a secured > built-in reliable request/reply facility. At the opposite a new > MH message needs an extra SPD entry, retransmission policy, etc. => as I've fixed the IPsec failover list address I've kept this long part. Sorry, I don't have any knowledge of the IPsec failover activity you mentioned and how it would compete with HA-switch. Can you point me at a draft? I don't follow any IETF IPsec-related WGs at the moment. => IMHO the easiest and fastest way is to go and/or read the agenda of the "ifare" BOF (tomorrow morning). It is true that there might have to be some API between the network stack and IKE, but it won't be necessary in all cases (and like Hui mentioned, isn't a MIPv6-specific requirement). In the HA-reliability case, the MN will have an SA with every HA already, so won't need to tell IKE to do anything during a switch. => can I translate this into it doesn't matter to keep unused IPsec SAs until they timeout? In the non-HA-reliability case there will be more work for the MN to do. I'm also not sure that trying to switch to using a different infrastructure (IKE) will fit in the timeframe in which a switch mechanism is required. => collaboration can help, no collaboration is likely a source of slow down. > - 1.Introduction (comment): note the security function can be considered > as an integral part of the Home Agent service. Did you want me to add some text? => IMHO only on good opportunity or if someone (else) asks for this. > - 4.1 Sending Home Agent Switch Messages "o A home agent to mobile > node authentication option": this idle introduces a bidding down > security issue. I propose to say the authentication MUST use the > same mechanism than BU/BA (this is what we want and this should keep > everybody happy :-). This issue will be on the slide at the WG meeting for discussion, I suppose it would make it both easier to specify and implement, and would support any future BU/BA security mechanism. => what do you think about my proposal? > - 5.1 Receiving Home Agent Switch Messages "o The packet MUST be > authenticated, either...": same issue (and same proposed solution). > > - 5.1 Receiving Home Agent Switch Messages: the presentation can suggest > the connection to a new HA has to be done after leaving the current one > (obviously this is not the intended behavior). There are two cases here: 1. Switch is from current HA - in this case you would break-before-make and teardown the old binding before replacing with one at the new HA. If we don't do this then ND-proxy could fail with the new HA, along with the BU. => IMHO this is not so clear: - the current HA can be clever enough to avoid the ND-proxy issue because it knows exactly what should happen. - when you move to another home link there is not possible ND-proxy issue. So the problem is not a wording problem as I believed, perhaps we need an explicit "break-before-make is authorized" notification. 2. Switch is from new HA - you would just send a BU to the new HA, assuming your current HA is dead. This method is assumed in the HA-reliability case. Thanks Francis.Dupont@fdupont.fr From owner-ietf-ipsec-failover Tue Mar 20 17:26:06 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2L0Q6R7004742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Mar 2007 17:26:06 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2L0Q6dA004741; Tue, 20 Mar 2007 17:26:06 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2L0Pi8M004731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 20 Mar 2007 17:26:04 -0700 (MST) (envelope-from vidyan@qualcomm.com) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l2L0PQR5030595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Mar 2007 17:25:26 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l2L0PO54024031; Tue, 20 Mar 2007 17:25:25 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 17:25:24 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Mip6] WG LC: draft-ietf-mip6-ha-switch-02.txt Date: Tue, 20 Mar 2007 17:25:20 -0700 Message-ID: In-Reply-To: <4600311A.4060402@hp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG LC: draft-ietf-mip6-ha-switch-02.txt Thread-Index: AcdrJObs95bxzS+UTMOf91WNqaY9JQAKT7PQ References: <200703200900.l2K90wSD023540@tao.fdupont.fr> <4600311A.4060402@hp.com> From: "Narayanan, Vidya" To: "Brian Haley" , "Francis Dupont" Cc: , "Basavaraj Patil" , X-OriginalArrivalTime: 21 Mar 2007 00:25:24.0966 (UTC) FILETIME=[6B459860:01C76B4F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l2L0Q48L004735 Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: So, it sounds like there is some confusion on what IFARE is proposing to do. IFARE is very much related to failover and state transfer (even if the client is only resuming a session with the same IPsec gateway) and very much unrelated to load balancing. Fundamentally, a failover solution must deal with state transfer. The IFARE charter proposes dealing with both stateless and stateful modes of operation - stateless mode implies state is stored in the client and presented to the gateway upon session resumption; stateful mode implies state is stored in the infrastructure. The main motivation for IFARE stems from the MIP6 use case, although there is nothing limiting the solution to that use case. If you are in Prague, please do plan on attending the BoF tomorrow morning. Thanks, Vidya > -----Original Message----- > From: Brian Haley [mailto:brian.haley@hp.com] > Sent: Tuesday, March 20, 2007 12:08 PM > To: Francis Dupont > Cc: mip6@ietf.org; Basavaraj Patil; ietf-ipsec-failover@vpnc.org > Subject: Re: [Mip6] WG LC: draft-ietf-mip6-ha-switch-02.txt > > Francis Dupont wrote: > > > Sorry, I don't have any knowledge of the IPsec failover > activity you > > mentioned and how it would compete with HA-switch. Can > you point me at > > a draft? I don't follow any IETF IPsec-related WGs at > the moment. > > > > => IMHO the easiest and fastest way is to go and/or read > the agenda of > > the "ifare" BOF (tomorrow morning). > > That's a long walk from my office in the US :) > > Quoting text from VijayD on another list since it seems related: > > "I am not sure how IFARE is related to this. IFARE does not > address transferring IPsec state. It is more explicitly > moving a client to another VPN gateway (load balancing, > failover, etc..). So transferring IPsec state is out of scope > for IFARE also." > > After reading the proposed charter that seems correct to me too. > > > It is true that there might have to be some API between > the network > > stack and IKE, but it won't be necessary in all cases > (and like Hui > > mentioned, isn't a MIPv6-specific requirement). In the > HA-reliability > > case, the MN will have an SA with every HA already, so > won't need to > > tell IKE to do anything during a switch. > > > > => can I translate this into it doesn't matter to keep unused IPsec > > SAs until they timeout? > > Yes, in the ha-reliability case we might have unused SAs for > all the backup HAs. > > > In the non-HA-reliability case there will be more work > for the MN to do. > > > > I'm also not sure that trying to switch to using a different > > infrastructure (IKE) will fit in the timeframe in which a switch > > mechanism is required. > > > > => collaboration can help, no collaboration is likely a > source of slow down. > > If IFARE turns-into a WG and decides to work on HA IPsec > failover that's great, it can specify a new protocol that > supercedes HA-switch, but the HA-switch draft is pretty > complete today. > > > > - 4.1 Sending Home Agent Switch Messages "o A home > agent to mobile > > > node authentication option": this idle introduces a > bidding down > > > security issue. I propose to say the authentication > MUST use the > > > same mechanism than BU/BA (this is what we want and > this should keep > > > everybody happy :-). > > > > This issue will be on the slide at the WG meeting for > discussion, I > > suppose it would make it both easier to specify and > implement, and would > > support any future BU/BA security mechanism. > > > > => what do you think about my proposal? > > I would support the change, but wanted to get the other > author's and WG feedback. > > > > - 5.1 Receiving Home Agent Switch Messages "o The > packet MUST be > > > authenticated, either...": same issue (and same > proposed solution). > > > > > > - 5.1 Receiving Home Agent Switch Messages: the > presentation can suggest > > > the connection to a new HA has to be done after > leaving the current one > > > (obviously this is not the intended behavior). > > > > There are two cases here: > > > > 1. Switch is from current HA - in this case you would > break-before-make > > and teardown the old binding before replacing with one > at the new HA. > > If we don't do this then ND-proxy could fail with the > new HA, along with > > the BU. > > > > => IMHO this is not so clear: > > - the current HA can be clever enough to avoid the > ND-proxy issue because > > it knows exactly what should happen. > > - when you move to another home link there is not possible > ND-proxy issue. > > So the problem is not a wording problem as I believed, > perhaps we need > > an explicit "break-before-make is authorized" notification. > > The other HA *should* be smart and not require the break, but > we can't assume that's the case. The only alternative right > now (finding a new HA when yours isn't responding) behaves > the same way, ha-switch is just a way to speed-up that > process. The ha-reliability soft switch mode is more > desirable of course. > > Thanks, > > -Brian > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > From owner-ietf-ipsec-failover Wed Mar 21 01:49:09 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2L8n9Il035809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 01:49:09 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2L8n9ih035808; Wed, 21 Mar 2007 01:49:09 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2L8mmPs035794 for ; Wed, 21 Mar 2007 01:49:09 -0700 (MST) (envelope-from gregory.ietf@gmail.com) Received: by py-out-1112.google.com with SMTP id b50so63770pyh for ; Wed, 21 Mar 2007 01:48:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:x-mailer:date:to:from:subject:mime-version:content-type:message-id; b=jO7thp67DIKysYxU5mKlxKoRYvzTl3zr7GnLXZGHVRUDkPHt+zLwHOYwpdwm1RuaYBdSBAppUz01A9okd/9jSROwWniLVYJAODp9gH7lzrJI7uepqdLMEchc/e7Ikdl6nm5g/IOhdrWM1vCsyuqBRrKU4YAOf8n5Ys8Cek7tjzE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:x-mailer:date:to:from:subject:mime-version:content-type:message-id; b=lEwJPxQi7hnRYUkDgTXwuDXb6zFUgaPyt1yTj3g+SgJz8cRwS/gLxxKQuBywbSrfZWI1gD2kBNCmDLYZVPQqsx61ULFILX16pGr4Kl0nlHajhrOsYPXrcbPJZhRUiK8JvcUJ5Y2s57xGKXu+7/RdVszWhfAKXpfSGIE2oyzEKyo= Received: by 10.35.126.2 with SMTP id d2mr1073290pyn.1174466928306; Wed, 21 Mar 2007 01:48:48 -0700 (PDT) Received: from gregory-lt.gmail.com ( [66.129.225.151]) by mx.google.com with ESMTP id f75sm2876379pye.2007.03.21.01.48.45; Wed, 21 Mar 2007 01:48:47 -0700 (PDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 21 Mar 2007 01:48:36 -0700 To: ietf-ipsec-failover@vpnc.org From: "Gregory M. Lebovitz" Subject: Lebo's feedback on charter Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_73858733==.ALT" Message-ID: <4600f16f.6245f154.432a.ffffb6ef@mx.google.com> Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=====================_73858733==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hey team, Here is my written feedback on the charter. I may share some of this today in meeting. But wanted the list to have it written. - Charter mentions not wanting to have to re-do EAP responses. But won't EAP responses that the gateway will experience often return attributes that are needed by the gateway too, attributes that allow the gateway to appropriately apply policy of various sorts to this remote peer and its traffic? Can't recover those w/o the EAP exchange, right, as in after a gtwy reboot? - add: it is also assumed that the gateways may be located in different physical locations, far from eachother, and thus state syncing between them directly is complex if not impractical. - vendors already have stateful sync. Suggest we charter to focus ONLY on stateless. - unclear from the text if we are or aren't solving the gtwy-to-gtwy stateful sync'ing problem. this paragraph: "The scope of this work involves the specification of stateless and stateful modes of recovery - in the stateless mode, the state is maintained on the client and no state is maintained in the infrastructure except on the serving gateway; in the stateful mode, the state is maintained in the infrastructure, either on a backup gateway or in a state store." makes me think that we are including in our focus the stateful sync between the gateways. However, the following paragraph "Support for capabilities beyond those listed above is out of scope: more precisely, specification of a gateway to gateway state transport protocol, protocol or payload extensions or modifications to support load balancing between gateways is out of scope." makes me think we are NOT including the gtwy-to-gtwy stateful sync problem. So which is it? I suggest we only focus on Gtwy1 to client, and Gtwy2 to client, but not Gtwy1-Gtwy2 sync'ing. Happy to see this work progress to WG. Gregory. +++++++++++++++++++++++ IETF-related email from Gregory M. Lebovitz Juniper Networks g r e go r y d o t i e tf a t g m a i l do t c o m --=====================_73858733==.ALT Content-Type: text/html; charset="us-ascii" Hey team,
Here is my written feedback on the charter. I may share some of this today in meeting. But wanted the list to have it written.

- Charter mentions not wanting to have to re-do EAP responses. But won't EAP responses that the gateway will experience often return attributes that are needed by the gateway too, attributes that allow the gateway to appropriately apply policy of various sorts to this remote peer and its traffic? Can't recover those w/o the EAP exchange, right, as in after a gtwy reboot?

- add: it is also assumed that the gateways may be located in different physical locations, far from eachother, and thus state syncing between them directly is complex if not impractical.

- vendors already have stateful sync. Suggest we charter to focus ONLY on stateless.

- unclear from the text if we are or aren't solving the gtwy-to-gtwy stateful sync'ing problem. this paragraph:

"
The scope of this work involves the specification of stateless
and
stateful modes of recovery - in the stateless mode, the state is
maintained on the client and no state is maintained in the
infrastructure except on the serving gateway; in the stateful mode, the
state is maintained in the infrastructure, either on a backup gateway or
in a state store." 

  makes me think that we are including in our focus the stateful
sync between the gateways. However, the following paragraph

"Support for capabilities beyond those listed above is out of scope:
more
precisely, specification of a gateway to gateway state transport
protocol, protocol or payload extensions or modifications to support
load balancing between gateways is out of scope."

  makes me think we are NOT including the gtwy-to-gtwy stateful sync
problem. 

So which is it? I suggest we only focus on Gtwy1 to client, and Gtwy2 to
client, but not Gtwy1-Gtwy2 sync'ing.
Happy to see this work progress to WG.
Gregory.

+++++++++++++++++++++++
IETF-related email from
Gregory M. Lebovitz
Juniper Networks
g r e go r  y d o t  i e tf a t  g m a i l  do t c o  m --=====================_73858733==.ALT-- From owner-ietf-ipsec-failover Wed Mar 21 02:20:42 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2L9Kg49037558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 02:20:42 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2L9Kgoo037557; Wed, 21 Mar 2007 02:20:42 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2L9KLDa037521 for ; Wed, 21 Mar 2007 02:20:41 -0700 (MST) (envelope-from Francis.Dupont@fdupont.fr) Received: from tao.fdupont.fr (tao.fdupont.fr [82.236.136.93]) by smtp4-g19.free.fr (Postfix) with ESMTP id 0088967958; Wed, 21 Mar 2007 10:20:19 +0100 (CET) Received: from tao.fdupont.fr (localhost [127.0.0.1]) by tao.fdupont.fr (8.13.5/8.13.5) with ESMTP id l2L9KGV4026970; Wed, 21 Mar 2007 10:20:18 +0100 (CET) Received: from tao.fdupont.fr (dupont@localhost) by tao.fdupont.fr (8.13.5/8.13.5/Submit) with ESMTP id l2L9KFBL026966; Wed, 21 Mar 2007 10:20:15 +0100 (CET) Message-Id: <200703210920.l2L9KFBL026966@tao.fdupont.fr> From: Francis Dupont To: Brian Haley cc: mip6@ietf.org, ietf-ipsec-failover@vpnc.org, Basavaraj Patil Subject: Re: [Mip6] WG LC: draft-ietf-mip6-ha-switch-02.txt In-reply-to: Your message of Tue, 20 Mar 2007 15:08:10 -0400. <4600311A.4060402@hp.com> Date: Wed, 21 Mar 2007 10:20:14 +0100 Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In your previous mail you wrote: > => IMHO the easiest and fastest way is to go and/or read the agenda of > the "ifare" BOF (tomorrow morning). That's a long walk from my office in the US :) => this is why I added "read the agenda..." (:-). Quoting text from VijayD on another list since it seems related: "I am not sure how IFARE is related to this. IFARE does not address transferring IPsec state. It is more explicitly moving a client to another VPN gateway (load balancing, failover, etc..). So transferring IPsec state is out of scope for IFARE also." After reading the proposed charter that seems correct to me too. => I don't know what is exactly "transferring IPsec state" but low latency failover (something is the slide in the screen now at ifare session) should include something at least close... > => collaboration can help, no collaboration is likely a source of > slow down. If IFARE turns-into a WG and decides to work on HA IPsec failover that's great, it can specify a new protocol that supercedes HA-switch, but the HA-switch draft is pretty complete today. => I believe that nobody wants two competitive protocols doing the same thing... BTW I checked at the beginning of the session whether such collaboration was in the agenda and the answer was yes (BTW I specified the mobile IP cloud because of the proposed merge of mip6/nemo/monami6). > => IMHO this is not so clear: > - the current HA can be clever enough to avoid the ND-proxy issue because > it knows exactly what should happen. > - when you move to another home link there is not possible ND-proxy issue. > So the problem is not a wording problem as I believed, perhaps we need > an explicit "break-before-make is authorized" notification. The other HA *should* be smart and not require the break, but we can't assume that's the case. => but the current HA has a better knowledge of the context so IMHO we should use it to control the way the switch could be done when some ways can raise issues. The only alternative right now (finding a new HA when yours isn't responding) behaves the same way, ha-switch is just a way to speed-up that process. => in fact I don't believe it is true because the client doesn't know if things were broken for the HA... So you can have a HA only working for the ND-proxy part and messing the DAD from the other HA! Of course this is not really related to the HA-switch protocol (i.e., there is nothing we can do so nothing to put in the document). The ha-reliability soft switch mode is more desirable of course. => yes but the world is not (yet :-) perfect. Thanks Francis.Dupont@fdupont.fr From owner-ietf-ipsec-failover Wed Mar 21 02:28:51 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2L9SoIS038159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 02:28:51 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2L9SoC5038158; Wed, 21 Mar 2007 02:28:50 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2L9SUlK038131 for ; Wed, 21 Mar 2007 02:28:50 -0700 (MST) (envelope-from gregory.ietf@gmail.com) Received: by py-out-1112.google.com with SMTP id b50so67002pyh for ; Wed, 21 Mar 2007 02:28:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:x-mailer:date:to:from:subject:cc:mime-version:content-type:message-id; b=dMOFPvntZgjS+gQqKUMlfeUavdgWFsucEEmo9mDNA0N6V+Wzyqp0jH5yWFUpCkfvTZxxi5us64QPvR6LuPkgk62dN0WKAILvzu0XnWjUVME8nZWImgC46T0U+qHa+b4xN9yjzQWFVxN1mHc3ooktkfTNplZYpdnbGdMV3XKGVVY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:x-mailer:date:to:from:subject:cc:mime-version:content-type:message-id; b=qaIunuZ6ya/cltqdyjc0VE6OpedlU6KfmTpyGnev77SBlFg5HpFNZAjF3niUs6tW6Dp29GkbOPiX9DLnfS13G9QNT6whmEQa3gxZFOy4wGUFKXj71PZrrQSaxZvlRclxoreMJ8QAUryouU1DvcKAJW0BpDi+J83a8vHab675p3s= Received: by 10.35.93.19 with SMTP id v19mr1080394pyl.1174469307420; Wed, 21 Mar 2007 02:28:27 -0700 (PDT) Received: from gregory-lt.gmail.com ( [66.129.225.151]) by mx.google.com with ESMTP id f51sm2918296pyh.2007.03.21.02.28.25; Wed, 21 Mar 2007 02:28:26 -0700 (PDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 21 Mar 2007 02:28:21 -0700 To: Paul Hoffman From: "Gregory M. Lebovitz" Subject: slide for scope Cc: ietf-ipsec-failover@vpnc.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_76237994==_" Message-ID: <4600faba.05e4d216.18b0.ffffc275@mx.google.com> Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=====================_76237994==_ Content-Type: text/plain; charset="us-ascii"; format=flowed here is the slide displaying a proposed scope. +++++++++++++++++++++++ IETF-related email from Gregory M. Lebovitz Juniper Networks g r e go r y d o t i e tf a t g m a i l do t c o m --=====================_76237994==_ Content-Type: application/pdf; name="scopeGraphic-00.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="scopeGraphic-00.pdf" JVBERi0xLjQNJeLjz9MNCjYgMCBvYmo8PC9IWzUxNiAxNDJdL0xpbmVhcml6ZWQgMS9FIDUwNjMv TCA5MDAyL04gMS9PIDkvVCA4ODM2Pj4NZW5kb2JqDSAgICAgICAgICAgICAgICAgICAgICAgICAg DQp4cmVmDQo2IDExDQowMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDA2NTggMDAwMDAgbg0KMDAw MDAwMDUxNiAwMDAwMCBuDQowMDAwMDAwNzM0IDAwMDAwIG4NCjAwMDAwMDA4NjIgMDAwMDAgbg0K MDAwMDAwMDk3MiAwMDAwMCBuDQowMDAwMDAxMDA2IDAwMDAwIG4NCjAwMDAwMDE3MDYgMDAwMDAg bg0KMDAwMDAwMjA5NyAwMDAwMCBuDQowMDAwMDA0NzY2IDAwMDAwIG4NCjAwMDAwMDQ5ODcgMDAw MDAgbg0KdHJhaWxlcg0KPDwvU2l6ZSAxNy9QcmV2IDg4MjYvUm9vdCA3IDAgUi9JbmZvIDUgMCBS L0lEWzw3NjUwMWJlMDc1OGY1NWZlZTlhN2Y3Y2M3ZjgyYjQ3ZT48NzRhYjlkYjkwMjgzNzA0M2I1 ZjMxZmM2ODMzNWU4ZDM+XT4+DQpzdGFydHhyZWYNCjANCiUlRU9GDQogICAgICAgICAgICAgICAg IA0KOCAwIG9iajw8L0xlbmd0aCA2NS9GaWx0ZXIvRmxhdGVEZWNvZGUvTCA3NS9TIDM4Pj5zdHJl YW0NCnjaYmBg4GBgYApgAAKBlwyogAmIWRg4GpiQxDigmIFBiYGH9YEPA9MssShv7g1aICFGBgZh S6hGC4AAAwDkrQYWDQplbmRzdHJlYW0NZW5kb2JqDTcgMCBvYmo8PC9QYWdlcyAzIDAgUi9UeXBl L0NhdGFsb2cvUGFnZUxhYmVscyAxIDAgUi9NZXRhZGF0YSA0IDAgUj4+DWVuZG9iag05IDAgb2Jq PDwvQ29udGVudHMgMTIgMCBSL1R5cGUvUGFnZS9QYXJlbnQgMyAwIFIvUm90YXRlIDkwL01lZGlh Qm94WzAgMCA2MTIgNzkyXS9Dcm9wQm94WzAgMCA2MTIgNzkyXS9SZXNvdXJjZXMgMTAgMCBSPj4N ZW5kb2JqDTEwIDAgb2JqPDwvQ29sb3JTcGFjZTw8L0NzNiAxMSAwIFI+Pi9Gb250PDwvVFQyIDEz IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0XS9FeHRHU3RhdGU8PC9HUzEgMTYgMCBSPj4+Pg1lbmRv YmoNMTEgMCBvYmpbL0lDQ0Jhc2VkIDE0IDAgUl0NZW5kb2JqDTEyIDAgb2JqPDwvTGVuZ3RoIDYz MS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSInMlU1v2kAQhu/7K+ZIK7Hst+3eElohqjSJ hNtL1EPqmojIQAVUqP++7+za1Jiqam4xWDvMzu48Mzs7TKb7QNWedPzsq42YzBaanvbCBsLXO0WZ UbSrxVIomZMiJUM01LQioa0hbzNaR8kFI50h7TPpySlIeRHHShijWp1xoTNkkVdjGlLQWvqckmXI 0moeK5F2jDq4aQ0735VYvhUTDmS6YD58FtNb8H1ESM/gzTwdSSv6RA9fFX1/JdB75NMRvynx2mIb pSMV7EyIVMHyHoF0EQdmCkljvOmsWOSlmGUp8wmJDa1Na3kEUtwu6thbMuwcxzy+AgpOTGbxIDl5 lrs4FjiEmKUAU8jeUe7assQh5zjcy7mFuC7FpCyBSCUb6pzGmosYnlDGWgPEULnG1JMYK6kUCMoK P8ujGM0Ox1/68U35LD6UqcBwU/7F5lEkXvXZLlQRqQeCcpFcWroHEh2blzgOnDt35nioGjpOGTDa Dx3rby+L2HszjPhM9feIfbAXEXeO+dbG6yp0wRcqcDUWJsbTCJ0jndaxjiVs0sDHf8A69DELBJej pQ1K52JuSI1DBLU1TsKkpVZcKqNps6o3h9uWnfujV7oIbRdSbRdy8tSEcD3S2axPbjmCBzbhN/ao 2GV06GwKFW3OmQortSGrMmkCM/UKeHR1f38zn16V87seWctkQdJ1QtyYIocXOGChYcGqkASHZhWn +G+gSX0TUk81RPImkwUegsWJKMTbNL/FKWx/1O+In9murjd0s9rUe+ZTWC9RDu9TUuM6xMbr7j6X tF3+WTvfHHaP4+vmZ03bXfvry2rb1Ic20N8CDAAMmmlyCg0KZW5kc3RyZWFtDWVuZG9iag0xMyAw IG9iajw8L1R5cGUvRm9udC9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvQmFzZUZvbnQvQXJpYWxN VC9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTIxL1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0 b3IgMTUgMCBSL1dpZHRoc1syNzggMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMzMzIDAgMCAwIDU1 NiA1NTYgMCAwIDAgMCAwIDAgMCAyNzggMCAwIDAgMCAwIDAgNjY3IDY2NyA3MjIgMCAwIDAgNzc4 IDAgMjc4IDAgMCA1NTYgMCA3MjIgNzc4IDY2NyAwIDAgMCA2MTEgNzIyIDY2NyAwIDAgMCAwIDAg MCAwIDAgMCAwIDU1NiA1NTYgNTAwIDAgNTU2IDI3OCAwIDAgMjIyIDAgMCAyMjIgMCA1NTYgNTU2 IDU1NiAwIDMzMyA1MDAgMjc4IDU1NiAwIDcyMiAwIDUwMF0+Pg1lbmRvYmoNMTQgMCBvYmo8PC9M ZW5ndGggMjU3NS9GaWx0ZXIvRmxhdGVEZWNvZGUvTiAzL0FsdGVybmF0ZS9EZXZpY2VSR0I+PnN0 cmVhbQ0KSImclnlUU3cWx39vyZ6QlbDDYw1bgLAGkDVsYZEdBFEISQgBEkJI2AVBRAUURUSEqpUy 1m10Rk9FnS6uY60O1n3q0gP1MOroOLQW146dFzhHnU5nptPvH+/3Ofd37+/d3733nfMAoCelqrXV MAsAjdagz0qMxRYVFGKkCQADCiACEQAyea0uLTshB+CSxkuwWtwJ/IueXgeQab0iTMrAMPD/iS3X 6Q0AQBk4ByiUtXKcO3GuqjfoTPYZnHmllSaGURPr8QRxtjSxap6953zmOdrECo1WgbMpZ51CozDx aZxX1xmVOCOpOHfVqZX1OF/F2aXKqFHj/NwUq1HKagFA6Sa7QSkvx9kPZ7o+J0uC8wIAyHTVO1z6 DhuUDQbTpSTVuka9WlVuwNzlHpgoNFSMJSnrq5QGgzBDJq+U6RWYpFqjk2kbAZi/85w4ptpieJGD RaHBwUJ/H9E7hfqvm79Qpt7O05PMuZ5B/AtvbT/nVz0KgHgWr836t7bSLQCMrwTA8uZbm8v7ADDx vh2++M59+KZ5KTcYdGG+vvX19T5qpdzHVNA3+p8Ov0DvvM/HdNyb8mBxyjKZscqAmeomr66qNuqx Wp1MrsSEPx3iXx3483l4ZynLlHqlFo/Iw6dMrVXh7dYq1AZ1tRZTa/9TE39l2E80P9e4uGOvAa/Y B7Au8gDytwsA5dIAUrQN34He9C2Vkgcy8DXf4d783M8J+vdT4T7To1atmouTZOVgcqO+bn7P9FkC AqACJuABK2APnIE7EAJ/EALCQTSIB8kgHeSAArAUyEE50AA9qActoB10gR6wHmwCw2A7GAO7wX5w EIyDj8EJ8EdwHnwJroFbYBJMg4dgBjwFryAIIkEMiAtZQQ6QK+QF+UNiKBKKh1KhLKgAKoFUkBYy Qi3QCqgH6oeGoR3Qbuj30FHoBHQOugR9BU1BD6DvoJcwAtNhHmwHu8G+sBiOgVPgHHgJrIJr4Ca4 E14HD8Gj8D74MHwCPg9fgyfhh/AsAhAawkccESEiRiRIOlKIlCF6pBXpRgaRUWQ/cgw5i1xBJpFH yAuUiHJRDBWi4WgSmovK0Rq0Fe1Fh9Fd6GH0NHoFnUJn0NcEBsGW4EUII0gJiwgqQj2hizBI2En4 iHCGcI0wTXhKJBL5RAExhJhELCBWEJuJvcStxAPE48RLxLvEWRKJZEXyIkWQ0kkykoHURdpC2kf6 jHSZNE16TqaRHcj+5ARyIVlL7iAPkveQPyVfJt8jv6KwKK6UMEo6RUFppPRRxijHKBcp05RXVDZV QI2g5lArqO3UIep+6hnqbeoTGo3mRAulZdLUtOW0IdrvaJ/Tpmgv6By6J11CL6Ib6evoH9KP07+i P2EwGG6MaEYhw8BYx9jNOMX4mvHcjGvmYyY1U5i1mY2YHTa7bPaYSWG6MmOYS5lNzEHmIeZF5iMW heXGkrBkrFbWCOso6wZrls1li9jpbA27l72HfY59n0PiuHHiOQpOJ+cDzinOXS7CdeZKuHLuCu4Y 9wx3mkfkCXhSXgWvh/db3gRvxpxjHmieZ95gPmL+ifkkH+G78aX8Kn4f/yD/Ov+lhZ1FjIXSYo3F fovLFs8sbSyjLZWW3ZYHLK9ZvrTCrOKtKq02WI1b3bFGrT2tM63rrbdZn7F+ZMOzCbeR23TbHLS5 aQvbetpm2TbbfmB7wXbWzt4u0U5nt8XulN0je759tH2F/YD9p/YPHLgOkQ5qhwGHzxz+ipljMVgV NoSdxmYcbR2THI2OOxwnHF85CZxynTqcDjjdcaY6i53LnAecTzrPuDi4pLm0uOx1uelKcRW7lrtu dj3r+sxN4Jbvtspt3O2+wFIgFTQJ9gpuuzPco9xr3Efdr3oQPcQelR5bPb70hD2DPMs9RzwvesFe wV5qr61el7wJ3qHeWu9R7xtCujBGWCfcK5zy4fuk+nT4jPs89nXxLfTd4HvW97VfkF+V35jfLRFH lCzqEB0Tfefv6S/3H/G/GsAISAhoCzgS8G2gV6AycFvgn4O4QWlBq4JOBv0jOCRYH7w/+EGIS0hJ yHshN8Q8cYa4V/x5KCE0NrQt9OPQF2HBYYawg2F/DxeGV4bvCb+/QLBAuWBswd0IpwhZxI6IyUgs siTy/cjJKMcoWdRo1DfRztGK6J3R92I8Yipi9sU8jvWL1cd+FPtMEiZZJjkeh8QlxnXHTcRz4nPj h+O/TnBKUCXsTZhJDEpsTjyeREhKSdqQdENqJ5VLd0tnkkOSlyWfTqGnZKcMp3yT6pmqTz2WBqcl p21Mu73QdaF24Xg6SJemb0y/kyHIqMn4QyYxMyNzJPMvWaKslqyz2dzs4uw92U9zYnP6cm7luuca c0/mMfOK8nbnPcuPy+/Pn1zku2jZovMF1gXqgiOFpMK8wp2Fs4vjF29aPF0UVNRVdH2JYEnDknNL rZdWLf2kmFksKz5UQijJL9lT8oMsXTYqmy2Vlr5XOiOXyDfLHyqiFQOKB8oIZb/yXllEWX/ZfVWE aqPqQXlU+WD5I7VEPaz+tiKpYnvFs8r0yg8rf6zKrzqgIWtKNEe1HG2l9nS1fXVD9SWdl65LN1kT VrOpZkafot9ZC9UuqT1i4OE/UxeM7saVxqm6yLqRuuf1efWHGtgN2oYLjZ6NaxrvNSU0/aYZbZY3 n2xxbGlvmVoWs2xHK9Ra2nqyzbmts216eeLyXe3U9sr2P3X4dfR3fL8if8WxTrvO5Z13Vyau3Ntl 1qXvurEqfNX21ehq9eqJNQFrtqx53a3o/qLHr2ew54deee8Xa0Vrh9b+uK5s3URfcN+29cT12vXX N0Rt2NXP7m/qv7sxbePhAWyge+D7TcWbzg0GDm7fTN1s3Dw5lPpPAKQBW/6YuJkkmZCZ/JpomtWb QpuvnByciZz3nWSd0p5Anq6fHZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum/adu p+CoUqjEqTepqaocqo+rAqt1q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOutCW0 nLUTtYq2AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzBZ8Hj wl/C28NYw9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83z7jQ OdC60TzRvtI/0sHTRNPG1EnUy9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3ZbeHN6i 3ynfr+A24L3hROHM4lPi2+Nj4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R7Zzu KO6070DvzPBY8OXxcvH/8ozzGfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9Kf26 /kv+3P9t//8CDAD3hPP7Cg0KZW5kc3RyZWFtDWVuZG9iag0xNSAwIG9iajw8L1R5cGUvRm9udERl c2NyaXB0b3IvRm9udEJCb3hbLTY2NSAtMzI1IDIwMDAgMTAwNl0vRm9udE5hbWUvQXJpYWxNVC9G bGFncyAzMi9TdGVtViA4OC9DYXBIZWlnaHQgNzE4L1hIZWlnaHQgNTE1L0FzY2VudCA5MDUvRGVz Y2VudCAtMjExL0l0YWxpY0FuZ2xlIDAvRm9udEZhbWlseShBcmlhbCkvRm9udFN0cmV0Y2gvTm9y bWFsL0ZvbnRXZWlnaHQgNDAwPj4NZW5kb2JqDTE2IDAgb2JqPDwvVHlwZS9FeHRHU3RhdGUvU0Eg ZmFsc2UvT1AgZmFsc2UvU00gMC4wMi9vcCBmYWxzZS9PUE0gMT4+DWVuZG9iag0xIDAgb2JqPDwv TnVtc1swIDIgMCBSXT4+DWVuZG9iag0yIDAgb2JqPDwvUy9EPj4NZW5kb2JqDTMgMCBvYmo8PC9D b3VudCAxL0tpZHNbOSAwIFJdL1R5cGUvUGFnZXM+Pg1lbmRvYmoNNCAwIG9iajw8L0xlbmd0aCAz MzQ1L1R5cGUvTWV0YWRhdGEvU3VidHlwZS9YTUw+PnN0cmVhbQ0KPD94cGFja2V0IGJlZ2luPSfv u78nIGlkPSdXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQnPz4KPD9hZG9iZS14YXAtZmlsdGVycyBl c2M9IkNSTEYiPz4NCjx4OnhtcG1ldGEgeG1sbnM6eD0nYWRvYmU6bnM6bWV0YS8nIHg6eG1wdGs9 J1hNUCB0b29sa2l0IDIuOS4xLTEzLCBmcmFtZXdvcmsgMS42Jz4NCjxyZGY6UkRGIHhtbG5zOnJk Zj0naHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIycgeG1sbnM6aVg9 J2h0dHA6Ly9ucy5hZG9iZS5jb20vaVgvMS4wLyc+DQo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91 dD0ndXVpZDo5OTY3MDA4My02ZjIzLTRhNzEtYmZiNy1mMjdhZTUwMTE3MDknIHhtbG5zOnBkZj0n aHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4zLycgcGRmOlByb2R1Y2VyPSdBY3JvYmF0IERpc3Rp bGxlciA2LjAgKFdpbmRvd3MpJz48L3JkZjpEZXNjcmlwdGlvbj4NCjxyZGY6RGVzY3JpcHRpb24g cmRmOmFib3V0PSd1dWlkOjk5NjcwMDgzLTZmMjMtNGE3MS1iZmI3LWYyN2FlNTAxMTcwOScgeG1s bnM6eGFwPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvJyB4YXA6Q3JlYXRvclRvb2w9J1BT Y3JpcHQ1LmRsbCBWZXJzaW9uIDUuMi4yJyB4YXA6TW9kaWZ5RGF0ZT0nMjAwNy0wMy0yMVQwMjoy NzozOC0wNzowMCcgeGFwOkNyZWF0ZURhdGU9JzIwMDctMDMtMjFUMDI6Mjc6MzgtMDc6MDAnPjwv cmRmOkRlc2NyaXB0aW9uPg0KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6OTk2NzAw ODMtNmYyMy00YTcxLWJmYjctZjI3YWU1MDExNzA5JyB4bWxuczp4YXBNTT0naHR0cDovL25zLmFk b2JlLmNvbS94YXAvMS4wL21tLycgeGFwTU06RG9jdW1lbnRJRD0ndXVpZDo3YjcyNzA5Zi01Zjgx LTQ4NWUtODA1Ny1jZGQ2NzMzNmE5YmQnLz4NCjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1 dWlkOjk5NjcwMDgzLTZmMjMtNGE3MS1iZmI3LWYyN2FlNTAxMTcwOScgeG1sbnM6ZGM9J2h0dHA6 Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvJyBkYzpmb3JtYXQ9J2FwcGxpY2F0aW9uL3BkZic+ PGRjOnRpdGxlPjxyZGY6QWx0PjxyZGY6bGkgeG1sOmxhbmc9J3gtZGVmYXVsdCc+TWljcm9zb2Z0 IFBvd2VyUG9pbnQgLSBzY29wZUdyYXBoaWMtMDAucHB0PC9yZGY6bGk+PC9yZGY6QWx0PjwvZGM6 dGl0bGU+PGRjOmNyZWF0b3I+PHJkZjpTZXE+PHJkZjpsaT5HcmVnb3J5PC9yZGY6bGk+PC9yZGY6 U2VxPjwvZGM6Y3JlYXRvcj48L3JkZjpEZXNjcmlwdGlvbj4NCjwvcmRmOlJERj4NCjwveDp4bXBt ZXRhPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg IAo8P3hwYWNrZXQgZW5kPSd3Jz8+DQplbmRzdHJlYW0NZW5kb2JqDTUgMCBvYmo8PC9Nb2REYXRl KEQ6MjAwNzAzMjEwMjI3MzgtMDcnMDAnKS9DcmVhdGlvbkRhdGUoRDoyMDA3MDMyMTAyMjczOC0w NycwMCcpL1RpdGxlKE1pY3Jvc29mdCBQb3dlclBvaW50IC0gc2NvcGVHcmFwaGljLTAwLnBwdCkv Q3JlYXRvcihQU2NyaXB0NS5kbGwgVmVyc2lvbiA1LjIuMikvUHJvZHVjZXIoQWNyb2JhdCBEaXN0 aWxsZXIgNi4wIFwoV2luZG93c1wpKS9BdXRob3IoR3JlZ29yeSk+Pg1lbmRvYmoNeHJlZg0KMCA2 DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDUwNjMgMDAwMDAgbg0KMDAwMDAwNTA5NiAwMDAw MCBuDQowMDAwMDA1MTE5IDAwMDAwIG4NCjAwMDAwMDUxNjkgMDAwMDAgbg0KMDAwMDAwODU5MCAw MDAwMCBuDQp0cmFpbGVyDQo8PC9TaXplIDY+Pg0Kc3RhcnR4cmVmDQoxMTYNCiUlRU9GDQo= --=====================_76237994==_-- From owner-ietf-ipsec-failover Wed Mar 21 03:15:23 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2LAFNe2043050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 03:15:23 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2LAFNug043049; Wed, 21 Mar 2007 03:15:23 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from randymail-a10.g.dreamhost.com (sd-green-bigip-81.dreamhost.com [208.97.132.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2LAF2Fa043026 for ; Wed, 21 Mar 2007 03:15:22 -0700 (MST) (envelope-from ekr@networkresonance.com) Received: from delta.rtfm.com (dhcp-1646.ietf68.org [130.129.22.70]) by randymail-a10.g.dreamhost.com (Postfix) with ESMTP id 9B44F10F86B for ; Wed, 21 Mar 2007 03:15:01 -0700 (PDT) Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 2EB011CC22 for ; Wed, 21 Mar 2007 03:13:55 -0700 (PDT) To: ietf-ipsec-failover@vpnc.org Subject: X-Mailer: MH-E 7.4.2; nmh 1.2; XEmacs 21.4 (patch 20) Date: Wed, 21 Mar 2007 03:13:55 -0700 From: EKR Message-Id: <20070321101355.2EB011CC22@delta.rtfm.com> Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: subscribe From owner-ietf-ipsec-failover Wed Mar 21 03:30:53 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2LAUrvh043935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 03:30:53 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2LAUrcK043934; Wed, 21 Mar 2007 03:30:53 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2LAUWi9043902 for ; Wed, 21 Mar 2007 03:30:52 -0700 (MST) (envelope-from gregory.ietf@gmail.com) Received: by nz-out-0506.google.com with SMTP id s1so162646nze for ; Wed, 21 Mar 2007 03:30:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:x-mailer:date:to:from:subject:mime-version:content-type:message-id; b=cLlS6E8SHz0j4ygbzvRmz3CCpcfRLXaUfQpHHIRyzSCPpeZEZDWD5/8uEfDRYnXCJ256hEc+KVynZJmZYxrw0iJMaB9xMpOU8bjf+97b3xgR6IhPTJYewYmtW0FDYFLGhbbfuT8hx8Z0b3lomb7/KkC1QDhABrKzW7Sn/9pyS2o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:x-mailer:date:to:from:subject:mime-version:content-type:message-id; b=oRE3J4hHOtVy5d78m1DrmxdKsRIgZA0pZXbVlAqb6HjCq0wzc3+OPymOz88UeNnRspVug7wBxR/o7lh18HQjNBrjf6aXJJtCVJV6LdmAjuasFx0AReJZJu4iJ4NDDIKdITlusMFDyhG+X3EBhhlvMKFsvLynzaEgWs4atufkv00= Received: by 10.35.59.5 with SMTP id m5mr1179636pyk.1174473025548; Wed, 21 Mar 2007 03:30:25 -0700 (PDT) Received: from gregory-lt.gmail.com ( [66.129.225.151]) by mx.google.com with ESMTP id f24sm3597038pyh.2007.03.21.03.30.23; Wed, 21 Mar 2007 03:30:24 -0700 (PDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 21 Mar 2007 03:30:18 -0700 To: ietf-ipsec-failover@vpnc.org From: "Gregory M. Lebovitz" Subject: scope clarifications, use cases Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <46010940.57c790c9.49f9.493b@mx.google.com> Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here is what I read aloud at the Prague BoF re: in-scope and out of scope statements and use cases. Out of scope: - Same-IP, directly connected, multiple vendor, transparent-to-client, gateway-to-gateway state sync (with this I've tried to describe the proprietary transparent state-sync mechanisms in place today by most vendors). In Scope: - non-directly-connected, multiple vendor, client-aware, rapid IPsec resumption to 2nd gateway - client may have an active role in the solution, but depends on solution design - gateways may need to talk to each other a bit for the solution, but depends on solution design Do these definitions help? Some use cases to capture: - inter-site gateways - intra-site gateways with no direct, gtwy-to-gtwy state sync - single gateway that restarts Gregory +++++++++++++++++++++++ IETF-related email from Gregory M. Lebovitz Juniper Networks g r e go r y d o t i e tf a t g m a i l do t c o m From owner-ietf-ipsec-failover Wed Mar 21 07:05:05 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2LE55ck061789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 07:05:05 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2LE556b061788; Wed, 21 Mar 2007 07:05:05 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2LE4itS061773 for ; Wed, 21 Mar 2007 07:05:05 -0700 (MST) (envelope-from gregory.ietf@gmail.com) Received: by nz-out-0506.google.com with SMTP id s1so213654nze for ; Wed, 21 Mar 2007 07:04:44 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:x-mailer:date:to:from:subject:cc:mime-version:content-type:message-id; b=ZrRuKz+AoNJQOtaUPczRSfspMBu0ArOWdSRmv68d36BntxfJdKh3yyJ+tYmKo/GI42okyBul3pXmrq3Si2CA4f7uaHtC5ZE1SRnl3v/wfagPRnn4D4YhECgzLyukchy5RvtFKdxLQXolHGtDg5Vg/yk6STKP1B0tZe9yZjD3DUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:x-mailer:date:to:from:subject:cc:mime-version:content-type:message-id; b=CuRfZJpRf+AWle8IG+EeQFNst6AISu6WGZDJhhmyisdpj//IlGnn2rRNwGK+ytCWictKxuaxiGULFWrcvfJKejKBE861v46S23bvS6ZAqgWWcsKMgDSDN+Wa1idEpVfCZYhUm+FOEgW+9n3S/vMPtYQ1g2eApxcmjBG3Vy3y7bo= Received: by 10.35.106.1 with SMTP id i1mr1472045pym.1174485883278; Wed, 21 Mar 2007 07:04:43 -0700 (PDT) Received: from gregory-lt.gmail.com ( [66.129.225.151]) by mx.google.com with ESMTP id a22sm3323247pye.2007.03.21.07.04.34; Wed, 21 Mar 2007 07:04:42 -0700 (PDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 21 Mar 2007 07:04:29 -0700 To: vidyan@qualcomm.com From: "Gregory M. Lebovitz" Subject: feedback on IFARE Prob Statement Cc: ietf-ipsec-failover@vpnc.org, lchen@juniper.net, shihchen@juniper.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <46013b7a.623b1b98.0d4c.5e00@mx.google.com> Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: NOTES ON PS: - may be nice to call out what happens to the apps as a result of the higher latency during failover, as an example. - nice to have one or more use cases, so vendors and network designers alike know what the reality looks like. Text-based graphics will go a long way to help. Examples of the use cases: 1 Gateway Failure - gtwy1 in NY, Gtwy2 in Dubai, client in Prague. Client connects to Gtwy1, accesses app. Mass outage in NY causes gtwy1 to go away. Client resumes app connectivity using Gtwy2. 2 Gateway Reboot - one gateway. Many clients. Clients all have IKEv2/IPsec connections to gatewway, accessing some app(s). Gateway core dumps and reboots. Clients quickly resume app connectivity using Gtwy1. 3 [OUT OF SCOPE] gtwy to gtwy, transparent to the client, full SA sync'ing. SECT 2. ========= - ADD: it isn't IKEv2's design that is so intensive, but the underlying DH exchange contained in IKE. Yet DH is an industry best practice for how to negotiate keys securely over an assumed snooped wire, so any modern key exchange method will be similarly intensive. - Using the certs to assert IKE ID doesn't really add too much, as long as the cache for the CRL and signing cert exists on box, and doesn't need to be fetched at the first packet presented. - "expensive process" is a pretty subjective comment. IKEv2's DH, for example, is MUCH faster than having to pick up the phone and share manual keys. Maybe you can give some context to the app requirements that deem this "expensive". para 3: change "per RFC4301, to lookup the relevant IPsec, encapsulates..." to "per RFC4301, to lookup the relevant IPsec SA, encapsulates..." Para 3, re: "HA" - given the overload of this acronym in this redundancy space, I suggest you spend the time to spell out Home Agent throughout this effort's docs, instead of using "HA". Change: "There are a number of proprietary solutions for this problem in the..." To: "There are a number of proprietary solutions for some part of this problem..." because we clarified today that the gtwy-to-gtwy full SA state sync is something we don't want to pursue. re: "Applications that need IPsec failover capability, such as Mobile IPv6..." can we list other applications that need the type of failover we are pursuing? At the BoF I heard: 3GPP wireless, UMA/GAN, remote access VPN in a large enterprise, carrier provisioned remote access VPN. SECT 4 ========== para 2: "In that case, clients typically use EAP over IKEv2 to establish an IPsec session" not sure how "typical" this is, as IKEv2 EAP implementations are still emerging, per the last IKEv2 bake-off in Orlando. Pls number the use cases, so we can have clearly dilineated conversations around particular cases. last para: change: "However, in the above cases, the failover cannot always be transparent to the client and hence, an interoperable protocol becomes very important." to "However, in the above cases, the failover MAY NOT always be transparent to the client and hence, an interoperable MECHANISM becomes very important." SECT 5 ============ suggest we number the goals, for easier discussion handling in the future. do we want to call "Distributed Failover Mechanism" to "Inter-site Failover Mechanism" ? Change to "Client Initiation Option" Change: "The goal is to allow the client to initiate the switch to a different gateway." TO "There may be times when the client, from its perspective, sees the gateway as unavailable and therefore needs to take some action to use a new gateway. The goal is to allow *the option for* the client to initiate the switch to a different gateway." re: "In cases where EAP is used for client authentication in IKEv2, the failover should not require EAP authentication, to avoid AAA overloading and possible user interaction." see my comment on this earlier on list. Gateway may well need the returned AAA attriutes and/or content. re; Interoperability: "Client-gateway and gateway-gateway interoperability is required. " using the "gateway-gateway" terminology seems to have been confusing people in the past. Let's find a way to clarify that we are talking about any gateway to gateway communication that might need to occur, rather than that we are tackling the gateway-gateway full SA state syncing. In "Stateless Gateway Operation" What do you mean by "remain stateless"? SECT 6 ============ add: forced failover - attacker forces a step down or other attacker-advantageous change from one gtwy to another. Hope it helps, Gregory. +++++++++++++++++++++++ IETF-related email from Gregory M. Lebovitz Juniper Networks g r e go r y d o t i e tf a t g m a i l do t c o m From owner-ietf-ipsec-failover Wed Mar 21 09:58:31 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2LGwVe9075458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 09:58:31 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2LGwVY3075457; Wed, 21 Mar 2007 09:58:31 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2LGwAZ8075407 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Wed, 21 Mar 2007 09:58:31 -0700 (MST) (envelope-from charliek@exchange.microsoft.com) Received: from df-bhd-01.exchange.corp.microsoft.com (157.54.54.216) by DF-GWY-07.exchange.corp.microsoft.com (157.54.63.164) with Microsoft SMTP Server (TLS) id 8.1.85.3; Wed, 21 Mar 2007 09:58:10 -0700 Received: from DF-GRTDANE-MSG.exchange.corp.microsoft.com ([157.54.62.8]) by df-bhd-01.exchange.corp.microsoft.com ([157.54.54.216]) with mapi; Wed, 21 Mar 2007 09:58:09 -0700 From: Charlie Kaufman To: "ietf-ipsec-failover@vpnc.org" Date: Wed, 21 Mar 2007 09:55:07 -0700 Subject: Range of Options for IPsec failover Thread-Topic: Range of Options for IPsec failover Thread-Index: Acdr2a2SkV3n71xgRYSqfWud9OXznA== Message-ID: <30C65F3A3407B943826897E025135BE67C5D652CAB@DF-GRTDANE-MSG.exchange.corp.microsoft.com> 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_30C65F3A3407B943826897E025135BE67C5D652CABDFGRTDANEMSGe_" MIME-Version: 1.0 Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --_000_30C65F3A3407B943826897E025135BE67C5D652CABDFGRTDANEMSGe_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At today's meeting, I think I heard some actual disagreements about what th= e group should do, but much more I think I heard confusion about what other= s meant in their statements of requirements. I think I understand the range= of possibilities people are talking about it, and I'm writing it up here i= n hopes of getting a common vocabulary for the discussion. Failing that, pe= rhaps someone else by correcting my summary can get us closer to that. The problem being addressed in this (potential) WG is related to MOBIKE, bu= t it is not the same. MOBIKE assumes a handoff, where an IKE SA and its ass= ociated IPsec SA state moves from one IP address to another without any sta= te being lost. This is accomplished by either having the computer implement= ing the IPsec endpoint changing its address but not the hardware on which i= t is implemented (the common case); or alternately, the IPsec state moves f= rom one machine to another in a tightly synchronized way. These two cases a= re not distinguishable to the end that didn't move. This (potential) WG would handle the case where an IPsec endpoint crashes, = becomes inaccessible, or otherwise loses IPsec state, but where we still wa= nt to "resume" communication with an alternate (or rebooted) endpoint more = quickly and seamlessly than would be possible by just rerunning IPsec from = a ground state. I see two dimensions for categorization of requirements (and potential solu= tions). Dimension 1: Whether we are trying to standardize failover between implemen= tations from different vendors (vs. declaring that case out of scope) This is best understood in the context of an example. Suppose my laptop ope= ns an IPsec tunnel to a firewall protecting my corporate intranet, and if I= want to be able to rapidly failover should my firewall crash by connecting= to another instance of the corporate firewall and running a quick IPsec in= itialization that skips (say) the manual input of the number form my SecurI= D card. I could do this by having the first instance of my firewall giving = my laptop some sort of cryptographic blob that will help me to reconnect on= failover, and modifying the IPsec implementation on my laptop to use that = blob in some special way when I reconnect. For this to work, there must be = some cooperation between the two firewalls that allow the blob produced by = one to be consumed by the other. The decision we (the BOF) must decide alon= g this dimension is whether we are "only" going to specify how the client i= s going to accept and send the blob and resume the IPsec session or whether= we are in addition going to specify the contents and syntax of the blob so= that a blob generated by one vendor's implementation will be consumable by= another's. In my opinion, this extra work seems high risk with little obvious value. I= n the common case, the different instances of my corporate firewall are goi= ng to be from the same vendor. So in my opinion, we should at least separat= e out any such specification into a separate work item, and we should desig= n our system so that servers could implement a proprietary blob format and = still interoperate with standard clients (though failover would only work b= etween compatible servers). Dimension 2: How much state are we going to preserve across IPsec resumes? = The more state we preserve, the faster the resume, but there is a downside = in terms of both performance and security in preserving more state. I can i= magine several logical points along this dimension (and I'll bet others can= think of more). Ordered from least to most state: Option 1: Avoid authentication on reconnect. This is attractive if the prob= lem you're trying to solve is avoiding the repeating of expensive and incon= venient EAP authentication or public key signing (perhaps using a smart car= d hosted key) during the resume. One could imagine that following an IPsec = authentication, the server presents the initiator with a secret key and a "= ticket". On a resumption, the client does a shared key authentication inste= ad of a public key or EAP authentication using that shared key. The ticket = contains information about the client identity encrypted under a secret key= that is private to the server (and its failover buddies). One could imagin= e a client caching the ticket and key for weeks or months - effectively as = long as you want to allow a connection to stay up without reproving the lon= g term credentials. Because shared key IPsec repeats the D-H exchange, ther= e is no loss of security with this approach, but resumption does require a = four message exchange and a D-H calculation and so lacks the performance of= some later options. Option 2: Avoid authentication and D-H on reconnect. This gives better perf= ormance than option 1 by avoiding the D-H exchange on reconnect. If not des= igned and implemented very carefully, however, Perfect Forward Secrecy is l= ost. Perfect Forward Secrecy provides that if a conversation is recorded an= d after the conversation ends an attacker gains access to all keys on both = ends of the connection, the attacker still cannot decrypt the recorded conv= ersation. The window necessarily opened by this option is that if a session= is resumed and then ends, and if the secret key used by the server to encr= ypt the ticket is remembered by server beyond the end of that session, an a= ttacker gaining access to that ticket encryption key will be able to decryp= t the resumed conversation. In the case where this mechanism is only used t= o fail over a large number of connections from one server to another, the b= ackup server could forget the ticket encryption key shortly after it reacqu= ires the failed over sessions to preserve PFS. Any sessions not resumed wit= hin the window would have to go the expensive path. This trick would not be= useful in the case where clients lose connectivity and want to resume conn= ections outside of large groups, since all tickets would have to be reissue= d every time any session resumed using a ticket terminated. Option 3: Avoid authentication, D-H, crypto negotiation, and traffic select= or negotiation on reconnect. Since upon resumption the two endpoints will p= resumably want to create the same number of IPsec SAs with the same traffic= selectors for each (in general, there can be many though in the common cas= e there is only one), some calculation and round trips can be avoided by in= cluding information about these in the ticket instead of renegotiating them= . One downside of this is that it requires the ticket to be updated wheneve= r an IPsec SA is created or deleted. Another is that it makes the ticket bi= gger, in turn making it less likely that it can be passed as part of an IKE= UDP message. Finally, unless you are going to preserve session keys and se= quence numbers (option 4 below), IKE would still have to do some per-SA wor= k to establish new SPIs. It is operationally fragile and may open security = flaws to reset the keys and/or sequence numbers on an SA without also chang= ing the SPI. Option 4: Avoid all state renegotiation. This is what MOBIKE does, which is= reasonable under the assumption that all server state (including session k= eys, traffic selectors, SPIs, and current sequence numbers) can be migrated= . It cannot deal with server crashes unless you assume that state is backed= up after every message (to record the new sequence numbers). In my opinion, supporting Option 1 seems both straightforward and operation= ally useful. Even if we also standardize Option 2, I would recommend also s= tandardizing Option 1. In my opinion, Option 2 is on the edge. As an engineer, I would find it int= eresting to design (trying to avoid the various security pitfalls while get= ting the performance benefit). But I have to sympathize with Eric's warning= not to bet against Moore's law and wonder whether we should be designing t= his fragile thing to solve a fringe case when we could instead throw hardwa= re at it. I think it is incumbent on those who think a D-H per client resu= mption is too expensive to describe in detail their motivating scenario. I = would also remind everyone that IPsec was designed to be "fairly secure" ev= en if clients and servers avoid repeated D-H calculations by reusing their = D-H keys and caching the results. It might be better to meet the performanc= e bar by abusing the current protocol rather than creating a new one. In my opinion, Option 3 seems farfetched. The potential performance gain is= one round trip (and it's not obvious that even that can be saved) and some= secret key operations for key derivation, while the cost in complexity and= in ticket size seems daunting. I could be convinced that there are scenari= os to justify it, but I can't imagine any. Option 4 seems plausible only in the case where the servers maintain shared= state, and in that case the MOBIKE protocol seems adequate. It's not obvio= us (to me anyway) why you would want to have the client participate in the = migration if the servers already have to be tightly coordinated. Tell me what I'm missing... --Charlie --_000_30C65F3A3407B943826897E025135BE67C5D652CABDFGRTDANEMSGe_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At today’s meeting, I think I heard some actual disagreements about what the group should do, but much more I think I heard confusion about what others meant in their statements of requirements. I th= ink I understand the range of possibilities people are talking about it, and I’m writing it up here in hopes of getting a common vocabulary for th= e discussion. Failing that, perhaps someone else by correcting my summary can= get us closer to that.

 

The problem being addressed in this (potential) WG is = related to MOBIKE, but it is not the same. MOBIKE assumes a handoff, where an IKE S= A and its associated IPsec SA state moves from one IP address to another with= out any state being lost. This is accomplished by either having the computer implementing the IPsec endpoint changing its address but not the hardware o= n which it is implemented (the common case); or alternately, the IPsec state moves from one machine to another in a tightly synchronized way. These two cases are not distinguishable to the end that didn’t move.=

 

This (potential) WG would handle the case where an IPs= ec endpoint crashes, becomes inaccessible, or otherwise loses IPsec state, but where we still want to “resume” communication with an alternate= (or rebooted) endpoint more quickly and seamlessly than would be possible by ju= st rerunning IPsec from a ground state.

 

I see two dimensions for categorization of requirement= s (and potential solutions).

 

Dimension 1: Whether we are trying to standardize fail= over between implementations from different vendors (vs. declaring that case out= of scope)

 

This is best understood in the context of an example. Suppose my laptop opens an IPsec tunnel to a firewall protecting my corpora= te intranet, and if I want to be able to rapidly failover should my firewall c= rash by connecting to another instance of the corporate firewall and running a q= uick IPsec initialization that skips (say) the manual input of the number form m= y SecurID card. I could do this by having the first instance of my firewall giving my laptop some sort of cryptographic blob that will help me to recon= nect on failover, and modifying the IPsec implementation on my laptop to use tha= t blob in some special way when I reconnect. For this to work, there must be = some cooperation between the two firewalls that allow the blob produced by one t= o be consumed by the other. The decision we (the BOF) must decide along this dimension is whether we are “only” going to specify how the cli= ent is going to accept and send the blob and resume the IPsec session or whethe= r we are in addition going to specify the contents and syntax of the blob so tha= t a blob generated by one vendor’s implementation will be consumable by another’s.

 

In my opinion, this extra work seems high risk with li= ttle obvious value. In the common case, the different instances of my corporate firewall are going to be from the same vendor. So in my opinion, we should = at least separate out any such specification into a separate work item, and we should design our system so that servers could implement a proprietary blob format and still interoperate with standard clients (though failover would = only work between compatible servers).

 

Dimension 2: How much state are we going to preserve a= cross IPsec resumes? The more state we preserve, the faster the resume, but there= is a downside in terms of both performance and security in preserving more sta= te. I can imagine several logical points along this dimension (and I’ll bet others can think of more). Ordered from least to most state:

 

Option 1: Avoid authentication on reconnect. This is attractive if the problem you’re trying to solve is avoiding the repeating of expensive and inconvenient EAP authentication or public key signing (perhaps using a smart card hosted key) during the resume. One coul= d imagine that following an IPsec authentication, the server presents the ini= tiator with a secret key and a “ticket”. On a resumption, the client d= oes a shared key authentication instead of a public key or EAP authentication u= sing that shared key. The ticket contains information about the client identity encrypted under a secret key that is private to the server (and its failove= r buddies). One could imagine a client caching the ticket and key for weeks o= r months – effectively as long as you want to allow a connection to sta= y up without reproving the long term credentials. Because shared key IPsec repea= ts the D-H exchange, there is no loss of security with this approach, but resu= mption does require a four message exchange and a D-H calculation and so lacks the performance of some later options.

 

Option 2: Avoid authentication and D-H on reconnect. T= his gives better performance than option 1 by avoiding the D-H exchange on reco= nnect. If not designed and implemented very carefully, however, Perfect Forward Secrecy is lost. Perfect Forward Secrecy provides that if a conversation is recorded and after the conversation ends an attacker gains access to all ke= ys on both ends of the connection, the attacker still cannot decrypt the recor= ded conversation. The window necessarily opened by this option is that if a ses= sion is resumed and then ends, and if the secret key used by the server to encry= pt the ticket is remembered by server beyond the end of that session, an attac= ker gaining access to that ticket encryption key will be able to decrypt the resumed conversation. In the case where this mechanism is only used to fail over a large number of connections from one server to another, the backup server could forget the ticket encryption key shortly after it reacquires t= he failed over sessions to preserve PFS. Any sessions not resumed within the window would have to go the expensive path. This trick would not be useful = in the case where clients lose connectivity and want to resume connections out= side of large groups, since all tickets would have to be reissued every time any session resumed using a ticket terminated.

 

Option 3: Avoid authentication, D-H, crypto negotiatio= n, and traffic selector negotiation on reconnect. Since upon resumption the two endpoints will presumably want to create the same number of IPsec SAs with = the same traffic selectors for each (in general, there can be many though in th= e common case there is only one), some calculation and round trips can be avo= ided by including information about these in the ticket instead of renegotiating them. One downside of this is that it requires the ticket to be updated whenever an IPsec SA is created or deleted. Another is that it makes the ti= cket bigger, in turn making it less likely that it can be passed as part of an I= KE UDP message. Finally, unless you are going to preserve session keys and sequence numbers (option 4 below), IKE would still have to do some per-SA w= ork to establish new SPIs. It is operationally fragile and may open security fl= aws to reset the keys and/or sequence numbers on an SA without also changing th= e SPI.

 

Option 4: Avoid all state renegotiation. This is what = MOBIKE does, which is reasonable under the assumption that all server state (inclu= ding session keys, traffic selectors, SPIs, and current sequence numbers) can be migrated. It cannot deal with server crashes unless you assume that state i= s backed up after every message (to record the new sequence numbers).

 

In my opinion, supporting Option 1 seems both straightforward and operationally useful. Even if we also standardize Optio= n 2, I would recommend also standardizing Option 1.

 

In my opinion, Option 2 is on the edge. As an engineer= , I would find it interesting to design (trying to avoid the various security pitfalls while getting the performance benefit). But I have to sympathize w= ith Eric’s warning not to bet against Moore’s law and wonder whethe= r we should be designing this fragile thing to solve a fringe case when we could instead throw hardware at it.  I think it is incumbent on those who th= ink a D-H per client resumption is too expensive to describe in detail their motivating scenario. I would also remind everyone that IPsec was designed t= o be “fairly secure” even if clients and servers avoid repeated D-H calculations by reusing their D-H keys and caching the results. It might be better to meet the performance bar by abusing the current protocol rather t= han creating a new one.

 

In my opinion, Option 3 seems farfetched. The potentia= l performance gain is one round trip (and it’s not obvious that even th= at can be saved) and some secret key operations for key derivation, while the = cost in complexity and in ticket size seems daunting. I could be convinced that there are scenarios to justify it, but I can’t imagine any.

 

Option 4 seems plausible only in the case where the se= rvers maintain shared state, and in that case the MOBIKE protocol seems adequate.= It’s not obvious (to me anyway) why you would want to have the client participat= e in the migration if the servers already have to be tightly coordinated.

 

Tell me what I’m missing…

 

         =        --Charlie

--_000_30C65F3A3407B943826897E025135BE67C5D652CABDFGRTDANEMSGe_-- From owner-ietf-ipsec-failover Wed Mar 21 10:34:13 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2LHYDt6077801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 10:34:13 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2LHYDYO077800; Wed, 21 Mar 2007 10:34:13 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from michael.checkpoint.com ([194.29.32.68]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2LHXpAf077786 for ; Wed, 21 Mar 2007 10:34:11 -0700 (MST) (envelope-from yaronf@checkpoint.com) Received: from [172.31.24.55] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id l2LHXfAo009099; Wed, 21 Mar 2007 19:33:42 +0200 (IST) Message-ID: <46016C75.306@checkpoint.com> Date: Wed, 21 Mar 2007 18:33:41 +0100 From: Yaron Sheffer User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Charlie Kaufman CC: "ietf-ipsec-failover@vpnc.org" Subject: Re: Range of Options for IPsec failover References: <30C65F3A3407B943826897E025135BE67C5D652CAB@DF-GRTDANE-MSG.exchange.corp.microsoft.com> In-Reply-To: <30C65F3A3407B943826897E025135BE67C5D652CAB@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------030705020105080406030403" Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------030705020105080406030403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Charlie, At the risk of repeating things I said at the BOF, I would like to argue in favor of option #2. First, the computational cost is not just D-H, typically it's D-H plus a signature for authenticating the gateway. The main point is cost-performance of the gateway. We can add more and more blades and accelerators to accommodate any number of clients. But we are trying to maintain reasonable cost. And we have found out that in some networks with real-time traffic, we would need 5-10X processing power on the gateway to deal with massive reconnects (to ensure all clients are reconnected before they start to time-out) than to deal with steady state IKE+IPsec traffic, or even with "Monday morning" traffic peaks. Our customers are already paying 2X for redundancy, usually with a local redundant gateway. They do insist on a solution for massive reconnects. Unfortunately they are not willing to pay 5X to get such a solution. Regarding your point about "abusing D-H", I believe this would only eliminate half of the computational cost, since you don't know what the client will be sending you. Lastly, when thinking about the "solution space" we've been assuming a ticket lifetime all along, which should allow us to regularly revoke ticket encryption keys. I accept we should engineer a solution so that the PFS property is retained. Thanks, Yaron Charlie Kaufman wrote: > At today's meeting, I think I heard some actual disagreements about > what the group should do, but much more I think I heard confusion > about what others meant in their statements of requirements. I think I > understand the range of possibilities people are talking about it, and > I'm writing it up here in hopes of getting a common vocabulary for the > discussion. Failing that, perhaps someone else by correcting my > summary can get us closer to that. > > > > The problem being addressed in this (potential) WG is related to > MOBIKE, but it is not the same. MOBIKE assumes a handoff, where an IKE > SA and its associated IPsec SA state moves from one IP address to > another without any state being lost. This is accomplished by either > having the computer implementing the IPsec endpoint changing its > address but not the hardware on which it is implemented (the common > case); or alternately, the IPsec state moves from one machine to > another in a tightly synchronized way. These two cases are not > distinguishable to the end that didn't move. > > > > This (potential) WG would handle the case where an IPsec endpoint > crashes, becomes inaccessible, or otherwise loses IPsec state, but > where we still want to "resume" communication with an alternate (or > rebooted) endpoint more quickly and seamlessly than would be possible > by just rerunning IPsec from a ground state. > > > > I see two dimensions for categorization of requirements (and potential > solutions). > > > > Dimension 1: Whether we are trying to standardize failover between > implementations from different vendors (vs. declaring that case out of > scope) > > > > This is best understood in the context of an example. Suppose my > laptop opens an IPsec tunnel to a firewall protecting my corporate > intranet, and if I want to be able to rapidly failover should my > firewall crash by connecting to another instance of the corporate > firewall and running a quick IPsec initialization that skips (say) the > manual input of the number form my SecurID card. I could do this by > having the first instance of my firewall giving my laptop some sort of > cryptographic blob that will help me to reconnect on failover, and > modifying the IPsec implementation on my laptop to use that blob in > some special way when I reconnect. For this to work, there must be > some cooperation between the two firewalls that allow the blob > produced by one to be consumed by the other. The decision we (the BOF) > must decide along this dimension is whether we are "only" going to > specify how the client is going to accept and send the blob and resume > the IPsec session or whether we are in addition going to specify the > contents and syntax of the blob so that a blob generated by one > vendor's implementation will be consumable by another's. > > > > In my opinion, this extra work seems high risk with little obvious > value. In the common case, the different instances of my corporate > firewall are going to be from the same vendor. So in my opinion, we > should at least separate out any such specification into a separate > work item, and we should design our system so that servers could > implement a proprietary blob format and still interoperate with > standard clients (though failover would only work between compatible > servers). > > > > Dimension 2: How much state are we going to preserve across IPsec > resumes? The more state we preserve, the faster the resume, but there > is a downside in terms of both performance and security in preserving > more state. I can imagine several logical points along this dimension > (and I'll bet others can think of more). Ordered from least to most state: > > > > Option 1: Avoid authentication on reconnect. This is attractive if the > problem you're trying to solve is avoiding the repeating of expensive > and inconvenient EAP authentication or public key signing (perhaps > using a smart card hosted key) during the resume. One could imagine > that following an IPsec authentication, the server presents the > initiator with a secret key and a "ticket". On a resumption, the > client does a shared key authentication instead of a public key or EAP > authentication using that shared key. The ticket contains information > about the client identity encrypted under a secret key that is private > to the server (and its failover buddies). One could imagine a client > caching the ticket and key for weeks or months -- effectively as long > as you want to allow a connection to stay up without reproving the > long term credentials. Because shared key IPsec repeats the D-H > exchange, there is no loss of security with this approach, but > resumption does require a four message exchange and a D-H calculation > and so lacks the performance of some later options. > > > > Option 2: Avoid authentication and D-H on reconnect. This gives better > performance than option 1 by avoiding the D-H exchange on reconnect. > If not designed and implemented very carefully, however, Perfect > Forward Secrecy is lost. Perfect Forward Secrecy provides that if a > conversation is recorded and after the conversation ends an attacker > gains access to all keys on both ends of the connection, the attacker > still cannot decrypt the recorded conversation. The window necessarily > opened by this option is that if a session is resumed and then ends, > and if the secret key used by the server to encrypt the ticket is > remembered by server beyond the end of that session, an attacker > gaining access to that ticket encryption key will be able to decrypt > the resumed conversation. In the case where this mechanism is only > used to fail over a large number of connections from one server to > another, the backup server could forget the ticket encryption key > shortly after it reacquires the failed over sessions to preserve PFS. > Any sessions not resumed within the window would have to go the > expensive path. This trick would not be useful in the case where > clients lose connectivity and want to resume connections outside of > large groups, since all tickets would have to be reissued every time > any session resumed using a ticket terminated. > > > > Option 3: Avoid authentication, D-H, crypto negotiation, and traffic > selector negotiation on reconnect. Since upon resumption the two > endpoints will presumably want to create the same number of IPsec SAs > with the same traffic selectors for each (in general, there can be > many though in the common case there is only one), some calculation > and round trips can be avoided by including information about these in > the ticket instead of renegotiating them. One downside of this is that > it requires the ticket to be updated whenever an IPsec SA is created > or deleted. Another is that it makes the ticket bigger, in turn making > it less likely that it can be passed as part of an IKE UDP message. > Finally, unless you are going to preserve session keys and sequence > numbers (option 4 below), IKE would still have to do some per-SA work > to establish new SPIs. It is operationally fragile and may open > security flaws to reset the keys and/or sequence numbers on an SA > without also changing the SPI. > > > > Option 4: Avoid all state renegotiation. This is what MOBIKE does, > which is reasonable under the assumption that all server state > (including session keys, traffic selectors, SPIs, and current sequence > numbers) can be migrated. It cannot deal with server crashes unless > you assume that state is backed up after every message (to record the > new sequence numbers). > > > > In my opinion, supporting Option 1 seems both straightforward and > operationally useful. Even if we also standardize Option 2, I would > recommend also standardizing Option 1. > > > > In my opinion, Option 2 is on the edge. As an engineer, I would find > it interesting to design (trying to avoid the various security > pitfalls while getting the performance benefit). But I have to > sympathize with Eric's warning not to bet against Moore's law and > wonder whether we should be designing this fragile thing to solve a > fringe case when we could instead throw hardware at it. I think it is > incumbent on those who think a D-H per client resumption is too > expensive to describe in detail their motivating scenario. I would > also remind everyone that IPsec was designed to be "fairly secure" > even if clients and servers avoid repeated D-H calculations by reusing > their D-H keys and caching the results. It might be better to meet the > performance bar by abusing the current protocol rather than creating a > new one. > > > > In my opinion, Option 3 seems farfetched. The potential performance > gain is one round trip (and it's not obvious that even that can be > saved) and some secret key operations for key derivation, while the > cost in complexity and in ticket size seems daunting. I could be > convinced that there are scenarios to justify it, but I can't imagine any. > > > > Option 4 seems plausible only in the case where the servers maintain > shared state, and in that case the MOBIKE protocol seems adequate. > It's not obvious (to me anyway) why you would want to have the client > participate in the migration if the servers already have to be tightly > coordinated. > > > > Tell me what I'm missing... > > > > --Charlie > --------------030705020105080406030403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hi Charlie,


At the risk of repeating things I said at the BOF, I would like to argue in favor of option #2.


First, the computational cost is not just D-H, typically it's D-H plus a signature for authenticating the gateway.


The main point is cost-performance of the gateway. We can add more and more blades and accelerators to accommodate any number of clients. But we are trying to maintain reasonable cost. And we have found out that in some networks with real-time traffic, we would need 5-10X processing power on the gateway to deal with massive reconnects (to ensure all clients are reconnected before they start to time-out) than to deal with steady state IKE+IPsec traffic, or even with "Monday morning" traffic peaks.


Our customers are already paying 2X for redundancy, usually with a local redundant gateway. They do insist on a solution for massive reconnects. Unfortunately they are not willing to pay 5X to get such a solution.


Regarding your point about "abusing D-H", I believe this would only eliminate half of the computational cost, since you don't know what the client will be sending you.


Lastly, when thinking about the "solution space" we've been assuming a ticket lifetime all along, which should allow us to regularly revoke ticket encryption keys. I accept we should engineer a solution so that the PFS property is retained.


Thanks,

    Yaron

 

Charlie Kaufman wrote:

At today’s meeting, I think I heard some actual disagreements about what the group should do, but much more I think I heard confusion about what others meant in their statements of requirements. I think I understand the range of possibilities people are talking about it, and I’m writing it up here in hopes of getting a common vocabulary for the discussion. Failing that, perhaps someone else by correcting my summary can get us closer to that.

 

The problem being addressed in this (potential) WG is related to MOBIKE, but it is not the same. MOBIKE assumes a handoff, where an IKE SA and its associated IPsec SA state moves from one IP address to another without any state being lost. This is accomplished by either having the computer implementing the IPsec endpoint changing its address but not the hardware on which it is implemented (the common case); or alternately, the IPsec state moves from one machine to another in a tightly synchronized way. These two cases are not distinguishable to the end that didn’t move.

 

This (potential) WG would handle the case where an IPsec endpoint crashes, becomes inaccessible, or otherwise loses IPsec state, but where we still want to “resume” communication with an alternate (or rebooted) endpoint more quickly and seamlessly than would be possible by just rerunning IPsec from a ground state.

 

I see two dimensions for categorization of requirements (and potential solutions).

 

Dimension 1: Whether we are trying to standardize failover between implementations from different vendors (vs. declaring that case out of scope)

 

This is best understood in the context of an example. Suppose my laptop opens an IPsec tunnel to a firewall protecting my corporate intranet, and if I want to be able to rapidly failover should my firewall crash by connecting to another instance of the corporate firewall and running a quick IPsec initialization that skips (say) the manual input of the number form my SecurID card. I could do this by having the first instance of my firewall giving my laptop some sort of cryptographic blob that will help me to reconnect on failover, and modifying the IPsec implementation on my laptop to use that blob in some special way when I reconnect. For this to work, there must be some cooperation between the two firewalls that allow the blob produced by one to be consumed by the other. The decision we (the BOF) must decide along this dimension is whether we are “only” going to specify how the client is going to accept and send the blob and resume the IPsec session or whether we are in addition going to specify the contents and syntax of the blob so that a blob generated by one vendor’s implementation will be consumable by another’s.

 

In my opinion, this extra work seems high risk with little obvious value. In the common case, the different instances of my corporate firewall are going to be from the same vendor. So in my opinion, we should at least separate out any such specification into a separate work item, and we should design our system so that servers could implement a proprietary blob format and still interoperate with standard clients (though failover would only work between compatible servers).

 

Dimension 2: How much state are we going to preserve across IPsec resumes? The more state we preserve, the faster the resume, but there is a downside in terms of both performance and security in preserving more state. I can imagine several logical points along this dimension (and I’ll bet others can think of more). Ordered from least to most state:

 

Option 1: Avoid authentication on reconnect. This is attractive if the problem you’re trying to solve is avoiding the repeating of expensive and inconvenient EAP authentication or public key signing (perhaps using a smart card hosted key) during the resume. One could imagine that following an IPsec authentication, the server presents the initiator with a secret key and a “ticket”. On a resumption, the client does a shared key authentication instead of a public key or EAP authentication using that shared key. The ticket contains information about the client identity encrypted under a secret key that is private to the server (and its failover buddies). One could imagine a client caching the ticket and key for weeks or months – effectively as long as you want to allow a connection to stay up without reproving the long term credentials. Because shared key IPsec repeats the D-H exchange, there is no loss of security with this approach, but resumption does require a four message exchange and a D-H calculation and so lacks the performance of some later options.

 

Option 2: Avoid authentication and D-H on reconnect. This gives better performance than option 1 by avoiding the D-H exchange on reconnect. If not designed and implemented very carefully, however, Perfect Forward Secrecy is lost. Perfect Forward Secrecy provides that if a conversation is recorded and after the conversation ends an attacker gains access to all keys on both ends of the connection, the attacker still cannot decrypt the recorded conversation. The window necessarily opened by this option is that if a session is resumed and then ends, and if the secret key used by the server to encrypt the ticket is remembered by server beyond the end of that session, an attacker gaining access to that ticket encryption key will be able to decrypt the resumed conversation. In the case where this mechanism is only used to fail over a large number of connections from one server to another, the backup server could forget the ticket encryption key shortly after it reacquires the failed over sessions to preserve PFS. Any sessions not resumed within the window would have to go the expensive path. This trick would not be useful in the case where clients lose connectivity and want to resume connections outside of large groups, since all tickets would have to be reissued every time any session resumed using a ticket terminated.

 

Option 3: Avoid authentication, D-H, crypto negotiation, and traffic selector negotiation on reconnect. Since upon resumption the two endpoints will presumably want to create the same number of IPsec SAs with the same traffic selectors for each (in general, there can be many though in the common case there is only one), some calculation and round trips can be avoided by including information about these in the ticket instead of renegotiating them. One downside of this is that it requires the ticket to be updated whenever an IPsec SA is created or deleted. Another is that it makes the ticket bigger, in turn making it less likely that it can be passed as part of an IKE UDP message. Finally, unless you are going to preserve session keys and sequence numbers (option 4 below), IKE would still have to do some per-SA work to establish new SPIs. It is operationally fragile and may open security flaws to reset the keys and/or sequence numbers on an SA without also changing the SPI.

 

Option 4: Avoid all state renegotiation. This is what MOBIKE does, which is reasonable under the assumption that all server state (including session keys, traffic selectors, SPIs, and current sequence numbers) can be migrated. It cannot deal with server crashes unless you assume that state is backed up after every message (to record the new sequence numbers).

 

In my opinion, supporting Option 1 seems both straightforward and operationally useful. Even if we also standardize Option 2, I would recommend also standardizing Option 1.

 

In my opinion, Option 2 is on the edge. As an engineer, I would find it interesting to design (trying to avoid the various security pitfalls while getting the performance benefit). But I have to sympathize with Eric’s warning not to bet against Moore’s law and wonder whether we should be designing this fragile thing to solve a fringe case when we could instead throw hardware at it.  I think it is incumbent on those who think a D-H per client resumption is too expensive to describe in detail their motivating scenario. I would also remind everyone that IPsec was designed to be “fairly secure” even if clients and servers avoid repeated D-H calculations by reusing their D-H keys and caching the results. It might be better to meet the performance bar by abusing the current protocol rather than creating a new one.

 

In my opinion, Option 3 seems farfetched. The potential performance gain is one round trip (and it’s not obvious that even that can be saved) and some secret key operations for key derivation, while the cost in complexity and in ticket size seems daunting. I could be convinced that there are scenarios to justify it, but I can’t imagine any.

 

Option 4 seems plausible only in the case where the servers maintain shared state, and in that case the MOBIKE protocol seems adequate. It’s not obvious (to me anyway) why you would want to have the client participate in the migration if the servers already have to be tightly coordinated.

 

Tell me what I’m missing…

 

                --Charlie

--------------030705020105080406030403-- From owner-ietf-ipsec-failover Thu Mar 22 06:15:47 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2MDFlod057512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2007 06:15:47 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2MDFlsB057511; Thu, 22 Mar 2007 06:15:47 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from mgw-ext12.nokia.com (smtp.nokia.com [131.228.20.171]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2MDFOtn057432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 22 Mar 2007 06:15:46 -0700 (MST) (envelope-from Pasi.Eronen@nokia.com) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2MDFJE7016667 for ; Thu, 22 Mar 2007 15:15:22 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 15:14:19 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 15:14:19 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Range of Options for IPsec failover Date: Thu, 22 Mar 2007 15:14:26 +0200 Message-ID: In-Reply-To: <30C65F3A3407B943826897E025135BE67C5D652CAB@DF-GRTDANE-MSG.exchange.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Range of Options for IPsec failover Thread-Index: Acdr2a2SkV3n71xgRYSqfWud9OXznAAqgYhg References: <30C65F3A3407B943826897E025135BE67C5D652CAB@DF-GRTDANE-MSG.exchange.corp.microsoft.com> From: To: X-OriginalArrivalTime: 22 Mar 2007 13:14:19.0694 (UTC) FILETIME=[00202CE0:01C76C84] X-eXpurgate-Category: 1/4 X-eXpurgate-ID: 149371::070322151522-3FAF4BB0-565D395A/0-0/0-17 X-Nokia-AV: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l2MDFltm057506 Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I must admit that I was a bit confused at IFARE. I've now spent some time thinking about the problem area, trying to slash it to more manageable pieces. Here's my totally subjective take, slightly different from Charlie's (which IMHO was more focused on the properties of the possible solutions). I got the impression that there are basically three different use cases people care about: inter-site failover, home agent switch, and suspend/resume. I'll go over these one by one. First, inter-site failover. Vendors today do client-transparent failover with clusters of VPN gateways. However, if you want to failover from one cluster (located in, say, London) to another cluster (in New York), the IP address seen by the client probably changes, and this part would need standardization. I think *the* important question here is how often we expect this case to happen. A site is not just a cluster of gateways, but also redundant power supplies, redundant Ethernet switches, redundant connections to Internet (*), and so on. If a total site failure happens once a year, optimizing the time-to-complete-IKE from 5 seconds to 0.5 seconds doesn't seem very important to me. And as many folks pointed out, it takes some time to discover that things have failed. (*) Redundant connections to Internet might mean redundant links where failures are handled by routing, or it might mean having multiple IP addresses. MOBIKE handles at least part of the gateway-with-multiple-IP-addresses problem. If we do a solution for inter-site failover, it could of course be used intra-site as well, reducing the need to have a tightly synchronized cluster of gateways. But then again, if vendors already have a working solution (client transparent failover), what exactly needs solving? Second, home agent switch: draft-ietf-mip6-ha-switch lists some reasons for moving a client from one home agent to another, the main ones being load balancing and planned maintenance of various kind. Another possible reason (which could be considered part of load balancing) seems to be traffic pattern optimization. Reputedly, some network operators would like to deploy a large number of home agents near the network edges; if the client moves "far away" from the current home agent it might want to switch to a home agent "near by". The reasons for switching home agents certainly sound plausible to me. However, most of the time it's a *planned* switch (rather than failover), and you can do IKE with the new box while still talking to the old one. So the absolute time-to-finish-IKE may not need that much optimization. Perhaps this puts some load on the AAA infrastructure that we'd like to reduce. The third case is suspend/resume. This is where you switch off your phone, fly to Prague, switch it on again, and would like to get back your VPN (a) without user interaction, such typing in your one-time password, and (b) reasonably fast. Here I'm not yet convinced that the time-to-complete-IKE is a big problem. User interaction certainly is; in MOBIKE we solved this for the mobility case, but decided not to do suspend/resume back then (although it was proposed). To summarize: I think there are (at least) three quite different use cases... but most of the meeting time was spent discussing the one I find least important (the first one). However, some of the proposed solutions might be applicable for all three. The different use cases might have quite different needs for optimization (compared to just doing a full IKE handshake). I think at least the following have been mentioned as reasons for needing optimization: - User interaction: Quite important... but applies only if the IKE authentication actually needs user interaction. - AAA infrastructure load: At least if IKE uses EAP authentication. - Client CPU time: Public key operations (including DH) are not exactly fast, but nowdays, not exactly slow either (even on things like mobile phones). - Gateway CPU time: Gateways that can handle a large number of clients also have HW for public-key ops, but some folks said a really huge number of clients arriving exactly at the same time might still be a problem. This seems relevant mainly in the first use case (inter-site failover), and even then it assumes that all clients detect failure at the same time (rather than, say, distributed over a 60 second interval). - Time to complete IKE: This obviously depends on client/gateway CPU time and the number of roundtrips (related to AAA infrastructure load). - Gateway-to-gateway communication load: (in current client transparent solutions) I'm not sure if anyone really said this load is a *problem*, but it was said that a client-visible solution could reduce the need for communication. Charlie's mail contained a list of options for how much state to preserve; his option #1 would IMHO handle the most important cases (avoid user interaction, and possibly AAA infrastructure load). (However, I'm not really sure I'm less confused after writing this mail than I was before it. I thus reserve the right to change my opinions :-) Best regards, Pasi From owner-ietf-ipsec-failover Thu Mar 22 08:07:57 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2MF7vH3068575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2007 08:07:57 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2MF7vMn068573; Thu, 22 Mar 2007 08:07:57 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from mgw-ext11.nokia.com (smtp.nokia.com [131.228.20.170]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2MF7WWG068544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 22 Mar 2007 08:07:54 -0700 (MST) (envelope-from Pasi.Eronen@nokia.com) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2MF75WI015377 for ; Thu, 22 Mar 2007 17:07:30 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 17:06:07 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 17:06:07 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Range of Options for IPsec failover Date: Thu, 22 Mar 2007 17:06:03 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Range of Options for IPsec failover Thread-Index: Acdr2a2SkV3n71xgRYSqfWud9OXznAAqgYhgAANkK3A= References: <30C65F3A3407B943826897E025135BE67C5D652CAB@DF-GRTDANE-MSG.exchange.corp.microsoft.com> From: To: X-OriginalArrivalTime: 22 Mar 2007 15:06:07.0288 (UTC) FILETIME=[9E29CB80:01C76C93] X-Nokia-AV: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l2MF7tWF068567 Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Amending my earlier message after talking with Yaron: there actually may be sub-cases of suspend/resume that need different treatment. The first sub-case is the "switch off your phone, fly to Prague" one. The second sub-case is a long break in network connectivity near the client (causing the IKE_SA to fail due to DPD). I think this is reasonably similar to the "power off" sub-case: we want to get the VPN back without user interaction, but sub-second optimization in time-to-complete-IKE probably isn't critical. The third sub-case is a long break in network connectivity near the gateway (affecting all clients, rather than just a couple). This is slightly different, since once the network comes back up, you can have a large number of clients reconnecting at exactly the same time. So while in the previous message I said that gateway CPU time seems relevant only for inter-site failover (which I'm not really convinced about yet), it could be relevant for some sub-cases of suspend/resume as well. (And in the possible solution space, we do have some alternatives that handle all three sub-cases of suspend/resume just fine, but would not really work well for inter-site failover.) Best regards, Pasi > -----Original Message----- > From: pasi.eronen@nokia.com > Sent: 22 March, 2007 15:14 > To: ietf-ipsec-failover@vpnc.org > Subject: RE: Range of Options for IPsec failover > > > > I must admit that I was a bit confused at IFARE. I've now spent some > time thinking about the problem area, trying to slash it to more > manageable pieces. Here's my totally subjective take, slightly > different from Charlie's (which IMHO was more focused on the > properties of the possible solutions). > > I got the impression that there are basically three different use > cases people care about: inter-site failover, home agent switch, > and suspend/resume. I'll go over these one by one. > > > First, inter-site failover. Vendors today do client-transparent > failover with clusters of VPN gateways. However, if you want to > failover from one cluster (located in, say, London) to another > cluster (in New York), the IP address seen by the client probably > changes, and this part would need standardization. > > I think *the* important question here is how often we expect this > case to happen. A site is not just a cluster of gateways, but also > redundant power supplies, redundant Ethernet switches, redundant > connections to Internet (*), and so on. If a total site failure > happens once a year, optimizing the time-to-complete-IKE from 5 > seconds to 0.5 seconds doesn't seem very important to me. And as > many folks pointed out, it takes some time to discover that things > have failed. > > (*) Redundant connections to Internet might mean redundant links > where failures are handled by routing, or it might mean having > multiple IP addresses. MOBIKE handles at least part of the > gateway-with-multiple-IP-addresses problem. > > If we do a solution for inter-site failover, it could of course be > used intra-site as well, reducing the need to have a tightly > synchronized cluster of gateways. But then again, if vendors already > have a working solution (client transparent failover), what exactly > needs solving? > > > Second, home agent switch: draft-ietf-mip6-ha-switch lists some > reasons for moving a client from one home agent to another, the main > ones being load balancing and planned maintenance of various kind. > Another possible reason (which could be considered part of load > balancing) seems to be traffic pattern optimization. Reputedly, > some network operators would like to deploy a large number of home > agents near the network edges; if the client moves "far away" from > the current home agent it might want to switch to a home agent > "near by". > > The reasons for switching home agents certainly sound plausible to > me. However, most of the time it's a *planned* switch (rather than > failover), and you can do IKE with the new box while still talking > to the old one. So the absolute time-to-finish-IKE may not need that > much optimization. Perhaps this puts some load on the AAA > infrastructure that we'd like to reduce. > > > The third case is suspend/resume. This is where you switch off your > phone, fly to Prague, switch it on again, and would like to get back > your VPN (a) without user interaction, such typing in your one-time > password, and (b) reasonably fast. Here I'm not yet convinced that > the time-to-complete-IKE is a big problem. User interaction > certainly is; in MOBIKE we solved this for the mobility case, but > decided not to do suspend/resume back then (although it was > proposed). > > > To summarize: I think there are (at least) three quite different use > cases... but most of the meeting time was spent discussing the one I > find least important (the first one). However, some of the proposed > solutions might be applicable for all three. > > The different use cases might have quite different needs for > optimization (compared to just doing a full IKE handshake). > I think at least the following have been mentioned as reasons > for needing optimization: > > - User interaction: Quite important... but applies only if the > IKE authentication actually needs user interaction. > > - AAA infrastructure load: At least if IKE uses EAP authentication. > > - Client CPU time: Public key operations (including DH) are not > exactly fast, but nowdays, not exactly slow either (even on > things like mobile phones). > > - Gateway CPU time: Gateways that can handle a large number of > clients also have HW for public-key ops, but some folks said > a really huge number of clients arriving exactly at the same > time might still be a problem. This seems relevant mainly in > the first use case (inter-site failover), and even then it > assumes that all clients detect failure at the same time > (rather than, say, distributed over a 60 second interval). > > - Time to complete IKE: This obviously depends on client/gateway > CPU time and the number of roundtrips (related to AAA > infrastructure load). > > - Gateway-to-gateway communication load: (in current client > transparent solutions) I'm not sure if anyone really said > this load is a *problem*, but it was said that a client-visible > solution could reduce the need for communication. > > Charlie's mail contained a list of options for how much state to > preserve; his option #1 would IMHO handle the most important cases > (avoid user interaction, and possibly AAA infrastructure load). > > (However, I'm not really sure I'm less confused after writing this > mail than I was before it. I thus reserve the right to change my > opinions :-) > > Best regards, > Pasi > > From owner-ietf-ipsec-failover Fri Mar 23 23:59:12 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2O6xCWY025753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Mar 2007 23:59:12 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l2O6xC6l025752; Fri, 23 Mar 2007 23:59:12 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l2O6wmAG025737 for ; Fri, 23 Mar 2007 23:59:11 -0700 (MST) (envelope-from kchowdhury@starentnetworks.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 676D2900B5; Sat, 24 Mar 2007 01:58:47 -0500 (EST) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19571-16; Sat, 24 Mar 2007 01:58:43 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP; Sat, 24 Mar 2007 01:58:43 -0500 (EST) X-MessageTextProcessor: DisclaimIt (2.70.271) [Starent Networks Corp.] Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Mar 2007 02:58:43 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76DE1.DBD7F9FC" Subject: RE: Range of Options for IPsec failover Date: Sat, 24 Mar 2007 02:58:42 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024D9D69@exchtewks2.starentnetworks.com> Content-Transfer-Encoding: 7bit In-Reply-To: <30C65F3A3407B943826897E025135BE67C5D652CAB@DF-GRTDANE-MSG.exchange.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Range of Options for IPsec failover thread-index: Acdr2a2SkV3n71xgRYSqfWud9OXznACAjZdg From: "Chowdhury, Kuntal" To: "Charlie Kaufman" , Importance: normal X-OriginalArrivalTime: 24 Mar 2007 06:58:43.0130 (UTC) FILETIME=[DC1CE9A0:01C76DE1] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C76DE1.DBD7F9FC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Charlie, =20 Thanks for the summary. I was present at the BoF and I raised some concerns with the applicability of a solution that is heavily dependent on the client to manage/assist gateway failovers. At least this concern is based on how the 3G wireless networks are setup to work (dormant/idle handling and paging overload). This approach seems to lead us to a scalability issue. Please see my comments inline for each of the dimensions and options that you summarized. =20 Regards, Kuntal =20 =20 ________________________________ From: owner-ietf-ipsec-failover@mail.vpnc.org [mailto:owner-ietf-ipsec-failover@mail.vpnc.org] On Behalf Of Charlie Kaufman Sent: Wednesday, March 21, 2007 11:55 AM To: ietf-ipsec-failover@vpnc.org Subject: Range of Options for IPsec failover =20 At today's meeting, I think I heard some actual disagreements about what the group should do, but much more I think I heard confusion about what others meant in their statements of requirements. I think I understand the range of possibilities people are talking about it, and I'm writing it up here in hopes of getting a common vocabulary for the discussion. Failing that, perhaps someone else by correcting my summary can get us closer to that. =20 The problem being addressed in this (potential) WG is related to MOBIKE, but it is not the same. MOBIKE assumes a handoff, where an IKE SA and its associated IPsec SA state moves from one IP address to another without any state being lost. This is accomplished by either having the computer implementing the IPsec endpoint changing its address but not the hardware on which it is implemented (the common case); or alternately, the IPsec state moves from one machine to another in a tightly synchronized way. These two cases are not distinguishable to the end that didn't move. =20 This (potential) WG would handle the case where an IPsec endpoint crashes, becomes inaccessible, or otherwise loses IPsec state, but where we still want to "resume" communication with an alternate (or rebooted) endpoint more quickly and seamlessly than would be possible by just rerunning IPsec from a ground state. =20 I see two dimensions for categorization of requirements (and potential solutions). =20 Dimension 1: Whether we are trying to standardize failover between implementations from different vendors (vs. declaring that case out of scope) =20 This is best understood in the context of an example. Suppose my laptop opens an IPsec tunnel to a firewall protecting my corporate intranet, and if I want to be able to rapidly failover should my firewall crash by connecting to another instance of the corporate firewall and running a quick IPsec initialization that skips (say) the manual input of the number form my SecurID card. I could do this by having the first instance of my firewall giving my laptop some sort of cryptographic blob that will help me to reconnect on failover, and modifying the IPsec implementation on my laptop to use that blob in some special way when I reconnect. For this to work, there must be some cooperation between the two firewalls that allow the blob produced by one to be consumed by the other. The decision we (the BOF) must decide along this dimension is whether we are "only" going to specify how the client is going to accept and send the blob and resume the IPsec session or whether we are in addition going to specify the contents and syntax of the blob so that a blob generated by one vendor's implementation will be consumable by another's. =20 In my opinion, this extra work seems high risk with little obvious value. In the common case, the different instances of my corporate firewall are going to be from the same vendor. So in my opinion, we should at least separate out any such specification into a separate work item, and we should design our system so that servers could implement a proprietary blob format and still interoperate with standard clients (though failover would only work between compatible servers). =20 [KC>] This is going to be problematic in a large scale 3G wireless network. The purpose of bringing up the 3G wireless scenario is that, at the meeting it was clarified that MIP6 Home Agent failover is a major motivation for this effort. In a 3G wireless network, we cannot assume that the Home Agents are all from the same vendor. Therefore, the assumption of an opaque implementation specific blob that is supposed to rescue the IPsec session upon failover won't be valid. =20 Dimension 2: How much state are we going to preserve across IPsec resumes? The more state we preserve, the faster the resume, but there is a downside in terms of both performance and security in preserving more state. I can imagine several logical points along this dimension (and I'll bet others can think of more). Ordered from least to most state: =20 Option 1: Avoid authentication on reconnect. This is attractive if the problem you're trying to solve is avoiding the repeating of expensive and inconvenient EAP authentication or public key signing (perhaps using a smart card hosted key) during the resume. One could imagine that following an IPsec authentication, the server presents the initiator with a secret key and a "ticket". On a resumption, the client does a shared key authentication instead of a public key or EAP authentication using that shared key. The ticket contains information about the client identity encrypted under a secret key that is private to the server (and its failover buddies). One could imagine a client caching the ticket and key for weeks or months - effectively as long as you want to allow a connection to stay up without reproving the long term credentials. Because shared key IPsec repeats the D-H exchange, there is no loss of security with this approach, but resumption does require a four message exchange and a D-H calculation and so lacks the performance of some later options. [KC>] This solution will have the same scalability problem since each client needs to be prompted to go through at least 4 IKE message exchanges. Depending on the number of clients supported on the failed gateway/Home Agent (potentially millions) this will cause massive overhead on a 3G wireless network. Moreover, we never talked about fail back (or switch back). Many operators want the session/traffic to switch back to the primary Home Agent when it recovers after a crash. Switch back will also cause another message storm over-the- air making the matter even worse. =20 Option 2: Avoid authentication and D-H on reconnect. This gives better performance than option 1 by avoiding the D-H exchange on reconnect. If not designed and implemented very carefully, however, Perfect Forward Secrecy is lost. Perfect Forward Secrecy provides that if a conversation is recorded and after the conversation ends an attacker gains access to all keys on both ends of the connection, the attacker still cannot decrypt the recorded conversation. The window necessarily opened by this option is that if a session is resumed and then ends, and if the secret key used by the server to encrypt the ticket is remembered by server beyond the end of that session, an attacker gaining access to that ticket encryption key will be able to decrypt the resumed conversation. In the case where this mechanism is only used to fail over a large number of connections from one server to another, the backup server could forget the ticket encryption key shortly after it reacquires the failed over sessions to preserve PFS. Any sessions not resumed within the window would have to go the expensive path. This trick would not be useful in the case where clients lose connectivity and want to resume connections outside of large groups, since all tickets would have to be reissued every time any session resumed using a ticket terminated. =20 Option 3: Avoid authentication, D-H, crypto negotiation, and traffic selector negotiation on reconnect. Since upon resumption the two endpoints will presumably want to create the same number of IPsec SAs with the same traffic selectors for each (in general, there can be many though in the common case there is only one), some calculation and round trips can be avoided by including information about these in the ticket instead of renegotiating them. One downside of this is that it requires the ticket to be updated whenever an IPsec SA is created or deleted. Another is that it makes the ticket bigger, in turn making it less likely that it can be passed as part of an IKE UDP message. Finally, unless you are going to preserve session keys and sequence numbers (option 4 below), IKE would still have to do some per-SA work to establish new SPIs. It is operationally fragile and may open security flaws to reset the keys and/or sequence numbers on an SA without also changing the SPI. =20 [KC>] Option 2 and 3 mitigate the problem by reducing the number messages required to be exchanged, but they still fail to serve a large scale 3G wireless deployment. =20 Option 4: Avoid all state renegotiation. This is what MOBIKE does, which is reasonable under the assumption that all server state (including session keys, traffic selectors, SPIs, and current sequence numbers) can be migrated. It cannot deal with server crashes unless you assume that state is backed up after every message (to record the new sequence numbers). [KC>] This seems to be the most promising to me. However, as you pointed out, we need to think of a good way to address the sequence number issue. BTW, for MIP6, the sequence number won't change per packet for data traffic. MIP6 only mandates IPsec ESP protection for the signaling packets (BU, BA, HoT, HoTi). These messages are exchanged rarely. So, it is quite likely that the sequence numbers of majority of the MIP6 sessions will be in-sync between the failed over Home Agent and the Clients. =20 In my opinion, supporting Option 1 seems both straightforward and operationally useful. Even if we also standardize Option 2, I would recommend also standardizing Option 1. =20 In my opinion, Option 2 is on the edge. As an engineer, I would find it interesting to design (trying to avoid the various security pitfalls while getting the performance benefit). But I have to sympathize with Eric's warning not to bet against Moore's law and wonder whether we should be designing this fragile thing to solve a fringe case when we could instead throw hardware at it. I think it is incumbent on those who think a D-H per client resumption is too expensive to describe in detail their motivating scenario. I would also remind everyone that IPsec was designed to be "fairly secure" even if clients and servers avoid repeated D-H calculations by reusing their D-H keys and caching the results. It might be better to meet the performance bar by abusing the current protocol rather than creating a new one. [KC>] Throwing more hardware to handle huge number of IKEv2 (D-H) messages is the easy part. The real problem lies in the fact that the IPsec clients may be using 3G wireless links where paging / access channel capacity is often in short supply and data path establishment for the dormant/idle clients take finite amount of network resources.=20 =20 In my opinion, Option 3 seems farfetched. The potential performance gain is one round trip (and it's not obvious that even that can be saved) and some secret key operations for key derivation, while the cost in complexity and in ticket size seems daunting. I could be convinced that there are scenarios to justify it, but I can't imagine any. =20 Option 4 seems plausible only in the case where the servers maintain shared state, and in that case the MOBIKE protocol seems adequate. It's not obvious (to me anyway) why you would want to have the client participate in the migration if the servers already have to be tightly coordinated. =20 Tell me what I'm missing... =20 --Charlie "This email message and any attachments are confidential information of = Starent Networks, Corp. The information transmitted may not be used to = create or change any contractual obligations of Starent Networks, Corp. = Any review, retransmission, dissemination or other use of, or taking of = any action in reliance upon this e-mail and its attachments by persons = or entities other than the intended recipient is prohibited. If you are = not the intended recipient, please notify the sender immediately -- by = replying to this message or by sending an email to = postmaster@starentnetworks.com -- and destroy all copies of this message = and any attachments without reading or disclosing their contents. Thank = you." ------_=_NextPart_001_01C76DE1.DBD7F9FC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Charlie,

 

Thanks for the summary. I was = present at the BoF and I raised some concerns with the applicability of a solution = that is heavily dependent on the client to manage/assist gateway failovers. At = least this concern is based on how the 3G wireless networks are setup to work (dormant/idle handling and paging overload). This approach seems to lead = us to a scalability issue. Please see my comments inline for each of the = dimensions and options that you summarized.

 

Regards,

Kuntal

 

 

From: owner-ietf-ipsec-failover@mail.vpnc.org [mailto:owner-ietf-ipsec-failover@mail.vpnc.org] On Behalf Of Charlie Kaufman
Sent: Wednesday, March = 21, 2007 11:55 AM
To: = ietf-ipsec-failover@vpnc.org
Subject: Range of Options for IPsec failover

 

At today’s meeting, I think I heard some actual disagreements about = what the group should do, but much more I think I heard confusion about what = others meant in their statements of requirements. I think I understand the = range of possibilities people are talking about it, and I’m writing it up = here in hopes of getting a common vocabulary for the discussion. Failing that, = perhaps someone else by correcting my summary can get us closer to = that.

 

The problem being addressed in this (potential) WG is related to MOBIKE, but = it is not the same. MOBIKE assumes a handoff, where an IKE SA and its = associated IPsec SA state moves from one IP address to another without any state = being lost. This is accomplished by either having the computer implementing = the IPsec endpoint changing its address but not the hardware on which it is = implemented (the common case); or alternately, the IPsec state moves from one = machine to another in a tightly synchronized way. These two cases are not = distinguishable to the end that didn’t move.

 

This (potential) WG would handle the case where an IPsec endpoint crashes, = becomes inaccessible, or otherwise loses IPsec state, but where we still want to = “resume” communication with an alternate (or rebooted) endpoint more quickly and seamlessly than would be possible by just rerunning IPsec from a ground = state.

 

I see two dimensions for categorization of requirements (and potential solutions).

 

Dimension 1: Whether we are trying to standardize failover between implementations = from different vendors (vs. declaring that case out of = scope)

 

This is best understood in the context of an example. Suppose my laptop opens = an IPsec tunnel to a firewall protecting my corporate intranet, and if I = want to be able to rapidly failover should my firewall crash by connecting to = another instance of the corporate firewall and running a quick IPsec = initialization that skips (say) the manual input of the number form my SecurID card. I = could do this by having the first instance of my firewall giving my laptop = some sort of cryptographic blob that will help me to reconnect on failover, and = modifying the IPsec implementation on my laptop to use that blob in some special = way when I reconnect. For this to work, there must be some cooperation between = the two firewalls that allow the blob produced by one to be consumed by the = other. The decision we (the BOF) must decide along this dimension is whether we are = “only” going to specify how the client is going to accept and send the blob and = resume the IPsec session or whether we are in addition going to specify the = contents and syntax of the blob so that a blob generated by one vendor’s implementation will be consumable by = another’s.

 

In my opinion, this extra work seems high risk with little obvious value. = In the common case, the different instances of my corporate firewall are going = to be from the same vendor. So in my opinion, we should at least separate out = any such specification into a separate work item, and we should design our = system so that servers could implement a proprietary blob format and still = interoperate with standard clients (though failover would only work between = compatible servers).

 

[KC>] This is going to be problematic in a large = scale 3G wireless network. The purpose of bringing up the 3G wireless scenario is = that, at the meeting it was clarified that MIP6 Home Agent failover is a major = motivation for this effort. In a 3G wireless network, we cannot assume that the = Home Agents are all from the same vendor. Therefore, the assumption of an = opaque implementation specific blob that is supposed to rescue the IPsec = session upon failover won’t be valid.

 

Dimension 2: How much state are we going to preserve across IPsec resumes? The = more state we preserve, the faster the resume, but there is a downside in terms of = both performance and security in preserving more state. I can imagine several logical points along this dimension (and I’ll bet others can think = of more). Ordered from least to most state:

 

Option 1: Avoid authentication on reconnect. This is attractive if the problem = you’re trying to solve is avoiding the repeating of expensive and inconvenient = EAP authentication or public key signing (perhaps using a smart card hosted = key) during the resume. One could imagine that following an IPsec = authentication, the server presents the initiator with a secret key and a = “ticket”. On a resumption, the client does a shared key authentication instead of = a public key or EAP authentication using that shared key. The ticket = contains information about the client identity encrypted under a secret key that = is private to the server (and its failover buddies). One could imagine a = client caching the ticket and key for weeks or months – effectively as = long as you want to allow a connection to stay up without reproving the long = term credentials. Because shared key IPsec repeats the D-H exchange, there is = no loss of security with this approach, but resumption does require a four = message exchange and a D-H calculation and so lacks the performance of some = later options.

[KC>] This solution will have the same scalability problem since each client needs to be prompted to go through at least 4 = IKE message exchanges. Depending on the number of clients supported on the = failed gateway/Home Agent (potentially millions) this will cause massive = overhead on a 3G wireless network. Moreover, we never talked about fail back (or = switch back). Many operators want the session/traffic to switch back to the primary = Home Agent when it recovers after a crash. Switch back will also cause = another message storm over-the- air making the matter even = worse.

 

Option 2: Avoid authentication and D-H on reconnect. This gives better = performance than option 1 by avoiding the D-H exchange on reconnect. If not designed = and implemented very carefully, however, Perfect Forward Secrecy is lost. = Perfect Forward Secrecy provides that if a conversation is recorded and after = the conversation ends an attacker gains access to all keys on both ends of = the connection, the attacker still cannot decrypt the recorded conversation. = The window necessarily opened by this option is that if a session is resumed = and then ends, and if the secret key used by the server to encrypt the = ticket is remembered by server beyond the end of that session, an attacker gaining = access to that ticket encryption key will be able to decrypt the resumed = conversation. In the case where this mechanism is only used to fail over a large = number of connections from one server to another, the backup server could forget = the ticket encryption key shortly after it reacquires the failed over = sessions to preserve PFS. Any sessions not resumed within the window would have to = go the expensive path. This trick would not be useful in the case where clients = lose connectivity and want to resume connections outside of large groups, = since all tickets would have to be reissued every time any session resumed using a = ticket terminated.

 

Option 3: Avoid authentication, D-H, crypto negotiation, and traffic selector negotiation on reconnect. Since upon resumption the two endpoints will presumably want to create the same number of IPsec SAs with the same = traffic selectors for each (in general, there can be many though in the common = case there is only one), some calculation and round trips can be avoided by including information about these in the ticket instead of renegotiating = them. One downside of this is that it requires the ticket to be updated = whenever an IPsec SA is created or deleted. Another is that it makes the ticket = bigger, in turn making it less likely that it can be passed as part of an IKE UDP = message. Finally, unless you are going to preserve session keys and sequence = numbers (option 4 below), IKE would still have to do some per-SA work to = establish new SPIs. It is operationally fragile and may open security flaws to reset = the keys and/or sequence numbers on an SA without also changing the = SPI.

 

[KC>] Option 2 and 3 mitigate the problem by = reducing the number messages required to be exchanged, but they still fail to serve a = large scale 3G wireless deployment.

 

Option 4: Avoid all state renegotiation. This is what MOBIKE does, which is = reasonable under the assumption that all server state (including session keys, = traffic selectors, SPIs, and current sequence numbers) can be migrated. It = cannot deal with server crashes unless you assume that state is backed up after = every message (to record the new sequence = numbers).

[KC>] This seems to be the most promising to me. = However, as you pointed out, we need to think of a good way to address the = sequence number issue. BTW, for MIP6, the sequence number won’t change per = packet for data traffic. MIP6 only mandates IPsec ESP protection for the = signaling packets (BU, BA, HoT, HoTi). These messages are exchanged rarely. So, it = is quite likely that the sequence numbers of majority of the MIP6 sessions = will be in-sync between the failed over Home Agent and the = Clients.

 

In my opinion, supporting Option 1 seems both straightforward and = operationally useful. Even if we also standardize Option 2, I would recommend also standardizing Option 1.

 

In my opinion, Option 2 is on the edge. As an engineer, I would find it interesting to design (trying to avoid the various security pitfalls = while getting the performance benefit). But I have to sympathize with = Eric’s warning not to bet against Moore’s law and wonder whether we should be designing this fragile thing to = solve a fringe case when we could instead throw hardware at it.  I think it = is incumbent on those who think a D-H per client resumption is too = expensive to describe in detail their motivating scenario. I would also remind = everyone that IPsec was designed to be “fairly secure” even if clients and servers avoid repeated D-H calculations by reusing their D-H keys and = caching the results. It might be better to meet the performance bar by abusing = the current protocol rather than creating a new = one.

[KC>] Throwing more hardware to handle huge number = of IKEv2 (D-H) messages is the easy part. The real problem lies in the fact = that the IPsec clients may be using 3G wireless links where paging / access = channel capacity is often in short supply and data path establishment for the dormant/idle clients take finite amount of network resources. =

 

In my opinion, Option 3 seems farfetched. The potential performance gain is = one round trip (and it’s not obvious that even that can be saved) and = some secret key operations for key derivation, while the cost in complexity = and in ticket size seems daunting. I could be convinced that there are = scenarios to justify it, but I can’t imagine any.

 

Option 4 seems plausible only in the case where the servers maintain shared = state, and in that case the MOBIKE protocol seems adequate. It’s not obvious = (to me anyway) why you would want to have the client participate in the = migration if the servers already have to be tightly = coordinated.

 

Tell me what I’m missing…

 

       &nbs= p;        --Charlie

"This email message and any attachments are confidential information = of Starent Networks, Corp. The information transmitted may not be used = to create or change any contractual obligations of Starent Networks, = Corp. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this e-mail and its attachments by = persons or entities other than the intended recipient is prohibited. If = you are not the intended recipient, please notify the sender immediately = -- by replying to this message or by sending an email to = postmaster@starentnetworks.com -- and destroy all copies of this message = and any attachments without reading or disclosing their contents. Thank = you." ------_=_NextPart_001_01C76DE1.DBD7F9FC-- From owner-ietf-ipsec-failover Tue Apr 3 17:49:12 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l340nC4n009356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2007 17:49:12 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l340nC43009355; Tue, 3 Apr 2007 17:49:12 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l340nAvY009348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 3 Apr 2007 17:49:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 3 Apr 2007 17:48:59 -0700 To: ietf-ipsec-failover@vpnc.org From: Paul Hoffman Subject: Minutes from Prague Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi again. Because we failed to get a scribe at the meeting, I listened to the MP3 of the meeting and created the minutes. They are at --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsec-failover Mon Apr 16 00:08:36 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3G78Zbq070551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 00:08:35 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3G78ZLF070550; Mon, 16 Apr 2007 00:08:35 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3G78DVY070527 for ; Mon, 16 Apr 2007 00:08:33 -0700 (MST) (envelope-from denghui02@gmail.com) Received: by an-out-0708.google.com with SMTP id b33so1629052ana for ; Mon, 16 Apr 2007 00:08:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HPBxVDMTvTrg7TcPZhP3uA/uw5DPoSzwwxNyh2rVl1biqc6VAHjGHqLWUgtcR4Ex522tRBYhLWR9aJvPe5guBI0bNR5xXRaXX2y3fhDNu4kyy449VIQBoTqAPTbHwrvr+Rif49dgnXpbCqmQ08/gC8DwtsNxi202tewrMpf/qJo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RaQ5KVLFhTwOtU1i/eWJaO2u4rX8Lc6iiApORTQG/6OlZnH6oyFp3gnqe753PfA6lCFk0o9OrTxDK7OIhW3svfJVHluqigplA2642QQmApaqOrJwvAVthQzK5UhDiYk3czfOmZlXuTkLj/pXeRFdNLXVX/ZoFDDf9Rt7WRlyHFA= Received: by 10.100.93.5 with SMTP id q5mr4264466anb.1176707292765; Mon, 16 Apr 2007 00:08:12 -0700 (PDT) Received: by 10.100.209.11 with HTTP; Mon, 16 Apr 2007 00:08:12 -0700 (PDT) Message-ID: <1d38a3350704160008h1abf10f7re76967aa1f5ceec8@mail.gmail.com> Date: Mon, 16 Apr 2007 15:08:12 +0800 From: "Hui Deng" To: "Chowdhury, Kuntal" Subject: Re: Range of Options for IPsec failover Cc: "Charlie Kaufman" , ietf-ipsec-failover@vpnc.org In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024D9D69@exchtewks2.starentnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <30C65F3A3407B943826897E025135BE67C5D652CAB@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <7CCD07160348804497EF29E9EA5560D7024D9D69@exchtewks2.starentnetworks.com> Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Please allow me cut in, > [KC>] This seems to be the most promising to me. However, as you pointed > out, we need to think of a good way to address the sequence number issue. > BTW, for MIP6, the sequence number won't change per packet for data traffic. > MIP6 only mandates IPsec ESP protection for the signaling packets (BU, BA, > HoT, HoTi). These messages are exchanged rarely. So, it is quite likely that > the sequence numbers of majority of the MIP6 sessions will be in-sync > between the failed over Home Agent and the Clients. Please include MPS and MPA, thanks -Hui From owner-ietf-ipsec-failover Fri May 18 16:58:02 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4INw2NI098207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 May 2007 16:58:02 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l4INw2se098206; Fri, 18 May 2007 16:58:02 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4INvw4x098173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 18 May 2007 16:57:59 -0700 (MST) (envelope-from vidyan@qualcomm.com) Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l4INvmr1004469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 May 2007 16:57:48 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l4INvkp3008491; Fri, 18 May 2007 16:57:47 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 16:57:46 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Revised IFARE problem statement Date: Fri, 18 May 2007 16:57:49 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revised IFARE problem statement Thread-Index: AceZqFb+7Zzt3wsaQSC+M9cMgF7s1A== From: "Narayanan, Vidya" To: Cc: , "Chowdhury, Kuntal" , "Vijay Devarapalli" , "Kent Leung (kleung)" X-OriginalArrivalTime: 18 May 2007 23:57:46.0758 (UTC) FILETIME=[55466260:01C799A8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l4INvx4w098175 Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, After talking to some more folks in the mobility space, I've updated the PS to reflect the scenarios in 3G networks and the relation to the MIP6 Home Agent reliability work in a better fashion. Consequently, some clarifications on the goals have also been added. This revision also addresses Gregory's comments that were sent to the list. Until the updated draft is available at the IETF repository, it can be found at http://www.geocities.com/hellovidya/draft-vidya-ipsec-failover-ps-02.txt . Please review and comment. Folks on the cc list, I'd especially like a review from you all to ensure that this revised draft captures your suggestions and if the goals now cover the cases needed for the MIP6 Home Agent reliability work in your view. Thanks, Vidya From owner-ietf-ipsec-failover Fri May 18 17:12:59 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4J0CxgZ004421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 May 2007 17:12:59 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l4J0CxD7004419; Fri, 18 May 2007 17:12:59 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4J0CuOI004400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 18 May 2007 17:12:58 -0700 (MST) (envelope-from vidyan@qualcomm.com) Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l4J0Cs4p005493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 May 2007 17:12:55 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l4J0Csn6014511; Fri, 18 May 2007 17:12:54 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 17:12:54 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: FW: Revised IFARE problem statement Date: Fri, 18 May 2007 17:12:58 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revised IFARE problem statement Thread-Index: AceZqFb+7Zzt3wsaQSC+M9cMgF7s1AAAN1VA From: "Narayanan, Vidya" To: Cc: X-OriginalArrivalTime: 19 May 2007 00:12:54.0409 (UTC) FILETIME=[7246EF90:01C799AA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l4J0CxOH004412 Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm forwarding this to MIP6 so that we can get more people to review the draft. The IFARE work is targeted towards enabling a quick Home Agent recovery from an IPsec perspective and hence relates to the MIP6 HA reliability work under progress. Please review and send any comments/questions either to me offline or to the IFARE mailing list (ietf-ipsec-failover@vpnc.org). Please refrain from having the discussion on the MIP6 list, unless the questions specifically relate to MIP6. In any event, copying the IFARE list would be appreciated. To provide some more background, while IFARE is targeting a generic IKEv2 session resumption mechanism that would help resuming IPsec sessions rather quickly upon the need for a gateway switch (or reconnect when a gateway reboots), the mechanism is meant to help quicker recovery from Home Agent switches in MIP6. In the process, it is feasible that certain additional optimizations may be applicable specifically for the MIP6 use. Such optimizations won't be in the scope of IFARE itself. Using the mechanisms that will be developed in IFARE, it may be possible to optimize the MIP6 use of it further and we could consider that as part of the HA reliability work if applicable. So, for the purpose of the IFARE work, please review to ensure that the goals in this draft cover everything needed for IPsec usage in MIP6. Thanks, Vidya > -----Original Message----- > From: Narayanan, Vidya > Sent: Friday, May 18, 2007 4:58 PM > To: ietf-ipsec-failover@vpnc.org > Cc: gregory.ietf@gmail.com; 'Chowdhury, Kuntal'; 'Vijay > Devarapalli'; 'Kent Leung (kleung)' > Subject: Revised IFARE problem statement > > All, > After talking to some more folks in the mobility space, I've > updated the PS to reflect the scenarios in 3G networks and > the relation to the MIP6 Home Agent reliability work in a > better fashion. Consequently, some clarifications on the > goals have also been added. This revision also addresses > Gregory's comments that were sent to the list. > > Until the updated draft is available at the IETF repository, > it can be found at > http://www.geocities.com/hellovidya/draft-vidya-ipsec-failover -ps-02.txt. > > Please review and comment. Folks on the cc list, I'd > especially like a review from you all to ensure that this > revised draft captures your suggestions and if the goals now > cover the cases needed for the MIP6 Home Agent reliability > work in your view. > > Thanks, > Vidya From owner-ietf-ipsec-failover Mon May 21 16:37:30 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4LNbUvH058670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 May 2007 16:37:30 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l4LNbUxg058669; Mon, 21 May 2007 16:37:30 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from [10.20.30.104] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4LNbScY058639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 May 2007 16:37:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 21 May 2007 16:37:20 -0700 To: From: Paul Hoffman Subject: Fwd: I-D ACTION:draft-vidya-ipsec-failover-ps-02.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >To: i-d-announce@ietf.org >Cc: >From: Internet-Drafts@ietf.org >Date: Mon, 21 May 2007 15:50:02 -0400 >X-Spam-Score: -2.5 (--) >X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 >Subject: I-D ACTION:draft-vidya-ipsec-failover-ps-02.txt >X-BeenThere: i-d-announce@ietf.org >X-Mailman-Version: 2.1.5 >Reply-To: internet-drafts@ietf.org >List-Id: i-d-announce.ietf.org > > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : IPsec Gateway Failover and Redundancy - >Problem Statement and Goals > Author(s) : V. Narayanan > Filename : draft-vidya-ipsec-failover-ps-02.txt > Pages : 15 > Date : 2007-5-21 > >Recovering from failure of IPsec gateways maintaining large numbers > of SAs may take several minutes, if they need to re-establish the > IPsec SAs by re-running the key management protocol, IKEv2. A > similar problem arises in the event of a network outage resulting in > the failure of several gateways and servers. The latency involved in > this approach is significant, leading to a need for a faster and yet > secure failover solution. This document describes the problem > statement and the goals for an IPsec/IKEv2 gateway failover/ > redundancy solution. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-vidya-ipsec-failover-ps-02.txt > From owner-ietf-ipsec-failover Thu May 31 19:46:05 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l512k5TP036516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 May 2007 19:46:05 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l512k5RH036515; Thu, 31 May 2007 19:46:05 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l512k3jb036509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 31 May 2007 19:46:04 -0700 (MST) (envelope-from ldondeti@qualcomm.com) Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l512jY1J031124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 31 May 2007 19:45:34 -0700 Received: from [10.50.73.85] (qconnect-10-50-73-85.qualcomm.com [10.50.73.85]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l512jWqx026223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 May 2007 19:45:32 -0700 (PDT) Message-ID: <465F884E.1050409@qualcomm.com> Date: Thu, 31 May 2007 19:45:34 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ietf-ipsec-failover@vpnc.org CC: gregory.ietf@gmail.com, kivinen@iki.fi, Michael Richardson , Yaron Sheffer Subject: IFARE open issues and next steps Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Folks, At the BoF session in Prague there were some questions for clarification, some objections and most crucially people showing interest on the IFARE work showing interest on various different components from the problem statement. At least that was the impression. My take is that the people showing interest were not really that far apart. So, could the folks active at the meeting post their thoughts on whether they agree with scope described in the PS? If not, what do you think should or shouldn't be in scope? If it helps for someone to put together some meaningful subsets, please let me know and I can try and do that. thanks, Lakshminath From owner-ietf-ipsec-failover Fri Jun 1 06:41:43 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l51Dfh9b062853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Jun 2007 06:41:43 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l51DfhIg062852; Fri, 1 Jun 2007 06:41:43 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l51DffaT062843 for ; Fri, 1 Jun 2007 06:41:42 -0700 (MST) (envelope-from jeanmichel.combes@gmail.com) Received: by an-out-0708.google.com with SMTP id d26so178997and for ; Fri, 01 Jun 2007 06:41:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Rw99yPlWekY9esWTjv/giR59PNQMLHQiavqDPQjb83PzeELISonxr1zz3hjJ7JC23RskobQJ6xutg4NKuV0cQ+VA7tVVZrAkx2gEHRUSZFiMEx9GJ4BKVHKwmuBD1fhgBphBt5qFXSpaiE+gnOJcx69C+Tm9Rqk9fZlHVJcYp8Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OZju47fXpr5LNHSFLxzSuaeALuw4vE1zWvTFVu1Nv/0KzzO/FvcAmpLLNBg/Vh3lk0tZh0uv3wURqi2Cqy0Cye4nWb8IN52GdfkYZ3WksiCI65D/lR2lFam3RNEYzngX/hfRTrTc7qSAHjQ9qyZ/jLjspk+7LHZQ9pM3ZxBtXB8= Received: by 10.100.206.11 with SMTP id d11mr1000935ang.1180705298735; Fri, 01 Jun 2007 06:41:38 -0700 (PDT) Received: by 10.100.135.16 with HTTP; Fri, 1 Jun 2007 06:41:38 -0700 (PDT) Message-ID: <729b68be0706010641v67eb1b85j1823a02d155e9e68@mail.gmail.com> Date: Fri, 1 Jun 2007 15:41:38 +0200 From: "Jean-Michel Combes" To: "Lakshminath Dondeti" Subject: Re: IFARE open issues and next steps Cc: ietf-ipsec-failover@vpnc.org, gregory.ietf@gmail.com, kivinen@iki.fi, "Michael Richardson" , "Yaron Sheffer" In-Reply-To: <465F884E.1050409@qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <465F884E.1050409@qualcomm.com> Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, sorry for the silence, but the main reason is that I am happy with the new version of the draft. Best regards. JMC. 2007/6/1, Lakshminath Dondeti : > > Folks, > > At the BoF session in Prague there were some questions for > clarification, some objections and most crucially people showing > interest on the IFARE work showing interest on various different > components from the problem statement. At least that was the impression. > > My take is that the people showing interest were not really that far > apart. So, could the folks active at the meeting post their thoughts on > whether they agree with scope described in the PS? If not, what do you > think should or shouldn't be in scope? > > If it helps for someone to put together some meaningful subsets, please > let me know and I can try and do that. > > thanks, > Lakshminath > > From owner-ietf-ipsec-failover Tue Jun 5 08:24:15 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l55FOFKU004958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jun 2007 08:24:15 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l55FOFxd004957; Tue, 5 Jun 2007 08:24:15 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l55FOEhY004951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 5 Jun 2007 08:24:14 -0700 (MST) (envelope-from ldondeti@qualcomm.com) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l55FNYJE023326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 5 Jun 2007 08:23:34 -0700 Received: from [129.46.78.141] (ldondeti.na.qualcomm.com [129.46.78.141]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l55FNWai025180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Jun 2007 08:23:32 -0700 Message-ID: <46657FF4.6040609@qualcomm.com> Date: Tue, 05 Jun 2007 08:23:32 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Jean-Michel Combes CC: ietf-ipsec-failover@vpnc.org, gregory.ietf@gmail.com, kivinen@iki.fi, Michael Richardson , Yaron Sheffer Subject: Re: IFARE open issues and next steps References: <465F884E.1050409@qualcomm.com> <729b68be0706010641v67eb1b85j1823a02d155e9e68@mail.gmail.com> In-Reply-To: <729b68be0706010641v67eb1b85j1823a02d155e9e68@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks much. Any others who think this work should go forward and that we should have a second BoF and a subsequent working group in this area? I am sorry for the high-level question, but we need to get this out of the way first. There was some confusion at the last meeting, but my sense is that there is general support. Others may think differently, and so we want explicit notes from people about their interest in the work. regards, Lakshminath On 6/1/2007 6:41 AM, Jean-Michel Combes wrote: > > Hi, > > sorry for the silence, but the main reason is that I am happy with the > new version of the draft. > > Best regards. > > JMC. > > 2007/6/1, Lakshminath Dondeti : >> >> Folks, >> >> At the BoF session in Prague there were some questions for >> clarification, some objections and most crucially people showing >> interest on the IFARE work showing interest on various different >> components from the problem statement. At least that was the impression. >> >> My take is that the people showing interest were not really that far >> apart. So, could the folks active at the meeting post their thoughts on >> whether they agree with scope described in the PS? If not, what do you >> think should or shouldn't be in scope? >> >> If it helps for someone to put together some meaningful subsets, please >> let me know and I can try and do that. >> >> thanks, >> Lakshminath >> >> > > From owner-ietf-ipsec-failover Tue Jun 5 21:44:02 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l564i2bb039347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jun 2007 21:44:02 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l564i2Dp039346; Tue, 5 Jun 2007 21:44:02 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l564i0Bj039314 for ; Tue, 5 Jun 2007 21:44:01 -0700 (MST) (envelope-from mstenber@cisco.com) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 05 Jun 2007 21:44:00 -0700 X-IronPort-AV: i="4.16,387,1175497200"; d="scan'208"; a="161153906:sNHT54789021" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l564i0AA019332 for ; Tue, 5 Jun 2007 21:44:00 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l564i0aI023791 for ; Wed, 6 Jun 2007 04:44:00 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 21:44:00 -0700 Received: from [127.0.0.1] ([10.70.237.16]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 21:43:59 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D741823-CFA3-4C4D-85C6-6A559BC2655F@cisco.com> Content-Transfer-Encoding: 7bit From: Markus Stenberg Subject: Comments on -02 PS.. Date: Wed, 6 Jun 2007 13:43:50 +0900 To: ietf-ipsec-failover@vpnc.org X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 06 Jun 2007 04:43:59.0991 (UTC) FILETIME=[4CC14870:01C7A7F5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2552; t=1181105040; x=1181969040; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mstenber@cisco.com; z=From:=20Markus=20Stenberg=20 |Subject:=20Comments=20on=20-02=20PS.. |Sender:=20; bh=ItgzbJCFJMDGf8FBzZQdYlGsMZbeUyDXfBlnSfOq1wg=; b=u3nhvzraWS7g6XXeq7Jkr+FSpfXsrnZuYKmTpPlyGWT8lk8eSG+aMSL7SCmo9UQgBvu9NWR8 BesKFTFuwjSDRW45BRuodLNL8MlPLPxIYHBH4Xk3isefLXG13BykJkoN; Authentication-Results: sj-dkim-2; header.From=mstenber@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Disclaimer: I have been interested on and off about this topic since the start, but missed the BoF due to $DAYJOB forcing me to go to another WG. I also use term 'server' here for the SGW/end host that the client connects to. I will probably miss the Chicago BOF if it happens too, again due to $DAYJOB. I think the PS has gone long ways in becoming concise and to the point; the initial versions were less specific about the applications, and how the solution was actually meant to work. Currently, the problem stmt basically provides a way of getting rid of most of the client/server computing load on switchover, and the cost of HA server state synchronization cost at the expense of some more complexity to the IPsec suite / some storage on the client. Looking at the pros/cons: Client + faster switchover (mobility, HA) due to less roundtrips (this is most likely big concern in mobility case) + less computing on switchover (also nice for mobility) - storage of the authorization blob; should be fairly small, although if vendor-specific extensions were allowed to payload in general, it might grow.. just IKEv2 _protocol_ state isn't that big - code complexity grows Server + less load on non-check-pointed switchovers + less state storage needed overall (due to no need to replicate state) + less complex code in general if HA can be skipped - however, if support for normal clients is also desired to work 'well', you lose the above benefit and the one above that is also bit questionable (certainly, across-site less state, but who'd design such a solution in the first place?) - extra code Looking at the arguments, if you control client/server, and do anything with MIP, you'd definitely want this solution - you could skip most of the normal IPsec-related HA code on the server side, get more scalable failovers, and get nice, fast switchovers for the mobile nodes given some assumptions on how the HA is handled) For normal VPN user case (is it still the traditional assumption?), I see only marginal benefits due to lack of guarantee of both ends supporting it - server needs to be designed for non-supporting case, and client gets some benefits with the rare server crashes, at cost of significant chunk of extra code. Overall? Seems worth doing to me, although I'm curious to hearing some sort of 'show of hands' about people really planning on implementing this, but guess that's what BoFs are for :-) Cheers, -Markus From owner-ietf-ipsec-failover Wed Jun 6 10:28:44 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l56HSib1005811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jun 2007 10:28:44 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l56HSirG005810; Wed, 6 Jun 2007 10:28:44 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l56HSgNK005795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 6 Jun 2007 10:28:43 -0700 (MST) (envelope-from vidyan@qualcomm.com) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l56HSfAO008984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Jun 2007 10:28:42 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l56HSdrl014848; Wed, 6 Jun 2007 10:28:41 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 10:28:35 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Comments on -02 PS.. Date: Wed, 6 Jun 2007 10:28:32 -0700 Message-ID: In-Reply-To: <7D741823-CFA3-4C4D-85C6-6A559BC2655F@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on -02 PS.. Thread-Index: Acen9hv533YROBB8Rom4DIFut50OtQAZnnoQ References: <7D741823-CFA3-4C4D-85C6-6A559BC2655F@cisco.com> From: "Narayanan, Vidya" To: "Markus Stenberg" , X-OriginalArrivalTime: 06 Jun 2007 17:28:35.0514 (UTC) FILETIME=[1CB291A0:01C7A860] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l56HShNJ005797 Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Markus, Thanks for the review. I agree that the case for the MIP6 use is more compelling than that for the regular VPN use, due to having to support failovers for regular clients that don't support this in the latter case. However, the use of VPNs in a 3G environment (such as for use over untrusted networks) can benefit from a solution such as this one. Basically, as you note, if the clients support the solution developed here, the gateways/servers would be able to use it, without having to do any state replication. Even if they do state replication, they can support distributed failovers using this approach. But, it will depend on client support. If the cellular standards require it on the client, the gateways deployed in those enviroments can use this to provide a distributed failover solution. In order to get there though, we need to have a solution at the IETF for the cellular SDOs to consider and evaluate it. Cheers, Vidya > -----Original Message----- > From: owner-ietf-ipsec-failover@mail.vpnc.org > [mailto:owner-ietf-ipsec-failover@mail.vpnc.org] On Behalf Of > Markus Stenberg > Sent: Tuesday, June 05, 2007 9:44 PM > To: ietf-ipsec-failover@vpnc.org > Subject: Comments on -02 PS.. > > > Disclaimer: I have been interested on and off about this > topic since the start, but missed the BoF due to $DAYJOB > forcing me to go to another WG. I also use term 'server' here > for the SGW/end host that the client connects to. I will > probably miss the Chicago BOF if it happens too, again due to $DAYJOB. > > I think the PS has gone long ways in becoming concise and to > the point; the initial versions were less specific about the > applications, and how the solution was actually meant to work. > > Currently, the problem stmt basically provides a way of > getting rid of most of the client/server computing load on > switchover, and the cost of HA server state synchronization > cost at the expense of some more complexity to the IPsec > suite / some storage on the client. > > Looking at the pros/cons: > > Client > + faster switchover (mobility, HA) due to less roundtrips (this is > most likely big concern in mobility case) > + less computing on switchover (also nice for mobility) > - storage of the authorization blob; should be fairly small, > although if vendor-specific extensions were allowed to > payload in general, it might grow.. just IKEv2 _protocol_ > state isn't that big > - code complexity grows > > Server > + less load on non-check-pointed switchovers less state > storage needed > + overall (due to no need to replicate state) less complex code in > + general if HA can be skipped > - however, if support for normal clients is also desired to > work 'well', you lose the above benefit and the one above > that is also bit questionable (certainly, across-site less > state, but who'd design such a solution in the first place?) > - extra code > > Looking at the arguments, if you control client/server, and > do anything with MIP, you'd definitely want this solution - > you could skip most of the normal IPsec-related HA code on > the server side, get more scalable failovers, and get nice, > fast switchovers for the mobile nodes given some assumptions > on how the HA is handled) > > For normal VPN user case (is it still the traditional > assumption?), I see only marginal benefits due to lack of > guarantee of both ends supporting it - server needs to be > designed for non-supporting case, and client gets some > benefits with the rare server crashes, at cost of significant > chunk of extra code. > > Overall? Seems worth doing to me, although I'm curious to > hearing some sort of 'show of hands' about people really > planning on implementing this, but guess that's what BoFs are for :-) > > Cheers, > > -Markus > > > From owner-ietf-ipsec-failover Mon Jun 11 17:17:52 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5C0HqHo082749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jun 2007 17:17:52 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5C0Hqhg082748; Mon, 11 Jun 2007 17:17:52 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from carter-zimmerman.suchdamage.org (m983336d0.tmodns.net [208.54.51.152]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5C0HjpG082742 for ; Mon, 11 Jun 2007 17:17:49 -0700 (MST) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5A646C4013; Mon, 11 Jun 2007 18:25:02 -0400 (EDT) From: Sam Hartman To: ietf-ipsec-failover@vpnc.org Cc: saag@mit.edu Subject: Declining the ifare bof for Chicago Date: Mon, 11 Jun 2007 18:25:02 -0400 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Regretfully, I have chosen to decline to sponsor the ifare bof for Chicago. I think there is a lot of interest. However I don't think we have come far enough in working with people who disagree with the ifare proposal or who don't see the value for a productive second BOF. Remember that if this second BOF doesn't get us the face to face time we need to get a charter, our options are very limited. Proposals are given at most two BOFs. According to the MIP6 chairs this effort has received little traction in the MIP6 working group. In order to use the current problem and applicability statement you would need to show significant interest from the MIP6 working group. Also, there has been rather limited discussion on the BOF list. I'd be happy to meet with proponents of this work in Chicago and discuss how we can try and build the necessary support for a second BOF. Sam Hartman Security Area Director From owner-ietf-ipsec-failover Mon Jun 11 18:55:11 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5C1tBxD087080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jun 2007 18:55:11 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5C1tB9G087079; Mon, 11 Jun 2007 18:55:11 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5C1t9mf087073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 11 Jun 2007 18:55:10 -0700 (MST) (envelope-from ldondeti@qualcomm.com) Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l5C1t78l026599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Jun 2007 18:55:08 -0700 Received: from [129.46.78.141] (ldondeti.na.qualcomm.com [129.46.78.141]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l5C1t7GP006994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Jun 2007 18:55:07 -0700 (PDT) Message-ID: <466DFCF8.8070305@qualcomm.com> Date: Mon, 11 Jun 2007 18:55:04 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Sam Hartman CC: ietf-ipsec-failover@vpnc.org, saag@mit.edu Subject: Re: Declining the ifare bof for Chicago References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sam, I don't understand your line of reasoning for turning away this work. You note that there is a lot of interest, and I know that there has only been one person who disagrees with the IFARE proposal (perhaps I* members' opinions are afforded special status?). There was also some confusion at the last face to face meeting; some of it was in fact clarified at the meeting (e.g., Paging issues were raised by folks who thought gateway initiated operation was being proposed -- it was not -- and Tero from the audience clarified that it is a non-issue as the proposal on the table was only talking about client-initiated operation) and quite a bit of it in offline exchanges, I am told. Given a lot of interest, one objection, and some confusion, what makes you draw the conclusion that the second BoF will not be productive? The MIP6 working group developed the AUTH protocol (do I need to bring up the thing about using 128 bit keys with HMAC-SHA-1, which seems to be an oversight and not a conscious choice with reasoning) and they think it is fine as an alternative to IPsec. I am surprised consensus in that group is the barrier for doing the IFARE work. Please read the security considerations of http://tools.ietf.org/html/draft-ietf-mip6-hareliability-01 http://tools.ietf.org/html/draft-ietf-mip6-ha-switch-03 One of them says use 4285 (one of the options listed, perhaps we should never mind the applicability statement on that RFC). The other says add a random number to the ESP sequence number so binding updates pass replay verification. What happens when we are in the mode of saying "it is not really clear to us," "we need to support this work" or "one of the I* members does not like it?" Other standards organizations are forced to make choices as they don't have time to wait until whenever the I* wants to wake up; often those involve using perhaps the wrong protocols (we have as clear cut a case as we are ever going to have here with 4285). There are many things you could have done if you wanted to help here. You might have sent an intent to decline a few weeks ago or better yet, you might have posted the next steps after the Prague meeting. If you really want to help, at least now, please schedule the BoF and make suggestions on how to build support for the work (we have more than a month before the Chicago meeting). Otherwise, it might be worthwhile to remove the IESG note in 4285. best regards, Lakshminath On 6/11/2007 3:25 PM, Sam Hartman wrote: > > > Regretfully, I have chosen to decline to sponsor the ifare bof for > Chicago. > > I think there is a lot of interest. However I don't think we have > come far enough in working with people who disagree with the ifare > proposal or who don't see the value for a productive second BOF. > Remember that if this second BOF doesn't get us the face to face time > we need to get a charter, our options are very limited. Proposals are > given at most two BOFs. > > According to the MIP6 chairs this effort has received little traction > in the MIP6 working group. In order to use the current problem and > applicability statement you would need to show significant interest > from the MIP6 working group. > > > Also, there has been rather limited discussion on the BOF list. > > I'd be happy to meet with proponents of this work in Chicago and > discuss how we can try and build the necessary support for a second > BOF. > > Sam Hartman > Security Area Director > > From owner-ietf-ipsec-failover Tue Jun 12 07:11:07 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5CEB7g7025238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 07:11:07 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5CEB7dU025237; Tue, 12 Jun 2007 07:11:07 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5CEB5tv025228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 12 Jun 2007 07:11:06 -0700 (MST) (envelope-from narten@us.ibm.com) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l5CEB2QN026173 for ; Tue, 12 Jun 2007 10:11:02 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l5CEB2aQ544846 for ; Tue, 12 Jun 2007 10:11:02 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l5CEB13x016529 for ; Tue, 12 Jun 2007 10:11:02 -0400 Received: from cichlid.raleigh.ibm.com (wecm-9-67-189-192.wecm.ibm.com [9.67.189.192]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l5CEB0Ya016380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 10:11:01 -0400 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id l5CEArEb012556; Tue, 12 Jun 2007 10:10:57 -0400 Message-Id: <200706121410.l5CEArEb012556@cichlid.raleigh.ibm.com> To: Lakshminath Dondeti cc: Sam Hartman , saag@mit.edu, ietf-ipsec-failover@vpnc.org Subject: Re: [saag] Declining the ifare bof for Chicago In-reply-to: <466DFCF8.8070305@qualcomm.com> References: <466DFCF8.8070305@qualcomm.com> Comments: In-reply-to Lakshminath Dondeti message dated "Mon, 11 Jun 2007 18:55:04 -0700." Date: Tue, 12 Jun 2007 10:10:53 -0400 From: Thomas Narten Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I don't understand your line of reasoning for turning away this work. Actually, I thought Sam's note was quite clear. And I applaud his willingness to say no, if the effort isn't ready for another BOF. Speaking as a former AD, it can be a very tough call to say yes/no to a BOF. Unfortunately, there is often interest, but interest is most definitely not enough. There needs to be more than interest. There needs to be a reasonable chance of a positive, forward-moving outcome. But in my experience, it is often the case with 2nd BOF requests that substantative issues have been raised already (on the list or in a previous BOF), but have not subsequently been adequately addressed by the BOF proponents. In such cases, another BOF will more-or-less just rehash what is already known, with no change in the overall status. It is the AD's job to judge whether that is likely to happen (in which case "no" is the right answer). For a second BOF, a real danger with allowing it to go forward is that it raises false expectations on where things are heading. There is a semi-written rule that says "no more than 2 BOFs". Thus, the second BOF needs to lead to a WG or an end of the effort. Once the second BOF has happened, there is (too often) an expectation that a WG will be formed. > You note that there is a lot of interest, and I know that there has only > been one person who disagrees with the IFARE proposal (perhaps I* > members' opinions are afforded special status?). Yes, I* opinions are afforded special status. They are our chosen leadership, and with leadership comes responsibility. Responsibility to be sure that if the work goes forward, it is well scoped, has a reasonable likelyhood of success, etc. And please remember, the IETF is a meritocracy. So please don't raise the "I* has special status" issue as if it were some kind of unfair or biased way of doing things. > If you really want to help, at least now, please schedule the BoF and > make suggestions on how to build support for the work (we have more than > a month before the Chicago meeting). Otherwise, it might be worthwhile > to remove the IESG note in 4285. I'd suggest you read (or reread) draft-narten-successful-bof-02.txt. It is the BOF proponent's job to build support for an effort. If they cannot do so, that (for better or worse) says something about the importance/interest in the work. And note that "support" means not just finding those in favor of an effort, but getting those opposed to the effort (as currently scoped) to be satisfied by rescoping the effort or addressing their concerns (and again, there is a judgement here). I.e., there needs to be a sufficient degree of consensus on having the work go forward (with an agreed upon scope, etc.). Thomas From owner-ietf-ipsec-failover Tue Jun 12 07:52:55 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5CEqtPf028129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 07:52:55 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5CEqtFs028128; Tue, 12 Jun 2007 07:52:55 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from carter-zimmerman.suchdamage.org (m1f1ffa48.tmodns.net [72.250.31.31]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5CEqkPe028102 for ; Tue, 12 Jun 2007 07:52:51 -0700 (MST) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C859848D6; Tue, 12 Jun 2007 09:53:07 -0400 (EDT) From: Sam Hartman To: Lakshminath Dondeti Cc: ietf-ipsec-failover@vpnc.org, saag@mit.edu Subject: Re: Declining the ifare bof for Chicago References: <466DFCF8.8070305@qualcomm.com> Date: Tue, 12 Jun 2007 09:53:07 -0400 In-Reply-To: <466DFCF8.8070305@qualcomm.com> (Lakshminath Dondeti's message of "Mon, 11 Jun 2007 18:55:04 -0700") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >>>>> "Lakshminath" == Lakshminath Dondeti writes: Lakshminath> Sam, I don't understand your line of reasoning for Lakshminath> turning away this work. You note that there is a lot Lakshminath> of interest, and I know that there has only been one Lakshminath> person who disagrees with the IFARE proposal (perhaps Lakshminath> I* members' opinions are afforded special status?). I don't think that claiming ekr is the only one who disagreed is a fair characterization of the bof. Lakshminath> There was also some confusion at the last face to Lakshminath> face meeting; some of it was in fact clarified at the Lakshminath> meeting (e.g., Paging issues were raised by folks who Lakshminath> thought gateway initiated operation was being Lakshminath> proposed -- it was not -- and Tero from the audience Lakshminath> clarified that it is a non-issue as the proposal on Lakshminath> the table was only talking about client-initiated Lakshminath> operation) and quite a bit of it in offline Lakshminath> exchanges, I am told. I don't think this confusion has been cleared up. Traffic on the bof list after the meeting brought up the paging issue again. There is a huge difference between asserting a solution to someone's objection and actually coming to closure with them. I believe that the proponents of the BOF have done the former and in some cases claimed the ladder. I understand your frustration; several of the people you have tried to engage have not found the work compelling enough to engage with you. Lakshminath> Given a lot of interest, one objection, and some Lakshminath> confusion, what makes you draw the conclusion that Lakshminath> the second BoF will not be productive? Your problem statement hinges heavily on the use of the technology for MIP. However you have not convinced the working group that they are interested in your proposal. I think that you must either come up with a compelling problem statement that does not discuss MIP or get them on board. I understand that you may have concerns about their current approach. You should feel free to bring those concerns forward in the MIP6 working group. Alternatively you can bring those concerns up with Tim or I or Jari. Lakshminath> What happens when we are in the mode of saying "it is Lakshminath> not really clear to us," "we need Lakshminath> to support this work" or "one of the I* members does Lakshminath> not like it?" Other standards organizations are Lakshminath> forced to make choices as they don't have time to Lakshminath> wait until whenever the I* wants to wake up; often Lakshminath> those involve using perhaps the wrong protocols (we Lakshminath> have as clear cut a case as we are ever going to have Lakshminath> here with 4285). The IETF operates by consensus. The IESG and IAB cannot force the MIP6 working group to adopt a particular solution. We can block solutions with certain classes of problem under some circumstances. We do have significant latitude in whether to charter work and I believe it entirely reasonable for me to insist that when a problem statement points to a consumer in the IETF, that consumer be interested in the solution. Lakshminath> There are many things you could have done if you Lakshminath> wanted to help here. You might have sent an intent to Lakshminath> decline a few weeks ago I did send a rather late message to the BOF chairs indicating that I had serous concerns. You are correct that I have been rather busy lately and that I could have done a much better job. Lakshminath> or better yet, you might have Lakshminath> posted the next steps after the Prague meeting. I did talk to the chairs about next steps. You are correct that making sure that conversation got summarized to the list would have been a good idea. From owner-ietf-ipsec-failover Tue Jun 12 09:53:05 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5CGr5OR036896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 09:53:05 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5CGr5i4036895; Tue, 12 Jun 2007 09:53:05 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5CGr1SQ036888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Jun 2007 09:53:04 -0700 (MST) (envelope-from aboba@internaut.com) Received: from c-24-16-66-58.hsd1.mn.comcast.net ([24.16.66.58] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.63) (envelope-from ) id 1Hy9bz-000GPD-2E; Tue, 12 Jun 2007 12:52:55 -0400 Received: by internaut.com (Postfix, from userid 1000) id 02A257099A; Tue, 12 Jun 2007 09:52:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id E6B941A689; Tue, 12 Jun 2007 09:52:53 -0700 (PDT) X-MHO-User: U2FsdGVkX194KUz8SMI+AJh5iyudXVZc X-MHO-User: U2FsdGVkX18V022VWQrdtpzeIIdTnwu/ X-MHO-User: U2FsdGVkX19aY9hIJ37ZdjwrUHSXpSIg X-MHO-User: U2FsdGVkX1/2DGw1tJLrwotX8vuJr59Z X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.16.66.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX190NMSleEWFm+xoewOmPzlh Date: Tue, 12 Jun 2007 09:52:53 -0700 (PDT) From: Bernard Aboba To: Thomas Narten cc: Lakshminath Dondeti , saag@mit.edu, Sam Hartman , ietf-ipsec-failover@vpnc.org Subject: Re: [saag] Declining the ifare bof for Chicago In-Reply-To: <200706121410.l5CEArEb012556@cichlid.raleigh.ibm.com> Message-ID: References: <466DFCF8.8070305@qualcomm.com> <200706121410.l5CEArEb012556@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: If we are going to have a more general discussion of the BOF process, I'd suggest that this would be better accomodated on the IETF list. On Tue, 12 Jun 2007, Thomas Narten wrote: > > I don't understand your line of reasoning for turning away this > work. > > Actually, I thought Sam's note was quite clear. And I applaud his > willingness to say no, if the effort isn't ready for another BOF. > > Speaking as a former AD, it can be a very tough call to say yes/no to > a BOF. Unfortunately, there is often interest, but interest is most > definitely not enough. There needs to be more than interest. There > needs to be a reasonable chance of a positive, forward-moving > outcome. But in my experience, it is often the case with 2nd BOF > requests that substantative issues have been raised already (on the > list or in a previous BOF), but have not subsequently been adequately > addressed by the BOF proponents. In such cases, another BOF will > more-or-less just rehash what is already known, with no change in the > overall status. It is the AD's job to judge whether that is likely to > happen (in which case "no" is the right answer). > > For a second BOF, a real danger with allowing it to go forward is that > it raises false expectations on where things are heading. There is a > semi-written rule that says "no more than 2 BOFs". Thus, the second > BOF needs to lead to a WG or an end of the effort. Once the second BOF > has happened, there is (too often) an expectation that a WG will be > formed. > > > You note that there is a lot of interest, and I know that there has only > > been one person who disagrees with the IFARE proposal (perhaps I* > > members' opinions are afforded special status?). > > Yes, I* opinions are afforded special status. They are our chosen > leadership, and with leadership comes responsibility. Responsibility > to be sure that if the work goes forward, it is well scoped, has a > reasonable likelyhood of success, etc. And please remember, the IETF > is a meritocracy. So please don't raise the "I* has special status" > issue as if it were some kind of unfair or biased way of doing things. > > > If you really want to help, at least now, please schedule the BoF and > > make suggestions on how to build support for the work (we have more than > > a month before the Chicago meeting). Otherwise, it might be worthwhile > > to remove the IESG note in 4285. > > I'd suggest you read (or reread) draft-narten-successful-bof-02.txt. > > It is the BOF proponent's job to build support for an effort. If they > cannot do so, that (for better or worse) says something about the > importance/interest in the work. And note that "support" means not > just finding those in favor of an effort, but getting those opposed to > the effort (as currently scoped) to be satisfied by rescoping the > effort or addressing their concerns (and again, there is a judgement > here). I.e., there needs to be a sufficient degree of consensus on > having the work go forward (with an agreed upon scope, etc.). > > Thomas > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag > From owner-ietf-ipsec-failover Tue Jun 12 10:56:06 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5CHu6WX041480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 10:56:06 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5CHu699041479; Tue, 12 Jun 2007 10:56:06 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from [10.20.30.108] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5CHtjiT041458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 10:55:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <466DFCF8.8070305@qualcomm.com> <200706121410.l5CEArEb012556@cichlid.raleigh.ibm.com> Date: Tue, 12 Jun 2007 10:55:41 -0700 To: Bernard Aboba , Thomas Narten From: Paul Hoffman Subject: Re: [saag] Declining the ifare bof for Chicago Cc: Lakshminath Dondeti , saag@mit.edu, Sam Hartman , ietf-ipsec-failover@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 9:52 AM -0700 6/12/07, Bernard Aboba wrote: >If we are going to have a more general discussion of the BOF process, I'd >suggest that this would be better accomodated on the IETF list. Yes, please. It would be good to keep using this list for the technical work that no longer has a BoF behind it but can hopefully still be discussed. --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsec-failover Tue Jun 12 11:03:21 2007 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5CI3L46041941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 11:03:21 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l5CI3LhG041940; Tue, 12 Jun 2007 11:03:21 -0700 (MST) (envelope-from owner-ietf-ipsec-failover@mail.vpnc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ipsec-failover@mail.vpnc.org using -f Received: from carter-zimmerman.suchdamage.org ([192.42.249.122]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5CI3JQj041925; Tue, 12 Jun 2007 11:03:20 -0700 (MST) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 46AF048CE; Tue, 12 Jun 2007 14:03:19 -0400 (EDT) From: Sam Hartman To: Paul Hoffman Cc: Bernard Aboba , Thomas Narten , saag@mit.edu, Lakshminath Dondeti , ietf-ipsec-failover@vpnc.org Subject: Re: [saag] Declining the ifare bof for Chicago References: <466DFCF8.8070305@qualcomm.com> <200706121410.l5CEArEb012556@cichlid.raleigh.ibm.com> Date: Tue, 12 Jun 2007 14:03:19 -0400 In-Reply-To: (Paul Hoffman's message of "Tue, 12 Jun 2007 10:55:41 -0700") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-ipsec-failover@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: