From yaronf.ietf@gmail.com Sat Dec 1 02:32:06 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD8A21F85D1 for ; Sat, 1 Dec 2012 02:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4WG0ul-EQiM for ; Sat, 1 Dec 2012 02:32:05 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id F1F8921F855E for ; Sat, 1 Dec 2012 02:32:04 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so579687eaa.31 for ; Sat, 01 Dec 2012 02:32:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=13GhM+hF8k6sL0xAwQDDCR8EcCe6ffX2DVu+oqo43Ac=; b=FEhutxeNslgsC90Pn+ev8QL8esHPeir//6UoeLVczH5oXpU/LFb+CS+AXKw7TOYNwl 3bX4EZCPupAQPniyX2rSrcHnamid04h3w58myiX6nLy117fL+qmUPsWY5fjNk4cmL0Wg +IPEeBxTIcmzUwAiJfpkp9kEvaYeZRN6gCY/zbtWmsyf0f9xetOmX/0ZAJG5qOoIM2Oz YPLYr5Mbk3x+n/1IxC2nNwV1xtWGjEKTl4EB9ZdbEVAYI3+N0QCbOmrgVYuKOCd10o2o U6bChed1KzdhZC/NV5gmklBgo41VyuXTaaM2TozMlFqHBlnlKVkQI+d/Hybv1AtBX+Fp fdzg== Received: by 10.14.209.193 with SMTP id s41mr14893156eeo.9.1354357924192; Sat, 01 Dec 2012 02:32:04 -0800 (PST) Received: from [10.0.0.3] (bzq-79-183-164-29.red.bezeqint.net. [79.183.164.29]) by mx.google.com with ESMTPS id f49sm16446702eep.12.2012.12.01.02.31.51 (version=SSLv3 cipher=OTHER); Sat, 01 Dec 2012 02:32:03 -0800 (PST) Message-ID: <50B9DC95.80202@gmail.com> Date: Sat, 01 Dec 2012 12:31:49 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Scott Fluhrer (sfluhrer)" References: <50B8A287.9090509@secunet.com> <074557eff2f722f10198aac4fb2f8d9c.squirrel@www.trepanning.net> <4613980CFC78314ABFD7F85CC30277210EDCE571@IL-EX10.ad.checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Johannes Merkle , Manfred Lochter , Yoav Nir , Dan Harkins , IPsecme WG , "rfc-ise@rfc-editor.org" , "Sean P. Turner" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 10:32:06 -0000 Actually, I think we have it wrong. There is no reason for a *valid* peer to send an incorrect KE. And IKEv2 already protects against a MITM doing such a thing. As we all know, the protocol assumes that messages #3 and #4 can be observed by an attacker, and protects against malicious changes to any of the 4 messages, including the KE value. In other words, I would say this is a QA-level test that MAY be performed by the sender. Not one that MUST be performed by the recipient. By the way, there are related protocols that need this test for their security and do include it: SPSK, and my own RFC 6631 (IKEv2 with PACE). See e.g. https://tools.ietf.org/html/rfc6631#section-3.4. Thanks, Yaron On 12/01/2012 12:00 AM, Scott Fluhrer (sfluhrer) wrote: > With ECDH, there are two separate EC points that are output by the algorithm: > > - There's the public value xG (where x is our secret); this is passed in the KE payload > - There's the shared secret value xyG (where x is our shared secret, and y is the peer's secret); this is used in the key derivation function. > > What RFC5903 says is: > - The public value xG will be expressed as explicit x, y coordinates. > - The shared secret value xyG (that is, the value we give to the sk generation function) will be only the x coordinate; the y coordinate will not be used. > > Yes, this implies that doing point compression on the shared secret value doesn't make much sense (as point compression discards all but one bit of y -- the format that RFC5903 chooses already discards all the bits of y). However, the argument about point compression was never about the shared secret value; instead, it was about the repesentation that appeared in the KE payload (that is, the one that is specified to have both the x and y coordinates). > > As for Dan's question, it was about whether we should validate the public value we get from the peer, well, the public value does have explicit x and y coordinates, and so it makes sense to check them. > > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir > Sent: Friday, November 30, 2012 4:39 PM > To: Johannes Merkle > Cc: IPsecme WG; Manfred Lochter; Sean P. Turner; Dan Harkins; rfc-ise@rfc-editor.org > Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange > > Hi Johannes, > > Dan't question made me realise something I hadn't noticed before. > > In section 2.3, the draft says: > For the encoding of the key exchange payload and the derivation of > the shared secret, the methods specified in [RFC5903] are adopted. > > In an ECP key exchange in IKEv2, the Diffie-Hellman public value > passed in a KE payload consists of two components, x and y, > > However, according to RFC 5903: > The Diffie-Hellman shared secret value consists of the x value of > the Diffie-Hellman common value. > > In fact RFC 5903 replaced 4753 just to say that the encoding consists only of x, not both x and y. > > This also relates to Dan't question. If the y value is missing, what is there to verify? > > Yoav > > On Nov 30, 2012, at 7:57 PM, Dan Harkins wrote: > >> >> Hi Johannes, >> >> On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote: >>> We have submitted a new revision of the Internet Draft on Using the >>> ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange >>> https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ >>> >>> Since there was considerable objection to the point compression >>> method in the WG, we have removed this option altogether and define >>> only the uncompressed KE payload format, which is in full accordance >>> with RFC 5903. >>> >>> >>> Any feedback is welcome. >> >> I see that there is a requirement that an implementation MUST verify >> that the D-H common value is not the point-at-infinity. Do you think >> there should also be a requirement that an implementation MUST verify >> that the x- and y-coordinates received from a peer satisfy the >> equation of the negotiated curve (and abort the exchange if not)? >> >> regards, >> >> Dan. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From sfluhrer@cisco.com Sat Dec 1 10:44:37 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CFB21E8039 for ; Sat, 1 Dec 2012 10:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTyVUi67EUq7 for ; Sat, 1 Dec 2012 10:44:37 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 86F5321E8095 for ; Sat, 1 Dec 2012 10:44:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5721; q=dns/txt; s=iport; t=1354387476; x=1355597076; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PTol6r9SPWstk6cwJAkHlY6fiC2E3VHk4jkdovn1hj4=; b=RQoa3AvKWna+QznvUTmA/gkm5+rS+lAYDOiXyEDthACXiyFRksj+a9Gp jtEbZjloscz0J43uk8+lAGZee7l0c53hafB4ZxNrCSoxxqA66C38GWjIC QUfDyGFPjq0L950mhA94589TGEp7h0Z7MR6qqqrsGMLNUlpLd7XcaYTUQ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOROulCtJV2c/2dsb2JhbABEwAcWc4IeAQEBAwEBAQE3NAsFBwQCAQgRBAEBAQoUCQchBgsUCQgCBA4FCId2AwkGDLRNDYlQBItXaYNgYQOST4FdjQyFEIJygWMCBRkGGA X-IronPort-AV: E=McAfee;i="5400,1158,6913"; a="148319110" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 01 Dec 2012 18:44:34 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qB1IiYOm005841 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 1 Dec 2012 18:44:34 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.203]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Sat, 1 Dec 2012 12:44:34 -0600 From: "Scott Fluhrer (sfluhrer)" To: Yaron Sheffer Thread-Topic: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange Thread-Index: AQHNzvPr3RuFFj57U0u04fPTF6DjPpgDDvyAgAA98gD//55asIABOYmAgAAjF5A= Date: Sat, 1 Dec 2012 18:44:34 +0000 Message-ID: References: <50B8A287.9090509@secunet.com> <074557eff2f722f10198aac4fb2f8d9c.squirrel@www.trepanning.net> <4613980CFC78314ABFD7F85CC30277210EDCE571@IL-EX10.ad.checkpoint.com> <50B9DC95.80202@gmail.com> In-Reply-To: <50B9DC95.80202@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Johannes Merkle , Manfred Lochter , Yoav Nir , Dan Harkins , IPsecme WG , "rfc-ise@rfc-editor.org" , "Sean P. Turner" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 18:44:38 -0000 I would humbly disagree. A peer might try to send us an invalid KE, with a= bogus point that acts as if it were of small order with our implementation= ; let us call this bogus point P, and its small order n. We would then gen= erate sk's based on the point (e mod n)P (where e is the value of our ECDH = secret); because n is small, that allows the attacker to recover the value = (e mod n). If we reuse the same ECDH secret for multiple exchanges (which is normally = safe), this allows someone who controls some of the peers we talk to to rec= over the secret value for exchanges he does not control; this is not good. Hence, we need to either mandate checking the point we receive, or forbid E= CDH secret reuse. -----Original Message----- From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]=20 Sent: Saturday, December 01, 2012 5:32 AM To: Scott Fluhrer (sfluhrer) Cc: Yoav Nir; Johannes Merkle; IPsecme WG; Manfred Lochter; Sean P. Turner;= Dan Harkins; rfc-ise@rfc-editor.org Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Ex= change Actually, I think we have it wrong. There is no reason for a *valid* peer t= o send an incorrect KE. And IKEv2 already protects against a MITM doing suc= h a thing. As we all know, the protocol assumes that messages #3 and #4 can be observed by an attacker, and protects against malicious ch= anges to any of the 4 messages, including the KE value. In other words, I would say this is a QA-level test that MAY be performed b= y the sender. Not one that MUST be performed by the recipient. By the way, there are related protocols that need this test for their secur= ity and do include it: SPSK, and my own RFC 6631 (IKEv2 with PACE).=20 See e.g. https://tools.ietf.org/html/rfc6631#section-3.4. Thanks, Yaron On 12/01/2012 12:00 AM, Scott Fluhrer (sfluhrer) wrote: > With ECDH, there are two separate EC points that are output by the algori= thm: > > - There's the public value xG (where x is our secret); this is passed=20 > in the KE payload > - There's the shared secret value xyG (where x is our shared secret, and = y is the peer's secret); this is used in the key derivation function. > > What RFC5903 says is: > - The public value xG will be expressed as explicit x, y coordinates. > - The shared secret value xyG (that is, the value we give to the sk gener= ation function) will be only the x coordinate; the y coordinate will not be= used. > > Yes, this implies that doing point compression on the shared secret value= doesn't make much sense (as point compression discards all but one bit of = y -- the format that RFC5903 chooses already discards all the bits of y). = However, the argument about point compression was never about the shared se= cret value; instead, it was about the repesentation that appeared in the KE= payload (that is, the one that is specified to have both the x and y coord= inates). > > As for Dan's question, it was about whether we should validate the public= value we get from the peer, well, the public value does have explicit x an= d y coordinates, and so it makes sense to check them. > > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf=20 > Of Yoav Nir > Sent: Friday, November 30, 2012 4:39 PM > To: Johannes Merkle > Cc: IPsecme WG; Manfred Lochter; Sean P. Turner; Dan Harkins;=20 > rfc-ise@rfc-editor.org > Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2=20 > Key Exchange > > Hi Johannes, > > Dan't question made me realise something I hadn't noticed before. > > In section 2.3, the draft says: > For the encoding of the key exchange payload and the derivation of > the shared secret, the methods specified in [RFC5903] are adopted. > > In an ECP key exchange in IKEv2, the Diffie-Hellman public value > passed in a KE payload consists of two components, x and y, > > However, according to RFC 5903: > The Diffie-Hellman shared secret value consists of the x value of > the Diffie-Hellman common value. > > In fact RFC 5903 replaced 4753 just to say that the encoding consists onl= y of x, not both x and y. > > This also relates to Dan't question. If the y value is missing, what is t= here to verify? > > Yoav > > On Nov 30, 2012, at 7:57 PM, Dan Harkins wrote: > >> >> Hi Johannes, >> >> On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote: >>> We have submitted a new revision of the Internet Draft on Using the=20 >>> ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange=20 >>> https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ >>> >>> Since there was considerable objection to the point compression=20 >>> method in the WG, we have removed this option altogether and define=20 >>> only the uncompressed KE payload format, which is in full accordance=20 >>> with RFC 5903. >>> >>> >>> Any feedback is welcome. >> >> I see that there is a requirement that an implementation MUST=20 >> verify that the D-H common value is not the point-at-infinity. Do you=20 >> think there should also be a requirement that an implementation MUST=20 >> verify that the x- and y-coordinates received from a peer satisfy the=20 >> equation of the negotiated curve (and abort the exchange if not)? >> >> regards, >> >> Dan. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From yaronf.ietf@gmail.com Sat Dec 1 11:29:06 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF05E21F8D97 for ; Sat, 1 Dec 2012 11:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNQ6g3ceXd1k for ; Sat, 1 Dec 2012 11:29:06 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id B272721F8D95 for ; Sat, 1 Dec 2012 11:29:05 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so1006125eek.31 for ; Sat, 01 Dec 2012 11:29:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=YECpbrUc3o+QXzQCPaCzu+I3O8SS9oHxLf29VDSwcqU=; b=TBbsy1JmvcGav4SmPQZZY16283mf89oVmoj+FOFcCkc5JcLZ2hiGsGNgioKaHet7+a pY80isHH33yQCd6XEo9vU1R3UuLOOLTmGYIi0Nw6hOesVXMLYexBeiq3gp971Ad/55Fh uoPTHiVrZXYI0KcA2jHd1JrITq4lYLeDjxsCZCENkKWcracZhodBkzMxtu/E002olykR nQSmGMoAAoibzI/mIfXPqoyB7wIBIa5xp7OBEbCtlMWWn6h9inYDFkMGqoEYB5RZJ7XL 15kN1Kgp/Jlw1OKbRIkzKMiJWrkNNmHsAnHE4w5hlbWjXRmYIefXF54J5TMB0FN+lAaq eVpA== Received: by 10.14.208.137 with SMTP id q9mr18436843eeo.28.1354390143500; Sat, 01 Dec 2012 11:29:03 -0800 (PST) Received: from [10.0.0.3] (bzq-79-183-164-29.red.bezeqint.net. [79.183.164.29]) by mx.google.com with ESMTPS id 46sm19508608eeg.4.2012.12.01.11.28.51 (version=SSLv3 cipher=OTHER); Sat, 01 Dec 2012 11:29:02 -0800 (PST) Message-ID: <50BA5A70.6030808@gmail.com> Date: Sat, 01 Dec 2012 21:28:48 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Scott Fluhrer (sfluhrer)" References: <50B8A287.9090509@secunet.com> <074557eff2f722f10198aac4fb2f8d9c.squirrel@www.trepanning.net> <4613980CFC78314ABFD7F85CC30277210EDCE571@IL-EX10.ad.checkpoint.com> <50B9DC95.80202@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Johannes Merkle , Manfred Lochter , Yoav Nir , Dan Harkins , IPsecme WG , "rfc-ise@rfc-editor.org" , "Sean P. Turner" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 19:29:07 -0000 Hi Scott, OK, I see your point (no pun intended). Regarding ECDH secret reuse, can you please review http://tools.ietf.org/html/rfc5996#section-2.12. That section was supposed to cover the relevant security considerations. In fact I think your attack is alluded to in the paper we reference from that section (see Sec. 5, first paragraph). If this needs to become a MUST requirement for IKEv2 peers using ECDH, it needs to be spelled out and not left as an exercise to the reader. But we have to understand whether this is a general requirement, or it only applies to peers that are reusing ECDH private keys for multiple IKE sessions. Thanks, Yaron On 12/01/2012 08:44 PM, Scott Fluhrer (sfluhrer) wrote: > I would humbly disagree. A peer might try to send us an invalid KE, with a bogus point that acts as if it were of small order with our implementation; let us call this bogus point P, and its small order n. We would then generate sk's based on the point (e mod n)P (where e is the value of our ECDH secret); because n is small, that allows the attacker to recover the value (e mod n). > > If we reuse the same ECDH secret for multiple exchanges (which is normally safe), this allows someone who controls some of the peers we talk to to recover the secret value for exchanges he does not control; this is not good. > > Hence, we need to either mandate checking the point we receive, or forbid ECDH secret reuse. > > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > Sent: Saturday, December 01, 2012 5:32 AM > To: Scott Fluhrer (sfluhrer) > Cc: Yoav Nir; Johannes Merkle; IPsecme WG; Manfred Lochter; Sean P. Turner; Dan Harkins; rfc-ise@rfc-editor.org > Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange > > Actually, I think we have it wrong. There is no reason for a *valid* peer to send an incorrect KE. And IKEv2 already protects against a MITM doing such a thing. As we all know, the protocol assumes that messages > #3 and #4 can be observed by an attacker, and protects against malicious changes to any of the 4 messages, including the KE value. > > In other words, I would say this is a QA-level test that MAY be performed by the sender. Not one that MUST be performed by the recipient. > > By the way, there are related protocols that need this test for their security and do include it: SPSK, and my own RFC 6631 (IKEv2 with PACE). > See e.g. https://tools.ietf.org/html/rfc6631#section-3.4. > > Thanks, > Yaron > > > On 12/01/2012 12:00 AM, Scott Fluhrer (sfluhrer) wrote: >> With ECDH, there are two separate EC points that are output by the algorithm: >> >> - There's the public value xG (where x is our secret); this is passed >> in the KE payload >> - There's the shared secret value xyG (where x is our shared secret, and y is the peer's secret); this is used in the key derivation function. >> >> What RFC5903 says is: >> - The public value xG will be expressed as explicit x, y coordinates. >> - The shared secret value xyG (that is, the value we give to the sk generation function) will be only the x coordinate; the y coordinate will not be used. >> >> Yes, this implies that doing point compression on the shared secret value doesn't make much sense (as point compression discards all but one bit of y -- the format that RFC5903 chooses already discards all the bits of y). However, the argument about point compression was never about the shared secret value; instead, it was about the repesentation that appeared in the KE payload (that is, the one that is specified to have both the x and y coordinates). >> >> As for Dan's question, it was about whether we should validate the public value we get from the peer, well, the public value does have explicit x and y coordinates, and so it makes sense to check them. >> >> >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of Yoav Nir >> Sent: Friday, November 30, 2012 4:39 PM >> To: Johannes Merkle >> Cc: IPsecme WG; Manfred Lochter; Sean P. Turner; Dan Harkins; >> rfc-ise@rfc-editor.org >> Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 >> Key Exchange >> >> Hi Johannes, >> >> Dan't question made me realise something I hadn't noticed before. >> >> In section 2.3, the draft says: >> For the encoding of the key exchange payload and the derivation of >> the shared secret, the methods specified in [RFC5903] are adopted. >> >> In an ECP key exchange in IKEv2, the Diffie-Hellman public value >> passed in a KE payload consists of two components, x and y, >> >> However, according to RFC 5903: >> The Diffie-Hellman shared secret value consists of the x value of >> the Diffie-Hellman common value. >> >> In fact RFC 5903 replaced 4753 just to say that the encoding consists only of x, not both x and y. >> >> This also relates to Dan't question. If the y value is missing, what is there to verify? >> >> Yoav >> >> On Nov 30, 2012, at 7:57 PM, Dan Harkins wrote: >> >>> >>> Hi Johannes, >>> >>> On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote: >>>> We have submitted a new revision of the Internet Draft on Using the >>>> ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange >>>> https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ >>>> >>>> Since there was considerable objection to the point compression >>>> method in the WG, we have removed this option altogether and define >>>> only the uncompressed KE payload format, which is in full accordance >>>> with RFC 5903. >>>> >>>> >>>> Any feedback is welcome. >>> >>> I see that there is a requirement that an implementation MUST >>> verify that the D-H common value is not the point-at-infinity. Do you >>> think there should also be a requirement that an implementation MUST >>> verify that the x- and y-coordinates received from a peer satisfy the >>> equation of the negotiated curve (and abort the exchange if not)? >>> >>> regards, >>> >>> Dan. >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> From Johannes.Merkle@secunet.com Mon Dec 3 02:52:23 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E0021F85E2 for ; Mon, 3 Dec 2012 02:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HOYeeFICQfN for ; Mon, 3 Dec 2012 02:52:22 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB3D21F85D1 for ; Mon, 3 Dec 2012 02:52:22 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 61B431A007F; Mon, 3 Dec 2012 11:52:09 +0100 (CET) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id E748A1A0079; Mon, 3 Dec 2012 11:52:06 +0100 (CET) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Dec 2012 11:52:17 +0100 Message-ID: <50BC8460.9030808@secunet.com> Date: Mon, 03 Dec 2012 11:52:16 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Yaron Sheffer References: <50B8A287.9090509@secunet.com> <074557eff2f722f10198aac4fb2f8d9c.squirrel@www.trepanning.net> <4613980CFC78314ABFD7F85CC30277210EDCE571@IL-EX10.ad.checkpoint.com> <50B9DC95.80202@gmail.com> <50BA5A70.6030808@gmail.com> In-Reply-To: <50BA5A70.6030808@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Dec 2012 10:52:17.0280 (UTC) FILETIME=[42D44000:01CDD144] Cc: Manfred Lochter , Yoav Nir , Dan Harkins , IPsecme WG , "rfc-ise@rfc-editor.org" , "Scott Fluhrer \(sfluhrer\)" , "Sean P. Turner" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 10:52:23 -0000 Hi Yaron, > > OK, I see your point (no pun intended). Regarding ECDH secret reuse, can you please review > http://tools.ietf.org/html/rfc5996#section-2.12. That section was supposed to cover the relevant security > considerations. In fact I think your attack is alluded to in the paper we reference from that section (see Sec. 5, first > paragraph). > I agree with you that this is a general issue that should be addressed generally. Yet, as a precaution, I could also include such a requirement in the current draft. > If this needs to become a MUST requirement for IKEv2 peers using ECDH, it needs to be spelled out and not left as an > exercise to the reader. But we have to understand whether this is a general requirement, or it only applies to peers > that are reusing ECDH private keys for multiple IKE sessions. > If the ECDH key is chosen at random for each negotiation, then the attacker can only gain knowledge on the shared secret and private key of the current negotiation. There is no other secret information involved that could be learned. Johannes From kivinen@iki.fi Mon Dec 3 04:48:27 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A99B21F8715 for ; Mon, 3 Dec 2012 04:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbM0QuQu714G for ; Mon, 3 Dec 2012 04:48:26 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4C93C21F870D for ; Mon, 3 Dec 2012 04:48:25 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qB3CluCn024163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Dec 2012 14:47:56 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qB3Clt7B026301; Mon, 3 Dec 2012 14:47:55 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20668.40826.934312.605279@fireball.kivinen.iki.fi> Date: Mon, 3 Dec 2012 14:47:54 +0200 From: Tero Kivinen To: Johannes Merkle In-Reply-To: <50BC8460.9030808@secunet.com> References: <50B8A287.9090509@secunet.com> <074557eff2f722f10198aac4fb2f8d9c.squirrel@www.trepanning.net> <4613980CFC78314ABFD7F85CC30277210EDCE571@IL-EX10.ad.checkpoint.com> <50B9DC95.80202@gmail.com> <50BA5A70.6030808@gmail.com> <50BC8460.9030808@secunet.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 12 min Cc: Manfred Lochter , Yoav Nir , Dan Harkins , IPsecme WG , "rfc-ise@rfc-editor.org" , "Scott Fluhrer \(sfluhrer\)" , "Sean P. Turner" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 12:48:27 -0000 Johannes Merkle writes: > > OK, I see your point (no pun intended). Regarding ECDH secret > > reuse, can you please review > > http://tools.ietf.org/html/rfc5996#section-2.12. That section was > > supposed to cover the relevant security considerations. In fact I > > think your attack is alluded to in the paper we reference from > > that section (see Sec. 5, first paragraph). > > > > I agree with you that this is a general issue that should be > addressed generally. Yet, as a precaution, I could also include such > a requirement in the current draft. Looking at the ECDH problems there seems to be in specifications (i.e. what checks are needed, RFC5114 refering to wrong RFC (it should refer to 5903 not 4753) etc, it seems we need to do something for this. I do not think it is good idea to include this kind of things as errata. Also I do not think we should include generic ECDH processing rules in to the draft specifying some EC groups. I think it would be best to take the ECDH processing rules (mostly from 5903 but also add the checks if those are needed) and create new RFC that will update 5996. This document should not include any groups. Then the question is what to do to 5114. The 5114 points to the 4753 and there is the problem that 4753 was modified with errata. This means that 5114 is also affected by the same errata, meaning complient implementatation should follow the same errata, i.e. the same format that is defined in the 5903. We should have made that 5903 to include also the 2 other groups from the 5114, i.e. groups 25 and 26, and we really should have obsoleted ALL ECP groups (19-21, 25-26) and allocated new numbers for all of those. If that new document includes all ECDH processing rules, perhaps that can be made to update all previous ECDH RFCs, and it can say all ECDH curves use exactly same processing rules? -- kivinen@iki.fi From sfluhrer@cisco.com Mon Dec 3 06:27:54 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9E921F85CD for ; Mon, 3 Dec 2012 06:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Arbbr43SRsK for ; Mon, 3 Dec 2012 06:27:53 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id E54E721F85AA for ; Mon, 3 Dec 2012 06:27:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9848; q=dns/txt; s=iport; t=1354544873; x=1355754473; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XFRh0OrRSkmmw39o28OWvkX08kQILugNcHME1nJMnNY=; b=g+6dD7AYQHGVLNtSNq1zmLcgZ20BwYB8dKkSslYEn47R4PRdN6ADqaYD xbY8IJxsUKT9mvREbfO21s4kvhnHnbiX/m8SG1A/06SjuC+u/mYakQF0X eWmQeCTu+RY52vjWhY8Gz5bPqUis3OVVj1KT3K76gEHFukAy5Iht3P6bu 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKS1vFCtJXG8/2dsb2JhbABEwAAWc4IeAQEBBAEBATc0CwwEAgEIEQQBAQEKFAkHIQYLFAkIAgQOBQiHdgMPDLQ5DYlUi1dpg2BhA5JPgV2CcYobhRCCcoFjAgUZBhg X-IronPort-AV: E=McAfee;i="5400,1158,6914"; a="148770493" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 03 Dec 2012 14:27:52 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qB3ERqod020354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Dec 2012 14:27:52 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.203]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.001; Mon, 3 Dec 2012 08:27:51 -0600 From: "Scott Fluhrer (sfluhrer)" To: Yaron Sheffer Thread-Topic: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange Thread-Index: AQHNz/olcML1jJ9U4EC5RJIM/xfJWZgHG0cg Date: Mon, 3 Dec 2012 14:27:50 +0000 Message-ID: References: <50B8A287.9090509@secunet.com> <074557eff2f722f10198aac4fb2f8d9c.squirrel@www.trepanning.net> <4613980CFC78314ABFD7F85CC30277210EDCE571@IL-EX10.ad.checkpoint.com> <50B9DC95.80202@gmail.com> <50BA5A70.6030808@gmail.com> In-Reply-To: <50BA5A70.6030808@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Johannes Merkle , Manfred Lochter , Yoav Nir , Dan Harkins , IPsecme WG , "rfc-ise@rfc-editor.org" , "Sean P. Turner" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 14:27:54 -0000 As for http://tools.ietf.org/html/rfc5996#section-2.12, it's fine as far as= it goes, however (IMHO) it rather punts on what self-checks are actually n= eeded. It does refer to the Menezes and Ustaoglu paper, which is quite goo= d, however, it would be better if you spell out exactly what tests the impl= ementer would need to run for each IKE group. An implementation might have= problems determining from the paper what is appropriate; for example, grou= ps 22-24 would be considered "DSA groups" by the nomenclature of the paper = (see section 2.1); however nowhere in the IKE documents are they actually l= abeled as such. Here is a quick run-down: - Standard MODP groups (1, 2, 5, 14-18): informational leakage from a small= group attack is minimal (see section 2.2 of the paper); hence, the only ch= eck needed is a verification that the peer's public value r is in range (1 = < r < p-1) - MODP groups with small subgroups (22-24): there is some informational lea= kage from a small subgroup attack (see section 2.1 of the paper); hence, yo= u need to check both that the peer's public value is in range (1 < r < p-1)= and that r**q =3D 1 mod p (where q is the size of the subgroup) - EC groups; there is some informational leakage possible (see section 2.3)= ; hence, you need to check that the peer's public value is valid; that is, = it is not the point-at-infinity, and that the x and y parameters from the p= eer's public value satisfies the curve equation, that is, y**2 =3D x**3 + a= x + b mod p. Note that even though the paper specifically targets odd char= acteristic EC curves, their advice of checking the curve equation is equall= y applicable to even characteristic curves as well.=20 Now, as for whether checking the peer's public value ought to be a requirem= ent, even if you aren't reusing private keys, I would still say that it oug= ht to be. If we look at the ECDH point addition/doubling code, well, they = are designed to work correctly if you give them valid points (that is, poin= ts that are actually on the curve). If you just take bit patterns you rece= ived in a packet from the peer, and just give them to the EC routines, well= , there's no inherent requirement what might happen if the values don't hap= pen to be valid. If the implementation uses the standard textbook point ad= dition/doubling code, we can predict what will happen -- however, a specifi= c implementation might decide to do something different. Because of this (= and because checking is so cheap -- we're talking maybe 1% of the cost of t= he cost of doing the ECDH phase two), I would strongly urge anyone to do th= is check. -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= aron Sheffer Sent: Saturday, December 01, 2012 2:29 PM To: Scott Fluhrer (sfluhrer) Cc: Johannes Merkle; Manfred Lochter; Yoav Nir; Dan Harkins; IPsecme WG; rf= c-ise@rfc-editor.org; Sean P. Turner Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Ex= change Hi Scott, OK, I see your point (no pun intended). Regarding ECDH secret reuse, can yo= u please review http://tools.ietf.org/html/rfc5996#section-2.12. That secti= on was supposed to cover the relevant security considerations. In fact I th= ink your attack is alluded to in the paper we reference from that section (= see Sec. 5, first paragraph). If this needs to become a MUST requirement for IKEv2 peers using ECDH, it n= eeds to be spelled out and not left as an exercise to the reader.=20 But we have to understand whether this is a general requirement, or it only= applies to peers that are reusing ECDH private keys for multiple IKE sessi= ons. Thanks, Yaron On 12/01/2012 08:44 PM, Scott Fluhrer (sfluhrer) wrote: > I would humbly disagree. A peer might try to send us an invalid KE, with= a bogus point that acts as if it were of small order with our implementati= on; let us call this bogus point P, and its small order n. We would then g= enerate sk's based on the point (e mod n)P (where e is the value of our ECD= H secret); because n is small, that allows the attacker to recover the valu= e (e mod n). > > If we reuse the same ECDH secret for multiple exchanges (which is normall= y safe), this allows someone who controls some of the peers we talk to to r= ecover the secret value for exchanges he does not control; this is not good= . > > Hence, we need to either mandate checking the point we receive, or forbid= ECDH secret reuse. > > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > Sent: Saturday, December 01, 2012 5:32 AM > To: Scott Fluhrer (sfluhrer) > Cc: Yoav Nir; Johannes Merkle; IPsecme WG; Manfred Lochter; Sean P.=20 > Turner; Dan Harkins; rfc-ise@rfc-editor.org > Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2=20 > Key Exchange > > Actually, I think we have it wrong. There is no reason for a *valid*=20 > peer to send an incorrect KE. And IKEv2 already protects against a=20 > MITM doing such a thing. As we all know, the protocol assumes that=20 > messages > #3 and #4 can be observed by an attacker, and protects against malicious = changes to any of the 4 messages, including the KE value. > > In other words, I would say this is a QA-level test that MAY be performed= by the sender. Not one that MUST be performed by the recipient. > > By the way, there are related protocols that need this test for their sec= urity and do include it: SPSK, and my own RFC 6631 (IKEv2 with PACE). > See e.g. https://tools.ietf.org/html/rfc6631#section-3.4. > > Thanks, > Yaron > > > On 12/01/2012 12:00 AM, Scott Fluhrer (sfluhrer) wrote: >> With ECDH, there are two separate EC points that are output by the algor= ithm: >> >> - There's the public value xG (where x is our secret); this is passed=20 >> in the KE payload >> - There's the shared secret value xyG (where x is our shared secret, and= y is the peer's secret); this is used in the key derivation function. >> >> What RFC5903 says is: >> - The public value xG will be expressed as explicit x, y coordinates. >> - The shared secret value xyG (that is, the value we give to the sk gene= ration function) will be only the x coordinate; the y coordinate will not b= e used. >> >> Yes, this implies that doing point compression on the shared secret valu= e doesn't make much sense (as point compression discards all but one bit of= y -- the format that RFC5903 chooses already discards all the bits of y). = However, the argument about point compression was never about the shared s= ecret value; instead, it was about the repesentation that appeared in the K= E payload (that is, the one that is specified to have both the x and y coor= dinates). >> >> As for Dan's question, it was about whether we should validate the publi= c value we get from the peer, well, the public value does have explicit x a= nd y coordinates, and so it makes sense to check them. >> >> >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On=20 >> Behalf Of Yoav Nir >> Sent: Friday, November 30, 2012 4:39 PM >> To: Johannes Merkle >> Cc: IPsecme WG; Manfred Lochter; Sean P. Turner; Dan Harkins;=20 >> rfc-ise@rfc-editor.org >> Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2=20 >> Key Exchange >> >> Hi Johannes, >> >> Dan't question made me realise something I hadn't noticed before. >> >> In section 2.3, the draft says: >> For the encoding of the key exchange payload and the derivation of >> the shared secret, the methods specified in [RFC5903] are adopted. >> >> In an ECP key exchange in IKEv2, the Diffie-Hellman public value >> passed in a KE payload consists of two components, x and y, >> >> However, according to RFC 5903: >> The Diffie-Hellman shared secret value consists of the x value o= f >> the Diffie-Hellman common value. >> >> In fact RFC 5903 replaced 4753 just to say that the encoding consists on= ly of x, not both x and y. >> >> This also relates to Dan't question. If the y value is missing, what is = there to verify? >> >> Yoav >> >> On Nov 30, 2012, at 7:57 PM, Dan Harkins wrote: >> >>> >>> Hi Johannes, >>> >>> On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote: >>>> We have submitted a new revision of the Internet Draft on Using the=20 >>>> ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange=20 >>>> https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ >>>> >>>> Since there was considerable objection to the point compression=20 >>>> method in the WG, we have removed this option altogether and define=20 >>>> only the uncompressed KE payload format, which is in full=20 >>>> accordance with RFC 5903. >>>> >>>> >>>> Any feedback is welcome. >>> >>> I see that there is a requirement that an implementation MUST=20 >>> verify that the D-H common value is not the point-at-infinity. Do=20 >>> you think there should also be a requirement that an implementation=20 >>> MUST verify that the x- and y-coordinates received from a peer=20 >>> satisfy the equation of the negotiated curve (and abort the exchange if= not)? >>> >>> regards, >>> >>> Dan. >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From sfluhrer@cisco.com Mon Dec 3 06:39:21 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF4721F8741 for ; Mon, 3 Dec 2012 06:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id no7ppLYBPL7C for ; Mon, 3 Dec 2012 06:39:19 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8B84D21F8705 for ; Mon, 3 Dec 2012 06:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10709; q=dns/txt; s=iport; t=1354545559; x=1355755159; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Xs60uhhfp3wrf9+R8hlY6hVUZsG1XV4vjShyEhHrHDM=; b=Zmrd+vRoh1EXLG0L9qqtlyfbvHJhLbvRGDXw7f+5Rpmp6pm7DIApbpdT CqzM6CVANR2N5gixD8SV6nEPEIW3Ly0QxroNNwQ5dD6sdCTk9qXxE+i+v Ily3OtpeeuiMFZ/Ms27CKOao/GwqXZnsi/rqy70MXoFkqcnYsrf7LqX/b M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGa4vFCtJV2d/2dsb2JhbABEwAAWc4IeAQEBBAEBATc0CwwEAgEIEQQBAQEKFAkHIQYLFAkIAgQOBQiHdgMPDLRDDYlUi1dpg2BhA5JPgV2CcYobhRCCcoFjAgUZBhg X-IronPort-AV: E=McAfee;i="5400,1158,6914"; a="148736339" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 03 Dec 2012 14:39:19 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qB3EdIDe009592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Dec 2012 14:39:18 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.203]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.001; Mon, 3 Dec 2012 08:39:18 -0600 From: "Scott Fluhrer (sfluhrer)" To: Yaron Sheffer Thread-Topic: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange Thread-Index: AQHN0WJnhnBcuawuSEyrEJrrx0oCJpgHJF3A Date: Mon, 3 Dec 2012 14:39:18 +0000 Message-ID: References: <50B8A287.9090509@secunet.com> <074557eff2f722f10198aac4fb2f8d9c.squirrel@www.trepanning.net> <4613980CFC78314ABFD7F85CC30277210EDCE571@IL-EX10.ad.checkpoint.com> <50B9DC95.80202@gmail.com> <50BA5A70.6030808@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Johannes Merkle , Manfred Lochter , Yoav Nir , Dan Harkins , IPsecme WG , "rfc-ise@rfc-editor.org" , "Sean P. Turner" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 14:39:21 -0000 Sigh, immediately after sending this, I remembered that even characteristic= EC curves tend to have cofactors h>1, hence there is further checking requ= ired for them. Scratch what I said that the what I said for odd characteri= stic EC curves applies to even as well -- that checking is necessary, but i= t is not sufficient. -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= cott Fluhrer (sfluhrer) Sent: Monday, December 03, 2012 9:28 AM To: Yaron Sheffer Cc: Johannes Merkle; Manfred Lochter; Yoav Nir; Dan Harkins; IPsecme WG; rf= c-ise@rfc-editor.org; Sean P. Turner Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Ex= change As for http://tools.ietf.org/html/rfc5996#section-2.12, it's fine as far as= it goes, however (IMHO) it rather punts on what self-checks are actually n= eeded. It does refer to the Menezes and Ustaoglu paper, which is quite goo= d, however, it would be better if you spell out exactly what tests the impl= ementer would need to run for each IKE group. An implementation might have= problems determining from the paper what is appropriate; for example, grou= ps 22-24 would be considered "DSA groups" by the nomenclature of the paper = (see section 2.1); however nowhere in the IKE documents are they actually l= abeled as such. Here is a quick run-down: - Standard MODP groups (1, 2, 5, 14-18): informational leakage from a small= group attack is minimal (see section 2.2 of the paper); hence, the only ch= eck needed is a verification that the peer's public value r is in range (1 = < r < p-1) - MODP groups with small subgroups (22-24): there is some informational lea= kage from a small subgroup attack (see section 2.1 of the paper); hence, yo= u need to check both that the peer's public value is in range (1 < r < p-1)= and that r**q =3D 1 mod p (where q is the size of the subgroup) - EC groups; there is some informational leakage possible (see section 2.3)= ; hence, you need to check that the peer's public value is valid; that is, = it is not the point-at-infinity, and that the x and y parameters from the p= eer's public value satisfies the curve equation, that is, y**2 =3D x**3 + a= x + b mod p. Note that even though the paper specifically targets odd char= acteristic EC curves, their advice of checking the curve equation is equall= y applicable to even characteristic curves as well.=20 Now, as for whether checking the peer's public value ought to be a requirem= ent, even if you aren't reusing private keys, I would still say that it oug= ht to be. If we look at the ECDH point addition/doubling code, well, they = are designed to work correctly if you give them valid points (that is, poin= ts that are actually on the curve). If you just take bit patterns you rece= ived in a packet from the peer, and just give them to the EC routines, well= , there's no inherent requirement what might happen if the values don't hap= pen to be valid. If the implementation uses the standard textbook point ad= dition/doubling code, we can predict what will happen -- however, a specifi= c implementation might decide to do something different. Because of this (= and because checking is so cheap -- we're talking maybe 1% of the cost of t= he cost of doing the ECDH phase two), I would strongly urge anyone to do th= is check. -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= aron Sheffer Sent: Saturday, December 01, 2012 2:29 PM To: Scott Fluhrer (sfluhrer) Cc: Johannes Merkle; Manfred Lochter; Yoav Nir; Dan Harkins; IPsecme WG; rf= c-ise@rfc-editor.org; Sean P. Turner Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Ex= change Hi Scott, OK, I see your point (no pun intended). Regarding ECDH secret reuse, can yo= u please review http://tools.ietf.org/html/rfc5996#section-2.12. That secti= on was supposed to cover the relevant security considerations. In fact I th= ink your attack is alluded to in the paper we reference from that section (= see Sec. 5, first paragraph). If this needs to become a MUST requirement for IKEv2 peers using ECDH, it n= eeds to be spelled out and not left as an exercise to the reader.=20 But we have to understand whether this is a general requirement, or it only= applies to peers that are reusing ECDH private keys for multiple IKE sessi= ons. Thanks, Yaron On 12/01/2012 08:44 PM, Scott Fluhrer (sfluhrer) wrote: > I would humbly disagree. A peer might try to send us an invalid KE, with= a bogus point that acts as if it were of small order with our implementati= on; let us call this bogus point P, and its small order n. We would then g= enerate sk's based on the point (e mod n)P (where e is the value of our ECD= H secret); because n is small, that allows the attacker to recover the valu= e (e mod n). > > If we reuse the same ECDH secret for multiple exchanges (which is normall= y safe), this allows someone who controls some of the peers we talk to to r= ecover the secret value for exchanges he does not control; this is not good= . > > Hence, we need to either mandate checking the point we receive, or forbid= ECDH secret reuse. > > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > Sent: Saturday, December 01, 2012 5:32 AM > To: Scott Fluhrer (sfluhrer) > Cc: Yoav Nir; Johannes Merkle; IPsecme WG; Manfred Lochter; Sean P.=20 > Turner; Dan Harkins; rfc-ise@rfc-editor.org > Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2=20 > Key Exchange > > Actually, I think we have it wrong. There is no reason for a *valid*=20 > peer to send an incorrect KE. And IKEv2 already protects against a=20 > MITM doing such a thing. As we all know, the protocol assumes that=20 > messages > #3 and #4 can be observed by an attacker, and protects against malicious = changes to any of the 4 messages, including the KE value. > > In other words, I would say this is a QA-level test that MAY be performed= by the sender. Not one that MUST be performed by the recipient. > > By the way, there are related protocols that need this test for their sec= urity and do include it: SPSK, and my own RFC 6631 (IKEv2 with PACE). > See e.g. https://tools.ietf.org/html/rfc6631#section-3.4. > > Thanks, > Yaron > > > On 12/01/2012 12:00 AM, Scott Fluhrer (sfluhrer) wrote: >> With ECDH, there are two separate EC points that are output by the algor= ithm: >> >> - There's the public value xG (where x is our secret); this is passed=20 >> in the KE payload >> - There's the shared secret value xyG (where x is our shared secret, and= y is the peer's secret); this is used in the key derivation function. >> >> What RFC5903 says is: >> - The public value xG will be expressed as explicit x, y coordinates. >> - The shared secret value xyG (that is, the value we give to the sk gene= ration function) will be only the x coordinate; the y coordinate will not b= e used. >> >> Yes, this implies that doing point compression on the shared secret valu= e doesn't make much sense (as point compression discards all but one bit of= y -- the format that RFC5903 chooses already discards all the bits of y). = However, the argument about point compression was never about the shared s= ecret value; instead, it was about the repesentation that appeared in the K= E payload (that is, the one that is specified to have both the x and y coor= dinates). >> >> As for Dan's question, it was about whether we should validate the publi= c value we get from the peer, well, the public value does have explicit x a= nd y coordinates, and so it makes sense to check them. >> >> >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On=20 >> Behalf Of Yoav Nir >> Sent: Friday, November 30, 2012 4:39 PM >> To: Johannes Merkle >> Cc: IPsecme WG; Manfred Lochter; Sean P. Turner; Dan Harkins;=20 >> rfc-ise@rfc-editor.org >> Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2=20 >> Key Exchange >> >> Hi Johannes, >> >> Dan't question made me realise something I hadn't noticed before. >> >> In section 2.3, the draft says: >> For the encoding of the key exchange payload and the derivation of >> the shared secret, the methods specified in [RFC5903] are adopted. >> >> In an ECP key exchange in IKEv2, the Diffie-Hellman public value >> passed in a KE payload consists of two components, x and y, >> >> However, according to RFC 5903: >> The Diffie-Hellman shared secret value consists of the x value o= f >> the Diffie-Hellman common value. >> >> In fact RFC 5903 replaced 4753 just to say that the encoding consists on= ly of x, not both x and y. >> >> This also relates to Dan't question. If the y value is missing, what is = there to verify? >> >> Yoav >> >> On Nov 30, 2012, at 7:57 PM, Dan Harkins wrote: >> >>> >>> Hi Johannes, >>> >>> On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote: >>>> We have submitted a new revision of the Internet Draft on Using the=20 >>>> ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange=20 >>>> https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ >>>> >>>> Since there was considerable objection to the point compression=20 >>>> method in the WG, we have removed this option altogether and define=20 >>>> only the uncompressed KE payload format, which is in full=20 >>>> accordance with RFC 5903. >>>> >>>> >>>> Any feedback is welcome. >>> >>> I see that there is a requirement that an implementation MUST=20 >>> verify that the D-H common value is not the point-at-infinity. Do=20 >>> you think there should also be a requirement that an implementation=20 >>> MUST verify that the x- and y-coordinates received from a peer=20 >>> satisfy the equation of the negotiated curve (and abort the exchange if= not)? >>> >>> regards, >>> >>> Dan. >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From internet-drafts@ietf.org Mon Dec 3 14:34:05 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721A221F8981; Mon, 3 Dec 2012 14:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djMPhviSbZXA; Mon, 3 Dec 2012 14:34:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1105421F8982; Mon, 3 Dec 2012 14:34:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121203223404.5441.71025.idtracker@ietfa.amsl.com> Date: Mon, 03 Dec 2012 14:34:04 -0800 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ike-tcp-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 22:34:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. Title : A TCP transport for the Internet Key Exchange Author(s) : Yoav Nir Filename : draft-ietf-ipsecme-ike-tcp-01.txt Pages : 9 Date : 2012-12-03 Abstract: This document describes using TCP for IKE messages. This facilitates the transport of large messages over paths where fragments are either dropped, or where packet loss makes the use of large UDP packets unreliable. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ike-tcp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ike-tcp-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-ike-tcp-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ynir@checkpoint.com Mon Dec 3 14:44:46 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8C421F8981 for ; Mon, 3 Dec 2012 14:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.413 X-Spam-Level: X-Spam-Status: No, score=-10.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hajE+sHkhyWE for ; Mon, 3 Dec 2012 14:44:45 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6062021F8949 for ; Mon, 3 Dec 2012 14:44:45 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id qB3Mie3h003173 for ; Tue, 4 Dec 2012 00:44:40 +0200 X-CheckPoint: {50BD2B25-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.14]) by IL-EX10.ad.checkpoint.com ([194.29.34.147]) with mapi id 14.02.0318.004; Tue, 4 Dec 2012 00:44:40 +0200 From: Yoav Nir To: IPsecme WG Thread-Topic: New Version Notification for draft-ietf-ipsecme-ike-tcp-01.txt Thread-Index: AQHN0aZR5AUY/fnrKEmTT9wsWOPWuA== Date: Mon, 3 Dec 2012 22:44:39 +0000 Message-ID: <4613980CFC78314ABFD7F85CC30277210EDD1C92@IL-EX10.ad.checkpoint.com> References: <20121203223404.5441.41129.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.65] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_4613980CFC78314ABFD7F85CC30277210EDD1C92ILEX10adcheckpo_" MIME-Version: 1.0 Subject: [IPsec] Fwd: New Version Notification for draft-ietf-ipsecme-ike-tcp-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 22:44:46 -0000 --_000_4613980CFC78314ABFD7F85CC30277210EDD1C92ILEX10adcheckpo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I've just posted version -01 of the draft, which I think addresses the issu= es discussed at the F2F in Atlanta: - Added a port specification to the notification (and so, port agility for= when the IKE peer is behind NAT) - Added the notification to the Initiator as well, so that it can advertis= e its port - Added discussion in section 2.1 about the not using a different transpor= t for the same request with a stateless cookie. - Added advice against sending a stateless cookie in the response to TCP. - Added a NAT considerations section (3.2) As Paul said at the meeting, we will need a couple of more rounds of this, = and I believe in publishing often, so keep those comments coming. Yoav Begin forwarded message: From: > Subject: New Version Notification for draft-ietf-ipsecme-ike-tcp-01.txt Date: December 4, 2012 12:34:04 AM GMT+02:00 To: > A new version of I-D, draft-ietf-ipsecme-ike-tcp-01.txt has been successfully submitted by Yoav Nir and posted to the IETF repository. Filename: draft-ietf-ipsecme-ike-tcp Revision: 01 Title: A TCP transport for the Internet Key Exchange Creation date: 2012-12-04 WG ID: ipsecme Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ike= -tcp-01.txt Status: http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ike-tcp Htmlized: http://tools.ietf.org/html/draft-ietf-ipsecme-ike-tcp-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-ike-= tcp-01 Abstract: This document describes using TCP for IKE messages. This facilitates the transport of large messages over paths where fragments are either dropped, or where packet loss makes the use of large UDP packets unreliable. --_000_4613980CFC78314ABFD7F85CC30277210EDD1C92ILEX10adcheckpo_ Content-Type: text/html; charset="us-ascii" Content-ID: <2AAA42EFBA5F1B4DA5F81ECDB50A7FFE@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable Hi

I've just posted version -01 of the draft, which I think addresses the= issues discussed at the F2F in Atlanta:

 - Added a port specification to the notification (and so, port a= gility for when the IKE peer is behind NAT)
 - Added the notification to the Initiator as well, so that it ca= n advertise its port
 - Added discussion in section 2.1 about the not using a differen= t transport for the same request with a stateless cookie.
 - Added advice against sending a stateless cookie in the respons= e to TCP.
 - Added a NAT considerations section (3.2)

As Paul said at the meeting, we will need a couple of more rounds of t= his, and I believe in publishing often, so keep those comments coming.

Yoav 

Begin forwarded message:

From: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=
Subject: Ne= w Version Notification for draft-ietf-ipsecme-ike-tcp-01.txt
Date: Decem= ber 4, 2012 12:34:04 AM GMT+02:00
To: <<= a href=3D"mailto:ynir@checkpoint.com">ynir@checkpoint.com>


A new version of I-D, draft-ietf-ipsecme-ike-tcp-01.txt
has been successfully submitted by Yoav Nir and posted to the
IETF repository.

Filename: d= raft-ietf-ipsecme-ike-tcp
Revision: 0= 1
Title: A TCP transport= for the Internet Key Exchange
Creation date: 2012-12-04
WG ID: ipsecme
Number of pages: 9
URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ike-tcp-01.= txt
Status:          http://datatracke= r.ietf.org/doc/draft-ietf-ipsecme-ike-tcp
Htmlized:        http://tools.ietf.org/html/dr= aft-ietf-ipsecme-ike-tcp-01
Diff:            h= ttp://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-ike-tcp-01

Abstract:
  This document describes using TCP for IKE messages.  This = facilitates
  the transport of large messages over paths where fragments are = either
  dropped, or where packet loss makes the use of large UDP packet= s
  unreliable.


--_000_4613980CFC78314ABFD7F85CC30277210EDD1C92ILEX10adcheckpo_-- From kivinen@iki.fi Tue Dec 4 06:24:56 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BABE21F8B29 for ; Tue, 4 Dec 2012 06:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6Vcd+VTt-dI for ; Tue, 4 Dec 2012 06:24:55 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id CA21621F8AF2 for ; Tue, 4 Dec 2012 06:24:54 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qB4EOmZB010502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Dec 2012 16:24:48 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qB4EOlHM018597; Tue, 4 Dec 2012 16:24:47 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20670.1967.744783.372876@fireball.kivinen.iki.fi> Date: Tue, 4 Dec 2012 16:24:47 +0200 From: Tero Kivinen To: ipsec@ietf.org In-Reply-To: <20121204135025.24091.3591.idtracker@ietfa.amsl.com> References: <20121204135025.24091.3591.idtracker@ietfa.amsl.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 25 min X-Total-Time: 32 min Subject: [IPsec] New Version Notification for draft-kivinen-ipsecme-signature-auth-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 14:24:56 -0000 I posted first version of the signature authentication method. This is based on the design team work on the ECDSA, but as the design team decided not to forbid other authentication methods, I named the draft to signature-auth, not ecdsa-auth. This draft is initial version, meaning it has still some things missing. I would need some good references for different things, and then there is missing the text about the guidance how to select suitable hash functions. We decided that adding such guidance is good idea, but design team didn't specify what such guidance should say, so I need more input for that. Another thing is that we need to decide whether we want to fully support RSASSA-PSS. The current draft only includes the OID from the AlgorithmIdentifier field, thus it cannot be used with RSASSA-PSS when parameters are used (as pointed out by Sean earlier). Actually I am not sure whether we can even use it with defaults, i.e. can RSASSA-PSS be used at all. We might need to add text saying it is always used with default parameters or something. To fully support RSASSA-PSS we would need to include full AlgorithmIdentifier ASN.1 including the parameters. I myself would think that would be best option, as that would allow widest possible use for this new method, i.e. we can support whatever PKIX does. Some design team members disagreed, and we ended up with the current compromize... Other things: In my draft I say: ---------------------------------------------------------------------- For the hash truncation the method of X9.62, SEC1 and IO 14888-3 MUST be used. XXX Need reference for X9.62/SEC1 etchere XXX. ---------------------------------------------------------------------- I.e. the draft points to this hash truncation method. Does anybody have proper reference for that, and it might be good if we could summarize it here too, as not all people have access to those other specifications. In security considerations section I have text: ---------------------------------------------------------------------- The hash algorithm registry does not include MD5 as supported hash algorithm, as it is not considered safe enough for signature use. XXX Need reference for MD5 considered unsafe. XXX ---------------------------------------------------------------------- Does anybody have good reference for MD5 especially with signatures (not with HMAC). In the security considerations section I also have: ---------------------------------------------------------------------- The current IKEv2 uses RSASSA-PKCS1-v1_5, and does not allow using newer padding methods like RSASSA-PSS. This new method allows using other padding methods. XXX Need reference for RSASSA-PSS vs RSASSA-PKCS1-v1_5 security. XXX ---------------------------------------------------------------------- RFC4055 says " The RSASSA-PSS signature algorithm is preferred over the PKCS #1 Version 1.5 signature algorithm. Although no attacks are known against PKCS #1 Version 1.5 signature algorithm, in the interest of increased robustness, RSASSA-PSS signature algorithm is recommended for eventual adoption, especially by new applications." Is this still the case, or do we have some reference which would point out why RSASSA-PSS is better.... Of course if we cannot support RSASSA-PSS with the this new method properly, this text in the security considerations section might not be needed... In the security considerations section: ---------------------------------------------------------------------- XXX The text about the guidance how to select suitable hash functions is missing here. XXX ---------------------------------------------------------------------- I.e we need to guidance or references to good guidance. As this draft is no longer only ECDSA, the RFC5480 might not be enough. For RSA, or normal DSA might also need some guidance. What kind of guidance do we want here. internet-drafts@ietf.org writes: > > A new version of I-D, draft-kivinen-ipsecme-signature-auth-00.txt > has been successfully submitted by Tero Kivinen and posted to the > IETF repository. > > Filename: draft-kivinen-ipsecme-signature-auth > Revision: 00 > Title: Signature Authentication in IKEv2 > Creation date: 2012-12-04 > WG ID: Individual Submission > Number of pages: 9 > URL: http://www.ietf.org/internet-drafts/draft-kivinen-ipsecme-signature-auth-00.txt > Status: http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-signature-auth > Htmlized: http://tools.ietf.org/html/draft-kivinen-ipsecme-signature-auth-00 > > > Abstract: > The Internet Key Exchange Version 2 (IKEv2) protocol has limited > support for the Elliptic Curve Digital Signature Algorithm (ECDSA). > The current support only includes support for three Elliptic Curve > groups, and there is fixed hash algorithm tied to each curve. This > document generalizes the IKEv2 signature support so it can support > any signature method supported by the PKIX and also adds signature > hash algorithm negotiation. This generic mechanism is not limited to > ECDSA, but can also be used with other signature algorithms. -- kivinen@iki.fi From lberger@labn.net Tue Dec 4 09:20:50 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C69421F8C72 for ; Tue, 4 Dec 2012 09:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.831 X-Spam-Level: X-Spam-Status: No, score=-99.831 tagged_above=-999 required=5 tests=[AWL=1.234, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNL3whQ7H4Rw for ; Tue, 4 Dec 2012 09:20:49 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 00FDE21F8C6D for ; Tue, 4 Dec 2012 09:20:48 -0800 (PST) Received: (qmail 27946 invoked by uid 0); 4 Dec 2012 17:20:27 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 4 Dec 2012 17:20:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=SzAGtb0L/99Z8SKBw4ZJX+i9t3qdIPb9wXBvyflmrGE=; b=AArmRVCKE8ozCXs6ixG0ZOMsYs/RqaO84vZm4OnJHq0fmVwXbtC+YPUHg+fAV5hm6dhdHvOBsq9Odb9pZ8jysVZJolo/xHd/9BX4bneM+DA4por3UBH1BmEKwhAEEttt; Received: from box313.bluehost.com ([69.89.31.113]:57638 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TfwAU-00075B-Ib; Tue, 04 Dec 2012 10:20:26 -0700 Message-ID: <50BE30D9.4030903@labn.net> Date: Tue, 04 Dec 2012 12:20:25 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Vishwas Manral References: <50A5703F.4070305@labn.net> <50A58CDB.30402@labn.net> <50A682F8.9080907@labn.net> <50A689A9.1090803@labn.net> <50A68D30.2040203@labn.net> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: IPsecme WG Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 17:20:50 -0000 Hi Vishwas, Was it your intent to fully incorporated the changes we discussed into the -01 rev? If so, I think some were missed (and I can send which in a separate message.) Thanks, Lou On 11/24/2012 12:21 PM, Vishwas Manral wrote: > Hi WG-participants, > > As its been a week and I have not heard any objections, I will update > this requirement and post the draft across. > > Thanks, > Vishwas > On Fri, Nov 16, 2012 at 11:10 AM, Vishwas Manral > wrote: > > Thanks Lou, > > Let me heard back from the WG on this, if they have any opinion. If > not we can go ahead with your suggestion. > > -Vishwas > > > On Fri, Nov 16, 2012 at 11:00 AM, Lou Berger > wrote: > > Vishwas, > > On 11/16/2012 1:48 PM, Vishwas Manral wrote: > > Hi Lou, > > > > Got it. Can you suggest some text for this? I will try to > incorporate > > the same into the document. > > Assuming you don't like my prior attempt: > X. The solution SHOULD support BGP/MPLS IP VPNs, see [RFC4364]. > > How about something like: > X. The solution MUST support Provider Edge (PE) based VPNs. > > Note that this phrasing doesn't indicate a specific solutions > which is > why I now suggest "MUST" vs "SHOULD". > > Lou > > > > > Thanks, > > Vishwas > > > > On Fri, Nov 16, 2012 at 10:44 AM, Lou Berger > > >> wrote: > > > > Vishwas, > > Sure, but it's the BGP information that indicates > what IPsec > > tunnels > > are needed / when the SAs get established... > > > > Again, I just asking for language that points to this use > case, not > > implementation details. > > > > Thanks, > > Lou > > > > On 11/16/2012 1:34 PM, Vishwas Manral wrote: > > > Hi Lou, > > > > > >> I'm not sure I agree with this statement. Let's say > you have > > >> a BGP VPN that uses IPsec tunnels between the PEs (which > > >> was described in a couple of expired drafts and can be > supported > > >> using RFC5566), and then wants to be able to use dynamic PE > > >> to PE IPsec tunnels. Does this fit your "2 different > layer" > > >> perspective? > > > IPsec with ADVPN secures the tunnel and creates the mesh > underlay on > > > need basis/ or automatically. L3VPN creates the overlay, > > identifies the > > > tenant/ customer a packet belongs to and passes the > packet on. > > > > > > Where do we see the need for tighter integration here? > Is it allowing > > > the ability to create groups of ADVPN instances? > > > > > > Thanks, > > > Vishwas > > > > > > On Fri, Nov 16, 2012 at 10:16 AM, Lou Berger > > > > > > > > >>> wrote: > > > > > > Vishwas, > > > > > > Please see below. > > > > > > On 11/16/2012 12:49 PM, Vishwas Manral wrote: > > > > Hi Lou, > > > > > > > > Thanks for the quick reply. Just a few comments > prefixed > > with a "VM>": > > > > > > > > > > > > > > We can add something in the lines of > additional protocols > > > are run over > > > > > the IPsec tunnels and the solution should > make an > > effort to > > > allow for > > > > > additional protocols like OSPF to be run > optimally without > > > too many > > > > > changes in configuration. > > > > > > > > > > Infact we have a requirement to the effect > in section 4.1 > > > > > > > > yes, this is what I referred to as 4.2 below, and > > suggested some > > > > replacement text... > > > > > > > > OK got it. > > > > > > > > > > > > > > Gateways MUST allow tunnel binding, such > that > > > applications like > > > > > Routing using the tunnels can work seamlessly > > without any > > > > updates to > > > > > the higher level application > configuration i.e. OSPF > > > > configuration. > > > > > > > > > > - In section 4.2, how about: > > > > > (replacement text) > > > > > 3. Gateways MUST allow for the > operation of > > > tunneling and > > > > > routing protocols operating over > spoke-to-spoke > > IPsec > > > Tunnels > > > > > with minimal, or no, configuration > impact. > > > > > > > > VM> Ok will specifically specify tunnels and > routing protocols. > > > > > > > > > > Great. > > > > > > > > > > > > > > > > > > > > > > X. The solution SHOULD support > BGP/MPLS IP > > VPNs, see > > > > [RFC4364]. > > > > > > > > > > If you want, you can make the "SHOULD" a > "MUST", and > > > "support" > > > > could be > > > > > "be compatible with". > > > > > > > > > > I do not want to go ahead into details of > what other > > routing > > > solutions > > > > > it should support. > > > > > > > > > > With that said I am not sure what you mean > by having BGP > > > MPLS VPN > > > > in an > > > > > ADVPN scenario. BGP MPLS VPN is a provider > provisioned VPN > > > solution, > > > > > this is a customer provisioned one. > > > > > > > > Ahh, interesting point. When I read the > document I was > > > looking to see > > > > if it was scoped purely to CE/customer based > solutions. > > > Reading section > > > > 2 (intro) and 2.2, I saw no such restriction. > So I think > > > section 2.2 > > > > should be explicit on this point either way. > Which is why I > > > proposed the > > > > text "There is also the case when L3VPNs > operate over IPsec > > > Tunnels." > > > > (To explicitly include this case.) If the WG > wants this > > case > > > excluded, > > > > that's fine too. > > > > > > > > VM> It is not scoped purely as a CE device > scenario, and > > after seeing > > > > your comment I see no reason to leave that out of > scope > > (though if I > > > > understand your concern better I may feel > otherwise). L3VPN > > can work > > > > over GRE tunnels/ L2TP tunnels, which can > themselves use IPsec. > > > Again in > > > > my view the L3VPN and the IPsec VPN are 2 > different layers > > in the > > > stack > > > > if they run on the same device. > > > > > > I'm not sure I agree with this statement. Let's say > you have > > a BGP VPN > > > that uses IPsec tunnels between the PEs (which was > described > > in a couple > > > of expired drafts and can be supported using > RFC5566), and > > then wants to > > > be able to use dynamic PE to PE IPsec tunnels. Does > this fit > > your "2 > > > different layer" perspective? > > > > > > Either way, I think such usage should be explicitly > in scope > > as it is a > > > very different model / use case from CE-based IPsec > VPNs. > > > > > > > Do you see a reason to explicitly > > > > mention L3VPN in this case? > > > > > > I'm open to different ways to cover the above. > > > > > > Much thanks, > > > Lou > > > > > > > > Thanks, > > > > Vishwas > > > > > > > > > > > > > > > > > I see the 2 working in different > > > > > layers, and interacting only in edge > gateways where both > > > solutions > > > > have > > > > > an edge. > > > > > > > > Sure, but the problem exists for both. > > > > > > > > Thanks, > > > > Lou > > > > > > > > > > > > > > > I also have a few more minor comments: > > > > > > > > > > I am ok with the minor suggestions you have. > > > > > > > > > > Thanks, > > > > > Vishwas > > > > > > > > > > > > > > > > > > > > - In section 2.1, you introduce the term > "NAT > > gateway" and > > > > then later > > > > > use just "gateway" when I suspect you > mean "NAT > > gateway". I > > > > suggest > > > > > using the term "NAT" and thereby not > introduce > > possible > > > confusion > > > > > between the gateway term defined in > section 1.1 > > and "NAT > > > > gateways". > > > > > > > > > > - In section 2.2, s/occupies/requires > > > > > > > > > > - In sections 2.2, and Section 3.2 you > say dynamic > > > addresses makes > > > > > static configuration impossible. This > doesn't reflect > > > the use of > > > > > dynamic dns to handle this issues (and > is currently > > > supported > > > > by some > > > > > vendors.) > > > > > > > > > > Let me know what you think, > > > > > Lou > > > > > > _______________________________________________ > > > > > IPsec mailing list > > > > > IPsec@ietf.org > > > > > >> > > > > > > > > >>> > > > > > > > > >> > > > > > > > > > >>>> > > > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From yaronf.ietf@gmail.com Tue Dec 4 09:28:39 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022D421F8C84 for ; Tue, 4 Dec 2012 09:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgKQ37ipNJ1e for ; Tue, 4 Dec 2012 09:28:38 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 44E8321F8C83 for ; Tue, 4 Dec 2012 09:28:38 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so1844492bku.31 for ; Tue, 04 Dec 2012 09:28:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding; bh=N/tS34RdnLCaAT7kBgzV1SJvhiFfml1pEMDAZAwfFx8=; b=tYxRnirGJqSMRLoS9jHFmjIDpKZEO0ae/d3klGcvrOM4oY8AWzvVqcYZfSHPyogInq +gbJu9VUOt23Mm0gHipWpXOcpGTA+EvPiOVHwD8cikztAbYkxjOxlwCDYIm4Jp4hxEJZ kLi2V0QQpTDnd+qCmc28KPHi2r6nuEyxab6sVzLBYmJz00QxBfGuCkn44huQyIrRA6xz AVCrKVeXIqLUEOEqhQFr/AEODDpD6t8MLXuWqV1Jm+nJDMt5wnjPt4fKPcbT8TtGE9UQ bNfQ4tCwA4uAQ+Q5Ksjrmk4WrKOM2oWUGrZL/HHSqRVA5FvwUdiZFZ/F9T1tFVotTWVs an1A== Received: by 10.204.149.86 with SMTP id s22mr4372721bkv.57.1354642117231; Tue, 04 Dec 2012 09:28:37 -0800 (PST) Received: from [10.0.0.13] ([93.173.108.159]) by mx.google.com with ESMTPS id 18sm1850682bkv.0.2012.12.04.09.28.34 (version=SSLv3 cipher=OTHER); Tue, 04 Dec 2012 09:28:36 -0800 (PST) Message-ID: <50BE32C0.4090704@gmail.com> Date: Tue, 04 Dec 2012 19:28:32 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: IPsecme WG References: <20121204172445.4398.8801.idtracker@ietfa.amsl.com> In-Reply-To: <20121204172445.4398.8801.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121204172445.4398.8801.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Fwd: Last Call: (An IKEv2 Extension for Supporting ERP) to Experimental RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 17:28:39 -0000 This is an individual submission, and discussion should be on the IETF mailing list. Thanks, Yaron -------- Original Message -------- Subject: Last Call: (An IKEv2 Extension for Supporting ERP) to Experimental RFC Date: Tue, 04 Dec 2012 09:24:45 -0800 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce The IESG has received a request from an individual submitter to consider the following document: - 'An IKEv2 Extension for Supporting ERP' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-01-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates the IKEv2 protocol, described in RFC 5996. This extension allows an IKE Security Association (SA) to be created and authenticated using the EAP Re-authentication Protocol extension as described in RFC 6696. The file can be obtained via http://datatracker.ietf.org/doc/draft-nir-ipsecme-erx/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-nir-ipsecme-erx/ballot/ No IPR declarations have been submitted directly on this I-D. From vishwas.ietf@gmail.com Tue Dec 4 09:54:24 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0CE521F8C86 for ; Tue, 4 Dec 2012 09:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgTrA70QUz1q for ; Tue, 4 Dec 2012 09:54:24 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 76DD021F8C6F for ; Tue, 4 Dec 2012 09:54:13 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id z4so1115372qan.10 for ; Tue, 04 Dec 2012 09:54:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/639Js0Jwr05EVMTjIHUcdBl1PyDcLfEGunQX5A3xtg=; b=sq1uKGO3wBIwEVttVnnIPpDzcMvLDaXz7JCR+VDRG7Z5A6shmgiy5qeqCZ6TMa8M3D dd4MjqDJyDfm7QuAAX6GE0g007Q5Had/uItPogC/n1xstL1GNtyrTvq62AkKRKPrT6BB 1/qDtY+TErxgW576XoUDrc3dNWqtIj00jO9vapwo8I+VbX24zrBcrKNbz+1NIELIhwQg 0qkjv0zs2R4GPp4f9icQrIEdbBOO7Ib6b8vvvjRjzOT5Q74gMhZYYTca9ERAJUpgbh9C Lj3MZ13ff3XXvpjS77dEdp5lYMVOgL33rexCJN96AKcy64U2CqodvHyKXWR+WJYRx7Jv +2wg== MIME-Version: 1.0 Received: by 10.49.48.110 with SMTP id k14mr26297787qen.28.1354643652758; Tue, 04 Dec 2012 09:54:12 -0800 (PST) Received: by 10.229.92.77 with HTTP; Tue, 4 Dec 2012 09:54:12 -0800 (PST) In-Reply-To: <50BE30D9.4030903@labn.net> References: <50A5703F.4070305@labn.net> <50A58CDB.30402@labn.net> <50A682F8.9080907@labn.net> <50A689A9.1090803@labn.net> <50A68D30.2040203@labn.net> <50BE30D9.4030903@labn.net> Date: Tue, 4 Dec 2012 09:54:12 -0800 Message-ID: From: Vishwas Manral To: Lou Berger Content-Type: multipart/alternative; boundary=047d7b6d99d2b84d6904d00a8d24 Cc: IPsecme WG Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 17:54:24 -0000 --047d7b6d99d2b84d6904d00a8d24 Content-Type: text/plain; charset=ISO-8859-1 Hi Lou, Yes that's the intent. Please let me know what is it that we agreed to, that is not there in the draft. Thanks, Vishwas On Tue, Dec 4, 2012 at 9:20 AM, Lou Berger wrote: > Was it your intent to fully incorporated the changes we discussed > into > the -01 rev? If so, I think some were missed (and I can send which in > a separate message.) > > Thanks, > Lou > --047d7b6d99d2b84d6904d00a8d24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lou,

Yes that's the intent. Please let me know what is it tha= t we agreed to, that is not there in the draft.

Thanks,
Vishwas
On Tue, Dec 4, 2012 at 9:20 AM, Lou Berger= <lberger@labn.net> wrote:
=A0 =A0 =A0 =A0 Was it your intent to =A0fully incorporated the changes we = discussed into
the -01 rev? =A0 If so, I think some were missed (and I can send which in a separate message.)

Thanks,
Lou

--047d7b6d99d2b84d6904d00a8d24-- From Johannes.Merkle@secunet.com Tue Dec 4 10:11:44 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E496821F896F for ; Tue, 4 Dec 2012 10:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yt0k1k5cMe4M for ; Tue, 4 Dec 2012 10:11:43 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id AC17521F8476 for ; Tue, 4 Dec 2012 10:11:42 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id E3F1F1A007A; Tue, 4 Dec 2012 19:11:11 +0100 (CET) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 44B4D1A0076; Tue, 4 Dec 2012 19:11:03 +0100 (CET) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Dec 2012 19:11:32 +0100 Message-ID: <50BE3CD3.3010304@secunet.com> Date: Tue, 04 Dec 2012 19:11:31 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Tero Kivinen References: <20121204135025.24091.3591.idtracker@ietfa.amsl.com> <20670.1967.744783.372876@fireball.kivinen.iki.fi> In-Reply-To: <20670.1967.744783.372876@fireball.kivinen.iki.fi> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Dec 2012 18:11:32.0120 (UTC) FILETIME=[C9F37180:01CDD24A] Cc: ipsec@ietf.org Subject: Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-signature-auth-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 18:11:44 -0000 Hi Tero, > I posted first version of the signature authentication method. This is > based on the design team work on the ECDSA, but as the design team > decided not to forbid other authentication methods, I named the draft > to signature-auth, not ecdsa-auth. Thanks for your work. > > To fully support RSASSA-PSS we would need to include full > AlgorithmIdentifier ASN.1 including the parameters. I myself would > think that would be best option, as that would allow widest possible > use for this new method, i.e. we can support whatever PKIX does. Some > design team members disagreed, and we ended up with the current > compromize... If RSA-PSS keys are used then this should not be an issue. In this case the SPKI of the cert specifies the parameters to be used. However, RSA-PSS keys are hardly supported yet. If the SPKI includes just an rsaEncryption OID, there are several problems: - A peer with an RSA signing key supporting RSA-PSS has no means to determine if the other peer supports PSS as well or if he should better fall back to PKCS#1v1.5. At least he can find out with trial and error. - When verifying a RSA-PSS signature based on a certificate specifying rsaEncryption in SPKI, additional information on the parameters used are needed. I would also advocate inclusion of parameters in the AlgorithmIdentifier inside Authentication Data. In most cases (except RSA-PSS with non-standard parameters) it is NULL, but I don't think, this is a problem. > Other things: > > In my draft I say: > ---------------------------------------------------------------------- > For the hash truncation the method of > X9.62, SEC1 and IO 14888-3 MUST be used. XXX Need reference for > X9.62/SEC1 etchere XXX. > ---------------------------------------------------------------------- > > I.e. the draft points to this hash truncation method. Does anybody > have proper reference for that, and it might be good if we could > summarize it here too, as not all people have access to those other > specifications. I have been the one bringing up this issue, so I should comment on this ;-) The issue is that ISO 15946-2 defines a different hash truncation method. But actually, ISO 15946-2 is deprecated (withdrawn) in favor of ISO 14888. Therefore, I don't think we need to specify anything w.r.t hash truncation. It is now uniformly defined in all current standards. > > > In security considerations section I have text: > ---------------------------------------------------------------------- > The hash algorithm registry does not include MD5 as supported hash > algorithm, as it is not considered safe enough for signature use. > > XXX Need reference for MD5 considered unsafe. XXX > ---------------------------------------------------------------------- > > Does anybody have good reference for MD5 especially with signatures > (not with HMAC). > Wikipedia list a good reference: Xiaoyun Wang; Hongbo Yu (2005). "How to Break MD5 and Other Hash Functions". If you are looking for standards... NIST SP 800-57 does not list MD5 as approved but does not explicitly mention it as ineligible. An explicit caveat is included in ETSI TS 102 176-1 "Recently some new attacks against hash function MD5 succeeded, it was shown that MD5 is not collision resistant by constructing classes of messages-pairs with the same hash value. Whereas the loss of collision resistance does not imply that a pre-image or second pre-image can easier be constructed, it is recommended to migrate to other hash functions, if the collision resistance becomes weaker." However, this standard is is from 2005 and focuses on Secure Electronic Signatures. Is this a problem? > > In the security considerations section I also have: > ---------------------------------------------------------------------- > The current IKEv2 uses RSASSA-PKCS1-v1_5, and does not allow using > newer padding methods like RSASSA-PSS. This new method allows using > other padding methods. > > XXX Need reference for RSASSA-PSS vs RSASSA-PKCS1-v1_5 security. > XXX > ---------------------------------------------------------------------- > > RFC4055 says > > " The RSASSA-PSS signature algorithm is preferred over the PKCS #1 > Version 1.5 signature algorithm. Although no attacks are known > against PKCS #1 Version 1.5 signature algorithm, in the interest of > increased robustness, RSASSA-PSS signature algorithm is recommended > for eventual adoption, especially by new applications." > > Is this still the case, or do we have some reference which would point > out why RSASSA-PSS is better.... Of course if we cannot support > RSASSA-PSS with the this new method properly, this text in the > security considerations section might not be needed... > There are attacks against implementations not checking for garbage after the hash value when using public exponent e=3 (a very special case, but the best attack I know of). http://csrc.nist.gov/groups/ST/toolkit/documents/dss/RSAstatement_10-12-06.pdf As permanent reference, this one is better: Ulrich Kuehn, Andrei Pyshkin, Erik Tews, Ralf-Philipp Weinmann: Variants of Bleichenbacher's Low-Exponent Attack on PKCS#1 RSA Signatures. Proceedings of Sicherheit 2008, pp. 97-109. > > In the security considerations section: > ---------------------------------------------------------------------- > XXX The text about the guidance how to select suitable hash > functions is missing here. XXX > ---------------------------------------------------------------------- > > I.e we need to guidance or references to good guidance. As this draft > is no longer only ECDSA, the RFC5480 might not be enough. For RSA, or > normal DSA might also need some guidance. What kind of guidance do we > want here. > NIST SP 800-57, Tables 2 in combination with Table 3. It seems that RFC 4055 also point to an early draft of NIST SP 800-57. -- Johannes From lberger@labn.net Tue Dec 4 11:09:49 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756DB21F8B2A for ; Tue, 4 Dec 2012 11:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.44 X-Spam-Level: X-Spam-Status: No, score=-100.44 tagged_above=-999 required=5 tests=[AWL=1.226, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kcmq+i4ByQrx for ; Tue, 4 Dec 2012 11:09:48 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 0951921F8BF5 for ; Tue, 4 Dec 2012 11:09:47 -0800 (PST) Received: (qmail 10220 invoked by uid 0); 4 Dec 2012 19:09:22 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 4 Dec 2012 19:09:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=YHo2o2sReHfGT2RlZTlUzCFOxY6mTUm1wPkn3Q9/ue0=; b=yRnhtxMpKpsu2l2CbtyNJAluIC/o1EBUfB8Y/5TSYfEeD4LMBNvB3vveTVso37mjOuUpAbfCrjC0VOPc+YAnB9Cvce2/GkUjfh9M8+2Wm6I8/gzdxv1tm1H6HZvjdR0Z; Received: from box313.bluehost.com ([69.89.31.113]:42191 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1Tfxrt-0001gZ-NB; Tue, 04 Dec 2012 12:09:21 -0700 Message-ID: <50BE4A60.1000303@labn.net> Date: Tue, 04 Dec 2012 14:09:20 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Vishwas Manral References: <50A5703F.4070305@labn.net> <50A58CDB.30402@labn.net> <50A682F8.9080907@labn.net> <50A689A9.1090803@labn.net> <50A68D30.2040203@labn.net> <50BE30D9.4030903@labn.net> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: IPsecme WG Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 19:09:49 -0000 Vishwas On 12/4/2012 12:54 PM, Vishwas Manral wrote: > Hi Lou, > > Yes that's the intent. Please let me know what is it that we agreed to, > that is not there in the draft. > > Thanks, > Vishwas Here's what I think has been missed (plus one new comment): On 11/15/2012 7:14 PM, Vishwas Manral wrote: > - In section 2.2, I think mentioning something about the routing > implications is worthwhile. How about at the end of the section adding > something along the lines of : > > Additionally, the routing implications of gateway-to-gateway > communication must be addressed. In the simple case, > selectors provide sufficient information for a gateway to > forward traffic appropriately. In other cases, additional > tunneling (e.g., GRE) and routing (e.g., OSPF) protocols are > run over IPsec tunnels, and the configuration impact on those > protocols must be considered. There is also the case when > L3VPNs operate over IPsec Tunnels. > > We can add something in the lines of additional protocols are run over > the IPsec tunnels and the solution should make an effort to allow for > additional protocols like OSPF to Also in section 2.2, the text now says: The solution should work in cases where the endpoints are administrated by separate management domains, albeit, ones that have an existing trust relationship (for example two organisations who are collaborating on a project, they may wish to join their networks, whilst retaining independent control over configuration)It is for this purpose spoke-to-spoke tunnels are dynamically created and torn- down. It is highly desirable that the solution works for the star, full mesh as well as dynamic full mesh topology. This revision now reads that the primary reason for dynamic spoke-to-spoke tunnels is separate management domains. I somehow don't think this was the intent. In section 4.1 we had discussed replacement text for 3: On 11/16/2012 12:49 PM, Vishwas Manral wrote: >>On 11/15/2012 5:44 PM, Lou Berger wrote: >> - In section 4.2, how about: >> (replacement text) >> 3. Gateways MUST allow for the operation of tunneling and >> routing protocols operating over spoke-to-spoke IPsec Tunnels >> with minimal, or no, configuration impact. > >VM> Ok will specifically specify tunnels and routing protocols. You have the following alternate / revised text: 3. In many cases additional tunneling protocols (i.e. GRE) or Routing protocols (i.e. OSPF) are run over the IPsec tunnels. Gateways MUST allow for the operation of tunneling and Routing protocols operating over spoke-to-spoke IPsec Tunnels with minimal or no, configuration impact. Routing using the tunnels can work seamlessly without any updates to the higher level application configuration i.e. OSPF configuration, when the tunnel parameter changes. I think this text is closer, but I think a few additional changes are needed: - GRE and OSPF are examples, so "i.e." should be replaced with "e.g." - I think the final sentence is likely to be incorrect in many / most real world cases, so would drop the sentence (from "Routing using the tunnels can work...") You also said you'd address the minor comments: On 11/15/2012 5:44 PM, Lou Berger wrote: > - In section 2.1, you introduce the term "NAT gateway" and then later > use just "gateway" when I suspect you mean "NAT gateway". I suggest > using the term "NAT" and thereby not introduce possible confusion > between the gateway term defined in section 1.1 and "NAT gateways". and > - In sections 2.2, and Section 3.2 you say dynamic addresses makes > static configuration impossible. This doesn't reflect the use of > dynamic dns to handle this issues (and is currently supported by some > vendors.) That's it. Let me know what you think. Much thanks, Lou From yaronf.ietf@gmail.com Tue Dec 4 14:27:46 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B62A21F8932 for ; Tue, 4 Dec 2012 14:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oK1DqgTSpAd1 for ; Tue, 4 Dec 2012 14:27:45 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 48DD121F88FD for ; Tue, 4 Dec 2012 14:27:45 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so1988986eaa.31 for ; Tue, 04 Dec 2012 14:27:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding; bh=OQPrxyBV2+ldEiUxAoDCQLptJXQLloLLW16kluOC/ww=; b=rLukEqqVp3vQvUZ7cubp7WqqKqMynomGpTkbpvKjI2XFhEuj+X7SDEFk3YW2AsnaV+ K7vpNB8DJTkQWAgsOpdZkuA8wR88O6F2hdhxjfmPGMWzYEXz/h1sFasGbkUNYOAO3+B+ 4V47m5vWtPBYaRlFg3850D7R3oKJs5CJQNrHvvMIuOa0/r9o+tfYcuwPMLwHaaPdDmd5 cIrz2EvdLNchZ1gLw+CtupeHRjQOvSR4qDXClfAUmQb2E4+pYMDEznTLmZZeEBT7lmYw JTbq+HkVuWxPAHIfbJUWtFu6L62uP86zPcnwSITYyMjeIq1FO8lpXfi2/xtJcw5GQtcS 890Q== Received: by 10.14.223.200 with SMTP id v48mr53317206eep.24.1354660064431; Tue, 04 Dec 2012 14:27:44 -0800 (PST) Received: from [10.0.0.3] (bzq-79-183-160-16.red.bezeqint.net. [79.183.160.16]) by mx.google.com with ESMTPS id w3sm5237189eel.17.2012.12.04.14.27.39 (version=SSLv3 cipher=OTHER); Tue, 04 Dec 2012 14:27:40 -0800 (PST) Message-ID: <50BE78D9.7040204@gmail.com> Date: Wed, 05 Dec 2012 00:27:37 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: IPsecme WG References: <20121204215912.6753.56591.idtracker@ietfa.amsl.com> In-Reply-To: <20121204215912.6753.56591.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121204215912.6753.56591.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Fwd: RETRACTION: Last Call: (An IKEv2 Extension for Supporting ERP) to Experimental RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 22:27:46 -0000 The previous announcement was in error. Sorry. -------- Original Message -------- Subject: RETRACTION: Last Call: (An IKEv2 Extension for Supporting ERP) to Experimental RFC Date: Tue, 04 Dec 2012 13:59:12 -0800 From: IESG Secretary To: IETF Announcement List The IESG would like to retract the current Last Call on the following document: - 'An IKEv2 Extension for Supporting ERP' as Experimental RFC This Last Call was sent in error. The document previously completed Last Call on 2012-11-26, and does not require a second Last Call at this time. From yaronf.ietf@gmail.com Tue Dec 4 23:59:39 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199E121F8C69 for ; Tue, 4 Dec 2012 23:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ySmf-a41iNn for ; Tue, 4 Dec 2012 23:59:38 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDFA21F8C50 for ; Tue, 4 Dec 2012 23:59:37 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so2076603bku.31 for ; Tue, 04 Dec 2012 23:59:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=7ftO8OO22FhJeKDlj0m7kv64RrSgCiiAxZ4l8c3nrk0=; b=n0U/9s7c/S1Nlv3kjkP0IGvl4+tUc28d3Q4C0E1yxWW/vvC0I8rqfudUIxga2lH0OJ zaVAeSAq24/DRJjWET06aPcaiObWSDeZg/GP76Qvlq+Zm3S28d4nXgVTL54dqPjmUs8w tJeVFn92/5yhHGABr+hp7wh1erlWSoZooCUXvHij4ntUnIAvpsKgyYSQuG/DvV37ZcW7 f+7zdKlGs58LcCN0rHlmskEDY4wP9BloHib/Pe6SruKp2prZvayLh9KHwwXbvETdgsd7 3J5O/lLZ01YlQEVG06u+8S8FTF6tb4DdViaVSXQOYuUxobTU0PlwBwtYWFvyY7bltNr0 GBkg== Received: by 10.204.6.20 with SMTP id 20mr5093234bkx.33.1354694376589; Tue, 04 Dec 2012 23:59:36 -0800 (PST) Received: from [192.168.1.217] (192.117.25.34.static.012.net.il. [192.117.25.34]) by mx.google.com with ESMTPS id o9sm2800507bko.15.2012.12.04.23.59.34 (version=SSLv3 cipher=OTHER); Tue, 04 Dec 2012 23:59:35 -0800 (PST) Message-ID: <50BEFEE5.9050900@gmail.com> Date: Wed, 05 Dec 2012 09:59:33 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] draft-ietf-ipsecme-ike-tcp-01 comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 07:59:39 -0000 Hi, In general, it seems to me we are trying to solve more than we should, and we should punt on some of the NAT use cases, leave them to configuration or to out-of-protocol solutions like STUN and friends. Maybe even DNS SRV registration. Specifically: - In the new text re: the Initiator sending IKE_TCP_SUPPORTED, I would change "prevented... by network address translation" to "prevented by policy". There are different ways to prevent a peer from being a responder, including firewalls, NAT or plain configuration. All should be included here. - I'm feeling uncomfortable with the rudimentary NAT bypass mechanism that we are proposing here: you're supposed to advertise a port number on another device (on the NAT box). I am sure there are loads of problems this will open up. Here's one: if we're talking about a very large NAT device (one that uses multiple public addresses), isn't it possible that the IP address allocated for the static NAT of the IKE listening port is different from the source IP address of the initial IKE request? - Also, given the port advertising, do we still need the liveness check described at the end of Sec. 3.2? Thanks, Yaron From ynir@checkpoint.com Wed Dec 5 01:41:15 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E89121F8CAC for ; Wed, 5 Dec 2012 01:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.466 X-Spam-Level: X-Spam-Status: No, score=-10.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiUOTrEYGmf2 for ; Wed, 5 Dec 2012 01:41:14 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3345021F8C9F for ; Wed, 5 Dec 2012 01:41:13 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id qB59f9vZ026292; Wed, 5 Dec 2012 11:41:09 +0200 X-CheckPoint: {50BF166F-2-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.14]) by IL-EX10.ad.checkpoint.com ([169.254.2.14]) with mapi id 14.02.0318.004; Wed, 5 Dec 2012 11:41:08 +0200 From: Yoav Nir To: Yaron Sheffer Thread-Topic: [IPsec] draft-ietf-ipsecme-ike-tcp-01 comments Thread-Index: AQHN0r5+hrRKPfFxi02auVilIkihkpgJ0kaA Date: Wed, 5 Dec 2012 09:41:07 +0000 Message-ID: <4613980CFC78314ABFD7F85CC30277210EDD3BBB@IL-EX10.ad.checkpoint.com> References: <50BEFEE5.9050900@gmail.com> In-Reply-To: <50BEFEE5.9050900@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.46] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11903f2e4d402ff5f18e12a665700b0558f9c538af Content-Type: text/plain; charset="us-ascii" Content-ID: <0406B6AEE995DB4FAEB8101BD069AF88@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] draft-ietf-ipsecme-ike-tcp-01 comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 09:41:15 -0000 Hi Yaron On Dec 5, 2012, at 9:59 AM, Yaron Sheffer wrote: > Hi, >=20 > In general, it seems to me we are trying to solve more than we should, an= d we should punt on some of the NAT use cases, leave them to configuration = or to out-of-protocol solutions like STUN and friends. Maybe even DNS SRV r= egistration. >=20 > Specifically: >=20 > - In the new text re: the Initiator sending IKE_TCP_SUPPORTED, I would ch= ange "prevented... by network address translation" to "prevented by policy"= . There are different ways to prevent a peer from being a responder, includ= ing firewalls, NAT or plain configuration. All should be included here. I strongly disagree with this. As section 1.1 says, we are not trying to cr= eate a protocol to subvert policy, and NATs are not generally a tool for po= licy enforcement. They do, however, cause issues with connecting to port 50= 0 of a host that's behind them. If the host is unreachable, it should not a= dvertise its support for IKE over TCP. If it uses STUN and friends so that = it is reachable at the NAT address on some port (usually referred to as "po= rt forwarding") then it should advertise that port. I think this would be i= mplemented as a configuration option, which you set after setting up the po= rt forwarding, but if there's an automated way of doing this, that would al= so work, and I agree that we should not specify which it is. > - I'm feeling uncomfortable with the rudimentary NAT bypass mechanism tha= t we are proposing here: you're supposed to advertise a port number on anot= her device (on the NAT box). I am sure there are loads of problems this wil= l open up. Here's one: if we're talking about a very large NAT device (one = that uses multiple public addresses), isn't it possible that the IP address= allocated for the static NAT of the IKE listening port is different from t= he source IP address of the initial IKE request? I'm not assuming that the original responder learns the IP address of the o= riginal initiator by the source of the request. If it is so, then we need s= omething better like an SRV record. > - Also, given the port advertising, do we still need the liveness check d= escribed at the end of Sec. 3.2? Sure. The liveness check clears the way and tests reachability for IPsec, b= y using the same ports as IPsec. >=20 > Thanks, > Yaron >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Email secured by Check Point From yaronf.ietf@gmail.com Wed Dec 5 02:55:36 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434F721F86B5 for ; Wed, 5 Dec 2012 02:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LL5I1cxFQGJO for ; Wed, 5 Dec 2012 02:55:35 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 11ED221F86A3 for ; Wed, 5 Dec 2012 02:55:34 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so4383844lbk.31 for ; Wed, 05 Dec 2012 02:55:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6Y91SnPA0DpwaHiD8MsViHuZQMczTSLd4lyiPFdxBGA=; b=mYcdz9LPGkwJOphu1X4yv2Cvh4BwBGtwxq7PQC2Eg9rAIkmed/M58Aynfikb16QRHT eqIquGFsyqtY7u3GkzI3BufQ5Y/QAbFd6rFA5blnTU98kFGZLaXs9ue6G+nxMFwTGEdJ 9Jk3snnhqf0u5WLIxrUDZ5FRzETDOPqEllWQgKr7yC/S3HQN38CXCl6CC+rXefaliT8/ m6fvtBz35+j365gBLdNHQbr5yZAuQzEqPmoI5/djFk7Ml3Qus3Lsmb6ajgpfanx3wC9K YGrjo4LqLh/6elXbosCOH5VCIhFXvjGT2w29DL2pZeyPN0u+THeb0mgfQNGR2kXajUZc dXBA== Received: by 10.152.144.164 with SMTP id sn4mr16106731lab.57.1354704933905; Wed, 05 Dec 2012 02:55:33 -0800 (PST) Received: from [10.0.0.13] ([93.173.108.159]) by mx.google.com with ESMTPS id oj5sm1852553lab.8.2012.12.05.02.55.31 (version=SSLv3 cipher=OTHER); Wed, 05 Dec 2012 02:55:32 -0800 (PST) Message-ID: <50BF2821.2020204@gmail.com> Date: Wed, 05 Dec 2012 12:55:29 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Yoav Nir References: <50BEFEE5.9050900@gmail.com> <4613980CFC78314ABFD7F85CC30277210EDD3BBB@IL-EX10.ad.checkpoint.com> In-Reply-To: <4613980CFC78314ABFD7F85CC30277210EDD3BBB@IL-EX10.ad.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] draft-ietf-ipsecme-ike-tcp-01 comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 10:55:36 -0000 Hi Yoav! On 12/05/2012 11:41 AM, Yoav Nir wrote: > Hi Yaron > > On Dec 5, 2012, at 9:59 AM, Yaron Sheffer > wrote: > >> Hi, >> >> In general, it seems to me we are trying to solve more than we >> should, and we should punt on some of the NAT use cases, leave them >> to configuration or to out-of-protocol solutions like STUN and >> friends. Maybe even DNS SRV registration. >> >> Specifically: >> >> - In the new text re: the Initiator sending IKE_TCP_SUPPORTED, I >> would change "prevented... by network address translation" to >> "prevented by policy". There are different ways to prevent a peer >> from being a responder, including firewalls, NAT or plain >> configuration. All should be included here. > > I strongly disagree with this. As section 1.1 says, we are not trying > to create a protocol to subvert policy, and NATs are not generally a > tool for policy enforcement. They do, however, cause issues with > connecting to port 500 of a host that's behind them. If the host is > unreachable, it should not advertise its support for IKE over TCP. If > it uses STUN and friends so that it is reachable at the NAT address > on some port (usually referred to as "port forwarding") then it > should advertise that port. I think this would be implemented as a > configuration option, which you set after setting up the port > forwarding, but if there's an automated way of doing this, that would > also work, and I agree that we should not specify which it is. I think we are saying the same thing here, and it's a question of wording. The Initiator should not send the notification if it cannot be reached (or does not want to be reached) for any reason at all. > >> - I'm feeling uncomfortable with the rudimentary NAT bypass >> mechanism that we are proposing here: you're supposed to advertise >> a port number on another device (on the NAT box). I am sure there >> are loads of problems this will open up. Here's one: if we're >> talking about a very large NAT device (one that uses multiple >> public addresses), isn't it possible that the IP address allocated >> for the static NAT of the IKE listening port is different from the >> source IP address of the initial IKE request? > > I'm not assuming that the original responder learns the IP address of > the original initiator by the source of the request. If it is so, > then we need something better like an SRV record. Now I'm not following. If the original responder does not _learn_ the IP address, then presumably the address is configured. In that case, you might as well configure the port number, too, and be rid of the advertising mechanism. > >> - Also, given the port advertising, do we still need the liveness >> check described at the end of Sec. 3.2? > > Sure. The liveness check clears the way and tests reachability for > IPsec, by using the same ports as IPsec. OK. > >> >> Thanks, Yaron >> >> >> _______________________________________________ IPsec mailing list >> IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec >> >> Email secured by Check Point > From vishwas.ietf@gmail.com Wed Dec 5 09:54:15 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8D721F8BAE for ; Wed, 5 Dec 2012 09:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDSDMGlljUd6 for ; Wed, 5 Dec 2012 09:54:13 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 88BA221F8BA9 for ; Wed, 5 Dec 2012 09:54:12 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id z4so2368910qan.10 for ; Wed, 05 Dec 2012 09:54:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rGcwvhhPRX2Ya/7LDQk0ZJvkGHf3m/BZs5KoSJEyrdI=; b=njii3l0hFd5zdIKwfeqAhXP9LaeJXxJKNwvu+AhqBqY27SwSsyPhLz7TvZBeJhmBME do3n7qPBr0jBw6ImN9DpLtc7mJBpmLWD6/+4wXWO6w72qttTE1RwQWyhdWWsbcj0Ll49 Ui1aRDYofCrkQJlZp3URx8I1LO8VApC2XaKoO8+jFB4B834IhnqV9p7LXjBOrMftnzHe ZTGK+aUsPumRJKuDwsfLiBYSXAupNsdtmfxpZLinCXiNttRtwWWrTB7m5bsCpD2ot/G7 Og7rS87uFsDbaIfuhYxSGq9+iytxD2xUxV/sSGa/QyBjbrlfnNv13gAjOkxGfaQ1fk96 EuDg== MIME-Version: 1.0 Received: by 10.49.128.37 with SMTP id nl5mr33817123qeb.59.1354730051885; Wed, 05 Dec 2012 09:54:11 -0800 (PST) Received: by 10.229.92.77 with HTTP; Wed, 5 Dec 2012 09:54:11 -0800 (PST) In-Reply-To: <50BE4A60.1000303@labn.net> References: <50A5703F.4070305@labn.net> <50A58CDB.30402@labn.net> <50A682F8.9080907@labn.net> <50A689A9.1090803@labn.net> <50A68D30.2040203@labn.net> <50BE30D9.4030903@labn.net> <50BE4A60.1000303@labn.net> Date: Wed, 5 Dec 2012 09:54:11 -0800 Message-ID: From: Vishwas Manral To: Lou Berger Content-Type: multipart/mixed; boundary=047d7b676e6e825bc404d01eab7f Cc: IPsecme WG Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 17:54:15 -0000 --047d7b676e6e825bc404d01eab7f Content-Type: multipart/alternative; boundary=047d7b676e6e825bbf04d01eab7d --047d7b676e6e825bbf04d01eab7d Content-Type: text/plain; charset=ISO-8859-1 Hi Lou, Thanks for your close reading of the document. I am attaching the changed document. Please let me know if it looks good. On 11/15/2012 7:14 PM, Vishwas Manral wrote: > > - In section 2.2, I think mentioning something about the routing > > implications is worthwhile. How about at the end of the section > adding > > something along the lines of : > > > > Additionally, the routing implications of gateway-to-gateway > > communication must be addressed. In the simple case, > > selectors provide sufficient information for a gateway to > > forward traffic appropriately. In other cases, additional > > tunneling (e.g., GRE) and routing (e.g., OSPF) protocols are > > run over IPsec tunnels, and the configuration impact on those > > protocols must be considered. There is also the case when > > L3VPNs operate over IPsec Tunnels. > > > > We can add something in the lines of additional protocols are run over > > the IPsec tunnels and the solution should make an effort to allow for > > additional protocols like OSPF to > > Also in section 2.2, the text now says: > > The solution should work in cases where the endpoints are > administrated by separate management domains, albeit, ones that have > an existing trust relationship (for example two organisations who are > collaborating on a project, they may wish to join their networks, > whilst retaining independent control over configuration)It is for > this purpose spoke-to-spoke tunnels are dynamically created and torn- > down. It is highly desirable that the solution works for the star, > full mesh as well as dynamic full mesh topology. > > This revision now reads that the primary reason for dynamic > spoke-to-spoke tunnels is separate management domains. I somehow don't > think this was the intent. > I have reordered the sentences. > > In section 4.1 we had discussed replacement text for 3: > On 11/16/2012 12:49 PM, Vishwas Manral wrote: > >>On 11/15/2012 5:44 PM, Lou Berger wrote: > >> - In section 4.2, how about: > >> (replacement text) > >> 3. Gateways MUST allow for the operation of tunneling and > >> routing protocols operating over spoke-to-spoke IPsec Tunnels > >> with minimal, or no, configuration impact. > > > >VM> Ok will specifically specify tunnels and routing protocols. > > You have the following alternate / revised text: > 3. In many cases additional tunneling protocols (i.e. GRE) or > Routing protocols (i.e. OSPF) are run over the IPsec tunnels. > Gateways MUST allow for the operation of tunneling and Routing > protocols operating over spoke-to-spoke IPsec Tunnels with minimal or > no, configuration impact. Routing using the tunnels can work > seamlessly without any updates to the higher level application > configuration i.e. OSPF configuration, when the tunnel parameter > changes. > > I think this text is closer, but I think a few additional changes are > needed: > - GRE and OSPF are examples, so "i.e." should be replaced with "e.g." > - I think the final sentence is likely to be incorrect in many / most > real world cases, so would drop the sentence (from "Routing using > the tunnels can work...") > I changed the "can" to a SHOULD for the second part. The idea is no changes should happen in configuration and our current solution allows that for most cases (hence SHOULD). > > You also said you'd address the minor comments: > On 11/15/2012 5:44 PM, Lou Berger wrote: > > - In section 2.1, you introduce the term "NAT gateway" and then later > > use just "gateway" when I suspect you mean "NAT gateway". I suggest > > using the term "NAT" and thereby not introduce possible confusion > > between the gateway term defined in section 1.1 and "NAT gateways". > > Updated it. I agree we can separate out the terms NAT gateway/ Gateway, though for most parts it may be the same device. Prepend NAT to change it to NAT gateway, as just replacing it with NAT made the sentence out of place. > and > > > - In sections 2.2, and Section 3.2 you say dynamic addresses makes > > static configuration impossible. This doesn't reflect the use of > > dynamic dns to handle this issues (and is currently supported by some > > vendors.) > > Do you have any reference and suggested text for this? I have not seen the same in our customer cases. Thanks, Vishwas --047d7b676e6e825bbf04d01eab7d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lou,

Thanks for your close reading of the document. I am attachin= g the changed document. Please let me know if it looks good.

On 11/15/2012 7:14 PM, Vishwas Manral wrote:
> =A0 =A0 - In section 2.2, I think mentioning s= omething about the routing
> =A0 =A0 implications is worthwhile. How about at the end of the sectio= n adding
> =A0 =A0 something along the lines of :
>
> =A0 =A0 =A0 =A0 Additionally, the routing implications of gateway-to-g= ateway
> =A0 =A0 =A0 =A0 communication must be addressed. =A0In the simple case= ,
> =A0 =A0 =A0 =A0 selectors provide sufficient information for a gateway= to
> =A0 =A0 =A0 =A0 forward traffic appropriately. =A0In other cases, addi= tional
> =A0 =A0 =A0 =A0 tunneling (e.g., GRE) and routing (e.g., OSPF) protoco= ls are
> =A0 =A0 =A0 =A0 run over IPsec tunnels, and the configuration impact o= n those
> =A0 =A0 =A0 =A0 protocols must be considered. =A0There is also t= he case when
> =A0 =A0 =A0 =A0 L3VPNs operate over IPsec Tunnels. >
> We can add something in the lines of additiona= l protocols are run over
> the IPsec tunnels and the solution should make an effort to allow for<= br> > additional protocols like OSPF to

Also in section 2.2, the text now says:

=A0 =A0The solution should work in cases where the endpoints are
=A0 =A0administrated by separate management domains, albeit, ones that have=
=A0 =A0an existing trust relationship (for example two organisations who ar= e
=A0 =A0collaborating on a project, they may wish to join their networks, =A0 =A0whilst retaining independent control over configuration)It is for =A0 =A0this purpose spoke-to-spoke tunnels are dynamically created and torn= -
=A0 =A0down. =A0It is highly desirable that the solution works for the star= ,
=A0 =A0full mesh as well as dynamic full mesh topology.

This revision now reads that the primary reason for dynamic
spoke-to-spoke tunnels is separate management domains. =A0I somehow don'= ;t
think this was the intent.

I have reordered the se= ntences.

In section 4.1 we had discussed replacement text for 3:
On 11/16/2012 12:49 PM, Vishwas Manral wrote:
>>On 11/15/2012 5:44 PM, Lou Berger wrote: >> =A0 =A0 - In section 4.2, how about:
>> =A0 =A0 =A0 =A0(replacement text)
>> =A0 =A0 =A0 =A03. =A0Gateways MUST allow for the operation of tunn= eling and
>> =A0 =A0 =A0 =A0routing protocols operating over spoke-to-spoke IPs= ec Tunnels
>> =A0 =A0 =A0 =A0with minimal, or no, configuration impact.
>
>VM> Ok will specifically specify tunnels and routing protocols.

You have the following alternate / revised text:
=A0 =A03. =A0In many cases additional tunneling protocols (i.e. =A0GRE) or<= br> =A0 =A0Routing protocols (i.e. =A0OSPF) are run over the IPsec tunnels.
=A0 =A0Gateways MUST allow for the operation of tunneling and Routing
=A0 =A0protocols operating over spoke-to-spoke IPsec Tunnels with minimal o= r
=A0 =A0no, configuration impact. =A0Routing using the tunnels can work
=A0 =A0seamlessly without any updates to the higher level= application
=A0 =A0configuration i.e. =A0OSPF configuration, when the tunnel para= meter
=A0 =A0changes.

I think this text is closer, but I think a few additional changes are
needed:
=A0- GRE and OSPF are examples, so "i.e." should be replaced with= "e.g."
=A0- I think the final sentence is likely to be incorrect in many / most =A0 =A0real world cases, so would drop the sentence (from "Routing usi= ng
=A0 =A0the tunnels can work...")
I changed the &q= uot;can" to a SHOULD for the second part. The idea is no changes shoul= d happen in configuration and our current solution allows that for most cas= es (hence SHOULD).

You also said you'd address the minor comments:
On 11/15/2012 5:44 PM, Lou Berger wrote:
> - In section 2.1, you introduce the term "NAT gateway" and t= hen later
> use just "gateway" when I suspect you mean "NAT gateway= ". =A0I suggest
> using the term "NAT" and thereby not introduce possible conf= usion
> between the gateway term defined in section 1.1 and "NAT gateways= ".

Updated it. I agree we can separate out the ter= ms NAT gateway/ Gateway, though for most parts it may be the same device. P= repend NAT to change it to NAT gateway, as just replacing it with NAT made = the sentence out of place.
=A0
and

> - In sections 2.2, and Section 3.2 you say dynamic addresses makes
> static configuration impossible. =A0This doesn't reflect the use o= f
> dynamic dns to handle this issues (and is currently supported by some<= br> > vendors.)

Do you have any reference and suggested text fo= r this? I have not seen the same in our customer cases.

Thanks= ,
Vishwas

--047d7b676e6e825bbf04d01eab7d-- --047d7b676e6e825bc404d01eab7f Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-ipsecme-ad-vpn-problem-02.txt" Content-Disposition: attachment; filename="draft-ietf-ipsecme-ad-vpn-problem-02.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hacr9nkg0 SVBzZWNNRSBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFMuIEhhbm5hDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmlwZXINCkludGVuZGVkIHN0YXR1czogSW5mb3Jt YXRpb25hbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFYuIE1hbnJhbA0KRXhwaXJl czogSnVuZSA4LCAyMDEzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEhQDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIERlY2VtYmVyIDUsIDIwMTINCg0KDQogICAgICAgICBBdXRvIERpc2NvdmVyeSBW UE4gUHJvYmxlbSBTdGF0ZW1lbnQgYW5kIFJlcXVpcmVtZW50cw0KICAgICAgICAgICAgICAgICAg ZHJhZnQtaWV0Zi1pcHNlY21lLWFkLXZwbi1wcm9ibGVtLTAyDQoNCkFic3RyYWN0DQoNCiAgIFRo aXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBwcm9ibGVtIG9mIGVuYWJsaW5nIGEgbGFyZ2UgbnVt YmVyIG9mDQogICBzeXN0ZW1zIHRvIGNvbW11bmljYXRlIGRpcmVjdGx5IHVzaW5nIElQc2VjIHRv IHByb3RlY3QgdGhlIHRyYWZmaWMNCiAgIGJldHdlZW4gdGhlbS4gIEl0IHRoZW4gZXhwYW5kcyBv biB0aGUgcmVxdWlyZW1lbnRzLCBmb3Igc3VjaCBhDQogICBzb2x1dGlvbi4NCg0KICAgTWFudWFs IGNvbmZpZ3VyYXRpb24gb2YgYWxsIHBvc3NpYmxlIHR1bm5lbHMgaXMgdG9vIGN1bWJlcnNvbWUg aW4NCiAgIG1hbnkgc3VjaCBjYXNlcy4gIEluIG90aGVyIGNhc2VzIHRoZSBJUCBhZGRyZXNzIG9m IGVuZHBvaW50cyBjaGFuZ2UNCiAgIG9yIHRoZSBlbmRwb2ludHMgbWF5IGJlIGJlaGluZCBOQVQg Z2F0ZXdheXMsIG1ha2luZyBzdGF0aWMNCiAgIGNvbmZpZ3VyYXRpb24gaW1wb3NzaWJsZS4gIFRo ZSBBdXRvIERpc2NvdmVyeSBWUE4gc29sdXRpb24gaXMNCiAgIGNoYXJ0ZXJlZCB0byBhZGRyZXNz IHRoZXNlIHJlcXVpcmVtZW50cy4NCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICBUaGlzIElu dGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlDQog ICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMg YXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICAgVGFz ayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1 dGUNCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9m IGN1cnJlbnQgSW50ZXJuZXQtDQogICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBk b2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJl IHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFu eQ0KICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBh cyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3 b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBv biBKdW5lIDgsIDIwMTMuDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KICAgQ29weXJpZ2h0IChjKSAy MDEyIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlDQogICBkb2N1 bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4NCg0KICAgVGhpcyBkb2N1bWVudCBp cyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbA0KICAgUHJvdmlz aW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cw0KICAgKGh0dHA6Ly90cnVzdGVlLmlldGYu b3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mDQoNCg0KDQpIYW5uYSAm IE1hbnJhbCAgICAgICAgICAgIEV4cGlyZXMgSnVuZSA4LCAyMDEzICAgICAgICAgICAgICAgICAg W1BhZ2UgMV0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgQXV0byBEaXNjb3ZlcnkgVlBO ICAgICAgICAgICAgICBEZWNlbWJlciAyMDEyDQoNCg0KICAgcHVibGljYXRpb24gb2YgdGhpcyBk b2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzDQogICBjYXJlZnVsbHksIGFz IHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QN CiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhp cyBkb2N1bWVudCBtdXN0DQogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBh cyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YNCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNp b25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcw0KICAgZGVzY3JpYmVkIGlu IHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLg0KDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCiAg IDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgMw0KICAgICAxLjEuICBUZXJtaW5vbG9neSAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDQogICAgIDEuMi4gIENvbnZlbnRpb25zIFVz ZWQgaW4gVGhpcyBEb2N1bWVudCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQNCiAgIDIuICBV c2UgQ2FzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgNQ0KICAgICAyLjEuICBFbmRwb2ludC10by1FbmRwb2ludCBBRCBWUE4gVXNlIENhc2Ug LiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1DQogICAgIDIuMi4gIEdhdGV3YXktdG8tR2F0ZXdheSBB RCBWUE4gVXNlIENhc2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUNCiAgICAgMi4zLiAgRW5k cG9pbnQtdG8tR2F0ZXdheSBBRCBWUE4gVXNlIENhc2UgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg Ng0KICAgMy4gIEluYWRlcXVhY3kgb2YgRXhpc3RpbmcgU29sdXRpb25zIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICA3DQogICAgIDMuMS4gIEV4aGF1c3RpdmUgQ29uZmlndXJhdGlvbiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcNCiAgICAgMy4yLiAgU3RhciBUb3Bv bG9neSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0KICAg ICAzLjMuICBQcm9wcmlldGFyeSBBcHByb2FjaGVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICA4DQogICA0LiAgUmVxdWlyZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkNCiAgICAgNC4xLiAgR2F0ZXdheSBhbmQgRW5k cG9pbnQgUmVxdWlyZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0KICAgNS4gIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDEyDQogICA2LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMNCiAgIDcuICBBY2tub3dsZWRnZW1lbnRzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNA0KICAgOC4gIE5vcm1hdGl2 ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE1 DQogICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTYNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpIYW5uYSAmIE1hbnJhbCAgICAgICAgICAgIEV4cGlyZXMgSnVuZSA4LCAyMDEzICAg ICAgICAgICAgICAgICAgW1BhZ2UgMl0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgQXV0 byBEaXNjb3ZlcnkgVlBOICAgICAgICAgICAgICBEZWNlbWJlciAyMDEyDQoNCg0KMS4gIEludHJv ZHVjdGlvbg0KDQogICBJUHNlYyBbUkZDNDMwMV0gaXMgdXNlZCBpbiBzZXZlcmFsIGRpZmZlcmVu dCBjYXNlcywgaW5jbHVkaW5nIHR1bm5lbC0NCiAgIG1vZGUgc2l0ZS10by1zaXRlIFZQTnMgYW5k IFJlbW90ZSBBY2Nlc3MgVlBOcy4gIEhvc3QgdG8gaG9zdA0KICAgY29tbXVuaWNhdGlvbiBlbXBs b3lpbmcgdHJhbnNwb3J0IG1vZGUgYWxzbyBleGlzdHMsIGJ1dCBpcyBmYXIgbGVzcw0KICAgY29t bW9ubHkgZGVwbG95ZWQuDQoNCiAgIFRoZSBzdWJqZWN0IG9mIHRoaXMgZG9jdW1lbnQgaXMgdGhl IHByb2JsZW0gcHJlc2VudGVkIGJ5IGxhcmdlIHNjYWxlDQogICBkZXBsb3ltZW50cyBvZiBJUHNl YyBhbmQgdGhlIHJlcXVpcmVtZW50cyBvbiBhIHNvbHV0aW9uIHRvIGFkZHJlc3MNCiAgIHRoZSBw cm9ibGVtLiAgVGhlc2UgbWF5IGJlIGEgbGFyZ2UgY29sbGVjdGlvbiBvZiBWUE4gZ2F0ZXdheXMN CiAgIGNvbm5lY3RpbmcgdmFyaW91cyBzaXRlcywgYSBsYXJnZSBudW1iZXIgb2YgcmVtb3RlIGVu ZHBvaW50cw0KICAgY29ubmVjdGluZyB0byBhIG51bWJlciBvZiBnYXRld2F5cyBvciB0byBlYWNo IG90aGVyLCBvciBhIG1peCBvZiB0aGUNCiAgIHR3by4gIFRoZSBnYXRld2F5cyBhbmQgZW5kcG9p bnRzIG1heSBiZWxvbmcgdG8gYSBzaW5nbGUNCiAgIGFkbWluaXN0cmF0aXZlIGRvbWFpbiBvciBz ZXZlcmFsIGRvbWFpbnMgd2l0aCBhIHRydXN0IHJlbGF0aW9uc2hpcC4NCg0KICAgU2VjdGlvbiA0 LjQgb2YgUkZDIDQzMDEgZGVzY3JpYmVzIHRoZSBtYWpvciBJUHNlYyBkYXRhYmFzZXMgbmVlZGVk DQogICBmb3IgSVBzZWMgcHJvY2Vzc2luZy4gIEl0IHJlcXVpcmVzIGFuIGV4dGVuc2l2ZSBjb25m aWd1cmF0aW9uIGZvcg0KICAgZWFjaCB0dW5uZWwsIHNvIG1hbnVhbGx5IGNvbmZpZ3VyaW5nIGEg c3lzdGVtIG9mIG1hbnkgZ2F0ZXdheXMgYW5kDQogICBlbmRwb2ludHMgYmVjb21lcyBpbmZlYXNp YmxlIGFuZCBpbmZsZXhpYmxlLg0KDQogICBUaGUgZGlmZmljdWx0eSBpcyB0aGF0IGFsbCB0aGUg Y29uZmlndXJhdGlvbiBtZW50aW9uZWQgaW4gUkZDIDQzMDEgaXMNCiAgIG5vdCBzdXBlcmZsdW91 cy4gIElLRSBpbXBsZW1lbnRhdGlvbnMgbmVlZCB0byBrbm93IHRoZSBpZGVudGl0eSBhbmQNCiAg IGNyZWRlbnRpYWxzIG9mIGFsbCBwb3NzaWJsZSBwZWVyIHN5c3RlbXMsIGFzIHdlbGwgYXMgdGhl IGFkZHJlc3NlcyBvZg0KICAgaG9zdHMgYW5kL29yIG5ldHdvcmtzIGJlaGluZCB0aGVtLiAgQSBz aW1wbGlmaWVkIG1lY2hhbmlzbSBmb3INCiAgIGR5bmFtaWNhbGx5IGVzdGFibGlzaGluZyBwb2lu dC10by1wb2ludCB0dW5uZWxzIGlzIG5lZWRlZC4gIFNlY3Rpb24gMg0KICAgY29udGFpbnMgc2V2 ZXJhbCB1c2UgY2FzZXMgdGhhdCBtb3RpdmF0ZSB0aGlzIGVmZm9ydC4NCg0KMS4xLiAgVGVybWlu b2xvZ3kNCg0KICAgRW5kcG9pbnQgLSBBIGRldmljZSB0aGF0IGltcGxlbWVudHMgSVBzZWMgZm9y IGl0cyBvd24gdHJhZmZpYyBidXQNCiAgIGRvZXMgbm90IGFjdCBhcyBhIGdhdGV3YXkuDQoNCiAg IEdhdGV3YXkgLSBBIG5ldHdvcmsgZGV2aWNlIHRoYXQgaW1wbGVtZW50cyBJUHNlYyB0byBwcm90 ZWN0IHRyYWZmaWMNCiAgIGZsb3dpbmcgdGhyb3VnaCB0aGUgZGV2aWNlLg0KDQogICBQb2ludC10 by1Qb2ludCAtIERpcmVjdCBjb21tdW5pY2F0aW9uIGJldHdlZW4gdHdvIHBhcnRpZXMgd2l0aG91 dA0KICAgYWN0aXZlIHBhcnRpY2lwYXRpb24gKGUuZy4gZW5jcnlwdGlvbiBvciBkZWNyeXB0aW9u KSBieSBhbnkgb3RoZXINCiAgIHBhcnRpZXMuDQoNCiAgIEh1YiAtIFRoZSBjZW50cmFsIHBvaW50 IGluIGEgc3RhciB0b3BvbG9neS8gZHluYW1pYyBmdWxsIG1lc2gNCiAgIHRvcG9sb2d5LCBvciBv bmUgb2YgdGhlIGNlbnRyYWwgcG9pbnRzIGluIHRoZSBmdWxsIG1lc2ggc3R5bGUgVlBOLA0KICAg aS5lLiBnYXRld2F5IHdoZXJlIG11bHRpcGxlIG90aGVyIGh1YnMgb3Igc3Bva2VzIGNvbm5lY3Qg dG8uICBUaGUNCiAgIGh1YnMgdXN1YWxseSBmb3J3YXJkIHRyYWZmaWMgY29taW5nIGZyb20gZW5j cnlwdGVkIGxpbmtzIHRvIG90aGVyDQogICBlbmNyeXB0ZWQgbGlua3MsIGkuZS4gdGhlcmUgaXMg bm8gZGV2aWNlcyBjb25uZWN0ZWQgdG8gaXQgaW4gY2xlYXIuDQoNCiAgIFNwb2tlIC0gVGhlIGVk Z2UgZGV2aWNlcyBpbiB0aGUgYSBzdGFyIHRvcG9sb2d5LyBkeW5hbWljIGZ1bGwgbWVzaA0KICAg dG9wb2xvZ3ksIG9yIGdhdGV3YXkgd2hpY2ggZm9yd2FyZHMgdHJhZmZpYyBmcm9tIG11bHRpcGxl IGNsZWFydGV4dA0KICAgZGV2aWNlcyB0byBvdGhlciBodWJzIG9yIHNwb2tlcywgYW5kIHNvbWUg b2YgdGhvc2Ugb3RoZXIgZGV2aWNlcyBhcmUNCg0KDQoNCkhhbm5hICYgTWFucmFsICAgICAgICAg ICAgRXhwaXJlcyBKdW5lIDgsIDIwMTMgICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICBBdXRvIERpc2NvdmVyeSBWUE4gICAgICAgICAgICAgIERl Y2VtYmVyIDIwMTINCg0KDQogICBjb25uZWN0ZWQgdG8gaXQgaW4gY2xlYXIgKGkuZS4gaXQgZW5j cnlwdCBkYXRhIGNvbWluZyBmcm9tIGNsZWFydGV4dA0KICAgZGV2aWNlIGFuZCBmb3J3YXJkcyBp dCB0byB0aGUgQUQgVlBOKS4NCg0KICAgU3RhciB0b3BvbG9neSAtIFRoaXMgaXMgdGhlIHRvcG9s b2d5IHdoZXJlIHRoZXJlIGlzIGRpcmVjdA0KICAgY29ubmVjdGl2aXR5IG9ubHkgYmV0d2VlbiB0 aGUgaHViIGFuZCBzcG9rZSBhbmQgY29tbXVuaWNhdGlvbiBiZXR3ZWVuDQogICB0aGUgMiBzcG9r ZXMgaGFwcGVucyB0aHJvdWdoIHRoZSBodWIuDQoNCiAgIEZ1bGwgTWVzaCB0b3BvbG9neSAtIFRo aXMgaXMgdGhlIHRvcG9sb2d5IHdoZXJlIHRoZXJlIGlzIGEgZGlyZWN0DQogICBjb25uZWN0aXZp dHkgYmV0d2VlbiBldmVyeSBTcG9rZSB0byBldmVyeSBvdGhlciBTcG9rZSBkaXJlY3RseSwNCiAg IHdpdGhvdXQgdGhlIHRyYWZmaWMgYmV0d2VlbiB0aGUgc3Bva2VzIGhhdmluZyB0byBiZSByZWRp cmVjdGVkDQogICB0aHJvdWdoIGFuIGludGVybWVkaWF0ZSBodWIgZGV2aWNlLg0KDQogICBEeW5h bWljIEZ1bGwgTWVzaCB0b3BvbG9neSAtIFRoaXMgaXMgdGhlIHRvcG9sb2d5IHdoZXJlIGRpcmVj dA0KICAgY29ubmVjdGlvbnMgZXhpc3QgaW4gYSBodWIgYW5kIHNwb2tlIG1hbm5lciwgYnV0IGR5 bmFtaWMgY29ubmVjdGlvbnMNCiAgIGFyZSBjcmVhdGVkLyByZW1vdmVkIGJldHdlZW4gdGhlIHNw b2tlcyBvbiBhIG5lZWQgYmFzaXMuDQoNCiAgIFNlY3VyaXR5IEFzc29jaWF0aW9uIChTQSkgLSBE ZWZpbmVkIGluIFtSRkM0MzAxXS4NCg0KMS4yLiAgQ29udmVudGlvbnMgVXNlZCBpbiBUaGlzIERv Y3VtZW50DQoNCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQi LCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNP TU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzDQogICBkb2N1bWVudCBhcmUg dG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4NCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KSGFubmEgJiBNYW5y YWwgICAgICAgICAgICBFeHBpcmVzIEp1bmUgOCwgMjAxMyAgICAgICAgICAgICAgICAgIFtQYWdl IDRdDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgIEF1dG8gRGlzY292ZXJ5IFZQTiAgICAg ICAgICAgICAgRGVjZW1iZXIgMjAxMg0KDQoNCjIuICBVc2UgQ2FzZXMNCg0KICAgVGhpcyBzZWN0 aW9uIHByZXNlbnRzIHRoZSBrZXkgdXNlIGNhc2VzIGZvciBsYXJnZS1zY2FsZSBwb2ludC10by0N CiAgIHBvaW50IFZQTi4NCg0KICAgSW4gYWxsIG9mIHRoZXNlIHVzZSBjYXNlcywgdGhlIHBhcnRp Y2lwYW50cyAoZW5kcG9pbnRzIGFuZCBnYXRld2F5cykNCiAgIG1heSBiZSBmcm9tIGEgc2luZ2xl IG9yZ2FuaXphdGlvbiBvciBmcm9tIG11bHRpcGxlIG9yZ2FuaXphdGlvbnMgd2l0aA0KICAgYW4g ZXN0YWJsaXNoZWQgdHJ1c3QgcmVsYXRpb25zaGlwLiAgV2hlbiBtdWx0aXBsZSBvcmdhbml6YXRp b25zIGFyZQ0KICAgaW52b2x2ZWQsIHByb2R1Y3RzIGZyb20gbXVsdGlwbGUgdmVuZG9ycyBhcmUg ZW1wbG95ZWQgc28gb3Blbg0KICAgc3RhbmRhcmRzIGFyZSBuZWVkZWQgdG8gcHJvdmlkZSBpbnRl cm9wZXJhYmlsaXR5LiAgRXN0YWJsaXNoaW5nDQogICBjb21tdW5pY2F0aW9ucyBiZXR3ZWVuIHBh cnRpY2lwYW50cyB3aXRoIG5vIGVzdGFibGlzaGVkIHRydXN0DQogICByZWxhdGlvbnNoaXAgaXMg b3V0IG9mIHNjb3BlIGZvciB0aGlzIGVmZm9ydC4NCg0KMi4xLiAgRW5kcG9pbnQtdG8tRW5kcG9p bnQgQUQgVlBOIFVzZSBDYXNlDQoNCiAgIFR3byBlbmRwb2ludHMgd2lzaCB0byBjb21tdW5pY2F0 ZSBzZWN1cmVseSB2aWEgYSBkaXJlY3QsIHBvaW50LXRvLQ0KICAgcG9pbnQgU2VjdXJpdHkgQXNz b2NpYXRpb24gKFNBKS4NCg0KICAgVGhlIG5lZWQgZm9yIHNlY3VyZSBlbmRwb2ludCB0byBlbmRw b2ludCBjb21tdW5pY2F0aW9ucyBpcyBvZnRlbg0KICAgZHJpdmVuIGJ5IGEgbmVlZCB0byBlbXBs b3kgaGlnaC1iYW5kd2lkdGgsIGxvdyBsYXRlbmN5IGxvY2FsDQogICBjb25uZWN0aXZpdHkgaW5z dGVhZCBvZiB1c2luZyBzbG93LCBleHBlbnNpdmUgbGlua3MgdG8gcmVtb3RlDQogICBnYXRld2F5 cy4gIEZvciBleGFtcGxlLCB0d28gdXNlcnMgaW4gY2xvc2UgcHJveGltaXR5IG1heSB3aXNoIHRv DQogICBwbGFjZSBhIGRpcmVjdCwgc2VjdXJlIHZpZGVvIG9yIHZvaWNlIGNhbGwgd2l0aG91dCBu ZWVkaW5nIHRvIHNlbmQNCiAgIHRoZSBjYWxsIHRocm91Z2ggcmVtb3RlIGdhdGV3YXlzLCB3aGlj aCB3b3VsZCBhZGQgbGF0ZW5jeSB0byB0aGUNCiAgIGNhbGwsIGNvbnN1bWUgcHJlY2lvdXMgcmVt b3RlIGJhbmR3aWR0aCwgYW5kIGluY3JlYXNlIG92ZXJhbGwgY29zdHMuDQogICBTdWNoIGEgdXNl IGNhc2UgYWxzbyBlbmFibGVzIGNvbm5lY3Rpdml0eSB3aGVuIGJvdGggZW5kcG9pbnRzIGFyZQ0K ICAgYmVoaW5kIE5BVCBnYXRld2F5cy4gIFN1Y2ggdXNlIGNhc2Ugc2hvdWxkIGFsbG93IGZvciBz ZWFtbGVzcw0KICAgY29ubmVjdGl2aXR5IGV2ZW4gYXMgZW5kcG9pbnRzIHJvYW0sIGV2ZW4gaWYg dGhleSBhcmUgbW92aW5nIG91dCBmcm9tDQogICBiZWhpbmQgYSBOQVQgZ2F0ZXdheSwgZnJvbSBi ZWhpbmQgb25lIE5BVCBnYXRld2F5IHRvIGJlaGluZCBhbm90aGVyLA0KICAgb3IgZnJvbSBhIHN0 YW5kYWxvbmUgcG9zaXRpb24gdG8gYmVoaW5kIGEgTkFUIGdhdGV3YXkuDQoNCiAgIEluIGEgaHVi IGFuZCBzcG9rZSB0b3BvbG9neSB3aGVuIHR3byBlbmRwb2ludHMgY29tbXVuaWNhdGUsIHRoZXkg bXVzdA0KICAgdXNlIGEgbWVjaGFuaXNtIGZvciBhdXRoZW50aWNhdGlvbiwgc3VjaCB0aGF0IHRo ZXkgZG8gbm90IGV4cG9zZSB0aGVtDQogICB0byBpbXBlcnNvbmF0aW9uIGJ5IHRoZSBvdGhlciBz cG9rZSBlbmRwb2ludC4NCg0KMi4yLiAgR2F0ZXdheS10by1HYXRld2F5IEFEIFZQTiBVc2UgQ2Fz ZQ0KDQogICBBIHR5cGljYWwgRW50ZXJwcmlzZSB0cmFmZmljIG1vZGVsIGZvbGxvd3MgYSBzdGFy IHRvcG9sb2d5LCB3aXRoIHRoZQ0KICAgZ2F0ZXdheXMgY29ubmVjdGluZyB0byBlYWNoIG90aGVy IHVzaW5nIElQc2VjIHR1bm5lbHMuDQoNCiAgIEhvd2V2ZXIgZm9yIHRoZSB2b2ljZSBhbmQgb3Ro ZXIgcmljaCBtZWRpYSB0cmFmZmljIHRoYXQgcmVxdWlyZXMgYQ0KICAgbG90IG9mIGJhbmR3aWR0 aCBvciBpcyBwZXJmb3JtYW5jZSBzZW5zaXRpdmUsIHRoZSB0cmFmZmljIHRyb21ib25pbmcNCiAg IHRvIHRoZSBodWIgY2FuIGNyZWF0ZSB0cmFmZmljIGJvdHRsZW5lY2tzIG9uIHRoZSBodWIgYW5k IGNhbiBsZWFkIHRvDQogICBhbiBpbmNyZWFzZSBpbiBjb3N0LiAgQSBmdWxseSBtZXNoZWQgc29s dXRpb24gaXMgd291bGQgbWFrZSBiZXN0IHVzZQ0KICAgb2YgdGhlIGF2YWlsYWJsZSBuZXR3b3Jr IGNhcGFjaXR5IGFuZCBwZXJmb3JtYW5jZSBidXQgdGhlIGRlcGxveW1lbnQNCiAgIG9mIGEgZnVs bHkgbWVzaGVkIHNvbHV0aW9uIGludm9sdmVzIGNvbnNpZGVyYWJsZSBjb25maWd1cmF0aW9uLA0K ICAgZXNwZWNpYWxseSB3aGVuIGEgbGFyZ2UgbnVtYmVyIG9mIG5vZGVzIGFyZSBpbnZvbHZlZC4g IEl0IGlzIGZvciB0aGlzDQogICBwdXJwb3NlIHNwb2tlLXRvLXNwb2tlIHR1bm5lbHMgYXJlIGR5 bmFtaWNhbGx5IGNyZWF0ZWQgYW5kIHRvcm4tZG93bi4NCg0KDQoNCkhhbm5hICYgTWFucmFsICAg ICAgICAgICAgRXhwaXJlcyBKdW5lIDgsIDIwMTMgICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0K DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBBdXRvIERpc2NvdmVyeSBWUE4gICAgICAgICAg ICAgIERlY2VtYmVyIDIwMTINCg0KDQogICBGb3IgdGhlIHJlYXNvbnMgb2YgY29zdCBhbmQgbWFu dWFsIGVycm9yIHJlZHVjdGlvbiwgaXQgaXMgZGVzaXJlZA0KICAgdGhhdCB0aGVyZSBiZSBtaW5p bWFsIGNvbmZpZ3VyYXRpb24gb24gZWFjaCBnYXRld2F5Lg0KDQogICBUaGUgc29sdXRpb24gc2hv dWxkIHdvcmsgaW4gY2FzZXMgd2hlcmUgdGhlIGVuZHBvaW50cyBhcmUNCiAgIGFkbWluaXN0cmF0 ZWQgYnkgc2VwYXJhdGUgbWFuYWdlbWVudCBkb21haW5zLCBhbGJlaXQsIG9uZXMgdGhhdCBoYXZl DQogICBhbiBleGlzdGluZyB0cnVzdCByZWxhdGlvbnNoaXAgKGZvciBleGFtcGxlIHR3byBvcmdh bmlzYXRpb25zIHdobyBhcmUNCiAgIGNvbGxhYm9yYXRpbmcgb24gYSBwcm9qZWN0LCB0aGV5IG1h eSB3aXNoIHRvIGpvaW4gdGhlaXIgbmV0d29ya3MsDQogICB3aGlsc3QgcmV0YWluaW5nIGluZGVw ZW5kZW50IGNvbnRyb2wgb3ZlciBjb25maWd1cmF0aW9uKS4gIEl0IGlzDQogICBoaWdobHkgZGVz aXJhYmxlIHRoYXQgdGhlIHNvbHV0aW9uIHdvcmtzIGZvciB0aGUgc3RhciwgZnVsbCBtZXNoIGFz DQogICB3ZWxsIGFzIGR5bmFtaWMgZnVsbCBtZXNoIHRvcG9sb2d5Lg0KDQogICBUaGUgZ2F0ZXdh eXMgY2FuIHRoZW1zZWx2ZXMgY29tZSB1cCBhbmQgZG93biwgZ2V0dGluZyBkaWZmZXJlbnQgSVAN CiAgIGFkZHJlc3NlcyBpbiB0aGUgcHJvY2VzcywgbWFraW5nIHN0YXRpYyBjb25maWd1cmF0aW9u IGltcG9zc2libGUuDQoNCiAgIFdoZW4gdHdvIGdhdGV3YXlzIGNvbW11bmljYXRlLCB0aGV5IG11 c3QgdXNlIGEgbWVjaGFuaXNtIGZvcg0KICAgYXV0aGVudGljYXRpb24sIHN1Y2ggdGhhdCB0aGV5 IGRvIG5vdCBleHBvc2UgdGhlbXNlbHZlcyB0byB0aGUgcmlzaw0KICAgb2YgaW1wZXJzb25hdGlv biBieSB0aGUgb3RoZXIgZW50aXRpZXMuDQoNCjIuMy4gIEVuZHBvaW50LXRvLUdhdGV3YXkgQUQg VlBOIFVzZSBDYXNlDQoNCiAgIEFuIGVuZHBvaW50IHNob3VsZCBiZSBhYmxlIHRvIHVzZSB0aGUg bW9zdCBlZmZpY2llbnQgZ2F0ZXdheSBhcyBpdA0KICAgcm9hbXMgaW4gdGhlIGludGVybmV0Lg0K DQogICBBIG1vYmlsZSB1c2VyIHJvYW1pbmcgb24gdGhlIEludGVybmV0IG1heSBjb25uZWN0IHRv IGEgZ2F0ZXdheSwgd2hpY2gNCiAgIGJlY2F1c2Ugb2Ygcm9hbWluZyBpcyBubyBsb25nZXIgdGhl IG1vc3QgZWZmaWNpZW50IGdhdGV3YXkgdG8gdXNlDQogICAocmVhc29ucyBjb3VsZCBiZSBjb3N0 LyBlZmZpY2llbmN5LyBsYXRlbmN5IG9yIHNvbWUgb3RoZXIgZmFjdG9yKS4NCiAgIFRoZSBtb2Jp bGUgdXNlciBzaG91bGQgYmUgYWJsZSB0byBkaXNjb3ZlciBhbmQgdGhlbiBjb25uZWN0IHRvIHRo ZQ0KICAgY3VycmVudCBtb3N0IGVmZmljaWVudCBnYXRld2F5IHdpdGhvdXQgaGF2aW5nIHRvIHJl aW5pdGlhdGUgdGhlDQogICBjb25uZWN0aW9uLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpIYW5uYSAmIE1hbnJhbCAgICAgICAgICAgIEV4cGlyZXMgSnVuZSA4 LCAyMDEzICAgICAgICAgICAgICAgICAgW1BhZ2UgNl0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgQXV0byBEaXNjb3ZlcnkgVlBOICAgICAgICAgICAgICBEZWNlbWJlciAyMDEyDQoNCg0K My4gIEluYWRlcXVhY3kgb2YgRXhpc3RpbmcgU29sdXRpb25zDQoNCiAgIFNldmVyYWwgc29sdXRp b25zIGV4aXN0IGZvciB0aGUgcHJvYmxlbXMgZGVzY3JpYmVkIGFib3ZlLiAgSG93ZXZlciwNCiAg IG5vbmUgb2YgdGhlc2Ugc29sdXRpb25zIGlzIGFkZXF1YXRlLCBhcyBkZXNjcmliZWQgaGVyZS4N Cg0KMy4xLiAgRXhoYXVzdGl2ZSBDb25maWd1cmF0aW9uDQoNCiAgIE9uZSBzaW1wbGUgc29sdXRp b24gaXMgdG8gY29uZmlndXJlIGFsbCBnYXRld2F5cyBhbmQgZW5kcG9pbnRzIGluDQogICBhZHZh bmNlIHdpdGggYWxsIHRoZSBpbmZvcm1hdGlvbiBuZWVkZWQgdG8gZGV0ZXJtaW5lIHdoaWNoIGdh dGV3YXkgb3INCiAgIGVuZHBvaW50IGlzIG9wdGltYWwgYW5kIHRvIGVzdGFibGlzaCBhbiBTQSB3 aXRoIHRoYXQgZ2F0ZXdheSBvcg0KICAgZW5kcG9pbnQuICBIb3dldmVyLCB0aGlzIHNvbHV0aW9u IGRvZXMgbm90IHNjYWxlIGluIGEgbGFyZ2UgbmV0d29yaw0KICAgd2l0aCBodW5kcmVkcyBvZiB0 aG91c2FuZHMgb2YgZ2F0ZXdheXMgYW5kIGVuZHBvaW50cywgZXNwZWNpYWxseSB3aGVuDQogICBt dWx0aXBsZSBvcmdhbml6YXRpb25zIGFyZSBpbnZvbHZlZCBhbmQgdGhpbmdzIGFyZSByYXBpZGx5 IGNoYW5naW5nDQogICAoZS5nLiBtb2JpbGUgZW5kcG9pbnRzKS4gIFN1Y2ggYSBzb2x1dGlvbiBp cyBhbHNvIGxpbWl0ZWQgYnkgdGhlDQogICBzbWFsbGVzdCBlbmRwb2ludC8gZ2F0ZXdheSwgYXMg dGhlIHNhbWUgZXhoYXVzdGl2ZSBjb25maWd1cmF0aW9uIGlzDQogICB0byBiZSBhcHBsaWVkIG9u IGFsbCBlbmRwb2ludHMvIGdhdGV3YXlzLiAgQSBtb3JlIGR5bmFtaWMsIHNlY3VyZSBhbmQNCiAg IHNjYWxhYmxlIHN5c3RlbSBmb3IgZXN0YWJsaXNoaW5nIFNBcyBiZXR3ZWVuIGdhdGV3YXlzIGlz IG5lZWRlZC4NCg0KMy4yLiAgU3RhciBUb3BvbG9neQ0KDQogICBUaGUgbW9zdCBjb21tb24gd2F5 IHRvIGFkZHJlc3MgYSBwYXJ0IG9mIHRoaXMgdGhpcyBwcm9ibGVtIHRvZGF5IGlzDQogICB0byB1 c2Ugd2hhdCBoYXMgYmVlbiB0ZXJtZWQgYSAic3RhciB0b3BvbG9neSIuICBJbiB0aGlzIGNhc2Ug b25lIG9yIGENCiAgIGZldyBnYXRld2F5cyBhcmUgZGVmaW5lZCBhcyAiaHViIGdhdGV3YXlzIiwg d2hpbGUgdGhlIHJlc3Qgb2YgdGhlDQogICBzeXN0ZW1zICh3aGV0aGVyIGVuZHBvaW50cyBvciBn YXRld2F5cykgYXJlIGRlZmluZWQgYXMgInNwb2tlcyIuICBUaGUNCiAgIHNwb2tlcyBuZXZlciBj b25uZWN0IHRvIG90aGVyIHNwb2tlcy4gIFRoZXkgb25seSBvcGVuIHR1bm5lbHMgd2l0aA0KICAg dGhlIGh1YiBnYXRld2F5cy4gIEFsc28gZm9yIGEgbGFyZ2UgbnVtYmVyIG9mIGdhdGV3YXlzIGlu IG9uZQ0KICAgYWRtaW5pc3RyYXRpdmUgZG9tYWluLCBvbmUgZ2F0ZXdheSBtYXkgYmUgZGVmaW5l ZCBhcyB0aGUgaHViLCBhbmQgdGhlDQogICByZXN0IG9mIHRoZSBnYXRld2F5cyBhbmQgcmVtb3Rl IGFjY2VzcyBjbGllbnRzIGNvbm5lY3Qgb25seSB0byB0aGF0DQogICBnYXRld2F5Lg0KDQogICBU aGlzIHNvbHV0aW9uIGhvd2V2ZXIgZG9lcyBub3Qgd29yayB3aGVuIHRoZSBzcG9rZXMgZ2V0IGR5 bmFtaWMgSVANCiAgIGFkZHJlc3Mgd2hpY2ggdGhlICJodWIgZ2F0ZXdheXMiIGNhbm5vdCBiZSBj b25maWd1cmVkIHdpdGguICBJdCBpcw0KICAgYWxzbyBkZXNpcmVkIHRoYXQgdGhlcmUgaXMgbWlu aW1hbCB0byBubyBjb25maWd1cmF0aW9uIG9uIHRoZSBodWIgYXMNCiAgIHRoZSBudW1iZXIgb2Yg c3Bva2VzIGluY3JlYXNlcyBhbmQgbmV3IHNwb2tlcyBhcmUgYWRkZWQgYW5kIGRlbGV0ZWQNCiAg IHJhbmRvbWx5Lg0KDQogICBBbm90aGVyIHByb2JsZW0gd2l0aCB0aGUgc3RhciB0b3BvbG9neSBp cyB0aGF0IGl0IGNyZWF0ZXMgYSBoaWdoIGxvYWQNCiAgIG9uIHRoZSBodWIgZ2F0ZXdheXMgYXMg d2VsbCBhcyBvbiB0aGUgY29ubmVjdGlvbiBiZXR3ZWVuIHRoZSBzcG9rZXMNCiAgIGFuZCB0aGUg aHViLiAgVGhpcyBsb2FkIGlzIGJvdGggaW4gcHJvY2Vzc2luZyBwb3dlciBhbmQgaW4gbmV0d29y aw0KICAgYmFuZHdpZHRoLiAgQSBzaW5nbGUgcGFja2V0IGluIHRoZSBodWItYW5kLXNwb2tlIHNj ZW5hcmlvIGNhbiBiZQ0KICAgZW5jcnlwdGVkIGFuZCBkZWNyeXB0ZWQgbXVsdGlwbGUgdGltZXMu ICBJdCB3b3VsZCBiZSBtdWNoIHByZWZlcmFibGUNCiAgIGlmIHRoZXNlIGdhdGV3YXlzIGFuZCBj bGllbnRzIGNvdWxkIGluaXRpYXRlIHR1bm5lbHMgYmV0d2VlbiB0aGVtLA0KICAgYnlwYXNzaW5n IHRoZSBodWIgZ2F0ZXdheXMuICBBZGRpdGlvbmFsbHksIHRoZSBwYXRoIGJhbmR3aWR0aCB0bw0K ICAgdGhlc2UgaHViIGdhdGV3YXlzIG1heSBiZSBsb3dlciB0aGFuIHRoYXQgb2YgdGhlIHBhdGgg YmV0d2VlbiB0aGUNCiAgIHNwb2tlcy4gIEZvciBleGFtcGxlLCB0d28gcmVtb3RlIGFjY2VzcyB1 c2VycyBtYXkgYmUgaW4gdGhlIHNhbWUNCiAgIGJ1aWxkaW5nIHdpdGggaGlnaC1zcGVlZCB3aWZp IChmb3IgZXhhbXBsZSwgYXQgYW4gSUVURiBtZWV0aW5nKS4NCiAgIENoYW5uZWxpbmcgdGhlaXIg Y29udmVyc2F0aW9uIHRocm91Z2ggdGhlIGh1YiBnYXRld2F5cyBvZiB0aGVpcg0KICAgcmVzcGVj dGl2ZSBlbXBsb3llcnMgc2VlbXMgZXh0cmVtZWx5IHdhc3RlZnVsLCBhcyB3ZWxsIGFzIGhhdmlu Zw0KDQoNCg0KSGFubmEgJiBNYW5yYWwgICAgICAgICAgICBFeHBpcmVzIEp1bmUgOCwgMjAxMyAg ICAgICAgICAgICAgICAgIFtQYWdlIDddDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgIEF1 dG8gRGlzY292ZXJ5IFZQTiAgICAgICAgICAgICAgRGVjZW1iZXIgMjAxMg0KDQoNCiAgIGxvd2Vy IGJhbmR3aWR0aC4NCg0KICAgVGhlIGNoYWxsZW5nZSBpcyB0byBidWlsZCBhIGxhcmdlIHNjYWxl LCBJUHNlYyBwcm90ZWN0ZWQgbmV0d29ya3MNCiAgIHRoYXQgY2FuIGR5bmFtaWNhbGx5IGNoYW5n ZSB3aXRoIG1pbmltdW0gYWRtaW5pc3RyYXRpdmUgb3ZlcmhlYWQuDQoNCjMuMy4gIFByb3ByaWV0 YXJ5IEFwcHJvYWNoZXMNCg0KICAgU2V2ZXJhbCB2ZW5kb3JzIG9mZmVyIHByb3ByaWV0YXJ5IHNv bHV0aW9ucyB0byB0aGVzZSBwcm9ibGVtcy4NCiAgIEhvd2V2ZXIsIHRoZXNlIHNvbHV0aW9ucyBv ZmZlciBubyBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gZXF1aXBtZW50DQogICBmcm9tIG9uZSB2 ZW5kb3IgYW5kIGFub3RoZXIuICBUaGlzIG1lYW5zIHRoYXQgdGhleSBhcmUgZ2VuZXJhbGx5DQog ICByZXN0cmljdGVkIHRvIHVzZSB3aXRoaW4gb25lIG9yZ2FuaXphdGlvbiwgYW5kIGl0IGlzIGhh cmRlciB0byBtb3ZlDQogICBvZmYgc3VjaCBzb2x1dGlvbnMgYXMgdGhlIGZlYXR1cmVzIGFyZSBu b3Qgc3RhbmRhcmRpemVkLiAgQmVzaWRlcw0KICAgbXVsdGlwbGUgb3JnYW5pemF0aW9ucyBjYW5u b3QgYmUgZXhwZWN0ZWQgdG8gYWxsIGNob29zZSB0aGUgc2FtZQ0KICAgZXF1aXBtZW50IHZlbmRv ci4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KSGFubmEgJiBNYW5yYWwgICAgICAgICAgICBFeHBpcmVzIEp1 bmUgOCwgMjAxMyAgICAgICAgICAgICAgICAgIFtQYWdlIDhdDQoNCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgIEF1dG8gRGlzY292ZXJ5IFZQTiAgICAgICAgICAgICAgRGVjZW1iZXIgMjAxMg0K DQoNCjQuICBSZXF1aXJlbWVudHMNCg0KICAgVGhpcyBzZWN0aW9uZGVmaW5lcyB0aGUgcmVxdWly ZW1lbnRzLCBvbiB3aGljaCB0aGUgc29sdXRpb24gd2lsbCBiZQ0KICAgYmFzZWQuDQoNCjQuMS4g IEdhdGV3YXkgYW5kIEVuZHBvaW50IFJlcXVpcmVtZW50cw0KDQogICAxLiAgRm9yIGFueSBuZXR3 b3JrIHRvcG9sb2d5IChzdGFyLCBmdWxsIG1lc2ggYW5kIGR5bmFtaWMgZnVsbCBtZXNoKQ0KICAg Z2F0ZXdheXMgYW5kIGVuZHBvaW50cyBNVVNUIG1pbmltaXplIGNvbmZpZ3VyYXRpb24gY2hhbmdl cyB3aGVuIGEgbmV3DQogICBnYXRld2F5IG9yIGVuZHBvaW50IGlzIGFkZGVkLCByZW1vdmVkIG9y IGNoYW5nZWQuICBBZGRpbmcgb3IgcmVtb3ZpbmcNCiAgIGEgc3Bva2UgaW4gdGhlIHRvcG9sb2d5 IE1VU1QgTk9UIHJlcXVpcmUgY29uZmlndXJhdGlvbiBjaGFuZ2VzIHRvIHRoZQ0KICAgaHVicyBv dGhlciB0aGFuIHdoZXJlIHRoZSBzcG9rZSB3YXMgY29ubmVjdGVkIHRvIGFuZCBTSE9VTEQgTk9U DQogICByZXF1aXJlIGNvbmZpZ3VyYXRpb24gY2hhbmdlcyB0byB0aGUgaHViIHRoZSBzcG9rZSB3 YXMgY29ubmVjdGVkIHRvLg0KICAgVGhlIGNoYW5nZXMgYWxzbyBNVVNUIE5PVCByZXF1aXJlIGNv bmZpZ3VyYXRpb24gY2hhbmdlcyBpbiBvdGhlcg0KICAgc3Bva2VzLg0KDQogICBTcGVjaWZpY2Fs bHksIHdoZW4gZXZhbHVhdGluZyBwb3RlbnRpYWwgcHJvcG9zYWxzLCB3ZSB3aWxsIGNvbXBhcmUN CiAgIHRoZW0gYnkgbG9va2luZyBhdCBob3cgbWFueSBlbmRwb2ludHMgb3IgZ2F0ZXdheXMgbXVz dCBiZQ0KICAgcmVjb25maWd1cmVkIHdoZW4gYSBuZXcgZ2F0ZXdheSBvciBlbmRwb2ludCBpcyBh ZGRlZCwgcmVtb3ZlZCwgb3INCiAgIGNoYW5nZWQgYW5kIGhvdyBzdWJzdGFudGlhbCB0aGlzIHJl Y29uZmlndXJhdGlvbiBpcywgYmVzaWRlcyB0aGUNCiAgIGFtb3VudCBvZiBzdGF0aWMgY29uZmln dXJhdGlvbiByZXF1aXJlZC4NCg0KICAgVGhpcyByZXF1aXJlbWVudCBpcyBkcml2ZW4gYnkgdXNl IGNhc2VzIDIuMSBhbmQgMi4yIGFuZCBieSB0aGUNCiAgIHNjYWxpbmcgbGltaXRhdGlvbnMgcG9p bnRlZCBvdXQgaW4gc2VjdGlvbiAzLjEuDQoNCiAgIDIuICBHYXRld2F5cyBhbmQgZW5kcG9pbnRz IE1VU1QgYWxsb3cgSVBzZWMgVHVubmVscyB0byBiZSBzZXR1cA0KICAgd2l0aG91dCBhbnkgY29u ZmlndXJhdGlvbiBjaGFuZ2VzLCBldmVuIHdoZW4gcGVlciBhZGRyZXNzZXMgZ2V0DQogICB1cGRh dGVkIGV2ZXJ5IHRpbWUgdGhlIGRldmljZSBjb21lcyB1cC4gIFRoaXMgaW1wbGllcyB0aGF0IFNQ RA0KICAgZW50cmllcyBvciBvdGhlciBjb25maWd1cmF0aW9uIGJhc2VkIG9uIHBlZXIgSVAgYWRk cmVzcyB3aWxsIG5lZWQgdG8NCiAgIGJlIGF1dG9tYXRpY2FsbHkgdXBkYXRlZCwgYXZvaWRlZCwg b3IgaGFuZGxlZCBpbiBzb21lIG1hbm5lciB0byBhdm9pZA0KICAgYSBuZWVkIHRvIG1hbnVhbGx5 IHVwZGF0ZSBwb2xpY3kgd2hlbmV2ZXIgYW4gYWRkcmVzcyBjaGFuZ2VzLg0KDQogICBUaGlzIHJl cXVpcmVtZW50IGlzIGRyaXZlbiBieSB1c2UgY2FzZXMgMi4xIGFuZCAyLjIgYW5kIGJ5IHRoZQ0K ICAgc2NhbGluZyBsaW1pdGF0aW9ucyBwb2ludGVkIG91dCBpbiBzZWN0aW9uIDMuMS4NCg0KICAg My4gIEluIG1hbnkgY2FzZXMgYWRkaXRpb25hbCB0dW5uZWxpbmcgcHJvdG9jb2xzIChlLmcuICBH UkUpIG9yDQogICBSb3V0aW5nIHByb3RvY29scyAoZS5nLiAgT1NQRikgYXJlIHJ1biBvdmVyIHRo ZSBJUHNlYyB0dW5uZWxzLg0KICAgR2F0ZXdheXMgTVVTVCBhbGxvdyBmb3IgdGhlIG9wZXJhdGlv biBvZiB0dW5uZWxpbmcgYW5kIFJvdXRpbmcNCiAgIHByb3RvY29scyBvcGVyYXRpbmcgb3ZlciBz cG9rZS10by1zcG9rZSBJUHNlYyBUdW5uZWxzIHdpdGggbWluaW1hbCBvcg0KICAgbm8sIGNvbmZp Z3VyYXRpb24gaW1wYWN0LiAgUm91dGluZyB1c2luZyB0aGUgdHVubmVscyBTSE9VTEQgd29yaw0K ICAgc2VhbWxlc3NseSB3aXRob3V0IGFueSB1cGRhdGVzIHRvIHRoZSBoaWdoZXIgbGV2ZWwgYXBw bGljYXRpb24NCiAgIGNvbmZpZ3VyYXRpb24gaS5lLiAgT1NQRiBjb25maWd1cmF0aW9uLCB3aGVu IHRoZSB0dW5uZWwgcGFyYW1ldGVyDQogICBjaGFuZ2VzLg0KDQogICA0LiAgSW4gdGhlIGZ1bGwg bWVzaCBhbmQgZHluYW1pYyBmdWxsIG1lc2ggdG9wb2xvZ3ksIFNwb2tlcyBNVVNUDQogICBhbGxv dyBmb3IgZGlyZWN0IGNvbW11bmljYXRpb24gd2l0aCBvdGhlciBzcG9rZSBnYXRld2F5cyBhbmQN CiAgIGVuZHBvaW50cy4gIEluIHRoZSBzdGFyIHRvcG9sb2d5IG1vZGUsIGRpcmVjdCBjb21tdW5p Y2F0aW9uIGJldHdlZW4NCiAgIHNwb2tlcyBNVVNUIGJlIGRpc2FsbG93ZWQuDQoNCg0KDQpIYW5u YSAmIE1hbnJhbCAgICAgICAgICAgIEV4cGlyZXMgSnVuZSA4LCAyMDEzICAgICAgICAgICAgICAg ICAgW1BhZ2UgOV0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgQXV0byBEaXNjb3Zlcnkg VlBOICAgICAgICAgICAgICBEZWNlbWJlciAyMDEyDQoNCg0KICAgVGhpcyByZXF1aXJlbWVudCBp cyBkcml2ZW4gYnkgdXNlIGNhc2VzIDIuMSBhbmQgMi4yIGFuZCBieSB0aGUNCiAgIGxpbWl0YXRp b25zIG9mIGEgc3RhciB0b3BvbG9neSBwb2ludGVkIG91dCBpbiBzZWN0aW9uIDMuMi4NCg0KICAg NS4gIE9uZSBzcG9rZSBNVVNUIE5PVCBiZSBhYmxlIHRvIGltcGVyc29uYXRlIGFub3RoZXIgc3Bv a2UuDQoNCiAgIFRoaXMgcmVxdWlyZW1lbnQgaXMgZHJpdmVuIGJ5IHVzZSBjYXNlIDIuMS4gIFNw b2tlcyBiZWNvbWUNCiAgIGNvbXByb21pc2VkIGZhaXJseSBvZnRlbi4gIFRoZSBjb21wcm9taXNl IG9mIG9uZSBTcG9rZSBzaG91bGQgbm90DQogICBhZmZlY3QgdGhlIHNlY3VyaXR5IG9mIG90aGVy IGVuZHBvaW50cy4NCg0KICAgNi4gIEdhdGV3YXlzIFNIT1VMRCBhbGxvdyBmb3Igc2VhbWxlc3Mg aGFuZG9mZiBvZiBzZXNzaW9ucyBpbiBjYXNlDQogICBlbmRwb2ludHMgYXJlIHJvYW1pbmcsIGV2 ZW4gaWYgdGhleSBjcm9zcyBwb2xpY3kgYm91bmRhcmllcy4gIFRoaXMNCiAgIHdvdWxkIG1lYW4g dGhlIGRhdGEgdHJhZmZpYyBpcyBtaW5pbWFsbHkgYWZmZWN0ZWQgZXZlbiBhcyB0aGUgaGFuZG9m Zg0KICAgaGFwcGVucy4gIEV4dGVybmFsIGZhY3RvcnMgbGlrZSBmaXJld2FsbCwgTkFUIGJveCB3 aWxsIG5vdCBiZQ0KICAgY29uc2lkZXJlZCBwYXJ0IG9mIHRoaXMgc29sdXRpb24uDQoNCiAgIFRo aXMgcmVxdWlyZW1lbnQgaXMgZHJpdmVuIGJ5IHVzZSBjYXNlIDIuMS4gIFRvZGF5J3MgZW5kcG9p bnRzIGFyZQ0KICAgbW9iaWxlIGFuZCB0cmFuc2l0aW9uIG9mdGVuIGJldHdlZW4gZGlmZmVyZW50 IG5ldHdvcmtzIChmcm9tIDRHIHRvDQogICBXaUZpIGFuZCBhbW9uZyB2YXJpb3VzIFdpRmkgbmV0 d29ya3MpLg0KDQogICA3LiAgR2F0ZXdheXMgU0hPVUxEIGFsbG93IGZvciBlYXN5IGhhbmRvZmYg b2YgYSBzZXNzaW9uIHRvIGFub3RoZXINCiAgIGdhdGV3YXksIHRvIG9wdGltaXplIGxhdGVuY3ks IGJhbmR3aWR0aCwgbG9hZCBiYWxhbmNpbmcsDQogICBhdmFpbGFiaWxpdHksIG9yIG90aGVyIGZh Y3RvcnMsIGJhc2VkIG9uIHBvbGljeS4NCg0KICAgVGhpcyByZXF1aXJlbWVudCBpcyBkcml2ZW4g YnkgdXNlIGNhc2UgMi4zLg0KDQogICA4LiAgR2F0ZXdheXMgYW5kIGVuZHBvaW50cyBNVVNUIGJl IGFibGUgdG8gd29yayB3aGVuIHRoZXkgYXJlIGJlaGluZA0KICAgTkFUIGJveGVzLiAgSXQgaXMg ZXNwZWNpYWxseSBkaWZmaWN1bHQgdG8gaGFuZGxlIGNhc2VzIHdoZXJlIHRoZSBIdWINCiAgIGlz IGJlaGluZCBhIE5BVCBib3gsIHN1Y2ggYSByZXF1aXJlbWVudCBNQVkgYmUgc3VwcG9ydGVkLiAg V2hlcmUgdGhlDQogICB0d28gZW5kcG9pbnRzIGFyZSBib3RoIGJlaGluZCBzZXBhcmF0ZSBOQVRz LCBjb21tdW5pY2F0aW9uIGJldHdlZW4NCiAgIHRoZXNlIHNwb2tlcyBTSE9VTEQgYmUgc3VwcG9y dGVkLiAgSW4gdGhlIGNhc2VzLCB3b3JrYXJvdW5kcyBNQVkgYmUNCiAgIHVzZWQgc3VjaCBhcyBw b3J0IGZvcndhcmRpbmcgYnkgdGhlIE5BVCBvciBkZXRlY3Rpbmcgd2hlbiB0d28gc3Bva2VzDQog ICBhcmUgYmVoaW5kIHVuY29vcGVyYXRpdmUgTkFUcyBhbmQgdXNpbmcgYSBodWIgaW4gdGhhdCBj YXNlLg0KDQogICBUaGlzIHJlcXVpcmVtZW50IGlzIGRyaXZlbiBieSB1c2UgY2FzZXMgMi4xIGFu ZCAyLjIuICBFbmRwb2ludHMgYXJlDQogICBvZnRlbiBiZWhpbmQgTkFUcyBhbmQgZ2F0ZXdheXMg c29tZXRpbWVzIGFyZS4gIElQc2VjIHNob3VsZCBjb250aW51ZQ0KICAgdG8gd29yayBzZWFtbGVz c2x5IHJlZ2FyZGxlc3MsIHVzaW5nIEFEIFZQTiB0ZWNobmlxdWVzIHdoZW5ldmVyDQogICBwb3Nz aWJsZSBhbmQgcHJvdmlkaW5nIGdyYWNlZnVsIGZhbGxiYWNrIHRvIGh1YiBhbmQgc3Bva2UgdGVj aG5pcXVlcw0KICAgYXMgbmVlZGVkLg0KDQogICA5LiAgQ2hhbmdlcyBzdWNoIGFzIGVzdGFibGlz aGluZyBhIG5ldyBJUHNlYyBTQSBTSE9VTEQgYmUgcmVwb3J0YWJsZQ0KICAgYW5kIG1hbmFnZWFi bGUuICBIb3dldmVyLCBjcmVhdGluZyBhIE1JQiBvciBvdGhlciBtYW5hZ2VtZW50DQogICB0ZWNo bmlxdWUgaXMgbm90IHdpdGhpbiBzY29wZSBmb3IgdGhpcyBlZmZvcnQuDQoNCiAgIFRoaXMgcmVx dWlyZW1lbnQgaXMgZHJpdmVuIGJ5IG1hbmFnZWFiaWxpdHkgY29uY2VybnMgZm9yIGFsbCB0aGUg dXNlDQogICBjYXNlcywgZXNwZWNpYWxseSB1c2UgY2FzZSAyLjIuICBBcyBJUHNlYyBuZXR3b3Jr cyBiZWNvbWUgbW9yZQ0KICAgZHluYW1pYywgbWFuYWdlbWVudCB0b29scyBiZWNvbWUgbW9yZSBl c3NlbnRpYWwuDQoNCiAgIDEwLiAgVG8gc3VwcG9ydCBhbGxpZWQgYW5kIGZlZGVyYXRlZCBlbnZp cm9ubWVudHMsIGVuZHBvaW50cyBhbmQNCg0KDQoNCkhhbm5hICYgTWFucmFsICAgICAgICAgICAg RXhwaXJlcyBKdW5lIDgsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0KDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICBBdXRvIERpc2NvdmVyeSBWUE4gICAgICAgICAgICAgIERlY2Vt YmVyIDIwMTINCg0KDQogICBnYXRld2F5cyBmcm9tIGRpZmZlcmVudCBvcmdhbml6YXRpb25zIFNI T1VMRCBiZSBhYmxlIHRvIGNvbm5lY3QgdG8NCiAgIGVhY2ggb3RoZXIuDQoNCiAgIDExLiAgVGhl IGFkbWluaXN0cmF0b3Igb2YgdGhlIEFEVlBOIFNIT1VMRCBhbGxvdyBmb3IgdGhlDQogICBjb25m aWd1cmF0aW9uIG9mIGEgU3RhciwgRnVsbCBtZXNoIG9yIGEgcGFydGlhbCBmdWxsIG1lc2ggdG9w b2xvZ3ksDQogICBiYXNlZCBvbiB3aGljaCB0dW5uZWxzIGFyZSBhbGxvd2VkIHRvIGJlIHNldHVw Lg0KDQogICBUaGlzIHJlcXVpcmVtZW50IGlzIGRyaXZlbiBieSBkZW1hbmQgZm9yIGFsbCB0aGUg dXNlIGNhc2VzIGluDQogICBmZWRlcmF0ZWQgYW5kIGFsbGllZCBlbnZpcm9ubWVudHMuDQoNCiAg IDEyLiAgVGhlIEFEVlBOIHNvbHV0aW9uIFNIT1VMRCBiZSBhYmxlIHRvIHNjYWxlIGZvciBtdWx0 aWNhc3QNCiAgIHRyYWZmaWMuDQoNCiAgIFRoaXMgcmVxdWlyZW1lbnQgaXMgZHJpdmVuIGJ5IHRo ZSB1c2UgY2FzZSAyLjIsIHdoZXJlIHRoZSBhbW91bnQgb2YNCiAgIHJpY2ggbWVkaWEgbXVsdGlj YXN0IHRyYWZmaWMgaXMgaW5jcmVhc2luZy4NCg0KICAgMTMuICBUaGUgQURWUE4gc29sdXRpb24g U0hPVUxEIGFsbG93IGZvciBlYXN5IG1vbml0b3JpbmcsIGxvZ2dpbmcgYW5kDQogICByZXBvcnRp bmcgb2YgdGhlIGR5bmFtaWMgY2hhbmdlcywgdG8gaGVscCBmb3IgdHJvdWJsZSBzaG9vdGluZyBz dWNoDQogICBlbnZpcm9ubWVudHMuDQoNCiAgIFRoaXMgcmVxdWlyZW1lbnQgaXMgZHJpdmVuIGJ5 IGRlbWFuZCBmb3IgYWxsIHRoZSB1c2UgY2FzZXMgaW4NCiAgIGZlZGVyYXRlZCBhbmQgYWxsaWVk IGVudmlyb25tZW50cy4NCg0KICAgMTQuICBUaGUgQURWUE4gc29sdXRpb24gTVVTVCBzdXBwb3J0 IFByb3ZpZGVyIEVkZ2UgKFBFKSBiYXNlZCBWUE4ncy4NCg0KICAgVGhpcyByZXF1aXJlbWVudCBp cyBkcml2ZW4gYnkgZGVtYW5kIGZvciBhbGwgdGhlIHVzZSBjYXNlcyBpbg0KICAgZmVkZXJhdGVk IGFuZCBhbGxpZWQgZW52aXJvbm1lbnRzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KSGFubmEgJiBNYW5yYWwgICAgICAgICAgICBFeHBpcmVzIEp1bmUg OCwgMjAxMyAgICAgICAgICAgICAgICAgW1BhZ2UgMTFdDQoNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgIEF1dG8gRGlzY292ZXJ5IFZQTiAgICAgICAgICAgICAgRGVjZW1iZXIgMjAxMg0KDQoN CjUuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBUaGUgc29sdXRpb24gdG8gdGhlIHBy b2JsZW1zIHByZXNlbnRlZCBpbiB0aGlzIGRyYWZ0IG1heSBpbnZvbHZlDQogICBkeW5hbWljIHVw ZGF0ZXMgdG8gZGF0YWJhc2VzIGRlZmluZWQgYnkgUkZDIDQzMDEsIHN1Y2ggYXMgdGhlDQogICBT ZWN1cml0eSBQb2xpY3kgRGF0YWJhc2UgKFNQRCkgb3IgdGhlIFBlZXIgQXV0aG9yaXphdGlvbiBE YXRhYmFzZQ0KICAgKFBBRCkuDQoNCiAgIFJGQyA0MzAxIGlzIHNpbGVudCBhYm91dCB0aGUgd2F5 IHRoZXNlIGRhdGFiYXNlcyBhcmUgcG9wdWxhdGVkLCBhbmQNCiAgIGl0IGlzIGltcGxpZWQgdGhh dCB0aGVzZSBkYXRhYmFzZXMgYXJlIHN0YXRpYyBhbmQgcHJlLWNvbmZpZ3VyZWQgYnkgYQ0KICAg aHVtYW4uICBBbGxvd2luZyBkeW5hbWljIHVwZGF0ZXMgdG8gdGhlc2UgZGF0YWJhc2VzIG11c3Qg YmUgdGhvdWdodA0KICAgb3V0IGNhcmVmdWxseSwgYmVjYXVzZSBpdCBhbGxvd3MgdGhlIHByb3Rv Y29sIHRvIGFsdGVyIHRoZSBzZWN1cml0eQ0KICAgcG9saWN5IHRoYXQgdGhlIElQc2VjIGVuZHBv aW50cyBpbXBsZW1lbnQuDQoNCiAgIE9uZSBvYnZpb3VzIGF0dGFjayB0byB3YXRjaCBvdXQgZm9y IGlzIHN0ZWFsaW5nIHRyYWZmaWMgdG8gYQ0KICAgcGFydGljdWxhciBzaXRlLiAgVGhlIElQIGFk ZHJlc3MgZm9yIHd3dy5leGFtcGxlLmNvbSBpcyAxOTIuMC4yLjEwLg0KICAgSWYgd2UgYWRkIGFu IGVudHJ5IHRvIGFuIElQc2VjIGVuZHBvaW50J3MgU1BEIHRoYXQgc2F5cyB0aGF0IHRyYWZmaWMN CiAgIHRvIDE5Mi4wLjIuMTAgaXMgcHJvdGVjdGVkIHRocm91Z2ggcGVlciBHdy1NYWxsb3J5LCB0 aGVuIHRoaXMgYWxsb3dzDQogICBHdy1NYWxsb3J5IHRvIGVpdGhlciBwcmV0ZW5kIHRvIGJlIHd3 dy5leGFtcGxlLmNvbSBvciB0byBwcm94eSBhbmQNCiAgIHJlYWQgYWxsIHRyYWZmaWMgdG8gdGhh dCBzaXRlLiAgVXBkYXRlcyB0byB0aGlzIGRhdGFiYXNlIHJlcXVpcmVzIGENCiAgIGNsZWFyIHRy dXN0IG1vZGVsLg0KDQogICBNb3JlIHRvIGJlIGFkZGVkLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkhhbm5hICYgTWFucmFsICAgICAg ICAgICAgRXhwaXJlcyBKdW5lIDgsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDEyXQ0KDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBBdXRvIERpc2NvdmVyeSBWUE4gICAgICAgICAgICAg IERlY2VtYmVyIDIwMTINCg0KDQo2LiAgSUFOQSBDb25zaWRlcmF0aW9ucw0KDQogICBObyBhY3Rp b25zIGFyZSByZXF1aXJlZCBmcm9tIElBTkEgZm9yIHRoaXMgaW5mb3JtYXRpb25hbCBkb2N1bWVu dC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkhhbm5hICYgTWFucmFs ICAgICAgICAgICAgRXhwaXJlcyBKdW5lIDgsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDEz XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBBdXRvIERpc2NvdmVyeSBWUE4gICAgICAg ICAgICAgIERlY2VtYmVyIDIwMTINCg0KDQo3LiAgQWNrbm93bGVkZ2VtZW50cw0KDQogICBNYW55 IHBlb3BsZSBoYXZlIGNvbnRyaWJ1dGVkIHRvIHRoZSBkZXZlbG9wbWVudCBvZiB0aGlzIHByb2Js ZW0NCiAgIHN0YXRlbWVudCBhbmQgbWFueSBtb3JlIHdpbGwgcHJvYmFibHkgZG8gc28gYmVmb3Jl IHdlIGFyZSBkb25lIHdpdGgNCiAgIGl0LiAgV2hpbGUgd2UgY2Fubm90IHRoYW5rIGFsbCBjb250 cmlidXRvcnMsIHNvbWUgaGF2ZSBwbGF5ZWQgYW4NCiAgIGVzcGVjaWFsbHkgcHJvbWluZW50IHJv bGUuICBZb2F2IE5pciwgWWFyb24gU2NoZWZmZXIsIEpvcmdlIENvcm9uZWwNCiAgIE1lbmRvemEs IENocmlzIFVsbGlvdHQsIGFuZCBKb2huIFZlaXphZGVzIHdyb3RlIHRoZSBkb2N1bWVudCB1cG9u DQogICB3aGljaCB0aGlzIGRyYWZ0IHdhcyBiYXNlZC4gIEdlb2ZmcmV5IEh1YW5nLCBTdXJlc2gg TWVsYW0sIFByYXZlZW4NCiAgIFNhdGh5YW5hcmF5YW4sIEFuZHJlYXMgU3RlZmZlbiwgQnJpYW4g V2VpcywgYW5kIExvdSBCZXJnZXIgcHJvdmlkZWQNCiAgIGVzc2VudGlhbCBpbnB1dC4NCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQpIYW5uYSAmIE1hbnJhbCAgICAgICAgICAgIEV4cGlyZXMgSnVu ZSA4LCAyMDEzICAgICAgICAgICAgICAgICBbUGFnZSAxNF0NCg0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgQXV0byBEaXNjb3ZlcnkgVlBOICAgICAgICAgICAgICBEZWNlbWJlciAyMDEyDQoN Cg0KOC4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4s ICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlDQogICAgICAgICAgICAgIFJl cXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQoNCiAgIFtS RkM0MzAxXSAgS2VudCwgUy4gYW5kIEsuIFNlbywgIlNlY3VyaXR5IEFyY2hpdGVjdHVyZSBmb3Ig dGhlDQogICAgICAgICAgICAgIEludGVybmV0IFByb3RvY29sIiwgUkZDIDQzMDEsIERlY2VtYmVy IDIwMDUuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KSGFubmEgJiBNYW5yYWwgICAg ICAgICAgICBFeHBpcmVzIEp1bmUgOCwgMjAxMyAgICAgICAgICAgICAgICAgW1BhZ2UgMTVdDQoN CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgIEF1dG8gRGlzY292ZXJ5IFZQTiAgICAgICAgICAg ICAgRGVjZW1iZXIgMjAxMg0KDQoNCkF1dGhvcnMnIEFkZHJlc3Nlcw0KDQogICBTdGV2ZSBIYW5u YQ0KICAgSnVuaXBlciBOZXR3b3JrcywgSW5jLg0KICAgMTE5NCBOLiBNYXRoaWxkYSBBdmUuDQog ICBTdW5ueXZhbGUsIENBICA5NDA4OQ0KICAgVVNBDQoNCiAgIEVtYWlsOiBzaGFubmFAanVuaXBl ci5uZXQNCg0KDQogICBWaXNod2FzIE1hbnJhbA0KICAgSGV3bGV0dC1QYWNrYXJkIENvLg0KICAg MTkxMTEgUHJ1bmVyaWRnZSBBdmUuDQogICBDdXBlcnRpbm8sIENBICA5NTExMw0KICAgVVNBDQoN CiAgIEVtYWlsOiB2aXNod2FzLm1hbnJhbEBocC5jb20NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkhhbm5hICYgTWFucmFs ICAgICAgICAgICAgRXhwaXJlcyBKdW5lIDgsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDE2 XQ0K --047d7b676e6e825bc404d01eab7f-- From Johannes.Merkle@secunet.com Wed Dec 5 10:15:40 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D802A21F8C84 for ; Wed, 5 Dec 2012 10:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWowsb-Jb5fE for ; Wed, 5 Dec 2012 10:15:40 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id ED6AF21F8BB9 for ; Wed, 5 Dec 2012 10:15:39 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id C101E1A007B; Wed, 5 Dec 2012 19:14:55 +0100 (CET) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 9A2A71A007A; Wed, 5 Dec 2012 19:14:51 +0100 (CET) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Dec 2012 19:15:34 +0100 Message-ID: <50BF8F44.6040003@secunet.com> Date: Wed, 05 Dec 2012 19:15:32 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Tero Kivinen References: <20121204135025.24091.3591.idtracker@ietfa.amsl.com> <20670.1967.744783.372876@fireball.kivinen.iki.fi> In-Reply-To: <20670.1967.744783.372876@fireball.kivinen.iki.fi> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Dec 2012 18:15:34.0182 (UTC) FILETIME=[84A4EC60:01CDD314] Cc: ipsec@ietf.org Subject: Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-signature-auth-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 18:15:41 -0000 Hi Tero, some additional feedback: Introduction: In the paragraph 4 you point out the two achievements of the draft: - A generalized authentication method for authentication with digital signatures - A negotiation method for the hash function used as message digest within the signature The motivation should be structured to reflect this distinction. In particular, the first and third paragraphs motivate the authentication method, while the second one motivates the second one. As ECDSA groups, RSASSA-PSS and DSA with other hash than SHA-1 all point to deficiencies of the old authentication method, I would use a list. How about the following? The current signature based authentication methods in the IKEv2 are per algorithm, i.e. there is one for RSA Digital signatures, one for DSS Digital Signatures (using SHA-1) and three for different ECDSA curves each tied to exactly one hash algorithm. This design starts to be cumbersome when more signature algorithms, hash algorithms and elliptic curves are to be supported: * The RSA Digital Signatures format in the IKEv2 is specified to use RSASSA-PKCS1-v1_5 padding, but [RFC 4055] and [PKCS1] recommend the use of the newer RSASSA_PSS. This new padding method is specified by additional parameters and for each parameter set to be supported new authentication methods would be required. * With ECDSA and DSS there is no way to extract the hash algorithm from the signature, thus, for each new hash function to be supported with ECDSA or DSA new authentication methods would be needed. Support for new hash functions is particularly needed for DSS because the current restriction to SHA-1 limits its security, meaning there is no point of using long keys with it. * The tying of ECDSA authentication methods to particular elliptic curve groups requires definition of additional methods for each new group. By combination of new ECDSA groups with various hash functions the number of required authentication methods may grow unmanageable. Furthermore, the restriction of ECDSA authentication to a specific group is inconsistent with the approach taken with DSS. With the selection of SHA-3 [Ref_TBD], it is seen that it might be possible that in the future the signature methods are used with SHA-3 also, not only SHA-2. This means new mechanism for negotiating the hash algorithm for the signature algorithms is needed. > The new digital signature method needs to be flexible enough to > include all current signature methods (ECDSA, ECGDSA, RSASSA-PSS, > ElGamal, etc), The term "current signature methods" is not precise. Currently used with IKE? Currently used in practice at all? Currently specified in standards (which ones)? Actually: - the new authentication method is agnostic to the signature algorithm (like X.509 or CMS are) as far as an ASN.1 algorithm identifier exists. (This holds true only, if parameters of the algorithm can be included) - The hash negotiation method supports only those hash algorithms for which code points have been defined. Furthermore, I suggest not to list specific signature methods supported, as some of them (ECDSA) are common while others are not. This may provoke discussion, in particular, as RSA with PKCS#1v1.5 as the most common one (by far) is not listed. Best regards, Johannes From lberger@labn.net Wed Dec 5 11:47:37 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A578C21F8C72 for ; Wed, 5 Dec 2012 11:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.415 X-Spam-Level: X-Spam-Status: No, score=-101.415 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICw8G7Gk3UPV for ; Wed, 5 Dec 2012 11:47:36 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id B925C21F8C3F for ; Wed, 5 Dec 2012 11:47:36 -0800 (PST) Received: (qmail 10723 invoked by uid 0); 5 Dec 2012 19:47:14 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 5 Dec 2012 19:47:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=GdQT0I1ms3algzsguNTTeL/wEUtn6+3bhw03Q1eGNrM=; b=E9U1aWQ2f3w6bI9utw/3PTM9aqQxZglwCjn2YSBjQjOT4sKPiISyH9ubnlBcrlle6dzYVhJo3wlPv8bILRpz3vrGt4dYCw0PS+HRBgdXAUyLLaraBuiKvKotFG0HGSaT; Received: from box313.bluehost.com ([69.89.31.113]:57196 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TgKw4-000230-Nw; Wed, 05 Dec 2012 12:47:12 -0700 Message-ID: <50BFA4C0.1060909@labn.net> Date: Wed, 05 Dec 2012 14:47:12 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Vishwas Manral References: <50A5703F.4070305@labn.net> <50A58CDB.30402@labn.net> <50A682F8.9080907@labn.net> <50A689A9.1090803@labn.net> <50A68D30.2040203@labn.net> <50BE30D9.4030903@labn.net> <50BE4A60.1000303@labn.net> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: IPsecme WG Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 19:47:37 -0000 Hi Vishwas, see below for response. On 12/5/2012 12:54 PM, Vishwas Manral wrote: > Hi Lou, > > Thanks for your close reading of the document. I am attaching the > changed document. Please let me know if it looks good. > > On 11/15/2012 7:14 PM, Vishwas Manral wrote: > > - In section 2.2, I think mentioning something about the routing > > implications is worthwhile. How about at the end of the > section adding > > something along the lines of : > > > > Additionally, the routing implications of gateway-to-gateway > > communication must be addressed. In the simple case, > > selectors provide sufficient information for a gateway to > > forward traffic appropriately. In other cases, additional > > tunneling (e.g., GRE) and routing (e.g., OSPF) protocols are > > run over IPsec tunnels, and the configuration impact on those > > protocols must be considered. There is also the case when > > L3VPNs operate over IPsec Tunnels. > > > > We can add something in the lines of additional protocols are run over > > the IPsec tunnels and the solution should make an effort to allow for > > additional protocols like OSPF to be run optimally without too many > > changes in configuration. > I don't see any changes in 2.2 related to this (old) comment on routing implications, am I missing something? > Also in section 2.2, the text now says: > > The solution should work in cases where the endpoints are > administrated by separate management domains, albeit, ones that have > an existing trust relationship (for example two organisations who are > collaborating on a project, they may wish to join their networks, > whilst retaining independent control over configuration)It is for > this purpose spoke-to-spoke tunnels are dynamically created and torn- > down. It is highly desirable that the solution works for the star, > full mesh as well as dynamic full mesh topology. > > This revision now reads that the primary reason for dynamic > spoke-to-spoke tunnels is separate management domains. I somehow don't > think this was the intent. > > > I have reordered the sentences. I think that works. > > > In section 4.1 we had discussed replacement text for 3: > On 11/16/2012 12:49 PM, Vishwas Manral wrote: > >>On 11/15/2012 5:44 PM, Lou Berger wrote: > >> - In section 4.2, how about: > >> (replacement text) > >> 3. Gateways MUST allow for the operation of tunneling and > >> routing protocols operating over spoke-to-spoke IPsec Tunnels > >> with minimal, or no, configuration impact. > > > >VM> Ok will specifically specify tunnels and routing protocols. > > You have the following alternate / revised text: > 3. In many cases additional tunneling protocols (i.e. GRE) or > Routing protocols (i.e. OSPF) are run over the IPsec tunnels. > Gateways MUST allow for the operation of tunneling and Routing > protocols operating over spoke-to-spoke IPsec Tunnels with minimal or > no, configuration impact. Routing using the tunnels can work > seamlessly without any updates to the higher level application > configuration i.e. OSPF configuration, when the tunnel parameter > changes. > > I think this text is closer, but I think a few additional changes are > needed: > - GRE and OSPF are examples, so "i.e." should be replaced with "e.g." > - I think the final sentence is likely to be incorrect in many / most > real world cases, so would drop the sentence (from "Routing using > the tunnels can work...") > > I changed the "can" to a SHOULD for the second part. The idea is no > changes should happen in configuration and our current solution allows > that for most cases (hence SHOULD). I think this is worse. Now you're placing requirements on routing protocols which IMO should not care if (or be aware of when) the tunnel they are running on is IPsec or carried via IPsec. What additional point are you trying to make in the following sentence? Routing using the tunnels SHOULD work seamlessly without any updates to the higher level application configuration i.e. OSPF configuration, when the tunnel parameter changes. Can the sentence just be dropped? > > > You also said you'd address the minor comments: > On 11/15/2012 5:44 PM, Lou Berger wrote: > > - In section 2.1, you introduce the term "NAT gateway" and then later > > use just "gateway" when I suspect you mean "NAT gateway". I suggest > > using the term "NAT" and thereby not introduce possible confusion > > between the gateway term defined in section 1.1 and "NAT gateways". > > Updated it. I agree we can separate out the terms NAT gateway/ Gateway, > though for most parts it may be the same device. Prepend NAT to change > it to NAT gateway, as just replacing it with NAT made the sentence out > of place. okay. I probably just would had stayed with "NAT" and dropped "gateway", but that's your call. > > > and > > > - In sections 2.2, and Section 3.2 you say dynamic addresses makes > > static configuration impossible. This doesn't reflect the use of > > dynamic dns to handle this issues (and is currently supported by some > > vendors.) > > Do you have any reference and suggested text for this? I have not seen > the same in our customer cases. I've seen this supported on some firewall products in conjunction with dynamic DNS. I used one for a couple of years (the spoke used a dynamic address + DDNS.) I certainly deffer to the WG on if such usage should be referenced in this document. You are, after all, the experts on this and I'm just an occasional user... some possible text for section 2.2. could be: OLD The gateways can themselves come up and down, getting different IP addresses in the process, making static configuration impossible. NEW The solution should also address the case where gateways use dynamic IP addresses. and section 3.2, perhaps something like: OLD This solution however does not work when the spokes get dynamic IP address which the "hub gateways" cannot be configured with. NEW This solution however is complicated by the case when the spokes use dynamic IP addresses and DNS with dynamic updates must be used. Thanks, Lou > > Thanks, > Vishwas > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From vishwas.ietf@gmail.com Wed Dec 5 12:06:46 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4819521F8AF5 for ; Wed, 5 Dec 2012 12:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCWX+YPERkug for ; Wed, 5 Dec 2012 12:06:44 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 110BB21F8722 for ; Wed, 5 Dec 2012 12:06:43 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so3223722qca.31 for ; Wed, 05 Dec 2012 12:06:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I68MjjVHtQ0T+lmh7uBU/oj3z99kQSB65veQPxRkbWc=; b=e2uaEsbnyewlG/JXbK++9R+qAiriBYmW9AQEXGwKfGoHdN+mRKR7nO0YV6L9yn7iWR uoTzv+fCwel0sB2RPL986Bec4pn8vKIsig1PUD6JsxaiMQm6sYVE7oYQJN7KJxwTTWJO hAxPxkP8zFJ+6271CyNPT/m4xD4SqB5fbEJKnh6ENIhv1xrJVjJcSv7S5dqsvGHhu7Lx Ie+UT921gE3+HhamA90E8eNAXzI1rfx9wTP1ZY6+OiBLuRaAxN4GaIJSkteLEuiJ6aU1 zHk9dwoOiWDG+9FRH5I+8QyLGxwyRKgBFH7ApJB0KNssRUNn4U6nQo9y3Yrt2yITo6h7 brLw== MIME-Version: 1.0 Received: by 10.229.234.158 with SMTP id kc30mr7042913qcb.52.1354738003447; Wed, 05 Dec 2012 12:06:43 -0800 (PST) Received: by 10.229.92.77 with HTTP; Wed, 5 Dec 2012 12:06:43 -0800 (PST) In-Reply-To: <50BFA4C0.1060909@labn.net> References: <50A5703F.4070305@labn.net> <50A58CDB.30402@labn.net> <50A682F8.9080907@labn.net> <50A689A9.1090803@labn.net> <50A68D30.2040203@labn.net> <50BE30D9.4030903@labn.net> <50BE4A60.1000303@labn.net> <50BFA4C0.1060909@labn.net> Date: Wed, 5 Dec 2012 12:06:43 -0800 Message-ID: From: Vishwas Manral To: Lou Berger Content-Type: multipart/alternative; boundary=001636c928a975907a04d020859e Cc: IPsecme WG Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 20:06:46 -0000 --001636c928a975907a04d020859e Content-Type: text/plain; charset=ISO-8859-1 Hi Lou, > Thanks for your close reading of the document. I am attaching the > > changed document. Please let me know if it looks good. > > > > On 11/15/2012 7:14 PM, Vishwas Manral wrote: > > > - In section 2.2, I think mentioning something about the > routing > > > implications is worthwhile. How about at the end of the > > section adding > > > something along the lines of : > > > > > > Additionally, the routing implications of > gateway-to-gateway > > > communication must be addressed. In the simple case, > > > selectors provide sufficient information for a gateway to > > > forward traffic appropriately. In other cases, additional > > > tunneling (e.g., GRE) and routing (e.g., OSPF) protocols > are > > > run over IPsec tunnels, and the configuration impact on > those > > > protocols must be considered. There is also the case when > > > L3VPNs operate over IPsec Tunnels. > > > > > > We can add something in the lines of additional protocols are run > over > > > the IPsec tunnels and the solution should make an effort to allow > for > > > additional protocols like OSPF to be run optimally without too many > > > changes in configuration. > > > > I don't see any changes in 2.2 related to this (old) comment on routing > implications, am I missing something? > > I am a bit confused here. You said " I think this text is closer, but I think a few additional changes are needed: - GRE and OSPF are examples, so "i.e." should be replaced with "e.g." - I think the final sentence is likely to be incorrect in many / most real world cases, so would drop the sentence (from "Routing using the tunnels can work...")" I performed the changes you asked for. For the second part I have told you the reason below. What am I missing? > > > > > > > In section 4.1 we had discussed replacement text for 3: > > On 11/16/2012 12:49 PM, Vishwas Manral wrote: > > >>On 11/15/2012 5:44 PM, Lou Berger wrote: > > >> - In section 4.2, how about: > > >> (replacement text) > > >> 3. Gateways MUST allow for the operation of tunneling and > > >> routing protocols operating over spoke-to-spoke IPsec > Tunnels > > >> with minimal, or no, configuration impact. > > > > > >VM> Ok will specifically specify tunnels and routing protocols. > > > > You have the following alternate / revised text: > > 3. In many cases additional tunneling protocols (i.e. GRE) or > > Routing protocols (i.e. OSPF) are run over the IPsec tunnels. > > Gateways MUST allow for the operation of tunneling and Routing > > protocols operating over spoke-to-spoke IPsec Tunnels with > minimal or > > no, configuration impact. Routing using the tunnels can work > > seamlessly without any updates to the higher level application > > configuration i.e. OSPF configuration, when the tunnel parameter > > changes. > > > > I think this text is closer, but I think a few additional changes are > > needed: > > - GRE and OSPF are examples, so "i.e." should be replaced with > "e.g." > > - I think the final sentence is likely to be incorrect in many / > most > > real world cases, so would drop the sentence (from "Routing using > > the tunnels can work...") > > > > I changed the "can" to a SHOULD for the second part. The idea is no > > changes should happen in configuration and our current solution allows > > that for most cases (hence SHOULD). > > I think this is worse. Now you're placing requirements on routing > protocols which IMO should not care if (or be aware of when) the tunnel > they are running on is IPsec or carried via IPsec. > > What additional point are you trying to make in the following sentence? > Routing using the tunnels SHOULD work > seamlessly without any updates to the higher level application > configuration i.e. OSPF configuration, when the tunnel parameter > changes. > > Can the sentence just be dropped? > > VM> I think this is an important requirement. A tunnel should be able to provide an interface by which when tunnel IP parameters change we do not have to change any configuration for higher application like Routing. I had earlier mentioned in more generic terms earlier but changed to the terms provided based on feedback from the list. The entire idea is the with scale configuration needs to be reduced and that needs to happen across layers, so every layer needs to provide the service. Let me know what it is I am unable to convey. > > > I've seen this supported on some firewall products in conjunction with > dynamic DNS. I used one for a couple of years (the spoke used a dynamic > address + DDNS.) I certainly deffer to the WG on if such usage should > be referenced in this document. You are, after all, the experts on this > and I'm just an occasional user... > > some possible text for section 2.2. could be: > OLD > The gateways can themselves come up and down, getting different IP > addresses in the process, making static configuration impossible. > NEW > The solution should also address the case where gateways use dynamic > IP addresses. > I am not sure how to 2 sentences mean the same thing, with DDNS inputs you have given. Are you saying keep the old text as well as add the new text. > > and section 3.2, perhaps something like: > OLD > This solution however does not work when the spokes get dynamic IP > address which the "hub gateways" cannot be configured with. > NEW > This solution however is complicated by the case when the spokes > use dynamic IP addresses and DNS with dynamic updates must be used. > > Same comment as above. Thanks, Vishwas > Thanks, > Lou > > > > > Thanks, > > Vishwas > > > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > --001636c928a975907a04d020859e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lou,

> Thanks for your close reading of the document. I am attaching the
> changed document. Please let me know if it looks good.
>
> =A0 =A0 On 11/15/2012 7:14 PM, Vishwas Manral wrote:
> =A0 =A0 > =A0 =A0 - In section 2.2, I think mentioning something ab= out the routing
> =A0 =A0 > =A0 =A0 implications is worthwhile. How about at the end = of the
> =A0 =A0 section adding
> =A0 =A0 > =A0 =A0 something along the lines of :
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 =A0 =A0 Additionally, the routing implications of= gateway-to-gateway
> =A0 =A0 > =A0 =A0 =A0 =A0 communication must be addressed. =A0In th= e simple case,
> =A0 =A0 > =A0 =A0 =A0 =A0 selectors provide sufficient information = for a gateway to
> =A0 =A0 > =A0 =A0 =A0 =A0 forward traffic appropriately. =A0In othe= r cases, additional
> =A0 =A0 > =A0 =A0 =A0 =A0 tunneling (e.g., GRE) and routing (e.g., = OSPF) protocols are
> =A0 =A0 > =A0 =A0 =A0 =A0 run over IPsec tunnels, and the configura= tion impact on those
> =A0 =A0 > =A0 =A0 =A0 =A0 protocols must be considered. =A0There is= also the case when
> =A0 =A0 > =A0 =A0 =A0 =A0 L3VPNs operate over IPsec Tunnels.
> =A0 =A0 >
> =A0 =A0 > We can add something in the lines of additional protocols= are run over
> =A0 =A0 > the IPsec tunnels and the solution should make an effort = to allow for
> =A0 =A0 > additional protocols like OSPF to= be run optimally without too many
> =A0 =A0 > changes in configuration.
>

I don't see any changes in 2.2 related to this (old) comment on r= outing
implications, am I missing something?

I am a bit confused here.
You said
" I think this text is closer, but I think a few additional changes are
needed:
=A0- GRE and OSPF are examples, so "i.e." should be replaced with= "e.g."
=A0- I think the final sentence is likely to be incorrect in many / most =A0 =A0real world cases, so would drop the sentence (from "Routing usi= ng
=A0 =A0the tunnels can work...")"

I performed the ch= anges you asked for. For the second part I have told you the reason below. = What am I missing?

>
>
> =A0 =A0 In section 4.1 we had discussed replacement text for 3:
> =A0 =A0 On 11/16/2012 12:49 PM, Vishwas Manral wrote:
> =A0 =A0 >>On 11/15/2012 5:44 PM, Lou Berger wrote:
> =A0 =A0 >> =A0 =A0 - In section 4.2, how about:
> =A0 =A0 >> =A0 =A0 =A0 =A0(replacement text)
> =A0 =A0 >> =A0 =A0 =A0 =A03. =A0Gateways MUST allow for the oper= ation of tunneling and
> =A0 =A0 >> =A0 =A0 =A0 =A0routing protocols operating over spoke= -to-spoke IPsec Tunnels
> =A0 =A0 >> =A0 =A0 =A0 =A0with minimal, or no, configuration imp= act.
> =A0 =A0 >
> =A0 =A0 >VM> Ok will specifically specify tunnels and routing pr= otocols.
>
> =A0 =A0 You have the following alternate / revised text:
> =A0 =A0 =A0 =A03. =A0In many cases additional tunneling protocols (i.e= . =A0GRE) or
> =A0 =A0 =A0 =A0Routing protocols (i.e. =A0OSPF) are run over the IPsec= tunnels.
> =A0 =A0 =A0 =A0Gateways MUST allow for the operation of tunneling and = Routing
> =A0 =A0 =A0 =A0protocols operating over spoke-to-spoke IPsec Tunnels w= ith minimal or
> =A0 =A0 =A0 =A0no, configuration impact. =A0Routing using the tunnels = can work
> =A0 =A0 =A0 =A0seamlessly without any updates to the higher level appl= ication
> =A0 =A0 =A0 =A0configuration i.e. =A0OSPF configuration, when the tunn= el parameter
> =A0 =A0 =A0 =A0changes.
>
> =A0 =A0 I think this text is closer, but I think a few additional chan= ges are
> =A0 =A0 needed:
> =A0 =A0 =A0- GRE and OSPF are examples, so "i.e." should be = replaced with "e.g."
> =A0 =A0 =A0- I think the final sentence is likely to be incorrect in m= any / most
> =A0 =A0 =A0 =A0real world cases, so would drop the sentence (from &quo= t;Routing using
> =A0 =A0 =A0 =A0the tunnels can work...")
>
> I changed the "can" to a SHOULD for the second part. The ide= a is no
> changes should happen in configuration and our current solution allows=
> that for most cases (hence SHOULD).

I think this is worse. =A0Now you're placing requirements o= n routing
protocols which IMO should not care if (or be aware of when) the tunnel
they are running on is IPsec or carried via IPsec.

What additional point are you trying to make in the following sentence?
=A0 =A0Routing using the tunnels SHOULD work
=A0 =A0seamlessly without any updates to the higher level= application
=A0 =A0configuration i.e. =A0OSPF configuration, when the tunnel parameter<= br> =A0 =A0changes.

Can the sentence just be dropped?

VM> I think this is an imp= ortant requirement. A tunnel should be able to provide an interface by whic= h when tunnel IP parameters change we do not have to change any configurati= on for higher application like Routing. I had earlier mentioned in more gen= eric terms earlier but changed to the terms provided based on feedback from= the list.

The entire idea is the with scale configuration needs to be reduced and= that needs to happen across layers, so every layer needs to provide the se= rvice. Let me know what it is I am unable to convey.


I've seen this supported on some firewall products in conjunction= with
dynamic DNS. =A0I used one for a couple of years (the spoke used a dynamic<= br> address + DDNS.) =A0I certainly deffer to the WG on if such usage should be referenced in this document. =A0You are, after all, the experts on this<= br> and I'm just an occasional user...

some possible text for section 2.2. could be:
OLD
=A0 =A0The gateways can themselves come up and down, getting different IP =A0 =A0addresses in the process, making static configuration impossible. NEW
=A0 =A0The solution should also address the case where gateways use dynamic=
=A0 =A0IP addresses.
I am not sure how to 2 sentences = mean the same thing, with DDNS inputs you have given. Are you saying keep t= he old text as well as add the new text.

and section 3.2, perhaps something like:
OLD
=A0 =A0This solution however does not work when the spokes get dynamic IP =A0 =A0address which the "hub gateways" cannot be configured with= .
NEW
=A0 =A0This solution however is complicated by the case when the spokes
=A0 =A0use dynamic IP addresses and DNS with dynamic updates must be used.<= br>
=A0Same comment as above.

Thanks,
Vishwas
Thanks,
Lou

>
> Thanks,
> Vishwas
>
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>


--001636c928a975907a04d020859e-- From lberger@labn.net Wed Dec 5 14:29:08 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E4721F8CEE for ; Wed, 5 Dec 2012 14:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.103 X-Spam-Level: X-Spam-Status: No, score=-102.103 tagged_above=-999 required=5 tests=[AWL=0.896, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aE-W+07YYso for ; Wed, 5 Dec 2012 14:29:07 -0800 (PST) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 4A01421F8CED for ; Wed, 5 Dec 2012 14:29:07 -0800 (PST) Received: (qmail 19314 invoked by uid 0); 5 Dec 2012 22:28:42 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 5 Dec 2012 22:28:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=0K2IZ8iPbbHc8GDCo3EXlrdLXhXEcdC0xqQKGCYgOAE=; b=wlmkngldF9JfKp6+vNDa+Gjjezi2+Kel5Z8lmvaJwTZSFZg1vbSzNXItC7+YT0axrErdtBBMnLjLeSUh0ZVrJUg+mOwtN78vN5j29OQ9V64ebaAwYd4/g8TrfQkuy2IY; Received: from box313.bluehost.com ([69.89.31.113]:50066 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TgNSL-0004aN-VS; Wed, 05 Dec 2012 15:28:42 -0700 Message-ID: <50BFCA9A.4030502@labn.net> Date: Wed, 05 Dec 2012 17:28:42 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Vishwas Manral References: <50A5703F.4070305@labn.net> <50A58CDB.30402@labn.net> <50A682F8.9080907@labn.net> <50A689A9.1090803@labn.net> <50A68D30.2040203@labn.net> <50BE30D9.4030903@labn.net> <50BE4A60.1000303@labn.net> <50BFA4C0.1060909@labn.net> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: IPsecme WG Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 22:29:09 -0000 Vishwas, See below. On 12/5/2012 3:06 PM, Vishwas Manral wrote: > Hi Lou, > > > Thanks for your close reading of the document. I am attaching the > > changed document. Please let me know if it looks good. > > > > On 11/15/2012 7:14 PM, Vishwas Manral wrote: > > > - In section 2.2, I think mentioning something about the > routing > > > implications is worthwhile. How about at the end of the > > section adding > > > something along the lines of : > > > > > > Additionally, the routing implications of > gateway-to-gateway > > > communication must be addressed. In the simple case, > > > selectors provide sufficient information for a > gateway to > > > forward traffic appropriately. In other cases, > additional > > > tunneling (e.g., GRE) and routing (e.g., OSPF) > protocols are > > > run over IPsec tunnels, and the configuration impact > on those > > > protocols must be considered. There is also the > case when > > > L3VPNs operate over IPsec Tunnels. > > > > > > We can add something in the lines of additional protocols > are run over > > > the IPsec tunnels and the solution should make an effort to > allow for > > > additional protocols like OSPF to be run optimally without > too many > > > changes in configuration. > > > > I don't see any changes in 2.2 related to this (old) comment on routing > implications, am I missing something? > > I am a bit confused here. > > You said > " I think this text is closer, but I think a few additional changes are > needed: > - GRE and OSPF are examples, so "i.e." should be replaced with "e.g." > - I think the final sentence is likely to be incorrect in many / most > real world cases, so would drop the sentence (from "Routing using > the tunnels can work...")" > > I performed the changes you asked for. For the second part I have told > you the reason below. What am I missing? I think we're getting changes in section 2 and 4 mixed up. Let me try again. WRT the new section *2.2* I think mentioning something about the routing implications is worthwhile. How about before the last paragraph of the section adding something along the lines of : Additionally, the routing implications of gateway-to-gateway communication must be addressed. In the simple case, selectors provide sufficient information for a gateway to forward traffic appropriately. In other cases, additional tunneling (e.g., GRE) and routing (e.g., OSPF) protocols are run over IPsec tunnels, and the configuration impact on those protocols must be considered. There is also the case when L3VPNs operate over IPsec Tunnels. > > > > > > > > In section 4.1 we had discussed replacement text for 3: > > On 11/16/2012 12:49 PM, Vishwas Manral wrote: > > >>On 11/15/2012 5:44 PM, Lou Berger wrote: > > >> - In section 4.2, how about: > > >> (replacement text) > > >> 3. Gateways MUST allow for the operation of > tunneling and > > >> routing protocols operating over spoke-to-spoke > IPsec Tunnels > > >> with minimal, or no, configuration impact. > > > > > >VM> Ok will specifically specify tunnels and routing protocols. > > > > You have the following alternate / revised text: > > 3. In many cases additional tunneling protocols (i.e. GRE) or > > Routing protocols (i.e. OSPF) are run over the IPsec tunnels. > > Gateways MUST allow for the operation of tunneling and Routing > > protocols operating over spoke-to-spoke IPsec Tunnels with > minimal or > > no, configuration impact. Routing using the tunnels can work > > seamlessly without any updates to the higher level application > > configuration i.e. OSPF configuration, when the tunnel > parameter > > changes. > > > > I think this text is closer, but I think a few additional > changes are > > needed: > > - GRE and OSPF are examples, so "i.e." should be replaced > with "e.g." > > - I think the final sentence is likely to be incorrect in > many / most > > real world cases, so would drop the sentence (from "Routing > using > > the tunnels can work...") > > > > I changed the "can" to a SHOULD for the second part. The idea is no > > changes should happen in configuration and our current solution allows > > that for most cases (hence SHOULD). > > I think this is worse. Now you're placing requirements on routing > protocols which IMO should not care if (or be aware of when) the tunnel > they are running on is IPsec or carried via IPsec. > > What additional point are you trying to make in the following sentence? > Routing using the tunnels SHOULD work > seamlessly without any updates to the higher level application > configuration i.e. OSPF configuration, when the tunnel parameter > changes. > > Can the sentence just be dropped? > > VM> I think this is an important requirement. A tunnel should be able to > provide an interface by which when tunnel IP parameters change we do not > have to change any configuration for higher application like Routing. I > had earlier mentioned in more generic terms earlier but changed to the > terms provided based on feedback from the list. What higher level protocols like most routing protocols that use the tunnel interface IP addresses in operation? > > The entire idea is the with scale configuration needs to be reduced and > that needs to happen across layers, so every layer needs to provide the > service. Let me know what it is I am unable to convey. sure, but I think you're placing new requirements on the routing & tunneling protocols. > > > > I've seen this supported on some firewall products in conjunction with > dynamic DNS. I used one for a couple of years (the spoke used a dynamic > address + DDNS.) I certainly deffer to the WG on if such usage should > be referenced in this document. You are, after all, the experts on this > and I'm just an occasional user... > > some possible text for section 2.2. could be: > OLD > The gateways can themselves come up and down, getting different IP > addresses in the process, making static configuration impossible. > NEW > The solution should also address the case where gateways use dynamic > IP addresses. > > I am not sure how to 2 sentences mean the same thing, with DDNS inputs > you have given. Are you saying keep the old text as well as add the new > text. Nope. I was trying to capture the use case in a way that avoided the problematic text. Does the latter cover your use case? If not, we can go into what I see as problematic with the old text. > > > and section 3.2, perhaps something like: > OLD > This solution however does not work when the spokes get dynamic IP > address which the "hub gateways" cannot be configured with. > NEW > This solution however is complicated by the case when the spokes > use dynamic IP addresses and DNS with dynamic updates must be used. > > Same comment as above. Well these sentences are much closer. The latter implies that the hubs are configured with the spokes FQDNs. We can add something to that effect if you think it helps. Thanks, Lou > > Thanks, > Vishwas > > Thanks, > Lou > > > > > Thanks, > > Vishwas > > > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From vishwas.ietf@gmail.com Thu Dec 6 10:55:47 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7693921F8813 for ; Thu, 6 Dec 2012 10:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpaHYRgC8H1e for ; Thu, 6 Dec 2012 10:55:47 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id CEA4B21F8803 for ; Thu, 6 Dec 2012 10:55:46 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id i20so871104qad.10 for ; Thu, 06 Dec 2012 10:55:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hhmHZpdYlWUfFQ1R2jZnmKRQX+kVSR+MJcDixZ28EgY=; b=W+deEIZYHnYtME6S1TJsHmpeU+0Y2hNk5L96z6KjD0had9RbrJDv3k1QvdHMx853PB 4pApmBaTEaCuP6vJqo3mCrhzWH03/nojrLhgt6rd+0GaZQgeN3FA+77/HRP6yvo4XE5U ocd5/fT6+IY6W0oa/NPp5kX82SaDOQz7QWFCEQ/AQ2IH8RY2mLef23yIp+vgP+Z+Y+Is RyC8WlwDGkE1BXSTR8yYSCJ/Qh5iSRztyh3VQytgIk+3mxLD8zi1Igwzpe8MmEBOWB/i KSiu/SfZJagQtHIDNoUH/vv64BffYyIiUnmq4xagXYJCOmK+g2+kOP5rGevUuRPymYUw U+Vw== MIME-Version: 1.0 Received: by 10.229.38.35 with SMTP id z35mr923923qcd.144.1354820146262; Thu, 06 Dec 2012 10:55:46 -0800 (PST) Received: by 10.229.92.77 with HTTP; Thu, 6 Dec 2012 10:55:46 -0800 (PST) In-Reply-To: <50BFCA9A.4030502@labn.net> References: <50A5703F.4070305@labn.net> <50A58CDB.30402@labn.net> <50A682F8.9080907@labn.net> <50A689A9.1090803@labn.net> <50A68D30.2040203@labn.net> <50BE30D9.4030903@labn.net> <50BE4A60.1000303@labn.net> <50BFA4C0.1060909@labn.net> <50BFCA9A.4030502@labn.net> Date: Thu, 6 Dec 2012 10:55:46 -0800 Message-ID: From: Vishwas Manral To: Lou Berger Content-Type: multipart/alternative; boundary=0016369205048d735f04d033a57b Cc: IPsecme WG Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 18:55:47 -0000 --0016369205048d735f04d033a57b Content-Type: text/plain; charset=ISO-8859-1 Hi Lou, I have included the other comments. The last one remaining is: > VM> I think this is an important requirement. A tunnel should be able to > > provide an interface by which when tunnel IP parameters change we do not > > have to change any configuration for higher application like Routing. I > > had earlier mentioned in more generic terms earlier but changed to the > > terms provided based on feedback from the list. > > What higher level protocols like most routing protocols that use the > tunnel interface IP addresses in operation? > > > > > The entire idea is the with scale configuration needs to be reduced and > > that needs to happen across layers, so every layer needs to provide the > > service. Let me know what it is I am unable to convey. > > sure, but I think you're placing new requirements on the routing & > tunneling protocols. > > VM> There are no restrictions on an application protocol like Routing. The idea is that the lower needs to provide a functionality, so that if required a higher layer can use it. There is no restriction at all on the higher layer. Do let me know if that is clearer? Thanks, Vishwas --0016369205048d735f04d033a57b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lou,

I have included the other comments. The last one remaining i= s:

> VM> I think this is an important requirement. A tunnel should be ab= le to
> provide an interface by which when tunnel IP parameters change we do n= ot
> have to change any configuration for higher application like Routing. = I
> had earlier mentioned in more generic terms earlier but changed to the=
> terms provided based on feedback from the list.

What higher level protocols like most routing protocols that us= e the
tunnel interface IP addresses in operation?

>
> The entire idea is the with scale configuration needs to be reduced an= d
> that needs to happen across layers, so every layer needs to provide th= e
> service. Let me know what it is I am unable to convey.

sure, but I think you're placing new requirements on the routing = &
tunneling protocols.

VM> There are no restrict= ions on an application protocol like Routing. The idea is that the lower ne= eds to provide a functionality, so that if required a higher layer can use = it. There is no restriction at all on the higher layer. Do let me know if t= hat is clearer?

Thanks,
Vishwas
--0016369205048d735f04d033a57b-- From lberger@labn.net Thu Dec 6 11:16:15 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDFC21F88B6 for ; Thu, 6 Dec 2012 11:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=1.066, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tu69cr8HMWf for ; Thu, 6 Dec 2012 11:16:14 -0800 (PST) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 6DC2721F88A1 for ; Thu, 6 Dec 2012 11:16:14 -0800 (PST) Received: (qmail 23812 invoked by uid 0); 6 Dec 2012 19:15:52 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 6 Dec 2012 19:15:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=l92MlZ5nCfkTqTrVR6hIUZmaunvLk3Bqs1sU0wzAVnY=; b=0jGOEa8iffLfucUqq5SZchIWMa1c+GKsgUSu2e7obDJ0ZhpecQ/dvkb7W0r/0gxiUrtTUnZfx3lMC/REO7KQp7Y955gobTbyR4vNBIiu9gdTHs+Iow7QGAvLcoa6oc9R; Received: from box313.bluehost.com ([69.89.31.113]:49359 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TggvI-0000Gy-0i; Thu, 06 Dec 2012 12:15:52 -0700 Message-ID: <50C0EEE9.7000904@labn.net> Date: Thu, 06 Dec 2012 14:15:53 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Vishwas Manral References: <50A5703F.4070305@labn.net> <50A58CDB.30402@labn.net> <50A682F8.9080907@labn.net> <50A689A9.1090803@labn.net> <50A68D30.2040203@labn.net> <50BE30D9.4030903@labn.net> <50BE4A60.1000303@labn.net> <50BFA4C0.1060909@labn.net> <50BFCA9A.4030502@labn.net> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: IPsecme WG Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 19:16:15 -0000 Vishwas, I think I see where you're headed. The text under discussion is: Routing using the tunnels SHOULD work seamlessly without any updates to the higher level application configuration i.e. OSPF configuration, when the tunnel parameter changes. I read this a requirement being placed on the higher level protocol, but I believe your intent was on the solution. How about rephrasing along the lines of a requirement on the ADVPN solution? Perhaps something like: The ADVPN solution SHOULD NOT increase the amount of information required to configure protocols running over IPsec tunnels. Lou On 12/6/2012 1:55 PM, Vishwas Manral wrote: > Hi Lou, > > I have included the other comments. The last one remaining is: > > > VM> I think this is an important requirement. A tunnel should be > able to > > provide an interface by which when tunnel IP parameters change we > do not > > have to change any configuration for higher application like > Routing. I > > had earlier mentioned in more generic terms earlier but changed to the > > terms provided based on feedback from the list. > > What higher level protocols like most routing protocols that use the > tunnel interface IP addresses in operation? > > > > > The entire idea is the with scale configuration needs to be > reduced and > > that needs to happen across layers, so every layer needs to > provide the > > service. Let me know what it is I am unable to convey. > > sure, but I think you're placing new requirements on the routing & > tunneling protocols. > > VM> There are no restrictions on an application protocol like Routing. > The idea is that the lower needs to provide a functionality, so that if > required a higher layer can use it. There is no restriction at all on > the higher layer. Do let me know if that is clearer? > > Thanks, > Vishwas > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From vishwas.ietf@gmail.com Thu Dec 6 15:52:00 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476FA21F85EA for ; Thu, 6 Dec 2012 15:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zuy9mFymgLw for ; Thu, 6 Dec 2012 15:51:58 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C219121F85D9 for ; Thu, 6 Dec 2012 15:51:57 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so3949200qca.31 for ; Thu, 06 Dec 2012 15:51:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kpxE5awiyNCwrBhEE6LYqlY8meqLk/KxRqCdmy0XTek=; b=Vy2jf3PrsGzyRdgBZW3SFAkyZsvgL0Nx+oiyJUBOVdSjXQJb6EARgZ10edDMZHo0TD xcRtXn1ue1VgK3aAvEfCx8K9Xtgsr4wEIDqZxChbk+hlZRbRVPdzSlY3HHTljUKDkK5M Eaj/NHV/T1XhVs2ZbEK8Yfwl4XlL7P6u7k/tBpOxlpZFWuQ/IP3hHNyo5R7NXDIGkqlM iVnxOnI+8zWv1ebthDckryEl0OcgkX3d/ksVRtsfwyXlGQryweahk34xGNDtIzDcyaqK qk0+iDo59ZoGUSJs8p29HmafrSmeif1gmVp+60LtXRsfGktXeTWTu4YJM8+MAawHrVX6 92cg== MIME-Version: 1.0 Received: by 10.224.168.136 with SMTP id u8mr5946397qay.17.1354837917171; Thu, 06 Dec 2012 15:51:57 -0800 (PST) Received: by 10.229.92.77 with HTTP; Thu, 6 Dec 2012 15:51:57 -0800 (PST) In-Reply-To: <50C0EEE9.7000904@labn.net> References: <50A5703F.4070305@labn.net> <50A58CDB.30402@labn.net> <50A682F8.9080907@labn.net> <50A689A9.1090803@labn.net> <50A68D30.2040203@labn.net> <50BE30D9.4030903@labn.net> <50BE4A60.1000303@labn.net> <50BFA4C0.1060909@labn.net> <50BFCA9A.4030502@labn.net> <50C0EEE9.7000904@labn.net> Date: Thu, 6 Dec 2012 15:51:57 -0800 Message-ID: From: Vishwas Manral To: Lou Berger Content-Type: multipart/mixed; boundary=20cf3074ba88c8016504d037c8b1 Cc: IPsecme WG Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 23:52:00 -0000 --20cf3074ba88c8016504d037c8b1 Content-Type: multipart/alternative; boundary=20cf3074ba88c8016104d037c8af --20cf3074ba88c8016104d037c8af Content-Type: text/plain; charset=ISO-8859-1 Hi Lou, Here is the latest draft, with all your comments incorporated. I will post the draft soon. Thanks, Vishwas On Thu, Dec 6, 2012 at 11:15 AM, Lou Berger wrote: > > Vishwas, > > I think I see where you're headed. > > The text under discussion is: > > Routing using the tunnels SHOULD work > seamlessly without any updates to the higher level application > configuration i.e. OSPF configuration, when the tunnel parameter > changes. > > I read this a requirement being placed on the higher level protocol, but > I believe your intent was on the solution. How about rephrasing along > the lines of a requirement on the ADVPN solution? Perhaps something like: > > The ADVPN solution SHOULD NOT increase the amount of information > required to configure protocols running over IPsec tunnels. > > Lou > > On 12/6/2012 1:55 PM, Vishwas Manral wrote: > > Hi Lou, > > > > I have included the other comments. The last one remaining is: > > > > > VM> I think this is an important requirement. A tunnel should be > > able to > > > provide an interface by which when tunnel IP parameters change we > > do not > > > have to change any configuration for higher application like > > Routing. I > > > had earlier mentioned in more generic terms earlier but changed to > the > > > terms provided based on feedback from the list. > > > > What higher level protocols like most routing protocols that use the > > tunnel interface IP addresses in operation? > > > > > > > > The entire idea is the with scale configuration needs to be > > reduced and > > > that needs to happen across layers, so every layer needs to > > provide the > > > service. Let me know what it is I am unable to convey. > > > > sure, but I think you're placing new requirements on the routing & > > tunneling protocols. > > > > VM> There are no restrictions on an application protocol like Routing. > > The idea is that the lower needs to provide a functionality, so that if > > required a higher layer can use it. There is no restriction at all on > > the higher layer. Do let me know if that is clearer? > > > > Thanks, > > Vishwas > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > --20cf3074ba88c8016104d037c8af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lou,

Here is the latest draft, with all your comments incorporate= d.

I will post the draft soon.

Thanks,
Vishwas


=
On Thu, Dec 6, 2012 at 11:15 AM, Lou Berger <lbe= rger@labn.net> wrote:

Vishwas,

I think I see where you're headed.

The text under discussion is:

=A0 =A0Routing using the tunnels SHOULD work
=A0 =A0seamlessly without any updates to the higher level application
=A0 =A0configuration i.e. =A0OSPF configuration, when the tunnel parameter<= br> =A0 =A0changes.

I read this a requirement being placed on the higher level protocol, = but
I believe your intent was on the solution. =A0How about rephrasing along the lines of a requirement on the ADVPN solution? Perhaps something like:
=A0 =A0The ADVPN solution SHOULD NOT increase the amount of information
=A0 =A0required to configure protocols running over IPsec tunnels.

Lou

On 12/6/2012 1:55 PM, Vishwas Manral wrote:
> Hi Lou,
>
> I have included the other comments. The last one remaining is:
>
> =A0 =A0 > VM> I think this is an important requirement. A tunnel= should be
> =A0 =A0 able to
> =A0 =A0 > provide an interface by which when tunnel IP parameters c= hange we
> =A0 =A0 do not
> =A0 =A0 > have to change any configuration for higher application l= ike
> =A0 =A0 Routing. I
> =A0 =A0 > had earlier mentioned in more generic terms earlier but c= hanged to the
> =A0 =A0 > terms provided based on feedback from the list.
>
> =A0 =A0 What higher level protocols like most routing protocols that u= se the
> =A0 =A0 tunnel interface IP addresses in operation?
>
> =A0 =A0 >
> =A0 =A0 > The entire idea is the with scale configuration needs to = be
> =A0 =A0 reduced and
> =A0 =A0 > that needs to happen across layers, so every layer needs = to
> =A0 =A0 provide the
> =A0 =A0 > service. Let me know what it is I am unable to convey. >
> =A0 =A0 sure, but I think you're placing new requirements on the r= outing &
> =A0 =A0 tunneling protocols.
>
> VM> There are no restrictions on an application protocol like Routi= ng.
> The idea is that the lower needs to provide a functionality, so that i= f
> required a higher layer can use it. There is no restriction at all on<= br> > the higher layer. Do let me know if that is clearer?
>
> Thanks,
> Vishwas
>
>
> __________________= _____________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>

--20cf3074ba88c8016104d037c8af-- --20cf3074ba88c8016504d037c8b1 Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-ipsecme-p2p-vpn-problem-02.txt" Content-Disposition: attachment; filename="draft-ietf-ipsecme-p2p-vpn-problem-02.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_haejhlux0 DQoNCklQc2VjTUUgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBTLiBIYW5uYQ0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKdW5pcGVyDQpJbnRlbmRlZCBzdGF0dXM6IElu Zm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWLiBNYW5yYWwNCkV4 cGlyZXM6IEp1bmUgMTAsIDIwMTMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBIUA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBEZWNlbWJlciA3LCAyMDEyDQoNCg0KICAgICAgICAgQXV0byBEaXNjb3Zl cnkgVlBOIFByb2JsZW0gU3RhdGVtZW50IGFuZCBSZXF1aXJlbWVudHMNCiAgICAgICAgICAgICAg ICAgIGRyYWZ0LWlldGYtaXBzZWNtZS1hZC12cG4tcHJvYmxlbS0wMg0KDQpBYnN0cmFjdA0KDQog ICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgcHJvYmxlbSBvZiBlbmFibGluZyBhIGxhcmdl IG51bWJlciBvZg0KICAgc3lzdGVtcyB0byBjb21tdW5pY2F0ZSBkaXJlY3RseSB1c2luZyBJUHNl YyB0byBwcm90ZWN0IHRoZSB0cmFmZmljDQogICBiZXR3ZWVuIHRoZW0uICBJdCB0aGVuIGV4cGFu ZHMgb24gdGhlIHJlcXVpcmVtZW50cywgZm9yIHN1Y2ggYQ0KICAgc29sdXRpb24uDQoNCiAgIE1h bnVhbCBjb25maWd1cmF0aW9uIG9mIGFsbCBwb3NzaWJsZSB0dW5uZWxzIGlzIHRvbyBjdW1iZXJz b21lIGluDQogICBtYW55IHN1Y2ggY2FzZXMuICBJbiBvdGhlciBjYXNlcyB0aGUgSVAgYWRkcmVz cyBvZiBlbmRwb2ludHMgY2hhbmdlDQogICBvciB0aGUgZW5kcG9pbnRzIG1heSBiZSBiZWhpbmQg TkFUIGdhdGV3YXlzLCBtYWtpbmcgc3RhdGljDQogICBjb25maWd1cmF0aW9uIGltcG9zc2libGUu ICBUaGUgQXV0byBEaXNjb3ZlcnkgVlBOIHNvbHV0aW9uIGlzDQogICBjaGFydGVyZWQgdG8gYWRk cmVzcyB0aGVzZSByZXF1aXJlbWVudHMuDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgVGhp cyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRo ZQ0KICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4NCg0KICAgSW50ZXJuZXQtRHJh ZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAg IFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0 cmlidXRlDQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlz dCBvZiBjdXJyZW50IEludGVybmV0LQ0KICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJh ZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1h eSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBh dCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFm dHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBh cyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBp cmUgb24gSnVuZSAxMCwgMjAxMy4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5cmlnaHQg KGMpIDIwMTIgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUNCiAg IGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLg0KDQogICBUaGlzIGRvY3Vt ZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsDQogICBQ cm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzDQogICAoaHR0cDovL3RydXN0ZWUu aWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YNCg0KDQoNCkhh bm5hICYgTWFucmFsICAgICAgICAgICAgRXhwaXJlcyBKdW5lIDEwLCAyMDEzICAgICAgICAgICAg ICAgICBbUGFnZSAxXQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBBdXRvIERpc2NvdmVy eSBWUE4gICAgICAgICAgICAgIERlY2VtYmVyIDIwMTINCg0KDQogICBwdWJsaWNhdGlvbiBvZiB0 aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMNCiAgIGNhcmVmdWxs eSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVz cGVjdA0KICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJv bSB0aGlzIGRvY3VtZW50IG11c3QNCiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0 ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZg0KICAgdGhlIFRydXN0IExlZ2FsIFBy b3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzDQogICBkZXNjcmli ZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuDQoNCg0KVGFibGUgb2YgQ29udGVudHMN Cg0KICAgMS4gIEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAzDQogICAgIDEuMS4gIFRlcm1pbm9sb2d5ICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNCiAgICAgMS4yLiAgQ29udmVudGlv bnMgVXNlZCBpbiBUaGlzIERvY3VtZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0KICAg Mi4gIFVzZSBDYXNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICA1DQogICAgIDIuMS4gIEVuZHBvaW50LXRvLUVuZHBvaW50IEFEIFZQTiBVc2Ug Q2FzZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUNCiAgICAgMi4yLiAgR2F0ZXdheS10by1HYXRl d2F5IEFEIFZQTiBVc2UgQ2FzZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0KICAgICAyLjMu ICBFbmRwb2ludC10by1HYXRld2F5IEFEIFZQTiBVc2UgQ2FzZSAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA2DQogICAzLiAgSW5hZGVxdWFjeSBvZiBFeGlzdGluZyBTb2x1dGlvbnMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcNCiAgICAgMy4xLiAgRXhoYXVzdGl2ZSBDb25maWd1cmF0 aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0KICAgICAzLjIuICBTdGFy IFRvcG9sb2d5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3 DQogICAgIDMuMy4gIFByb3ByaWV0YXJ5IEFwcHJvYWNoZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDgNCiAgIDQuICBSZXF1aXJlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0KICAgICA0LjEuICBHYXRld2F5IGFu ZCBFbmRwb2ludCBSZXF1aXJlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DQogICA1 LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTINCiAgIDYuICBJQU5BIENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMw0KICAgNy4gIEFja25vd2xlZGdlbWVudHMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE0DQogICA4LiAgTm9y bWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMTUNCiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAxNg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCkhhbm5hICYgTWFucmFsICAgICAgICAgICAgRXhwaXJlcyBKdW5lIDEwLCAy MDEzICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICBBdXRvIERpc2NvdmVyeSBWUE4gICAgICAgICAgICAgIERlY2VtYmVyIDIwMTINCg0KDQoxLiAg SW50cm9kdWN0aW9uDQoNCiAgIElQc2VjIFtSRkM0MzAxXSBpcyB1c2VkIGluIHNldmVyYWwgZGlm ZmVyZW50IGNhc2VzLCBpbmNsdWRpbmcgdHVubmVsLQ0KICAgbW9kZSBzaXRlLXRvLXNpdGUgVlBO cyBhbmQgUmVtb3RlIEFjY2VzcyBWUE5zLiAgSG9zdCB0byBob3N0DQogICBjb21tdW5pY2F0aW9u IGVtcGxveWluZyB0cmFuc3BvcnQgbW9kZSBhbHNvIGV4aXN0cywgYnV0IGlzIGZhciBsZXNzDQog ICBjb21tb25seSBkZXBsb3llZC4NCg0KICAgVGhlIHN1YmplY3Qgb2YgdGhpcyBkb2N1bWVudCBp cyB0aGUgcHJvYmxlbSBwcmVzZW50ZWQgYnkgbGFyZ2Ugc2NhbGUNCiAgIGRlcGxveW1lbnRzIG9m IElQc2VjIGFuZCB0aGUgcmVxdWlyZW1lbnRzIG9uIGEgc29sdXRpb24gdG8gYWRkcmVzcw0KICAg dGhlIHByb2JsZW0uICBUaGVzZSBtYXkgYmUgYSBsYXJnZSBjb2xsZWN0aW9uIG9mIFZQTiBnYXRl d2F5cw0KICAgY29ubmVjdGluZyB2YXJpb3VzIHNpdGVzLCBhIGxhcmdlIG51bWJlciBvZiByZW1v dGUgZW5kcG9pbnRzDQogICBjb25uZWN0aW5nIHRvIGEgbnVtYmVyIG9mIGdhdGV3YXlzIG9yIHRv IGVhY2ggb3RoZXIsIG9yIGEgbWl4IG9mIHRoZQ0KICAgdHdvLiAgVGhlIGdhdGV3YXlzIGFuZCBl bmRwb2ludHMgbWF5IGJlbG9uZyB0byBhIHNpbmdsZQ0KICAgYWRtaW5pc3RyYXRpdmUgZG9tYWlu IG9yIHNldmVyYWwgZG9tYWlucyB3aXRoIGEgdHJ1c3QgcmVsYXRpb25zaGlwLg0KDQogICBTZWN0 aW9uIDQuNCBvZiBSRkMgNDMwMSBkZXNjcmliZXMgdGhlIG1ham9yIElQc2VjIGRhdGFiYXNlcyBu ZWVkZWQNCiAgIGZvciBJUHNlYyBwcm9jZXNzaW5nLiAgSXQgcmVxdWlyZXMgYW4gZXh0ZW5zaXZl IGNvbmZpZ3VyYXRpb24gZm9yDQogICBlYWNoIHR1bm5lbCwgc28gbWFudWFsbHkgY29uZmlndXJp bmcgYSBzeXN0ZW0gb2YgbWFueSBnYXRld2F5cyBhbmQNCiAgIGVuZHBvaW50cyBiZWNvbWVzIGlu ZmVhc2libGUgYW5kIGluZmxleGlibGUuDQoNCiAgIFRoZSBkaWZmaWN1bHR5IGlzIHRoYXQgYWxs IHRoZSBjb25maWd1cmF0aW9uIG1lbnRpb25lZCBpbiBSRkMgNDMwMSBpcw0KICAgbm90IHN1cGVy Zmx1b3VzLiAgSUtFIGltcGxlbWVudGF0aW9ucyBuZWVkIHRvIGtub3cgdGhlIGlkZW50aXR5IGFu ZA0KICAgY3JlZGVudGlhbHMgb2YgYWxsIHBvc3NpYmxlIHBlZXIgc3lzdGVtcywgYXMgd2VsbCBh cyB0aGUgYWRkcmVzc2VzIG9mDQogICBob3N0cyBhbmQvb3IgbmV0d29ya3MgYmVoaW5kIHRoZW0u ICBBIHNpbXBsaWZpZWQgbWVjaGFuaXNtIGZvcg0KICAgZHluYW1pY2FsbHkgZXN0YWJsaXNoaW5n IHBvaW50LXRvLXBvaW50IHR1bm5lbHMgaXMgbmVlZGVkLiAgU2VjdGlvbiAyDQogICBjb250YWlu cyBzZXZlcmFsIHVzZSBjYXNlcyB0aGF0IG1vdGl2YXRlIHRoaXMgZWZmb3J0Lg0KDQoxLjEuICBU ZXJtaW5vbG9neQ0KDQogICBFbmRwb2ludCAtIEEgZGV2aWNlIHRoYXQgaW1wbGVtZW50cyBJUHNl YyBmb3IgaXRzIG93biB0cmFmZmljIGJ1dA0KICAgZG9lcyBub3QgYWN0IGFzIGEgZ2F0ZXdheS4N Cg0KICAgR2F0ZXdheSAtIEEgbmV0d29yayBkZXZpY2UgdGhhdCBpbXBsZW1lbnRzIElQc2VjIHRv IHByb3RlY3QgdHJhZmZpYw0KICAgZmxvd2luZyB0aHJvdWdoIHRoZSBkZXZpY2UuDQoNCiAgIFBv aW50LXRvLVBvaW50IC0gRGlyZWN0IGNvbW11bmljYXRpb24gYmV0d2VlbiB0d28gcGFydGllcyB3 aXRob3V0DQogICBhY3RpdmUgcGFydGljaXBhdGlvbiAoZS5nLiBlbmNyeXB0aW9uIG9yIGRlY3J5 cHRpb24pIGJ5IGFueSBvdGhlcg0KICAgcGFydGllcy4NCg0KICAgSHViIC0gVGhlIGNlbnRyYWwg cG9pbnQgaW4gYSBzdGFyIHRvcG9sb2d5LyBkeW5hbWljIGZ1bGwgbWVzaA0KICAgdG9wb2xvZ3ks IG9yIG9uZSBvZiB0aGUgY2VudHJhbCBwb2ludHMgaW4gdGhlIGZ1bGwgbWVzaCBzdHlsZSBWUE4s DQogICBpLmUuIGdhdGV3YXkgd2hlcmUgbXVsdGlwbGUgb3RoZXIgaHVicyBvciBzcG9rZXMgY29u bmVjdCB0by4gIFRoZQ0KICAgaHVicyB1c3VhbGx5IGZvcndhcmQgdHJhZmZpYyBjb21pbmcgZnJv bSBlbmNyeXB0ZWQgbGlua3MgdG8gb3RoZXINCiAgIGVuY3J5cHRlZCBsaW5rcywgaS5lLiB0aGVy ZSBpcyBubyBkZXZpY2VzIGNvbm5lY3RlZCB0byBpdCBpbiBjbGVhci4NCg0KICAgU3Bva2UgLSBU aGUgZWRnZSBkZXZpY2VzIGluIHRoZSBhIHN0YXIgdG9wb2xvZ3kvIGR5bmFtaWMgZnVsbCBtZXNo DQogICB0b3BvbG9neSwgb3IgZ2F0ZXdheSB3aGljaCBmb3J3YXJkcyB0cmFmZmljIGZyb20gbXVs dGlwbGUgY2xlYXJ0ZXh0DQogICBkZXZpY2VzIHRvIG90aGVyIGh1YnMgb3Igc3Bva2VzLCBhbmQg c29tZSBvZiB0aG9zZSBvdGhlciBkZXZpY2VzIGFyZQ0KDQoNCg0KSGFubmEgJiBNYW5yYWwgICAg ICAgICAgICBFeHBpcmVzIEp1bmUgMTAsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoN CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgIEF1dG8gRGlzY292ZXJ5IFZQTiAgICAgICAgICAg ICAgRGVjZW1iZXIgMjAxMg0KDQoNCiAgIGNvbm5lY3RlZCB0byBpdCBpbiBjbGVhciAoaS5lLiBp dCBlbmNyeXB0IGRhdGEgY29taW5nIGZyb20gY2xlYXJ0ZXh0DQogICBkZXZpY2UgYW5kIGZvcndh cmRzIGl0IHRvIHRoZSBBRCBWUE4pLg0KDQogICBTdGFyIHRvcG9sb2d5IC0gVGhpcyBpcyB0aGUg dG9wb2xvZ3kgd2hlcmUgdGhlcmUgaXMgZGlyZWN0DQogICBjb25uZWN0aXZpdHkgb25seSBiZXR3 ZWVuIHRoZSBodWIgYW5kIHNwb2tlIGFuZCBjb21tdW5pY2F0aW9uIGJldHdlZW4NCiAgIHRoZSAy IHNwb2tlcyBoYXBwZW5zIHRocm91Z2ggdGhlIGh1Yi4NCg0KICAgRnVsbCBNZXNoIHRvcG9sb2d5 IC0gVGhpcyBpcyB0aGUgdG9wb2xvZ3kgd2hlcmUgdGhlcmUgaXMgYSBkaXJlY3QNCiAgIGNvbm5l Y3Rpdml0eSBiZXR3ZWVuIGV2ZXJ5IFNwb2tlIHRvIGV2ZXJ5IG90aGVyIFNwb2tlIGRpcmVjdGx5 LA0KICAgd2l0aG91dCB0aGUgdHJhZmZpYyBiZXR3ZWVuIHRoZSBzcG9rZXMgaGF2aW5nIHRvIGJl IHJlZGlyZWN0ZWQNCiAgIHRocm91Z2ggYW4gaW50ZXJtZWRpYXRlIGh1YiBkZXZpY2UuDQoNCiAg IER5bmFtaWMgRnVsbCBNZXNoIHRvcG9sb2d5IC0gVGhpcyBpcyB0aGUgdG9wb2xvZ3kgd2hlcmUg ZGlyZWN0DQogICBjb25uZWN0aW9ucyBleGlzdCBpbiBhIGh1YiBhbmQgc3Bva2UgbWFubmVyLCBi dXQgZHluYW1pYyBjb25uZWN0aW9ucw0KICAgYXJlIGNyZWF0ZWQvIHJlbW92ZWQgYmV0d2VlbiB0 aGUgc3Bva2VzIG9uIGEgbmVlZCBiYXNpcy4NCg0KICAgU2VjdXJpdHkgQXNzb2NpYXRpb24gKFNB KSAtIERlZmluZWQgaW4gW1JGQzQzMDFdLg0KDQoxLjIuICBDb252ZW50aW9ucyBVc2VkIGluIFRo aXMgRG9jdW1lbnQNCg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFV SVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwg IlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCiAgIGRvY3VtZW50 IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpIYW5uYSAm IE1hbnJhbCAgICAgICAgICAgIEV4cGlyZXMgSnVuZSAxMCwgMjAxMyAgICAgICAgICAgICAgICAg W1BhZ2UgNF0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgQXV0byBEaXNjb3ZlcnkgVlBO ICAgICAgICAgICAgICBEZWNlbWJlciAyMDEyDQoNCg0KMi4gIFVzZSBDYXNlcw0KDQogICBUaGlz IHNlY3Rpb24gcHJlc2VudHMgdGhlIGtleSB1c2UgY2FzZXMgZm9yIGxhcmdlLXNjYWxlIHBvaW50 LXRvLQ0KICAgcG9pbnQgVlBOLg0KDQogICBJbiBhbGwgb2YgdGhlc2UgdXNlIGNhc2VzLCB0aGUg cGFydGljaXBhbnRzIChlbmRwb2ludHMgYW5kIGdhdGV3YXlzKQ0KICAgbWF5IGJlIGZyb20gYSBz aW5nbGUgb3JnYW5pemF0aW9uIG9yIGZyb20gbXVsdGlwbGUgb3JnYW5pemF0aW9ucyB3aXRoDQog ICBhbiBlc3RhYmxpc2hlZCB0cnVzdCByZWxhdGlvbnNoaXAuICBXaGVuIG11bHRpcGxlIG9yZ2Fu aXphdGlvbnMgYXJlDQogICBpbnZvbHZlZCwgcHJvZHVjdHMgZnJvbSBtdWx0aXBsZSB2ZW5kb3Jz IGFyZSBlbXBsb3llZCBzbyBvcGVuDQogICBzdGFuZGFyZHMgYXJlIG5lZWRlZCB0byBwcm92aWRl IGludGVyb3BlcmFiaWxpdHkuICBFc3RhYmxpc2hpbmcNCiAgIGNvbW11bmljYXRpb25zIGJldHdl ZW4gcGFydGljaXBhbnRzIHdpdGggbm8gZXN0YWJsaXNoZWQgdHJ1c3QNCiAgIHJlbGF0aW9uc2hp cCBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgZWZmb3J0Lg0KDQoyLjEuICBFbmRwb2ludC10by1F bmRwb2ludCBBRCBWUE4gVXNlIENhc2UNCg0KICAgVHdvIGVuZHBvaW50cyB3aXNoIHRvIGNvbW11 bmljYXRlIHNlY3VyZWx5IHZpYSBhIGRpcmVjdCwgcG9pbnQtdG8tDQogICBwb2ludCBTZWN1cml0 eSBBc3NvY2lhdGlvbiAoU0EpLg0KDQogICBUaGUgbmVlZCBmb3Igc2VjdXJlIGVuZHBvaW50IHRv IGVuZHBvaW50IGNvbW11bmljYXRpb25zIGlzIG9mdGVuDQogICBkcml2ZW4gYnkgYSBuZWVkIHRv IGVtcGxveSBoaWdoLWJhbmR3aWR0aCwgbG93IGxhdGVuY3kgbG9jYWwNCiAgIGNvbm5lY3Rpdml0 eSBpbnN0ZWFkIG9mIHVzaW5nIHNsb3csIGV4cGVuc2l2ZSBsaW5rcyB0byByZW1vdGUNCiAgIGdh dGV3YXlzLiAgRm9yIGV4YW1wbGUsIHR3byB1c2VycyBpbiBjbG9zZSBwcm94aW1pdHkgbWF5IHdp c2ggdG8NCiAgIHBsYWNlIGEgZGlyZWN0LCBzZWN1cmUgdmlkZW8gb3Igdm9pY2UgY2FsbCB3aXRo b3V0IG5lZWRpbmcgdG8gc2VuZA0KICAgdGhlIGNhbGwgdGhyb3VnaCByZW1vdGUgZ2F0ZXdheXMs IHdoaWNoIHdvdWxkIGFkZCBsYXRlbmN5IHRvIHRoZQ0KICAgY2FsbCwgY29uc3VtZSBwcmVjaW91 cyByZW1vdGUgYmFuZHdpZHRoLCBhbmQgaW5jcmVhc2Ugb3ZlcmFsbCBjb3N0cy4NCiAgIFN1Y2gg YSB1c2UgY2FzZSBhbHNvIGVuYWJsZXMgY29ubmVjdGl2aXR5IHdoZW4gYm90aCBlbmRwb2ludHMg YXJlDQogICBiZWhpbmQgTkFUIGdhdGV3YXlzLiAgU3VjaCB1c2UgY2FzZSBzaG91bGQgYWxsb3cg Zm9yIHNlYW1sZXNzDQogICBjb25uZWN0aXZpdHkgZXZlbiBhcyBlbmRwb2ludHMgcm9hbSwgZXZl biBpZiB0aGV5IGFyZSBtb3Zpbmcgb3V0IGZyb20NCiAgIGJlaGluZCBhIE5BVCBnYXRld2F5LCBm cm9tIGJlaGluZCBvbmUgTkFUIGdhdGV3YXkgdG8gYmVoaW5kIGFub3RoZXIsDQogICBvciBmcm9t IGEgc3RhbmRhbG9uZSBwb3NpdGlvbiB0byBiZWhpbmQgYSBOQVQgZ2F0ZXdheS4NCg0KICAgSW4g YSBodWIgYW5kIHNwb2tlIHRvcG9sb2d5IHdoZW4gdHdvIGVuZHBvaW50cyBjb21tdW5pY2F0ZSwg dGhleSBtdXN0DQogICB1c2UgYSBtZWNoYW5pc20gZm9yIGF1dGhlbnRpY2F0aW9uLCBzdWNoIHRo YXQgdGhleSBkbyBub3QgZXhwb3NlIHRoZW0NCiAgIHRvIGltcGVyc29uYXRpb24gYnkgdGhlIG90 aGVyIHNwb2tlIGVuZHBvaW50Lg0KDQoyLjIuICBHYXRld2F5LXRvLUdhdGV3YXkgQUQgVlBOIFVz ZSBDYXNlDQoNCiAgIEEgdHlwaWNhbCBFbnRlcnByaXNlIHRyYWZmaWMgbW9kZWwgZm9sbG93cyBh IHN0YXIgdG9wb2xvZ3ksIHdpdGggdGhlDQogICBnYXRld2F5cyBjb25uZWN0aW5nIHRvIGVhY2gg b3RoZXIgdXNpbmcgSVBzZWMgdHVubmVscy4NCg0KICAgSG93ZXZlciBmb3IgdGhlIHZvaWNlIGFu ZCBvdGhlciByaWNoIG1lZGlhIHRyYWZmaWMgdGhhdCByZXF1aXJlcyBhDQogICBsb3Qgb2YgYmFu ZHdpZHRoIG9yIGlzIHBlcmZvcm1hbmNlIHNlbnNpdGl2ZSwgdGhlIHRyYWZmaWMgdHJvbWJvbmlu Zw0KICAgdG8gdGhlIGh1YiBjYW4gY3JlYXRlIHRyYWZmaWMgYm90dGxlbmVja3Mgb24gdGhlIGh1 YiBhbmQgY2FuIGxlYWQgdG8NCiAgIGFuIGluY3JlYXNlIGluIGNvc3QuICBBIGZ1bGx5IG1lc2hl ZCBzb2x1dGlvbiBpcyB3b3VsZCBtYWtlIGJlc3QgdXNlDQogICBvZiB0aGUgYXZhaWxhYmxlIG5l dHdvcmsgY2FwYWNpdHkgYW5kIHBlcmZvcm1hbmNlIGJ1dCB0aGUgZGVwbG95bWVudA0KICAgb2Yg YSBmdWxseSBtZXNoZWQgc29sdXRpb24gaW52b2x2ZXMgY29uc2lkZXJhYmxlIGNvbmZpZ3VyYXRp b24sDQogICBlc3BlY2lhbGx5IHdoZW4gYSBsYXJnZSBudW1iZXIgb2Ygbm9kZXMgYXJlIGludm9s dmVkLiAgSXQgaXMgZm9yIHRoaXMNCiAgIHB1cnBvc2Ugc3Bva2UtdG8tc3Bva2UgdHVubmVscyBh cmUgZHluYW1pY2FsbHkgY3JlYXRlZCBhbmQgdG9ybi1kb3duLg0KDQoNCg0KSGFubmEgJiBNYW5y YWwgICAgICAgICAgICBFeHBpcmVzIEp1bmUgMTAsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdl IDVdDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgIEF1dG8gRGlzY292ZXJ5IFZQTiAgICAg ICAgICAgICAgRGVjZW1iZXIgMjAxMg0KDQoNCiAgIEZvciB0aGUgcmVhc29ucyBvZiBjb3N0IGFu ZCBtYW51YWwgZXJyb3IgcmVkdWN0aW9uLCBpdCBpcyBkZXNpcmVkDQogICB0aGF0IHRoZXJlIGJl IG1pbmltYWwgY29uZmlndXJhdGlvbiBvbiBlYWNoIGdhdGV3YXkuDQoNCiAgIFRoZSBzb2x1dGlv biBzaG91bGQgd29yayBpbiBjYXNlcyB3aGVyZSB0aGUgZW5kcG9pbnRzIGFyZQ0KICAgYWRtaW5p c3RyYXRlZCBieSBzZXBhcmF0ZSBtYW5hZ2VtZW50IGRvbWFpbnMsIGFsYmVpdCwgb25lcyB0aGF0 IGhhdmUNCiAgIGFuIGV4aXN0aW5nIHRydXN0IHJlbGF0aW9uc2hpcCAoZm9yIGV4YW1wbGUgdHdv IG9yZ2FuaXNhdGlvbnMgd2hvIGFyZQ0KICAgY29sbGFib3JhdGluZyBvbiBhIHByb2plY3QsIHRo ZXkgbWF5IHdpc2ggdG8gam9pbiB0aGVpciBuZXR3b3JrcywNCiAgIHdoaWxzdCByZXRhaW5pbmcg aW5kZXBlbmRlbnQgY29udHJvbCBvdmVyIGNvbmZpZ3VyYXRpb24pLiAgSXQgaXMNCiAgIGhpZ2hs eSBkZXNpcmFibGUgdGhhdCB0aGUgc29sdXRpb24gd29ya3MgZm9yIHRoZSBzdGFyLCBmdWxsIG1l c2ggYXMNCiAgIHdlbGwgYXMgZHluYW1pYyBmdWxsIG1lc2ggdG9wb2xvZ3kuDQoNCiAgIFRoZSBz b2x1dGlvbiBzaG91bGQgYWxzbyBhZGRyZXNzIHRoZSBjYXNlIHdoZXJlIGdhdGV3YXlzIHVzZSBk eW5hbWljDQogICBJUCBhZGRyZXNzZXMuDQoNCiAgIEFkZGl0aW9uYWxseSwgdGhlIHJvdXRpbmcg aW1wbGljYXRpb25zIG9mIGdhdGV3YXktdG8tZ2F0ZXdheQ0KICAgY29tbXVuaWNhdGlvbiBtdXN0 IGJlIGFkZHJlc3NlZC4gIEluIHRoZSBzaW1wbGUgY2FzZSwgc2VsZWN0b3JzDQogICBwcm92aWRl IHN1ZmZpY2llbnQgaW5mb3JtYXRpb24gZm9yIGEgZ2F0ZXdheSB0byBmb3J3YXJkIHRyYWZmaWMN CiAgIGFwcHJvcHJpYXRlbHkuICBJbiBvdGhlciBjYXNlcywgYWRkaXRpb25hbCB0dW5uZWxpbmcg KGUuZy4sIEdSRSkgYW5kDQogICByb3V0aW5nIChlLmcuLCBPU1BGKSBwcm90b2NvbHMgYXJlIHJ1 biBvdmVyIElQc2VjIHR1bm5lbHMsIGFuZCB0aGUNCiAgIGNvbmZpZ3VyYXRpb24gaW1wYWN0IG9u IHRob3NlIHByb3RvY29scyBtdXN0IGJlIGNvbnNpZGVyZWQuICBUaGVyZSBpcw0KICAgYWxzbyB0 aGUgY2FzZSB3aGVuIEwzVlBOcyBvcGVyYXRlIG92ZXIgSVBzZWMgVHVubmVscy4NCg0KICAgV2hl biB0d28gZ2F0ZXdheXMgY29tbXVuaWNhdGUsIHRoZXkgbXVzdCB1c2UgYSBtZWNoYW5pc20gZm9y DQogICBhdXRoZW50aWNhdGlvbiwgc3VjaCB0aGF0IHRoZXkgZG8gbm90IGV4cG9zZSB0aGVtc2Vs dmVzIHRvIHRoZSByaXNrDQogICBvZiBpbXBlcnNvbmF0aW9uIGJ5IHRoZSBvdGhlciBlbnRpdGll cy4NCg0KMi4zLiAgRW5kcG9pbnQtdG8tR2F0ZXdheSBBRCBWUE4gVXNlIENhc2UNCg0KICAgQW4g ZW5kcG9pbnQgc2hvdWxkIGJlIGFibGUgdG8gdXNlIHRoZSBtb3N0IGVmZmljaWVudCBnYXRld2F5 IGFzIGl0DQogICByb2FtcyBpbiB0aGUgaW50ZXJuZXQuDQoNCiAgIEEgbW9iaWxlIHVzZXIgcm9h bWluZyBvbiB0aGUgSW50ZXJuZXQgbWF5IGNvbm5lY3QgdG8gYSBnYXRld2F5LCB3aGljaA0KICAg YmVjYXVzZSBvZiByb2FtaW5nIGlzIG5vIGxvbmdlciB0aGUgbW9zdCBlZmZpY2llbnQgZ2F0ZXdh eSB0byB1c2UNCiAgIChyZWFzb25zIGNvdWxkIGJlIGNvc3QvIGVmZmljaWVuY3kvIGxhdGVuY3kg b3Igc29tZSBvdGhlciBmYWN0b3IpLg0KICAgVGhlIG1vYmlsZSB1c2VyIHNob3VsZCBiZSBhYmxl IHRvIGRpc2NvdmVyIGFuZCB0aGVuIGNvbm5lY3QgdG8gdGhlDQogICBjdXJyZW50IG1vc3QgZWZm aWNpZW50IGdhdGV3YXkgd2l0aG91dCBoYXZpbmcgdG8gcmVpbml0aWF0ZSB0aGUNCiAgIGNvbm5l Y3Rpb24uDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KSGFubmEgJiBNYW5yYWwgICAgICAg ICAgICBFeHBpcmVzIEp1bmUgMTAsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDZdDQoNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgIEF1dG8gRGlzY292ZXJ5IFZQTiAgICAgICAgICAgICAg RGVjZW1iZXIgMjAxMg0KDQoNCjMuICBJbmFkZXF1YWN5IG9mIEV4aXN0aW5nIFNvbHV0aW9ucw0K DQogICBTZXZlcmFsIHNvbHV0aW9ucyBleGlzdCBmb3IgdGhlIHByb2JsZW1zIGRlc2NyaWJlZCBh Ym92ZS4gIEhvd2V2ZXIsDQogICBub25lIG9mIHRoZXNlIHNvbHV0aW9ucyBpcyBhZGVxdWF0ZSwg YXMgZGVzY3JpYmVkIGhlcmUuDQoNCjMuMS4gIEV4aGF1c3RpdmUgQ29uZmlndXJhdGlvbg0KDQog ICBPbmUgc2ltcGxlIHNvbHV0aW9uIGlzIHRvIGNvbmZpZ3VyZSBhbGwgZ2F0ZXdheXMgYW5kIGVu ZHBvaW50cyBpbg0KICAgYWR2YW5jZSB3aXRoIGFsbCB0aGUgaW5mb3JtYXRpb24gbmVlZGVkIHRv IGRldGVybWluZSB3aGljaCBnYXRld2F5IG9yDQogICBlbmRwb2ludCBpcyBvcHRpbWFsIGFuZCB0 byBlc3RhYmxpc2ggYW4gU0Egd2l0aCB0aGF0IGdhdGV3YXkgb3INCiAgIGVuZHBvaW50LiAgSG93 ZXZlciwgdGhpcyBzb2x1dGlvbiBkb2VzIG5vdCBzY2FsZSBpbiBhIGxhcmdlIG5ldHdvcmsNCiAg IHdpdGggaHVuZHJlZHMgb2YgdGhvdXNhbmRzIG9mIGdhdGV3YXlzIGFuZCBlbmRwb2ludHMsIGVz cGVjaWFsbHkgd2hlbg0KICAgbXVsdGlwbGUgb3JnYW5pemF0aW9ucyBhcmUgaW52b2x2ZWQgYW5k IHRoaW5ncyBhcmUgcmFwaWRseSBjaGFuZ2luZw0KICAgKGUuZy4gbW9iaWxlIGVuZHBvaW50cyku ICBTdWNoIGEgc29sdXRpb24gaXMgYWxzbyBsaW1pdGVkIGJ5IHRoZQ0KICAgc21hbGxlc3QgZW5k cG9pbnQvIGdhdGV3YXksIGFzIHRoZSBzYW1lIGV4aGF1c3RpdmUgY29uZmlndXJhdGlvbiBpcw0K ICAgdG8gYmUgYXBwbGllZCBvbiBhbGwgZW5kcG9pbnRzLyBnYXRld2F5cy4gIEEgbW9yZSBkeW5h bWljLCBzZWN1cmUgYW5kDQogICBzY2FsYWJsZSBzeXN0ZW0gZm9yIGVzdGFibGlzaGluZyBTQXMg YmV0d2VlbiBnYXRld2F5cyBpcyBuZWVkZWQuDQoNCjMuMi4gIFN0YXIgVG9wb2xvZ3kNCg0KICAg VGhlIG1vc3QgY29tbW9uIHdheSB0byBhZGRyZXNzIGEgcGFydCBvZiB0aGlzIHRoaXMgcHJvYmxl bSB0b2RheSBpcw0KICAgdG8gdXNlIHdoYXQgaGFzIGJlZW4gdGVybWVkIGEgInN0YXIgdG9wb2xv Z3kiLiAgSW4gdGhpcyBjYXNlIG9uZSBvciBhDQogICBmZXcgZ2F0ZXdheXMgYXJlIGRlZmluZWQg YXMgImh1YiBnYXRld2F5cyIsIHdoaWxlIHRoZSByZXN0IG9mIHRoZQ0KICAgc3lzdGVtcyAod2hl dGhlciBlbmRwb2ludHMgb3IgZ2F0ZXdheXMpIGFyZSBkZWZpbmVkIGFzICJzcG9rZXMiLiAgVGhl DQogICBzcG9rZXMgbmV2ZXIgY29ubmVjdCB0byBvdGhlciBzcG9rZXMuICBUaGV5IG9ubHkgb3Bl biB0dW5uZWxzIHdpdGgNCiAgIHRoZSBodWIgZ2F0ZXdheXMuICBBbHNvIGZvciBhIGxhcmdlIG51 bWJlciBvZiBnYXRld2F5cyBpbiBvbmUNCiAgIGFkbWluaXN0cmF0aXZlIGRvbWFpbiwgb25lIGdh dGV3YXkgbWF5IGJlIGRlZmluZWQgYXMgdGhlIGh1YiwgYW5kIHRoZQ0KICAgcmVzdCBvZiB0aGUg Z2F0ZXdheXMgYW5kIHJlbW90ZSBhY2Nlc3MgY2xpZW50cyBjb25uZWN0IG9ubHkgdG8gdGhhdA0K ICAgZ2F0ZXdheS4NCg0KICAgVGhpcyBzb2x1dGlvbiBob3dldmVyIGlzIGNvbXBsaWNhdGVkIGJ5 IHRoZSBjYXNlIHdoZW4gdGhlIHNwb2tlcyB1c2UNCiAgIGR5bmFtaWMgSVAgYWRkcmVzc2VzIGFu ZCBETlMgd2l0aCBkeW5hbWljIHVwZGF0ZXMgbXVzdCBiZSB1c2VkLiAgSXQNCiAgIGlzIGFsc28g ZGVzaXJlZCB0aGF0IHRoZXJlIGlzIG1pbmltYWwgdG8gbm8gY29uZmlndXJhdGlvbiBvbiB0aGUg aHViDQogICBhcyB0aGUgbnVtYmVyIG9mIHNwb2tlcyBpbmNyZWFzZXMgYW5kIG5ldyBzcG9rZXMg YXJlIGFkZGVkIGFuZA0KICAgZGVsZXRlZCByYW5kb21seS4NCg0KICAgQW5vdGhlciBwcm9ibGVt IHdpdGggdGhlIHN0YXIgdG9wb2xvZ3kgaXMgdGhhdCBpdCBjcmVhdGVzIGEgaGlnaCBsb2FkDQog ICBvbiB0aGUgaHViIGdhdGV3YXlzIGFzIHdlbGwgYXMgb24gdGhlIGNvbm5lY3Rpb24gYmV0d2Vl biB0aGUgc3Bva2VzDQogICBhbmQgdGhlIGh1Yi4gIFRoaXMgbG9hZCBpcyBib3RoIGluIHByb2Nl c3NpbmcgcG93ZXIgYW5kIGluIG5ldHdvcmsNCiAgIGJhbmR3aWR0aC4gIEEgc2luZ2xlIHBhY2tl dCBpbiB0aGUgaHViLWFuZC1zcG9rZSBzY2VuYXJpbyBjYW4gYmUNCiAgIGVuY3J5cHRlZCBhbmQg ZGVjcnlwdGVkIG11bHRpcGxlIHRpbWVzLiAgSXQgd291bGQgYmUgbXVjaCBwcmVmZXJhYmxlDQog ICBpZiB0aGVzZSBnYXRld2F5cyBhbmQgY2xpZW50cyBjb3VsZCBpbml0aWF0ZSB0dW5uZWxzIGJl dHdlZW4gdGhlbSwNCiAgIGJ5cGFzc2luZyB0aGUgaHViIGdhdGV3YXlzLiAgQWRkaXRpb25hbGx5 LCB0aGUgcGF0aCBiYW5kd2lkdGggdG8NCiAgIHRoZXNlIGh1YiBnYXRld2F5cyBtYXkgYmUgbG93 ZXIgdGhhbiB0aGF0IG9mIHRoZSBwYXRoIGJldHdlZW4gdGhlDQogICBzcG9rZXMuICBGb3IgZXhh bXBsZSwgdHdvIHJlbW90ZSBhY2Nlc3MgdXNlcnMgbWF5IGJlIGluIHRoZSBzYW1lDQogICBidWls ZGluZyB3aXRoIGhpZ2gtc3BlZWQgd2lmaSAoZm9yIGV4YW1wbGUsIGF0IGFuIElFVEYgbWVldGlu ZykuDQogICBDaGFubmVsaW5nIHRoZWlyIGNvbnZlcnNhdGlvbiB0aHJvdWdoIHRoZSBodWIgZ2F0 ZXdheXMgb2YgdGhlaXINCiAgIHJlc3BlY3RpdmUgZW1wbG95ZXJzIHNlZW1zIGV4dHJlbWVseSB3 YXN0ZWZ1bCwgYXMgd2VsbCBhcyBoYXZpbmcNCg0KDQoNCkhhbm5hICYgTWFucmFsICAgICAgICAg ICAgRXhwaXJlcyBKdW5lIDEwLCAyMDEzICAgICAgICAgICAgICAgICBbUGFnZSA3XQ0KDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICBBdXRvIERpc2NvdmVyeSBWUE4gICAgICAgICAgICAgIERl Y2VtYmVyIDIwMTINCg0KDQogICBsb3dlciBiYW5kd2lkdGguDQoNCiAgIFRoZSBjaGFsbGVuZ2Ug aXMgdG8gYnVpbGQgYSBsYXJnZSBzY2FsZSwgSVBzZWMgcHJvdGVjdGVkIG5ldHdvcmtzDQogICB0 aGF0IGNhbiBkeW5hbWljYWxseSBjaGFuZ2Ugd2l0aCBtaW5pbXVtIGFkbWluaXN0cmF0aXZlIG92 ZXJoZWFkLg0KDQozLjMuICBQcm9wcmlldGFyeSBBcHByb2FjaGVzDQoNCiAgIFNldmVyYWwgdmVu ZG9ycyBvZmZlciBwcm9wcmlldGFyeSBzb2x1dGlvbnMgdG8gdGhlc2UgcHJvYmxlbXMuDQogICBI b3dldmVyLCB0aGVzZSBzb2x1dGlvbnMgb2ZmZXIgbm8gaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVu IGVxdWlwbWVudA0KICAgZnJvbSBvbmUgdmVuZG9yIGFuZCBhbm90aGVyLiAgVGhpcyBtZWFucyB0 aGF0IHRoZXkgYXJlIGdlbmVyYWxseQ0KICAgcmVzdHJpY3RlZCB0byB1c2Ugd2l0aGluIG9uZSBv cmdhbml6YXRpb24sIGFuZCBpdCBpcyBoYXJkZXIgdG8gbW92ZQ0KICAgb2ZmIHN1Y2ggc29sdXRp b25zIGFzIHRoZSBmZWF0dXJlcyBhcmUgbm90IHN0YW5kYXJkaXplZC4gIEJlc2lkZXMNCiAgIG11 bHRpcGxlIG9yZ2FuaXphdGlvbnMgY2Fubm90IGJlIGV4cGVjdGVkIHRvIGFsbCBjaG9vc2UgdGhl IHNhbWUNCiAgIGVxdWlwbWVudCB2ZW5kb3IuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkhhbm5hICYgTWFu cmFsICAgICAgICAgICAgRXhwaXJlcyBKdW5lIDEwLCAyMDEzICAgICAgICAgICAgICAgICBbUGFn ZSA4XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBBdXRvIERpc2NvdmVyeSBWUE4gICAg ICAgICAgICAgIERlY2VtYmVyIDIwMTINCg0KDQo0LiAgUmVxdWlyZW1lbnRzDQoNCiAgIFRoaXMg c2VjdGlvbmRlZmluZXMgdGhlIHJlcXVpcmVtZW50cywgb24gd2hpY2ggdGhlIHNvbHV0aW9uIHdp bGwgYmUNCiAgIGJhc2VkLg0KDQo0LjEuICBHYXRld2F5IGFuZCBFbmRwb2ludCBSZXF1aXJlbWVu dHMNCg0KICAgMS4gIEZvciBhbnkgbmV0d29yayB0b3BvbG9neSAoc3RhciwgZnVsbCBtZXNoIGFu ZCBkeW5hbWljIGZ1bGwgbWVzaCkNCiAgIGdhdGV3YXlzIGFuZCBlbmRwb2ludHMgTVVTVCBtaW5p bWl6ZSBjb25maWd1cmF0aW9uIGNoYW5nZXMgd2hlbiBhIG5ldw0KICAgZ2F0ZXdheSBvciBlbmRw b2ludCBpcyBhZGRlZCwgcmVtb3ZlZCBvciBjaGFuZ2VkLiAgQWRkaW5nIG9yIHJlbW92aW5nDQog ICBhIHNwb2tlIGluIHRoZSB0b3BvbG9neSBNVVNUIE5PVCByZXF1aXJlIGNvbmZpZ3VyYXRpb24g Y2hhbmdlcyB0byB0aGUNCiAgIGh1YnMgb3RoZXIgdGhhbiB3aGVyZSB0aGUgc3Bva2Ugd2FzIGNv bm5lY3RlZCB0byBhbmQgU0hPVUxEIE5PVA0KICAgcmVxdWlyZSBjb25maWd1cmF0aW9uIGNoYW5n ZXMgdG8gdGhlIGh1YiB0aGUgc3Bva2Ugd2FzIGNvbm5lY3RlZCB0by4NCiAgIFRoZSBjaGFuZ2Vz IGFsc28gTVVTVCBOT1QgcmVxdWlyZSBjb25maWd1cmF0aW9uIGNoYW5nZXMgaW4gb3RoZXINCiAg IHNwb2tlcy4NCg0KICAgU3BlY2lmaWNhbGx5LCB3aGVuIGV2YWx1YXRpbmcgcG90ZW50aWFsIHBy b3Bvc2Fscywgd2Ugd2lsbCBjb21wYXJlDQogICB0aGVtIGJ5IGxvb2tpbmcgYXQgaG93IG1hbnkg ZW5kcG9pbnRzIG9yIGdhdGV3YXlzIG11c3QgYmUNCiAgIHJlY29uZmlndXJlZCB3aGVuIGEgbmV3 IGdhdGV3YXkgb3IgZW5kcG9pbnQgaXMgYWRkZWQsIHJlbW92ZWQsIG9yDQogICBjaGFuZ2VkIGFu ZCBob3cgc3Vic3RhbnRpYWwgdGhpcyByZWNvbmZpZ3VyYXRpb24gaXMsIGJlc2lkZXMgdGhlDQog ICBhbW91bnQgb2Ygc3RhdGljIGNvbmZpZ3VyYXRpb24gcmVxdWlyZWQuDQoNCiAgIFRoaXMgcmVx dWlyZW1lbnQgaXMgZHJpdmVuIGJ5IHVzZSBjYXNlcyAyLjEgYW5kIDIuMiBhbmQgYnkgdGhlDQog ICBzY2FsaW5nIGxpbWl0YXRpb25zIHBvaW50ZWQgb3V0IGluIHNlY3Rpb24gMy4xLg0KDQogICAy LiAgR2F0ZXdheXMgYW5kIGVuZHBvaW50cyBNVVNUIGFsbG93IElQc2VjIFR1bm5lbHMgdG8gYmUg c2V0dXANCiAgIHdpdGhvdXQgYW55IGNvbmZpZ3VyYXRpb24gY2hhbmdlcywgZXZlbiB3aGVuIHBl ZXIgYWRkcmVzc2VzIGdldA0KICAgdXBkYXRlZCBldmVyeSB0aW1lIHRoZSBkZXZpY2UgY29tZXMg dXAuICBUaGlzIGltcGxpZXMgdGhhdCBTUEQNCiAgIGVudHJpZXMgb3Igb3RoZXIgY29uZmlndXJh dGlvbiBiYXNlZCBvbiBwZWVyIElQIGFkZHJlc3Mgd2lsbCBuZWVkIHRvDQogICBiZSBhdXRvbWF0 aWNhbGx5IHVwZGF0ZWQsIGF2b2lkZWQsIG9yIGhhbmRsZWQgaW4gc29tZSBtYW5uZXIgdG8gYXZv aWQNCiAgIGEgbmVlZCB0byBtYW51YWxseSB1cGRhdGUgcG9saWN5IHdoZW5ldmVyIGFuIGFkZHJl c3MgY2hhbmdlcy4NCg0KICAgVGhpcyByZXF1aXJlbWVudCBpcyBkcml2ZW4gYnkgdXNlIGNhc2Vz IDIuMSBhbmQgMi4yIGFuZCBieSB0aGUNCiAgIHNjYWxpbmcgbGltaXRhdGlvbnMgcG9pbnRlZCBv dXQgaW4gc2VjdGlvbiAzLjEuDQoNCiAgIDMuICBJbiBtYW55IGNhc2VzIGFkZGl0aW9uYWwgdHVu bmVsaW5nIHByb3RvY29scyAoZS5nLiAgR1JFKSBvcg0KICAgUm91dGluZyBwcm90b2NvbHMgKGUu Zy4gIE9TUEYpIGFyZSBydW4gb3ZlciB0aGUgSVBzZWMgdHVubmVscy4NCiAgIEdhdGV3YXlzIE1V U1QgYWxsb3cgZm9yIHRoZSBvcGVyYXRpb24gb2YgdHVubmVsaW5nIGFuZCBSb3V0aW5nDQogICBw cm90b2NvbHMgb3BlcmF0aW5nIG92ZXIgc3Bva2UtdG8tc3Bva2UgSVBzZWMgVHVubmVscyB3aXRo IG1pbmltYWwgb3INCiAgIG5vLCBjb25maWd1cmF0aW9uIGltcGFjdC4gIFRoZSBBRFZQTiBzb2x1 dGlvbiBTSE9VTEQgTk9UIGluY3JlYXNlIHRoZQ0KICAgYW1vdW50IG9mIGluZm9ybWF0aW9uIHJl cXVpcmVkIHRvIGNvbmZpZ3VyZSBwcm90b2NvbHMgcnVubmluZyBvdmVyDQogICBJUHNlYyB0dW5u ZWxzLg0KDQogICA0LiAgSW4gdGhlIGZ1bGwgbWVzaCBhbmQgZHluYW1pYyBmdWxsIG1lc2ggdG9w b2xvZ3ksIFNwb2tlcyBNVVNUDQogICBhbGxvdyBmb3IgZGlyZWN0IGNvbW11bmljYXRpb24gd2l0 aCBvdGhlciBzcG9rZSBnYXRld2F5cyBhbmQNCiAgIGVuZHBvaW50cy4gIEluIHRoZSBzdGFyIHRv cG9sb2d5IG1vZGUsIGRpcmVjdCBjb21tdW5pY2F0aW9uIGJldHdlZW4NCiAgIHNwb2tlcyBNVVNU IGJlIGRpc2FsbG93ZWQuDQoNCg0KDQoNCkhhbm5hICYgTWFucmFsICAgICAgICAgICAgRXhwaXJl cyBKdW5lIDEwLCAyMDEzICAgICAgICAgICAgICAgICBbUGFnZSA5XQ0KDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICBBdXRvIERpc2NvdmVyeSBWUE4gICAgICAgICAgICAgIERlY2VtYmVyIDIw MTINCg0KDQogICBUaGlzIHJlcXVpcmVtZW50IGlzIGRyaXZlbiBieSB1c2UgY2FzZXMgMi4xIGFu ZCAyLjIgYW5kIGJ5IHRoZQ0KICAgbGltaXRhdGlvbnMgb2YgYSBzdGFyIHRvcG9sb2d5IHBvaW50 ZWQgb3V0IGluIHNlY3Rpb24gMy4yLg0KDQogICA1LiAgT25lIHNwb2tlIE1VU1QgTk9UIGJlIGFi bGUgdG8gaW1wZXJzb25hdGUgYW5vdGhlciBzcG9rZS4NCg0KICAgVGhpcyByZXF1aXJlbWVudCBp cyBkcml2ZW4gYnkgdXNlIGNhc2UgMi4xLiAgU3Bva2VzIGJlY29tZQ0KICAgY29tcHJvbWlzZWQg ZmFpcmx5IG9mdGVuLiAgVGhlIGNvbXByb21pc2Ugb2Ygb25lIFNwb2tlIHNob3VsZCBub3QNCiAg IGFmZmVjdCB0aGUgc2VjdXJpdHkgb2Ygb3RoZXIgZW5kcG9pbnRzLg0KDQogICA2LiAgR2F0ZXdh eXMgU0hPVUxEIGFsbG93IGZvciBzZWFtbGVzcyBoYW5kb2ZmIG9mIHNlc3Npb25zIGluIGNhc2UN CiAgIGVuZHBvaW50cyBhcmUgcm9hbWluZywgZXZlbiBpZiB0aGV5IGNyb3NzIHBvbGljeSBib3Vu ZGFyaWVzLiAgVGhpcw0KICAgd291bGQgbWVhbiB0aGUgZGF0YSB0cmFmZmljIGlzIG1pbmltYWxs eSBhZmZlY3RlZCBldmVuIGFzIHRoZSBoYW5kb2ZmDQogICBoYXBwZW5zLiAgRXh0ZXJuYWwgZmFj dG9ycyBsaWtlIGZpcmV3YWxsLCBOQVQgYm94IHdpbGwgbm90IGJlDQogICBjb25zaWRlcmVkIHBh cnQgb2YgdGhpcyBzb2x1dGlvbi4NCg0KICAgVGhpcyByZXF1aXJlbWVudCBpcyBkcml2ZW4gYnkg dXNlIGNhc2UgMi4xLiAgVG9kYXkncyBlbmRwb2ludHMgYXJlDQogICBtb2JpbGUgYW5kIHRyYW5z aXRpb24gb2Z0ZW4gYmV0d2VlbiBkaWZmZXJlbnQgbmV0d29ya3MgKGZyb20gNEcgdG8NCiAgIFdp RmkgYW5kIGFtb25nIHZhcmlvdXMgV2lGaSBuZXR3b3JrcykuDQoNCiAgIDcuICBHYXRld2F5cyBT SE9VTEQgYWxsb3cgZm9yIGVhc3kgaGFuZG9mZiBvZiBhIHNlc3Npb24gdG8gYW5vdGhlcg0KICAg Z2F0ZXdheSwgdG8gb3B0aW1pemUgbGF0ZW5jeSwgYmFuZHdpZHRoLCBsb2FkIGJhbGFuY2luZywN CiAgIGF2YWlsYWJpbGl0eSwgb3Igb3RoZXIgZmFjdG9ycywgYmFzZWQgb24gcG9saWN5Lg0KDQog ICBUaGlzIHJlcXVpcmVtZW50IGlzIGRyaXZlbiBieSB1c2UgY2FzZSAyLjMuDQoNCiAgIDguICBH YXRld2F5cyBhbmQgZW5kcG9pbnRzIE1VU1QgYmUgYWJsZSB0byB3b3JrIHdoZW4gdGhleSBhcmUg YmVoaW5kDQogICBOQVQgYm94ZXMuICBJdCBpcyBlc3BlY2lhbGx5IGRpZmZpY3VsdCB0byBoYW5k bGUgY2FzZXMgd2hlcmUgdGhlIEh1Yg0KICAgaXMgYmVoaW5kIGEgTkFUIGJveCwgc3VjaCBhIHJl cXVpcmVtZW50IE1BWSBiZSBzdXBwb3J0ZWQuICBXaGVyZSB0aGUNCiAgIHR3byBlbmRwb2ludHMg YXJlIGJvdGggYmVoaW5kIHNlcGFyYXRlIE5BVHMsIGNvbW11bmljYXRpb24gYmV0d2Vlbg0KICAg dGhlc2Ugc3Bva2VzIFNIT1VMRCBiZSBzdXBwb3J0ZWQuICBJbiB0aGUgY2FzZXMsIHdvcmthcm91 bmRzIE1BWSBiZQ0KICAgdXNlZCBzdWNoIGFzIHBvcnQgZm9yd2FyZGluZyBieSB0aGUgTkFUIG9y IGRldGVjdGluZyB3aGVuIHR3byBzcG9rZXMNCiAgIGFyZSBiZWhpbmQgdW5jb29wZXJhdGl2ZSBO QVRzIGFuZCB1c2luZyBhIGh1YiBpbiB0aGF0IGNhc2UuDQoNCiAgIFRoaXMgcmVxdWlyZW1lbnQg aXMgZHJpdmVuIGJ5IHVzZSBjYXNlcyAyLjEgYW5kIDIuMi4gIEVuZHBvaW50cyBhcmUNCiAgIG9m dGVuIGJlaGluZCBOQVRzIGFuZCBnYXRld2F5cyBzb21ldGltZXMgYXJlLiAgSVBzZWMgc2hvdWxk IGNvbnRpbnVlDQogICB0byB3b3JrIHNlYW1sZXNzbHkgcmVnYXJkbGVzcywgdXNpbmcgQUQgVlBO IHRlY2huaXF1ZXMgd2hlbmV2ZXINCiAgIHBvc3NpYmxlIGFuZCBwcm92aWRpbmcgZ3JhY2VmdWwg ZmFsbGJhY2sgdG8gaHViIGFuZCBzcG9rZSB0ZWNobmlxdWVzDQogICBhcyBuZWVkZWQuDQoNCiAg IDkuICBDaGFuZ2VzIHN1Y2ggYXMgZXN0YWJsaXNoaW5nIGEgbmV3IElQc2VjIFNBIFNIT1VMRCBi ZSByZXBvcnRhYmxlDQogICBhbmQgbWFuYWdlYWJsZS4gIEhvd2V2ZXIsIGNyZWF0aW5nIGEgTUlC IG9yIG90aGVyIG1hbmFnZW1lbnQNCiAgIHRlY2huaXF1ZSBpcyBub3Qgd2l0aGluIHNjb3BlIGZv ciB0aGlzIGVmZm9ydC4NCg0KICAgVGhpcyByZXF1aXJlbWVudCBpcyBkcml2ZW4gYnkgbWFuYWdl YWJpbGl0eSBjb25jZXJucyBmb3IgYWxsIHRoZSB1c2UNCiAgIGNhc2VzLCBlc3BlY2lhbGx5IHVz ZSBjYXNlIDIuMi4gIEFzIElQc2VjIG5ldHdvcmtzIGJlY29tZSBtb3JlDQogICBkeW5hbWljLCBt YW5hZ2VtZW50IHRvb2xzIGJlY29tZSBtb3JlIGVzc2VudGlhbC4NCg0KICAgMTAuICBUbyBzdXBw b3J0IGFsbGllZCBhbmQgZmVkZXJhdGVkIGVudmlyb25tZW50cywgZW5kcG9pbnRzIGFuZA0KDQoN Cg0KSGFubmEgJiBNYW5yYWwgICAgICAgICAgICBFeHBpcmVzIEp1bmUgMTAsIDIwMTMgICAgICAg ICAgICAgICAgW1BhZ2UgMTBdDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgIEF1dG8gRGlz Y292ZXJ5IFZQTiAgICAgICAgICAgICAgRGVjZW1iZXIgMjAxMg0KDQoNCiAgIGdhdGV3YXlzIGZy b20gZGlmZmVyZW50IG9yZ2FuaXphdGlvbnMgU0hPVUxEIGJlIGFibGUgdG8gY29ubmVjdCB0bw0K ICAgZWFjaCBvdGhlci4NCg0KICAgMTEuICBUaGUgYWRtaW5pc3RyYXRvciBvZiB0aGUgQURWUE4g U0hPVUxEIGFsbG93IGZvciB0aGUNCiAgIGNvbmZpZ3VyYXRpb24gb2YgYSBTdGFyLCBGdWxsIG1l c2ggb3IgYSBwYXJ0aWFsIGZ1bGwgbWVzaCB0b3BvbG9neSwNCiAgIGJhc2VkIG9uIHdoaWNoIHR1 bm5lbHMgYXJlIGFsbG93ZWQgdG8gYmUgc2V0dXAuDQoNCiAgIFRoaXMgcmVxdWlyZW1lbnQgaXMg ZHJpdmVuIGJ5IGRlbWFuZCBmb3IgYWxsIHRoZSB1c2UgY2FzZXMgaW4NCiAgIGZlZGVyYXRlZCBh bmQgYWxsaWVkIGVudmlyb25tZW50cy4NCg0KICAgMTIuICBUaGUgQURWUE4gc29sdXRpb24gU0hP VUxEIGJlIGFibGUgdG8gc2NhbGUgZm9yIG11bHRpY2FzdA0KICAgdHJhZmZpYy4NCg0KICAgVGhp cyByZXF1aXJlbWVudCBpcyBkcml2ZW4gYnkgdGhlIHVzZSBjYXNlIDIuMiwgd2hlcmUgdGhlIGFt b3VudCBvZg0KICAgcmljaCBtZWRpYSBtdWx0aWNhc3QgdHJhZmZpYyBpcyBpbmNyZWFzaW5nLg0K DQogICAxMy4gIFRoZSBBRFZQTiBzb2x1dGlvbiBTSE9VTEQgYWxsb3cgZm9yIGVhc3kgbW9uaXRv cmluZywgbG9nZ2luZyBhbmQNCiAgIHJlcG9ydGluZyBvZiB0aGUgZHluYW1pYyBjaGFuZ2VzLCB0 byBoZWxwIGZvciB0cm91YmxlIHNob290aW5nIHN1Y2gNCiAgIGVudmlyb25tZW50cy4NCg0KICAg VGhpcyByZXF1aXJlbWVudCBpcyBkcml2ZW4gYnkgZGVtYW5kIGZvciBhbGwgdGhlIHVzZSBjYXNl cyBpbg0KICAgZmVkZXJhdGVkIGFuZCBhbGxpZWQgZW52aXJvbm1lbnRzLg0KDQogICAxNC4gIFRo ZSBBRFZQTiBzb2x1dGlvbiBNVVNUIHN1cHBvcnQgUHJvdmlkZXIgRWRnZSAoUEUpIGJhc2VkIFZQ TidzLg0KDQogICBUaGlzIHJlcXVpcmVtZW50IGlzIGRyaXZlbiBieSBkZW1hbmQgZm9yIGFsbCB0 aGUgdXNlIGNhc2VzIGluDQogICBmZWRlcmF0ZWQgYW5kIGFsbGllZCBlbnZpcm9ubWVudHMuDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpIYW5uYSAmIE1h bnJhbCAgICAgICAgICAgIEV4cGlyZXMgSnVuZSAxMCwgMjAxMyAgICAgICAgICAgICAgICBbUGFn ZSAxMV0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgQXV0byBEaXNjb3ZlcnkgVlBOICAg ICAgICAgICAgICBEZWNlbWJlciAyMDEyDQoNCg0KNS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25z DQoNCiAgIFRoZSBzb2x1dGlvbiB0byB0aGUgcHJvYmxlbXMgcHJlc2VudGVkIGluIHRoaXMgZHJh ZnQgbWF5IGludm9sdmUNCiAgIGR5bmFtaWMgdXBkYXRlcyB0byBkYXRhYmFzZXMgZGVmaW5lZCBi eSBSRkMgNDMwMSwgc3VjaCBhcyB0aGUNCiAgIFNlY3VyaXR5IFBvbGljeSBEYXRhYmFzZSAoU1BE KSBvciB0aGUgUGVlciBBdXRob3JpemF0aW9uIERhdGFiYXNlDQogICAoUEFEKS4NCg0KICAgUkZD IDQzMDEgaXMgc2lsZW50IGFib3V0IHRoZSB3YXkgdGhlc2UgZGF0YWJhc2VzIGFyZSBwb3B1bGF0 ZWQsIGFuZA0KICAgaXQgaXMgaW1wbGllZCB0aGF0IHRoZXNlIGRhdGFiYXNlcyBhcmUgc3RhdGlj IGFuZCBwcmUtY29uZmlndXJlZCBieSBhDQogICBodW1hbi4gIEFsbG93aW5nIGR5bmFtaWMgdXBk YXRlcyB0byB0aGVzZSBkYXRhYmFzZXMgbXVzdCBiZSB0aG91Z2h0DQogICBvdXQgY2FyZWZ1bGx5 LCBiZWNhdXNlIGl0IGFsbG93cyB0aGUgcHJvdG9jb2wgdG8gYWx0ZXIgdGhlIHNlY3VyaXR5DQog ICBwb2xpY3kgdGhhdCB0aGUgSVBzZWMgZW5kcG9pbnRzIGltcGxlbWVudC4NCg0KICAgT25lIG9i dmlvdXMgYXR0YWNrIHRvIHdhdGNoIG91dCBmb3IgaXMgc3RlYWxpbmcgdHJhZmZpYyB0byBhDQog ICBwYXJ0aWN1bGFyIHNpdGUuICBUaGUgSVAgYWRkcmVzcyBmb3Igd3d3LmV4YW1wbGUuY29tIGlz IDE5Mi4wLjIuMTAuDQogICBJZiB3ZSBhZGQgYW4gZW50cnkgdG8gYW4gSVBzZWMgZW5kcG9pbnQn cyBTUEQgdGhhdCBzYXlzIHRoYXQgdHJhZmZpYw0KICAgdG8gMTkyLjAuMi4xMCBpcyBwcm90ZWN0 ZWQgdGhyb3VnaCBwZWVyIEd3LU1hbGxvcnksIHRoZW4gdGhpcyBhbGxvd3MNCiAgIEd3LU1hbGxv cnkgdG8gZWl0aGVyIHByZXRlbmQgdG8gYmUgd3d3LmV4YW1wbGUuY29tIG9yIHRvIHByb3h5IGFu ZA0KICAgcmVhZCBhbGwgdHJhZmZpYyB0byB0aGF0IHNpdGUuICBVcGRhdGVzIHRvIHRoaXMgZGF0 YWJhc2UgcmVxdWlyZXMgYQ0KICAgY2xlYXIgdHJ1c3QgbW9kZWwuDQoNCiAgIE1vcmUgdG8gYmUg YWRkZWQuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KSGFubmEgJiBNYW5yYWwgICAgICAgICAgICBFeHBpcmVzIEp1bmUgMTAsIDIwMTMg ICAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgIEF1 dG8gRGlzY292ZXJ5IFZQTiAgICAgICAgICAgICAgRGVjZW1iZXIgMjAxMg0KDQoNCjYuICBJQU5B IENvbnNpZGVyYXRpb25zDQoNCiAgIE5vIGFjdGlvbnMgYXJlIHJlcXVpcmVkIGZyb20gSUFOQSBm b3IgdGhpcyBpbmZvcm1hdGlvbmFsIGRvY3VtZW50Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KSGFubmEgJiBNYW5yYWwgICAgICAgICAgICBFeHBpcmVzIEp1bmUgMTAs IDIwMTMgICAgICAgICAgICAgICAgW1BhZ2UgMTNdDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgIEF1dG8gRGlzY292ZXJ5IFZQTiAgICAgICAgICAgICAgRGVjZW1iZXIgMjAxMg0KDQoNCjcu ICBBY2tub3dsZWRnZW1lbnRzDQoNCiAgIE1hbnkgcGVvcGxlIGhhdmUgY29udHJpYnV0ZWQgdG8g dGhlIGRldmVsb3BtZW50IG9mIHRoaXMgcHJvYmxlbQ0KICAgc3RhdGVtZW50IGFuZCBtYW55IG1v cmUgd2lsbCBwcm9iYWJseSBkbyBzbyBiZWZvcmUgd2UgYXJlIGRvbmUgd2l0aA0KICAgaXQuICBX aGlsZSB3ZSBjYW5ub3QgdGhhbmsgYWxsIGNvbnRyaWJ1dG9ycywgc29tZSBoYXZlIHBsYXllZCBh bg0KICAgZXNwZWNpYWxseSBwcm9taW5lbnQgcm9sZS4gIFlvYXYgTmlyLCBZYXJvbiBTY2hlZmZl ciwgSm9yZ2UgQ29yb25lbA0KICAgTWVuZG96YSwgQ2hyaXMgVWxsaW90dCwgYW5kIEpvaG4gVmVp emFkZXMgd3JvdGUgdGhlIGRvY3VtZW50IHVwb24NCiAgIHdoaWNoIHRoaXMgZHJhZnQgd2FzIGJh c2VkLiAgR2VvZmZyZXkgSHVhbmcsIFN1cmVzaCBNZWxhbSwgUHJhdmVlbg0KICAgU2F0aHlhbmFy YXlhbiwgQW5kcmVhcyBTdGVmZmVuLCBCcmlhbiBXZWlzLCBhbmQgTG91IEJlcmdlciBwcm92aWRl ZA0KICAgZXNzZW50aWFsIGlucHV0Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkhhbm5hICYg TWFucmFsICAgICAgICAgICAgRXhwaXJlcyBKdW5lIDEwLCAyMDEzICAgICAgICAgICAgICAgIFtQ YWdlIDE0XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBBdXRvIERpc2NvdmVyeSBWUE4g ICAgICAgICAgICAgIERlY2VtYmVyIDIwMTINCg0KDQo4LiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMN Cg0KICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3Mg dG8gSW5kaWNhdGUNCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBS RkMgMjExOSwgTWFyY2ggMTk5Ny4NCg0KICAgW1JGQzQzMDFdICBLZW50LCBTLiBhbmQgSy4gU2Vv LCAiU2VjdXJpdHkgQXJjaGl0ZWN0dXJlIGZvciB0aGUNCiAgICAgICAgICAgICAgSW50ZXJuZXQg UHJvdG9jb2wiLCBSRkMgNDMwMSwgRGVjZW1iZXIgMjAwNS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQpIYW5uYSAmIE1hbnJhbCAgICAgICAgICAgIEV4cGlyZXMgSnVuZSAxMCwgMjAx MyAgICAgICAgICAgICAgICBbUGFnZSAxNV0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg QXV0byBEaXNjb3ZlcnkgVlBOICAgICAgICAgICAgICBEZWNlbWJlciAyMDEyDQoNCg0KQXV0aG9y cycgQWRkcmVzc2VzDQoNCiAgIFN0ZXZlIEhhbm5hDQogICBKdW5pcGVyIE5ldHdvcmtzLCBJbmMu DQogICAxMTk0IE4uIE1hdGhpbGRhIEF2ZS4NCiAgIFN1bm55dmFsZSwgQ0EgIDk0MDg5DQogICBV U0ENCg0KICAgRW1haWw6IHNoYW5uYUBqdW5pcGVyLm5ldA0KDQoNCiAgIFZpc2h3YXMgTWFucmFs DQogICBIZXdsZXR0LVBhY2thcmQgQ28uDQogICAxOTExMSBQcnVuZXJpZGdlIEF2ZS4NCiAgIEN1 cGVydGlubywgQ0EgIDk1MTEzDQogICBVU0ENCg0KICAgRW1haWw6IHZpc2h3YXMubWFucmFsQGhw LmNvbQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KSGFubmEgJiBNYW5yYWwgICAgICAgICAgICBFeHBpcmVzIEp1bmUgMTAs IDIwMTMgICAgICAgICAgICAgICAgW1BhZ2UgMTZdDQo= --20cf3074ba88c8016504d037c8b1-- From vishwas.ietf@gmail.com Thu Dec 6 15:52:28 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B09921F85EA for ; Thu, 6 Dec 2012 15:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.418 X-Spam-Level: X-Spam-Status: No, score=-3.418 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCg9tLeA+-cy for ; Thu, 6 Dec 2012 15:52:27 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7D78D21E8040 for ; Thu, 6 Dec 2012 15:52:27 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id i20so20203qad.10 for ; Thu, 06 Dec 2012 15:52:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=be9R0mkaSreLhrluIj2ywxNSrtSraZfSEN7oq/fcanY=; b=Xefbm3ztzrnI3CaLR1NTA0+bnli5KsqpOHfwv8yUDFQdHVHyeODecvzqkJmPFCXV98 CMlxLrHeA6BzxCSmGFvEpkbSB9IVMb7oQk1YyMU3cGazDuFl33yo0p8Gm+LgYGb6Ff5D 6TtDHlYPX1/JjjewmaPVll+jfuu/0cQZzqOVlxeWdzleCmNDplCldWDvkWBAHnPR/dN7 /Uci9pRgQHP/IOn6LqKyAVWDbP34uI7AJDeYa5oGUWzQSJf9vcolHbroPda2DvD7VxgI 0xIbUC2o1tsMMTqcI1S7hvbBwS2zu2hjyiX3TniolGByxVSMyPyp40xsx6OZQIP7yBdj b5FQ== MIME-Version: 1.0 Received: by 10.224.71.16 with SMTP id f16mr6084056qaj.45.1354837947035; Thu, 06 Dec 2012 15:52:27 -0800 (PST) Received: by 10.229.92.77 with HTTP; Thu, 6 Dec 2012 15:52:26 -0800 (PST) In-Reply-To: References: <50A5703F.4070305@labn.net> <50A58CDB.30402@labn.net> <50A682F8.9080907@labn.net> <50A689A9.1090803@labn.net> <50A68D30.2040203@labn.net> <50BE30D9.4030903@labn.net> <50BE4A60.1000303@labn.net> <50BFA4C0.1060909@labn.net> <50BFCA9A.4030502@labn.net> <50C0EEE9.7000904@labn.net> Date: Thu, 6 Dec 2012 15:52:26 -0800 Message-ID: From: Vishwas Manral To: Lou Berger Content-Type: multipart/alternative; boundary=bcaec51b1b978fb1af04d037ca0d Cc: IPsecme WG Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 23:52:28 -0000 --bcaec51b1b978fb1af04d037ca0d Content-Type: text/plain; charset=ISO-8859-1 Sorry. Here it is with the right file. -Vishwas On Thu, Dec 6, 2012 at 3:51 PM, Vishwas Manral wrote: > Hi Lou, > > Here is the latest draft, with all your comments incorporated. > > I will post the draft soon. > > Thanks, > Vishwas > > > > On Thu, Dec 6, 2012 at 11:15 AM, Lou Berger wrote: > >> >> Vishwas, >> >> I think I see where you're headed. >> >> The text under discussion is: >> >> Routing using the tunnels SHOULD work >> seamlessly without any updates to the higher level application >> configuration i.e. OSPF configuration, when the tunnel parameter >> changes. >> >> I read this a requirement being placed on the higher level protocol, but >> I believe your intent was on the solution. How about rephrasing along >> the lines of a requirement on the ADVPN solution? Perhaps something like: >> >> The ADVPN solution SHOULD NOT increase the amount of information >> required to configure protocols running over IPsec tunnels. >> >> Lou >> >> On 12/6/2012 1:55 PM, Vishwas Manral wrote: >> > Hi Lou, >> > >> > I have included the other comments. The last one remaining is: >> > >> > > VM> I think this is an important requirement. A tunnel should be >> > able to >> > > provide an interface by which when tunnel IP parameters change we >> > do not >> > > have to change any configuration for higher application like >> > Routing. I >> > > had earlier mentioned in more generic terms earlier but changed >> to the >> > > terms provided based on feedback from the list. >> > >> > What higher level protocols like most routing protocols that use the >> > tunnel interface IP addresses in operation? >> > >> > > >> > > The entire idea is the with scale configuration needs to be >> > reduced and >> > > that needs to happen across layers, so every layer needs to >> > provide the >> > > service. Let me know what it is I am unable to convey. >> > >> > sure, but I think you're placing new requirements on the routing & >> > tunneling protocols. >> > >> > VM> There are no restrictions on an application protocol like Routing. >> > The idea is that the lower needs to provide a functionality, so that if >> > required a higher layer can use it. There is no restriction at all on >> > the higher layer. Do let me know if that is clearer? >> > >> > Thanks, >> > Vishwas >> > >> > >> > _______________________________________________ >> > IPsec mailing list >> > IPsec@ietf.org >> > https://www.ietf.org/mailman/listinfo/ipsec >> > >> > > --bcaec51b1b978fb1af04d037ca0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry. Here it is with the right file.

-Vishwas

On Thu, Dec 6, 2012 at 3:51 PM, Vishwas Manral <vishwas= .ietf@gmail.com> wrote:
Hi Lou,

Here is the latest draft, wit= h all your comments incorporated.

I will post the draft soon.
Thanks,
Vishwas



On Thu, Dec 6, 2012 at 11:15 AM, Lou Berger <lberger@= labn.net> wrote:

Vishwas,

I think I see where you're headed.

The text under discussion is:

=A0 =A0Routing using the tunnels SHOULD work
=A0 =A0seamlessly without any updates to the higher level application
=A0 =A0configuration i.e. =A0OSPF configuration, when the tunnel parameter<= br> =A0 =A0changes.

I read this a requirement being placed on the higher level protocol, = but
I believe your intent was on the solution. =A0How about rephrasing along the lines of a requirement on the ADVPN solution? Perhaps something like:
=A0 =A0The ADVPN solution SHOULD NOT increase the amount of information
=A0 =A0required to configure protocols running over IPsec tunnels.

Lou

On 12/6/2012 1:55 PM, Vishwas Manral wrote:
> Hi Lou,
>
> I have included the other comments. The last one remaining is:
>
> =A0 =A0 > VM> I think this is an important requirement. A tunnel= should be
> =A0 =A0 able to
> =A0 =A0 > provide an interface by which when tunnel IP parameters c= hange we
> =A0 =A0 do not
> =A0 =A0 > have to change any configuration for higher application l= ike
> =A0 =A0 Routing. I
> =A0 =A0 > had earlier mentioned in more generic terms earlier but c= hanged to the
> =A0 =A0 > terms provided based on feedback from the list.
>
> =A0 =A0 What higher level protocols like most routing protocols that u= se the
> =A0 =A0 tunnel interface IP addresses in operation?
>
> =A0 =A0 >
> =A0 =A0 > The entire idea is the with scale configuration needs to = be
> =A0 =A0 reduced and
> =A0 =A0 > that needs to happen across layers, so every layer needs = to
> =A0 =A0 provide the
> =A0 =A0 > service. Let me know what it is I am unable to convey. >
> =A0 =A0 sure, but I think you're placing new requirements on the r= outing &
> =A0 =A0 tunneling protocols.
>
> VM> There are no restrictions on an application protocol like Routi= ng.
> The idea is that the lower needs to provide a functionality, so that i= f
> required a higher layer can use it. There is no restriction at all on<= br> > the higher layer. Do let me know if that is clearer?
>
> Thanks,
> Vishwas
>
>
> _______________________________________________<= br> > IPsec mailing list
> IPsec@ietf.org=
> https://www.ietf.org/mailman/listinfo/ipsec
>


--bcaec51b1b978fb1af04d037ca0d-- From vishwas.ietf@gmail.com Thu Dec 6 15:53:09 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951EE21E803A for ; Thu, 6 Dec 2012 15:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4xeZBm6ej2f for ; Thu, 6 Dec 2012 15:53:07 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2755021E8039 for ; Thu, 6 Dec 2012 15:53:07 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id i20so20466qad.10 for ; Thu, 06 Dec 2012 15:53:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pRhLu15yy/Qu77WN3+o7+yqbT7raRM1fZY7PJaHZ6Zg=; b=QSAHzmN9VK3Df9U4z1qEGwXf+TEM8oMGttKVFCBFXCPJmlimqY1KnwF7OQPLeLtQ3L ePwevJNXnnYZp4KJZsShoVYcW+6zi2sSulInUFxBP+VqCGuwU4LjvcscO+yVO4I9qNk6 5VCrH7GoRqNHSFj3PYpBDrKme7KYLdGM7kIbFVH++ZmRW8qkaOUMwkX+lfQG1FFo+D9w WQvE/JZT4bscMX1Z5f93S5Jui8DOIrSQFJXA3TTCXNbo4rhhjcpl5NWMekuBUQVwe+Pj fG4BsqSFDLCmKyaTAXql94l+INbbhWljjrxuMM77PtfmfB8x6ee+442aZc2IYaY7v6aO zPEg== MIME-Version: 1.0 Received: by 10.224.40.14 with SMTP id i14mr6016611qae.37.1354837986589; Thu, 06 Dec 2012 15:53:06 -0800 (PST) Received: by 10.229.92.77 with HTTP; Thu, 6 Dec 2012 15:53:06 -0800 (PST) In-Reply-To: References: <50A5703F.4070305@labn.net> <50A58CDB.30402@labn.net> <50A682F8.9080907@labn.net> <50A689A9.1090803@labn.net> <50A68D30.2040203@labn.net> <50BE30D9.4030903@labn.net> <50BE4A60.1000303@labn.net> <50BFA4C0.1060909@labn.net> <50BFCA9A.4030502@labn.net> <50C0EEE9.7000904@labn.net> Date: Thu, 6 Dec 2012 15:53:06 -0800 Message-ID: From: Vishwas Manral To: Lou Berger Content-Type: multipart/mixed; boundary=20cf3074b3b2eb3c0204d037cc04 Cc: IPsecme WG Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 23:53:09 -0000 --20cf3074b3b2eb3c0204d037cc04 Content-Type: multipart/alternative; boundary=20cf3074b3b2eb3bfb04d037cc02 --20cf3074b3b2eb3bfb04d037cc02 Content-Type: text/plain; charset=ISO-8859-1 Here finally!!! Sorry about the duplicate mails. -Vishwas On Thu, Dec 6, 2012 at 3:52 PM, Vishwas Manral wrote: > Sorry. Here it is with the right file. > > -Vishwas > > > On Thu, Dec 6, 2012 at 3:51 PM, Vishwas Manral wrote: > >> Hi Lou, >> >> Here is the latest draft, with all your comments incorporated. >> >> I will post the draft soon. >> >> Thanks, >> Vishwas >> >> >> >> On Thu, Dec 6, 2012 at 11:15 AM, Lou Berger wrote: >> >>> >>> Vishwas, >>> >>> I think I see where you're headed. >>> >>> The text under discussion is: >>> >>> Routing using the tunnels SHOULD work >>> seamlessly without any updates to the higher level application >>> configuration i.e. OSPF configuration, when the tunnel parameter >>> changes. >>> >>> I read this a requirement being placed on the higher level protocol, but >>> I believe your intent was on the solution. How about rephrasing along >>> the lines of a requirement on the ADVPN solution? Perhaps something like: >>> >>> The ADVPN solution SHOULD NOT increase the amount of information >>> required to configure protocols running over IPsec tunnels. >>> >>> Lou >>> >>> On 12/6/2012 1:55 PM, Vishwas Manral wrote: >>> > Hi Lou, >>> > >>> > I have included the other comments. The last one remaining is: >>> > >>> > > VM> I think this is an important requirement. A tunnel should be >>> > able to >>> > > provide an interface by which when tunnel IP parameters change we >>> > do not >>> > > have to change any configuration for higher application like >>> > Routing. I >>> > > had earlier mentioned in more generic terms earlier but changed >>> to the >>> > > terms provided based on feedback from the list. >>> > >>> > What higher level protocols like most routing protocols that use >>> the >>> > tunnel interface IP addresses in operation? >>> > >>> > > >>> > > The entire idea is the with scale configuration needs to be >>> > reduced and >>> > > that needs to happen across layers, so every layer needs to >>> > provide the >>> > > service. Let me know what it is I am unable to convey. >>> > >>> > sure, but I think you're placing new requirements on the routing & >>> > tunneling protocols. >>> > >>> > VM> There are no restrictions on an application protocol like Routing. >>> > The idea is that the lower needs to provide a functionality, so that if >>> > required a higher layer can use it. There is no restriction at all on >>> > the higher layer. Do let me know if that is clearer? >>> > >>> > Thanks, >>> > Vishwas >>> > >>> > >>> > _______________________________________________ >>> > IPsec mailing list >>> > IPsec@ietf.org >>> > https://www.ietf.org/mailman/listinfo/ipsec >>> > >>> >> >> > --20cf3074b3b2eb3bfb04d037cc02 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here finally!!! Sorry about the duplicate mails.

-Vishwas

On Thu, Dec 6, 2012 at 3:52 PM, Vishwas Manral <vishwas.ietf@gmail.com> wrote:
Sorry. Here it is with the right file.

-Vishwas


On Thu, Dec 6, 2012 at= 3:51 PM, Vishwas Manral <vishwas.ietf@gmail.com> wrote= :
Hi Lou,

Here is the latest draft, wit= h all your comments incorporated.

I will post the draft soon.
Thanks,
Vishwas



On Thu, = Dec 6, 2012 at 11:15 AM, Lou Berger <lberger@labn.net> wrote:=

Vishwas,

I think I see where you're headed.

The text under discussion is:

=A0 =A0Routing using the tunnels SHOULD work
=A0 =A0seamlessly without any updates to the higher level application
=A0 =A0configuration i.e. =A0OSPF configuration, when the tunnel parameter<= br> =A0 =A0changes.

I read this a requirement being placed on the higher level protocol, = but
I believe your intent was on the solution. =A0How about rephrasing along the lines of a requirement on the ADVPN solution? Perhaps something like:
=A0 =A0The ADVPN solution SHOULD NOT increase the amount of information
=A0 =A0required to configure protocols running over IPsec tunnels.

Lou

On 12/6/2012 1:55 PM, Vishwas Manral wrote:
> Hi Lou,
>
> I have included the other comments. The last one remaining is:
>
> =A0 =A0 > VM> I think this is an important requirement. A tunnel= should be
> =A0 =A0 able to
> =A0 =A0 > provide an interface by which when tunnel IP parameters c= hange we
> =A0 =A0 do not
> =A0 =A0 > have to change any configuration for higher application l= ike
> =A0 =A0 Routing. I
> =A0 =A0 > had earlier mentioned in more generic terms earlier but c= hanged to the
> =A0 =A0 > terms provided based on feedback from the list.
>
> =A0 =A0 What higher level protocols like most routing protocols that u= se the
> =A0 =A0 tunnel interface IP addresses in operation?
>
> =A0 =A0 >
> =A0 =A0 > The entire idea is the with scale configuration needs to = be
> =A0 =A0 reduced and
> =A0 =A0 > that needs to happen across layers, so every layer needs = to
> =A0 =A0 provide the
> =A0 =A0 > service. Let me know what it is I am unable to convey. >
> =A0 =A0 sure, but I think you're placing new requirements on the r= outing &
> =A0 =A0 tunneling protocols.
>
> VM> There are no restrictions on an application protocol like Routi= ng.
> The idea is that the lower needs to provide a functionality, so that i= f
> required a higher layer can use it. There is no restriction at all on<= br> > the higher layer. Do let me know if that is clearer?
>
> Thanks,
> Vishwas
>
>
> _______________________________________________<= br> > IPsec mailing list
> IPsec@ietf.org=
> https://www.ietf.org/mailman/listinfo/ipsec
>



--20cf3074b3b2eb3bfb04d037cc02-- --20cf3074b3b2eb3c0204d037cc04 Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-ipsecme-ad-vpn-problem-02.txt" Content-Disposition: attachment; filename="draft-ietf-ipsecme-ad-vpn-problem-02.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_haejjhkm0 DQpJUHNlY01FIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgUy4gSGFubmENCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgSnVuaXBlcg0KSW50ZW5kZWQgc3RhdHVzOiBJbmZv cm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVi4gTWFucmFsDQpFeHBp cmVzOiBKdW5lIDksIDIwMTMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgSFANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgRGVjZW1iZXIgNiwgMjAxMg0KDQoNCiAgICAgICAgIEF1dG8gRGlzY292ZXJ5 IFZQTiBQcm9ibGVtIFN0YXRlbWVudCBhbmQgUmVxdWlyZW1lbnRzDQogICAgICAgICAgICAgICAg ICBkcmFmdC1pZXRmLWlwc2VjbWUtYWQtdnBuLXByb2JsZW0tMDINCg0KQWJzdHJhY3QNCg0KICAg VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHByb2JsZW0gb2YgZW5hYmxpbmcgYSBsYXJnZSBu dW1iZXIgb2YNCiAgIHN5c3RlbXMgdG8gY29tbXVuaWNhdGUgZGlyZWN0bHkgdXNpbmcgSVBzZWMg dG8gcHJvdGVjdCB0aGUgdHJhZmZpYw0KICAgYmV0d2VlbiB0aGVtLiAgSXQgdGhlbiBleHBhbmRz IG9uIHRoZSByZXF1aXJlbWVudHMsIGZvciBzdWNoIGENCiAgIHNvbHV0aW9uLg0KDQogICBNYW51 YWwgY29uZmlndXJhdGlvbiBvZiBhbGwgcG9zc2libGUgdHVubmVscyBpcyB0b28gY3VtYmVyc29t ZSBpbg0KICAgbWFueSBzdWNoIGNhc2VzLiAgSW4gb3RoZXIgY2FzZXMgdGhlIElQIGFkZHJlc3Mg b2YgZW5kcG9pbnRzIGNoYW5nZQ0KICAgb3IgdGhlIGVuZHBvaW50cyBtYXkgYmUgYmVoaW5kIE5B VCBnYXRld2F5cywgbWFraW5nIHN0YXRpYw0KICAgY29uZmlndXJhdGlvbiBpbXBvc3NpYmxlLiAg VGhlIEF1dG8gRGlzY292ZXJ5IFZQTiBzb2x1dGlvbiBpcw0KICAgY2hhcnRlcmVkIHRvIGFkZHJl c3MgdGhlc2UgcmVxdWlyZW1lbnRzLg0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIFRoaXMg SW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUN CiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAgIEludGVybmV0LURyYWZ0 cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBU YXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJp YnV0ZQ0KICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qg b2YgY3VycmVudCBJbnRlcm5ldC0NCiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0 IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMNCiAgIGFuZCBtYXkg YmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQg YW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRz IGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMg IndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJl IG9uIEp1bmUgOSwgMjAxMy4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5cmlnaHQgKGMp IDIwMTIgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUNCiAgIGRv Y3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLg0KDQogICBUaGlzIGRvY3VtZW50 IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsDQogICBQcm92 aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzDQogICAoaHR0cDovL3RydXN0ZWUuaWV0 Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YNCg0KDQoNCkhhbm5h ICYgTWFucmFsICAgICAgICAgICAgRXhwaXJlcyBKdW5lIDksIDIwMTMgICAgICAgICAgICAgICAg ICBbUGFnZSAxXQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBBdXRvIERpc2NvdmVyeSBW UE4gICAgICAgICAgICAgIERlY2VtYmVyIDIwMTINCg0KDQogICBwdWJsaWNhdGlvbiBvZiB0aGlz IGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMNCiAgIGNhcmVmdWxseSwg YXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVj dA0KICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0 aGlzIGRvY3VtZW50IG11c3QNCiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0 IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZg0KICAgdGhlIFRydXN0IExlZ2FsIFByb3Zp c2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzDQogICBkZXNjcmliZWQg aW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuDQoNCg0KVGFibGUgb2YgQ29udGVudHMNCg0K ICAgMS4gIEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAzDQogICAgIDEuMS4gIFRlcm1pbm9sb2d5ICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNCiAgICAgMS4yLiAgQ29udmVudGlvbnMg VXNlZCBpbiBUaGlzIERvY3VtZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0KICAgMi4g IFVzZSBDYXNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICA1DQogICAgIDIuMS4gIEVuZHBvaW50LXRvLUVuZHBvaW50IEFEIFZQTiBVc2UgQ2Fz ZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUNCiAgICAgMi4yLiAgR2F0ZXdheS10by1HYXRld2F5 IEFEIFZQTiBVc2UgQ2FzZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0KICAgICAyLjMuICBF bmRwb2ludC10by1HYXRld2F5IEFEIFZQTiBVc2UgQ2FzZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA2DQogICAzLiAgSW5hZGVxdWFjeSBvZiBFeGlzdGluZyBTb2x1dGlvbnMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDcNCiAgICAgMy4xLiAgRXhoYXVzdGl2ZSBDb25maWd1cmF0aW9u IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0KICAgICAzLjIuICBTdGFyIFRv cG9sb2d5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DQog ICAgIDMuMy4gIFByb3ByaWV0YXJ5IEFwcHJvYWNoZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDgNCiAgIDQuICBSZXF1aXJlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0KICAgICA0LjEuICBHYXRld2F5IGFuZCBF bmRwb2ludCBSZXF1aXJlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DQogICA1LiAg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTINCiAgIDYuICBJQU5BIENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMw0KICAgNy4gIEFja25vd2xlZGdlbWVudHMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE0DQogICA4LiAgTm9ybWF0 aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTUNCiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAxNg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCkhhbm5hICYgTWFucmFsICAgICAgICAgICAgRXhwaXJlcyBKdW5lIDksIDIwMTMg ICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBB dXRvIERpc2NvdmVyeSBWUE4gICAgICAgICAgICAgIERlY2VtYmVyIDIwMTINCg0KDQoxLiAgSW50 cm9kdWN0aW9uDQoNCiAgIElQc2VjIFtSRkM0MzAxXSBpcyB1c2VkIGluIHNldmVyYWwgZGlmZmVy ZW50IGNhc2VzLCBpbmNsdWRpbmcgdHVubmVsLQ0KICAgbW9kZSBzaXRlLXRvLXNpdGUgVlBOcyBh bmQgUmVtb3RlIEFjY2VzcyBWUE5zLiAgSG9zdCB0byBob3N0DQogICBjb21tdW5pY2F0aW9uIGVt cGxveWluZyB0cmFuc3BvcnQgbW9kZSBhbHNvIGV4aXN0cywgYnV0IGlzIGZhciBsZXNzDQogICBj b21tb25seSBkZXBsb3llZC4NCg0KICAgVGhlIHN1YmplY3Qgb2YgdGhpcyBkb2N1bWVudCBpcyB0 aGUgcHJvYmxlbSBwcmVzZW50ZWQgYnkgbGFyZ2Ugc2NhbGUNCiAgIGRlcGxveW1lbnRzIG9mIElQ c2VjIGFuZCB0aGUgcmVxdWlyZW1lbnRzIG9uIGEgc29sdXRpb24gdG8gYWRkcmVzcw0KICAgdGhl IHByb2JsZW0uICBUaGVzZSBtYXkgYmUgYSBsYXJnZSBjb2xsZWN0aW9uIG9mIFZQTiBnYXRld2F5 cw0KICAgY29ubmVjdGluZyB2YXJpb3VzIHNpdGVzLCBhIGxhcmdlIG51bWJlciBvZiByZW1vdGUg ZW5kcG9pbnRzDQogICBjb25uZWN0aW5nIHRvIGEgbnVtYmVyIG9mIGdhdGV3YXlzIG9yIHRvIGVh Y2ggb3RoZXIsIG9yIGEgbWl4IG9mIHRoZQ0KICAgdHdvLiAgVGhlIGdhdGV3YXlzIGFuZCBlbmRw b2ludHMgbWF5IGJlbG9uZyB0byBhIHNpbmdsZQ0KICAgYWRtaW5pc3RyYXRpdmUgZG9tYWluIG9y IHNldmVyYWwgZG9tYWlucyB3aXRoIGEgdHJ1c3QgcmVsYXRpb25zaGlwLg0KDQogICBTZWN0aW9u IDQuNCBvZiBSRkMgNDMwMSBkZXNjcmliZXMgdGhlIG1ham9yIElQc2VjIGRhdGFiYXNlcyBuZWVk ZWQNCiAgIGZvciBJUHNlYyBwcm9jZXNzaW5nLiAgSXQgcmVxdWlyZXMgYW4gZXh0ZW5zaXZlIGNv bmZpZ3VyYXRpb24gZm9yDQogICBlYWNoIHR1bm5lbCwgc28gbWFudWFsbHkgY29uZmlndXJpbmcg YSBzeXN0ZW0gb2YgbWFueSBnYXRld2F5cyBhbmQNCiAgIGVuZHBvaW50cyBiZWNvbWVzIGluZmVh c2libGUgYW5kIGluZmxleGlibGUuDQoNCiAgIFRoZSBkaWZmaWN1bHR5IGlzIHRoYXQgYWxsIHRo ZSBjb25maWd1cmF0aW9uIG1lbnRpb25lZCBpbiBSRkMgNDMwMSBpcw0KICAgbm90IHN1cGVyZmx1 b3VzLiAgSUtFIGltcGxlbWVudGF0aW9ucyBuZWVkIHRvIGtub3cgdGhlIGlkZW50aXR5IGFuZA0K ICAgY3JlZGVudGlhbHMgb2YgYWxsIHBvc3NpYmxlIHBlZXIgc3lzdGVtcywgYXMgd2VsbCBhcyB0 aGUgYWRkcmVzc2VzIG9mDQogICBob3N0cyBhbmQvb3IgbmV0d29ya3MgYmVoaW5kIHRoZW0uICBB IHNpbXBsaWZpZWQgbWVjaGFuaXNtIGZvcg0KICAgZHluYW1pY2FsbHkgZXN0YWJsaXNoaW5nIHBv aW50LXRvLXBvaW50IHR1bm5lbHMgaXMgbmVlZGVkLiAgU2VjdGlvbiAyDQogICBjb250YWlucyBz ZXZlcmFsIHVzZSBjYXNlcyB0aGF0IG1vdGl2YXRlIHRoaXMgZWZmb3J0Lg0KDQoxLjEuICBUZXJt aW5vbG9neQ0KDQogICBFbmRwb2ludCAtIEEgZGV2aWNlIHRoYXQgaW1wbGVtZW50cyBJUHNlYyBm b3IgaXRzIG93biB0cmFmZmljIGJ1dA0KICAgZG9lcyBub3QgYWN0IGFzIGEgZ2F0ZXdheS4NCg0K ICAgR2F0ZXdheSAtIEEgbmV0d29yayBkZXZpY2UgdGhhdCBpbXBsZW1lbnRzIElQc2VjIHRvIHBy b3RlY3QgdHJhZmZpYw0KICAgZmxvd2luZyB0aHJvdWdoIHRoZSBkZXZpY2UuDQoNCiAgIFBvaW50 LXRvLVBvaW50IC0gRGlyZWN0IGNvbW11bmljYXRpb24gYmV0d2VlbiB0d28gcGFydGllcyB3aXRo b3V0DQogICBhY3RpdmUgcGFydGljaXBhdGlvbiAoZS5nLiBlbmNyeXB0aW9uIG9yIGRlY3J5cHRp b24pIGJ5IGFueSBvdGhlcg0KICAgcGFydGllcy4NCg0KICAgSHViIC0gVGhlIGNlbnRyYWwgcG9p bnQgaW4gYSBzdGFyIHRvcG9sb2d5LyBkeW5hbWljIGZ1bGwgbWVzaA0KICAgdG9wb2xvZ3ksIG9y IG9uZSBvZiB0aGUgY2VudHJhbCBwb2ludHMgaW4gdGhlIGZ1bGwgbWVzaCBzdHlsZSBWUE4sDQog ICBpLmUuIGdhdGV3YXkgd2hlcmUgbXVsdGlwbGUgb3RoZXIgaHVicyBvciBzcG9rZXMgY29ubmVj dCB0by4gIFRoZQ0KICAgaHVicyB1c3VhbGx5IGZvcndhcmQgdHJhZmZpYyBjb21pbmcgZnJvbSBl bmNyeXB0ZWQgbGlua3MgdG8gb3RoZXINCiAgIGVuY3J5cHRlZCBsaW5rcywgaS5lLiB0aGVyZSBp cyBubyBkZXZpY2VzIGNvbm5lY3RlZCB0byBpdCBpbiBjbGVhci4NCg0KICAgU3Bva2UgLSBUaGUg ZWRnZSBkZXZpY2VzIGluIHRoZSBhIHN0YXIgdG9wb2xvZ3kvIGR5bmFtaWMgZnVsbCBtZXNoDQog ICB0b3BvbG9neSwgb3IgZ2F0ZXdheSB3aGljaCBmb3J3YXJkcyB0cmFmZmljIGZyb20gbXVsdGlw bGUgY2xlYXJ0ZXh0DQogICBkZXZpY2VzIHRvIG90aGVyIGh1YnMgb3Igc3Bva2VzLCBhbmQgc29t ZSBvZiB0aG9zZSBvdGhlciBkZXZpY2VzIGFyZQ0KDQoNCg0KSGFubmEgJiBNYW5yYWwgICAgICAg ICAgICBFeHBpcmVzIEp1bmUgOSwgMjAxMyAgICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgIEF1dG8gRGlzY292ZXJ5IFZQTiAgICAgICAgICAgICAg RGVjZW1iZXIgMjAxMg0KDQoNCiAgIGNvbm5lY3RlZCB0byBpdCBpbiBjbGVhciAoaS5lLiBpdCBl bmNyeXB0IGRhdGEgY29taW5nIGZyb20gY2xlYXJ0ZXh0DQogICBkZXZpY2UgYW5kIGZvcndhcmRz IGl0IHRvIHRoZSBBRCBWUE4pLg0KDQogICBTdGFyIHRvcG9sb2d5IC0gVGhpcyBpcyB0aGUgdG9w b2xvZ3kgd2hlcmUgdGhlcmUgaXMgZGlyZWN0DQogICBjb25uZWN0aXZpdHkgb25seSBiZXR3ZWVu IHRoZSBodWIgYW5kIHNwb2tlIGFuZCBjb21tdW5pY2F0aW9uIGJldHdlZW4NCiAgIHRoZSAyIHNw b2tlcyBoYXBwZW5zIHRocm91Z2ggdGhlIGh1Yi4NCg0KICAgRnVsbCBNZXNoIHRvcG9sb2d5IC0g VGhpcyBpcyB0aGUgdG9wb2xvZ3kgd2hlcmUgdGhlcmUgaXMgYSBkaXJlY3QNCiAgIGNvbm5lY3Rp dml0eSBiZXR3ZWVuIGV2ZXJ5IFNwb2tlIHRvIGV2ZXJ5IG90aGVyIFNwb2tlIGRpcmVjdGx5LA0K ICAgd2l0aG91dCB0aGUgdHJhZmZpYyBiZXR3ZWVuIHRoZSBzcG9rZXMgaGF2aW5nIHRvIGJlIHJl ZGlyZWN0ZWQNCiAgIHRocm91Z2ggYW4gaW50ZXJtZWRpYXRlIGh1YiBkZXZpY2UuDQoNCiAgIER5 bmFtaWMgRnVsbCBNZXNoIHRvcG9sb2d5IC0gVGhpcyBpcyB0aGUgdG9wb2xvZ3kgd2hlcmUgZGly ZWN0DQogICBjb25uZWN0aW9ucyBleGlzdCBpbiBhIGh1YiBhbmQgc3Bva2UgbWFubmVyLCBidXQg ZHluYW1pYyBjb25uZWN0aW9ucw0KICAgYXJlIGNyZWF0ZWQvIHJlbW92ZWQgYmV0d2VlbiB0aGUg c3Bva2VzIG9uIGEgbmVlZCBiYXNpcy4NCg0KICAgU2VjdXJpdHkgQXNzb2NpYXRpb24gKFNBKSAt IERlZmluZWQgaW4gW1JGQzQzMDFdLg0KDQoxLjIuICBDb252ZW50aW9ucyBVc2VkIGluIFRoaXMg RG9jdW1lbnQNCg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJF RCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJF Q09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCiAgIGRvY3VtZW50IGFy ZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpIYW5uYSAmIE1h bnJhbCAgICAgICAgICAgIEV4cGlyZXMgSnVuZSA5LCAyMDEzICAgICAgICAgICAgICAgICAgW1Bh Z2UgNF0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgQXV0byBEaXNjb3ZlcnkgVlBOICAg ICAgICAgICAgICBEZWNlbWJlciAyMDEyDQoNCg0KMi4gIFVzZSBDYXNlcw0KDQogICBUaGlzIHNl Y3Rpb24gcHJlc2VudHMgdGhlIGtleSB1c2UgY2FzZXMgZm9yIGxhcmdlLXNjYWxlIHBvaW50LXRv LQ0KICAgcG9pbnQgVlBOLg0KDQogICBJbiBhbGwgb2YgdGhlc2UgdXNlIGNhc2VzLCB0aGUgcGFy dGljaXBhbnRzIChlbmRwb2ludHMgYW5kIGdhdGV3YXlzKQ0KICAgbWF5IGJlIGZyb20gYSBzaW5n bGUgb3JnYW5pemF0aW9uIG9yIGZyb20gbXVsdGlwbGUgb3JnYW5pemF0aW9ucyB3aXRoDQogICBh biBlc3RhYmxpc2hlZCB0cnVzdCByZWxhdGlvbnNoaXAuICBXaGVuIG11bHRpcGxlIG9yZ2FuaXph dGlvbnMgYXJlDQogICBpbnZvbHZlZCwgcHJvZHVjdHMgZnJvbSBtdWx0aXBsZSB2ZW5kb3JzIGFy ZSBlbXBsb3llZCBzbyBvcGVuDQogICBzdGFuZGFyZHMgYXJlIG5lZWRlZCB0byBwcm92aWRlIGlu dGVyb3BlcmFiaWxpdHkuICBFc3RhYmxpc2hpbmcNCiAgIGNvbW11bmljYXRpb25zIGJldHdlZW4g cGFydGljaXBhbnRzIHdpdGggbm8gZXN0YWJsaXNoZWQgdHJ1c3QNCiAgIHJlbGF0aW9uc2hpcCBp cyBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgZWZmb3J0Lg0KDQoyLjEuICBFbmRwb2ludC10by1FbmRw b2ludCBBRCBWUE4gVXNlIENhc2UNCg0KICAgVHdvIGVuZHBvaW50cyB3aXNoIHRvIGNvbW11bmlj YXRlIHNlY3VyZWx5IHZpYSBhIGRpcmVjdCwgcG9pbnQtdG8tDQogICBwb2ludCBTZWN1cml0eSBB c3NvY2lhdGlvbiAoU0EpLg0KDQogICBUaGUgbmVlZCBmb3Igc2VjdXJlIGVuZHBvaW50IHRvIGVu ZHBvaW50IGNvbW11bmljYXRpb25zIGlzIG9mdGVuDQogICBkcml2ZW4gYnkgYSBuZWVkIHRvIGVt cGxveSBoaWdoLWJhbmR3aWR0aCwgbG93IGxhdGVuY3kgbG9jYWwNCiAgIGNvbm5lY3Rpdml0eSBp bnN0ZWFkIG9mIHVzaW5nIHNsb3csIGV4cGVuc2l2ZSBsaW5rcyB0byByZW1vdGUNCiAgIGdhdGV3 YXlzLiAgRm9yIGV4YW1wbGUsIHR3byB1c2VycyBpbiBjbG9zZSBwcm94aW1pdHkgbWF5IHdpc2gg dG8NCiAgIHBsYWNlIGEgZGlyZWN0LCBzZWN1cmUgdmlkZW8gb3Igdm9pY2UgY2FsbCB3aXRob3V0 IG5lZWRpbmcgdG8gc2VuZA0KICAgdGhlIGNhbGwgdGhyb3VnaCByZW1vdGUgZ2F0ZXdheXMsIHdo aWNoIHdvdWxkIGFkZCBsYXRlbmN5IHRvIHRoZQ0KICAgY2FsbCwgY29uc3VtZSBwcmVjaW91cyBy ZW1vdGUgYmFuZHdpZHRoLCBhbmQgaW5jcmVhc2Ugb3ZlcmFsbCBjb3N0cy4NCiAgIFN1Y2ggYSB1 c2UgY2FzZSBhbHNvIGVuYWJsZXMgY29ubmVjdGl2aXR5IHdoZW4gYm90aCBlbmRwb2ludHMgYXJl DQogICBiZWhpbmQgTkFUIGdhdGV3YXlzLiAgU3VjaCB1c2UgY2FzZSBzaG91bGQgYWxsb3cgZm9y IHNlYW1sZXNzDQogICBjb25uZWN0aXZpdHkgZXZlbiBhcyBlbmRwb2ludHMgcm9hbSwgZXZlbiBp ZiB0aGV5IGFyZSBtb3Zpbmcgb3V0IGZyb20NCiAgIGJlaGluZCBhIE5BVCBnYXRld2F5LCBmcm9t IGJlaGluZCBvbmUgTkFUIGdhdGV3YXkgdG8gYmVoaW5kIGFub3RoZXIsDQogICBvciBmcm9tIGEg c3RhbmRhbG9uZSBwb3NpdGlvbiB0byBiZWhpbmQgYSBOQVQgZ2F0ZXdheS4NCg0KICAgSW4gYSBo dWIgYW5kIHNwb2tlIHRvcG9sb2d5IHdoZW4gdHdvIGVuZHBvaW50cyBjb21tdW5pY2F0ZSwgdGhl eSBtdXN0DQogICB1c2UgYSBtZWNoYW5pc20gZm9yIGF1dGhlbnRpY2F0aW9uLCBzdWNoIHRoYXQg dGhleSBkbyBub3QgZXhwb3NlIHRoZW0NCiAgIHRvIGltcGVyc29uYXRpb24gYnkgdGhlIG90aGVy IHNwb2tlIGVuZHBvaW50Lg0KDQoyLjIuICBHYXRld2F5LXRvLUdhdGV3YXkgQUQgVlBOIFVzZSBD YXNlDQoNCiAgIEEgdHlwaWNhbCBFbnRlcnByaXNlIHRyYWZmaWMgbW9kZWwgZm9sbG93cyBhIHN0 YXIgdG9wb2xvZ3ksIHdpdGggdGhlDQogICBnYXRld2F5cyBjb25uZWN0aW5nIHRvIGVhY2ggb3Ro ZXIgdXNpbmcgSVBzZWMgdHVubmVscy4NCg0KICAgSG93ZXZlciBmb3IgdGhlIHZvaWNlIGFuZCBv dGhlciByaWNoIG1lZGlhIHRyYWZmaWMgdGhhdCByZXF1aXJlcyBhDQogICBsb3Qgb2YgYmFuZHdp ZHRoIG9yIGlzIHBlcmZvcm1hbmNlIHNlbnNpdGl2ZSwgdGhlIHRyYWZmaWMgdHJvbWJvbmluZw0K ICAgdG8gdGhlIGh1YiBjYW4gY3JlYXRlIHRyYWZmaWMgYm90dGxlbmVja3Mgb24gdGhlIGh1YiBh bmQgY2FuIGxlYWQgdG8NCiAgIGFuIGluY3JlYXNlIGluIGNvc3QuICBBIGZ1bGx5IG1lc2hlZCBz b2x1dGlvbiBpcyB3b3VsZCBtYWtlIGJlc3QgdXNlDQogICBvZiB0aGUgYXZhaWxhYmxlIG5ldHdv cmsgY2FwYWNpdHkgYW5kIHBlcmZvcm1hbmNlIGJ1dCB0aGUgZGVwbG95bWVudA0KICAgb2YgYSBm dWxseSBtZXNoZWQgc29sdXRpb24gaW52b2x2ZXMgY29uc2lkZXJhYmxlIGNvbmZpZ3VyYXRpb24s DQogICBlc3BlY2lhbGx5IHdoZW4gYSBsYXJnZSBudW1iZXIgb2Ygbm9kZXMgYXJlIGludm9sdmVk LiAgSXQgaXMgZm9yIHRoaXMNCiAgIHB1cnBvc2Ugc3Bva2UtdG8tc3Bva2UgdHVubmVscyBhcmUg ZHluYW1pY2FsbHkgY3JlYXRlZCBhbmQgdG9ybi1kb3duLg0KDQoNCg0KSGFubmEgJiBNYW5yYWwg ICAgICAgICAgICBFeHBpcmVzIEp1bmUgOSwgMjAxMyAgICAgICAgICAgICAgICAgIFtQYWdlIDVd DQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgIEF1dG8gRGlzY292ZXJ5IFZQTiAgICAgICAg ICAgICAgRGVjZW1iZXIgMjAxMg0KDQoNCiAgIEZvciB0aGUgcmVhc29ucyBvZiBjb3N0IGFuZCBt YW51YWwgZXJyb3IgcmVkdWN0aW9uLCBpdCBpcyBkZXNpcmVkDQogICB0aGF0IHRoZXJlIGJlIG1p bmltYWwgY29uZmlndXJhdGlvbiBvbiBlYWNoIGdhdGV3YXkuDQoNCiAgIFRoZSBzb2x1dGlvbiBz aG91bGQgd29yayBpbiBjYXNlcyB3aGVyZSB0aGUgZW5kcG9pbnRzIGFyZQ0KICAgYWRtaW5pc3Ry YXRlZCBieSBzZXBhcmF0ZSBtYW5hZ2VtZW50IGRvbWFpbnMsIGFsYmVpdCwgb25lcyB0aGF0IGhh dmUNCiAgIGFuIGV4aXN0aW5nIHRydXN0IHJlbGF0aW9uc2hpcCAoZm9yIGV4YW1wbGUgdHdvIG9y Z2FuaXNhdGlvbnMgd2hvIGFyZQ0KICAgY29sbGFib3JhdGluZyBvbiBhIHByb2plY3QsIHRoZXkg bWF5IHdpc2ggdG8gam9pbiB0aGVpciBuZXR3b3JrcywNCiAgIHdoaWxzdCByZXRhaW5pbmcgaW5k ZXBlbmRlbnQgY29udHJvbCBvdmVyIGNvbmZpZ3VyYXRpb24pLiAgSXQgaXMNCiAgIGhpZ2hseSBk ZXNpcmFibGUgdGhhdCB0aGUgc29sdXRpb24gd29ya3MgZm9yIHRoZSBzdGFyLCBmdWxsIG1lc2gg YXMNCiAgIHdlbGwgYXMgZHluYW1pYyBmdWxsIG1lc2ggdG9wb2xvZ3kuDQoNCiAgIFRoZSBzb2x1 dGlvbiBzaG91bGQgYWxzbyBhZGRyZXNzIHRoZSBjYXNlIHdoZXJlIGdhdGV3YXlzIHVzZSBkeW5h bWljDQogICBJUCBhZGRyZXNzZXMuDQoNCiAgIEFkZGl0aW9uYWxseSwgdGhlIHJvdXRpbmcgaW1w bGljYXRpb25zIG9mIGdhdGV3YXktdG8tZ2F0ZXdheQ0KICAgY29tbXVuaWNhdGlvbiBtdXN0IGJl IGFkZHJlc3NlZC4gIEluIHRoZSBzaW1wbGUgY2FzZSwgc2VsZWN0b3JzDQogICBwcm92aWRlIHN1 ZmZpY2llbnQgaW5mb3JtYXRpb24gZm9yIGEgZ2F0ZXdheSB0byBmb3J3YXJkIHRyYWZmaWMNCiAg IGFwcHJvcHJpYXRlbHkuICBJbiBvdGhlciBjYXNlcywgYWRkaXRpb25hbCB0dW5uZWxpbmcgKGUu Zy4sIEdSRSkgYW5kDQogICByb3V0aW5nIChlLmcuLCBPU1BGKSBwcm90b2NvbHMgYXJlIHJ1biBv dmVyIElQc2VjIHR1bm5lbHMsIGFuZCB0aGUNCiAgIGNvbmZpZ3VyYXRpb24gaW1wYWN0IG9uIHRo b3NlIHByb3RvY29scyBtdXN0IGJlIGNvbnNpZGVyZWQuICBUaGVyZSBpcw0KICAgYWxzbyB0aGUg Y2FzZSB3aGVuIEwzVlBOcyBvcGVyYXRlIG92ZXIgSVBzZWMgVHVubmVscy4NCg0KICAgV2hlbiB0 d28gZ2F0ZXdheXMgY29tbXVuaWNhdGUsIHRoZXkgbXVzdCB1c2UgYSBtZWNoYW5pc20gZm9yDQog ICBhdXRoZW50aWNhdGlvbiwgc3VjaCB0aGF0IHRoZXkgZG8gbm90IGV4cG9zZSB0aGVtc2VsdmVz IHRvIHRoZSByaXNrDQogICBvZiBpbXBlcnNvbmF0aW9uIGJ5IHRoZSBvdGhlciBlbnRpdGllcy4N Cg0KMi4zLiAgRW5kcG9pbnQtdG8tR2F0ZXdheSBBRCBWUE4gVXNlIENhc2UNCg0KICAgQW4gZW5k cG9pbnQgc2hvdWxkIGJlIGFibGUgdG8gdXNlIHRoZSBtb3N0IGVmZmljaWVudCBnYXRld2F5IGFz IGl0DQogICByb2FtcyBpbiB0aGUgaW50ZXJuZXQuDQoNCiAgIEEgbW9iaWxlIHVzZXIgcm9hbWlu ZyBvbiB0aGUgSW50ZXJuZXQgbWF5IGNvbm5lY3QgdG8gYSBnYXRld2F5LCB3aGljaA0KICAgYmVj YXVzZSBvZiByb2FtaW5nIGlzIG5vIGxvbmdlciB0aGUgbW9zdCBlZmZpY2llbnQgZ2F0ZXdheSB0 byB1c2UNCiAgIChyZWFzb25zIGNvdWxkIGJlIGNvc3QvIGVmZmljaWVuY3kvIGxhdGVuY3kgb3Ig c29tZSBvdGhlciBmYWN0b3IpLg0KICAgVGhlIG1vYmlsZSB1c2VyIHNob3VsZCBiZSBhYmxlIHRv IGRpc2NvdmVyIGFuZCB0aGVuIGNvbm5lY3QgdG8gdGhlDQogICBjdXJyZW50IG1vc3QgZWZmaWNp ZW50IGdhdGV3YXkgd2l0aG91dCBoYXZpbmcgdG8gcmVpbml0aWF0ZSB0aGUNCiAgIGNvbm5lY3Rp b24uDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KSGFubmEgJiBNYW5yYWwgICAgICAgICAg ICBFeHBpcmVzIEp1bmUgOSwgMjAxMyAgICAgICAgICAgICAgICAgIFtQYWdlIDZdDQoNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgIEF1dG8gRGlzY292ZXJ5IFZQTiAgICAgICAgICAgICAgRGVj ZW1iZXIgMjAxMg0KDQoNCjMuICBJbmFkZXF1YWN5IG9mIEV4aXN0aW5nIFNvbHV0aW9ucw0KDQog ICBTZXZlcmFsIHNvbHV0aW9ucyBleGlzdCBmb3IgdGhlIHByb2JsZW1zIGRlc2NyaWJlZCBhYm92 ZS4gIEhvd2V2ZXIsDQogICBub25lIG9mIHRoZXNlIHNvbHV0aW9ucyBpcyBhZGVxdWF0ZSwgYXMg ZGVzY3JpYmVkIGhlcmUuDQoNCjMuMS4gIEV4aGF1c3RpdmUgQ29uZmlndXJhdGlvbg0KDQogICBP bmUgc2ltcGxlIHNvbHV0aW9uIGlzIHRvIGNvbmZpZ3VyZSBhbGwgZ2F0ZXdheXMgYW5kIGVuZHBv aW50cyBpbg0KICAgYWR2YW5jZSB3aXRoIGFsbCB0aGUgaW5mb3JtYXRpb24gbmVlZGVkIHRvIGRl dGVybWluZSB3aGljaCBnYXRld2F5IG9yDQogICBlbmRwb2ludCBpcyBvcHRpbWFsIGFuZCB0byBl c3RhYmxpc2ggYW4gU0Egd2l0aCB0aGF0IGdhdGV3YXkgb3INCiAgIGVuZHBvaW50LiAgSG93ZXZl ciwgdGhpcyBzb2x1dGlvbiBkb2VzIG5vdCBzY2FsZSBpbiBhIGxhcmdlIG5ldHdvcmsNCiAgIHdp dGggaHVuZHJlZHMgb2YgdGhvdXNhbmRzIG9mIGdhdGV3YXlzIGFuZCBlbmRwb2ludHMsIGVzcGVj aWFsbHkgd2hlbg0KICAgbXVsdGlwbGUgb3JnYW5pemF0aW9ucyBhcmUgaW52b2x2ZWQgYW5kIHRo aW5ncyBhcmUgcmFwaWRseSBjaGFuZ2luZw0KICAgKGUuZy4gbW9iaWxlIGVuZHBvaW50cykuICBT dWNoIGEgc29sdXRpb24gaXMgYWxzbyBsaW1pdGVkIGJ5IHRoZQ0KICAgc21hbGxlc3QgZW5kcG9p bnQvIGdhdGV3YXksIGFzIHRoZSBzYW1lIGV4aGF1c3RpdmUgY29uZmlndXJhdGlvbiBpcw0KICAg dG8gYmUgYXBwbGllZCBvbiBhbGwgZW5kcG9pbnRzLyBnYXRld2F5cy4gIEEgbW9yZSBkeW5hbWlj LCBzZWN1cmUgYW5kDQogICBzY2FsYWJsZSBzeXN0ZW0gZm9yIGVzdGFibGlzaGluZyBTQXMgYmV0 d2VlbiBnYXRld2F5cyBpcyBuZWVkZWQuDQoNCjMuMi4gIFN0YXIgVG9wb2xvZ3kNCg0KICAgVGhl IG1vc3QgY29tbW9uIHdheSB0byBhZGRyZXNzIGEgcGFydCBvZiB0aGlzIHRoaXMgcHJvYmxlbSB0 b2RheSBpcw0KICAgdG8gdXNlIHdoYXQgaGFzIGJlZW4gdGVybWVkIGEgInN0YXIgdG9wb2xvZ3ki LiAgSW4gdGhpcyBjYXNlIG9uZSBvciBhDQogICBmZXcgZ2F0ZXdheXMgYXJlIGRlZmluZWQgYXMg Imh1YiBnYXRld2F5cyIsIHdoaWxlIHRoZSByZXN0IG9mIHRoZQ0KICAgc3lzdGVtcyAod2hldGhl ciBlbmRwb2ludHMgb3IgZ2F0ZXdheXMpIGFyZSBkZWZpbmVkIGFzICJzcG9rZXMiLiAgVGhlDQog ICBzcG9rZXMgbmV2ZXIgY29ubmVjdCB0byBvdGhlciBzcG9rZXMuICBUaGV5IG9ubHkgb3BlbiB0 dW5uZWxzIHdpdGgNCiAgIHRoZSBodWIgZ2F0ZXdheXMuICBBbHNvIGZvciBhIGxhcmdlIG51bWJl ciBvZiBnYXRld2F5cyBpbiBvbmUNCiAgIGFkbWluaXN0cmF0aXZlIGRvbWFpbiwgb25lIGdhdGV3 YXkgbWF5IGJlIGRlZmluZWQgYXMgdGhlIGh1YiwgYW5kIHRoZQ0KICAgcmVzdCBvZiB0aGUgZ2F0 ZXdheXMgYW5kIHJlbW90ZSBhY2Nlc3MgY2xpZW50cyBjb25uZWN0IG9ubHkgdG8gdGhhdA0KICAg Z2F0ZXdheS4NCg0KICAgVGhpcyBzb2x1dGlvbiBob3dldmVyIGlzIGNvbXBsaWNhdGVkIGJ5IHRo ZSBjYXNlIHdoZW4gdGhlIHNwb2tlcyB1c2UNCiAgIGR5bmFtaWMgSVAgYWRkcmVzc2VzIGFuZCBE TlMgd2l0aCBkeW5hbWljIHVwZGF0ZXMgbXVzdCBiZSB1c2VkLiAgSXQNCiAgIGlzIGFsc28gZGVz aXJlZCB0aGF0IHRoZXJlIGlzIG1pbmltYWwgdG8gbm8gY29uZmlndXJhdGlvbiBvbiB0aGUgaHVi DQogICBhcyB0aGUgbnVtYmVyIG9mIHNwb2tlcyBpbmNyZWFzZXMgYW5kIG5ldyBzcG9rZXMgYXJl IGFkZGVkIGFuZA0KICAgZGVsZXRlZCByYW5kb21seS4NCg0KICAgQW5vdGhlciBwcm9ibGVtIHdp dGggdGhlIHN0YXIgdG9wb2xvZ3kgaXMgdGhhdCBpdCBjcmVhdGVzIGEgaGlnaCBsb2FkDQogICBv biB0aGUgaHViIGdhdGV3YXlzIGFzIHdlbGwgYXMgb24gdGhlIGNvbm5lY3Rpb24gYmV0d2VlbiB0 aGUgc3Bva2VzDQogICBhbmQgdGhlIGh1Yi4gIFRoaXMgbG9hZCBpcyBib3RoIGluIHByb2Nlc3Np bmcgcG93ZXIgYW5kIGluIG5ldHdvcmsNCiAgIGJhbmR3aWR0aC4gIEEgc2luZ2xlIHBhY2tldCBp biB0aGUgaHViLWFuZC1zcG9rZSBzY2VuYXJpbyBjYW4gYmUNCiAgIGVuY3J5cHRlZCBhbmQgZGVj cnlwdGVkIG11bHRpcGxlIHRpbWVzLiAgSXQgd291bGQgYmUgbXVjaCBwcmVmZXJhYmxlDQogICBp ZiB0aGVzZSBnYXRld2F5cyBhbmQgY2xpZW50cyBjb3VsZCBpbml0aWF0ZSB0dW5uZWxzIGJldHdl ZW4gdGhlbSwNCiAgIGJ5cGFzc2luZyB0aGUgaHViIGdhdGV3YXlzLiAgQWRkaXRpb25hbGx5LCB0 aGUgcGF0aCBiYW5kd2lkdGggdG8NCiAgIHRoZXNlIGh1YiBnYXRld2F5cyBtYXkgYmUgbG93ZXIg dGhhbiB0aGF0IG9mIHRoZSBwYXRoIGJldHdlZW4gdGhlDQogICBzcG9rZXMuICBGb3IgZXhhbXBs ZSwgdHdvIHJlbW90ZSBhY2Nlc3MgdXNlcnMgbWF5IGJlIGluIHRoZSBzYW1lDQogICBidWlsZGlu ZyB3aXRoIGhpZ2gtc3BlZWQgd2lmaSAoZm9yIGV4YW1wbGUsIGF0IGFuIElFVEYgbWVldGluZyku DQogICBDaGFubmVsaW5nIHRoZWlyIGNvbnZlcnNhdGlvbiB0aHJvdWdoIHRoZSBodWIgZ2F0ZXdh eXMgb2YgdGhlaXINCiAgIHJlc3BlY3RpdmUgZW1wbG95ZXJzIHNlZW1zIGV4dHJlbWVseSB3YXN0 ZWZ1bCwgYXMgd2VsbCBhcyBoYXZpbmcNCg0KDQoNCkhhbm5hICYgTWFucmFsICAgICAgICAgICAg RXhwaXJlcyBKdW5lIDksIDIwMTMgICAgICAgICAgICAgICAgICBbUGFnZSA3XQ0KDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICBBdXRvIERpc2NvdmVyeSBWUE4gICAgICAgICAgICAgIERlY2Vt YmVyIDIwMTINCg0KDQogICBsb3dlciBiYW5kd2lkdGguDQoNCiAgIFRoZSBjaGFsbGVuZ2UgaXMg dG8gYnVpbGQgYSBsYXJnZSBzY2FsZSwgSVBzZWMgcHJvdGVjdGVkIG5ldHdvcmtzDQogICB0aGF0 IGNhbiBkeW5hbWljYWxseSBjaGFuZ2Ugd2l0aCBtaW5pbXVtIGFkbWluaXN0cmF0aXZlIG92ZXJo ZWFkLg0KDQozLjMuICBQcm9wcmlldGFyeSBBcHByb2FjaGVzDQoNCiAgIFNldmVyYWwgdmVuZG9y cyBvZmZlciBwcm9wcmlldGFyeSBzb2x1dGlvbnMgdG8gdGhlc2UgcHJvYmxlbXMuDQogICBIb3dl dmVyLCB0aGVzZSBzb2x1dGlvbnMgb2ZmZXIgbm8gaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIGVx dWlwbWVudA0KICAgZnJvbSBvbmUgdmVuZG9yIGFuZCBhbm90aGVyLiAgVGhpcyBtZWFucyB0aGF0 IHRoZXkgYXJlIGdlbmVyYWxseQ0KICAgcmVzdHJpY3RlZCB0byB1c2Ugd2l0aGluIG9uZSBvcmdh bml6YXRpb24sIGFuZCBpdCBpcyBoYXJkZXIgdG8gbW92ZQ0KICAgb2ZmIHN1Y2ggc29sdXRpb25z IGFzIHRoZSBmZWF0dXJlcyBhcmUgbm90IHN0YW5kYXJkaXplZC4gIEJlc2lkZXMNCiAgIG11bHRp cGxlIG9yZ2FuaXphdGlvbnMgY2Fubm90IGJlIGV4cGVjdGVkIHRvIGFsbCBjaG9vc2UgdGhlIHNh bWUNCiAgIGVxdWlwbWVudCB2ZW5kb3IuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkhhbm5hICYgTWFucmFs ICAgICAgICAgICAgRXhwaXJlcyBKdW5lIDksIDIwMTMgICAgICAgICAgICAgICAgICBbUGFnZSA4 XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBBdXRvIERpc2NvdmVyeSBWUE4gICAgICAg ICAgICAgIERlY2VtYmVyIDIwMTINCg0KDQo0LiAgUmVxdWlyZW1lbnRzDQoNCiAgIFRoaXMgc2Vj dGlvbmRlZmluZXMgdGhlIHJlcXVpcmVtZW50cywgb24gd2hpY2ggdGhlIHNvbHV0aW9uIHdpbGwg YmUNCiAgIGJhc2VkLg0KDQo0LjEuICBHYXRld2F5IGFuZCBFbmRwb2ludCBSZXF1aXJlbWVudHMN Cg0KICAgMS4gIEZvciBhbnkgbmV0d29yayB0b3BvbG9neSAoc3RhciwgZnVsbCBtZXNoIGFuZCBk eW5hbWljIGZ1bGwgbWVzaCkNCiAgIGdhdGV3YXlzIGFuZCBlbmRwb2ludHMgTVVTVCBtaW5pbWl6 ZSBjb25maWd1cmF0aW9uIGNoYW5nZXMgd2hlbiBhIG5ldw0KICAgZ2F0ZXdheSBvciBlbmRwb2lu dCBpcyBhZGRlZCwgcmVtb3ZlZCBvciBjaGFuZ2VkLiAgQWRkaW5nIG9yIHJlbW92aW5nDQogICBh IHNwb2tlIGluIHRoZSB0b3BvbG9neSBNVVNUIE5PVCByZXF1aXJlIGNvbmZpZ3VyYXRpb24gY2hh bmdlcyB0byB0aGUNCiAgIGh1YnMgb3RoZXIgdGhhbiB3aGVyZSB0aGUgc3Bva2Ugd2FzIGNvbm5l Y3RlZCB0byBhbmQgU0hPVUxEIE5PVA0KICAgcmVxdWlyZSBjb25maWd1cmF0aW9uIGNoYW5nZXMg dG8gdGhlIGh1YiB0aGUgc3Bva2Ugd2FzIGNvbm5lY3RlZCB0by4NCiAgIFRoZSBjaGFuZ2VzIGFs c28gTVVTVCBOT1QgcmVxdWlyZSBjb25maWd1cmF0aW9uIGNoYW5nZXMgaW4gb3RoZXINCiAgIHNw b2tlcy4NCg0KICAgU3BlY2lmaWNhbGx5LCB3aGVuIGV2YWx1YXRpbmcgcG90ZW50aWFsIHByb3Bv c2Fscywgd2Ugd2lsbCBjb21wYXJlDQogICB0aGVtIGJ5IGxvb2tpbmcgYXQgaG93IG1hbnkgZW5k cG9pbnRzIG9yIGdhdGV3YXlzIG11c3QgYmUNCiAgIHJlY29uZmlndXJlZCB3aGVuIGEgbmV3IGdh dGV3YXkgb3IgZW5kcG9pbnQgaXMgYWRkZWQsIHJlbW92ZWQsIG9yDQogICBjaGFuZ2VkIGFuZCBo b3cgc3Vic3RhbnRpYWwgdGhpcyByZWNvbmZpZ3VyYXRpb24gaXMsIGJlc2lkZXMgdGhlDQogICBh bW91bnQgb2Ygc3RhdGljIGNvbmZpZ3VyYXRpb24gcmVxdWlyZWQuDQoNCiAgIFRoaXMgcmVxdWly ZW1lbnQgaXMgZHJpdmVuIGJ5IHVzZSBjYXNlcyAyLjEgYW5kIDIuMiBhbmQgYnkgdGhlDQogICBz Y2FsaW5nIGxpbWl0YXRpb25zIHBvaW50ZWQgb3V0IGluIHNlY3Rpb24gMy4xLg0KDQogICAyLiAg R2F0ZXdheXMgYW5kIGVuZHBvaW50cyBNVVNUIGFsbG93IElQc2VjIFR1bm5lbHMgdG8gYmUgc2V0 dXANCiAgIHdpdGhvdXQgYW55IGNvbmZpZ3VyYXRpb24gY2hhbmdlcywgZXZlbiB3aGVuIHBlZXIg YWRkcmVzc2VzIGdldA0KICAgdXBkYXRlZCBldmVyeSB0aW1lIHRoZSBkZXZpY2UgY29tZXMgdXAu ICBUaGlzIGltcGxpZXMgdGhhdCBTUEQNCiAgIGVudHJpZXMgb3Igb3RoZXIgY29uZmlndXJhdGlv biBiYXNlZCBvbiBwZWVyIElQIGFkZHJlc3Mgd2lsbCBuZWVkIHRvDQogICBiZSBhdXRvbWF0aWNh bGx5IHVwZGF0ZWQsIGF2b2lkZWQsIG9yIGhhbmRsZWQgaW4gc29tZSBtYW5uZXIgdG8gYXZvaWQN CiAgIGEgbmVlZCB0byBtYW51YWxseSB1cGRhdGUgcG9saWN5IHdoZW5ldmVyIGFuIGFkZHJlc3Mg Y2hhbmdlcy4NCg0KICAgVGhpcyByZXF1aXJlbWVudCBpcyBkcml2ZW4gYnkgdXNlIGNhc2VzIDIu MSBhbmQgMi4yIGFuZCBieSB0aGUNCiAgIHNjYWxpbmcgbGltaXRhdGlvbnMgcG9pbnRlZCBvdXQg aW4gc2VjdGlvbiAzLjEuDQoNCiAgIDMuICBJbiBtYW55IGNhc2VzIGFkZGl0aW9uYWwgdHVubmVs aW5nIHByb3RvY29scyAoZS5nLiAgR1JFKSBvcg0KICAgUm91dGluZyBwcm90b2NvbHMgKGUuZy4g IE9TUEYpIGFyZSBydW4gb3ZlciB0aGUgSVBzZWMgdHVubmVscy4NCiAgIEdhdGV3YXlzIE1VU1Qg YWxsb3cgZm9yIHRoZSBvcGVyYXRpb24gb2YgdHVubmVsaW5nIGFuZCBSb3V0aW5nDQogICBwcm90 b2NvbHMgb3BlcmF0aW5nIG92ZXIgc3Bva2UtdG8tc3Bva2UgSVBzZWMgVHVubmVscyB3aXRoIG1p bmltYWwgb3INCiAgIG5vLCBjb25maWd1cmF0aW9uIGltcGFjdC4gIFJvdXRpbmcgdXNpbmcgdGhl IHR1bm5lbHMgU0hPVUxEIHdvcmsNCiAgIHNlYW1sZXNzbHkgd2l0aG91dCBhbnkgdXBkYXRlcyB0 byB0aGUgaGlnaGVyIGxldmVsIGFwcGxpY2F0aW9uDQogICBjb25maWd1cmF0aW9uIGkuZS4gIE9T UEYgY29uZmlndXJhdGlvbiwgd2hlbiB0aGUgdHVubmVsIHBhcmFtZXRlcg0KICAgY2hhbmdlcy4N Cg0KICAgNC4gIEluIHRoZSBmdWxsIG1lc2ggYW5kIGR5bmFtaWMgZnVsbCBtZXNoIHRvcG9sb2d5 LCBTcG9rZXMgTVVTVA0KICAgYWxsb3cgZm9yIGRpcmVjdCBjb21tdW5pY2F0aW9uIHdpdGggb3Ro ZXIgc3Bva2UgZ2F0ZXdheXMgYW5kDQogICBlbmRwb2ludHMuICBJbiB0aGUgc3RhciB0b3BvbG9n eSBtb2RlLCBkaXJlY3QgY29tbXVuaWNhdGlvbiBiZXR3ZWVuDQogICBzcG9rZXMgTVVTVCBiZSBk aXNhbGxvd2VkLg0KDQoNCg0KSGFubmEgJiBNYW5yYWwgICAgICAgICAgICBFeHBpcmVzIEp1bmUg OSwgMjAxMyAgICAgICAgICAgICAgICAgIFtQYWdlIDldDQoNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgIEF1dG8gRGlzY292ZXJ5IFZQTiAgICAgICAgICAgICAgRGVjZW1iZXIgMjAxMg0KDQoN CiAgIFRoaXMgcmVxdWlyZW1lbnQgaXMgZHJpdmVuIGJ5IHVzZSBjYXNlcyAyLjEgYW5kIDIuMiBh bmQgYnkgdGhlDQogICBsaW1pdGF0aW9ucyBvZiBhIHN0YXIgdG9wb2xvZ3kgcG9pbnRlZCBvdXQg aW4gc2VjdGlvbiAzLjIuDQoNCiAgIDUuICBPbmUgc3Bva2UgTVVTVCBOT1QgYmUgYWJsZSB0byBp bXBlcnNvbmF0ZSBhbm90aGVyIHNwb2tlLg0KDQogICBUaGlzIHJlcXVpcmVtZW50IGlzIGRyaXZl biBieSB1c2UgY2FzZSAyLjEuICBTcG9rZXMgYmVjb21lDQogICBjb21wcm9taXNlZCBmYWlybHkg b2Z0ZW4uICBUaGUgY29tcHJvbWlzZSBvZiBvbmUgU3Bva2Ugc2hvdWxkIG5vdA0KICAgYWZmZWN0 IHRoZSBzZWN1cml0eSBvZiBvdGhlciBlbmRwb2ludHMuDQoNCiAgIDYuICBHYXRld2F5cyBTSE9V TEQgYWxsb3cgZm9yIHNlYW1sZXNzIGhhbmRvZmYgb2Ygc2Vzc2lvbnMgaW4gY2FzZQ0KICAgZW5k cG9pbnRzIGFyZSByb2FtaW5nLCBldmVuIGlmIHRoZXkgY3Jvc3MgcG9saWN5IGJvdW5kYXJpZXMu ICBUaGlzDQogICB3b3VsZCBtZWFuIHRoZSBkYXRhIHRyYWZmaWMgaXMgbWluaW1hbGx5IGFmZmVj dGVkIGV2ZW4gYXMgdGhlIGhhbmRvZmYNCiAgIGhhcHBlbnMuICBFeHRlcm5hbCBmYWN0b3JzIGxp a2UgZmlyZXdhbGwsIE5BVCBib3ggd2lsbCBub3QgYmUNCiAgIGNvbnNpZGVyZWQgcGFydCBvZiB0 aGlzIHNvbHV0aW9uLg0KDQogICBUaGlzIHJlcXVpcmVtZW50IGlzIGRyaXZlbiBieSB1c2UgY2Fz ZSAyLjEuICBUb2RheSdzIGVuZHBvaW50cyBhcmUNCiAgIG1vYmlsZSBhbmQgdHJhbnNpdGlvbiBv ZnRlbiBiZXR3ZWVuIGRpZmZlcmVudCBuZXR3b3JrcyAoZnJvbSA0RyB0bw0KICAgV2lGaSBhbmQg YW1vbmcgdmFyaW91cyBXaUZpIG5ldHdvcmtzKS4NCg0KICAgNy4gIEdhdGV3YXlzIFNIT1VMRCBh bGxvdyBmb3IgZWFzeSBoYW5kb2ZmIG9mIGEgc2Vzc2lvbiB0byBhbm90aGVyDQogICBnYXRld2F5 LCB0byBvcHRpbWl6ZSBsYXRlbmN5LCBiYW5kd2lkdGgsIGxvYWQgYmFsYW5jaW5nLA0KICAgYXZh aWxhYmlsaXR5LCBvciBvdGhlciBmYWN0b3JzLCBiYXNlZCBvbiBwb2xpY3kuDQoNCiAgIFRoaXMg cmVxdWlyZW1lbnQgaXMgZHJpdmVuIGJ5IHVzZSBjYXNlIDIuMy4NCg0KICAgOC4gIEdhdGV3YXlz IGFuZCBlbmRwb2ludHMgTVVTVCBiZSBhYmxlIHRvIHdvcmsgd2hlbiB0aGV5IGFyZSBiZWhpbmQN CiAgIE5BVCBib3hlcy4gIEl0IGlzIGVzcGVjaWFsbHkgZGlmZmljdWx0IHRvIGhhbmRsZSBjYXNl cyB3aGVyZSB0aGUgSHViDQogICBpcyBiZWhpbmQgYSBOQVQgYm94LCBzdWNoIGEgcmVxdWlyZW1l bnQgTUFZIGJlIHN1cHBvcnRlZC4gIFdoZXJlIHRoZQ0KICAgdHdvIGVuZHBvaW50cyBhcmUgYm90 aCBiZWhpbmQgc2VwYXJhdGUgTkFUcywgY29tbXVuaWNhdGlvbiBiZXR3ZWVuDQogICB0aGVzZSBz cG9rZXMgU0hPVUxEIGJlIHN1cHBvcnRlZC4gIEluIHRoZSBjYXNlcywgd29ya2Fyb3VuZHMgTUFZ IGJlDQogICB1c2VkIHN1Y2ggYXMgcG9ydCBmb3J3YXJkaW5nIGJ5IHRoZSBOQVQgb3IgZGV0ZWN0 aW5nIHdoZW4gdHdvIHNwb2tlcw0KICAgYXJlIGJlaGluZCB1bmNvb3BlcmF0aXZlIE5BVHMgYW5k IHVzaW5nIGEgaHViIGluIHRoYXQgY2FzZS4NCg0KICAgVGhpcyByZXF1aXJlbWVudCBpcyBkcml2 ZW4gYnkgdXNlIGNhc2VzIDIuMSBhbmQgMi4yLiAgRW5kcG9pbnRzIGFyZQ0KICAgb2Z0ZW4gYmVo aW5kIE5BVHMgYW5kIGdhdGV3YXlzIHNvbWV0aW1lcyBhcmUuICBJUHNlYyBzaG91bGQgY29udGlu dWUNCiAgIHRvIHdvcmsgc2VhbWxlc3NseSByZWdhcmRsZXNzLCB1c2luZyBBRCBWUE4gdGVjaG5p cXVlcyB3aGVuZXZlcg0KICAgcG9zc2libGUgYW5kIHByb3ZpZGluZyBncmFjZWZ1bCBmYWxsYmFj ayB0byBodWIgYW5kIHNwb2tlIHRlY2huaXF1ZXMNCiAgIGFzIG5lZWRlZC4NCg0KICAgOS4gIENo YW5nZXMgc3VjaCBhcyBlc3RhYmxpc2hpbmcgYSBuZXcgSVBzZWMgU0EgU0hPVUxEIGJlIHJlcG9y dGFibGUNCiAgIGFuZCBtYW5hZ2VhYmxlLiAgSG93ZXZlciwgY3JlYXRpbmcgYSBNSUIgb3Igb3Ro ZXIgbWFuYWdlbWVudA0KICAgdGVjaG5pcXVlIGlzIG5vdCB3aXRoaW4gc2NvcGUgZm9yIHRoaXMg ZWZmb3J0Lg0KDQogICBUaGlzIHJlcXVpcmVtZW50IGlzIGRyaXZlbiBieSBtYW5hZ2VhYmlsaXR5 IGNvbmNlcm5zIGZvciBhbGwgdGhlIHVzZQ0KICAgY2FzZXMsIGVzcGVjaWFsbHkgdXNlIGNhc2Ug Mi4yLiAgQXMgSVBzZWMgbmV0d29ya3MgYmVjb21lIG1vcmUNCiAgIGR5bmFtaWMsIG1hbmFnZW1l bnQgdG9vbHMgYmVjb21lIG1vcmUgZXNzZW50aWFsLg0KDQogICAxMC4gIFRvIHN1cHBvcnQgYWxs aWVkIGFuZCBmZWRlcmF0ZWQgZW52aXJvbm1lbnRzLCBlbmRwb2ludHMgYW5kDQoNCg0KDQpIYW5u YSAmIE1hbnJhbCAgICAgICAgICAgIEV4cGlyZXMgSnVuZSA5LCAyMDEzICAgICAgICAgICAgICAg ICBbUGFnZSAxMF0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgQXV0byBEaXNjb3Zlcnkg VlBOICAgICAgICAgICAgICBEZWNlbWJlciAyMDEyDQoNCg0KICAgZ2F0ZXdheXMgZnJvbSBkaWZm ZXJlbnQgb3JnYW5pemF0aW9ucyBTSE9VTEQgYmUgYWJsZSB0byBjb25uZWN0IHRvDQogICBlYWNo IG90aGVyLg0KDQogICAxMS4gIFRoZSBhZG1pbmlzdHJhdG9yIG9mIHRoZSBBRFZQTiBTSE9VTEQg YWxsb3cgZm9yIHRoZQ0KICAgY29uZmlndXJhdGlvbiBvZiBhIFN0YXIsIEZ1bGwgbWVzaCBvciBh IHBhcnRpYWwgZnVsbCBtZXNoIHRvcG9sb2d5LA0KICAgYmFzZWQgb24gd2hpY2ggdHVubmVscyBh cmUgYWxsb3dlZCB0byBiZSBzZXR1cC4NCg0KICAgVGhpcyByZXF1aXJlbWVudCBpcyBkcml2ZW4g YnkgZGVtYW5kIGZvciBhbGwgdGhlIHVzZSBjYXNlcyBpbg0KICAgZmVkZXJhdGVkIGFuZCBhbGxp ZWQgZW52aXJvbm1lbnRzLg0KDQogICAxMi4gIFRoZSBBRFZQTiBzb2x1dGlvbiBTSE9VTEQgYmUg YWJsZSB0byBzY2FsZSBmb3IgbXVsdGljYXN0DQogICB0cmFmZmljLg0KDQogICBUaGlzIHJlcXVp cmVtZW50IGlzIGRyaXZlbiBieSB0aGUgdXNlIGNhc2UgMi4yLCB3aGVyZSB0aGUgYW1vdW50IG9m DQogICByaWNoIG1lZGlhIG11bHRpY2FzdCB0cmFmZmljIGlzIGluY3JlYXNpbmcuDQoNCiAgIDEz LiAgVGhlIEFEVlBOIHNvbHV0aW9uIFNIT1VMRCBhbGxvdyBmb3IgZWFzeSBtb25pdG9yaW5nLCBs b2dnaW5nIGFuZA0KICAgcmVwb3J0aW5nIG9mIHRoZSBkeW5hbWljIGNoYW5nZXMsIHRvIGhlbHAg Zm9yIHRyb3VibGUgc2hvb3Rpbmcgc3VjaA0KICAgZW52aXJvbm1lbnRzLg0KDQogICBUaGlzIHJl cXVpcmVtZW50IGlzIGRyaXZlbiBieSBkZW1hbmQgZm9yIGFsbCB0aGUgdXNlIGNhc2VzIGluDQog ICBmZWRlcmF0ZWQgYW5kIGFsbGllZCBlbnZpcm9ubWVudHMuDQoNCiAgIDE0LiAgVGhlIEFEVlBO IHNvbHV0aW9uIE1VU1Qgc3VwcG9ydCBQcm92aWRlciBFZGdlIChQRSkgYmFzZWQgVlBOJ3MuDQoN CiAgIFRoaXMgcmVxdWlyZW1lbnQgaXMgZHJpdmVuIGJ5IGRlbWFuZCBmb3IgYWxsIHRoZSB1c2Ug Y2FzZXMgaW4NCiAgIGZlZGVyYXRlZCBhbmQgYWxsaWVkIGVudmlyb25tZW50cy4NCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkhhbm5hICYgTWFucmFsICAg ICAgICAgICAgRXhwaXJlcyBKdW5lIDksIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0K DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBBdXRvIERpc2NvdmVyeSBWUE4gICAgICAgICAg ICAgIERlY2VtYmVyIDIwMTINCg0KDQo1LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAg VGhlIHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtcyBwcmVzZW50ZWQgaW4gdGhpcyBkcmFmdCBtYXkg aW52b2x2ZQ0KICAgZHluYW1pYyB1cGRhdGVzIHRvIGRhdGFiYXNlcyBkZWZpbmVkIGJ5IFJGQyA0 MzAxLCBzdWNoIGFzIHRoZQ0KICAgU2VjdXJpdHkgUG9saWN5IERhdGFiYXNlIChTUEQpIG9yIHRo ZSBQZWVyIEF1dGhvcml6YXRpb24gRGF0YWJhc2UNCiAgIChQQUQpLg0KDQogICBSRkMgNDMwMSBp cyBzaWxlbnQgYWJvdXQgdGhlIHdheSB0aGVzZSBkYXRhYmFzZXMgYXJlIHBvcHVsYXRlZCwgYW5k DQogICBpdCBpcyBpbXBsaWVkIHRoYXQgdGhlc2UgZGF0YWJhc2VzIGFyZSBzdGF0aWMgYW5kIHBy ZS1jb25maWd1cmVkIGJ5IGENCiAgIGh1bWFuLiAgQWxsb3dpbmcgZHluYW1pYyB1cGRhdGVzIHRv IHRoZXNlIGRhdGFiYXNlcyBtdXN0IGJlIHRob3VnaHQNCiAgIG91dCBjYXJlZnVsbHksIGJlY2F1 c2UgaXQgYWxsb3dzIHRoZSBwcm90b2NvbCB0byBhbHRlciB0aGUgc2VjdXJpdHkNCiAgIHBvbGlj eSB0aGF0IHRoZSBJUHNlYyBlbmRwb2ludHMgaW1wbGVtZW50Lg0KDQogICBPbmUgb2J2aW91cyBh dHRhY2sgdG8gd2F0Y2ggb3V0IGZvciBpcyBzdGVhbGluZyB0cmFmZmljIHRvIGENCiAgIHBhcnRp Y3VsYXIgc2l0ZS4gIFRoZSBJUCBhZGRyZXNzIGZvciB3d3cuZXhhbXBsZS5jb20gaXMgMTkyLjAu Mi4xMC4NCiAgIElmIHdlIGFkZCBhbiBlbnRyeSB0byBhbiBJUHNlYyBlbmRwb2ludCdzIFNQRCB0 aGF0IHNheXMgdGhhdCB0cmFmZmljDQogICB0byAxOTIuMC4yLjEwIGlzIHByb3RlY3RlZCB0aHJv dWdoIHBlZXIgR3ctTWFsbG9yeSwgdGhlbiB0aGlzIGFsbG93cw0KICAgR3ctTWFsbG9yeSB0byBl aXRoZXIgcHJldGVuZCB0byBiZSB3d3cuZXhhbXBsZS5jb20gb3IgdG8gcHJveHkgYW5kDQogICBy ZWFkIGFsbCB0cmFmZmljIHRvIHRoYXQgc2l0ZS4gIFVwZGF0ZXMgdG8gdGhpcyBkYXRhYmFzZSBy ZXF1aXJlcyBhDQogICBjbGVhciB0cnVzdCBtb2RlbC4NCg0KICAgTW9yZSB0byBiZSBhZGRlZC4N Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQpIYW5uYSAmIE1hbnJhbCAgICAgICAgICAgIEV4cGlyZXMgSnVuZSA5LCAyMDEzICAgICAgICAg ICAgICAgICBbUGFnZSAxMl0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgQXV0byBEaXNj b3ZlcnkgVlBOICAgICAgICAgICAgICBEZWNlbWJlciAyMDEyDQoNCg0KNi4gIElBTkEgQ29uc2lk ZXJhdGlvbnMNCg0KICAgTm8gYWN0aW9ucyBhcmUgcmVxdWlyZWQgZnJvbSBJQU5BIGZvciB0aGlz IGluZm9ybWF0aW9uYWwgZG9jdW1lbnQuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpIYW5uYSAmIE1hbnJhbCAgICAgICAgICAgIEV4cGlyZXMgSnVuZSA5LCAyMDEzICAg ICAgICAgICAgICAgICBbUGFnZSAxM10NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgQXV0 byBEaXNjb3ZlcnkgVlBOICAgICAgICAgICAgICBEZWNlbWJlciAyMDEyDQoNCg0KNy4gIEFja25v d2xlZGdlbWVudHMNCg0KICAgTWFueSBwZW9wbGUgaGF2ZSBjb250cmlidXRlZCB0byB0aGUgZGV2 ZWxvcG1lbnQgb2YgdGhpcyBwcm9ibGVtDQogICBzdGF0ZW1lbnQgYW5kIG1hbnkgbW9yZSB3aWxs IHByb2JhYmx5IGRvIHNvIGJlZm9yZSB3ZSBhcmUgZG9uZSB3aXRoDQogICBpdC4gIFdoaWxlIHdl IGNhbm5vdCB0aGFuayBhbGwgY29udHJpYnV0b3JzLCBzb21lIGhhdmUgcGxheWVkIGFuDQogICBl c3BlY2lhbGx5IHByb21pbmVudCByb2xlLiAgWW9hdiBOaXIsIFlhcm9uIFNjaGVmZmVyLCBKb3Jn ZSBDb3JvbmVsDQogICBNZW5kb3phLCBDaHJpcyBVbGxpb3R0LCBhbmQgSm9obiBWZWl6YWRlcyB3 cm90ZSB0aGUgZG9jdW1lbnQgdXBvbg0KICAgd2hpY2ggdGhpcyBkcmFmdCB3YXMgYmFzZWQuICBH ZW9mZnJleSBIdWFuZywgU3VyZXNoIE1lbGFtLCBQcmF2ZWVuDQogICBTYXRoeWFuYXJheWFuLCBB bmRyZWFzIFN0ZWZmZW4sIEJyaWFuIFdlaXMsIGFuZCBMb3UgQmVyZ2VyIHByb3ZpZGVkDQogICBl c3NlbnRpYWwgaW5wdXQuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KSGFubmEgJiBNYW5yYWwg ICAgICAgICAgICBFeHBpcmVzIEp1bmUgOSwgMjAxMyAgICAgICAgICAgICAgICAgW1BhZ2UgMTRd DQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgIEF1dG8gRGlzY292ZXJ5IFZQTiAgICAgICAg ICAgICAgRGVjZW1iZXIgMjAxMg0KDQoNCjguICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBb UkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRp Y2F0ZQ0KICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5 LCBNYXJjaCAxOTk3Lg0KDQogICBbUkZDNDMwMV0gIEtlbnQsIFMuIGFuZCBLLiBTZW8sICJTZWN1 cml0eSBBcmNoaXRlY3R1cmUgZm9yIHRoZQ0KICAgICAgICAgICAgICBJbnRlcm5ldCBQcm90b2Nv bCIsIFJGQyA0MzAxLCBEZWNlbWJlciAyMDA1Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCkhhbm5hICYgTWFucmFsICAgICAgICAgICAgRXhwaXJlcyBKdW5lIDksIDIwMTMgICAgICAg ICAgICAgICAgIFtQYWdlIDE1XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBBdXRvIERp c2NvdmVyeSBWUE4gICAgICAgICAgICAgIERlY2VtYmVyIDIwMTINCg0KDQpBdXRob3JzJyBBZGRy ZXNzZXMNCg0KICAgU3RldmUgSGFubmENCiAgIEp1bmlwZXIgTmV0d29ya3MsIEluYy4NCiAgIDEx OTQgTi4gTWF0aGlsZGEgQXZlLg0KICAgU3Vubnl2YWxlLCBDQSAgOTQwODkNCiAgIFVTQQ0KDQog ICBFbWFpbDogc2hhbm5hQGp1bmlwZXIubmV0DQoNCg0KICAgVmlzaHdhcyBNYW5yYWwNCiAgIEhl d2xldHQtUGFja2FyZCBDby4NCiAgIDE5MTExIFBydW5lcmlkZ2UgQXZlLg0KICAgQ3VwZXJ0aW5v LCBDQSAgOTUxMTMNCiAgIFVTQQ0KDQogICBFbWFpbDogdmlzaHdhcy5tYW5yYWxAaHAuY29tDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpIYW5uYSAmIE1hbnJhbCAgICAgICAgICAgIEV4cGlyZXMgSnVuZSA5LCAyMDEzICAg ICAgICAgICAgICAgICBbUGFnZSAxNl0NCg== --20cf3074b3b2eb3c0204d037cc04-- From Johannes.Merkle@secunet.com Fri Dec 7 02:50:07 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E0621F883A for ; Fri, 7 Dec 2012 02:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWexGVTLWgSn for ; Fri, 7 Dec 2012 02:50:06 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 70F7E21F8742 for ; Fri, 7 Dec 2012 02:50:04 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 8CC0C1A008C; Fri, 7 Dec 2012 11:49:47 +0100 (CET) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 6F7141A008F; Fri, 7 Dec 2012 11:49:41 +0100 (CET) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Dec 2012 11:49:56 +0100 Message-ID: <50C1C9D3.30200@secunet.com> Date: Fri, 07 Dec 2012 11:49:55 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Scott Fluhrer (sfluhrer)" References: <50B8A287.9090509@secunet.com> <074557eff2f722f10198aac4fb2f8d9c.squirrel@www.trepanning.net> <4613980CFC78314ABFD7F85CC30277210EDCE571@IL-EX10.ad.checkpoint.com> <50B9DC95.80202@gmail.com> <50BA5A70.6030808@gmail.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 07 Dec 2012 10:49:56.0198 (UTC) FILETIME=[9863D860:01CDD468] Cc: Manfred Lochter , Yoav Nir , Dan Harkins , IPsecme WG , "rfc-ise@rfc-editor.org" , "Sean P. Turner" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 10:50:08 -0000 Hi Scott, > Sigh, immediately after sending this, I remembered that even characteristic EC curves tend to have cofactors h>1, hence there is further checking required for them. Scratch what I said that the what I said for odd characteristic EC curves applies to even as well -- that checking is necessary, but it is not sufficient. > After having verified that the point (x,y) = P satisfies the curve equation and is not the point at infinity O, checking n*P = O is sufficient. If the cofactor h is 1 then this last check is not even necessary. The validation algorithm is defined in detail in SEC1, Section 3.2.2.1. This reference should be used for the validation requirements. Checking n*P = O is costly, but fortunately, all NIST and Brainpool curves have cofactor 1 making this check uneccesary. BTW: The check n*P = O can be omitted even for non-trivial cofactor, if h*P is used as public DH key instead of P, i.e. if the Elliptic Curve Cofactor Diffie-Hellman Primitive described in Section 3.3.2 of SEC1 is used. Johannes > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Scott Fluhrer (sfluhrer) > Sent: Monday, December 03, 2012 9:28 AM > To: Yaron Sheffer > Cc: Johannes Merkle; Manfred Lochter; Yoav Nir; Dan Harkins; IPsecme WG; rfc-ise@rfc-editor.org; Sean P. Turner > Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange > > As for http://tools.ietf.org/html/rfc5996#section-2.12, it's fine as far as it goes, however (IMHO) it rather punts on what self-checks are actually needed. It does refer to the Menezes and Ustaoglu paper, which is quite good, however, it would be better if you spell out exactly what tests the implementer would need to run for each IKE group. An implementation might have problems determining from the paper what is appropriate; for example, groups 22-24 would be considered "DSA groups" by the nomenclature of the paper (see section 2.1); however nowhere in the IKE documents are they actually labeled as such. > > Here is a quick run-down: > - Standard MODP groups (1, 2, 5, 14-18): informational leakage from a small group attack is minimal (see section 2.2 of the paper); hence, the only check needed is a verification that the peer's public value r is in range (1 < r < p-1) > > - MODP groups with small subgroups (22-24): there is some informational leakage from a small subgroup attack (see section 2.1 of the paper); hence, you need to check both that the peer's public value is in range (1 < r < p-1) and that r**q = 1 mod p (where q is the size of the subgroup) > > - EC groups; there is some informational leakage possible (see section 2.3); hence, you need to check that the peer's public value is valid; that is, it is not the point-at-infinity, and that the x and y parameters from the peer's public value satisfies the curve equation, that is, y**2 = x**3 + ax + b mod p. Note that even though the paper specifically targets odd characteristic EC curves, their advice of checking the curve equation is equally applicable to even characteristic curves as well. > > > Now, as for whether checking the peer's public value ought to be a requirement, even if you aren't reusing private keys, I would still say that it ought to be. If we look at the ECDH point addition/doubling code, well, they are designed to work correctly if you give them valid points (that is, points that are actually on the curve). If you just take bit patterns you received in a packet from the peer, and just give them to the EC routines, well, there's no inherent requirement what might happen if the values don't happen to be valid. If the implementation uses the standard textbook point addition/doubling code, we can predict what will happen -- however, a specific implementation might decide to do something different. Because of this (and because checking is so cheap -- we're talking maybe 1% of the cost of the cost of doing the ECDH phase two), I would strongly urge anyone to do this check. > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer > Sent: Saturday, December 01, 2012 2:29 PM > To: Scott Fluhrer (sfluhrer) > Cc: Johannes Merkle; Manfred Lochter; Yoav Nir; Dan Harkins; IPsecme WG; rfc-ise@rfc-editor.org; Sean P. Turner > Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange > > Hi Scott, > > OK, I see your point (no pun intended). Regarding ECDH secret reuse, can you please review http://tools.ietf.org/html/rfc5996#section-2.12. That section was supposed to cover the relevant security considerations. In fact I think your attack is alluded to in the paper we reference from that section (see Sec. 5, first paragraph). > > If this needs to become a MUST requirement for IKEv2 peers using ECDH, it needs to be spelled out and not left as an exercise to the reader. > But we have to understand whether this is a general requirement, or it only applies to peers that are reusing ECDH private keys for multiple IKE sessions. > > Thanks, > Yaron > > On 12/01/2012 08:44 PM, Scott Fluhrer (sfluhrer) wrote: >> I would humbly disagree. A peer might try to send us an invalid KE, with a bogus point that acts as if it were of small order with our implementation; let us call this bogus point P, and its small order n. We would then generate sk's based on the point (e mod n)P (where e is the value of our ECDH secret); because n is small, that allows the attacker to recover the value (e mod n). >> >> If we reuse the same ECDH secret for multiple exchanges (which is normally safe), this allows someone who controls some of the peers we talk to to recover the secret value for exchanges he does not control; this is not good. >> >> Hence, we need to either mandate checking the point we receive, or forbid ECDH secret reuse. >> >> -----Original Message----- >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >> Sent: Saturday, December 01, 2012 5:32 AM >> To: Scott Fluhrer (sfluhrer) >> Cc: Yoav Nir; Johannes Merkle; IPsecme WG; Manfred Lochter; Sean P. >> Turner; Dan Harkins; rfc-ise@rfc-editor.org >> Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 >> Key Exchange >> >> Actually, I think we have it wrong. There is no reason for a *valid* >> peer to send an incorrect KE. And IKEv2 already protects against a >> MITM doing such a thing. As we all know, the protocol assumes that >> messages >> #3 and #4 can be observed by an attacker, and protects against malicious changes to any of the 4 messages, including the KE value. >> >> In other words, I would say this is a QA-level test that MAY be performed by the sender. Not one that MUST be performed by the recipient. >> >> By the way, there are related protocols that need this test for their security and do include it: SPSK, and my own RFC 6631 (IKEv2 with PACE). >> See e.g. https://tools.ietf.org/html/rfc6631#section-3.4. >> >> Thanks, >> Yaron >> >> >> On 12/01/2012 12:00 AM, Scott Fluhrer (sfluhrer) wrote: >>> With ECDH, there are two separate EC points that are output by the algorithm: >>> >>> - There's the public value xG (where x is our secret); this is passed >>> in the KE payload >>> - There's the shared secret value xyG (where x is our shared secret, and y is the peer's secret); this is used in the key derivation function. >>> >>> What RFC5903 says is: >>> - The public value xG will be expressed as explicit x, y coordinates. >>> - The shared secret value xyG (that is, the value we give to the sk generation function) will be only the x coordinate; the y coordinate will not be used. >>> >>> Yes, this implies that doing point compression on the shared secret value doesn't make much sense (as point compression discards all but one bit of y -- the format that RFC5903 chooses already discards all the bits of y). However, the argument about point compression was never about the shared secret value; instead, it was about the repesentation that appeared in the KE payload (that is, the one that is specified to have both the x and y coordinates). >>> >>> As for Dan's question, it was about whether we should validate the public value we get from the peer, well, the public value does have explicit x and y coordinates, and so it makes sense to check them. >>> >>> >>> -----Original Message----- >>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >>> Behalf Of Yoav Nir >>> Sent: Friday, November 30, 2012 4:39 PM >>> To: Johannes Merkle >>> Cc: IPsecme WG; Manfred Lochter; Sean P. Turner; Dan Harkins; >>> rfc-ise@rfc-editor.org >>> Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 >>> Key Exchange >>> >>> Hi Johannes, >>> >>> Dan't question made me realise something I hadn't noticed before. >>> >>> In section 2.3, the draft says: >>> For the encoding of the key exchange payload and the derivation of >>> the shared secret, the methods specified in [RFC5903] are adopted. >>> >>> In an ECP key exchange in IKEv2, the Diffie-Hellman public value >>> passed in a KE payload consists of two components, x and y, >>> >>> However, according to RFC 5903: >>> The Diffie-Hellman shared secret value consists of the x value of >>> the Diffie-Hellman common value. >>> >>> In fact RFC 5903 replaced 4753 just to say that the encoding consists only of x, not both x and y. >>> >>> This also relates to Dan't question. If the y value is missing, what is there to verify? >>> >>> Yoav >>> >>> On Nov 30, 2012, at 7:57 PM, Dan Harkins wrote: >>> >>>> >>>> Hi Johannes, >>>> >>>> On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote: >>>>> We have submitted a new revision of the Internet Draft on Using the >>>>> ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange >>>>> https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ >>>>> >>>>> Since there was considerable objection to the point compression >>>>> method in the WG, we have removed this option altogether and define >>>>> only the uncompressed KE payload format, which is in full >>>>> accordance with RFC 5903. >>>>> >>>>> >>>>> Any feedback is welcome. >>>> >>>> I see that there is a requirement that an implementation MUST >>>> verify that the D-H common value is not the point-at-infinity. Do >>>> you think there should also be a requirement that an implementation >>>> MUST verify that the x- and y-coordinates received from a peer >>>> satisfy the equation of the negotiated curve (and abort the exchange if not)? >>>> >>>> regards, >>>> >>>> Dan. >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > -- Mit freundlichen Grüßen, Johannes Merkle Biometrie & Hoheitliche Dokumente secunet Security Networks AG Mergenthaler Allee 77 65760 Eschborn Germany Telefon +49 201 54 54-3091 Telefax +49 201 54 54-1325 Mobil +49 175 2224439 johannes.merkle@secunet.com www.secunet.com From Johannes.Merkle@secunet.com Fri Dec 7 02:52:04 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4B921F8525 for ; Fri, 7 Dec 2012 02:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIMTi6FnGGOQ for ; Fri, 7 Dec 2012 02:52:03 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7D17821F8522 for ; Fri, 7 Dec 2012 02:52:03 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id D2C591A008E; Fri, 7 Dec 2012 11:51:47 +0100 (CET) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id A4A571A008C; Fri, 7 Dec 2012 11:51:46 +0100 (CET) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Dec 2012 11:52:01 +0100 Message-ID: <50C1CA50.3020703@secunet.com> Date: Fri, 07 Dec 2012 11:52:00 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Tero Kivinen References: <50B8A287.9090509@secunet.com> <074557eff2f722f10198aac4fb2f8d9c.squirrel@www.trepanning.net> <4613980CFC78314ABFD7F85CC30277210EDCE571@IL-EX10.ad.checkpoint.com> <50B9DC95.80202@gmail.com> <50BA5A70.6030808@gmail.com> <50BC8460.9030808@secunet.com> <20668.40826.934312.605279@fireball.kivinen.iki.fi> In-Reply-To: <20668.40826.934312.605279@fireball.kivinen.iki.fi> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Dec 2012 10:52:01.0451 (UTC) FILETIME=[E30BEFB0:01CDD468] Cc: Manfred Lochter , Yoav Nir , Dan Harkins , IPsecme WG , "rfc-ise@rfc-editor.org" , "Scott Fluhrer \(sfluhrer\)" , "Sean P. Turner" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 10:52:04 -0000 Hi Tero, > > I think it would be best to take the ECDH processing rules (mostly > from 5903 but also add the checks if those are needed) and create new > RFC that will update 5996. This document should not include any > groups. > I assume that my draft should refer to this RFC-to-be, right? -- Johannes From Johannes.Merkle@secunet.com Fri Dec 7 04:20:30 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6781121F882F for ; Fri, 7 Dec 2012 04:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2u0ft8yF05t for ; Fri, 7 Dec 2012 04:20:29 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id ADE5221F881E for ; Fri, 7 Dec 2012 04:20:28 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 9753C1A0083; Fri, 7 Dec 2012 13:20:08 +0100 (CET) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 488BC1A0079; Fri, 7 Dec 2012 13:20:06 +0100 (CET) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Dec 2012 13:20:19 +0100 Message-ID: <50C1DF02.2030309@secunet.com> Date: Fri, 07 Dec 2012 13:20:18 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Scott Fluhrer (sfluhrer)" References: <50B8A287.9090509@secunet.com> <074557eff2f722f10198aac4fb2f8d9c.squirrel@www.trepanning.net> <4613980CFC78314ABFD7F85CC30277210EDCE571@IL-EX10.ad.checkpoint.com> <50B9DC95.80202@gmail.com> <50BA5A70.6030808@gmail.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 07 Dec 2012 12:20:21.0853 (UTC) FILETIME=[3A5518D0:01CDD475] Cc: Manfred Lochter , Yoav Nir , Dan Harkins , IPsecme WG , "rfc-ise@rfc-editor.org" , "Sean P. Turner" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 12:20:30 -0000 Hi Scott, > - Standard MODP groups (1, 2, 5, 14-18): informational leakage from a small group attack is minimal (see section 2.2 of the paper); hence, the only check needed is a verification that the peer's public value r is in range (1 < r < p- > > - MODP groups with small subgroups (22-24): there is some informational leakage from a small subgroup attack (see section 2.1 of the paper); hence, you need to check both that the peer's public value is in range (1 < r < p-1) and that r**q = 1 mod p (where q is the size of the subgroup) For MODP groups, we can just refer to RFC 2631, Section 2.1.5 > > - EC groups; there is some informational leakage possible (see section 2.3); hence, you need to check that the peer's public value is valid; that is, it is not the point-at-infinity, and that the x and y parameters from the peer's public value satisfies the curve equation, that is, y**2 = x**3 + ax + b mod p. Note that even though the paper specifically targets odd characteristic EC curves, their advice of checking the curve equation is equally applicable to even characteristic curves as well. > As I said in my earlier mail, we could refer to SEC1, Section 3.2.2.1 > > Now, as for whether checking the peer's public value ought to be a requirement, even if you aren't reusing private keys, I would still say that it ought to be. If we look at the ECDH point addition/doubling code, well, they are designed to work correctly if you give them valid points (that is, points that are actually on the curve). If you just take bit patterns you received in a packet from the peer, and just give them to the EC routines, well, there's no inherent requirement what might happen if the values don't happen to be valid. If the implementation uses the standard textbook point addition/doubling code, we can predict what will happen -- however, a specific implementation might decide to do something different. Because of this (and because checking is so cheap -- we're talking maybe 1% of the cost of the cost of doing the ECDH phase two), I would strongly urge anyone to do this check. > In general, the potential information leakage does not depend on the implementation. In case of ephemeral DH keys all secret information involved in the DH-KE (the private DH key) is renewed in every execution. Thus, all that can be learned is only relevant for the current session. And this information is known to the sending peer anyway. However, if there is any statistical dependence between the private DH keys of different executions, the above argument is not valid anymore. Thus, the validation of the H-key is necessary as soon as complete independence is not ensured, e.g. by deploying an (P)RNG with insufficient entropy. The dependences should not be exploitable for attacks in case that strong PRNG are used. But since you can not be certain about the security of a practical PRNG (its entropy source or internal state may be influenced or leaked) it is always advisable to perform the public key validation. Johannes > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer > Sent: Saturday, December 01, 2012 2:29 PM > To: Scott Fluhrer (sfluhrer) > Cc: Johannes Merkle; Manfred Lochter; Yoav Nir; Dan Harkins; IPsecme WG; rfc-ise@rfc-editor.org; Sean P. Turner > Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange > > Hi Scott, > > OK, I see your point (no pun intended). Regarding ECDH secret reuse, can you please review http://tools.ietf.org/html/rfc5996#section-2.12. That section was supposed to cover the relevant security considerations. In fact I think your attack is alluded to in the paper we reference from that section (see Sec. 5, first paragraph). > > If this needs to become a MUST requirement for IKEv2 peers using ECDH, it needs to be spelled out and not left as an exercise to the reader. > But we have to understand whether this is a general requirement, or it only applies to peers that are reusing ECDH private keys for multiple IKE sessions. > > Thanks, > Yaron > > On 12/01/2012 08:44 PM, Scott Fluhrer (sfluhrer) wrote: >> I would humbly disagree. A peer might try to send us an invalid KE, with a bogus point that acts as if it were of small order with our implementation; let us call this bogus point P, and its small order n. We would then generate sk's based on the point (e mod n)P (where e is the value of our ECDH secret); because n is small, that allows the attacker to recover the value (e mod n). >> >> If we reuse the same ECDH secret for multiple exchanges (which is normally safe), this allows someone who controls some of the peers we talk to to recover the secret value for exchanges he does not control; this is not good. >> >> Hence, we need to either mandate checking the point we receive, or forbid ECDH secret reuse. >> >> -----Original Message----- >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >> Sent: Saturday, December 01, 2012 5:32 AM >> To: Scott Fluhrer (sfluhrer) >> Cc: Yoav Nir; Johannes Merkle; IPsecme WG; Manfred Lochter; Sean P. >> Turner; Dan Harkins; rfc-ise@rfc-editor.org >> Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 >> Key Exchange >> >> Actually, I think we have it wrong. There is no reason for a *valid* >> peer to send an incorrect KE. And IKEv2 already protects against a >> MITM doing such a thing. As we all know, the protocol assumes that >> messages >> #3 and #4 can be observed by an attacker, and protects against malicious changes to any of the 4 messages, including the KE value. >> >> In other words, I would say this is a QA-level test that MAY be performed by the sender. Not one that MUST be performed by the recipient. >> >> By the way, there are related protocols that need this test for their security and do include it: SPSK, and my own RFC 6631 (IKEv2 with PACE). >> See e.g. https://tools.ietf.org/html/rfc6631#section-3.4. >> >> Thanks, >> Yaron >> >> >> On 12/01/2012 12:00 AM, Scott Fluhrer (sfluhrer) wrote: >>> With ECDH, there are two separate EC points that are output by the algorithm: >>> >>> - There's the public value xG (where x is our secret); this is passed >>> in the KE payload >>> - There's the shared secret value xyG (where x is our shared secret, and y is the peer's secret); this is used in the key derivation function. >>> >>> What RFC5903 says is: >>> - The public value xG will be expressed as explicit x, y coordinates. >>> - The shared secret value xyG (that is, the value we give to the sk generation function) will be only the x coordinate; the y coordinate will not be used. >>> >>> Yes, this implies that doing point compression on the shared secret value doesn't make much sense (as point compression discards all but one bit of y -- the format that RFC5903 chooses already discards all the bits of y). However, the argument about point compression was never about the shared secret value; instead, it was about the repesentation that appeared in the KE payload (that is, the one that is specified to have both the x and y coordinates). >>> >>> As for Dan's question, it was about whether we should validate the public value we get from the peer, well, the public value does have explicit x and y coordinates, and so it makes sense to check them. >>> >>> >>> -----Original Message----- >>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >>> Behalf Of Yoav Nir >>> Sent: Friday, November 30, 2012 4:39 PM >>> To: Johannes Merkle >>> Cc: IPsecme WG; Manfred Lochter; Sean P. Turner; Dan Harkins; >>> rfc-ise@rfc-editor.org >>> Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 >>> Key Exchange >>> >>> Hi Johannes, >>> >>> Dan't question made me realise something I hadn't noticed before. >>> >>> In section 2.3, the draft says: >>> For the encoding of the key exchange payload and the derivation of >>> the shared secret, the methods specified in [RFC5903] are adopted. >>> >>> In an ECP key exchange in IKEv2, the Diffie-Hellman public value >>> passed in a KE payload consists of two components, x and y, >>> >>> However, according to RFC 5903: >>> The Diffie-Hellman shared secret value consists of the x value of >>> the Diffie-Hellman common value. >>> >>> In fact RFC 5903 replaced 4753 just to say that the encoding consists only of x, not both x and y. >>> >>> This also relates to Dan't question. If the y value is missing, what is there to verify? >>> >>> Yoav >>> >>> On Nov 30, 2012, at 7:57 PM, Dan Harkins wrote: >>> >>>> >>>> Hi Johannes, >>>> >>>> On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote: >>>>> We have submitted a new revision of the Internet Draft on Using the >>>>> ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange >>>>> https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ >>>>> >>>>> Since there was considerable objection to the point compression >>>>> method in the WG, we have removed this option altogether and define >>>>> only the uncompressed KE payload format, which is in full >>>>> accordance with RFC 5903. >>>>> >>>>> >>>>> Any feedback is welcome. >>>> >>>> I see that there is a requirement that an implementation MUST >>>> verify that the D-H common value is not the point-at-infinity. Do >>>> you think there should also be a requirement that an implementation >>>> MUST verify that the x- and y-coordinates received from a peer >>>> satisfy the equation of the negotiated curve (and abort the exchange if not)? >>>> >>>> regards, >>>> >>>> Dan. >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > -- Mit freundlichen Grüßen, Johannes Merkle Biometrie & Hoheitliche Dokumente secunet Security Networks AG Mergenthaler Allee 77 65760 Eschborn Germany Telefon +49 201 54 54-3091 Telefax +49 201 54 54-1325 Mobil +49 175 2224439 johannes.merkle@secunet.com www.secunet.com From yaronf.ietf@gmail.com Fri Dec 7 04:48:22 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718CD21F8727 for ; Fri, 7 Dec 2012 04:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbkPH3ZaC9rm for ; Fri, 7 Dec 2012 04:48:21 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 244FE21F86EB for ; Fri, 7 Dec 2012 04:48:20 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so222196bku.31 for ; Fri, 07 Dec 2012 04:48:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+W+vfD+2IYfr0cDWPfR1ZL1MzFYkSpGKDwE2tWueO/o=; b=0bIuNlMJ5LaXxbk7ZUekSjAEVA8iq6CYApRB4aghwylqNYUjLemeRTkcdMUr8uDaKo ILF55x2aCGcB4szwMkO4WUGNtEHRf5YhQ5B/5AJjIYRYRFVS0iiKdI3BfqHj1j7D6yB6 W/zkI+Nqrve6mcgyx1nKkI1+l37KixaimzH0hiLeNFksjSlQAVk4jLALE+7ENMVmjUI6 e90DUmhvw4cOEifs8+VvObImrTARAQ+OgRnANMM1hbMKxNOIEGaob34CceRghXde1qBA 3AssLf89oHgEeANeEnC/uy+ZsN/JpocJNLKr5H3Aqh+aqZOlYHWhbyGIMlP13Xa/L2HF 9l3Q== Received: by 10.204.4.131 with SMTP id 3mr1825080bkr.25.1354884500093; Fri, 07 Dec 2012 04:48:20 -0800 (PST) Received: from [10.0.0.3] (bzq-79-180-163-165.red.bezeqint.net. [79.180.163.165]) by mx.google.com with ESMTPS id y11sm8957804bkw.8.2012.12.07.04.47.56 (version=SSLv3 cipher=OTHER); Fri, 07 Dec 2012 04:48:18 -0800 (PST) Message-ID: <50C1E577.8060607@gmail.com> Date: Fri, 07 Dec 2012 14:47:51 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Johannes Merkle References: <50B8A287.9090509@secunet.com> <074557eff2f722f10198aac4fb2f8d9c.squirrel@www.trepanning.net> <4613980CFC78314ABFD7F85CC30277210EDCE571@IL-EX10.ad.checkpoint.com> <50B9DC95.80202@gmail.com> <50BA5A70.6030808@gmail.com> <50BC8460.9030808@secunet.com> <20668.40826.934312.605279@fireball.kivinen.iki.fi> <50C1CA50.3020703@secunet.com> In-Reply-To: <50C1CA50.3020703@secunet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Manfred Lochter , Yoav Nir , Dan Harkins , Tero Kivinen , IPsecme WG , "rfc-ise@rfc-editor.org" , "Scott Fluhrer \(sfluhrer\)" , "Sean P. Turner" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 12:48:22 -0000 Hi Johannes, Scott and I are working on this draft. You can expect an initial version within a week. Thanks, Yaron On 12/07/2012 12:52 PM, Johannes Merkle wrote: > Hi Tero, > >> >> I think it would be best to take the ECDH processing rules (mostly >> from 5903 but also add the checks if those are needed) and create new >> RFC that will update 5996. This document should not include any >> groups. >> > I assume that my draft should refer to this RFC-to-be, right? > > > From kivinen@iki.fi Fri Dec 7 05:49:15 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AA221F869A for ; Fri, 7 Dec 2012 05:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcuLSPHycdUe for ; Fri, 7 Dec 2012 05:49:14 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDD821F8532 for ; Fri, 7 Dec 2012 05:49:13 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qB7DnCFv017768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Dec 2012 15:49:12 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qB7DnBW6024323; Fri, 7 Dec 2012 15:49:11 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20673.62423.672402.859432@fireball.kivinen.iki.fi> Date: Fri, 7 Dec 2012 15:49:11 +0200 From: Tero Kivinen To: Johannes Merkle In-Reply-To: <50BE3CD3.3010304@secunet.com> References: <20121204135025.24091.3591.idtracker@ietfa.amsl.com> <20670.1967.744783.372876@fireball.kivinen.iki.fi> <50BE3CD3.3010304@secunet.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 20 min X-Total-Time: 73 min Cc: ipsec@ietf.org Subject: Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-signature-auth-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 13:49:15 -0000 Johannes Merkle writes: > > To fully support RSASSA-PSS we would need to include full > > AlgorithmIdentifier ASN.1 including the parameters. I myself would > > think that would be best option, as that would allow widest possible > > use for this new method, i.e. we can support whatever PKIX does. Some > > design team members disagreed, and we ended up with the current > > compromize... > > If RSA-PSS keys are used then this should not be an issue. In this > case the SPKI of the cert specifies the parameters to be used. Even in that case we need to say in this draft that the RSASSA-PSS parameters are taken from the SPKI of the cert. If the SPKI includes parameters, are those the only parameters that can be used with the cert, i.e. does that mean that you cannot use any other hash than what is speficied there (I am not familiar enough with RSASSA-PSS to know how it works). > However, RSA-PSS keys are hardly supported yet. If the SPKI includes > just an rsaEncryption OID, there are several problems: > - A peer with an RSA signing key supporting RSA-PSS has no means to > determine if the other peer supports PSS as well or if he should > better fall back to PKCS#1v1.5. At least he can find out with trial > and error. Or by configuration / policy. I.e. if the policy says RSASSA-PSS is to be used, then it can be assumed it also works for those peers where the policy requires it... I do not think this is going to be problem in general case. The IPsec configuration usually have quite a lot of all kind of configuration / policy information in both ends and some of those needs to match. > - When verifying a RSA-PSS signature based on a certificate > specifying rsaEncryption in SPKI, additional information on the > parameters used are needed. But the problem is when you do know from the configuration that other end do support RSASSA-PSS, and you can see the supported hash functions from the SIGNATURE_HASH_ALGORITHMs, but you do not know which hash function the other end uses, as the RSASSA-PSS oid does not include it... I think that is much bigger problem. > I would also advocate inclusion of parameters in the > AlgorithmIdentifier inside Authentication Data. In most cases > (except RSA-PSS with non-standard parameters) it is NULL, but I > don't think, this is a problem. Yep. > > ---------------------------------------------------------------------- > > For the hash truncation the method of > > X9.62, SEC1 and IO 14888-3 MUST be used. XXX Need reference for > > X9.62/SEC1 etchere XXX. > > ---------------------------------------------------------------------- > > > > I.e. the draft points to this hash truncation method. Does anybody > > have proper reference for that, and it might be good if we could > > summarize it here too, as not all people have access to those other > > specifications. > > I have been the one bringing up this issue, so I should comment on > this ;-) The issue is that ISO 15946-2 defines a different hash > truncation method. But actually, ISO 15946-2 is deprecated > (withdrawn) in favor of ISO 14888. Therefore, I don't think we need > to specify anything w.r.t hash truncation. It is now uniformly > defined in all current standards. So do you have any RFC that we can point to which specifies the hash truncation? If there ever has been two ways of doing things, I would like to point to some place where it is clear which way is used here, even when the other way has already been deprecated. > > In security considerations section I have text: > > ---------------------------------------------------------------------- > > The hash algorithm registry does not include MD5 as supported hash > > algorithm, as it is not considered safe enough for signature use. > > > > XXX Need reference for MD5 considered unsafe. XXX > > ---------------------------------------------------------------------- > > > > Does anybody have good reference for MD5 especially with signatures > > (not with HMAC). > > > Wikipedia list a good reference: Xiaoyun Wang; Hongbo Yu (2005). > "How to Break MD5 and Other Hash Functions". Added that... > If you are looking for standards... NIST SP 800-57 does not list MD5 > as approved but does not explicitly mention it as ineligible. An > explicit caveat is included in ETSI TS 102 176-1 "Recently some new > attacks against hash function MD5 succeeded, it was shown that MD5 > is not collision resistant by constructing classes of messages-pairs > with the same hash value. Whereas the loss of collision resistance > does not imply that a pre-image or second pre-image can easier be > constructed, it is recommended to migrate to other hash functions, > if the collision resistance becomes weaker." However, this standard > is is from 2005 and focuses on Secure Electronic Signatures. Is this > a problem? I think the the "How to break MD5 ..." paper is good enough. > > > > In the security considerations section I also have: > > ---------------------------------------------------------------------- > > The current IKEv2 uses RSASSA-PKCS1-v1_5, and does not allow using > > newer padding methods like RSASSA-PSS. This new method allows using > > other padding methods. > > > > XXX Need reference for RSASSA-PSS vs RSASSA-PKCS1-v1_5 security. > > XXX > > ---------------------------------------------------------------------- > > > > RFC4055 says > > > > " The RSASSA-PSS signature algorithm is preferred over the PKCS #1 > > Version 1.5 signature algorithm. Although no attacks are known > > against PKCS #1 Version 1.5 signature algorithm, in the interest of > > increased robustness, RSASSA-PSS signature algorithm is recommended > > for eventual adoption, especially by new applications." > > > > Is this still the case, or do we have some reference which would point > > out why RSASSA-PSS is better.... Of course if we cannot support > > RSASSA-PSS with the this new method properly, this text in the > > security considerations section might not be needed... > > > There are attacks against implementations not checking for garbage > after the hash value when using public exponent e=3 (a very special > case, but the best attack I know of). > http://csrc.nist.gov/groups/ST/toolkit/documents/dss/RSAstatement_10-12-06.pdf > As permanent reference, this one is better: Ulrich Kuehn, Andrei > Pyshkin, Erik Tews, Ralf-Philipp Weinmann: Variants of > Bleichenbacher's Low-Exponent Attack on PKCS#1 RSA Signatures. > Proceedings of Sicherheit 2008, pp. 97-109. This just points the problems in the PKCS#1 RSA signatures, but does not mention anything about RSASSA-PSS. Anyway I added that reference as it points out reasons why RSASSA-PSS might be needed... > > > > In the security considerations section: > > ---------------------------------------------------------------------- > > XXX The text about the guidance how to select suitable hash > > functions is missing here. XXX > > ---------------------------------------------------------------------- > > > > I.e we need to guidance or references to good guidance. As this draft > > is no longer only ECDSA, the RFC5480 might not be enough. For RSA, or > > normal DSA might also need some guidance. What kind of guidance do we > > want here. > > > > NIST SP 800-57, Tables 2 in combination with Table 3. It seems that > RFC 4055 also point to an early draft of NIST SP 800-57. Added following text: The "Recommendations for Key Management" ([NIST800-57]) table 2 combined with table 3 gives recommendations for how to select suitable hash functions for the signature. -- kivinen@iki.fi From kivinen@iki.fi Fri Dec 7 06:04:26 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14EB521F85B2 for ; Fri, 7 Dec 2012 06:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-77KVXWAnw4 for ; Fri, 7 Dec 2012 06:04:25 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 30E6921F8532 for ; Fri, 7 Dec 2012 06:04:24 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qB7E3wfY016986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Dec 2012 16:03:58 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qB7E3tv0011116; Fri, 7 Dec 2012 16:03:55 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20673.63307.890415.254854@fireball.kivinen.iki.fi> Date: Fri, 7 Dec 2012 16:03:55 +0200 From: Tero Kivinen To: Johannes Merkle In-Reply-To: <50C1CA50.3020703@secunet.com> References: <50B8A287.9090509@secunet.com> <074557eff2f722f10198aac4fb2f8d9c.squirrel@www.trepanning.net> <4613980CFC78314ABFD7F85CC30277210EDCE571@IL-EX10.ad.checkpoint.com> <50B9DC95.80202@gmail.com> <50BA5A70.6030808@gmail.com> <50BC8460.9030808@secunet.com> <20668.40826.934312.605279@fireball.kivinen.iki.fi> <50C1CA50.3020703@secunet.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 2 min Cc: Manfred Lochter , Yoav Nir , Dan Harkins , IPsecme WG , "rfc-ise@rfc-editor.org" , "Scott Fluhrer \(sfluhrer\)" , "Sean P. Turner" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 14:04:26 -0000 Johannes Merkle writes: > > I think it would be best to take the ECDH processing rules (mostly > > from 5903 but also add the checks if those are needed) and create new > > RFC that will update 5996. This document should not include any > > groups. > > > I assume that my draft should refer to this RFC-to-be, right? Most certainly, if we can agree to make such RFC, and get it published fast enough. The question is, whether there is enough interest to make such RFC, and who would be willing to work on such document. -- kivinen@iki.fi From lberger@labn.net Fri Dec 7 06:20:40 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA3221F8925 for ; Fri, 7 Dec 2012 06:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.933 X-Spam-Level: X-Spam-Status: No, score=-101.933 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOJ+ZLtzmWDd for ; Fri, 7 Dec 2012 06:20:39 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 16EAE21F860F for ; Fri, 7 Dec 2012 06:20:39 -0800 (PST) Received: (qmail 9502 invoked by uid 0); 7 Dec 2012 14:20:04 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 7 Dec 2012 14:20:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=yxMqSiYlG9X/rlbBXdCOBJ11h5MG9Yd5SrIcyXhprcc=; b=j474Dp0sDSPLIrealkONcKF4QjCF1UUGPGfdGDVUNyN27GbTjLqxSTFGNg3OJgm5DixU6dmjSU9K2DPTk4ffrntG+4YkgrSnXejn28vapJ+MsTQMxeD2INEs9YrOQdCx; Received: from box313.bluehost.com ([69.89.31.113]:57000 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TgymZ-0008FT-KR; Fri, 07 Dec 2012 07:20:03 -0700 Message-ID: <50C1FB15.4050301@labn.net> Date: Fri, 07 Dec 2012 09:20:05 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Vishwas Manral References: <50A5703F.4070305@labn.net> <50A689A9.1090803@labn.net> <50A68D30.2040203@labn.net> <50BE30D9.4030903@labn.net> <50BE4A60.1000303@labn.net> <50BFA4C0.1060909@labn.net> <50BFCA9A.4030502@labn.net> <50C0EEE9.7000904@labn.net> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: IPsecme WG Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 14:20:40 -0000 Vishwas, Much thanks! I think we're almost there. The sole remaining item is the last sentence of 4.1 requirement 3: Routing using the tunnels SHOULD work seamlessly without any updates to the higher level application configuration i.e. OSPF configuration, when the tunnel parameter changes. Per my previous message, I read this as a requirement being placed on the higher level protocol, but I believe your intent was on the solution. How about rephrasing along the lines of a requirement on the ADVPN solution? Perhaps something like: The ADVPN solution SHOULD NOT increase the amount of information required to configure protocols running over IPsec tunnels. Lou On 12/6/2012 6:53 PM, Vishwas Manral wrote: > Here finally!!! Sorry about the duplicate mails. > > -Vishwas > > On Thu, Dec 6, 2012 at 3:52 PM, Vishwas Manral > wrote: > > Sorry. Here it is with the right file. > > -Vishwas > > > On Thu, Dec 6, 2012 at 3:51 PM, Vishwas Manral > > wrote: > > Hi Lou, > > Here is the latest draft, with all your comments incorporated. > > I will post the draft soon. > > Thanks, > Vishwas > > > > On Thu, Dec 6, 2012 at 11:15 AM, Lou Berger > wrote: > > > Vishwas, > > I think I see where you're headed. > > The text under discussion is: > > Routing using the tunnels SHOULD work > seamlessly without any updates to the higher level > application > configuration i.e. OSPF configuration, when the tunnel > parameter > changes. > > I read this a requirement being placed on the higher level > protocol, but > I believe your intent was on the solution. How about > rephrasing along > the lines of a requirement on the ADVPN solution? Perhaps > something like: > > The ADVPN solution SHOULD NOT increase the amount of > information > required to configure protocols running over IPsec tunnels. > > Lou > > On 12/6/2012 1:55 PM, Vishwas Manral wrote: > > Hi Lou, > > > > I have included the other comments. The last one remaining is: > > > > > VM> I think this is an important requirement. A > tunnel should be > > able to > > > provide an interface by which when tunnel IP > parameters change we > > do not > > > have to change any configuration for higher > application like > > Routing. I > > > had earlier mentioned in more generic terms earlier > but changed to the > > > terms provided based on feedback from the list. > > > > What higher level protocols like most routing > protocols that use the > > tunnel interface IP addresses in operation? > > > > > > > > The entire idea is the with scale configuration > needs to be > > reduced and > > > that needs to happen across layers, so every layer > needs to > > provide the > > > service. Let me know what it is I am unable to convey. > > > > sure, but I think you're placing new requirements on > the routing & > > tunneling protocols. > > > > VM> There are no restrictions on an application protocol > like Routing. > > The idea is that the lower needs to provide a > functionality, so that if > > required a higher layer can use it. There is no > restriction at all on > > the higher layer. Do let me know if that is clearer? > > > > Thanks, > > Vishwas > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From sfluhrer@cisco.com Fri Dec 7 06:28:19 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0CCC21F8A1B for ; Fri, 7 Dec 2012 06:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfkQFpx86U5o for ; Fri, 7 Dec 2012 06:28:19 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC3221F89AD for ; Fri, 7 Dec 2012 06:28:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=635; q=dns/txt; s=iport; t=1354890499; x=1356100099; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DScj/8i4u9Qc1ssoAJkq8JdQK7RtuUJzXM8CPBbNo8o=; b=XqlFrB0Nf3RZZsTHqu1hIJStFfZkAJiClOXa9Ue0f2oGNmgAAovUNarl pTq50YpPz6FaCmD1PX4x1qno6xvLh9CqqivQlS51WFmH1x5eK4PdClpfz yFxlTK4BxHbBFCbs8QMdwB0RLMQ9iap2pFtjT7NDGIYxS2pKLi3xF2+n9 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAFAIr8wVCtJXHA/2dsb2JhbABEhW64SRZzgh4BAQEEOj8MBAIBCBEEAQELFAkHMhQJCAIEDgUIiAnCTYw/g2JhA6ZNgnOCIg X-IronPort-AV: E=McAfee;i="5400,1158,6918"; a="150530840" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 07 Dec 2012 14:28:13 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qB7ESDEw031124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Dec 2012 14:28:13 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.203]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Fri, 7 Dec 2012 08:28:13 -0600 From: "Scott Fluhrer (sfluhrer)" To: Johannes Merkle Thread-Topic: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange Thread-Index: AQHNz/olcML1jJ9U4EC5RJIM/xfJWZgHG0cggAaTyQD//73eUA== Date: Fri, 7 Dec 2012 14:28:12 +0000 Message-ID: References: <50B8A287.9090509@secunet.com> <074557eff2f722f10198aac4fb2f8d9c.squirrel@www.trepanning.net> <4613980CFC78314ABFD7F85CC30277210EDCE571@IL-EX10.ad.checkpoint.com> <50B9DC95.80202@gmail.com> <50BA5A70.6030808@gmail.com> <50C1DF02.2030309@secunet.com> In-Reply-To: <50C1DF02.2030309@secunet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Manfred Lochter , Yoav Nir , Dan Harkins , IPsecme WG , "rfc-ise@rfc-editor.org" , "Sean P. Turner" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 14:28:19 -0000 Well, no; step 2 of the check is unnecessary for the standard IKE groups (1= , 2, 5, 14-18), and it is extremely expensive as written; and while there a= re optimizations possible, it's still not cheap. -----Original Message----- From: Johannes Merkle [mailto:johannes.merkle@secunet.com]=20 Sent: Friday, December 07, 2012 7:20 AM To: Scott Fluhrer (sfluhrer) Cc: Yaron Sheffer; Manfred Lochter; Yoav Nir; Dan Harkins; IPsecme WG; rfc-= ise@rfc-editor.org; Sean P. Turner Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Ex= change For MODP groups, we can just refer to RFC 2631, Section 2.1.5 From Johannes.Merkle@secunet.com Fri Dec 7 07:09:22 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4AE21F87D2 for ; Fri, 7 Dec 2012 07:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_PART_ALI=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7hRA3+l6Tu7 for ; Fri, 7 Dec 2012 07:09:21 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6502621F87D1 for ; Fri, 7 Dec 2012 07:09:21 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id CF21F1A007A; Fri, 7 Dec 2012 16:09:02 +0100 (CET) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id DB47D1A0081; Fri, 7 Dec 2012 16:08:56 +0100 (CET) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Dec 2012 16:09:14 +0100 Message-ID: <50C20699.7040902@secunet.com> Date: Fri, 07 Dec 2012 16:09:13 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Tero Kivinen References: <20121204135025.24091.3591.idtracker@ietfa.amsl.com> <20670.1967.744783.372876@fireball.kivinen.iki.fi> <50BE3CD3.3010304@secunet.com> <20673.62423.672402.859432@fireball.kivinen.iki.fi> In-Reply-To: <20673.62423.672402.859432@fireball.kivinen.iki.fi> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Dec 2012 15:09:14.0127 (UTC) FILETIME=[D1A369F0:01CDD48C] Cc: ipsec@ietf.org Subject: Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-signature-auth-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 15:09:22 -0000 >> >> If RSA-PSS keys are used then this should not be an issue. In this >> case the SPKI of the cert specifies the parameters to be used. > > Even in that case we need to say in this draft that the RSASSA-PSS > parameters are taken from the SPKI of the cert. If the SPKI includes > parameters, are those the only parameters that can be used with the > cert, i.e. does that mean that you cannot use any other hash than what > is speficied there (I am not familiar enough with RSASSA-PSS to know > how it works). Yes, restriction to the specified parameters is exactly the semantics of the parameter field of the SPKI. Section 1.2 of RFC 4055 states: When a certificate conveys an RSA public key with the id-RSASSA-PSS object identifier, the certificate user MUST only use the certified RSA public key for RSASSA-PSS operations, and, if RSASSA-PSS-params is present, the certificate user MUST perform those operations using the one-way hash function, mask generation function, and trailer field identified in the subject public key algorithm identifier parameters within the certificate. > >> However, RSA-PSS keys are hardly supported yet. If the SPKI includes >> just an rsaEncryption OID, there are several problems: >> - A peer with an RSA signing key supporting RSA-PSS has no means to >> determine if the other peer supports PSS as well or if he should >> better fall back to PKCS#1v1.5. At least he can find out with trial >> and error. > > Or by configuration / policy. I.e. if the policy says RSASSA-PSS is to > be used, then it can be assumed it also works for those peers where > the policy requires it... > > I do not think this is going to be problem in general case. The IPsec > configuration usually have quite a lot of all kind of configuration / > policy information in both ends and some of those needs to match. > Agreed. Still it could be useful to hint to this potential issue. >> - When verifying a RSA-PSS signature based on a certificate >> specifying rsaEncryption in SPKI, additional information on the >> parameters used are needed. > > But the problem is when you do know from the configuration that other > end do support RSASSA-PSS, and you can see the supported hash > functions from the SIGNATURE_HASH_ALGORITHMs, but you do not know > which hash function the other end uses, as the RSASSA-PSS oid does not > include it... I think that is much bigger problem. > This is just part of the problem I referred to: The hash function used as message digest is part of the parameters. The parameters consist of 4 parts, for many of which recommendations exist in RFC 4055: 1. HashAlgorithm is the hash function used for computing the message digest. In contrast to PKCS#v1.5 the hash function is applied twice, first only to the message, the to the resulting hash concatenated with a fixed padding and a salt. 2. maskGenAlgorithm is the mask generating function for computing the padding. RFC 4055 only support the MFG-1 construction based on SHA-1 or SHA-2. RFC 4055 strongly recommends that the underlying hash function of MFG-1 be the same as the one identified by hashAlgorithm. I.e., when following this recommendation, the maskGenAlgorithm is uniquely defined by HashAlgorithm. 3. saltLength. Although RFC 4055 specifies a default length of 20 octets, it recommends that saltLength is the number of octets in the hash value. I.e., when following this recommendation, the saltLength is uniquely defined by HashAlgorithm. 4. trailerField. RFC 4055 requires it to be 0xBC. So, there is also no choice left. Thus, when following the recommendations of RFC 4055, there are only 5 parameter sets left: Set1: (SHA-1, mgf1SHA1Identifier, 20, 0xBC) Set2: (SHA-224, mgf1SHA224Identifier, 28, 0xBC) Set3: (SHA-256, mgf1SHA256Identifier, 32, 0xBC) Set4: (SHA-384, mgf1SHA384Identifier, 48, 0xBC) Set5: (SHA-512, mgf1SHA512Identifier, 64, 0xBC) I really wonder, why RFC 4055 has not defined simple OIDs for these 5 parameter combinations. This would make implementations limited to RFC 4055 recommended parameters much easier. And I really see no need to deviate from these recommendations. If we limit IKEv2 authentication with RSASSA-PSS to these sets, we could specify the missing OIDs and forget about the parameter field. Or we could ask the pkix WG if they are willing to issue an RFC defining these 5 OIDs for simplified use? > >>> ---------------------------------------------------------------------- >>> For the hash truncation the method of >>> X9.62, SEC1 and IO 14888-3 MUST be used. XXX Need reference for >>> X9.62/SEC1 etchere XXX. >>> ---------------------------------------------------------------------- >>> >>> I.e. the draft points to this hash truncation method. Does anybody >>> have proper reference for that, and it might be good if we could >>> summarize it here too, as not all people have access to those other >>> specifications. >> >> I have been the one bringing up this issue, so I should comment on >> this ;-) The issue is that ISO 15946-2 defines a different hash >> truncation method. But actually, ISO 15946-2 is deprecated >> (withdrawn) in favor of ISO 14888. Therefore, I don't think we need >> to specify anything w.r.t hash truncation. It is now uniformly >> defined in all current standards. > > So do you have any RFC that we can point to which specifies the hash > truncation? If there ever has been two ways of doing things, I would > like to point to some place where it is clear which way is used here, > even when the other way has already been deprecated. > I just looked it up in RFC 6090 and detected that there the hash value is _not truncated_, which is one more reason to clarify this in our draft. There is no RFC defining the ECDSA algorithm and most RFCs refer to ANSI X9.62. So this is the proper reference. >> There are attacks against implementations not checking for garbage >> after the hash value when using public exponent e=3 (a very special >> case, but the best attack I know of). >> http://csrc.nist.gov/groups/ST/toolkit/documents/dss/RSAstatement_10-12-06.pdf >> As permanent reference, this one is better: Ulrich Kuehn, Andrei >> Pyshkin, Erik Tews, Ralf-Philipp Weinmann: Variants of >> Bleichenbacher's Low-Exponent Attack on PKCS#1 RSA Signatures. >> Proceedings of Sicherheit 2008, pp. 97-109. > > This just points the problems in the PKCS#1 RSA signatures, but does > not mention anything about RSASSA-PSS. The reason why RSASSA-PSS is considered better is because there is a security proof (w.r.t adaptive chosen-message attacks) in the random oracle model. A good reference for a fair comparison with the conclusion that RSASSA-PSS is preferable is Alfred Menezes. Evaluation of Security Level of Cryptography: RSA-OAEP, RSA-PSS, RSA Signature. Technical Report, University of Waterloo, 2001 However, this paper is quite old and does not consider the latest attacks against the old padding method. -- Johannes From vishwas.ietf@gmail.com Fri Dec 7 09:51:14 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D49721F8925 for ; Fri, 7 Dec 2012 09:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9A5INFzXvSh for ; Fri, 7 Dec 2012 09:51:13 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id CD62A21F88C1 for ; Fri, 7 Dec 2012 09:51:10 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id z4so2134957qan.10 for ; Fri, 07 Dec 2012 09:51:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M3EJBUQYBrnNa1IBHsDIgZ3LkKhkA4PvVY8nHFh3oeM=; b=KZPL/IHc0YtTGXv1/FFU/Mg2Fmh1RSRbkWsqBPjHyI5lqjFbOZ6RvRcrML0VeSczdw Ue1NJYg+Rf4Jk13JcT9yoReYobr+Lf2Gc6DcJAijxNhNMFH76FWpZjSRjfvGu7ogEYBn UGLLkCU4bo2g8ZfH5L/l+3aRYqlxmz4I/xHRHq0o2vmtJdf9/Mh2Eifh7Sxtammz39JT sIPJZC4K04wek+8nzfWM3+zOemP+Mpsut6mk75A3aqWoMC6L8i9qB3LG7qE+tEZcwsk+ oqmFaNO4TyveeTycGN6edm7h4aYpQQhhNFyPJ3XwcA0VW+HY59HyDiE3BvvnIOE6hbIw JqAA== MIME-Version: 1.0 Received: by 10.49.73.105 with SMTP id k9mr11744423qev.6.1354902661469; Fri, 07 Dec 2012 09:51:01 -0800 (PST) Received: by 10.229.92.77 with HTTP; Fri, 7 Dec 2012 09:51:01 -0800 (PST) In-Reply-To: <50C1FB15.4050301@labn.net> References: <50A5703F.4070305@labn.net> <50A689A9.1090803@labn.net> <50A68D30.2040203@labn.net> <50BE30D9.4030903@labn.net> <50BE4A60.1000303@labn.net> <50BFA4C0.1060909@labn.net> <50BFCA9A.4030502@labn.net> <50C0EEE9.7000904@labn.net> <50C1FB15.4050301@labn.net> Date: Fri, 7 Dec 2012 09:51:01 -0800 Message-ID: From: Vishwas Manral To: Lou Berger Content-Type: multipart/alternative; boundary=047d7b67897cd794c804d046db2f Cc: IPsecme WG Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 17:51:14 -0000 --047d7b67897cd794c804d046db2f Content-Type: text/plain; charset=ISO-8859-1 Updated. Will post the document across. -Vishwas On Fri, Dec 7, 2012 at 6:20 AM, Lou Berger wrote: > The ADVPN solution SHOULD NOT increase the amount of information > required to configure protocols running over IPsec tunnels. > --047d7b67897cd794c804d046db2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Updated. Will post the document across.

-Vishwas

On Fri, Dec 7, 2012 at 6:20 AM, Lou Berger <lberger@labn.n= et> wrote:
The ADVPN solution SHOULD = NOT increase the amount of information
=A0 =A0required to configure protocols running over IPsec tunnels.

--047d7b67897cd794c804d046db2f-- From lberger@labn.net Fri Dec 7 10:57:30 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9F321F86E2 for ; Fri, 7 Dec 2012 10:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.994 X-Spam-Level: X-Spam-Status: No, score=-101.994 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXfp9k7IR712 for ; Fri, 7 Dec 2012 10:57:29 -0800 (PST) Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id 56EF121F864D for ; Fri, 7 Dec 2012 10:57:29 -0800 (PST) Received: (qmail 21916 invoked by uid 0); 7 Dec 2012 18:57:06 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy8.bluehost.com with SMTP; 7 Dec 2012 18:57:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=XSMFJlt9e2BnsnikSDVEVapoB9/wzG7kJS8+u04/oOI=; b=rVMGTD1WpsNaJd/3jmYY+FWlBZ4vUk7W9nrntrQW04HLkZie/tBpZPiZTZkjDdyrYrRa4Zk64RpE0i2IiZ7bv7Y/cB084qt0P13Sdf75nJcrdY3yvNYh6p8gC4VGqkZk; Received: from box313.bluehost.com ([69.89.31.113]:35668 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1Th36f-00059L-Nc; Fri, 07 Dec 2012 11:57:05 -0700 Message-ID: <50C23BFD.7080109@labn.net> Date: Fri, 07 Dec 2012 13:57:01 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Vishwas Manral References: <50A5703F.4070305@labn.net> <50A68D30.2040203@labn.net> <50BE30D9.4030903@labn.net> <50BE4A60.1000303@labn.net> <50BFA4C0.1060909@labn.net> <50BFCA9A.4030502@labn.net> <50C0EEE9.7000904@labn.net> <50C1FB15.4050301@labn.net> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: IPsecme WG Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 18:57:30 -0000 Excellent & thank you! Lou On 12/7/2012 12:51 PM, Vishwas Manral wrote: > Updated. Will post the document across. > > -Vishwas > > On Fri, Dec 7, 2012 at 6:20 AM, Lou Berger > wrote: > > The ADVPN solution SHOULD NOT increase the amount of information > required to configure protocols running over IPsec tunnels. > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From kivinen@iki.fi Mon Dec 10 06:55:04 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D487E21F84FD for ; Mon, 10 Dec 2012 06:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.766 X-Spam-Level: X-Spam-Status: No, score=-101.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, SARE_OBFU_PART_ALI=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40FNSe3a96mc for ; Mon, 10 Dec 2012 06:55:04 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 575A021F84FC for ; Mon, 10 Dec 2012 06:55:01 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qBAEstxO005063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Dec 2012 16:54:55 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qBAEssoS012817; Mon, 10 Dec 2012 16:54:54 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20677.63422.680431.678461@fireball.kivinen.iki.fi> Date: Mon, 10 Dec 2012 16:54:54 +0200 From: Tero Kivinen To: Johannes Merkle In-Reply-To: <50C20699.7040902@secunet.com> References: <20121204135025.24091.3591.idtracker@ietfa.amsl.com> <20670.1967.744783.372876@fireball.kivinen.iki.fi> <50BE3CD3.3010304@secunet.com> <20673.62423.672402.859432@fireball.kivinen.iki.fi> <50C20699.7040902@secunet.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 16 min X-Total-Time: 42 min Cc: ipsec@ietf.org Subject: Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-signature-auth-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 14:55:04 -0000 Johannes Merkle writes: > >> If RSA-PSS keys are used then this should not be an issue. In this > >> case the SPKI of the cert specifies the parameters to be used. > > > > Even in that case we need to say in this draft that the RSASSA-PSS > > parameters are taken from the SPKI of the cert. If the SPKI includes > > parameters, are those the only parameters that can be used with the > > cert, i.e. does that mean that you cannot use any other hash than what > > is speficied there (I am not familiar enough with RSASSA-PSS to know > > how it works). > > Yes, restriction to the specified parameters is exactly the > semantics of the parameter field of the SPKI. Section 1.2 of > RFC 4055 states: > When a certificate conveys an RSA public key with the id-RSASSA-PSS > object identifier, the certificate user MUST only use the certified > RSA public key for RSASSA-PSS operations, and, if RSASSA-PSS-params > is present, the certificate user MUST perform those operations using > the one-way hash function, mask generation function, and trailer > field identified in the subject public key algorithm identifier > parameters within the certificate. Ok, I should add pointer to that in my draft. What happens if the RSASSA-PSS-params is NOT present? Do we use defaults, or is the certificate user allowed to pick any hash/mask etc he feels like? If it can use any hash, then we still have problem as the receipient cannot know which hash the other end picked. Added following text to my draft: ---------------------------------------------------------------------- Note, that if the RSASSA-PSS is used, and if the public key is specified with id-RSASSA-PSS and there is RSASSA-PSS-params, then those params needs to be used as specified in the Section 1.2 of the RFC4055 ([RFC4055]). ---------------------------------------------------------------------- > > I do not think this is going to be problem in general case. The IPsec > > configuration usually have quite a lot of all kind of configuration / > > policy information in both ends and some of those needs to match. > > > > Agreed. Still it could be useful to hint to this potential issue. Yep. And I also want to add similar text to my raw public key draft, pointing out that if it is used to send RSASSA-PSS keys inside the SPKI of the raw key, then you still need to follow the RFC4055, even when the SPKI is not inside the Certificate payload. > >> - When verifying a RSA-PSS signature based on a certificate > >> specifying rsaEncryption in SPKI, additional information on the > >> parameters used are needed. > > > > But the problem is when you do know from the configuration that other > > end do support RSASSA-PSS, and you can see the supported hash > > functions from the SIGNATURE_HASH_ALGORITHMs, but you do not know > > which hash function the other end uses, as the RSASSA-PSS oid does not > > include it... I think that is much bigger problem. > > > This is just part of the problem I referred to: The hash function > used as message digest is part of the parameters. The parameters > consist of 4 parts, for many of which recommendations exist in RFC > 4055: > > 1. HashAlgorithm is the hash function used for computing the message > digest. In contrast to PKCS#v1.5 the hash function is applied twice, > first only to the message, the to the resulting hash concatenated > with a fixed padding and a salt. > > 2. maskGenAlgorithm is the mask generating function for computing > the padding. RFC 4055 only support the MFG-1 construction based on > SHA-1 or SHA-2. RFC 4055 strongly recommends that the underlying > hash function of MFG-1 be the same as the one identified by > hashAlgorithm. I.e., when following this recommendation, the > maskGenAlgorithm is uniquely defined by HashAlgorithm. > > 3. saltLength. Although RFC 4055 specifies a default length of 20 > octets, it recommends that saltLength is the number of octets in the > hash value. I.e., when following this recommendation, the saltLength > is uniquely defined by HashAlgorithm. > > 4. trailerField. RFC 4055 requires it to be 0xBC. So, there is also > no choice left. And in future there might be update to the RFC 4055, which adds new hash functions to it... > Thus, when following the recommendations of RFC 4055, there are only > 5 parameter sets left: > Set1: (SHA-1, mgf1SHA1Identifier, 20, 0xBC) > Set2: (SHA-224, mgf1SHA224Identifier, 28, 0xBC) > Set3: (SHA-256, mgf1SHA256Identifier, 32, 0xBC) > Set4: (SHA-384, mgf1SHA384Identifier, 48, 0xBC) > Set5: (SHA-512, mgf1SHA512Identifier, 64, 0xBC) > > I really wonder, why RFC 4055 has not defined simple OIDs for these > 5 parameter combinations. This would make implementations limited to > RFC 4055 recommended parameters much easier. And I really see no > need to deviate from these recommendations. If we limit IKEv2 > authentication with RSASSA-PSS to these sets, we could specify the > missing OIDs and forget about the parameter field. Or we could ask > the pkix WG if they are willing to issue an RFC defining these 5 > OIDs for simplified use? Or we can simply add the whole AlgorithmIdentifier sequence, which would include the OID and parameters in front the signature, and that will also take care of the problem. > > So do you have any RFC that we can point to which specifies the hash > > truncation? If there ever has been two ways of doing things, I would > > like to point to some place where it is clear which way is used here, > > even when the other way has already been deprecated. > > > > I just looked it up in RFC 6090 and detected that there the hash > value is _not truncated_, which is one more reason to clarify this > in our draft. There is no RFC defining the ECDSA algorithm and most > RFCs refer to ANSI X9.62. So this is the proper reference. Ok, added: ---------------------------------------------------------------------- For the hash truncation the method of X9.62 ([X9.62]) MUST be used. ... [X9.62] American National Standards Institute, "Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62, November 2005. ---------------------------------------------------------------------- > >> There are attacks against implementations not checking for garbage > >> after the hash value when using public exponent e=3 (a very special > >> case, but the best attack I know of). > >> http://csrc.nist.gov/groups/ST/toolkit/documents/dss/RSAstatement_10-12-06.pdf > >> As permanent reference, this one is better: Ulrich Kuehn, Andrei > >> Pyshkin, Erik Tews, Ralf-Philipp Weinmann: Variants of > >> Bleichenbacher's Low-Exponent Attack on PKCS#1 RSA Signatures. > >> Proceedings of Sicherheit 2008, pp. 97-109. > > > > This just points the problems in the PKCS#1 RSA signatures, but does > > not mention anything about RSASSA-PSS. > > The reason why RSASSA-PSS is considered better is because there is a > security proof (w.r.t adaptive chosen-message attacks) in the random > oracle model. A good reference for a fair comparison with the > conclusion that RSASSA-PSS is preferable is Alfred Menezes. > Evaluation of Security Level of Cryptography: RSA-OAEP, RSA-PSS, RSA > Signature. Technical Report, University of Waterloo, 2001 However, > this paper is quite old and does not consider the latest attacks > against the old padding method. Added that ---------------------------------------------------------------------- The current IKEv2 uses RSASSA-PKCS1-v1_5, which do have some problems ([KA08], [ME01]) and does not allow using newer padding methods like RSASSA-PSS. This new method allows using other padding methods. ... [KA08] Kuehn, U., Pyshkin, A., Tews, E., and R. Weinmann, "Variants of Bleichenbacher's Low-Exponent Attack on PKCS#1 RSA Signatures", Proc. Sicherheit 2008 pp.97-109. [ME01] Menezes, A., "Evaluation of Security Level of Cryptography: RSA-OAEP, RSA-PSS, RSA Signature", December 2001. -- kivinen@iki.fi From yaronf.ietf@gmail.com Mon Dec 10 10:44:07 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDB021F856B for ; Mon, 10 Dec 2012 10:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aOZlDlXV5qX for ; Mon, 10 Dec 2012 10:44:07 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1264921F8555 for ; Mon, 10 Dec 2012 10:43:58 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so1329963bku.31 for ; Mon, 10 Dec 2012 10:43:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=23ub+X1N4hFSnEJM8ol4rxHdhkfYLM8bLcJvqgb3yuE=; b=u01OOqzg+k1snbca92UNaPfh6fZUw/TgCxdTdTGHeQYADeR0yzgyUfCtgB/+X43RfY DflQhcf8R28d3KZKGApDayeLLST1pyc39uuA04NKkevnkUTMfzVwJm/TGAxaXWw+6t5v Vm2f1rhG1XsJ46DOVWjoc9QshF5ptBdtcWe5Ss+ty2HuCapzezLnRtYX41DsBCjhH4qn 5az6R+jeH8qv9n7laC7imBHskoAti+loxztVqlS4sdUEaOAW00WFSugZ/jI+AMp7DMOQ QyhZjhfId1wJN4HxRVRDP8R1Js9AOSvrnPEktRJ4kIAlJQVxSuQfCsbydNYdTgxTQSHu FC1g== Received: by 10.204.147.139 with SMTP id l11mr5022066bkv.46.1355165038205; Mon, 10 Dec 2012 10:43:58 -0800 (PST) Received: from [10.0.0.3] (bzq-79-180-163-165.red.bezeqint.net. [79.180.163.165]) by mx.google.com with ESMTPS id d16sm14979820bkw.2.2012.12.10.10.43.56 (version=SSLv3 cipher=OTHER); Mon, 10 Dec 2012 10:43:57 -0800 (PST) Message-ID: <50C62D6A.8010709@gmail.com> Date: Mon, 10 Dec 2012 20:43:54 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] New draft on IKE Diffie-Hellman checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 18:44:07 -0000 Hi, following the recent discussion on the mailing list, Scott Fluhrer and myself just published a draft that updates RFC 5996 by adding the required recipient-side tests for ECDH. Please see http://www.ietf.org/internet-drafts/draft-sheffer-ipsecme-dh-checks-00.txt. We have not addressed the issues raised by Dan and Tero regarding inconsistencies between various RFCs that define ECDH groups for IKE. I personally deem these issues to be out of scope of the current document. Comments are very welcome. Thanks, Yaron From hugokraw@gmail.com Mon Dec 10 11:50:49 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B1221F860A for ; Mon, 10 Dec 2012 11:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoqOgDbtIYPY for ; Mon, 10 Dec 2012 11:50:48 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2669F21F85EA for ; Mon, 10 Dec 2012 11:50:48 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so3167932vcb.31 for ; Mon, 10 Dec 2012 11:50:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=8of+Mji61BZH/jXMukofDoAO6GzD0G5BcggmGbajfXA=; b=C6cdpl3wD7ldx8hj7Ygdang/jiDjIJoeE9PPBlMmKpOt63eYBrpaqqGKhKDqKqHW0M /10tbtlH7ZuPloP+fwWWQ3DeKmi6qYAfXkDUHvkt2bcRrSA5kk/KM3otRiANMBkOYbB7 0rf/wdbP30ECXK/dop18iKo+lYdarfnt8/KgWc1FWQ7PqIurWOIlsvebIDAGvDvmKJhf e+TcQ5xaI2+YmSal4vH7DPuwdHDkss/31o7OLwTdnwpqi5szSQTAHA4tJcKceHPf1BE7 LXe1WqZ5/EZbvtGpABfs2gVaVXvDQmCI3fG1KDy/JW2DTd3oKePwgT5xwxFKxKswotJv uZww== Received: by 10.58.64.51 with SMTP id l19mr10019172ves.15.1355169047524; Mon, 10 Dec 2012 11:50:47 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.58.29.50 with HTTP; Mon, 10 Dec 2012 11:50:27 -0800 (PST) In-Reply-To: <50C62D6A.8010709@gmail.com> References: <50C62D6A.8010709@gmail.com> From: Hugo Krawczyk Date: Mon, 10 Dec 2012 14:50:27 -0500 X-Google-Sender-Auth: E2zJyVXIz8GOLI6Q93kWMs-PW6I Message-ID: To: Yaron Sheffer Content-Type: multipart/alternative; boundary=047d7b6d8102b033ae04d084e1c4 Cc: IPsecme WG Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 19:50:49 -0000 --047d7b6d8102b033ae04d084e1c4 Content-Type: text/plain; charset=UTF-8 The tests in sections 2.1 and 2.3 are cheap and can serve as sanity checks for an implementation as stated in the draft, even if DH is not reused. On the other hand, the test in 2.2 is expensive, equivalent to a group exponentiation, and therefore should not be recommended without DH re-use (in which case the test is an expensive waste). Actually, the right recommendation (or MUST) for 2.2 groups is NOT to reuse DH values. Indeed, the reason to reuse DH is to save an exponentiation but if you do so you pay with an extra exponentiation for the membership test. Moreover, while the exponentiation you are saving can be performed offline (before the run of the IKE session), the group membership test is online, so either way it makes no sense to reuse the DH exponents. By the way, if you forbid re-use, you need to actually mandate fresh exponents with each session (otherwise, an implementation maybe tempted to avoid re-use by using g^x, g^{x+1}, g^{x+2}, etc.) Hugo On Mon, Dec 10, 2012 at 1:43 PM, Yaron Sheffer wrote: > Hi, > > following the recent discussion on the mailing list, Scott Fluhrer and > myself just published a draft that updates RFC 5996 by adding the required > recipient-side tests for ECDH. Please see http://www.ietf.org/internet-** > drafts/draft-sheffer-ipsecme-**dh-checks-00.txt > . > > We have not addressed the issues raised by Dan and Tero regarding > inconsistencies between various RFCs that define ECDH groups for IKE. I > personally deem these issues to be out of scope of the current document. > > Comments are very welcome. > > Thanks, > Yaron > > ______________________________**_________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/**listinfo/ipsec > --047d7b6d8102b033ae04d084e1c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The tests in sections 2.1 and 2.3 a= re cheap and can serve as sanity checks for an implementation as stated in = the draft, even if DH is not reused.

On the other hand, the test in = 2.2 is expensive, equivalent to a group exponentiation, and therefore shoul= d not be recommended without DH re-use (in which case the test is an expens= ive waste).

Actually, the right recommendation (or MUST) for 2.2 groups is NOT to reuse DH values.
Indeed, the reason t= o reuse DH is to save an exponentiation but if you do so you pay with an ex= tra exponentiation for the membership test. Moreover, while the exponentiat= ion you are saving can be performed offline (before the run of the IKE sess= ion), the group membership test is online, so either way it makes no sense = to reuse the DH exponents.
By the way, if you forbid re-use, you need to actually mandate fresh expone= nts with each session (otherwise, an implementation maybe tempted to avoid = re-use by using g^x, g^{x+1}, g^{x+2}, etc.)
=C2=A0
Hugo

On Mon, Dec 10, 2012 at 1:43 PM, Yaron Sheffer <= span dir=3D"ltr"><yaronf.ietf@gmail.com> wrote:
Hi,

following the recent discussion on the mailing list, Scott Fluhrer and myse= lf just published a draft that updates RFC 5996 by adding the required reci= pient-side tests for ECDH. Please see http://= www.ietf.org/internet-drafts/draft-sheffer-ipsecme-dh-checks-= 00.txt.

We have not addressed the issues raised by Dan and Tero regarding inconsist= encies between various RFCs that define ECDH groups for IKE. I personally d= eem these issues to be out of scope of the current document.

Comments are very welcome.

Thanks,
=C2=A0 =C2=A0 Yaron

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

--047d7b6d8102b033ae04d084e1c4-- From sfluhrer@cisco.com Mon Dec 10 13:53:41 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A1C21F8558 for ; Mon, 10 Dec 2012 13:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S50TVeVjOoZY for ; Mon, 10 Dec 2012 13:53:40 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8186C21F8534 for ; Mon, 10 Dec 2012 13:53:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13050; q=dns/txt; s=iport; t=1355176418; x=1356386018; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=38Rq/8yOBp9V/TEo6jLptGps9Ib8Jh9fb+nUwISaGmI=; b=f25t22lQ9xqNjF0pFUkk6rwxVpv0aM9SZldAWMxbTrKyEyjKdsEE8rFg PSG1c+PmAup1k/i9+gcbdR0H8LdAqf8hfgIvkXPpAfZ3RBU2uiMPLd7rn P8lQmD26kBe0to32d3IyTp3efl8hgQtQBfZIDWMt3Gjbli/aKU1fx5Pdp g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAOxYxlCtJXHB/2dsb2JhbABFDoI7g263N3MWc4IeAQEBBAEBASAKQQsQAgEIEQQBAQsdAwICAh8GCxQJCAIEAQ0FCAGHdgMPDKVOiHUNiVSLVmmDMDJhA5QwjQ2FEYI1PoIi X-IronPort-AV: E=McAfee;i="5400,1158,6922"; a="151404788" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 10 Dec 2012 21:53:37 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBALrbt0004377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Dec 2012 21:53:37 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.29]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Mon, 10 Dec 2012 15:53:37 -0600 From: "Scott Fluhrer (sfluhrer)" To: Hugo Krawczyk , Yaron Sheffer Thread-Topic: [IPsec] New draft on IKE Diffie-Hellman checks Thread-Index: AQHN1wZaPpZNcIh600ewXpvuWaXH0pgS1byA//+wE6A= Date: Mon, 10 Dec 2012 21:53:36 +0000 Message-ID: References: <50C62D6A.8010709@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.86] Content-Type: multipart/alternative; boundary="_000_A113ACFD9DF8B04F96395BDEACB340421E4BE9xmbrcdx04ciscocom_" MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 21:53:41 -0000 --_000_A113ACFD9DF8B04F96395BDEACB340421E4BE9xmbrcdx04ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppcHNlYy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgSHVnbyBLcmF3Y3p5aw0KU2VudDogTW9uZGF5LCBEZWNlbWJl ciAxMCwgMjAxMiAyOjUwIFBNDQpUbzogWWFyb24gU2hlZmZlcg0KQ2M6IElQc2VjbWUgV0cNClN1 YmplY3Q6IFJlOiBbSVBzZWNdIE5ldyBkcmFmdCBvbiBJS0UgRGlmZmllLUhlbGxtYW4gY2hlY2tz DQoNClRoZSB0ZXN0cyBpbiBzZWN0aW9ucyAyLjEgYW5kIDIuMyBhcmUgY2hlYXAgYW5kIGNhbiBz ZXJ2ZSBhcyBzYW5pdHkgY2hlY2tzIGZvciBhbiBpbXBsZW1lbnRhdGlvbiBhcyBzdGF0ZWQgaW4g dGhlIGRyYWZ0LCBldmVuIGlmIERIIGlzIG5vdCByZXVzZWQuDQoNCk9uIHRoZSBvdGhlciBoYW5k LCB0aGUgdGVzdCBpbiAyLjIgaXMgZXhwZW5zaXZlLCBlcXVpdmFsZW50IHRvIGEgZ3JvdXAgZXhw b25lbnRpYXRpb24sIGFuZCB0aGVyZWZvcmUgc2hvdWxkIG5vdCBiZSByZWNvbW1lbmRlZCB3aXRo b3V0IERIIHJlLXVzZSAoaW4gd2hpY2ggY2FzZSB0aGUgdGVzdCBpcyBhbiBleHBlbnNpdmUgd2Fz dGUpLg0KDQpBY3R1YWxseSwgdGhlIHJpZ2h0IHJlY29tbWVuZGF0aW9uIChvciBNVVNUKSBmb3Ig Mi4yIGdyb3VwcyBpcyBOT1QgdG8gcmV1c2UgREggdmFsdWVzLg0KSW5kZWVkLCB0aGUgcmVhc29u IHRvIHJldXNlIERIIGlzIHRvIHNhdmUgYW4gZXhwb25lbnRpYXRpb24gYnV0IGlmIHlvdSBkbyBz byB5b3UgcGF5IHdpdGggYW4gZXh0cmEgZXhwb25lbnRpYXRpb24gZm9yIHRoZSBtZW1iZXJzaGlw IHRlc3QuIE1vcmVvdmVyLCB3aGlsZSB0aGUgZXhwb25lbnRpYXRpb24geW91IGFyZSBzYXZpbmcg Y2FuIGJlIHBlcmZvcm1lZCBvZmZsaW5lIChiZWZvcmUgdGhlIHJ1biBvZiB0aGUgSUtFIHNlc3Np b24pLCB0aGUgZ3JvdXAgbWVtYmVyc2hpcCB0ZXN0IGlzIG9ubGluZSwgc28gZWl0aGVyIHdheSBp dCBtYWtlcyBubyBzZW5zZSB0byByZXVzZSB0aGUgREggZXhwb25lbnRzLg0KSSBjYW5ub3QgZGlz YWdyZWUgd2l0aCBhbnl0aGluZyB5b3Ugc2F5LiAgSG93ZXZlciwgdGhlIHJlYWwgcmVhc29uIHRo ZSAyLjIgZ3JvdXBzICgyMiwgMjMsIDI0KSBleGlzdCBpcyB0aGUgb3RoZXIgTU9EUCBncm91cHMg ZG8gbm90IGNvbmZvcm0gdG8gTklTVCBTUCA4MDAtNTZBIChzZWUgc2VjdGlvbiA1LjUuMS4xKS4g IEFuZCwgU1AgODAwLTU2QSBhbHNvIG1hbmRhdGVzIHRoZSBjaGVja3Mgd2UgcmVjb21tZW5kIChz ZWN0aW9uIDUuNi4yLjQpLg0KVGhhdCBpcywgaWYgeW91IGFyZSBpbXBsZW1lbnRpbmcgKHNheSkg Z3JvdXAgMjQgc3BlY2lmaWNhbGx5IGZvciBjb25mb3JtYW5jZSByZWFzb25zLCB5b3XigJlyZSBn b2luZyB0byBkbyB0aGF0IHRlc3QgYW55d2F5cyAoeWVzLCBpdCBtYXkgYmUgYW4gZXhwZW5zaXZl IHdhc3RlIGZvciBjcnlwdG9ncmFwaGljYWwgcmVhc29ucywgaG93ZXZlciwgaXQgaXNu4oCZdCBm b3IgY29uZm9ybWFuY2UgcmVhc29ucykuICBJbiB0aGF0IHNjZW5hcmlvLCBESCByZXVzZSBkb2Vz IG1ha2Ugc2Vuc2UgKGJlY2F1c2Ugbm90IGRvaW5nIERIIHJldXNlIGRvZXNu4oCZdCBsZXQgeW91 IGVsaW1pbmF0ZSB0aGUgdGVzdCkuDQpJIHdvdWxkIGFncmVlIHRoYXQgbWF5YmUgd2UgbmVlZCB0 byBleHRlbmQgdGhlIGRyYWZ0IHRvIGRpc2N1c3MgdGhlc2Ugbm9uY3J5cHRvZ3JhcGhpY2FsIGlz c3Vlcy4NCg0KDQpCeSB0aGUgd2F5LCBpZiB5b3UgZm9yYmlkIHJlLXVzZSwgeW91IG5lZWQgdG8g YWN0dWFsbHkgbWFuZGF0ZSBmcmVzaCBleHBvbmVudHMgd2l0aCBlYWNoIHNlc3Npb24gKG90aGVy d2lzZSwgYW4gaW1wbGVtZW50YXRpb24gbWF5YmUgdGVtcHRlZCB0byBhdm9pZCByZS11c2UgYnkg dXNpbmcgZ154LCBnXnt4KzF9LCBnXnt4KzJ9LCBldGMuKQ0KDQpIdWdvDQpPbiBNb24sIERlYyAx MCwgMjAxMiBhdCAxOjQzIFBNLCBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5jb208 bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KSGksDQoNCmZvbGxvd2luZyB0 aGUgcmVjZW50IGRpc2N1c3Npb24gb24gdGhlIG1haWxpbmcgbGlzdCwgU2NvdHQgRmx1aHJlciBh bmQgbXlzZWxmIGp1c3QgcHVibGlzaGVkIGEgZHJhZnQgdGhhdCB1cGRhdGVzIFJGQyA1OTk2IGJ5 IGFkZGluZyB0aGUgcmVxdWlyZWQgcmVjaXBpZW50LXNpZGUgdGVzdHMgZm9yIEVDREguIFBsZWFz ZSBzZWUgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc2hlZmZlci1p cHNlY21lLWRoLWNoZWNrcy0wMC50eHQuDQoNCldlIGhhdmUgbm90IGFkZHJlc3NlZCB0aGUgaXNz dWVzIHJhaXNlZCBieSBEYW4gYW5kIFRlcm8gcmVnYXJkaW5nIGluY29uc2lzdGVuY2llcyBiZXR3 ZWVuIHZhcmlvdXMgUkZDcyB0aGF0IGRlZmluZSBFQ0RIIGdyb3VwcyBmb3IgSUtFLiBJIHBlcnNv bmFsbHkgZGVlbSB0aGVzZSBpc3N1ZXMgdG8gYmUgb3V0IG9mIHNjb3BlIG9mIHRoZSBjdXJyZW50 IGRvY3VtZW50Lg0KDQpDb21tZW50cyBhcmUgdmVyeSB3ZWxjb21lLg0KDQpUaGFua3MsDQogICAg WWFyb24NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CklQc2VjIG1haWxpbmcgbGlzdA0KSVBzZWNAaWV0Zi5vcmc8bWFpbHRvOklQc2VjQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYw0KDQo= --_000_A113ACFD9DF8B04F96395BDEACB340421E4BE9xmbrcdx04ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1 IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gaXBzZWMtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmlwc2VjLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPkh1Z28gS3Jhd2N6eWs8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBEZWNlbWJl ciAxMCwgMjAxMiAyOjUwIFBNPGJyPg0KPGI+VG86PC9iPiBZYXJvbiBTaGVmZmVyPGJyPg0KPGI+ Q2M6PC9iPiBJUHNlY21lIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSVBzZWNdIE5ldyBk cmFmdCBvbiBJS0UgRGlmZmllLUhlbGxtYW4gY2hlY2tzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZSB0ZXN0 cyBpbiBzZWN0aW9ucyAyLjEgYW5kIDIuMyBhcmUgY2hlYXAgYW5kIGNhbiBzZXJ2ZSBhcyBzYW5p dHkgY2hlY2tzIGZvciBhbiBpbXBsZW1lbnRhdGlvbiBhcyBzdGF0ZWQgaW4gdGhlIGRyYWZ0LCBl dmVuIGlmIERIIGlzIG5vdCByZXVzZWQuPGJyPg0KPGJyPg0KT24gdGhlIG90aGVyIGhhbmQsIHRo ZSB0ZXN0IGluIDIuMiBpcyBleHBlbnNpdmUsIGVxdWl2YWxlbnQgdG8gYSBncm91cCBleHBvbmVu dGlhdGlvbiwgYW5kIHRoZXJlZm9yZSBzaG91bGQgbm90IGJlIHJlY29tbWVuZGVkIHdpdGhvdXQg REggcmUtdXNlIChpbiB3aGljaCBjYXNlIHRoZSB0ZXN0IGlzIGFuIGV4cGVuc2l2ZSB3YXN0ZSku DQo8YnI+DQo8YnI+DQpBY3R1YWxseSwgdGhlIHJpZ2h0IHJlY29tbWVuZGF0aW9uIChvciBNVVNU KSBmb3IgMi4yIGdyb3VwcyBpcyBOT1QgdG8gcmV1c2UgREggdmFsdWVzLg0KPGJyPg0KSW5kZWVk LCB0aGUgcmVhc29uIHRvIHJldXNlIERIIGlzIHRvIHNhdmUgYW4gZXhwb25lbnRpYXRpb24gYnV0 IGlmIHlvdSBkbyBzbyB5b3UgcGF5IHdpdGggYW4gZXh0cmEgZXhwb25lbnRpYXRpb24gZm9yIHRo ZSBtZW1iZXJzaGlwIHRlc3QuIE1vcmVvdmVyLCB3aGlsZSB0aGUgZXhwb25lbnRpYXRpb24geW91 IGFyZSBzYXZpbmcgY2FuIGJlIHBlcmZvcm1lZCBvZmZsaW5lIChiZWZvcmUgdGhlIHJ1biBvZiB0 aGUgSUtFIHNlc3Npb24pLCB0aGUgZ3JvdXANCiBtZW1iZXJzaGlwIHRlc3QgaXMgb25saW5lLCBz byBlaXRoZXIgd2F5IGl0IG1ha2VzIG5vIHNlbnNlIHRvIHJldXNlIHRoZSBESCBleHBvbmVudHMu PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGNhbm5vdCBkaXNhZ3JlZSB3 aXRoIGFueXRoaW5nIHlvdSBzYXkuJm5ic3A7IEhvd2V2ZXIsIHRoZSByZWFsIHJlYXNvbiB0aGUg Mi4yIGdyb3VwcyAoMjIsIDIzLCAyNCkgZXhpc3QgaXMgdGhlIG90aGVyIE1PRFAgZ3JvdXBzIGRv DQogbm90IGNvbmZvcm0gdG8gTklTVCBTUCA4MDAtNTZBIChzZWUgc2VjdGlvbiA1LjUuMS4xKS4m bmJzcDsgQW5kLCBTUCA4MDAtNTZBIGFsc28gbWFuZGF0ZXMgdGhlIGNoZWNrcyB3ZSByZWNvbW1l bmQgKHNlY3Rpb24gNS42LjIuNCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhdCBpcywgaWYgeW91IGFyZSBpbXBsZW1lbnRpbmcg KHNheSkgZ3JvdXAgMjQgc3BlY2lmaWNhbGx5IGZvciBjb25mb3JtYW5jZSByZWFzb25zLCB5b3Xi gJlyZSBnb2luZyB0byBkbyB0aGF0IHRlc3QgYW55d2F5cyAoeWVzLA0KIGl0IG1heSBiZSBhbiBl eHBlbnNpdmUgd2FzdGUgZm9yIGNyeXB0b2dyYXBoaWNhbCByZWFzb25zLCBob3dldmVyLCBpdCBp c27igJl0IGZvciBjb25mb3JtYW5jZSByZWFzb25zKS4mbmJzcDsgSW4gdGhhdCBzY2VuYXJpbywg REggcmV1c2UgZG9lcyBtYWtlIHNlbnNlIChiZWNhdXNlIG5vdCBkb2luZyBESCByZXVzZSBkb2Vz buKAmXQgbGV0IHlvdSBlbGltaW5hdGUgdGhlIHRlc3QpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd291bGQgYWdyZWUgdGhhdCBt YXliZSB3ZSBuZWVkIHRvIGV4dGVuZCB0aGUgZHJhZnQgdG8gZGlzY3VzcyB0aGVzZSBub25jcnlw dG9ncmFwaGljYWwgaXNzdWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PGJyPg0KQnkgdGhlIHdheSwgaWYgeW91IGZvcmJpZCByZS11c2UsIHlvdSBuZWVkIHRvIGFjdHVh bGx5IG1hbmRhdGUgZnJlc2ggZXhwb25lbnRzIHdpdGggZWFjaCBzZXNzaW9uIChvdGhlcndpc2Us IGFuIGltcGxlbWVudGF0aW9uIG1heWJlIHRlbXB0ZWQgdG8gYXZvaWQgcmUtdXNlIGJ5IHVzaW5n IGdeeCwgZ157eCYjNDM7MX0sIGdee3gmIzQzOzJ9LCBldGMuKTxicj4NCiZuYnNwOzxicj4NCkh1 Z288L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g TW9uLCBEZWMgMTAsIDIwMTIgYXQgMTo0MyBQTSwgWWFyb24gU2hlZmZlciAmbHQ7PGEgaHJlZj0i bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnlhcm9uZi5pZXRm QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGksPGJyPg0KPGJyPg0KZm9sbG93aW5nIHRoZSByZWNlbnQgZGlzY3Vzc2lvbiBvbiB0 aGUgbWFpbGluZyBsaXN0LCBTY290dCBGbHVocmVyIGFuZCBteXNlbGYganVzdCBwdWJsaXNoZWQg YSBkcmFmdCB0aGF0IHVwZGF0ZXMgUkZDIDU5OTYgYnkgYWRkaW5nIHRoZSByZXF1aXJlZCByZWNp cGllbnQtc2lkZSB0ZXN0cyBmb3IgRUNESC4gUGxlYXNlIHNlZQ0KPGEgaHJlZj0iaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc2hlZmZlci1pcHNlY21lLWRoLWNoZWNr cy0wMC50eHQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LXNoZWZmZXItaXBzZWNtZS1kaC1jaGVja3MtMDAudHh0PC9hPi48YnI+DQo8 YnI+DQpXZSBoYXZlIG5vdCBhZGRyZXNzZWQgdGhlIGlzc3VlcyByYWlzZWQgYnkgRGFuIGFuZCBU ZXJvIHJlZ2FyZGluZyBpbmNvbnNpc3RlbmNpZXMgYmV0d2VlbiB2YXJpb3VzIFJGQ3MgdGhhdCBk ZWZpbmUgRUNESCBncm91cHMgZm9yIElLRS4gSSBwZXJzb25hbGx5IGRlZW0gdGhlc2UgaXNzdWVz IHRvIGJlIG91dCBvZiBzY29wZSBvZiB0aGUgY3VycmVudCBkb2N1bWVudC48YnI+DQo8YnI+DQpD b21tZW50cyBhcmUgdmVyeSB3ZWxjb21lLjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQombmJzcDsg Jm5ic3A7IFlhcm9uPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpJUHNlYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86SVBzZWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JUHNlY0BpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNl YzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_A113ACFD9DF8B04F96395BDEACB340421E4BE9xmbrcdx04ciscocom_-- From dharkins@lounge.org Mon Dec 10 14:02:22 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3BD21F85A7 for ; Mon, 10 Dec 2012 14:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghrA8mD3uRcg for ; Mon, 10 Dec 2012 14:02:22 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 2064F21F8552 for ; Mon, 10 Dec 2012 14:02:22 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 8101910224008; Mon, 10 Dec 2012 14:02:21 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 10 Dec 2012 14:02:21 -0800 (PST) Message-ID: In-Reply-To: <50C62D6A.8010709@gmail.com> References: <50C62D6A.8010709@gmail.com> Date: Mon, 10 Dec 2012 14:02:21 -0800 (PST) From: "Dan Harkins" To: "Yaron Sheffer" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: IPsecme WG Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 22:02:22 -0000 Hello, On Mon, December 10, 2012 10:43 am, Yaron Sheffer wrote: > Hi, > > following the recent discussion on the mailing list, Scott Fluhrer and > myself just published a draft that updates RFC 5996 by adding the > required recipient-side tests for ECDH. Please see > http://www.ietf.org/internet-drafts/draft-sheffer-ipsecme-dh-checks-00.txt. > > We have not addressed the issues raised by Dan and Tero regarding > inconsistencies between various RFCs that define ECDH groups for IKE. I > personally deem these issues to be out of scope of the current document. If you're planning on updating a standards-track product of this working group then isn't it up to the group to decide whether they want to tackle various issues? Dan. From yaronf.ietf@gmail.com Mon Dec 10 14:09:07 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242B121F8635 for ; Mon, 10 Dec 2012 14:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.475 X-Spam-Level: X-Spam-Status: No, score=-103.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIXSAMzn--4N for ; Mon, 10 Dec 2012 14:09:06 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 533CB21F8634 for ; Mon, 10 Dec 2012 14:09:06 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so2046578eek.31 for ; Mon, 10 Dec 2012 14:09:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=WV+0Q2Ay96AKrtuQToLB4ZRsN0JYyh3hm87+5qHcrrs=; b=YRccOTdosgzv171mUjekFN54U9G8c2MjtzmOxH+Uz+YLh03VC54042HtPpe//yxs0H xc826ZUe6UG7zd9EN6hY8Dt+47ve4VcazwJkxvQNa09gsHnFXDDzdPFysbS1TVDu+wOu uwzD41decClL58a8OXjX4uLx0LZe+66X12ZWVP421o18Ss3ee5EfnwaJLRqNw/Gy/c0y 0J5T8mLvl191Em5SRcAqf02wj73pieyqWEyVifxecJbz3pzJERso+9rFbwM47SeD5liP 2xVR4nYzmy1yK6qweTu1zWM7nIoWgie5wum/uarWwwFY0hI0aWLtZvc711qKv0rqjnvO eUbw== Received: by 10.14.223.200 with SMTP id v48mr53928178eep.24.1355177345467; Mon, 10 Dec 2012 14:09:05 -0800 (PST) Received: from [10.0.0.3] (bzq-79-180-163-165.red.bezeqint.net. [79.180.163.165]) by mx.google.com with ESMTPS id l3sm27808020eem.14.2012.12.10.14.09.03 (version=SSLv3 cipher=OTHER); Mon, 10 Dec 2012 14:09:04 -0800 (PST) Message-ID: <50C65D7D.6030102@gmail.com> Date: Tue, 11 Dec 2012 00:09:01 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Dan Harkins References: <50C62D6A.8010709@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 22:09:07 -0000 Yes it is. That's why I mentioned that this is my personal opinion. You might have different personal opinions. Yaron On 12/11/2012 12:02 AM, Dan Harkins wrote: > > Hello, > > On Mon, December 10, 2012 10:43 am, Yaron Sheffer wrote: >> Hi, >> >> following the recent discussion on the mailing list, Scott Fluhrer and >> myself just published a draft that updates RFC 5996 by adding the >> required recipient-side tests for ECDH. Please see >> http://www.ietf.org/internet-drafts/draft-sheffer-ipsecme-dh-checks-00.txt. >> >> We have not addressed the issues raised by Dan and Tero regarding >> inconsistencies between various RFCs that define ECDH groups for IKE. I >> personally deem these issues to be out of scope of the current document. > > If you're planning on updating a standards-track product of this working > group then isn't it up to the group to decide whether they want to tackle > various issues? > > Dan. > > From hugokraw@gmail.com Mon Dec 10 14:56:49 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE7821F85E6 for ; Mon, 10 Dec 2012 14:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 414ZIlJnIV8I for ; Mon, 10 Dec 2012 14:56:48 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE8621F8507 for ; Mon, 10 Dec 2012 14:56:48 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so3340368vcb.31 for ; Mon, 10 Dec 2012 14:56:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=woLufvmT9IqVmbSrNhceStcWd4hPnTSOsaOJc/NDX9g=; b=vmZMC9Dz/Mbv0GwUnbd37iJXlPAhtSSce/9KefWPvj9zOuSOUAoDORAWGQrTkvn0ua 6KmTz0Qzox9sWRTHa8dPjv6zafOmXdadwpiLXUPC41kAqYAZnn6lrKR4rhVsfb+CEVuH nA8P9I/iWdgGr+hPWzPiodERzpBhFP72Jdol5JfFYqD9RDJdGvWNoo1GEjfKuWtwuOVV IHS+YTIIJMkD06fkpaWG5u9EUUt6Gn9+JXklsNQirFACpb/5XPNTghLDxZCFCLIE38RY uQq1quXGQDOzdSjVCOXEjipxhQWB6SO219zmJFf0rKG8jYgsGBxRUYcMk5FQ2rzCxM3u MVsw== Received: by 10.58.198.164 with SMTP id jd4mr10279709vec.34.1355180208104; Mon, 10 Dec 2012 14:56:48 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.58.29.50 with HTTP; Mon, 10 Dec 2012 14:56:28 -0800 (PST) In-Reply-To: References: <50C62D6A.8010709@gmail.com> From: Hugo Krawczyk Date: Mon, 10 Dec 2012 17:56:28 -0500 X-Google-Sender-Auth: ygb_RxvQ0gFL3qG8gHIav-AxhAk Message-ID: To: "Scott Fluhrer (sfluhrer)" Content-Type: multipart/alternative; boundary=e89a8f642ee0e9242f04d0877ad0 Cc: IPsecme WG Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 22:56:49 -0000 --e89a8f642ee0e9242f04d0877ad0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If the recommendation is to be compatible with the unnecessary checks of 56A in this case then say that. As written now, one would assume that there is a security benefit to it. (That's how we carry legacy misconceptions from standard to standard.) Hugo On Mon, Dec 10, 2012 at 4:53 PM, Scott Fluhrer (sfluhrer) < sfluhrer@cisco.com> wrote: > ** ** > > ** ** > > *From:* ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] *On Behalf > Of *Hugo Krawczyk > *Sent:* Monday, December 10, 2012 2:50 PM > *To:* Yaron Sheffer > *Cc:* IPsecme WG > *Subject:* Re: [IPsec] New draft on IKE Diffie-Hellman checks**** > > ** ** > > The tests in sections 2.1 and 2.3 are cheap and can serve as sanity check= s > for an implementation as stated in the draft, even if DH is not reused. > > On the other hand, the test in 2.2 is expensive, equivalent to a group > exponentiation, and therefore should not be recommended without DH re-use > (in which case the test is an expensive waste). > > Actually, the right recommendation (or MUST) for 2.2 groups is NOT to > reuse DH values. > Indeed, the reason to reuse DH is to save an exponentiation but if you do > so you pay with an extra exponentiation for the membership test. Moreover= , > while the exponentiation you are saving can be performed offline (before > the run of the IKE session), the group membership test is online, so eith= er > way it makes no sense to reuse the DH exponents.**** > > I cannot disagree with anything you say. However, the real reason the 2.= 2 > groups (22, 23, 24) exist is the other MODP groups do not conform to NIST > SP 800-56A (see section 5.5.1.1). And, SP 800-56A also mandates the chec= ks > we recommend (section 5.6.2.4).**** > > That is, if you are implementing (say) group 24 specifically for > conformance reasons, you=E2=80=99re going to do that test anyways (yes, i= t may be > an expensive waste for cryptographical reasons, however, it isn=E2=80=99t= for > conformance reasons). In that scenario, DH reuse does make sense (becaus= e > not doing DH reuse doesn=E2=80=99t let you eliminate the test).**** > > I would agree that maybe we need to extend the draft to discuss these > noncryptographical issues.**** > > ** ** > > > By the way, if you forbid re-use, you need to actually mandate fresh > exponents with each session (otherwise, an implementation maybe tempted t= o > avoid re-use by using g^x, g^{x+1}, g^{x+2}, etc.) > > Hugo**** > > On Mon, Dec 10, 2012 at 1:43 PM, Yaron Sheffer > wrote:**** > > Hi, > > following the recent discussion on the mailing list, Scott Fluhrer and > myself just published a draft that updates RFC 5996 by adding the require= d > recipient-side tests for ECDH. Please see > http://www.ietf.org/internet-drafts/draft-sheffer-ipsecme-dh-checks-00.tx= t > . > > We have not addressed the issues raised by Dan and Tero regarding > inconsistencies between various RFCs that define ECDH groups for IKE. I > personally deem these issues to be out of scope of the current document. > > Comments are very welcome. > > Thanks, > Yaron > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec**** > > ** ** > --e89a8f642ee0e9242f04d0877ad0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If the recommendation is to be comp= atible with the unnecessary checks of 56A in this case then say that.
A= s written now, one would assume that there is a security benefit to it.
(That's how we carry legacy misconceptions from standard to standard.)<= br>
Hugo

On Mon, Dec 10,= 2012 at 4:53 PM, Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com> wrote:

=C2=A0

=C2=A0

From: ipsec-bounces@ietf.org= [mailto:ip= sec-bounces@ietf.org] On Behalf Of Hugo Krawczyk
Sent: Monday, December 10, 2012 2:50 PM
To: Yaron Sheffer
Cc: IPsecme WG
Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks

=C2=A0

The tests in sections 2.1= and 2.3 are cheap and can serve as sanity checks for an implementation as = stated in the draft, even if DH is not reused.

On the other hand, the test in 2.2 is expensive, equivalent to a group expo= nentiation, and therefore should not be recommended without DH re-use (in w= hich case the test is an expensive waste).

Actually, the right recommendation (or MUST) for 2.2 groups is NOT to reuse= DH values.
Indeed, the reason to reuse DH is to save an exponentiation but if you do s= o you pay with an extra exponentiation for the membership test. Moreover, w= hile the exponentiation you are saving can be performed offline (before the= run of the IKE session), the group membership test is online, so either way it makes no sense to reuse the DH= exponents.

I cannot disagree with anything you say.=C2=A0 However, the rea= l reason the 2.2 groups (22, 23, 24) exist is the other MODP groups do not conform to NIST SP 800-56A (see section 5.5.1.1).=C2=A0 And, SP 800-56= A also mandates the checks we recommend (section 5.6.2.4).

That is, if you are implementing (say) group 24 specifically for conf= ormance reasons, you=E2=80=99re going to do that test anyways (yes, it may be an expensive waste for cryptographical reasons, however, it isn= =E2=80=99t for conformance reasons).=C2=A0 In that scenario, DH reuse does = make sense (because not doing DH reuse doesn=E2=80=99t let you eliminate th= e test).

I would agree that maybe we need to extend the draft to discuss these= noncryptographical issues.

=C2=A0


By the way, if you forbid re-use, you need to actually mandate fresh expone= nts with each session (otherwise, an implementation maybe tempted to avoid = re-use by using g^x, g^{x+1}, g^{x+2}, etc.)
=C2=A0
Hugo

On Mon, Dec 10, 2012 at 1:43 PM, Yaron Sheffer <<= a href=3D"mailto:yaronf.ietf@gmail.com" target=3D"_blank">yaronf.ietf@gmail= .com> wrote:

Hi,

following the recent discussion on the mailing list, Scott Fluhrer and myse= lf just published a draft that updates RFC 5996 by adding the required reci= pient-side tests for ECDH. Please see http://www.ietf.org/internet-drafts/draft-sheffer-ipsecme-dh-checks-00.txt<= /a>.

We have not addressed the issues raised by Dan and Tero regarding inconsist= encies between various RFCs that define ECDH groups for IKE. I personally d= eem these issues to be out of scope of the current document.

Comments are very welcome.

Thanks,
=C2=A0 =C2=A0 Yaron

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

=C2=A0


--e89a8f642ee0e9242f04d0877ad0-- From svanru@gmail.com Tue Dec 11 04:16:35 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16BA21F8818 for ; Tue, 11 Dec 2012 04:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MJuG8yURjUq for ; Tue, 11 Dec 2012 04:16:35 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 191B921F8810 for ; Tue, 11 Dec 2012 04:16:34 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so3116015lah.31 for ; Tue, 11 Dec 2012 04:16:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=P1eCH2FtZEDL9KjGn8hKkdOQR9vcN9qW83eXrlw1M7k=; b=Fx30xVWYPhddXb/XbKsSRP3q1gnp6lEsKqj5S0hsZCnUXg/LPu7qJE38arQmmv/gxT cG0FGUvLh7MkWxjy2ajRSVoBx26Mjxj61MulB4kxHrP0m0L/eFvolDUa1OnEv3TuJa+t jCBw0ibcHDyurRcYuCEYuZpyyz6uL9l4VKolKqVpip2LZ0Bc33ppDHb2ucrRbhoTYcdF qLS88FxSnxTQLNHYEHJzddaCyqimnX2ipyLdDviQPnJNUsHtcDE0GeW4MkGT3BdkWWWw V1IGsyrB+oVyF7wp2QpZQ3ieWIQLQwYi7JUBG44Djs9h1G9wwMpi/YYzgPVCpOWAf5Vy Bl9g== Received: by 10.112.29.104 with SMTP id j8mr7616136lbh.0.1355228194086; Tue, 11 Dec 2012 04:16:34 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPS id ne2sm2183818lab.10.2012.12.11.04.16.31 (version=SSLv3 cipher=OTHER); Tue, 11 Dec 2012 04:16:32 -0800 (PST) Message-ID: From: "Valery Smyslov" To: References: <20121203223404.5441.71025.idtracker@ietfa.amsl.com> Date: Tue, 11 Dec 2012 16:16:18 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: Yoav Nir Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ike-tcp-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 12:16:36 -0000 Hi, I'm a bit uncomfortable with the requirement that IKE peer "MUST" advertise NAT device port if it is reachable and "MUST NOT" if it isn't. I think, that IKE Initiator in most cases cannot reliably determine whether it is reachable or not. For example, even if you manually configured port forwarding on your home network border NAT box and then configured IKE to advertise this port, that wouldn't imply that this port is actually reachable as your ISP may have another NAT and, as CGN become more common, number of those nested NAT's will increase. Even STUN might not be a good solution - it is pretty expensive in terms of round trips, requires the presence of STUN server in the same network segment as IKE Responder, utilizes TLS and, most important, deals with UDP only (AFAIK). So, I think that the requirement for IKE Initiator to advertise its support for TCP and port it thinks it is reachable at should be listed as "SHOULD" or even "MAY". Otherwise it sounds like a paradox - protocol requires IKE to do or not to do some action depending on condition that IKE in most cases is unable to determine. Related issues. - in description to TCP Port field in IKE_TCP_SUPPORTED Notification it is written that "If the sender is not subject to network address translation, the port SHOULD be 500." Again, IKE Initiator cannot reliably determine whether it is behind NAT or not. It becomes clear only after initial request completes and NAT_TRAVERSAL_*_IP are processed. - as it is quite possible that the port advertised by IKE Initiator in IKE_TCP_SUPPORTED Notification is actually not reachable, I think it is worth to mention, that if original Responder after IKE SA is established wants to make some request using TCP port advertised by original Initiator and this port appears to be not reachable, this Responder MUST NOT tear down IKE SA but MUST instead fall back to UDP transport. Regards, Valery Smyslov. From dharkins@lounge.org Tue Dec 11 10:06:07 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BF921F8703 for ; Tue, 11 Dec 2012 10:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.205 X-Spam-Level: X-Spam-Status: No, score=-6.205 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqLDp5ZQsiPz for ; Tue, 11 Dec 2012 10:06:06 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 722BA21F86E4 for ; Tue, 11 Dec 2012 10:06:06 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id AA4C310224008; Tue, 11 Dec 2012 10:06:05 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 11 Dec 2012 10:06:06 -0800 (PST) Message-ID: <5808c090d8485cc6698829b522fade80.squirrel@www.trepanning.net> In-Reply-To: <50C62D6A.8010709@gmail.com> References: <50C62D6A.8010709@gmail.com> Date: Tue, 11 Dec 2012 10:06:06 -0800 (PST) From: "Dan Harkins" To: "Yaron Sheffer" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: IPsecme WG Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 18:06:07 -0000 Hello, I have a few comments. - The Introduction says that "It turns out using EC groups in some scenarios require...additional tests. This document defines these tests." Well the memo is defining more than EC. I think the Intro should introduce us to the why, which is sort of mentioned in the next section. It would be better to state in the Intro that the memo is defining group membership tests to apply to DH values received during IKEv2. Then let section 2 have normative text for what's REQUIRED and what's RECOMMENDED and set up the reason for the sub-sections-- i.e. different kinds of DH groups have different kinds of group membership tests. - The IANA considerations imply that this is placing requirements on future RFCs. That being the case, I think the subsections of section 2 should not be so group-number-specific, e.g. today's group numbers should not be in the subsection titles. I'd suggest: 2.1 MODP Groups Based on Sophie-Germain Primes 2.2 MODP Groups With a Small Sub-Group 2.3 Elliptic Curve Groups Over a Prime Finite Field and then in each of them you say what the group membership test is and only then say that as of publication of this memo the following groups are covered by this section...list the group numbers. This will allow, for example, Johannes' draft to say that the membership tests for the groups it is defining are in section 2.3 of RFCXYZ and that section heading won't say "groups 19-21, 25, 26" which would be somewhat clumsy. Also, don't say that a=-3 in 2.3. Just say that a, b, and p are from the domain parameter set defining the group. I think it's better to just define the test, let the reader get a, b, and p. - I'd also suggest a sub-section like this: 2.4 Elliptic Curve Groups Over a Characteristic-2 Finite Field And the check is that the x- and y-coordinates are binary polynomials of degree m-1 (where m is field size of the curve) and that: y^2 + xy = x^3 + ax^2 + b (in GF(2^m)) I know that the binary curves in RFC2409's registry were removed from the RFC5996's registry but some may be defined in the future and it would be good to cover all the possibilities now. - I think it should be mentioned that elliptic curve groups have a co-factor, h, and if h > 1 that a further check is also required, namely, if the x- and y-coordinates define a point Q then ensure that: hQ = point-at-infinity Add this check to both 2.3 and 2.4. Of course if h=1 then this check can be skipped. - Let IANA know what registry these new requirements are being place on. It says, "The groups mentioned here are managed by IANA." I suggest adding "in [IKEV2IANA]." and add the following in the References: [IKEV2IANA] Internet Assigned Numbers Authority, "Internet Key Exchange Version 2 (IKEv2) Parameters", Transform Type 4-- Diffie-Hellman Group Transform IDs. regards, Dan. On Mon, December 10, 2012 10:43 am, Yaron Sheffer wrote: > Hi, > > following the recent discussion on the mailing list, Scott Fluhrer and > myself just published a draft that updates RFC 5996 by adding the > required recipient-side tests for ECDH. Please see > http://www.ietf.org/internet-drafts/draft-sheffer-ipsecme-dh-checks-00.txt. > > We have not addressed the issues raised by Dan and Tero regarding > inconsistencies between various RFCs that define ECDH groups for IKE. I > personally deem these issues to be out of scope of the current document. > > Comments are very welcome. > > Thanks, > Yaron > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From bew@cisco.com Tue Dec 11 12:39:03 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3639511E809B for ; Tue, 11 Dec 2012 12:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.399 X-Spam-Level: X-Spam-Status: No, score=-109.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARp2dBR1dUkR for ; Tue, 11 Dec 2012 12:39:02 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEA311E8097 for ; Tue, 11 Dec 2012 12:39:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2459; q=dns/txt; s=iport; t=1355258342; x=1356467942; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=bklYj4e+W+AQ+r1kSU1gfkudnITWnYfapNmPVltv0BA=; b=DsDjfC9owdIwAcGkkG51XUc08QjdzoBSVOcNxGVkjAaY0nMAsYde015D BmFtaGBPi8ZxTwnqrBak6D28G72K3QHXJAPX3uFzLumT2Vz3RQQp/9y+G AWDVoT2um+THMEBMiKRoVIIncni3KvAapXEeDv0vyT/q4F4jMH40pv8cy U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8HAC6Yx1CrRDoG/2dsb2JhbABFg0i7BhZzgl8/KYEVAS2HdasukFKQLGEDiGCNJ5BIgxQ X-IronPort-AV: E=McAfee;i="5400,1158,6923"; a="63197224" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 11 Dec 2012 20:39:01 +0000 Received: from sjc-vpn5-90.cisco.com (sjc-vpn5-90.cisco.com [10.21.88.90]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBBKcrbZ018702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Dec 2012 20:39:01 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Dec 2012 12:30:56 -0800 Message-Id: <0B592A71-6BE1-4988-8BA7-2F3CD61AD03A@cisco.com> To: Stephen Hanna , "vishwas.manral@hp.com" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: ipsec@ietf.org Subject: [IPsec] Comments on proposed draft-ietf-ipsecme-ad-vpn-problem-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 20:39:03 -0000 Hi Steve & Vishwas, Here are a couple of comments on the proposed -02 sent a few days ago. Requirement 1 says "gateways and endpoints MUST minimize configuration = changes when a new gateway or endpoint is added, removed or changed." = While I certainly agree with the sentiment behind the requirement, this = statement is about as strong as "gateways and endpoints MUST perform = well", or "gateways and endpoints MUST be easy to use". In other words, = it isn't a testable assertion that can be evaluated. Also the body of = the document says "it is desired that there be minimal configuration on = each gateway", which does not support a MUST requirement. This ought to = be a SHOULD rather than a MUST. Requirement 8 has gone through several versions, but I think it could = still be made clearer. It first requires Gateways and endpoints "to work = when they are behind NAT boxes", and then makes a bunch of necessary = exceptions. The following replacement text attempts to make the same = points as the original but might be clearer: 8. Gateways and endpoints MUST have the capability to participate=20 in an AD VPN even when they are located behind NAT boxes. However,=20 in some cases they may be deployed in such a way that they will not = be=20 fully reachable behind a NAT box. It is especially difficult=20 to handle cases where the Hub is behind a NAT box. Where the two endpoints are both behind separate NATs, communication between these spokes SHOULD be supported using workarounds such as port forwarding by the NAT or detecting when two spokes are behind uncooperative NATs and using a hub in that case.=20 Requirement 14 says "The ADVPN solution MUST support Provider Edge (PE) = based VPN's". This requirement seems unfair to the end point use cases = in 2.1 and 2.3, or even gateway-to-gateway ADVPN solutions that have = nothing to do with L3VPNs! I think you're trying to say it must be = possible to build an ADVPN solution that meets the requirements of = L3VPN, which I have no problem with but I don't think think this it's a = fair requirement to put in Section 4. Is there anything beyond the new = text you added in 2.2 regarding L3VPN that needs to be said? There's a couple remaining nits: Section 2.2: s/A fully meshed solution is would/A fully meshed solution = would/ Section 4: s/This sectiondefines/This section defines/ Thanks, Brian From dharkins@lounge.org Tue Dec 11 13:32:27 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F0221F84F3 for ; Tue, 11 Dec 2012 13:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.215 X-Spam-Level: X-Spam-Status: No, score=-6.215 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQMbLzGabg8H for ; Tue, 11 Dec 2012 13:32:26 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id C16BC21F84DC for ; Tue, 11 Dec 2012 13:32:26 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 0136110224008; Tue, 11 Dec 2012 13:32:26 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 11 Dec 2012 13:32:26 -0800 (PST) Message-ID: In-Reply-To: <5808c090d8485cc6698829b522fade80.squirrel@www.trepanning.net> References: <50C62D6A.8010709@gmail.com> <5808c090d8485cc6698829b522fade80.squirrel@www.trepanning.net> Date: Tue, 11 Dec 2012 13:32:26 -0800 (PST) From: "Dan Harkins" To: "Dan Harkins" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: IPsecme WG Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 21:32:27 -0000 I made a mistake below. Thanks to Dan Brown for pointing it out. On Tue, December 11, 2012 10:06 am, Dan Harkins wrote: [snip] > - I think it should be mentioned that elliptic curve groups > have a co-factor, h, and if h > 1 that a further check is > also required, namely, if the x- and y-coordinates define > a point Q then ensure that: > > hQ = point-at-infinity > > Add this check to both 2.3 and 2.4. Of course if h=1 then this > check can be skipped. The check should be hQ != point-at-infinity. An equivalent check could be nQ = point-at-infinity where n is the order of the group formed by the generator, G. regards, Dan. From prvs=469265c35f=dbrown@certicom.com Tue Dec 11 13:36:30 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E1D21F84FE for ; Tue, 11 Dec 2012 13:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.603 X-Spam-Level: X-Spam-Status: No, score=-4.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_28=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9v8QtbysDNX for ; Tue, 11 Dec 2012 13:36:30 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 187F721F84F3 for ; Tue, 11 Dec 2012 13:36:29 -0800 (PST) X-AuditID: 0a41282f-b7fea6d000001d56-d9-50c7a756cb85 Received: from XCT106CNC.rim.net (xct106cnc.rim.net [10.65.161.206]) by mhs060cnc.rim.net (SBG) with SMTP id 04.0E.07510.657A7C05; Tue, 11 Dec 2012 15:36:22 -0600 (CST) Received: from XCT113CNC.rim.net (10.65.161.213) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.2.318.1; Tue, 11 Dec 2012 16:36:22 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT113CNC.rim.net ([::1]) with mapi id 14.02.0318.001; Tue, 11 Dec 2012 16:36:21 -0500 From: Dan Brown To: 'Dan Harkins' Thread-Topic: [IPsec] New draft on IKE Diffie-Hellman checks Thread-Index: AQHN1wZilu/9uGwwRUmtYsZlChLDnZgUOiUAgAA5pgD//6x6sA== Date: Tue, 11 Dec 2012 21:36:21 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF50EC94B@XMB111CNC.rim.net> References: <50C62D6A.8010709@gmail.com> <5808c090d8485cc6698829b522fade80.squirrel@www.trepanning.net> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.245] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFKsWRmVeSWpSXmKPExsXC5bjwnG7Y8uMBBht6lSyW/vvCYrF/yws2 ByaPJUt+Mnk82/2SJYApqoHRJimxpCw4Mz1P384mMS8vvySxJFUhJbU42VbJJzU9MUchoCiz LDG5UsElszg5JzEzN7VISSEzxVbJREmhICcxOTU3Na/EVimxoCA1L0XJjksBA9gAlWXmKaTm JeenZOal2yp5BvvrWliYWuoaKtnpJnTyZKw5cYOp4BRnxd3OCYwNjAvYuxg5OSQETCQO32uC ssUkLtxbz9bFyMUhJLCKUeJG6zQWkISQwEpGiYXN0hCJOYwSx/ccYQVJsAmoStw/eo65i5GD Q0RAXWLL91iQMLOAvMTmL7vYQGxhAWuJ9b/2M4LYIgI2EvNW3GOFsJ0k/vUfB6thARrz5MEu ZhCbV8BN4t2Pa6xwR6x82gvWzCngLTFx03UmEJtRQFZi91kIm1lAXOLWk/lMEB8ISCzZc54Z whaVePn4HyuErSix+tUtNoh6HYkFuz9B2doSyxa+hlosKHFy5hOohxUkrlzfxzKBUWIWkhWz kLTPQtI+C0n7AkaWVYyCuRnFBmYGyXnJekWZuXp5qSWbGMGJRUN/B+Pb9xaHGAU4GJV4eOOP HQsQYk0sK67MPcQowcGsJMI7K+F4gBBvSmJlVWpRfnxRaU5q8SFGV2AQTWSW4k7OBya9vJJ4 YwMD3BwlcV5l5oMBQgLpwDSWnZpakFoEM4eJgxNkD5eUSDEwGaUWJZaWZMSDUmZ8MTBpSjUw 6nlvniUzd23GlwiZp2kiz3vq5vGyqOxZ7vn1YfoCjh0bfX40SnyWq572wna2VuTVy7t8/ssX eF7bXeG0uTmgqXKOeeSp2Zc/6X08a/m049iqEMMFy/1KlMKXPBK7/a7/e0drSvwu3suFAlIW F4Vd33/qrpL+NWPppykrt9rZZnHGq17UV3j4SomlOCPRUIu5qDgRAKyOGOltAwAA Cc: IPsecme WG Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 21:36:30 -0000 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Dan Harkins > Sent: Tuesday, December 11, 2012 4:32 PM > To: Dan Harkins > Cc: IPsecme WG > Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks > > > I made a mistake below. Thanks to Dan Brown for pointing it out. > > On Tue, December 11, 2012 10:06 am, Dan Harkins wrote: > [snip] > > - I think it should be mentioned that elliptic curve groups > > have a co-factor, h, and if h > 1 that a further check is > > also required, namely, if the x- and y-coordinates define > > a point Q then ensure that: > > > > hQ =3D point-at-infinity > > > > Add this check to both 2.3 and 2.4. Of course if h=3D1 then this > > check can be skipped. > > The check should be hQ !=3D point-at-infinity. An equivalent check > could be nQ =3D point-at-infinity where n is the order of the group > formed by the generator, G. > [DB] Well, the hQ !=3D infinity check is insufficient for security, and not= equivalent to ensuring that nQ=3Dinfinity. Dan, sorry, I did not explain these details in my response to you. Best regards, Dan --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From dharkins@lounge.org Tue Dec 11 14:01:36 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EBF11E80A6 for ; Tue, 11 Dec 2012 14:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.922 X-Spam-Level: X-Spam-Status: No, score=-5.922 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtOpzVSA56FN for ; Tue, 11 Dec 2012 14:01:36 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 05DD021F853B for ; Tue, 11 Dec 2012 14:01:36 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6EF2F10224008; Tue, 11 Dec 2012 14:01:35 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 11 Dec 2012 14:01:35 -0800 (PST) Message-ID: In-Reply-To: <810C31990B57ED40B2062BA10D43FBF50EC94B@XMB111CNC.rim.net> References: <50C62D6A.8010709@gmail.com> <5808c090d8485cc6698829b522fade80.squirrel@www.trepanning.net> <810C31990B57ED40B2062BA10D43FBF50EC94B@XMB111CNC.rim.net> Date: Tue, 11 Dec 2012 14:01:35 -0800 (PST) From: "Dan Harkins" To: "Dan Brown" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: IPsecme WG , 'Dan Harkins' Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 22:01:36 -0000 On Tue, December 11, 2012 1:36 pm, Dan Brown wrote: > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of Dan Harkins >> Sent: Tuesday, December 11, 2012 4:32 PM >> To: Dan Harkins >> Cc: IPsecme WG >> Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks >> >> >> I made a mistake below. Thanks to Dan Brown for pointing it out. >> >> On Tue, December 11, 2012 10:06 am, Dan Harkins wrote: >> [snip] >> > - I think it should be mentioned that elliptic curve groups >> > have a co-factor, h, and if h > 1 that a further check is >> > also required, namely, if the x- and y-coordinates define >> > a point Q then ensure that: >> > >> > hQ = point-at-infinity >> > >> > Add this check to both 2.3 and 2.4. Of course if h=1 then this >> > check can be skipped. >> >> The check should be hQ != point-at-infinity. An equivalent check >> could be nQ = point-at-infinity where n is the order of the group >> formed by the generator, G. >> > [DB] Well, the hQ != infinity check is insufficient for security, and not > equivalent to ensuring that nQ=infinity. > > Dan, sorry, I did not explain these details in my response to you. That's interesting. Your paper "Validating EC Public Keys" (Antipa, Brown, Menezes, Struik and Vanstone) says in section 3 that the steps to validate an EC public key, W=(xw, yw), are: 1. W != infinity 2. xw and yw are properly represented elements of the finite field 3. W satisfies the defining equation of the curve; and 4. nW = infinity It then says that "if h=1, then condition 4 is implied by the other three conditions. In some protocols the check that nW = infinity may either be embedded in the protocol computations or replaced by the check that hW != infinity." Can you explain why hQ != infinity is insufficient and not equivalent to nQ = infinity? thanks and best regards, Dan. From prvs=76926c8199=dbrown@certicom.com Tue Dec 11 14:29:03 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E021F0CB1 for ; Tue, 11 Dec 2012 14:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.903 X-Spam-Level: X-Spam-Status: No, score=-4.903 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbKUOKlSfmwq for ; Tue, 11 Dec 2012 14:29:03 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id B88C91F0CAF for ; Tue, 11 Dec 2012 14:29:02 -0800 (PST) X-AuditID: 0a41282f-b7fea6d000001d56-c5-50c7b3a0ebb9 Received: from XCT108CNC.rim.net (xct108cnc.rim.net [10.65.161.208]) by mhs060cnc.rim.net (SBG) with SMTP id 15.7F.07510.0A3B7C05; Tue, 11 Dec 2012 16:28:48 -0600 (CST) Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT108CNC.rim.net ([fe80::8dc1:9551:6ed8:c618%17]) with mapi id 14.02.0318.001; Tue, 11 Dec 2012 17:28:48 -0500 From: Dan Brown To: 'Dan Harkins' Thread-Topic: [IPsec] New draft on IKE Diffie-Hellman checks Thread-Index: AQHN1wZilu/9uGwwRUmtYsZlChLDnZgUOiUAgAA5pgD//6x6sIAAW6uA//+t3gA= Date: Tue, 11 Dec 2012 22:28:47 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF50EC9A8@XMB111CNC.rim.net> References: <50C62D6A.8010709@gmail.com> <5808c090d8485cc6698829b522fade80.squirrel@www.trepanning.net> <810C31990B57ED40B2062BA10D43FBF50EC94B@XMB111CNC.rim.net> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.245] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIKsWRmVeSWpSXmKPExsXC5bjwgu6CzccDDKbc07BY+u8Li8X+LS/Y HJg8liz5yeTxbPdLlgCmqAZGm6TEkrLgzPQ8fTubxLy8/JLEklSFlNTiZFsln9T0xByFgKLM ssTkSgWXzOLknMTM3NQiJYXMFFslEyWFgpzE5NTc1LwSW6XEgoLUvBQlOy4FDGADVJaZp5Ca l5yfkpmXbqvkGeyva2FhaqlrqGSnm9DJk7H34Eemgsn8Fcs65rA1MD7k7mLk5JAQMJFou3mY EcIWk7hwbz1bFyMXh5DAKkaJXY8aWCGcrYwSb560s4FUsQmoStw/eo65i5GDQ0RAXWLL91iQ MLOAvMTmL7vASoQFrCXW/9oPNlREwEZi3op7rBDlfhJbz1aBhFmApjQ0PWcBsXkF3CR2Tz/N DLFqI5PE23m/WEESnALeEuu3zAabySggK7H77HUmiF3iEreezGeCOFpAYsme88wQtqjEy8f/ WCFsRYnVr26xQdTrSCzY/QnK1pZYtvA1M8RiQYmTM5+wTGAUm4Vk7CwkLbOQtMxC0rKAkWUV o2BuRrGBmUFyXrJeUWauXl5qySZGcJrQ0N/B+Pa9xSFGAQ5GJR7e+GPHAoRYE8uKK3MPMUpw MCuJ8BquOh4gxJuSWFmVWpQfX1Sak1p8iNEVGCwTmaW4k/OBKSyvJN7YwAA3R0mcV5n5YICQ QDowKWWnphakFsHMYeLgBNnDJSVSDEwtqUWJpSUZ8aAEGF8MTIFSDYyT/KfPbmr4k/7ywdLe kGtdc4K3JfV3OvEIJL/IePFdbynf7qVPFvrru1znYl82Y55Ju0DELzmj1F5eC+HDK0NaDAV/ H96Ucz9b5WDpi+Vtb7anLi2SZrr0QOnz+ZAL04LajblPPVp7eGGIU1udK5fqpLrlNitsWPMf n70c9MHaoGHCmk1P5kxQYinOSDTUYi4qTgQA4WC0EVQDAAA= Cc: IPsecme WG Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 22:29:03 -0000 Hmm, I think this may be getting too far off-topic for IPSec, since IKE most= ly uses ephemeral keys ... > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Tuesday, December 11, 2012 5:02 PM > > That's interesting. Your paper "Validating EC Public Keys" (Antipa, > Brown, Menezes, Struik and Vanstone) says in section 3 that the > steps to validate an EC public key, W=3D(xw, yw), are: > > 1. W !=3D infinity > 2. xw and yw are properly represented elements of the finite field > 3. W satisfies the defining equation of the curve; and > 4. nW =3D infinity > > It then says that "if h=3D1, then condition 4 is implied by the other > three conditions. In some protocols the check that nW =3D infinity may > either be embedded in the protocol computations or replaced by the > check that hW !=3D infinity." [DB] Sorry about that mistake in the paper. That paper was mostly about ski= pping the check number 3, not step 4. > > Can you explain why hQ !=3D infinity is insufficient and not equivalent > to nQ =3D infinity? > [DB] I should first correct myself when I said "insufficient for security".= This only really applies for very large h, which would be a very unusual c= ase. Now suppose that G has order n and H has order h. Then Q=3DG+H has order hn= , not h. In particular, it would pass the simpler test of hQ !=3D inf. Suppose s is a static private key s, and P =3D sG is the corresponding publi= c key. The shared secret is s applied to Q is Z =3D sQ =3D sG + sH =3D P + sH. The= refore, Z is confined to a small set, and can leak information about s, whic= h is the main security problem. So, log_2(h) bits of the private key can be leaked. For most curves, h is s= mall, and this is not too big a deal. Anyway, the hQ !=3D infinity test is not equivalent to the nQ =3D infinity t= est. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From sfluhrer@cisco.com Wed Dec 12 10:53:18 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A406321E8088 for ; Wed, 12 Dec 2012 10:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgqbTAsg9JlX for ; Wed, 12 Dec 2012 10:53:16 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8448421E80EB for ; Wed, 12 Dec 2012 10:53:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6764; q=dns/txt; s=iport; t=1355338396; x=1356547996; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tm8oBVrSt8UnjIzgDBO5Bt1Rn8X/GiTBa7aSlVrMT5I=; b=JIO8CW8/biiTS/W+YSMscwpPQh5/mVjF5J6IZIs2PSPZnGh5i7UuKmMN hzv4vOmYjukFuTikAhQ8PNqZO3BONX90qrx2rfXKd8mLa5KQ2nkvM62fm tgLeivsPFsezQkx2fPSbeKdYt1wE5dBmoxijNWdI3jtiBJgRlKHRNBK2u 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAE/SyFCtJXG8/2dsb2JhbABFvxgWc4IeAQEBAwEBAQE3MwELBQcEAgEIDgMEAQEBChQJBycLFAkIAgQBDQUIAYgCBgy9Z4xLg2JhA4tRkRKJboJzgiI X-IronPort-AV: E=Sophos;i="4.84,268,1355097600"; d="scan'208";a="152276420" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 12 Dec 2012 18:53:16 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBCIrFks006915 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Dec 2012 18:53:15 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.29]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Wed, 12 Dec 2012 12:53:15 -0600 From: "Scott Fluhrer (sfluhrer)" To: Dan Harkins , Yaron Sheffer Thread-Topic: [IPsec] New draft on IKE Diffie-Hellman checks Thread-Index: AQHN1wZaPpZNcIh600ewXpvuWaXH0pgUSukAgAEvCfA= Date: Wed, 12 Dec 2012 18:53:15 +0000 Message-ID: References: <50C62D6A.8010709@gmail.com> <5808c090d8485cc6698829b522fade80.squirrel@www.trepanning.net> In-Reply-To: <5808c090d8485cc6698829b522fade80.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 18:53:18 -0000 Maybe we should talk about who the audience of this RFC ought to be. I'm positing an audience of people who know little about elliptic curves; t= hey have no idea about what a cofactor or a Sophie-Germain prime is. All t= hey're interested in is trying to implement this protocol in a secure manne= r, and want to dig into the mathematical details as little as possible. With that in mind, I have comments below: > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Dan Harkins > Sent: Tuesday, December 11, 2012 1:06 PM > To: Yaron Sheffer > Cc: IPsecme WG > Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks >=20 >=20 > Hello, >=20 > I have a few comments. >=20 > - The Introduction says that "It turns out using EC groups in > some scenarios require...additional tests. This document > defines these tests." Well the memo is defining more than > EC. I think the Intro should introduce us to the why, which > is sort of mentioned in the next section. It would be better > to state in the Intro that the memo is defining group > membership tests to apply to DH values received during > IKEv2. Then let section 2 have normative text for what's > REQUIRED and what's RECOMMENDED and set up the reason > for the sub-sections-- i.e. different kinds of DH groups have > different kinds of group membership tests. >=20 > - The IANA considerations imply that this is placing requirements > on future RFCs. That being the case, I think the subsections > of section 2 should not be so group-number-specific, e.g. > today's group numbers should not be in the subsection titles. > I'd suggest: >=20 > 2.1 MODP Groups Based on Sophie-Germain Primes And what's a Sophie-Germain prime? Yes, I know (and definition you're usin= g is not the definition that Ms. Germain originally gave it); however, a ra= ndom implementor is unlikely to. The reason I put the group numbers in the titles is to make it easier for a= n implementer to decide, for a specific group, which section is appropriate= . Perhaps another approach for achieving that goal would be better. > 2.2 MODP Groups With a Small Sub-Group > 2.3 Elliptic Curve Groups Over a Prime Finite Field >=20 > and then in each of them you say what the group membership > test is and only then say that as of publication of this memo > the following groups are covered by this section...list the group > numbers. >=20 > This will allow, for example, Johannes' draft to say that the > membership tests for the groups it is defining are in section > 2.3 of RFCXYZ and that section heading won't say "groups > 19-21, 25, 26" which would be somewhat clumsy. >=20 > Also, don't say that a=3D-3 in 2.3. Just say that a, b, and p are > from the domain parameter set defining the group. I think it's > better to just define the test, let the reader get a, b, and p. RFC5903 doesn't list the value of 'a' for those curves; that's why I listed= it here. I don't believe it is appropriate to send someone to a document = which doesn't list the details we say it lists. >=20 > - I'd also suggest a sub-section like this: >=20 > 2.4 Elliptic Curve Groups Over a Characteristic-2 Finite Field >=20 > And the check is that the x- and y-coordinates are binary > polynomials of degree m-1 (where m is field size of the curve) > and that: >=20 > y^2 + xy =3D x^3 + ax^2 + b (in GF(2^m)) >=20 > I know that the binary curves in RFC2409's registry were > removed from the RFC5996's registry but some may be defined > in the future and it would be good to cover all the possibilities > now. >=20 > - I think it should be mentioned that elliptic curve groups > have a co-factor, h, and if h > 1 that a further check is > also required, namely, if the x- and y-coordinates define > a point Q then ensure that: >=20 > hQ !=3D point-at-infinity This is a cheap check (if h=3D2, I believe that's just a check that a coord= inate !=3D 0, and as you say below, it's even cheaper if h=3D1). However, = is there a specific attack that is possible if you don't do the check? If = you're worried about someone modifying the DH public value with this value,= IKE already has protections against that in place. If you're worried abou= t someone learning the value of (e mod h) (where e is the private ECDH mult= iplier), this check doesn't prevent that. >=20 > Add this check to both 2.3 and 2.4. Of course if h=3D1 then this > check can be skipped. Neither RFC5114 nor RFC5903 list the value of the cofactor for the curves i= t defines. How then do we expect someone to implement the test if they don= 't know that already? Remember the goal; keep things simple for the implementor. Yes, this cofac= tor test is cheap; however, if that check doesn't actually prevent an attac= k, I'd prefer that we don't make the implementor worry about it (especially= since it asks for a detail that isn't listed in the RFCs that defines the = curves) >=20 > - Let IANA know what registry these new requirements are > being place on. It says, "The groups mentioned here are managed > by IANA." I suggest adding "in [IKEV2IANA]." and add the following > in the References: >=20 > [IKEV2IANA] Internet Assigned Numbers Authority, "Internet Key > Exchange Version 2 (IKEv2) Parameters", Transform > Type 4-- Diffie-Hellman Group Transform IDs. >=20 > regards, >=20 > Dan. >=20 > On Mon, December 10, 2012 10:43 am, Yaron Sheffer wrote: > > Hi, > > > > following the recent discussion on the mailing list, Scott Fluhrer and > > myself just published a draft that updates RFC 5996 by adding the > > required recipient-side tests for ECDH. Please see > > http://www.ietf.org/internet-drafts/draft-sheffer-ipsecme-dh-checks- > 00.txt. > > > > We have not addressed the issues raised by Dan and Tero regarding > > inconsistencies between various RFCs that define ECDH groups for IKE. > > I personally deem these issues to be out of scope of the current > document. > > > > Comments are very welcome. > > > > Thanks, > > Yaron > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From Johannes.Merkle@secunet.com Thu Dec 13 02:41:36 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4877621F88C9 for ; Thu, 13 Dec 2012 02:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tE4RFZaBU7Yj for ; Thu, 13 Dec 2012 02:41:35 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6C021F889E for ; Thu, 13 Dec 2012 02:41:34 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 471BF1A0080; Thu, 13 Dec 2012 11:41:32 +0100 (CET) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id D4AFB1A007F; Thu, 13 Dec 2012 11:41:30 +0100 (CET) Received: from [172.16.48.110] ([172.16.48.110]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Dec 2012 11:41:30 +0100 Message-ID: <50C9B0B5.9090600@secunet.com> Date: Thu, 13 Dec 2012 11:40:53 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Scott Fluhrer (sfluhrer)" References: <50C62D6A.8010709@gmail.com> <5808c090d8485cc6698829b522fade80.squirrel@www.trepanning.net> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Dec 2012 10:41:30.0717 (UTC) FILETIME=[699410D0:01CDD91E] Cc: IPsecme WG , Dan Harkins Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 10:41:36 -0000 > I'm positing an audience of people who know little about elliptic curves; they have no idea about what a cofactor or a Sophie-Germain prime is. All they're interested in is trying to implement this protocol in a secure manner, and want to dig into the mathematical details as little as possible. Why not keeping the main document general and giving details for registered groups in an appendix? > The reason I put the group numbers in the titles is to make it easier for an implementer to decide, for a specific group, which section is appropriate. Perhaps another approach for achieving that goal would be better. The mapping between the registered groups and the individual subsections should be given in the appendix. >> hQ != point-at-infinity > > This is a cheap check (if h=2, I believe that's just a check that a coordinate != 0, and as you say below, it's even cheaper if h=1). However, is there a specific attack that is possible if you don't do the check? If you're worried about someone modifying the DH public value with this value, IKE already has protections against that in place. If you're worried about someone learning the value of (e mod h) (where e is the private ECDH multiplier), this check doesn't prevent that. You are right, this is exactly what Daniel has pointed out. Unfortunately, in case of a non-trivial cofactor, the check n*P != 0 necessary to prevent an attacker from learning (e mod h) is not cheap at all. In that case, the suggestion of Hugo applies as well, i.e. it is better to recommend not to reuse DH keys for EC groups with non-trivial cofactor. -- Johannes From sfluhrer@cisco.com Thu Dec 13 07:57:59 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82CE21F8A9B for ; Thu, 13 Dec 2012 07:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfCka2uxtiyH for ; Thu, 13 Dec 2012 07:57:59 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1444721F8A99 for ; Thu, 13 Dec 2012 07:57:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3294; q=dns/txt; s=iport; t=1355414279; x=1356623879; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=J+NmaIMoRmmezwU1qRSE0seHXWgvLMdHxiykmNKiJ3k=; b=GqB8Px7UrMJCdZTwdQYTatShRIrzpxYmEOs9Iso/xbHY96hiAm2RtD93 nJVjPNTsGlF1Iq0+2e4MQq0pqD9X+LCSKZvnpNaFCeDvhnNLyzgYK+D/3 sknG40mMnOkQ1C18ka27rtdo9lHaZYyalOuApb9dIsjqNubfCO8qgFlQX c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIP6yVCtJXG+/2dsb2JhbABFvm4Wc4IeAQEBBDozDAwEAgEIEQQBAQsUCQcyFAkIAgQOBQiIC71WjFeDYmEDplGCc4Ii X-IronPort-AV: E=Sophos;i="4.84,274,1355097600"; d="scan'208";a="152641660" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 13 Dec 2012 15:57:34 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBDFvYe2004291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Dec 2012 15:57:34 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.29]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Thu, 13 Dec 2012 09:57:33 -0600 From: "Scott Fluhrer (sfluhrer)" To: Johannes Merkle Thread-Topic: [IPsec] New draft on IKE Diffie-Hellman checks Thread-Index: AQHN1wZaPpZNcIh600ewXpvuWaXH0pgUSukAgAEvCfCAAXk8gP//62bg Date: Thu, 13 Dec 2012 15:57:32 +0000 Message-ID: References: <50C62D6A.8010709@gmail.com> <5808c090d8485cc6698829b522fade80.squirrel@www.trepanning.net> <50C9B0B5.9090600@secunet.com> In-Reply-To: <50C9B0B5.9090600@secunet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , Dan Harkins Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 15:57:59 -0000 > -----Original Message----- > From: Johannes Merkle [mailto:johannes.merkle@secunet.com] > Sent: Thursday, December 13, 2012 5:41 AM > To: Scott Fluhrer (sfluhrer) > Cc: Dan Harkins; Yaron Sheffer; IPsecme WG > Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks >=20 >=20 > > I'm positing an audience of people who know little about elliptic curve= s; > they have no idea about what a cofactor or a Sophie-Germain prime is. Al= l > they're interested in is trying to implement this protocol in a secure > manner, and want to dig into the mathematical details as little as possib= le. >=20 > Why not keeping the main document general and giving details for > registered groups in an appendix? Hmmmm, I like that suggestion. >=20 >=20 > > The reason I put the group numbers in the titles is to make it easier f= or an > implementer to decide, for a specific group, which section is appropriate= . > Perhaps another approach for achieving that goal would be better. >=20 > The mapping between the registered groups and the individual subsections > should be given in the appendix. >=20 >=20 > >> hQ !=3D point-at-infinity > > > > This is a cheap check (if h=3D2, I believe that's just a check that a c= oordinate > !=3D 0, and as you say below, it's even cheaper if h=3D1). However, is t= here a > specific attack that is possible if you don't do the check? If you're wo= rried > about someone modifying the DH public value with this value, IKE already > has protections against that in place. If you're worried about someone > learning the value of (e mod h) (where e is the private ECDH multiplier),= this > check doesn't prevent that. >=20 > You are right, this is exactly what Daniel has pointed out. Unfortunately= , in > case of a non-trivial cofactor, the check n*P !=3D 0 necessary to prevent= an > attacker from learning (e mod h) is not cheap at all. In that case, the > suggestion of Hugo applies as well, i.e. it is better to recommend not to > reuse DH keys for EC groups with non-trivial cofactor. Here's what I'm wrestling with; every curve that we currently support (and,= in fact, every prime curve I've heard anyone suggest) has h=3D1 (having h>= 1 makes the discrete log problem be a factor of sqrt(h) easier, for no bene= fit that I can see); hence, this cofactor test is moot. So, do we complica= te our description (at least, of the prime curve section) with a test that = never really applies? Now, if we do have a section covering even characteristic curves, those hav= e h>1 (the math pretty much forces that), and so a discussion there wouldn'= t be entirely out of place. On the other hand, there are standardized ways= of defining the ECDH operation so that the cofactor doesn't cause any leak= age ("ECC CDH", where the shared secret really is hxyG); if the group is de= fined using that primitive, such a cofactor test beforehand is unneeded. W= ill such a group use such a modified DH operation? Well, given that no suc= h groups are currently defined, we can't say. My opinion: in the prime curve section, there's no reason to mention a cofa= ctor; and that it's premature to put in an even characteristic curve sectio= n. >=20 > -- > Johannes From hilarie@purplestreak.com Wed Dec 12 12:50:57 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5289621E8034 for ; Wed, 12 Dec 2012 12:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfRFNU3iRNOy for ; Wed, 12 Dec 2012 12:50:49 -0800 (PST) Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by ietfa.amsl.com (Postfix) with ESMTP id 7541621E8037 for ; Wed, 12 Dec 2012 12:50:48 -0800 (PST) Received: from mx03.mta.xmission.com ([166.70.13.213]) by out01.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1TitGK-00006e-Hu; Wed, 12 Dec 2012 13:50:40 -0700 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=sylvester.rhmr.com) by mx03.mta.xmission.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1TitGI-0001S6-3I; Wed, 12 Dec 2012 13:50:40 -0700 Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.3/Debian-9.1ubuntu1) with ESMTP id qBCKnq6K010825; Wed, 12 Dec 2012 13:49:52 -0700 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id qBCKnqGg010823; Wed, 12 Dec 2012 13:49:52 -0700 Date: Wed, 12 Dec 2012 13:49:52 -0700 Message-Id: <201212122049.qBCKnqGg010823@sylvester.rhmr.com> From: "Hilarie Orman" To: sfluhrer@cisco.com In-reply-to: Yourmessage X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx03.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-SA-Exim-Connect-IP: 166.70.57.249 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;sfluhrer@cisco.com X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 14:26:46 -0700) X-SA-Exim-Scanned: Yes (on mx03.mta.xmission.com) X-Mailman-Approved-At: Thu, 13 Dec 2012 08:47:45 -0800 Cc: ipsec@ietf.org Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Hilarie Orman List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 20:50:57 -0000 > And what's a Sophie-Germain prime? Yes, I know (and definition you're using is not the definition that Ms. Germain originally gave it) The term came into mathematical parlance long after the death of the mathematician. Hilarie From ynir@checkpoint.com Thu Dec 13 09:20:47 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D353A21F8BBD for ; Thu, 13 Dec 2012 09:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cak1ZpkYc5X for ; Thu, 13 Dec 2012 09:20:46 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A4C4521F8BC3 for ; Thu, 13 Dec 2012 09:20:45 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id qBDHKgFk012633; Thu, 13 Dec 2012 19:20:42 +0200 X-CheckPoint: {50CA0DC6-2-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.238]) by IL-EX10.ad.checkpoint.com ([169.254.2.238]) with mapi id 14.02.0318.004; Thu, 13 Dec 2012 19:20:43 +0200 From: Yoav Nir To: Valery Smyslov Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-ike-tcp-01.txt Thread-Index: AQHN0aZ0+Cpu7UGWpE+FbQ2/NGD005gTj3v/gANYDgA= Date: Thu, 13 Dec 2012 17:20:42 +0000 Message-ID: <4613980CFC78314ABFD7F85CC30277210EDFD9D0@IL-EX10.ad.checkpoint.com> References: <20121203223404.5441.71025.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.57] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ike-tcp-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 17:20:47 -0000 Hi Valery Thinking it over, I kind of regret adding the port field to the TCP_SUPPORT= ED notification. We don't have any mechanism for alternate UDP ports. Yes, = UDP has cheap liveness checks to keep the mapping in the NAT so that reques= ts can be initiated to the original initiator, while TCP does not.=20 But your points are well taken. Leaving the advertised TCP port to configur= ation or auto-discovery is error prone and adds unnecessary complications t= o the protocol. =20 I propose that: 1. We remove the port from the Notify 2. All connections will be done to port 500. 3. We warn against trying to use TCP to a peer behind NAT This loses the ability to use port forwarding to have a reachable TCP port = (unless that port is 500), but I think the simplification justifies it. Yoav On Dec 11, 2012, at 2:16 PM, Valery Smyslov wrote: > Hi, >=20 > I'm a bit uncomfortable with the requirement that IKE peer "MUST" > advertise NAT device port if it is reachable and "MUST NOT" > if it isn't. I think, that IKE Initiator in most cases cannot > reliably determine whether it is reachable or not. For example, > even if you manually configured port forwarding on your home > network border NAT box and then configured IKE to advertise this > port, that wouldn't imply that this port is actually reachable > as your ISP may have another NAT and, as CGN become more > common, number of those nested NAT's will increase. > Even STUN might not be a good solution - it is pretty expensive in terms = of round trips, requires the presence of STUN server in the same network se= gment as IKE Responder, utilizes TLS and, most important, deals with UDP o= nly (AFAIK). >=20 > So, I think that the requirement for IKE Initiator to advertise > its support for TCP and port it thinks it is reachable at > should be listed as "SHOULD" or even "MAY". Otherwise > it sounds like a paradox - protocol requires IKE to do > or not to do some action depending on condition that IKE in most cases is= unable to determine. >=20 > Related issues. > - in description to TCP Port field in IKE_TCP_SUPPORTED Notification i= t is written that "If the sender is not subject to network address trans= lation, the port SHOULD be 500." Again, IKE Initiator > cannot reliably determine whether it is behind NAT or not. > It becomes clear only after initial request completes and > NAT_TRAVERSAL_*_IP are processed. > - as it is quite possible that the port advertised by IKE Initiator > in IKE_TCP_SUPPORTED Notification is actually not reachable, I think= it is worth to mention, that if original > Responder after IKE SA is established wants to make some request usi= ng TCP port advertised by > original Initiator and this port appears to be not reachable, > this Responder MUST NOT tear down IKE SA but MUST instead fall back = to UDP transport. >=20 > Regards, > Valery Smyslov. >=20 >=20 > Email secured by Check Point From paul.hoffman@vpnc.org Thu Dec 13 09:27:04 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A395821F8B1B for ; Thu, 13 Dec 2012 09:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceZFcaXBnU8f for ; Thu, 13 Dec 2012 09:27:04 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF9C21F8B96 for ; Thu, 13 Dec 2012 09:27:04 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qBDHQmXV039403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 10:26:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <4613980CFC78314ABFD7F85CC30277210EDFD9D0@IL-EX10.ad.checkpoint.com> Date: Thu, 13 Dec 2012 09:26:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <27020E4B-C496-4BC3-BA75-1AEC4FCC42EE@vpnc.org> References: <20121203223404.5441.71025.idtracker@ietfa.amsl.com> <4613980CFC78314ABFD7F85CC30277210EDFD9D0@IL-EX10.ad.checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1499) Cc: "" , Valery Smyslov Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ike-tcp-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 17:27:04 -0000 On Dec 13, 2012, at 9:20 AM, Yoav Nir wrote: > Hi Valery >=20 > Thinking it over, I kind of regret adding the port field to the = TCP_SUPPORTED notification. We don't have any mechanism for alternate = UDP ports. Yes, UDP has cheap liveness checks to keep the mapping in the = NAT so that requests can be initiated to the original initiator, while = TCP does not.=20 >=20 > But your points are well taken. Leaving the advertised TCP port to = configuration or auto-discovery is error prone and adds unnecessary = complications to the protocol. =20 >=20 > I propose that: > 1. We remove the port from the Notify > 2. All connections will be done to port 500. > 3. We warn against trying to use TCP to a peer behind NAT >=20 > This loses the ability to use port forwarding to have a reachable TCP = port (unless that port is 500), but I think the simplification justifies = it. +1. It was getting too complex and iffy. --Paul Hoffman= From vishwas.ietf@gmail.com Thu Dec 13 09:54:17 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FC621F8B01 for ; Thu, 13 Dec 2012 09:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.818 X-Spam-Level: X-Spam-Status: No, score=-2.818 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJ6iZZf+7-iN for ; Thu, 13 Dec 2012 09:54:16 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4769021F8533 for ; Thu, 13 Dec 2012 09:54:16 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id i20so3310460qad.10 for ; Thu, 13 Dec 2012 09:54:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hG4llqoi2etokspeMZyKznEdjoxzkZqvXbiCe0SNUrQ=; b=xW284hUlky92utirEIQ4vcGnN7c6wL91S3KuDs9U0DVlEtQYXYkT6N7ZP6Pn2saalI IpC2DtM+j4L2afUtja/ETZh63wFqFDCQrqBQGw53IbRf+Wi+sfx2zE+pwEHHbaKPDvjZ eVLwbDaLHfbFixy3dup05lBFnOkQc9Nr80voV8MfAwxYNR5skV4/aVMiB9VHYSDQRhkR GImVDk+O59M+RnATpxQ9VUW3ekA75CQKQxdknzFj7HolE44EyRRU7YhLfklx9j9MPU83 QNRuxc2MjlA2KUj/TKRFWb1OoxVqNrKCzgsFTLLyYbyCbLn6CYabFqX3wt89fFmzE9bz i6ag== MIME-Version: 1.0 Received: by 10.224.179.205 with SMTP id br13mr803666qab.37.1355421249388; Thu, 13 Dec 2012 09:54:09 -0800 (PST) Received: by 10.229.92.77 with HTTP; Thu, 13 Dec 2012 09:54:09 -0800 (PST) In-Reply-To: <0B592A71-6BE1-4988-8BA7-2F3CD61AD03A@cisco.com> References: <0B592A71-6BE1-4988-8BA7-2F3CD61AD03A@cisco.com> Date: Thu, 13 Dec 2012 09:54:09 -0800 Message-ID: From: Vishwas Manral To: Brian Weis Content-Type: multipart/alternative; boundary=485b397dcd5b17413804d0bf9a39 Cc: "vishwas.manral@hp.com" , ipsec@ietf.org, Stephen Hanna Subject: Re: [IPsec] Comments on proposed draft-ietf-ipsecme-ad-vpn-problem-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 17:54:17 -0000 --485b397dcd5b17413804d0bf9a39 Content-Type: text/plain; charset=ISO-8859-1 Hi Brian, Thanks a lot for your comments and sorry I did not reply immediately. I have still been waiting for the version 2 to upload. I have sent it to the internet-drafts@ietf.org address. My comments are inline and will be updated in version 03. We could do it in version 02 too if it does not get posted soon enough. The only issue I have is with the L3VPN comment and would want Lou Berger's opinion on it, as he thought the text would add value there (though if you see previous comments I am more of the opinion similar to yours). On Tue, Dec 11, 2012 at 12:30 PM, Brian Weis wrote: > Hi Steve & Vishwas, > > Here are a couple of comments on the proposed -02 sent a few days ago. > > Requirement 1 says "gateways and endpoints MUST minimize configuration > changes when a new gateway or endpoint is added, removed or changed." While > I certainly agree with the sentiment behind the requirement, this statement > is about as strong as "gateways and endpoints MUST perform well", or > "gateways and endpoints MUST be easy to use". In other words, it isn't a > testable assertion that can be evaluated. Also the body of the document > says "it is desired that there be minimal configuration on each gateway", > which does not support a MUST requirement. This ought to be a SHOULD rather > than a MUST. > Changed the MUST to a SHOULD. > Requirement 8 has gone through several versions, but I think it could > still be made clearer. It first requires Gateways and endpoints "to work > when they are behind NAT boxes", and then makes a bunch of necessary > exceptions. The following replacement text attempts to make the same points > as the original but might be clearer: > > 8. Gateways and endpoints MUST have the capability to participate > in an AD VPN even when they are located behind NAT boxes. However, > in some cases they may be deployed in such a way that they will not be > fully reachable behind a NAT box. It is especially difficult > to handle cases where the Hub is behind a NAT box. Where the > two endpoints are both behind separate NATs, communication between > these spokes SHOULD be supported using workarounds > such as port forwarding by the NAT or detecting when two spokes > are behind uncooperative NATs and using a hub in that case. > VM> Updated. > > Requirement 14 says "The ADVPN solution MUST support Provider Edge (PE) > based VPN's". This requirement seems unfair to the end point use cases in > 2.1 and 2.3, or even gateway-to-gateway ADVPN solutions that have nothing > to do with L3VPNs! I think you're trying to say it must be possible to > build an ADVPN solution that meets the requirements of L3VPN, which I have > no problem with but I don't think think this it's a fair requirement to put > in Section 4. Is there anything beyond the new text you added in 2.2 > regarding L3VPN that needs to be said? > VM> No I did not add any extra text for L3VPN besides this one. The idea was that if IPsec over GRE as PE to PE communication tunnels the ADVPN technology should not preclude such a solution.Like I have said earlier I do not have strong opinion regarding this requirement. Lou thought this should be there and I asked the list if there were objections to this, and I did not hear anyone object, so I added it. Lets try to hear from Lou on this. > > There's a couple remaining nits: > > Section 2.2: s/A fully meshed solution is would/A fully meshed solution > would/ > Section 4: s/This sectiondefines/This section defines/ > VM> Updated. Thanks, Vishwas > > Thanks, > Brian > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --485b397dcd5b17413804d0bf9a39 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Brian,

Thanks a lot for your comments and sorry I did not reply i= mmediately. I have still been waiting for the version 2 to upload. I have s= ent it to the internet-drafts@i= etf.org address.

My comments are inline and will be updated in version 03. We could do i= t in version 02 too if it does not get posted soon enough. The only issue I= have is with the L3VPN comment and would want Lou Berger's opinion on = it, as he thought the text would add value there (though if you see previou= s comments I am more of the opinion similar to yours).

On Tue, Dec 11, 2012 at 12:30 PM, Brian Weis= <b= ew@cisco.com> wrote:
Hi Steve & Vishwas,

Here are a couple of comments on the proposed -02 sent a few days ago.

Requirement 1 says "gateways and endpoints MUST minimize configuration= changes when a new gateway or endpoint is added, removed or changed."= While I certainly agree with the sentiment behind the requirement, this st= atement is about as strong as "gateways and endpoints MUST perform wel= l", or "gateways and endpoints MUST be easy to use". In othe= r words, it isn't a testable assertion that can be evaluated. Also the = body of the document says "it is desired that there be minimal configu= ration on each gateway", which does not support a MUST requirement. Th= is ought to be a SHOULD rather than a MUST.
Changed the MUST to a SHOULD.


Requirement 8 has gone through several versions, but I think it could still= be made clearer. It first requires Gateways and endpoints "to work wh= en they are behind NAT boxes", and then makes a bunch of necessary exc= eptions. The following replacement text attempts to make the same points as= the original but might be clearer:

=A0 =A08. =A0Gateways and endpoints MUST have the capability to participate=
=A0 =A0in an AD VPN even when they are located behind NAT boxes. However, =A0 =A0in some cases they may be deployed in such a way that they will not = be
=A0 =A0fully reachable behind a NAT box. =A0It is especially difficult
=A0 =A0to handle cases where the Hub is behind a NAT box. =A0Where the
=A0 =A0two endpoints are both behind separate NATs, communication between =A0 =A0these spokes SHOULD be supported using workarounds
=A0 =A0such as port forwarding by the NAT or detecting when two spokes
=A0 =A0are behind uncooperative NATs and using a hub in that case.
VM> Updated.

Requirement 14 says "The ADVPN solution MUST support Provider Edge (PE= ) based VPN's". This requirement seems unfair to the end point use= cases in 2.1 and 2.3, or even gateway-to-gateway ADVPN solutions that have= nothing to do with L3VPNs! I think you're trying to say it must be pos= sible to build an ADVPN solution that meets the requirements of L3VPN, whic= h I have no problem with but I don't think think this it's a fair r= equirement to put in Section 4. Is there anything beyond the new text you a= dded in 2.2 regarding L3VPN that needs to be said?
VM> No I did not add any extra text for L3VPN besides = this one. The idea was that if IPsec over GRE as PE to PE communication tun= nels the ADVPN technology should not preclude such a solution.Like I have s= aid earlier I do not have strong opinion regarding this requirement. Lou th= ought this should be there and I asked the list if there were objections to= this, and I did not hear anyone object, so I added it.
=A0
Lets try to hear from Lou on this.

There's a couple remaining nits:

Section 2.2: s/A fully meshed solution is would/A fully meshed solution wou= ld/
Section 4: s/This sectiondefines/This section defines/
VM> Updated.

Thanks,
Vishwas

Thanks,
Brian

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

--485b397dcd5b17413804d0bf9a39-- From bew@cisco.com Thu Dec 13 13:48:19 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE15321F86C2 for ; Thu, 13 Dec 2012 13:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-w4pf69v7fT for ; Thu, 13 Dec 2012 13:48:18 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id A9B6F21F8653 for ; Thu, 13 Dec 2012 13:48:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12424; q=dns/txt; s=iport; t=1355435298; x=1356644898; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=DszcbJN7mfI2Q/pbhgKe3CRhYx3jVGyvf6tHcojJLJg=; b=f7P+oZGKmbHCBB07AfEiXEo7YiJV3ilGhJOkWxxc+JWFVfI46QvTCB3c nZVp5D/CMSCfYiZxj8iFJaQxnxtWx75QiFYdQmd3Uuhz4vAiAKYSz2wg3 vKZoLIyOp7FbHoivs1wx7+sPRaBR7OG6Sw/cdWB/abOHvb2/DTzv/vF71 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigHAPZMylCrRDoH/2dsb2JhbABFg0i7KBZzgh4BAQEDAQEBAWsLBQsLGC4hBjAGExuHZgMJBQEMsyENiVEEi25pg2JhA4hgi1OBVos3hRGDFA X-IronPort-AV: E=Sophos;i="4.84,276,1355097600"; d="scan'208,217";a="66499568" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 13 Dec 2012 21:48:07 +0000 Received: from dhcp-128-107-147-77.cisco.com (dhcp-128-107-147-77.cisco.com [128.107.147.77]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBDLm7Wn008567 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 21:48:07 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_FE874739-0BB3-4B47-BC5A-AF6CE1C1309F" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Weis In-Reply-To: Date: Thu, 13 Dec 2012 13:48:06 -0800 Message-Id: <154376FC-F5D4-472F-B321-5B2ED0C5CA2C@cisco.com> References: <0B592A71-6BE1-4988-8BA7-2F3CD61AD03A@cisco.com> To: Vishwas Manral X-Mailer: Apple Mail (2.1499) Cc: "vishwas.manral@hp.com" , ipsec@ietf.org, Stephen Hanna Subject: Re: [IPsec] Comments on proposed draft-ietf-ipsecme-ad-vpn-problem-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 21:48:19 -0000 --Apple-Mail=_FE874739-0BB3-4B47-BC5A-AF6CE1C1309F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Vishwas, See a couple of notes inline. On Dec 13, 2012, at 9:54 AM, Vishwas Manral = wrote: > Hi Brian, >=20 > Thanks a lot for your comments and sorry I did not reply immediately. = I have still been waiting for the version 2 to upload. I have sent it to = the internet-drafts@ietf.org address. >=20 > My comments are inline and will be updated in version 03. We could do = it in version 02 too if it does not get posted soon enough. Updating version 03 is fine with me. I was a bit late with the comments. > The only issue I have is with the L3VPN comment and would want Lou = Berger's opinion on it, as he thought the text would add value there = (though if you see previous comments I am more of the opinion similar to = yours). >=20 > On Tue, Dec 11, 2012 at 12:30 PM, Brian Weis wrote: > Hi Steve & Vishwas, >=20 > Here are a couple of comments on the proposed -02 sent a few days ago. >=20 > Requirement 1 says "gateways and endpoints MUST minimize configuration = changes when a new gateway or endpoint is added, removed or changed." = While I certainly agree with the sentiment behind the requirement, this = statement is about as strong as "gateways and endpoints MUST perform = well", or "gateways and endpoints MUST be easy to use". In other words, = it isn't a testable assertion that can be evaluated. Also the body of = the document says "it is desired that there be minimal configuration on = each gateway", which does not support a MUST requirement. This ought to = be a SHOULD rather than a MUST. > Changed the MUST to a SHOULD.=20 >=20 >=20 > Requirement 8 has gone through several versions, but I think it could = still be made clearer. It first requires Gateways and endpoints "to work = when they are behind NAT boxes", and then makes a bunch of necessary = exceptions. The following replacement text attempts to make the same = points as the original but might be clearer: >=20 > 8. Gateways and endpoints MUST have the capability to participate > in an AD VPN even when they are located behind NAT boxes. However, > in some cases they may be deployed in such a way that they will not = be > fully reachable behind a NAT box. It is especially difficult > to handle cases where the Hub is behind a NAT box. Where the > two endpoints are both behind separate NATs, communication between > these spokes SHOULD be supported using workarounds > such as port forwarding by the NAT or detecting when two spokes > are behind uncooperative NATs and using a hub in that case. > VM> Updated.=20 >=20 > Requirement 14 says "The ADVPN solution MUST support Provider Edge = (PE) based VPN's". This requirement seems unfair to the end point use = cases in 2.1 and 2.3, or even gateway-to-gateway ADVPN solutions that = have nothing to do with L3VPNs! I think you're trying to say it must be = possible to build an ADVPN solution that meets the requirements of = L3VPN, which I have no problem with but I don't think think this it's a = fair requirement to put in Section 4. Is there anything beyond the new = text you added in 2.2 regarding L3VPN that needs to be said? > VM> No I did not add any extra text for L3VPN besides this one. The = idea was that if IPsec over GRE as PE to PE communication tunnels the = ADVPN technology should not preclude such a solution.Like I have said = earlier I do not have strong opinion regarding this requirement. Lou = thought this should be there and I asked the list if there were = objections to this, and I did not hear anyone object, so I added it. > =20 Thanks for the background. It should be possible to address Lou's = concern underlying concern without adding a requirement that is onerous = for ADVPN use cases where L3VPN doesn't apply. The Section 2.2 text I = referred to is "There is also the case when L3VPNs operate over IPsec = Tunnels." Maybe that could be expanded into a new paragraph in lieu of a = requirement? I notice the use of lower case "must" is used in this = section.=20 > Lets try to hear from Lou on this. Lou, would something like the following text in Section 2.2 be a = satisfactory replacement for Requirement 14? There is also the case when L3VPNs operate over IPsec Tunnels,=20 for example Provider Edge (PE) based VPN's. An AD VPN must support L3VPN as an application protected by the IPsec Tunnels. Thanks, Brian >=20 > There's a couple remaining nits: >=20 > Section 2.2: s/A fully meshed solution is would/A fully meshed = solution would/ > Section 4: s/This sectiondefines/This section defines/ > VM> Updated. >=20 > Thanks, > Vishwas=20 >=20 > Thanks, > Brian >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 --Apple-Mail=_FE874739-0BB3-4B47-BC5A-AF6CE1C1309F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Vishwas,

See a couple of notes = inline.

On Dec 13, 2012, at 9:54 AM, Vishwas = Manral <vishwas.ietf@gmail.com> = wrote:

Hi Brian,

Thanks a lot for your comments = and sorry I did not reply immediately. I have still been waiting for the = version 2 to upload. I have sent it to the internet-drafts@ietf.org = address.

My comments are inline and will be updated in version 03. We could = do it in version 02 too if it does not get posted soon enough. =

Updating version 03 is fine with me. I = was a bit late with the comments.

The = only issue I have is with the L3VPN comment and would want Lou Berger's = opinion on it, as he thought the text would add value there (though if = you see previous comments I am more of the opinion similar to = yours).

On Tue, Dec 11, 2012 at 12:30 PM, Brian = Weis <bew@cisco.com> wrote:
Hi Steve & Vishwas,

Here are a couple of comments on the proposed -02 sent a few days = ago.

Requirement 1 says "gateways and endpoints MUST minimize configuration = changes when a new gateway or endpoint is added, removed or changed." = While I certainly agree with the sentiment behind the requirement, this = statement is about as strong as "gateways and endpoints MUST perform = well", or "gateways and endpoints MUST be easy to use". In other words, = it isn't a testable assertion that can be evaluated. Also the body of = the document says "it is desired that there be minimal configuration on = each gateway", which does not support a MUST requirement. This ought to = be a SHOULD rather than a MUST.
Changed the MUST to a SHOULD. =


Requirement 8 has gone through several versions, but I think it could = still be made clearer. It first requires Gateways and endpoints "to work = when they are behind NAT boxes", and then makes a bunch of necessary = exceptions. The following replacement text attempts to make the same = points as the original but might be clearer:

   8.  Gateways and endpoints MUST have the capability to = participate
   in an AD VPN even when they are located behind NAT boxes. = However,
   in some cases they may be deployed in such a way that they = will not be
   fully reachable behind a NAT box.  It is especially = difficult
   to handle cases where the Hub is behind a NAT box. =  Where the
   two endpoints are both behind separate NATs, communication = between
   these spokes SHOULD be supported using workarounds
   such as port forwarding by the NAT or detecting when two = spokes
   are behind uncooperative NATs and using a hub in that = case.
VM> Updated.

Requirement 14 says "The ADVPN solution MUST support Provider Edge (PE) = based VPN's". This requirement seems unfair to the end point use cases = in 2.1 and 2.3, or even gateway-to-gateway ADVPN solutions that have = nothing to do with L3VPNs! I think you're trying to say it must be = possible to build an ADVPN solution that meets the requirements of = L3VPN, which I have no problem with but I don't think think this it's a = fair requirement to put in Section 4. Is there anything beyond the new = text you added in 2.2 regarding L3VPN that needs to be said?
VM> No I did not add any extra text for L3VPN = besides this one. The idea was that if IPsec over GRE as PE to PE = communication tunnels the ADVPN technology should not preclude such a = solution.Like I have said earlier I do not have strong opinion regarding = this requirement. Lou thought this should be there and I asked the list = if there were objections to this, and I did not hear anyone object, so I = added it.
 

Thanks for = the background. It should be possible to address Lou's concern = underlying  concern without adding a requirement that is onerous = for ADVPN use cases where L3VPN doesn't apply. The Section 2.2 text I = referred to is "There is also the case when L3VPNs operate over = IPsec Tunnels." Maybe that could be expanded into a new paragraph in = lieu of a requirement? I notice the use of lower case "must" is used in = this section. 

Lets try to hear from Lou on = this.

Lou, would = something like the following text in Section 2.2 be a satisfactory = replacement for Requirement 14?

  =   There is also the case when L3VPNs operate over IPsec = Tunnels, 
    for example Provider Edge = (PE) based VPN's. An AD VPN must
    support L3VPN = as an application protected by the IPsec
    = Tunnels.

Thanks,
Brian


There's a couple remaining nits:

Section 2.2: s/A fully meshed solution is would/A fully meshed solution = would/
Section 4: s/This sectiondefines/This section = defines/
VM> Updated.

Thanks,
Vishwas =

Thanks,
Brian

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


= --Apple-Mail=_FE874739-0BB3-4B47-BC5A-AF6CE1C1309F-- From lberger@labn.net Thu Dec 13 14:00:39 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223B821F8A32 for ; Thu, 13 Dec 2012 14:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.518 X-Spam-Level: X-Spam-Status: No, score=-101.518 tagged_above=-999 required=5 tests=[AWL=-0.453, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJhiYuxJOKrJ for ; Thu, 13 Dec 2012 14:00:38 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 6F4D321F8A15 for ; Thu, 13 Dec 2012 14:00:38 -0800 (PST) Received: (qmail 7185 invoked by uid 0); 13 Dec 2012 22:00:16 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 13 Dec 2012 22:00:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=/R0+tr5XLbJJNFYDTcPEagTeaNWoNJnmtzuN6QDpDIw=; b=TXeHDY/vPs9JtJ+jRQ5BTIhvyO5PKhjIZLXXFXW5VYKnqmqwAdPXgBZajeBj6r319GmmEGCPO2C7XecZ3yrryKgnj6JnfM4U0L/CJ6gVuHxTIQtP/1T/SoS+UqzAVQPr; Received: from box313.bluehost.com ([69.89.31.113]:53022 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TjGpE-0001IL-LA; Thu, 13 Dec 2012 15:00:16 -0700 Message-ID: <50CA4FF0.9030405@labn.net> Date: Thu, 13 Dec 2012 17:00:16 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Vishwas Manral References: <0B592A71-6BE1-4988-8BA7-2F3CD61AD03A@cisco.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "vishwas.manral@hp.com" , ipsec@ietf.org, Stephen Hanna , Brian Weis Subject: Re: [IPsec] Comments on proposed draft-ietf-ipsecme-ad-vpn-problem-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:00:39 -0000 Vishwas / Brian, See below On 12/13/2012 12:54 PM, Vishwas Manral wrote: > Hi Brian, > > Thanks a lot for your comments and sorry I did not reply immediately. I > have still been waiting for the version 2 to upload. I have sent it to > the internet-drafts@ietf.org address. > > My comments are inline and will be updated in version 03. We could do it > in version 02 too if it does not get posted soon enough. The only issue > I have is with the L3VPN comment and would want Lou Berger's opinion on > it, as he thought the text would add value there (though if you see > previous comments I am more of the opinion similar to yours). > > On Tue, Dec 11, 2012 at 12:30 PM, Brian Weis > wrote: > > Hi Steve & Vishwas, > > Here are a couple of comments on the proposed -02 sent a few days ago. > ... > Requirement 14 says "The ADVPN solution MUST support Provider Edge > (PE) based VPN's". This requirement seems unfair to the end point > use cases in 2.1 and 2.3, or even gateway-to-gateway ADVPN solutions > that have nothing to do with L3VPNs! Agreed, but the requirement is on the solution, not on a particular implementation. > I think you're trying to say it > must be possible to build an ADVPN solution that meets the > requirements of L3VPN, which I have no problem Yes, this was my basic point. > with but I don't > think think this it's a fair requirement to put in Section 4. I agree, it's not fair to have this as a specific implementation requirement, but I think it's fair that this case must be supported by the overall solution -- which is simply the previous point. > Is > there anything beyond the new text you added in 2.2 regarding L3VPN > that needs to be said? > > VM> No I did not add any extra text for L3VPN besides this one. The idea > was that if IPsec over GRE as PE to PE communication tunnels the ADVPN > technology should not preclude such a solution.Like I have said earlier > I do not have strong opinion regarding this requirement. Lou thought > this should be there and I asked the list if there were objections to > this, and I did not hear anyone object, so I added it. > > Lets try to hear from Lou on this. > > ... I think I've covered it above. Much thanks, Lou From dharkins@lounge.org Thu Dec 13 14:58:59 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CE221F8B11 for ; Thu, 13 Dec 2012 14:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yd78WBmJ0xJe for ; Thu, 13 Dec 2012 14:58:58 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id AC5BF21F8B0C for ; Thu, 13 Dec 2012 14:58:58 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 211701022400A; Thu, 13 Dec 2012 14:58:57 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 13 Dec 2012 14:58:58 -0800 (PST) Message-ID: In-Reply-To: References: <50C62D6A.8010709@gmail.com> <5808c090d8485cc6698829b522fade80.squirrel@www.trepanning.net> <50C9B0B5.9090600@secunet.com> Date: Thu, 13 Dec 2012 14:58:58 -0800 (PST) From: "Dan Harkins" To: "Scott Fluhrer (sfluhrer)" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: IPsecme WG , Johannes Merkle , Dan Harkins Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 22:58:59 -0000 On Thu, December 13, 2012 7:57 am, Scott Fluhrer (sfluhrer) wrote: > >> -----Original Message----- >> From: Johannes Merkle [mailto:johannes.merkle@secunet.com] >> Sent: Thursday, December 13, 2012 5:41 AM >> To: Scott Fluhrer (sfluhrer) >> Cc: Dan Harkins; Yaron Sheffer; IPsecme WG >> Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks >> >> > I'm positing an audience of people who know little about elliptic >> curves; >> they have no idea about what a cofactor or a Sophie-Germain prime is. >> All >> they're interested in is trying to implement this protocol in a secure >> manner, and want to dig into the mathematical details as little as >> possible. >> >> Why not keeping the main document general and giving details for >> registered groups in an appendix? > > Hmmmm, I like that suggestion. That's a great suggestion. Yaron also mentioned the idea of adding a note column to the DH group repository that references the particular section of your draft (instruct IANA to update the registry with the section and the RFC number that gets assigned to your draft). I think both of those would be good. > Here's what I'm wrestling with; every curve that we currently support > (and, in fact, every prime curve I've heard anyone suggest) has h=1 > (having h>1 makes the discrete log problem be a factor of sqrt(h) easier, > for no benefit that I can see); hence, this cofactor test is moot. So, do > we complicate our description (at least, of the prime curve section) with > a test that never really applies? Maybe not. It might make sense to say that all the curves have an implied co-factor of 1 though. > Now, if we do have a section covering even characteristic curves, those > have h>1 (the math pretty much forces that), and so a discussion there > wouldn't be entirely out of place. On the other hand, there are > standardized ways of defining the ECDH operation so that the cofactor > doesn't cause any leakage ("ECC CDH", where the shared secret really is > hxyG); if the group is defined using that primitive, such a cofactor test > beforehand is unneeded. Will such a group use such a modified DH > operation? Well, given that no such groups are currently defined, we > can't say. > > My opinion: in the prime curve section, there's no reason to mention a > cofactor; and that it's premature to put in an even characteristic curve > section. OK, I agree with the former, but why not just cover all the possibilities by mentioning the characteristic curves? It's supposed to be a forward- looking document that's placing requirements on future RFCs that add new groups and there's no reason why someone couldn't add such a curve. I think it would be cleaner to have everything covered here instead of having this one mention 3 of 4 and another RFC mention the 4th. Dan. From svanru@gmail.com Thu Dec 13 21:37:26 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985C121F8929 for ; Thu, 13 Dec 2012 21:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umo2pxNGD8Ix for ; Thu, 13 Dec 2012 21:37:16 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 750AB21F897E for ; Thu, 13 Dec 2012 21:37:16 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2433202lbk.31 for ; Thu, 13 Dec 2012 21:37:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=zQWcy+aBmFxagbj/Fg4Xk0yJRzGCGxWzXZ7xdsA+GUw=; b=hJ250cZ5SfcFUBjnFnAnunZdvkidJhrH9MYufo3lGdh6JyTG1qWyaM47TsyyUy/92f q7Nrk/VTwHJynob2O3DvJ/XNwquAcQ41Og4bEAPRn2ggPwuGrH0xomPzQcNSKg+Ywix9 3cCNjMIW4lK47EpbGYHPcHsgVlCALNFLOoawKoNegkpsimcRgTjGGcHfzxP16j2SI0YV c/XBrPI2JL1CddXHJFUxYifDq/0zhWUPccPvouAc78eWHtqb+cGE6X4lZR+MKiwFMjFQ BGvgHFAUlIJdqeghI5i6xtgxqNfjiozDZfetlO8SFRoYDDR8MclPVlBJIysxj7kM4XyC LEwQ== Received: by 10.152.112.36 with SMTP id in4mr1514176lab.35.1355463435345; Thu, 13 Dec 2012 21:37:15 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPS id fb1sm1434342lbb.15.2012.12.13.21.37.12 (version=SSLv3 cipher=OTHER); Thu, 13 Dec 2012 21:37:14 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Yoav Nir" References: <20121203223404.5441.71025.idtracker@ietfa.amsl.com> <4613980CFC78314ABFD7F85CC30277210EDFD9D0@IL-EX10.ad.checkpoint.com> Date: Fri, 14 Dec 2012 09:37:06 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ike-tcp-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 05:37:27 -0000 Hi Yoav, > Hi Valery > > Thinking it over, I kind of regret adding the port field to the > TCP_SUPPORTED notification. > We don't have any mechanism for alternate UDP ports. Yes, UDP has cheap > liveness checks > to keep the mapping in the NAT so that requests can be initiated to the > original initiator, while TCP does not. > > But your points are well taken. Leaving the advertised TCP port to > configuration or auto-discovery is error > prone and adds unnecessary complications to the protocol. > > I propose that: > 1. We remove the port from the Notify > 2. All connections will be done to port 500. > 3. We warn against trying to use TCP to a peer behind NAT Fully agree. And in this case please add the following to the list: 4. We remove TCP_SUPPORTED notification from Initiator's message (as it becomes redundant for most use cases). > This loses the ability to use port forwarding to have a reachable TCP port > (unless that port is 500), > but I think the simplification justifies it. Agree. Valery. > Yoav From paul@nohats.ca Thu Dec 13 22:04:37 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83EC721F888E for ; Thu, 13 Dec 2012 22:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odWBxZqLDaJH for ; Thu, 13 Dec 2012 22:04:36 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4401221F8882 for ; Thu, 13 Dec 2012 22:04:35 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id A4B4B829B2; Fri, 14 Dec 2012 01:03:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 97DEC829A3; Fri, 14 Dec 2012 01:03:30 -0500 (EST) Date: Fri, 14 Dec 2012 01:03:30 -0500 (EST) From: Paul Wouters To: Valery Smyslov In-Reply-To: Message-ID: References: <20121203223404.5441.71025.idtracker@ietfa.amsl.com> <4613980CFC78314ABFD7F85CC30277210EDFD9D0@IL-EX10.ad.checkpoint.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ike-tcp-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 06:04:37 -0000 On Fri, 14 Dec 2012, Valery Smyslov wrote: >> Thinking it over, I kind of regret adding the port field to the >> TCP_SUPPORTED notification. >> We don't have any mechanism for alternate UDP ports. Yes, UDP has cheap >> liveness checks >> to keep the mapping in the NAT so that requests can be initiated to the >> original initiator, while TCP does not. >> >> But your points are well taken. Leaving the advertised TCP port to >> configuration or auto-discovery is error >> prone and adds unnecessary complications to the protocol. >> >> I propose that: >> 1. We remove the port from the Notify >> 2. All connections will be done to port 500. >> 3. We warn against trying to use TCP to a peer behind NAT That's too bad, but I agree it added a lot of complexity. What is the blocking rate for TCP 500 in the wild? And does anyone know why Cisco moved to port 10000? A higher port does seem to have a better chance at not being blocked. > Fully agree. And in this case please add the following to the list: > 4. We remove TCP_SUPPORTED notification from Initiator's message > (as it becomes redundant for most use cases). So if the responder falls back to TCP, and later becomes the initiator, should it assume TCP 500 is available, or do we go through another round of udp fail to tcp? As implementor, I see no issue remembering TCP is supported as longe as we have a parent SA. We don't need the TCP_SUPPORTED notification in the original initiator for that. But firewall rules might not be symmetric, and an outgoing TCP might work while an incoming TCP is blocked. But I guess if UDP isn't working well, there is not much choice left but try TCP. Paul From lberger@labn.net Fri Dec 14 10:15:25 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E03121F8A9B for ; Fri, 14 Dec 2012 10:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.464 X-Spam-Level: X-Spam-Status: No, score=-101.464 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7weReZEUvnD for ; Fri, 14 Dec 2012 10:15:24 -0800 (PST) Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 78C4A21F8A90 for ; Fri, 14 Dec 2012 10:15:24 -0800 (PST) Received: (qmail 31763 invoked by uid 0); 14 Dec 2012 18:15:00 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 14 Dec 2012 18:15:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=2sevO7JFVaOiN8dzpAFQm/3JCGcZE5AmqYckCgAN1/g=; b=yh/n6vO9MXk317zoMmySXqkJqFYnW6qM5HMNYDaF3mf2PE4Wy1PYl9mBEtPjEvLbwPOIrbr1qAlOKEn6aooRUS0H+dWh8FwViDrLjVhJQv2ZCy7XvWY6XSplm8NME2Zr; Received: from box313.bluehost.com ([69.89.31.113]:55293 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TjZml-0005h7-Lt; Fri, 14 Dec 2012 11:15:00 -0700 Message-ID: <50CB6CA4.3020806@labn.net> Date: Fri, 14 Dec 2012 13:15:00 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Brian Weis References: <0B592A71-6BE1-4988-8BA7-2F3CD61AD03A@cisco.com> <154376FC-F5D4-472F-B321-5B2ED0C5CA2C@cisco.com> In-Reply-To: <154376FC-F5D4-472F-B321-5B2ED0C5CA2C@cisco.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "vishwas.manral@hp.com" , Stephen Hanna , ipsec@ietf.org Subject: Re: [IPsec] Comments on proposed draft-ietf-ipsecme-ad-vpn-problem-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 18:15:25 -0000 Brian, Opps, should have replied to this message (and not the prior). My previous mail basically said the new requirement is placed on the ADVPN solution, not a particular implementation. I think it's important to ensure that the overall solution provides for Requirement 14, and I'm not sure how this can be done without a requirement. See below for additional specific responses. On 12/13/2012 4:48 PM, Brian Weis wrote: > Hi Vishwas, > > See a couple of notes inline. > > On Dec 13, 2012, at 9:54 AM, Vishwas Manral > wrote: > >> Hi Brian, ... >> Requirement 14 says "The ADVPN solution MUST support Provider Edge >> (PE) based VPN's". This requirement seems unfair to the end point >> use cases in 2.1 and 2.3, or even gateway-to-gateway ADVPN >> solutions that have nothing to do with L3VPNs! I think you're >> trying to say it must be possible to build an ADVPN solution that >> meets the requirements of L3VPN, which I have no problem with but >> I don't think think this it's a fair requirement to put in Section >> 4. Is there anything beyond the new text you added in 2.2 >> regarding L3VPN that needs to be said? >> >> VM> No I did not add any extra text for L3VPN besides this one. The >> idea was that if IPsec over GRE as PE to PE communication tunnels the >> ADVPN technology should not preclude such a solution.Like I have said >> earlier I do not have strong opinion regarding this requirement. Lou >> thought this should be there and I asked the list if there were >> objections to this, and I did not hear anyone object, so I added it. >> > > Thanks for the background. It should be possible to address Lou's > concern underlying concern without adding a requirement that is onerous > for ADVPN use cases where L3VPN doesn't apply. I agree there implementation cases where the requirement doesn't apply. This is why the requirement was phrased as being a requirement on the overall solution, not on as an implementation requirement. > The Section 2.2 text I > referred to is "There is also the case when L3VPNs operate over IPsec > Tunnels." Maybe that could be expanded into a new paragraph in lieu of a > requirement? I notice the use of lower case "must" is used in this section. > >> Lets try to hear from Lou on this. > > Lou, would something like the following text in Section 2.2 be a > satisfactory replacement for Requirement 14? > > There is also the case when L3VPNs operate over IPsec Tunnels, > for example Provider Edge (PE) based VPN's. An AD VPN must > support L3VPN as an application protected by the IPsec > Tunnels. it he must was a MUST, sure. Lou > > Thanks, > Brian > >> >> There's a couple remaining nits: >> >> Section 2.2: s/A fully meshed solution is would/A fully meshed >> solution would/ >> Section 4: s/This sectiondefines/This section defines/ >> >> VM> Updated. >> >> Thanks, >> Vishwas >> >> >> Thanks, >> Brian >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From Internet-Drafts@ietf.org Fri Dec 14 13:51:15 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1938A21F8AB9; Fri, 14 Dec 2012 13:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsKAqJTnduYu; Fri, 14 Dec 2012 13:51:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D40421F8AAC; Fri, 14 Dec 2012 13:51:10 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121214215110.20089.32721.idtracker@ietfa.amsl.com> Date: Fri, 14 Dec 2012 13:51:10 -0800 Cc: ipsec@ietf.org Subject: [IPsec] I-D ACTION:draft-ietf-ipsecme-ad-vpn-problem-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 21:51:15 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Auto Discovery VPN Problem Statement and Requirements Author(s) : S. Hanna, et al Filename : draft-ietf-ipsecme-ad-vpn-problem Pages : 16 Date : Dec. 14, 2012 This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements, for such a solution. Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases the IP address of endpoints change or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto Discovery VPN solution is chartered to address these requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ad-vpn-problem-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ad-vpn-problem"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-12-14135107.I-D@ietf.org> --NextPart-- From bew@cisco.com Fri Dec 14 13:56:27 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB4121F89F9 for ; Fri, 14 Dec 2012 13:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.849 X-Spam-Level: X-Spam-Status: No, score=-109.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1qd2qfLdWp0 for ; Fri, 14 Dec 2012 13:56:23 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id D167A21F88F5 for ; Fri, 14 Dec 2012 13:56:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1433; q=dns/txt; s=iport; t=1355522184; x=1356731784; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=QzYJmDnX0k1JOP6S3XCgWZbGh4wGT5udhfCc8i5kDRE=; b=KVstqp0frZxLaRXTJts1fu0H47xT3knywiiDfA9PZizPEj5h8L13ZZK3 87i0PqY4AfEtBBmc1hdk+5DZqBiUcp7aMfR2TVPgIR9nujxDF6RLmzDJs OXW8dXT3RVAcUo7W4vpnV3Mb4TlrqDmCTg1kJEkjRrOUZO3YrT4DKLnHT E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkIAP6fy1CrRDoI/2dsb2JhbABFg0i7QxZzgh4BAQEDAXkFCwsOOFcGExuHcgUBvRmMVxuDR2EDiGCJPINtkEiDFIFM X-IronPort-AV: E=Sophos;i="4.84,284,1355097600"; d="scan'208";a="66594166" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 14 Dec 2012 21:56:23 +0000 Received: from dhcp-128-107-147-77.cisco.com (dhcp-128-107-147-77.cisco.com [128.107.147.77]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBELuNKt003537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Dec 2012 21:56:23 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Weis In-Reply-To: <50CB6CA4.3020806@labn.net> Date: Fri, 14 Dec 2012 13:56:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9D8C5AA9-B072-445C-813E-FA187ED75BCE@cisco.com> References: <0B592A71-6BE1-4988-8BA7-2F3CD61AD03A@cisco.com> <154376FC-F5D4-472F-B321-5B2ED0C5CA2C@cisco.com> <50CB6CA4.3020806@labn.net> To: Lou Berger X-Mailer: Apple Mail (2.1499) Cc: "vishwas.manral@hp.com" , Stephen Hanna , ipsec@ietf.org Subject: Re: [IPsec] Comments on proposed draft-ietf-ipsecme-ad-vpn-problem-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 21:56:28 -0000 Hi Lou, On Dec 14, 2012, at 10:15 AM, Lou Berger wrote: > Brian, > Opps, should have replied to this message (and not the prior). >=20 > My previous mail basically said the new requirement is placed on the > ADVPN solution, not a particular implementation. I think it's = important > to ensure that the overall solution provides for Requirement 14, and = I'm > not sure how this can be done without a requirement. If I understand correctly, these requirements are intending to be = relevant to "ADVPN solutions" that don't include network infrastructure. = It doesn't make sense to me to make a "ADVPN solution" implemented on = PCs and comprised exclusively of PCs subject to this as a general = requirement. All other MUST requirements in Section 4 seem to apply equally to all = use cases. >=20 > See below for additional specific responses. [snip] >> Lou, would something like the following text in Section 2.2 be a >> satisfactory replacement for Requirement 14? >>=20 >> There is also the case when L3VPNs operate over IPsec Tunnels,=20 >> for example Provider Edge (PE) based VPN's. An AD VPN must >> support L3VPN as an application protected by the IPsec >> Tunnels. >=20 > it he must was a MUST, sure. I'd happily support a MUST here. There aren't any other MUSTs outside of = Section 4, but I don't know why. Thanks, Brian >=20 > Lou From vishwas.ietf@gmail.com Fri Dec 14 14:09:32 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2DB921F8983 for ; Fri, 14 Dec 2012 14:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.78 X-Spam-Level: X-Spam-Status: No, score=-2.78 tagged_above=-999 required=5 tests=[AWL=-0.382, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0l7v2oSnS5BL for ; Fri, 14 Dec 2012 14:09:32 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id EB4D921F89E6 for ; Fri, 14 Dec 2012 14:09:31 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id i20so1173293qad.10 for ; Fri, 14 Dec 2012 14:09:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Xw5ni/wl5FYMoiWbuEOnU2h3U++uZh5kkGbENq62IRs=; b=qys60rEh8mW9mcyvl1m2Q6+HPdd0ZTrq6djl+KRej4cXPKl4KjPXEG7ED8b3Bzf3MR cBwy0m0gucYzdHa4xpPc/XjZc7sBVwGau3Wlxw/tM8qClP2e30XJnpl+NCzXkBT3QNAX 5RpzL1dHdTeCS5v328ywVmXfgqFAHz/nguccBEdzHptDPzOTR7s7uD0xSIg4kT5Q3kv9 sVFzLD4S9hauyadyDt+w7IJ8EU09v/fDPQ+j/4v4B8ewTjoCOJhw3+P382qbkk/74g/f zUlBk9M9aPbfGTB5l3gG2+mpWH7NEXPY7YYgBBC4TNQPFENQ5ViHv81+Zcc3V3K1Ie7y rdbQ== MIME-Version: 1.0 Received: by 10.49.118.138 with SMTP id km10mr3596176qeb.18.1355522971446; Fri, 14 Dec 2012 14:09:31 -0800 (PST) Received: by 10.229.92.77 with HTTP; Fri, 14 Dec 2012 14:09:31 -0800 (PST) In-Reply-To: <9D8C5AA9-B072-445C-813E-FA187ED75BCE@cisco.com> References: <0B592A71-6BE1-4988-8BA7-2F3CD61AD03A@cisco.com> <154376FC-F5D4-472F-B321-5B2ED0C5CA2C@cisco.com> <50CB6CA4.3020806@labn.net> <9D8C5AA9-B072-445C-813E-FA187ED75BCE@cisco.com> Date: Fri, 14 Dec 2012 14:09:31 -0800 Message-ID: From: Vishwas Manral To: Brian Weis Content-Type: multipart/alternative; boundary=047d7b6d97a232ac5904d0d74947 Cc: "vishwas.manral@hp.com" , ipsec@ietf.org, Stephen Hanna , Lou Berger Subject: Re: [IPsec] Comments on proposed draft-ietf-ipsecme-ad-vpn-problem-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 22:09:32 -0000 --047d7b6d97a232ac5904d0d74947 Content-Type: text/plain; charset=ISO-8859-1 Hi Brian/ Lou, So as a resolution for this, the only change required would be replacing the requirement to: There is also the case when L3VPNs operate over IPsec Tunnels, for example Provider Edge (PE) based VPN's. An ADVPN MUST support L3VPN as an application protected by the IPsec Tunnels. I can do that now and post the new version of the draft across. Thanks, Vishwas ===================================================== On Fri, Dec 14, 2012 at 1:56 PM, Brian Weis wrote: > Hi Lou, > > On Dec 14, 2012, at 10:15 AM, Lou Berger wrote: > > > Brian, > > Opps, should have replied to this message (and not the prior). > > > > My previous mail basically said the new requirement is placed on the > > ADVPN solution, not a particular implementation. I think it's important > > to ensure that the overall solution provides for Requirement 14, and I'm > > not sure how this can be done without a requirement. > > If I understand correctly, these requirements are intending to be relevant > to "ADVPN solutions" that don't include network infrastructure. It doesn't > make sense to me to make a "ADVPN solution" implemented on PCs and > comprised exclusively of PCs subject to this as a general requirement. > > All other MUST requirements in Section 4 seem to apply equally to all use > cases. > > > > > See below for additional specific responses. > > [snip] > > >> Lou, would something like the following text in Section 2.2 be a > >> satisfactory replacement for Requirement 14? > >> > >> There is also the case when L3VPNs operate over IPsec Tunnels, > >> for example Provider Edge (PE) based VPN's. An AD VPN must > >> support L3VPN as an application protected by the IPsec > >> Tunnels. > > > > it he must was a MUST, sure. > > I'd happily support a MUST here. There aren't any other MUSTs outside of > Section 4, but I don't know why. > > Thanks, > Brian > > > > > Lou > > --047d7b6d97a232ac5904d0d74947 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Brian/ Lou,

So as a resolution for this, the only change required= would be replacing the requirement to:

There is also the case when L3VPNs operate over IPsec Tunnels, for exam= ple Provider Edge (PE) based VPN's. An ADVPN MUST support L3VPN as an a= pplication protected by the IPsec Tunnels.

I can do that now and post the new version of the draft across.
Thanks,
Vishwas
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
On Fr= i, Dec 14, 2012 at 1:56 PM, Brian Weis <bew@cisco.com> wrote:
Hi Lou,

On Dec 14, 2012, at 10:15 AM, Lou Berger <lberger@labn.net> wrote:

> Brian,
> =A0 =A0 =A0 Opps, should have replied to this message (and not the pri= or).
>
> My previous mail basically said the new requirement is placed on the > ADVPN solution, not a particular implementation. =A0I think it's i= mportant
> to ensure that the overall solution provides for Requirement 14, and I= 'm
> not sure how this can be done without a requirement.

If I understand correctly, these requirements are intending to be rel= evant to "ADVPN solutions" that don't include network infrast= ructure. It doesn't make sense to me to make a "ADVPN solution&quo= t; implemented on PCs and comprised exclusively of PCs subject to this as a= general requirement.

All other MUST requirements in Section 4 seem to apply equally to all use c= ases.

>
> See below for additional specific responses.

[snip]

>> Lou, would something like the following text in Section 2.2 be a >> satisfactory replacement for Requirement 14?
>>
>> =A0 =A0There is also the case when L3VPNs operate over IPsec Tunne= ls,
>> =A0 =A0for example Provider Edge (PE) based VPN's. An AD VPN m= ust
>> =A0 =A0support L3VPN as an application protected by the IPsec
>> =A0 =A0Tunnels.
>
> it he must was a MUST, sure.

I'd happily support a MUST here. There aren't any other MUSTs= outside of Section 4, but I don't know why.

Thanks,
Brian

>
> Lou


--047d7b6d97a232ac5904d0d74947-- From lberger@labn.net Sun Dec 16 09:12:10 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8DC21F885E for ; Sun, 16 Dec 2012 09:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.45 X-Spam-Level: X-Spam-Status: No, score=-101.45 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LG+V3XOmEnQd for ; Sun, 16 Dec 2012 09:12:09 -0800 (PST) Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 9E56821F8856 for ; Sun, 16 Dec 2012 09:12:09 -0800 (PST) Received: (qmail 1269 invoked by uid 0); 16 Dec 2012 17:11:44 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 16 Dec 2012 17:11:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=9++gv1uPDjPHNgQRZ4Dn/1WyoZTW+l2/ihQpQQERdFk=; b=oa0/HE9urOIrARfyGfc1L/lniGMWvG32qCIKW5OXRfyNYwE+cY7OgrwF/dBUDvCO95ClP3ZmKGjWmwEdVIjxEM8LOWcd0N2Of01rhYPWtNwi4NuLzHcXIACBfMxswZZS; Received: from box313.bluehost.com ([69.89.31.113]:58189 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TkHkd-0002JX-NL; Sun, 16 Dec 2012 10:11:43 -0700 Message-ID: <50CE00C6.30005@labn.net> Date: Sun, 16 Dec 2012 12:11:34 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Vishwas Manral References: <0B592A71-6BE1-4988-8BA7-2F3CD61AD03A@cisco.com> <154376FC-F5D4-472F-B321-5B2ED0C5CA2C@cisco.com> <50CB6CA4.3020806@labn.net> <9D8C5AA9-B072-445C-813E-FA187ED75BCE@cisco.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "vishwas.manral@hp.com" , ipsec@ietf.org, Stephen Hanna , Brian Weis Subject: Re: [IPsec] Comments on proposed draft-ietf-ipsecme-ad-vpn-problem-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 17:12:10 -0000 Vishwas, This sounds reasonable to me. Much thanks! Lou On 12/14/2012 5:09 PM, Vishwas Manral wrote: > Hi Brian/ Lou, > > So as a resolution for this, the only change required would be replacing > the requirement to: > > There is also the case when L3VPNs operate over IPsec Tunnels, for > example Provider Edge (PE) based VPN's. An ADVPN MUST support L3VPN as > an application protected by the IPsec Tunnels. > > I can do that now and post the new version of the draft across. > > Thanks, > Vishwas > ===================================================== > On Fri, Dec 14, 2012 at 1:56 PM, Brian Weis > wrote: > > Hi Lou, > > On Dec 14, 2012, at 10:15 AM, Lou Berger > wrote: > > > Brian, > > Opps, should have replied to this message (and not the prior). > > > > My previous mail basically said the new requirement is placed on the > > ADVPN solution, not a particular implementation. I think it's > important > > to ensure that the overall solution provides for Requirement 14, > and I'm > > not sure how this can be done without a requirement. > > If I understand correctly, these requirements are intending to be > relevant to "ADVPN solutions" that don't include network > infrastructure. It doesn't make sense to me to make a "ADVPN > solution" implemented on PCs and comprised exclusively of PCs > subject to this as a general requirement. > > All other MUST requirements in Section 4 seem to apply equally to > all use cases. > > > > > See below for additional specific responses. > > [snip] > > >> Lou, would something like the following text in Section 2.2 be a > >> satisfactory replacement for Requirement 14? > >> > >> There is also the case when L3VPNs operate over IPsec Tunnels, > >> for example Provider Edge (PE) based VPN's. An AD VPN must > >> support L3VPN as an application protected by the IPsec > >> Tunnels. > > > > it he must was a MUST, sure. > > I'd happily support a MUST here. There aren't any other MUSTs > outside of Section 4, but I don't know why. > > Thanks, > Brian > > > > > Lou > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From lberger@labn.net Sun Dec 16 09:13:18 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7168221F8484 for ; Sun, 16 Dec 2012 09:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.437 X-Spam-Level: X-Spam-Status: No, score=-101.437 tagged_above=-999 required=5 tests=[AWL=-0.372, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGWpOGKR00Rt for ; Sun, 16 Dec 2012 09:13:17 -0800 (PST) Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id EE54721F845A for ; Sun, 16 Dec 2012 09:13:12 -0800 (PST) Received: (qmail 1347 invoked by uid 0); 16 Dec 2012 17:12:48 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy8.bluehost.com with SMTP; 16 Dec 2012 17:12:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=zGwnV/ofLFhSi31BSdvGQ36y7w37n26L+t2KifnVe+o=; b=P7rpXtT1SBXmq5trsco10k21Hd/x60JWAiqf/wk8cOttBT3AnAP7G4YMUjKl12yxrqnx/BUma7X5x9Fgsfk9kO6+ARXLavYptMC7jvI4ZkU8oPG5sS0jVNJlSa9vrXD0; Received: from box313.bluehost.com ([69.89.31.113]:58347 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TkHlg-0002l8-5I; Sun, 16 Dec 2012 10:12:48 -0700 Message-ID: <50CE010E.4000709@labn.net> Date: Sun, 16 Dec 2012 12:12:46 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Brian Weis References: <0B592A71-6BE1-4988-8BA7-2F3CD61AD03A@cisco.com> <154376FC-F5D4-472F-B321-5B2ED0C5CA2C@cisco.com> <50CB6CA4.3020806@labn.net> <9D8C5AA9-B072-445C-813E-FA187ED75BCE@cisco.com> In-Reply-To: <9D8C5AA9-B072-445C-813E-FA187ED75BCE@cisco.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "vishwas.manral@hp.com" , ipsec@ietf.org, Stephen Hanna Subject: Re: [IPsec] Comments on proposed draft-ietf-ipsecme-ad-vpn-problem-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 17:13:18 -0000 Brian, Just want to confirm that Vishwas solution closes this issue. Agreed? Thanks, Lou On 12/14/2012 4:56 PM, Brian Weis wrote: > Hi Lou, > > On Dec 14, 2012, at 10:15 AM, Lou Berger wrote: > >> Brian, >> Opps, should have replied to this message (and not the prior). >> >> My previous mail basically said the new requirement is placed on the >> ADVPN solution, not a particular implementation. I think it's important >> to ensure that the overall solution provides for Requirement 14, and I'm >> not sure how this can be done without a requirement. > > If I understand correctly, these requirements are intending to be relevant to "ADVPN solutions" that don't include network infrastructure. It doesn't make sense to me to make a "ADVPN solution" implemented on PCs and comprised exclusively of PCs subject to this as a general requirement. > > All other MUST requirements in Section 4 seem to apply equally to all use cases. > >> >> See below for additional specific responses. > > [snip] > >>> Lou, would something like the following text in Section 2.2 be a >>> satisfactory replacement for Requirement 14? >>> >>> There is also the case when L3VPNs operate over IPsec Tunnels, >>> for example Provider Edge (PE) based VPN's. An AD VPN must >>> support L3VPN as an application protected by the IPsec >>> Tunnels. >> >> it he must was a MUST, sure. > > I'd happily support a MUST here. There aren't any other MUSTs outside of Section 4, but I don't know why. > > Thanks, > Brian > >> >> Lou > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > From bew@cisco.com Mon Dec 17 10:43:53 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3327721F8B77 for ; Mon, 17 Dec 2012 10:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.827 X-Spam-Level: X-Spam-Status: No, score=-109.827 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NV97Hh0Dve2C for ; Mon, 17 Dec 2012 10:43:52 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2474421F8B65 for ; Mon, 17 Dec 2012 10:43:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1984; q=dns/txt; s=iport; t=1355769832; x=1356979432; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=CVB60PYanXyHGdFvnUi/4EdM5LPEq3LLXyOZwnBADZo=; b=A9YMyPfPHxHTll0RIPujPLeOYJ1YWcvUZLdXL4iDehR2LCiBlejzMJ0w V5aohmZU6d4XB6XORwvjYZxxS1+YuWH1+ijgDfAbgiFY1qZNN+m9P3vXp t2o+wwEHOpBOBvWSgtuk25Q1sovLsEpW4kV+D69UtgzHxgqKLOW8VBVi0 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYHACxnz1CrRDoJ/2dsb2JhbABFg0i6axZzgh4BAQEDAQEBAWsLBQsLDgouJzAGExuHcgUBDLl4BIxdG4NHYQOIYYk8g22QSIMUgUw X-IronPort-AV: E=Sophos;i="4.84,304,1355097600"; d="scan'208";a="66724586" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 17 Dec 2012 18:43:51 +0000 Received: from dhcp-128-107-147-77.cisco.com (dhcp-128-107-147-77.cisco.com [128.107.147.77]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBHIhpeW022713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Dec 2012 18:43:51 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Weis In-Reply-To: <50CE010E.4000709@labn.net> Date: Mon, 17 Dec 2012 10:43:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0B592A71-6BE1-4988-8BA7-2F3CD61AD03A@cisco.com> <154376FC-F5D4-472F-B321-5B2ED0C5CA2C@cisco.com> <50CB6CA4.3020806@labn.net> <9D8C5AA9-B072-445C-813E-FA187ED75BCE@cisco.com> <50CE010E.4000709@labn.net> To: Lou Berger X-Mailer: Apple Mail (2.1499) Cc: "vishwas.manral@hp.com" , ipsec@ietf.org, Stephen Hanna Subject: Re: [IPsec] Comments on proposed draft-ietf-ipsecme-ad-vpn-problem-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 18:43:53 -0000 On Dec 16, 2012, at 9:12 AM, Lou Berger wrote: > Brian, > Just want to confirm that Vishwas solution closes this issue. = Agreed? Agreed! Thanks, Brian >=20 > Thanks, > Lou >=20 > On 12/14/2012 4:56 PM, Brian Weis wrote: >> Hi Lou, >>=20 >> On Dec 14, 2012, at 10:15 AM, Lou Berger wrote: >>=20 >>> Brian, >>> Opps, should have replied to this message (and not the prior). >>>=20 >>> My previous mail basically said the new requirement is placed on the >>> ADVPN solution, not a particular implementation. I think it's = important >>> to ensure that the overall solution provides for Requirement 14, and = I'm >>> not sure how this can be done without a requirement. >>=20 >> If I understand correctly, these requirements are intending to be = relevant to "ADVPN solutions" that don't include network infrastructure. = It doesn't make sense to me to make a "ADVPN solution" implemented on = PCs and comprised exclusively of PCs subject to this as a general = requirement. >>=20 >> All other MUST requirements in Section 4 seem to apply equally to all = use cases. >>=20 >>>=20 >>> See below for additional specific responses. >>=20 >> [snip] >>=20 >>>> Lou, would something like the following text in Section 2.2 be a >>>> satisfactory replacement for Requirement 14? >>>>=20 >>>> There is also the case when L3VPNs operate over IPsec Tunnels,=20 >>>> for example Provider Edge (PE) based VPN's. An AD VPN must >>>> support L3VPN as an application protected by the IPsec >>>> Tunnels. >>>=20 >>> it he must was a MUST, sure. >>=20 >> I'd happily support a MUST here. There aren't any other MUSTs outside = of Section 4, but I don't know why. >>=20 >> Thanks, >> Brian >>=20 >>>=20 >>> Lou >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >>=20 >>=20 >>=20 From vishwas.ietf@gmail.com Mon Dec 17 10:52:16 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DEE21F8852 for ; Mon, 17 Dec 2012 10:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.748 X-Spam-Level: X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qsXuXejWqTV for ; Mon, 17 Dec 2012 10:52:15 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 736F621F8853 for ; Mon, 17 Dec 2012 10:52:15 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id k19so4149218qcs.27 for ; Mon, 17 Dec 2012 10:52:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lxi84detk/8ClJPYG0uID33sLmpbS6EQl5j2cQbXHkM=; b=t7IjCVoMZP5A6FztpmOjE8lmdcPZJ9QYTiAT/59SC9bdsvmkxgzlc6ZnweLZ6QPdku +YOY8ekmovZgncXRaY0TnWHoa7PBhuaUIjEq/Sfunr9eywizhO6g8ig0FusPYewUdsvr nnRklPd1iFd1vsETQ089liUjcBTluYnLYWMH3z/hnV2hKPaRAEUMbN/HGVhWXJpu7Qtr wunSSvYkqjN7DWb9VVGHXKHquCcDqkKYca0r4IPR49zssY/1VKP72nQrH/r1l2PcPWfC g0gUUVRFZuXWtyXyk6FJK29pH533l84fSj5EBvhRRuVlAER6B80G3Us/MOZuzG7K7ejG iQ4Q== MIME-Version: 1.0 Received: by 10.224.221.145 with SMTP id ic17mr6632552qab.34.1355770334919; Mon, 17 Dec 2012 10:52:14 -0800 (PST) Received: by 10.229.92.77 with HTTP; Mon, 17 Dec 2012 10:52:14 -0800 (PST) In-Reply-To: References: <0B592A71-6BE1-4988-8BA7-2F3CD61AD03A@cisco.com> <154376FC-F5D4-472F-B321-5B2ED0C5CA2C@cisco.com> <50CB6CA4.3020806@labn.net> <9D8C5AA9-B072-445C-813E-FA187ED75BCE@cisco.com> <50CE010E.4000709@labn.net> Date: Mon, 17 Dec 2012 10:52:14 -0800 Message-ID: From: Vishwas Manral To: Brian Weis Content-Type: multipart/alternative; boundary=20cf3074b45835badb04d110e1d4 Cc: "vishwas.manral@hp.com" , ipsec@ietf.org, Stephen Hanna , Lou Berger Subject: Re: [IPsec] Comments on proposed draft-ietf-ipsecme-ad-vpn-problem-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 18:52:16 -0000 --20cf3074b45835badb04d110e1d4 Content-Type: text/plain; charset=ISO-8859-1 Perfect. I will send the udpated draft today. -Vishwas On Mon, Dec 17, 2012 at 10:43 AM, Brian Weis wrote: > > On Dec 16, 2012, at 9:12 AM, Lou Berger wrote: > > > Brian, > > Just want to confirm that Vishwas solution closes this issue. > Agreed? > > Agreed! > > Thanks, > Brian > > > > > Thanks, > > Lou > > > > On 12/14/2012 4:56 PM, Brian Weis wrote: > >> Hi Lou, > >> > >> On Dec 14, 2012, at 10:15 AM, Lou Berger wrote: > >> > >>> Brian, > >>> Opps, should have replied to this message (and not the prior). > >>> > >>> My previous mail basically said the new requirement is placed on the > >>> ADVPN solution, not a particular implementation. I think it's > important > >>> to ensure that the overall solution provides for Requirement 14, and > I'm > >>> not sure how this can be done without a requirement. > >> > >> If I understand correctly, these requirements are intending to be > relevant to "ADVPN solutions" that don't include network infrastructure. It > doesn't make sense to me to make a "ADVPN solution" implemented on PCs and > comprised exclusively of PCs subject to this as a general requirement. > >> > >> All other MUST requirements in Section 4 seem to apply equally to all > use cases. > >> > >>> > >>> See below for additional specific responses. > >> > >> [snip] > >> > >>>> Lou, would something like the following text in Section 2.2 be a > >>>> satisfactory replacement for Requirement 14? > >>>> > >>>> There is also the case when L3VPNs operate over IPsec Tunnels, > >>>> for example Provider Edge (PE) based VPN's. An AD VPN must > >>>> support L3VPN as an application protected by the IPsec > >>>> Tunnels. > >>> > >>> it he must was a MUST, sure. > >> > >> I'd happily support a MUST here. There aren't any other MUSTs outside > of Section 4, but I don't know why. > >> > >> Thanks, > >> Brian > >> > >>> > >>> Lou > >> > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > >> > >> > >> > >> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --20cf3074b45835badb04d110e1d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Perfect. I will send the udpated draft today.

-Vishwas

On Mon, Dec 17, 2012 at 10:43 AM, Brian Weis <bew@cisco.c= om> wrote:

On Dec 16, 2012, at 9:12 AM, Lou Berger <lberger@labn.net> wrote:

> Brian,
> =A0 =A0 =A0 Just want to confirm that Vishwas = solution closes this issue. =A0Agreed?

Agreed!

Thanks,
Brian

>
> Thanks,
> Lou
>
> On 12/14/2012 4:56 PM, Brian Weis wrote:
>> Hi Lou,
>>
>> On Dec 14, 2012, at 10:15 AM, Lou Berger <lberger@labn.net> wrote:
>>
>>> Brian,
>>> =A0 =A0 Opps, should have replied to this message (and not the= prior).
>>>
>>> My previous mail basically said the new requirement is placed = on the
>>> ADVPN solution, not a particular implementation. =A0I think it= 's important
>>> to ensure that the overall solution provides for Requirement 1= 4, and I'm
>>> not sure how this can be done without a requirement.
>>
>> If I understand correctly, these requirements are intending to be = relevant to "ADVPN solutions" that don't include network infr= astructure. It doesn't make sense to me to make a "ADVPN solution&= quot; implemented on PCs and comprised exclusively of PCs subject to this a= s a general requirement.
>>
>> All other MUST requirements in Section 4 seem to apply equally to = all use cases.
>>
>>>
>>> See below for additional specific responses.
>>
>> [snip]
>>
>>>> Lou, would something like the following text in Section 2.= 2 be a
>>>> satisfactory replacement for Requirement 14?
>>>>
>>>> =A0 There is also the case when L3VPNs operate over IPsec = Tunnels,
>>>> =A0 for example Provider Edge (PE) based VPN's. An AD = VPN must
>>>> =A0 support L3VPN as an application protected by the IPsec=
>>>> =A0 Tunnels.
>>>
>>> it he must was a MUST, sure.
>>
>> I'd happily support a MUST here. There aren't any other MU= STs outside of Section 4, but I don't know why.
>>
>> Thanks,
>> Brian
>>
>>>
>>> Lou
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>>
>>
>>

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

--20cf3074b45835badb04d110e1d4-- From lberger@labn.net Mon Dec 17 11:13:10 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6648721F873F for ; Mon, 17 Dec 2012 11:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.592 X-Spam-Level: X-Spam-Status: No, score=-101.592 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLx-pab0RFcf for ; Mon, 17 Dec 2012 11:13:09 -0800 (PST) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id A66C421F8632 for ; Mon, 17 Dec 2012 11:13:09 -0800 (PST) Received: (qmail 15377 invoked by uid 0); 17 Dec 2012 19:12:47 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 17 Dec 2012 19:12:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=XoUa9BFbx9lRZF+tU85epGXiiQy6yfuNO7MRJa3Wcio=; b=N9PvcjwDGgDx2GjlOpZspmZKkI2D1QOO++lrRfuy67cxZPsrT9HKsTuZPjA0gMzKXk3NytHLU4wUcOqZ32Rcfs2J6Epkho5gAbTsJzI/dRHUrWbeiQdqTPeV7Ja2vmMu; Received: from box313.bluehost.com ([69.89.31.113]:55622 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1Tkg7K-000146-NE; Mon, 17 Dec 2012 12:12:46 -0700 Message-ID: <50CF6EAD.9050005@labn.net> Date: Mon, 17 Dec 2012 14:12:45 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Brian Weis , "vishwas.manral@hp.com" References: <0B592A71-6BE1-4988-8BA7-2F3CD61AD03A@cisco.com> <154376FC-F5D4-472F-B321-5B2ED0C5CA2C@cisco.com> <50CB6CA4.3020806@labn.net> <9D8C5AA9-B072-445C-813E-FA187ED75BCE@cisco.com> <50CE010E.4000709@labn.net> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ipsec@ietf.org, Stephen Hanna Subject: Re: [IPsec] Comments on proposed draft-ietf-ipsecme-ad-vpn-problem-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 19:13:10 -0000 excellent. Thank you both for resolving my comments so rapidly! Lou On 12/17/2012 1:43 PM, Brian Weis wrote: > > On Dec 16, 2012, at 9:12 AM, Lou Berger wrote: > >> Brian, >> Just want to confirm that Vishwas solution closes this issue. Agreed? > > Agreed! > > Thanks, > Brian > >> >> Thanks, >> Lou >> >> On 12/14/2012 4:56 PM, Brian Weis wrote: >>> Hi Lou, >>> >>> On Dec 14, 2012, at 10:15 AM, Lou Berger wrote: >>> >>>> Brian, >>>> Opps, should have replied to this message (and not the prior). >>>> >>>> My previous mail basically said the new requirement is placed on the >>>> ADVPN solution, not a particular implementation. I think it's important >>>> to ensure that the overall solution provides for Requirement 14, and I'm >>>> not sure how this can be done without a requirement. >>> >>> If I understand correctly, these requirements are intending to be relevant to "ADVPN solutions" that don't include network infrastructure. It doesn't make sense to me to make a "ADVPN solution" implemented on PCs and comprised exclusively of PCs subject to this as a general requirement. >>> >>> All other MUST requirements in Section 4 seem to apply equally to all use cases. >>> >>>> >>>> See below for additional specific responses. >>> >>> [snip] >>> >>>>> Lou, would something like the following text in Section 2.2 be a >>>>> satisfactory replacement for Requirement 14? >>>>> >>>>> There is also the case when L3VPNs operate over IPsec Tunnels, >>>>> for example Provider Edge (PE) based VPN's. An AD VPN must >>>>> support L3VPN as an application protected by the IPsec >>>>> Tunnels. >>>> >>>> it he must was a MUST, sure. >>> >>> I'd happily support a MUST here. There aren't any other MUSTs outside of Section 4, but I don't know why. >>> >>> Thanks, >>> Brian >>> >>>> >>>> Lou >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> >>> >>> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > From internet-drafts@ietf.org Mon Dec 17 14:00:14 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86AF21F89BB; Mon, 17 Dec 2012 14:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTp5eVvdp0qo; Mon, 17 Dec 2012 14:00:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA5221F89CA; Mon, 17 Dec 2012 14:00:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121217220006.20125.54841.idtracker@ietfa.amsl.com> Date: Mon, 17 Dec 2012 14:00:06 -0800 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ad-vpn-problem-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 22:00:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. Title : Auto Discovery VPN Problem Statement and Requirements Author(s) : Steve Hanna Vishwas Manral Filename : draft-ietf-ipsecme-ad-vpn-problem-03.txt Pages : 16 Date : 2012-12-17 Abstract: This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements, for such a solution. Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases the IP address of endpoints change or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto Discovery VPN solution is chartered to address these requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-ad-vpn-problem-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Tue Dec 18 09:14:31 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79DD21F8A80; Tue, 18 Dec 2012 09:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHCc551hlooB; Tue, 18 Dec 2012 09:14:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD4721F8A88; Tue, 18 Dec 2012 09:14:31 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121218171431.6115.9992.idtracker@ietfa.amsl.com> Date: Tue, 18 Dec 2012 09:14:31 -0800 Cc: ipsecme WG Subject: [IPsec] WG Action: Rechartered IP Security Maintenance and Extensions (ipsecme) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 17:14:31 -0000 The IP Security Maintenance and Extensions (ipsecme) working group in the Security Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ Current Status: Active Working Group Chairs: Paul Hoffman Yaron Sheffer Assigned Area Director: Sean Turner Mailing list Address: ipsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: http://www.ietf.org/mail-archive/web/ipsec/ Charter of Working Group: The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 5996), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The current work items include: In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (in a single administrative domain or across multiple domains), customers want to get on-demand point-to-point IPsec capability for efficiency. However, this cannot be feasibly accomplished only with today's IPsec and IKE due to problems with address lookup, reachability, policy configuration, and so on. The IPsecME Working Group will handle this large scale VPN problem by: * Creating a problem statement document including use cases, definitions and proper requirements for discovery and updates. This document would be solution-agnostic. * Publishing a common solution for the discovery and update problems that will satisfy the requirements in the problem statement document. The working group may standardize one of the vendor solutions, a combination, an superset of such a solution, or a new protocol. * Reviewing and helping publish Informational documents describing current vendor proprietary solutions. Recently discovered incorrect behavior of ISPs poses a challenge to IKE, whose UDP messages (especially #3 and #4) sometimes get fragmented at the IP level and then dropped by these ISPs. There is interest in solving this issue by allowing transport of IKE over TCP; this is currently implemented by some vendors. The group will standardize such a solution, using draft-nir-ipsecme-ike-tcp as a starting point. The WG will review and possibly revise the list of mandatory-to- implement algorithms for ESP and AH based on five years of experience with newer algorithms and cryptographic modes. This work will be based on draft-mcgrew-ipsec-me-esp-ah-reqts. The WG will update the way IKEv2 uses public keys that are trusted out-of-band (that is, not through a common PKIX trust anchor). This work will be based on draft-kivinen-ipsecme-oob-pubkey. This charter will expire in November 2015 (24 months from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Milestones: Done - WG last call on IPv6 configuration payloads Done - WG last call on IPsec roadmap Done - WG last call on session resumption Done - WG last call on redirect Done - WG last call on IKEv2bis Done - WG last call on ESP NULL traffic visibility Done - WG last call on HA requirements Done - WG last call on quick crash discovery Done - WG last call on EAP-only authentication Nov 2012 - IETF Last Call on large scale VPN use cases and requirements Feb 2013 - IETF Last Call on IKE over TCP Jun 2013 - IETF Last Call on large scale VPN protocol From kivinen@iki.fi Thu Dec 20 05:52:35 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC9021F8812 for ; Thu, 20 Dec 2012 05:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.683 X-Spam-Level: X-Spam-Status: No, score=-101.683 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, SARE_FWDLOOK=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HYcgvpwOvUB for ; Thu, 20 Dec 2012 05:52:34 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6B421F880C for ; Thu, 20 Dec 2012 05:52:33 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qBKDqE5c018719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2012 15:52:14 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qBKDqCSm003551; Thu, 20 Dec 2012 15:52:12 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20691.6156.393731.420290@fireball.kivinen.iki.fi> Date: Thu, 20 Dec 2012 15:52:12 +0200 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: References: <50C62D6A.8010709@gmail.com> <5808c090d8485cc6698829b522fade80.squirrel@www.trepanning.net> <50C9B0B5.9090600@secunet.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 12 min Cc: IPsecme WG , Johannes Merkle , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 13:52:35 -0000 Dan Harkins writes: > >> Why not keeping the main document general and giving details for > >> registered groups in an appendix? > > > > Hmmmm, I like that suggestion. > > That's a great suggestion. Yaron also mentioned the idea of adding > a note column to the DH group repository that references the particular > section of your draft (instruct IANA to update the registry with the section > and the RFC number that gets assigned to your draft). I think both of > those would be good. Now, when I am reading the actual context (I was bit swamped with other things last week) I think this is good idea. I.e. make the document define the generic ideas in the body, make IANA considerations section to add the note field to the IANA registry, which specifies this RFC and subsection in it for each group. When I originally got the emails from Yaron about the IANA registry, I wasn't sure whether the implementor needs to know these facts or just the draft author writing new RFCs that adds new groups. Now as it seems clear that each implementor needs to know this information, I think new column to the IANA registry is good way forward. And I do not think we need appedix to list the current groups, we can just put it in the IANA considerations section, as they need to add that column and that column has all the information (i.e. mapping from the group to the checks needed). > > Here's what I'm wrestling with; every curve that we currently support > > (and, in fact, every prime curve I've heard anyone suggest) has h=1 > > (having h>1 makes the discrete log problem be a factor of sqrt(h) easier, > > for no benefit that I can see); hence, this cofactor test is moot. So, do > > we complicate our description (at least, of the prime curve section) with > > a test that never really applies? > > Maybe not. It might make sense to say that all the curves have an > implied co-factor of 1 though. If we are going to add binary group subsection (and I think we should), I think we should also add special section for groups having h > 1 (whatever that means :-). It does not matter that there is no groups now defined using that section, and if it is as slow because of the checks it might be there never will be, but at least then we do not need to think again what kind of checks are needed if someone defines such group. It also makes it sure that if someone defines such group he will use correct checks for the groups, and not just assume that section 2.3 is ok, as this is elliptic curve group... > > Now, if we do have a section covering even characteristic curves, those > > have h>1 (the math pretty much forces that), and so a discussion there > > wouldn't be entirely out of place. On the other hand, there are > > standardized ways of defining the ECDH operation so that the cofactor > > doesn't cause any leakage ("ECC CDH", where the shared secret really is > > hxyG); if the group is defined using that primitive, such a cofactor test > > beforehand is unneeded. Will such a group use such a modified DH > > operation? Well, given that no such groups are currently defined, we > > can't say. > > > > My opinion: in the prime curve section, there's no reason to mention a > > cofactor; and that it's premature to put in an even characteristic curve > > section. > > OK, I agree with the former, but why not just cover all the possibilities > by mentioning the characteristic curves? It's supposed to be a forward- > looking document that's placing requirements on future RFCs that add > new groups and there's no reason why someone couldn't add such a curve. > I think it would be cleaner to have everything covered here instead of > having this one mention 3 of 4 and another RFC mention the 4th. As we seem to have people who know about these checks and are interested in this issues, I would really like to get all cases covered. It will make IANA experts life also easier if there is all cases covered in the this document... For example I (as an current IANA expert for the IPsec registry) would have no idea to know whether some EC group has h > 1 or not, and whether it means something special. If there is no text about it in the document, I most likely would not notice it at all. Now if this document do have separate section, I would most likely send question to auhtors and ask them to verify which of these two subsection is approprite in their document if they have not already pointed it out in their document. So I am all in favor of making this document forward-looking document, and include checks for those groups which are not yet used, but which might be added later. Also as implementors will come to this document through the IANA registry which points to specific subsection, other subsections in this document does not matter to them... -- kivinen@iki.fi From Johannes.Merkle@secunet.com Thu Dec 20 06:05:45 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3F421F8623 for ; Thu, 20 Dec 2012 06:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLfq+ht7Xjie for ; Thu, 20 Dec 2012 06:05:45 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id BECF221F8980 for ; Thu, 20 Dec 2012 06:05:44 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 5C23D1A008E; Thu, 20 Dec 2012 15:05:43 +0100 (CET) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 4E5A81A008C; Thu, 20 Dec 2012 15:05:42 +0100 (CET) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Dec 2012 15:05:41 +0100 Message-ID: <50D31B35.8090104@secunet.com> Date: Thu, 20 Dec 2012 15:05:41 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Tero Kivinen References: <50C62D6A.8010709@gmail.com> <5808c090d8485cc6698829b522fade80.squirrel@www.trepanning.net> <50C9B0B5.9090600@secunet.com> <20691.6156.393731.420290@fireball.kivinen.iki.fi> In-Reply-To: <20691.6156.393731.420290@fireball.kivinen.iki.fi> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Dec 2012 14:05:41.0687 (UTC) FILETIME=[189DFC70:01CDDEBB] Cc: IPsecme WG , Dan Harkins , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 14:05:45 -0000 > > I.e. make the document define the generic ideas in the body, make IANA > considerations section to add the note field to the IANA registry, > which specifies this RFC and subsection in it for each group. > Which way to prefer for the "new" EC groups, i.e. the Brainpool I-Ds from Dan and me? 1. Also include references to these I-D in the draft IKE Diffie-Hellman checks 2. Include a note in the IANA section of each Brainpool I-D to add for these curves a reference to the corresponding section of the DH-checks RFC? Johannes From yaronf.ietf@gmail.com Thu Dec 20 06:33:50 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3254221F84F1 for ; Thu, 20 Dec 2012 06:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFNa2xcAdgzw for ; Thu, 20 Dec 2012 06:33:49 -0800 (PST) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3E47621F84FC for ; Thu, 20 Dec 2012 06:33:49 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id m13so3121341lah.35 for ; Thu, 20 Dec 2012 06:33:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DFdn8SjVEN6fo2CWFVE94DkSSGPtu8CVNyzvbAYJeLM=; b=em/joXvh5OCrAYIFE5/7eIeEzmBmKPtUv2plN+3q6i2W+FGiwgqciTnS1wfh5kf9YA fEkvW38L5mrfhaXxTkutImaUy5mt6a7CZds2AuK16qUfrSyterIY6uo2XFsitPTbJo9h 1lxjjx3cooy9/YyoFIBYD8kKpKAeWgnRb3ifA7ykNA1KVO0ZymH1WR0RRrDKaJdaAAMf ydxH/Zeu5yjX/rEPUb7RHgkZmrlhOJsKr8eFp5/HBR7rFhAQcbl/SUVRSCU4nkgcuBwx zqWWVU2dePS4KsM0cNolbrZooO4loS2A7XG8nh9xnXrcaAnf1cvF2DsbzixlCkfflPE/ JAFg== X-Received: by 10.152.104.112 with SMTP id gd16mr9155479lab.26.1356014022055; Thu, 20 Dec 2012 06:33:42 -0800 (PST) Received: from [10.0.0.13] (85-250-110-45.bb.netvision.net.il. [85.250.110.45]) by mx.google.com with ESMTPS id b3sm3513961lbl.0.2012.12.20.06.33.36 (version=SSLv3 cipher=OTHER); Thu, 20 Dec 2012 06:33:40 -0800 (PST) Message-ID: <50D321BE.1080407@gmail.com> Date: Thu, 20 Dec 2012 16:33:34 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Johannes Merkle References: <50C62D6A.8010709@gmail.com> <5808c090d8485cc6698829b522fade80.squirrel@www.trepanning.net> <50C9B0B5.9090600@secunet.com> <20691.6156.393731.420290@fireball.kivinen.iki.fi> <50D31B35.8090104@secunet.com> In-Reply-To: <50D31B35.8090104@secunet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Dan Harkins , Tero Kivinen , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 14:33:50 -0000 Hi Johannes, note that this discussion is still a bit tentative, as we are working with Sean to add the "DH checks" draft into our charter. But anyway... For formal reasons, I would like to avoid a dependency from "DH Checks" on Brainpool. So the better option is #2: have Brainpool I-Ds refer to our I-D in their IANA Considerations. I would like to use this opportunity to wish everyone on this list Happy Holidays and a Happy New Year. Paul and I did consider creating a Christmas video for your enjoyment (like http://www.youtube.com/watch?v=-YR-d3JHYec&feature=youtu.be), luckily for everyone we decided to skip it this year :-) Yaron On 12/20/2012 04:05 PM, Johannes Merkle wrote: >> >> I.e. make the document define the generic ideas in the body, make IANA >> considerations section to add the note field to the IANA registry, >> which specifies this RFC and subsection in it for each group. >> > Which way to prefer for the "new" EC groups, i.e. the Brainpool I-Ds from Dan and me? > 1. Also include references to these I-D in the draft IKE Diffie-Hellman checks > 2. Include a note in the IANA section of each Brainpool I-D to add for these curves a reference to the corresponding > section of the DH-checks RFC? > > Johannes > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From kivinen@iki.fi Thu Dec 20 06:36:42 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBB021F88C4 for ; Thu, 20 Dec 2012 06:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPMwoM4pui0V for ; Thu, 20 Dec 2012 06:36:41 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id C5F5921F88EA for ; Thu, 20 Dec 2012 06:36:36 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qBKEaYKC005973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Dec 2012 16:36:34 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qBKEaYJD029772; Thu, 20 Dec 2012 16:36:34 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20691.8818.516025.394027@fireball.kivinen.iki.fi> Date: Thu, 20 Dec 2012 16:36:34 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 10 min Subject: [IPsec] My comments to draft-ietf-ipsecme-ike-tcp-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 14:36:42 -0000 Ok, got finally to continue my IPsec work. Here are my comments to the draft (next is advpn, but not sure whether I will be able to read it before xmas): ---------------------------------------------------------------------- 1.1. Non-Goals of this Specification Firewall traversal is not a goal of this specification. If a Add (except when bypassing broken firewall dropping all framents) I think that is one of the goals. I.e. goal is not to bypass policy rules, goals is to fix brokeness caused by broken implementations not supporting fragments. ---------------------------------------------------------------------- 2.1. Initiator ... An initiator MUST accept responses sent over IKE within the same connection, but MUST also accept responses over other transports, if the request had been sent over them as well. What that "sent over IKE" is supposed to mean, TCP/UDP? Any protocol? ---------------------------------------------------------------------- 2.4. Receiver ... the same way as regular UDP messages. That includes retransmission detection, with one slight difference: if a retransmitted request is detected, the response is retransmitted as well, but using the current TCP connection rather than whatever other transport had been used for the original transmission of the request. What does this mean with MOBIKE. For example the UPDATE_SA_ADDRESSES notify assumes the address which should be used is taken from the current IP header (IP and port), but if the message is retransmitted over TCP this messes up things (port is different if there is NAT). Easiest way would say that such UPDATE_SA_ADDRESSES notification over TCP is replied, but ignored, i.e. it does not cause any actual MOBIKE change. We cannot really do the change, as we do not know the UDP port number in case the initiator sending UPDATE_SA_ADDRESSES is behind NAT. Also with MOBIKE that will disable the dynamic port update happening with normal IKEv2, so all UDP port changes only happen with UPDATE_SA_ADDESSES. Other option is to reply with UNACCEPTABLE_ADDRESSES error to all MOBIKE UPDATE_SA_ADDRESSES requests coming over TCP, in which case it is clear for sender of UPDATE_SA_ADDRESSES thta it failed, but it should also be clear for sender of the request that it retried it over TCP, so it should be able to ignore it in that case too.. Actually the whole behavior with the MOBIKE is missing. I.e. do we first try with UDP then with TCP, and if that fails, then try other IP addresses, or do we first try with all IP addresses with MOBIKE and then fall back to TCP. I think it should most likely try with TCP only if the packet we are trying to send is big i.e > 500 bytes, and if the packet we are trying to send is small then we should first try all possible IP addresses, and if that fails then go to TCP. If packet is big, we should first try with TCP over the current IP address, and if that does not work, then fall back to normal MOBIKE processing. ---------------------------------------------------------------------- 4. Security Considerations Most of the security considerations for IKE over TCP are the same as those for UDP as in RFC 5996. For the Responder, listening to TCP port 500 involves all the risks of maintaining any TCP server. Precautions against DoS attacks, such as SYN cookies are RECOMMENDED. see [RFC4987] for details. Actually TCP has much bigger buffering and state requirements than UDP, especially with the stateless cookies. Syn cookies are not only attack, any peer can open TCP session to the gateway and start sending 4GB IKE packet... Unless special checks of source IP is done then any host in the world can do the same. IKE header length field is 32 bits, so it might be good idea for implementations to limit this to something suitable... On the other hand one reason to use TCP would be able to transfer big certfificate chains or CRL lists, so the limit cannot be too small... -- kivinen@iki.fi From kivinen@iki.fi Fri Dec 21 01:50:11 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5918421F8AD6 for ; Fri, 21 Dec 2012 01:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.96 X-Spam-Level: X-Spam-Status: No, score=-102.96 tagged_above=-999 required=5 tests=[AWL=0.639, BAYES_00=-2.599, GB_I_LETTER=-2, J_BACKHAIR_35=1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBFlo1R-ra-j for ; Fri, 21 Dec 2012 01:50:10 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 83CE121F8A7E for ; Fri, 21 Dec 2012 01:50:09 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qBL9o3ZS008983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Dec 2012 11:50:03 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qBL9o3IB015778; Fri, 21 Dec 2012 11:50:03 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20692.12491.489818.760016@fireball.kivinen.iki.fi> Date: Fri, 21 Dec 2012 11:50:03 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 57 min X-Total-Time: 1119 min Subject: [IPsec] My comments to the draft-ietf-ipsecme-ad-vpn-problem-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 09:50:11 -0000 I now read the lastest version. The terminology is much clearer now, and the document is much easier to read. I still see that not all of my comments in previous versions have been added to the document (some even from my 2012-03-14 email http://www.ietf.org/mail-archive/web/ipsec/current/msg07558.html, i.e the changes to section 3.1, 3.2 and 3.3). I am now going through my comments from 2012-09-10 email http://www.ietf.org/mail-archive/web/ipsec/current/msg07910.html and see which still apply). ---------------------------------------------------------------------- Now that we have new terminology, it would be nice to have all terms defined in the terminology to use capital letter, so it would be clear that Hub/Gateway/Spoke/Endpoint etc has special meaning... ---------------------------------------------------------------------- > 4.1. Gateway and Endpoint Requirements > ... > 2. Gateways and endpoints MUST allow IPsec Tunnels to be setup > without any configuration changes, even when peer addresses get > updated every time the device comes up. This implies that SPD > entries or other configuration based on peer IP address will need to > be automatically updated, avoided, or handled in some manner to avoid > a need to manually update policy whenever an address changes. In this I was trying to ask whether this is supposed to for existing already configured Gateways and endpoints, and as now the 1 has been changed to include gateway or endpoints addition/removal/changes, it is quite clear this only covers the normal operational use, i.e. when the gateways and endpoints are already configured. Perhaps changing it something like 2. Existing member Gateways and endpoints of the ADVPN MUST allow IPsec Tunnels to be setup with other members of the ADVPN without any configuration changes, even when peer addresses get updated every time the device comes up. This implies that SPD entries or other configuration based on peer IP address will need to be automatically updated, avoided, or handled in some manner to avoid a need to manually update policy whenever an address changes. to make it clear that we are not talking about the initial configuration but the actual normal use case of 2 peers which are already part of the ADVPN. BTW, perhaps we should add "ADVPN Peer" to the terminology and say it is any member (gateway, endpoint, hub or spoke) of the ADVPN and use "other ADVPN peers" above instead of "other members of the ADVPN". Or see if there is any other uses for peer than exactly that, and then define "Peer" to be same as ADVPN Peer... ---------------------------------------------------------------------- > 4. In the full mesh and dynamic full mesh topology, Spokes MUST > allow for direct communication with other spoke gateways and > endpoints. In the star topology mode, direct communication between > spokes MUST be disallowed. I have question here, why are we defining things for strict star topology mode, as the 2.2 says star topology is not good, and we need to have spoke to spoke communications. So 2.2 does NOT justify the last sentence in this requirement that forbids spoke to spoke communications for star topology mode. What is the justification for it? If we are not defining things for star topology we should not put any restrictions to it either. In my March email I pointed out that star topology is sometimes used for policy reasons, but that addition never made to the document. Those policy reasons might be one reason why some setups would still use star topology even with ADVPN, but I would expect it to be more like half star half mesh setup, where some traffic goes through star and some traffic bypasses it, so even there the last sentence does not work out. ---------------------------------------------------------------------- > 5. One spoke MUST NOT be able to impersonate another spoke. Note, that this does not say anything about the Hubs or Endpoints. For Endpoints I think there should be same requirement, i.e. one Endpoint MUST NOT be able to impersonate another Endpoint or Gateway. Btw, I think it would also be unacceptable for Spoke to impersonate of being Hub, so the "another Spoke" should be changed to "any other Gateway". Note, also that Spokes and Hubs quite often can impersonate Endpoints, as Endpoints might use weak form authentication (shared secrets), and the Spokes have access to them. Also when using temporary credentials given by Spokes/Hubs etc to the Endpoints for Point-to-Point communication between two Endpoints the entity who gave those out might be able to impersonate Endpoints (unless the temporary credentials is in form of certificate signed by some CA). When I pointed this out last time, I got answer that this document is trying to impose the "typical enterprice connectivity scenario" here, but I think we should think these requirements, not rely on some unspoken enterprice connectivity scenario. Especially as it do limit our options and will affect our threat model. So I would like to see expictly whether Hubs should be able to impersonate other Gateways / Endpoints and same for Endpoints. Also last time the comment was that with this "typical enterprice connectivity scenario" spoke to hub connections are static, but now we have requirement 7 which says that gateway might handoff sessions to another gateway. Gateway includes hubs, so hub can handoff spokes to another hub if he feels like. If this was not intended, then 7 should be changed so it says "Spokes SHOULD allow for easy handoff of a session to another Spoke, ...". Also as this connectivity scenario is not documented anywhere, so if it is wanted, we should add text for it, i.e. most likely change the Hub and Spoke definitions to say that connections between Hubs and Spokes are mostly static. ---------------------------------------------------------------------- > 6. Gateways SHOULD allow for seamless handoff of sessions in case > endpoints are roaming, even if they cross policy boundaries. This > would mean the data traffic is minimally affected even as the handoff > happens. External factors like firewall, NAT box will not be > considered part of this solution. > > This requirement is driven by use case 2.1. Today's endpoints are > mobile and transition often between different networks (from 4G to > WiFi and among various WiFi networks). This is still unclear. Last time I proposed two options, and I was said that both of them might be correct, but neither one of them are what is really said above. As the 2.1 is Endpoint-to-Endpoint use case, I assume this is supposed to say that "Spokes SHOULD allow for seamless handoff of sessions to Point-to-Point communication mode between Endpoints that used to be connected to Spoke, in case ...". I.e. This does not cover the Endpoint moving from one Spoke to another, but two Endpoints talking through Spokes moving to the Point-to-Point mode, I think the Endpoint moving from one Spoke to another Spoke is covered by requirement 7. Right? ---------------------------------------------------------------------- > 7. Gateways SHOULD allow for easy handoff of a session to another > gateway, to optimize latency, bandwidth, load balancing, > availability, or other factors, based on policy. > > This requirement is driven by use case 2.3. And as 2.3 is Endpoint-to-Gateway, I assume this is the case where Spoke gives one Endpoint to another Spoke..., i.e. "Spokes SHOULD allow for easy handoff of a Endpoint to another Spoke, ...". Am I correct here? And if we assume Hub<->Spoke connection is mostly static we do not allow Hubs to handoff Spokes to another Hubs (if we do want to say that, then we can use the "Gateways" above). These 6 and 7 use term "session" which is not very well defined. There are multiple possible meanings for it, and I think it would be good idea to try to define which one of them is meant. -- kivinen@iki.fi From kivinen@iki.fi Fri Dec 21 01:56:58 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B0D21F8AF8 for ; Fri, 21 Dec 2012 01:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HeLtJ+cw0Li for ; Fri, 21 Dec 2012 01:56:57 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 26B3F21F8539 for ; Fri, 21 Dec 2012 01:56:56 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qBL9unkR003476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Dec 2012 11:56:49 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qBL9ulgP007355; Fri, 21 Dec 2012 11:56:47 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20692.12895.718495.872957@fireball.kivinen.iki.fi> Date: Fri, 21 Dec 2012 11:56:47 +0200 From: Tero Kivinen To: Johannes Merkle In-Reply-To: <50D31B35.8090104@secunet.com> References: <50C62D6A.8010709@gmail.com> <5808c090d8485cc6698829b522fade80.squirrel@www.trepanning.net> <50C9B0B5.9090600@secunet.com> <20691.6156.393731.420290@fireball.kivinen.iki.fi> <50D31B35.8090104@secunet.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 1 min Cc: IPsecme WG , Dan Harkins , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 09:56:58 -0000 Johannes Merkle writes: > > > > I.e. make the document define the generic ideas in the body, make IANA > > considerations section to add the note field to the IANA registry, > > which specifies this RFC and subsection in it for each group. > > > Which way to prefer for the "new" EC groups, i.e. the Brainpool I-Ds > from Dan and me? > 1. Also include references to these I-D in the draft IKE > Diffie-Hellman checks Yes, reference to the Diffie-Hellman checks RFC is needed. > 2. Include a note in the IANA section of each Brainpool I-D to add > for these curves a reference to the corresponding section of the > DH-checks RFC? Yes. -- kivinen@iki.fi From kivinen@iki.fi Fri Dec 21 02:01:22 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A7821F85D2 for ; Fri, 21 Dec 2012 02:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaCnq6Sp9MiB for ; Fri, 21 Dec 2012 02:01:21 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 433C521F85AE for ; Fri, 21 Dec 2012 02:01:21 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qBLA1G9f026052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Dec 2012 12:01:16 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qBLA1GgA018380; Fri, 21 Dec 2012 12:01:16 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20692.13164.237231.901915@fireball.kivinen.iki.fi> Date: Fri, 21 Dec 2012 12:01:16 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <50D321BE.1080407@gmail.com> References: <50C62D6A.8010709@gmail.com> <5808c090d8485cc6698829b522fade80.squirrel@www.trepanning.net> <50C9B0B5.9090600@secunet.com> <20691.6156.393731.420290@fireball.kivinen.iki.fi> <50D31B35.8090104@secunet.com> <50D321BE.1080407@gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min Cc: IPsecme WG , Johannes Merkle , Dan Harkins , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 10:01:22 -0000 Yaron Sheffer writes: > note that this discussion is still a bit tentative, as we are working > with Sean to add the "DH checks" draft into our charter. But anyway... > > For formal reasons, I would like to avoid a dependency from "DH Checks" > on Brainpool. So the better option is #2: have Brainpool I-Ds refer to > our I-D in their IANA Considerations. Ups, I misread the previous comment. I meant that the new brainpool etc drafts should have normative reference to the DH checks draft, not the other way around. There is no need to change the DH checks draft to include reference to the new drafts as that would lock those two drafts together, neither can go forward without the other. The brainpool draft can just write in its IANA considerations section that this document adds these groups, and these are the checks that needs to be done for them (i.e. what to put in the DH checks column etc). So I agree with Yaron about this... -- kivinen@iki.fi From svanru@gmail.com Tue Dec 25 22:11:25 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2154921F8C4E for ; Tue, 25 Dec 2012 22:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-1.299, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLcgcyNxEGic for ; Tue, 25 Dec 2012 22:11:24 -0800 (PST) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3D18B21F8C4C for ; Tue, 25 Dec 2012 22:11:23 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id p9so10095144laa.4 for ; Tue, 25 Dec 2012 22:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=mgarpD7UnjDw9LjsevobbL+Js/fD5vd8EHNN8BSkJLU=; b=z7cx9gYGe651I6dszhR+94dk/5se4iasvklwSrqFShvEWp9U4I/zZkohb5iqtpXeGF tmPCNPU3q/rC1hC5iUTJy5G66ua4Go+g2ZHT6qTNtKb6qxYf6bxGOvLPUxq9+voy8NqK mPYgxLR51SP6HAWfhNa2TqfEF/JWL6+vVFCKrE9FpaQNO9FrfHYMDvMJlJRkI+QdrCiK C/8yL6ef580g1rWRumB8hqLijJ/c1Y4JWTqIx/H0y7fCYtGOB/VKxi6mg5aRQeWUE1rS UGjm8kbsu9/3ikYaunlot1qJlNXoeEcP+OWzFXr7SX8trqGn7rl1WfTgkiR79x3Bh5ws 7Qew== X-Received: by 10.152.111.72 with SMTP id ig8mr24340039lab.1.1356502282772; Tue, 25 Dec 2012 22:11:22 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPS id v7sm9144197lbj.13.2012.12.25.22.11.14 (version=SSLv3 cipher=OTHER); Tue, 25 Dec 2012 22:11:21 -0800 (PST) Message-ID: From: "Valery Smyslov" To: References: <20121203223404.5441.71025.idtracker@ietfa.amsl.com> <4613980CFC78314ABFD7F85CC30277210EDFD9D0@IL-EX10.ad.checkpoint.com> Date: Wed, 26 Dec 2012 10:11:09 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: [IPsec] Error in RFC6290 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 06:11:25 -0000 Hi, RFC6290 (Quick Crash Detection) contains an error. In Section 4.3 it states: For session resumption, as specified in [RFC5723], the situation is similar. The responder, which is necessarily the peer that has crashed, SHOULD send a new ticket within the protected payload of the IKE_SESSION_RESUME exchange. If the Initiator is also a token maker, it needs to send a QCD_TOKEN in a separate INFORMATIONAL exchange. But IKE_SESSION_RESUME exchange, as specified in RFC5723, doesn't contain any protected payload - it is completely in clear and must be followed by IKE_AUTH exchange. I suspect this error came from early versions of IKE SA Resumption protocol that, as far as I remember, did contain protected payload. But currently this para should look like: For session resumption, as specified in [RFC5723], the situation is similar. The responder, which is necessarily the peer that has crashed, SHOULD send a new ticket in IKE_AUTH exchange that immediately followed IKE_SESSION_RESUME exchange. If the Initiator is also a token maker, it needs to send a QCD_TOKEN in the same IKE_AUTH exchange. And one more consideration. In Section 4.1 RFC6290 states: o Protocol ID (1 octet) MUST be 1, as this message is related to an IKE SA. o SPI Size (1 octet) MUST be zero, in conformance with Section 3.10 of [RFC5996]. I think here we have contradiction with RFC5996 (despite clamed conformance with it). In abovementioned Section 3.10 it is written: o Protocol ID (1 octet) - If this notification concerns an existing SA whose SPI is given in the SPI field, this field indicates the type of that SA. For notifications concerning Child SAs, this field MUST contain either (2) to indicate AH or (3) to indicate ESP. Of the notifications defined in this document, the SPI is included only with INVALID_SELECTORS and REKEY_SA. If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt. Let me emphasize that RFC5996 clearly requires that If the SPI field is empty, Protocol ID field MUST be sent as zero and MUST be ignored on receipt, but RFC6290 while requiring SPI field to be empty, requres Protocol ID field to be non-zero. Actually, I see no value in this requirement, as Protocol ID MUST be ignored on receipt anyway (if SPI field is empty), so it just complicates protocol and makes it cumbersome. Merry Christmas, Valery Smyslov. From ynir@checkpoint.com Wed Dec 26 00:42:59 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F3E21F8C6C for ; Wed, 26 Dec 2012 00:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcbTABggvdqt for ; Wed, 26 Dec 2012 00:42:58 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3E33021F8C51 for ; Wed, 26 Dec 2012 00:42:57 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id qBQ8gq2b017793; Wed, 26 Dec 2012 10:42:53 +0200 X-CheckPoint: {50DAB73E-2-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.238]) by IL-EX10.ad.checkpoint.com ([169.254.2.238]) with mapi id 14.02.0318.004; Wed, 26 Dec 2012 10:42:52 +0200 From: Yoav Nir To: Valery Smyslov , "ipsec@ietf.org" Thread-Topic: [IPsec] Error in RFC6290 Thread-Index: AQHN4y/c3fArnE5T60Wa6aVDlN07vJgqwzRA Date: Wed, 26 Dec 2012 08:42:52 +0000 Message-ID: <4613980CFC78314ABFD7F85CC30277210EE0910F@IL-EX10.ad.checkpoint.com> References: <20121203223404.5441.71025.idtracker@ietfa.amsl.com> <4613980CFC78314ABFD7F85CC30277210EDFD9D0@IL-EX10.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.81] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] Error in RFC6290 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 08:42:59 -0000 Hi I agree with point #2. I'll leave it to some of the session resumption expe= rts to comment on point #1. It's a little late for "Merry Christmas", so just happy new year. Yoav -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of V= alery Smyslov Sent: Wednesday, December 26, 2012 8:11 AM To: ipsec@ietf.org Subject: [IPsec] Error in RFC6290 Hi, RFC6290 (Quick Crash Detection) contains an error. In Section 4.3 it states= : For session resumption, as specified in [RFC5723], the situation is similar. The responder, which is necessarily the peer that has crashed, SHOULD send a new ticket within the protected payload of the IKE_SESSION_RESUME exchange. If the Initiator is also a token maker, it needs to send a QCD_TOKEN in a separate INFORMATIONAL exchange. But IKE_SESSION_RESUME exchange, as specified in RFC5723, doesn't contain a= ny protected payload - it is completely in clear and must be followed by IK= E_AUTH exchange. I suspect this error came from early versions of IKE SA Re= sumption protocol that, as far as I remember, did contain protected payload= . But currently this para should look like: For session resumption, as specified in [RFC5723], the situation is similar. The responder, which is necessarily the peer that has crashed, SHOULD send a new ticket in IKE_AUTH exchange that immediately followed IKE_SESSION_RESUME exchange. If the Initiator is also a token maker, it needs to send a QCD_TOKEN in the same IKE_AUTH exchange. And one more consideration. In Section 4.1 RFC6290 states: o Protocol ID (1 octet) MUST be 1, as this message is related to an IKE SA. o SPI Size (1 octet) MUST be zero, in conformance with Section 3.10 of [RFC5996]. I think here we have contradiction with RFC5996 (despite clamed conformance= with it). In abovementioned Section 3.10 it is written: o Protocol ID (1 octet) - If this notification concerns an existing SA whose SPI is given in the SPI field, this field indicates the type of that SA. For notifications concerning Child SAs, this field MUST contain either (2) to indicate AH or (3) to indicate ESP. Of the notifications defined in this document, the SPI is included only with INVALID_SELECTORS and REKEY_SA. If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt. Let me emphasize that RFC5996 clearly requires that If the SPI field is emp= ty, Protocol ID field MUST be sent as zero and MUST be ignored on receipt, = but RFC6290 while requiring SPI field to be empty, requres Protocol ID fiel= d to be non-zero. Actually, I see no value in this requirement, as Protocol= ID MUST be ignored on receipt anyway (if SPI field is empty), so it just c= omplicates protocol and makes it cumbersome. Merry Christmas, Valery Smyslov. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Email secured by Check Point From yaronf.ietf@gmail.com Wed Dec 26 09:16:06 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD2221F8C78 for ; Wed, 26 Dec 2012 09:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4l7IX3bG7ri for ; Wed, 26 Dec 2012 09:16:05 -0800 (PST) Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id 67F3221F89F8 for ; Wed, 26 Dec 2012 09:16:05 -0800 (PST) Received: by mail-ee0-f45.google.com with SMTP id d49so4277342eek.18 for ; Wed, 26 Dec 2012 09:16:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AUkPU7bbCwGejYgsFhHNNypgz4hyVLd/409FUMelNPk=; b=oUy9iCeU5LfX0hO1fIYirvwfu1PccU6NCmTrvaudsWQCZ4UucvmVZ6NYu5/v3FI9Mm ZK2Z4+Pb0DauKdOalMgA8pGoRbOj/J8J0akGpjf2iYeWEz7IWUraYQASqrCa68K12BrN aKzHaPJeEq7ojhXMHqQiVXSiM1LjNh1uess90GFSVN3plASeAvonaLcjpDcoJSVJYHeu MKHXJU7Sa9W8iNCxV0P87Wg3Uiv+mhdTZGA9vbg7tfuh4fJ1mBfFibcwILnnERC22TSM T7HbOTQOgJpiheUHm8Taj7ossFkmcgqUrBSQH8sDUso5A/qhC8apemL34+YIWQEQAGYP TCVQ== X-Received: by 10.14.223.135 with SMTP id v7mr71461037eep.41.1356542164428; Wed, 26 Dec 2012 09:16:04 -0800 (PST) Received: from [10.0.0.13] (85-250-110-45.bb.netvision.net.il. [85.250.110.45]) by mx.google.com with ESMTPS id 6sm54426745eea.3.2012.12.26.09.16.01 (version=SSLv3 cipher=OTHER); Wed, 26 Dec 2012 09:16:03 -0800 (PST) Message-ID: <50DB30CF.7010604@gmail.com> Date: Wed, 26 Dec 2012 19:15:59 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Yoav Nir References: <20121203223404.5441.71025.idtracker@ietfa.amsl.com> <4613980CFC78314ABFD7F85CC30277210EDFD9D0@IL-EX10.ad.checkpoint.com> <4613980CFC78314ABFD7F85CC30277210EE0910F@IL-EX10.ad.checkpoint.com> In-Reply-To: <4613980CFC78314ABFD7F85CC30277210EE0910F@IL-EX10.ad.checkpoint.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , Valery Smyslov Subject: Re: [IPsec] Error in RFC6290 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 17:16:06 -0000 Hi Yoav, Valery, Valery is right that the IKE_SESSION_RESUME exchange does not have a protected payload. But his new text is incorrect, since the (session resumption) ticket is sent in IKE_SESSION_RESUME and not in the immediately following IKE_AUTH (he might have got it mixed with the ticket sent when *requesting* a ticket). So I guess we should just replace "within the protected payload of the IKE_SESSION_RESUME exchange" by "within the IKE_SESSION_RESUME exchange". According to http://en.wikipedia.org/wiki/Christmas#Listing, it's still more than a week until the Eastern Churches' Christmas. So Merry Christmas to some of us, and a Happy New Year to all. Thanks, Yaron On 12/26/2012 10:42 AM, Yoav Nir wrote: > Hi > > I agree with point #2. I'll leave it to some of the session resumption experts to comment on point #1. > > It's a little late for "Merry Christmas", so just happy new year. > > Yoav > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Valery Smyslov > Sent: Wednesday, December 26, 2012 8:11 AM > To: ipsec@ietf.org > Subject: [IPsec] Error in RFC6290 > > Hi, > > RFC6290 (Quick Crash Detection) contains an error. In Section 4.3 it states: > > For session resumption, as specified in [RFC5723], the situation is > similar. The responder, which is necessarily the peer that has > crashed, SHOULD send a new ticket within the protected payload of the > IKE_SESSION_RESUME exchange. If the Initiator is also a token maker, > it needs to send a QCD_TOKEN in a separate INFORMATIONAL exchange. > > But IKE_SESSION_RESUME exchange, as specified in RFC5723, doesn't contain any protected payload - it is completely in clear and must be followed by IKE_AUTH exchange. I suspect this error came from early versions of IKE SA Resumption protocol that, as far as I remember, did contain protected payload. But currently this para should look like: > > For session resumption, as specified in [RFC5723], the situation is > similar. The responder, which is necessarily the peer that has > crashed, SHOULD send a new ticket in IKE_AUTH exchange > that immediately followed IKE_SESSION_RESUME exchange. > If the Initiator is also a token maker, it needs to send a QCD_TOKEN in > the same IKE_AUTH exchange. > > > > And one more consideration. In Section 4.1 RFC6290 states: > > o Protocol ID (1 octet) MUST be 1, as this message is related to an > IKE SA. > > o SPI Size (1 octet) MUST be zero, in conformance with Section 3.10 > of [RFC5996]. > > I think here we have contradiction with RFC5996 (despite clamed conformance with it). In abovementioned Section 3.10 it is written: > > o Protocol ID (1 octet) - If this notification concerns an existing > SA whose SPI is given in the SPI field, this field indicates the > type of that SA. For notifications concerning Child SAs, this > field MUST contain either (2) to indicate AH or (3) to indicate > ESP. Of the notifications defined in this document, the SPI is > included only with INVALID_SELECTORS and REKEY_SA. If the SPI > field is empty, this field MUST be sent as zero and MUST be > ignored on receipt. > > Let me emphasize that RFC5996 clearly requires that If the SPI field is empty, Protocol ID field MUST be sent as zero and MUST be ignored on receipt, but RFC6290 while requiring SPI field to be empty, requres Protocol ID field to be non-zero. Actually, I see no value in this requirement, as Protocol ID MUST be ignored on receipt anyway (if SPI field is empty), so it just complicates protocol and makes it cumbersome. > > Merry Christmas, > Valery Smyslov. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Email secured by Check Point > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From svanru@gmail.com Wed Dec 26 09:58:51 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0693621F8CB0 for ; Wed, 26 Dec 2012 09:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zzr+v0bUyMIG for ; Wed, 26 Dec 2012 09:58:50 -0800 (PST) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) by ietfa.amsl.com (Postfix) with ESMTP id A3FDB21F8C6C for ; Wed, 26 Dec 2012 09:58:49 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id r15so10823902lag.22 for ; Wed, 26 Dec 2012 09:58:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:from:to:cc:references:subject:date :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:x-mailer:x-mimeole; bh=9kudY7aGC0FljxEqsbqPihLHnBxmAND0wuw3u26VZbA=; b=BugvHUV6wnXuhCSaYzIaJ/EEu+XdfpXWeCmVHU2xZXoPJzF2eyNG+6XTwpGlUck7BX OeTE/NP15OnNZTe6vlwM9HUm/UN7yrnifyDvB5Ww3kEvyPxQ/wqaqhs6eXg7/5TtQS1+ XDjxuYm3t+SBBZUVrkfYM4Wv4FqSV69kT2au5VgU8ZNVnDupCMeISDYnj24T6etClR2a 6iDI1r8h3spd/5mThUM7EV8lpYohGMtqOi0U/HSIPu6iMVrHTxVNRetE+Kw0mw2wlTRa 4wYH4AIW55dvHzK1e4/t7ZZIt/s8Z4eaOailOMVznoDbHLm58kcTKF5V0fjFOHJ7mVZn nPxw== X-Received: by 10.152.47.75 with SMTP id b11mr25677845lan.14.1356544728109; Wed, 26 Dec 2012 09:58:48 -0800 (PST) Received: from chichi (ppp91-77-170-54.pppoe.mtu-net.ru. [91.77.170.54]) by mx.google.com with ESMTPS id hc20sm10321300lab.11.2012.12.26.09.58.46 (version=SSLv3 cipher=OTHER); Wed, 26 Dec 2012 09:58:47 -0800 (PST) Message-ID: <472FFB92C2804A6B8EDFD96421D52B42@chichi> From: "Valery Smyslov" To: "Yaron Sheffer" , "Yoav Nir" References: <20121203223404.5441.71025.idtracker@ietfa.amsl.com> <4613980CFC78314ABFD7F85CC30277210EDFD9D0@IL-EX10.ad.checkpoint.com> <4613980CFC78314ABFD7F85CC30277210EE0910F@IL-EX10.ad.checkpoint.com> <50DB30CF.7010604@gmail.com> Date: Wed, 26 Dec 2012 21:58:41 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: ipsec@ietf.org Subject: Re: [IPsec] Error in RFC6290 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 17:58:51 -0000 Hi Yaron, oh, you've catched one more error in this text - it mixed up terms "ticket" (used in RFC5723 as Session Resumption ticket) and "token" (used in RFC6290 as QCD token). I din't notice that. You are right, that "ticket" (Session Resumption) is sent in IKE_SESSION_RESUME, but RFC6290 talks where QCD token must be sent. And from my understanding of the whole protocol it must not be sent in clear under any circumstances (otherwise eavesdropper can easily tear down IKE SA), so the only logical place for it in case of IKE SA resumption is IKE_AUTH exchange that immediately follows IKE_SESSION_RESUME. So, I think, correct text should be: For session resumption, as specified in [RFC5723], the situation is similar. The responder, which is necessarily the peer that has crashed, SHOULD send a new QCD_TOKEN in IKE_AUTH exchange that immediately followes IKE_SESSION_RESUME exchange. If the Initiator is also a token maker, it needs to send a QCD_TOKEN in the same IKE_AUTH exchange. Best wishes, Valery. > Hi Yoav, Valery, > > Valery is right that the IKE_SESSION_RESUME exchange does not have a protected payload. > > But his new text is incorrect, since the (session resumption) ticket is sent in IKE_SESSION_RESUME > and not in the immediately following IKE_AUTH (he might have got it mixed with the ticket sent > when *requesting* a ticket). So I guess we should just replace "within the protected payload of > the IKE_SESSION_RESUME exchange" by "within the IKE_SESSION_RESUME exchange". > > According to http://en.wikipedia.org/wiki/Christmas#Listing, it's still more than a week until the > Eastern Churches' Christmas. So Merry Christmas to some of us, and a Happy New Year to all. > > Thanks, > Yaron > > > On 12/26/2012 10:42 AM, Yoav Nir wrote: >> Hi >> >> I agree with point #2. I'll leave it to some of the session resumption experts to comment on >> point #1. >> >> It's a little late for "Merry Christmas", so just happy new year. >> >> Yoav >> >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Valery Smyslov >> Sent: Wednesday, December 26, 2012 8:11 AM >> To: ipsec@ietf.org >> Subject: [IPsec] Error in RFC6290 >> >> Hi, >> >> RFC6290 (Quick Crash Detection) contains an error. In Section 4.3 it states: >> >> For session resumption, as specified in [RFC5723], the situation is >> similar. The responder, which is necessarily the peer that has >> crashed, SHOULD send a new ticket within the protected payload of the >> IKE_SESSION_RESUME exchange. If the Initiator is also a token maker, >> it needs to send a QCD_TOKEN in a separate INFORMATIONAL exchange. >> >> But IKE_SESSION_RESUME exchange, as specified in RFC5723, doesn't contain any protected payload - >> it is completely in clear and must be followed by IKE_AUTH exchange. I suspect this error came >> from early versions of IKE SA Resumption protocol that, as far as I remember, did contain >> protected payload. But currently this para should look like: >> >> For session resumption, as specified in [RFC5723], the situation is >> similar. The responder, which is necessarily the peer that has >> crashed, SHOULD send a new ticket in IKE_AUTH exchange >> that immediately followed IKE_SESSION_RESUME exchange. >> If the Initiator is also a token maker, it needs to send a QCD_TOKEN in >> the same IKE_AUTH exchange. >> >> >> >> And one more consideration. In Section 4.1 RFC6290 states: >> >> o Protocol ID (1 octet) MUST be 1, as this message is related to an >> IKE SA. >> >> o SPI Size (1 octet) MUST be zero, in conformance with Section 3.10 >> of [RFC5996]. >> >> I think here we have contradiction with RFC5996 (despite clamed conformance with it). In >> abovementioned Section 3.10 it is written: >> >> o Protocol ID (1 octet) - If this notification concerns an existing >> SA whose SPI is given in the SPI field, this field indicates the >> type of that SA. For notifications concerning Child SAs, this >> field MUST contain either (2) to indicate AH or (3) to indicate >> ESP. Of the notifications defined in this document, the SPI is >> included only with INVALID_SELECTORS and REKEY_SA. If the SPI >> field is empty, this field MUST be sent as zero and MUST be >> ignored on receipt. >> >> Let me emphasize that RFC5996 clearly requires that If the SPI field is empty, Protocol ID field >> MUST be sent as zero and MUST be ignored on receipt, but RFC6290 while requiring SPI field to be >> empty, requres Protocol ID field to be non-zero. Actually, I see no value in this requirement, as >> Protocol ID MUST be ignored on receipt anyway (if SPI field is empty), so it just complicates >> protocol and makes it cumbersome. >> >> Merry Christmas, >> Valery Smyslov. >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> Email secured by Check Point >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> From ynir@checkpoint.com Sun Dec 30 05:01:45 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B8921F8958 for ; Sun, 30 Dec 2012 05:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.506 X-Spam-Level: X-Spam-Status: No, score=-10.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mO+5+QeszFRk for ; Sun, 30 Dec 2012 05:01:44 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4948821F871A for ; Sun, 30 Dec 2012 05:01:42 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id qBUD1cSl006692; Sun, 30 Dec 2012 15:01:38 +0200 X-CheckPoint: {50E039A6-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.238]) by IL-EX10.ad.checkpoint.com ([169.254.2.238]) with mapi id 14.02.0318.004; Sun, 30 Dec 2012 15:01:38 +0200 From: Yoav Nir To: Valery Smyslov Thread-Topic: [IPsec] Error in RFC6290 Thread-Index: AQHN4y/c3fArnE5T60Wa6aVDlN07vJgqwzRAgABuPYCAAC2JiIAF1CyA Date: Sun, 30 Dec 2012 13:01:37 +0000 Message-ID: <4613980CFC78314ABFD7F85CC30277210EE0BD0F@IL-EX10.ad.checkpoint.com> References: <20121203223404.5441.71025.idtracker@ietfa.amsl.com> <4613980CFC78314ABFD7F85CC30277210EDFD9D0@IL-EX10.ad.checkpoint.com> <4613980CFC78314ABFD7F85CC30277210EE0910F@IL-EX10.ad.checkpoint.com> <50DB30CF.7010604@gmail.com> <472FFB92C2804A6B8EDFD96421D52B42@chichi> In-Reply-To: <472FFB92C2804A6B8EDFD96421D52B42@chichi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.157] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <40C4F2048115A4459FCE44F5C7B78EE8@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [IPsec] Error in RFC6290 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 13:01:45 -0000 I agree. On Dec 26, 2012, at 7:58 PM, Valery Smyslov wrote: > Hi Yaron, >=20 > oh, you've catched one more error in this text - it mixed up terms "ticke= t" > (used in RFC5723 as Session Resumption ticket) and "token" > (used in RFC6290 as QCD token). I din't notice that. You are right, > that "ticket" (Session Resumption) is sent in IKE_SESSION_RESUME, > but RFC6290 talks where QCD token must be sent. And from my understanding > of the whole protocol it must not be sent in clear under any circumstance= s > (otherwise eavesdropper can easily tear down IKE SA), so the only logical > place for it in case of IKE SA resumption is IKE_AUTH exchange > that immediately follows IKE_SESSION_RESUME. So, I think, > correct text should be: >=20 > For session resumption, as specified in [RFC5723], the situation is > similar. The responder, which is necessarily the peer that has > crashed, SHOULD send a new QCD_TOKEN in IKE_AUTH exchange > that immediately followes IKE_SESSION_RESUME exchange. > If the Initiator is also a token maker, it needs to send a QCD_TOKEN i= n > the same IKE_AUTH exchange. >=20 > Best wishes, > Valery.