From david.black@emc.com Mon Oct 10 21:42:22 2011 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 3029921F8D38 for ; Mon, 10 Oct 2011 21:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oC3NavstQCjB for ; Mon, 10 Oct 2011 21:42:21 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC4321F8D29 for ; Mon, 10 Oct 2011 21:42:20 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p9B4gKB4026506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Oct 2011 00:42:20 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Tue, 11 Oct 2011 00:42:13 -0400 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.221.56.102]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p9B4gD4p005461 for ; Tue, 11 Oct 2011 00:42:13 -0400 Received: from mx14a.corp.emc.com ([169.254.1.78]) by mxhub13.corp.emc.com ([128.221.56.102]) with mapi; Tue, 11 Oct 2011 00:42:13 -0400 From: To: Date: Tue, 11 Oct 2011 00:42:11 -0400 Thread-Topic: iSCSI: IPsec requirements Thread-Index: Acx8jUvC2Rsx1YNhR8mJYm/zd3iOdwLGrwDA Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058CFE5BAC@MX14A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: david.black@emc.com Subject: [IPsec] iSCSI: IPsec requirements 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 Oct 2011 04:42:22 -0000 As a co-chair of the storm WG, I'm looking for some input on updating the I= Psec requirements for iSCSI, which is the subject of a WG Last Call comment agai= nst the new iSCSI draft. The history here is that as part of the original work for iSCSI (and some a= dditional storage protocols), a profile of the then-current version of IPsec (2400-se= ries RFCs) was produced (RFC 3723), and iSCSI (RFC 3720) has "MUST implement" requirem= ents for that version of IPsec. By the time iSCSI was completed, the next version o= f IPsec (4300-series RFCs) was imminent, but a deliberate decision was made to have= both RFC 3720 and 3723 continue to refer to the older version of IPsec. A primary reason at the time was that iSCSI and IPsec implementations are g= enerally independent, and the most likely implementation path for iSCSI involved exi= sting older IPsec implementations. That was back in 2004, and the IPsec world ha= s moved on since them. The issue has been raised that it may not be appropriate fo= r the new iSCSI RFC-to-be to continue to require implementation of RFC 2400-series IP= sec. The new iSCSI draft is fully backwards compatible with the existing iSCSI R= FCs (in contrast to IPsec, where the versions of IKE deliberately don't interoperat= e), so jumping straight to 4300-series IPsec does not seem like a good move unless 2400-series IPsec is extinct for all practical purposes. Assuming 2400-series IPsec is not extinct, the appropriate requirements may= be of roughly the following form (this is a template, see RFC 3720 or 3723 for th= e specific requirements to which this structure is to be applied): - MUST implement IPsec, 2400-series RFCs or 4300-series RFCs. - SHOULD implement IPsec, 4300-series RFCs. - I'm not inclined to also say: SHOULD NOT implement 2400-series IPsec. OTOH, if 2400-series IPsec is extinct for all practical purposes, that all = reduces to - MUST implement IPsec, 4300-series. I'm interested in comments on what the right thing to do is here and why. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From mcr@sandelman.ca Tue Oct 11 18:40:54 2011 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 070D921F8B66 for ; Tue, 11 Oct 2011 18:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[AWL=0.570, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qo1PtS2TabV9 for ; Tue, 11 Oct 2011 18:40:53 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB2321F8B3D for ; Tue, 11 Oct 2011 18:40:53 -0700 (PDT) Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id 4A7F2343A2; Tue, 11 Oct 2011 21:39:47 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 14FE498C90; Tue, 11 Oct 2011 21:41:43 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 0E64298B2E; Tue, 11 Oct 2011 21:41:43 -0400 (EDT) From: Michael Richardson To: david.black@emc.com In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E058CFE5BAC@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E058CFE5BAC@MX14A.corp.emc.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 11 Oct 2011 21:41:43 -0400 Message-ID: <26551.1318383703@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: ipsec@ietf.org Subject: Re: [IPsec] iSCSI: IPsec requirements 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 Oct 2011 01:40:54 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "david" =3D=3D david black writes: david> Assuming 2400-series IPsec is not extinct, the appropriate requi= rements may be of david> roughly the following form (this is a template, see RFC 3720 david> or 3723 for the specific=20 Well, I'm not really sure how to answer your question. There is certainly still lots and lots and lots of 2400-series IPsec in use. I'd say it was the majority in devices which can easily be upgraded, and which aren't because IKEv1 still works well for the solution space out there. Certainly IKEv2 is pretty rare on smartphones, I'd say for *VPN* connectivity.=20=20 While at the same time, it's required for 3GPP interop (my understanding, I never wrote that code myself) However, we aren't talking about general purpose devices, but rather operating systems, HBA cards, virtualization systems (iSCSI clients) and NAS (iSCSI targets). Presuming that none of these devices is going to want to stop claiming conformance to RFC 3723/RFC 3720, then they will have to continue to implement IPsec-2400 series.=20 The only advantage to implementing IPsec-4300 series would be on newer devices where code space and configuration is an issue, i.e. HBAs.=20=20 It isn't like an IKEv2 speaking endpoint can't recognize and speak IKEv1, particularly when it is a responder, it doesn't even cost a round trip. I don't know what other things you are updating in this round, so I don't know what other things might drive an implementation to do RFC3720bis, but would prevent it from deploying IKEv2. I therefore think that you should MUST implement 4300 (IKEv2), and MAY implement 2400 series (IKEv1). Note that the *ESP* level things, like extended sequence numbers that appears in 4300 can be negotiated, so it's really not that big a deal to MUST the rest of 4300 stuff in my opinion.=20 All the iSCSI devices that want to support 3723/3720 clients is going to support IKEv1. But, if there is a greenfield implementation of 3720bis, then they could implement only the much simpler IKEv2. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATpTwVoCLcPvd0N1lAQIsRwf+Oe8XcjftfVTtCvB8P58wlPXo+KVZ9x+O FUSBHWjeMs+d1b83WU18cw/RzYUH1DtjkVmNnzgFU0D+MFJ2HgzUZV+I8eWAMxXY dBsRErPaWUVWnm0/iEKXpd0GbpQuL6jp1LSpCoYZB2ux67NZgAwlkXQKTqFt8dyD CllcAvilMbxrX+bIgzlOaFUcZoM/mnLSWgJSS/KQ8BDVcXMh9ry41r3vpf/+26Lo 1mqn7LPPp3zdblxhO3Jb8QXUASA19zDtLaJ1zjTDKctQylPHl0GLK+41WVOLJ3rB Q8dwb1RtydSsg58lxD48jZkHdiQuEHOf7pUn02NqR0fPR5NBKMvDJA== =ytOE -----END PGP SIGNATURE----- --=-=-=-- From ramaswamy.bm@globaledgesoft.com Wed Oct 12 02:14:38 2011 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 A238721F8C4C for ; Wed, 12 Oct 2011 02:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQAP2sbJT8bl for ; Wed, 12 Oct 2011 02:14:37 -0700 (PDT) Received: from gesmail.globaledgesoft.com (gesmail.globaledgesoft.com [119.82.106.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6327521F8C48 for ; Wed, 12 Oct 2011 02:14:36 -0700 (PDT) Received: from RamaswamySM (ramaswamy_sm.globaledgesoft.com [172.16.8.54]) by gesmail.globaledgesoft.com (Postfix) with ESMTP id 97FA158823B; Wed, 12 Oct 2011 14:48:07 +0530 (IST) From: "ramaswamy" To: "'Tero Kivinen'" References: <20013.29623.491247.654466@fireball.kivinen.iki.fi> <90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com> <4E2EA248.70708@gmail.com> <008901cc63b8$e5c9c640$b15d52c0$@bm@globaledgesoft.com> <20060.43306.157789.942917@fireball.kivinen.iki.fi> <00e301cc76d8$44b0e940$ce12bbc0$@bm@globaledgesoft.com> <20087.57900.897702.835641@fireball.kivinen.iki.fi> In-Reply-To: Date: Wed, 12 Oct 2011 14:44:22 +0530 Message-ID: <009b01cc88bf$549f2a30$fddd7e90$@bm@globaledgesoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acx3Lw/ZXwa4JV2PQYSqB5taTHlj8gALYVdAAWjgLsAC78sooA== Content-Language: en-us Cc: ipsec@ietf.org, ipsec-tools-devel@lists.sourceforge.net, ipsec-tools-users@lists.sourceforge.net, ikev2-devel@lists.sourceforge.net Subject: Re: [IPsec] New method to resist replay attack in ikev2 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 Oct 2011 09:14:38 -0000 Please see my comments inline. Best Regards , Ram -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen Sent: Tuesday, September 20, 2011 6:16 AM To: ramaswamy Cc: ipsec@ietf.org; ipsec-tools-devel@lists.sourceforge.net; ipsec-tools-users@lists.sourceforge.net; ikev2-devel@lists.sourceforge.net Subject: Re: [IPsec] New method to resist replay attack in ikev2 ramaswamy writes: > Thanks for the response, I agree with your comments, I think we can > use certificates to avoid man in the middle attacks and error message > flooding in the INIT phase only, as certificates are signed by trusted > certificate authorities authenticity is ensured. > > If certificates are used in INIT message exchanges [mutual > authentication], we can effectively avoid afore said attacks as it > avoids huge computation of IKE-keys before the client OR server is authenticated. RSA operations are already huge computation. There is no big difference whether you do RSA or Diffie-Hellman. >>>>>>>>>>> [Ram] I agree with you, but we have certificate verification done at AUTH phase, our suggestion is the same can be moved to initial phase of ikev2 exchanges and this will ensure authenticity before IKEv2-KEYS[seven keys] are generated. As IKE users are already authenticated there is no need of CERT message exchanges in AUTH phase and also which in turn will help to avoid man in the middle attacks and error message flooding at IKEv2-INIT level only. And also it will avoid unnecessary computation of ikev2-keys[seven keys: which involves huge computation] at server end due to INIT-REQESTS sent by attackers. >>>>>>>>>>>>>>>>>>>>>>>>>>> > To avoid Replay attacks: > By using RSA private key of certificate to encrypt the nonce (Ni) in > INIT_REQUEST message we can avoid replay attacks, at the receiving > end, first certificate is verified using root CA and nonce is > decrypted using public key of the received certificate which ensures > that sender holds the valid private key of the certificate and not an > attacker. By using nonce we can avoid Replay attacks[Packets can be > rejected if the same nonce is received within a particular session]. So you plan to store that nonce forever, and always verify that the nonce is not used before? That would be extremely expensive way to solve the replay attack. >>>>>>>>>>> [Ram] I agree that storing nonce forever is not an best solution to solve replay attacks, but our suggestion is to store the nonce from particular client for particular session [time limit Eg: 2 minutes]. If it receives same nonce with in the permissible time limit it should rejected. If it more than permissible limit server will throw an error SKEW_ERROR, handling of which is explained below. To do it more effectively Ikev2 client should be clock synchronized with server by negotiating client time by using encrypted nonce(Ni) --> timestamp [Ni is encrypted by RSA private key of certificate of ikev2 client certificate] in INIT-REQUEST it self, and server can check the received time [encrypted nonce(Ni):timestamp] and if it is more than permissible time limit say Eg: 2 minutes it can throw an clock skew error[SKEW_ERROR], by putting its server time using encrypted server nonce (Nr) using RSA private key of certificate of ikev2 server certificate. Upon receipt of skew error ikev2 client must compute the difference (in seconds) between the two clocks based upon the client and server time contained in the SKEW_ERROR message. The client should store this clock difference in non-volatile memory and must use it to adjust ikev2 client timestamps[Ni] in subsequent INIT-REQ request messages by adding the clock skew to its local clock value each time. If the encrypted nonce differs from server time by permissible limit it can reject the INIT-REQ and avoid replay attacks. >>>>>>>>>>>>>>>>>> -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From david.black@emc.com Wed Oct 12 09:58:47 2011 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 C9F2C21F8B98 for ; Wed, 12 Oct 2011 09:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.548 X-Spam-Level: X-Spam-Status: No, score=-104.548 tagged_above=-999 required=5 tests=[AWL=2.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzCSg86uozt2 for ; Wed, 12 Oct 2011 09:58:47 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1125F21F8B7C for ; Wed, 12 Oct 2011 09:58:46 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p9CGwjrF006091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Oct 2011 12:58:45 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Wed, 12 Oct 2011 12:58:37 -0400 Received: from mxhub08.corp.emc.com (mxhub08.corp.emc.com [128.221.46.116]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p9CGvsjI005243; Wed, 12 Oct 2011 12:58:36 -0400 Received: from mx14a.corp.emc.com ([169.254.1.78]) by mxhub08.corp.emc.com ([128.221.46.116]) with mapi; Wed, 12 Oct 2011 12:58:11 -0400 From: To: Date: Wed, 12 Oct 2011 12:58:10 -0400 Thread-Topic: [IPsec] iSCSI: IPsec requirements Thread-Index: AcyIgA1+nMQ53fVfQtG1cSKwr0nKqwAfy/ug Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058CFE5FC9@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E058CFE5BAC@MX14A.corp.emc.com> <26551.1318383703@marajade.sandelman.ca> In-Reply-To: <26551.1318383703@marajade.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: ipsec@ietf.org, david.black@emc.com Subject: Re: [IPsec] iSCSI: IPsec requirements 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 Oct 2011 16:58:47 -0000 Michael, Thanks for the response. iSCSI is a rather stable protocol - existing implementations are expected t= o comply with this new spec with little to no change. There is another dra= ft in the storm WG that is making minor functional additions to iSCSI (give= n the number of years since RFC 3720, the amount of change needed is surpri= singly small). The new spec needs to normatively reference and update RFC 3723 (but there = will be no 3723bis), so it sounds like the right approach is the following = combination: - MUST implement IPsec, 2400-series RFCs (IPsec v2, IKEv1). - SHOULD implement IPsec, 4300-series RFCs (IPsec v3, IKEv2). The MUST is for interoperability and to acknowledge what's out there; the S= HOULD is to encourage implementers to move forward. Now I need to go write= the actual text to go into the draft. Thanks, --David > -----Original Message----- > From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] > Sent: Tuesday, October 11, 2011 9:42 PM > To: Black, David > Cc: ipsec@ietf.org > Subject: Re: [IPsec] iSCSI: IPsec requirements >=20 >=20 > >>>>> "david" =3D=3D david black writes: > david> Assuming 2400-series IPsec is not extinct, the appropriate req= uirements may be of > david> roughly the following form (this is a template, see RFC 3720 > david> or 3723 for the specific >=20 > Well, I'm not really sure how to answer your question. > There is certainly still lots and lots and lots of 2400-series IPsec in > use. I'd say it was the majority in devices which can easily be > upgraded, and which aren't because IKEv1 still works well for the > solution space out there. Certainly IKEv2 is pretty rare on > smartphones, I'd say for *VPN* connectivity. > While at the same time, it's required for 3GPP interop (my > understanding, I never wrote that code myself) >=20 > However, we aren't talking about general purpose devices, but rather > operating systems, HBA cards, virtualization systems (iSCSI clients) and > NAS (iSCSI targets). >=20 > Presuming that none of these devices is going to want to stop claiming > conformance to RFC 3723/RFC 3720, then they will have to continue to > implement IPsec-2400 series. >=20 > The only advantage to implementing IPsec-4300 series would be on newer > devices where code space and configuration is an issue, i.e. HBAs. > It isn't like an IKEv2 speaking endpoint can't recognize and speak > IKEv1, particularly when it is a responder, it doesn't even cost a round > trip. >=20 > I don't know what other things you are updating in this round, so I > don't know what other things might drive an implementation to do > RFC3720bis, but would prevent it from deploying IKEv2. >=20 > I therefore think that you should MUST implement 4300 (IKEv2), and MAY > implement 2400 series (IKEv1). Note that the *ESP* level things, like > extended sequence numbers that appears in 4300 can be negotiated, so > it's really not that big a deal to MUST the rest of 4300 stuff in my > opinion. >=20 > All the iSCSI devices that want to support 3723/3720 clients is going to > support IKEv1. But, if there is a greenfield implementation of 3720bis, > then they could implement only the much simpler IKEv2. >=20 >=20 > -- > ] He who is tired of Weird Al is tired of life! | firewa= lls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net arch= itect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device d= river[ > Kyoto Plus: watch the video > then sign the petition. From mayer@ntp.org Thu Oct 13 07:43:59 2011 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 D49DE21F8B6D; Thu, 13 Oct 2011 07:43:59 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkuFiRFuFhAA; Thu, 13 Oct 2011 07:43:58 -0700 (PDT) Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by ietfa.amsl.com (Postfix) with ESMTP id 9440321F8AF9; Thu, 13 Oct 2011 07:43:55 -0700 (PDT) Received: from [198.22.153.6] (helo=[10.60.102.37]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1REMVh-0007vP-EZ; Thu, 13 Oct 2011 14:43:52 +0000 Message-ID: <4E96F91E.3020202@ntp.org> Date: Thu, 13 Oct 2011 10:43:42 -0400 From: Danny Mayer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Cui Yang References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> In-Reply-To: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 198.22.153.6 X-SA-Exim-Rcpt-To: cuiyang@huawei.com, ipsec@ietf.org, TICTOC@ietf.org, gnn@neville-neil.com X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) X-Mailman-Approved-At: Thu, 13 Oct 2011 08:16:41 -0700 Cc: "ipsec@ietf.org" , George Neville-Neil , "TICTOC@ietf.org" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 14:44:00 -0000 On 9/18/2011 9:41 PM, Cui Yang wrote: > Dear IPsec experts, > cc TICTOC WG > > May I make a review request for the draft on > "IPsec security for packet based synchronization" > > http://datatracker.ietf.org/doc/draft-xu-tictoc-ipsec-security-for-synchronization/ > > Abstract: > Cellular networks often use Internet standard technologies to handle > synchronization. This document defines an extension based on WESP. > Usually, several traffic flows are carried in one IPsec tunnel, for > some applications, such as, 1588 or NTP, the packets need to be > identified after IPsec encryption to handle specially. In order to > achieve high scalability in implement, a separate IPsec tunnel will > not be established for some special traffic. This document analyses > the need for security methods for synchronization messages > distributed over the Internet. This document also gives a solution > on how to mark the synchronization message when IPSec is implemented > in end to end frequency synchronization." > > This work is proposed in TICTOC WG, but closely related to the IPsec security issues in synchronization. > We would like to get advices from security experts. I have strong objections to this draft. There are no clear reasons to do it, it totally ignores the requirements for what a timing packet needs in favor of identifying the timing packets which once identified externally become a potential target for attack. Since this draft is about security for synchronization you've just lost your security. This draft concentrates totally on identifying how to identify timing packets but there is no consideration for the timing packet's requirements and why you should do it in the first place. I also note that this is marked as Standards Track so there needs to be very good justification for doing something like this. Sending an NTP packet through an IPsec tunnel with all of the encryption/decryption involved throws out the error budget needed for timing packets. So why are you doing this in the first place? There is no need for encryption on a timing packet since it has no secrets. IEEE-1588 (PTP) also cannot benefit from this as it is basically a hardware-stamping protocol and now you are routing it through a software tunnel which means it has to be timestamped before it is IPsec encapsulated which decreases it's accuracy. It's no longer on-wire. Please also note that this is an IETF Working Group. Your informative References need to provide a publicly available location where to get them. Furthermore the NTP RFC (RFC5905) is not even referenced. Going into details: In Section 1 (Introduction) you state that: "the timing signal purports to come from a higher quality clock than it actually does.... this may be used to attack the integrity of the network, to disrupt the synchronization flow, or cause authentication failures". However the proposal in your draft is to identify those very packets you are trying to protect, so an attacker just needs to create fake timing packets and inject them into the stream causing disruption or in a MIM attack just cause them to be dropped. Knowing how to identify them makes this easy. You also say that "it may be possible for unauthorized users to request service from a clock server" but you do not state why this is a problem. You don't care about other clients, if they get a packet it makes no difference. A NTP server can be told which requests to respond to and PTP is basically unidirectional and all packets flow downstream. In NTP the autokey protocol (RFC 5906) can be used to authenticate the server if the receiving client needs to ensure the validity of it's timing packet. "Femtocell ... requires time synchronization" But it fails to state what kind of synchronization or accuracy is needed. If you don't know the error budget you don't know whether or not the recommendations being made will support the requirements nor is there any reference to a publicly available document that states such requirements. I cannot analyze this any further as your reference [3GPP.33.320] does not provide a publicly available document reference required of all IETF RFC's and drafts. Section 3 talks about ITUT [G.8265] which also does not point to a publicly available document reference and that "timing packets flow across multiple network domains which may introduce specific security requirements". It does not say what those specific security requirements are or how they should be addressed. NTP (RFC 5905) can use the Autokey protocol (RFC 5906) to authenticate the packets and can tolerate packet loss over a very large Wide-Area Network with no problems so it's not clear what the concern is. >From items in section 3: 1. "synchronization client SHOULD be prevented from connecting to rogue clock servers". How do you identify a "rogue" clock server? In NTP the client requests NTP packets of a specific set of servers and can authenticate them through autokey and furthermore does not rely on a single NTP server and is likely to throw out packets received from a server that is out of the range of the other servers. In NTP terms this is designated as a falseticker. See RFC 5905. 2. "clock servers SHOULD be prevented from providing service to unauthorized synchronization client" Again how do you know what is "unauthorized"? The server can be configured to ignore requests from clients not on its list but why do you care about this? How is this a security concern? 3. "Security mechanisms to achieve synchronization SHOULD minimize any degradation in performance and this side effect SHOULD be controlled to meet specific synchronization requirements (e.g. Femtocell synchronization)." It's not clear why this is in this document since that would always be a goal. IPsec will always degrade performance to some degree but the real concern here is not the degradation in performance but the degradation in accuracy of the timing packets and IPsec definitely makes it worse. Section 4 talks about "Security mechanism for synchronization" and talks about authentication-based and encryption-based security. If you are talking about IPsec the packets are already encrypted so where are you going with this? If you already have a rogue within the tunnel you have bigger problems than worrying about the timing packets. "Full encryption might be required for various reasons. The content of the packet may be considered secret, such as might be the case where the accuracy of time distribution is sold as a service." This is a rather bizarre statement. If you are selling a service, you refused to respond to requests unless you are listed at the server and you provide the secret key for authentication purposes through an OOB mechanism to the customer buying the service. There is nothing secret about a timing packet. It is already "out-of-date" the moment it goes on the wire. The only thing of importance for a timing packet is how quickly you can deliver it to the recipient. Nothing else matters. It is also worth pointing out that there are lots of publicly available NTP servers out there which are available through the NTP pool (pool.ntp.org) so most clients do not need to look for other sources like the ones you are discussing. A customer that NEEDS good timing packets is going to make sure that they get a good source and not try to piggyback off a third-party's mechanisms. If funneling all traffic through an IPsec tunnel for other reasons then you still need to consider whether it will degrade the accuracy of the timing packet to such as an extent that the timing packet becomes useless as a synchronization source. The error budget is all important here, security is just a minor issue. You don't want or need to protect the time packets, you need to get them delivered as fast as possible and to allow the receiving client to authenticate the server by whatever means you deem best. In Section 5 you discuss how to identify the synchronization messages in IPsec in the physical layer in order to improve the synchronization accuracy but you do not say how identifying the packets will accomplish this task. While the document is not about that there should at least be a reference to a document that describes how identifying the synchronization packets will improve the synchronization accuracy. Ignored in Section 6 description of the operation of how it works with the Security Gateway and the Femtocell is the fact that a lot of processing is taking place, there is additional transmission of the packet and it doesn't take advantage of the fact that the WESP packet can potentially add some sort of timestamp information so that the receiver can calculate some of the additional timing delays introduced by these additional mechanisms. Section 8 - Security Considerations mentions security properties of ESP but does not discuss the reduction in security that would result in the ability to identify the time packets which would allow the attacker to block or intercept the time packets. Yet it is critical to discuss this part otherwise why would you use IPsec at all? I don't know anything about Frequency synchronization packets so what those affects would be I cannot discuss but that also needs attention. Under Nits, a lot of acronyms are used in the document without spelling out what they mean. Acronyms needs to be spelled out on first use and documents referenced where relevant. External documents (non-IETF) need to provide an online publicly available location reference. Danny From ynir@checkpoint.com Thu Oct 13 22:23:36 2011 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 3823621F8C1E for ; Thu, 13 Oct 2011 22:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roOGYTKJJanL for ; Thu, 13 Oct 2011 22:23:35 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4CF21F8C0F for ; Thu, 13 Oct 2011 22:23:35 -0700 (PDT) X-CheckPoint: {4E97C71C-10008-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p9E5NXWL026872 for ; Fri, 14 Oct 2011 07:23:33 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 14 Oct 2011 07:23:33 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Fri, 14 Oct 2011 07:23:34 +0200 From: Yoav Nir To: "ipsec@ietf.org" Date: Fri, 14 Oct 2011 07:23:31 +0200 Thread-Topic: New -00 draft: Creating Large Scale Mesh VPNs Problem Statement Thread-Index: AcyKMWox+6ym89crSny8HqKBPuoyDg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Subject: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 05:23:36 -0000 Hi all For years, one of the barriers to the adoption of IPsec was that configuration didn't scale. With thousands of peers, the PAD and SPD would become unwieldy, so even where IPsec was deployed it was often built in hub-and-spoke configurations, not because policy demanded this, but because it was more convenient to configure. Individual vendors have incompatible solutions for this, but they only work with that vendor's products, and within the same administrative domain. In this draft, we are proposing that the IPsecME working group take on a working item to first define the problem, and then offer solutions that will make IPsec scale better and in an inter-operable way. We plan to hold a side meeting in Taipei, and we welcome comments both before and at that meeting. Yoav http://www.ietf.org/id/draft-nir-ipsecme-p2p-00.txt http://tools.ietf.org/html/draft-nir-ipsecme-p2p-00 From dharkins@lounge.org Thu Oct 13 23:18:51 2011 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 C0A4721F8C46 for ; Thu, 13 Oct 2011 23:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POeblCs2-WYy for ; Thu, 13 Oct 2011 23:18:51 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5378921F8C20 for ; Thu, 13 Oct 2011 23:18:51 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id E89FBA88811A; Thu, 13 Oct 2011 23:18:50 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 13 Oct 2011 23:18:51 -0700 (PDT) Message-ID: <20d9fa38a4964b77176e7eb0579d0199.squirrel@www.trepanning.net> In-Reply-To: References: Date: Thu, 13 Oct 2011 23:18:51 -0700 (PDT) From: "Dan Harkins" To: "Yoav Nir" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "ipsec@ietf.org" Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 06:18:51 -0000 Sounds like TED: http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/ted.html Dan. On Thu, October 13, 2011 10:23 pm, Yoav Nir wrote: > Hi all > > For years, one of the barriers to the adoption of IPsec was that > configuration didn't scale. With thousands of peers, the PAD and SPD would > become unwieldy, so even where IPsec was deployed it was often built in > hub-and-spoke configurations, not because policy demanded this, but > because it was more convenient to configure. Individual vendors have > incompatible solutions for this, but they only work with that vendor's > products, and within the same administrative domain. > > In this draft, we are proposing that the IPsecME working group take on a > working item to first define the problem, and then offer solutions that > will make IPsec scale better and in an inter-operable way. > > We plan to hold a side meeting in Taipei, and we welcome comments both > before and at that meeting. > > Yoav > > http://www.ietf.org/id/draft-nir-ipsecme-p2p-00.txt > http://tools.ietf.org/html/draft-nir-ipsecme-p2p-00 > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From ynir@checkpoint.com Thu Oct 13 23:35:20 2011 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 4825121F8C59 for ; Thu, 13 Oct 2011 23:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmMQaux9WkUI for ; Thu, 13 Oct 2011 23:35:19 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 61AF121F8C58 for ; Thu, 13 Oct 2011 23:35:19 -0700 (PDT) X-CheckPoint: {4E97D7EC-10011-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p9E6ZHn2003576; Fri, 14 Oct 2011 08:35:17 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 14 Oct 2011 08:35:16 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Fri, 14 Oct 2011 08:35:16 +0200 From: Yoav Nir To: Dan Harkins Date: Fri, 14 Oct 2011 08:35:14 +0200 Thread-Topic: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement Thread-Index: AcyKO29Jo0rOSinlQp6bBKBB6KnbYA== Message-ID: In-Reply-To: <20d9fa38a4964b77176e7eb0579d0199.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "ipsec@ietf.org" Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 06:35:20 -0000 A little. Also like GET-VPN and AC-VPN and Provider-1 (apologies to all the vendors I've missed) Those are some of the incompatible solutions by individual vendors. Yoav On 10/14/11 8:18 AM, "Dan Harkins" wrote: > > Sounds like TED: > >http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/ted.html > > Dan. > >On Thu, October 13, 2011 10:23 pm, Yoav Nir wrote: >> Hi all >> >> For years, one of the barriers to the adoption of IPsec was that >> configuration didn't scale. With thousands of peers, the PAD and SPD >>would >> become unwieldy, so even where IPsec was deployed it was often built in >> hub-and-spoke configurations, not because policy demanded this, but >> because it was more convenient to configure. Individual vendors have >> incompatible solutions for this, but they only work with that vendor's >> products, and within the same administrative domain. >> >> In this draft, we are proposing that the IPsecME working group take on a >> working item to first define the problem, and then offer solutions that >> will make IPsec scale better and in an inter-operable way. >> >> We plan to hold a side meeting in Taipei, and we welcome comments both >> before and at that meeting. >> >> Yoav >> >> http://www.ietf.org/id/draft-nir-ipsecme-p2p-00.txt >> http://tools.ietf.org/html/draft-nir-ipsecme-p2p-00 >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > > >Scanned by Check Point Total Security Gateway. From yaronf.ietf@gmail.com Fri Oct 14 02:37:13 2011 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 CE5C721F87D9 for ; Fri, 14 Oct 2011 02:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.141 X-Spam-Level: X-Spam-Status: No, score=-102.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WqU4bhe4fgz for ; Fri, 14 Oct 2011 02:37:12 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 94CF421F84C2 for ; Fri, 14 Oct 2011 02:37:07 -0700 (PDT) Received: by ggnk3 with SMTP id k3so1066806ggn.31 for ; Fri, 14 Oct 2011 02:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=xwqpK0An1fHhr9ORr7seukM0pt/N+pMlXjHJtxNxiqA=; b=kL4Cg1oqecuelg289VpUcj4sBfibSz6+cSXmwkRPmh8aLUzsXHDzxYxwmxy3EdBpgO 7H2CWU/BdOfFNRQnLGVstl1xGD8P2ufaZK5w5aKriNDGhn8YHnCtjRZjBe9OW/8ThlDR WZzkQhRfM95WI/WmcTvOWrOkrAGvgeegf7AVo= Received: by 10.223.77.71 with SMTP id f7mr3004052fak.33.1318585026757; Fri, 14 Oct 2011 02:37:06 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-176-251-203.red.bezeqint.net. [79.176.251.203]) by mx.google.com with ESMTPS id k26sm2688870fab.12.2011.10.14.02.37.05 (version=SSLv3 cipher=OTHER); Fri, 14 Oct 2011 02:37:06 -0700 (PDT) Message-ID: <4E9802BF.4010102@gmail.com> Date: Fri, 14 Oct 2011 11:37:03 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [IPsec] Comments on the new meshed VPN draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 09:37:13 -0000

I am going on vacation, but I did want to post these before. Sorry if I cannot take part in the ensuing discussion.

Overall, this is a good start for an important set of problems. But I would have liked the document to be clearer/deeper before we can discuss it seriously. I find some of the use cases too vague to discuss the issues, let alone engineer a solution.

Thanks,

    Yaron

• The following sentence simply doesn't apply to standard remote access situations, and should be refined: "IKE implementations need to know the identity and credentials of all possible peer systems, as well as the addresses of hosts and/or networks behind them."

• The introduction should mention the related problem that RA clients are not discoverable and in some scenarios lack any usable identity (when using IP addresses for example). Whether we choose to deal with this problem now is a different matter.
• 2.1: it is unclear whether the discussion is of the service provider as an enterprise, in which case the fact that it is a service provider is immaterial. What is "service provider enterprise"?
• 2.2: what are "different administrative domains" in this context, and why discuss this case before we discuss meshed VPN within a single domain?
• 2.3.1: this scenario sounds very much like a requirement for per-user profiles, and I don't see how it relates to the problem at hand.
• The scenario of two remote users communicating with one another is mentioned clearly in the introduction but surely deserves a use case.
• The security considerations again make some assumptions about the desired solution. My personal opinion is that the static RFC 4301 "databases" must remain static and provisioned by humans, but their semantics may need to be extended so they can express more dynamic policies.

From mcr@sandelman.ca Fri Oct 14 07:08:22 2011 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 23D0D21F8C20 for ; Fri, 14 Oct 2011 07:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.954 X-Spam-Level: X-Spam-Status: No, score=-0.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_BACKHAIR_44=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDHUqHo07-7S for ; Fri, 14 Oct 2011 07:08:21 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 85D7121F8BAE for ; Fri, 14 Oct 2011 07:08:21 -0700 (PDT) Received: from marajade.sandelman.ca (74-115-197-34.eng.wind.ca [74.115.197.34]) by relay.sandelman.ca (Postfix) with ESMTPS id 2A6F6343CD for ; Fri, 14 Oct 2011 10:07:14 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 7E6F898CB6; Fri, 14 Oct 2011 09:48:21 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 754E798CB5 for ; Fri, 14 Oct 2011 09:48:21 -0400 (EDT) From: Michael Richardson To: "ipsec@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Fri, 14 Oct 2011 09:48:21 -0400 Message-ID: <6087.1318600101@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 14:08:22 -0000 >>>>> "Yoav" == Yoav Nir writes: Yoav> A little. Also like GET-VPN and AC-VPN and Provider-1 Yoav> (apologies to all the vendors I've missed) Yoav> Those are some of the incompatible solutions by individual Yoav> vendors. And RFC4322. FreeSWAN has a number of local controls whereby one simply lists the CIDRs that one wishes to be "secure or fail" vs ones that are "nice to be secure". Many people have implemented MESHs by distributing the reverse DNS. What it is missing in IKEv1 is a way to turn the host<->host tunnels into subnet<->subnet tunnels, and that would be easy to do in IKEv2 with the TS. >> Sounds like TED: >> >> http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/ted.html >> >> Dan. >> >> On Thu, October 13, 2011 10:23 pm, Yoav Nir wrote: >>> Hi all >>> >>> For years, one of the barriers to the adoption of IPsec was that >>> configuration didn't scale. With thousands of peers, the PAD and >>> SPD would become unwieldy, so even where IPsec was deployed it >>> was often built in hub-and-spoke configurations, not because >>> policy demanded this, but because it was more convenient to >>> configure. Individual vendors have incompatible solutions for >>> this, but they only work with that vendor's products, and within >>> the same administrative domain. >>> >>> In this draft, we are proposing that the IPsecME working group >>> take on a working item to first define the problem, and then >>> offer solutions that will make IPsec scale better and in an >>> inter-operable way. >>> >>> We plan to hold a side meeting in Taipei, and we welcome >>> comments both before and at that meeting. >>> >>> Yoav >>> >>> http://www.ietf.org/id/draft-nir-ipsecme-p2p-00.txt >>> http://tools.ietf.org/html/draft-nir-ipsecme-p2p-00 >>> >>> _______________________________________________ IPsec mailing >>> list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec >>> >> >> >> >> Scanned by Check Point Total Security Gateway. Yoav> _______________________________________________ IPsec mailing Yoav> list IPsec@ietf.org Yoav> https://www.ietf.org/mailman/listinfo/ipsec From kevin.gross@avanw.com Thu Oct 13 11:28:43 2011 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 B6F0E21F8ABB for ; Thu, 13 Oct 2011 11:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KBDz7f0M8sE for ; Thu, 13 Oct 2011 11:28:42 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id 04A4B21F8A95 for ; Thu, 13 Oct 2011 11:28:41 -0700 (PDT) Received: (qmail 3137 invoked by uid 0); 13 Oct 2011 18:28:40 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy1.bluehost.com with SMTP; 13 Oct 2011 18:28:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=LOo3sRfUvM03dUYuL0jSqle+TXm/Us3rXGAeFMYrr04=; b=bfvBI4fQNDBqDWa7sRv2CedxR5Qjgpu5I5XmRALMymll+0U67Hx/jeoVlUW7AyMDLmdTEif7cr70L06e1WDUGnKOGZYCexTVfIYk9g9zI0I7FL/4fomK+LUnILDJjWiQ; Received: from mail-bw0-f44.google.com ([209.85.214.44]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1REQ1I-0005wW-4o; Thu, 13 Oct 2011 12:28:40 -0600 Received: by bkbzv3 with SMTP id zv3so2028720bkb.31 for ; Thu, 13 Oct 2011 11:28:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.65.76 with SMTP id h12mr7709810fai.7.1318530518183; Thu, 13 Oct 2011 11:28:38 -0700 (PDT) Received: by 10.223.93.202 with HTTP; Thu, 13 Oct 2011 11:28:38 -0700 (PDT) In-Reply-To: <4E96F91E.3020202@ntp.org> References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> Date: Thu, 13 Oct 2011 12:28:38 -0600 Message-ID: From: Kevin Gross To: Danny Mayer Content-Type: multipart/alternative; boundary=0015174753e0296e7404af324f92 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.214.44 authed with kevin.gross@avanw.com} X-Mailman-Approved-At: Fri, 14 Oct 2011 09:31:29 -0700 Cc: "ipsec@ietf.org" , "TICTOC@ietf.org" , Cui Yang Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 18:28:43 -0000 --0015174753e0296e7404af324f92 Content-Type: text/plain; charset=ISO-8859-1 Definitely important issues for some synchronization protocols but it seems though two-step 1588 would work through such a connection. The followup message will contain an accurate (and encrypted) timestamp. Encryption delays would not result in significant loss of accuracy with respect to an unencrypted connection also using two step. Kevin Gross On Thu, Oct 13, 2011 at 8:43 AM, Danny Mayer wrote: > On 9/18/2011 9:41 PM, Cui Yang wrote: > IEEE-1588 (PTP) also cannot benefit from this as it is basically a > hardware-stamping protocol and now you are routing it through a software > tunnel which means it has to be timestamped before it is IPsec > encapsulated which decreases it's accuracy. It's no longer on-wire. > --0015174753e0296e7404af324f92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Definitely important issues for some synchronization protocols but it seems= though two-step 1588 would work through such a connection. The followup me= ssage will contain an accurate (and encrypted) timestamp. Encryption delays= would not result in significant loss of accuracy with respect to an unencr= ypted=A0connection also using two step.

Kevin Gross

On Thu, Oct 13, 2011 at 8:43 AM, Danny Mayer <= mayer@ntp.org> wrote:
On 9/18/2011 9:41 PM, Cui Yang wrote:
<= div>
IEEE-1588 (= PTP) also cannot benefit from this as it is basically a
hardware-stamping protocol and now you are routing it through a software tunnel which means it has to be timestamped before it is IPsec
encapsulated which decreases it's accuracy. It's no longer on-wire.=

--0015174753e0296e7404af324f92-- From mayer@ntp.org Thu Oct 13 17:07:48 2011 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 28CAF21F8AFD; Thu, 13 Oct 2011 17:07:48 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35BlBebmGbMx; Thu, 13 Oct 2011 17:07:47 -0700 (PDT) Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by ietfa.amsl.com (Postfix) with ESMTP id A85A921F8AE6; Thu, 13 Oct 2011 17:07:47 -0700 (PDT) Received: from pool-141-157-188-170.bstnma.btas.verizon.net ([141.157.188.170] helo=[10.10.10.102]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1REVJL-000JRl-UO; Fri, 14 Oct 2011 00:07:42 +0000 Message-ID: <4E977D47.5070709@ntp.org> Date: Thu, 13 Oct 2011 20:07:35 -0400 From: Danny Mayer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Kevin Gross References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 141.157.188.170 X-SA-Exim-Rcpt-To: kevin.gross@avanw.com, cuiyang@huawei.com, ipsec@ietf.org, TICTOC@ietf.org, mills@udel.edu X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) X-Mailman-Approved-At: Fri, 14 Oct 2011 09:31:29 -0700 Cc: "ipsec@ietf.org" , "TICTOC@ietf.org" , Cui Yang , "David L. Mills" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 00:07:48 -0000 On 10/13/2011 2:28 PM, Kevin Gross wrote: > Definitely important issues for some synchronization protocols but it > seems though two-step 1588 would work through such a connection. The > followup message will contain an accurate (and encrypted) timestamp. > Encryption delays would not result in significant loss of accuracy with > respect to an unencrypted connection also using two step. > Has anyone tested or measured that? I have not seen any information how this will work without losing accuracy. Don't forget the followon message will also have to be encrypted and decrypted when sent making for additional uncertainties and errors. I have not reviewed how the two-step IEEE 1588 protocol works so I don't have a good understanding of the effects of IPsec encryption on such packets. Danny > Kevin Gross > > On Thu, Oct 13, 2011 at 8:43 AM, Danny Mayer > wrote: > > On 9/18/2011 9:41 PM, Cui Yang wrote: > > > IEEE-1588 (PTP) also cannot benefit from this as it is basically a > hardware-stamping protocol and now you are routing it through a software > tunnel which means it has to be timestamped before it is IPsec > encapsulated which decreases it's accuracy. It's no longer on-wire. > > From nico@cryptonector.com Fri Oct 14 10:25:44 2011 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 AFEE821F8485; Fri, 14 Oct 2011 10:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7Tp0fIzSgPh; Fri, 14 Oct 2011 10:25:44 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 2874C21F84BC; Fri, 14 Oct 2011 10:25:44 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 15DB21007B; Fri, 14 Oct 2011 10:25:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=Sd3pmvFrAVta6HTYLSZbJ zTY/2DO9rHC5uQLsxRIO5VVGgND9MISwrNtAcl9NcwBH92u+bbVG3+qgKwltzMtc /yzZ660kyzqvnwu+SjIUfto+XdRpQIgJe4N73nRqFf44rZYggl/5g7jdMacPy8eI a+yKCgknK6C6c5+ElSgTZM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=gPbRVsOs2/Y/99veRHyC iq4T84A=; b=ri910CMRP3QRpDAkZGWAQYjQIF+fpHV7xtBb+wJDgn9IKJ7Y5Baq jDK6kkpgtBmNN/6QElUcma/bpHHQvS4lZ+98zoV/uJ2VLf6g5zF5TtQ6CwlYF+2Y //NnEWiUOT2QLJS5Mny+ciT4S/JGzCNn3ilDhoybB0UeALbJcNhxO14= Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 943A61007F; Fri, 14 Oct 2011 10:25:30 -0700 (PDT) Received: by pzk37 with SMTP id 37so6051310pzk.9 for ; Fri, 14 Oct 2011 10:25:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.156.1 with SMTP id wa1mr18156751pbb.58.1318613128643; Fri, 14 Oct 2011 10:25:28 -0700 (PDT) Received: by 10.68.59.169 with HTTP; Fri, 14 Oct 2011 10:25:28 -0700 (PDT) In-Reply-To: <4E977D47.5070709@ntp.org> References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> Date: Fri, 14 Oct 2011 12:25:28 -0500 Message-ID: From: Nico Williams To: Danny Mayer Content-Type: text/plain; charset=UTF-8 Cc: "ipsec@ietf.org" , "David L. Mills" , "TICTOC@ietf.org" , Kevin Gross , Cui Yang Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 17:25:44 -0000 On Thu, Oct 13, 2011 at 7:07 PM, Danny Mayer wrote: > On 10/13/2011 2:28 PM, Kevin Gross wrote: >> Definitely important issues for some synchronization protocols but it >> seems though two-step 1588 would work through such a connection. The >> followup message will contain an accurate (and encrypted) timestamp. >> Encryption delays would not result in significant loss of accuracy with >> respect to an unencrypted connection also using two step. > > Has anyone tested or measured that? I have not seen any information how > this will work without losing accuracy. Don't forget the followon > message will also have to be encrypted and decrypted when sent making > for additional uncertainties and errors. I have not reviewed how the > two-step IEEE 1588 protocol works so I don't have a good understanding > of the effects of IPsec encryption on such packets. The cost of crypto can be measured, and performance generally deterministic (particularly when there's no side channels in the crypto) (assuming no mid-crypto context switches), so that it should be possible to correct for the delays introduced by crypto (just as it's possible to measure and estimate network latency). Indeed, crypto processing will likely be more deterministic than network latency :) However, I do agree that there's no point to encrypting time synchronization signals unless they facilitate traffic analysis (say). Nor do I see the point of using WESP for this. Also, NTP has a public key authentication facility nowadays -- why not use it? Nico -- From btv1==26888188e07==gdowd@symmetricom.com Fri Oct 14 10:08:09 2011 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 CCF9E21F8B1F for ; Fri, 14 Oct 2011 10:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qRgU3dYT2KE for ; Fri, 14 Oct 2011 10:08:09 -0700 (PDT) Received: from mail5.symmetricom.com (mail5.symmetricom.com [69.25.98.10]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5CB21F8A95 for ; Fri, 14 Oct 2011 10:08:09 -0700 (PDT) X-ASG-Debug-ID: 1318612087-11aa65670001-2ho77O Received: from SJC-HUB-01.symmetricom.com ([192.168.10.171]) by mail5.symmetricom.com with ESMTP id aFt2O0y9KVPdw52z; Fri, 14 Oct 2011 10:08:07 -0700 (PDT) X-Barracuda-Envelope-From: gdowd@symmetricom.com Received: from SJC-MBX-01.symmetricom.com ([169.254.1.221]) by SJC-HUB-01.symmetricom.com ([::1]) with mapi id 14.01.0289.001; Fri, 14 Oct 2011 10:08:07 -0700 From: Greg Dowd To: Danny Mayer , Kevin Gross Thread-Topic: [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) X-ASG-Orig-Subj: RE: [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) Thread-Index: Acx2bU0nGnMbOv0GSKWyrWTZm9gvcwTg9+4AAAfbEAAAC9ZzgAAUrLAw Date: Fri, 14 Oct 2011 17:08:06 +0000 Message-ID: <26FBD265CD8D234EAF41115A180F92BB38B33E70@SJC-MBX-01.symmetricom.com> References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> In-Reply-To: <4E977D47.5070709@ntp.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.3.42] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[192.168.10.171] X-Barracuda-Start-Time: 1318612087 X-Barracuda-URL: http://192.168.10.96:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at symmetricom.com X-Barracuda-Spam-Score: -1002.00 X-Barracuda-Spam-Status: No, SCORE=-1002.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 X-Mailman-Approved-At: Sat, 15 Oct 2011 08:30:24 -0700 Cc: "ipsec@ietf.org" , "TICTOC@ietf.org" , Cui Yang , "David L. Mills" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 17:12:03 -0000 Hi Danny, Yes, we (Symmetricom) have tested this. It does work. It basically is wh= at the 2step clock was designed for. You create an event message (SYNC) an= d send it out. As it gets transmitted, you record the actual time of trans= mission. Then you follow up with a general message (FOLLOW UP) in which ti= ming doesn't matter to send the corrected tx time. The slave sees the foll= ow up bit set in the SYNC message which tells the slave to wait for the fol= low up packet before processing the timestamp. This was designed as hardware wasn't available to insert timestamps accura= tely but it was/is relatively easy to tap the G/MII channel to see the pack= et flowing into the PHY. Obviously, you need to correlate the packet with = the timestamp which you can do by serializing transmission or looking at th= e frame. This is part of the reasoning behind the draft in that, if the fr= ame is encrypted, it makes it easier to identify if there is a bit set some= where. =20 =20 Greg Dowd gdowd at symmetricom dot com (antispam format) Symmetricom, Inc. www.symmetricom.com "A clever person solves a problem. A wise person avoids it." Albert Einste= in -----Original Message----- From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of= Danny Mayer Sent: Thursday, October 13, 2011 5:08 PM To: Kevin Gross Cc: ipsec@ietf.org; TICTOC@ietf.org; Cui Yang; David L. Mills Subject: Re: [TICTOC] Review request for IPsec security for packet based sy= nchronization (Yang Cui) On 10/13/2011 2:28 PM, Kevin Gross wrote: > Definitely important issues for some synchronization protocols but it > seems though two-step 1588 would work through such a connection. The > followup message will contain an accurate (and encrypted) timestamp. > Encryption delays would not result in significant loss of accuracy with > respect to an unencrypted connection also using two step. >=20 Has anyone tested or measured that? I have not seen any information how this will work without losing accuracy. Don't forget the followon message will also have to be encrypted and decrypted when sent making for additional uncertainties and errors. I have not reviewed how the two-step IEEE 1588 protocol works so I don't have a good understanding of the effects of IPsec encryption on such packets. Danny > Kevin Gross >=20 > On Thu, Oct 13, 2011 at 8:43 AM, Danny Mayer > wrote: >=20 > On 9/18/2011 9:41 PM, Cui Yang wrote: >=20 >=20 > IEEE-1588 (PTP) also cannot benefit from this as it is basically a > hardware-stamping protocol and now you are routing it through a softw= are > tunnel which means it has to be timestamped before it is IPsec > encapsulated which decreases it's accuracy. It's no longer on-wire. >=20 >=20 _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc From mills@udel.edu Fri Oct 14 17:19:15 2011 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 3B58221F8CF1; Fri, 14 Oct 2011 17:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23nbzzJg4fPK; Fri, 14 Oct 2011 17:19:14 -0700 (PDT) Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5525521F8CED; Fri, 14 Oct 2011 17:19:14 -0700 (PDT) Received: from [192.168.1.2] (pool-173-62-174-206.phlapa.fios.verizon.net [173.62.174.206]) (Authenticated sender: mills@mail.eecis.udel.edu) by mail.eecis.udel.edu (Postfix) with ESMTP id D2DE9AFB; Fri, 14 Oct 2011 20:19:07 -0400 (EDT) Message-ID: <4E98D17E.8000801@udel.edu> Date: Sat, 15 Oct 2011 00:19:10 +0000 From: "David L. Mills" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nico Williams References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000509020409070902060809" X-Mailman-Approved-At: Sat, 15 Oct 2011 08:30:24 -0700 Cc: "ipsec@ietf.org" , Danny Mayer , "TICTOC@ietf.org" , Kevin Gross , Cui Yang Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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, 15 Oct 2011 00:19:15 -0000 This is a multi-part message in MIME format. --------------000509020409070902060809 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nico and Danny, It might help to explain the issues in the NTP white papers at the NTP project page www.eecis.udel.edu./ntp.html. Chapter 16 in the book shows the results of experiments using interleaved mode, which might be of interest in PTP broadcast issues. The paper on Simulation and Analysis of the NTP On-Wire protocol uses a two-step process similar to PTP. The paper on NTP Security Analysis may have lessons for PTP authentication. The NTP Autokey model needs help, as suggested in that paper. Dave Nico Williams wrote: >On Thu, Oct 13, 2011 at 7:07 PM, Danny Mayer wrote: > > >>On 10/13/2011 2:28 PM, Kevin Gross wrote: >> >> >>>Definitely important issues for some synchronization protocols but it >>>seems though two-step 1588 would work through such a connection. The >>>followup message will contain an accurate (and encrypted) timestamp. >>>Encryption delays would not result in significant loss of accuracy with >>>respect to an unencrypted connection also using two step. >>> >>> >>Has anyone tested or measured that? I have not seen any information how >>this will work without losing accuracy. Don't forget the followon >>message will also have to be encrypted and decrypted when sent making >>for additional uncertainties and errors. I have not reviewed how the >>two-step IEEE 1588 protocol works so I don't have a good understanding >>of the effects of IPsec encryption on such packets. >> >> > >The cost of crypto can be measured, and performance generally >deterministic (particularly when there's no side channels in the >crypto) (assuming no mid-crypto context switches), so that it should >be possible to correct for the delays introduced by crypto (just as >it's possible to measure and estimate network latency). Indeed, >crypto processing will likely be more deterministic than network >latency :) > >However, I do agree that there's no point to encrypting time >synchronization signals unless they facilitate traffic analysis (say). > Nor do I see the point of using WESP for this. Also, NTP has a >public key authentication facility nowadays -- why not use it? > >Nico >-- > > --------------000509020409070902060809 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Nico and Danny,

It might help to explain the issues in the NTP white papers at the NTP project page www.eecis.udel.edu./ntp.html. Chapter 16 in the book shows the results of experiments using interleaved mode, which might be of interest in PTP broadcast issues. The paper on Simulation and Analysis of the NTP On-Wire protocol uses a two-step process similar to PTP. The paper on NTP Security Analysis may have lessons for PTP authentication. The NTP Autokey model needs help, as suggested in that paper.

Dave

Nico Williams wrote:
On Thu, Oct 13, 2011 at 7:07 PM, Danny Mayer <mayer@ntp.org> wrote:
  
On 10/13/2011 2:28 PM, Kevin Gross wrote:
    
Definitely important issues for some synchronization protocols but it
seems though two-step 1588 would work through such a connection. The
followup message will contain an accurate (and encrypted) timestamp.
Encryption delays would not result in significant loss of accuracy with
respect to an unencrypted connection also using two step.
      
Has anyone tested or measured that? I have not seen any information how
this will work without losing accuracy. Don't forget the followon
message will also have to be encrypted and decrypted when sent making
for additional uncertainties and errors. I have not reviewed how the
two-step IEEE 1588 protocol works so I don't have a good understanding
of the effects of IPsec encryption on such packets.
    

The cost of crypto can be measured, and performance generally
deterministic (particularly when there's no side channels in the
crypto) (assuming no mid-crypto context switches), so that it should
be possible to correct for the delays introduced by crypto (just as
it's possible to measure and estimate network latency).  Indeed,
crypto processing will likely be more deterministic than network
latency :)

However, I do agree that there's no point to encrypting time
synchronization signals unless they facilitate traffic analysis (say).
 Nor do I see the point of using WESP for this.  Also, NTP has a
public key authentication facility nowadays -- why not use it?

Nico
--

--------------000509020409070902060809-- From nico@cryptonector.com Sat Oct 15 18:30:01 2011 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 D0A0B21F85B8; Sat, 15 Oct 2011 18:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3d9HRmoN5l1G; Sat, 15 Oct 2011 18:30:01 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 3E75F21F8569; Sat, 15 Oct 2011 18:30:01 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 8B3CC1B4058; Sat, 15 Oct 2011 18:30:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=VNq20AeA/B/WYj4Go6JEg Rh1Tn0NHbffBST/VnMNMBR74rwAo7TPWMX1PIa3VlhiBtA1LiY+R7J+IAz+zQfmh zZlJfVldYAI2JqGGm8NpmB+tULyUxd/7mNey/QViUinTJCjhVvb69HWQqSBwFrtE 6LtjNkbXSpfOcUA/mKAjco= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=krbcSYAxM/gL2/6XC1Oe 4CvgOok=; b=ld8BV01+ZGo4UA9ljQD8jzABZ4tH4ELk59keDxyGI7QlbIIDn441 5ccNWlgYIb52qbUeVuQRtj6PmCMgeAZLZWPNcUaUOjr0hwcBeIhOeefP/DU5PvGg rNXl2IGG8+v5e0QL20bUQgDVw64CLodSvuXRhTqBkV1+sAzEEMk1T1Y= Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 5213B1B4057; Sat, 15 Oct 2011 18:30:00 -0700 (PDT) Received: by iabn5 with SMTP id n5so4658924iab.31 for ; Sat, 15 Oct 2011 18:29:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.13.135 with SMTP id h7mr3465297pbc.75.1318728599435; Sat, 15 Oct 2011 18:29:59 -0700 (PDT) Received: by 10.68.41.169 with HTTP; Sat, 15 Oct 2011 18:29:59 -0700 (PDT) In-Reply-To: <4E98D17E.8000801@udel.edu> References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E98D17E.8000801@udel.edu> Date: Sat, 15 Oct 2011 20:29:59 -0500 Message-ID: From: Nico Williams To: "David L. Mills" Content-Type: text/plain; charset=UTF-8 Cc: "ipsec@ietf.org" , Danny Mayer , "TICTOC@ietf.org" , Kevin Gross , Cui Yang Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 01:30:02 -0000 On Fri, Oct 14, 2011 at 7:19 PM, David L. Mills wrote: > Nico and Danny, > > It might help to explain the issues in the NTP white papers at the NTP > project page www.eecis.udel.edu./ntp.html. Chapter 16 in the book shows the > results of experiments using interleaved mode, which might be of interest in > PTP broadcast issues. The paper on Simulation and Analysis of the NTP > On-Wire protocol uses a two-step process similar to PTP. The paper on NTP > Security Analysis may have lessons for PTP authentication. The NTP Autokey > model needs help, as suggested in that paper. Also helpful was to note the cc list and then look at the TICTOC WG charter. If I understand the I-D we're talking about a an extension to IPsec to minimize overhead in handling of packets carrying time data, particularly in an SG environment. This would allow NTP to be run with no crypto inside the security boundary, with IPsec providing security outside. Is this correct? And this performs better than the interleaved NTP scheme with asymmetric key signatures? Nico -- From mayer@ntp.org Sun Oct 16 10:53:14 2011 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 911C021F85F1; Sun, 16 Oct 2011 10:53:14 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id to-FbLd7NPNr; Sun, 16 Oct 2011 10:53:13 -0700 (PDT) Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF3B21F8514; Sun, 16 Oct 2011 10:52:41 -0700 (PDT) Received: from pool-141-157-188-170.bstnma.btas.verizon.net ([141.157.188.170] helo=[10.10.10.102]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RFUsz-000Ojq-9h; Sun, 16 Oct 2011 17:52:35 +0000 Message-ID: <4E9B19DE.70006@ntp.org> Date: Sun, 16 Oct 2011 13:52:30 -0400 From: Danny Mayer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Greg Dowd References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <26FBD265CD8D234EAF41115A180F92BB38B33E70@SJC-MBX-01.symmetricom.com> In-Reply-To: <26FBD265CD8D234EAF41115A180F92BB38B33E70@SJC-MBX-01.symmetricom.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 141.157.188.170 X-SA-Exim-Rcpt-To: gdowd@symmetricom.com, kevin.gross@avanw.com, ipsec@ietf.org, TICTOC@ietf.org, cuiyang@huawei.com, mills@udel.edu X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: "ipsec@ietf.org" , "David L. Mills" , "TICTOC@ietf.org" , Kevin Gross , Cui Yang Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 17:53:14 -0000 On 10/14/2011 1:08 PM, Greg Dowd wrote: > Hi Danny, > Yes, we (Symmetricom) have tested this. It does work. It basically > is what the 2step clock was designed for. You create an event message (SYNC) and send it out. As it gets transmitted, you record the actual time of transmission. Then you follow up with a general message (FOLLOW UP) in which timing doesn't matter to send the corrected tx time. The slave sees the follow up bit set in the SYNC message which tells the slave to wait for the follow up packet before processing the timestamp. > Good to know that. This implies that if these are NTP packets you need to be in interleave mode in order to support this. > This was designed as hardware wasn't available to insert timestamps accurately but it was/is relatively easy to tap the G/MII channel to see the packet flowing into the PHY. Obviously, you need to correlate the packet with the timestamp which you can do by serializing transmission or looking at the frame. This is part of the reasoning behind the draft in that, if the frame is encrypted, it makes it easier to identify if there is a bit set somewhere. > How does identifying the packet help? If you want to do correlation then properly speaking you should be adding an ID to the packet so that the followon packet can carry the same ID to give you a way of updating that packet. According to what you are saying it doesn't matter that they have to be decoded at the receiving end, they will be processed and associated with the original packet. Danny > > Greg Dowd > gdowd at symmetricom dot com (antispam format) > Symmetricom, Inc. > www.symmetricom.com > "A clever person solves a problem. A wise person avoids it." Albert Einstein > > > -----Original Message----- > From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Danny Mayer > Sent: Thursday, October 13, 2011 5:08 PM > To: Kevin Gross > Cc: ipsec@ietf.org; TICTOC@ietf.org; Cui Yang; David L. Mills > Subject: Re: [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) > > On 10/13/2011 2:28 PM, Kevin Gross wrote: >> Definitely important issues for some synchronization protocols but it >> seems though two-step 1588 would work through such a connection. The >> followup message will contain an accurate (and encrypted) timestamp. >> Encryption delays would not result in significant loss of accuracy with >> respect to an unencrypted connection also using two step. >> > > Has anyone tested or measured that? I have not seen any information how > this will work without losing accuracy. Don't forget the followon > message will also have to be encrypted and decrypted when sent making > for additional uncertainties and errors. I have not reviewed how the > two-step IEEE 1588 protocol works so I don't have a good understanding > of the effects of IPsec encryption on such packets. > > Danny >> Kevin Gross >> >> On Thu, Oct 13, 2011 at 8:43 AM, Danny Mayer > > wrote: >> >> On 9/18/2011 9:41 PM, Cui Yang wrote: >> >> >> IEEE-1588 (PTP) also cannot benefit from this as it is basically a >> hardware-stamping protocol and now you are routing it through a software >> tunnel which means it has to be timestamped before it is IPsec >> encapsulated which decreases it's accuracy. It's no longer on-wire. >> >> > > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > From ynir@checkpoint.com Sun Oct 16 12:02:55 2011 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 3A9A921F8AD9 for ; Sun, 16 Oct 2011 12:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_44=1, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YONutxcDdseD for ; Sun, 16 Oct 2011 12:02:54 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2041721F8AC9 for ; Sun, 16 Oct 2011 12:02:53 -0700 (PDT) X-CheckPoint: {4E9B2A1D-10003-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p9GJ2pMa024183; Sun, 16 Oct 2011 21:02:52 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 16 Oct 2011 21:02:51 +0200 From: Yoav Nir To: Michael Richardson , "ipsec@ietf.org" Date: Sun, 16 Oct 2011 21:02:56 +0200 Thread-Topic: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement Thread-Index: AcyMNjN93WoyfhPzSumoIGtj6ib10g== Message-ID: In-Reply-To: <6087.1318600101@marajade.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 19:02:55 -0000 I definitely think that the authors of this draft (I'm mostly just the editor) need a good answer about why RFC 4322 doesn't cover the use cases. Mostly, the starting point is different. RFC 4322 begins with nodes that have no prior trust relationship, and builds opportunistic bridges between them. The problem here is that groups of nodes that have trust relationships between them, but not between every pair of them. They want communications that now go through some hub gateway to go directly from spoke to spoke. On 10/14/11 3:48 PM, "Michael Richardson" wrote: > >>>>>> "Yoav" =3D=3D Yoav Nir writes: > Yoav> A little. Also like GET-VPN and AC-VPN and Provider-1 > Yoav> (apologies to all the vendors I've missed) > > Yoav> Those are some of the incompatible solutions by individual > Yoav> vendors. > >And RFC4322. > >FreeSWAN has a number of local controls whereby one simply lists the >CIDRs that one wishes to be "secure or fail" vs ones that are "nice to >be secure". Many people have implemented MESHs by distributing the >reverse DNS. > >What it is missing in IKEv1 is a way to turn the host<->host tunnels >into subnet<->subnet tunnels, and that would be easy to do in IKEv2 with >the TS. > > > >> Sounds like TED: > >>=20 > >>=20 >http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/ted.html > >>=20 > >> Dan. > >>=20 > >> On Thu, October 13, 2011 10:23 pm, Yoav Nir wrote: > >>> Hi all > >>>=20 > >>> For years, one of the barriers to the adoption of IPsec was that > >>> configuration didn't scale. With thousands of peers, the PAD and > >>> SPD would become unwieldy, so even where IPsec was deployed it > >>> was often built in hub-and-spoke configurations, not because > >>> policy demanded this, but because it was more convenient to > >>> configure. Individual vendors have incompatible solutions for > >>> this, but they only work with that vendor's products, and within > >>> the same administrative domain. > >>>=20 > >>> In this draft, we are proposing that the IPsecME working group > >>> take on a working item to first define the problem, and then > >>> offer solutions that will make IPsec scale better and in an > >>> inter-operable way. > >>>=20 > >>> We plan to hold a side meeting in Taipei, and we welcome > >>> comments both before and at that meeting. > >>>=20 > >>> Yoav > >>>=20 > >>> http://www.ietf.org/id/draft-nir-ipsecme-p2p-00.txt > >>> http://tools.ietf.org/html/draft-nir-ipsecme-p2p-00 > >>>=20 > >>> _______________________________________________ IPsec mailing > >>> list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec > >>>=20 > >>=20 > >>=20 > >>=20 > >> Scanned by Check Point Total Security Gateway. > > Yoav> _______________________________________________ IPsec mailing > Yoav> list IPsec@ietf.org > Yoav> https://www.ietf.org/mailman/listinfo/ipsec >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec > >Scanned by Check Point Total Security Gateway. From mayer@ntp.org Sun Oct 16 20:08:23 2011 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 EA8F211E8081; Sun, 16 Oct 2011 20:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8Qcdf1ZISpv; Sun, 16 Oct 2011 20:08:23 -0700 (PDT) Received: from mx04.gis.net (mx04.gis.net [208.218.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2984B11E8073; Sun, 16 Oct 2011 20:08:22 -0700 (PDT) Received: from [10.10.10.102] ([141.157.188.170]) by mx04.gis.net; Sun, 16 Oct 2011 23:08:01 -0400 Message-ID: <4E9B9C12.6000505@ntp.org> Date: Sun, 16 Oct 2011 23:08:02 -0400 From: Danny Mayer Organization: NTP User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Nico Williams References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E98D17E.8000801@udel.edu> In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , Cui Yang , "TICTOC@ietf.org" , Kevin Gross , "David L. Mills" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mayer@ntp.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 03:08:24 -0000 On 10/15/2011 9:29 PM, Nico Williams wrote: > On Fri, Oct 14, 2011 at 7:19 PM, David L. Mills wrote: >> Nico and Danny, >> >> It might help to explain the issues in the NTP white papers at the NTP >> project page www.eecis.udel.edu./ntp.html. Chapter 16 in the book shows the >> results of experiments using interleaved mode, which might be of interest in >> PTP broadcast issues. The paper on Simulation and Analysis of the NTP >> On-Wire protocol uses a two-step process similar to PTP. The paper on NTP >> Security Analysis may have lessons for PTP authentication. The NTP Autokey >> model needs help, as suggested in that paper. > > Also helpful was to note the cc list and then look at the TICTOC WG charter. > > If I understand the I-D we're talking about a an extension to IPsec to > minimize overhead in handling of packets carrying time data, > particularly in an SG environment. This would allow NTP to be run > with no crypto inside the security boundary, with IPsec providing > security outside. Is this correct? And this performs better than the > interleaved NTP scheme with asymmetric key signatures? > I cannot answer for the performance but if I was worried about making sure I got the correct time I'd be more likely to be concerned about authenticating the server than encrypting the contents. Encryption doesn't do a thing for ensuring you got a valid packet. Danny From Chris.Ulliott@cesg.gsi.gov.uk Mon Oct 17 04:39:45 2011 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 690AC21F8B80 for ; Mon, 17 Oct 2011 04:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_BACKHAIR_44=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmDB8Hf8vsqW for ; Mon, 17 Oct 2011 04:39:44 -0700 (PDT) Received: from mail185.messagelabs.com (mail185.messagelabs.com [85.158.143.19]) by ietfa.amsl.com (Postfix) with SMTP id 1BA3E21F8B7E for ; Mon, 17 Oct 2011 04:39:43 -0700 (PDT) X-Env-Sender: Chris.Ulliott@cesg.gsi.gov.uk X-Msg-Ref: server-12.tower-185.messagelabs.com!1318851579!298125!1 X-Originating-IP: [62.25.106.208] X-StarScan-Version: 6.3.6; banners=cesg.gsi.gov.uk,-,- X-VirusChecked: Checked Received: (qmail 28780 invoked from network); 17 Oct 2011 11:39:39 -0000 Received: from gateway-102.energis.gsi.gov.uk (HELO mx.hosting-w.gsi.gov.uk) (62.25.106.208) by server-12.tower-185.messagelabs.com with SMTP; 17 Oct 2011 11:39:39 -0000 From: "Ulliott, Chris" To: 'Yoav Nir' , Michael Richardson , "ipsec@ietf.org" Date: Mon, 17 Oct 2011 12:39:32 +0100 Thread-Topic: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement Thread-Index: AcyMNjN93WoyfhPzSumoIGtj6ib10gAiUaOg Message-ID: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 11:39:45 -0000 The challenge for us is around discovery of the next cryptographic hop com= bined with the increase use of VoIP and other protocols that need peer to = peer connectivity / low latency etc. If I'm sat behind a gateway and send a packet to a.b.c.d - my gateway need= s to perform a lookup to find out who it needs to establish an SA with bef= ore it can encrypt the packet and send it on its way. To my knowledge, th= ere is not standard way of discovering this (although I'll happily be corr= ected!) For example... (and I hope the ASCII art works!) Host 1 --> R --> Za --> R --> R --> Zb --> R --> Host 2 (Where R is a router and Zx is a crypto) Host 1 send a packet to Host 2, it's routed to the gateway Za as normal, b= ut at this point Za needs to work out which remote endpoint to establish a= n SA with. In this case it's Zb - but the traditional way to achieve this= is through static configuration which doesn't scale if you want to run fu= lly meshed networks (we have thousands of nodes). When Zb received the pa= cket it decrypts and forwards to Host 2. When you add resilience, this gets even more complicate, for example: Host 1 --> R --> Za --> R --> R --> Zb --> R --> Host 2 | --------> Zc --> R ------^ Packets for Host two can be sent via Zb or Zc, how does Za make that decis= ion? In this example Zc is less hops away so would make more sense unless = it wasn't available. Our interest also throws in the problem of multiple administrative domains= . We have numerous sites, but IT is provisioned by differing integrators.= Any standard should (in our opinion) enable this to still work. At the = moment, commercial solutions for meshed VPN's assume that all the cryptogr= aphic devices are run by the same team. I hope that helps! Chris -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Yoav Nir Sent: Sunday, October 16, 2011 8:03 PM To: Michael Richardson; ipsec@ietf.org Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem= Statement I definitely think that the authors of this draft (I'm mostly just the editor) need a good answer about why RFC 4322 doesn't cover the use cases.= Mostly, the starting point is different. RFC 4322 begins with nodes that have no prior trust relationship, and builds opportunistic bridges between them. The problem here is that groups of nodes that have trust relationships between them, but not between every pair of them. They want communications= that now go through some hub gateway to go directly from spoke to spoke. On 10/14/11 3:48 PM, "Michael Richardson" wrote: > >>>>>> "Yoav" =3D=3D Yoav Nir writes: > Yoav> A little. Also like GET-VPN and AC-VPN and Provider-1 > Yoav> (apologies to all the vendors I've missed) > > Yoav> Those are some of the incompatible solutions by individual > Yoav> vendors. > >And RFC4322. > >FreeSWAN has a number of local controls whereby one simply lists the >CIDRs that one wishes to be "secure or fail" vs ones that are "nice to >be secure". Many people have implemented MESHs by distributing the >reverse DNS. > >What it is missing in IKEv1 is a way to turn the host<->host tunnels >into subnet<->subnet tunnels, and that would be easy to do in IKEv2 with >the TS. > > > >> Sounds like TED: > >> > >> >http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/ted.html > >> > >> Dan. > >> > >> On Thu, October 13, 2011 10:23 pm, Yoav Nir wrote: > >>> Hi all > >>> > >>> For years, one of the barriers to the adoption of IPsec was that > >>> configuration didn't scale. With thousands of peers, the PAD and > >>> SPD would become unwieldy, so even where IPsec was deployed it > >>> was often built in hub-and-spoke configurations, not because > >>> policy demanded this, but because it was more convenient to > >>> configure. Individual vendors have incompatible solutions for > >>> this, but they only work with that vendor's products, and within > >>> the same administrative domain. > >>> > >>> In this draft, we are proposing that the IPsecME working group > >>> take on a working item to first define the problem, and then > >>> offer solutions that will make IPsec scale better and in an > >>> inter-operable way. > >>> > >>> We plan to hold a side meeting in Taipei, and we welcome > >>> comments both before and at that meeting. > >>> > >>> Yoav > >>> > >>> http://www.ietf.org/id/draft-nir-ipsecme-p2p-00.txt > >>> http://tools.ietf.org/html/draft-nir-ipsecme-p2p-00 > >>> > >>> _______________________________________________ IPsec mailing > >>> list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec > >>> > >> > >> > >> > >> Scanned by Check Point Total Security Gateway. > > Yoav> _______________________________________________ IPsec mailing > Yoav> list IPsec@ietf.org > Yoav> https://www.ietf.org/mailman/listinfo/ipsec >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec > >Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec **************************************************************************= ** Communications with GCHQ may be monitored and/or recorded=20 for system efficiency and other lawful purposes. Any views or=20 opinions expressed in this e-mail do not necessarily reflect GCHQ=20 policy. This email, and any attachments, is intended for the=20 attention of the addressee(s) only. Its unauthorised use,=20 disclosure, storage or copying is not permitted. If you are not the intended recipient, please notify postmaster@gchq.gsi.gov.uk. =20 This information is exempt from disclosure under the Freedom of=20 Information Act 2000 and may be subject to exemption under other UK information legislation. Refer disclosure requests to=20 GCHQ on 01242 221491 ext 30306 (non-secure) or email infoleg@gchq.gsi.gov.uk **************************************************************************= ** The original of this email was scanned for viruses by the Government Secur= e Intranet virus scanning service supplied by Cable&Wireless Worldwide in = partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On l= eaving the GSi this email was certified virus free. Communications via the GSi may be automatically logged, monitored and/or r= ecorded for legal purposes. From mcr@sandelman.ca Mon Oct 17 06:53:06 2011 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 1A4BD21F8BAD for ; Mon, 17 Oct 2011 06:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_BACKHAIR_44=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRtu+hcKyd24 for ; Mon, 17 Oct 2011 06:53:05 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACD021F8AF4 for ; Mon, 17 Oct 2011 06:53:04 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 3527E343C7 for ; Mon, 17 Oct 2011 09:51:55 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 54F6D98CAD; Mon, 17 Oct 2011 09:52:56 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 512AB98B2E for ; Mon, 17 Oct 2011 09:52:56 -0400 (EDT) From: Michael Richardson To: "ipsec@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 17 Oct 2011 09:52:56 -0400 Message-ID: <15140.1318859576@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 13:53:06 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Yoav" =3D=3D Yoav Nir writes: Yoav> I definitely think that the authors of this draft (I'm mostly Yoav> just the editor) need a good answer about why RFC 4322 doesn't Yoav> cover the use cases. Mostly, the starting point is different. Yoav> RFC 4322 begins with nodes that have no prior trust Yoav> relationship, and builds opportunistic bridges between them. No precisely true. 4322 says that we trust the central IP address delegation authority (IANA), and builds trust from there.=20=20 Yoav> The problem here is that groups of nodes that have trust Yoav> relationships between them, but not between every pair of Yoav> them. They want communications that now go through some hub Yoav> gateway to go directly from spoke to spoke. So you can do this on a host<->host basis by implementing 4322, and then pulling (being a secondary using stock tools and protocols) the reverse zone from the hub (over your trusted link to the hub, or via TSIG/SIG(0), or just be IP address trust).=20 What is (in the form of running code) missing is a way to transform the host<->host tunnels into subnet<->subnet tunnels. In IKEv2 we have a way to express the request now, what is missing is a way to express the authority statement. If subnets are on octet boundaries (or smaller, apply RFC2317), then it is pretty straightforward to search for TXT/IPSECKEY for the subnet.=20 For CIDR subnets, which we can express in IKEv2, one could just confirm them all, but my bet is that there are no such networks that matter. ps: by the time IPSECKEY (RFC4025) was assigned, rfc4322 was pretty much in the can, and we did not have deployed code to be able to test the IPSECKEY RR easily. We decided that we would use the existence of IPSECKEY as a clue that we should try IKEv2 first. Openswan did not get an IKEv2 implementation until early 2008 though. What this means is that an RFC4322bis could properly specify semantics for IPSECKEY RR, and if they were a bit different than the semantics in 4322 for the TXT RR, that would be okay. =3D=3D=3D Yoav> Those are some of the incompatible solutions by individual Yoav> vendors. >> And RFC4322. >>=20 >> FreeSWAN has a number of local controls whereby one simply lists >> the CIDRs that one wishes to be "secure or fail" vs ones that are >> "nice to be secure". Many people have implemented MESHs by >> distributing the reverse DNS. >>=20 >> What it is missing in IKEv1 is a way to turn the host<->host >> tunnels into subnet<->subnet tunnels, and that would be easy to >> do in IKEv2 with the TS. >>=20 >>=20 >> >> Sounds like TED: >> >>=20 >> >>=20 >> http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/ted.h= tml >> >>=20 >> >> Dan. >> >>=20 >> >> On Thu, October 13, 2011 10:23 pm, Yoav Nir wrote: >>> Hi all >> >>>=20 >> >>> For years, one of the barriers to the adoption of IPsec was >> that >>> configuration didn't scale. With thousands of peers, the >> PAD and >>> SPD would become unwieldy, so even where IPsec was >> deployed it >>> was often built in hub-and-spoke configurations, >> not because >>> policy demanded this, but because it was more >> convenient to >>> configure. Individual vendors have incompatible >> solutions for >>> this, but they only work with that vendor's >> products, and within >>> the same administrative domain. >> >>>=20 >> >>> In this draft, we are proposing that the IPsecME working >> group >>> take on a working item to first define the problem, and >> then >>> offer solutions that will make IPsec scale better and in >> an >>> inter-operable way. >> >>>=20 >> >>> We plan to hold a side meeting in Taipei, and we welcome >>> >> comments both before and at that meeting. >> >>>=20 >> >>> Yoav >> >>>=20 >> >>> http://www.ietf.org/id/draft-nir-ipsecme-p2p-00.txt >>> >> http://tools.ietf.org/html/draft-nir-ipsecme-p2p-00 >> >>>=20 >> >>> _______________________________________________ IPsec mailing >> >>> list IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >>>=20 >> >>=20 >> >>=20 >> >>=20 >> >> Scanned by Check Point Total Security Gateway. >>=20 Yoav> _______________________________________________ IPsec mailing Yoav> list IPsec@ietf.org Yoav> https://www.ietf.org/mailman/listinfo/ipsec >> _______________________________________________ IPsec mailing >> list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec >>=20 >> Scanned by Check Point Total Security Gateway. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATpwzN4CLcPvd0N1lAQK1Gwf/QhHrlw4qE96lJ5d4uxxjeYyQzM5X0Crq 4BHPngR4FLabnnyINW2rLnJqtJoI/IpQu3+cuoa6Fk3L/1YDbnBFxdagrnyWX1Of agzXwiha4zKFHZqI3+P8IW75iOvU1RZ3nRIJEw38Td2cE9MFP50JEll2yKRx9ang oXpqDPs6WtaJBiXkXIoObqvBEif58+rCx0MuLn+MwZuZR2bX702UtvYcqePApbEb leIuSQOhfmYyCsl/kVm5TlVrCajDB5bDvApc9n8GKgr5VcldpGGyswj2n3Rrhcg+ qdmcTXWhn3CML9k9uBI1PUY3PJmdINp2sMc1PFinaFl/QE9RVJLMYQ== =zfW3 -----END PGP SIGNATURE----- --=-=-=-- From Paul_Koning@Dell.com Mon Oct 17 09:00:09 2011 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 B662221F8D12; Mon, 17 Oct 2011 09:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.555 X-Spam-Level: X-Spam-Status: No, score=-106.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozuRXQpolIEO; Mon, 17 Oct 2011 09:00:09 -0700 (PDT) Received: from ausc60ps301.us.dell.com (ausc60ps301.us.dell.com [143.166.148.206]) by ietfa.amsl.com (Postfix) with ESMTP id D4A4421F8D0A; Mon, 17 Oct 2011 09:00:08 -0700 (PDT) X-Loopcount0: from 10.170.28.40 From: To: , Date: Mon, 17 Oct 2011 05:48:34 -0500 Thread-Topic: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) Thread-Index: AcyMeg1KeeB0+xx5Q9uX8lZCIlZnnAAQAAFw Message-ID: <09787EF419216C41A903FD14EE5506DD030CB8FC8B@AUSX7MCPC103.AMER.DELL.COM> References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E98D17E.8000801@udel.edu> <4E9B9C12.6000505@ntp.org> In-Reply-To: <4E9B9C12.6000505@ntp.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ipsec@ietf.org, mills@udel.edu, TICTOC@ietf.org, cuiyang@huawei.com, kevin.gross@avanw.com Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 16:00:10 -0000 >I cannot answer for the performance but if I was worried about making sure= I got the correct time I'd be more likely to be concerned about authentica= ting the server than encrypting the contents. Encryption doesn't do a thing= for ensuring you got a valid packet. You don't need data confidentiality, but you do need data integrity and ant= i-replay, both of which you get from the integrity part of IPSec. This is= a place where the integrity-only cipher suites are applicable. paul From kevin.gross@avanw.com Tue Oct 18 09:43:00 2011 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 4368321F8BE9 for ; Tue, 18 Oct 2011 09:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQpE5bqxrwhi for ; Tue, 18 Oct 2011 09:42:59 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 859F721F8BB7 for ; Tue, 18 Oct 2011 09:42:59 -0700 (PDT) Received: (qmail 12534 invoked by uid 0); 18 Oct 2011 16:42:59 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy9.bluehost.com with SMTP; 18 Oct 2011 16:42:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=o23GyOZRxlzmKqcI8VNXJzFD0GD+3VH0s3hHBlvDeYo=; b=DCtHdpNZoQnWYmSPVaVYsbguQeYKg23aUEnTiWANq02V/3GGljqvFoZ1wIXtZY06AjvsNoFAyPA4PLHCjU/ipvmeTGnkEIUe8PhKD+fAbLJnjgjNUKuhDZ95tUS0ufrA; Received: from mail-yw0-f44.google.com ([209.85.213.44]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1RGCkk-0002Jq-SA; Tue, 18 Oct 2011 10:42:58 -0600 Received: by ywa8 with SMTP id 8so946307ywa.31 for ; Tue, 18 Oct 2011 09:42:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.17.147 with SMTP id s19mr5020140faa.19.1318956177697; Tue, 18 Oct 2011 09:42:57 -0700 (PDT) Received: by 10.223.93.202 with HTTP; Tue, 18 Oct 2011 09:42:57 -0700 (PDT) In-Reply-To: References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> Date: Tue, 18 Oct 2011 10:42:57 -0600 Message-ID: From: Kevin Gross To: Nico Williams Content-Type: multipart/alternative; boundary=00151747958a722d3004af956a63 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.213.44 authed with kevin.gross@avanw.com} Cc: "ipsec@ietf.org" , Danny Mayer , "TICTOC@ietf.org" , Cui Yang , "David L. Mills" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 16:43:00 -0000 --00151747958a722d3004af956a63 Content-Type: text/plain; charset=ISO-8859-1 It does seem reasonable to consider modeling encryption and decryption in as part of network latency. As long as delays introduced are the same each direction, the sync protocols will naturally subtract out this contribution. Kevin Gross On Fri, Oct 14, 2011 at 11:25 AM, Nico Williams wrote: > > The cost of crypto can be measured, and performance generally > deterministic (particularly when there's no side channels in the > crypto) (assuming no mid-crypto context switches), so that it should > be possible to correct for the delays introduced by crypto (just as > it's possible to measure and estimate network latency). Indeed, > crypto processing will likely be more deterministic than network > latency :) > > --00151747958a722d3004af956a63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It does seem reasonable to consider modeling encryption and decryption= in as part of network latency. As long as delays introduced are the same e= ach direction, the sync protocols will naturally subtract out this contribu= tion.

Kevin Gross

On Fri,= Oct 14, 2011 at 11:25 AM, Nico Williams <nico@cryptonector.com> wrote:

The cost of crypto can be measured, and performance generally
deterministic (particularly when there's no side channels in the
crypto) (assuming no mid-crypto context switches), so that it should
be possible to correct for the delays introduced by crypto (just as
it's possible to measure and estimate network latency). =A0Indeed,
crypto processing will likely be more deterministic than network
latency :)

--00151747958a722d3004af956a63-- From kevin.gross@avanw.com Tue Oct 18 09:44:22 2011 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 36E4A21F8BA2 for ; Tue, 18 Oct 2011 09:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvhyO7iCb+um for ; Tue, 18 Oct 2011 09:44:21 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 7B67121F8BA8 for ; Tue, 18 Oct 2011 09:44:21 -0700 (PDT) Received: (qmail 15877 invoked by uid 0); 18 Oct 2011 16:44:21 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy9.bluehost.com with SMTP; 18 Oct 2011 16:44:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=MfRCjCHNNd7J4ICYlT/GqSbgHpvGWPl8wPwSPs4GXUE=; b=BAM74BzrdSMya5a7ymshjnWIRzQgwZ3JTqDi7DENCFFRBgMoGPX1dn9YkmrKORT7NTOvHVaWIrZ2+gwAkJgik98q9tRsCNwcAoPHD8khwVpCMSBiVm91uEgXU1/TWG8B; Received: from mail-bw0-f44.google.com ([209.85.214.44]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1RGCm4-0003M0-Kq; Tue, 18 Oct 2011 10:44:20 -0600 Received: by bkas6 with SMTP id s6so1202644bka.31 for ; Tue, 18 Oct 2011 09:44:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.81.205 with SMTP id y13mr4967850fak.34.1318956258711; Tue, 18 Oct 2011 09:44:18 -0700 (PDT) Received: by 10.223.93.202 with HTTP; Tue, 18 Oct 2011 09:44:18 -0700 (PDT) In-Reply-To: <4A4385BFBA1BC54C863E7394BD1AECB338AACB0F@SJC-MBX-01.symmetricom.com> References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E98D17E.8000801@udel.edu> <4E9B9C12.6000505@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB8FC8B@AUSX7MCPC103.AMER.DELL.COM> <4A4385BFBA1BC54C863E7394BD1AECB338AACB0F@SJC-MBX-01.symmetricom.com> Date: Tue, 18 Oct 2011 10:44:18 -0600 Message-ID: From: Kevin Gross To: Tim Frost Content-Type: multipart/alternative; boundary=0015175d037e465aba04af956f25 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.214.44 authed with kevin.gross@avanw.com} Cc: "cuiyang@huawei.com" , "mayer@ntp.org" , "ipsec@ietf.org" , "TICTOC@ietf.org" , "nico@cryptonector.com" , "Paul_Koning@Dell.com" , "mills@udel.edu" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 16:44:22 -0000 --0015175d037e465aba04af956f25 Content-Type: text/plain; charset=ISO-8859-1 My previous comments about two-step took into account only the transmitter. Of course the the receiver needs to timestamp arrival times. Most hardware does this by recognizing packet format, a strategy that would be thwarted by encryption. It is my understanding that some network hardware timestamps all packets attaching a hardware-generated timestamp to each receive queue entry. That's what seems to be required here. This type of hardware combined with two-step sync announcements (apparently supported by both 1588 and NTP) could make for a workable solution. Kevin Gross On Tue, Oct 18, 2011 at 9:37 AM, Tim Frost wrote: > I think most of the reviewers are missing the point of this draft. > > The point is not that the timing packets are inherently secret and need > encryption, but that the 3GPP architecture mandates that EVERYTHING flowing > to the femtocell must be inside a secure tunnel, whether the security is > needed or not. It's a wider architecture issue, not the issue about whether > encryption is needed and how best to do it. > > The key figure from the draft is Figure 1: > > +-------------+ > | | > | Femtocell |<-----------------------------+ > | | | > +-------------+ | > | > | > /---------------------\ > | | > | Public Network | > | | > \---------------------/ > | > | > +------------+ +-------------+ | > |Clock Server|---------->| | | > +------------+ | | | > | Security GW |->---+ > +------------+ | | > |Femto GW |---------->| | > +------------+ +-------------+ > > > Figure 1. Typical Architecture of a Femtocell Network > > The problem with this is once the packets have been encrypted, it is not > possible for the femtocell to timestamp them on reception because it doesn't > recognise them until after decryption, which is what this draft tries to > address. > > I totally agree with the comments people like Danny have made that point > out the difficulties that identifying timing packets just opens them up to > attack. However, comments attacking the rationale for encryption are wide of > the mark - the packets are encrypted by 3GPP architecture, we have to work > out how to deal with that. > > We could argue that 3GPP should never have mandated this type of > architecture, but we would be better off arguing that at 3GPP, not here in > IETF. > > Tim > > > --0015175d037e465aba04af956f25 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My previous comment= s about two-step took into account only the transmitter. Of course the the = receiver needs to timestamp arrival times. Most hardware does this by=A0rec= ognizing=A0packet format, a strategy that would be thwarted by encryption.= =A0It is my understanding that some network hardware timestamps all packets= attaching a hardware-generated timestamp to each receive queue entry.=A0Th= at's what seems to be required here.=A0This type of hardware combined w= ith two-step sync announcements (apparently supported by both 1588 and NTP)= could make for a workable solution.

Kevin Gross


On Tue, Oct 18, 2011 at 9:37 AM, Tim Frost <= tfrost@symmetricom.com> wrote:
I think most of the reviewers are missing t= he point of this draft.

The point is not that the timing packets are inherently secret and need enc= ryption, but that the 3GPP architecture mandates that EVERYTHING flowing to= the femtocell must be inside a secure tunnel, whether the security is need= ed or not. It's a wider architecture issue, not the issue about whether= encryption is needed and how best to do it.

The key figure from the draft is Figure 1:

=A0 =A0 =A0 =A0 =A0+-------------+
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0| =A0Femtocell =A0|<-----------------------------+ =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0+-------------+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 /---------------------\
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 | =A0 Public Network =A0 =A0|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 \---------------------/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0+------------+ =A0 =A0 =A0 =A0 =A0 +-------------+ =A0 = =A0 |
=A0 =A0 =A0 =A0 =A0|Clock Server|---------->| =A0 =A0 =A0 =A0 =A0 =A0 |= =A0 =A0 |
=A0 =A0 =A0 =A0 =A0+------------+ =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 = =A0 =A0 | =A0 =A0 |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Secu= rity GW |->---+
=A0 =A0 =A0 =A0 =A0+------------+ =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 = =A0 =A0 |
=A0 =A0 =A0 =A0 =A0|Femto GW =A0 =A0|---------->| =A0 =A0 =A0 =A0 =A0 = =A0 |
=A0 =A0 =A0 =A0 =A0+------------+ =A0 =A0 =A0 =A0 =A0 +-------------+


=A0 Figure 1. =A0Typical Architecture of a Femtocell Network

The problem with this is once the packets have been encrypted, it is not po= ssible for the femtocell to timestamp them on reception because it doesn= 9;t recognise them until after decryption, which is what this draft tries t= o address.

I totally agree with the comments people like Danny have made that point ou= t the difficulties that identifying timing packets just opens them up to at= tack. However, comments attacking the rationale for encryption are wide of = the mark - the packets are encrypted by 3GPP architecture, we have to work = out how to deal with that.

We could argue that 3GPP should never have mandated this type of architectu= re, but we would be better off arguing that at 3GPP, not here in IETF.

Tim


--0015175d037e465aba04af956f25-- From Paul_Koning@Dell.com Tue Oct 18 09:49:29 2011 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 08A1021F877F; Tue, 18 Oct 2011 09:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2iC6qF0I6e3; Tue, 18 Oct 2011 09:49:27 -0700 (PDT) Received: from ausc60ps301.us.dell.com (ausc60ps301.us.dell.com [143.166.148.206]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1B421F8459; Tue, 18 Oct 2011 09:49:27 -0700 (PDT) X-Loopcount0: from 10.170.28.39 From: To: , Date: Tue, 18 Oct 2011 11:49:24 -0500 Thread-Topic: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) Thread-Index: AcyNtQ4n0oVwj5YJQW6CAxA8LlsddwAAG6oA Message-ID: <09787EF419216C41A903FD14EE5506DD030CB90B81@AUSX7MCPC103.AMER.DELL.COM> References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_09787EF419216C41A903FD14EE5506DD030CB90B81AUSX7MCPC103A_" MIME-Version: 1.0 Cc: ipsec@ietf.org, mayer@ntp.org, TICTOC@ietf.org, cuiyang@huawei.com, mills@udel.edu Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 16:49:29 -0000 --_000_09787EF419216C41A903FD14EE5506DD030CB90B81AUSX7MCPC103A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable But why would you assume that the delays are consistent? In the non-encrypted case, you can reasonably assume that because there is = an underlying assumption that there are no malicious agents in the network.= However, if you believe that encryption is needed because the network doe= s contain malicious agents, you would want to assume that anything that's i= nteresting to attack is in fact attacked. In particular, if you assume that active attacks are taking place where tim= e sync packets are selectively delayed, what does that do to your protocol? paul From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of K= evin Gross Sent: Tuesday, October 18, 2011 12:43 PM To: Nico Williams Cc: ipsec@ietf.org; Danny Mayer; TICTOC@ietf.org; Cui Yang; David L. Mills Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet = based synchronization (Yang Cui) It does seem reasonable to consider modeling encryption and decryption in a= s part of network latency. As long as delays introduced are the same each d= irection, the sync protocols will naturally subtract out this contribution. Kevin Gross On Fri, Oct 14, 2011 at 11:25 AM, Nico Williams > wrote: The cost of crypto can be measured, and performance generally deterministic (particularly when there's no side channels in the crypto) (assuming no mid-crypto context switches), so that it should be possible to correct for the delays introduced by crypto (just as it's possible to measure and estimate network latency). Indeed, crypto processing will likely be more deterministic than network latency :) --_000_09787EF419216C41A903FD14EE5506DD030CB90B81AUSX7MCPC103A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

But why w= ould you assume that the delays are consistent?

 

In the non-encrypted case, you can reasonably assume that because there = is an underlying assumption that there are no malicious agents in the netwo= rk.  However, if you believe that encryption is needed because the net= work does contain malicious agents, you would want to assume that anything = that’s interesting to attack is in fact attacked.

 

In particular, if you assume that active attacks are taking plac= e where time sync packets are selectively delayed, what does that do to you= r protocol?

 

     &nb= sp;          paul

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] = On Behalf Of Kevin Gross
Sent: Tuesday, October 18, 2011 12:4= 3 PM
To: Nico Williams
Cc: ipsec@ietf.org; Danny Mayer;= TICTOC@ietf.org; Cui Yang; David L. Mills
Subject: Re: [IPsec] [= TICTOC] Review request for IPsec security for packet based synchronization = (Yang Cui)

 

<= div>

It does seem reasonable to consider modeling encry= ption and decryption in as part of network latency. As long as delays intro= duced are the same each direction, the sync protocols will naturally subtra= ct out this contribution.

 

Kevin Gross

 

= On Fri, Oct 14, 2011 at 11:25 AM, Nico Williams <nico@cryptonector.com> wrote:

<= p class=3DMsoNormal> 

The cost of crypto can be measured, and performan= ce generally
deterministic (particularly when there's no side channels i= n the
crypto) (assuming no mid-crypto context switches), so that it shou= ld
be possible to correct for the delays introduced by crypto (just asit's possible to measure and estimate network latency).  Indeed,
= crypto processing will likely be more deterministic than network
latency= :)

= --_000_09787EF419216C41A903FD14EE5506DD030CB90B81AUSX7MCPC103A_-- From kevin.gross@avanw.com Tue Oct 18 10:46:39 2011 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 AF8B821F8B14 for ; Tue, 18 Oct 2011 10:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMmGexVJjuxP for ; Tue, 18 Oct 2011 10:46:38 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id C61BB21F8B0A for ; Tue, 18 Oct 2011 10:46:38 -0700 (PDT) Received: (qmail 1587 invoked by uid 0); 18 Oct 2011 17:46:34 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy1.bluehost.com with SMTP; 18 Oct 2011 17:46:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=hkynkH5PK4j61h9yOf64G2vc7b2pyXH4M9LKg7itIfY=; b=iOQJ2UTVa7ueJ5XYQK11DsBRYsTEJxJ3SByt4C9mvXipXcqGGkZQArycEOypoQImyEXMiOB2TpvNRK9mTzIGIoUfDS2Y2rUnzjLPA/WVCos6G/sYjDb9kI0+VJLlPqBp; Received: from mail-ey0-f172.google.com ([209.85.215.172]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1RGDkI-0001Xk-7i; Tue, 18 Oct 2011 11:46:34 -0600 Received: by eyg24 with SMTP id 24so878216eyg.31 for ; Tue, 18 Oct 2011 10:46:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.65.20 with SMTP id g20mr5349268fai.20.1318959913531; Tue, 18 Oct 2011 10:45:13 -0700 (PDT) Received: by 10.223.93.202 with HTTP; Tue, 18 Oct 2011 10:45:13 -0700 (PDT) In-Reply-To: <09787EF419216C41A903FD14EE5506DD030CB90B81@AUSX7MCPC103.AMER.DELL.COM> References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB90B81@AUSX7MCPC103.AMER.DELL.COM> Date: Tue, 18 Oct 2011 11:45:13 -0600 Message-ID: From: Kevin Gross To: Paul_Koning@dell.com Content-Type: multipart/alternative; boundary=001517402a461e7b7304af9649da X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.215.172 authed with kevin.gross@avanw.com} Cc: cuiyang@huawei.com, mayer@ntp.org, ipsec@ietf.org, TICTOC@ietf.org, nico@cryptonector.com, mills@udel.edu Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 17:46:39 -0000 --001517402a461e7b7304af9649da Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Nico's contention is that it should take a constant amount of time to decrypt a packet once it is received. I don't think this is exactly true bu= t when compared to other (variable) latencies in the system, possibly a reasonable approximation. If an attacker delays or drops synchronization packets, clock quality will suffer. In the extreme case, all useful clock communication is lost and nothing works. I don't think this situation is any different for clock traffic than it is for other traffic. Encryption cannot prevent denial of service. Kevin Gross On Tue, Oct 18, 2011 at 10:49 AM, wrote: > But why would you assume that the delays are consistent?**** > > ** ** > > In the non-encrypted case, you can reasonably assume that because there i= s > an underlying assumption that there are no malicious agents in the networ= k. > However, if you believe that encryption is needed because the network doe= s > contain malicious agents, you would want to assume that anything that=92s > interesting to attack is in fact attacked.**** > > ** ** > > In particular, if you assume that active attacks are taking place where > time sync packets are selectively delayed, what does that do to your > protocol?**** > > ** ** > > paul**** > > ** ** > > *From:* ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] *On Behalf > Of *Kevin Gross > *Sent:* Tuesday, October 18, 2011 12:43 PM > *To:* Nico Williams > *Cc:* ipsec@ietf.org; Danny Mayer; TICTOC@ietf.org; Cui Yang; David L. > Mills > *Subject:* Re: [IPsec] [TICTOC] Review request for IPsec security for > packet based synchronization (Yang Cui)**** > > ** ** > > It does seem reasonable to consider modeling encryption and decryption in > as part of network latency. As long as delays introduced are the same eac= h > direction, the sync protocols will naturally subtract out this contributi= on. > **** > > ** ** > > Kevin Gross**** > > ** ** > > On Fri, Oct 14, 2011 at 11:25 AM, Nico Williams > wrote:**** > > ** ** > > The cost of crypto can be measured, and performance generally > deterministic (particularly when there's no side channels in the > crypto) (assuming no mid-crypto context switches), so that it should > be possible to correct for the delays introduced by crypto (just as > it's possible to measure and estimate network latency). Indeed, > crypto processing will likely be more deterministic than network > latency :)**** > --001517402a461e7b7304af9649da Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Nico's contention is that it should take a constant amount of time to d= ecrypt a packet once it is received. I don't think this is exactly true= but when compared to other (variable) latencies in the system, possibly a = reasonable approximation.

If an attacker delays or drops synchronization packets, cloc= k quality will suffer. In the extreme case, all useful clock communication = is lost and nothing works. I don't think this situation is any differen= t for clock traffic than it is for other traffic. Encryption cannot prevent= denial of service.

Kevin Gross

On Tue, O= ct 18, 2011 at 10:49 AM, <Paul_Koning@dell.com> wrote:

But why would you assume= that the delays are consistent?

=A0

In th= e non-encrypted case, you can reasonably assume that because there is an un= derlying assumption that there are no malicious agents in the network.=A0 H= owever, if you believe that encryption is needed because the network does c= ontain malicious agents, you would want to assume that anything that=92s in= teresting to attack is in fact attacked.

=A0

In particular, if you assume that active attacks are taki= ng place where time sync packets are selectively delayed, what does that do= to your protocol?

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 paul=

=A0

=

From:= ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Be= half Of Kevin Gross
Sent: Tuesday, October 18, 2011 12:43 PM
To: Nico Williams=
Cc: ipsec@ie= tf.org; Danny Mayer; TICTOC@ietf.org; Cui Yang; David L. Mills
Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for = packet based synchronization (Yang Cui)

<= /div>

=A0

It does seem reasonable to consider modeling encryption and decryption in a= s part of network latency. As long as delays introduced are the same each d= irection, the sync protocols will naturally subtract out this contribution.=

=A0

Kevin Gross

=A0

On Fri, Oct 14, 2011 at 11:2= 5 AM, Nico Williams <nico@cryptonector.com> wrote:

=A0

The cost of crypto can be measured, and p= erformance generally
deterministic (particularly when there's no sid= e channels in the
crypto) (assuming no mid-crypto context switches), so that it should
be = possible to correct for the delays introduced by crypto (just as
it'= s possible to measure and estimate network latency). =A0Indeed,
crypto p= rocessing will likely be more deterministic than network
latency :)


--001517402a461e7b7304af9649da-- From Paul_Koning@Dell.com Tue Oct 18 11:16:48 2011 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 00C5B21F8ABB; Tue, 18 Oct 2011 11:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.587 X-Spam-Level: X-Spam-Status: No, score=-106.587 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKHHyveqT0hq; Tue, 18 Oct 2011 11:16:45 -0700 (PDT) Received: from ausxipps301.us.dell.com (ausxipps301.us.dell.com [143.166.148.223]) by ietfa.amsl.com (Postfix) with ESMTP id 8612521F858C; Tue, 18 Oct 2011 11:16:45 -0700 (PDT) X-Loopcount0: from 10.170.28.40 From: To: Date: Tue, 18 Oct 2011 13:16:41 -0500 Thread-Topic: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) Thread-Index: AcyNveJ4wldp1urkTFy4NS4+8o8H1gAA9I2Q Message-ID: <09787EF419216C41A903FD14EE5506DD030CD64A86@AUSX7MCPC103.AMER.DELL.COM> References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB90B81@AUSX7MCPC103.AMER.DELL.COM> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_09787EF419216C41A903FD14EE5506DD030CD64A86AUSX7MCPC103A_" MIME-Version: 1.0 Cc: cuiyang@huawei.com, mayer@ntp.org, ipsec@ietf.org, TICTOC@ietf.org, nico@cryptonector.com, mills@udel.edu Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 18:16:48 -0000 --_000_09787EF419216C41A903FD14EE5506DD030CD64A86AUSX7MCPC103A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Absolutely. But if you allow, say, one second round trip time, you have to= assume that your time is off by that amount from the master. In an enviro= nment without active attackers you would assume that the error is a fair am= ount smaller, basically the estimate of the difference between the two legs= of the trip plus some allowance for jitter. If you introduce attackers, y= ou might have an underlying network that offers near-zero latency, and all = the latency you're seeing is due to active attack on one or the other legs = of the round trip. paul From: Kevin Gross [mailto:kevin.gross@avanw.com] Sent: Tuesday, October 18, 2011 1:45 PM To: Koning, Paul Cc: nico@cryptonector.com; ipsec@ietf.org; mayer@ntp.org; TICTOC@ietf.org; = cuiyang@huawei.com; mills@udel.edu Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet = based synchronization (Yang Cui) Nico's contention is that it should take a constant amount of time to decry= pt a packet once it is received. I don't think this is exactly true but whe= n compared to other (variable) latencies in the system, possibly a reasonab= le approximation. If an attacker delays or drops synchronization packets, clock quality will = suffer. In the extreme case, all useful clock communication is lost and not= hing works. I don't think this situation is any different for clock traffic= than it is for other traffic. Encryption cannot prevent denial of service. Kevin Gross On Tue, Oct 18, 2011 at 10:49 AM, > wrote: But why would you assume that the delays are consistent? In the non-encrypted case, you can reasonably assume that because there is = an underlying assumption that there are no malicious agents in the network.= However, if you believe that encryption is needed because the network doe= s contain malicious agents, you would want to assume that anything that's i= nteresting to attack is in fact attacked. In particular, if you assume that active attacks are taking place where tim= e sync packets are selectively delayed, what does that do to your protocol? paul From: ipsec-bounces@ietf.org [mailto:ipsec-b= ounces@ietf.org] On Behalf Of Kevin Gross Sent: Tuesday, October 18, 2011 12:43 PM To: Nico Williams Cc: ipsec@ietf.org; Danny Mayer; TICTOC@ietf.org; Cui Yang; David L. Mills Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet = based synchronization (Yang Cui) It does seem reasonable to consider modeling encryption and decryption in a= s part of network latency. As long as delays introduced are the same each d= irection, the sync protocols will naturally subtract out this contribution. Kevin Gross On Fri, Oct 14, 2011 at 11:25 AM, Nico Williams > wrote: The cost of crypto can be measured, and performance generally deterministic (particularly when there's no side channels in the crypto) (assuming no mid-crypto context switches), so that it should be possible to correct for the delays introduced by crypto (just as it's possible to measure and estimate network latency). Indeed, crypto processing will likely be more deterministic than network latency :) --_000_09787EF419216C41A903FD14EE5506DD030CD64A86AUSX7MCPC103A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Absolutel= y.  But if you allow, say, one second round trip time, you have to ass= ume that your time is off by that amount from the master.  In an envir= onment without active attackers you would assume that the error is a fair a= mount smaller, basically the estimate of the difference between the two leg= s of the trip plus some allowance for jitter.  If you introduce attack= ers, you might have an underlying network that offers near-zero latency, an= d all the latency you’re seeing is due to active attack on one or the= other legs of the round trip.

 

  &n= bsp;            = ; paul

 

From: Kevin Gross [mailto:kevin.gross@avanw.com= ]
Sent: Tuesday, October 18, 2011 1:45 PM
To: Koning, = Paul
Cc: nico@cryptonector.com; ipsec@ietf.org; mayer@ntp.org; TI= CTOC@ietf.org; cuiyang@huawei.com; mills@udel.edu
Subject: Re: [I= Psec] [TICTOC] Review request for IPsec security for packet based synchroni= zation (Yang Cui)

 

Nico's contention is that it should take a const= ant amount of time to decrypt a packet once it is received. I don't think t= his is exactly true but when compared to other (variable) latencies in the = system, possibly a reasonable approximation.

 

If an attack= er delays or drops synchronization packets, clock quality will suffer. In t= he extreme case, all useful clock communication is lost and nothing works. = I don't think this situation is any different for clock traffic than it is = for other traffic. Encryption cannot prevent denial of service.<= /p>

 

Kevin Gross

=

On Tue, Oct 18, 2011 at 10:49 AM, <Paul_Koning@dell.com> wrote:

<= div>

But why woul= d you assume that the delays are consistent?

<= span style=3D'font-size:11.0pt;color:#1F497D'> 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>In the non-encrypted c= ase, you can reasonably assume that because there is an underlying assumpti= on that there are no malicious agents in the network.  However, if you= believe that encryption is needed because the network does contain malicio= us agents, you would want to assume that anything that’s interesting = to attack is in fact attacked.

 

In particular, if you assume that act= ive attacks are taking place where time sync packets are selectively delaye= d, what does that do to your protocol?

 

<= span style=3D'font-size:11.0pt;color:#1F497D'>     = ;           paul

 

From:= ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] O= n Behalf Of Kevin Gross
Sent: Tuesday, October 18, 2011 12:43= PM
To: Nico Williams
Cc: ipsec@ietf.org; Danny Mayer; TICTOC@ietf.org; Cui Yang; David L. M= ills
Subject: Re: [IPsec] [TICTOC] Review request for IPsec secur= ity for packet based synchronization (Yang Cui)

<= div>

 

It does seem reasonable to cons= ider modeling encryption and decryption in as part of network latency. As l= ong as delays introduced are the same each direction, the sync protocols wi= ll naturally subtract out this contribution.

 

Kevin Gross

 

On Fri, Oct 14, 2011 at 11:25 AM, Nic= o Williams <n= ico@cryptonector.com> wrote:

 

The cost of crypto can be measured, and performance generall= y
deterministic (particularly when there's no side channels in the
cr= ypto) (assuming no mid-crypto context switches), so that it should
be po= ssible to correct for the delays introduced by crypto (just as
it's poss= ible to measure and estimate network latency).  Indeed,
crypto proc= essing will likely be more deterministic than network
latency :)

 =

= --_000_09787EF419216C41A903FD14EE5506DD030CD64A86AUSX7MCPC103A_-- From kevin.gross@avanw.com Tue Oct 18 11:57:15 2011 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 7F1D521F8B31 for ; Tue, 18 Oct 2011 11:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTuy5knL8ia4 for ; Tue, 18 Oct 2011 11:57:14 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 8F7F721F877F for ; Tue, 18 Oct 2011 11:57:14 -0700 (PDT) Received: (qmail 16537 invoked by uid 0); 18 Oct 2011 18:57:14 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy7.bluehost.com with SMTP; 18 Oct 2011 18:57:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=4bQrKoHrvxa1DSWWxuuyXPl37yFlxSygupTnP+S39so=; b=a1wHxyYAGYSgPt8xcHYkbMCN45WGvMiaW7eJwWpXeLmIh95VF+35u1MJhU1+fyFTb5N1rSiaQ/rh/YU1yFzBUgN2cVJmrM0BRdLAZTa9T8hL9SFpty/P+A9o7gtz1ytd; Received: from mail-ey0-f172.google.com ([209.85.215.172]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1RGEqf-0005ND-Me; Tue, 18 Oct 2011 12:57:14 -0600 Received: by eyg24 with SMTP id 24so944214eyg.31 for ; Tue, 18 Oct 2011 11:57:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.5.3 with SMTP id 3mr5780266fat.4.1318964232205; Tue, 18 Oct 2011 11:57:12 -0700 (PDT) Received: by 10.223.93.202 with HTTP; Tue, 18 Oct 2011 11:57:12 -0700 (PDT) In-Reply-To: <09787EF419216C41A903FD14EE5506DD030CD64A86@AUSX7MCPC103.AMER.DELL.COM> References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB90B81@AUSX7MCPC103.AMER.DELL.COM> <09787EF419216C41A903FD14EE5506DD030CD64A86@AUSX7MCPC103.AMER.DELL.COM> Date: Tue, 18 Oct 2011 12:57:12 -0600 Message-ID: From: Kevin Gross To: Paul_Koning@dell.com Content-Type: multipart/alternative; boundary=00151747948e8837c704af974a4b X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.215.172 authed with kevin.gross@avanw.com} Cc: cuiyang@huawei.com, mayer@ntp.org, ipsec@ietf.org, TICTOC@ietf.org, nico@cryptonector.com, mills@udel.edu Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 18:57:15 -0000 --00151747948e8837c704af974a4b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I suppose there is a possible selective attack vector here based on messing with packets based on their length and transmission timing. It's an interesting topic but I don't think that was the intended topic of this discussion. We want to figure out how/if can we make clock distribution wor= k through an IPSec connection. I guess your point is that an "IPSec connection" should be defined as an IPSec connection _under active attack_. I'm afraid not qualified to assess these larger-picture security questions. Kevin Gross On Tue, Oct 18, 2011 at 12:16 PM, wrote: > Absolutely. But if you allow, say, one second round trip time, you have = to > assume that your time is off by that amount from the master. In an > environment without active attackers you would assume that the error is a > fair amount smaller, basically the estimate of the difference between the > two legs of the trip plus some allowance for jitter. If you introduce > attackers, you might have an underlying network that offers near-zero > latency, and all the latency you=92re seeing is due to active attack on o= ne or > the other legs of the round trip.**** > > ** ** > > paul**** > > ** ** > > *From:* Kevin Gross [mailto:kevin.gross@avanw.com] > *Sent:* Tuesday, October 18, 2011 1:45 PM > *To:* Koning, Paul > *Cc:* nico@cryptonector.com; ipsec@ietf.org; mayer@ntp.org; > TICTOC@ietf.org; cuiyang@huawei.com; mills@udel.edu > > *Subject:* Re: [IPsec] [TICTOC] Review request for IPsec security for > packet based synchronization (Yang Cui)**** > > ** ** > > Nico's contention is that it should take a constant amount of time to > decrypt a packet once it is received. I don't think this is exactly true = but > when compared to other (variable) latencies in the system, possibly a > reasonable approximation.**** > > ** ** > > If an attacker delays or drops synchronization packets, clock quality wil= l > suffer. In the extreme case, all useful clock communication is lost and > nothing works. I don't think this situation is any different for clock > traffic than it is for other traffic. Encryption cannot prevent denial of > service.**** > > ** ** > > Kevin Gross**** > > On Tue, Oct 18, 2011 at 10:49 AM, wrote:**** > > But why would you assume that the delays are consistent?**** > > **** > > In the non-encrypted case, you can reasonably assume that because there i= s > an underlying assumption that there are no malicious agents in the networ= k. > However, if you believe that encryption is needed because the network doe= s > contain malicious agents, you would want to assume that anything that=92s > interesting to attack is in fact attacked.**** > > **** > > In particular, if you assume that active attacks are taking place where > time sync packets are selectively delayed, what does that do to your > protocol?**** > > **** > > paul**** > > **** > > *From:* ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] *On Behalf > Of *Kevin Gross > *Sent:* Tuesday, October 18, 2011 12:43 PM > *To:* Nico Williams > *Cc:* ipsec@ietf.org; Danny Mayer; TICTOC@ietf.org; Cui Yang; David L. > Mills > *Subject:* Re: [IPsec] [TICTOC] Review request for IPsec security for > packet based synchronization (Yang Cui)**** > > **** > > It does seem reasonable to consider modeling encryption and decryption in > as part of network latency. As long as delays introduced are the same eac= h > direction, the sync protocols will naturally subtract out this contributi= on. > **** > > **** > > Kevin Gross**** > > **** > > On Fri, Oct 14, 2011 at 11:25 AM, Nico Williams > wrote:**** > > **** > > The cost of crypto can be measured, and performance generally > deterministic (particularly when there's no side channels in the > crypto) (assuming no mid-crypto context switches), so that it should > be possible to correct for the delays introduced by crypto (just as > it's possible to measure and estimate network latency). Indeed, > crypto processing will likely be more deterministic than network > latency :)**** > > ** ** > --=20 Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org --00151747948e8837c704af974a4b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I suppose there is a possible selective attack vector here based on messing= with packets based on their length and transmission timing. It's an in= teresting topic but I don't think that was the intended topic of this d= iscussion. We want to figure out how/if can we make clock distribution work= through an IPSec connection. I guess your point is that an "IPSec con= nection" should be defined as an IPSec connection _under active attack= _. I'm afraid not qualified to assess these larger-picture security que= stions.

Kevin Gross

On Tue, Oct 18= , 2011 at 12:16 PM, <Paul_Koning@dell.com> wrote:

Absolutely.=A0 But if yo= u allow, say, one second round trip time, you have to assume that your time= is off by that amount from the master.=A0 In an environment without active= attackers you would assume that the error is a fair amount smaller, basica= lly the estimate of the difference between the two legs of the trip plus so= me allowance for jitter.=A0 If you introduce attackers, you might have an u= nderlying network that offers near-zero latency, and all the latency you=92= re seeing is due to active attack on one or the other legs of the round tri= p.

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 paul=

=A0

=

From:= Kevin Gross [mailto:kevin.gross@avanw.com]
Sent: Tuesday, October 18, 2011 1:45 PM
To: Koning, PaulCc: nic= o@cryptonector.com; ipsec@ietf.org; may= er@ntp.org; TICTOC= @ietf.org; cuiy= ang@huawei.com; mil= ls@udel.edu


Subject: Re: [IPsec] [TICTOC] Review request f= or IPsec security for packet based synchronization (Yang Cui)=

=A0

=

Nico's contention is that it should take a constant amount of time to d= ecrypt a packet once it is received. I don't think this is exactly true= but when compared to other (variable) latencies in the system, possibly a = reasonable approximation.

=A0

If an attacker delays or drops synchronization packets, clock quali= ty will suffer. In the extreme case, all useful clock communication is lost= and nothing works. I don't think this situation is any different for c= lock traffic than it is for other traffic. Encryption cannot prevent denial= of service.

=A0

Kevin Gross

=

On Tue, Oct 18, 2011 at 10:49 AM, <Paul_Koning@dell.com= > wrote:

But why would you assume that the delays are consistent?=

=A0

In th= e non-encrypted case, you can reasonably assume that because there is an un= derlying assumption that there are no malicious agents in the network.=A0 H= owever, if you believe that encryption is needed because the network does c= ontain malicious agents, you would want to assume that anything that=92s in= teresting to attack is in fact attacked.

=A0

In particular, if you assume that active attacks are taki= ng place where time sync packets are selectively delayed, what does that do= to your protocol?

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 paul=

=A0

=

From:= ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Be= half Of Kevin Gross
Sent: Tuesday, October 18, 2011 12:43 PM
To: Nico Williams=
Cc: ipsec@ie= tf.org; Danny Mayer; TICTOC@ietf.org; Cui Yang; David L. Mills
Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for = packet based synchronization (Yang Cui)

<= p class=3D"MsoNormal">=A0

It d= oes seem reasonable to consider modeling encryption and decryption in as pa= rt of network latency. As long as delays introduced are the same each direc= tion, the sync protocols will naturally subtract out this contribution.<= /u>

=A0

Kevin Gross

= =A0

On Fri, Oct 14, 2011 at 11= :25 AM, Nico Williams <nico@cryptonector.com> wrote:

=A0

The cost of crypto can be measured, and p= erformance generally
deterministic (particularly when there's no sid= e channels in the
crypto) (assuming no mid-crypto context switches), so that it should
be = possible to correct for the delays introduced by crypto (just as
it'= s possible to measure and estimate network latency). =A0Indeed,
crypto p= rocessing will likely be more deterministic than network
latency :)

=A0




--
Kevin Gross
+1-303-447= -0517
Media Network Consultant
AVA Networks -=A0www.AVAnw.com,=A0www.X192.org


--00151747948e8837c704af974a4b-- From Paul_Koning@Dell.com Tue Oct 18 12:11:51 2011 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 7975E21F8CDE; Tue, 18 Oct 2011 12:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.591 X-Spam-Level: X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWCESor2gQdd; Tue, 18 Oct 2011 12:11:50 -0700 (PDT) Received: from ausxipps301.us.dell.com (ausxipps301.us.dell.com [143.166.148.223]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEA121F8CD0; Tue, 18 Oct 2011 12:11:49 -0700 (PDT) X-Loopcount0: from 10.175.216.250 From: To: Date: Tue, 18 Oct 2011 14:11:47 -0500 Thread-Topic: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) Thread-Index: AcyNx8DPeZQX8DsBRBKy6ouHGFQ5PgAAWMLw Message-ID: <09787EF419216C41A903FD14EE5506DD030CD64B50@AUSX7MCPC103.AMER.DELL.COM> References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB90B81@AUSX7MCPC103.AMER.DELL.COM> <09787EF419216C41A903FD14EE5506DD030CD64A86@AUSX7MCPC103.AMER.DELL.COM> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_09787EF419216C41A903FD14EE5506DD030CD64B50AUSX7MCPC103A_" MIME-Version: 1.0 Cc: cuiyang@huawei.com, mayer@ntp.org, ipsec@ietf.org, TICTOC@ietf.org, nico@cryptonector.com, mills@udel.edu Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 19:11:51 -0000 --_000_09787EF419216C41A903FD14EE5506DD030CD64B50AUSX7MCPC103A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That's what I was thinking. The point is that IPSec is a security mechanism, so if you're specifying it= s use you need to discuss the security considerations. (The RFC will need = to do so.) That translates into discussing the possible attacks and what e= ffect they would have on the integrity of the service. And yes, active att= acks are very much part of the world in which IPSec is intended to live. Usually, IPSec protects data, and the data carried by IPSec is protected fr= om eavesdropping and from undetected modification or replay. It is not pro= tected from denial of service. All that is true for time synchronization as well. But unlike most data tr= ansfer protocols, in your case it's not just the content of the packets tha= t matters, but also their arrival times. And my point is that IPSec does n= ot protect you from an attacker tampering with the arrival times. So you'd= want to call out the fact that a measured round trip time T means the time= obtained by the sync process is accurate to T - but that you cannot assume= it is accurate to better than T as you usually would. paul From: Kevin Gross [mailto:kevin.gross@avanw.com] Sent: Tuesday, October 18, 2011 2:57 PM To: Koning, Paul Cc: nico@cryptonector.com; ipsec@ietf.org; mayer@ntp.org; TICTOC@ietf.org; = cuiyang@huawei.com; mills@udel.edu Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet = based synchronization (Yang Cui) I suppose there is a possible selective attack vector here based on messing= with packets based on their length and transmission timing. It's an intere= sting topic but I don't think that was the intended topic of this discussio= n. We want to figure out how/if can we make clock distribution work through= an IPSec connection. I guess your point is that an "IPSec connection" shou= ld be defined as an IPSec connection _under active attack_. I'm afraid not = qualified to assess these larger-picture security questions. ... --_000_09787EF419216C41A903FD14EE5506DD030CD64B50AUSX7MCPC103A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That̵= 7;s what I was thinking.

<= o:p> 

The point is that IP= Sec is a security mechanism, so if you’re specifying its use you need= to discuss the security considerations.  (The RFC will need to do so.= )  That translates into discussing the possible attacks and what effec= t they would have on the integrity of the service.  And yes, active at= tacks are very much part of the world in which IPSec is intended to live.

 

Usually, IPSec protects data, and the data car= ried by IPSec is protected from eavesdropping and from undetected modificat= ion or replay.  It is not protected from denial of service.=

 

All that is true for time synchronization as well. = ; But unlike most data transfer protocols, in your case it’s not just= the content of the packets that matters, but also their arrival times.&nbs= p; And my point is that IPSec does not protect you from an attacker tamperi= ng with the arrival times.  So you’d want to call out the fact t= hat a measured round trip time T means the time obtained by the sync proces= s is accurate to T – but that you cannot assume it is accurate to bet= ter than T as you usually would.

=  

  =             &nb= sp; paul

 =

From: Kevin Gross [mailto:kevin.gross@avanw.c= om]
Sent: Tuesday, October 18, 2011 2:57 PM
To: Koning= , Paul
Cc: nico@cryptonector.com; ipsec@ietf.org; mayer@ntp.org; = TICTOC@ietf.org; cuiyang@huawei.com; mills@udel.edu
Subject: Re: = [IPsec] [TICTOC] Review request for IPsec security for packet based synchro= nization (Yang Cui)

 

I suppose there is a possible selective attack= vector here based on messing with packets based on their length and transm= ission timing. It's an interesting topic but I don't think that was the int= ended topic of this discussion. We want to figure out how/if can we make cl= ock distribution work through an IPSec connection. I guess your point is th= at an "IPSec connection" should be defined as an IPSec connection= _under active attack_. I'm afraid not qualified to assess these larger-pic= ture security questions.

= …

 

= --_000_09787EF419216C41A903FD14EE5506DD030CD64B50AUSX7MCPC103A_-- From nico@cryptonector.com Tue Oct 18 12:20:42 2011 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 05E0F21F8A56; Tue, 18 Oct 2011 12:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ggcasxdlcn9; Tue, 18 Oct 2011 12:20:39 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9301E21F8D7B; Tue, 18 Oct 2011 12:20:39 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 8FC0267808E; Tue, 18 Oct 2011 12:20:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=nlAo8xpWzCtm25XURrwjZ cM15GnwMpf5q1enrzA9QhSVUXd0isHqtp0IkeM2tyR9LyXWl0bWG+p2RUrloaY5E dOX3QfOYrDy1uKsMU/IgAtd2+HqciFpR2KwqLzDFPH6N80hJkkNLwLYVxvfYgvG5 hkkeJjmhX1rSjuh/P85es4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=S99SyLdi81oA4v45JAvv 0MJALXs=; b=jlq3J6GCEm7qg6+7ELwDeiiuWAcZpJwAj2NdEpYizYxvI2kN1evy JwgfJFVZxOdaGYOjCm3xaVn/hI5gaHoyL2uLdrqFbWchzs70folBdIs4mLBEt02X LEy2caSZYeHFVbOFF7MjTkISLaNN8I+6CrZZxc6Xv68V3ai7VRS/XMU= Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id D8E4E678096; Tue, 18 Oct 2011 12:20:01 -0700 (PDT) Received: by pzk34 with SMTP id 34so2452902pzk.9 for ; Tue, 18 Oct 2011 12:20:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.57.102 with SMTP id h6mr6959173pbq.7.1318965601503; Tue, 18 Oct 2011 12:20:01 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Tue, 18 Oct 2011 12:20:01 -0700 (PDT) In-Reply-To: References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB90B81@AUSX7MCPC103.AMER.DELL.COM> <09787EF419216C41A903FD14EE5506DD030CD64A86@AUSX7MCPC103.AMER.DELL.COM> Date: Tue, 18 Oct 2011 14:20:01 -0500 Message-ID: From: Nico Williams To: Kevin Gross Content-Type: text/plain; charset=UTF-8 Cc: cuiyang@huawei.com, mayer@ntp.org, ipsec@ietf.org, TICTOC@ietf.org, Paul_Koning@dell.com, mills@udel.edu Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 19:20:42 -0000 On Tue, Oct 18, 2011 at 1:57 PM, Kevin Gross wrote: > I suppose there is a possible selective attack vector here based on messing > with packets based on their length and transmission timing. It's an > interesting topic but I don't think that was the intended topic of this > discussion. We want to figure out how/if can we make clock distribution work > through an IPSec connection. I guess your point is that an "IPSec > connection" should be defined as an IPSec connection _under active attack_. > I'm afraid not qualified to assess these larger-picture security questions. [Nit: it's IPsec, not IPSec.] There's no such thing as an "IPsec connection". (The closest to that would be RFC5660.) I don't understand what it is about IPsec that makes it difficult or impossible to distribute time ("[w]e want to figure out how/if we can make clock distribution work through [IPsec]"). My guess is that you are referring to IPsec processing latency, but that's only a guess. Nico -- From nico@cryptonector.com Tue Oct 18 12:33:25 2011 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 E91A621F8D1B; Tue, 18 Oct 2011 12:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJfidLnktaqT; Tue, 18 Oct 2011 12:33:25 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 5916E21F8D80; Tue, 18 Oct 2011 12:33:25 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id C6C54BC04E; Tue, 18 Oct 2011 12:33:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=q3ggU+ZP39zDIY1Ll5Yf6 uh1OfUg6a8f9R/kIuJAHCGMhMQOAmUSlWkqBvvbRDHgHuhm6FtjNNZZg/3BvtslH gbQHsxYYqOJ77d/6kVqScYlFSSVUzBP5Kvm8L/1hRSKvOtADBWPlBa5EvHTnbhyv pu3YgayJ1JZ0xVV/uuViwQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=PRiNn2PYJrgOyr6WPKk1 +X3GJ+Y=; b=gfmTUBzS2/44SmXtZqQ4W6fBJvv3+3oZowbFtC3CJwYjKwdEvIL3 NRxgfcDHV7h9p2zeRO6TFJdgwr1PXyTxcXU/C3X6gkcN0eA9Xu8Wwkl449F7Mr8t 1pvAqLL+IEXPpuYzUtunTFakiHeLSPHz99sLVMttdm9p7clSRoFYWNM= Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id 679A0BC047; Tue, 18 Oct 2011 12:33:04 -0700 (PDT) Received: by gyh20 with SMTP id 20so1137294gyh.31 for ; Tue, 18 Oct 2011 12:33:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.57.102 with SMTP id h6mr7025851pbq.7.1318966383422; Tue, 18 Oct 2011 12:33:03 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Tue, 18 Oct 2011 12:33:03 -0700 (PDT) In-Reply-To: References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB90B81@AUSX7MCPC103.AMER.DELL.COM> Date: Tue, 18 Oct 2011 14:33:03 -0500 Message-ID: From: Nico Williams To: Kevin Gross Content-Type: text/plain; charset=UTF-8 Cc: cuiyang@huawei.com, mayer@ntp.org, ipsec@ietf.org, TICTOC@ietf.org, Paul_Koning@dell.com, mills@udel.edu Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 19:33:26 -0000 On Tue, Oct 18, 2011 at 12:45 PM, Kevin Gross wrote: > Nico's contention is that it should take a constant amount of time to > decrypt a packet once it is received. I don't think this is exactly true but > when compared to other (variable) latencies in the system, possibly a > reasonable approximation. Not constant so much as deterministic (for some algorithms, and some implementations, but I assume that side-channels are not desirable, which leads to the assumption of deterministic timing) or measurable. In practice measuring this time is probably difficult, for example, in preemptible kernel designs, or if the HW lacks a sufficiently high resolution timer or CPU cycle counter. I grant then that the proposed solution is simpler to implement. But should the proposal be negotiable, and if so, how? > If an attacker delays or drops synchronization packets, clock quality will > suffer. In the extreme case, all useful clock communication is lost and > nothing works. I don't think this situation is any different for clock > traffic than it is for other traffic. Encryption cannot prevent denial of > service. However, encryption can make it harder for an attacker to delay just the timing packets (though not impossible given enough meta-data leaking to mount effective traffic analysis). Or, to put it differently, making timing packets identifiable makes it easier for an attacker to DoS only the timing exchanges but not the rest. DoS attacks based on not allowing packets through, or delaying them, generally cannot be avoided, so perhaps there's no cause for concern. I think you'd want to have a security consideration describing the problems that might arise from a selective DoS attack on timing, as well as mitigations. Nico -- From nico@cryptonector.com Tue Oct 18 12:35:21 2011 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 D985121F8DA8; Tue, 18 Oct 2011 12:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSeO0ZEFQdbT; Tue, 18 Oct 2011 12:35:21 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 59E6421F8D70; Tue, 18 Oct 2011 12:35:21 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 4D1125C8035; Tue, 18 Oct 2011 12:33:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=wr+34V82pm/rdUUUTMtY77B+SUDOSqvhF/OlLHEyVR+9 9YKiM+Hdp/ntQI6sjTwcuOEPego2SEHJJ3JT4q9E+BOoEYZBQxVoYbLZds0h5rbJ y6e4D89wFEp+7uZjcdobwFsmWMUkrEv4hiw9b7qhVNI35EBNGmk6ePpbIiUMaaU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=NQXvB3YItBTUIzQ4ZawxZ8La+TI=; b=GOMZE3jNAkf e6pp94U9CPc+y25yBLjAUElsK6mv4IlW8LJPSEWVESiryzQ1QHTelq0iPDXcW5SP 0wAg4n9RKkqmGut/aZ83xtZVY7q4WE7G/quJWI78wdcRcROmStsI66p4XcoDrf+H SUF1GyHG/F05KLMVYwoNrxE5zRlqpUDw= Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 0CBA16740A0; Tue, 18 Oct 2011 12:13:45 -0700 (PDT) Received: by qadb12 with SMTP id b12so904931qad.31 for ; Tue, 18 Oct 2011 12:13:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.38.68 with SMTP id e4mr6629328pbk.126.1318965225156; Tue, 18 Oct 2011 12:13:45 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Tue, 18 Oct 2011 12:13:45 -0700 (PDT) In-Reply-To: <4A4385BFBA1BC54C863E7394BD1AECB338AACB0F@SJC-MBX-01.symmetricom.com> References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E98D17E.8000801@udel.edu> <4E9B9C12.6000505@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB8FC8B@AUSX7MCPC103.AMER.DELL.COM> <4A4385BFBA1BC54C863E7394BD1AECB338AACB0F@SJC-MBX-01.symmetricom.com> Date: Tue, 18 Oct 2011 14:13:45 -0500 Message-ID: From: Nico Williams To: Tim Frost Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "cuiyang@huawei.com" , "mayer@ntp.org" , "ipsec@ietf.org" , "TICTOC@ietf.org" , "Paul_Koning@Dell.com" , "mills@udel.edu" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 19:35:22 -0000 On Tue, Oct 18, 2011 at 10:37 AM, Tim Frost wrote: > I think most of the reviewers are missing the point of this draft. > > The point is not that the timing packets are inherently secret and need e= ncryption, but that the 3GPP architecture mandates that EVERYTHING flowing = to the femtocell must be inside a secure tunnel, whether the security is ne= eded or not. It's a wider architecture issue, not the issue about whether e= ncryption is needed and how best to do it. OK, but what's the point of WESP then? Is it simply to reduce the overhead on timing packets? Special handling of timing packets is claimed to be desired, but when I read the I-D I must have missed what the special handling was. Also, if the point can be made so succintly, then please make it so in the abstract. > The key figure from the draft is Figure 1: Doesn't help me. > The problem with this is once the packets have been encrypted, it is not = possible for the femtocell to timestamp them on reception because it doesn'= t recognise them until after decryption, which is what this draft tries to = address. OK, so you want receive time to be tracked for timing packets as soon as the NIC interrupts the CPU, but you don't want to bother with this for all packets, just timing packets. Yes? Assuming I get this, then why not write the abstract so that it says all this. E.g., something like this: This document describes how to use Wrapped Encapsulating Security Payload (WESP) to carry timing packets, such as for the Network Time Protocol (NTP), such that they be may recognized as such early on during inbound processing. This allows end-nodes to easily track the time at which timing packets are received prior to decapsulation without having to do so for all encapsulated packets. Timing packets generally bear no confidential data, which means they do not require confidentiality protection. Finally, in the interest of performance, WESP is used without having to create additional SA pairs. The fact that Femtocell is the motivator doesn't seem that interesting. If this is a problem for Femtocell it's likely to be a problem for others. > I totally agree with the comments people like Danny have made that point = out the difficulties that identifying timing packets just opens them up to = attack. However, comments attacking the rationale for encryption are wide o= f the mark - the packets are encrypted by 3GPP architecture, we have to wor= k out how to deal with that. I don't understand this comment. Are these packets encrypted, or not? > We could argue that 3GPP should never have mandated this type of architec= ture, but we would be better off arguing that at 3GPP, not here in IETF. I have no problem with the architecture. I have a problem understanding what's actually being proposed. As to what I think the proposal is, I'm not sure that it's necessary, but I also don't have any objections (assuming I did understand correctly). Nico -- From mayer@ntp.org Wed Oct 19 04:57:20 2011 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 83F9F21F8B45; Wed, 19 Oct 2011 04:57:20 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnJZ4JITsks3; Wed, 19 Oct 2011 04:57:20 -0700 (PDT) Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by ietfa.amsl.com (Postfix) with ESMTP id D522521F8B3A; Wed, 19 Oct 2011 04:57:19 -0700 (PDT) Received: from [198.22.153.6] (helo=[10.60.102.31]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RGUln-000GKj-55; Wed, 19 Oct 2011 11:57:15 +0000 Message-ID: <4E9EBB11.5090407@ntp.org> Date: Wed, 19 Oct 2011 07:57:05 -0400 From: Danny Mayer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Tim Frost References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E98D17E.8000801@udel.edu> <4E9B9C12.6000505@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB8FC8B@AUSX7MCPC103.AMER.DELL.COM> <4A4385BFBA1BC54C863E7394BD1AECB338AACB0F@SJC-MBX-01.symmetricom.com> In-Reply-To: <4A4385BFBA1BC54C863E7394BD1AECB338AACB0F@SJC-MBX-01.symmetricom.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 198.22.153.6 X-SA-Exim-Rcpt-To: tfrost@symmetricom.com, Paul_Koning@Dell.com, nico@cryptonector.com, ipsec@ietf.org, mills@udel.edu, TICTOC@ietf.org, cuiyang@huawei.com X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: "cuiyang@huawei.com" , "ipsec@ietf.org" , "TICTOC@ietf.org" , "nico@cryptonector.com" , "Paul_Koning@Dell.com" , "mills@udel.edu" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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, 19 Oct 2011 11:57:20 -0000 On 10/18/2011 11:37 AM, Tim Frost wrote: > I think most of the reviewers are missing the point of this draft. > > The point is not that the timing packets are inherently secret and need encryption, but that the 3GPP architecture mandates that EVERYTHING flowing to the femtocell must be inside a secure tunnel, whether the security is needed or not. It's a wider architecture issue, not the issue about whether encryption is needed and how best to do it. Thank you for clarifying this. This information is totally missing in the draft which should be providing a rationale for the proposal. I might argue that the 3GPP architecture is wrong when dealing with timing packets but this is the wrong forum to discuss that and that boat has probably sailed anyway. > The key figure from the draft is Figure 1: > > +-------------+ > | | > | Femtocell |<-----------------------------+ > | | | > +-------------+ | > | > | > /---------------------\ > | | > | Public Network | > | | > \---------------------/ > | > | > +------------+ +-------------+ | > |Clock Server|---------->| | | > +------------+ | | | > | Security GW |->---+ > +------------+ | | > |Femto GW |---------->| | > +------------+ +-------------+ > > > Figure 1. Typical Architecture of a Femtocell Network > > The problem with this is once the packets have been encrypted, it is not possible for the femtocell to timestamp them on reception because it doesn't recognise them until after decryption, which is what this draft tries to address. You could always timestamp all packets and then worry about whether or not you need the timestamp or is this prohibitive in cost? > > I totally agree with the comments people like Danny have made that point out the difficulties that identifying timing packets just opens them up to attack. However, comments attacking the rationale for encryption are wide of the mark - the packets are encrypted by 3GPP architecture, we have to work out how to deal with that. > The rationale was attacked because it was not spelled out in the document, it's as simple as that. The next question becomes is there a better way to accomplish the goal given the architecture? > We could argue that 3GPP should never have mandated this type of architecture, but we would be better off arguing that at 3GPP, not here in IETF. Agreed. Danny From mcr@sandelman.ca Wed Oct 19 07:00:05 2011 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 F20CD21F8C1A; Wed, 19 Oct 2011 07:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.794 X-Spam-Level: X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYmb0GPwClTe; Wed, 19 Oct 2011 07:00:04 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id D271121F8C17; Wed, 19 Oct 2011 07:00:03 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id E2D4F343A1; Wed, 19 Oct 2011 09:58:51 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 0DDA098C90; Wed, 19 Oct 2011 10:00:35 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 0A2E29817F; Wed, 19 Oct 2011 10:00:35 -0400 (EDT) From: Michael Richardson To: Kevin Gross In-Reply-To: References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB90B81@AUSX7MCPC103.AMER.DELL.COM> <09787EF419216C41A903FD14EE5506DD030CD64A86@AUSX7MCPC103.AMER.DELL.COM> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 19 Oct 2011 10:00:34 -0400 Message-ID: <16147.1319032834@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: cuiyang@huawei.com, mayer@ntp.org, ipsec@ietf.org, TICTOC@ietf.org, nico@cryptonector.com, Paul_Koning@dell.com, mills@udel.edu Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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, 19 Oct 2011 14:00:05 -0000 --=-=-= If I was an off-path attacker, and I couldn't drop your packets (but maybe I can see them), and I am not going to try to decrypt your packets, I would simply replay/make-up some packets. If I do this within the IPsec replay window, the receiving machines have to run the auth check, and so due to head-of-queue effects, the decrypt time might not be constant. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATp7YAoCLcPvd0N1lAQKLRwf+MpzfDIDJGs5Ue/X+xK0rDFRo9VuUBpMF Z70sdZXl3fTy7erF5r0OGNaWrfw4wHyzlrR/fAvWqm1u/qTQivyCM8wejjJ+0IBK F7FIGo9j8u/06qKcKkNUSDB8S0aO0Zns409YdProQb0RrDdGujwtxwkdWnAXH4mT /BHd08bp1TYOoa1d8yhRuTGITtczpUUQA4a2BqFLdj+UU94b6GwFe7F+BWkCdtvO xcfLBIaw/KWPBXB+XoYphMx+MGaQbIQPNDyUc0GH/aTAr/ivX/qnyw/L+GoJBXFv wwy7f3K8X//Qv/pIPTOwHzyQuF8pukwkQFRXSQlP9ubCO0gHo9DNJw== =tM0C -----END PGP SIGNATURE----- --=-=-=-- From mayer@ntp.org Wed Oct 19 07:53:17 2011 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 0C4C621F8AFB; Wed, 19 Oct 2011 07:53:17 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cb0SexTu2lbY; Wed, 19 Oct 2011 07:53:16 -0700 (PDT) Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8C15A21F8AF7; Wed, 19 Oct 2011 07:53:16 -0700 (PDT) Received: from [198.22.153.6] (helo=[10.60.102.31]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RGXW5-0002mg-Ab; Wed, 19 Oct 2011 14:53:14 +0000 Message-ID: <4E9EE450.9010202@ntp.org> Date: Wed, 19 Oct 2011 10:53:04 -0400 From: Danny Mayer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Kevin Gross References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 198.22.153.6 X-SA-Exim-Rcpt-To: kevin.gross@avanw.com, nico@cryptonector.com, ipsec@ietf.org, TICTOC@ietf.org, cuiyang@huawei.com, mills@udel.edu X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: "ipsec@ietf.org" , Nico Williams , "TICTOC@ietf.org" , Cui Yang , "David L. Mills" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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, 19 Oct 2011 14:53:17 -0000 On 10/18/2011 12:42 PM, Kevin Gross wrote: > It does seem reasonable to consider modeling encryption and decryption > in as part of network latency. As long as delays introduced are the same > each direction, the sync protocols will naturally subtract out this > contribution. I very much doubt that encryption and decryption take the same length of time but I'm sure people with experience with this will be able to tell us definitively. Almost certainly you will have asymmetric delays in the network path anyway even if the path is identical in both directions. Danny > Kevin Gross > > On Fri, Oct 14, 2011 at 11:25 AM, Nico Williams > wrote: > > > The cost of crypto can be measured, and performance generally > deterministic (particularly when there's no side channels in the > crypto) (assuming no mid-crypto context switches), so that it should > be possible to correct for the delays introduced by crypto (just as > it's possible to measure and estimate network latency). Indeed, > crypto processing will likely be more deterministic than network > latency :) > From btv1==2729d603e68==tfrost@symmetricom.com Tue Oct 18 08:37:45 2011 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 456D521F8B8C for ; Tue, 18 Oct 2011 08:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1DdDj+jZmmE for ; Tue, 18 Oct 2011 08:37:44 -0700 (PDT) Received: from mail5.symmetricom.com (mail5.symmetricom.com [69.25.98.10]) by ietfa.amsl.com (Postfix) with ESMTP id C78C821F8B86 for ; Tue, 18 Oct 2011 08:37:44 -0700 (PDT) X-ASG-Debug-ID: 1318952262-11aa8ea90001-2ho77O Received: from SJC-HUB-01.symmetricom.com ([192.168.10.171]) by mail5.symmetricom.com with ESMTP id jH0UkAMaOgJlYbgk; Tue, 18 Oct 2011 08:37:42 -0700 (PDT) X-Barracuda-Envelope-From: tfrost@symmetricom.com Received: from SJC-MBX-01.symmetricom.com ([169.254.1.221]) by SJC-HUB-01.symmetricom.com ([::1]) with mapi id 14.01.0289.001; Tue, 18 Oct 2011 08:37:41 -0700 From: Tim Frost To: "Paul_Koning@Dell.com" , "mayer@ntp.org" , "nico@cryptonector.com" Thread-Topic: [TICTOC] [IPsec] Review request for IPsec security for packet based synchronization (Yang Cui) X-ASG-Orig-Subj: RE: [TICTOC] [IPsec] Review request for IPsec security for packet based synchronization (Yang Cui) Thread-Index: AcyMeg1KeeB0+xx5Q9uX8lZCIlZnnAAQAAFwADwZDdA= Date: Tue, 18 Oct 2011 15:37:40 +0000 Message-ID: <4A4385BFBA1BC54C863E7394BD1AECB338AACB0F@SJC-MBX-01.symmetricom.com> References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E98D17E.8000801@udel.edu> <4E9B9C12.6000505@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB8FC8B@AUSX7MCPC103.AMER.DELL.COM> In-Reply-To: <09787EF419216C41A903FD14EE5506DD030CB8FC8B@AUSX7MCPC103.AMER.DELL.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.7.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[192.168.10.171] X-Barracuda-Start-Time: 1318952262 X-Barracuda-URL: http://192.168.10.96:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at symmetricom.com X-Barracuda-Spam-Score: -1002.00 X-Barracuda-Spam-Status: No, SCORE=-1002.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 X-Mailman-Approved-At: Wed, 19 Oct 2011 08:27:43 -0700 Cc: "ipsec@ietf.org" , "TICTOC@ietf.org" , "cuiyang@huawei.com" , "mills@udel.edu" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 15:52:46 -0000 I think most of the reviewers are missing the point of this draft. The point is not that the timing packets are inherently secret and need enc= ryption, but that the 3GPP architecture mandates that EVERYTHING flowing to= the femtocell must be inside a secure tunnel, whether the security is need= ed or not. It's a wider architecture issue, not the issue about whether enc= ryption is needed and how best to do it. The key figure from the draft is Figure 1: +-------------+ | | | Femtocell |<-----------------------------+ | | | +-------------+ | | | /---------------------\ | | | Public Network | | | \---------------------/ | | +------------+ +-------------+ | |Clock Server|---------->| | | +------------+ | | | | Security GW |->---+ +------------+ | | |Femto GW |---------->| | +------------+ +-------------+ Figure 1. Typical Architecture of a Femtocell Network The problem with this is once the packets have been encrypted, it is not po= ssible for the femtocell to timestamp them on reception because it doesn't = recognise them until after decryption, which is what this draft tries to ad= dress. I totally agree with the comments people like Danny have made that point ou= t the difficulties that identifying timing packets just opens them up to at= tack. However, comments attacking the rationale for encryption are wide of = the mark - the packets are encrypted by 3GPP architecture, we have to work = out how to deal with that. We could argue that 3GPP should never have mandated this type of architectu= re, but we would be better off arguing that at 3GPP, not here in IETF. Tim -----Original Message----- From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of= Paul_Koning@Dell.com Sent: 17 October 2011 11:49 To: mayer@ntp.org; nico@cryptonector.com Cc: ipsec@ietf.org; mills@udel.edu; TICTOC@ietf.org; cuiyang@huawei.com Subject: Re: [TICTOC] [IPsec] Review request for IPsec security for packet = based synchronization (Yang Cui) >I cannot answer for the performance but if I was worried about making sure= I got the correct time I'd be more likely to be concerned about authentica= ting the server than encrypting the contents. Encryption doesn't do a thing= for ensuring you got a valid packet. You don't need data confidentiality, but you do need data integrity and ant= i-replay, both of which you get from the integrity part of IPSec. This is= a place where the integrity-only cipher suites are applicable. paul _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc From btv1==2733b651656==tfrost@symmetricom.com Wed Oct 19 03:27:02 2011 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 8375521F8B45 for ; Wed, 19 Oct 2011 03:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORSEATG30jQg for ; Wed, 19 Oct 2011 03:27:02 -0700 (PDT) Received: from mail5.symmetricom.com (mail5.symmetricom.com [69.25.98.10]) by ietfa.amsl.com (Postfix) with ESMTP id E780D21F8AA8 for ; Wed, 19 Oct 2011 03:27:01 -0700 (PDT) X-ASG-Debug-ID: 1319020020-11aa9fff0001-2ho77O Received: from SJC-HUB-01.symmetricom.com ([192.168.10.171]) by mail5.symmetricom.com with ESMTP id RZm37Gc1E17a5yTV; Wed, 19 Oct 2011 03:27:00 -0700 (PDT) X-Barracuda-Envelope-From: tfrost@symmetricom.com Received: from SJC-MBX-01.symmetricom.com ([169.254.1.221]) by SJC-HUB-01.symmetricom.com ([::1]) with mapi id 14.01.0289.001; Wed, 19 Oct 2011 03:27:00 -0700 From: Tim Frost To: Nico Williams Thread-Topic: [TICTOC] [IPsec] Review request for IPsec security for packet based synchronization (Yang Cui) X-ASG-Orig-Subj: RE: [TICTOC] [IPsec] Review request for IPsec security for packet based synchronization (Yang Cui) Thread-Index: AcyMeg1KeeB0+xx5Q9uX8lZCIlZnnAAQAAFwADwZDdAAFpJLgAAODb9w Date: Wed, 19 Oct 2011 10:26:58 +0000 Message-ID: <4A4385BFBA1BC54C863E7394BD1AECB338AACF66@SJC-MBX-01.symmetricom.com> References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E98D17E.8000801@udel.edu> <4E9B9C12.6000505@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB8FC8B@AUSX7MCPC103.AMER.DELL.COM> <4A4385BFBA1BC54C863E7394BD1AECB338AACB0F@SJC-MBX-01.symmetricom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.7.33] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[192.168.10.171] X-Barracuda-Start-Time: 1319020020 X-Barracuda-URL: http://192.168.10.96:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at symmetricom.com X-Barracuda-Spam-Score: -1002.00 X-Barracuda-Spam-Status: No, SCORE=-1002.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 X-Mailman-Approved-At: Wed, 19 Oct 2011 08:27:43 -0700 Cc: "cuiyang@huawei.com" , "mayer@ntp.org" , "ipsec@ietf.org" , "TICTOC@ietf.org" , "Paul_Koning@Dell.com" , "mills@udel.edu" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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, 19 Oct 2011 10:41:47 -0000 TmljbywNCg0KSSBhbSBub3QgYW4gYXV0aG9yIG9mIHRoaXMgZHJhZnQsIHNvIEkgZG9uJ3QgcHJv cG9zZSB0byBkZWZlbmQgdGhlIGNvbnRlbnRzLiBJIHdhcyBtZXJlbHkgcG9pbnRpbmcgb3V0IHRo YXQgdGhvc2UgcGVvcGxlIGNyaXRpY2l6aW5nIGl0IG9uIHRoZSBiYXNpcyB0aGF0IGVuY3J5cHRp b24gb2YgdGltaW5nIHBhY2tldHMgd2FzIHVubmVjZXNzYXJ5IHdlcmUgbWlzc2luZyB0aGUgcG9p bnQsIHdoaWNoIHdhcyB0aGF0IHRpbWluZyBwYWNrZXRzIGFyZSBlbmNyeXB0ZWQgYmVjYXVzZSB0 aGUgM0dQUCBhcmNoaXRlY3R1cmUgc2F5cyB0aGV5IG11c3QgYmUsIHNvIHdlIGhhdmUgdG8gd29y ayBvdXQgaG93IHRvIGRlYWwgd2l0aCB0aGF0Lg0KDQpJIHRoaW5rIHlvdXIgcmV2aXNlZCBhYnN0 cmFjdCBpcyBnb29kIGFuZCBleHBsYWlucyB0aGUgcG9pbnQgY2xlYXJseTsgSSB3b3VsZCByZWNv bW1lbmQgdGhhdCB0aGUgYXV0aG9ycyB0YWtlIG5vdGUgb2YgdGhpcyBpbiB0aGUgbmV4dCByZXZp c2lvbi4NCg0KVGltDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE5pY28g V2lsbGlhbXMgW21haWx0bzpuaWNvQGNyeXB0b25lY3Rvci5jb21dIA0KU2VudDogMTggT2N0b2Jl ciAyMDExIDIwOjE0DQpUbzogVGltIEZyb3N0DQpDYzogUGF1bF9Lb25pbmdARGVsbC5jb207IG1h eWVyQG50cC5vcmc7IGlwc2VjQGlldGYub3JnOyBtaWxsc0B1ZGVsLmVkdTsgVElDVE9DQGlldGYu b3JnOyBjdWl5YW5nQGh1YXdlaS5jb20NClN1YmplY3Q6IFJlOiBbVElDVE9DXSBbSVBzZWNdIFJl dmlldyByZXF1ZXN0IGZvciBJUHNlYyBzZWN1cml0eSBmb3IgcGFja2V0IGJhc2VkIHN5bmNocm9u aXphdGlvbiAoWWFuZyBDdWkpDQoNCk9uIFR1ZSwgT2N0IDE4LCAyMDExIGF0IDEwOjM3IEFNLCBU aW0gRnJvc3QgPHRmcm9zdEBzeW1tZXRyaWNvbS5jb20+IHdyb3RlOg0KPiBJIHRoaW5rIG1vc3Qg b2YgdGhlIHJldmlld2VycyBhcmUgbWlzc2luZyB0aGUgcG9pbnQgb2YgdGhpcyBkcmFmdC4NCj4N Cj4gVGhlIHBvaW50IGlzIG5vdCB0aGF0IHRoZSB0aW1pbmcgcGFja2V0cyBhcmUgaW5oZXJlbnRs eSBzZWNyZXQgYW5kIG5lZWQgZW5jcnlwdGlvbiwgYnV0IHRoYXQgdGhlIDNHUFAgYXJjaGl0ZWN0 dXJlIG1hbmRhdGVzIHRoYXQgRVZFUllUSElORyBmbG93aW5nIHRvIHRoZSBmZW10b2NlbGwgbXVz dCBiZSBpbnNpZGUgYSBzZWN1cmUgdHVubmVsLCB3aGV0aGVyIHRoZSBzZWN1cml0eSBpcyBuZWVk ZWQgb3Igbm90LiBJdCdzIGEgd2lkZXIgYXJjaGl0ZWN0dXJlIGlzc3VlLCBub3QgdGhlIGlzc3Vl IGFib3V0IHdoZXRoZXIgZW5jcnlwdGlvbiBpcyBuZWVkZWQgYW5kIGhvdyBiZXN0IHRvIGRvIGl0 Lg0KDQpPSywgYnV0IHdoYXQncyB0aGUgcG9pbnQgb2YgV0VTUCB0aGVuPyAgSXMgaXQgc2ltcGx5 IHRvIHJlZHVjZSB0aGUNCm92ZXJoZWFkIG9uIHRpbWluZyBwYWNrZXRzPyAgU3BlY2lhbCBoYW5k bGluZyBvZiB0aW1pbmcgcGFja2V0cyBpcw0KY2xhaW1lZCB0byBiZSBkZXNpcmVkLCBidXQgd2hl biBJIHJlYWQgdGhlIEktRCBJIG11c3QgaGF2ZSBtaXNzZWQgd2hhdA0KdGhlIHNwZWNpYWwgaGFu ZGxpbmcgd2FzLg0KDQpBbHNvLCBpZiB0aGUgcG9pbnQgY2FuIGJlIG1hZGUgc28gc3VjY2ludGx5 LCB0aGVuIHBsZWFzZSBtYWtlIGl0IHNvIGluDQp0aGUgYWJzdHJhY3QuDQoNCj4gVGhlIGtleSBm aWd1cmUgZnJvbSB0aGUgZHJhZnQgaXMgRmlndXJlIDE6DQoNCkRvZXNuJ3QgaGVscCBtZS4NCg0K PiBUaGUgcHJvYmxlbSB3aXRoIHRoaXMgaXMgb25jZSB0aGUgcGFja2V0cyBoYXZlIGJlZW4gZW5j cnlwdGVkLCBpdCBpcyBub3QgcG9zc2libGUgZm9yIHRoZSBmZW10b2NlbGwgdG8gdGltZXN0YW1w IHRoZW0gb24gcmVjZXB0aW9uIGJlY2F1c2UgaXQgZG9lc24ndCByZWNvZ25pc2UgdGhlbSB1bnRp bCBhZnRlciBkZWNyeXB0aW9uLCB3aGljaCBpcyB3aGF0IHRoaXMgZHJhZnQgdHJpZXMgdG8gYWRk cmVzcy4NCg0KT0ssIHNvIHlvdSB3YW50IHJlY2VpdmUgdGltZSB0byBiZSB0cmFja2VkIGZvciB0 aW1pbmcgcGFja2V0cyBhcyBzb29uDQphcyB0aGUgTklDIGludGVycnVwdHMgdGhlIENQVSwgYnV0 IHlvdSBkb24ndCB3YW50IHRvIGJvdGhlciB3aXRoIHRoaXMNCmZvciBhbGwgcGFja2V0cywganVz dCB0aW1pbmcgcGFja2V0cy4gIFllcz8NCg0KQXNzdW1pbmcgSSBnZXQgdGhpcywgdGhlbiB3aHkg bm90IHdyaXRlIHRoZSBhYnN0cmFjdCBzbyB0aGF0IGl0IHNheXMNCmFsbCB0aGlzLiAgRS5nLiwg c29tZXRoaW5nIGxpa2UgdGhpczoNCg0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IHRv IHVzZSBXcmFwcGVkIEVuY2Fwc3VsYXRpbmcgU2VjdXJpdHkNClBheWxvYWQgKFdFU1ApIHRvIGNh cnJ5IHRpbWluZyBwYWNrZXRzLCBzdWNoIGFzIGZvciB0aGUgTmV0d29yayBUaW1lDQpQcm90b2Nv bCAoTlRQKSwgc3VjaCB0aGF0IHRoZXkgYmUgbWF5IHJlY29nbml6ZWQgYXMgc3VjaCBlYXJseSBv bg0KZHVyaW5nIGluYm91bmQgcHJvY2Vzc2luZy4gIFRoaXMgYWxsb3dzIGVuZC1ub2RlcyB0byBl YXNpbHkgdHJhY2sgdGhlDQp0aW1lIGF0IHdoaWNoIHRpbWluZyBwYWNrZXRzIGFyZSByZWNlaXZl ZCBwcmlvciB0byBkZWNhcHN1bGF0aW9uDQp3aXRob3V0IGhhdmluZyB0byBkbyBzbyBmb3IgYWxs IGVuY2Fwc3VsYXRlZCBwYWNrZXRzLiAgVGltaW5nIHBhY2tldHMNCmdlbmVyYWxseSBiZWFyIG5v IGNvbmZpZGVudGlhbCBkYXRhLCB3aGljaCBtZWFucyB0aGV5IGRvIG5vdCByZXF1aXJlDQpjb25m aWRlbnRpYWxpdHkgcHJvdGVjdGlvbi4gIEZpbmFsbHksIGluIHRoZSBpbnRlcmVzdCBvZiBwZXJm b3JtYW5jZSwNCldFU1AgaXMgdXNlZCB3aXRob3V0IGhhdmluZyB0byBjcmVhdGUgYWRkaXRpb25h bCBTQSBwYWlycy4NCg0KVGhlIGZhY3QgdGhhdCBGZW10b2NlbGwgaXMgdGhlIG1vdGl2YXRvciBk b2Vzbid0IHNlZW0gdGhhdA0KaW50ZXJlc3RpbmcuICBJZiB0aGlzIGlzIGEgcHJvYmxlbSBmb3Ig RmVtdG9jZWxsIGl0J3MgbGlrZWx5IHRvIGJlIGENCnByb2JsZW0gZm9yIG90aGVycy4NCg0KPiBJ IHRvdGFsbHkgYWdyZWUgd2l0aCB0aGUgY29tbWVudHMgcGVvcGxlIGxpa2UgRGFubnkgaGF2ZSBt YWRlIHRoYXQgcG9pbnQgb3V0IHRoZSBkaWZmaWN1bHRpZXMgdGhhdCBpZGVudGlmeWluZyB0aW1p bmcgcGFja2V0cyBqdXN0IG9wZW5zIHRoZW0gdXAgdG8gYXR0YWNrLiBIb3dldmVyLCBjb21tZW50 cyBhdHRhY2tpbmcgdGhlIHJhdGlvbmFsZSBmb3IgZW5jcnlwdGlvbiBhcmUgd2lkZSBvZiB0aGUg bWFyayAtIHRoZSBwYWNrZXRzIGFyZSBlbmNyeXB0ZWQgYnkgM0dQUCBhcmNoaXRlY3R1cmUsIHdl IGhhdmUgdG8gd29yayBvdXQgaG93IHRvIGRlYWwgd2l0aCB0aGF0Lg0KDQpJIGRvbid0IHVuZGVy c3RhbmQgdGhpcyBjb21tZW50LiAgQXJlIHRoZXNlIHBhY2tldHMgZW5jcnlwdGVkLCBvciBub3Q/ DQoNCj4gV2UgY291bGQgYXJndWUgdGhhdCAzR1BQIHNob3VsZCBuZXZlciBoYXZlIG1hbmRhdGVk IHRoaXMgdHlwZSBvZiBhcmNoaXRlY3R1cmUsIGJ1dCB3ZSB3b3VsZCBiZSBiZXR0ZXIgb2ZmIGFy Z3VpbmcgdGhhdCBhdCAzR1BQLCBub3QgaGVyZSBpbiBJRVRGLg0KDQpJIGhhdmUgbm8gcHJvYmxl bSB3aXRoIHRoZSBhcmNoaXRlY3R1cmUuICBJIGhhdmUgYSBwcm9ibGVtDQp1bmRlcnN0YW5kaW5n IHdoYXQncyBhY3R1YWxseSBiZWluZyBwcm9wb3NlZC4gIEFzIHRvIHdoYXQgSSB0aGluayB0aGUN CnByb3Bvc2FsIGlzLCBJJ20gbm90IHN1cmUgdGhhdCBpdCdzIG5lY2Vzc2FyeSwgYnV0IEkgYWxz byBkb24ndCBoYXZlDQphbnkgb2JqZWN0aW9ucyAoYXNzdW1pbmcgSSBkaWQgdW5kZXJzdGFuZCBj b3JyZWN0bHkpLg0KDQpOaWNvDQotLQ0K From manav.bhatia@alcatel-lucent.com Wed Oct 19 04:51:56 2011 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 7F3A521F8B3F; Wed, 19 Oct 2011 04:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.774 X-Spam-Level: X-Spam-Status: No, score=-6.774 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w54w-3ArOO1P; Wed, 19 Oct 2011 04:51:55 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id AB09F21F8B70; Wed, 19 Oct 2011 04:51:55 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p9JBowe0016312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Oct 2011 06:51:01 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p9JBout6019220 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Oct 2011 17:20:56 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.59]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 19 Oct 2011 17:20:56 +0530 From: "Bhatia, Manav (Manav)" To: Tim Frost , Nico Williams Date: Wed, 19 Oct 2011 17:20:54 +0530 Thread-Topic: [TICTOC] [IPsec] Review request for IPsec security for packet based synchronization (Yang Cui) Thread-Index: AcyMeg1KeeB0+xx5Q9uX8lZCIlZnnAAQAAFwADwZDdAAFpJLgAAODb9wAAWF3SA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350D007ABB04@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E98D17E.8000801@udel.edu> <4E9B9C12.6000505@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB8FC8B@AUSX7MCPC103.AMER.DELL.COM> <4A4385BFBA1BC54C863E7394BD1AECB338AACB0F@SJC-MBX-01.symmetricom.com> <4A4385BFBA1BC54C863E7394BD1AECB338AACF66@SJC-MBX-01.symmetricom.com> In-Reply-To: <4A4385BFBA1BC54C863E7394BD1AECB338AACF66@SJC-MBX-01.symmetricom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Mailman-Approved-At: Wed, 19 Oct 2011 08:27:43 -0700 Cc: "ipsec@ietf.org" , "Paul_Koning@Dell.com" , "TICTOC@ietf.org" , "cuiyang@huawei.com" , "mills@udel.edu" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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, 19 Oct 2011 11:51:56 -0000 Hi, I had spoken to one of the initial authors of this IPsec draft and I was to= ld that setting up an Ipsec tunnel exclusively for shipping 1588 may not be= possible in the femto architecture. They are thus trying to use WESP (that= I have co-authored) to identify 1588 packets within an IPSec stream. I have tried to describe the problem that this draft is attempting to addre= ss here: http://www.ietf.org/mail-archive/web/tictoc/current/msg00755.html As an author of WESP I can say that the way this draft uses WESP to protect= 1588 is not very appropriate. The draft tries to add some additional ident= ifiers in each protocol packet to uniquely identify 1588 packets. This in t= he security land will not be accepted as anybody snooping on the wire will = be easily able to disambiguate 1588 packets from other packets in the strea= m. If the authors want to use WESP then they must negotiate this unique ID = (or a set of IDs) in IKE and pad the packets randomly so that the attackers= cant identify the 1588 packets in the Ipsec stream. Cheers, Manav > -----Original Message----- > From: tictoc-bounces@ietf.org=20 > [mailto:tictoc-bounces@ietf.org] On Behalf Of Tim Frost > Sent: Wednesday, October 19, 2011 3:57 PM > To: Nico Williams > Cc: cuiyang@huawei.com; ipsec@ietf.org; TICTOC@ietf.org;=20 > Paul_Koning@Dell.com; mills@udel.edu > Subject: Re: [TICTOC] [IPsec] Review request for IPsec=20 > security for packet based synchronization (Yang Cui) >=20 > Nico, >=20 > I am not an author of this draft, so I don't propose to=20 > defend the contents. I was merely pointing out that those=20 > people criticizing it on the basis that encryption of timing=20 > packets was unnecessary were missing the point, which was=20 > that timing packets are encrypted because the 3GPP=20 > architecture says they must be, so we have to work out how to=20 > deal with that. >=20 > I think your revised abstract is good and explains the point=20 > clearly; I would recommend that the authors take note of this=20 > in the next revision. >=20 > Tim >=20 >=20 > -----Original Message----- > From: Nico Williams [mailto:nico@cryptonector.com] > Sent: 18 October 2011 20:14 > To: Tim Frost > Cc: Paul_Koning@Dell.com; mayer@ntp.org; ipsec@ietf.org;=20 > mills@udel.edu; TICTOC@ietf.org; cuiyang@huawei.com > Subject: Re: [TICTOC] [IPsec] Review request for IPsec=20 > security for packet based synchronization (Yang Cui) >=20 > On Tue, Oct 18, 2011 at 10:37 AM, Tim Frost=20 > wrote: > > I think most of the reviewers are missing the point of this draft. > > > > The point is not that the timing packets are inherently=20 > secret and need encryption, but that the 3GPP architecture=20 > mandates that EVERYTHING flowing to the femtocell must be=20 > inside a secure tunnel, whether the security is needed or=20 > not. It's a wider architecture issue, not the issue about=20 > whether encryption is needed and how best to do it. >=20 > OK, but what's the point of WESP then? Is it simply to=20 > reduce the overhead on timing packets? Special handling of=20 > timing packets is claimed to be desired, but when I read the=20 > I-D I must have missed what the special handling was. >=20 > Also, if the point can be made so succintly, then please make=20 > it so in the abstract. >=20 > > The key figure from the draft is Figure 1: >=20 > Doesn't help me. >=20 > > The problem with this is once the packets have been=20 > encrypted, it is not possible for the femtocell to timestamp=20 > them on reception because it doesn't recognise them until=20 > after decryption, which is what this draft tries to address. >=20 > OK, so you want receive time to be tracked for timing packets=20 > as soon as the NIC interrupts the CPU, but you don't want to=20 > bother with this for all packets, just timing packets. Yes? >=20 > Assuming I get this, then why not write the abstract so that=20 > it says all this. E.g., something like this: >=20 > This document describes how to use Wrapped Encapsulating=20 > Security Payload (WESP) to carry timing packets, such as for=20 > the Network Time Protocol (NTP), such that they be may=20 > recognized as such early on during inbound processing. This=20 > allows end-nodes to easily track the time at which timing=20 > packets are received prior to decapsulation without having to=20 > do so for all encapsulated packets. Timing packets generally=20 > bear no confidential data, which means they do not require=20 > confidentiality protection. Finally, in the interest of=20 > performance, WESP is used without having to create additional=20 > SA pairs. >=20 > The fact that Femtocell is the motivator doesn't seem that=20 > interesting. If this is a problem for Femtocell it's likely=20 > to be a problem for others. >=20 > > I totally agree with the comments people like Danny have=20 > made that point out the difficulties that identifying timing=20 > packets just opens them up to attack. However, comments=20 > attacking the rationale for encryption are wide of the mark -=20 > the packets are encrypted by 3GPP architecture, we have to=20 > work out how to deal with that. >=20 > I don't understand this comment. Are these packets encrypted, or not? >=20 > > We could argue that 3GPP should never have mandated this=20 > type of architecture, but we would be better off arguing that=20 > at 3GPP, not here in IETF. >=20 > I have no problem with the architecture. I have a problem=20 > understanding what's actually being proposed. As to what I=20 > think the proposal is, I'm not sure that it's necessary, but=20 > I also don't have any objections (assuming I did understand=20 > correctly). >=20 > Nico > -- > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > = From nico@cryptonector.com Wed Oct 19 08:41:46 2011 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 D133921F8B6D; Wed, 19 Oct 2011 08:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0Ic2oRa0j-V; Wed, 19 Oct 2011 08:41:46 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3051F21F8B62; Wed, 19 Oct 2011 08:41:46 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 8A48F36006A; Wed, 19 Oct 2011 08:41:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=Ls/iLOHnuHqEo7vBJUv9o Z1Rwek/jzdUgtZrWFYCuTLwlPF0lKJV94xEQZltBTlPdYQYJRBqQHKPP3cIgAqNN opfufjIgcdpOjBpjQsfH/oZnb9QR1AArf9ZZw/IZCh7JuSxXaXaaq4w1Av/ktwLM u7/9Ux6jL29U2MbYZgOTiU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=K41Sv8vhAMcQVpzOYUTn zOBbU80=; b=Z0E1PQ+FP155FiNsaHe7XqfW6cTEkBUc0rCKqjJxqpsLn9xhZyRr rqD1q+gEw2h1xe9u28UXBX+5fARMlsTqdsL9a5KFsex+/YZIX/MIoqq81h78Issh 2PlvIX5qUDgtwn2K0NkczixBaBhOdIjTscv5w6Q79E9m622o3FmqFEo= Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 557E6360065; Wed, 19 Oct 2011 08:41:45 -0700 (PDT) Received: by pzk34 with SMTP id 34so4810719pzk.9 for ; Wed, 19 Oct 2011 08:41:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.24.200 with SMTP id w8mr13315862pbf.109.1319038904756; Wed, 19 Oct 2011 08:41:44 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Wed, 19 Oct 2011 08:41:44 -0700 (PDT) In-Reply-To: <4E9EBB11.5090407@ntp.org> References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E98D17E.8000801@udel.edu> <4E9B9C12.6000505@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB8FC8B@AUSX7MCPC103.AMER.DELL.COM> <4A4385BFBA1BC54C863E7394BD1AECB338AACB0F@SJC-MBX-01.symmetricom.com> <4E9EBB11.5090407@ntp.org> Date: Wed, 19 Oct 2011 10:41:44 -0500 Message-ID: From: Nico Williams To: Danny Mayer Content-Type: text/plain; charset=UTF-8 Cc: "cuiyang@huawei.com" , "ipsec@ietf.org" , Tim Frost , "TICTOC@ietf.org" , "Paul_Koning@Dell.com" , "mills@udel.edu" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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, 19 Oct 2011 15:41:46 -0000 On Wed, Oct 19, 2011 at 6:57 AM, Danny Mayer wrote: >> The problem with this is once the packets have been encrypted, it is >> not possible for the femtocell to timestamp them on reception because it >> doesn't recognise them until after decryption, which is what this draft >> tries to address. > > You could always timestamp all packets and then worry about whether or > not you need the timestamp or is this prohibitive in cost? That's my take as well. If you can timestamp some packets, you can timestamp them all. Perhaps the reading of a hi-res timer is a slow operation, or perhaps it can have deleterious effects. For example, a hi-res timer might be available only w/o reference to a single clock, with each hi-res timer being CPU core-/thread-specific, in which case the system would have to arrange for the packet to continue to be processed on the same core/thread even if it'd be better not to for other reasons. Modern CPUs can count CPU cycles though, which can be used as a good proxy for hi-res timers for relatively short runs of code, but perhaps tracking CPU cycles used to process a packet might require extensive changes to an implementation. Or perhaps some femtocells are implemented almost entirely in HW whose architecture makes it expensive to timestamp every packet. Details would be nice. As it becomes clear that this proposal is really a case of allowing local limitations of *some* implementations (possibly not even real limitations; details are missing, so we can't tell for sure) to bleed into protocol architecture, I'm now much more in the "this is not a good idea" camp. It might yet turn out that these limitations are much more universal than I imagine though. >> I totally agree with the comments people like Danny have made that > point out the difficulties that identifying timing packets just opens > them up to attack. However, comments attacking the rationale for > encryption are wide of the mark - the packets are encrypted by 3GPP > architecture, we have to work out how to deal with that. > > The rationale was attacked because it was not spelled out in the > document, it's as simple as that. The next question becomes is there a > better way to accomplish the goal given the architecture? I second this. The draft wasn't ready for review by the IPsec list. The result was bound to be either silence or skepticism. Nico -- From kent@bbn.com Wed Oct 19 08:54:27 2011 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 1D99121F8C2F; Wed, 19 Oct 2011 08:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WofYvml2l+9H; Wed, 19 Oct 2011 08:54:26 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9976C21F85A4; Wed, 19 Oct 2011 08:54:26 -0700 (PDT) Received: from [192.1.255.173] (port=49204) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RGYT9-000Ews-Mo; Wed, 19 Oct 2011 11:54:15 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4E9EE450.9010202@ntp.org> References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E9EE450.9010202@ntp.org> Date: Wed, 19 Oct 2011 11:53:37 -0400 To: Danny Mayer From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Cui Yang , Kevin Gross , "ipsec@ietf.org" , "TICTOC@ietf.org" , Nico Williams , "David L. Mills" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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, 19 Oct 2011 15:54:27 -0000 At 10:53 AM -0400 10/19/11, Danny Mayer wrote: >On 10/18/2011 12:42 PM, Kevin Gross wrote: >> It does seem reasonable to consider modeling encryption and decryption >> in as part of network latency. As long as delays introduced are the same >> each direction, the sync protocols will naturally subtract out this >> contribution. > >I very much doubt that encryption and decryption take the same length of >time but I'm sure people with experience with this will be able to tell >us definitively. Almost certainly you will have asymmetric delays in the >network path anyway even if the path is identical in both directions. > >Danny For most symmetric algs, and many modes of use, the times are the same. The timing tend to differ for asymmetric algs. Steve From mayer@ntp.org Wed Oct 19 13:31:28 2011 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 8731721F8AFC; Wed, 19 Oct 2011 13:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GV6jIObyFIVN; Wed, 19 Oct 2011 13:31:28 -0700 (PDT) Received: from mx04.gis.net (mx04.gis.net [208.218.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id B933421F8AFD; Wed, 19 Oct 2011 13:31:27 -0700 (PDT) Received: from [10.60.102.31] ([198.22.153.6]) by mx04.gis.net; Wed, 19 Oct 2011 16:31:09 -0400 Message-ID: <4E9F338B.3060703@ntp.org> Date: Wed, 19 Oct 2011 16:31:07 -0400 From: Danny Mayer Organization: NTP User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Paul_Koning@Dell.com References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB90B81@AUSX7MCPC103.AMER.DELL.COM> <09787EF419216C41A903FD14EE5506DD030CD64A86@AUSX7MCPC103.AMER.DELL.COM> In-Reply-To: <09787EF419216C41A903FD14EE5506DD030CD64A86@AUSX7MCPC103.AMER.DELL.COM> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: cuiyang@huawei.com, kevin.gross@avanw.com, ipsec@ietf.org, TICTOC@ietf.org, nico@cryptonector.com, mills@udel.edu Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mayer@ntp.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 20:31:28 -0000 On 10/18/2011 2:16 PM, Paul_Koning@Dell.com wrote: > Absolutely. But if you allow, say, one second round trip time, you have > to assume that your time is off by that amount from the master. No, half that amount. Round trip means exactly that! In an > environment without active attackers you would assume that the error is > a fair amount smaller, basically the estimate of the difference between > the two legs of the trip plus some allowance for jitter. If you > introduce attackers, you might have an underlying network that offers > near-zero latency, and all the latency you’re seeing is due to active > attack on one or the other legs of the round trip. > I doubt that the interference would be that close and you certainly cannot count on that. Danny From nico@cryptonector.com Wed Oct 19 14:12:33 2011 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 8049F21F8A62; Wed, 19 Oct 2011 14:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYJj6xJACCx1; Wed, 19 Oct 2011 14:12:32 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id BDA5D21F8A58; Wed, 19 Oct 2011 14:12:32 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 729212AC064; Wed, 19 Oct 2011 14:12:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=wpQaCzyxHEhw8ivIIEAFN435b4WSQJzOHFhzaYKqSjIE uqBWvN8G05RfYSsB1VDbJvt142lqKwVFp5PQyxH9npwTV/v3IiscGUXzzTocpQkV S3pKBeOT04Wiu+ce95c/H2O6Uf8JRrdSC5RJ209lM5bxmFsvqMvXOUJMdoGk3X8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=o4FlSCQaDdgNMI00AIcky/Vf4Uo=; b=d/K3f2zYSql LFmpih10Vc92dZ6JUBduaRNaMXkOhTCEPWY+x4DIfydW2jAnu7idmAvaeOXe4DFP 8NcA3t/dbXK53Z5wDOAtbGkRtCC3N9/joz4V989yPpMO42FHJudGuWjnp63tBt8V eSjE0Mat2+A4pysLkn6xNgpzA6z/D63g= Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 4D35A2AC05E; Wed, 19 Oct 2011 14:12:32 -0700 (PDT) Received: by pzk34 with SMTP id 34so5568273pzk.9 for ; Wed, 19 Oct 2011 14:12:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.31.131 with SMTP id a3mr14969647pbi.24.1319058751943; Wed, 19 Oct 2011 14:12:31 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Wed, 19 Oct 2011 14:12:31 -0700 (PDT) In-Reply-To: <4E9F338B.3060703@ntp.org> References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB90B81@AUSX7MCPC103.AMER.DELL.COM> <09787EF419216C41A903FD14EE5506DD030CD64A86@AUSX7MCPC103.AMER.DELL.COM> <4E9F338B.3060703@ntp.org> Date: Wed, 19 Oct 2011 16:12:31 -0500 Message-ID: From: Nico Williams To: mayer@ntp.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: cuiyang@huawei.com, kevin.gross@avanw.com, ipsec@ietf.org, TICTOC@ietf.org, Paul_Koning@dell.com, mills@udel.edu Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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, 19 Oct 2011 21:12:33 -0000 On Wed, Oct 19, 2011 at 3:31 PM, Danny Mayer wrote: > On 10/18/2011 2:16 PM, Paul_Koning@Dell.com wrote: >> Absolutely. =C2=A0But if you allow, say, one second round trip time, you= have >> to assume that your time is off by that amount from the master. > > No, half that amount. Round trip means exactly that! You're assuming symmetric routing... From Paul_Koning@Dell.com Wed Oct 19 18:14:59 2011 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 4FB2E1F0C41; Wed, 19 Oct 2011 18:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.593 X-Spam-Level: X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0GBd5wE3zKd; Wed, 19 Oct 2011 18:14:58 -0700 (PDT) Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) by ietfa.amsl.com (Postfix) with ESMTP id BC5C51F0C36; Wed, 19 Oct 2011 18:14:58 -0700 (PDT) X-Loopcount0: from 10.170.28.39 From: To: , Date: Wed, 19 Oct 2011 20:14:39 -0500 Thread-Topic: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) Thread-Index: AcyOo9bbpLh8en2MTu21TDQ10CijNgAIaFdw Message-ID: <09787EF419216C41A903FD14EE5506DD030CD659B5@AUSX7MCPC103.AMER.DELL.COM> References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB90B81@AUSX7MCPC103.AMER.DELL.COM> <09787EF419216C41A903FD14EE5506DD030CD64A86@AUSX7MCPC103.AMER.DELL.COM> <4E9F338B.3060703@ntp.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: ipsec@ietf.org, mills@udel.edu, TICTOC@ietf.org, kevin.gross@avanw.com, cuiyang@huawei.com Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 01:14:59 -0000 SSB0aGluayBEYW5ueSBpcyByaWdodDogaWYgdGhlIHJvdW5kIHRyaXAgdGltZSBpcyAxIHNlY29u ZCwgYW5kIHlvdSBwaWNrIHRoZSBtaWRwb2ludCBhcyB0aGUgb3V0Y29tZSBvZiB0aGUgc3luYyBw cm9jZXNzLCB5b3UncmUgb2ZmIGF0IG1vc3QgcGx1cyBvciBtaW51cyBoYWxmIGEgc2Vjb25kLiAg SSB3YXMgbWl4aW5nIHVwIHRoZSBlcnJvciBib3VuZCB3aXRoIHRoZSBzaXplIG9mIHRoZSBlcnJv ciByYW5nZS4NCg0KCXBhdWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE5p Y28gV2lsbGlhbXMgW21haWx0bzpuaWNvQGNyeXB0b25lY3Rvci5jb21dIA0KU2VudDogV2VkbmVz ZGF5LCBPY3RvYmVyIDE5LCAyMDExIDU6MTMgUE0NClRvOiBtYXllckBudHAub3JnDQpDYzogS29u aW5nLCBQYXVsOyBrZXZpbi5ncm9zc0BhdmFudy5jb207IGlwc2VjQGlldGYub3JnOyBUSUNUT0NA aWV0Zi5vcmc7IGN1aXlhbmdAaHVhd2VpLmNvbTsgbWlsbHNAdWRlbC5lZHUNClN1YmplY3Q6IFJl OiBbSVBzZWNdIFtUSUNUT0NdIFJldmlldyByZXF1ZXN0IGZvciBJUHNlYyBzZWN1cml0eSBmb3Ig cGFja2V0IGJhc2VkIHN5bmNocm9uaXphdGlvbiAoWWFuZyBDdWkpDQoNCk9uIFdlZCwgT2N0IDE5 LCAyMDExIGF0IDM6MzEgUE0sIERhbm55IE1heWVyIDxtYXllckBudHAub3JnPiB3cm90ZToNCj4g T24gMTAvMTgvMjAxMSAyOjE2IFBNLCBQYXVsX0tvbmluZ0BEZWxsLmNvbSB3cm90ZToNCj4+IEFi c29sdXRlbHkuIMKgQnV0IGlmIHlvdSBhbGxvdywgc2F5LCBvbmUgc2Vjb25kIHJvdW5kIHRyaXAg dGltZSwgeW91IA0KPj4gaGF2ZSB0byBhc3N1bWUgdGhhdCB5b3VyIHRpbWUgaXMgb2ZmIGJ5IHRo YXQgYW1vdW50IGZyb20gdGhlIG1hc3Rlci4NCj4NCj4gTm8sIGhhbGYgdGhhdCBhbW91bnQuIFJv dW5kIHRyaXAgbWVhbnMgZXhhY3RseSB0aGF0IQ0KDQpZb3UncmUgYXNzdW1pbmcgc3ltbWV0cmlj IHJvdXRpbmcuLi4NCg== From nico@cryptonector.com Wed Oct 19 18:30:58 2011 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 5168F11E80BA; Wed, 19 Oct 2011 18:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBHExx7nK6fU; Wed, 19 Oct 2011 18:30:57 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id D0BB511E80B6; Wed, 19 Oct 2011 18:30:57 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 4DBC31005D; Wed, 19 Oct 2011 18:30:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=ex55nt8ZOMfOsUuZrvsm5lMvCcRxixnkuDKRlkJGHkO5 vNnDjua7AcJDQMuggNWO/LmXiIxmWT5MMp3n0U3X0r2PNkSD8M5YkL2kIm2pO8xU k1/Bcfhb6FCrKAu7xuWIOAG3loOA7apZnRihB/zsfpfdSDfi+kqNCH/KHx218NE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=X7QwlKKyZKYGMEiwGuaVFqZTK8Y=; b=DO6w+EjGTCd BtUROoScEAT9JT50JY2t/VXwJo+Voh7or288L/ys5RPSFKq7lD+q/93GyshqTEBt q46E+2R+NG2G5Ve1FmB+nbsppis1XvV+Jqu9BtqqyhvzDHgVDhTgRXghfIo7b4xc wpN6PkU37Pa9zzSx8TaPhIS7md5oMPEM= Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 2B19610058; Wed, 19 Oct 2011 18:30:57 -0700 (PDT) Received: by pzk34 with SMTP id 34so6023054pzk.9 for ; Wed, 19 Oct 2011 18:30:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.13.135 with SMTP id h7mr16239660pbc.75.1319074256787; Wed, 19 Oct 2011 18:30:56 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Wed, 19 Oct 2011 18:30:56 -0700 (PDT) In-Reply-To: <09787EF419216C41A903FD14EE5506DD030CD659B5@AUSX7MCPC103.AMER.DELL.COM> References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB90B81@AUSX7MCPC103.AMER.DELL.COM> <09787EF419216C41A903FD14EE5506DD030CD64A86@AUSX7MCPC103.AMER.DELL.COM> <4E9F338B.3060703@ntp.org> <09787EF419216C41A903FD14EE5506DD030CD659B5@AUSX7MCPC103.AMER.DELL.COM> Date: Wed, 19 Oct 2011 20:30:56 -0500 Message-ID: From: Nico Williams To: Paul_Koning@dell.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: cuiyang@huawei.com, kevin.gross@avanw.com, mayer@ntp.org, ipsec@ietf.org, TICTOC@ietf.org, mills@udel.edu Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 01:30:58 -0000 On Wed, Oct 19, 2011 at 8:14 PM, wrote: > I think Danny is right: if the round trip time is 1 second, and you pick = the midpoint as the outcome of the sync process, you're off at most plus or= minus half a second. =C2=A0I was mixing up the error bound with the size o= f the error range. Ah, yes, right, observed from one of the end-nodes. From cuiyang@huawei.com Wed Oct 19 19:12:19 2011 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 987FC11E80C6; Wed, 19 Oct 2011 19:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.049 X-Spam-Level: *** X-Spam-Status: No, score=3.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_26=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCld95xPlp9R; Wed, 19 Oct 2011 19:12:19 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 72B151F0C3E; Wed, 19 Oct 2011 19:12:18 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTC006W3E26P2@szxga05-in.huawei.com>; Thu, 20 Oct 2011 10:10:54 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTC00ESEE1HN6@szxga05-in.huawei.com>; Thu, 20 Oct 2011 10:10:54 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEI09514; Thu, 20 Oct 2011 10:10:52 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 20 Oct 2011 10:10:46 +0800 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.6]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0270.001; Thu, 20 Oct 2011 10:09:57 +0800 Date: Thu, 20 Oct 2011 02:09:55 +0000 From: Cui Yang In-reply-to: X-Originating-IP: [172.24.2.41] To: Nico Williams , Danny Mayer Message-id: <8CC0CB0BCAE52F46882E17828A9AE21619F98817@SZXEML508-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [TICTOC] [IPsec] Review request for IPsec security for packet based synchronization (Yang Cui) Thread-index: AQHMjavsSCwWr4eJ50iPSX1zFeaaMJWDCvyAgAA+xACAATO2nQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E98D17E.8000801@udel.edu> <4E9B9C12.6000505@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB8FC8B@AUSX7MCPC103.AMER.DELL.COM> <4A4385BFBA1BC54C863E7394BD1AECB338AACB0F@SJC-MBX-01.symmetricom.com> <4E9EBB11.5090407@ntp.org> Cc: "manav.bhatia@alcatel-lucent.com" , "ipsec@ietf.org" , Tim Frost , "TICTOC@ietf.org" , "Paul_Koning@Dell.com" , "mills@udel.edu" Subject: [IPsec] =?gb2312?b?tPC4tDogW1RJQ1RPQ10gIFJldmlldyByZXF1ZXN0IGZv?= =?gb2312?b?ciBJUHNlYyBzZWN1cml0eSBmb3IgcGFja2V0IGJhc2VkIHN5bmNocm9uaXph?= =?gb2312?b?dGlvbiAoWWFuZyBDdWkp?= 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 Oct 2011 02:12:19 -0000 U29ycnkgZm9yIHRoZSBsYXRlIHJlc3BvbnNlLCBJIGFtIG9uIGEgYnVzaW5lc3MgdHJpcCBhbmQg d2lsbCByZXR1cm4gdG8gQmVpamluZyBPZmZpY2UgbmV4dCB3ZWVrLiBUaGFua3MgZm9yIHRoaXMg bG9uZyB0aHJlYWQgYW5kIG1hbnkgaGVscGZ1bCBjb21tZW50cyBhbmQgb2JqZWN0aW9ucywgaXQg ZGlkIGhlbHAgdXMgZW5oYW5jZSB0aGUgZHJhZnQgYWNjb3JkaW5nbHksIEkgYmVsaWV2ZS4KCkkg cXVpY2tseSBsb29rIHRocm91Z2ggdGhvc2UgZW1haWxzIG9uIHRpY3RvYyAmIGlwc2VjIE1MKHBs ZWFzZSB0ZWxsIG1lIGlmIEkgbWlzc2luZyBzb21lIGltcG9ydGFudCBjb21tZW50cykuIEFzIHRo ZSBmaXJzdCByZXBseSwgSSB3b3VsZCBsaWtlIHRvIHBvaW50IG91dCBzZXZlcmFsIGZhY3RzIGlu IHRoZSBmb2xsb3dpbmc6CgoxLiBNb3N0IGRvdWJ0cyBoYXZlIGJlZW4gY2FzdCBvbiB0aGUgcmF0 aW9uYWxlIG9mIGVuY3J5cHRpb24uIFRoYW5rcyB0byAgY29tbWVudHMgYnkgVGltIGFuZCBvdGhl cnMsIHRoaXMgcmVxdWlyZW1lbnQgY29tZXMgZnJvbSAzR1BQIHNwZWMuLCBhcyBleHBsYWluZWQg aW4gdGhlIEludHJvZHVjdGlvbiwgd2hlcmUgaXQgc2F5cyB0aGF0IDNHUFAgc3BlYy4gU0hBTEwg c3VwcG9ydCBlbmNyeXB0aW9uL3R1bm5lbCBpbiBiYWNraGF1bCBsaW5rLgoKMi4gVGhlbiB0aGUg cHJvYmxlbSBhcmlzZW4gaXMgdGhlIChpbnRlcm1lZGlhdGUpIG5vZGVzIGNhbm5vdCByZWNvZ25p emUgdGhlIHRpbWluZyBpZiB1c2luZyBhbiBlbmNyeXB0ZWQgSUVFRSAxNTg4LCB1bmxlc3MgYW4g aWRlbnRpZmllciBpcyBhdHRhY2hlZCB0byBzdWNoIHBhY2tldHMuIFRpbWluZyBwYWNrZXRzIHdp dGggYW4gaWRlbnRpZmllciBkb2VzIG5vdCBkZXN0cm95IGl0cyBpbnRlZ3JpdHkgcHJvdGVjdGlv biwgd2hlcmUgSVRVVFtHLjgyNjVdIGRlZmluZXMgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIG9uIHN5 bmNocm9uaXphdGlvbiwgYXMgd2UgZGVzY3JpYmVkIGluIHRoZSBkcmFmdCAoU2VjLiAzKS4gQW4g dW5hdXRob3JpemVkIGNsaWVudCBvciBhIHJvdWdlIHRpbWUgc2VydmVyIHdpdGhvdXQga25vd2lu ZyB0aGUgc2VjcmV0IGtleSBjYW5ub3QgZGVjcnlwdCB0aGUgdGltaW5nIGluZm9ybWF0aW9uLCBh bmQgdGh1cyBjYW5ub3QgYmVuZWZpdCBmcm9tIHRoZSBwcm90b2NvbC4KCjMuIElkZW50aWZpZWQg dGltaW5nIHBhY2tldHMgZ2l2ZXMgYSBsaXR0bGUgbW9yZSBpbmZvcm1hdGlvbiB0byBhdHRhY2tl cnMgdGhhbiBub3JtYWwsIGNvbnNpZGVyaW5nIERvUyBhdHRhY2ssIGJ1dCBpdCBpcyBvdXQgb2Yg dGhlIHNjb3BlIG9mIHRoaXMgZHJhZnQgYW5kIGNhbiBoYXJkbHkgYmUgcHJldmVudGVkLiBJZiBh biBhdHRhY2tlciBpcyB3aWxsaW5nIHRvIGZvY3VzIG9uIGRyb3BwaW5nIHBhY2tldHMgb3IgYmxv Y2tpbmcgdHJhZmZpYywgSSBhbSBhZnJhaWQgdGhhdCBtb3N0IG9mIGN1cnJlbnQgc2VjdXJpdHkg Y291bnRlcm1lYXN1cmVzIGFyZSB1c2VsZXNzLiBTaW1pbGFybHksIGFueSBpbnRlbnRpb25hbCBk ZWxheSBieSBhdHRhY2tlcnMgY2FuIG1pc2xlYWQgdGhlIGNsaWVudCB0byByZWNlaXZlIGEgZmFs c2UgdGltaW5nLiBJbiBjb250cmFzdCwgbGF0ZW5jeSBmcm9tIGNyeXB0byBvcGVyYXRpb25zIGNh biBiZSBtZWFzdXJlZCBlYXNpbHkuCgo0LiBIYXJkd2FyZSBiYXNlZCBwcm90b2NvbCwgdGltZXN0 YW1waW5nIG9uIGFsbCBwYWNrZXRzLCB3aWxsIGxlYWQgdG8gYW4gdW5hY2NlcHRhYmxlIHBlcmZv cm1hbmNlIGRvd24gb2YgRmVtdG9jZWxsLCBkdWUgdG8gb3VyIGV4cGVyaW1lbnRhbCByZXN1bHRz LiBTbywgaXQgaXMgbm90IGNvcnJlY3QgdG8gY2xhaW0gdGhhdCAiaWYgeW91IGNhbiB0aW1lc3Rh bXAgc29tZSBwYWNrZXQsIHRoZW4geW91IGNhbiB0aW1lc3RhbXAgYWxsIiwgYXQgbGVhc3QgZnJv bSBhIHBlcmZvcm1hbmNlIHBvaW50IG9mIHZpZXcuIEl0IGRvZXMgbm90IHNhdGlzZnkgb3VyIHJl cXVpcmVtZW50IDMoU2VjLiAzKSwgYXMgd2VsbC4KCjUuIFRoYW5rcyBOaWNvIGZvciBoaXMgYWJz dHJhY3QsIGl0IGlzIG11Y2ggY2xlYXJlci4KCjYuIFRoYW5rcyBNYW5hdidzIGV4cGxhbmF0aW9u LCAKaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3RpY3RvYy9jdXJyZW50L21z ZzAwNzU1Lmh0bWwgCml0IGlzIGluZGVlZCBvbmUgb2YgdGhlIG1vdGl2YXRpb24gdG8gaWRlbnRp ZnkgdGltaW5nIHVuZGVyIHNlY3VyaXR5IHR1bm5lbC4gCgpGaW5hbGx5LCBhbGwgY29tbWVudHMg YW5kIG9iamVjdGlvbnMgYXJlIGhpZ2hseSBhcHByZWNpYXRlZC4gCldlIGFyZSB0aGFua2Z1bCB0 byBhbGwgdGhvc2UgaGF2ZSBjb250cmlidXRlZCB0byB0aGlzIGRpc2N1c3Npb24sIGFuZCB3aWxs IHJldmlzZSB0aGUgZHJhZnQgY29ycmVzcG9uZGluZ2x5LiAKCkNoZWVycywKWWFuZwo8IGN1aXlh bmdAaHVhd2VpLmNvbSA+Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K t6K8/sjLOiBOaWNvIFdpbGxpYW1zIFtuaWNvQGNyeXB0b25lY3Rvci5jb21dCreiy83KsbzkOiAy MDExxOoxMNTCMTnI1SAyMzo0MQq1vTogRGFubnkgTWF5ZXIKQ2M6IFRpbSBGcm9zdDsgUGF1bF9L b25pbmdARGVsbC5jb207IGlwc2VjQGlldGYub3JnOyBtaWxsc0B1ZGVsLmVkdTsgVElDVE9DQGll dGYub3JnOyBDdWkgWWFuZwrW98ziOiBSZTogW1RJQ1RPQ10gW0lQc2VjXSBSZXZpZXcgcmVxdWVz dCBmb3IgSVBzZWMgc2VjdXJpdHkgZm9yIHBhY2tldCBiYXNlZCBzeW5jaHJvbml6YXRpb24gKFlh bmcgQ3VpKQoKT24gV2VkLCBPY3QgMTksIDIwMTEgYXQgNjo1NyBBTSwgRGFubnkgTWF5ZXIgPG1h eWVyQG50cC5vcmc+IHdyb3RlOgo+PiBUaGUgcHJvYmxlbSB3aXRoIHRoaXMgaXMgb25jZSB0aGUg cGFja2V0cyBoYXZlIGJlZW4gZW5jcnlwdGVkLCBpdCBpcwo+PiBub3QgcG9zc2libGUgZm9yIHRo ZSBmZW10b2NlbGwgdG8gdGltZXN0YW1wIHRoZW0gb24gcmVjZXB0aW9uIGJlY2F1c2UgaXQKPj4g ZG9lc24ndCByZWNvZ25pc2UgdGhlbSB1bnRpbCBhZnRlciBkZWNyeXB0aW9uLCB3aGljaCBpcyB3 aGF0IHRoaXMgZHJhZnQKPj4gdHJpZXMgdG8gYWRkcmVzcy4KPgo+IFlvdSBjb3VsZCBhbHdheXMg dGltZXN0YW1wIGFsbCBwYWNrZXRzIGFuZCB0aGVuIHdvcnJ5IGFib3V0IHdoZXRoZXIgb3IKPiBu b3QgeW91IG5lZWQgdGhlIHRpbWVzdGFtcCBvciBpcyB0aGlzIHByb2hpYml0aXZlIGluIGNvc3Q/ CgpUaGF0J3MgbXkgdGFrZSBhcyB3ZWxsLiAgSWYgeW91IGNhbiB0aW1lc3RhbXAgc29tZSBwYWNr ZXRzLCB5b3UgY2FuCnRpbWVzdGFtcCB0aGVtIGFsbC4gIFBlcmhhcHMgdGhlIHJlYWRpbmcgb2Yg YSBoaS1yZXMgdGltZXIgaXMgYSBzbG93Cm9wZXJhdGlvbiwgb3IgcGVyaGFwcyBpdCBjYW4gaGF2 ZSBkZWxldGVyaW91cyBlZmZlY3RzLiAgRm9yIGV4YW1wbGUsIGEKaGktcmVzIHRpbWVyIG1pZ2h0 IGJlIGF2YWlsYWJsZSBvbmx5IHcvbyByZWZlcmVuY2UgdG8gYSBzaW5nbGUgY2xvY2ssCndpdGgg ZWFjaCBoaS1yZXMgdGltZXIgYmVpbmcgQ1BVIGNvcmUtL3RocmVhZC1zcGVjaWZpYywgaW4gd2hp Y2ggY2FzZQp0aGUgc3lzdGVtIHdvdWxkIGhhdmUgdG8gYXJyYW5nZSBmb3IgdGhlIHBhY2tldCB0 byBjb250aW51ZSB0byBiZQpwcm9jZXNzZWQgb24gdGhlIHNhbWUgY29yZS90aHJlYWQgZXZlbiBp ZiBpdCdkIGJlIGJldHRlciBub3QgdG8gZm9yCm90aGVyIHJlYXNvbnMuICBNb2Rlcm4gQ1BVcyBj YW4gY291bnQgQ1BVIGN5Y2xlcyB0aG91Z2gsIHdoaWNoIGNhbiBiZQp1c2VkIGFzIGEgZ29vZCBw cm94eSBmb3IgaGktcmVzIHRpbWVycyBmb3IgcmVsYXRpdmVseSBzaG9ydCBydW5zIG9mCmNvZGUs IGJ1dCBwZXJoYXBzIHRyYWNraW5nIENQVSBjeWNsZXMgdXNlZCB0byBwcm9jZXNzIGEgcGFja2V0 IG1pZ2h0CnJlcXVpcmUgZXh0ZW5zaXZlIGNoYW5nZXMgdG8gYW4gaW1wbGVtZW50YXRpb24uICBP ciBwZXJoYXBzIHNvbWUKZmVtdG9jZWxscyBhcmUgaW1wbGVtZW50ZWQgYWxtb3N0IGVudGlyZWx5 IGluIEhXIHdob3NlIGFyY2hpdGVjdHVyZQptYWtlcyBpdCBleHBlbnNpdmUgdG8gdGltZXN0YW1w IGV2ZXJ5IHBhY2tldC4gIERldGFpbHMgd291bGQgYmUgbmljZS4KCkFzIGl0IGJlY29tZXMgY2xl YXIgdGhhdCB0aGlzIHByb3Bvc2FsIGlzIHJlYWxseSBhIGNhc2Ugb2YgYWxsb3dpbmcKbG9jYWwg bGltaXRhdGlvbnMgb2YgKnNvbWUqIGltcGxlbWVudGF0aW9ucyAocG9zc2libHkgbm90IGV2ZW4g cmVhbApsaW1pdGF0aW9uczsgZGV0YWlscyBhcmUgbWlzc2luZywgc28gd2UgY2FuJ3QgdGVsbCBm b3Igc3VyZSkgdG8gYmxlZWQKaW50byBwcm90b2NvbCBhcmNoaXRlY3R1cmUsIEknbSBub3cgbXVj aCBtb3JlIGluIHRoZSAidGhpcyBpcyBub3QgYQpnb29kIGlkZWEiIGNhbXAuICBJdCBtaWdodCB5 ZXQgdHVybiBvdXQgdGhhdCB0aGVzZSBsaW1pdGF0aW9ucyBhcmUKbXVjaCBtb3JlIHVuaXZlcnNh bCB0aGFuIEkgaW1hZ2luZSB0aG91Z2guCgo+PiBJIHRvdGFsbHkgYWdyZWUgd2l0aCB0aGUgY29t bWVudHMgcGVvcGxlIGxpa2UgRGFubnkgaGF2ZSBtYWRlIHRoYXQKPiBwb2ludCBvdXQgdGhlIGRp ZmZpY3VsdGllcyB0aGF0IGlkZW50aWZ5aW5nIHRpbWluZyBwYWNrZXRzIGp1c3Qgb3BlbnMKPiB0 aGVtIHVwIHRvIGF0dGFjay4gSG93ZXZlciwgY29tbWVudHMgYXR0YWNraW5nIHRoZSByYXRpb25h bGUgZm9yCj4gZW5jcnlwdGlvbiBhcmUgd2lkZSBvZiB0aGUgbWFyayAtIHRoZSBwYWNrZXRzIGFy ZSBlbmNyeXB0ZWQgYnkgM0dQUAo+IGFyY2hpdGVjdHVyZSwgd2UgaGF2ZSB0byB3b3JrIG91dCBo b3cgdG8gZGVhbCB3aXRoIHRoYXQuCj4KPiBUaGUgcmF0aW9uYWxlIHdhcyBhdHRhY2tlZCBiZWNh dXNlIGl0IHdhcyBub3Qgc3BlbGxlZCBvdXQgaW4gdGhlCj4gZG9jdW1lbnQsIGl0J3MgYXMgc2lt cGxlIGFzIHRoYXQuIFRoZSBuZXh0IHF1ZXN0aW9uIGJlY29tZXMgaXMgdGhlcmUgYQo+IGJldHRl ciB3YXkgdG8gYWNjb21wbGlzaCB0aGUgZ29hbCBnaXZlbiB0aGUgYXJjaGl0ZWN0dXJlPwoKSSBz ZWNvbmQgdGhpcy4gIFRoZSBkcmFmdCB3YXNuJ3QgcmVhZHkgZm9yIHJldmlldyBieSB0aGUgSVBz ZWMgbGlzdC4KVGhlIHJlc3VsdCB3YXMgYm91bmQgdG8gYmUgZWl0aGVyIHNpbGVuY2Ugb3Igc2tl cHRpY2lzbS4KCk5pY28KLS0K From kevin.gross@avanw.com Wed Oct 19 19:15:09 2011 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 856661F0C5F for ; Wed, 19 Oct 2011 19:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDgH71J1OwcE for ; Wed, 19 Oct 2011 19:15:08 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id CE70E1F0C59 for ; Wed, 19 Oct 2011 19:15:08 -0700 (PDT) Received: (qmail 13524 invoked by uid 0); 20 Oct 2011 02:15:08 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy9.bluehost.com with SMTP; 20 Oct 2011 02:15:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=9u1Vtm420psH/KFag4x/6inv93zSq2hqX2fv5I3pgsw=; b=ESmcgTVNnkTLgHCLx7u4beKYYvlz4qb+Q72f0mq/xckquZqXLF68vyez7w4XRMcJBTUJyAie+CTLGymk4oltx9+cJCNXpWp7YcCMXVDMpwNeza4TNWIOlqTGhXweDngF; Received: from mail-ey0-f172.google.com ([209.85.215.172]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1RGi9z-0001FE-Se; Wed, 19 Oct 2011 20:15:08 -0600 Received: by eyg24 with SMTP id 24so2474165eyg.31 for ; Wed, 19 Oct 2011 19:15:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.57.139 with SMTP id c11mr14934900fah.24.1319076906280; Wed, 19 Oct 2011 19:15:06 -0700 (PDT) Received: by 10.223.93.202 with HTTP; Wed, 19 Oct 2011 19:15:06 -0700 (PDT) In-Reply-To: References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E9EE450.9010202@ntp.org> Date: Wed, 19 Oct 2011 20:15:06 -0600 Message-ID: From: Kevin Gross To: Stephen Kent Content-Type: multipart/alternative; boundary=00151747542c6e277a04afb18648 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.215.172 authed with kevin.gross@avanw.com} Cc: Cui Yang , Danny Mayer , "ipsec@ietf.org" , "TICTOC@ietf.org" , Nico Williams , "David L. Mills" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 02:15:09 -0000 --00151747542c6e277a04afb18648 Content-Type: text/plain; charset=ISO-8859-1 We don't need decrypt and encrypt to take the same amount of time. We need encrypt+decrypt from master to slave to take the same time as encrypt+decrypt from slave to master. On Wed, Oct 19, 2011 at 9:53 AM, Stephen Kent wrote: > At 10:53 AM -0400 10/19/11, Danny Mayer wrote: > >> On 10/18/2011 12:42 PM, Kevin Gross wrote: >> >>> It does seem reasonable to consider modeling encryption and decryption >>> in as part of network latency. As long as delays introduced are the same >>> each direction, the sync protocols will naturally subtract out this >>> contribution. >>> >> >> I very much doubt that encryption and decryption take the same length of >> time but I'm sure people with experience with this will be able to tell >> us definitively. Almost certainly you will have asymmetric delays in the >> network path anyway even if the path is identical in both directions. >> >> Danny >> > > For most symmetric algs, and many modes of use, the times are the same. > The timing tend to differ for asymmetric algs. > > Steve > -- Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org --00151747542c6e277a04afb18648 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We don't need decrypt and encrypt to take the same amount of time. We n= eed encrypt+decrypt from master to slave to take the same time as encrypt+d= ecrypt from slave to master.

On Wed, Oct = 19, 2011 at 9:53 AM, Stephen Kent <kent@bbn.com> wrote:
At 10:53 AM -0400 10/19/1= 1, Danny Mayer wrote:
On 10/18/2011 12:42 PM, Kevin Gross wrote:
=A0It does seem reasonable to consider modeling encryption and decryption =A0in as part of network latency. As long as delays introduced are the same=
=A0each direction, the sync protocols will naturally subtract out this
=A0contribution.

I very much doubt that encryption and decryption take the same length of time but I'm sure people with experience with this will be able to tell=
us definitively. Almost certainly you will have asymmetric delays in the network path anyway even if the path is identical in both directions.

Danny

For most symmetric algs, and many modes of use, the times are the same.
The timing tend to differ for asymmetric algs.

Steve



--
Kevin Gross<= br>
+1-303-447-0517
Media Network Consultant

--00151747542c6e277a04afb18648-- From kevin.gross@avanw.com Wed Oct 19 19:21:40 2011 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 76D531F0C4B for ; Wed, 19 Oct 2011 19:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MOVQXvfOM1B for ; Wed, 19 Oct 2011 19:21:38 -0700 (PDT) Received: from oproxy3-pub.bluehost.com (oproxy3.bluehost.com [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id 5ECE21F0C36 for ; Wed, 19 Oct 2011 19:21:37 -0700 (PDT) Received: (qmail 12476 invoked by uid 0); 20 Oct 2011 02:21:35 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy3.bluehost.com with SMTP; 20 Oct 2011 02:21:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=AJHXrfcWW2y3mkIzbPcPshyXBoZl3/BhGyDcGh39lgc=; b=ZBMCEl6hOY31X/SiWa7q12B82F8Ew4bbhTCzUTWhedqHSAvEYaBZWQQdISIZGHrVZj5ayYQ8Lurxpjeb/EkWC75q5roFzXX5gX2dk02adTo1j90B6OvI73UXLTj8Ro8e; Received: from mail-ey0-f172.google.com ([209.85.215.172]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1RGiGF-0004ZN-98; Wed, 19 Oct 2011 20:21:35 -0600 Received: by eyg24 with SMTP id 24so2477939eyg.31 for ; Wed, 19 Oct 2011 19:21:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.61.138 with SMTP id t10mr163488fah.20.1319077293779; Wed, 19 Oct 2011 19:21:33 -0700 (PDT) Received: by 10.223.93.202 with HTTP; Wed, 19 Oct 2011 19:21:33 -0700 (PDT) In-Reply-To: References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E98D17E.8000801@udel.edu> <4E9B9C12.6000505@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB8FC8B@AUSX7MCPC103.AMER.DELL.COM> <4A4385BFBA1BC54C863E7394BD1AECB338AACB0F@SJC-MBX-01.symmetricom.com> <4E9EBB11.5090407@ntp.org> Date: Wed, 19 Oct 2011 20:21:33 -0600 Message-ID: From: Kevin Gross To: Nico Williams Content-Type: multipart/alternative; boundary=001517402a6e86ea9f04afb19dd1 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.215.172 authed with kevin.gross@avanw.com} Cc: "cuiyang@huawei.com" , Danny Mayer , "ipsec@ietf.org" , "TICTOC@ietf.org" , "Paul_Koning@Dell.com" , "mills@udel.edu" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 02:21:40 -0000 --001517402a6e86ea9f04afb19dd1 Content-Type: text/plain; charset=ISO-8859-1 It would be nice to have timestamps on every packet but, for whatever reason, this is not how most existing 1588 hardware works. Current hardware keys off specific protocol identifier fields in packets and takes a timestamp on match. There's some small amount of hardware buffer dedicated to holding timestamps. On Wed, Oct 19, 2011 at 9:41 AM, Nico Williams wrote: > On Wed, Oct 19, 2011 at 6:57 AM, Danny Mayer wrote: > >> The problem with this is once the packets have been encrypted, it is > >> not possible for the femtocell to timestamp them on reception because it > >> doesn't recognise them until after decryption, which is what this draft > >> tries to address. > > > > You could always timestamp all packets and then worry about whether or > > not you need the timestamp or is this prohibitive in cost? > > That's my take as well. If you can timestamp some packets, you can > timestamp them all. Perhaps the reading of a hi-res timer is a slow > operation, or perhaps it can have deleterious effects. For example, a > hi-res timer might be available only w/o reference to a single clock, > with each hi-res timer being CPU core-/thread-specific, in which case > the system would have to arrange for the packet to continue to be > processed on the same core/thread even if it'd be better not to for > other reasons. Modern CPUs can count CPU cycles though, which can be > used as a good proxy for hi-res timers for relatively short runs of > code, but perhaps tracking CPU cycles used to process a packet might > require extensive changes to an implementation. Or perhaps some > femtocells are implemented almost entirely in HW whose architecture > makes it expensive to timestamp every packet. Details would be nice. > > --001517402a6e86ea9f04afb19dd1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It would be nice to have timestamps on every packet but, for whatever reaso= n, this is not how most existing 1588 hardware works. Current hardware keys= off specific protocol identifier fields in packets and takes a timestamp o= n match. =A0There's some small amount of hardware buffer dedicated to h= olding timestamps.

On Wed, Oct 19, 2011 at 9:41 AM, Nico Willia= ms <nico@cryp= tonector.com> wrote:
On Wed, Oct 19, 2011 at 6:57 AM, Danny Mayer <mayer@ntp.org> wrote:
>> The problem with this is once the packets have been encrypted, it = is
>> not possible for the femtocell to timestamp them on reception beca= use it
>> doesn't recognise them until after decryption, which is what t= his draft
>> tries to address.
>
> You could always timestamp all packets and then worry about whether or=
> not you need the timestamp or is this prohibitive in cost?

That's my take as well. =A0If you can timestamp some packets, you= can
timestamp them all. =A0Perhaps the reading of a hi-res timer is a slow
operation, or perhaps it can have deleterious effects. =A0For example, a hi-res timer might be available only w/o reference to a single clock,
with each hi-res timer being CPU core-/thread-specific, in which case
the system would have to arrange for the packet to continue to be
processed on the same core/thread even if it'd be better not to for
other reasons. =A0Modern CPUs can count CPU cycles though, which can be
used as a good proxy for hi-res timers for relatively short runs of
code, but perhaps tracking CPU cycles used to process a packet might
require extensive changes to an implementation. =A0Or perhaps some
femtocells are implemented almost entirely in HW whose architecture
makes it expensive to timestamp every packet. =A0Details would be nice.
=
--001517402a6e86ea9f04afb19dd1-- From nico@cryptonector.com Wed Oct 19 19:35:34 2011 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 3F90911E80CD; Wed, 19 Oct 2011 19:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjfJh56ZKCDS; Wed, 19 Oct 2011 19:35:33 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id DFC4111E80BF; Wed, 19 Oct 2011 19:35:33 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id A890810060; Wed, 19 Oct 2011 19:35:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=qex+ONsUs5eD7gd7g6NcF o0VdDo4L0A1F0kf9eJrwA7dZKcJAOgKZvwW7q6O3q25T3CSrxXvsO6MoYBwmd/Iy LPG7f9PeGD2NxrRMyqXvRRBG5mDa+8gSFEaDzT8EvLDWnzRJGpeQO023FwFvWPkr XyvOp9CcjIu1hPIbNYcHoc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=/QwNcykcOLR7KDIKbqYj 5RYC0u4=; b=e3BFn76BNM5+IG8dMOUMLYbqsILnDDI9deurPgsA8cv4Aa5QET5S JWnJR/QGqYAYPicEnys+HCgXaZYLcAg197TPP40FWSbYMQl/zxmsk3wWPSuRBq+o +iyYfr532BX56LMXFvKWIAMtlRv67BQ1r/priaK/kIP8DXanWvXJNS8= Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 86EBC10058; Wed, 19 Oct 2011 19:35:33 -0700 (PDT) Received: by pzk34 with SMTP id 34so6132865pzk.9 for ; Wed, 19 Oct 2011 19:35:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.13.135 with SMTP id h7mr16612818pbc.75.1319078133245; Wed, 19 Oct 2011 19:35:33 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Wed, 19 Oct 2011 19:35:33 -0700 (PDT) In-Reply-To: References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E9EE450.9010202@ntp.org> Date: Wed, 19 Oct 2011 21:35:33 -0500 Message-ID: From: Nico Williams To: Kevin Gross Content-Type: text/plain; charset=UTF-8 Cc: Stephen Kent , Cui Yang , Danny Mayer , "ipsec@ietf.org" , "TICTOC@ietf.org" , "David L. Mills" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 02:35:34 -0000 On Wed, Oct 19, 2011 at 9:15 PM, Kevin Gross wrote: > We don't need decrypt and encrypt to take the same amount of time. We need > encrypt+decrypt from master to slave to take the same time as > encrypt+decrypt from slave to master. Since the plaintext lengths will differ, the ciphertext lengths might too, and so might the time needed. Nico -- From nico@cryptonector.com Wed Oct 19 19:36:45 2011 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 9F60221F8551; Wed, 19 Oct 2011 19:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E16HuJdoZtQL; Wed, 19 Oct 2011 19:36:45 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 22CD321F854D; Wed, 19 Oct 2011 19:36:45 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id BD05F768058; Wed, 19 Oct 2011 19:36:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=i+ATMm6ryJJ0H5/BwC1/IDz6ZKW2r6uD94FzjZM0Df3H 75mc6hP7Aa7PpU4MnC/cyaMxvmcUPgRrTkpWku6t0kl6BC/Q96zgTQmxxabQLxVo TcRv7wapoSf69t4hQezP+KNmRQpFosZnq39j9ab/wdmATWGbQa6jkjnq699t3dg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=S9+uyxEkPJRraO6uJCGfRPwb50w=; b=aXJPdhLkLTq 2ZMQF+rJFqHEOuap5VbZ+JlyefxDc7aKb7WAGXlBtwN3a3HYF3qZQ0CeZtikvwu/ vs6/rtg7/RGRmPRRD2kWPN1ciqyD/T8jPFabrvL0A37qLQY4jNMkLOE+Yscirdaa L1WkjMh95ZFFLATD1IJWTf1lJWqqKK/E= Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 89938768057; Wed, 19 Oct 2011 19:36:44 -0700 (PDT) Received: by pzk34 with SMTP id 34so6134645pzk.9 for ; Wed, 19 Oct 2011 19:36:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.35.129 with SMTP id h1mr11758070pbj.92.1319078204168; Wed, 19 Oct 2011 19:36:44 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Wed, 19 Oct 2011 19:36:44 -0700 (PDT) In-Reply-To: References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E98D17E.8000801@udel.edu> <4E9B9C12.6000505@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB8FC8B@AUSX7MCPC103.AMER.DELL.COM> <4A4385BFBA1BC54C863E7394BD1AECB338AACB0F@SJC-MBX-01.symmetricom.com> <4E9EBB11.5090407@ntp.org> Date: Wed, 19 Oct 2011 21:36:44 -0500 Message-ID: From: Nico Williams To: Kevin Gross Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "cuiyang@huawei.com" , Danny Mayer , "ipsec@ietf.org" , "TICTOC@ietf.org" , "Paul_Koning@Dell.com" , "mills@udel.edu" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 02:36:45 -0000 On Wed, Oct 19, 2011 at 9:21 PM, Kevin Gross wrote: > It would be nice to have timestamps on every packet but, for whatever > reason, this is not how most existing 1588 hardware works. Current hardwa= re > keys off specific protocol identifier fields in packets and takes a > timestamp on match. =C2=A0There's some small amount of hardware buffer de= dicated > to holding timestamps. This is key, and needs to be stated in the I-D, quite possibly in the abstract. I guess it's time to set aside time to go read IEEE 1588... From kevin.gross@avanw.com Wed Oct 19 20:13:18 2011 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 A87CE11E80D7 for ; Wed, 19 Oct 2011 20:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBTLfSw6fY4k for ; Wed, 19 Oct 2011 20:13:18 -0700 (PDT) Received: from oproxy3-pub.bluehost.com (oproxy3.bluehost.com [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id 034D011E80CD for ; Wed, 19 Oct 2011 20:13:17 -0700 (PDT) Received: (qmail 31759 invoked by uid 0); 20 Oct 2011 03:13:17 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy3.bluehost.com with SMTP; 20 Oct 2011 03:13:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Transfer-Encoding:Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=yqWJpvrPnII99Oh38GH7LzMnL4916zQ9litQIq7l+PA=; b=HXZHcv15QG2DrFn1BVKtNaJJ7zo5earZFn29KLjhvGuVxlFSQwDcY9MqK3YHgPFcsETo5JgWSSwRKwox1/385D/G+TehqGaUSpkqt41NkY+JNL242vchZ6TXtFQpktnP; Received: from mail-bw0-f44.google.com ([209.85.214.44]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1RGj4H-00088w-FE; Wed, 19 Oct 2011 21:13:17 -0600 Received: by bkas6 with SMTP id s6so3369044bka.31 for ; Wed, 19 Oct 2011 20:13:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.77.77 with SMTP id f13mr7598622fak.19.1319080395715; Wed, 19 Oct 2011 20:13:15 -0700 (PDT) Received: by 10.223.93.202 with HTTP; Wed, 19 Oct 2011 20:13:15 -0700 (PDT) In-Reply-To: References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E98D17E.8000801@udel.edu> <4E9B9C12.6000505@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB8FC8B@AUSX7MCPC103.AMER.DELL.COM> <4A4385BFBA1BC54C863E7394BD1AECB338AACB0F@SJC-MBX-01.symmetricom.com> <4E9EBB11.5090407@ntp.org> Date: Wed, 19 Oct 2011 21:13:15 -0600 Message-ID: From: Kevin Gross To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.214.44 authed with kevin.gross@avanw.com} Cc: "cuiyang@huawei.com" , Danny Mayer , "ipsec@ietf.org" , "TICTOC@ietf.org" , "Paul_Koning@Dell.com" , "mills@udel.edu" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 03:13:18 -0000 The IEEE 1588 standards are quite abstract so you won't find these implementation details there. You need to read NIC datasheets. Many of these are only available under NDA. On Wed, Oct 19, 2011 at 8:36 PM, Nico Williams wrot= e: > On Wed, Oct 19, 2011 at 9:21 PM, Kevin Gross wrot= e: >> It would be nice to have timestamps on every packet but, for whatever >> reason, this is not how most existing 1588 hardware works. Current hardw= are >> keys off specific protocol identifier fields in packets and takes a >> timestamp on match. =A0There's some small amount of hardware buffer dedi= cated >> to holding timestamps. > > This is key, and needs to be stated in the I-D, quite possibly in the > abstract. =A0I guess it's time to set aside time to go read IEEE 1588... > --=20 Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks -=A0www.AVAnw.com,=A0www.X192.org From cuiyang@huawei.com Wed Oct 19 22:41:15 2011 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 D209E11E80C5; Wed, 19 Oct 2011 22:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.327 X-Spam-Level: X-Spam-Status: No, score=0.327 tagged_above=-999 required=5 tests=[AWL=2.723, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qppO2a-9Q8aH; Wed, 19 Oct 2011 22:41:15 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id D800111E8089; Wed, 19 Oct 2011 22:41:14 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTC00IMVNQGKF@szxga03-in.huawei.com>; Thu, 20 Oct 2011 13:39:52 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTC00KP0NQF64@szxga03-in.huawei.com>; Thu, 20 Oct 2011 13:39:52 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEI21246; Thu, 20 Oct 2011 13:39:50 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 20 Oct 2011 13:39:45 +0800 Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.6]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Thu, 20 Oct 2011 13:39:44 +0800 Date: Thu, 20 Oct 2011 05:39:43 +0000 From: Cui Yang In-reply-to: X-Originating-IP: [172.24.2.40] To: Kevin Gross , Nico Williams Message-id: <8CC0CB0BCAE52F46882E17828A9AE21619F98885@SZXEML508-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [TICTOC] [IPsec] Review request for IPsec security for packet based synchronization (Yang Cui) Thread-index: AQHMjavsSCwWr4eJ50iPSX1zFeaaMJWDCvyAgAA+xACAALLDgIAABD4AgAAKNICAAK0X9g== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E98D17E.8000801@udel.edu> <4E9B9C12.6000505@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB8FC8B@AUSX7MCPC103.AMER.DELL.COM> <4A4385BFBA1BC54C863E7394BD1AECB338AACB0F@SJC-MBX-01.symmetricom.com> <4E9EBB11.5090407@ntp.org> Cc: "ipsec@ietf.org" , Danny Mayer , "Paul_Koning@Dell.com" , "TICTOC@ietf.org" , "mills@udel.edu" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 05:41:15 -0000 QXMgSSBoYXZlIG5vdGVkIGluIHRoZSBsYXN0IGVtYWlsLCB0aW1lc3RhbXBpbmcgYWxsIHBhY2tl dHMgaXMgdG9vIGNvc3RseSB0byBhZmZvcmQgdG8uIFdlIGhhdmUgZG9uZSBzb21lIGV4cGVyaW1l bnRzIG9uIG91ciBwcm9kdWN0cywgdGhlIGRlZ3JhZGluZyBvZiBwZXJmb3JtYW5jZSBpcyB1bmFj Y2VwdGFibGUuIFRoYXQgaXMgd2h5IHdlIG5lZWQgdG8gZGlzdGluZ3Vpc2ggMTU4OCBwYWNrZXQg ZnJvbSBvdGhlcnMgd2l0aCBoaWdoIHByaW9yaXR5LCBhbmQgaXMgdGhlIGNydWNpYWwgcmVhc29u IHRoYXQgd2UgZXF1aXAgV0VTUCB3aXRoIGlkZW50aWZpZXIuCgpZYW5nCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18Kt6K8/sjLOiBLZXZpbiBHcm9zcyBba2V2aW4uZ3Jv c3NAYXZhbncuY29tXQq3osvNyrG85DogMjAxMcTqMTDUwjIwyNUgMTE6MTMKtb06IE5pY28gV2ls bGlhbXMKQ2M6IERhbm55IE1heWVyOyBDdWkgWWFuZzsgaXBzZWNAaWV0Zi5vcmc7IFRJQ1RPQ0Bp ZXRmLm9yZzsgUGF1bF9Lb25pbmdARGVsbC5jb207IG1pbGxzQHVkZWwuZWR1Ctb3zOI6IFJlOiBb VElDVE9DXSBbSVBzZWNdIFJldmlldyByZXF1ZXN0IGZvciBJUHNlYyBzZWN1cml0eSBmb3IgcGFj a2V0IGJhc2VkIHN5bmNocm9uaXphdGlvbiAoWWFuZyBDdWkpCgpUaGUgSUVFRSAxNTg4IHN0YW5k YXJkcyBhcmUgcXVpdGUgYWJzdHJhY3Qgc28geW91IHdvbid0IGZpbmQgdGhlc2UKaW1wbGVtZW50 YXRpb24gZGV0YWlscyB0aGVyZS4gWW91IG5lZWQgdG8gcmVhZCBOSUMgZGF0YXNoZWV0cy4gTWFu eSBvZgp0aGVzZSBhcmUgb25seSBhdmFpbGFibGUgdW5kZXIgTkRBLgoKT24gV2VkLCBPY3QgMTks IDIwMTEgYXQgODozNiBQTSwgTmljbyBXaWxsaWFtcyA8bmljb0BjcnlwdG9uZWN0b3IuY29tPiB3 cm90ZToKPiBPbiBXZWQsIE9jdCAxOSwgMjAxMSBhdCA5OjIxIFBNLCBLZXZpbiBHcm9zcyA8a2V2 aW4uZ3Jvc3NAYXZhbncuY29tPiB3cm90ZToKPj4gSXQgd291bGQgYmUgbmljZSB0byBoYXZlIHRp bWVzdGFtcHMgb24gZXZlcnkgcGFja2V0IGJ1dCwgZm9yIHdoYXRldmVyCj4+IHJlYXNvbiwgdGhp cyBpcyBub3QgaG93IG1vc3QgZXhpc3RpbmcgMTU4OCBoYXJkd2FyZSB3b3Jrcy4gQ3VycmVudCBo YXJkd2FyZQo+PiBrZXlzIG9mZiBzcGVjaWZpYyBwcm90b2NvbCBpZGVudGlmaWVyIGZpZWxkcyBp biBwYWNrZXRzIGFuZCB0YWtlcyBhCj4+IHRpbWVzdGFtcCBvbiBtYXRjaC4gIFRoZXJlJ3Mgc29t ZSBzbWFsbCBhbW91bnQgb2YgaGFyZHdhcmUgYnVmZmVyIGRlZGljYXRlZAo+PiB0byBob2xkaW5n IHRpbWVzdGFtcHMuCj4KPiBUaGlzIGlzIGtleSwgYW5kIG5lZWRzIHRvIGJlIHN0YXRlZCBpbiB0 aGUgSS1ELCBxdWl0ZSBwb3NzaWJseSBpbiB0aGUKPiBhYnN0cmFjdC4gIEkgZ3Vlc3MgaXQncyB0 aW1lIHRvIHNldCBhc2lkZSB0aW1lIHRvIGdvIHJlYWQgSUVFRSAxNTg4Li4uCj4KCgoKLS0KS2V2 aW4gR3Jvc3MKKzEtMzAzLTQ0Ny0wNTE3Ck1lZGlhIE5ldHdvcmsgQ29uc3VsdGFudApBVkEgTmV0 d29ya3MgLSB3d3cuQVZBbncuY29tLCB3d3cuWDE5Mi5vcmcK From Chris.Ulliott@cesg.gsi.gov.uk Thu Oct 20 01:27:45 2011 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 8A66A21F8B65 for ; Thu, 20 Oct 2011 01:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_BACKHAIR_44=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAVJfq3vaWWu for ; Thu, 20 Oct 2011 01:27:44 -0700 (PDT) Received: from mail185.messagelabs.com (mail185.messagelabs.com [85.158.143.19]) by ietfa.amsl.com (Postfix) with SMTP id 5597E21F8B4D for ; Thu, 20 Oct 2011 01:27:42 -0700 (PDT) X-Env-Sender: Chris.Ulliott@cesg.gsi.gov.uk X-Msg-Ref: server-12.tower-185.messagelabs.com!1319099260!678096!1 X-Originating-IP: [195.92.40.48] X-StarScan-Version: 6.3.6; banners=cesg.gsi.gov.uk,-,- X-VirusChecked: Checked Received: (qmail 31380 invoked from network); 20 Oct 2011 08:27:40 -0000 Received: from gateway-201.energis.gsi.gov.uk (HELO mx.hosting-e.gsi.gov.uk) (195.92.40.48) by server-12.tower-185.messagelabs.com with SMTP; 20 Oct 2011 08:27:40 -0000 From: "Ulliott, Chris" To: 'Michael Richardson' , "ipsec@ietf.org" Date: Thu, 20 Oct 2011 09:27:35 +0100 Thread-Topic: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement Thread-Index: AcyM1CJMM6eoSrPVQ6evPYLj8owJwACLTLkA Message-ID: In-Reply-To: <15140.1318859576@marajade.sandelman.ca> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 08:27:45 -0000 The main problem I have is that RFC 4322 makes two assumptions that don't = always hold true in practical deployments. Firstly, it assumes that a gateway or endpoint is able to configure entrie= s in the secured DNS. For example, if I have an endpoint that is connecte= d to a hotel wifi, I probably can't modify the reverse DNS to deploy my pu= blic keys or publish my gateway address. This also applies when you have = mobile sites that may be using multiple bearers of opportunity such as Sat= Com / 3G etc. The second assumption is that I can secure the DNSSec deployment to the sa= me level of trust, as I have in the network behind my IPSec device... agai= n, this may not always be true. Chris -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Michael Richardson Sent: Monday, October 17, 2011 2:53 PM To: ipsec@ietf.org Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem= Statement >>>>> "Yoav" =3D=3D Yoav Nir writes: Yoav> I=20definitely think that the authors of this draft (I'm mostly Yoav> just the editor) need a good answer about why RFC 4322 doesn't Yoav> cover the use cases. Mostly, the starting point is different. Yoav> RFC 4322 begins with nodes that have no prior trust Yoav> relationship, and builds opportunistic bridges between them. No precisely true. 4322 says that we trust the central IP address delegation authority (IANA), and builds trust from there. Yoav> The problem here is that groups of nodes that have trust Yoav> relationships between them, but not between every pair of Yoav> them. They want communications that now go through some hub Yoav> gateway to go directly from spoke to spoke. So you can do this on a host<->host basis by implementing 4322, and then pulling (being a secondary using stock tools and protocols) the reverse zone from the hub (over your trusted link to the hub, or via TSIG/SIG(0), or just be IP address trust). What is (in the form of running code) missing is a way to transform the host<->host tunnels into subnet<->subnet tunnels. In IKEv2 we have a way to express the request now, what is missing is a way to express the authority statement. If subnets are on octet boundaries (or smaller, apply RFC2317), then it is pretty straightforward to search for TXT/IPSECKEY for the subnet. For CIDR subnets, which we can express in IKEv2, one could just confirm them all, but my bet is that there are no such networks that matter. ps: by the time IPSECKEY (RFC4025) was assigned, rfc4322 was pretty much in the can, and we did not have deployed code to be able to test the IPSECKEY RR easily. We decided that we would use the existence of IPSECKEY as a clue that we should try IKEv2 first. Openswan did not get an IKEv2 implementation until early 2008 though. What this means is that an RFC4322bis could properly specify semantics for IPSECKEY RR, and if they were a bit different than the semantics in 4322 for the TXT RR, that would be okay. =3D=3D=3D Yoav> Those are some of the incompatible solutions by individual Yoav> vendors. >> And RFC4322. >> >> FreeSWAN has a number of local controls whereby one simply lists >> the CIDRs that one wishes to be "secure or fail" vs ones that are >> "nice to be secure". Many people have implemented MESHs by >> distributing the reverse DNS. >> >> What it is missing in IKEv1 is a way to turn the host<->host >> tunnels into subnet<->subnet tunnels, and that would be easy to >> do in IKEv2 with the TS. >> >> >> >> Sounds like TED: >> >> >> >> >> http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/ted.= html >> >> >> >> Dan. >> >> >> >> On Thu, October 13, 2011 10:23 pm, Yoav Nir wrote: >>> Hi all >> >>> >> >>> For years, one of the barriers to the adoption of IPsec was >> that >>> configuration didn't scale. With thousands of peers, the >> PAD and >>> SPD would become unwieldy, so even where IPsec was >>=20deployed it >>> was often built in hub-and-spoke configurations, >> not because >>> policy demanded this, but because it was more >> convenient to >>> configure. Individual vendors have incompatible >> solutions for >>> this, but they only work with that vendor's >> products, and within >>> the same administrative domain. >> >>> >> >>> In this draft, we are proposing that the IPsecME working >> group >>> take on a working item to first define the problem, and >> then >>> offer solutions that will make IPsec scale better and in >> an >>> inter-operable way. >> >>> >> >>> We plan to hold a side meeting in Taipei, and we welcome >>> >> comments both before and at that meeting. >> >>> >> >>> Yoav >> >>> >> >>> http://www.ietf.org/id/draft-nir-ipsecme-p2p-00.txt >>> >> http://tools.ietf.org/html/draft-nir-ipsecme-p2p-00 >> >>> >> >>> _______________________________________________ IPsec mailing >> >>> list IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >>> >> >> >> >> >> >> >> >> Scanned by Check Point Total Security Gateway. >> Yoav> _______________________________________________ IPsec mailing Yoav> list IPsec@ietf.org Yoav> https://www.ietf.org/mailman/listinfo/ipsec >> _______________________________________________ IPsec mailing >> list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. **************************************************************************= ** Communications with GCHQ may be monitored and/or recorded=20 for system efficiency and other lawful purposes. Any views or=20 opinions expressed in this e-mail do not necessarily reflect GCHQ=20 policy. This email, and any attachments, is intended for the=20 attention of the addressee(s) only. Its unauthorised use,=20 disclosure, storage or copying is not permitted. If you are not the intended recipient, please notify postmaster@gchq.gsi.gov.uk. =20 This information is exempt from disclosure under the Freedom of=20 Information Act 2000 and may be subject to exemption under other UK information legislation. Refer disclosure requests to=20 GCHQ on 01242 221491 ext 30306 (non-secure) or email infoleg@gchq.gsi.gov.uk **************************************************************************= ** The original of this email was scanned for viruses by the Government Secur= e Intranet virus scanning service supplied by Cable&Wireless Worldwide in = partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On l= eaving the GSi this email was certified virus free. Communications via the GSi may be automatically logged, monitored and/or r= ecorded for legal purposes. From mayer@ntp.org Thu Oct 20 05:22:52 2011 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 74E4E21F8AF0; Thu, 20 Oct 2011 05:22:52 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTkibbyF4Faw; Thu, 20 Oct 2011 05:22:52 -0700 (PDT) Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by ietfa.amsl.com (Postfix) with ESMTP id DC72C21F8AFB; Thu, 20 Oct 2011 05:22:51 -0700 (PDT) Received: from [198.22.153.9] (helo=[10.60.111.27]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RGre0-000G3h-IV; Thu, 20 Oct 2011 12:22:45 +0000 Message-ID: <4EA0128A.2010004@ntp.org> Date: Thu, 20 Oct 2011 08:22:34 -0400 From: Danny Mayer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Nico Williams References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB90B81@AUSX7MCPC103.AMER.DELL.COM> In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 198.22.153.9 X-SA-Exim-Rcpt-To: nico@cryptonector.com, kevin.gross@avanw.com, Paul_Koning@dell.com, ipsec@ietf.org, TICTOC@ietf.org, cuiyang@huawei.com, mills@udel.edu X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: cuiyang@huawei.com, Kevin Gross , ipsec@ietf.org, TICTOC@ietf.org, Paul_Koning@dell.com, mills@udel.edu Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 12:22:52 -0000 On 10/18/2011 3:33 PM, Nico Williams wrote: > On Tue, Oct 18, 2011 at 12:45 PM, Kevin Gross wrote: >> Nico's contention is that it should take a constant amount of time to >> decrypt a packet once it is received. I don't think this is exactly true but >> when compared to other (variable) latencies in the system, possibly a >> reasonable approximation. > > Not constant so much as deterministic (for some algorithms, and some > implementations, but I assume that side-channels are not desirable, > which leads to the assumption of deterministic timing) or measurable. > In practice measuring this time is probably difficult, for example, in > preemptible kernel designs, or if the HW lacks a sufficiently high > resolution timer or CPU cycle counter. I grant then that the proposed > solution is simpler to implement. But should the proposal be > negotiable, and if so, how? > >> If an attacker delays or drops synchronization packets, clock quality will >> suffer. In the extreme case, all useful clock communication is lost and >> nothing works. I don't think this situation is any different for clock >> traffic than it is for other traffic. Encryption cannot prevent denial of >> service. > > However, encryption can make it harder for an attacker to delay just > the timing packets (though not impossible given enough meta-data > leaking to mount effective traffic analysis). Or, to put it > differently, making timing packets identifiable makes it easier for an > attacker to DoS only the timing exchanges but not the rest. > > DoS attacks based on not allowing packets through, or delaying them, > generally cannot be avoided, so perhaps there's no cause for concern. > I think you'd want to have a security consideration describing the > problems that might arise from a selective DoS attack on timing, as > well as mitigations. For NTP at least, the loss of some packets doesn't matter, it will continue on disciplining the clock at the same rate until it decides it has enough reliable data to adjust the frequency of the clock to bring it back in line with its NTP reference clock servers. Even then it will throw out packets which show large variations. In the worst case it will be receiving no valid packets and just won't make changes to the clock. NTP is robust enough that the clock will be accurate enough even if it hasn't received a single packet for hours. I cannot answer for PSP since I don't know what it does. Danny From mayer@ntp.org Thu Oct 20 06:02:10 2011 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 7FCCC21F8B47; Thu, 20 Oct 2011 06:02:10 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IP1Cq7vv0E3; Thu, 20 Oct 2011 06:02:10 -0700 (PDT) Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by ietfa.amsl.com (Postfix) with ESMTP id F39DD21F8B46; Thu, 20 Oct 2011 06:02:09 -0700 (PDT) Received: from [198.22.153.9] (helo=[10.60.111.27]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RGsG5-000IAj-3o; Thu, 20 Oct 2011 13:02:07 +0000 Message-ID: <4EA01BC3.3050107@ntp.org> Date: Thu, 20 Oct 2011 09:01:55 -0400 From: Danny Mayer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E98D17E.8000801@udel.edu> <4E9B9C12.6000505@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB8FC8B@AUSX7MCPC103.AMER.DELL.COM> <4A4385BFBA1BC54C863E7394BD1AECB338AACB0F@SJC-MBX-01.symmetricom.com> <4A4385BFBA1BC54C863E7394BD1AECB338AACF66@SJC-MBX-01.symmetricom.com> <7C362EEF9C7896468B36C9B79200D8350D007ABB04@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D007ABB04@INBANSXCHMBSA1.in.alcatel-lucent.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 198.22.153.9 X-SA-Exim-Rcpt-To: manav.bhatia@alcatel-lucent.com, tfrost@symmetricom.com, nico@cryptonector.com, ipsec@ietf.org, Paul_Koning@dell.com, TICTOC@ietf.org, cuiyang@huawei.com, mills@udel.edu X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: "cuiyang@huawei.com" , "ipsec@ietf.org" , Tim Frost , "TICTOC@ietf.org" , Nico Williams , "Paul_Koning@Dell.com" , "mills@udel.edu" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 13:02:10 -0000 On 10/19/2011 7:50 AM, Bhatia, Manav (Manav) wrote: > Hi, > > I had spoken to one of the initial authors of this IPsec draft and I was told that setting up an Ipsec tunnel exclusively for shipping 1588 may not be possible in the femto architecture. They are thus trying to use WESP (that I have co-authored) to identify 1588 packets within an IPSec stream. > > I have tried to describe the problem that this draft is attempting > to address here: > > http://www.ietf.org/mail-archive/web/tictoc/current/msg00755.html > > As an author of WESP I can say that the way this draft uses WESP to protect 1588 is not very appropriate. The draft tries to add some additional identifiers in each protocol packet to uniquely identify 1588 packets. This in the security land will not be accepted as anybody snooping on the wire will be easily able to disambiguate 1588 packets from other packets in the stream. If the authors want to use WESP then they must negotiate this unique ID (or a set of IDs) in IKE and pad the packets randomly so that the attackers cant identify the 1588 packets in the Ipsec stream. In that case the receiving end will also be unable to identify those packets which defeats the purpose of the draft. Danny From kevin.gross@avanw.com Thu Oct 20 06:08:49 2011 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 8663321F8B72 for ; Thu, 20 Oct 2011 06:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+stv01xSDD4 for ; Thu, 20 Oct 2011 06:08:48 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id CD2D921F8B71 for ; Thu, 20 Oct 2011 06:08:48 -0700 (PDT) Received: (qmail 22652 invoked by uid 0); 20 Oct 2011 13:08:47 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by cpoproxy2.bluehost.com with SMTP; 20 Oct 2011 13:08:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Transfer-Encoding:Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=4Fiu3EYKpp2hn0DcIUCdxESKVqb2p73Ni42adx3BFmA=; b=L9nKtiyAH6ltDcYyglOZjoW7IkUFWTnshwwx9uFaXN21SeFUx+c6LkiTUci9dQqFbrYhNEnOogYbDChE2/tJ7Jfkz3FNkKf/NrTiBD22ByUOM4zPuH8hx4AKt1UUwozX; Received: from mail-ey0-f172.google.com ([209.85.215.172]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1RGsMZ-0006Qj-6D; Thu, 20 Oct 2011 07:08:47 -0600 Received: by eyg24 with SMTP id 24so3020266eyg.31 for ; Thu, 20 Oct 2011 06:08:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.5.3 with SMTP id 3mr18221252fat.4.1319116125453; Thu, 20 Oct 2011 06:08:45 -0700 (PDT) Received: by 10.223.93.202 with HTTP; Thu, 20 Oct 2011 06:08:45 -0700 (PDT) In-Reply-To: <4EA0128A.2010004@ntp.org> References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB90B81@AUSX7MCPC103.AMER.DELL.COM> <4EA0128A.2010004@ntp.org> Date: Thu, 20 Oct 2011 07:08:45 -0600 Message-ID: From: Kevin Gross To: Danny Mayer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.215.172 authed with kevin.gross@avanw.com} Cc: cuiyang@huawei.com, ipsec@ietf.org, TICTOC@ietf.org, Nico Williams , Paul_Koning@dell.com, mills@udel.edu Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 13:08:49 -0000 IEEE 1588 (PTP) specifies how updates are delivered. Unlike NTP, PTP does not specify what devices do with these updates. In both cases, stability in the absence of updates is mostly a function of the quality of the local oscillator and not so much dependent on the time protocol. Kevin Gross On Thu, Oct 20, 2011 at 6:22 AM, Danny Mayer wrote: > On 10/18/2011 3:33 PM, Nico Williams wrote: >> On Tue, Oct 18, 2011 at 12:45 PM, Kevin Gross wr= ote: >>> Nico's contention is that it should take a constant amount of time to >>> decrypt a packet once it is received. I don't think this is exactly tru= e but >>> when compared to other (variable) latencies in the system, possibly a >>> reasonable approximation. >> >> Not constant so much as deterministic (for some algorithms, and some >> implementations, but I assume that side-channels are not desirable, >> which leads to the assumption of deterministic timing) or measurable. >> In practice measuring this time is probably difficult, for example, in >> preemptible kernel designs, or if the HW lacks a sufficiently high >> resolution timer or CPU cycle counter. =A0I grant then that the proposed >> solution is simpler to implement. =A0But should the proposal be >> negotiable, and if so, how? >> >>> If an attacker delays or drops synchronization packets, clock quality w= ill >>> suffer. In the extreme case, all useful clock communication is lost and >>> nothing works. I don't think this situation is any different for clock >>> traffic than it is for other traffic. Encryption cannot prevent denial = of >>> service. >> >> However, encryption can make it harder for an attacker to delay just >> the timing packets (though not impossible given enough meta-data >> leaking to mount effective traffic analysis). =A0Or, to put it >> differently, making timing packets identifiable makes it easier for an >> attacker to DoS only the timing exchanges but not the rest. >> >> DoS attacks based on not allowing packets through, or delaying them, >> generally cannot be avoided, so perhaps there's no cause for concern. >> I think you'd want to have a security consideration describing the >> problems that might arise from a selective DoS attack on timing, as >> well as mitigations. > > For NTP at least, the loss of some packets doesn't matter, it will > continue on disciplining the clock at the same rate until it decides it > has enough reliable data to adjust the frequency of the clock to bring > it back in line with its NTP reference clock servers. Even then it will > throw out packets which show large variations. In the worst case it will > be receiving no valid packets and just won't make changes to the clock. > NTP is robust enough that the clock will be accurate enough even if it > hasn't received a single packet for hours. I cannot answer for PSP since > I don't know what it does. > > Danny > From lgoldin@cisco.com Wed Oct 19 19:29:05 2011 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 59BE711E80BF; Wed, 19 Oct 2011 19:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPJD2WfYlCP4; Wed, 19 Oct 2011 19:29:01 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E1D0911E80CD; Wed, 19 Oct 2011 19:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lgoldin@cisco.com; l=7703; q=dns/txt; s=iport; t=1319077741; x=1320287341; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=SXxsylKPq13pepMgIdjAPOwiD9jPQ1EFMxOqNuf5L0I=; b=X8ugI1VYQkzaaN9jE8J3zVypperUdhBc+F9OHOoTqybVQiUi0mgv8JVj 4RBb6B3sQ8F3ciG8r3WxZr8eHpfg2mYG/pneDLylWU1tpOsKuBRT5mgm5 ntpdD0d51RACW1Jvn4sRRtimZ3nElfcBr4Q0EIumJUB/CCWx1B+s3lKhE 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4AADKHn06tJXHA/2dsb2JhbABBA4JNlwSPMoEFgW4BAQEBAxIBCREDGTAQAgEIBwoEAQELBhcBBgFFCQgBAQQBEggan0ABnk2FBoI0YQSIApEvjEI X-IronPort-AV: E=Sophos;i="4.69,375,1315180800"; d="scan'208,217";a="29671294" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 20 Oct 2011 02:29:00 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p9K2T0jv012099; Thu, 20 Oct 2011 02:29:00 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Oct 2011 21:29:00 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC8ED0.065860E4" Date: Wed, 19 Oct 2011 21:28:57 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TICTOC] [IPsec] Review request for IPsec security for packet based synchronization (Yang Cui) Thread-Index: AcyOzh05hwElsgQgROSOP8dacTy6jwAAK0Cg References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com><4E96F91E.3020202@ntp.org><4E977D47.5070709@ntp.org><4E9EE450.9010202@ntp.org> From: "Leonid Goldin (lgoldin)" To: "Kevin Gross" , "Stephen Kent" X-OriginalArrivalTime: 20 Oct 2011 02:29:00.0200 (UTC) FILETIME=[069A0280:01CC8ED0] X-Mailman-Approved-At: Thu, 20 Oct 2011 08:36:03 -0700 Cc: ipsec@ietf.org, Nico Williams , TICTOC@ietf.org, Cui Yang , "David L. Mills" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 02:29:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8ED0.065860E4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The encryption and decryption may or may not take the same time. Different manufacturers may have different latency for the same function. Therefore it would be hard to say for sure that the encrypt + decrypt delay in each direction would be the same .=20 my $0.02 Leon =20 From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Kevin Gross Sent: Wednesday, October 19, 2011 10:15 PM To: Stephen Kent Cc: Cui Yang; ipsec@ietf.org; TICTOC@ietf.org; Nico Williams; David L. Mills Subject: Re: [TICTOC] [IPsec] Review request for IPsec security for packet based synchronization (Yang Cui) =20 We don't need decrypt and encrypt to take the same amount of time. We need encrypt+decrypt from master to slave to take the same time as encrypt+decrypt from slave to master. On Wed, Oct 19, 2011 at 9:53 AM, Stephen Kent wrote: At 10:53 AM -0400 10/19/11, Danny Mayer wrote: On 10/18/2011 12:42 PM, Kevin Gross wrote: It does seem reasonable to consider modeling encryption and decryption in as part of network latency. As long as delays introduced are the same each direction, the sync protocols will naturally subtract out this contribution. I very much doubt that encryption and decryption take the same length of time but I'm sure people with experience with this will be able to tell us definitively. Almost certainly you will have asymmetric delays in the network path anyway even if the path is identical in both directions. Danny =20 For most symmetric algs, and many modes of use, the times are the same. The timing tend to differ for asymmetric algs. Steve =20 --=20 Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org =20 =20 ------_=_NextPart_001_01CC8ED0.065860E4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The encryption and decryption may or may not take the = same time. Different manufacturers may have different latency for the same = function. Therefore it would be hard to say for sure that the encrypt + decrypt = delay in each direction would be the same .

my $0.02

Leon

 

From:= = tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Kevin Gross
Sent: Wednesday, October 19, 2011 10:15 PM
To: Stephen Kent
Cc: Cui Yang; ipsec@ietf.org; TICTOC@ietf.org; Nico Williams; = David L. Mills
Subject: Re: [TICTOC] [IPsec] Review request for IPsec security = for packet based synchronization (Yang Cui)

 

We don't need = decrypt and encrypt to take the same amount of time. We need encrypt+decrypt from = master to slave to take the same time as encrypt+decrypt from slave to = master.

On Wed, Oct 19, 2011 at 9:53 AM, Stephen Kent = <kent@bbn.com> wrote:

At 10:53 AM -0400 10/19/11, Danny Mayer = wrote:

On 10/18/2011 12:42 PM, Kevin Gross = wrote:

 It does seem reasonable to consider modeling encryption and decryption
 in as part of network latency. As long as delays introduced are = the same
 each direction, the sync protocols will naturally subtract out = this
 contribution.


I very much doubt that encryption and decryption take the same length = of
time but I'm sure people with experience with this will be able to = tell
us definitively. Almost certainly you will have asymmetric delays in = the
network path anyway even if the path is identical in both = directions.

Danny

 

For most symmetric algs, and many modes of use, the = times are the same.
The timing tend to differ for asymmetric algs.

Steve



 

--
Kevin Gross

+1-303-447-0517

Media Network Consultant

AVA Networks - www.AVAnw.com, www.X192.org

 

 

------_=_NextPart_001_01CC8ED0.065860E4-- From mayer@ntp.org Fri Oct 21 06:01:41 2011 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 3F63021F8C4E; Fri, 21 Oct 2011 06:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FC51oqjM62+1; Fri, 21 Oct 2011 06:01:40 -0700 (PDT) Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by ietfa.amsl.com (Postfix) with ESMTP id B51AC21F8AEA; Fri, 21 Oct 2011 06:01:40 -0700 (PDT) Received: from [198.22.153.6] (helo=[10.60.100.174]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RHEj4-000HQd-7n; Fri, 21 Oct 2011 13:01:31 +0000 Message-ID: <4EA16D22.7050206@ntp.org> Date: Fri, 21 Oct 2011 09:01:22 -0400 From: Danny Mayer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Cui Yang References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E98D17E.8000801@udel.edu> <4E9B9C12.6000505@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB8FC8B@AUSX7MCPC103.AMER.DELL.COM> <4A4385BFBA1BC54C863E7394BD1AECB338AACB0F@SJC-MBX-01.symmetricom.com> <4E9EBB11.5090407@ntp.org> <8CC0CB0BCAE52F46882E17828A9AE21619F98817@SZXEML508-MBS.china.huawei.com> In-Reply-To: <8CC0CB0BCAE52F46882E17828A9AE21619F98817@SZXEML508-MBS.china.huawei.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 198.22.153.6 X-SA-Exim-Rcpt-To: cuiyang@huawei.com, nico@cryptonector.com, tfrost@symmetricom.com, Paul_Koning@dell.com, ipsec@ietf.org, mills@udel.edu, TICTOC@ietf.org, manav.bhatia@alcatel-lucent.com X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: "manav.bhatia@alcatel-lucent.com" , "ipsec@ietf.org" , Tim Frost , "TICTOC@ietf.org" , Nico Williams , "Paul_Koning@Dell.com" , "mills@udel.edu" Subject: Re: [IPsec] =?iso-8859-1?q?=B4=F0=B8=B4=3A_=5BTICTOC=5D__Review_reque?= =?iso-8859-1?q?st_for_IPsec_security_for_packet_based_synchronization_=28?= =?iso-8859-1?q?Yang_Cui=29?= 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 Oct 2011 13:01:41 -0000 On 10/19/2011 10:09 PM, Cui Yang wrote: [...] > 1. Most doubts have been cast on the rationale of encryption. Thanks to comments by Tim and others, this requirement comes from 3GPP spec., as explained in the Introduction, where it says that 3GPP spec. SHALL support encryption/tunnel in backhaul link. If it says SHALL support encryption/tunnel in backhaul link does it say that you MUST use it for timing packets or is it silent on required usage? > > 2. Then the problem arisen is the (intermediate) nodes cannot recognize the timing if using an encrypted IEEE 1588, unless an identifier is attached to such packets. Timing packets with an identifier does not destroy its integrity protection, where ITUT[G.8265] defines security requirements on synchronization, as we described in the draft (Sec. 3). An unauthorized client or a rouge time server without knowing the secret key cannot decrypt the timing information, and thus cannot benefit from the protocol. Noone cares about an unauthorized client. In NTP at least a rogue time server would have its packets dropped because it would be so out-of-line with other NTP servers sending NTP packets, irrespective of whether or not they have access to the secret key. Even with autokey enabled NTP won't accept falseticker packets. > > 3. Identified timing packets gives a little more information to attackers than normal, considering DoS attack, but it is out of the scope of this draft and can hardly be prevented. If an attacker is willing to focus on dropping packets or blocking traffic, I am afraid that most of current security countermeasures are useless. Similarly, any intentional delay by attackers can mislead the client to receive a false timing. In contrast, latency from crypto operations can be measured easily. An intentionally delayed packet or a false timing packet in NTP would be automatically dropped and the clock would continue to be disciplined as normal. While you can never totally defend against a DOS attack, NTP can continue for hours if not days (depending on the quality of the clock crystal) and keep accurate time. If you are concerned about this use OCXO clock crystals which are much more stable long-term and will be better if you are concerned about receiving good truechimer NTP packets. > > 4. Hardware based protocol, timestamping on all packets, will lead > to an unacceptable performance down of Femtocell, due to our experimental results. So, it is not correct to claim that "if you can timestamp some packet, then you can timestamp all", at least from a performance point of view. It does not satisfy our requirement 3(Sec. 3), as well. You *can* timestamp all packets. The real question here is whether or not the hardware and software can handle it and whether it solves the problem and is of benefit. Danny From mayer@ntp.org Fri Oct 21 06:14:24 2011 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 DB93621F8C53; Fri, 21 Oct 2011 06:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jokYmC1kgl-F; Fri, 21 Oct 2011 06:14:23 -0700 (PDT) Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by ietfa.amsl.com (Postfix) with ESMTP id 1574521F8C44; Fri, 21 Oct 2011 06:14:23 -0700 (PDT) Received: from [198.22.153.6] (helo=[10.60.100.174]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RHEvT-000HTa-QD; Fri, 21 Oct 2011 13:14:20 +0000 Message-ID: <4EA17025.9090502@ntp.org> Date: Fri, 21 Oct 2011 09:14:13 -0400 From: Danny Mayer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Cui Yang References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E98D17E.8000801@udel.edu> <4E9B9C12.6000505@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB8FC8B@AUSX7MCPC103.AMER.DELL.COM> <4A4385BFBA1BC54C863E7394BD1AECB338AACB0F@SJC-MBX-01.symmetricom.com> <4E9EBB11.5090407@ntp.org> <8CC0CB0BCAE52F46882E17828A9AE21619F98885@SZXEML508-MBS.china.huawei.com> In-Reply-To: <8CC0CB0BCAE52F46882E17828A9AE21619F98885@SZXEML508-MBS.china.huawei.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 198.22.153.6 X-SA-Exim-Rcpt-To: cuiyang@huawei.com, kevin.gross@avanw.com, nico@cryptonector.com, ipsec@ietf.org, TICTOC@ietf.org, Paul_Koning@dell.com, mills@udel.edu X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: Kevin Gross , "ipsec@ietf.org" , "TICTOC@ietf.org" , Nico Williams , "Paul_Koning@Dell.com" , "mills@udel.edu" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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 Oct 2011 13:14:24 -0000 On 10/20/2011 1:39 AM, Cui Yang wrote: > As I have noted in the last email, timestamping all packets is too costly to afford to. We have done some experiments on our products, the degrading of performance is unacceptable. That is why we need to distinguish 1588 packet from others with high priority, and is the crucial reason that we equip WESP with identifier. Costly in what way? Hardware, implementation, something else? Can you expand on this? Danny From ynir@checkpoint.com Sun Oct 23 14:37:15 2011 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 F3F2C21F8B4C for ; Sun, 23 Oct 2011 14:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjxxKpG+8sdf for ; Sun, 23 Oct 2011 14:37:14 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id EC32F21F8B4B for ; Sun, 23 Oct 2011 14:37:13 -0700 (PDT) X-CheckPoint: {4EA488B9-1000A-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p9NLbA3I016564; Sun, 23 Oct 2011 23:37:10 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sun, 23 Oct 2011 23:37:10 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sun, 23 Oct 2011 23:37:10 +0200 From: Yoav Nir To: "Ulliott, Chris" , Michael Richardson , "ipsec@ietf.org" Date: Sun, 23 Oct 2011 23:37:07 +0200 Thread-Topic: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement Thread-Index: AcyRy+ruL581+Vq+S7mxfB1XdS4ogg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled X-KSE-Antivirus-Interceptor-Info: scan successful X-KSE-Antivirus-Info: Clean Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 21:37:15 -0000 Hi Chris As I've asked you off-list, I'm still trying to understand the initial condition. It's one thing if Za believes that "host 2" is behind *some* gateway, and it's only a matter of finding out which gateway that is. It's a different thing if "host 2" might also be not behind any gateway at all. In that case policy should either say that the packet should be dropped, or it should say that the packet should be forwarded unencrypted (BYPASS in RFC 4301 language). There is a subset of the Internet where Za can encrypt traffic. Is Za pre-configured with that subset? Yoav On 10/17/11 1:39 PM, "Ulliott, Chris" wrote: >The challenge for us is around discovery of the next cryptographic hop >combined with the increase use of VoIP and other protocols that need peer >to peer connectivity / low latency etc. > >If I'm sat behind a gateway and send a packet to a.b.c.d - my gateway >needs to perform a lookup to find out who it needs to establish an SA >with before it can encrypt the packet and send it on its way. To my >knowledge, there is not standard way of discovering this (although I'll >happily be corrected!) > >For example... (and I hope the ASCII art works!) > >Host 1 --> R --> Za --> R --> R --> Zb --> R --> Host 2 > >(Where R is a router and Zx is a crypto) > >Host 1 send a packet to Host 2, it's routed to the gateway Za as normal, >but at this point Za needs to work out which remote endpoint to establish >an SA with. In this case it's Zb - but the traditional way to achieve >this is through static configuration which doesn't scale if you want to >run fully meshed networks (we have thousands of nodes). When Zb received >the packet it decrypts and forwards to Host 2. > >When you add resilience, this gets even more complicate, for example: > >Host 1 --> R --> Za --> R --> R --> Zb --> R --> Host 2 > | --------> Zc --> R ------^ > >Packets for Host two can be sent via Zb or Zc, how does Za make that >decision? In this example Zc is less hops away so would make more sense >unless it wasn't available. > >Our interest also throws in the problem of multiple administrative >domains. We have numerous sites, but IT is provisioned by differing >integrators. Any standard should (in our opinion) enable this to still >work. At the moment, commercial solutions for meshed VPN's assume that >all the cryptographic devices are run by the same team. > >I hope that helps! > >Chris From Masanobu.Katagi@jp.sony.com Mon Oct 24 02:11:09 2011 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 A74AC21F84A4 for ; Mon, 24 Oct 2011 02:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id il4wXOP-A2tu for ; Mon, 24 Oct 2011 02:11:08 -0700 (PDT) Received: from ms6.sony.co.jp (ms6.sony.co.jp [IPv6:2001:cf8:0:56::204]) by ietfa.amsl.com (Postfix) with ESMTP id 9026521F8485 for ; Mon, 24 Oct 2011 02:11:08 -0700 (PDT) Received: from mta6.sony.co.jp (mta6.sony.co.jp [137.153.71.9]) by ms6.sony.co.jp (R8/Sony) with ESMTP id p9O9At1E012968 for ; Mon, 24 Oct 2011 18:10:55 +0900 (JST) Received: from mta6.sony.co.jp (localhost [127.0.0.1]) by mta6.sony.co.jp (R8/Sony) with ESMTP id p9O9AtoF011561 for ; Mon, 24 Oct 2011 18:10:55 +0900 (JST) Received: from jptkyxbh102.jp.sony.com ([43.15.31.4]) by mta6.sony.co.jp (R8/Sony) with ESMTP id p9O9At9r011509 for ; Mon, 24 Oct 2011 18:10:55 +0900 (JST) Received: from jptkyxim101.jp.sony.com ([43.15.31.5]) by jptkyxbh102.jp.sony.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Oct 2011 18:10:48 +0900 Received: from [43.11.214.45] ([43.11.214.45]) by jptkyxim101.jp.sony.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Oct 2011 18:10:48 +0900 Date: Mon, 24 Oct 2011 18:13:18 +0900 From: Masanobu Katagi To: "ipsec@ietf.org" Message-Id: <20111024181318.AF71.1C812BE2@jp.sony.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Mailer: Becky! ver. 2.51.07 [ja] (Unregistered) X-OriginalArrivalTime: 24 Oct 2011 09:10:48.0101 (UTC) FILETIME=[D1AEC550:01CC922C] Cc: Masanobu.Katagi@jp.sony.com, shiho.moriai@jp.sony.com Subject: [IPsec] Fw: New Version Notification for draft-katagi-ipsecme-clefia-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, 24 Oct 2011 09:11:10 -0000 Hi all, I have submitted a new version of the Internet draft about using CLEFIA in IPsec and IKE. This draft is available at http://tools.ietf.org/html/draft-katagi-ipsecme-clefia-00. CLEFIA is a 128-bit block cipher, which is designed in 2007. The security of CLEFIA has been well evaluated through the CRYPTREC project for the revision of the e-Government recommended ciphers list in Japan. CLEFIA is also included in the Final Draft International Standard of ISO/IEC 29192-2 (Lightweight cryptography). CLEFIA offers high performance both in software and hardware. Especially, CLEFIA has advantages in efficient hardware implementation over AES. I believe that CLEFIA will contribute to efficiency of IPsec. Any feedback will be appreciated. Best regards, Masanobu Katagi Sony Corporation Forwarded by Masanobu Katagi ----------------------- Original Message ----------------------- From: "internet-drafts@ietf.org" To: "Katagi, Masanobu" Cc: "Katagi, Masanobu" , "Moriai, Shiho" Date: Sat, 22 Oct 2011 15:26:28 +0900 Subject: New Version Notification for draft-katagi-ipsecme-clefia-00.txt ---- A new version of I-D, draft-katagi-ipsecme-clefia-00.txt has been successfully submitted by Masanobu Katagi and posted to the IETF repository. Filename: draft-katagi-ipsecme-clefia Revision: 00 Title: The CLEFIA Cipher Algorithm and Its Use with IPsec Creation date: 2011-10-22 WG ID: Individual Submission Number of pages: 14 Abstract: This document describes the use of the CLEFIA block cipher algorithm in conjunction with several different modes of operation within IKE and IPsec. The IETF Secretariat --------------------- Original Message Ends -------------------- From Chris.Ulliott@cesg.gsi.gov.uk Mon Oct 24 04:53:00 2011 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 2907A21F8C54 for ; Mon, 24 Oct 2011 04:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yzouYsQTTcc for ; Mon, 24 Oct 2011 04:52:59 -0700 (PDT) Received: from mail89.messagelabs.com (mail89.messagelabs.com [194.106.220.3]) by ietfa.amsl.com (Postfix) with SMTP id ABAC021F85AA for ; Mon, 24 Oct 2011 04:52:58 -0700 (PDT) X-Env-Sender: Chris.Ulliott@cesg.gsi.gov.uk X-Msg-Ref: server-8.tower-89.messagelabs.com!1319457176!39342168!1 X-Originating-IP: [62.25.106.208] X-StarScan-Version: 6.3.6; banners=cesg.gsi.gov.uk,-,- X-VirusChecked: Checked Received: (qmail 24626 invoked from network); 24 Oct 2011 11:52:56 -0000 Received: from gateway-102.energis.gsi.gov.uk (HELO mx.hosting-w.gsi.gov.uk) (62.25.106.208) by server-8.tower-89.messagelabs.com with SMTP; 24 Oct 2011 11:52:56 -0000 From: "Ulliott, Chris" To: 'Yoav Nir' , Michael Richardson , "ipsec@ietf.org" Date: Mon, 24 Oct 2011 12:52:49 +0100 Thread-Topic: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement Thread-Index: AcyRy+ruL581+Vq+S7mxfB1XdS4oggAdvzJg Message-ID: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 11:53:00 -0000 Yoav... the answer is either! Za needs to pass a packet to Host 2, it may = be between a gateway, may be running IPSec itself, or may be unable to rec= eive encrypted packets at all. As with RFC 4322, you would need a policy = to determine behaviour when an encrypted channel can't be achieved, but th= e solution needs to enable Za to discover if there are available cryptogra= phic routes, then make decisions based on the results combined with a poli= cy. I hope that helps! Chris -----Original Message----- From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Sunday, October 23, 2011 10:37 PM To: Ulliott, Chris; Michael Richardson; ipsec@ietf.org Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem= Statement Hi Chris As I've asked you off-list, I'm still trying to understand the initial condition. It's one thing if Za believes that "host 2" is behind *some* gateway, and it's only a matter of finding out which gateway that is. It's a different thing if "host 2" might also be not behind any gateway at= all. In that case policy should either say that the packet should be dropped, or it should say that the packet should be forwarded unencrypted (BYPASS in RFC 4301 language). There is a subset of the Internet where Za can encrypt traffic. Is Za pre-configured with that subset? Yoav On 10/17/11 1:39 PM, "Ulliott, Chris" wrote: >The challenge for us is around discovery of the next cryptographic hop >combined with the increase use of VoIP and other protocols that need peer= >to peer connectivity / low latency etc. > >If I'm sat behind a gateway and send a packet to a.b.c.d - my gateway >needs to perform a lookup to find out who it needs to establish an SA >with before it can encrypt the packet and send it on its way. To my >knowledge, there is not standard way of discovering this (although I'll >happily be corrected!) > >For example... (and I hope the ASCII art works!) > >Host 1 --> R --> Za --> R --> R --> Zb --> R --> Host 2 > >(Where R is a router and Zx is a crypto) > >Host 1 send a packet to Host 2, it's routed to the gateway Za as normal, >but at this point Za needs to work out which remote endpoint to establish= >an SA with. In this case it's Zb - but the traditional way to achieve >this is through static configuration which doesn't scale if you want to >run fully meshed networks (we have thousands of nodes). When Zb received= >the packet it decrypts and forwards to Host 2. > >When you add resilience, this gets even more complicate, for example: > >Host 1 --> R --> Za --> R --> R --> Zb --> R --> Host 2 > | --------> Zc --> R ------^ > >Packets for Host two can be sent via Zb or Zc, how does Za make that >decision? In this example Zc is less hops away so would make more sense >unless it wasn't available. > >Our interest also throws in the problem of multiple administrative >domains. We have numerous sites, but IT is provisioned by differing >integrators. Any standard should (in our opinion) enable this to still >work. At the moment, commercial solutions for meshed VPN's assume that >all the cryptographic devices are run by the same team. > >I hope that helps! > >Chris **************************************************************************= ** Communications with GCHQ may be monitored and/or recorded=20 for system efficiency and other lawful purposes. Any views or=20 opinions expressed in this e-mail do not necessarily reflect GCHQ=20 policy. This email, and any attachments, is intended for the=20 attention of the addressee(s) only. Its unauthorised use,=20 disclosure, storage or copying is not permitted. If you are not the intended recipient, please notify postmaster@gchq.gsi.gov.uk. =20 This information is exempt from disclosure under the Freedom of=20 Information Act 2000 and may be subject to exemption under other UK information legislation. Refer disclosure requests to=20 GCHQ on 01242 221491 ext 30306 (non-secure) or email infoleg@gchq.gsi.gov.uk **************************************************************************= ** The original of this email was scanned for viruses by the Government Secur= e Intranet virus scanning service supplied by Cable&Wireless Worldwide in = partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On l= eaving the GSi this email was certified virus free. Communications via the GSi may be automatically logged, monitored and/or r= ecorded for legal purposes. From ynir@checkpoint.com Mon Oct 24 05:16:59 2011 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 56C1D21F8D20 for ; Mon, 24 Oct 2011 05:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.516 X-Spam-Level: X-Spam-Status: No, score=-10.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ApPv-65T07l for ; Mon, 24 Oct 2011 05:16:58 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id DB44D21F8D1C for ; Mon, 24 Oct 2011 05:16:52 -0700 (PDT) X-CheckPoint: {4EA556E3-10007-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p9OCGnt2020617; Mon, 24 Oct 2011 14:16:49 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 24 Oct 2011 14:16:49 +0200 From: Yoav Nir To: "Ulliott, Chris" , Michael Richardson , "ipsec@ietf.org" Date: Mon, 24 Oct 2011 14:16:50 +0200 Thread-Topic: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement Thread-Index: AcySRs3KrFh54Ot3TVmaR65SEYLp6w== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 12:16:59 -0000 It does. But then, both I and MCR agree that RFC 4322 in its present form is not the answer, but a second edition (as in "rfc4322bis") might be. Do you think a discovery process based on DNS could be acceptable? I have never registered a domain, but I know how one could publish records for an FQDN. I have no idea how I (or an administrator) could get to add records to the reverse registry. RFC 4322 acknowledges this, and suggests an alternative - add the records to the FQDN of the host. But in general networking, we don't have FQDNs for hosts. Anyway, we seem to be doing the engineer thing of jumping right to the solution. We're currently at the problem statement phase. MCR: are you going to be in Taipei? Yoav On 10/24/11 1:52 PM, "Ulliott, Chris" wrote: >Yoav... the answer is either! Za needs to pass a packet to Host 2, it may >be between a gateway, may be running IPSec itself, or may be unable to >receive encrypted packets at all. As with RFC 4322, you would need a >policy to determine behaviour when an encrypted channel can't be >achieved, but the solution needs to enable Za to discover if there are >available cryptographic routes, then make decisions based on the results >combined with a policy. > >I hope that helps! > >Chris > >-----Original Message----- >From: Yoav Nir [mailto:ynir@checkpoint.com] >Sent: Sunday, October 23, 2011 10:37 PM >To: Ulliott, Chris; Michael Richardson; ipsec@ietf.org >Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs >Problem Statement > >Hi Chris > >As I've asked you off-list, I'm still trying to understand the initial >condition. > >It's one thing if Za believes that "host 2" is behind *some* gateway, and >it's only a matter of finding out which gateway that is. > >It's a different thing if "host 2" might also be not behind any gateway at >all. In that case policy should either say that the packet should be >dropped, or it should say that the packet should be forwarded unencrypted >(BYPASS in RFC 4301 language). > >There is a subset of the Internet where Za can encrypt traffic. Is Za >pre-configured with that subset? > >Yoav > >On 10/17/11 1:39 PM, "Ulliott, Chris" >wrote: > >>The challenge for us is around discovery of the next cryptographic hop >>combined with the increase use of VoIP and other protocols that need peer >>to peer connectivity / low latency etc. >> >>If I'm sat behind a gateway and send a packet to a.b.c.d - my gateway >>needs to perform a lookup to find out who it needs to establish an SA >>with before it can encrypt the packet and send it on its way. To my >>knowledge, there is not standard way of discovering this (although I'll >>happily be corrected!) >> >>For example... (and I hope the ASCII art works!) >> >>Host 1 --> R --> Za --> R --> R --> Zb --> R --> Host 2 >> >>(Where R is a router and Zx is a crypto) >> >>Host 1 send a packet to Host 2, it's routed to the gateway Za as normal, >>but at this point Za needs to work out which remote endpoint to establish >>an SA with. In this case it's Zb - but the traditional way to achieve >>this is through static configuration which doesn't scale if you want to >>run fully meshed networks (we have thousands of nodes). When Zb received >>the packet it decrypts and forwards to Host 2. >> >>When you add resilience, this gets even more complicate, for example: >> >>Host 1 --> R --> Za --> R --> R --> Zb --> R --> Host 2 >> | --------> Zc --> R ------^ >> >>Packets for Host two can be sent via Zb or Zc, how does Za make that >>decision? In this example Zc is less hops away so would make more sense >>unless it wasn't available. >> >>Our interest also throws in the problem of multiple administrative >>domains. We have numerous sites, but IT is provisioned by differing >>integrators. Any standard should (in our opinion) enable this to still >>work. At the moment, commercial solutions for meshed VPN's assume that >>all the cryptographic devices are run by the same team. >> >>I hope that helps! >> >>Chris > > >************************************************************************** >** >Communications with GCHQ may be monitored and/or recorded >for system efficiency and other lawful purposes. Any views or >opinions expressed in this e-mail do not necessarily reflect GCHQ >policy. This email, and any attachments, is intended for the >attention of the addressee(s) only. Its unauthorised use, >disclosure, storage or copying is not permitted. If you are not the >intended recipient, please notify postmaster@gchq.gsi.gov.uk. > >This information is exempt from disclosure under the Freedom of >Information Act 2000 and may be subject to exemption under >other UK information legislation. Refer disclosure requests to >GCHQ on 01242 221491 ext 30306 (non-secure) or email >infoleg@gchq.gsi.gov.uk > >************************************************************************** >** > > >The original of this email was scanned for viruses by the Government >Secure Intranet virus scanning service supplied by Cable&Wireless >Worldwide in partnership with MessageLabs. (CCTM Certificate Number >2009/09/0052.) On leaving the GSi this email was certified virus free. >Communications via the GSi may be automatically logged, monitored and/or >recorded for legal purposes. > >Scanned by Check Point Total Security Gateway. From mcr@sandelman.ca Mon Oct 24 06:59:42 2011 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 9CB0921F8DA0 for ; Mon, 24 Oct 2011 06:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yq5vc6ih02kC for ; Mon, 24 Oct 2011 06:59:41 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0266121F8DA9 for ; Mon, 24 Oct 2011 06:59:40 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id E2B27343CB; Mon, 24 Oct 2011 09:58:25 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id DB8BF98C90; Mon, 24 Oct 2011 10:00:34 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id D3FC798B2E; Mon, 24 Oct 2011 10:00:34 -0400 (EDT) From: Michael Richardson To: "ipsec@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Mon, 24 Oct 2011 10:00:34 -0400 Message-ID: <14515.1319464834@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: "Ulliott, Chris" Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 13:59:42 -0000 I was not intending to be, (I have no ticket as yet), but plans might change. It seems like Chris has all of the requirements of OE, and there is all of the challenges. IPv6 and homenet might well provide FDQNs for hosts, and a trusted path to update the reverse. If DNS does not work for you, then you need another trusted introducer, and there have been many proposals out there for doing this kind of thing. None of taken off and hit the elbow of exponential growth. >>>>> "Yoav" == Yoav Nir writes: Yoav> It does. Yoav> But then, both I and MCR agree that RFC 4322 in its present form is not Yoav> the answer, but a second edition (as in "rfc4322bis") might be. Yoav> Do you think a discovery process based on DNS could be acceptable? I have Yoav> never registered a domain, but I know how one could publish records for an Yoav> FQDN. I have no idea how I (or an administrator) could get to add records Yoav> to the reverse registry. RFC 4322 acknowledges this, and suggests an Yoav> alternative - add the records to the FQDN of the host. But in general Yoav> networking, we don't have FQDNs for hosts. Yoav> Anyway, we seem to be doing the engineer thing of jumping right to the Yoav> solution. We're currently at the problem statement phase. Yoav> MCR: are you going to be in Taipei? Yoav> Yoav Yoav> On 10/24/11 1:52 PM, "Ulliott, Chris" Yoav> wrote: >> Yoav... the answer is either! Za needs to pass a packet to Host 2, it may >> be between a gateway, may be running IPSec itself, or may be unable to >> receive encrypted packets at all. As with RFC 4322, you would need a >> policy to determine behaviour when an encrypted channel can't be >> achieved, but the solution needs to enable Za to discover if there are >> available cryptographic routes, then make decisions based on the results >> combined with a policy. >> >> I hope that helps! >> >> Chris >> >> -----Original Message----- Yoav> From: Yoav Nir [mailto:ynir@checkpoint.com] >> Sent: Sunday, October 23, 2011 10:37 PM >> To: Ulliott, Chris; Michael Richardson; ipsec@ietf.org >> Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs >> Problem Statement >> >> Hi Chris >> >> As I've asked you off-list, I'm still trying to understand the initial >> condition. >> >> It's one thing if Za believes that "host 2" is behind *some* gateway, and >> it's only a matter of finding out which gateway that is. >> >> It's a different thing if "host 2" might also be not behind any gateway at >> all. In that case policy should either say that the packet should be >> dropped, or it should say that the packet should be forwarded unencrypted >> (BYPASS in RFC 4301 language). >> >> There is a subset of the Internet where Za can encrypt traffic. Is Za >> pre-configured with that subset? >> >> Yoav >> >> On 10/17/11 1:39 PM, "Ulliott, Chris" >> wrote: >> >>> The challenge for us is around discovery of the next cryptographic hop >>> combined with the increase use of VoIP and other protocols that need peer >>> to peer connectivity / low latency etc. >>> >>> If I'm sat behind a gateway and send a packet to a.b.c.d - my gateway >>> needs to perform a lookup to find out who it needs to establish an SA >>> with before it can encrypt the packet and send it on its way. To my >>> knowledge, there is not standard way of discovering this (although I'll >>> happily be corrected!) >>> >>> For example... (and I hope the ASCII art works!) >>> >>> Host 1 --> R --> Za --> R --> R --> Zb --> R --> Host 2 >>> >>> (Where R is a router and Zx is a crypto) >>> >>> Host 1 send a packet to Host 2, it's routed to the gateway Za as normal, >>> but at this point Za needs to work out which remote endpoint to establish >>> an SA with. In this case it's Zb - but the traditional way to achieve >>> this is through static configuration which doesn't scale if you want to >>> run fully meshed networks (we have thousands of nodes). When Zb received >>> the packet it decrypts and forwards to Host 2. >>> >>> When you add resilience, this gets even more complicate, for example: >>> >>> Host 1 --> R --> Za --> R --> R --> Zb --> R --> Host 2 >>> | --------> Zc --> R ------^ >>> >>> Packets for Host two can be sent via Zb or Zc, how does Za make that >>> decision? In this example Zc is less hops away so would make more sense >>> unless it wasn't available. >>> >>> Our interest also throws in the problem of multiple administrative >>> domains. We have numerous sites, but IT is provisioned by differing >>> integrators. Any standard should (in our opinion) enable this to still >>> work. At the moment, commercial solutions for meshed VPN's assume that >>> all the cryptographic devices are run by the same team. >>> >>> I hope that helps! >>> >>> Chris >> >> >> ************************************************************************** >> ** >> Communications with GCHQ may be monitored and/or recorded >> for system efficiency and other lawful purposes. Any views or >> opinions expressed in this e-mail do not necessarily reflect GCHQ >> policy. This email, and any attachments, is intended for the >> attention of the addressee(s) only. Its unauthorised use, >> disclosure, storage or copying is not permitted. If you are not the >> intended recipient, please notify postmaster@gchq.gsi.gov.uk. >> >> This information is exempt from disclosure under the Freedom of >> Information Act 2000 and may be subject to exemption under >> other UK information legislation. Refer disclosure requests to >> GCHQ on 01242 221491 ext 30306 (non-secure) or email >> infoleg@gchq.gsi.gov.uk >> >> ************************************************************************** >> ** >> >> >> The original of this email was scanned for viruses by the Government >> Secure Intranet virus scanning service supplied by Cable&Wireless >> Worldwide in partnership with MessageLabs. (CCTM Certificate Number >> 2009/09/0052.) On leaving the GSi this email was certified virus free. >> Communications via the GSi may be automatically logged, monitored and/or >> recorded for legal purposes. >> >> Scanned by Check Point Total Security Gateway. From prbatra@cisco.com Mon Oct 24 09:11:14 2011 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 AADF621F88B6 for ; Mon, 24 Oct 2011 09:11:14 -0700 (PDT) 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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KalB4D66h5vT for ; Mon, 24 Oct 2011 09:11:13 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 754A321F8D00 for ; Mon, 24 Oct 2011 09:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=prbatra@cisco.com; l=3282; q=dns/txt; s=iport; t=1319472673; x=1320682273; h=mime-version:subject:date:message-id:from:to; bh=Q26YthiUkHljPMWSAWt1i8EBZw7GXv1bXA0oRorOUuI=; b=X1zojELMSFvasrwvDTit2HJzgIwFCI7IYa6vfvUK0sCeto9nokiDmU9t RGQMR+MqWQIZ54kLwFv9vpiM2bsnmZbXhqnCQU9McovcrutG0z33gcFlo UmFEM7aqDVmDlcnltB25ZbSSBd38BpoKlXs91vwAaKGPx8BU1IhUD485Z g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8HAG+NpU5Io8UT/2dsb2JhbABDgk2XR45+gQWBcAEBAxIBCREDWwEMHgYYB1cBBAsQGpwogSYBng+HX2EEiASROowu X-IronPort-AV: E=Sophos;i="4.69,399,1315180800"; d="scan'208,217";a="119874334" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 24 Oct 2011 16:11:11 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9OGBBQk020777 for ; Mon, 24 Oct 2011 16:11:11 GMT Received: from xmb-bgl-419.cisco.com ([72.163.129.215]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Oct 2011 21:41:10 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: b20= 2ws= AGTO A4qF BnXn CV33 CXIe EtUS Ezij FHie FUbg GlgI IA/4 Ijw+ I9lw LZW7; 1; aQBwAHMAZQBjAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {5927EF22-47DC-4FF1-B412-713F017DC00D}; cAByAGIAYQB0AHIAYQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Mon, 24 Oct 2011 16:11:06 GMT; ZQBhAHAALQBtAGQANQAgAGIAYQBzAGUAZAAgAGEAdQB0AGgAZQBuAHQAaQBjAGEAdABpAG8AbgA= MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC9267.8B5EED5E" x-cr-puzzleid: {5927EF22-47DC-4FF1-B412-713F017DC00D} Content-class: urn:content-classes:message Date: Mon, 24 Oct 2011 21:41:06 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: eap-md5 based authentication Thread-Index: AcySZ4jfbp85XhqtQZOVC/WpALfLMQ== From: "Prashant Batra (prbatra)" To: X-OriginalArrivalTime: 24 Oct 2011 16:11:10.0947 (UTC) FILETIME=[8BABA330:01CC9267] Subject: [IPsec] eap-md5 based authentication 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, 24 Oct 2011 16:11:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC9267.8B5EED5E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 I am facing some problem in calculating md5-challenge response. What I am doing is simply MD5(Identifier | | ). The challenge response is somehow wrong. =20 Is it correct to say that Challenge value used as input to md5 is the same value what is in the EAP payload (type md5-challenge request)? =20 Regards, Prashant =20 ------_=_NextPart_001_01CC9267.8B5EED5E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I am facing some problem in calculating = md5-challenge response.

What I am doing is simply MD5(Identifier | = <secret> | <Challenge value received in the challenge request>).

The challenge response is somehow = wrong.

 

Is it correct to say that Challenge value used as = input to md5 is the same value what is in the EAP payload (type md5-challenge = request)?

 

Regards,

Prashant

 

------_=_NextPart_001_01CC9267.8B5EED5E-- From kent@bbn.com Mon Oct 24 10:04:40 2011 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 E820321F8BCD; Mon, 24 Oct 2011 10:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.425 X-Spam-Level: X-Spam-Status: No, score=-106.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDidN1+HfTwV; Mon, 24 Oct 2011 10:04:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id E00FE21F8BC5; Mon, 24 Oct 2011 10:04:39 -0700 (PDT) Received: from dhcp89-089-093.bbn.com ([128.89.89.93]:49284) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RINwx-0006ts-72; Mon, 24 Oct 2011 13:04:35 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E9EE450.9010202@ntp.org> Date: Mon, 24 Oct 2011 13:04:13 -0400 To: Kevin Gross From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Cui Yang , Danny Mayer , "ipsec@ietf.org" , "TICTOC@ietf.org" , Nico Williams , "David L. Mills" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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, 24 Oct 2011 17:04:41 -0000 At 8:15 PM -0600 10/19/11, Kevin Gross wrote: >We don't need decrypt and encrypt to take the same amount of time. >We need encrypt+decrypt from master to slave to take the same time >as encrypt+decrypt from slave to master. That further reduces the likely variance that is algorithm or mode specific, but it does increase the potential for variance due to differences in the processing capabilities of masters and slaves. Steve From nico@cryptonector.com Mon Oct 24 10:42:47 2011 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 6EA0211E80AA; Mon, 24 Oct 2011 10:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aJE2rkuqWmF; Mon, 24 Oct 2011 10:42:46 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id C292811E8080; Mon, 24 Oct 2011 10:42:46 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id ACC8620204F; Mon, 24 Oct 2011 10:42:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=p9yphLFtDwfQ162C5y3rd606XeHgRWq8WTRl9BEPPm+k hp6M0lYB3fdMJmhrr0oZzLEcToSe2u40KNenYKwqXcpzg40WIPjU4Y0BvQLa1MJH rJYRbu2Ke6EKiIFhhwb9Ao2B7ovg9tCmnYLWyv9PyAHsj5UpF+yKv/E3JFmGF4U= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=gSB4tkbMQQZeDne4/VQQKgP8Ecc=; b=t/Ia+u7d2KW muYYRuxknYq/9aEKhbUPj0mUkPr3KsPcD2/jA92JPF2oTJu3KswdSgAhVnhnoXG2 cngvlotRdI1+GCdFb3l9+nCXlIya3wsWr1O5SIpQtKxCLl10aFpggQTaFtmwxuf5 cwb0z+WPIkGjyC2cqC8lmG6T21d/RetY= Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id BF67C20204B; Mon, 24 Oct 2011 10:42:14 -0700 (PDT) Received: by ywt2 with SMTP id 2so3026142ywt.31 for ; Mon, 24 Oct 2011 10:42:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.156.1 with SMTP id wa1mr49341336pbb.58.1319478133241; Mon, 24 Oct 2011 10:42:13 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Mon, 24 Oct 2011 10:42:13 -0700 (PDT) In-Reply-To: <4A4385BFBA1BC54C863E7394BD1AECB338AACB0F@SJC-MBX-01.symmetricom.com> References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E98D17E.8000801@udel.edu> <4E9B9C12.6000505@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB8FC8B@AUSX7MCPC103.AMER.DELL.COM> <4A4385BFBA1BC54C863E7394BD1AECB338AACB0F@SJC-MBX-01.symmetricom.com> Date: Mon, 24 Oct 2011 12:42:13 -0500 Message-ID: From: Nico Williams To: Tim Frost Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "cuiyang@huawei.com" , "mayer@ntp.org" , "ipsec@ietf.org" , "TICTOC@ietf.org" , "Paul_Koning@Dell.com" , "mills@udel.edu" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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, 24 Oct 2011 17:42:47 -0000 On Tue, Oct 18, 2011 at 10:37 AM, Tim Frost wrote: > I think most of the reviewers are missing the point of this draft. > > The point is not that the timing packets are inherently secret and need e= ncryption, but that the 3GPP architecture mandates that EVERYTHING flowing = to the femtocell must be inside a secure tunnel, whether the security is ne= eded or not. It's a wider architecture issue, not the issue about whether e= ncryption is needed and how best to do it. "Everything"?? Some bits can't be in a tunnel. For example, the outer IP headers. Obviously some bits of IKE also go in the clear. What exactly is "everything" intended to encompass? It can't be truly all bits. At most it can only be "all bits that can be tunneled". I don't see why timing signals need to be protected by IPsec if they can carry their own cryptographic protection. I know very little about IEEE 1588 (PTP), but if there's any way that it can provide its own security protocol[*] then I think it'd be fair to keep PTP out of the "everything" that must be tunneled. OTOH, if PTP lacks sufficient security functionality, then my suggestions would be to either use NTP or else we'll all have to hold our noses for the proposed solution. Is PTP mandated for Femtocell as well? [*] The paper "Security Flaws and Workarounds for IEEE 1588 (Transparent) Clocks" by A. Treytl and B. Hirschler tells me that PTP does have a secure mode and that it's not very good. Have those issues been addressed since? Nico -- From nico@cryptonector.com Mon Oct 24 14:02:03 2011 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 0D55321F8ACE; Mon, 24 Oct 2011 14:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D60oUFWeHWS7; Mon, 24 Oct 2011 14:02:02 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 4C21521F8AC3; Mon, 24 Oct 2011 14:02:02 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id D28677E407D; Mon, 24 Oct 2011 14:01:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=x/ThK/qoBTnbLIjnvfU9iHGa3UET8WBTQNHUxz9PweaR BgdmFTsGtol6y7TjQ84zzbg0X2zrzpFvdrzZROKBLwNjwMou37RsJDPsIqfemzqO xG0dqOfKlxzX5j3mCeCGlh5qdsgyaDngS+JQfR9iMvxzCIsVYpiMMxRjVsPLYIM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=Xd+g3Ycb8y/IY8B7YlDI8Awtn8k=; b=czOq9XBizXQ Qn9OjF0fpyWs5TI9VOYZyD/yXHesfW6fRexNnqeT6jTNMwcnErwC935BJNOrm0VC SVWtQ2/TEl9rSY55iWgt/LC9SoKRQO143w8Q64wr+d3nhVJQMQM7DNYTx1dXDLfG B4X34Z13k0CQxlIUAIiS8OSBQFLJHlyQ= Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id 46A037E405D; Mon, 24 Oct 2011 14:01:15 -0700 (PDT) Received: by yxi11 with SMTP id 11so2078297yxi.31 for ; Mon, 24 Oct 2011 14:01:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.35.129 with SMTP id h1mr46102513pbj.92.1319490074614; Mon, 24 Oct 2011 14:01:14 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Mon, 24 Oct 2011 14:01:14 -0700 (PDT) In-Reply-To: References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E98D17E.8000801@udel.edu> <4E9B9C12.6000505@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB8FC8B@AUSX7MCPC103.AMER.DELL.COM> <4A4385BFBA1BC54C863E7394BD1AECB338AACB0F@SJC-MBX-01.symmetricom.com> Date: Mon, 24 Oct 2011 16:01:14 -0500 Message-ID: From: Nico Williams To: Doug Arnold Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "cuiyang@huawei.com" , "ipsec@ietf.org" , Tim Frost , "TICTOC@ietf.org" , "Paul_Koning@Dell.com" , "mills@udel.edu" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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, 24 Oct 2011 21:02:03 -0000 On Mon, Oct 24, 2011 at 1:38 PM, Doug Arnold wrot= e: > This debate has been going on since before the PTP v2 standard was releas= ed, and the consensus in the timing community agrees with you. =C2=A0Timing= packets do not need to be encrypted. =C2=A0Authentication would be a more = appropriate security mechanism, since time is not a secret. =C2=A0There is = even an experimental authentication mechanism in the standard, as you sugge= sted (See Annex K of IEEE 1588-2008). > > Nevertheless, there is a requirement for PTP over IPsec. =C2=A0The reason= is that some system architects/admins want to have a policy that all packe= ts go through the IPsec tunnel. =C2=A0We timing geeks like to think of PTP = as special, but to many system architects it is just one of many management= protocols that run on their network. They don't want the complexity of mak= ing an exception for one protocol. There's no reason to agree to a bad architecture just because it appears to be written in stone. Agreeing to document it on account of its being deployed is another story, but there's no requirement that we do that either. Timing packets *should* need no more protection than the outer IP headers on an IPsec-protected packet (hello) or than the cleartext bits of IKE. Some things have to go in the clear. So much so -so much so!- that the proposal on the table is to make enough of the timing packets go in the clear that the end nodes can get more accurate time. Imagine that. What better proof is there that the architecture is broken? But does PTP need protection? Or would it need any modifications/extensions to make it safe to use without IPsec? You didn't clarify this. It may well be easier for IPsecme WG and the IETF to agree to the proposal than it would be to fix PTP if it needs fixing, but it'd be nice if we could establish that too. This is the sort of homework that the proposal's proponents should be doing. > TICTOC could make a big push to educate the system architects that ptp sh= ould not be encrypted. =C2=A0We could even convert some of them, but not al= l of them. =C2=A0The only thing that could kill this requirement is if we c= onvincingly show that ptp over IPsec could absolutely not be made to work i= n wireless backhaul networks. =C2=A0I don't think that such an argument is = forthcoming. If TICTOC WG won't say "no" then the maybe IPsecme WG, the IETF, and/or the IESG will. I guess we're about to find out what IPsecme thinks of this. > GET OVER IT EVERYONE, THE REQUIREMENT FOR PTP OVER IPsec IS NOT GOING AWA= Y! =C2=A0We need to figure out how to make it work as well as it can. There is no requirement that the IETF rubber-stamp this either. Using caps won't help achieve consensus. Now that the issue is clear, I think we could actually work towards establishing consensus on one or another proposals, or even simply show that there's consensus for none if that's what happens. As part of this process it'd be useful to find out what the process might be to change the femtocell architecture so as to remove the requirement that timing packets be encrypted. What if the IETF consensus is that the femtocell architecture should be cha= nged? Nico -- From nico@cryptonector.com Mon Oct 24 17:23:13 2011 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 8E81511E81E4; Mon, 24 Oct 2011 17:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8abcTPfjxBz; Mon, 24 Oct 2011 17:23:12 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id E15F111E808F; Mon, 24 Oct 2011 17:23:12 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 9D897350058; Mon, 24 Oct 2011 17:23:12 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 5AAF9350057; Mon, 24 Oct 2011 17:23:12 -0700 (PDT) Received: by yxi11 with SMTP id 11so2238410yxi.31 for ; Mon, 24 Oct 2011 17:23:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.57.102 with SMTP id h6mr51667743pbq.7.1319502191491; Mon, 24 Oct 2011 17:23:11 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Mon, 24 Oct 2011 17:23:11 -0700 (PDT) In-Reply-To: References: <8CC0CB0BCAE52F46882E17828A9AE21606C71723@SZXEML508-MBS.china.huawei.com> <4E96F91E.3020202@ntp.org> <4E977D47.5070709@ntp.org> <4E98D17E.8000801@udel.edu> <4E9B9C12.6000505@ntp.org> <09787EF419216C41A903FD14EE5506DD030CB8FC8B@AUSX7MCPC103.AMER.DELL.COM> <4A4385BFBA1BC54C863E7394BD1AECB338AACB0F@SJC-MBX-01.symmetricom.com> Date: Mon, 24 Oct 2011 19:23:11 -0500 Message-ID: From: Nico Williams To: Doug Arnold Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "cuiyang@huawei.com" , "ipsec@ietf.org" , Tim Frost , "TICTOC@ietf.org" , "Paul_Koning@Dell.com" , "mills@udel.edu" Subject: Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui) 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, 25 Oct 2011 00:23:13 -0000 On Mon, Oct 24, 2011 at 6:19 PM, Doug Arnold wrot= e: > I don't agree that it is incumbent on those preparing a draft on PTP over= IPsec to show the need. =C2=A0The wireless system architects have already = said they want this. =C2=A0If someone disagrees, they are the ones who need= to explain why an exception for timing is necessary. Really? So, just publish any I-D and don't show why it's needed, just by dint of submitting your I-D you get to have volunteers review your I-D and ultimately have an RFC published? I don't think so. I-D authors do need to justify their proposals. Their justification *can* be "we have no choice because this other standard development organization left us no choice", but it has to be stated -- certainly when that is their motivation, and especially if there's also any controversy as to the proposal. > You raise the possibility of the IETF as a whole taking a stand on archit= ecture. =C2=A0This would certainly carry a lot more weight than a stand by = one obscure WG, TICTOC. =C2=A0Such a stand happens sometimes, around big is= sues. =C2=A0For example, the IETF has taken a stand that security shall be = implemented via IPsec, and not with separate mechanisms for each applicatio= n, such as https. =C2=A0 The IETF has taken a stand promoting IPv6. =C2=A0(= note: IPv4 and https persist despite these stands.) I'm pessimistic, though= , about the possibility of convincing those high up in the IETF organizatio= n that encrypted PTP is a big enough issue for the IETF as whole to weigh i= n on. =C2=A0At the very least they are likely to say that we haven't tried = hard enough to make this work yet. This is basically the same problem that = we have with network architects. =C2=A0Timing is a very small part of the b= ig world of networking. No, I raised the possibility that the IPsecme WG and IETF might not reach consensus of publishing the proposal on the Standards-Track or any track. There may not be any need to take a stand on the issue -- the I-D requires consensus to progress, and may not be able to obtain it. The IESG can take a stand, as can the IAB in an appeal. But long before we get there it's perfectly fair for participants to question the proposal and propose alternatives. In any case, the IETF didn't say "we won't standardize SSL/TLS because IPsec is what should be used" or anything of the sort. The IPsec vision for end-to-end security certainly has failed, and IPv6 has not yet dethroned IPv4 -- all true, but that says nothing about the current issue other than that you can put together a strawman :) > However, you have brought up an interesting possibility. =C2=A0The IPsecm= e WG might be persuaded to create an option for leaving timestamps in the c= lear, in some fashion. =C2=A0If such a thing were implemented in a future v= ersion of IPsec, then the system architects who want everything to run thro= ugh the tunnel would likely be mollified. =C2=A0This is probably the best l= ong term solution. =C2=A0I expect that IPsecme WG would want to see somethi= ng written down that quantitatively documents the advantage of not encrypti= ng time, either in terms of hardware cost or timing performance on the same= hardware. =C2=A0At least to the level of a paper study or simulation. =C2= =A0Since you have passion for this, perhaps you would like to start a draft= of such a document? Did I bring that up? I did not. However, there is an interesting idea: fold PTP/NTP into IKE, then it will be easy to timestamp all IKE packets (since there should be so few IKE packets compared to ESP)! Bonus: the timing packets can be fully encrypted and not be identified as such. Nice try on volunteering me though! :) > Even if the IPsecme WG were persuaded to address this, It would probably = take a while before it was in the field in servers and routers. =C2=A0I pre= dict that there will be a "lock-out spec" for encrypted PTP from at least o= ne major wireless infrastructure company sometime soon. =C2=A0And those of = us who sell to them are either going to build it, or lose the business to s= omeone who will. And if the IETF won't define it then the ITU, IEEE or some= one other organization will. =C2=A0I suggest that the IETF is the organizat= ion which is best suited to define PTP over IPsec, since the IETF controls = IPsec. Isn't that true of the proposed WESP extension as well? In any case, if the proponents don't care if the IETF blesses their proposal then why not just not bother? If many proposals rejected here are simply standardized elsewhere, why bother coming here at all? Or why bother standardizing anything? I submit that the reason why one should bother is that the IETF has significant brand value and significant value in getting *others* to implement valuable ideas, and part of that value surely derives from having the sort of review that does sometimes lead to a decision (or lack of consensus) to not publish some proposal. I'm not scared by threats of going elsewhere, especially when the authors haven't made such threats in the first place. I don't see why the proponents should be scared of rejection by yours truly either, since my opinion is hardly the determinant of consensus here. Proponents should be more concerned by the relative silence of many of the key IPsecme WG participants. > One last thing, I promise, no more all caps statements. Thanks! :) Nico -- From ynir@checkpoint.com Tue Oct 25 01:35:16 2011 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 F121721F8BEF for ; Tue, 25 Oct 2011 01:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.527 X-Spam-Level: X-Spam-Status: No, score=-10.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d384e-BP9JUh for ; Tue, 25 Oct 2011 01:35:16 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C4CAD21F8BF0 for ; Tue, 25 Oct 2011 01:35:15 -0700 (PDT) X-CheckPoint: {4EA6746E-10008-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p9P8Z9bA016274; Tue, 25 Oct 2011 10:35:09 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 25 Oct 2011 10:35:05 +0200 From: Yoav Nir To: "'Prashant Batra (prbatra)'" , "ipsec@ietf.org" Date: Tue, 25 Oct 2011 10:35:04 +0200 Thread-Topic: eap-md5 based authentication Thread-Index: AcySZ4jfbp85XhqtQZOVC/WpALfLMQAiTjCQ Message-ID: <006FEB08D9C6444AB014105C9AEB133F01797F068C77@il-ex01.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_006FEB08D9C6444AB014105C9AEB133F01797F068C77ilex01adche_" MIME-Version: 1.0 Subject: Re: [IPsec] eap-md5 based authentication 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, 25 Oct 2011 08:35:17 -0000 --_000_006FEB08D9C6444AB014105C9AEB133F01797F068C77ilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Prashant. I think in the challenge request, the first byte is the challenge length (u= sually 16) followed by the challenge itself, and then followed by some serv= er name. I guess the reasoning is that this allows the client to choose the= correct password based on the server name. Yoav ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of P= rashant Batra (prbatra) Sent: 24 October 2011 18:11 To: ipsec@ietf.org Subject: [IPsec] eap-md5 based authentication Hello, I am facing some problem in calculating md5-challenge response. What I am doing is simply MD5(Identifier | | ). The challenge response is somehow wrong. Is it correct to say that Challenge value used as input to md5 is the same = value what is in the EAP payload (type md5-challenge request)? Regards, Prashant --_000_006FEB08D9C6444AB014105C9AEB133F01797F068C77ilex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Prashant.
 
I=20 think in the challenge request, the first byte is the challenge length (usu= ally=20 16) followed by the challenge itself, and then followed by some server name= . I=20 guess the reasoning is that this allows the client to choose the correct=20 password based on the server name.
 
Yoav

From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of Prashant Batra=20 (prbatra)
Sent: 24 October 2011 18:11
To:=20 ipsec@ietf.org
Subject: [IPsec] eap-md5 based=20 authentication

Hello,

 

I am facing some problem in calculating md5-challenge= =20 response.

What I am doing is simply MD5(Identifier | <secret&= gt; |=20 <Challenge value received in the challenge request>).

The challenge response is somehow wrong.

 

Is it correct to say that Challenge value used as inpu= t to=20 md5 is the same value what is in the EAP payload (type md5-challenge=20 request)?

 

Regards,

Prashant

 

--_000_006FEB08D9C6444AB014105C9AEB133F01797F068C77ilex01adche_-- From ynir@checkpoint.com Tue Oct 25 01:39:39 2011 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 3DA8521F8C0B for ; Tue, 25 Oct 2011 01:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.536 X-Spam-Level: X-Spam-Status: No, score=-10.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRA5mLm68-YZ for ; Tue, 25 Oct 2011 01:39:38 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id DA79721F8C00 for ; Tue, 25 Oct 2011 01:39:37 -0700 (PDT) X-CheckPoint: {4EA67576-10003-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p9P8dYVa017280; Tue, 25 Oct 2011 10:39:35 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 25 Oct 2011 10:39:35 +0200 From: Yoav Nir To: "'Michael Richardson'" , "ipsec@ietf.org" Date: Tue, 25 Oct 2011 10:39:34 +0200 Thread-Topic: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement Thread-Index: AcySVTUR9ss6StcaSY2obxRdfrZTqwAm9pyQ Message-ID: <006FEB08D9C6444AB014105C9AEB133F01797F068C78@il-ex01.ad.checkpoint.com> References: <14515.1319464834@marajade.sandelman.ca> In-Reply-To: <14515.1319464834@marajade.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Ulliott, Chris" Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 08:39:39 -0000 Chris' case is a little different, because he is willing to do some work to= establish trust between the two administrative domains, so it's not really= opportunistic (although doing it with OE might be a solution) So there could be some "hub gateway" that could do the introducing, perhaps= over IPsec or IKE.=20 On the one hand, if DNS works and everybody already has a DNS resolver, it = may be better to use that than to invent a new mechanism. OTOH if I didn't = like inventing new mechanisms, I wouldn't be participating in the IETF. -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of M= ichael Richardson Sent: 24 October 2011 16:01 To: ipsec@ietf.org Cc: Ulliott, Chris Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem = Statement I was not intending to be, (I have no ticket as yet), but plans might chang= e. It seems like Chris has all of the requirements of OE, and there is all of = the challenges. IPv6 and homenet might well provide FDQNs for hosts, and a= trusted path to update the reverse. If DNS does not work for you, then you need another trusted introducer, and= there have been many proposals out there for doing this kind of thing. No= ne of taken off and hit the elbow of exponential growth. From glenzorn@gmail.com Tue Oct 25 03:16:01 2011 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 36D0E21F84DD for ; Tue, 25 Oct 2011 03:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+NHc8E+Ox3e for ; Tue, 25 Oct 2011 03:16:00 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B9D2C21F84D5 for ; Tue, 25 Oct 2011 03:16:00 -0700 (PDT) Received: by ggnv1 with SMTP id v1so403305ggn.31 for ; Tue, 25 Oct 2011 03:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Ojodl+6qaWUwsj1UCjqFyG5a1xZRXdCRKpWez3qDDoA=; b=FVGeZE12zu7qteLszVrIACi1apJFLIM/+v4oVQiZiG0smW3Vplwbf/N4mcez58PSWL nTNB5ZtjmABvXQ8+wl4eG/6KktzprcJybChn5unUqEMCT/lXRlYFCA0F89zRLePIOYzn tdr1bzeCSRZBXQy9jaU/kodKelLayhmS4g1bU= Received: by 10.68.14.6 with SMTP id l6mr55381760pbc.84.1319537760080; Tue, 25 Oct 2011 03:16:00 -0700 (PDT) Received: from [192.168.1.99] (ppp-110-169-216-231.revip5.asianet.co.th. [110.169.216.231]) by mx.google.com with ESMTPS id lt6sm5991653pbb.17.2011.10.25.03.15.55 (version=SSLv3 cipher=OTHER); Tue, 25 Oct 2011 03:15:58 -0700 (PDT) Message-ID: <4EA68C58.6010904@gmail.com> Date: Tue, 25 Oct 2011 17:15:52 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Yoav Nir References: <006FEB08D9C6444AB014105C9AEB133F01797F068C77@il-ex01.ad.checkpoint.com> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F01797F068C77@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , "'Prashant Batra \(prbatra\)'" Subject: Re: [IPsec] eap-md5 based authentication 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, 25 Oct 2011 10:16:01 -0000 On 10/25/2011 3:35 PM, Yoav Nir wrote: > Hi Prashant. > > I think in the challenge request, the first byte is the challenge length > (usually 16) followed by the challenge itself, and then followed by some > server name. I guess the reasoning is that this allows the client to > choose the correct password based on the server name. The format is defined in Section 4.1 of RFC 1994 ... From prbatra@cisco.com Tue Oct 25 05:10:46 2011 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 B798021F8B00 for ; Tue, 25 Oct 2011 05:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSRtPHVi11nT for ; Tue, 25 Oct 2011 05:10:40 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id B04B721F8AB8 for ; Tue, 25 Oct 2011 05:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=prbatra@cisco.com; l=1380; q=dns/txt; s=iport; t=1319544639; x=1320754239; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=s5G6yM4KGfr41PsgkfZGosfTsOZpgHQUHLwXjCZib3o=; b=k9rKFXi3rsaSdl1EzkzV9FMZWFShImvA+rpgcPistKLnf68KpmYW3Pe0 FDrxOhYzxcvyQ/cgntUUGbyi3zXtYnwGJIqULhTe/bC75+2WD58RwT3VP qM+L169ex0PW1P5VWpMPC4s0yOfxKiDnCFL0SnzmWtkNwuCl5jJLueQRd s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAAAympk5Io8UR/2dsb2JhbABDmVOPQoEFgW4BAQEBAgEBAQEPAR0KNAsFBwQCAQgRBAEBCwYIDwEGASYfCQgBAQQBCggIGodeCJVjAZ5qBIU0gi5hBIgEkTqMMA X-IronPort-AV: E=Sophos;i="4.69,404,1315180800"; d="scan'208";a="58494142" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 25 Oct 2011 12:10:26 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9PCAQ3G006194; Tue, 25 Oct 2011 12:10:26 GMT Received: from xmb-bgl-419.cisco.com ([72.163.129.215]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 17:40:26 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Oct 2011 17:40:25 +0530 Message-ID: In-Reply-To: <4EA68C58.6010904@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] eap-md5 based authentication Thread-Index: AcyS/yB1OCitABfURmKFRfMl171/KgADxwkA References: <006FEB08D9C6444AB014105C9AEB133F01797F068C77@il-ex01.ad.checkpoint.com> <4EA68C58.6010904@gmail.com> From: "Prashant Batra (prbatra)" To: "Glen Zorn" , "Yoav Nir" X-OriginalArrivalTime: 25 Oct 2011 12:10:26.0163 (UTC) FILETIME=[14524430:01CC930F] Cc: ipsec@ietf.org Subject: Re: [IPsec] eap-md5 based authentication 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, 25 Oct 2011 12:10:46 -0000 Thanks Yaov and Glen, I could successfully calculate the challenge response. Now, after the challenge response is successful, the server will send EAP-SUCCESS, then the client has to send a AUTH payload. As eap-md5 doesn't result in any key like eap-aka/sim, the client will use the same password(used for calculating challenge response) to calculate AUTH payload. If so, why there is an explicit auth required here. EAP-SUCCESS, can itself indicate that the client is authenticated. Maybe, it is required for some extra authentication? Regards, Prashant -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Glen Zorn Sent: Tuesday, October 25, 2011 3:46 PM To: Yoav Nir Cc: ipsec@ietf.org; Prashant Batra (prbatra) Subject: Re: [IPsec] eap-md5 based authentication On 10/25/2011 3:35 PM, Yoav Nir wrote: > Hi Prashant. > =20 > I think in the challenge request, the first byte is the challenge length > (usually 16) followed by the challenge itself, and then followed by some > server name. I guess the reasoning is that this allows the client to > choose the correct password based on the server name. The format is defined in Section 4.1 of RFC 1994 ... _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Tue Oct 25 05:29:04 2011 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 74C5821F8B47 for ; Tue, 25 Oct 2011 05:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.243 X-Spam-Level: X-Spam-Status: No, score=-10.243 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ih6ok5Tp4YMC for ; Tue, 25 Oct 2011 05:29:03 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4988B21F8B45 for ; Tue, 25 Oct 2011 05:29:03 -0700 (PDT) X-CheckPoint: {4EA6AB3B-10008-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p9PCSvwJ005027; Tue, 25 Oct 2011 14:28:57 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 25 Oct 2011 14:28:57 +0200 From: Yoav Nir To: "Prashant Batra (prbatra)" , Glen Zorn Date: Tue, 25 Oct 2011 14:28:58 +0200 Thread-Topic: [IPsec] eap-md5 based authentication Thread-Index: AcyTEaoywA/lDqqGTGCWTQmieExGaw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] eap-md5 based authentication 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, 25 Oct 2011 12:29:04 -0000 No, you don't use the same password for calculating the AUTH payload. >From section 2.15: There are two types of EAP authentication (described in Section 2.16), and each type uses different values in the AUTH computations shown above. If the EAP method is key-generating, substitute master session key (MSK) for the shared secret in the computation. For non-key-generating methods, substitute SK_pi and SK_pr, respectively, for the shared secret in the two AUTH Computations. So the client in your case is going to use SK_pi. If you don't mind the question, how did this come up? If you're writing your own client, why not use something better than EAP-MD5 such as EAP-EKE or EAP-pwd? If you're using a third-party client (like Microsoft's Win7 client) I think they're using EAP-MSChapv2. Where did you find a client with EAP-MD5? Yoav On 10/25/11 2:10 PM, "Prashant Batra (prbatra)" wrote: >Thanks Yaov and Glen, > >I could successfully calculate the challenge response. >Now, after the challenge response is successful, the server will send >EAP-SUCCESS, then the client has to send a AUTH payload. >As eap-md5 doesn't result in any key like eap-aka/sim, the client will >use the same password(used for calculating challenge response) to >calculate AUTH payload. >If so, why there is an explicit auth required here. EAP-SUCCESS, can >itself indicate that the client is authenticated. > >Maybe, it is required for some extra authentication? > >Regards, >Prashant > >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >Of Glen Zorn >Sent: Tuesday, October 25, 2011 3:46 PM >To: Yoav Nir >Cc: ipsec@ietf.org; Prashant Batra (prbatra) >Subject: Re: [IPsec] eap-md5 based authentication > >On 10/25/2011 3:35 PM, Yoav Nir wrote: > >> Hi Prashant. >> =20 >> I think in the challenge request, the first byte is the challenge >length >> (usually 16) followed by the challenge itself, and then followed by >some >> server name. I guess the reasoning is that this allows the client to >> choose the correct password based on the server name. > >The format is defined in Section 4.1 of RFC 1994 > >... >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec > >Scanned by Check Point Total Security Gateway. From prbatra@cisco.com Tue Oct 25 08:01:04 2011 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 3067521F84B7 for ; Tue, 25 Oct 2011 08:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RODLKuEtt04R for ; Tue, 25 Oct 2011 08:01:03 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id E1DD021F8495 for ; Tue, 25 Oct 2011 08:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=prbatra@cisco.com; l=3232; q=dns/txt; s=iport; t=1319554863; x=1320764463; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=7RikElN25hpGz78A53wMYFAlhzQ6wxmXS/BTgSSPbVM=; b=S8YAqbhkl/+MMpXBmwoymd1LJhhxMa/5wziGV1pw5W/nXixeNS7hBCFE UmhCpgIPU5aS3+3HrmyBqCUD8yIBAPjCdqcgs9pZsroQlbGBrxiMjAllz ZUskJ0KyQYrJpce7aModlv9C3HJm3s9Jmym13NM8aYSVwhEcbwSvlYDqy s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAAIrOpk5Io8UR/2dsb2JhbABCmVWNf4FDgQWBbgEBAQEDAQEBDwEdCjQLDAQCAQgOAwQBAQEKBggPAQYBJh8JCAEBBAEKCAgah2aVbwGeZwSFNIIuYQSIBJE6jDA X-IronPort-AV: E=Sophos;i="4.69,404,1315180800"; d="scan'208";a="119972819" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 25 Oct 2011 15:00:57 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9PF0uft003483; Tue, 25 Oct 2011 15:00:56 GMT Received: from xmb-bgl-419.cisco.com ([72.163.129.215]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 20:30:56 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Oct 2011 20:30:55 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] eap-md5 based authentication Thread-Index: AcyTEaoywA/lDqqGTGCWTQmieExGawADZaCw References: From: "Prashant Batra (prbatra)" To: "Yoav Nir" , "Glen Zorn" X-OriginalArrivalTime: 25 Oct 2011 15:00:56.0450 (UTC) FILETIME=[E60C2E20:01CC9326] Cc: ipsec@ietf.org Subject: Re: [IPsec] eap-md5 based authentication 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, 25 Oct 2011 15:01:04 -0000 Thanks Yoav, I think I missed it somehow from the RFC. Regarding the usage of EAP-MD5, it is just that the client should support all types of authentication, So even the weakest ones also and rfc-3748 says that md5-challenge is a must. Moreover, it is the server that has to decide what is the best suited auth mechanisms for a particular client. Regards, Prashant -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Tuesday, October 25, 2011 5:59 PM To: Prashant Batra (prbatra); Glen Zorn Cc: ipsec@ietf.org Subject: Re: [IPsec] eap-md5 based authentication No, you don't use the same password for calculating the AUTH payload. >From section 2.15: There are two types of EAP authentication (described in Section 2.16), and each type uses different values in the AUTH computations shown above. If the EAP method is key-generating, substitute master session key (MSK) for the shared secret in the computation. For non-key-generating methods, substitute SK_pi and SK_pr, respectively, for the shared secret in the two AUTH Computations. So the client in your case is going to use SK_pi. If you don't mind the question, how did this come up? If you're writing your own client, why not use something better than EAP-MD5 such as EAP-EKE or EAP-pwd? If you're using a third-party client (like Microsoft's Win7 client) I think they're using EAP-MSChapv2. Where did you find a client with EAP-MD5? Yoav On 10/25/11 2:10 PM, "Prashant Batra (prbatra)" wrote: >Thanks Yaov and Glen, > >I could successfully calculate the challenge response. >Now, after the challenge response is successful, the server will send >EAP-SUCCESS, then the client has to send a AUTH payload. >As eap-md5 doesn't result in any key like eap-aka/sim, the client will >use the same password(used for calculating challenge response) to >calculate AUTH payload. >If so, why there is an explicit auth required here. EAP-SUCCESS, can >itself indicate that the client is authenticated. > >Maybe, it is required for some extra authentication? > >Regards, >Prashant > >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >Of Glen Zorn >Sent: Tuesday, October 25, 2011 3:46 PM >To: Yoav Nir >Cc: ipsec@ietf.org; Prashant Batra (prbatra) >Subject: Re: [IPsec] eap-md5 based authentication > >On 10/25/2011 3:35 PM, Yoav Nir wrote: > >> Hi Prashant. >> =20 >> I think in the challenge request, the first byte is the challenge >length >> (usually 16) followed by the challenge itself, and then followed by >some >> server name. I guess the reasoning is that this allows the client to >> choose the correct password based on the server name. > >The format is defined in Section 4.1 of RFC 1994 > >... >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec > >Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From shanna@juniper.net Wed Oct 26 07:02:48 2011 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 6DC2F21F86EE for ; Wed, 26 Oct 2011 07:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.702 X-Spam-Level: X-Spam-Status: No, score=-105.702 tagged_above=-999 required=5 tests=[AWL=0.897, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yc-MpoXsUTyK for ; Wed, 26 Oct 2011 07:02:47 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 21F9821F8713 for ; Wed, 26 Oct 2011 07:02:37 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP; Wed, 26 Oct 2011 07:02:47 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 26 Oct 2011 07:00:22 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 26 Oct 2011 10:00:07 -0400 From: Stephen Hanna To: Yoav Nir , 'Michael Richardson' , "ipsec@ietf.org" Date: Wed, 26 Oct 2011 10:00:05 -0400 Thread-Topic: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement Thread-Index: AcySVTUR9ss6StcaSY2obxRdfrZTqwAm9pyQAD1w6tA= Message-ID: References: <14515.1319464834@marajade.sandelman.ca> <006FEB08D9C6444AB014105C9AEB133F01797F068C78@il-ex01.ad.checkpoint.com> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F01797F068C78@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Ulliott, Chris" Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 14:02:48 -0000 I'm concerned about using DNS as the introducer here. Doing this securely requires DNS records to be updated, signed, and distributed whenever a new "satellite" gateway or host arrives or departs. That's cumbersome, expensive, and complex since it requires interfacing the IPsec and DNSSEC infrastructure and lots of resigning. The core IPsec gateway already knows all the information necessary to establish a secure direct connection between satellites and there's already a secure connection between the core and the satellites. Why not use that connection to distribute the information directly from the core to the satellites? Whatever technology is decided upon, my employer (Juniper Networks) sees a need for dynamically established "peer-to-peer" VPNs and supports efforts to create standards in this area and to get widespread adoption of those standards. Thanks, Steve Hanna > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Yoav Nir > Sent: Tuesday, October 25, 2011 4:40 AM > To: 'Michael Richardson'; ipsec@ietf.org > Cc: Ulliott, Chris > Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs > Problem Statement >=20 > Chris' case is a little different, because he is willing to do some > work to establish trust between the two administrative domains, so it's > not really opportunistic (although doing it with OE might be a > solution) >=20 > So there could be some "hub gateway" that could do the introducing, > perhaps over IPsec or IKE. >=20 > On the one hand, if DNS works and everybody already has a DNS resolver, > it may be better to use that than to invent a new mechanism. OTOH if I > didn't like inventing new mechanisms, I wouldn't be participating in > the IETF. >=20 >=20 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Michael Richardson > Sent: 24 October 2011 16:01 > To: ipsec@ietf.org > Cc: Ulliott, Chris > Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs > Problem Statement >=20 >=20 > I was not intending to be, (I have no ticket as yet), but plans might > change. > It seems like Chris has all of the requirements of OE, and there is all > of the challenges. IPv6 and homenet might well provide FDQNs for > hosts, and a trusted path to update the reverse. >=20 > If DNS does not work for you, then you need another trusted introducer, > and there have been many proposals out there for doing this kind of > thing. None of taken off and hit the elbow of exponential growth. >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Wed Oct 26 07:40:37 2011 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 8A7E521F8AC9 for ; Wed, 26 Oct 2011 07:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zprW+33wXia8 for ; Wed, 26 Oct 2011 07:40:37 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0C14C21F8A67 for ; Wed, 26 Oct 2011 07:40:36 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p9QEeZ74064238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 26 Oct 2011 07:40:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: Date: Wed, 26 Oct 2011 07:40:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <10A8B057-C86B-4DF0-9171-A9FA14177793@vpnc.org> References: <14515.1319464834@marajade.sandelman.ca> <006FEB08D9C6444AB014105C9AEB133F01797F068C78@il-ex01.ad.checkpoint.com> To: IPsecme WG X-Mailer: Apple Mail (2.1251.1) Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 14:40:37 -0000 On Oct 26, 2011, at 7:00 AM, Stephen Hanna wrote: > I'm concerned about using DNS as the introducer here. Doing this > securely requires DNS records to be updated, signed, and distributed > whenever a new "satellite" gateway or host arrives or departs. > That's cumbersome, expensive, and complex since it requires > interfacing the IPsec and DNSSEC infrastructure and lots of > resigning. >=20 > The core IPsec gateway already knows all the information necessary > to establish a secure direct connection between satellites and > there's already a secure connection between the core and the > satellites. Why not use that connection to distribute the information > directly from the core to the satellites? +1. Putting in a dependency not only on DNS, but DNSSEC, seems odd here. = If there is already a trusted introducer here, use it. The use case for = RFC 4322, opportunistic encryption (and thus no trusted introducer), is = quite different than the one being proposed here. --Paul Hoffman From galina@juniper.net Wed Oct 26 07:55:42 2011 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 8DF1E21F8B71 for ; Wed, 26 Oct 2011 07:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1gU57IEtZfm for ; Wed, 26 Oct 2011 07:55:42 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5878A21F8B70 for ; Wed, 26 Oct 2011 07:55:40 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP; Wed, 26 Oct 2011 07:55:41 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 26 Oct 2011 07:51:36 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 26 Oct 2011 10:51:36 -0400 From: Galina Pildush To: Paul Hoffman , IPsecme WG Date: Wed, 26 Oct 2011 10:51:32 -0400 Thread-Topic: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement Thread-Index: AcyT7T4dJfVG2ekzQfqdE2+lMvRMvQAAOtgA Message-ID: References: <14515.1319464834@marajade.sandelman.ca> <006FEB08D9C6444AB014105C9AEB133F01797F068C78@il-ex01.ad.checkpoint.com> <10A8B057-C86B-4DF0-9171-A9FA14177793@vpnc.org> In-Reply-To: <10A8B057-C86B-4DF0-9171-A9FA14177793@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 14:55:42 -0000 + Definitely agree with Steve and Paul - the proposed draft proposes spoke-= to-spoke direct tunnel establishment based on the information known to hub = and all spokes. We've seen many service providers wanting this ability to s= cale painlessly and seamlessly.=20 Galina Pildush -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of P= aul Hoffman Sent: Wednesday, October 26, 2011 10:41 AM To: IPsecme WG Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem = Statement On Oct 26, 2011, at 7:00 AM, Stephen Hanna wrote: > I'm concerned about using DNS as the introducer here. Doing this > securely requires DNS records to be updated, signed, and distributed > whenever a new "satellite" gateway or host arrives or departs. > That's cumbersome, expensive, and complex since it requires > interfacing the IPsec and DNSSEC infrastructure and lots of > resigning. >=20 > The core IPsec gateway already knows all the information necessary > to establish a secure direct connection between satellites and > there's already a secure connection between the core and the > satellites. Why not use that connection to distribute the information > directly from the core to the satellites? +1. Putting in a dependency not only on DNS, but DNSSEC, seems odd here. If= there is already a trusted introducer here, use it. The use case for RFC 4= 322, opportunistic encryption (and thus no trusted introducer), is quite di= fferent than the one being proposed here. --Paul Hoffman _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Wed Oct 26 10:03:51 2011 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 1633821F87E2 for ; Wed, 26 Oct 2011 10:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.519 X-Spam-Level: X-Spam-Status: No, score=-10.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upIC5qHIqMJO for ; Wed, 26 Oct 2011 10:03:50 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 20FEC21F8783 for ; Wed, 26 Oct 2011 10:03:49 -0700 (PDT) X-CheckPoint: {4EA83D1F-10008-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p9QH3mYX009176; Wed, 26 Oct 2011 19:03:48 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 26 Oct 2011 19:03:48 +0200 From: Yoav Nir To: "'Galina Pildush'" , Paul Hoffman , IPsecme WG Date: Wed, 26 Oct 2011 19:03:47 +0200 Thread-Topic: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement Thread-Index: AcyT7T4dJfVG2ekzQfqdE2+lMvRMvQAAOtgAAASka3A= Message-ID: <006FEB08D9C6444AB014105C9AEB133F01797F068C85@il-ex01.ad.checkpoint.com> References: <14515.1319464834@marajade.sandelman.ca> <006FEB08D9C6444AB014105C9AEB133F01797F068C78@il-ex01.ad.checkpoint.com> <10A8B057-C86B-4DF0-9171-A9FA14177793@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 17:03:51 -0000 This goes back to my previous question. What is this information that is "known to hub and all spokes" ? If the spoke knows what addresses are behind each other spoke, then we lose= the scalability - that's a lot of configuration up front. If the spoke only knows the union of all addresses behind other spokes, it = sounds more feasible, but I still would like to know how it's configured. If it's only the hub that knows the union, then again, how was that configu= red? If each spoke knows only its own addresses and informs the hub, how do we p= revent the problem of a malicious spoke claiming Facebook's subnets? Yoav -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of G= alina Pildush Sent: 26 October 2011 16:52 To: Paul Hoffman; IPsecme WG Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem = Statement + Definitely agree with Steve and Paul - the proposed draft proposes spoke-= to-spoke direct tunnel establishment based on the information known to hub = and all spokes. We've seen many service providers wanting this ability to s= cale painlessly and seamlessly.=20 Galina Pildush -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of P= aul Hoffman Sent: Wednesday, October 26, 2011 10:41 AM To: IPsecme WG Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem = Statement On Oct 26, 2011, at 7:00 AM, Stephen Hanna wrote: > I'm concerned about using DNS as the introducer here. Doing this=20 > securely requires DNS records to be updated, signed, and distributed=20 > whenever a new "satellite" gateway or host arrives or departs. > That's cumbersome, expensive, and complex since it requires=20 > interfacing the IPsec and DNSSEC infrastructure and lots of resigning. >=20 > The core IPsec gateway already knows all the information necessary to=20 > establish a secure direct connection between satellites and there's=20 > already a secure connection between the core and the satellites. Why=20 > not use that connection to distribute the information directly from=20 > the core to the satellites? +1. Putting in a dependency not only on DNS, but DNSSEC, seems odd here. If= there is already a trusted introducer here, use it. The use case for RFC 4= 322, opportunistic encryption (and thus no trusted introducer), is quite di= fferent than the one being proposed here. --Paul Hoffman _______________________________________________ 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 Scanned by Check Point Total Security Gateway. From yaronf.ietf@gmail.com Wed Oct 26 12:39:50 2011 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 5EC4811E809D for ; Wed, 26 Oct 2011 12:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kBnN78EyBqJ for ; Wed, 26 Oct 2011 12:39:49 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A0ABE11E8090 for ; Wed, 26 Oct 2011 12:39:47 -0700 (PDT) Received: by wwe6 with SMTP id 6so2142997wwe.13 for ; Wed, 26 Oct 2011 12:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=uI6L2TqQW1sc6lq1io6OlkZEahoZd6rVf3vPMscJ1mw=; b=hEV/ikJm/DlXXJbXmooauuN50Ex8baJf94NqD2FZH6sPeJuwSCD9h7OeD868NzlEUd rZa7XVmreAZaeaiwkj+BrQomqZs0f25L9DDScywZPr5kri9wg5UVWg/ClnbNMSQLssWa +qo/L2Z/S8Bksc2nbT/SEnUxVosSWdGdqB9x4= Received: by 10.227.207.205 with SMTP id fz13mr11962657wbb.0.1319657986807; Wed, 26 Oct 2011 12:39:46 -0700 (PDT) Received: from [192.168.1.99] (AMarseille-257-1-16-63.w90-42.abo.wanadoo.fr. [90.42.247.63]) by mx.google.com with ESMTPS id es5sm5013562wbb.11.2011.10.26.12.39.44 (version=SSLv3 cipher=OTHER); Wed, 26 Oct 2011 12:39:45 -0700 (PDT) Message-ID: <4EA861FE.2010107@gmail.com> Date: Wed, 26 Oct 2011 21:39:42 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: Yoav Nir References: <14515.1319464834@marajade.sandelman.ca> <006FEB08D9C6444AB014105C9AEB133F01797F068C78@il-ex01.ad.checkpoint.com> <10A8B057-C86B-4DF0-9171-A9FA14177793@vpnc.org> <006FEB08D9C6444AB014105C9AEB133F01797F068C85@il-ex01.ad.checkpoint.com> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F01797F068C85@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , 'Galina Pildush' , Paul Hoffman Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 19:39:50 -0000 There is a common use case where we don't worry about malicious spokes, i.e. where they are all trusted. We do worry about misconfigured spokes, but that would most likely result in loss of connectivity, which I expect to be fixed in due time. Or it can be prevented by (static) configuration on the hub. Thanks, Yaron On 10/26/2011 07:03 PM, Yoav Nir wrote: > This goes back to my previous question. > > What is this information that is "known to hub and all spokes" ? > > If the spoke knows what addresses are behind each other spoke, then we lose the scalability - that's a lot of configuration up front. > > If the spoke only knows the union of all addresses behind other spokes, it sounds more feasible, but I still would like to know how it's configured. > > If it's only the hub that knows the union, then again, how was that configured? > > If each spoke knows only its own addresses and informs the hub, how do we prevent the problem of a malicious spoke claiming Facebook's subnets? > > Yoav > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Galina Pildush > Sent: 26 October 2011 16:52 > To: Paul Hoffman; IPsecme WG > Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement > > + Definitely agree with Steve and Paul - the proposed draft proposes spoke-to-spoke direct tunnel establishment based on the information known to hub and all spokes. We've seen many service providers wanting this ability to scale painlessly and seamlessly. > > Galina Pildush > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Hoffman > Sent: Wednesday, October 26, 2011 10:41 AM > To: IPsecme WG > Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement > > On Oct 26, 2011, at 7:00 AM, Stephen Hanna wrote: > >> I'm concerned about using DNS as the introducer here. Doing this >> securely requires DNS records to be updated, signed, and distributed >> whenever a new "satellite" gateway or host arrives or departs. >> That's cumbersome, expensive, and complex since it requires >> interfacing the IPsec and DNSSEC infrastructure and lots of resigning. >> >> The core IPsec gateway already knows all the information necessary to >> establish a secure direct connection between satellites and there's >> already a secure connection between the core and the satellites. Why >> not use that connection to distribute the information directly from >> the core to the satellites? > +1. Putting in a dependency not only on DNS, but DNSSEC, seems odd here. If there is already a trusted introducer here, use it. The use case for RFC 4322, opportunistic encryption (and thus no trusted introducer), is quite different than the one being proposed here. > > --Paul Hoffman > > _______________________________________________ > 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 > > Scanned by Check Point Total Security Gateway. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Wed Oct 26 13:02:50 2011 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 7BA0C11E8085 for ; Wed, 26 Oct 2011 13:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZRfqmLa4GN0 for ; Wed, 26 Oct 2011 13:02:50 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 02C8021F84B9 for ; Wed, 26 Oct 2011 13:02:49 -0700 (PDT) Received: from [165.227.249.211] (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p9QK2mrW076291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 26 Oct 2011 13:02:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: <4EA861FE.2010107@gmail.com> Date: Wed, 26 Oct 2011 13:02:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4BFD672C-78A7-42D2-83F0-D13AB27CE975@vpnc.org> References: <14515.1319464834@marajade.sandelman.ca> <006FEB08D9C6444AB014105C9AEB133F01797F068C78@il-ex01.ad.checkpoint.com> <10A8B057-C86B-4DF0-9171-A9FA14177793@vpnc.org> <006FEB08D9C6444AB014105C9AEB133F01797F068C85@il-ex01.ad.checkpoint.com> <4EA861FE.2010107@gmail.com> To: IPsecme WG X-Mailer: Apple Mail (2.1251.1) Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 20:02:50 -0000 On Oct 26, 2011, at 12:39 PM, Yaron Sheffer wrote: > There is a common use case where we don't worry about malicious = spokes, i.e. where they are all trusted. Exactly right. The fact that the hub trusts a spoke is all that a = different spoke needs to know for many (most?) common cases. Having said that, it would be great of the authors of the document could = come up with some terminology to differentiate "spoke trust hub to = introduce to other spokes directly" and "spoke trusts hub to introduce = to other spokes, possibly through indirection through other hubs". --Paul Hoffman From ghuang@juniper.net Wed Oct 26 13:21:48 2011 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 A0B241F0C55 for ; Wed, 26 Oct 2011 13:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Da6t1xKkU5rl for ; Wed, 26 Oct 2011 13:21:47 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 792831F0C50 for ; Wed, 26 Oct 2011 13:21:47 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP; Wed, 26 Oct 2011 13:21:47 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 26 Oct 2011 13:18:57 -0700 From: Geoffrey Huang To: "ipsec@ietf.org" Date: Wed, 26 Oct 2011 13:19:06 -0700 Thread-Topic: Re: New -00 draft: Creating Large Scale Mesh VPNs Problem Thread-Index: AcyUG+pGp2BsVZKrTZ2Zwl/noZToZg== Message-ID: <84600D05C20FF943918238042D7670FD41BF14E8A3@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_84600D05C20FF943918238042D7670FD41BF14E8A3EMBX01HQjnprn_" MIME-Version: 1.0 Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs 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, 26 Oct 2011 20:21:48 -0000 --_000_84600D05C20FF943918238042D7670FD41BF14E8A3EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have to agree with the recent comments about the inapplicability of RFC 4= 322. I don't think that a DNNSEC infrastructure can be assumed, particular= ly not in the deployments I have seen. I agree with Steve Hanna's comments about the need for ad-hoc peer-to-peer = VPNs, bypassing a centralized hub. I also agree with Paul Hoffman's commen= ts about using an already-existing "trusted introducer." Finally, I will be in Taiwan, but specifically (only) to discuss this topic= . I'm hoping that the date of Wednesday, November 16 is still good for the= bar BOF that some of us had previously discussed. -geoff --_000_84600D05C20FF943918238042D7670FD41BF14E8A3EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have to agree = with the recent comments about the inapplicability of RFC 4322.  I don= ’t think that a DNNSEC infrastructure can be assumed, particularly no= t in the deployments I have seen.

&= nbsp;

I agree with Steve Hanna’s commen= ts about the need for ad-hoc peer-to-peer VPNs, bypassing a centralized hub= .  I also agree with Paul Hoffman’s comments about using an alre= ady-existing “trusted introducer.”

 

Finally, I will be in Taiw= an, but specifically (only) to discuss this topic.  I’m hoping t= hat the date of Wednesday, November 16 is still good for the bar BOF that s= ome of us had previously discussed.

 

-geoff

= --_000_84600D05C20FF943918238042D7670FD41BF14E8A3EMBX01HQjnprn_-- From ynir@checkpoint.com Wed Oct 26 13:36:08 2011 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 C385011E8097 for ; Wed, 26 Oct 2011 13:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.526 X-Spam-Level: X-Spam-Status: No, score=-10.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-lhp7B4EFrj for ; Wed, 26 Oct 2011 13:36:08 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 16DBA11E8090 for ; Wed, 26 Oct 2011 13:36:06 -0700 (PDT) X-CheckPoint: {4EA86EDF-10008-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p9QKa3WD019141; Wed, 26 Oct 2011 22:36:03 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 26 Oct 2011 22:36:03 +0200 From: Yoav Nir To: Yaron Sheffer Date: Wed, 26 Oct 2011 22:36:04 +0200 Thread-Topic: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement Thread-Index: AcyUHuDEvOHsmzWeTfKJ9O1tXMragw== Message-ID: In-Reply-To: <4EA861FE.2010107@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , 'Galina Pildush' , Paul Hoffman Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 20:36:08 -0000 On 10/26/11 9:39 PM, "Yaron Sheffer" wrote: >There is a common use case where we don't worry about malicious spokes, >i.e. where they are all trusted. > >We do worry about misconfigured spokes, but that would most likely >result in loss of connectivity, which I expect to be fixed in due time. >Or it can be prevented by (static) configuration on the hub. Malicious/misconfigured/compromised, it doesn't matter. One way or another we have a spoke that is configured to protect the 69.171.0.0/16 subnet, that includes all facebook.com servers. If the hub learns the protected network of the spokes from the spokes, then this information will propagate to the entire network. The configuration is easy, because each protected network needs to be configured in one place only, but we have the security problem. Maybe the use of sidr resource certificates could mitigate this, but I don't think they're in wide use yet. On the other hand, we could have all the protected networks of the spokes statically configured on the hub, as you suggest. Then it doesn't matter if the spoke thinks it owns facebook, because none of the others will agree. This has several implications: - Configuration is harder and error prone - spoke and hub must match - It introduces an asymmetry. IPsec is all about peers with separate but matching configuration. In this scenario there is an all-knowing hub that introduces the spokes to one another. I'm not necessarily saying that the second scenario is bad, but it's not as scalable as the first. I'd rather solve both, but solving just the first may be a good first step. From ynir@checkpoint.com Fri Oct 28 07:00:16 2011 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 EF23321F844D for ; Fri, 28 Oct 2011 07:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.532 X-Spam-Level: X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8DT80rlMyZt for ; Fri, 28 Oct 2011 07:00:15 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id BC1ED21F844A for ; Fri, 28 Oct 2011 07:00:14 -0700 (PDT) X-CheckPoint: {4EAAB513-10013-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p9SE0CPS015081; Fri, 28 Oct 2011 16:00:12 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 28 Oct 2011 16:00:10 +0200 From: Yoav Nir To: Geoffrey Huang , Stephen Hanna Date: Fri, 28 Oct 2011 16:00:06 +0200 Thread-Topic: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Thread-Index: AcyVeedTAgoijwbeQ7O9PAVuhxKapg== Message-ID: In-Reply-To: <84600D05C20FF943918238042D7670FD41BF14E8A3@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_CAD081138129ynircheckpointcom_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs 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, 28 Oct 2011 14:00:16 -0000 --_000_CAD081138129ynircheckpointcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Well, there is a free room between 1300-1500 on Wednesday, but then we're o= pposite WebSec, and I can't attend. Our best bet is to do it after the Plenary. The plenary ends at 19:30, and = people might want to grab something to eat, so it would probably be best to= do it at 20:00. Hope you don't have a flight for Wednesday night=85 On 10/26/11 10:19 PM, "Geoffrey Huang" > wrote: I have to agree with the recent comments about the inapplicability of RFC 4= 322. I don=92t think that a DNNSEC infrastructure can be assumed, particul= arly not in the deployments I have seen. I agree with Steve Hanna=92s comments about the need for ad-hoc peer-to-pee= r VPNs, bypassing a centralized hub. I also agree with Paul Hoffman=92s co= mments about using an already-existing =93trusted introducer.=94 Finally, I will be in Taiwan, but specifically (only) to discuss this topic= . I=92m hoping that the date of Wednesday, November 16 is still good for t= he bar BOF that some of us had previously discussed. -geoff --_000_CAD081138129ynircheckpointcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Well, there is a free room betw= een 1300-1500 on Wednesday, but then we're opposite WebSec, and I can't att= end.

Our best bet is to do it after the Plenary. T= he plenary ends at 19:30, and people might want to grab something to eat, s= o it would probably be best to do it at 20:00. 

Hope you don't have a flight for Wednesday night=85

=
On 10/26/11 10:19 PM, "Geo= ffrey Huang" <ghuang@juniper.= net> wrote:

I have to ag= ree with the recent comments about the inapplicability of RFC 4322.  I= don=92t think that a DNNSEC infrastructure can be assumed, particularly no= t in the deployments I have seen.

 

I agree with Steve Hanna=92s commen= ts about the need for ad-hoc peer-to-peer VPNs, bypassing a centralized hub= .  I also agree with Paul Hoffman=92s comments about using an already-= existing =93trusted introducer.=94

 

Finally, I will be in Taiwan, but = specifically (only) to discuss this topic.  I=92m hoping that the date= of Wednesday, November 16 is still good for the bar BOF that some of us ha= d previously discussed.

 

-geoff

--_000_CAD081138129ynircheckpointcom_-- From Chris.Ulliott@cesg.gsi.gov.uk Fri Oct 28 09:01:44 2011 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 8B7FB21F85AA for ; Fri, 28 Oct 2011 09:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.432 X-Spam-Level: X-Spam-Status: No, score=-5.432 tagged_above=-999 required=5 tests=[AWL=1.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpUkT9CxG8CC for ; Fri, 28 Oct 2011 09:01:43 -0700 (PDT) Received: from mail185.messagelabs.com (mail185.messagelabs.com [85.158.143.19]) by ietfa.amsl.com (Postfix) with SMTP id 673BC21F86A6 for ; Fri, 28 Oct 2011 09:01:43 -0700 (PDT) X-Env-Sender: Chris.Ulliott@cesg.gsi.gov.uk X-Msg-Ref: server-15.tower-185.messagelabs.com!1319817701!1655799!1 X-Originating-IP: [62.25.106.208] X-StarScan-Version: 6.3.6; banners=cesg.gsi.gov.uk,-,- X-VirusChecked: Checked Received: (qmail 21995 invoked from network); 28 Oct 2011 16:01:41 -0000 Received: from gateway-102.energis.gsi.gov.uk (HELO mx22.hosting-w.gsi.gov.uk) (62.25.106.208) by server-15.tower-185.messagelabs.com with SMTP; 28 Oct 2011 16:01:41 -0000 From: "Ulliott, Chris" To: 'Yoav Nir' , 'Galina Pildush' , Paul Hoffman , IPsecme WG Date: Fri, 28 Oct 2011 17:01:34 +0100 Thread-Topic: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement Thread-Index: AcyT7T4dJfVG2ekzQfqdE2+lMvRMvQAAOtgAAASka3AAVk9+MA== Message-ID: In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F01797F068C85@il-ex01.ad.checkpoint.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 16:01:44 -0000 So the assumption I've always had is that a spoke knows two things: 1) a method to identify the next cryptographic hop 2) a method to determine if it's allowed to talk to a specific cryptograph= ic hop once identified. The second point could be solved through PKI and policy (although we need = a standard way to apply this) and the first could be solved through numero= us methods... the challenge is to find a standard way for all vendors are = willing to implement :-) Chris -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Yoav Nir Sent: Wednesday, October 26, 2011 6:04 PM To: 'Galina Pildush'; Paul Hoffman; IPsecme WG Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem= Statement This goes back to my previous question. What is this information that is "known to hub and all spokes" ? If the spoke knows what addresses are behind each other spoke, then we los= e the scalability - that's a lot of configuration up front. If the spoke only knows the union of all addresses behind other spokes, it= sounds more feasible, but I still would like to know how it's configured.= If it's only the hub that knows the union, then again, how was that config= ured? If each spoke knows only its own addresses and informs the hub, how do we = prevent the problem of a malicious spoke claiming Facebook's subnets? Yoav -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Galina Pildush Sent: 26 October 2011 16:52 To: Paul Hoffman; IPsecme WG Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem= Statement + Definitely agree with Steve and Paul - the proposed draft proposes spoke= -to-spoke direct tunnel establishment based on the information known to hu= b and all spokes. We've seen many service providers wanting this ability t= o scale painlessly and seamlessly. Galina Pildush -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Paul Hoffman Sent: Wednesday, October 26, 2011 10:41 AM To: IPsecme WG Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem= Statement On Oct 26, 2011, at 7:00 AM, Stephen Hanna wrote: > I'm concerned about using DNS as the introducer here. Doing this > securely requires DNS records to be updated, signed, and distributed > whenever a new "satellite" gateway or host arrives or departs. > That's cumbersome, expensive, and complex since it requires > interfacing the IPsec and DNSSEC infrastructure and lots of resigning. > > The core IPsec gateway already knows all the information necessary to > establish a secure direct connection between satellites and there's > already a secure connection between the core and the satellites. Why > not use that connection to distribute the information directly from > the core to the satellites? +1. Putting in a dependency not only on DNS, but DNSSEC, seems odd here. I= f there is already a trusted introducer here, use it. The use case for RFC= 4322, opportunistic encryption (and thus=20no trusted introducer), is qui= te different than the one being proposed here. --Paul Hoffman _______________________________________________ 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 Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec **************************************************************************= ** Communications with GCHQ may be monitored and/or recorded=20 for system efficiency and other lawful purposes. Any views or=20 opinions expressed in this e-mail do not necessarily reflect GCHQ=20 policy. This email, and any attachments, is intended for the=20 attention of the addressee(s) only. Its unauthorised use,=20 disclosure, storage or copying is not permitted. If you are not the intended recipient, please notify postmaster@gchq.gsi.gov.uk. =20 This information is exempt from disclosure under the Freedom of=20 Information Act 2000 and may be subject to exemption under other UK information legislation. Refer disclosure requests to=20 GCHQ on 01242 221491 ext 30306 (non-secure) or email infoleg@gchq.gsi.gov.uk **************************************************************************= ** The original of this email was scanned for viruses by the Government Secur= e Intranet virus scanning service supplied by Cable&Wireless Worldwide in = partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On l= eaving the GSi this email was certified virus free. Communications via the GSi may be automatically logged, monitored and/or r= ecorded for legal purposes. From paul.hoffman@vpnc.org Fri Oct 28 10:07:13 2011 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 D5B4321F8663 for ; Fri, 28 Oct 2011 10:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.358 X-Spam-Level: X-Spam-Status: No, score=-102.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBvOLf48-VWn for ; Fri, 28 Oct 2011 10:07:13 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 635F921F85A8 for ; Fri, 28 Oct 2011 10:07:13 -0700 (PDT) Received: from [165.227.249.211] (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p9SH77eQ080772 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Oct 2011 10:07:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Fri, 28 Oct 2011 10:07:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7A848FE0-1FC3-465F-8A6E-A51964EE63C1@vpnc.org> References: To: "Ulliott, Chris" X-Mailer: Apple Mail (2.1251.1) Cc: IPsecme WG Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 17:07:13 -0000 On Oct 28, 2011, at 9:01 AM, Ulliott, Chris wrote: > So the assumption I've always had is that a spoke knows two things: >=20 > 1) a method to identify the next cryptographic hop > 2) a method to determine if it's allowed to talk to a specific = cryptographic hop once identified. >=20 > The second point could be solved through PKI and policy (although we = need a standard way to apply this) and the first could be solved through = numerous methods... the challenge is to find a standard way for all = vendors are willing to implement :-) The first point needs to be a bit more specific: "a method to identify = the next cryptographic hop towards a particular address range". --Paul Hoffman From Chris.Ulliott@cesg.gsi.gov.uk Fri Oct 28 10:25:14 2011 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 C517421F86D0 for ; Fri, 28 Oct 2011 10:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-QyyIg+Al+y for ; Fri, 28 Oct 2011 10:25:14 -0700 (PDT) Received: from mail89.messagelabs.com (mail89.messagelabs.com [194.106.220.3]) by ietfa.amsl.com (Postfix) with SMTP id DB0BF21F87D9 for ; Fri, 28 Oct 2011 10:25:13 -0700 (PDT) X-Env-Sender: Chris.Ulliott@cesg.gsi.gov.uk X-Msg-Ref: server-5.tower-89.messagelabs.com!1319822711!40289919!1 X-Originating-IP: [195.92.40.48] X-StarScan-Version: 6.3.6; banners=cesg.gsi.gov.uk,-,- X-VirusChecked: Checked Received: (qmail 11064 invoked from network); 28 Oct 2011 17:25:11 -0000 Received: from gateway-201.energis.gsi.gov.uk (HELO mx.hosting-e.gsi.gov.uk) (195.92.40.48) by server-5.tower-89.messagelabs.com with SMTP; 28 Oct 2011 17:25:11 -0000 From: "Ulliott, Chris" To: "'paul.hoffman@vpnc.org'" Date: Fri, 28 Oct 2011 18:25:05 +0100 Thread-Topic: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement Thread-Index: AcyVlAmJ6zE8CuJ1QTGXhWJqFRRZ2QAAn9Jq Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'ipsec@ietf.org'" Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 17:25:14 -0000 Q2xhc3NpZmljYXRpb246VU5DTEFTU0lGSUVECgpJZiBhIHZhbGlkIGFkZHJlc3MgcmFuZ2UgY291 bGQgaW5jbHVkZSAvMzIncyBpZSBhIHNpbmdsZSBob3N0LCBJJ2QgYWdyZWUuCgpDaHJpcwoKW1Ro aXMgbWVzc2FnZSBoYXMgYmVlbiBzZW50IGJ5IGEgbW9iaWxlIGRldmljZV0KCi0tLS0tIE9yaWdp bmFsIE1lc3NhZ2UgLS0tLS0KRnJvbTogUGF1bCBIb2ZmbWFuIDxwYXVsLmhvZmZtYW5AdnBuYy5v cmc+ClRvOiBVbGxpb3R0LCBDaHJpcwpDYzogSVBzZWNtZSBXRyA8aXBzZWNAaWV0Zi5vcmc+ClNl bnQ6IEZyaSBPY3QgMjggMTg6MDc6MDcgMjAxMQpTdWJqZWN0OiBSZTogW0lQc2VjXSBOZXcgLTAw IGRyYWZ0OiBDcmVhdGluZyBMYXJnZQlTY2FsZQlNZXNoCVZQTnMJUHJvYmxlbSBTdGF0ZW1lbnQK CgpPbiBPY3QgMjgsIDIwMTEsIGF0IDk6MDEgQU0sIFVsbGlvdHQsIENocmlzIHdyb3RlOgoKPiBT byB0aGUgYXNzdW1wdGlvbiBJJ3ZlIGFsd2F5cyBoYWQgaXMgdGhhdCBhIHNwb2tlIGtub3dzIHR3 byB0aGluZ3M6Cj4gCj4gMSkgYSBtZXRob2QgdG8gaWRlbnRpZnkgdGhlIG5leHQgY3J5cHRvZ3Jh cGhpYyBob3AKPiAyKSBhIG1ldGhvZCB0byBkZXRlcm1pbmUgaWYgaXQncyBhbGxvd2VkIHRvIHRh bGsgdG8gYSBzcGVjaWZpYyBjcnlwdG9ncmFwaGljIGhvcCBvbmNlIGlkZW50aWZpZWQuCj4gCj4g VGhlIHNlY29uZCBwb2ludCBjb3VsZCBiZSBzb2x2ZWQgdGhyb3VnaCBQS0kgYW5kIHBvbGljeSAo YWx0aG91Z2ggd2UgbmVlZCBhIHN0YW5kYXJkIHdheSB0byBhcHBseSB0aGlzKSBhbmQgdGhlIGZp cnN0IGNvdWxkIGJlIHNvbHZlZCB0aHJvdWdoIG51bWVyb3VzIG1ldGhvZHMuLi4gdGhlIGNoYWxs ZW5nZSBpcyB0byBmaW5kIGEgc3RhbmRhcmQgd2F5IGZvciBhbGwgdmVuZG9ycyBhcmUgd2lsbGlu ZyB0byBpbXBsZW1lbnQgOi0pCgpUaGUgZmlyc3QgcG9pbnQgbmVlZHMgdG8gYmUgYSBiaXQgbW9y ZSBzcGVjaWZpYzogImEgbWV0aG9kIHRvIGlkZW50aWZ5IHRoZSBuZXh0IGNyeXB0b2dyYXBoaWMg aG9wIHRvd2FyZHMgYSBwYXJ0aWN1bGFyIGFkZHJlc3MgcmFuZ2UiLgoKLS1QYXVsIEhvZmZtYW4K CgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqCkNvbW11bmljYXRpb25zIHdpdGggR0NIUSBtYXkgYmUgbW9u aXRvcmVkIGFuZC9vciByZWNvcmRlZCAKZm9yIHN5c3RlbSBlZmZpY2llbmN5IGFuZCBvdGhlciBs YXdmdWwgcHVycG9zZXMuIEFueSB2aWV3cyBvciAKb3BpbmlvbnMgZXhwcmVzc2VkIGluIHRoaXMg ZS1tYWlsIGRvIG5vdCBuZWNlc3NhcmlseSByZWZsZWN0IEdDSFEgCnBvbGljeS4gIFRoaXMgZW1h aWwsIGFuZCBhbnkgYXR0YWNobWVudHMsIGlzIGludGVuZGVkIGZvciB0aGUgCmF0dGVudGlvbiBv ZiB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIEl0cyB1bmF1dGhvcmlzZWQgdXNlLCAKZGlzY2xvc3Vy ZSwgc3RvcmFnZSBvciBjb3B5aW5nIGlzIG5vdCBwZXJtaXR0ZWQuICBJZiB5b3UgYXJlIG5vdCB0 aGUKaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHBvc3RtYXN0ZXJAZ2NocS5nc2ku Z292LnVrLiAgCgpUaGlzIGluZm9ybWF0aW9uIGlzIGV4ZW1wdCBmcm9tIGRpc2Nsb3N1cmUgdW5k ZXIgdGhlIEZyZWVkb20gb2YgCkluZm9ybWF0aW9uIEFjdCAyMDAwIGFuZCBtYXkgYmUgc3ViamVj dCB0byBleGVtcHRpb24gdW5kZXIKb3RoZXIgVUsgaW5mb3JtYXRpb24gbGVnaXNsYXRpb24uIFJl ZmVyIGRpc2Nsb3N1cmUgcmVxdWVzdHMgdG8gCkdDSFEgb24gMDEyNDIgMjIxNDkxIGV4dCAzMDMw NiAobm9uLXNlY3VyZSkgb3IgZW1haWwKaW5mb2xlZ0BnY2hxLmdzaS5nb3YudWsKCioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioKCgpUaGUgb3JpZ2luYWwgb2YgdGhpcyBlbWFpbCB3YXMgc2Nhbm5lZCBmb3Ig dmlydXNlcyBieSB0aGUgR292ZXJubWVudCBTZWN1cmUgSW50cmFuZXQgdmlydXMgc2Nhbm5pbmcg c2VydmljZSBzdXBwbGllZCBieSBDYWJsZSZXaXJlbGVzcyBXb3JsZHdpZGUgaW4gcGFydG5lcnNo aXAgd2l0aCBNZXNzYWdlTGFicy4gKENDVE0gQ2VydGlmaWNhdGUgTnVtYmVyIDIwMDkvMDkvMDA1 Mi4pIE9uIGxlYXZpbmcgdGhlIEdTaSB0aGlzIGVtYWlsIHdhcyBjZXJ0aWZpZWQgdmlydXMgZnJl ZS4KQ29tbXVuaWNhdGlvbnMgdmlhIHRoZSBHU2kgbWF5IGJlIGF1dG9tYXRpY2FsbHkgbG9nZ2Vk LCBtb25pdG9yZWQgYW5kL29yIHJlY29yZGVkIGZvciBsZWdhbCBwdXJwb3Nlcy4K From shanna@juniper.net Fri Oct 28 15:16:38 2011 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 6ABA91F0C43 for ; Fri, 28 Oct 2011 15:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.791 X-Spam-Level: X-Spam-Status: No, score=-105.791 tagged_above=-999 required=5 tests=[AWL=0.807, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bd7YsKprdQYy for ; Fri, 28 Oct 2011 15:16:37 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 502AD1F0C38 for ; Fri, 28 Oct 2011 15:16:30 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP; Fri, 28 Oct 2011 15:16:36 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 28 Oct 2011 15:09:30 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 28 Oct 2011 18:09:29 -0400 From: Stephen Hanna To: Yoav Nir , Geoffrey Huang Date: Fri, 28 Oct 2011 18:09:27 -0400 Thread-Topic: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Thread-Index: AcyVeedTAgoijwbeQ7O9PAVuhxKapgARBv4g Message-ID: References: <84600D05C20FF943918238042D7670FD41BF14E8A3@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AC6674AB7BC78549BB231821ABF7A9AEB80F02CF33EMBX01WFjnprn_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs 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, 28 Oct 2011 22:16:38 -0000 --_000_AC6674AB7BC78549BB231821ABF7A9AEB80F02CF33EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree. Wednesday night would be best. Who else is interested in getting together to discuss this? Clearly, there = are plenty of interesting issues to discuss. Steve From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= oav Nir Sent: Friday, October 28, 2011 10:00 AM To: Geoffrey Huang; Stephen Hanna Cc: ipsec@ietf.org Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Well, there is a free room between 1300-1500 on Wednesday, but then we're o= pposite WebSec, and I can't attend. Our best bet is to do it after the Plenary. The plenary ends at 19:30, and = people might want to grab something to eat, so it would probably be best to= do it at 20:00. Hope you don't have a flight for Wednesday night... On 10/26/11 10:19 PM, "Geoffrey Huang" > wrote: I have to agree with the recent comments about the inapplicability of RFC 4= 322. I don't think that a DNNSEC infrastructure can be assumed, particular= ly not in the deployments I have seen. I agree with Steve Hanna's comments about the need for ad-hoc peer-to-peer = VPNs, bypassing a centralized hub. I also agree with Paul Hoffman's commen= ts about using an already-existing "trusted introducer." Finally, I will be in Taiwan, but specifically (only) to discuss this topic= . I'm hoping that the date of Wednesday, November 16 is still good for the= bar BOF that some of us had previously discussed. -geoff --_000_AC6674AB7BC78549BB231821ABF7A9AEB80F02CF33EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree. Wednesday night would be best.

 

= Who else is interested in getting together to discuss this? Clearly, there = are plenty of interesting issues to discuss.

 

Steve

<= p class=3DMsoNormal> <= /p>

From: ipsec-bounces@ietf.org [ma= ilto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir
Sent: F= riday, October 28, 2011 10:00 AM
To: Geoffrey Huang; Stephen Hann= a
Cc: ipsec@ietf.org
Subject: Re: [IPsec] New -00 draft= : Creating Large Scale Mesh VPNs Problem

<= p class=3DMsoNormal> 

Well, there is a free room between 130= 0-1500 on Wednesday, but then we're opposite WebSec, and I can't attend.

 

Our best bet is to do it= after the Plenary. The plenary ends at 19:30, and people might want to gra= b something to eat, so it would probably be best to do it at 20:00. 

 

Hope you don't have a f= light for Wednesday night…

 =

On 10/26/11 10:19 PM, "Geoffrey Huang" <ghuang@juniper.net> wrote:

 

I have to agr= ee with the recent comments about the inapplicability of RFC 4322.  I = don’t think that a DNNSEC infrastructure can be assumed, particularly= not in the deployments I have seen.

 

I agree with Steve Hanna’s comments= about the need for ad-hoc peer-to-peer VPNs, bypassing a centralized hub.&= nbsp; I also agree with Paul Hoffman’s comments about using an alread= y-existing “trusted introducer.”

 

Finally, I will be in Taiwan, bu= t specifically (only) to discuss this topic.  I’m hoping that th= e date of Wednesday, November 16 is still good for the bar BOF that some of= us had previously discussed.

 

<= span style=3D'color:black'>-geoff

= --_000_AC6674AB7BC78549BB231821ABF7A9AEB80F02CF33EMBX01WFjnprn_-- From irani@spawar.navy.mil Fri Oct 28 16:00:45 2011 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 0F0D21F0C34 for ; Fri, 28 Oct 2011 16:00:45 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpAYw2p8kL4t for ; Fri, 28 Oct 2011 16:00:43 -0700 (PDT) Received: from ins2.sd.spawar.navy.mil (ins2.sd.spawar.navy.mil [IPv6:2001:480:10:4::3]) by ietfa.amsl.com (Postfix) with ESMTP id 06A0B1F0C43 for ; Fri, 28 Oct 2011 16:00:42 -0700 (PDT) Received: from [IPv6:2001:480:10:160:224:e8ff:fed6:117d] (poo.sd.spawar.navy.mil [IPv6:2001:480:10:160:224:e8ff:fed6:117d]) (authenticated bits=0) by ins2.sd.spawar.navy.mil (8.13.1/8.13.1) with ESMTP id p9SN0UOK016928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 28 Oct 2011 16:00:42 -0700 Message-ID: <4EAB340E.9050509@spawar.navy.mil> Date: Fri, 28 Oct 2011 16:00:30 -0700 From: Mike Irani User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: ipsec@ietf.org References: <84600D05C20FF943918238042D7670FD41BF14E8A3@EMBX01-HQ.jnpr.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020702050204020005000604" Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs 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, 28 Oct 2011 23:00:45 -0000 This is a multi-part message in MIME format. --------------020702050204020005000604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I am definitely interested in attending. Weds night works here. On 10/28/2011 3:09 PM, Stephen Hanna wrote: > > I agree. Wednesday night would be best. > > Who else is interested in getting together to discuss this? Clearly, > there are plenty of interesting issues to discuss. > > Steve > > *From:*ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] *On > Behalf Of *Yoav Nir > *Sent:* Friday, October 28, 2011 10:00 AM > *To:* Geoffrey Huang; Stephen Hanna > *Cc:* ipsec@ietf.org > *Subject:* Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs > Problem > > Well, there is a free room between 1300-1500 on Wednesday, but then > we're opposite WebSec, and I can't attend. > > Our best bet is to do it after the Plenary. The plenary ends at 19:30, > and people might want to grab something to eat, so it would probably > be best to do it at 20:00. > > Hope you don't have a flight for Wednesday night... > > On 10/26/11 10:19 PM, "Geoffrey Huang" > wrote: > > I have to agree with the recent comments about the inapplicability > of RFC 4322. I don't think that a DNNSEC infrastructure can be > assumed, particularly not in the deployments I have seen. > > I agree with Steve Hanna's comments about the need for ad-hoc > peer-to-peer VPNs, bypassing a centralized hub. I also agree with > Paul Hoffman's comments about using an already-existing "trusted > introducer." > > Finally, I will be in Taiwan, but specifically (only) to discuss > this topic. I'm hoping that the date of Wednesday, November 16 is > still good for the bar BOF that some of us had previously discussed. > > -geoff > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --------------020702050204020005000604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I am definitely interested in attending. Weds night works here.


 

On 10/28/2011 3:09 PM, Stephen Hanna wrote:

I agree. Wednesday night would be best.

 

Who else is interested in getting together to discuss this? Clearly, there are plenty of interesting issues to discuss.

 

Steve

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir
Sent: Friday, October 28, 2011 10:00 AM
To: Geoffrey Huang; Stephen Hanna
Cc: ipsec@ietf.org
Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

 

Well, there is a free room between 1300-1500 on Wednesday, but then we're opposite WebSec, and I can't attend.

 

Our best bet is to do it after the Plenary. The plenary ends at 19:30, and people might want to grab something to eat, so it would probably be best to do it at 20:00. 

 

Hope you don't have a flight for Wednesday night…

 

On 10/26/11 10:19 PM, "Geoffrey Huang" <ghuang@juniper.net> wrote:

 

I have to agree with the recent comments about the inapplicability of RFC 4322.  I don’t think that a DNNSEC infrastructure can be assumed, particularly not in the deployments I have seen.

 

I agree with Steve Hanna’s comments about the need for ad-hoc peer-to-peer VPNs, bypassing a centralized hub.  I also agree with Paul Hoffman’s comments about using an already-existing “trusted introducer.”

 

Finally, I will be in Taiwan, but specifically (only) to discuss this topic.  I’m hoping that the date of Wednesday, November 16 is still good for the bar BOF that some of us had previously discussed.

 

-geoff



_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--------------020702050204020005000604-- From Chris.Ulliott@cesg.gsi.gov.uk Sat Oct 29 01:06:11 2011 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 4410121F854E for ; Sat, 29 Oct 2011 01:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJhqvIEa0z9d for ; Sat, 29 Oct 2011 01:06:10 -0700 (PDT) Received: from mail185.messagelabs.com (mail185.messagelabs.com [85.158.143.19]) by ietfa.amsl.com (Postfix) with SMTP id 93D6E21F854D for ; Sat, 29 Oct 2011 01:06:09 -0700 (PDT) X-Env-Sender: Chris.Ulliott@cesg.gsi.gov.uk X-Msg-Ref: server-4.tower-185.messagelabs.com!1319875566!1704565!1 X-Originating-IP: [195.92.40.48] X-StarScan-Version: 6.3.6; banners=cesg.gsi.gov.uk,-,- X-VirusChecked: Checked Received: (qmail 12004 invoked from network); 29 Oct 2011 08:06:06 -0000 Received: from gateway-201.energis.gsi.gov.uk (HELO mx.hosting-e.gsi.gov.uk) (195.92.40.48) by server-4.tower-185.messagelabs.com with SMTP; 29 Oct 2011 08:06:06 -0000 From: "Ulliott, Chris" To: "'shanna@juniper.net'" Date: Sat, 29 Oct 2011 09:05:58 +0100 Thread-Topic: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Thread-Index: AcyVeedTAgoijwbeQ7O9PAVuhxKapgARBv4gABTlCFU= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A5B7123F7AE40F4ABFF0BCAC7D12145A0C24B922FFPIACHEEXG11GC_" MIME-Version: 1.0 Cc: "'ipsec@ietf.org'" Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs 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: Sat, 29 Oct 2011 08:06:11 -0000 --_000_A5B7123F7AE40F4ABFF0BCAC7D12145A0C24B922FFPIACHEEXG11GC_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2xhc3NpZmljYXRpb246VU5DTEFTU0lGSUVECgpTYWRseSBJIGNhbid0IGpvaW4gaW4gcGVyc29u LCBidXQgYW0gbW9yZSB0aGFuIGhhcHB5IHRvIHByZXNlbnQgYSB2aXJ0dWFsIG1lIGlmIGl0J3Mg cG9zc2libGUgZGlhbCBpbi4KCkNocmlzCgpbVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNlbnQgYnkg YSBtb2JpbGUgZGV2aWNlXQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRnJvbTog aXBzZWMtYm91bmNlc0BpZXRmLm9yZwpUbzogWW9hdiBOaXIgOyBHZW9mZnJleSBIdWFuZwpDYzog aXBzZWNAaWV0Zi5vcmcKU2VudDogRnJpIE9jdCAyOCAyMzowOToyNyAyMDExClN1YmplY3Q6IFJl OiBbSVBzZWNdIE5ldyAtMDAgZHJhZnQ6IENyZWF0aW5nIExhcmdlIFNjYWxlIE1lc2ggVlBOcyBQ cm9ibGVtCkkgYWdyZWUuIFdlZG5lc2RheSBuaWdodCB3b3VsZCBiZSBiZXN0LgoKV2hvIGVsc2Ug aXMgaW50ZXJlc3RlZCBpbiBnZXR0aW5nIHRvZ2V0aGVyIHRvIGRpc2N1c3MgdGhpcz8gQ2xlYXJs eSwgdGhlcmUgYXJlIHBsZW50eSBvZiBpbnRlcmVzdGluZyBpc3N1ZXMgdG8gZGlzY3Vzcy4KClN0 ZXZlCgpGcm9tOiBpcHNlYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aXBzZWMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFlvYXYgTmlyClNlbnQ6IEZyaWRheSwgT2N0b2JlciAyOCwg MjAxMSAxMDowMCBBTQpUbzogR2VvZmZyZXkgSHVhbmc7IFN0ZXBoZW4gSGFubmEKQ2M6IGlwc2Vj QGlldGYub3JnClN1YmplY3Q6IFJlOiBbSVBzZWNdIE5ldyAtMDAgZHJhZnQ6IENyZWF0aW5nIExh cmdlIFNjYWxlIE1lc2ggVlBOcyBQcm9ibGVtCgpXZWxsLCB0aGVyZSBpcyBhIGZyZWUgcm9vbSBi ZXR3ZWVuIDEzMDAtMTUwMCBvbiBXZWRuZXNkYXksIGJ1dCB0aGVuIHdlJ3JlIG9wcG9zaXRlIFdl YlNlYywgYW5kIEkgY2FuJ3QgYXR0ZW5kLgoKT3VyIGJlc3QgYmV0IGlzIHRvIGRvIGl0IGFmdGVy IHRoZSBQbGVuYXJ5LiBUaGUgcGxlbmFyeSBlbmRzIGF0IDE5OjMwLCBhbmQgcGVvcGxlIG1pZ2h0 IHdhbnQgdG8gZ3JhYiBzb21ldGhpbmcgdG8gZWF0LCBzbyBpdCB3b3VsZCBwcm9iYWJseSBiZSBi ZXN0IHRvIGRvIGl0IGF0IDIwOjAwLgoKSG9wZSB5b3UgZG9uJ3QgaGF2ZSBhIGZsaWdodCBmb3Ig V2VkbmVzZGF5IG5pZ2h04oCmCgpPbiAxMC8yNi8xMSAxMDoxOSBQTSwgIkdlb2ZmcmV5IEh1YW5n IiA8Z2h1YW5nQGp1bmlwZXIubmV0PG1haWx0bzpnaHVhbmdAanVuaXBlci5uZXQ+PiB3cm90ZToK CkkgaGF2ZSB0byBhZ3JlZSB3aXRoIHRoZSByZWNlbnQgY29tbWVudHMgYWJvdXQgdGhlIGluYXBw bGljYWJpbGl0eSBvZiBSRkMgNDMyMi4gIEkgZG9u4oCZdCB0aGluayB0aGF0IGEgRE5OU0VDIGlu ZnJhc3RydWN0dXJlIGNhbiBiZSBhc3N1bWVkLCBwYXJ0aWN1bGFybHkgbm90IGluIHRoZSBkZXBs b3ltZW50cyBJIGhhdmUgc2Vlbi4KCkkgYWdyZWUgd2l0aCBTdGV2ZSBIYW5uYeKAmXMgY29tbWVu dHMgYWJvdXQgdGhlIG5lZWQgZm9yIGFkLWhvYyBwZWVyLXRvLXBlZXIgVlBOcywgYnlwYXNzaW5n IGEgY2VudHJhbGl6ZWQgaHViLiAgSSBhbHNvIGFncmVlIHdpdGggUGF1bCBIb2ZmbWFu4oCZcyBj b21tZW50cyBhYm91dCB1c2luZyBhbiBhbHJlYWR5LWV4aXN0aW5nIOKAnHRydXN0ZWQgaW50cm9k dWNlci7igJ0KCkZpbmFsbHksIEkgd2lsbCBiZSBpbiBUYWl3YW4sIGJ1dCBzcGVjaWZpY2FsbHkg KG9ubHkpIHRvIGRpc2N1c3MgdGhpcyB0b3BpYy4gIEnigJltIGhvcGluZyB0aGF0IHRoZSBkYXRl IG9mIFdlZG5lc2RheSwgTm92ZW1iZXIgMTYgaXMgc3RpbGwgZ29vZCBmb3IgdGhlIGJhciBCT0Yg dGhhdCBzb21lIG9mIHVzIGhhZCBwcmV2aW91c2x5IGRpc2N1c3NlZC4KCi1nZW9mZgoKVGhpcyBl bWFpbCB3YXMgcmVjZWl2ZWQgZnJvbSB0aGUgSU5URVJORVQgYW5kIHNjYW5uZWQgYnkgdGhlIEdv dmVybm1lbnQgU2VjdXJlIEludHJhbmV0IGFudGktdmlydXMgc2VydmljZSBzdXBwbGllZCBieSBD YWJsZSZXaXJlbGVzcyBXb3JsZHdpZGUgaW4gcGFydG5lcnNoaXAgd2l0aCBNZXNzYWdlTGFicy4g KENDVE0gQ2VydGlmaWNhdGUgTnVtYmVyIDIwMDkvMDkvMDA1Mi4pIEluIGNhc2Ugb2YgcHJvYmxl bXMsIHBsZWFzZSBjYWxsIHlvdXIgb3JnYW5pc2F0aW9u4oCZcyBJVCBIZWxwZGVzay4KQ29tbXVu aWNhdGlvbnMgdmlhIHRoZSBHU2kgbWF5IGJlIGF1dG9tYXRpY2FsbHkgbG9nZ2VkLCBtb25pdG9y ZWQgYW5kL29yIHJlY29yZGVkIGZvciBsZWdhbCBwdXJwb3Nlcy4KCioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioKQ29tbXVuaWNhdGlvbnMgd2l0aCBHQ0hRIG1heSBiZSBtb25pdG9yZWQgYW5kL29yIHJlY29y ZGVkIApmb3Igc3lzdGVtIGVmZmljaWVuY3kgYW5kIG90aGVyIGxhd2Z1bCBwdXJwb3Nlcy4gQW55 IHZpZXdzIG9yIApvcGluaW9ucyBleHByZXNzZWQgaW4gdGhpcyBlLW1haWwgZG8gbm90IG5lY2Vz c2FyaWx5IHJlZmxlY3QgR0NIUSAKcG9saWN5LiAgVGhpcyBlbWFpbCwgYW5kIGFueSBhdHRhY2ht ZW50cywgaXMgaW50ZW5kZWQgZm9yIHRoZSAKYXR0ZW50aW9uIG9mIHRoZSBhZGRyZXNzZWUocykg b25seS4gSXRzIHVuYXV0aG9yaXNlZCB1c2UsIApkaXNjbG9zdXJlLCBzdG9yYWdlIG9yIGNvcHlp bmcgaXMgbm90IHBlcm1pdHRlZC4gIElmIHlvdSBhcmUgbm90IHRoZQppbnRlbmRlZCByZWNpcGll bnQsIHBsZWFzZSBub3RpZnkgcG9zdG1hc3RlckBnY2hxLmdzaS5nb3YudWsuICAKClRoaXMgaW5m b3JtYXRpb24gaXMgZXhlbXB0IGZyb20gZGlzY2xvc3VyZSB1bmRlciB0aGUgRnJlZWRvbSBvZiAK SW5mb3JtYXRpb24gQWN0IDIwMDAgYW5kIG1heSBiZSBzdWJqZWN0IHRvIGV4ZW1wdGlvbiB1bmRl cgpvdGhlciBVSyBpbmZvcm1hdGlvbiBsZWdpc2xhdGlvbi4gUmVmZXIgZGlzY2xvc3VyZSByZXF1 ZXN0cyB0byAKR0NIUSBvbiAwMTI0MiAyMjE0OTEgZXh0IDMwMzA2IChub24tc2VjdXJlKSBvciBl bWFpbAppbmZvbGVnQGdjaHEuZ3NpLmdvdi51awoKKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgoKClRoZSBv cmlnaW5hbCBvZiB0aGlzIGVtYWlsIHdhcyBzY2FubmVkIGZvciB2aXJ1c2VzIGJ5IHRoZSBHb3Zl cm5tZW50IFNlY3VyZSBJbnRyYW5ldCB2aXJ1cyBzY2FubmluZyBzZXJ2aWNlIHN1cHBsaWVkIGJ5 IENhYmxlJldpcmVsZXNzIFdvcmxkd2lkZSBpbiBwYXJ0bmVyc2hpcCB3aXRoIE1lc3NhZ2VMYWJz LiAoQ0NUTSBDZXJ0aWZpY2F0ZSBOdW1iZXIgMjAwOS8wOS8wMDUyLikgT24gbGVhdmluZyB0aGUg R1NpIHRoaXMgZW1haWwgd2FzIGNlcnRpZmllZCB2aXJ1cyBmcmVlLgpDb21tdW5pY2F0aW9ucyB2 aWEgdGhlIEdTaSBtYXkgYmUgYXV0b21hdGljYWxseSBsb2dnZWQsIG1vbml0b3JlZCBhbmQvb3Ig cmVjb3JkZWQgZm9yIGxlZ2FsIHB1cnBvc2VzLgo= --_000_A5B7123F7AE40F4ABFF0BCAC7D12145A0C24B922FFPIACHEEXG11GC_ Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+CjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVdpbmRvd3MtMTI1MiI+PG1ldGEgbmFtZT0iR2VuZXJh dG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxl PjwhLS0KLyogRm9udCBEZWZpbml0aW9ucyAqLwpAZm9udC1mYWNlCgl7Zm9udC1mYW1pbHk6IkNh bWJyaWEgTWF0aCI7CglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30KQGZvbnQtZmFjZQoJ e2ZvbnQtZmFtaWx5OkNhbGlicmk7CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9CkBm b250LWZhY2UKCXtmb250LWZhbWlseTpUYWhvbWE7CglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0 IDIgNDt9Ci8qIFN0eWxlIERlZmluaXRpb25zICovCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwKCXttYXJnaW46MGluOwoJbWFyZ2luLWJvdHRvbTouMDAwMXB0OwoJZm9u dC1zaXplOjExLjBwdDsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6Ymx1 ZTsKCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQKCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7Cgljb2xvcjpwdXJwbGU7Cgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30Kc3Bhbi5FbWFpbFN0eWxlMTcKCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Cgljb2xvcjp3 aW5kb3d0ZXh0O30Kc3Bhbi5FbWFpbFN0eWxlMTgKCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Cgljb2xvcjojMUY0OTdE O30KLk1zb0NocERlZmF1bHQKCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsKCWZvbnQtc2l6 ZToxMC4wcHQ7fQpAcGFnZSBXb3JkU2VjdGlvbjEKCXtzaXplOjguNWluIDExLjBpbjsKCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9CmRpdi5Xb3JkU2VjdGlvbjEKCXtwYWdlOldvcmRT ZWN0aW9uMTt9Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+CjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+CjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPgo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+CjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPgo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl IiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOy13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTst d2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlIj48cD48Zm9udCBzaXplPTIgY29s b3I9bmF2eSBmYWNlPUFyaWFsPgpDbGFzc2lmaWNhdGlvbjpVTkNMQVNTSUZJRUQ8YnI+PGJyPlNh ZGx5IEkgY2FuJ3Qgam9pbiBpbiBwZXJzb24sIGJ1dCBhbSBtb3JlIHRoYW4gaGFwcHkgdG8gcHJl c2VudCBhIHZpcnR1YWwgbWUgaWYgaXQncyBwb3NzaWJsZSBkaWFsIGluLjxicj48YnI+Q2hyaXMN PGJyPg08YnI+W1RoaXMgbWVzc2FnZSBoYXMgYmVlbiBzZW50IGJ5IGEgbW9iaWxlIGRldmljZV08 L2ZvbnQ+PC9wPgo8cD48aHIgc2l6ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXIgdGFiaW5k ZXg9LTE+Cjxmb250IGZhY2U9VGFob21hIHNpemU9Mj4KPGI+RnJvbTwvYj46IGlwc2VjLWJvdW5j ZXNAaWV0Zi5vcmcgPGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmc+DTxicj48Yj5UbzwvYj46IFlvYXYg TmlyIDx5bmlyQGNoZWNrcG9pbnQuY29tPjsgR2VvZmZyZXkgSHVhbmcgPGdodWFuZ0BqdW5pcGVy Lm5ldD4NPGJyPjxiPkNjPC9iPjogaXBzZWNAaWV0Zi5vcmcgPGlwc2VjQGlldGYub3JnPg08YnI+ PGI+U2VudDwvYj46IEZyaSBPY3QgMjggMjM6MDk6MjcgMjAxMTxicj48Yj5TdWJqZWN0PC9iPjog UmU6IFtJUHNlY10gTmV3IC0wMCBkcmFmdDogQ3JlYXRpbmcgTGFyZ2UgU2NhbGUgTWVzaCBWUE5z IFByb2JsZW0NPGJyPjwvZm9udD48L3A+CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+PHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgYWdyZWUuIFdlZG5l c2RheSBuaWdodCB3b3VsZCBiZSBiZXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5XaG8gZWxzZSBpcyBpbnRlcmVzdGVkIGluIGdldHRpbmcgdG9nZXRoZXIgdG8gZGlzY3VzcyB0 aGlzPyBDbGVhcmx5LCB0aGVyZSBhcmUgcGxlbnR5IG9mIGludGVyZXN0aW5nIGlzc3VlcyB0byBk aXNjdXNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TdGV2ZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+PGRp dj48ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppcHNlYy1ib3VuY2VzQGll dGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPllvYXYgTmlyPGJyPjxiPlNlbnQ6PC9iPiBGcmlk YXksIE9jdG9iZXIgMjgsIDIwMTEgMTA6MDAgQU08YnI+PGI+VG86PC9iPiBHZW9mZnJleSBIdWFu ZzsgU3RlcGhlbiBIYW5uYTxicj48Yj5DYzo8L2I+IGlwc2VjQGlldGYub3JnPGJyPjxiPlN1Ympl Y3Q6PC9iPiBSZTogW0lQc2VjXSBOZXcgLTAwIGRyYWZ0OiBDcmVhdGluZyBMYXJnZSBTY2FsZSBN ZXNoIFZQTnMgUHJvYmxlbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5XZWxsLCB0aGVy ZSBpcyBhIGZyZWUgcm9vbSBiZXR3ZWVuIDEzMDAtMTUwMCBvbiBXZWRuZXNkYXksIGJ1dCB0aGVu IHdlJ3JlIG9wcG9zaXRlIFdlYlNlYywgYW5kIEkgY2FuJ3QgYXR0ZW5kLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtjb2xvcjpibGFjayI+T3VyIGJlc3QgYmV0IGlzIHRvIGRvIGl0IGFmdGVyIHRoZSBQbGVuYXJ5 LiBUaGUgcGxlbmFyeSBlbmRzIGF0IDE5OjMwLCBhbmQgcGVvcGxlIG1pZ2h0IHdhbnQgdG8gZ3Jh YiBzb21ldGhpbmcgdG8gZWF0LCBzbyBpdCB3b3VsZCBwcm9iYWJseSBiZSBiZXN0IHRvIGRvIGl0 IGF0IDIwOjAwLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+SG9wZSB5b3UgZG9u J3QgaGF2ZSBhIGZsaWdodCBmb3IgV2VkbmVzZGF5IG5pZ2h04oCmPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6YmxhY2siPk9uIDEwLzI2LzExIDEwOjE5IFBNLCAmcXVvdDtHZW9mZnJleSBIdWFu ZyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdodWFuZ0BqdW5pcGVyLm5ldCI+Z2h1YW5nQGp1 bmlwZXIubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2 PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGlu IiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+PGRpdj48ZGl2PjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SSBoYXZlIHRvIGFncmVl IHdpdGggdGhlIHJlY2VudCBjb21tZW50cyBhYm91dCB0aGUgaW5hcHBsaWNhYmlsaXR5IG9mIFJG QyA0MzIyLiZuYnNwOyBJIGRvbuKAmXQgdGhpbmsgdGhhdCBhIEROTlNFQyBpbmZyYXN0cnVjdHVy ZSBjYW4gYmUgYXNzdW1lZCwgcGFydGljdWxhcmx5IG5vdCBpbiB0aGUgZGVwbG95bWVudHMgSSBo YXZlIHNlZW4uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SSBhZ3JlZSB3aXRoIFN0ZXZl IEhhbm5h4oCZcyBjb21tZW50cyBhYm91dCB0aGUgbmVlZCBmb3IgYWQtaG9jIHBlZXItdG8tcGVl ciBWUE5zLCBieXBhc3NpbmcgYSBjZW50cmFsaXplZCBodWIuJm5ic3A7IEkgYWxzbyBhZ3JlZSB3 aXRoIFBhdWwgSG9mZm1hbuKAmXMgY29tbWVudHMgYWJvdXQgdXNpbmcgYW4gYWxyZWFkeS1leGlz dGluZyDigJx0cnVzdGVkIGludHJvZHVjZXIu4oCdPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+RmluYWxseSwgSSB3aWxsIGJlIGluIFRhaXdhbiwgYnV0IHNwZWNpZmljYWxseSAob25seSkg dG8gZGlzY3VzcyB0aGlzIHRvcGljLiZuYnNwOyBJ4oCZbSBob3BpbmcgdGhhdCB0aGUgZGF0ZSBv ZiBXZWRuZXNkYXksIE5vdmVtYmVyIDE2IGlzIHN0aWxsIGdvb2QgZm9yIHRoZSBiYXIgQk9GIHRo YXQgc29tZSBvZiB1cyBoYWQgcHJldmlvdXNseSBkaXNjdXNzZWQuPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+LWdlb2ZmPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvYmxv Y2txdW90ZT48L2Rpdj48L2Rpdj48YnIgY2xlYXI9ImJvdGgiPgpUaGlzIGVtYWlsIHdhcyByZWNl aXZlZCBmcm9tIHRoZSBJTlRFUk5FVCBhbmQgc2Nhbm5lZCBieSB0aGUgR292ZXJubWVudCBTZWN1 cmUgSW50cmFuZXQgYW50aS12aXJ1cyBzZXJ2aWNlIHN1cHBsaWVkIGJ5IENhYmxlJmFtcDtXaXJl bGVzcyBXb3JsZHdpZGUgaW4gcGFydG5lcnNoaXAgd2l0aCBNZXNzYWdlTGFicy4gKENDVE0gQ2Vy dGlmaWNhdGUgTnVtYmVyIDIwMDkvMDkvMDA1Mi4pIEluIGNhc2Ugb2YgcHJvYmxlbXMsIHBsZWFz ZSBjYWxsIHlvdXIgb3JnYW5pc2F0aW9u4oCZcyBJVCBIZWxwZGVzay4gPGJyPgpDb21tdW5pY2F0 aW9ucyB2aWEgdGhlIEdTaSBtYXkgYmUgYXV0b21hdGljYWxseSBsb2dnZWQsIG1vbml0b3JlZCBh bmQvb3IgcmVjb3JkZWQgZm9yIGxlZ2FsIHB1cnBvc2VzLjxicj4KCjxwPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTonQXJpYWwnO2ZvbnQtc2l6ZTo4cHQ7Ij4qKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPC9z cGFuPjwvcD4KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OidBcmlhbCc7Zm9udC1zaXplOjhw dDsiPkNvbW11bmljYXRpb25zIHdpdGggR0NIUSBtYXkgYmUgbW9uaXRvcmVkIGFuZC9vciByZWNv cmRlZCA8L3NwYW4+PC9wPgo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6J0FyaWFsJztmb250 LXNpemU6OHB0OyI+Zm9yIHN5c3RlbSBlZmZpY2llbmN5IGFuZCBvdGhlciBsYXdmdWwgcHVycG9z ZXMuIEFueSB2aWV3cyBvciA8L3NwYW4+PC9wPgo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 J0FyaWFsJztmb250LXNpemU6OHB0OyI+b3BpbmlvbnMgZXhwcmVzc2VkIGluIHRoaXMgZS1tYWls IGRvIG5vdCBuZWNlc3NhcmlseSByZWZsZWN0IEdDSFEgPC9zcGFuPjwvcD4KPHA+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OidBcmlhbCc7Zm9udC1zaXplOjhwdDsiPnBvbGljeS4gIFRoaXMgZW1h aWwsIGFuZCBhbnkgYXR0YWNobWVudHMsIGlzIGludGVuZGVkIGZvciB0aGUgPC9zcGFuPjwvcD4K PHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OidBcmlhbCc7Zm9udC1zaXplOjhwdDsiPmF0dGVu dGlvbiBvZiB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIEl0cyB1bmF1dGhvcmlzZWQgdXNlLCA8L3Nw YW4+PC9wPgo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6J0FyaWFsJztmb250LXNpemU6OHB0 OyI+ZGlzY2xvc3VyZSwgc3RvcmFnZSBvciBjb3B5aW5nIGlzIG5vdCBwZXJtaXR0ZWQuICBJZiB5 b3UgYXJlIG5vdCB0aGU8L3NwYW4+PC9wPgo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6J0Fy aWFsJztmb250LXNpemU6OHB0OyI+aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHBv c3RtYXN0ZXJAZ2NocS5nc2kuZ292LnVrLiAgPC9zcGFuPjwvcD4KPHA+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OidBcmlhbCc7Zm9udC1zaXplOjhwdDsiPjwvc3Bhbj48L3A+CjxwPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTonQXJpYWwnO2ZvbnQtc2l6ZTo4cHQ7Ij4mbmJzcDs8L3NwYW4+PC9w Pgo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6J0FyaWFsJztmb250LXNpemU6OHB0OyI+VGhp cyBpbmZvcm1hdGlvbiBpcyBleGVtcHQgZnJvbSBkaXNjbG9zdXJlIHVuZGVyIHRoZSBGcmVlZG9t IG9mIDwvc3Bhbj48L3A+CjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTonQXJpYWwnO2ZvbnQt c2l6ZTo4cHQ7Ij5JbmZvcm1hdGlvbiBBY3QgMjAwMCBhbmQgbWF5IGJlIHN1YmplY3QgdG8gZXhl bXB0aW9uIHVuZGVyPC9zcGFuPjwvcD4KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OidBcmlh bCc7Zm9udC1zaXplOjhwdDsiPm90aGVyIFVLIGluZm9ybWF0aW9uIGxlZ2lzbGF0aW9uLiBSZWZl ciBkaXNjbG9zdXJlIHJlcXVlc3RzIHRvIDwvc3Bhbj48L3A+CjxwPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTonQXJpYWwnO2ZvbnQtc2l6ZTo4cHQ7Ij5HQ0hRIG9uIDAxMjQyIDIyMTQ5MSBleHQg MzAzMDYgKG5vbi1zZWN1cmUpIG9yIGVtYWlsPC9zcGFuPjwvcD4KPHA+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OidBcmlhbCc7Zm9udC1zaXplOjhwdDsiPmluZm9sZWdAZ2NocS5nc2kuZ292LnVr PC9zcGFuPjwvcD4KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OidBcmlhbCc7Zm9udC1zaXpl OjhwdDsiPjwvc3Bhbj48L3A+CjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTonQXJpYWwnO2Zv bnQtc2l6ZTo4cHQ7Ij4mbmJzcDs8L3NwYW4+PC9wPgo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6J0FyaWFsJztmb250LXNpemU6OHB0OyI+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjwvc3Bhbj48L3A+ CjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTonQXJpYWwnO2ZvbnQtc2l6ZTo4cHQ7Ij4mbmJz cDs8L3NwYW4+PC9wPjxiciBjbGVhcj0iYm90aCI+ClRoZSBvcmlnaW5hbCBvZiB0aGlzIGVtYWls IHdhcyBzY2FubmVkIGZvciB2aXJ1c2VzIGJ5IHRoZSBHb3Zlcm5tZW50IFNlY3VyZSBJbnRyYW5l dCB2aXJ1cyBzY2FubmluZyBzZXJ2aWNlIHN1cHBsaWVkIGJ5IENhYmxlJldpcmVsZXNzIFdvcmxk d2lkZSBpbiBwYXJ0bmVyc2hpcCB3aXRoIE1lc3NhZ2VMYWJzLiAoQ0NUTSBDZXJ0aWZpY2F0ZSBO dW1iZXIgMjAwOS8wOS8wMDUyLikgT24gbGVhdmluZyB0aGUgR1NpIHRoaXMgZW1haWwgd2FzIGNl cnRpZmllZCB2aXJ1cyBmcmVlLjxCUj4KQ29tbXVuaWNhdGlvbnMgdmlhIHRoZSBHU2kgbWF5IGJl IGF1dG9tYXRpY2FsbHkgbG9nZ2VkLCBtb25pdG9yZWQgYW5kL29yIHJlY29yZGVkIGZvciBsZWdh bCBwdXJwb3Nlcy48QlI+CjwvYm9keT48L2h0bWw+Cg== --_000_A5B7123F7AE40F4ABFF0BCAC7D12145A0C24B922FFPIACHEEXG11GC_-- From jcoronel@live.com Sat Oct 29 09:18:13 2011 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 64EC621F8AAC for ; Sat, 29 Oct 2011 09:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bd5MxhULD46B for ; Sat, 29 Oct 2011 09:18:12 -0700 (PDT) Received: from blu0-omc2-s19.blu0.hotmail.com (blu0-omc2-s19.blu0.hotmail.com [65.55.111.94]) by ietfa.amsl.com (Postfix) with ESMTP id DFA1F21F8A7B for ; Sat, 29 Oct 2011 09:18:11 -0700 (PDT) Received: from BLU0-SMTP397 ([65.55.111.72]) by blu0-omc2-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 29 Oct 2011 09:18:11 -0700 X-Originating-IP: [76.22.107.105] X-Originating-Email: [jcoronel@live.com] Message-ID: Received: from HOMEPC1 ([76.22.107.105]) by BLU0-SMTP397.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 29 Oct 2011 09:18:10 -0700 From: Jorge Coronel To: "'Geoffrey Huang'" , References: <84600D05C20FF943918238042D7670FD41BF14E8A3@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD41BF14E8A3@EMBX01-HQ.jnpr.net> Date: Sat, 29 Oct 2011 09:16:37 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0117_01CC961B.770D1050" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ0vMEBidECkyqPvwz7nVhU5PWG15RDL+mw Content-Language: en-us X-OriginalArrivalTime: 29 Oct 2011 16:18:10.0296 (UTC) FILETIME=[59AFF780:01CC9656] Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs 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: Sat, 29 Oct 2011 16:18:13 -0000 ------=_NextPart_000_0117_01CC961B.770D1050 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit +1 I agree DNSSEC cannot be assumed, its deployments have been marginal. I also agree with the need of an ad-hoc peer-to-peer VPN bypassing gateways. While there are implementations from multiple vendors, including the one I work for, there is no standardized/scalable solution for the problems associated with these scenarios. Key challenges are: - Discoverability of suitable peers - Discovery of the set of crypto contracts required if allowed I won't be able to attend the IETF meeting in Taiwan, however once the date and time is settled I'll coordinate with someone representing my company to attend the BOF meeting. Thanks Jorge Coronel From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Geoffrey Huang Sent: Wednesday, October 26, 2011 1:19 PM To: ipsec@ietf.org Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem I have to agree with the recent comments about the inapplicability of RFC 4322. I don't think that a DNNSEC infrastructure can be assumed, particularly not in the deployments I have seen. I agree with Steve Hanna's comments about the need for ad-hoc peer-to-peer VPNs, bypassing a centralized hub. I also agree with Paul Hoffman's comments about using an already-existing "trusted introducer." Finally, I will be in Taiwan, but specifically (only) to discuss this topic. I'm hoping that the date of Wednesday, November 16 is still good for the bar BOF that some of us had previously discussed. -geoff ------=_NextPart_000_0117_01CC961B.770D1050 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

I agree DNSSEC cannot be = assumed, its deployments have been marginal.

I also agree with the = need of an ad-hoc peer-to-peer VPN bypassing gateways. While there are = implementations from multiple vendors, including the one I work for, = there is no standardized/scalable solution for  the problems = associated with these scenarios. Key challenges = are:

-          = Discoverability of  suitable peers =

-          = Discovery = of the set of crypto contracts required if allowed =

 

I won’t be able to = attend the IETF meeting in Taiwan, however once the date and time is = settled I’ll coordinate with someone representing my company to = attend the BOF meeting.

 

Thanks

Jorge = Coronel

 

From:= = ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Geoffrey Huang
Sent: Wednesday, October 26, 2011 1:19 = PM
To: ipsec@ietf.org
Subject: Re: [IPsec] New -00 = draft: Creating Large Scale Mesh VPNs = Problem

 

I have to = agree with the recent comments about the inapplicability of RFC = 4322.  I don’t think that a DNNSEC infrastructure can be = assumed, particularly not in the deployments I have = seen.

 

I agree with Steve Hanna’s comments about the = need for ad-hoc peer-to-peer VPNs, bypassing a centralized hub.  I = also agree with Paul Hoffman’s comments about using an = already-existing “trusted introducer.”

 

Finally, I = will be in Taiwan, but specifically (only) to discuss this topic.  = I’m hoping that the date of Wednesday, November 16 is still good = for the bar BOF that some of us had previously = discussed.

 

-geoff

------=_NextPart_000_0117_01CC961B.770D1050-- From ynir@checkpoint.com Sat Oct 29 13:35:15 2011 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 78AB221F8512 for ; Sat, 29 Oct 2011 13:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.537 X-Spam-Level: X-Spam-Status: No, score=-10.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBFOOSR1Na3P for ; Sat, 29 Oct 2011 13:35:15 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 671FD21F84D5 for ; Sat, 29 Oct 2011 13:35:14 -0700 (PDT) X-CheckPoint: {4EAC6323-10007-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p9TKZAax021003; Sat, 29 Oct 2011 22:35:11 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sat, 29 Oct 2011 22:35:00 +0200 From: Yoav Nir To: Jorge Coronel , "'Geoffrey Huang'" , "ipsec@ietf.org" Date: Sat, 29 Oct 2011 22:34:58 +0200 Thread-Topic: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Thread-Index: AcyWejqbJEKJjzOeRcSuLdbUsjvs/A== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs 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: Sat, 29 Oct 2011 20:35:15 -0000 OK. So DNSSEC is off the table. At least for now. At least with Chris's scenario, we can assume that there's an "administrative domain" that includes a "hub" and some "spokes". This "hub" has information about the addresses protected by each of the "spokes", so it makes sense that it will do the "introductions". (BTW: all the terms in quotes will need a proper definition in the draft). Alternatively, the "introductions" can be done by yet another node that's dedicated to these introductions. So the administrator of this administrative domain may not need to configure a lot of tunnels, but he or she still needs to configure all of the encryption domain of all the spokes on the introduces, but at least that's only one place. What is a "crypto contract"? Also, my company calls the addresses protected by a particular IPsec node an "encryption domain". Can we use this term, or is it too vendor-specific? Yoav On 10/29/11 6:16 PM, "Jorge Coronel" wrote: >+1=20 >I agree DNSSEC cannot be assumed, its deployments have been marginal. >I also agree with the need of an ad-hoc peer-to-peer VPN bypassing >gateways. While there are implementations from multiple vendors, >including the one I work for, there is no standardized/scalable solution >for the problems associated with these scenarios. Key challenges are: >- Discoverability of suitable peers >- Discovery of the set of crypto contracts required if allowed >=20 >I won=B9t be able to attend the IETF meeting in Taiwan, however once the >date and time is settled I=B9ll coordinate with someone representing my >company to attend the BOF meeting. >=20 >Thanks >Jorge Coronel >=20 From paul.hoffman@vpnc.org Sat Oct 29 18:25:03 2011 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 105E81F0C38 for ; Sat, 29 Oct 2011 18:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLlHQ7L51ulZ for ; Sat, 29 Oct 2011 18:25:02 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA431F0C34 for ; Sat, 29 Oct 2011 18:25:02 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p9U1OpEA038303 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 29 Oct 2011 18:24:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: Date: Sat, 29 Oct 2011 18:24:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Yoav Nir X-Mailer: Apple Mail (2.1251.1) Cc: IPsecme WG Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs 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: Sun, 30 Oct 2011 01:25:03 -0000 On Oct 29, 2011, at 1:34 PM, Yoav Nir wrote: > So the administrator of this administrative domain may not need to > configure a lot of tunnels, but he or she still needs to configure all = of > the encryption domain of all the spokes on the introduces, but at = least > that's only one place. >=20 > What is a "crypto contract"? I think a better term is "tunnel crypto policy". It's not a contract at = all: the "contract" part comes when SpokeA and SpokeB complete the = handshake. > Also, my company calls the addresses protected by a particular IPsec = node > an "encryption domain". Can we use this term, or is it too = vendor-specific? Regardless if that is vendor specific, it is not accurate. Part of the = tunnel crypto policy is the authentication policy, which has nothing to = do with encryption. Further, part of the tunnel crypto policy is the = addresses that will be in the tunnel. I assume if SpokeA says to HubX "I = want to open a tunnel to 5.6.7.0/24", and the only address policy that = SpokeA has that matches that is for 5.0.0.0/8 with the gateway at = 5.1.2.3, that HubX would respond with that as a possibility that SpokeA = might like. So there are two types of policy: tunnel (address), and = crypto (authentication and eventual encryption). At least, that was my picture of the requirements. --Paul Hoffman From mcr@sandelman.ca Mon Oct 31 06:29:48 2011 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 2E25321F8C7F for ; Mon, 31 Oct 2011 06:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGmTMufsBE5M for ; Mon, 31 Oct 2011 06:29:47 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id B729121F8C74 for ; Mon, 31 Oct 2011 06:29:47 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 3D5F5A0067 for ; Mon, 31 Oct 2011 09:28:25 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 6E12898C90; Mon, 31 Oct 2011 09:30:18 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 6808298B2E for ; Mon, 31 Oct 2011 09:30:18 -0400 (EDT) From: Michael Richardson To: ipsec@ietf.org In-Reply-To: References: <84600D05C20FF943918238042D7670FD41BF14E8A3@EMBX01-HQ.jnpr.net> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Mon, 31 Oct 2011 09:30:18 -0400 Message-ID: <10257.1320067818@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 13:29:48 -0000 >>>>> "Jorge" == Jorge Coronel writes: Jorge> +1 Jorge> I agree DNSSEC cannot be assumed, its deployments have been Jorge> marginal. DNSSEC is *one* *public* trusted third party. It's not the only way to use DNS securely, it's just the easiest one to arrange between total strangers. You don't need DNSSEC deployed universally to use DNS securely. Jorge> I also agree with the need of an ad-hoc peer-to-peer VPN Jorge> bypassing gateways. While there are implementations from Jorge> multiple vendors, including the one I work for, there is no Jorge> standardized/scalable solution for the problems associated Jorge> with these scenarios. Key challenges are: Jorge> - Discoverability of suitable peers Jorge> - Discovery of the set of crypto contracts required if Jorge> allowed ==== Jorge> I won't be able to attend the IETF meeting in Taiwan, however Jorge> once the date and time is settled I'll coordinate with Jorge> someone representing my company to attend the BOF meeting. +1 From paul@xelerance.com Mon Oct 31 08:52:42 2011 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 B2DB611E80A5 for ; Mon, 31 Oct 2011 08:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKWA6by3Mupr for ; Mon, 31 Oct 2011 08:52:41 -0700 (PDT) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id 6063F11E80B9 for ; Mon, 31 Oct 2011 08:52:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id C87A774D for ; Mon, 31 Oct 2011 11:52:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-type:content-type:mime-version:user-agent:message-id :subject:subject:from:from:date:date:received:received:received :received; s=smtp; t=1320076358; x=1320681158; bh=5IQqsUkVJU2aS9 1XoOKs55efhU14Pfa52ulckTV6274=; b=Xi++RveZWk/P0GxGYkuehA1ofB9bc+ EYorwjg9niVZ0+VNgh1J2bDsjtzWzZFICpjFaiiT9KCZyuP4+FnIxgMmP8dTynk2 cGXgw4jIt7NG47Fa3Db2oEFB/zBhHxPNTN4PxHT25tX2rXzzBLvFAe8dIbuFadyQ ohpswb+8FGAhE= Received: from mx.xelerance.com ([127.0.0.1]) by localhost (mx.xelerance.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id Ukibh4LVjA0q for ; Mon, 31 Oct 2011 11:52:38 -0400 (EDT) Received: from mail.xelerance.com (mail.xelerance.com [193.110.157.189]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.xelerance.com (Postfix) with ESMTPS id 2F66E25A for ; Mon, 31 Oct 2011 11:52:38 -0400 (EDT) Received: by mail.xelerance.com (Postfix, from userid 1001) id 11FA088B; Mon, 31 Oct 2011 11:52:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id 10DC4598 for ; Mon, 31 Oct 2011 11:52:38 -0400 (EDT) Date: Mon, 31 Oct 2011 11:52:38 -0400 (EDT) From: Paul Wouters To: ipsec@ietf.org Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [IPsec] IKEv1 delete/notify response question 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, 31 Oct 2011 15:52:42 -0000 Hi, I'm looking at a bug report where openswan sends a Delete/Notify in response to a Delete/Notify message. I vaguely remember things got cleared up on this for IKEv2, but I cannot find in 2401/2406/etc what the proper response is. If the peer send us a Notify/Delete, they no longer can receive our Notify/Delete. However, without receiving it, they cannot tell we actually deleted the SA. Should we keep sending Delete/Notify's to Delete messages - even though the majority of those cannot be read by the other peer? If there is no clear RFC guideance, what do other implementations do in this case? Thanks, Paul From ynir@checkpoint.com Mon Oct 31 15:02:35 2011 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 54F2311E8290 for ; Mon, 31 Oct 2011 15:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.542 X-Spam-Level: X-Spam-Status: No, score=-10.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeCcKDa36wrv for ; Mon, 31 Oct 2011 15:02:34 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB4811E8273 for ; Mon, 31 Oct 2011 15:02:34 -0700 (PDT) X-CheckPoint: {4EAF1A98-10002-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p9VM2TmF027389; Tue, 1 Nov 2011 00:02:29 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 1 Nov 2011 00:02:29 +0200 From: Yoav Nir To: Michael Richardson , "ipsec@ietf.org" Date: Tue, 1 Nov 2011 00:02:25 +0200 Thread-Topic: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Thread-Index: AcyYGMcsWGgt7z/oRVW0ZrY5AFU5tQ== Message-ID: In-Reply-To: <10257.1320067818@marajade.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 22:02:35 -0000 On 10/31/11 3:30 PM, "Michael Richardson" wrote: > >>>>>> "Jorge" =3D=3D Jorge Coronel writes: > Jorge> +1 > > Jorge> I agree DNSSEC cannot be assumed, its deployments have been > Jorge> marginal. > >DNSSEC is *one* *public* trusted third party. It's not the only way to >use DNS securely, it's just the easiest one to arrange between total >strangers.=20 Yup, expect that the problem we're trying to solve here is not that of total strangers. > From ghuang@juniper.net Mon Oct 31 17:57:50 2011 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 C29CB1F0DC6 for ; Mon, 31 Oct 2011 17:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3cmmQqPeYHv for ; Mon, 31 Oct 2011 17:57:49 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 11DE61F0DBC for ; Mon, 31 Oct 2011 17:57:36 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP; Mon, 31 Oct 2011 17:57:36 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 31 Oct 2011 17:56:16 -0700 From: Geoffrey Huang To: Stephen Hanna , Yoav Nir Date: Mon, 31 Oct 2011 17:56:14 -0700 Thread-Topic: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Thread-Index: AcyVeedTAgoijwbeQ7O9PAVuhxKapgARBv4gAJy+KQA= Message-ID: <84600D05C20FF943918238042D7670FD41BF460EE0@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD41BF14E8A3@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_84600D05C20FF943918238042D7670FD41BF460EE0EMBX01HQjnprn_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs 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, 01 Nov 2011 00:57:50 -0000 --_000_84600D05C20FF943918238042D7670FD41BF460EE0EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Put differently, it better be Wednesday night, since I can't be in Taipei a= ny earlier ;-). -geoff From: Stephen Hanna Sent: Friday, October 28, 2011 3:09 PM To: Yoav Nir; Geoffrey Huang Cc: ipsec@ietf.org Subject: RE: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem I agree. Wednesday night would be best. Who else is interested in getting together to discuss this? Clearly, there = are plenty of interesting issues to discuss. Steve From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= oav Nir Sent: Friday, October 28, 2011 10:00 AM To: Geoffrey Huang; Stephen Hanna Cc: ipsec@ietf.org Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Well, there is a free room between 1300-1500 on Wednesday, but then we're o= pposite WebSec, and I can't attend. Our best bet is to do it after the Plenary. The plenary ends at 19:30, and = people might want to grab something to eat, so it would probably be best to= do it at 20:00. Hope you don't have a flight for Wednesday night... On 10/26/11 10:19 PM, "Geoffrey Huang" > wrote: I have to agree with the recent comments about the inapplicability of RFC 4= 322. I don't think that a DNNSEC infrastructure can be assumed, particular= ly not in the deployments I have seen. I agree with Steve Hanna's comments about the need for ad-hoc peer-to-peer = VPNs, bypassing a centralized hub. I also agree with Paul Hoffman's commen= ts about using an already-existing "trusted introducer." Finally, I will be in Taiwan, but specifically (only) to discuss this topic= . I'm hoping that the date of Wednesday, November 16 is still good for the= bar BOF that some of us had previously discussed. -geoff --_000_84600D05C20FF943918238042D7670FD41BF460EE0EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Put differently, it better be Wednesday night, since I can= 217;t be in Taipei any earlier ;-).

 

-geoff

 

From: Stephen Hanna
Sent: Friday, O= ctober 28, 2011 3:09 PM
To: Yoav Nir; Geoffrey Huang
Cc: ipsec@ietf.org
Subject: RE: [IPsec] New -00 draft: Creating Lar= ge Scale Mesh VPNs Problem

 

I agree. Wednesday night would be best.

 

Who else is interested in getti= ng together to discuss this? Clearly, there are plenty of interesting issue= s to discuss.

 

Steve

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir
Sent: Friday, October 28, 2011 10:00 A= M
To: Geoffrey Huang; Stephen Hanna
Cc: ipsec@ietf.org<= br>Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPN= s Problem

 =

Well, there is a free room between 1300-1500 on Wednesday, but then w= e're opposite WebSec, and I can't attend.

<= p class=3DMsoNormal> = ;

Our best bet is to do it after the Plenary. The plenary= ends at 19:30, and people might want to grab something to eat, so it would= probably be best to do it at 20:00. 

=

&nbs= p;

Hope you don't have a flight for Wednesday night…= ;

 

On 10/26/11 10:= 19 PM, "Geoffrey Huang" <ghuang@juniper.net> wrote:

 =

I have to a= gree with the recent comments about the inapplicability of RFC 4322.  = I don’t think that a DNNSEC infrastructure can be assumed, particular= ly not in the deployments I have seen.

 

I agree with Steve Hanna’s commen= ts about the need for ad-hoc peer-to-peer VPNs, bypassing a centralized hub= .  I also agree with Paul Hoffman’s comments about using an alre= ady-existing “trusted introducer.”

 

Finally, I will be in Taiwan, b= ut specifically (only) to discuss this topic.  I’m hoping that t= he date of Wednesday, November 16 is still good for the bar BOF that some o= f us had previously discussed.

 

= -geoff

= --_000_84600D05C20FF943918238042D7670FD41BF460EE0EMBX01HQjnprn_-- From mcr@sandelman.ca Mon Oct 31 20:09:00 2011 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 9D46721F8F20 for ; Mon, 31 Oct 2011 20:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.525 X-Spam-Level: X-Spam-Status: No, score=-1.525 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RqM5EFr0xXx for ; Mon, 31 Oct 2011 20:09:00 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3A42E21F8B20 for ; Mon, 31 Oct 2011 20:08:59 -0700 (PDT) Received: from marajade.sandelman.ca (wlan203.sandelman.ca [209.87.252.203]) by relay.sandelman.ca (Postfix) with ESMTPS id 4EA73A0068 for ; Mon, 31 Oct 2011 23:07:41 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id D53C59817F; Mon, 31 Oct 2011 23:09:55 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id C368B980DB for ; Mon, 31 Oct 2011 23:09:55 -0400 (EDT) From: Michael Richardson To: "ipsec@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 31 Oct 2011 23:09:55 -0400 Message-ID: <28621.1320116995@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs 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, 01 Nov 2011 03:09:00 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Yoav" =3D=3D Yoav Nir writes: Jorge> I agree DNSSEC cannot be assumed, its deployments have been Jorge> marginal. >> DNSSEC is *one* *public* trusted third party. It's not the only >> way to use DNS securely, it's just the easiest one to arrange >> between total strangers. Yoav> Yup, expect that the problem we're trying to solve here is not Yoav> that of total strangers. If the entities are in fact a group who has an internal trust anchor: a) if they want to use DNSSEC, it only matters they have DNSSEC deployed for the part of the reverse zone they use, and that they have a trusted anchor into that. b) a really simple way to get secure DNS data is to make every (gateway) machine a secondary for the zones in question.=20 c) a second way is to simply point the /etc/resolv.conf and/or the DNS-forwarders to some *set* of internal servers, ideally authenticated with TSIG... OR, even do it over the single spoke to hub IPsec tunnel. Finally, if we are talking IPv4, then the internal IPs are likely RFC1918, and so one can't use the public DNS anyway, so you have to do either (b) or (c) ANYWAY. Again, this can all be done with existing protocols and existing software, which, on a Linux machine, you can do a yum install or apt-get install. =20 =20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATq9jAoCLcPvd0N1lAQJAqAf8CNkGihz4RFDLfN3EJp4Me8bQoIw3sOOV Kpd5rr52BEv6pp//pSkB2ekVHddcV/TCytPZ4hK1NaVUrIt5wxvTwdL50zQvEowq PZFQO/PXZeZ8xDL5AWxZKi/XaS2tdRZBSeoczZB8QOUEV8FuVOgGwBxPE2wxUSgX OygQnhnmAkv7BrLReyLjJbnIOSGpaALvsnZrYhEgAI5m42ggOw2GgBGFGpOapMy6 PV0etebnicv6Bksrj6OPrv///tg2G6OZzC30WJRoRJfwWqIvr4+qdAuPkBwb37Yt zCJdbvWLA0gJQl3QILAiUSHheXVGEe+TckeE24guUOKI888UANMx9A== =CJiB -----END PGP SIGNATURE----- --=-=-=--