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 S