From tcpm-bounces@ietf.org Tue Jul 1 09:49:52 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C07563A691C; Tue, 1 Jul 2008 09:49:52 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3DB63A691C for ; Tue, 1 Jul 2008 09:49:50 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxUr90tkn7aE for ; Tue, 1 Jul 2008 09:49:48 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id B447C3A67D9 for ; Tue, 1 Jul 2008 09:49:48 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1731642rvf.49 for ; Tue, 01 Jul 2008 09:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=ZIET0oRo58VShxnE+Up2GsCxuaFolux3fkGi7cL/UIM=; b=o51zwRVDbBzukusYNcAFuVHji/3XiBzMe2MtgEL0iUY40OoqHguvBOjRkSE1j7ySWL N4quigwtaO6JoL4HXWr+e0rwlRjzuhKwONG3ROJ8A2Mx1x/SweGrEAHioNlpIU5SY2jr WRSdQx7O2/qYqA2mVa8xk1IWJKM7imy97Ykbk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=umEsKKy/5yzlIrdghA5VPTVOrFL3+2Z6IbJfrTsqQ4BM4S8QCQKrkVpZJeSLmF6rQC SkPiIx8vH35IhTYulT3hjrZVYGS8LGPM3QX0UeysFJTjFWJf+ul0H7N0gqAMtN/OUL4S tvaZ7XKMH9rUV5iL93Io3dtyTMZLg2llmpCsg= Received: by 10.141.23.7 with SMTP id a7mr3740974rvj.58.1214930997205; Tue, 01 Jul 2008 09:49:57 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Tue, 1 Jul 2008 09:49:57 -0700 (PDT) Message-ID: <396556a20807010949i6c6c1d16g41c74e2f78414a92@mail.gmail.com> Date: Tue, 1 Jul 2008 09:49:57 -0700 From: "Adam Langley" To: tcpm@ietf.org MIME-Version: 1.0 Content-Disposition: inline X-Google-Sender-Auth: 3ca456172c01e9d2 Subject: [tcpm] TCP Long Options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org SSd2ZSByZXZpdmVkIGFuIG9sZCBkcmFmdCwgd2l0aCB0aGUgb3JpZ2luYWwgYXV0aG9yJ3MgcGVy bWlzc2lvbjogVENQCkxvbmcgT3B0aW9uc1sxXQoKRm9yIGEgU1lOIHBhY2tldCB3aXRoIHdpbmRv dyBzY2FsZSwgTVNTLCBUUywgU0FDSyBwZXJtaXR0ZWQgYW5kIE1ENQpvcHRpb25zIChhbmQgdGhl IGFzc29jaWF0ZWQgd29yZCBhbGlnbm1lbnQgcGFkZGluZykgd2UgaGF2ZSBhbHJlYWR5CmZpbGxl ZCB0aGUgNDAgYnl0ZSBvcHRpb24gc3BhY2UuIE5vdCB0byBtZW50aW9uIHRoYXQgU0FDSyBwZXJt aXR0ZWQgaXMKYSB3YXN0ZSBpbiBzdWNoIGEgcGFja2V0IHNpbmNlIG5vIFNBQ0sgYmxvY2tzIGNh biBmaXQgaW4gdGhlIGZvbGxvd2luZwpmcmFtZXMuCgpUQ1AtQU8gd2lsbCBwcm9iYWJseSB0cnVu Y2F0ZSB0aGUgTUFDIGJ5IDQgYnl0ZXMgdG8gYWRkIHNwYWNlIGZvciBhCnNpbmdsZSBTQUNLIGJs b2NrLCBidXQgZXZlbiBwYWNrZXRzIHdpdGhvdXQgYXV0aGVudGljYXRpb24gb3B0aW9ucwpoYXZl IG9ubHkgMjAgYnl0ZXMgb2Ygb3B0aW9uIHNwYWNlIGxlZnQgaW4gYSB0eXBpY2FsIFNZTiBbMl0u IFRoaXMgaXMKaGFtcGVyaW5nIGV4cGVyaW1lbnRhdGlvbiwgZXNwIGluIHRoZSBjcnlwdG9ncmFw aGljIHNwYWNlIGJlY2F1c2UgeW91CmNhbid0IGZpdCBldmVuIGEgcmVhc29uYWJsZSBlbGxpcHRp YyBjdXJ2ZSBrZXkgaW4gdGhlIHJlbWFpbmluZwpzcGFjZVs0XS4gRXZlbiB3aXRoIHRoZSBjdXJy ZW50IGZlYXR1cmUgc2V0LCBleHRyYSBTQUNLIGJsb2NrcyBhcmUKa25vd24gdG8gYmUgaGVscGZ1 bCBpbiBjZXJ0YWluIHNpdHVhdGlvbnNbM10uCgpJIHN1Z2dlc3QgdG8gdGhlIHdvcmtpbmcgZ3Jv dXAgdGhhdCByZWFjaGluZyBjb25zZW5zdXMgb24gYSBsb25nCm9wdGlvbnMgc3RhbmRhcmQgd291 bGQgYmUgcG9zaXRpdmUgZm9yIFRDUC4KCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWVkZHktdGNwLWxvby0wNC50eHQKCkV4cGVyaW1lbnRhbCwgTGludXggaW1wbGVt ZW50YXRpb246CgpodHRwOi8vbWFyYy5pbmZvLz9sPWxpbnV4LW5ldGRldiZtPTEyMTQzNTU1NTYx OTU5MSZ3PTIKCkNoYW5nZXMgc2luY2UgMDMKCiAgIDEuICBDaGFuZ2UgdGhlIG9wdGlvbiBudW1i ZXJzIHNwZWNpZmllZCB0byBwbGFjZWhvbGRlcnM6CiAgICAgICAiVEJELUlBTkEtS0lORDEiIGFu ZCAiVEJELUlBTkEtS0lORDIiLgoKICAgMi4gIENoYW5nZSB0aGUgcmVxdWlyZW1lbnQgdGhhdCBh bGwgc2VnbWVudHMgaW5jbHVkZSB0aGUgTE8gb3B0aW9uLAogICAgICAgaWYgbmVnb3RpYXRlZCwg dG8gYSBTSE9VTEQgTk9UIHVubGVzcyB0aGUgb3B0aW9ucyByZXF1aXJlIGl0LgogICAgICAgVGhl IHJlYXNvbmluZyBiZWhpbmQgdGhlIGluaXRpYWwgcmVxdWlyZW1lbnQgd2FzIGZvcgogICAgICAg aW1wbGVtZW50YXRpb24gZWFzZSBidXQsIGhhdmluZyBpbXBsZW1lbnRlZCBpdCBteXNlbGYsIHRo ZQogICAgICAgYWJpbGl0eSB0byB1c2UgdGhlIGZhc3QgcGF0aCBwcm9jZXNzaW5nIGZvciBMTyBj b25uZWN0aW9ucwogICAgICAgb3V0d2VpZ2hzIHRoYXQuCgogICAzLiAgQ2hhbmdlIHRoZSB1bml0 cyBvZiB0aGUgTE8gb3B0aW9uIGZyb20gYnl0ZXMgdG8gd29yZHMuICBUaGlzIHdhcwogICAgICAg YW1iaWd1b3VzIGluIHRoZSAwMyBkcmFmdCBhbmQsIHNpbmNlIHBhZGRpbmcgdG8gZm91ciBieXRl cyB3YXMKICAgICAgIHJlcXVpcmVkIGFueXdheSwgaXQgc2VlbWVkIGJlc3QgdG8gcmVtb3ZlIG9u ZSBleHRyYSB3YXkgdGhhdCB0aGUKICAgICAgIG9wdGlvbiBjb3VsZCBiZSBpbnZhbGlkLgoKClsx XSBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1lZGR5LXRjcC1sb28t MDQudHh0ClsyXSBTWU4gb3B0aW9ucyB0YWtlIDIwIGJ5dGVzIGluIG1vZGVybiBMaW51eCBrZXJu ZWxzIHdpdGggZGVmYXVsdApzeXNjdGwgc2V0dGluZ3MKWzNdIGh0dHA6Ly9wb3J0YWwuYWNtLm9y Zy9jaXRhdGlvbi5jZm0/aWQ9MTI1OTU5MS4xMjYwMTAyJmNvbGw9R1VJREUmZGw9R1VJREUKWzRd IEFzc3VtaW5nIHRoaXMgaXQgaXNuJ3QgdG8gYmUgdGhlIGxhc3Qgb3B0aW9uIGV2ZXIsIHdlIGxl YXZlIDQKYnl0ZXMgb2Ygc3BhY2UuIFdpdGggdGhlIDIgYnl0ZSBvcHRpb24gaGVhZGVyLCB3ZSBo YXZlIDE0IGJ5dGVzLCBvcgoxMTIgYml0cyBmb3IgYSBrZXkuIFVzaW5nIFBvbGxhcmQncyBSaG8g YWxnb3JpdGhtIHdlIG5lZWQgMTQqMyA9IDQyCmJ5dGVzIHRvIHN0b3JlIGEgcG9pbnQuIEdyYW50 aW5nIHRoZSBhdHRhY2tlciBvbmx5IDEgUEIgb2Ygc3BhY2UKKGFwcHJveCBjb3N0IDwg4oKsMjAw SykgdGhleSBjYW4gc3RvcmUgMioqNDQgcG9pbnRzLCBzbyBvbmUgaW4gMioqMTIKcG9pbnRzIGFy ZSBkaXN0aW5ndWlzaGVkLiBTbyB0aGUgYXR0YWNrZXIgY2FuIGJyZWFrIHN1Y2ggYSBrZXkgYWxt b3N0Cmluc3RhbnRseTogMioqMTIgb3BlcmF0aW9ucyBvbiBhdmVyYWdlLgoKCkFHTAoKLS0gCkFk YW0gTGFuZ2xleSBhZ2xAaW1wZXJpYWx2aW9sZXQub3JnIGh0dHA6Ly93d3cuaW1wZXJpYWx2aW9s ZXQub3JnCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCnRj cG0gbWFpbGluZyBsaXN0CnRjcG1AaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90Y3BtCg== From tcpm-bounces@ietf.org Tue Jul 1 10:21:45 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBA373A69B9; Tue, 1 Jul 2008 10:21:45 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B139E3A6781 for ; Tue, 1 Jul 2008 10:21:44 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrL4qLXt8Vd6 for ; Tue, 1 Jul 2008 10:21:43 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 3FDAE3A6B7A for ; Tue, 1 Jul 2008 10:21:30 -0700 (PDT) Received: from [127.0.0.1] (pool-71-106-103-55.lsanca.dsl-w.verizon.net [71.106.103.55]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m61HKtrk003152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Jul 2008 10:20:57 -0700 (PDT) Message-ID: <486A6777.80809@isi.edu> Date: Tue, 01 Jul 2008 10:20:55 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Adam Langley References: <396556a20807010949i6c6c1d16g41c74e2f78414a92@mail.gmail.com> In-Reply-To: <396556a20807010949i6c6c1d16g41c74e2f78414a92@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP Long Options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1124342422==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1124342422== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8F992B94696ADA5FC273C3D8" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8F992B94696ADA5FC273C3D8 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable It might be worth reviewing the discussion on the TCP-LO when it was=20 previously presented, and provide a summary to the group as to whether=20 anything has changed. Joe Adam Langley wrote: > I've revived an old draft, with the original author's permission: TCP > Long Options[1] >=20 > For a SYN packet with window scale, MSS, TS, SACK permitted and MD5 > options (and the associated word alignment padding) we have already > filled the 40 byte option space. Not to mention that SACK permitted is > a waste in such a packet since no SACK blocks can fit in the following > frames. >=20 > TCP-AO will probably truncate the MAC by 4 bytes to add space for a > single SACK block, but even packets without authentication options > have only 20 bytes of option space left in a typical SYN [2]. This is > hampering experimentation, esp in the cryptographic space because you > can't fit even a reasonable elliptic curve key in the remaining > space[4]. Even with the current feature set, extra SACK blocks are > known to be helpful in certain situations[3]. >=20 > I suggest to the working group that reaching consensus on a long > options standard would be positive for TCP. >=20 > http://www.ietf.org/internet-drafts/draft-eddy-tcp-loo-04.txt >=20 > Experimental, Linux implementation: >=20 > http://marc.info/?l=3Dlinux-netdev&m=3D121435555619591&w=3D2 >=20 > Changes since 03 >=20 > 1. Change the option numbers specified to placeholders: > "TBD-IANA-KIND1" and "TBD-IANA-KIND2". >=20 > 2. Change the requirement that all segments include the LO option, > if negotiated, to a SHOULD NOT unless the options require it. > The reasoning behind the initial requirement was for > implementation ease but, having implemented it myself, the > ability to use the fast path processing for LO connections > outweighs that. >=20 > 3. Change the units of the LO option from bytes to words. This was= > ambiguous in the 03 draft and, since padding to four bytes was > required anyway, it seemed best to remove one extra way that the= > option could be invalid. >=20 >=20 > [1] http://www.ietf.org/internet-drafts/draft-eddy-tcp-loo-04.txt > [2] SYN options take 20 bytes in modern Linux kernels with default > sysctl settings > [3] http://portal.acm.org/citation.cfm?id=3D1259591.1260102&coll=3DGUID= E&dl=3DGUIDE > [4] Assuming this it isn't to be the last option ever, we leave 4 > bytes of space. With the 2 byte option header, we have 14 bytes, or > 112 bits for a key. Using Pollard's Rho algorithm we need 14*3 =3D 42 > bytes to store a point. Granting the attacker only 1 PB of space > (approx cost < =E2=82=AC200K) they can store 2**44 points, so one in 2*= *12 > points are distinguished. So the attacker can break such a key almost > instantly: 2**12 operations on average. >=20 >=20 > AGL >=20 --------------enig8F992B94696ADA5FC273C3D8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIamd3E5f5cImnZrsRAlSVAKCMDzmt9wxMgqAwjSZgpnLFKoe0SQCfQJUl OEJKbuw5/QaWHau9n+xQMVw= =JP5n -----END PGP SIGNATURE----- --------------enig8F992B94696ADA5FC273C3D8-- --===============1124342422== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1124342422==-- From tcpm-bounces@ietf.org Tue Jul 1 10:45:40 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 241E73A6B99; Tue, 1 Jul 2008 10:45:40 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B943B3A6B99 for ; Tue, 1 Jul 2008 10:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKc9OE5kzgdR for ; Tue, 1 Jul 2008 10:45:37 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id A57303A6784 for ; Tue, 1 Jul 2008 10:45:37 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1750502rvf.49 for ; Tue, 01 Jul 2008 10:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=9ro0LVpya/FkbX/L6WF+gPkXV4UMlXGZ/mP9HLIveJc=; b=HWXOg3glUfbc36Dq4PKH6CDI7lSIaTSu98ZkKegFlhEOe9c0sRVLuxQcoCbitxdXlF hS3AlXASZJ9jp0pSywNbCe56izkijBNC7mTaLy+wYGAkgMN7VHsAgj3px+SZhkP0LsM3 MrJ4x+VBPolFlaT5bikTMtk7ikd2EO+AmVhHA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=sZ+QqO8H9NReoMznRyDuPo7jQdrt8ZNrQKRwa9Cj6VdENApTfeHUDM1mm/MxCTBK9I /v4NuCDEZ3uYPGkg5E8setJ/tB6qGh9OxB2i8ILd2Xq9W8jCX6S4L00lTEMOAMJKoSxP aglQ0k59uWqrwaU5rupZQUJEHlXL623NsJzeA= Received: by 10.140.200.16 with SMTP id x16mr3777851rvf.120.1214934348351; Tue, 01 Jul 2008 10:45:48 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Tue, 1 Jul 2008 10:45:48 -0700 (PDT) Message-ID: <396556a20807011045n20656450w7da5955bab19fbd9@mail.gmail.com> Date: Tue, 1 Jul 2008 10:45:48 -0700 From: "Adam Langley" To: tcpm@ietf.org MIME-Version: 1.0 Content-Disposition: inline X-Google-Sender-Auth: 9c5a367d19511aec Subject: [tcpm] draft-ietf-tcpm-tcp-auth-opt-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > 2.2. TCP-AO Option [snip] > The MAC is computed over the following fields in the following order: Currently AO is suggesting the same serialisation as TCPMD5: sig = MAC(key, pseudoheader + header + data) I suggest, instead, that the default serialisation be: sig = MAC(key, H(data) + pseudoheader + header) When the TCP stack is getting data from userspace, it generally knows the MSS and splits the data into packets right away. With the suggested serialisation, the data can be hashed as it's copied and the hash stored with the data. This saves traversing the data again at transmit time to calculate the MD5 signature. The latter is no less secure, I believe, and opens up possibilities for optimisation so should be a clear gain. Note that MAC(key, H(data) + pseudoheader + header) is better than MAC(key, data + pseudoheader + header) because, with the latter, a partial block needs to be stored as well. With common hash functions (MD5, SHA-1) this is 64-bytes of extra data. Additionally, the draft already mentions an Option Kind Exclusion List and I'd suggest another option: that the pseudoheader be omitted and the source/destination ports in the TCP header be zeroed. This would allowed the signature to be robust to most (all?) NATs. The NAT workaround suggested in section 7 is impractical for many uses and a significant fraction of hosts are now imprisoned behind NATs. Currently unspecified is a nonce for the packets. Modern MAC functions, based on polynomials (such as [1]), can have the very pleasing property of being provably within a factor as secure as another function (like a block cipher). However, they often require nonces as inputs. A trivial solution would be to keep a 64-bit counter, increment it for each transmission and transmit it along with the signature. However, we'll struggle to fit that all in the options space; esp for SYN packets. Next we could consider taking the seq number as the lower 32-bits of a 64-bit counter. However, that doesn't guarantee that two different messages wouldn't be transmitted with the same nonce. We could just transmit the bottom (say) 16-bits of the nonce, but a prolonged outage could knock the endpoints out of sync. I don't have a good solution here. Also, is encryption of the payload considered out-of-scope for this spec? [1] http://cr.yp.to/mac.html -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 1 10:47:27 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC4313A6BB6; Tue, 1 Jul 2008 10:47:27 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D3393A6BB6 for ; Tue, 1 Jul 2008 10:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.159 X-Spam-Level: X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbohO+WwkWB9 for ; Tue, 1 Jul 2008 10:47:25 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0589C3A6784 for ; Tue, 1 Jul 2008 10:47:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,732,1204531200"; d="scan'208";a="47304452" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 01 Jul 2008 10:47:31 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m61HlVlG003823; Tue, 1 Jul 2008 10:47:31 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m61HlVhY010399; Tue, 1 Jul 2008 17:47:31 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Jul 2008 10:47:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Jul 2008 10:46:31 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58056ADDF2@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <396556a20807010949i6c6c1d16g41c74e2f78414a92@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCP Long Options Thread-Index: AcjbmoksLMF9/xvjTJa2AHeahYl44QABZLhQ References: <396556a20807010949i6c6c1d16g41c74e2f78414a92@mail.gmail.com> From: "Anantha Ramaiah (ananth)" To: "Adam Langley" , X-OriginalArrivalTime: 01 Jul 2008 17:47:30.0942 (UTC) FILETIME=[88FB61E0:01C8DBA2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4772; t=1214934451; x=1215798451; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[tcpm]=20TCP=20Long=20Options |Sender:=20; bh=K5toAta09D9FgWx3e0t+goH3oKXMbmYwPTc8r3uOQls=; b=eJ8jiGueobPS6FqhWt9RNHYU/5bJe46XqWWBxn0T600cdERHXJ8TwM25zL JIXajZOQ15qe9MlPLn7Q9fXvgq0b1/ONgtJTZg29gU7UtasY8EwallXJ20og egzxOLtr0O; Authentication-Results: sj-dkim-2; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [tcpm] TCP Long Options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org SXQgaXMgZ29vZCBjYWxsIHRvIHJldml2ZSB0aGlzIGRyYWZ0LiBOZWVkbGVzcyB0byBtZW50aW9u LCB0aGUgVENQIG9wdGlvbiBzcGFjZSBpcyBleGhhdXN0ZWQgYW5kIHNvbWV0aGluZyBuZWVkcyB0 byBiZSBkb25lIHRvIGZpeCBpdC4gV2hlbiB0aGUgZGlzY3Vzc2lvbnMgbGFzdCBjYW1lIHVwLCBJ IHZvdGVkIGluIGZhdm9yIG9mIHRha2luZyB0aGlzIGl0ZW0gdXAsIGFuZCBteSB2aWV3cG9pbnQg cmVtYWlucyB0aGUgc2FtZSA6LSkNCg0KSSB3aWxsIGdpdmUgdGhpcyBuZXcgdmVyc2lvbiwgYSBy ZWFkIGxhdGVyLg0KDQpUaGFua3MsDQotQW5hbnRoYQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IHRjcG0tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOml0Y3BtLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIA0KPiBCZWhhbGYgT2YgQWRhbSBMYW5nbGV5DQo+IFNlbnQ6IFR1ZXNk YXksIEp1bHkgMDEsIDIwMDggOTo1MCBBTQ0KPiBUbzogdGNwbUBpZXRmLm9yZw0KPiBTdWJqZWN0 OiBbdGNwbV0gVENQIExvbmcgT3B0aW9ucw0KPiANCj4gSSd2ZSByZXZpdmVkIGFuIG9sZCBkcmFm dCwgd2l0aCB0aGUgb3JpZ2luYWwgYXV0aG9yJ3MgDQo+IHBlcm1pc3Npb246IFRDUCBMb25nIE9w dGlvbnNbMV0NCj4gDQo+IEZvciBhIFNZTiBwYWNrZXQgd2l0aCB3aW5kb3cgc2NhbGUsIE1TUywg VFMsIFNBQ0sgcGVybWl0dGVkIA0KPiBhbmQgTUQ1IG9wdGlvbnMgKGFuZCB0aGUgYXNzb2NpYXRl ZCB3b3JkIGFsaWdubWVudCBwYWRkaW5nKSANCj4gd2UgaGF2ZSBhbHJlYWR5IGZpbGxlZCB0aGUg NDAgYnl0ZSBvcHRpb24gc3BhY2UuIE5vdCB0byANCj4gbWVudGlvbiB0aGF0IFNBQ0sgcGVybWl0 dGVkIGlzIGEgd2FzdGUgaW4gc3VjaCBhIHBhY2tldCBzaW5jZSANCj4gbm8gU0FDSyBibG9ja3Mg Y2FuIGZpdCBpbiB0aGUgZm9sbG93aW5nIGZyYW1lcy4NCj4gDQo+IFRDUC1BTyB3aWxsIHByb2Jh Ymx5IHRydW5jYXRlIHRoZSBNQUMgYnkgNCBieXRlcyB0byBhZGQgc3BhY2UgDQo+IGZvciBhIHNp bmdsZSBTQUNLIGJsb2NrLCBidXQgZXZlbiBwYWNrZXRzIHdpdGhvdXQgDQo+IGF1dGhlbnRpY2F0 aW9uIG9wdGlvbnMgaGF2ZSBvbmx5IDIwIGJ5dGVzIG9mIG9wdGlvbiBzcGFjZSANCj4gbGVmdCBp biBhIHR5cGljYWwgU1lOIFsyXS4gVGhpcyBpcyBoYW1wZXJpbmcgZXhwZXJpbWVudGF0aW9uLCAN Cj4gZXNwIGluIHRoZSBjcnlwdG9ncmFwaGljIHNwYWNlIGJlY2F1c2UgeW91IGNhbid0IGZpdCBl dmVuIGEgDQo+IHJlYXNvbmFibGUgZWxsaXB0aWMgY3VydmUga2V5IGluIHRoZSByZW1haW5pbmcg c3BhY2VbNF0uIEV2ZW4gDQo+IHdpdGggdGhlIGN1cnJlbnQgZmVhdHVyZSBzZXQsIGV4dHJhIFNB Q0sgYmxvY2tzIGFyZSBrbm93biB0byANCj4gYmUgaGVscGZ1bCBpbiBjZXJ0YWluIHNpdHVhdGlv bnNbM10uDQo+IA0KPiBJIHN1Z2dlc3QgdG8gdGhlIHdvcmtpbmcgZ3JvdXAgdGhhdCByZWFjaGlu ZyBjb25zZW5zdXMgb24gYSANCj4gbG9uZyBvcHRpb25zIHN0YW5kYXJkIHdvdWxkIGJlIHBvc2l0 aXZlIGZvciBUQ1AuDQo+IA0KPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1lZGR5LXRjcC1sb28tMDQudHh0DQo+IA0KPiBFeHBlcmltZW50YWwsIExpbnV4IGltcGxl bWVudGF0aW9uOg0KPiANCj4gaHR0cDovL21hcmMuaW5mby8/bD1saW51eC1uZXRkZXYmbT0xMjE0 MzU1NTU2MTk1OTEmdz0yDQo+IA0KPiBDaGFuZ2VzIHNpbmNlIDAzDQo+IA0KPiAgICAxLiAgQ2hh bmdlIHRoZSBvcHRpb24gbnVtYmVycyBzcGVjaWZpZWQgdG8gcGxhY2Vob2xkZXJzOg0KPiAgICAg ICAgIlRCRC1JQU5BLUtJTkQxIiBhbmQgIlRCRC1JQU5BLUtJTkQyIi4NCj4gDQo+ICAgIDIuICBD aGFuZ2UgdGhlIHJlcXVpcmVtZW50IHRoYXQgYWxsIHNlZ21lbnRzIGluY2x1ZGUgdGhlIExPIG9w dGlvbiwNCj4gICAgICAgIGlmIG5lZ290aWF0ZWQsIHRvIGEgU0hPVUxEIE5PVCB1bmxlc3MgdGhl IG9wdGlvbnMgcmVxdWlyZSBpdC4NCj4gICAgICAgIFRoZSByZWFzb25pbmcgYmVoaW5kIHRoZSBp bml0aWFsIHJlcXVpcmVtZW50IHdhcyBmb3INCj4gICAgICAgIGltcGxlbWVudGF0aW9uIGVhc2Ug YnV0LCBoYXZpbmcgaW1wbGVtZW50ZWQgaXQgbXlzZWxmLCB0aGUNCj4gICAgICAgIGFiaWxpdHkg dG8gdXNlIHRoZSBmYXN0IHBhdGggcHJvY2Vzc2luZyBmb3IgTE8gY29ubmVjdGlvbnMNCj4gICAg ICAgIG91dHdlaWdocyB0aGF0Lg0KPiANCj4gICAgMy4gIENoYW5nZSB0aGUgdW5pdHMgb2YgdGhl IExPIG9wdGlvbiBmcm9tIGJ5dGVzIHRvIHdvcmRzLiANCj4gIFRoaXMgd2FzDQo+ICAgICAgICBh bWJpZ3VvdXMgaW4gdGhlIDAzIGRyYWZ0IGFuZCwgc2luY2UgcGFkZGluZyB0byBmb3VyIGJ5dGVz IHdhcw0KPiAgICAgICAgcmVxdWlyZWQgYW55d2F5LCBpdCBzZWVtZWQgYmVzdCB0byByZW1vdmUg b25lIGV4dHJhIA0KPiB3YXkgdGhhdCB0aGUNCj4gICAgICAgIG9wdGlvbiBjb3VsZCBiZSBpbnZh bGlkLg0KPiANCj4gDQo+IFsxXSBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1lZGR5LXRjcC1sb28tMDQudHh0DQo+IFsyXSBTWU4gb3B0aW9ucyB0YWtlIDIwIGJ5dGVz IGluIG1vZGVybiBMaW51eCBrZXJuZWxzIHdpdGggDQo+IGRlZmF1bHQgc3lzY3RsIHNldHRpbmdz IFszXSANCj4gaHR0cDovL3BvcnRhbC5hY20ub3JnL2NpdGF0aW9uLmNmbT9pZD0xMjU5NTkxLjEy NjAxMDImY29sbD1HVUkNCj4gREUmZGw9R1VJREUNCj4gWzRdIEFzc3VtaW5nIHRoaXMgaXQgaXNu J3QgdG8gYmUgdGhlIGxhc3Qgb3B0aW9uIGV2ZXIsIHdlIA0KPiBsZWF2ZSA0IGJ5dGVzIG9mIHNw YWNlLiBXaXRoIHRoZSAyIGJ5dGUgb3B0aW9uIGhlYWRlciwgd2UgDQo+IGhhdmUgMTQgYnl0ZXMs IG9yDQo+IDExMiBiaXRzIGZvciBhIGtleS4gVXNpbmcgUG9sbGFyZCdzIFJobyBhbGdvcml0aG0g d2UgbmVlZCANCj4gMTQqMyA9IDQyIGJ5dGVzIHRvIHN0b3JlIGEgcG9pbnQuIEdyYW50aW5nIHRo ZSBhdHRhY2tlciBvbmx5IA0KPiAxIFBCIG9mIHNwYWNlIChhcHByb3ggY29zdCA8IOKCrDIwMEsp IHRoZXkgY2FuIHN0b3JlIDIqKjQ0IA0KPiBwb2ludHMsIHNvIG9uZSBpbiAyKioxMiBwb2ludHMg YXJlIGRpc3Rpbmd1aXNoZWQuIFNvIHRoZSANCj4gYXR0YWNrZXIgY2FuIGJyZWFrIHN1Y2ggYSBr ZXkgYWxtb3N0DQo+IGluc3RhbnRseTogMioqMTIgb3BlcmF0aW9ucyBvbiBhdmVyYWdlLg0KPiAN Cj4gDQo+IEFHTA0KPiANCj4gLS0NCj4gQWRhbSBMYW5nbGV5IGFnbEBpbXBlcmlhbHZpb2xldC5v cmcgDQo+IGh0dHA6Ly93d3cuaW1wZXJpYWx2aW9sZXQub3JnIA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB0Y3BtIG1haWxpbmcgbGlzdA0KPiB0 Y3BtQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNw bQ0KPiANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCnRj cG0gbWFpbGluZyBsaXN0CnRjcG1AaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90Y3BtCg== From tcpm-bounces@ietf.org Tue Jul 1 11:27:56 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15BE93A6876; Tue, 1 Jul 2008 11:27:56 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 932A13A686C for ; Tue, 1 Jul 2008 11:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntoHHUl5QmAN for ; Tue, 1 Jul 2008 11:27:53 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id 989E63A6876 for ; Tue, 1 Jul 2008 11:27:53 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so6849rvf.49 for ; Tue, 01 Jul 2008 11:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=w5Qjn2r4+WA33GiM2KNJkcW5c1I1zObK0Vr5YVde8bM=; b=nFLCCXy51jUXBgnT6LCe4UY4ssyi+uNuWQkp0V52rML1PEoHhpU+71/exNQchqqyF9 bS3RTWEbfg/F0tRybys4stPPFm/zC1MSdkPGNXBHbV6AVY9pAZk4oQpkz7o86WLQhRx8 njgwt/6513csi6hH3dJ5WMRSno/88gfxjmI8o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=lPX7J/feMT3FAn4alpAr0fD6LT/4jFvyn68L7uMu86WaKHpQczI8L8YQ28N2bIVOHq /l5MV0NWVzZURhnxZqurDkyBvHc2SZKO+QTOsYOMUBmCEO8pftiJE8auKy8PtGizHMZS LgxuZZ3f8QjgZiUQUBVB10Lh27Aohx3OYife4= Received: by 10.141.75.17 with SMTP id c17mr3801224rvl.212.1214936884322; Tue, 01 Jul 2008 11:28:04 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Tue, 1 Jul 2008 11:28:04 -0700 (PDT) Message-ID: <396556a20807011128v27796016k81204b84e78fc25a@mail.gmail.com> Date: Tue, 1 Jul 2008 11:28:04 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <486A6777.80809@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20807010949i6c6c1d16g41c74e2f78414a92@mail.gmail.com> <486A6777.80809@isi.edu> X-Google-Sender-Auth: 3729f51fcf5730fa Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP Long Options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Tue, Jul 1, 2008 at 10:20 AM, Joe Touch wrote: > It might be worth reviewing the discussion on the TCP-LO when it was > previously presented, and provide a summary to the group as to whether > anything has changed. Good point, although I am probably omitting salient points which I missed when reviewing the archives: 1. It's a "non-optional option" / it's another 4 bytes of bloat Referring to the requirement that the LO option be included in every packet. This requirement has been removed for implementation reasons (it's very good to have a single fast path), but that also addresses this. (However, the LO option is still required to be the first option, if present and DO is required to be set to 6 in this case. I reasoned that it was still best to remove extra degrees of freedom about where to put it / how to set DO) 2. Some options can't be included in SLO This is still correct. There's no good way to negotiate some options, like MSS, if not included in the SYN packet so they cannot be moved to the SLO option. The draft doesn't discuss this, and possibly it should. Thinking about it, I might suggest that only options explicitly defined to be SLO compatible should be included in the SLO space. At the moment, that list might include just timestamps. (Consider a SYN with MD5: LO (4 bytes) + WScale (4 bytes) + MSS (4 bytes) + SACK perm + TS (12 bytes) + MD5 (20 bytes) > 40 bytes - so we can't even advertise LO in this case if we include TS in the SYN) 3. Three SACK blocks is sufficient This is probably true for the vast majority of the time. However, auth options esp reduce the number of possible SACK blocks when timestamps are included as well. So, although extra SACK space is probably a waste in packets with just a timestamp option, it can have it's uses 4. We could squeeze the options better Several suggestions concerning making better use of the options space were suggested like a binary flags option where timestamp permitted and SACK permitted could live, or making the timestamp option smaller in SYN packets. This would have been a great idea before these options were deployed, but there's really no good way to transition now that they have wide acceptance in their current form. However, possibly we should change that by defining that binary flags option right now and make LO the first user. If there's general acceptance of this, I'll happily write the drafts. 5. Other methods of extending the option space For example, making DO 5-bits wide or defining a scaling options for DO. None seemed to gather widespread acceptance. 6. There's no need / we're not running out of space Fundamentally, this objection is unaddressable by a long options draft :) I suggest that there is a need in the case of TCP-AO/MD5 to include SACK blocks. Additionally, the lack on long options hampers experimentation. Personally, I'm pushing this because I want to include an ECDH key exchange and need the extra options space. Others have certainly needed the same thing and by specifying it we can aid experimentation and encourage future TCP work which might not have happened otherwise. -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 1 22:08:59 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B8583A6845; Tue, 1 Jul 2008 22:08:59 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CC423A6845 for ; Tue, 1 Jul 2008 22:08:58 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmFgyLJrLiwM for ; Tue, 1 Jul 2008 22:08:57 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by core3.amsl.com (Postfix) with ESMTP id 3B6293A67FC for ; Tue, 1 Jul 2008 22:08:57 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so81431and.122 for ; Tue, 01 Jul 2008 22:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=mQ5kmK6OKsR9GH0FW494dhrqxLUCXhMC+RMTp3ATxUk=; b=ceA1Hi3Y4f995tZ9DxCkft68uc9zmB6bqSgliv9yD2Zg4kE6ykf9bgK1TCLPf51lIn sN+OTC59r62V3dB189Js0CAt0DwxFsEeOy7oBUGng59k7mz7yiIbnhg/2DgkIFEC0Qe+ DelHL1kEFxFXHI5aZqlAe8JLQq3G7yIyh3trc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=eHQocasZpL9by/1Ok5KUblEqUEGM+36rMdS4n57uGtY8lwIjwRmjiHNt2O9R0JN17H 8513SRgFxD7qeFbrwkrzm6LUPyuWqKhruWM0Lgze87K9+wFQSmr7GyQ4k6W77X7LUIsL zQlKnyaxPkD6l/SZuAal5Imed6bD+ASQIlPQQ= Received: by 10.100.3.4 with SMTP id 4mr5915698anc.54.1214975342964; Tue, 01 Jul 2008 22:09:02 -0700 (PDT) Received: by 10.100.135.3 with HTTP; Tue, 1 Jul 2008 22:09:02 -0700 (PDT) Message-ID: <1e41a3230807012209j4a564e5bpd1b0b190c74e0ad1@mail.gmail.com> Date: Tue, 1 Jul 2008 22:09:02 -0700 From: "John Heffner" To: "Anantha Ramaiah (ananth)" In-Reply-To: <0C53DCFB700D144284A584F54711EC58056ADBFB@xmb-sjc-21c.amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <0C53DCFB700D144284A584F54711EC58056ADBF7@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC58056ADBFB@xmb-sjc-21c.amer.cisco.com> Cc: TCP Maintenance and Minor Extensions WG Subject: Re: [tcpm] TCP persist state issue. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Mon, Jun 30, 2008 at 10:44 PM, Anantha Ramaiah (ananth) wrote: >> You can find the copy of the first draft at : >> http://www.ietf.org/internet-drafts/draft-ananth-tcpm-persist-00.txt. >> Comments welcome. As with the previous draft, I think the greatest weakness of this one is that it focuses so much on the persist state. The conclusion states, "The document addresses the fact that terminating TCP connections stuck in the persist condition does not violate any RFC." But isn't this statement also true without the condition that connections are "stuck" in persist? That is, terminating a connection at any time is allowed, regardless of its state (see RFC 793, section 3.8, the ABORT command). And again, I think the persist state has fairly little to do with the more general DoS issue. Consider the following: a client that, instead of shrinking its window to zero, simply stops ACKing after sending the request, or a client that slowly acks one byte at a time. Both have the same effect on the server, are fairly straightforward, and neither advertise a zero window. -John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 2 07:55:01 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 614503A6BCA; Wed, 2 Jul 2008 07:55:01 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA1C43A687E for ; Wed, 2 Jul 2008 07:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.305 X-Spam-Level: X-Spam-Status: No, score=-6.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Rp2RsU8Oq1w for ; Wed, 2 Jul 2008 07:54:59 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E4DC43A6C7B for ; Wed, 2 Jul 2008 07:54:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,737,1204502400"; d="scan'208";a="17166313" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 02 Jul 2008 14:55:09 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m62Et9Pr001891; Wed, 2 Jul 2008 07:55:09 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m62Et7MY026005; Wed, 2 Jul 2008 14:55:09 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Jul 2008 07:55:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Jul 2008 07:54:07 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58056AE1FC@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <1e41a3230807012209j4a564e5bpd1b0b190c74e0ad1@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCP persist state issue. Thread-Index: AcjcAcJC+GWbdDHFS1qYXfNCcrNsUAAT7+IQ References: <0C53DCFB700D144284A584F54711EC58056ADBF7@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC58056ADBFB@xmb-sjc-21c.amer.cisco.com> <1e41a3230807012209j4a564e5bpd1b0b190c74e0ad1@mail.gmail.com> From: "Anantha Ramaiah (ananth)" To: "John Heffner" X-OriginalArrivalTime: 02 Jul 2008 14:55:09.0395 (UTC) FILETIME=[9F5A4A30:01C8DC53] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2376; t=1215010509; x=1215874509; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[tcpm]=20TCP=20persist=20state=20issue. |Sender:=20; bh=LU20eUKEV24C0z2+ynz0mxbIvPVfxIvfsQbCv7HXImw=; b=Uxi0wz9lw2ZhhWBIrpNlRcYaKbuozlyK3CamTOL97mZYnp5sFzQDAu3Y9K WE1r3m8SzPT0Hefu45VKKVki0eiU0SsPUOr6mKnn1FaFfXWrjgJ3fdremi6f IxgFSt4lRxyzfjSM7AANndYfVXo1gUZS5wY0CN0siAv7ysXn2PMnY=; Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: TCP Maintenance and Minor Extensions WG Subject: Re: [tcpm] TCP persist state issue. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hi John, Thanks for your comments, Pl see inline. > -----Original Message----- > From: John Heffner [mailto:johnwheffner@gmail.com] > Sent: Tuesday, July 01, 2008 10:09 PM > To: Anantha Ramaiah (ananth) > Cc: TCP Maintenance and Minor Extensions WG > Subject: Re: [tcpm] TCP persist state issue. > > On Mon, Jun 30, 2008 at 10:44 PM, Anantha Ramaiah (ananth) > wrote: > >> You can find the copy of the first draft at : > >> > http://www.ietf.org/internet-drafts/draft-ananth-tcpm-persist-00.txt. > >> Comments welcome. > > > As with the previous draft, I think the greatest weakness of > this one is that it focuses so much on the persist state. > The conclusion states, "The document addresses the fact that > terminating TCP connections stuck in the persist condition > does not violate any RFC." > But isn't this statement also true without the condition that > connections are "stuck" in persist? That is, terminating a > connection at any time is allowed, regardless of its state > (see RFC 793, section 3.8, the ABORT command). Correct. The whole point of writing this draft is that there is confusion w.r.t RFC 1122 verbiage which needed clarification. Atleast there was some consensus to that. It focuses on persist state because that is where the clarification is needed. Atleast that is the reading which was gathered after 60+ email exchanges last time. > > And again, I think the persist state has fairly little to do > with the more general DoS issue. Consider the following: a > client that, instead of shrinking its window to zero, simply > stops ACKing after sending the request, or a client that This will cause retransmissions from the server and eventually the connection would timeout. > slowly acks one byte at a time. > Both have the same effect on the server, are fairly > straightforward, and neither advertise a zero window. Slowly acking "one( or n << MSS) byte at a time" OR "ACK division attack" has other side effects too.. Like purposefully increase cwnd is covered by ABC draft. Again, the purpose of this document is not about various scenarios and solutions , it is written as an informational draft to clarifiy RFC 1122 verbiage w.r.t persist state. -Anantha > > -John > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 2 08:21:54 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 960EC3A69B8; Wed, 2 Jul 2008 08:21:54 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6DAD3A69B8 for ; Wed, 2 Jul 2008 08:21:53 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+OaXpsPyZt4 for ; Wed, 2 Jul 2008 08:21:53 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 0515F3A67EC for ; Wed, 2 Jul 2008 08:21:53 -0700 (PDT) Received: from [127.0.0.1] (pool-71-106-103-55.lsanca.dsl-w.verizon.net [71.106.103.55]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m62FLFXR017119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Jul 2008 08:21:17 -0700 (PDT) Message-ID: <486B9CEB.5040308@isi.edu> Date: Wed, 02 Jul 2008 08:21:15 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <0C53DCFB700D144284A584F54711EC58056ADBF7@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC58056ADBFB@xmb-sjc-21c.amer.cisco.com> <1e41a3230807012209j4a564e5bpd1b0b190c74e0ad1@mail.gmail.com> <0C53DCFB700D144284A584F54711EC58056AE1FC@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58056AE1FC@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: TCP Maintenance and Minor Extensions WG Subject: Re: [tcpm] TCP persist state issue. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0571029653==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0571029653== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF4D7141F6B2C28EA30A99053" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF4D7141F6B2C28EA30A99053 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: =2E.. > Correct. The whole point of writing this draft is that there is > confusion w.r.t RFC 1122 verbiage which needed clarification.=20 =2E.. > Again, the purpose of this document is not about various scenarios and > solutions , it is written as an informational draft to clarifiy RFC 112= 2 > verbiage w.r.t persist state. As Informational, it would not have that effect on a Standard. If this=20 is intended to redefine behavior, it needs to be standards track. I don't think highlighting a response in this case is needed at all,=20 since, as John pointed out, the behavior is already permitted by 793. Joe --------------enigF4D7141F6B2C28EA30A99053 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIa5zrE5f5cImnZrsRAnwAAKCd2mDjz+Hsh7xwUFIExTJEgPhVZgCfSh8m Cf385uDIplXD+H1zXFHBAaw= =kIIU -----END PGP SIGNATURE----- --------------enigF4D7141F6B2C28EA30A99053-- --===============0571029653== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0571029653==-- From tcpm-bounces@ietf.org Wed Jul 2 08:37:34 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F40C83A6838; Wed, 2 Jul 2008 08:37:33 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 705FD3A68BE for ; Wed, 2 Jul 2008 08:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.379 X-Spam-Level: X-Spam-Status: No, score=-6.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-kVUpEcMOBl for ; Wed, 2 Jul 2008 08:37:28 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 8B7623A6838 for ; Wed, 2 Jul 2008 08:37:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,738,1204502400"; d="scan'208";a="47819600" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 02 Jul 2008 15:37:38 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m62FbcNU014243; Wed, 2 Jul 2008 08:37:38 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m62Fbau5002072; Wed, 2 Jul 2008 15:37:38 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Jul 2008 08:36:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Jul 2008 08:35:34 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58056AE237@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <486B9CEB.5040308@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCP persist state issue. Thread-Index: AcjcV2gvm9qzwrbQQJy/odyxllMxqwAACjGA References: <0C53DCFB700D144284A584F54711EC58056ADBF7@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC58056ADBFB@xmb-sjc-21c.amer.cisco.com> <1e41a3230807012209j4a564e5bpd1b0b190c74e0ad1@mail.gmail.com><0C53DCFB700D144284A584F54711EC58056AE1FC@xmb-sjc-21c.amer.cisco.com> <486B9CEB.5040308@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" X-OriginalArrivalTime: 02 Jul 2008 15:36:35.0363 (UTC) FILETIME=[691AE730:01C8DC59] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2234; t=1215013058; x=1215877058; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[tcpm]=20TCP=20persist=20state=20issue. |Sender:=20; bh=tjbAkFn2xcHu6cO1sAqzYnJ8mHF33BssWS3htmVY2ww=; b=neyrVJejG1lfdVtYUrJNqdl/OIbXPfPx4SR45Xha21hgfjULkLkGpAKq2w hCaxFCSQ33lrGCoRdGhf/N9p9RtofdEpAeA4RVHdd+kU+ujYCOVIIlQZEQ6X w3vQHOQlWp; Authentication-Results: sj-dkim-2; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: TCP Maintenance and Minor Extensions WG Subject: Re: [tcpm] TCP persist state issue. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of Joe Touch > Sent: Wednesday, July 02, 2008 8:21 AM > To: Anantha Ramaiah (ananth) > Cc: TCP Maintenance and Minor Extensions WG > Subject: Re: [tcpm] TCP persist state issue. > > > > Anantha Ramaiah (ananth) wrote: > ... > > Correct. The whole point of writing this draft is that there is > > confusion w.r.t RFC 1122 verbiage which needed clarification. > ... > > Again, the purpose of this document is not about various > scenarios and > > solutions , it is written as an informational draft to clarifiy RFC > > 1122 verbiage w.r.t persist state. > > As Informational, it would not have that effect on a > Standard. If this is intended to redefine behavior, it needs > to be standards track. > > I don't think highlighting a response in this case is needed > at all, since, as John pointed out, the behavior is already > permitted by 793. Combining the above two statements, it appears that : "there is nothing to change in the standard since RFC 793 permits it". RFC 1122 is supposed to act as clarification for RFC 793 in many cases, which says " A TCP MAY keep it's offered receive window closed indefinitely. As long as the receiving TCP continues to send acknowledgments in response to the probe segments, the sending TCP MUST allow the connection to stay open. The RFC goes on to say that it is important to remember that ACK (acknowledgement) segments that contain no data are not reliably transmitted by TCP. Therefore zero window probing SHOULD be supported to prevent a connection from hanging forever if ACK segments that re-opens the window is lost....... So, the thinking was to have a clarification draft which combines the sentiments of RFC 793 and RFC 1122 and also the current issue's relationship to DoS. Well, I am not arguing agaianst your viewpoint, but trying to justify why this draft was written in the first place. I can post a summary of email exchanges and "conclusions" arrived after those email exchanges, if that helps. Thanks, -Anantha > > Joe > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 7 11:58:24 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1386F3A695E; Mon, 7 Jul 2008 11:58:24 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A1853A6948 for ; Mon, 7 Jul 2008 11:58:23 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jacUlJrz6-E for ; Mon, 7 Jul 2008 11:58:22 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 2D5513A681C for ; Mon, 7 Jul 2008 11:58:22 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 987EA3281B8; Mon, 7 Jul 2008 13:58:28 -0500 (CDT) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsppt02.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id m67IwSHA019041; Mon, 7 Jul 2008 13:58:28 -0500 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw03.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jul 2008 13:58:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 13:58:42 -0500 Message-ID: In-Reply-To: <396556a20807011128v27796016k81204b84e78fc25a@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCP Long Options Thread-Index: AcjbqDxYikw807+KSPevT7OwgdvH3AEuH1Ow References: <396556a20807010949i6c6c1d16g41c74e2f78414a92@mail.gmail.com><486A6777.80809@isi.edu> <396556a20807011128v27796016k81204b84e78fc25a@mail.gmail.com> From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: "Adam Langley" , "Joe Touch" X-OriginalArrivalTime: 07 Jul 2008 18:58:28.0471 (UTC) FILETIME=[71254070:01C8E063] X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7160:2.4.4, 1.2.40, 4.0.166 definitions=2008-07-07_04:2008-07-07, 2008-07-07, 2008-07-07 signatures=0 Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP Long Options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >Behalf Of Adam Langley >Sent: Tuesday, July 01, 2008 2:28 PM > >On Tue, Jul 1, 2008 at 10:20 AM, Joe Touch wrote: >> It might be worth reviewing the discussion on the TCP-LO when it was >> previously presented, and provide a summary to the group as >to whether >> anything has changed. > >Good point, although I am probably omitting salient points which I >missed when reviewing the archives: > > ... > Based on my memory, Adam's summary is pretty accurate. In 2005, the reason that Bob Braden cited to me for not publishing the previous version of this draft as Experimental was: > Basically, the critical fact here is that TCP is a core protocol for > the Internet, so any changes to it should go through the IETF process. > We understand that there are competing proposals, and TCP does not seem > to be an area where competition is desirable. Experimental > implementations of your proposal would probably not be a good idea. I guess the real problem was that the TCPM group didn't ever get consensus that working on any long options mechanism was important, so it never got done as a WG item, and it couldn't be done as an independent submission RFC because TCP is a core protocol. Thus, 4 years later, it is still not done, and I still get email every few months from people that stumble upon the draft and want to use it to enable some other experimental modification that requires a really long option or two. I think this is what happened with Adam. He was working on another project, ran across the previous version of the TCP Long Options draft, and discovered it was what he had been reinventing. In my personal opinion, it's a good idea to have some way to do long options (any way, not necessarily even this draft) that's at least published Experimental (off by default), simply because different groups of people keep thinking they need long options. I think that's the point that the WG didn't have consensus on in the past, and may or may not still lack. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 7 12:45:32 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 638BE3A6B1C; Mon, 7 Jul 2008 12:45:32 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B11A53A6B21 for ; Mon, 7 Jul 2008 12:45:22 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6q50rvenhoNK for ; Mon, 7 Jul 2008 12:45:17 -0700 (PDT) Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by core3.amsl.com (Postfix) with ESMTP id 5947D3A6B13 for ; Mon, 7 Jul 2008 12:45:16 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 15:45:27 -0400 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7703DC2C9B@nekter> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCP Long Options Thread-Index: AcjbqDxYikw807+KSPevT7OwgdvH3AEuH1OwAAIJBsA= References: <396556a20807010949i6c6c1d16g41c74e2f78414a92@mail.gmail.com><486A6777.80809@isi.edu><396556a20807011128v27796016k81204b84e78fc25a@mail.gmail.com> From: "Caitlin Bestler" To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" , "Adam Langley" , "Joe Touch" Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP Long Options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Wesley Eddy wrote: > > I guess the real problem was that the TCPM group didn't ever get > consensus that working on any long options mechanism was important, > so it never got done as a WG item, and it couldn't be done as an > independent submission RFC because TCP is a core protocol. Thus, > 4 years later, it is still not done, and I still get email every > few months from people that stumble upon the draft and want to use > it to enable some other experimental modification that requires a > really long option or two. I think this is what happened with Adam. > He was working on another project, ran across the previous version > of the TCP Long Options draft, and discovered it was what he had been > reinventing. > > In my personal opinion, it's a good idea to have some way to do > long options (any way, not necessarily even this draft) that's > at least published Experimental (off by default), simply because > different groups of people keep thinking they need long options. I > think that's the point that the WG didn't have consensus on in the > past, and may or may not still lack. > The functionality sought with TCP "long options" are already provided with SCTP. The only valid reason cited for not using SCTP for these type of new applications is lack of support from middle-boxes. Any TCP enhancement that does not preserve transparency to existing software and hardware will face all of the problems of SCTP, and probably with fewer benefits. In addition to the middle-box issue that is always cited, there is a special issue with changing the syntax of TCP options that is in the hosts themselves - any form of header/data separation done in existing software or hardware could be broken. This is especially true for LRO/LSO (Large Receive/Send Offload). I strongly suspect that any encoding that provided more option space would prove inherently incompatible with one or more existing middle boxes, host stacks and/or NICs. If such a feature merely provides SOCK_STREAM service between two enhancement-aware endpoints, then why not simply map SOCK_STREAM to SCTP at both ends and leave TCP alone? _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 7 13:34:39 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DACCE28C1D8; Mon, 7 Jul 2008 13:34:39 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72BA428C1E1 for ; Mon, 7 Jul 2008 13:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tm6sPCdtWrgI for ; Mon, 7 Jul 2008 13:34:37 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 76A2228C1D8 for ; Mon, 7 Jul 2008 13:34:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,318,1212364800"; d="scan'208";a="63357019" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 07 Jul 2008 20:30:51 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m67KUptR010637; Mon, 7 Jul 2008 13:30:51 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m67KUpGN012074; Mon, 7 Jul 2008 20:30:51 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jul 2008 13:30:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Jul 2008 13:29:48 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58056FDCA4@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7703DC2C9B@nekter> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCP Long Options Thread-Index: AcjbqDxYikw807+KSPevT7OwgdvH3AEuH1OwAAIJBsAAAWSLQA== References: <396556a20807010949i6c6c1d16g41c74e2f78414a92@mail.gmail.com><486A6777.80809@isi.edu><396556a20807011128v27796016k81204b84e78fc25a@mail.gmail.com> <78C9135A3D2ECE4B8162EBDCE82CAD7703DC2C9B@nekter> From: "Anantha Ramaiah (ananth)" To: "Caitlin Bestler" , "Eddy, Wesley M. (GRC-RCN0)[VZ]" , "Adam Langley" , "Joe Touch" X-OriginalArrivalTime: 07 Jul 2008 20:30:51.0138 (UTC) FILETIME=[58D51E20:01C8E070] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1445; t=1215462651; x=1216326651; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[tcpm]=20TCP=20Long=20Options |Sender:=20; bh=E+Ubb2eLKbH2yGgEJ75vjXBvFoMVRglJv/wP8r8yYHk=; b=OgffQ28UABVGMtNfmE0pujb1defOoRVfY8iYxWMKgmRJKRinXaXd+5tGuA RFAGQ0Yw290OoxP2BifBFnS7RAxNgflB1ihPB4RVDaEGakiBGuIIpsodA3dI Ifp1+DQmbo; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP Long Options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > > > > The functionality sought with TCP "long options" are already > provided with SCTP. The only valid reason cited for not using > SCTP for these type of new applications is lack of support > from middle-boxes. I have to dis-agree here. There are planty of TCP applications that wouldn't simply migrate to SCTP for many reasons. This is somewhat similar to the "IPv4 to IPv6 transition, NAT's" etc., Hence I would be very careful to use this sort of reasoning. > > Any TCP enhancement that does not preserve transparency to > existing software and hardware will face all of the problems > of SCTP, and probably with fewer benefits. Well, are you saying that the proposed enhancements wouldn't work well with middleboxes? Again, that shouldn't stop from having enhancements made to TCP. IMO. > I strongly suspect that any encoding that provided more > option space would prove inherently incompatible with one or > more existing middle boxes, host stacks and/or NICs. If such > a feature merely provides SOCK_STREAM service between two > enhancement-aware endpoints, then why not simply map > SOCK_STREAM to SCTP at both ends and leave TCP alone? Easier said than done. The issue here is that the existing TCP applications need support for long TCP options, so asking them to migrate to SCTP may be ok, but doesn't sound practical. $0.02, -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 7 14:07:35 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FE7F3A6B3A; Mon, 7 Jul 2008 14:07:35 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1AE128C22F for ; Mon, 7 Jul 2008 14:07:34 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dH+g+XoTTDRq for ; Mon, 7 Jul 2008 14:07:34 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 570DA3A6876 for ; Mon, 7 Jul 2008 14:07:32 -0700 (PDT) Received: from [127.0.0.1] (9.sub-75-214-59.myvzw.com [75.214.59.9]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m67L7F1f021381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Jul 2008 14:07:18 -0700 (PDT) Message-ID: <48728582.5080904@isi.edu> Date: Mon, 07 Jul 2008 14:07:14 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" References: <396556a20807010949i6c6c1d16g41c74e2f78414a92@mail.gmail.com><486A6777.80809@isi.edu> <396556a20807011128v27796016k81204b84e78fc25a@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] TCP Long Options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0231498302==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0231498302== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8FFA4473AFCF618772CBE3E1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8FFA4473AFCF618772CBE3E1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 >> Behalf Of Adam Langley >> Sent: Tuesday, July 01, 2008 2:28 PM >> >> On Tue, Jul 1, 2008 at 10:20 AM, Joe Touch wrote: >>> It might be worth reviewing the discussion on the TCP-LO when it was >>> previously presented, and provide a summary to the group as=20 >> to whether >>> anything has changed. >> >> Good point, although I am probably omitting salient points which I >> missed when reviewing the archives: >> >> ... >> >=20 >=20 > Based on my memory, Adam's summary is pretty accurate. In 2005, the > reason that Bob Braden cited to me for not publishing the previous > version of this draft as Experimental was: =2E.. > I guess the real problem was that the TCPM group didn't ever get > consensus that working on any long options mechanism was important, > so it never got done as a WG item, and it couldn't be done as an > independent submission RFC because TCP is a core protocol.... I'm recalling that no mechanism was ever developed that was backward=20 compatible with legacy TCP implementations, i.e., that "did the right=20 thing" for SYNs with long options. Doing well for other segments is=20 somewhat moot if SYNs cannot be extended, because space is most critical = for them. Joe --------------enig8FFA4473AFCF618772CBE3E1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIcoWDE5f5cImnZrsRAlkhAKCjqR8f/HAbcQNIUZqFuLwrp5tCYACgngaR XGuvKmXLAuWczCodvQbI2jQ= =OiJf -----END PGP SIGNATURE----- --------------enig8FFA4473AFCF618772CBE3E1-- --===============0231498302== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0231498302==-- From tcpm-bounces@ietf.org Mon Jul 7 14:27:04 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C46F28C249; Mon, 7 Jul 2008 14:27:04 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C9E028C249 for ; Mon, 7 Jul 2008 14:27:03 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqjDcXPkYBJL for ; Mon, 7 Jul 2008 14:27:02 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id A23E928C248 for ; Mon, 7 Jul 2008 14:27:02 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2178268rvf.49 for ; Mon, 07 Jul 2008 14:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=LqSVa9HvbQSXtkzV0x3+salyKc+oFD5rOra7gf52fxc=; b=RkHW78go9SZqjSe3lX+FgA1GbwpgkUK9QQS0/139LnS4+WuZboi3c8nP5QnAh5hGEC ob2bZFmGmp6CtKV3oOY153xBFo22xokena21mqeL0qq8pd2RdjpMWwYbzLlVR2dxPXau enIIdjLAGo/AgK3ySTJ5CXtugPa4x78JuP5y4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=oRA+YEkli+h65gMCs6QWRhiuIpU294P+WfIjxhOGj+mJJZyWY/sl3QSpcHz2xNWyKH F1o45sINqq6CxN7VmzBHEusStSIhs9+sGTPLNv0Al7RasDGPUX8KuBAb4D3tWfRCYd3O BC2c0BingqS8aCKvYBE2QdcWNvA/VnwFa4+sU= Received: by 10.141.114.19 with SMTP id r19mr2752195rvm.295.1215466025899; Mon, 07 Jul 2008 14:27:05 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Mon, 7 Jul 2008 14:27:05 -0700 (PDT) Message-ID: <396556a20807071427l27ec0087ya7d68f321749e36@mail.gmail.com> Date: Mon, 7 Jul 2008 14:27:05 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <48728582.5080904@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20807010949i6c6c1d16g41c74e2f78414a92@mail.gmail.com> <486A6777.80809@isi.edu> <396556a20807011128v27796016k81204b84e78fc25a@mail.gmail.com> <48728582.5080904@isi.edu> X-Google-Sender-Auth: 2fdf9a7de9cfa6dc Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP Long Options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Mon, Jul 7, 2008 at 2:07 PM, Joe Touch wrote: > I'm recalling that no mechanism was ever developed that was backward > compatible with legacy TCP implementations, i.e., that "did the right thing" > for SYNs with long options. Doing well for other segments is somewhat moot > if SYNs cannot be extended, because space is most critical for them. I don't believe that such a system is actually possible; if anyone has an idea about this please speak up. One could imagine assuming that the remote end supports long options and backing off when retransmitting the SYN frame, but I don't believe such behaviour is actually reasonable because of the additional latency. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 7 14:53:05 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 913D43A6876; Mon, 7 Jul 2008 14:53:05 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E48D3A697C for ; Mon, 7 Jul 2008 14:53:04 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0DvbnGRRKDH for ; Mon, 7 Jul 2008 14:53:03 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 47C923A6B2B for ; Mon, 7 Jul 2008 14:53:00 -0700 (PDT) Received: from [127.0.0.1] (9.sub-75-214-59.myvzw.com [75.214.59.9]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m67LqAON003463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Jul 2008 14:52:42 -0700 (PDT) Message-ID: <48729009.3020606@isi.edu> Date: Mon, 07 Jul 2008 14:52:09 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Adam Langley References: <396556a20807010949i6c6c1d16g41c74e2f78414a92@mail.gmail.com> <486A6777.80809@isi.edu> <396556a20807011128v27796016k81204b84e78fc25a@mail.gmail.com> <48728582.5080904@isi.edu> <396556a20807071427l27ec0087ya7d68f321749e36@mail.gmail.com> In-Reply-To: <396556a20807071427l27ec0087ya7d68f321749e36@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP Long Options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1097391221==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1097391221== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig27358DACCF13AE51FD6B3E23" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig27358DACCF13AE51FD6B3E23 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Adam Langley wrote: > On Mon, Jul 7, 2008 at 2:07 PM, Joe Touch wrote: >> I'm recalling that no mechanism was ever developed that was backward >> compatible with legacy TCP implementations, i.e., that "did the right = thing" >> for SYNs with long options. Doing well for other segments is somewhat = moot >> if SYNs cannot be extended, because space is most critical for them. >=20 > I don't believe that such a system is actually possible... I believe that was the sticking point the last time we talked. If we=20 give up on backward compatibility, the variants become overwhelming,=20 including Mark Allman's "let's double all the fields" proposal, as I=20 recall, and none is sufficiently motivated at this time AFAICT. I.e., it = is when we give up on backward compatibility that Braden's observation,=20 I believe, applies. Joe --------------enig27358DACCF13AE51FD6B3E23 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIcpAJE5f5cImnZrsRAgVHAJ4rMFE1kcPcyJJHnRzex41o7iZ4tACeM/G3 ebSABfp+w9PwiDvHGOmS1Tw= =2Bmo -----END PGP SIGNATURE----- --------------enig27358DACCF13AE51FD6B3E23-- --===============1097391221== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1097391221==-- From tcpm-bounces@ietf.org Tue Jul 8 21:49:24 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A39128C0E5; Tue, 8 Jul 2008 21:49:24 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6E9E28C0E5 for ; Tue, 8 Jul 2008 21:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APUhAbLjfKBS for ; Tue, 8 Jul 2008 21:49:21 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id ADFC228C0DF for ; Tue, 8 Jul 2008 21:49:21 -0700 (PDT) Received: from [127.0.0.1] (pool-71-106-110-19.lsanca.dsl-w.verizon.net [71.106.110.19]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m694nKQm001540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Jul 2008 21:49:22 -0700 (PDT) Message-ID: <48744351.20609@isi.edu> Date: Tue, 08 Jul 2008 21:49:21 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Adam Langley References: <396556a20807011045n20656450w7da5955bab19fbd9@mail.gmail.com> In-Reply-To: <396556a20807011045n20656450w7da5955bab19fbd9@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcp-auth-opt-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0174443146==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0174443146== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7C8BA6B2E7E7F9BDF76B97A5" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7C8BA6B2E7E7F9BDF76B97A5 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Adam Langley wrote: >> 2.2. TCP-AO Option >=20 > [snip] >=20 >> The MAC is computed over the following fields in the following order: >=20 > Currently AO is suggesting the same serialisation as TCPMD5: > sig =3D MAC(key, pseudoheader + header + data) >=20 > I suggest, instead, that the default serialisation be: > sig =3D MAC(key, H(data) + pseudoheader + header) >=20 > When the TCP stack is getting data from userspace, it generally knows > the MSS and splits the data into packets right away. With the > suggested serialisation, the data can be hashed as it's copied and the > hash stored with the data. This saves traversing the data again at > transmit time to calculate the MD5 signature. The latter is no less > secure, I believe, and opens up possibilities for optimisation so > should be a clear gain. The current algorithm is optimized for the most common case, where=20 TCP-AO is implemented inside the stack, and the hash is computed just=20 before the packet is emitted. The same is true on the receiving end -=20 i.e., in both cases, the data is processed as a single stream, whichis=20 why the order is [pseudoheader, header, data]. This works well for both=20 software implementations inside the stack and hardware as well. The above is optimized assuming that the hash is computed during a copy=20 operation that may or may not occur (e.g., it would not in a zero-copy=20 stack), and further assumes that the copy is performed one MSS at a time = (vs. copying the entire write() call argument, i.e., copy-on-write).=20 It's not clear that optimizing the algorithm for this corner case is=20 desirable, especially given the impact on more traditional=20 implementations (i.e., the extra header copies/moves). =2E.. > Additionally, the draft already mentions an Option Kind Exclusion List > and I'd suggest another option: that the pseudoheader be omitted and > the source/destination ports in the TCP header be zeroed. This would > allowed the signature to be robust to most (all?) NATs. The NAT > workaround suggested in section 7 is impractical for many uses and a > significant fraction of hosts are now imprisoned behind NATs. I'd like to hear what others think of this. My view is that NATs do=20 other things to TCP packets (e.g., rewrite sequence numbers, modify TCP=20 options) that TCP-AO should probably detect as attacks. An earlier=20 version of this work did consider replacing these values (addr/port=20 pairs), not zeroing them out - i.e., replacing them with values=20 determined during key exchange. I would prefer that to zeroing them out, = though. > Currently unspecified is a nonce for the packets. Modern MAC > functions, based on polynomials (such as [1]), can have the very > pleasing property of being provably within a factor as secure as > another function (like a block cipher). However, they often require > nonces as inputs. >=20 > A trivial solution would be to keep a 64-bit counter, increment it for > each transmission and transmit it along with the signature. However, > we'll struggle to fit that all in the options space; esp for SYN > packets. Next we could consider taking the seq number as the lower > 32-bits of a 64-bit counter. However, that doesn't guarantee that two > different messages wouldn't be transmitted with the same nonce. We > could just transmit the bottom (say) 16-bits of the nonce, but a > prolonged outage could knock the endpoints out of sync. I don't have a > good solution here. TCP already includes a 16-bit counter - the sequence number. The use of=20 longer counters that retain the high-order bits of that number were=20 discussed in Philadelphia. The key problems involve retransmission at=20 the edge of counter wrap; a goal of TCP-AO is to avoid modifying the TCP = protocol itself. As you note, there didn't seem to be a good solution her= e. =2E.. > Also, is encryption of the payload considered out-of-scope for this spe= c? Yes. Payload encryption is provided by SSL. oe --------------enig7C8BA6B2E7E7F9BDF76B97A5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIdENRE5f5cImnZrsRAhoOAKDR9JM3vL2Hw8aqufV12g3mSpAWCQCfYyiD 66b67kqzEtVDYxx5e6arkL8= =XvL/ -----END PGP SIGNATURE----- --------------enig7C8BA6B2E7E7F9BDF76B97A5-- --===============0174443146== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0174443146==-- From tcpm-bounces@ietf.org Tue Jul 8 23:59:22 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA4BE3A683B; Tue, 8 Jul 2008 23:59:22 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7311E3A683B for ; Tue, 8 Jul 2008 23:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrPJ5qPIFt92 for ; Tue, 8 Jul 2008 23:59:21 -0700 (PDT) Received: from wall.ikr.uni-stuttgart.de (wall.ikr.uni-stuttgart.de [129.69.170.1]) by core3.amsl.com (Postfix) with ESMTP id 2D6933A6839 for ; Tue, 8 Jul 2008 23:59:21 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by wall.ikr.uni-stuttgart.de (Postfix) with ESMTP id 0A86B56CD3 for ; Wed, 9 Jul 2008 08:59:31 +0200 (CEST) Received: by netsrv1.ikr.uni-stuttgart.de (Postfix, from userid 539) id 09A46BC081; Wed, 9 Jul 2008 08:59:31 +0200 (CEST) Received: from ikr.uni-stuttgart.de (inode21 [10.21.18.11]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with SMTP id DA26FBC07E for ; Wed, 9 Jul 2008 08:59:30 +0200 (CEST) Received: by ikr.uni-stuttgart.de (sSMTP sendmail emulation); Wed, 9 Jul 2008 08:59:30 +0200 Date: Wed, 9 Jul 2008 08:59:30 +0200 From: Michael Scharf To: tcpm@ietf.org Message-ID: <20080709065930.GA20872@ikr.uni-stuttgart.de> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Subject: [tcpm] New ID: draft-scharf-tcpm-flow-control-quick-start-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hi all, this draft addresses some specific issues of the TCP flow control that can arise if the congestion control does not use the Slow-Start, e. g., by using the Quick-Start TCP extension (RFC 4782). An earlier version of this draft has been submitted to TSVWG, and resulted in an errata to RFC 4782: http://www.rfc-editor.org/errata_search.php?rfc=4782 But since the underlying problem is not specific to Quick-Start and could also arise in other "Faster-Than-Slow-Start" schemes, there has been some feedback from TSVWG that TCPM might be a better place to discuss this draft. Please note that there are some ongoing discussions in ICCRG how "Faster-Than-Slow-Start" schemes other than Quick-Start could be realized. This draft is relevant in this context. Any comments would be welcome. Michael ----- Forwarded message from Internet-Drafts@ietf.org ----- From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-scharf-tcpm-flow-control-quick-start-00.txt Date: Mon, 7 Jul 2008 06:30:02 -0700 (PDT) Precedence: list Reply-To: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : TCP Flow Control for Fast Startup Schemes Author(s) : M. Scharf, et al. Filename : draft-scharf-tcpm-flow-control-quick-start-00.txt Pages : 13 Date : 2008-07-07 This document describes extensions for the flow control of the Transmission Control Protocol (TCP) that avoid interactions with fast startup congestion control mechanisms, in particular the Quick-Start TCP extension. Quick-Start is an optional TCP extension that allows to start data transfers with a large congestion window, using feedback of the routers along the path. This can avoid the time consuming Slow-Start, provided that the TCP flow control is not a limiting factor. There are two potential interactions between the TCP flow control and congestion control schemes without the standard Slow-Start: First, receivers might not allocate a sufficiently large buffer space after connection setup, or they may advertise a receive window implicitly assuming the Slow-Start behavior on the sender side. This document therefore provides guidelines for buffer allocation in hosts supporting the Quick-Start extension. Second, the TCP receive window scaling mechanism can prevent fast startups immediately after the initial three-way handshake connection setup. This document describes a simple solution to overcome this problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-scharf-tcpm-flow-control-quick-start-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ----- End forwarded message ----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 9 00:30:04 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 291C63A6935; Wed, 9 Jul 2008 00:30:04 -0700 (PDT) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A93823A683D; Wed, 9 Jul 2008 00:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080709073001.A93823A683D@core3.amsl.com> Date: Wed, 9 Jul 2008 00:30:01 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcpsecure-10.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Improving TCP's Robustness to Blind In-Window Attacks Author(s) : A. Ramaiah, et al. Filename : draft-ietf-tcpm-tcpsecure-10.txt Pages : 27 Date : 2008-07-09 TCP has historically been considered protected against spoofed off- path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32 bit sequence number(s). A combination of increasing window sizes and applications using longer term connections (e.g. H-323 or Border Gateway Protocol [RFC4271]) have left modern TCP implementations more vulnerable to these types of spoofed packet injection attacks. Many of these long term TCP applications tend to have predictable IP addresses and ports which makes it far easier for the 4-tuple to be guessed. Having guessed the 4-tuple correctly, an attacker can inject a RST, SYN or DATA segment into a TCP connection by systematically guessing the sequence number of the spoofed segment to be in the current receive window. This can cause the connection to either abort or possibly cause data corruption. This document specifies small modifications to the way TCP handles inbound segments that can reduce the chances of a successful attack. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-tcpsecure-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-09002153.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Wed Jul 9 07:18:06 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C290F28C160; Wed, 9 Jul 2008 07:18:06 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 648713A6AC2 for ; Wed, 9 Jul 2008 07:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-Lc7A2LJqRg for ; Wed, 9 Jul 2008 07:18:04 -0700 (PDT) Received: from mail-i4.informatik.rwth-aachen.de (mail-i4.informatik.RWTH-Aachen.DE [137.226.12.21]) by core3.amsl.com (Postfix) with ESMTP id 084933A6AC7 for ; Wed, 9 Jul 2008 07:18:03 -0700 (PDT) Received: from info-4.informatik.rwth-aachen.de (cronos.info-4.informatik.rwth-aachen.de [137.226.12.31]) by mail-i4.informatik.rwth-aachen.de (Postfix) with ESMTP id D9306578BB for ; Wed, 9 Jul 2008 16:18:14 +0200 (CEST) Received: from chicago.info-4.informatik.rwth-aachen.de ([137.226.12.187]) by info-4.informatik.rwth-aachen.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jul 2008 16:18:14 +0200 Message-Id: From: Alexander Zimmermann To: tcpm@ietf.org Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 9 Jul 2008 16:18:14 +0200 X-Pgp-Agent: GPGMail d51 (Leopard) X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 09 Jul 2008 14:18:14.0708 (UTC) FILETIME=[A0301F40:01C8E1CE] Cc: braden@isi.edu, david.borman@windriver.com, van@packetdesign.com Subject: [tcpm] (Mini)Review: draft-ietf-tcpm-1323bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0634874389==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0634874389== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-65--1064789792" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-65--1064789792 Content-Type: multipart/alternative; boundary=Apple-Mail-64--1064789832 --Apple-Mail-64--1064789832 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi folks, here some comments: page 6, 2**31/B: In my opinion a short reason or a reference why 2**31 and not for example 2**32-1 is correct would be nice. page 14, figures: The new (upper) figure is (from step 5 on) incorrect. TSval should be 65 in step 5, isn't it? Hmm, we have also two steps with number 5... page 15, paragraph 3: The last sentence is incomplete. page 34, point (b): It should be TS.Recent and not TSrecent, right? Regards, Alex // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science 4, RWTH Aachen University // Ahornstr. 55, 52074 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-64--1064789832 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Hi = folks,

here some = comments:

page 6, 2**31/B: In my opinion a = short reason or a reference why  2**31 and not for example = 2**32-1 is correct would be nice.
page 14, figures: The new = (upper) figure is  (from step 5 on) incorrect. TSval = should be 65 in step 5, isn't it? Hmm, we have also two steps with = number 5...
page 15, paragraph 3: The last sentence is = incomplete.
page 34, point (b): It should be TS.Recent and not = TSrecent, = right?

Regards,
Alex

//
// Dipl.-Inform. Alexander = Zimmermann
// Department of Computer Science 4, RWTH Aachen = University
// Ahornstr. 55, 52074 Aachen, Germany
// = phone: (49-241) 80-21422, fax: (49-241) 80-22220
/= /

= --Apple-Mail-64--1064789832-- --Apple-Mail-65--1064789792 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkh0yKcACgkQdyiq39b9uS7utQCguQqxex0OWFNNavQToKm+56gl 8GsAnRwxAxG+r5p9ddruahw9CG3pqLAP =4J44 -----END PGP SIGNATURE----- --Apple-Mail-65--1064789792-- --===============0634874389== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0634874389==-- From tcpm-bounces@ietf.org Wed Jul 9 09:30:44 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F1293A6B12; Wed, 9 Jul 2008 09:30:44 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9D083A6AE4 for ; Wed, 9 Jul 2008 09:30:42 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DCllN77Y7iV for ; Wed, 9 Jul 2008 09:30:41 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 634D83A6B11 for ; Wed, 9 Jul 2008 09:30:41 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m69GUoaQ028164; Wed, 9 Jul 2008 09:30:50 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 09:30:49 -0700 Received: from dab-restive.wrs.com ([192.168.117.73]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 09:30:49 -0700 Message-Id: From: David Borman To: tcpm@ietf.org, Alexander Zimmermann In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 9 Jul 2008 11:30:48 -0500 References: X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 09 Jul 2008 16:30:49.0815 (UTC) FILETIME=[25CD1E70:01C8E1E1] Subject: Re: [tcpm] (Mini)Review: draft-ietf-tcpm-1323bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hi Alexander, Thanks for the review, see my comments below. -David Borman On Jul 9, 2008, at 9:18 AM, Alexander Zimmermann wrote: > Hi folks, > > here some comments: > > page 6, 2**31/B: In my opinion a short reason or a reference why > 2**31 and not for example 2**32-1 is correct would be nice. This section is talking about issues of wrapping the sequence space, which happens at 2**31. The other half of the sequence space is to the left of the window. > page 14, figures: The new (upper) figure is (from step 5 on) > incorrect. TSval should be 65 in step 5, isn't it? Hmm, we have also > two steps with number 5... Oh my, this whole example is messed up. I'm not quite sure what happened, but I will fix it for the next revision. > page 15, paragraph 3: The last sentence is incomplete. Yes, that'll be fixed in the next revision. > page 34, point (b): It should be TS.Recent and not TSrecent, right? Yes. And I found two other cases where the same change needs to be made. > > > Regards, > Alex > > // > // Dipl.-Inform. Alexander Zimmermann > // Department of Computer Science 4, RWTH Aachen University > // Ahornstr. 55, 52074 Aachen, Germany > // phone: (49-241) 80-21422, fax: (49-241) 80-22220 > // email: zimmermann@cs.rwth-aachen.de > // web: http://www.umic-mesh.net > // > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 9 09:48:08 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57A053A6A88; Wed, 9 Jul 2008 09:48:08 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E46C3A6A88 for ; Wed, 9 Jul 2008 09:48:07 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meB+JhsfspJ6 for ; Wed, 9 Jul 2008 09:48:06 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id 1DCA13A68E8 for ; Wed, 9 Jul 2008 09:48:06 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2759807rvf.49 for ; Wed, 09 Jul 2008 09:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=WfKtzgBP/mEGMjB/LMu+TN8vl8IyRBkkxRHUfIdO1kQ=; b=CGEgr7KEakItV4NYi2uZkR1Pp4sok9gIgsXKBMKHtWLPaxa7JOCEsegQLgfUG2MByo jYFCJ4QGfEW9xsPnveHoa6S9XiS9sN2QDNr7Cm9eJnqKFkttEQQvuqd/tkKPCXUoKoKE ssaYt/AXx2F2tdi/P//AofzHlNIuXLq71+Uc0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=TXyqe7BVybW+4bcco6G5FCftNO+JypT1i/SaZo5Cr0mVX3i8bx/cqjCYXydZZnBIrN cjoBzzy86ivL2NESOcG5B6cg1cxFbapwFb0pPPdxBhMLL5/2fdV5jr0nEDs6Q3K3fjhM mUAbM0QKQY45ZX+YYCVtZuOIZEdkntoaS2C8g= Received: by 10.141.172.6 with SMTP id z6mr4116962rvo.91.1215622096177; Wed, 09 Jul 2008 09:48:16 -0700 (PDT) Received: by 10.141.37.3 with HTTP; Wed, 9 Jul 2008 09:48:16 -0700 (PDT) Message-ID: <396556a20807090948i10212b9dgcdc4525cc7676fa7@mail.gmail.com> Date: Wed, 9 Jul 2008 09:48:16 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <48744351.20609@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20807011045n20656450w7da5955bab19fbd9@mail.gmail.com> <48744351.20609@isi.edu> X-Google-Sender-Auth: 11f778e34cda372e Cc: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcp-auth-opt-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Tue, Jul 8, 2008 at 9:49 PM, Joe Touch wrote: > The above is optimized assuming that the hash is computed during a copy > operation that may or may not occur (e.g., it would not in a zero-copy > stack), and further assumes that the copy is performed one MSS at a time > (vs. copying the entire write() call argument, i.e., copy-on-write). It's > not clear that optimizing the algorithm for this corner case is desirable, > especially given the impact on more traditional implementations (i.e., the > extra header copies/moves). I don't believe that it would involve moving any extra data, you just update the hash context with chunks in a different order. Although I feel it's very low cost when not used and useful where it can be used, it is fundamentally just a trick and not that important. > I'd like to hear what others think of this. My view is that NATs do other > things to TCP packets (e.g., rewrite sequence numbers, modify TCP options) > that TCP-AO should probably detect as attacks. An earlier version of this > work did consider replacing these values (addr/port pairs), not zeroing them > out - i.e., replacing them with values determined during key exchange. I > would prefer that to zeroing them out, though. Although some NATs do change seq numbers, I've only heard it used for FTP PORT commands. By not including the sequence numbers in a hash, you are really reducing the power of the signatures, but it would still have some use (against blind sweeps of the sequence space, for example), so it shouldn't be dismissed out of hand. Since the option exclusion list is so general, it would seem inconsistent if the spec was to be inflexible here. NATs which change ports and IPs are now, sadly, almost ubiquitous and cannot be ignored. The most general solution would be for applications to specify a 20 byte mask and a single bit to determine if the pseudoheader is to be included. Then the TCP header for the hash is: (header & mask) | (filler & !mask) where "header" is the header on the wire and "filler" is key-dependent material. (Basically, a zero bit in the mask means "replace this bit with a bit from the filler"). The bits corresponding to the TCP checksum should probably be forced to zero by the kernel. Since only applications can decide what should be considered an attack, that covers all the cases, it's fast and easy to do in hardware. The filler needs to be 20 bytes, so I'd suggest iterating H(key), H("\x00" + key), H("\x00\x00" + key) etc until 20 bytes have been generated. For SHA1, only one iteration is needed. For MD5, only two. ("+" is a concatenation operator here) > TCP already includes a 16-bit counter - the sequence number. The use of > longer counters that retain the high-order bits of that number were > discussed in Philadelphia. The security properties of these functions usually depend strongly on the condition that no two messages be transmitted with the same nonce. If the seq number were to be taken as the bottom 32-bits of a nonce counter, we could still hit the situation where two different packets were transmitted with the same nonce. For example, a host acking data, but not transmitting any itself. If we included both seq and ack in the nonce, then I believe the retransmitted ACKs with and without SACK options could still break this. > The key problems involve retransmission at the > edge of counter wrap; a goal of TCP-AO is to avoid modifying the TCP > protocol itself. As you note, there didn't seem to be a good solution here. I don't see that's a big problem: The host maintains a belief of the high 32-bits (H) of the counter and the last low-32 bits that it saw (L). For each packet with a new sequence number (S): If the distance from L..S is < S..L (mod 2**32) then assume out-of-order reception; if L...S crosses a rollover, decrement H. L <- S. Otherwise, if S..L crosses a rollover, increment H. L <- S This can be confused by massive reordering. However, that just leads to the packet being rejected and it's probably been retransmitted anyway. Also, if a huge number of packets were lost the hosts could be knocked out of sync. Some additional logic could cope with this (assume it might have happened and check the MAC for another sequence number), but I believe that the window would have to be about 2GB big for this to happen. So, I believe the non-uniqueness problem is much greater. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 9 11:49:06 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 614583A695C; Wed, 9 Jul 2008 11:49:06 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95D7628C1F6 for ; Wed, 9 Jul 2008 11:49:05 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+Tceejuk7Qd for ; Wed, 9 Jul 2008 11:49:04 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 999463A695C for ; Wed, 9 Jul 2008 11:49:04 -0700 (PDT) Received: from [127.0.0.1] (118.sub-75-214-147.myvzw.com [75.214.147.118]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m69ImolL013971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Jul 2008 11:48:52 -0700 (PDT) Message-ID: <4875080D.9040500@isi.edu> Date: Wed, 09 Jul 2008 11:48:45 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Adam Langley References: <396556a20807011045n20656450w7da5955bab19fbd9@mail.gmail.com> <48744351.20609@isi.edu> <396556a20807090948i10212b9dgcdc4525cc7676fa7@mail.gmail.com> In-Reply-To: <396556a20807090948i10212b9dgcdc4525cc7676fa7@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-tcp-auth-opt-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0833839435==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0833839435== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6AD8E2778CFC0E64B204CAF6" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6AD8E2778CFC0E64B204CAF6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Adam Langley wrote: =2E.. =2E.. >> TCP already includes a 16-bit counter - the sequence number. The use o= f >> longer counters that retain the high-order bits of that number were >> discussed in Philadelphia. (I had the IP ID on my brain; it's a 32-bit counter, as noted below). > The security properties of these functions usually depend strongly on > the condition that no two messages be transmitted with the same nonce. Note that the inclusion of the IP ID may help in this regard; not only=20 does the 32-bit seqno need to be repeated, but so does the ID; overall,=20 the pair of those two should could be sufficient for statistical=20 uniqueness (although, if we relax the ID requirement as per my intarea=20 draft, that might not be the case)... We talked in Phila about the use of either counters for the high-order=20 bits of the 32-bit space, or about the use of rekeying to handle this. >> The key problems involve retransmission at the >> edge of counter wrap; a goal of TCP-AO is to avoid modifying the TCP >> protocol itself. As you note, there didn't seem to be a good solution = here. >=20 > I don't see that's a big problem: The host maintains a belief of the > high 32-bits (H) of the counter and the last low-32 bits that it saw > (L). For each packet with a new sequence number (S): > If the distance from L..S is < S..L (mod 2**32) then assume > out-of-order reception; if L...S crosses a rollover, decrement H. L <- > S. > Otherwise, if S..L crosses a rollover, increment H. L <- S >=20 > This can be confused by massive reordering. However, that just leads > to the packet being rejected and it's probably been retransmitted > anyway. Also, if a huge number of packets were lost the hosts could be > knocked out of sync. Some additional logic could cope with this > (assume it might have happened and check the MAC for another sequence > number), but I believe that the window would have to be about 2GB big > for this to happen. IMO, this is much more effectively handled by rekeying. Doing so every=20 4GB (or even twice as often) should be more than sufficient. Joe --------------enig6AD8E2778CFC0E64B204CAF6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIdQgRE5f5cImnZrsRAtc1AJ9EKLUUZ852OLUy6WPnNhao82w2NgCg1o0F ZcflBukcP1rsZPegn1psx2c= =ObL4 -----END PGP SIGNATURE----- --------------enig6AD8E2778CFC0E64B204CAF6-- --===============0833839435== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0833839435==-- From tcpm-bounces@ietf.org Sun Jul 13 23:04:50 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABC433A6A82; Sun, 13 Jul 2008 23:04:50 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75F5F3A6A46 for ; Sun, 13 Jul 2008 23:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cz3bqsNDQBmG for ; Sun, 13 Jul 2008 23:04:48 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 726D33A6A73 for ; Sun, 13 Jul 2008 23:04:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,357,1212364800"; d="url'?scan'208";a="52469408" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 14 Jul 2008 06:05:13 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m6E65D7N027447; Sun, 13 Jul 2008 23:05:13 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m6E65DOf000302; Mon, 14 Jul 2008 06:05:13 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 13 Jul 2008 23:05:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8E577.946011EA" Date: Sun, 13 Jul 2008 23:04:09 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58057555B0@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] I-D Action:draft-ietf-tcpm-tcpsecure-10.txt Thread-Index: AcjhlfHU62R2P/2zQpyxAtM9tRKa6QDro4lg From: "Anantha Ramaiah (ananth)" To: X-OriginalArrivalTime: 14 Jul 2008 06:05:13.0610 (UTC) FILETIME=[948B86A0:01C8E577] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4672; t=1216015513; x=1216879513; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20=20[tcpm]=20I-D=20Action=3Adraft-ietf-tcpm-tcps ecure-10.txt |Sender:=20; bh=w4jmTSfaHYZgjSNgCo8JkdnfTYXI/6kYAwkjHKpW38A=; b=rN8w+mK1E94st+gTCDelnAgxYz8BNBZeoIrmksFVuRjF0IeF3P4xa7IwzS 423Jhpkzgmm0t+sUa7kahBUmvPZo56AngjotEHiPDuGJSESD1Y0BS0H2gcDK rNcWJGqs1/; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: David Borman Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcpsecure-10.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E577.946011EA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings, The new version of the tcpsecure (version 10) incorporates the following :- #1 - the last pending issue before WGLC viz., the strength of mitigations, where there was a "very thin consensus" for tagging the RST, SYN and Data mitigations as SHOULD/SHOULD/MAY respectively. (It was previously tagged as SHOULD/SHOULD/SHOULD). The document is modified accordingly. #2 - Andre Oppermann brought about some important errors in the document. They are :-=20 a) In the SYN mitigation (sec 4.2) there was a typo when quoting RFC 793 i.e. instead of saying [RCV.NXT =3D< SEG.SEQ < RCV.NXT+RCV.WND], it was misquoted as [RCV.NXT =3D< SEG.SEQ =3D< RCV.NXT+RCV.WND] b) In the Data mitigation section, the text was wrong. I.e. it previously said : Data that doesn't satisfy the new check MUST be discarded silently, it should have been "data that doesn't satisfy the new check MUST be discarded and an ACK sent (as per the RFC 793) The document is corrected accordingly. #3 - A reference to ICMP attacks document, which Fernando brought about. Ted Faber/Joe Touch suggested the text which I have incorporated in the security considerations. #4 - Alfred Hoenes editorial comments on version 9. I have added a section called "strength of mitigations". The rationale for adding this section is that, to clear up the reasoning, for tagging the mitigations strengths as S/S/M esp. after the "Applicability statement" is in place. Digging through the responses (textual and verbal) I don't see a strong technical reasoning for choosing the Data mitigation as MAY. I request the WG members who voted for MAY to speak up their technical reasoning. Pl remember that this reasoning is highly desirable since in future many people may ask the same question and hence it is prudent to come with a better technical explanation. Thanks, -Anantha -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, July 09, 2008 12:30 AM To: i-d-announce@ietf.org Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcpsecure-10.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Improving TCP's Robustness to Blind In-Window Attacks Author(s) : A. Ramaiah, et al. Filename : draft-ietf-tcpm-tcpsecure-10.txt Pages : 27 Date : 2008-07-09 TCP has historically been considered protected against spoofed off- path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32 bit sequence number(s). A combination of increasing window sizes and applications using longer term connections (e.g. H-323 or Border Gateway Protocol [RFC4271]) have left modern TCP implementations more vulnerable to these types of spoofed packet injection attacks. Many of these long term TCP applications tend to have predictable IP addresses and ports which makes it far easier for the 4-tuple to be guessed. Having guessed the 4-tuple correctly, an attacker can inject a RST, SYN or DATA segment into a TCP connection by systematically guessing the sequence number of the spoofed segment to be in the current receive window. This can cause the connection to either abort or possibly cause data corruption. This document specifies small modifications to the way TCP handles inbound segments that can reduce the chances of a successful attack. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C8E577.946011EA Content-Type: application/octet-stream; name="draft-ietf-tcpm-tcpsecure-10.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-tcpm-tcpsecure-10.URL Content-Disposition: attachment; filename="draft-ietf-tcpm-tcpsecure-10.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLXRjcG0tdGNwc2VjdXJlLTEwLnR4dA0K ------_=_NextPart_001_01C8E577.946011EA Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm ------_=_NextPart_001_01C8E577.946011EA-- From tcpm-bounces@ietf.org Mon Jul 14 05:14:02 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C9783A68FF; Mon, 14 Jul 2008 05:14:02 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02B323A6932 for ; Mon, 14 Jul 2008 05:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0A8MnctejcOG for ; Mon, 14 Jul 2008 05:14:00 -0700 (PDT) Received: from wall.ikr.uni-stuttgart.de (wall.ikr.uni-stuttgart.de [129.69.170.1]) by core3.amsl.com (Postfix) with ESMTP id 4377A3A683D for ; Mon, 14 Jul 2008 05:14:00 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by wall.ikr.uni-stuttgart.de (Postfix) with ESMTP id 280B156CDD for ; Mon, 14 Jul 2008 14:14:25 +0200 (CEST) Received: by netsrv1.ikr.uni-stuttgart.de (Postfix, from userid 539) id 2164BBC081; Mon, 14 Jul 2008 14:14:25 +0200 (CEST) Received: from ikr.uni-stuttgart.de (inode21 [10.21.18.11]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with SMTP id E52DFBC07E for ; Mon, 14 Jul 2008 14:14:24 +0200 (CEST) Received: by ikr.uni-stuttgart.de (sSMTP sendmail emulation); Mon, 14 Jul 2008 14:14:24 +0200 Date: Mon, 14 Jul 2008 14:14:24 +0200 From: Michael Scharf To: tcpm@ietf.org Message-ID: <20080714121424.GA31382@ikr.uni-stuttgart.de> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Subject: [tcpm] TCP Long Options - Why not as payload in SYNs? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hi all, I wonder whether "modern" TCP stacks indeed process application payload data in SYN segments. Even though RFC 793 explicitly allows payload in SYN segments, there are TCP stacks that just seem to ignore it. Couldn't this offer an opportunity to transport long TCP options in the payload of SYN segments, instead of expanding the header option space? Sorry if this question has already been answered elsewhere. Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 14 05:15:02 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ABFC3A69C7; Mon, 14 Jul 2008 05:15:02 -0700 (PDT) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 837033A69C7; Mon, 14 Jul 2008 05:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080714121501.837033A69C7@core3.amsl.com> Date: Mon, 14 Jul 2008 05:15:01 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-rfc4138bis-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP Author(s) : P. Sarolahti, et al. Filename : draft-ietf-tcpm-rfc4138bis-02.txt Pages : 21 Date : 2008-07-14 Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc4138bis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-rfc4138bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-14050700.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Mon Jul 14 06:48:22 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D71F73A69D8; Mon, 14 Jul 2008 06:48:22 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D08B3A69D8 for ; Mon, 14 Jul 2008 06:48: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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpZ4wRMphDUt for ; Mon, 14 Jul 2008 06:48:17 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id 9FEDF3A6903 for ; Mon, 14 Jul 2008 06:48:17 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so4277640rvf.49 for ; Mon, 14 Jul 2008 06:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=vxFkSGxxXzwomuOmhqnS2NNhlix26g02PIMryhfAgxA=; b=Tf0leIV704r5hgQrVaPOQjb0rzs7OPvgRheT1sV+yXslaXv4COt9FYXdi9BLUAAowc Em2UlR8Cx7S4uKkyU8EdA1dgAKY0jKUMHwiBnP0SN5mUqEC0eHtUWraYbv6fPLMgGH+v mxk0F7czz8y5km1FiXPjh1zbM/z4IPmH7tTCE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=jgBwO2GCt3cP91itjlwrmQg1/kLgJEGguKj86TgwPhqFovUx93urBzMI2gZTBLJn/u c+TkMUMETEUJarxZkhwv2+dfpgs+c+3qtQk5Br6w1lrGKIw+Ssl9gUH07TvMG+RpnxPF IZ20a7ElmY33Q0kt+zlsSQJSSE4RG5m52bsNM= Received: by 10.141.88.3 with SMTP id q3mr6627490rvl.46.1216043323275; Mon, 14 Jul 2008 06:48:43 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Mon, 14 Jul 2008 06:48:43 -0700 (PDT) Message-ID: <396556a20807140648lb5f923x478665473667d807@mail.gmail.com> Date: Mon, 14 Jul 2008 06:48:43 -0700 From: "Adam Langley" To: "Michael Scharf" In-Reply-To: <20080714121424.GA31382@ikr.uni-stuttgart.de> MIME-Version: 1.0 Content-Disposition: inline References: <20080714121424.GA31382@ikr.uni-stuttgart.de> X-Google-Sender-Auth: f200b8855f1ad763 Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Mon, Jul 14, 2008 at 5:14 AM, Michael Scharf wrote: > Even though RFC 793 explicitly allows payload in SYN segments, there > are TCP stacks that just seem to ignore it. Couldn't this offer an > opportunity to transport long TCP options in the payload of SYN > segments, instead of expanding the header option space? > > Sorry if this question has already been answered elsewhere. I don't have the necessary menagerie of operating systems needed to gather good data. But Linux's net/ipv4/tcp_input.c [1] says 5188 /* Now we have several options: In theory there is 5189 * nothing else in the frame. KA9Q has an option to 5190 * send data with the syn, BSD accepts data with the 5191 * syn up to the [to be] advertised window and 5192 * Solaris 2.1 gives you a protocol error. For now 5193 * we just ignore it, that fits the spec precisely 5194 * and avoids incompatibilities. It would be nice in 5195 * future to drop through and process the data. [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=net/ipv4/tcp_input.c;h=cad73b7dfef07798ddc0b8debba24c9aad94c53b;hb=HEAD And that suggests that it's not just those OSes which ignore SYNs with payloads - it's also those which reject the packet completely. Having to retransmit SYNs in such cases is sufficiently common, and sufficiently painful that I think it's a non-starter. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 14 08:02:49 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63D6A3A6AD5; Mon, 14 Jul 2008 08:02:49 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 363013A6856 for ; Mon, 14 Jul 2008 08:02:48 -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.596, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flbPBdNmfiTp for ; Mon, 14 Jul 2008 08:02:47 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 4CF033A6ADF for ; Mon, 14 Jul 2008 08:02:10 -0700 (PDT) Received: from [127.0.0.1] (pool-71-106-110-19.lsanca.dsl-w.verizon.net [71.106.110.19]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6EF2HP3008098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Jul 2008 08:02:20 -0700 (PDT) Message-ID: <487B6A79.2040608@isi.edu> Date: Mon, 14 Jul 2008 08:02:17 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 References: <20080714121424.GA31382@ikr.uni-stuttgart.de> <396556a20807140648lb5f923x478665473667d807@mail.gmail.com> In-Reply-To: <396556a20807140648lb5f923x478665473667d807@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: andre.zuquete@ua.pt, tcpm@ietf.org, =?ISO-8859-1?Q?S=E9rgio_Freire?= Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0104537561==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0104537561== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAC73C9F074B18D6AF1B357E1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAC73C9F074B18D6AF1B357E1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Adam Langley wrote: > On Mon, Jul 14, 2008 at 5:14 AM, Michael Scharf > wrote: >> Even though RFC 793 explicitly allows payload in SYN segments, there >> are TCP stacks that just seem to ignore it. Couldn't this offer an >> opportunity to transport long TCP options in the payload of SYN >> segments, instead of expanding the header option space? See Usenix 2008, "A TCP-layer Name Service for TCP Ports" http://www.usenix.org/events/usenix08/tech/full_papers/freire/freire_html= /index.html The authors, Sergio and Andre (cc'd), therein combine options in the SYN = payload with other mechanisms in a port-names solution. I have spoken=20 with them about cleanly separating the idea of data as payload option=20 space (i.e., removing other features that are distinct, e.g., use of=20 port 0, changing ports after the SYN, etc.), and basically we came up wit= h: set a conventional option that says where the payload option ends, within the SYN segment (typically the end of that segment) wait for an ACK indicating that option is set (could be set in advance), indicating the options will be processed correctly NB - the option is set in advance when a sender speaks the option but has no long options to send, or has long options to send and is doing so. EITHER WAY the option MUST occur, or the handshake will fail. if the ACK does not confirm the ability to process options in the data, then RST the connection and retry without data options Note that this works only for the SYN segment, and it isn't clear how it = might interoperate with SYN cookies. It also ALWAYS consumes option=20 space, and MUST occur in the existing options. =2E.. > And that suggests that it's not just those OSes which ignore SYNs with > payloads - it's also those which reject the packet completely. AFAICT, ACKing the SYN and not the data is compliant, but rejecting the=20 SYN entirely doesn't appear to be - it should be called a bug, IMO. Joe --------------enigAC73C9F074B18D6AF1B357E1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIe2p5E5f5cImnZrsRApASAJ4ip7x8qOCrUa6xM5fTAb/fRnChvwCgkZQV y9QWvz82eJrERjySqqwyoOk= =H8L+ -----END PGP SIGNATURE----- --------------enigAC73C9F074B18D6AF1B357E1-- --===============0104537561== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0104537561==-- From tcpm-bounces@ietf.org Mon Jul 14 08:03:02 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C24A83A6B15; Mon, 14 Jul 2008 08:03:02 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D521F3A6ACE for ; Mon, 14 Jul 2008 08:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCjK48jDcNDT for ; Mon, 14 Jul 2008 08:03:01 -0700 (PDT) Received: from wall.ikr.uni-stuttgart.de (wall.ikr.uni-stuttgart.de [129.69.170.1]) by core3.amsl.com (Postfix) with ESMTP id D651E3A68DD for ; Mon, 14 Jul 2008 08:02:43 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by wall.ikr.uni-stuttgart.de (Postfix) with ESMTP id 6743756CDF; Mon, 14 Jul 2008 17:03:09 +0200 (CEST) Received: by netsrv1.ikr.uni-stuttgart.de (Postfix, from userid 539) id 4940DBC081; Mon, 14 Jul 2008 17:03:09 +0200 (CEST) Received: from ikr.uni-stuttgart.de (inode21 [10.21.18.11]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with SMTP id 09531BC07E; Mon, 14 Jul 2008 17:03:09 +0200 (CEST) Received: by ikr.uni-stuttgart.de (sSMTP sendmail emulation); Mon, 14 Jul 2008 17:03:09 +0200 Date: Mon, 14 Jul 2008 17:03:08 +0200 From: Michael Scharf To: Adam Langley Message-ID: <20080714150308.GA4866@ikr.uni-stuttgart.de> References: <20080714121424.GA31382@ikr.uni-stuttgart.de> <396556a20807140648lb5f923x478665473667d807@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <396556a20807140648lb5f923x478665473667d807@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Mon, 14 Jul 2008 at 06:48:43, Adam Langley wrote: > > Even though RFC 793 explicitly allows payload in SYN segments, there > > are TCP stacks that just seem to ignore it. Couldn't this offer an > > opportunity to transport long TCP options in the payload of SYN > > segments, instead of expanding the header option space? > > I don't have the necessary menagerie of operating systems needed to > gather good data. But Linux's net/ipv4/tcp_input.c [1] says > > 5188 /* Now we have several options: In theory there is > 5189 * nothing else in the frame. KA9Q has an option to > 5190 * send data with the syn, BSD accepts > data with the > 5191 * syn up to the [to be] advertised window and > 5192 * Solaris 2.1 gives you a protocol error. For now > 5193 * we just ignore it, that fits the spec precisely > 5194 * and avoids incompatibilities. It would > be nice in > 5195 * future to drop through and process the data. > > [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=net/ipv4/tcp_input.c;h=cad73b7dfef07798ddc0b8debba24c9aad94c53b;hb=HEAD > > And that suggests that it's not just those OSes which ignore SYNs with > payloads - it's also those which reject the packet completely. Having > to retransmit SYNs in such cases is sufficiently common, and > sufficiently painful that I think it's a non-starter. This comment is probably over 10 years old (Linux kernel version 2.0.3x or earlier). This is why I asked for the behavior of "modern" stacks (and, of course, "modern" middlebox implementations). Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 14 08:20:29 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26C593A6903; Mon, 14 Jul 2008 08:20:29 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 193953A6B4E for ; Mon, 14 Jul 2008 08:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fguBkoRWlZXf for ; Mon, 14 Jul 2008 08:20:27 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id A22003A6BF8 for ; Mon, 14 Jul 2008 08:20:13 -0700 (PDT) Received: from [127.0.0.1] (pool-71-106-110-19.lsanca.dsl-w.verizon.net [71.106.110.19]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6EFKHAi013932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Jul 2008 08:20:19 -0700 (PDT) Message-ID: <487B6EB1.6040308@isi.edu> Date: Mon, 14 Jul 2008 08:20:17 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Joe Touch References: <20080714121424.GA31382@ikr.uni-stuttgart.de> <396556a20807140648lb5f923x478665473667d807@mail.gmail.com> <487B6A79.2040608@isi.edu> In-Reply-To: <487B6A79.2040608@isi.edu> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: andre.zuquete@ua.pt, tcpm@ietf.org, =?ISO-8859-1?Q?S=E9rgio_Freire?= Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0877439267==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0877439267== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF4918E4970A8EC8CD720B5D8" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF4918E4970A8EC8CD720B5D8 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable PS - if there's interest in this, we could pull together an I-D in time=20 for Dublin, but it won't (didn't) make the individual deadline... Joe Joe Touch wrote: > Adam Langley wrote: >> On Mon, Jul 14, 2008 at 5:14 AM, Michael Scharf >> wrote: >>> Even though RFC 793 explicitly allows payload in SYN segments, there >>> are TCP stacks that just seem to ignore it. Couldn't this offer an >>> opportunity to transport long TCP options in the payload of SYN >>> segments, instead of expanding the header option space? >=20 > See Usenix 2008, "A TCP-layer Name Service for TCP Ports" > http://www.usenix.org/events/usenix08/tech/full_papers/freire/freire_ht= ml/index.html=20 >=20 >=20 > The authors, Sergio and Andre (cc'd), therein combine options in the SY= N=20 > payload with other mechanisms in a port-names solution. I have spoken=20 > with them about cleanly separating the idea of data as payload option=20 > space (i.e., removing other features that are distinct, e.g., use of=20 > port 0, changing ports after the SYN, etc.), and basically we came up w= ith: >=20 > set a conventional option that says where the > payload option ends, within the SYN segment > (typically the end of that segment) >=20 > wait for an ACK indicating that option is set > (could be set in advance), indicating the > options will be processed correctly > NB - the option is set in advance when > a sender speaks the option but has no > long options to send, or has long options > to send and is doing so. EITHER WAY > the option MUST occur, or the handshake > will fail. >=20 > if the ACK does not confirm the ability to > process options in the data, then RST the > connection and retry without data options >=20 > Note that this works only for the SYN segment, and it isn't clear how i= t=20 > might interoperate with SYN cookies. It also ALWAYS consumes option=20 > space, and MUST occur in the existing options. >=20 > ... >> And that suggests that it's not just those OSes which ignore SYNs with= >> payloads - it's also those which reject the packet completely. >=20 > AFAICT, ACKing the SYN and not the data is compliant, but rejecting the= =20 > SYN entirely doesn't appear to be - it should be called a bug, IMO. >=20 > Joe >=20 --------------enigF4918E4970A8EC8CD720B5D8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIe26xE5f5cImnZrsRAoScAKDiboFbtS3UjcGGQFb4eVFkBLszzACguEU2 g09qOHgofiR93aQCtqMyNNY= =nqX8 -----END PGP SIGNATURE----- --------------enigF4918E4970A8EC8CD720B5D8-- --===============0877439267== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0877439267==-- From tcpm-bounces@ietf.org Mon Jul 14 09:15:40 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8CB13A6B24; Mon, 14 Jul 2008 09:15:40 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C76FA28C155 for ; Mon, 14 Jul 2008 09:15:39 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Yfj0ocOdMLY for ; Mon, 14 Jul 2008 09:15:39 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id DA5313A6B54 for ; Mon, 14 Jul 2008 09:15:38 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so4323449rvf.49 for ; Mon, 14 Jul 2008 09:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=KAFERiCT1SQfAzLjmIyKY9HfmQTiW+Cm3dZLT0HJABw=; b=AJjrAZvcIctcL8HpiPntUrYJCqDNSfYo4BnDYEFqJCn4gbUun9wJB4LZWUedjEyM9g G1UjTjmOLI3362wngsm5YGXNclVPeDKrgVW1SozGGFn9rJDBF4kS90axLEDn9iC2CZhJ vl3jio+7O+llNZb33wEo1OS1PTlyiJpjv1bGo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=nldas/r6+o9RC1EJ+gfsJnS/EUBtN4YlXcjpSEjV9zbMhqe21LzTNQOT+cqRfqhktd Xkl3T875h4YsEtC48Y6arlamDOb1sj1RKF+JcYrisc5KtA7v60ZhAc8b8Sc5vwvCW/p4 sD2NFjZtTgQ4O3IO+hFKVtmCY3pHkTubxMNNM= Received: by 10.141.78.14 with SMTP id f14mr6705975rvl.119.1216052164653; Mon, 14 Jul 2008 09:16:04 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Mon, 14 Jul 2008 09:16:04 -0700 (PDT) Message-ID: <396556a20807140916h63312209m5c4a21f5c3c272a7@mail.gmail.com> Date: Mon, 14 Jul 2008 09:16:04 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <487B6A79.2040608@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <20080714121424.GA31382@ikr.uni-stuttgart.de> <396556a20807140648lb5f923x478665473667d807@mail.gmail.com> <487B6A79.2040608@isi.edu> X-Google-Sender-Auth: 5214dfdd22eae872 Cc: andre.zuquete@ua.pt, tcpm@ietf.org, =?UTF-8?Q?S=C3=A9rgio_Freire?= Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Mon, Jul 14, 2008 at 8:02 AM, Joe Touch wrote: > AFAICT, ACKing the SYN and not the data is compliant, but rejecting the SYN > entirely doesn't appear to be - it should be called a bug, IMO. Sorry, that was written too early in the morning. The problematic cases, of course, are where the host ignores a SYN with a payload, and where it accepts such data as application level data. A host which ACKed the SYN and ignored the payload provides for easy backwards compatibility. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 14 10:25:01 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B551328C266; Mon, 14 Jul 2008 10:25:01 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 359ED28C266 for ; Mon, 14 Jul 2008 10:25:00 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDVkv-dL1HoP for ; Mon, 14 Jul 2008 10:24:59 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 72C3428C262 for ; Mon, 14 Jul 2008 10:24:59 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 8424A3281DF for ; Mon, 14 Jul 2008 12:25:24 -0500 (CDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsppt03.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id m6EHPOFp021394 for ; Mon, 14 Jul 2008 12:25:24 -0500 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 12:25:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 12:25:38 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft agenda for Dublin Thread-Index: Acjl1qH9g+yT9o7pTWKQCdhIZFREYw== From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: X-OriginalArrivalTime: 14 Jul 2008 17:25:24.0515 (UTC) FILETIME=[99BD6F30:01C8E5D6] Subject: [tcpm] draft agenda for Dublin X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On the 16th, draft working group agendas are due to be submitted. So far, there have been few requests for TCPM agenda slots. We have a two hour timeslot, and I think there is a lot of room left in that, at the moment, so keep the requests coming! Here's what I've received at this point: "TCPM Status" - Wesley Eddy - 10 minutes Active WG Item Presentations: "TCP-AO Update" - Joe Touch - 15+ minutes Other Proposals and Presentations: "Clarification of RFC 1122 language on ZWP" - Anantha Ramaiah / Mahesh Jethanandani - 15+ minutes _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 14 12:45:43 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5936B3A6BF4; Mon, 14 Jul 2008 12:45:41 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339143A6B06 for ; Mon, 14 Jul 2008 12:45:09 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKlJAEXvxaJH for ; Mon, 14 Jul 2008 12:45:01 -0700 (PDT) Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by core3.amsl.com (Postfix) with ESMTP id 2F4EF3A67A4 for ; Mon, 14 Jul 2008 12:45:00 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 15:45:27 -0400 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7703E66F37@nekter> In-Reply-To: <20080714121424.GA31382@ikr.uni-stuttgart.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCP Long Options - Why not as payload in SYNs? Thread-Index: AcjlqzMv4BdTSCxPTgm4HBfpZCNwWgAPpYIg References: <20080714121424.GA31382@ikr.uni-stuttgart.de> From: "Caitlin Bestler" To: "Michael Scharf" , Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Michael Scharf > Sent: Monday, July 14, 2008 5:14 AM > To: tcpm@ietf.org > Subject: [tcpm] TCP Long Options - Why not as payload in SYNs? > > Hi all, > > I wonder whether "modern" TCP stacks indeed process application > payload data in SYN segments. > > Even though RFC 793 explicitly allows payload in SYN segments, there > are TCP stacks that just seem to ignore it. Couldn't this offer an > opportunity to transport long TCP options in the payload of SYN > segments, instead of expanding the header option space? > > Sorry if this question has already been answered elsewhere. > > Michael Any stack that uses SYN Cookies, or wants the option to, will reject any SYN that has payload. If a stack were to decide to accept SYNs with Payload as part of an optional enhancement then it would need a new method of defending from SYN floods. Generally, any stack that obligates itself to retain state in its memory on the basis of a single received SYN is a sitting duck for a Denial of Service attack. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 14 13:07:24 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FD0F3A6C5F; Mon, 14 Jul 2008 13:00:07 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F33093A6C51 for ; Mon, 14 Jul 2008 13:00:05 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOyHiwg-3A0y for ; Mon, 14 Jul 2008 13:00:05 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 2217728C291 for ; Mon, 14 Jul 2008 12:58:02 -0700 (PDT) Received: from [127.0.0.1] (228.sub-75-214-74.myvzw.com [75.214.74.228]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6EJw8T5011959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Jul 2008 12:58:11 -0700 (PDT) Message-ID: <487BAFCF.3020402@isi.edu> Date: Mon, 14 Jul 2008 12:58:07 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Caitlin Bestler References: <20080714121424.GA31382@ikr.uni-stuttgart.de> <78C9135A3D2ECE4B8162EBDCE82CAD7703E66F37@nekter> In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7703E66F37@nekter> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0730687308==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0730687308== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1ADBEA3793AC05775EE5C926" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1ADBEA3793AC05775EE5C926 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Caitlin Bestler wrote: =2E.. > Any stack that uses SYN Cookies, or wants the option to, will reject > any SYN that has payload. Why couldn't it ACK the SYN but not the data, and compute the cookie=20 based on the header only (as with an 'empty' SYN?) As I noted before, rejecting a SYN just because it has data seems out of = spec. Joe --------------enig1ADBEA3793AC05775EE5C926 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIe6/PE5f5cImnZrsRAoqUAKDxGuBlGWi04+FBsLi85Rr03sec8ACg41ke F07d9VtAGx13oLjWBX0PUMM= =Ug9Z -----END PGP SIGNATURE----- --------------enig1ADBEA3793AC05775EE5C926-- --===============0730687308== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0730687308==-- From tcpm-bounces@ietf.org Mon Jul 14 14:15:18 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5A7D28C1FF; Mon, 14 Jul 2008 14:03:52 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5A473A6B0C for ; Mon, 14 Jul 2008 14:03:51 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIrov2PB0kC4 for ; Mon, 14 Jul 2008 14:03:51 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id EC4743A6C78 for ; Mon, 14 Jul 2008 14:03:42 -0700 (PDT) Received: from [127.0.0.1] (228.sub-75-214-74.myvzw.com [75.214.74.228]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6EL3Pxi002196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Jul 2008 14:03:29 -0700 (PDT) Message-ID: <487BBF1C.7000101@isi.edu> Date: Mon, 14 Jul 2008 14:03:24 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Joe Touch References: <20080714121424.GA31382@ikr.uni-stuttgart.de> <78C9135A3D2ECE4B8162EBDCE82CAD7703E66F37@nekter> <487BAFCF.3020402@isi.edu> In-Reply-To: <487BAFCF.3020402@isi.edu> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Caitlin Bestler Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0722515407==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0722515407== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig644D235A3CF7D48064EED9F3" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig644D235A3CF7D48064EED9F3 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, all, Sorry if my response below was cryptic. Let me clarify... Joe Touch wrote: >=20 >=20 > Caitlin Bestler wrote: > ... >> Any stack that uses SYN Cookies, or wants the option to, will reject >> any SYN that has payload. >=20 > Why couldn't it ACK the SYN but not the data, and compute the cookie=20 > based on the header only (as with an 'empty' SYN?) Note that this is a valid response only where the data is NOT=20 interpreted as extended option space. AFAICT, SYN cookies are incompatible with long options, and yes,=20 rejecting them is the appropriate response if cookies are required for=20 all connections. Joe --------------enig644D235A3CF7D48064EED9F3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIe78cE5f5cImnZrsRArOkAKDEcn5LxFrggyaioN5gLnDjYPd/FACeMFgy g9/O++ST9bBpemtMNk/3CkU= =3AaL -----END PGP SIGNATURE----- --------------enig644D235A3CF7D48064EED9F3-- --===============0722515407== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0722515407==-- From tcpm-bounces@ietf.org Mon Jul 14 14:57:59 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43DD828C243; Mon, 14 Jul 2008 14:57:59 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 430BB28C243 for ; Mon, 14 Jul 2008 14:57:58 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GgXG4vhWxvP for ; Mon, 14 Jul 2008 14:57:57 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 75AF828C147 for ; Mon, 14 Jul 2008 14:57:57 -0700 (PDT) Received: from [127.0.0.1] (228.sub-75-214-74.myvzw.com [75.214.74.228]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6ELvX9w016938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Jul 2008 14:57:39 -0700 (PDT) Message-ID: <487BCBCD.7030103@isi.edu> Date: Mon, 14 Jul 2008 14:57:33 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Joe Touch References: <20080714121424.GA31382@ikr.uni-stuttgart.de> <78C9135A3D2ECE4B8162EBDCE82CAD7703E66F37@nekter> <487BAFCF.3020402@isi.edu> <487BBF1C.7000101@isi.edu> In-Reply-To: <487BBF1C.7000101@isi.edu> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Caitlin Bestler Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1425733043==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1425733043== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig00A0B40DF93E7FFA84E8E6DC" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig00A0B40DF93E7FFA84E8E6DC Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Joe Touch wrote: > Hi, all, =2E.. > AFAICT, SYN cookies are incompatible with long options, and yes,=20 > rejecting them is the appropriate response if cookies are required for = > all connections. PS - one conclusion that we could draw here is that: - we can show that there are NO versions of extending TCP options that=20 are truly backward compatible i.e., that use a single SYN - we can also show that there are NO versions of extending TCP options=20 that are compatible with SYN cookies as long as the ISN is the same length, there's only so much place for state Overall, that may imply that we cannot extend the TCP option space in a=20 backward compatible way, at which point maybe we're back to Mark=20 Allman's "let's double all the fields" proposal, i.e., a 'clean slate'=20 TCPv2... Joe --------------enig00A0B40DF93E7FFA84E8E6DC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIe8vNE5f5cImnZrsRAqRXAJ4qbftpMlIFTI2I4+1w+D1VAT4MYwCfanN0 P3VlnOsSl30KMAD467cMJkc= =/Ibb -----END PGP SIGNATURE----- --------------enig00A0B40DF93E7FFA84E8E6DC-- --===============1425733043== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1425733043==-- From tcpm-bounces@ietf.org Mon Jul 14 14:59:42 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A92128C347; Mon, 14 Jul 2008 14:59:42 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17C1B28C347 for ; Mon, 14 Jul 2008 14:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqrwlrfW8dcL for ; Mon, 14 Jul 2008 14:59:40 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 478593A6842 for ; Mon, 14 Jul 2008 14:59:40 -0700 (PDT) Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.54.46.187) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.251.2; Mon, 14 Jul 2008 15:00:06 -0700 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.18.32) by tk1-exhub-c103.redmond.corp.microsoft.com (157.54.46.187) with Microsoft SMTP Server id 8.1.240.5; Mon, 14 Jul 2008 15:00:06 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.32]) with mapi; Mon, 14 Jul 2008 14:59:04 -0700 From: Christian Huitema To: Joe Touch Date: Mon, 14 Jul 2008 15:00:04 -0700 Thread-Topic: [tcpm] TCP Long Options - Why not as payload in SYNs? Thread-Index: Acjl+F9KFGgwUjqSTqezIAyjfCp2WQAA5lfQ Message-ID: <8EFB68EAE061884A8517F2A755E8B60A0AA17C60F8@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <20080714121424.GA31382@ikr.uni-stuttgart.de> <78C9135A3D2ECE4B8162EBDCE82CAD7703E66F37@nekter> <487BAFCF.3020402@isi.edu> <487BBF1C.7000101@isi.edu> In-Reply-To: <487BBF1C.7000101@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "tcpm@ietf.org" , Caitlin Bestler Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > >> Any stack that uses SYN Cookies, or wants the option to, will reject > >> any SYN that has payload. > > > > Why couldn't it ACK the SYN but not the data, and compute the cookie > > based on the header only (as with an 'empty' SYN?) > > Note that this is a valid response only where the data is NOT > interpreted as extended option space. > > AFAICT, SYN cookies are incompatible with long options, and yes, > rejecting them is the appropriate response if cookies are required for > all connections. Also, SYN cookies are only one specific defense against SYN flooding attacks. They are a good defense if the main worry is the memory consumed by connection state. They have however two drawbacks: they do nothing about "back flood", i.e. saturating the output NIC and link with SYN-ACK; and they diminish the robustness of the connection set-up for all applications where the first message comes from the server. When experimenting with these attacks, I found that we can achieve a good defense with a combination of "short" state information in memory for the "half open" connections, and rate limiting of the number of SYN that a system is willing to process. Cookies would not help much, if at all. -- Christian Huitema _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 14 15:45:36 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36CE728C314; Mon, 14 Jul 2008 15:45:36 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B68CF28C127 for ; Mon, 14 Jul 2008 15:45:34 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-Bc1l0tUzcw for ; Mon, 14 Jul 2008 15:45:33 -0700 (PDT) Received: from cgpmail.ua.pt (frontend-2.servers.ua.pt [193.136.173.3]) by core3.amsl.com (Postfix) with ESMTP id 044353A6B0B for ; Mon, 14 Jul 2008 15:45:31 -0700 (PDT) Received: from [85.241.154.174] (account etfreire@ua.pt HELO portsfreire) by frontend-2.cgpmail.ua.pt (CommuniGate Pro SMTP 5.1.13) with ESMTPSA id 151993370; Mon, 14 Jul 2008 23:45:53 +0100 From: "Sergio Freire" To: "'Joe Touch'" References: <20080714121424.GA31382@ikr.uni-stuttgart.de> <396556a20807140648lb5f923x478665473667d807@mail.gmail.com> <487B6A79.2040608@isi.edu> <487B6EB1.6040308@isi.edu> In-Reply-To: Date: Mon, 14 Jul 2008 23:45:50 +0100 Message-ID: <003c01c8e603$5db60740$192215c0$@pt> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjlxXUzdE6E+wMmQZCQzvcUsc3D1wAPWbbAAAAamsA= Content-Language: pt Cc: andre.zuquete@ua.pt, tcpm@ietf.org Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hi Joe et all, Yes, I think it would be a great idea to write an I-D concerning the use of TCP options in the payload.. what is the deadline? Sergio -----Original Message----- From: Joe Touch [mailto:touch@ISI.EDU] = Sent: segunda-feira, 14 de Julho de 2008 16:20 To: Joe Touch Cc: andre.zuquete@ua.pt; tcpm@ietf.org; S=E9rgio Freire Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs? PS - if there's interest in this, we could pull together an I-D in time for Dublin, but it won't (didn't) make the individual deadline... Joe Joe Touch wrote: > Adam Langley wrote: >> On Mon, Jul 14, 2008 at 5:14 AM, Michael Scharf = >> wrote: >>> Even though RFC 793 explicitly allows payload in SYN segments, there = >>> are TCP stacks that just seem to ignore it. Couldn't this offer an = >>> opportunity to transport long TCP options in the payload of SYN = >>> segments, instead of expanding the header option space? > = > See Usenix 2008, "A TCP-layer Name Service for TCP Ports" > http://www.usenix.org/events/usenix08/tech/full_papers/freire/freire_h > tml/index.html > = > = > The authors, Sergio and Andre (cc'd), therein combine options in the = > SYN payload with other mechanisms in a port-names solution. I have = > spoken with them about cleanly separating the idea of data as payload = > option space (i.e., removing other features that are distinct, e.g., = > use of port 0, changing ports after the SYN, etc.), and basically we came up with: > = > set a conventional option that says where the > payload option ends, within the SYN segment > (typically the end of that segment) > = > wait for an ACK indicating that option is set > (could be set in advance), indicating the > options will be processed correctly > NB - the option is set in advance when > a sender speaks the option but has no > long options to send, or has long options > to send and is doing so. EITHER WAY > the option MUST occur, or the handshake > will fail. > = > if the ACK does not confirm the ability to > process options in the data, then RST the > connection and retry without data options > = > Note that this works only for the SYN segment, and it isn't clear how = > it might interoperate with SYN cookies. It also ALWAYS consumes option = > space, and MUST occur in the existing options. > = > ... >> And that suggests that it's not just those OSes which ignore SYNs = >> with payloads - it's also those which reject the packet completely. > = > AFAICT, ACKing the SYN and not the data is compliant, but rejecting = > the SYN entirely doesn't appear to be - it should be called a bug, IMO. > = > Joe > = _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 14 15:54:14 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A26243A6A31; Mon, 14 Jul 2008 15:54:14 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 689BD3A6B0B for ; Mon, 14 Jul 2008 15:54:14 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdsArnQKSYPj for ; Mon, 14 Jul 2008 15:54:13 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 9F6E63A68E3 for ; Mon, 14 Jul 2008 15:54:13 -0700 (PDT) Received: from [127.0.0.1] (228.sub-75-214-74.myvzw.com [75.214.74.228]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6EMlj6A000606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Jul 2008 15:47:48 -0700 (PDT) Message-ID: <487BD791.4020203@isi.edu> Date: Mon, 14 Jul 2008 15:47:45 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=E9rgio_Freire?= References: <20080714121424.GA31382@ikr.uni-stuttgart.de> <396556a20807140648lb5f923x478665473667d807@mail.gmail.com> <487B6A79.2040608@isi.edu> <487B6EB1.6040308@isi.edu> <711EBBFA1DE9C64FB3CF8053A261C6FC05199B25@INOAVREX05.ptin.corpPT.com> In-Reply-To: <711EBBFA1DE9C64FB3CF8053A261C6FC05199B25@INOAVREX05.ptin.corpPT.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: andre.zuquete@ua.pt, tcpm@ietf.org Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0366703310==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0366703310== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1B2523492885B0E0ECE2DFB7" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1B2523492885B0E0ECE2DFB7 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable The deadline was last week for new individual submissions, but if useful = we could just issue it when it's done anyway. The question is whether the WG has interest... otherwise, we could wait=20 until after the IETF ;-) Joe S=E9rgio Freire wrote: > Hi Joe et all, > Yes, I think it would be a great idea to write an I-D concerning the us= e of TCP options in the payload.. what is the deadline? > Sergio >=20 >=20 > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU]=20 > Sent: segunda-feira, 14 de Julho de 2008 16:20 > To: Joe Touch > Cc: andre.zuquete@ua.pt; tcpm@ietf.org; S=E9rgio Freire > Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs? >=20 > PS - if there's interest in this, we could pull together an I-D in time= for Dublin, but it won't (didn't) make the individual deadline... >=20 > Joe >=20 > Joe Touch wrote: >> Adam Langley wrote: >>> On Mon, Jul 14, 2008 at 5:14 AM, Michael Scharf=20 >>> wrote: >>>> Even though RFC 793 explicitly allows payload in SYN segments, there= =20 >>>> are TCP stacks that just seem to ignore it. Couldn't this offer an=20 >>>> opportunity to transport long TCP options in the payload of SYN=20 >>>> segments, instead of expanding the header option space? >> See Usenix 2008, "A TCP-layer Name Service for TCP Ports" >> http://www.usenix.org/events/usenix08/tech/full_papers/freire/freire_h= >> tml/index.html >> >> >> The authors, Sergio and Andre (cc'd), therein combine options in the=20 >> SYN payload with other mechanisms in a port-names solution. I have=20 >> spoken with them about cleanly separating the idea of data as payload = >> option space (i.e., removing other features that are distinct, e.g.,=20 >> use of port 0, changing ports after the SYN, etc.), and basically we c= ame up with: >> >> set a conventional option that says where the >> payload option ends, within the SYN segment >> (typically the end of that segment) >> >> wait for an ACK indicating that option is set >> (could be set in advance), indicating the >> options will be processed correctly >> NB - the option is set in advance when >> a sender speaks the option but has no >> long options to send, or has long options >> to send and is doing so. EITHER WAY >> the option MUST occur, or the handshake >> will fail. >> >> if the ACK does not confirm the ability to >> process options in the data, then RST the >> connection and retry without data options >> >> Note that this works only for the SYN segment, and it isn't clear how = >> it might interoperate with SYN cookies. It also ALWAYS consumes option= =20 >> space, and MUST occur in the existing options. >> >> ... >>> And that suggests that it's not just those OSes which ignore SYNs=20 >>> with payloads - it's also those which reject the packet completely. >> AFAICT, ACKing the SYN and not the data is compliant, but rejecting=20 >> the SYN entirely doesn't appear to be - it should be called a bug, IMO= =2E >> >> Joe >> >=20 --------------enig1B2523492885B0E0ECE2DFB7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIe9eRE5f5cImnZrsRAr6AAKDKGD5JMeyzK5eOzCyJ1GV0mWwEvQCeOsmd eqcVhUnTn9Wx2YCiQiwBCbA= =/Ll4 -----END PGP SIGNATURE----- --------------enig1B2523492885B0E0ECE2DFB7-- --===============0366703310== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0366703310==-- From tcpm-bounces@ietf.org Mon Jul 14 16:42:04 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 531E93A677E; Mon, 14 Jul 2008 16:42:04 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67B043A68A0 for ; Mon, 14 Jul 2008 16:42:02 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YU0AhSRBmrto for ; Mon, 14 Jul 2008 16:42:01 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id 6E3883A6767 for ; Mon, 14 Jul 2008 16:42:01 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so4440049rvf.49 for ; Mon, 14 Jul 2008 16:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=NuZJrZLKaqVNGMKup3fBKP3vD1Na6D00v/mAJRlVJzI=; b=dutSEkiwUhBZ1PUpdkkXfP2y56XCLqYXbqObHWFKSNXwL8pCQ0lOo8o7iOJA4RlckS 7Wss767NkUaWj0jkzkGDm5nHGKzv5JBreJspKS5stPlXMED9swOyA/Mg0nq6nTONv814 h4L/MNr4GaY/Oj4pSz78IyenejgeIaoC7ZcaM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=o2DgJ9+sHuH3fBZvc/vQFMey5LB8iDvdTIWTFKAVmQL0qKGv26UsltvjrS6H5ILjOj J0qDS+EbMDI9hj/Is3mImDyJWqb9/XRC4EXiBovd7vBB32e4I5WjjUohs9i5zP+bLQWb 4c9DYKApB4tTP2Et7fNByoIEWLOW3Rfp8/FgY= Received: by 10.141.63.9 with SMTP id q9mr6948979rvk.47.1216078945900; Mon, 14 Jul 2008 16:42:25 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Mon, 14 Jul 2008 16:42:25 -0700 (PDT) Message-ID: <396556a20807141642g4cb384e8v1a9065996908d30a@mail.gmail.com> Date: Mon, 14 Jul 2008 16:42:25 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <487BCBCD.7030103@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <20080714121424.GA31382@ikr.uni-stuttgart.de> <78C9135A3D2ECE4B8162EBDCE82CAD7703E66F37@nekter> <487BAFCF.3020402@isi.edu> <487BBF1C.7000101@isi.edu> <487BCBCD.7030103@isi.edu> X-Google-Sender-Auth: 16ca312aae3fa8ef Cc: tcpm@ietf.org, Caitlin Bestler Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Mon, Jul 14, 2008 at 2:57 PM, Joe Touch wrote: > - we can show that there are NO versions of extending TCP options that are > truly backward compatible > i.e., that use a single SYN I believe that's true if you're talking about extending the options in a SYN packet. > - we can also show that there are NO versions of extending TCP options that > are compatible with SYN cookies > as long as the ISN is the same length, there's only so much > place for state Well, it's reasonable for stacks to disable certain features when using SYN cookies. Until very recently, I believe that Linux would forget about SACK permitted options in the SYN when cookies were in use. It got around that by using the TCP timestamp as extra cookie space. (I'm informed that BSD uses the same timestamp/cookie trick.) If SYN cookies are only enabled when some attack heuristic is met, that's a reasonable thing to do. Extensions which involve SYN options thus need to cope with the case where they are ignored by a host under attack. (I've a draft, that I'll probably post tomorrow, that does exactly that.) AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 14 16:45:39 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CD4328C2C4; Mon, 14 Jul 2008 16:45:31 -0700 (PDT) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AC4793A69F4; Mon, 14 Jul 2008 16:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080714234502.AC4793A69F4@core3.amsl.com> Date: Mon, 14 Jul 2008 16:45:02 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : The TCP Authentication Option Author(s) : J. Touch, et al. Filename : draft-ietf-tcpm-tcp-auth-opt-01.txt Pages : 30 Date : 2008-07-14 This document specifies a TCP Authentication Option (TCP-AO) which is intended to replace the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs) and provides more details on the association of security associations with TCP connections. TCP-AO assumes an external, out- of-band mechanism (manual or via a separate protocol) for session key establishment, parameter negotiation, and rekeying, replicating the separation of key management and key use as in the IPsec suite. The result is intended to be a simple modification to support current infrastructure uses of TCP MD5, such as to protect BGP and LDP, and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a new option identifier, even though it is intended to be mutually exclusive with TCP MD5 on a given TCP connection. It supports IPv6, and is fully compatible with requirements under development for an update to TCP MD5. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-auth-opt-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-14163525.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Mon Jul 14 17:35:00 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18FDF3A694D; Mon, 14 Jul 2008 17:35:00 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 170953A68EC for ; Mon, 14 Jul 2008 17:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imGnhBm6wgIt for ; Mon, 14 Jul 2008 17:34:56 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id A1C503A6845 for ; Mon, 14 Jul 2008 17:34:56 -0700 (PDT) Received: from [127.0.0.1] (pool-71-106-110-19.lsanca.dsl-w.verizon.net [71.106.110.19]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6F0ZBjR028421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Jul 2008 17:35:13 -0700 (PDT) Message-ID: <487BF0BE.1020605@isi.edu> Date: Mon, 14 Jul 2008 17:35:10 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Adam Langley References: <20080714121424.GA31382@ikr.uni-stuttgart.de> <78C9135A3D2ECE4B8162EBDCE82CAD7703E66F37@nekter> <487BAFCF.3020402@isi.edu> <487BBF1C.7000101@isi.edu> <487BCBCD.7030103@isi.edu> <396556a20807141642g4cb384e8v1a9065996908d30a@mail.gmail.com> In-Reply-To: <396556a20807141642g4cb384e8v1a9065996908d30a@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Caitlin Bestler Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0974671938==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0974671938== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6151EB4C50BB45B2FB629532" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6151EB4C50BB45B2FB629532 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Adam Langley wrote: =2E.. > Extensions which involve SYN options thus need to cope with the case > where they are ignored by a host under attack. (I've a draft, that > I'll probably post tomorrow, that does exactly that.) I don't think that's tenable. SYNs are where the presence of all=20 capabilities are negotiated. TCP has no semantics for turning=20 capabilities on after a connection is negotiated. If you ignore options in the SYN, you're saying "I can't do that=20 capability for the entirety of this connection". For options that are=20 optional (i.e., that are disabled if not ACKd), that works fine, but=20 then disables the feature for the rest of the connection. For options that initiators want to require (e.g., TCP-AO, for one), if=20 you ignore the option in the SYN-ACK, or forget that it was negotiated,=20 the option will not work and the connection will be dropped. That says you've hit a case where SYN cookies don't support TCP, not=20 where your options aren't supported by SYN cookies, IMO. Joe --------------enig6151EB4C50BB45B2FB629532 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIe/C/E5f5cImnZrsRAsgTAKDPaRxdZTSrLV9DTHPxzHiIOxZc3QCfeVjC itc8MiftRGY3mnGlIEu5i1s= =qdGo -----END PGP SIGNATURE----- --------------enig6151EB4C50BB45B2FB629532-- --===============0974671938== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0974671938==-- From tcpm-bounces@ietf.org Mon Jul 14 19:04:34 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19F633A68A0; Mon, 14 Jul 2008 19:04:34 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E55AA3A68A0 for ; Mon, 14 Jul 2008 19:04:32 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmoRxz771Kyy for ; Mon, 14 Jul 2008 19:04:31 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id D2C313A67EC for ; Mon, 14 Jul 2008 19:04:31 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so4473433rvf.49 for ; Mon, 14 Jul 2008 19:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=3eUQK3XAbfmo9ZPp5bYzfpq1gfqSFfR+wnYG+ts3kF4=; b=Z8BXYrnDFAH+BDYiJXc+fFdYULkeEG9UrEoeRdRnQa3HwnuCzDNIZk5iEF+YSaGUSa pzhIMxqDpvIN+86QR2BQWXudF0QlloJ2YutUWlqFwCXVXE+f6caZDChpP2NWK14uBCzj wQqX/FHWrt1CradhWCyN/EGLxhSwoQ25aO/SU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=QYNWw08p314SJlqzMwur6xZRQUD+SHJ8gw8FS1SO/1yxUg0Rv9GK5fc5YNJ0VLwGqw 1/Oom6lWt7/tK3CFX3faiPxIJmIrf0lBFfBA/E8ppLYb8D3ycLjBjZbxAPUwO13SLyhH +yX0dSA4sxUBE0IGsUJvc94AZMWLh2wqYaF/o= Received: by 10.141.142.15 with SMTP id u15mr5431662rvn.51.1216087498517; Mon, 14 Jul 2008 19:04:58 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Mon, 14 Jul 2008 19:04:58 -0700 (PDT) Message-ID: <396556a20807141904j6577993ar33592061c42b7c83@mail.gmail.com> Date: Mon, 14 Jul 2008 19:04:58 -0700 From: "Adam Langley" To: tcpm@ietf.org In-Reply-To: <20080714234502.AC4793A69F4@core3.amsl.com> MIME-Version: 1.0 Content-Disposition: inline References: <20080714234502.AC4793A69F4@core3.amsl.com> X-Google-Sender-Auth: 9c82ff79fcac365f Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org 2008/7/14 : > A New Internet-Draft is available from the on-line Internet-Drafts directories. > Title : The TCP Authentication Option > Author(s) : J. Touch, et al. > Filename : draft-ietf-tcpm-tcp-auth-opt-01.txt Going by the changes section: > requiring an algorithm for nonce introduction based on ISNs" ... > The presence of TCP's pair of > Initial Sequence Numbers presents a nonce that may be useful in that > case. Such a nonce could be computed as the concatenation of the ISNs > (initiator, responder), and the socket pair (addresses, ports): > o Nonce = ISN_i, ISN_r, IP_address_i, IP_address_r, port_i, port_r I'd like to step back and review this for a moment: We have a couple of reasons for wanting to define an nonce: Reason 1: Without a monotonic counter, a MAC is open to replay attacks. I'm not sure how serious this is. Certainly you can elicit different behaviour from stacks by replaying, say, an ACK very quickly. This is undesirable, but it might be acceptable. More troubling is the possibility of exploiting sequence number rollover to inject a valid packet from 2^32 bytes in the past into the current stream. A monotonic nonce would mean that we could reject replays. Reason 2: Some MAC functions require an nonce as an input and their security depends on the nonce never being reused for any other message with the same key. Consider a connection where all the application-level data transfer is one way and a packet, seq number n, is lost by the network. Here, it's very possible that an ACK for n-1 is transmitted, followed by an ACK for n-1 with a SACK option. Now we've transmitted two different messages with the same nonce. Any nonce based only the sequence numbers has this problem unless we disable/don't include SACK. Also, if we are only including 32-bits of seq, then we trivially repeat every 2^32 bytes. The suggested nonce scheme, above, thus doesn't suffice for reason 2. However, since the ISNs and pseudoheader are already included in the MAC's input, it doesn't do anything for reason 1 either. I don't believe adding in the IP ID would help either. Option 1: don't define an nonce, accept the reply-attack implications and disallow MACs which require strong nonces Option 2: define a 64-bit message counter in each direction, include the bottom n-bits in the AO option and allow some small amount of reordering. Reject duplicate messages. This solves reasons 1 and 2 but requires extra option data and extra state. Option 3: use the seq number as the bottom 32-bits of a 64-bit sequence. It solves replay attacks after 2^32 bytes, but not some other replay attacks. It doesn't solve reason 2. It involves extra state. However, if options are not included in the message, then this *does* solve reason 2 I suspect. I'd want some wiser minds to confirm this however. Option 2 is the cryptographically strong solution. Consider the options in a packet: 10 bytes of timestamp option 18 bytes of AO (96-bit MAC + 2 bytes of option header + key id + nonce) 12 bytes remaining (enough for one SACK block) If the key id was only a bit, then we have 31 low bits of message counter. That's acceptable I think. It would require a packet loss burst of 3^30 packets to de-sync the hosts (which implies a window of > 1 TB @ 1500 MTU). It's really cramming things, however and the storing the counter-space holes to allow for reordering might become expensive if the reorder window is large. So, although I like option 2, any of them would be ok. But I think the current wording in the spec needs to be clearer about which we're choosing. > Clarify NAT interaction I do believe that some method of getting through common NATs (other than wrapping the packets in a tunnel) is needed. There was my previous suggestion of making pseudo-header inclusion optional and having userspace specify a 20-byte bit mask, which is applied to the TCP header (I'll concede that it's a painful 20-bytes of extra state). Alternatively, the common case can be specified with a single bit to remove the pseudo-header and port numbers from the MAC's input. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 14 20:33:02 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48E3E3A686A; Mon, 14 Jul 2008 20:33:02 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 052AC3A67DF for ; Mon, 14 Jul 2008 20:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-alen7gOtEr for ; Mon, 14 Jul 2008 20:33:00 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id F13073A67D1 for ; Mon, 14 Jul 2008 20:32:59 -0700 (PDT) Received: from [127.0.0.1] (pool-71-106-110-19.lsanca.dsl-w.verizon.net [71.106.110.19]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6F3XCLX007354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Jul 2008 20:33:16 -0700 (PDT) Message-ID: <487C1A77.5090804@isi.edu> Date: Mon, 14 Jul 2008 20:33:11 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Adam Langley References: <20080714234502.AC4793A69F4@core3.amsl.com> <396556a20807141904j6577993ar33592061c42b7c83@mail.gmail.com> In-Reply-To: <396556a20807141904j6577993ar33592061c42b7c83@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1417146699==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1417146699== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCE7D869D7485C2321D96AE4D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCE7D869D7485C2321D96AE4D Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, Adam, Adam Langley wrote: > 2008/7/14 : >> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >> Title : The TCP Authentication Option >> Author(s) : J. Touch, et al. >> Filename : draft-ietf-tcpm-tcp-auth-opt-01.txt >=20 > Going by the changes section: >=20 >> requiring an algorithm for nonce introduction based on ISNs" > ... >> The presence of TCP's pair of >> Initial Sequence Numbers presents a nonce that may be useful in that= >> case. Such a nonce could be computed as the concatenation of the ISN= s >> (initiator, responder), and the socket pair (addresses, ports): >=20 >> o Nonce =3D ISN_i, ISN_r, IP_address_i, IP_address_r, port_i, port_= r >=20 > I'd like to step back and review this for a moment: >=20 > We have a couple of reasons for wanting to define an nonce: >=20 > Reason 1: Without a monotonic counter, a MAC is open to replay > attacks.=20 The nonce is for generating per-session keys, not for per-packet=20 operations. Per packet uniqueness is discussed in the replay section of=20 the Security Considerations, and is governed primarily by the TCP=20 sequence number, and the strong suggestion (elsewhere) to change the key = every 2^31 bytes if uniqueness is a concern. =2E.. > The suggested nonce scheme, above, thus doesn't suffice for reason 2. > However, since the ISNs and pseudoheader are already included in the > MAC's input, it doesn't do anything for reason 1 either. I don't > believe adding in the IP ID would help either. We can't add in the IP ID as a rule; this mechanism needs to work for=20 IPv6 - which, when not source fragmented, has no such ID (see also my=20 other I-D deprecating IPv4 ID uniqueness for related reasons). This is, as noted above, only to ensure session key uniqueness. It=20 removes the need to check for key reuse. ---- As to per-packet uniqueness... > Option 1: don't define an nonce, accept the reply-attack implications > and disallow MACs which require strong nonces >=20 > Option 2: define a 64-bit message counter in each direction, include > the bottom n-bits in the AO option and allow some small amount of > reordering. Reject duplicate messages. This solves reasons 1 and 2 but > requires extra option data and extra state. >=20 > Option 3: use the seq number as the bottom 32-bits of a 64-bit > sequence. It solves replay attacks after 2^32 bytes, but not some > other replay attacks. It doesn't solve reason 2. It involves extra > state. However, if options are not included in the message, then this > *does* solve reason 2 I suspect. I'd want some wiser minds to confirm > this however. Option 4 is what we currently suggest, which is: use the 32-bit sequence number as the per-packet nonce, and encourage=20 rekeying every 2^31 bytes or so. This is preferable to the above because: - it avoids the need for additional state in TCP that can be hard to manage when retransmissions straddle rollover (i.e., state changes not already inside TCP); this state is complex whether it's the top part of a counter or a new counter - it avoids the space a full new counter would consume in the option - it still provides a nonce (I don't see how to "disallow" MACs that require a nonce. I don't know what a "strong" nonce is, though - nonce just means unique. If 'strong' means 'random', that's different (i.e., entropy inducer, vs. just unique). Finally, if none of that is sufficient and users need true nonces, then=20 other protocols might be preferable (e.g., IPsec); this isn't intended=20 to be a complete solution for all situations. >> Clarify NAT interaction >=20 > I do believe that some method of getting through common NATs (other > than wrapping the packets in a tunnel) is needed. There was my > previous suggestion of making pseudo-header inclusion optional and > having userspace specify a 20-byte bit mask, which is applied to the > TCP header (I'll concede that it's a painful 20-bytes of extra state). > Alternatively, the common case can be specified with a single bit to > remove the pseudo-header and port numbers from the MAC's input. I prefer including the expected addrs and port numbers for the following = reason: 1. TCP-AO needs to know what the addr/port pair is at the receiver=20 behind the NAT anyway in order to match keys to connections 2. if the addr/port pair at the dest is known, it could be coordinated=20 with the source and the source can include those values when computing=20 the MAC i.e., if you have enough information to make keying work properly, you=20 have enough to compute a valid received MAC that includes the addrs and=20 ports, and thus validates that info when a message is received. Joe --------------enigCE7D869D7485C2321D96AE4D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIfBp4E5f5cImnZrsRAuTyAKC4HnQenx5WRhAbnUPuwyxF/ZTvYQCfbGEJ VgEKL9NAsZzViT88w7ZBRPM= =A2YF -----END PGP SIGNATURE----- --------------enigCE7D869D7485C2321D96AE4D-- --===============1417146699== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1417146699==-- From tcpm-bounces@ietf.org Mon Jul 14 21:58:17 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BFBD3A6881; Mon, 14 Jul 2008 21:58:17 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B51823A6881 for ; Mon, 14 Jul 2008 21:58:15 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9YWrk1bg519 for ; Mon, 14 Jul 2008 21:58:14 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id D452D3A67D1 for ; Mon, 14 Jul 2008 21:58:14 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so4510680rvf.49 for ; Mon, 14 Jul 2008 21:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=6hLb4kLN64Jd1utPIpk0d9Xvb+rIT0n6vISGTH7eum0=; b=nS+M1L3MTcvAzaXuPx6EmwXo7ru1nnNmrNtR2JKQQJ8KzVH7yJD3Hmr6Cw841PgojW oj1rr17MFWd/deTIQ+TKFu/JSujj/64xKeyVbAqX8uWCBPw4/hOs4CmUimiICntPYHIZ lwYykMUf+FvVeHqg6awmUnO5Tf0E5xINz0puo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=VZbQbk3+s3UQtlkLkVqkrwBxkXsfy1YlP/pwnwlekSj9UaB1F2hqm3jljRLIZVWq4n H1ryU8zwUSfhmclJO7aXLQ14wrNqtvPQtKEa37jiI5gzNp+E7Shv2bVB6E/xAntDh/BU GRYO7izmpql2VPhzINZ1joOe3uBlD5kQ/h3v0= Received: by 10.141.114.19 with SMTP id r19mr7113624rvm.146.1216097921637; Mon, 14 Jul 2008 21:58:41 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Mon, 14 Jul 2008 21:58:41 -0700 (PDT) Message-ID: <396556a20807142158v1b0c0695h810d601382c7545d@mail.gmail.com> Date: Mon, 14 Jul 2008 21:58:41 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <487C1A77.5090804@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <20080714234502.AC4793A69F4@core3.amsl.com> <396556a20807141904j6577993ar33592061c42b7c83@mail.gmail.com> <487C1A77.5090804@isi.edu> X-Google-Sender-Auth: 1801ddf90d907fd9 Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Mon, Jul 14, 2008 at 8:33 PM, Joe Touch wrote: > The nonce is for generating per-session keys, not for per-packet operations. > Per packet uniqueness is discussed in the replay section of the Security > Considerations, and is governed primarily by the TCP sequence number, and > the strong suggestion (elsewhere) to change the key every 2^31 bytes if > uniqueness is a concern. Right, sorry I misunderstood that. > Option 4 is what we currently suggest, which is: > use the 32-bit sequence number as the per-packet nonce, and encourage > rekeying every 2^31 bytes or so. Ok. That's what I called option one, > - it still provides a nonce (I don't see how to "disallow" > MACs that require a nonce. I don't know what a "strong" > nonce is, though - nonce just means unique. If 'strong' > means 'random', that's different (i.e., entropy inducer, > vs. just unique). Some MACs accept a pair as their input (M,n) where n is a strong nonce. These MACs require that a given nonce, n, never be used with two different messages. If you do, then you may well be exposing key information etc (the security proof is invalid so anything's possible). Since we can't guarantee this, we just have to exclude them I believe. Since the well known MACs (MD5, SHA family etc) are not of this type it's not a big issue. > I prefer including the expected addrs and port numbers for the following > reason: > > 1. TCP-AO needs to know what the addr/port pair is at the receiver behind > the NAT anyway in order to match keys to connections Only in the case where a listening socket is configured with a list of (source, key) pairs. That's the case with routers and BGP sessions etc, but one could certainly imagine TCP-AO as a (better) alternative to port-knocking schemes. Also, it doesn't work for connections where the AO key is established by the application level after the TCP handshake. (Although, in the latter case, one could argue that each host should tell the other its NAT translated identity just to make AO work). AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 15 10:07:12 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 078713A6B14; Tue, 15 Jul 2008 10:07:12 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 574D03A6AF6 for ; Tue, 15 Jul 2008 10:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P66DZwhquqPT for ; Tue, 15 Jul 2008 10:07:09 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 81EF93A6B14 for ; Tue, 15 Jul 2008 10:07:09 -0700 (PDT) Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6FH7SMB013708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Jul 2008 10:07:30 -0700 (PDT) Message-ID: <487CD94E.4010004@isi.edu> Date: Tue, 15 Jul 2008 10:07:26 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <0C53DCFB700D144284A584F54711EC58057555B0@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58057555B0@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, David Borman Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcpsecure-10.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anantha Ramaiah (ananth) wrote: ... | I have added a section called "strength of mitigations". The rationale | for adding this section is that, to clear up the reasoning, for tagging | the mitigations strengths as S/S/M esp. after the "Applicability | statement" is in place. Digging through the responses (textual and | verbal) I don't see a strong technical reasoning for choosing the Data | mitigation as MAY. I request the WG members who voted for MAY to speak | up their technical reasoning. Pl remember that this reasoning is highly | desirable since in future many people may ask the same question and | hence it is prudent to come with a better technical explanation. IMO there was insufficient motivation for making this MUST. I don't feel the document needs to come up with anything "better" than that, which should be easy to state briefly. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIfNlOE5f5cImnZrsRAkKLAJ9/mXDgQzKuMya8xdlIFfrpNroTQgCfZNBz a01ANJnaIPyt9EEMCivsmxU= =rnN1 -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 15 11:11:35 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69C993A68F1; Tue, 15 Jul 2008 11:11:35 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8C3C3A68E8 for ; Tue, 15 Jul 2008 11:11:34 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1ksVvLAqbJY for ; Tue, 15 Jul 2008 11:11:34 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id E5DE43A696E for ; Tue, 15 Jul 2008 11:11:33 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so4704091rvf.49 for ; Tue, 15 Jul 2008 11:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=SfVW/E1/Rrzn+jkb3qeyldtukYKvcmNxyANqBBK7kR0=; b=x+GCn/tlBYdn7/5z6rN1Egj14uZYrmViKtNdq7VwJ99mI/DSTpJxn9Q5NyztJiK5CW nZySvtbWtaU/vruD5a36I3DB40AqT51HN1vylWIt/cDO2Hqwp/rzqrQOJroxm82+H9l/ WS3qhAjR7c5h5V/99DlgKo5D/a3cpXL8d4jUc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=VuVBbjnC5McZbUGBfe6+kjUAexi/81kC0G/K5h30ojthbJV8/7HFLtSLXx52EDh2er IAW5/t33jGl0/QxTqkZbqsuy4V8gCdGPJEehzQsvJARdF7wgcNkHGnTIjC9G8CPNKZLA KH28e2z3greIcGqkaHiNZKSwzHHDbfhA2qq2I= Received: by 10.140.200.16 with SMTP id x16mr7641960rvf.120.1216145519789; Tue, 15 Jul 2008 11:11:59 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Tue, 15 Jul 2008 11:11:59 -0700 (PDT) Message-ID: <396556a20807151111u778faed3wb5a533e90c00b8c1@mail.gmail.com> Date: Tue, 15 Jul 2008 11:11:59 -0700 From: "Adam Langley" To: tcpm@ietf.org MIME-Version: 1.0 Content-Disposition: inline X-Google-Sender-Auth: e83c86d7966459c0 Subject: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Although I cannot attend Dublin, I though that I would post this before the meeting in case people wished to discuss it there. For the record, I'm still advocating that long options be an experimental RFC although my work has switched to using the tricks detailed in this draft. Thanks go to Wes Eddy for comments on the previous version of this draft. http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-00.txt -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 15 11:22:21 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD6E73A6AFC; Tue, 15 Jul 2008 11:22:21 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D8DF3A6AFC for ; Tue, 15 Jul 2008 11:22:20 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14F-1QAUWk+9 for ; Tue, 15 Jul 2008 11:22:19 -0700 (PDT) Received: from mail72.messagelabs.com (mail72.messagelabs.com [193.109.255.147]) by core3.amsl.com (Postfix) with SMTP id 0D01A3A6A5F for ; Tue, 15 Jul 2008 11:22:18 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-8.tower-72.messagelabs.com!1216146165!51891825!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 13814 invoked from network); 15 Jul 2008 18:22:45 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-8.tower-72.messagelabs.com with SMTP; 15 Jul 2008 18:22:45 -0000 Received: from ads30.surrey.ac.uk ([131.227.120.130]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 19:22:45 +0100 Received: from [192.168.1.208] ([82.44.158.76]) by ads30.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 19:22:44 +0100 Message-Id: <7E78ADB4-804B-4C57-824E-04E11B484E94@surrey.ac.uk> From: Lloyd Wood To: "Adam Langley" In-Reply-To: <396556a20807151111u778faed3wb5a533e90c00b8c1@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 15 Jul 2008 19:22:43 +0100 References: <396556a20807151111u778faed3wb5a533e90c00b8c1@mail.gmail.com> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 15 Jul 2008 18:22:45.0147 (UTC) FILETIME=[C6EDF6B0:01C8E6A7] Cc: tcpm@ietf.org, Lloyd Wood Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This looks awfully like reinventing transactional TCP to me - and IIRC the reason that never got widely adopted was the increased potential for DOS attacks by tying up memory early on with a loaded SYN. What am I missing? On 15 Jul 2008, at 19:11, Adam Langley wrote: > Although I cannot attend Dublin, I though that I would post this > before the meeting in case people wished to discuss it there. > > For the record, I'm still advocating that long options be an > experimental RFC although my work has switched to using the tricks > detailed in this draft. > > Thanks go to Wes Eddy for comments on the previous version of this > draft. > > http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-00.txt > > -- > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 15 11:29:20 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B53EC3A6B3A; Tue, 15 Jul 2008 11:29:20 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BEA93A6B5A for ; Tue, 15 Jul 2008 11:29:19 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRBPXUyRUx+0 for ; Tue, 15 Jul 2008 11:29:18 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id 91B603A6AF6 for ; Tue, 15 Jul 2008 11:29:18 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so4708442rvf.49 for ; Tue, 15 Jul 2008 11:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=ul24djLZIahrWv9+09+rwZxQaZ1AxZH4FGCnZYtL/yk=; b=YYGdQnzAAwIm7NYwjS9Bta+46euNdFKtU2S/2ncpNry/0MtbnkUOp6udwPueG+v+VD XjH77X+mMQ57ImeAgkd7SQTt54+Z3SzW7q0kOqsxTGK0Pyb/BeGpv9nv59+0uOQjtsZs Z63TPQehPkxDk5mOOdabnFj7e+i6MyTnsMa4I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=dYDYe0KjI1QK3O5o1adYp9GYY1DGhDgtwKDU/HBFzoYwXARQ8i2dbVAehzLlrsE/aq aq4PzNpIkIwwN670K2QGrTgpY4qbs9eTAcNC9fMwmiumHJqA836UikOUi8LofkQRkOqd O0D1VWUbFaKSwTrrwemUlIaQc/yy0xKZQ+Y7o= Received: by 10.141.74.18 with SMTP id b18mr7647172rvl.159.1216146585912; Tue, 15 Jul 2008 11:29:45 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Tue, 15 Jul 2008 11:29:45 -0700 (PDT) Message-ID: <396556a20807151129m50cc0ad6u44cd9599b7e51ac1@mail.gmail.com> Date: Tue, 15 Jul 2008 11:29:45 -0700 From: "Adam Langley" To: "Lloyd Wood" In-Reply-To: <7E78ADB4-804B-4C57-824E-04E11B484E94@surrey.ac.uk> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20807151111u778faed3wb5a533e90c00b8c1@mail.gmail.com> <7E78ADB4-804B-4C57-824E-04E11B484E94@surrey.ac.uk> X-Google-Sender-Auth: e7faaf52b09507fd Cc: tcpm@ietf.org Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Tue, Jul 15, 2008 at 11:22 AM, Lloyd Wood wrote: > This looks awfully like reinventing transactional TCP to me - and IIRC the > reason that never got widely adopted was the increased potential for DOS > attacks by tying up memory early on with a loaded SYN. > > What am I missing? There's a short section in the draft comparing it to T/TCP, but the quick version: * For a given SYN there's one bit of additional state required (and the draft says that a host can completely ignore a SYNACK Payload Permitted bit if it's under heavy load and using cookies etc) * There's no payload in the SYN, so you can't send data to an application from an unverified source address In short, I don't believe that any of the T/TCP objections apply to this draft, although I could be wrong. I suggest that the similarities with it are only superficial. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 15 11:58:35 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 806683A689F; Tue, 15 Jul 2008 11:58:35 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42E923A689F; Tue, 15 Jul 2008 11:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Gku619e3fVb; Tue, 15 Jul 2008 11:58:33 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 9742E3A67DD; Tue, 15 Jul 2008 11:58:33 -0700 (PDT) Received: from [127.0.0.1] (nib.isi.edu [128.9.160.144]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6FIwmZw021161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Jul 2008 11:58:50 -0700 (PDT) Message-ID: <487CF368.3050207@isi.edu> Date: Tue, 15 Jul 2008 11:58:48 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Internet-Drafts@ietf.org References: <20080714234502.AC4793A69F4@core3.amsl.com> In-Reply-To: <20080714234502.AC4793A69F4@core3.amsl.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, i-d-announce@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1563234654==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1563234654== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5A057155E18AD49429DD9B42" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5A057155E18AD49429DD9B42 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, all, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the TCP Maintenance and Minor Extensions W= orking Group of the IETF. >=20 >=20 > Title : The TCP Authentication Option > Author(s) : J. Touch, et al. > Filename : draft-ietf-tcpm-tcp-auth-opt-01.txt > Pages : 30 > Date : 2008-07-14 FYI, a list of changes and remaining open issues is contained in the=20 document. Joe --------------enig5A057155E18AD49429DD9B42 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIfPNoE5f5cImnZrsRArziAKDgao/M/9dLpr+q5rVgmqBqZUrrWQCg85g6 w4PfeUjoa/P3tNbV1vYUz9M= =/3tf -----END PGP SIGNATURE----- --------------enig5A057155E18AD49429DD9B42-- --===============1563234654== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1563234654==-- From tcpm-bounces@ietf.org Tue Jul 15 13:52:28 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC3DD3A696C; Tue, 15 Jul 2008 13:52:28 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99EFA3A696C for ; Tue, 15 Jul 2008 13:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVonQJ2tysk5 for ; Tue, 15 Jul 2008 13:52:25 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6F7303A6863 for ; Tue, 15 Jul 2008 13:52:25 -0700 (PDT) Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6FKqVS3028147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Jul 2008 13:52:32 -0700 (PDT) Message-ID: <487D0E0D.3030408@isi.edu> Date: Tue, 15 Jul 2008 13:52:29 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Adam Langley References: <396556a20807151111u778faed3wb5a533e90c00b8c1@mail.gmail.com> <7E78ADB4-804B-4C57-824E-04E11B484E94@surrey.ac.uk> <396556a20807151129m50cc0ad6u44cd9599b7e51ac1@mail.gmail.com> In-Reply-To: <396556a20807151129m50cc0ad6u44cd9599b7e51ac1@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Lloyd Wood Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Adam (et al.), I looked this over, and had a clarification: Data could *always* come in the SYN/ACK (i.e., in a SYN), but often it's just ignored. So this option is just a hint to the server that the client won't ignore that data. It doesn't change any rules about data delivery; once the SYN/ACK arrives, the client can send that data up to the user as per conventional rules, AFAICT. Adam Langley wrote: | On Tue, Jul 15, 2008 at 11:22 AM, Lloyd Wood wrote: |> This looks awfully like reinventing transactional TCP to me - and IIRC the |> reason that never got widely adopted was the increased potential for DOS |> attacks by tying up memory early on with a loaded SYN. Transaction TCP allows a server to push data to the user that arrives in the SYN without waiting for the client's final ACK; that doesn't appear to be related to this. I think the only catch is that this works only when there's a unidirectional-initiated connection from client to server, and only helps hint the server that the client will accept data in the SYN/ACK. It doesn't help with simultaneous opens, e.g., since neither side can send the data up until their SYN is ACK'd -- *that* is what T/TCP changes, but this doesn't, again AFAICT. I'm really not sure what buying a single RTT will do for TCP, though. Very few exchanges that need reliable transfer of a single packet need TCP, IMO. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIfQ4NE5f5cImnZrsRAhXdAKC54DBHXzDHYMLhyoIebf1WuF5puACfcEnj rl+lp9HBV6XIGjhfaBnu7YA= =MHdC -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 15 14:14:59 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0DD93A6AD9; Tue, 15 Jul 2008 14:14:59 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A9833A6AA3 for ; Tue, 15 Jul 2008 14:14:58 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqBXrWyuagxo for ; Tue, 15 Jul 2008 14:14:57 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 506FE3A67BD for ; Tue, 15 Jul 2008 14:14:57 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so4747660rvf.49 for ; Tue, 15 Jul 2008 14:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=OlpuRNT+9kTRmStumez1gwyLkV0yUOX0DvYVh7FEzlA=; b=qKOdgti3xxsAjxSohwPkicunTzw8MpOJI6gr5wq0q04Ic5I3hpaGa9afKQF8z+CUDh gqCfPGAvTEoIZ9MEN6dW+cLXhyT+fnn1itwbXttF0Jc8uMuSyG5hp88ypoxdwkox7FtJ b1JZ0Tf3gstu4KFTWluM6Wljv8g81hGwweQK8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=hBNLfDnb3N+TWgpNS9SRZRdHRFD0ECtwDGYwnAyro9xHs/1FY6ypr4wypi4qFDRRna DNPVR9sET5yoJk2B+TpDcd6a1DkrNdEvSRl96mKFSofRXPi9bzmwUl138rMaDSp7qQwO AqjZSuXXJi/dwexFBPofer08Y6uSHMfD5NrUQ= Received: by 10.140.185.1 with SMTP id i1mr7761594rvf.102.1216156513731; Tue, 15 Jul 2008 14:15:13 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Tue, 15 Jul 2008 14:15:13 -0700 (PDT) Message-ID: <396556a20807151415i7e6b0d4bu6984617a095b07db@mail.gmail.com> Date: Tue, 15 Jul 2008 14:15:13 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <487D0E0D.3030408@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20807151111u778faed3wb5a533e90c00b8c1@mail.gmail.com> <7E78ADB4-804B-4C57-824E-04E11B484E94@surrey.ac.uk> <396556a20807151129m50cc0ad6u44cd9599b7e51ac1@mail.gmail.com> <487D0E0D.3030408@isi.edu> X-Google-Sender-Auth: ea19e2ee436e7f05 Cc: tcpm@ietf.org, Lloyd Wood Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Tue, Jul 15, 2008 at 1:52 PM, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Data could *always* come in the SYN/ACK (i.e., in a SYN), but often it's > just ignored. So this option is just a hint to the server that the > client won't ignore that data. It doesn't change any rules about data > delivery; once the SYN/ACK arrives, the client can send that data up to > the user as per conventional rules, AFAICT. Although I've not tested it, I suspect that you're correct here. I should reword that section of the draft. > I'm really not sure what buying a single RTT will do for TCP, though. > Very few exchanges that need reliable transfer of a single packet need > TCP, IMO. Although it could be used for single packet exchanges from the server, I would be surprised if any one did. My expectation is that protocols would use it to shave a RTT from the TCP connection setup latency. My personal motivation for this draft is hinted at in section 2: "This also allows existing protocols to be extended with encryption with no additional round trips and with transparent fallback." Consider a web browser which sets the SYNACK permitted bit and a web server which includes an elliptic-curve Diffie Hellman key in it's static SYNACK payload. When connecting to a normal webserver, the browser will see that no SYNACK payload was received and carry on as normal. But for augmented webservers, the browser calculate a shared key and include its own ECDH key just before the HTTP "GET" request, carried in the final ACK of the 3-way. Thus we have opportunistic encryption and no additional latency in either case. (Also, that's not just idle speculation: the firefox build that I'm writing this email in is such a web browser and the lighttpd I have running at home is such a web server.) Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 15 17:36:20 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BA3928C0EE; Tue, 15 Jul 2008 17:36:20 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A012B3A68DB for ; Tue, 15 Jul 2008 17:36:19 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UbWdv4wQlYB for ; Tue, 15 Jul 2008 17:36:18 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id 670413A6915 for ; Tue, 15 Jul 2008 17:36:04 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so4784995rvf.49 for ; Tue, 15 Jul 2008 17:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=wUt5i7Q1GfrwSjOSfop6IsGiKT8zfXN4LBCHibu7Tj8=; b=svhEWHu/6/bEELfvdi8EsecmH0ZgHRSEm7Uv7gUiCWjrZmwUEagauzntr6raobMz3K r7J8l5f08+by800iskPf5OM4q1RRNb5Sa2vYD+ZBWxI0XDrqqEIIcORo52hqAPaENSU+ Mpz9HW6TVz1jezvZJrSKf3zir26way7Afwab4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=rGBpSTTrP7lJr6Rd+OzoPF2moPtw47RnbxGBYg2gq2dEXgxkyHA0UUgYppzWBcyiVS TpKHYLhsyg7NYJO/SEx20S89NOEsI0PVe1ysp64m9dGBXnPiL3KI0J69RdUpF7tkcG5Q wr96Iaoxtl0l5WAMSUmZyDnEzxQaIgx5XeHyc= Received: by 10.141.137.16 with SMTP id p16mr7849466rvn.192.1216168592893; Tue, 15 Jul 2008 17:36:32 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Tue, 15 Jul 2008 17:36:32 -0700 (PDT) Message-ID: <396556a20807151736k35564e19h9fc6699e489c94fb@mail.gmail.com> Date: Tue, 15 Jul 2008 17:36:32 -0700 From: "Adam Langley" To: tcpm@ietf.org In-Reply-To: <20080714234502.AC4793A69F4@core3.amsl.com> MIME-Version: 1.0 Content-Disposition: inline References: <20080714234502.AC4793A69F4@core3.amsl.com> X-Google-Sender-Auth: d3a0c18fcfd36b3b Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org 2008/7/14 : > Title : The TCP Authentication Option > Author(s) : J. Touch, et al. > Filename : draft-ietf-tcpm-tcp-auth-opt-01.txt ... Simple typo, section 4: " a. TCP option exclusion flag. When 0, this flag allows default operation, i.e., TCP options are When 1, all options " I think there should be "included" after "are". AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 15 17:46:40 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A3693A67D4; Tue, 15 Jul 2008 17:46:40 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84DEB3A67D4 for ; Tue, 15 Jul 2008 17:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krafmulNP5QV for ; Tue, 15 Jul 2008 17:46:37 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 5E1223A6B13 for ; Tue, 15 Jul 2008 17:46:25 -0700 (PDT) Received: from [127.0.0.1] (pool-71-106-110-19.lsanca.dsl-w.verizon.net [71.106.110.19]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6G0kaqV002778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Jul 2008 17:46:38 -0700 (PDT) Message-ID: <487D44EB.4090305@isi.edu> Date: Tue, 15 Jul 2008 17:46:35 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Adam Langley References: <20080714234502.AC4793A69F4@core3.amsl.com> <396556a20807151736k35564e19h9fc6699e489c94fb@mail.gmail.com> In-Reply-To: <396556a20807151736k35564e19h9fc6699e489c94fb@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0260847942==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0260847942== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig114214DC78BDD5496692B1DC" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig114214DC78BDD5496692B1DC Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Adam Langley wrote: > 2008/7/14 : >> Title : The TCP Authentication Option >> Author(s) : J. Touch, et al. >> Filename : draft-ietf-tcpm-tcp-auth-opt-01.txt > ... >=20 > Simple typo, section 4: >=20 > " a. TCP option exclusion flag. When 0, this flag allows default > operation, i.e., TCP options are When 1, all options " >=20 > I think there should be "included" after "are". Yes - simple typo ;-( Joe --------------enig114214DC78BDD5496692B1DC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIfUTrE5f5cImnZrsRArtqAKDmJZTTGYkCNQ/Mhd1qw1OajLlLPgCfWV9+ eMDCpvWMRcCV/iZRzoHzxOw= =LcAL -----END PGP SIGNATURE----- --------------enig114214DC78BDD5496692B1DC-- --===============0260847942== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0260847942==-- From tcpm-bounces@ietf.org Tue Jul 15 18:48:27 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3A5B3A6A58; Tue, 15 Jul 2008 18:48:26 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F007F3A6A58 for ; Tue, 15 Jul 2008 18:48: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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3N6rZ9oilPzC for ; Tue, 15 Jul 2008 18:48:25 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 0EFCB3A6A37 for ; Tue, 15 Jul 2008 18:48:25 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so5204314wfd.31 for ; Tue, 15 Jul 2008 18:48:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=h/f95Up+ifPphQZYZjdWQgfSCMkUdGH06+tV+Nodk2s=; b=vBxmQHAAINCXVfOsj0RnVGDIiDEo4HynwwAt3XOyIzBLUYP6g7iX4KKT7v5rDRCiQ4 MG1FwMcVm8zCITNqZaAOgh8WRG74DlA7rjAldnnpfKSoeafX2hhbhCk/qLw+qxievIM7 ZOBL+kAPM45MT4zVIRPEy08Od/Ey11TJWfydM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=K1ygym2gggmff9lid51mQVnL0VtML6xKgrHFfsmrWDyRUeJizXI5sLZWQurt5naoxv jmt3cyqImBwmPOPRX0unRWcxSVdGm6YVv9ITNP75psBIWrVMJFR6E/BgXikUH9Ao7w6j OjsRTWwJL+f8/40Ljt/8vwPowVEl5FMlcXoRQ= Received: by 10.142.11.2 with SMTP id 2mr4917075wfk.1.1216172933617; Tue, 15 Jul 2008 18:48:53 -0700 (PDT) Received: by 10.142.139.12 with HTTP; Tue, 15 Jul 2008 18:48:53 -0700 (PDT) Message-ID: <396556a20807151848h56766b43gf5a76f43432262de@mail.gmail.com> Date: Tue, 15 Jul 2008 18:48:53 -0700 From: "Adam Langley" To: "Lloyd Wood" In-Reply-To: <396556a20807151129m50cc0ad6u44cd9599b7e51ac1@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20807151111u778faed3wb5a533e90c00b8c1@mail.gmail.com> <7E78ADB4-804B-4C57-824E-04E11B484E94@surrey.ac.uk> <396556a20807151129m50cc0ad6u44cd9599b7e51ac1@mail.gmail.com> X-Google-Sender-Auth: 00604be60e610a46 Cc: tcpm@ietf.org Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Tue, Jul 15, 2008 at 11:29 AM, Adam Langley wrote: > * For a given SYN there's one bit of additional state required (and > the draft says that a host can completely ignore a SYNACK Payload > Permitted bit if it's under heavy load and using cookies etc) I screwed that up, sorry. If you're asking the kernel to generate an nonce for you, it has to remember the value, so that's actually 9 bytes of state. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 15 23:53:19 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 131D63A68E5; Tue, 15 Jul 2008 23:53:19 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB44E3A6829 for ; Tue, 15 Jul 2008 23:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCP377T3NNgx for ; Tue, 15 Jul 2008 23:53:17 -0700 (PDT) Received: from wall.ikr.uni-stuttgart.de (wall.ikr.uni-stuttgart.de [129.69.170.1]) by core3.amsl.com (Postfix) with ESMTP id CF5763A681A for ; Tue, 15 Jul 2008 23:53:16 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by wall.ikr.uni-stuttgart.de (Postfix) with ESMTP id D7C1256CD3; Wed, 16 Jul 2008 08:53:44 +0200 (CEST) Received: by netsrv1.ikr.uni-stuttgart.de (Postfix, from userid 539) id CC93ABC081; Wed, 16 Jul 2008 08:53:44 +0200 (CEST) Received: from ikr.uni-stuttgart.de (inode21 [10.21.18.11]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with SMTP id A5834BC07E; Wed, 16 Jul 2008 08:53:44 +0200 (CEST) Received: by ikr.uni-stuttgart.de (sSMTP sendmail emulation); Wed, 16 Jul 2008 08:53:44 +0200 Date: Wed, 16 Jul 2008 08:53:44 +0200 From: Michael Scharf To: Adam Langley Message-ID: <20080716065344.GA4443@ikr.uni-stuttgart.de> References: <396556a20807151111u778faed3wb5a533e90c00b8c1@mail.gmail.com> <7E78ADB4-804B-4C57-824E-04E11B484E94@surrey.ac.uk> <396556a20807151129m50cc0ad6u44cd9599b7e51ac1@mail.gmail.com> <487D0E0D.3030408@isi.edu> <396556a20807151415i7e6b0d4bu6984617a095b07db@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <396556a20807151415i7e6b0d4bu6984617a095b07db@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: tcpm@ietf.org, Lloyd Wood , Joe Touch Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hi Adam, On Tue, 15 Jul 2008 at 14:15:13, Adam Langley wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Data could *always* come in the SYN/ACK (i.e., in a SYN), but often it's > > just ignored. So this option is just a hint to the server that the > > client won't ignore that data. It doesn't change any rules about data > > delivery; once the SYN/ACK arrives, the client can send that data up to > > the user as per conventional rules, AFAICT. > > Although I've not tested it, I suspect that you're correct here. I > should reword that section of the draft. sorry for asking once again "stupid" questions: Wouldn't it be a simple solution if the server just sent the data in a normal packet immediately after the SYN/ACK? The resulting sequence would be: Client Server ------SYN----> <---SYN/ACK--- <====Data===== ------ACK----> I think that this would be compliant to RFC 793. I would also expect that many clients would accept this data packet if it arrives after the SYN/ACK, i. e., if there is no reordering. This could also save one RTT of latency, and the overhead of one packet would not be that large. Do I miss something? Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 16 09:36:16 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE0EE3A690F; Wed, 16 Jul 2008 09:36:16 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 670A23A690F for ; Wed, 16 Jul 2008 09:36:15 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdsOMzIEKFk6 for ; Wed, 16 Jul 2008 09:36:14 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 6DBC13A6806 for ; Wed, 16 Jul 2008 09:36:14 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so1581146yxg.49 for ; Wed, 16 Jul 2008 09:36:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=IE07fj3NrpZr3HiW7pDwNPCkd7Yt2exrA4ZP4KhWNb0=; b=HljEit45jGt5qN7Jp8qZ2K5Tts+qgZXB+PtlduQ7rJ0hA6I/PR2nMXvbN5Mm493V1U b2Wl6sDlAnGi7SpPb5zr/hlJX8YomS9ZQd5X9kLe3Z6hrOPyH77gm+o9qVjWL2rC4tWi jRYRx0Jk5ely5vjpkc6IMLmo/yI77t3Xs/LRA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=qjgG+a2d9BXZDYU2LVWh1AezlDX28kAFTuN5zh04vFawpncVMmv2jKZsL/d4C/oOh6 JhIQYgupAYXSCBuBzveCCtbeFrXHsLQCxC9tQsmQnD+EoCyrryZzPE8aYBKHcCNTDzsv 0uqFAcYt+WFP9Mi4kwZEbsqAL4kNIlIHBuk54= Received: by 10.141.162.6 with SMTP id p6mr314413rvo.121.1216226201365; Wed, 16 Jul 2008 09:36:41 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Wed, 16 Jul 2008 09:36:41 -0700 (PDT) Message-ID: <396556a20807160936u5839080eh26d904fa27e0c07b@mail.gmail.com> Date: Wed, 16 Jul 2008 09:36:41 -0700 From: "Adam Langley" To: "Michael Scharf" In-Reply-To: <20080716065344.GA4443@ikr.uni-stuttgart.de> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20807151111u778faed3wb5a533e90c00b8c1@mail.gmail.com> <7E78ADB4-804B-4C57-824E-04E11B484E94@surrey.ac.uk> <396556a20807151129m50cc0ad6u44cd9599b7e51ac1@mail.gmail.com> <487D0E0D.3030408@isi.edu> <396556a20807151415i7e6b0d4bu6984617a095b07db@mail.gmail.com> <20080716065344.GA4443@ikr.uni-stuttgart.de> X-Google-Sender-Auth: 5c8dac161a7ef2f9 Cc: tcpm@ietf.org Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Tue, Jul 15, 2008 at 11:53 PM, Michael Scharf wrote: > sorry for asking once again "stupid" questions: Wouldn't it be a > simple solution if the server just sent the data in a normal packet > immediately after the SYN/ACK? That's a very interesting idea; I hadn't considered it. The pros would be that one could imagine that the active open host wouldn't need any changes to support it. Let's consider what could go wrong: Packet loss: shouldn't be an issue. If the SYNACK is lost, the packet with a payload would, at worst, get ignored. Possibly some stacks would enqueue it. Reordering: again, should be fine. Since the data packet is affecting the sequence numbers it would get retransmitted if it was dropped because it arrived early. However, application level protocols probably need to change in order to take advantage of early passive-open data transmission. Either because they weren't designed with that in mind or because they need to be a lot more frugal with their bits to fit within the 64-byte limit. So the option in the SYN would still be needed, and that means there's an issue of consistency. Both sides need to know if early-data is in play because it affects the application level. Consider AO: active open host PO: passive open host 1. AO: A SYN is sent with SYNPACK Payload Permitted 2. PO: A SYNACK reply is sent and a data packet is sent 3. AO: A timeout occurs and the SYN is retransmitted without the permitted bit. Although I don't think middleware dropping the unknown option is going to be too much of a problem (see citations in the draft), it's good if hosts have the option of doing this 4. AO: The SYNACK packet (from step 2) arrives. ACK is sent 5. AO: The data packet (from step 2) arrives and is enqueued. 5. PO: The second SYN causes another SYNACK (which will be ignored by AO) 6: PO: The ACK arrives Now, neither side believe that an extra data packet was in play (AO because it timed out and transmitted without the permitted bit in 3 and PO because it got a SYN without the bit in 5). However, the data reaches the application level. This means that we have to mark the data packet in some way (probably an option) so that AO can drop it at step 5. Alternatively we could require that, if the AO host wishes to back off from sending the permitted bit, it has to start a whole new connection. Another con would be the, minor, additional SYN flood problems - a SYN can now elicit two packets and an additional 30 (or so) bytes from a host. So I think the balance comes out against, but it was very much worth the consideration. Thanks AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 16 10:39:39 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAB653A688B; Wed, 16 Jul 2008 10:39:39 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 428C53A6844 for ; Wed, 16 Jul 2008 10:39:38 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuCbt3E2f2ja for ; Wed, 16 Jul 2008 10:39:37 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by core3.amsl.com (Postfix) with ESMTP id 800523A67EB for ; Wed, 16 Jul 2008 10:39:37 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so3234794pyg.24 for ; Wed, 16 Jul 2008 10:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=+4C7+U9+uXnYuBff4X9beyxk50KEZMW8XZ6B2W8eukM=; b=bo6GYzlKH3MJRbXbUjhAuatm25A7YnVDoTuPz/X+L5JSiEqp4a45QplCwlT708Uj6S dtTHXhwwqSfCMzB3FDeA2c3xuaFOhTi5/Rl04GmHzgOEFdspajqnwNrQ0+8ttzDSoYX4 waGKgwEm0Q0Es2WWGg/N1s2GOsmQj9ZY4QZe8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=W0QzBRPtjhcd1cbE1zSovivOgpoxkYGw6JmMInctZALcseHKyOiZxGSjGKrJgYNUQz FP6/PO3t0w8VsPuXejDWqOJ4A3hdlKULsc4Z/w/4nGMl24TCvq1bg0ITBoQk5W+QsStt 7J8QVjzK2vKuM5TX3KAhlRpiSx2T8bGmMdJxI= Received: by 10.141.49.18 with SMTP id b18mr409351rvk.92.1216230006609; Wed, 16 Jul 2008 10:40:06 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Wed, 16 Jul 2008 10:40:06 -0700 (PDT) Message-ID: <396556a20807161040s21a6a081i326af08add5d7f4e@mail.gmail.com> Date: Wed, 16 Jul 2008 10:40:06 -0700 From: "Adam Langley" To: tcpm@ietf.org In-Reply-To: <396556a20807151736k35564e19h9fc6699e489c94fb@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <20080714234502.AC4793A69F4@core3.amsl.com> <396556a20807151736k35564e19h9fc6699e489c94fb@mail.gmail.com> X-Google-Sender-Auth: 28bca2b0971a53b3 Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Tue, Jul 15, 2008 at 5:36 PM, Adam Langley wrote: > 2008/7/14 : >> Title : The TCP Authentication Option >> Author(s) : J. Touch, et al. >> Filename : draft-ietf-tcpm-tcp-auth-opt-01.txt Another thought: the keyid should be at the beginning of the MAC. We want the options to be 4-byte aligned if at all possible and we want the MAC to also be 4 byte aligned because CPUs have an easier time the aligned data. Currently (with the key ID at the end) the option, on the wire, looks like: NOP OPT 15 <12 bytes of MAC> KeyID (16 bytes, 96-bit MAC) or NOP OPT 19 <16 bytes of MAC> KeyID (20 bytes, 128-bit MAC) Both MACs are unaligned. Moving the KeyID to the beginning means that the MACs would be 4-byte aligned: NOP OPT 15 KeyID <12 bytes of MAC> etc Cheers, AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 16 10:46:06 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F75A3A698C; Wed, 16 Jul 2008 10:46:06 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059323A67B5 for ; Wed, 16 Jul 2008 10:46:05 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPzs-AjLrYy4 for ; Wed, 16 Jul 2008 10:46:01 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by core3.amsl.com (Postfix) with ESMTP id A72293A698C for ; Wed, 16 Jul 2008 10:46:00 -0700 (PDT) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-04.forthnet.gr (8.14.3/8.14.3) with ESMTP id m6GHkTRF006582 for ; Wed, 16 Jul 2008 20:46:29 +0300 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-04.forthnet.gr (8.14.3/8.14.3) with ESMTP id m6GHkTpo025167 for ; Wed, 16 Jul 2008 20:46:29 +0300 Received: from hell.hell.gr (adsl43-134.lsf.forthnet.gr [79.103.170.134]) by MX-IN-01.forthnet.gr (8.14.3/8.14.3) with ESMTP id m6GHkPad001121 for ; Wed, 16 Jul 2008 20:46:26 +0300 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=v13@v13.gr; spf=neutral Authentication-Results: MX-IN-01.forthnet.gr header.from=v13@v13.gr; sender-id=neutral From: Stefanos Harhalakis To: tcpm@ietf.org Date: Wed, 16 Jul 2008 20:46:24 +0300 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807162046.24361.v13@v13.gr> Subject: [tcpm] More TCP options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hello there, AFAICS there is clearly a need for more options space in TCP (especially in a way to extend option negotiation). Even though current needs may be satisfied with workarounds, it is clear that a more generic approach will be needed. I suggest that we find a backwards compatible solution that would allow TCP to become extensible again. I dare to propose one such approach: Add one (final) TCP option that would be negotiated during the initial handshake. This option will eventually initiate a kind of TCPv2 communication that may one day in the future become the de-facto standard. Upon exchanging and agreeing on this option, both sides will be able to support 'long options'. I propose that long options be implemented as an intermediate layer between the existing TCP and the data. Imagine something like this: +------------+-------------------------------------+------+ | TCP Header | Extended TCP Header (Long Options) | Data | +------------+-------------------------------------+------+ Then, middleboxes (NAT boxes) will be unaffected as long they don't re-pack data (is there such a possibility?). The initial option negotiation problem will be solved by: * Permitting cookies to do their job as there will be no extra options in the SYNACK segment. * Allowing extra options to be negotiated by data segments. (A modification to existing TCP semantics). After a successful "extended header" negotiation, all TCP segments should contain an option that indicates the size of the included extend header. This may be 0 for no such options. Having this in mind it will be possible to allow more options to be negotiated using data segments (most probably the first segment). A way for reliably performing such a handshake is also required. I believe that we should have in mind what we would like to have in 10 years from now (and not tomorrow) and that something like the above will be an absolute requirement. Providing such a common infrastructure to TCP will allow most TCP implementations to become compatible in (lets say) N years from now and be able to "survive" for M (M>>N) years more, without loosing backward compatibility. Nonsense ? Already discussed ? _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 16 10:52:16 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 924B63A69C4; Wed, 16 Jul 2008 10:52:16 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 649AB3A67AD for ; Wed, 16 Jul 2008 10:52:15 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqySLBi71ZzJ for ; Wed, 16 Jul 2008 10:52:14 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id AA6C93A69C4 for ; Wed, 16 Jul 2008 10:52:14 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so4994517rvf.49 for ; Wed, 16 Jul 2008 10:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=ZwrCctGiuSuxoE9gj8RAZdBXc6f+10OhbJq4et04Bnc=; b=eGDA9KDpnAA5bcX6nuB56ZppqP/3GGmATrTqsqBvDfF/52IJW02ZTbtENUSDIrTemu qqF+ZyHkQZDBU5foxlKAHlBpeuofE8IP+amXRhowmk5gFwYxpzjf9OBaYZZE3FArT//t xrEdGOp//lAm/sutySsFeD0hQ/24RGfIGYGjE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=XPzlTaQDzS/0EMJIFc+SA2hSvwgD92sJ7uauMnjcQqctgVdjomKdwjB/5Dxeh9vtk4 nhU1YWyJVWDqTk2NYHU4iqER2H8i0H7r2tXq+A/xfL+e6oVtN5iAF59CqM48uSQZjnT6 DLhvqLQNvTuwa74r9jFQ2zIWi3TZHXiSaVYC4= Received: by 10.140.126.14 with SMTP id y14mr427389rvc.96.1216230764373; Wed, 16 Jul 2008 10:52:44 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Wed, 16 Jul 2008 10:52:44 -0700 (PDT) Message-ID: <396556a20807161052i32b0b37bgc12df72f8b596830@mail.gmail.com> Date: Wed, 16 Jul 2008 10:52:44 -0700 From: "Adam Langley" To: "Stefanos Harhalakis" In-Reply-To: <200807162046.24361.v13@v13.gr> MIME-Version: 1.0 Content-Disposition: inline References: <200807162046.24361.v13@v13.gr> X-Google-Sender-Auth: 0a4ff41a9246bf99 Cc: tcpm@ietf.org Subject: Re: [tcpm] More TCP options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, Jul 16, 2008 at 10:46 AM, Stefanos Harhalakis wrote: > Nonsense ? Already discussed ? I believe that the current thinking around this issue is given in http://tools.ietf.org/html/draft-eddy-tcp-loo-04 If you've not already carefully read that, you should, to save reiterating discussions. Also, there's an archive of the tcpm list online: http://www.ietf.org/mail-archive/web/tcpm/current/maillist.html Cheers, AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 16 11:33:55 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 095993A68A1; Wed, 16 Jul 2008 11:33:55 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 431FA3A68A1 for ; Wed, 16 Jul 2008 11:33:54 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVdQYY4jJ94R for ; Wed, 16 Jul 2008 11:33:53 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id 1DD713A67B5 for ; Wed, 16 Jul 2008 11:33:53 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so5005449rvf.49 for ; Wed, 16 Jul 2008 11:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=3YfKddd6Sn/OTCr7DuZzXdElBfKcGsXtSVOoQ0tce5M=; b=QUyBUMO8QWcDUduFY/AtcQz4aSWJDZRPScLLjke1x308V29zQvpAUGff3igxmEaFQN +QH7Ma9h40F4ZbfezpDf0aAlXYJtyS8Gr6QbZ+6fyVz4TejDQmQZLHx8IT3QF46MKaXW MCHbu8k+nxspcVrvrAmvb7YZNBmRgHPGv0TLk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=rM8BFXpyPHcZ7rkDYkR56fyYXxYvfRMG+knTdc26vg8/Cm0Otrp7uqNUw7Td8hipeY WZuruGz7eWLHXq7CiYum50Uvkk8ctiEWUBS+WaVFQ0kLl2hK7yrLtovRj6Vs9Kc4q0kw Wdv+LzlOBIeQshAk7OeCSHAt5Y6mOftUfbQvM= Received: by 10.141.172.6 with SMTP id z6mr485233rvo.112.1216233260990; Wed, 16 Jul 2008 11:34:20 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Wed, 16 Jul 2008 11:34:20 -0700 (PDT) Message-ID: <396556a20807161134y193dfbccnb5de836cb5108a06@mail.gmail.com> Date: Wed, 16 Jul 2008 11:34:20 -0700 From: "Adam Langley" To: "Stefanos Harhalakis" In-Reply-To: <200807162109.58250.v13@it.teithe.gr> MIME-Version: 1.0 Content-Disposition: inline References: <200807162046.24361.v13@v13.gr> <396556a20807161052i32b0b37bgc12df72f8b596830@mail.gmail.com> <200807162109.58250.v13@it.teithe.gr> X-Google-Sender-Auth: 8c7eba7755758693 Cc: tcpm@ietf.org Subject: Re: [tcpm] More TCP options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, Jul 16, 2008 at 11:09 AM, Stefanos Harhalakis wrote: > Please excuse my ignorance. After (carefully) reading the draft I see that it > already describes everything I proposed and addresses the concerns too. I'll > try to be more carefull in the future. No apologies needed! Although no one is scheduled to give a presentation of long options at the next IETF meeting[1], I expect there will be some discussion. If you have a use case for long options you might want to tell the list about it. Currently I don't believe there's a really compelling one. Cheers [1] http://www.ietf.org/meetings/72/ -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 16 11:41:19 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 846293A67EB; Wed, 16 Jul 2008 11:41:19 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AADDF3A63EC for ; Wed, 16 Jul 2008 11:41: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaCk+716geeO for ; Wed, 16 Jul 2008 11:41:17 -0700 (PDT) Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by core3.amsl.com (Postfix) with ESMTP id BD31B3A67EB for ; Wed, 16 Jul 2008 11:41:16 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Jul 2008 14:41:46 -0400 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7703E6760F@nekter> In-Reply-To: <200807162046.24361.v13@v13.gr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] More TCP options Thread-Index: Acjna/D3nuiYGfhhQziQ3b3TTcnc9QABv7ww References: <200807162046.24361.v13@v13.gr> From: "Caitlin Bestler" To: "Stefanos Harhalakis" , Subject: Re: [tcpm] More TCP options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Stefanos Harhalakis wrote: > > Upon exchanging and agreeing on this option, both sides will be able to > support 'long options'. I propose that long options be implemented as > an intermediate layer between the existing TCP and the data. Imagine > something like this: > > +------------+-------------------------------------+------+ > | TCP Header | Extended TCP Header (Long Options) | Data | > +------------+-------------------------------------+------+ > > Then, middleboxes (NAT boxes) will be unaffected as long they don't re- > pack data (is there such a possibility?). > Very definitely. See RFC 5044 on what RDMA had to do to work around these problems. The bottom line is that the TCP Data Stream is a stream, and no offload NIC or middle-box is obligated to understand it as having any other structure. The best you can do is to create an endpoint agreement that they will exchange certain information in the payload, and only proceed farther if they are in agreement. Something like that might be possible as an endpoint solution, and still be exercised by the TCP stacks themselves. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 16 12:39:05 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE9953A687D; Wed, 16 Jul 2008 12:39:05 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83EE53A683C for ; Wed, 16 Jul 2008 12:39:04 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWQy9N+bb1Qa for ; Wed, 16 Jul 2008 12:39:03 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id BB2FE3A6953 for ; Wed, 16 Jul 2008 12:39:03 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id C19DB3284B2; Wed, 16 Jul 2008 14:39:31 -0500 (CDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsppt02.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id m6GJdWPu022034; Wed, 16 Jul 2008 14:39:32 -0500 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jul 2008 14:39:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Jul 2008 14:39:32 -0500 Message-ID: In-Reply-To: <396556a20807161134y193dfbccnb5de836cb5108a06@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] More TCP options Thread-Index: AcjncpcsSl+VyWKlS5CkYXZ46bFvrQACFuwg References: <200807162046.24361.v13@v13.gr><396556a20807161052i32b0b37bgc12df72f8b596830@mail.gmail.com><200807162109.58250.v13@it.teithe.gr> <396556a20807161134y193dfbccnb5de836cb5108a06@mail.gmail.com> From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: "Adam Langley" , "Stefanos Harhalakis" X-OriginalArrivalTime: 16 Jul 2008 19:39:31.0681 (UTC) FILETIME=[AB0D0510:01C8E77B] Cc: tcpm@ietf.org Subject: Re: [tcpm] More TCP options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >Behalf Of Adam Langley >Sent: Wednesday, July 16, 2008 2:34 PM > >No apologies needed! Although no one is scheduled to give a >presentation of long options at the next IETF meeting[1], I expect >there will be some discussion. If you have a use case for long options >you might want to tell the list about it. Currently I don't believe >there's a really compelling one. There's plenty of meeting time left, based on the current agenda requests: http://www.ietf.org/proceedings/08jul/agenda/tcpm.txt If someone wants to give a presentation to spur some face-to-face discussion, there seems to be enough mailing list discussion from different people to warrant it. Are there any volunteers? _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 16 14:13:33 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDC933A69C6; Wed, 16 Jul 2008 14:13:33 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84D713A69C5 for ; Wed, 16 Jul 2008 14:13:32 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Z2tCwdepIkv for ; Wed, 16 Jul 2008 14:13:31 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id B095C3A69B6 for ; Wed, 16 Jul 2008 14:13:31 -0700 (PDT) Received: from [127.0.0.1] (242.sub-75-211-44.myvzw.com [75.211.44.242]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6GLDRao015983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 Jul 2008 14:13:31 -0700 (PDT) Message-ID: <487E6475.30107@isi.edu> Date: Wed, 16 Jul 2008 14:13:25 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Adam Langley References: <20080714234502.AC4793A69F4@core3.amsl.com> <396556a20807151736k35564e19h9fc6699e489c94fb@mail.gmail.com> <396556a20807161040s21a6a081i326af08add5d7f4e@mail.gmail.com> In-Reply-To: <396556a20807161040s21a6a081i326af08add5d7f4e@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1406412672==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1406412672== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2662B49E70B662D7384B1F68" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2662B49E70B662D7384B1F68 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Adam Langley wrote: > On Tue, Jul 15, 2008 at 5:36 PM, Adam Langley = wrote: >> 2008/7/14 : >>> Title : The TCP Authentication Option >>> Author(s) : J. Touch, et al. >>> Filename : draft-ietf-tcpm-tcp-auth-opt-01.txt >=20 > Another thought: the keyid should be at the beginning of the MAC. We > want the options to be 4-byte aligned if at all possible and we want > the MAC to also be 4 byte aligned because CPUs have an easier time the > aligned data. We can place the keyID wherever it's most useful; note that putting the=20 KeyID at the front will probably make the MAC non-wordaligned. > Currently (with the key ID at the end) the option, on the wire, looks l= ike: > NOP OPT 15 <12 bytes of MAC> KeyID (16 bytes, 96-bit MAC) > or > NOP OPT 19 <16 bytes of MAC> KeyID (20 bytes, 128-bit MAC) >=20 > Both MACs are unaligned. Moving the KeyID to the beginning means that > the MACs would be 4-byte aligned: > NOP OPT 15 KeyID <12 bytes of MAC> etc This presumes that we misalign the option to start, using the NOP. I=20 would prefer to assume that the option starts word-aligned. I don't see=20 a way to do that, though, without wasting another byte in the option.=20 The goal is currently to assume a half-word aligned start, and let the=20 next option decide whether to pad or not. At that point, it's better to=20 leave the MAC half-word aligned too. I.e., there are various concerns here, and a solution isn't very clear.=20 Thoughts from anyone else on this? Joe --------------enig2662B49E70B662D7384B1F68 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIfmR1E5f5cImnZrsRAkrcAKD1lgMt7ZOW+xEs1KAhDSN9e5sNuwCdGEa/ 8zqVetj7Me4D+/OEbUdanj4= =9sBd -----END PGP SIGNATURE----- --------------enig2662B49E70B662D7384B1F68-- --===============1406412672== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1406412672==-- From tcpm-bounces@ietf.org Wed Jul 16 14:21:43 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 988F33A6A08; Wed, 16 Jul 2008 14:21:43 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 737DD3A68AD for ; Wed, 16 Jul 2008 14:21:42 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rw4uOu5vWfDh for ; Wed, 16 Jul 2008 14:21:41 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 810863A6A06 for ; Wed, 16 Jul 2008 14:21:08 -0700 (PDT) Received: from [127.0.0.1] (242.sub-75-211-44.myvzw.com [75.211.44.242]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6GLH5e2017535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 Jul 2008 14:17:09 -0700 (PDT) Message-ID: <487E6550.3030502@isi.edu> Date: Wed, 16 Jul 2008 14:17:04 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Stefanos Harhalakis References: <200807162046.24361.v13@v13.gr> In-Reply-To: <200807162046.24361.v13@v13.gr> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] More TCP options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2022031596==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2022031596== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigED6B7AA5513677D5848CE770" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigED6B7AA5513677D5848CE770 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Stefanos Harhalakis wrote: > Hello there, >=20 > AFAICS there is clearly a need for more options space in TCP (especiall= y in a=20 > way to extend option negotiation). Even though current needs may be sat= isfied=20 > with workarounds, it is clear that a more generic approach will be need= ed. >=20 > I suggest that we find a backwards compatible solution that would allow= TCP to=20 > become extensible again. >=20 > I dare to propose one such approach: >=20 > Add one (final) TCP option that would be negotiated during the initial = > handshake. This option will eventually initiate a kind of TCPv2 communi= cation=20 > that may one day in the future become the de-facto standard. >=20 > Upon exchanging and agreeing on this option, both sides will be able to= =20 > support 'long options'. This is equivalent to a required TCP option. There's no such thing; if=20 the other side doesn't support the option, it will return a SYN/ACK=20 (granted, without the appropriate response). The trouble is that the only solution is to RST that connection. That=20 means that the new TCP is NOT backward compatible. There's no such=20 thing, as a result. You might as well pick another protocol number, at=20 which point you can redefine the protocol fields however you like. > Nonsense ? Already discussed ?=20 I do think we've been around this block before; it led to Mark Allman's=20 "double everything" proposal. If it's worth discussing in Dublin, it=20 might be useful, but I encourage others to review the archives on this=20 topic. Joe --------------enigED6B7AA5513677D5848CE770 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIfmVQE5f5cImnZrsRAvZJAKC4+i+jfoOd9mLm8xauVfQfN1TqegCgi5Z3 Di2BFqbtUub3IlxgRCPFlrc= =rTW7 -----END PGP SIGNATURE----- --------------enigED6B7AA5513677D5848CE770-- --===============2022031596== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============2022031596==-- From tcpm-bounces@ietf.org Wed Jul 16 14:53:45 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0FCE3A696F; Wed, 16 Jul 2008 14:53:45 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 255313A69CA for ; Wed, 16 Jul 2008 14:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.827 X-Spam-Level: X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIkO8SQE6K8q for ; Wed, 16 Jul 2008 14:53:43 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 4947C3A696F for ; Wed, 16 Jul 2008 14:53:43 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so5056609rvf.49 for ; Wed, 16 Jul 2008 14:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=20kWud63nprlGxoDLR78UCQQR4gqxBefzYMjb1z5fZA=; b=k7cLQOuYsNowjaEVpit2+qLOtNPFVLVrW1kC/MALyaphOwcgbuAPP4DfCj0BV56RT3 AEdG3KDUubyDNYvqIsdGVxU0OtmvgiAnYVaPDT77AR5ffMdkX+KkC+HZGIoF+Ivt3kXH qk3tWIYZxcm1GUeZnxZljGHXTFBKyoVxQH/kg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=tsO2x1UBQUdxRunRARzoa3mJkNNB+synYazrVwCUUD1nROXdc5jXpV5iG5aLdeCMRS JkH+fEHYN+/o3YUMFLxcbdnzjaCjoJlvvUTqNZ6gAm3ZoFruUVjOkdX3txWGamTwsbhK ap9jliT2Z6MW/HQb8SyDG2jETB30VROgVqZYM= Received: by 10.140.133.9 with SMTP id g9mr682189rvd.235.1216245253489; Wed, 16 Jul 2008 14:54:13 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Wed, 16 Jul 2008 14:54:13 -0700 (PDT) Message-ID: <396556a20807161454g14346470g89ce7d87ff4379c9@mail.gmail.com> Date: Wed, 16 Jul 2008 14:54:13 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <487E6475.30107@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <20080714234502.AC4793A69F4@core3.amsl.com> <396556a20807151736k35564e19h9fc6699e489c94fb@mail.gmail.com> <396556a20807161040s21a6a081i326af08add5d7f4e@mail.gmail.com> <487E6475.30107@isi.edu> X-Google-Sender-Auth: e8a12b0b9660b8c3 Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, Jul 16, 2008 at 2:13 PM, Joe Touch wrote: > This presumes that we misalign the option to start, using the NOP. I would > prefer to assume that the option starts word-aligned. I don't see a way to > do that, though, without wasting another byte in the option. The goal is > currently to assume a half-word aligned start, and let the next option > decide whether to pad or not. At that point, it's better to leave the MAC > half-word aligned too. Just as a couple of data points: * Linux writes options in 32-bit chunks and pads with NOPs before the option to make the option a multiple of 4 bytes long * FreeBSD appears to pad with NOPs before the option too[1] [1] http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/netinet/tcp_output.c?rev=1.151;content-type=text%2Fplain tcp_addoptions function AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 16 15:38:10 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6E793A67FE; Wed, 16 Jul 2008 15:38:10 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEA7C3A6821 for ; Wed, 16 Jul 2008 15:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSVafF6O2n59 for ; Wed, 16 Jul 2008 15:38:09 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 37E273A67FE for ; Wed, 16 Jul 2008 15:38:09 -0700 (PDT) Received: from [127.0.0.1] (68.sub-75-208-144.myvzw.com [75.208.144.68]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6GMcJwL020314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 Jul 2008 15:38:22 -0700 (PDT) Message-ID: <487E7859.3090409@isi.edu> Date: Wed, 16 Jul 2008 15:38:17 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Adam Langley References: <20080714234502.AC4793A69F4@core3.amsl.com> <396556a20807151736k35564e19h9fc6699e489c94fb@mail.gmail.com> <396556a20807161040s21a6a081i326af08add5d7f4e@mail.gmail.com> <487E6475.30107@isi.edu> <396556a20807161454g14346470g89ce7d87ff4379c9@mail.gmail.com> In-Reply-To: <396556a20807161454g14346470g89ce7d87ff4379c9@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0986164351==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0986164351== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCDE256D306DBBFDE51F9AD7A" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCDE256D306DBBFDE51F9AD7A Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Adam Langley wrote: > On Wed, Jul 16, 2008 at 2:13 PM, Joe Touch wrote: >> This presumes that we misalign the option to start, using the NOP. I w= ould >> prefer to assume that the option starts word-aligned. I don't see a wa= y to >> do that, though, without wasting another byte in the option. The goal = is >> currently to assume a half-word aligned start, and let the next option= >> decide whether to pad or not. At that point, it's better to leave the = MAC >> half-word aligned too. >=20 > Just as a couple of data points: > * Linux writes options in 32-bit chunks and pads with NOPs before > the option to make the option a multiple of 4 bytes long > * FreeBSD appears to pad with NOPs before the option too[1] Both of these seem strange. They end up making the end of the option=20 align, but disturb the front of the option. Why don't they pad at the end= ? (TCP requires only that the last option have that pad, too) Joe --------------enigCDE256D306DBBFDE51F9AD7A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIfnhZE5f5cImnZrsRAiQbAJ0cz3czGhW51k31mq5n/8RWIWdw4ACg/CXw oqh8bWMHoOdjAEmPtDYMRCw= =hcOS -----END PGP SIGNATURE----- --------------enigCDE256D306DBBFDE51F9AD7A-- --===============0986164351== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0986164351==-- From tcpm-bounces@ietf.org Wed Jul 16 16:08:49 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD29B3A68EA; Wed, 16 Jul 2008 16:08:49 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67FE93A68EF for ; Wed, 16 Jul 2008 16:08:48 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6d43NZcvykV1 for ; Wed, 16 Jul 2008 16:08:47 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by core3.amsl.com (Postfix) with ESMTP id 8CCB03A68EA for ; Wed, 16 Jul 2008 16:08:47 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so3311315pyg.24 for ; Wed, 16 Jul 2008 16:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=doD99jYtiFk9AnhRKgQbyus2MZ2VE5DaS+VPM2gWnwE=; b=VNw07rE8COe5oMckthCXz+r6ZZOIMSQk3D9LYDiBvke0TBnjj/FtEqIhIlmVUD/kfH Y96YyNHpjWmrxlwuxOZHUyuhhfX/Kn54t2kTuledknHcK+PmFsSvDrFivh3G2oDsesfm uaNVv+kyp+aWGImopbZV/JzevX9twULzqNcMo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=qKOS2fg3bVC7rWDToFzg01e/C/J9drlCho1mISC9EOWsweuqwy1MF0V3qEKxQuwZSG r7Ewrjd9c4ldNIH8Jvs5Y/23pzJeqcsg5UUeEZ0N9wOVDC3BjaEx5ym9U9dyk6HF+xI6 y4ZNaIKFmj3sOhBV1NIvfFDed3h/KAjeA1Bgg= Received: by 10.141.49.6 with SMTP id b6mr726194rvk.223.1216249755199; Wed, 16 Jul 2008 16:09:15 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Wed, 16 Jul 2008 16:09:15 -0700 (PDT) Message-ID: <396556a20807161609x455948f8qa40414799b64de72@mail.gmail.com> Date: Wed, 16 Jul 2008 16:09:15 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <487E7859.3090409@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <20080714234502.AC4793A69F4@core3.amsl.com> <396556a20807151736k35564e19h9fc6699e489c94fb@mail.gmail.com> <396556a20807161040s21a6a081i326af08add5d7f4e@mail.gmail.com> <487E6475.30107@isi.edu> <396556a20807161454g14346470g89ce7d87ff4379c9@mail.gmail.com> <487E7859.3090409@isi.edu> X-Google-Sender-Auth: 810e2838a43748f7 Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, Jul 16, 2008 at 3:38 PM, Joe Touch wrote: > Both of these seem strange. They end up making the end of the option align, > but disturb the front of the option. Why don't they pad at the end? So here's my hypothesis (and it's only a guess really): It's good to write in 32-bit words for speed reasons. Also, some architectures make writing non-aligned 32-bit words hard. Now, consider the SACK and timestamp options, you want to write a 32-bit header followed by a payload (2 32-bit words for timestamp and 2*n words for SACK). So you want the payload to be 32-bit aligned for both writing and reading. So you end up with: uint32_t *ptr; *ptr++ = htonl((NOP << 24) | (NOP << 16) | (TCP_OPT_TS << 8) | length) *ptr++ = htonl(timestamp_1) *ptr++ = htonl(timestamp_2) and, from the timestamp and SACK options all the others keep the same style of padding with NOPs before the option. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 16 16:13:44 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E99113A68EA; Wed, 16 Jul 2008 16:13:44 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89FA13A68EA for ; Wed, 16 Jul 2008 16:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZIjbHkvrkek for ; Wed, 16 Jul 2008 16:13:42 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id C2D093A683F for ; Wed, 16 Jul 2008 16:13:42 -0700 (PDT) Received: from [127.0.0.1] (68.sub-75-208-144.myvzw.com [75.208.144.68]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6GNDfXh002891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 Jul 2008 16:13:44 -0700 (PDT) Message-ID: <487E809C.7090608@isi.edu> Date: Wed, 16 Jul 2008 16:13:32 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Adam Langley References: <20080714234502.AC4793A69F4@core3.amsl.com> <396556a20807151736k35564e19h9fc6699e489c94fb@mail.gmail.com> <396556a20807161040s21a6a081i326af08add5d7f4e@mail.gmail.com> <487E6475.30107@isi.edu> <396556a20807161454g14346470g89ce7d87ff4379c9@mail.gmail.com> <487E7859.3090409@isi.edu> <396556a20807161609x455948f8qa40414799b64de72@mail.gmail.com> In-Reply-To: <396556a20807161609x455948f8qa40414799b64de72@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0941871425==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0941871425== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD05D4EDE71A53430B282FDF5" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD05D4EDE71A53430B282FDF5 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Adam Langley wrote: > On Wed, Jul 16, 2008 at 3:38 PM, Joe Touch wrote: >> Both of these seem strange. They end up making the end of the option a= lign, >> but disturb the front of the option. Why don't they pad at the end? >=20 > So here's my hypothesis (and it's only a guess really): >=20 > It's good to write in 32-bit words for speed reasons. Also, some > architectures make writing non-aligned 32-bit words hard. Now, > consider the SACK and timestamp options, you want to write a 32-bit > header followed by a payload (2 32-bit words for timestamp and 2*n > words for SACK). So you want the payload to be 32-bit aligned for both > writing and reading.=20 That makes sense, but putting the pad at the beginning of every option=20 vs. at the end of that option makes no sense AFIACT. (putting the pad for each option is inefficient, esp. since options=20 aren't all that big a space and need to be byte-parsed anyway). Joe --------------enigD05D4EDE71A53430B282FDF5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIfoCjE5f5cImnZrsRAsxWAJ4wSF3yyrNI/XIWw6FXX05QCQFnRQCgkL9u aStc2htFytY++OGHAYGXt8k= =7Cun -----END PGP SIGNATURE----- --------------enigD05D4EDE71A53430B282FDF5-- --===============0941871425== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0941871425==-- From tcpm-bounces@ietf.org Wed Jul 16 17:25:39 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 084B53A68D8; Wed, 16 Jul 2008 17:25:39 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F1703A68D8 for ; Wed, 16 Jul 2008 17:25:37 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T11SZairJCAO for ; Wed, 16 Jul 2008 17:25:36 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by core3.amsl.com (Postfix) with ESMTP id 4AA4F3A680F for ; Wed, 16 Jul 2008 17:25:36 -0700 (PDT) Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-06.forthnet.gr (8.14.3/8.14.3) with ESMTP id m6H0Q4dk031909; Thu, 17 Jul 2008 03:26:04 +0300 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-05.forthnet.gr (8.14.3/8.14.3) with ESMTP id m6H0Q4NA013245; Thu, 17 Jul 2008 03:26:04 +0300 Received: from hell.hell.gr (adsl43-134.lsf.forthnet.gr [79.103.170.134]) by MX-IN-01.forthnet.gr (8.14.3/8.14.3) with ESMTP id m6H0Q1ir023570; Thu, 17 Jul 2008 03:26:03 +0300 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=v13@v13.gr; spf=neutral Authentication-Results: MX-IN-01.forthnet.gr header.from=v13@v13.gr; sender-id=neutral From: Stefanos Harhalakis To: tcpm@ietf.org Date: Thu, 17 Jul 2008 03:25:59 +0300 User-Agent: KMail/1.9.9 References: <20080714234502.AC4793A69F4@core3.amsl.com> <396556a20807161609x455948f8qa40414799b64de72@mail.gmail.com> <487E809C.7090608@isi.edu> In-Reply-To: <487E809C.7090608@isi.edu> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807170325.59866.v13@v13.gr> Cc: Adam Langley , Joe Touch Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Thursday 17 July 2008, Joe Touch wrote: > Adam Langley wrote: > > On Wed, Jul 16, 2008 at 3:38 PM, Joe Touch wrote: > >> Both of these seem strange. They end up making the end of the option > >> align, but disturb the front of the option. Why don't they pad at the > >> end? > > > > So here's my hypothesis (and it's only a guess really): > > > > It's good to write in 32-bit words for speed reasons. Also, some > > architectures make writing non-aligned 32-bit words hard. Now, > > consider the SACK and timestamp options, you want to write a 32-bit > > header followed by a payload (2 32-bit words for timestamp and 2*n > > words for SACK). So you want the payload to be 32-bit aligned for both > > writing and reading. > > That makes sense, but putting the pad at the beginning of every option > vs. at the end of that option makes no sense AFIACT. If I see this correctly, it makes no difference at all since the padding will be added after all. It seems more as a matter of programming convenience. Indeed TIMESTAMPs, SACK and MD5 are added with 16 bit padding each in data segments and something similar happens for syn segments too. > (putting the pad for each option is inefficient, esp. since options > aren't all that big a space and need to be byte-parsed anyway). (In linux kernel) When using timestamps and SACK, a word (32bits) is filled with NOPs.I believe that the current approach is an accepted one since it doesn't violate any RFC and it doesn't reduce the available space long enough to cause problems. Is there a way that the extra 32 bits could be used (as of today)? Apart from that, I believe that you (we) should fill a bug report. FYI: Git shows that the oldest corresponding lines were last changed at 2006 by Stephen Hemminger and Yoshifuji Hideaki. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 16 17:40:44 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73CE53A6812; Wed, 16 Jul 2008 17:40:44 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 992333A68BD for ; Wed, 16 Jul 2008 17:40:43 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XKgTAUdYGCm for ; Wed, 16 Jul 2008 17:40:42 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 97EED3A6812 for ; Wed, 16 Jul 2008 17:40:42 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so1637437yxg.49 for ; Wed, 16 Jul 2008 17:41:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=vPn80AMMUrO7rX75qXJuoSv2cTPLzue4NdFjB1dPFAU=; b=c1EcUPFx2t7k5Ys1QZ/wxx/ngeHySXQkjPsBAFIO4SS0pEIWGkC5y4i9zrjr2YBUh7 6Dip7Md3XpcbLy56qQeA/AKx6Dg9ZxSITbkMb7UHbz28Q8/k/KZqeWdblQZZhsEQrQz2 gJbzhL9WAEMSk+KNdq/nba0pZfXGBmKyz7sPQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=NehGth6jBonphmRC9pz8B5Mxxlg8BmmsQQs+dGP8m2wlC3AhFsB26+DHaVds8Ly5Me wod1AtTtqQZT0x/gwmSjszOIJKrdHaYlUArqjKKs/sKhQYLrX5V2HZCSqkk21nsskkk1 99djFYoEby2ca3m9CqpB90svp4UqOJ2EKU6JQ= Received: by 10.141.133.14 with SMTP id k14mr797481rvn.127.1216255270936; Wed, 16 Jul 2008 17:41:10 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Wed, 16 Jul 2008 17:41:10 -0700 (PDT) Message-ID: <396556a20807161741p20cb4902l50f14856b8332716@mail.gmail.com> Date: Wed, 16 Jul 2008 17:41:10 -0700 From: "Adam Langley" To: "Stefanos Harhalakis" In-Reply-To: <200807170325.59866.v13@v13.gr> MIME-Version: 1.0 Content-Disposition: inline References: <20080714234502.AC4793A69F4@core3.amsl.com> <396556a20807161609x455948f8qa40414799b64de72@mail.gmail.com> <487E809C.7090608@isi.edu> <200807170325.59866.v13@v13.gr> X-Google-Sender-Auth: 8de55c9fd8379c33 Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, Jul 16, 2008 at 5:25 PM, Stefanos Harhalakis wrote: > Apart from that, I believe that you (we) should fill a bug report. Well, since I was the last person to rewrite the options code in Linux(*), you might as well tell me here :) I'm not sure exactly what the issue is here. There isn't excessive padding: 99.9% of packets have only a timestamp option and thus have the minimal amount of padding. The advantage of writing/reading aligned data outweighs better compaction in SYN frames since there's (currently) no options that we excluded because of the padding. (*) it should be in .27, maybe .28 AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jul 18 07:32:32 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2925B3A686E; Fri, 18 Jul 2008 07:32:32 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF4713A684A for ; Fri, 18 Jul 2008 07:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ye2zunAfIaQV for ; Fri, 18 Jul 2008 07:32:30 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by core3.amsl.com (Postfix) with ESMTP id A86153A68AC for ; Fri, 18 Jul 2008 07:32:29 -0700 (PDT) Received: from mx-av-06.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.14.3/8.14.3) with ESMTP id m6IEX0Tn017369; Fri, 18 Jul 2008 17:33:00 +0300 Received: from MX-IN-02.forthnet.gr (mx-in-02.forthnet.gr [193.92.150.185]) by mx-av-06.forthnet.gr (8.14.3/8.14.3) with ESMTP id m6IEX0kN024145; Fri, 18 Jul 2008 17:33:00 +0300 Received: from hell.hell.gr (adsl43-134.lsf.forthnet.gr [79.103.170.134]) by MX-IN-02.forthnet.gr (8.14.3/8.14.3) with ESMTP id m6IEWowx024027; Fri, 18 Jul 2008 17:32:52 +0300 Authentication-Results: MX-IN-02.forthnet.gr smtp.mail=v13@v13.gr; spf=neutral Authentication-Results: MX-IN-02.forthnet.gr header.from=v13@v13.gr; sender-id=neutral From: Stefanos Harhalakis To: "Adam Langley" Date: Fri, 18 Jul 2008 17:32:50 +0300 User-Agent: KMail/1.9.9 References: <20080714234502.AC4793A69F4@core3.amsl.com> <200807170325.59866.v13@v13.gr> <396556a20807161741p20cb4902l50f14856b8332716@mail.gmail.com> In-Reply-To: <396556a20807161741p20cb4902l50f14856b8332716@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807181732.51217.v13@v13.gr> Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Thursday 17 July 2008, Adam Langley wrote: > On Wed, Jul 16, 2008 at 5:25 PM, Stefanos Harhalakis wrote: > > Apart from that, I believe that you (we) should fill a bug report. > > Well, since I was the last person to rewrite the options code in > Linux(*), you might as well tell me here :) > > I'm not sure exactly what the issue is here. There isn't excessive > padding: 99.9% of packets have only a timestamp option and thus have > the minimal amount of padding. The advantage of writing/reading > aligned data outweighs better compaction in SYN frames since there's > (currently) no options that we excluded because of the padding. There are not many more things to report that those discussed in the list: * The ability to store more options when necessary * 4 bytes of extra space for data when TSs and SACKs are included * 4xN less bytes transmitted over the network in each session (where N is the number of segments with TS+SACK that are sent) >From a very sallow test/accounting I've just performed (1 minute run) on a linux firewall for a not so large, not congested network, it seems that about 3-4% of the TS segments also include a SACK header and that there could be saved about 1 byte every 7-8 TS-enabled segments (not counting SYN segments). Sample results: ts: 7497, tssack: 255, noop: 1020 ts: 8133, tssack: 347, noop: 1388 ts: 7295, tssack: 270, noop: 1080 ts: 7030, tssack: 265, noop: 1060 ts: 7162, tssack: 234, noop: 936 ts: 7328, tssack: 294, noop: 1176 1st column is segments with TS, second is segments with TS+SACK (also counted in first column), third column is SUM(floor(NOOP_count/4)*4) (number of bytes that where transmitted as NOOP and could be saved (only counts 32 bit words)). Is it worth? _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jul 18 07:53:31 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 404E13A6AC0; Fri, 18 Jul 2008 07:53:31 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D1993A6ABF for ; Fri, 18 Jul 2008 07:53:30 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLX8A6jAhTq6 for ; Fri, 18 Jul 2008 07:53:29 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 297003A6ABA for ; Fri, 18 Jul 2008 07:53:29 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id E8687328386 for ; Fri, 18 Jul 2008 09:54:01 -0500 (CDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsppt02.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id m6IEs1jO009052 for ; Fri, 18 Jul 2008 09:54:01 -0500 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Jul 2008 09:54:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 18 Jul 2008 09:54:02 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: working group last call for 4138bis F-RTO draft Thread-Index: Acjo5h3Mv8FI5arLQFu7JG25qsK6ig== From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: X-OriginalArrivalTime: 18 Jul 2008 14:54:02.0115 (UTC) FILETIME=[1DDC2D30:01C8E8E6] Subject: [tcpm] working group last call for 4138bis F-RTO draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At a prior meeting, it was determined that the F-RTO draft was ready for working group last call. We would like to start the WGLC on the recent update: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc4138bis-02.txt This will last until August 8, because of the Dublin meeting falling in the middle of the WGLC. As usual, read the draft, and send any issues, comments, or suggested corrections to this mailing list. As an FYI, I recently noticed this draft, which has some helpful guidelines for writing reviews, in my opinion: http://www.ietf.org/internet-drafts/draft-krishnan-review-process-01.txt It might be of interest, but it's not required to follow or anything like that. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jul 18 08:59:56 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 233EC3A6B03; Fri, 18 Jul 2008 08:59:56 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BD053A6AF8 for ; Fri, 18 Jul 2008 08:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGT0rFQPFq7E for ; Fri, 18 Jul 2008 08:59:54 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 8124D28C187 for ; Fri, 18 Jul 2008 08:59:54 -0700 (PDT) Received: from webmail.isi.edu (webmail.isi.edu [128.9.152.28]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6IFxr1D027392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 18 Jul 2008 08:59:55 -0700 (PDT) Received: (from apache@localhost) by webmail.isi.edu (8.12.8/8.12.7) id m6IFxpjr030492; Fri, 18 Jul 2008 08:59:51 -0700 X-Authentication-Warning: webmail.isi.edu: apache set sender to touch@isi.edu using -f Received: from pool-71-106-110-19.lsanca.dsl-w.verizon.net (pool-71-106-110-19.lsanca.dsl-w.verizon.net [71.106.110.19]) by webmail.isi.edu (IMP) with HTTP for ; Fri, 18 Jul 2008 08:59:51 -0700 Message-ID: <1216396791.4880bdf78c97b@webmail.isi.edu> Date: Fri, 18 Jul 2008 08:59:51 -0700 From: touch@ISI.EDU To: Stefanos Harhalakis References: <20080714234502.AC4793A69F4@core3.amsl.com> <200807170325.59866.v13@v13.gr> <396556a20807161741p20cb4902l50f14856b8332716@mail.gmail.com> <200807181732.51217.v13@v13.gr> In-Reply-To: <200807181732.51217.v13@v13.gr> MIME-Version: 1.0 User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 71.106.110.19 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Quoting Stefanos Harhalakis : .. > There are not many more things to report that those discussed in the list: > * The ability to store more options when necessary > * 4 bytes of extra space for data when TSs and SACKs are included > * 4xN less bytes transmitted over the network in each session (where N is the > > number of segments with TS+SACK that are sent) > > From a very sallow test/accounting I've just performed (1 minute run) on a > linux firewall for a not so large, not congested network, it seems that about > > 3-4% of the TS segments also include a SACK header and that there could be > saved about 1 byte every 7-8 TS-enabled segments (not counting SYN > segments). .. > that where transmitted as NOOP and could be saved (only counts 32 bit > words)). > > Is it worth? If nothing changes, probably not. However, legacy TCP is likely to be around for a while, so conservation is critical to using that space for other things. Also, the space is most critical in the SYNs; that is the only place where capabilities are negotiated. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jul 18 10:36:13 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 332E228C1FD; Fri, 18 Jul 2008 10:36:13 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7AB828C1FD; Fri, 18 Jul 2008 10:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[AWL=-0.842, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_PROXY=1.643, SARE_RECV_SPEEDY_AR=0.808] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQQeCK4yxaeI; Fri, 18 Jul 2008 10:36:11 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 0B6F028C1B2; Fri, 18 Jul 2008 10:36:09 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id DA27D6B6764; Fri, 18 Jul 2008 14:36:43 -0300 (ART) Received: from notebook.gont.com.ar (201-254-34-122.speedy.com.ar [201.254.34.122] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id m6IHaWB3006186; Fri, 18 Jul 2008 14:36:32 -0300 Message-Id: <200807181736.m6IHaWB3006186@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 18 Jul 2008 14:33:07 -0300 To: Jari Arkko , iesg@ietf.org, tcpm@ietf.org From: Fernando Gont In-Reply-To: <20080717102200.0757D3A69C6@core3.amsl.com> References: <20080717102200.0757D3A69C6@core3.amsl.com> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Fri, 18 Jul 2008 14:36:43 -0300 (ART) Cc: tcpm-chairs@tools.ietf.org, david.borman@windriver.com, weddy@grc.nasa.gov, draft-ietf-tcpm-tcp-soft-errors@tools.ietf.org Subject: Re: [tcpm] DISCUSS: draft-ietf-tcpm-tcp-soft-errors X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 07:22 a.m. 17/07/2008, Jari Arkko wrote: >First, I was unable to find any evidence of review from the 6MAN or V6OPS >communities. No request for review has been posted to the lists, at least. >Has there been such review, and if not, can we ensure it happens now? >Normally, in general and in particularly for Informational documents IETF >Last Call suffices, but as I outlined above, this specification is >important enough to warrant that we get it right. Actually, the document took off from an initial ID from v6ops. e.g., the "Contributors" section in the draft acknowledges this (also it does not explicitly reference the v6ops wg). >Section 2.1 says: > > When receiving an ICMP error message that indicates a hard error > condition, TCP will simply abort the corresponding connection, > regardless of the connection state. > >Question. I was under the impression that recent specifications have >started to say to not blindly believe ICMP errors due to denial- >of-service concerns? If this is not the case, then no problem. I'm the author of the TCPM WG's "ICMP attacks against TCP draft". While that draft was initially meant for the informational track, it is now aims at "Informational". So, even when virtually all current implementations behave as you describe, the IETF specifications remain unchanged. >Section 3.2 says: > > In scenarios where a node has no default routers and Neighbor > Unreachability Detection (NUD) [RFC4861] fails for destinations > assumed to be on-link, or where firewalls or other systems that > enforce scope boundaries send ICMPv6 errors, the sending node will be > signaled of the unreachability problem. However, as discussed in > Section 2.2, standard TCP implementations will not abort connections > when receiving ICMP error messages that indicate soft errors. > >Clarity. This is somewhat misleading. When the node has no default >routers it also has no prefixes, no global addresses and it will not >even try to use IPv6 towards other global addresses. Why not? What if a Router Advertisement has a "Router Lifetime" of 0? Am I missing something? Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jul 18 14:31:47 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF8B3A684D; Fri, 18 Jul 2008 14:31:47 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69E193A684D for ; Fri, 18 Jul 2008 14:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWDO1Bp4C88G for ; Fri, 18 Jul 2008 14:31:45 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id 6BD6B3A680D for ; Fri, 18 Jul 2008 14:31:45 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so383386rvf.49 for ; Fri, 18 Jul 2008 14:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=6ONnT5eqJTMS9GSdASUHcVnccR5RKJDUMuY0s/G7QDI=; b=XjWGpqRnT+3dAF3QL2UJFnUd4NbKikcUnlfFYtydeyOgbD9vZ/tS0pkEVWdlZXg1hs Nh0aYWLU2UWcIiZs4Dkw1SECINuESgF7kv9x70YVc+KIC8rrIK+9S3M2VFqyEnt2N+jL aftit15y4c1fSZXE07bU5xn/Qh6IPJL7Lx/+k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=O97i4i+lV0uVCzCLmJzP5Ibbr2mU+YDnbDU4r8j6pEmLfUMm0B2stvkQj2miCuGfZh Q4GZxnvFoLwxs8fsc9vQ4FfbSvX/2MySLTwDo0CYCLNfEkTd1YmK0kKY6Ir0h8bRJwWu i1skfPP7kybt7kC/rjhtsczKEglokFdHy6hLE= Received: by 10.140.136.5 with SMTP id j5mr347676rvd.27.1216416735101; Fri, 18 Jul 2008 14:32:15 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Fri, 18 Jul 2008 14:32:15 -0700 (PDT) Message-ID: <396556a20807181432s2bc50f84kf932b9804c6abf24@mail.gmail.com> Date: Fri, 18 Jul 2008 14:32:15 -0700 From: "Adam Langley" To: tcpm@ietf.org MIME-Version: 1.0 Content-Disposition: inline X-Google-Sender-Auth: 00343fd1f56a9d8b Subject: [tcpm] TCP Auth experimental Linux patches X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Since the TCP auth is settling down, I thought that I would try implementing it to see if any fell out. Others interrested in playing are welcome to try the patch series[1]. It also includes a netcat like tool which is capable of configuring TCP auth: ./tcp-auth-nc --auth auth:0.0.0.0,password,hmac-md5-96 -l 1234 (server listening on port 1234) ./tcp-auth-nc --auth auth:1.2.3.4,password,hmac-md5-96 1.2.3.4 1234 (client connecting to 1.2.3.4 port 1234) It's quite a long series and applies against net-2.6 [2]. The first three patches aren't related to TCP auth and will probably be in 2.6.28. The forth is a search and replace s/md5/auth. The fifth contains the actual code. Although it doesn't crash on simple client/server tests I've not tried key rotation etc yet. Stuff that is clearly a result of the experimental nature of this patch: * The TCP option number hasn't been assigned yet, so I just took a guess * The MAC functions haven't been decided yet, so I took a guess at HMAC-MD5-96 and HMAC-SHA1-96 * Even if you choose a 96-bit MAC, SACK isn't enabled Limitations which might well persist into a final patch unless someone has a good argument against: * Only two keys supported (against a spec max of 256) * Asymmetric protection not supported Stuff I included that I hope will end up in the new draft of the spec: * The keyid is placed at the beginning of the MAC for better alignment * Excluding the pseudoheader and port numbers for NAT traversal is supported Stuff that might be a good idea, I'm not sure yet: * Latch mode: unsigned packets are accepted until the first signed packet is received. This is for applications which setup TCP auth after an unsigned SYN handshake. The userspace interface is similar to the md5sig one (and md5sig is still supported with a wrapper around the TCP auth code) and is probably adequately described by the header: #define TCP_AUTH_KEYED_MD5_128 0 #define TCP_AUTH_HMAC_MD5_96 1 #define TCP_AUTH_HMAC_SHA1_96 2 #define TCP_AUTH_MAX_MAC 2 #define TCP_AUTH_MAX_MAC_SIZE 20 /* SHA1 sets the limit */ /* tcpa_flags */ #define TCP_AUTH_ALLOW_KEY0 (1 << 0) #define TCP_AUTH_ALLOW_KEY1 (1 << 1) #define TCP_AUTH_TX_KEY1 (1 << 2) #define TCP_AUTH_RFC2385 (1 << 3) #define TCP_AUTH_OPTIONS_EXCLUDE (1 << 4) #define TCP_AUTH_PSEUDOHEADER_EXCLUDE (1 << 5) #define TCP_AUTH_PORT_NUMS_EXCLUDE (1 << 6) #define TCP_AUTH_LATCH (1 << 7) struct tcp_auth { struct __kernel_sockaddr_storage tcpa_addr; /* address associated */ __u8 tcpa_key0[TCP_AUTH_MAXKEYLEN]; /* key0 (binary) */ __u8 tcpa_key1[TCP_AUTH_MAXKEYLEN]; /* key1 (binary) */ __u8 tcpa_key0len; /* key0 length */ __u8 tcpa_key1len; /* key1 length */ __u8 tcpa_macfunc; /* MAC function */ __u8 tcpa_flags; }; [1] http://www.imperialviolet.org/binary/tcp-auth-quilt.tar.bz2 [2] git://git.kernel.org/linux/kernel/git/davem/net-2.6.git AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jul 18 14:40:07 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DE503A6883; Fri, 18 Jul 2008 14:40:07 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DB2B3A6883 for ; Fri, 18 Jul 2008 14:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fNRQYHPBmjA for ; Fri, 18 Jul 2008 14:40:05 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 88CDA3A680D for ; Fri, 18 Jul 2008 14:40:05 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so385534rvf.49 for ; Fri, 18 Jul 2008 14:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=ek4VDqG4jDn63H3/2j7O461t0sFzcZywEn0d3m+JOQo=; b=vbEZKRFBfT2LlOM8HZOX09k+AssyiQzMetfU5XHegC7/Y9yMD9TbtuBB4gKGUsZYaR pTOfbZGSaZzXYMwluZSGdSFkk4TqvnheoAkIhDFUN+lb5B+J7eYwx9ED8mwlRLM64I9l cH/mACThp5El9zzGM5f2Cj6r2PXrPQygDIE0Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=tBnmpchMQ7IG8qHwaIfHAMh2rVKHKqiGS1vMolurSRpmk4J7DYUuPUi4F3HCugq3mi DPhh975OwNFwaaJR5k9owk703uoEPAMrvRnAPfxMTUfhsU35jZbfawpXEAb4dvNnws0E +VwhuVVJPN0EWYQ/qAw4WgShBNWlkIUAnoqzY= Received: by 10.141.66.16 with SMTP id t16mr337884rvk.168.1216417239562; Fri, 18 Jul 2008 14:40:39 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Fri, 18 Jul 2008 14:40:39 -0700 (PDT) Message-ID: <396556a20807181440i438f2696yced3e0c7d713bd1f@mail.gmail.com> Date: Fri, 18 Jul 2008 14:40:39 -0700 From: "Adam Langley" To: tcpm@ietf.org In-Reply-To: <396556a20807181432s2bc50f84kf932b9804c6abf24@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20807181432s2bc50f84kf932b9804c6abf24@mail.gmail.com> X-Google-Sender-Auth: d1e57931664a15b4 Subject: Re: [tcpm] TCP Auth experimental Linux patches X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Fri, Jul 18, 2008 at 2:32 PM, Adam Langley wrote: > Since the TCP auth is settling down, I thought that I would try > implementing it to see if any fell out. I'm sorry, that sentence should be taken out and shot. Please let me try again: "Since the TCP auth spec is settling down, I thought that I would try implementing it to see if anything fell out." Thanks, -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 21 12:43:25 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E2E13A6867; Mon, 21 Jul 2008 12:43:25 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA68C3A6867 for ; Mon, 21 Jul 2008 12:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcqA7ebeNkCa for ; Mon, 21 Jul 2008 12:43:22 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id AC1163A67DD for ; Mon, 21 Jul 2008 12:43:22 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1215445rvf.49 for ; Mon, 21 Jul 2008 12:43:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=KHBAczIDvNp1Ojkfich6CWHEogK/G4/VgZlFerTyVWk=; b=bPLdF49vpnDr/KZV0Xr+odhsw3Uj4NNLoeq1SSLQ5Gv+RYUm3Y1eM1NCw7GSPhe8TQ iNneVcq09Hxo+HeDwsZB7XnR/Z+i0lcfiDGSJK/RGKh3lXyt5XvIZg5q6Vr3hzLXovuF FqjLjijiTPJOKNl6l7GEzqNe8W6Dna8cOTd50= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=dooz6VV+qQmEgKhDxsbM1AxPl9rX1QkgLOI//2BWFCflifjZUoztS/d3kKKtEdB/f1 L21/n86uTp0KuYjOOfRudHOa0r5dpzUn8iHRwz8EY3U4F9g5gHgYtcyAhLTC0Ein5ZY2 Jdn90XsUfHZqGq8ZcGI3RuNWur9gM7rBa4cOU= Received: by 10.140.139.3 with SMTP id m3mr2065468rvd.38.1216669438108; Mon, 21 Jul 2008 12:43:58 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Mon, 21 Jul 2008 12:43:58 -0700 (PDT) Message-ID: <396556a20807211243w673e2638r74b19af48d07e19d@mail.gmail.com> Date: Mon, 21 Jul 2008 12:43:58 -0700 From: "Adam Langley" To: tcpm@ietf.org In-Reply-To: <20080714234502.AC4793A69F4@core3.amsl.com> MIME-Version: 1.0 Content-Disposition: inline References: <20080714234502.AC4793A69F4@core3.amsl.com> X-Google-Sender-Auth: b4d9b71577e0b610 Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org 2008/7/14 : > A New Internet-Draft is available from the on-line Internet-Drafts directories. > Title : The TCP Authentication Option > Author(s) : J. Touch, et al. > Filename : draft-ietf-tcpm-tcp-auth-opt-01.txt An item which I believe is unclear in the spec: Are KeyIDs specific to a single direction? E.g if A and B are transmitting with different keys, could they both call them KeyID 0? At the moment the wording around the TSAD seems to allow this (specifically 6.1). Also, comments on the linux netdev mailing list got me thinking more about key rotation and I think the spec probably needs a sentence or two advising about the use of key rotation. The spec currently suggests that rotation occur every 2**31 bytes sent. It's not clear if the keys for each direction are assumed to rotate independently or not. If the directions are independent then a large one-way transfer allows an attacker to build up a dictionary of valid ACKs. Since the transfer is only one way, the ACKing side will never rotate keys. Thus an attacker could step in and convince the sender that everything was fine even if the true destination was dead. If the keys rotate after 2**31 bytes sent or recved there is a possible window issue. Consider a host which is sending with a very large window over a high delay link. It transmits several key rotations worth of data before the first ack comes back from the other side. Since this ack was elicited by the beginning of the data, it will be transmitted with the first key. If the first key is still active, everything is fine, but if the key window has rotated to the point where old keys are getting evicted then the ACK will be rejected. This currently shouldn't be a problem because the max window size is 1GB, which is less than 2**31 bytes. At some point in the future, if window scaling is allowed to grow past 2**14, then key rotation could limit the window size. Given all these questions, I think the spec should make some advisory remarks. I'm not too sure, but I think I like rotating a per-direction key better. The ACK dictionary attack is unfortunate, but if we aren't having real sequence numbers then our security is limited at best anyway. Based on that I'd suggest a 2-key pair, where, for a half-connection from A to B: B RX enables key 1 at 2**30 bytes received, A switches to key 1 at 2**31 bytes, B RX enables a new key 0 at 2**31 + 2**30 bytes, A switches to new key 0 at 2**32 etc. That would also mean that KeyIDs are specific to a given half-connection. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 21 13:45:31 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 865B73A6AA8; Mon, 21 Jul 2008 13:45:31 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B497D3A6A76 for ; Mon, 21 Jul 2008 13:45:26 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I779FMoV1i1T for ; Mon, 21 Jul 2008 13:45:19 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 4F5EE3A68C2 for ; Mon, 21 Jul 2008 13:45:15 -0700 (PDT) Received: from [70.213.139.181] (181.sub-70-213-139.myvzw.com [70.213.139.181]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6LKjO08021133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 21 Jul 2008 13:45:27 -0700 (PDT) Message-ID: <4884F548.4060208@isi.edu> Date: Mon, 21 Jul 2008 13:44:56 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Adam Langley References: <20080714234502.AC4793A69F4@core3.amsl.com> <396556a20807211243w673e2638r74b19af48d07e19d@mail.gmail.com> In-Reply-To: <396556a20807211243w673e2638r74b19af48d07e19d@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Adam, Adam Langley wrote: | 2008/7/14 : |> A New Internet-Draft is available from the on-line Internet-Drafts directories. |> Title : The TCP Authentication Option |> Author(s) : J. Touch, et al. |> Filename : draft-ietf-tcpm-tcp-auth-opt-01.txt | | An item which I believe is unclear in the spec: | | Are KeyIDs specific to a single direction? E.g if A and B are | transmitting with different keys, could they both call them KeyID 0? | At the moment the wording around the TSAD seems to allow this | (specifically 6.1). Yes. | Also, comments on the linux netdev mailing list got me thinking more | about key rotation and I think the spec probably needs a sentence or | two advising about the use of key rotation. How often would be in the key management document; we don't specify that. | The spec currently suggests that rotation occur every 2**31 bytes | sent. It's not clear if the keys for each direction are assumed to | rotate independently or not. They are. The purpose of key rotation based on 2**31 is replay attacks, not frequency of rotation for other reasons. Others have noted that such rotation may not be needed with modern HMACs. | If the directions are independent then a large one-way transfer allows | an attacker to build up a dictionary of valid ACKs. Since the transfer | is only one way, the ACKing side will never rotate keys. Thus an | attacker could step in and convince the sender that everything was | fine even if the true destination was dead. The ACKing side needs to rotate keys only when its seqnums rollover, not the ones it's ACKing. | If the keys rotate after 2**31 bytes sent or recved there is a | possible window issue. Consider a host which is sending with a very | large window over a high delay link. It transmits several key | rotations worth of data before the first ack comes back from the other | side. Since this ack was elicited by the beginning of the data, it | will be transmitted with the first key. If the first key is still | active, everything is fine, but if the key window has rotated to the | point where old keys are getting evicted then the ACK will be | rejected. The key rotations are supposed to be reasonably synchronized and/or overlapped to avoid such issues. | This currently shouldn't be a problem because the max window size is | 1GB, which is less than 2**31 bytes. At some point in the future, if | window scaling is allowed to grow past 2**14, then key rotation could | limit the window size. This isn't an issue of window scaling; it's an issue of replaying. Keys are rotated per 2**31 (recommended, at least) based on the rollover of the seqno; they can be rotated for other reasons as well. | Given all these questions, I think the spec should make some advisory remarks. | | I'm not too sure, but I think I like rotating a per-direction key | better. The ACK dictionary attack is unfortunate, but if we aren't | having real sequence numbers then our security is limited at best | anyway. Based on that I'd suggest a 2-key pair, where, for a | half-connection from A to B: B RX enables key 1 at 2**30 bytes | received, A switches to key 1 at 2**31 bytes, B RX enables a new key 0 | at 2**31 + 2**30 bytes, A switches to new key 0 at 2**32 etc. That | would also mean that KeyIDs are specific to a given half-connection. They should already be; the TSAD entries are specified per-direction for that reason. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiE9UgACgkQE5f5cImnZrudaQCgzwgXYSauxf9kwmIvkpAQFZje 82kAn3mVEgGOOcBKiaOC71JKtPdepwaw =6DCJ -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Jul 27 16:20:47 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 116D63A69D7; Sun, 27 Jul 2008 16:20:47 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E151D3A685E for ; Sun, 27 Jul 2008 16:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iA2uAYYZ+3XF for ; Sun, 27 Jul 2008 16:20:42 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id B687B3A6A18 for ; Sun, 27 Jul 2008 16:20:41 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6RNKdEt011865; Mon, 28 Jul 2008 02:20:44 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jul 2008 02:20:39 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jul 2008 02:20:26 +0300 Received: from [172.16.7.32] ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jul 2008 02:20:25 +0300 Message-Id: <59AF725C-B3D0-4EBB-AAA4-BF5BC7AFA422@nokia.com> From: Lars Eggert To: ext Rui Paulo In-Reply-To: Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 28 Jul 2008 00:20:20 +0100 References: <20080613124507.7FD733A684C@core3.amsl.com> <9AF7DF3F-643E-4E44-BA0F-6934CC0F39F4@nokia.com> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 27 Jul 2008 23:20:26.0066 (UTC) FILETIME=[59D2EB20:01C8F03F] X-Nokia-AV: Clean Cc: tcpm Extensions WG Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-uto-09.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On 2008-7-27, at 17:47, ext Rui Paulo wrote: > I've noticed that the rest of the last sentence of the Abstract > seems missing. It continues on top of the following page. (xml2rfc doesn't do decent widow/orphan prevention.) Lars _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Jul 27 21:24:46 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DBDA3A6938; Sun, 27 Jul 2008 21:24:46 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAB893A67E7 for ; Sun, 27 Jul 2008 21:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.572 X-Spam-Level: X-Spam-Status: No, score=-0.572 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbFa-VNq6dLW for ; Sun, 27 Jul 2008 21:24:43 -0700 (PDT) Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 9AA8D3A6938 for ; Sun, 27 Jul 2008 21:24:43 -0700 (PDT) Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id C7A174B7AD3 for ; Sun, 27 Jul 2008 21:24:51 -0700 (PDT) Date: Sun, 27 Jul 2008 21:24:51 -0700 From: Eric Rescorla To: tcpm@ietf.org User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080728042451.C7A174B7AD3@kilo.rtfm.com> Subject: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org $Id: draft-ietf-tcpm-tcp-auth-01-rev.txt,v 1.1 2008/07/28 03:06:22 ekr Exp $ I've reviewed the latest version of this document and while it seems to incorporate some improvements over the -00 version, I still have a number of concerns: - The document seems to assume an (unspecified) external key management mechanism. That seems less than maximally useful - There's discussion of a "per-connection nonce" in S 3.2, but it's non-normative and does not completely specify how the nonce is to be used: MACs typically benefit from a per-connection nonce, notably in avoiding the impact of key reuse. The presence of TCP's pair of Initial Sequence Numbers presents a nonce that may be useful in that case. Such a nonce could be computed as the concatenation of the ISNs (initiator, responder), and the socket pair (addresses, ports): o Nonce = ISN_i, ISN_r, IP_address_i, IP_address_r, port_i, port_r The initial SYN would not know ISN_r, so that packet's nonce would use ISN_r = 0. Use of these nonces avoids the need to avoid key reuse on a per connection basis. >> ISN and socket pair nonces MUST be used to generate unique per- session keys. I don't see in the draft where it actually describes how this is intended to work. - The discussion of key rollover seems incomplete >> TCP-AO implementations SHOULD change keys for a connection at least every 2^31 bytes, to avoid resending segments with the same TCP sequence number, data, and length under the same key. How is this intended to work? It seems to me that a useful system needs to describe a complete set of mechanisms that allow the establishment of a single static key which can be used to secure multiple connections. I don't see that this document does that. Previous comments which I believe remain outstanding: S 1. there have been escalating attacks on the algorithm itself [Be05] [Bu06]. TCP MD5 also lacks both key management and algorithm These citations should be to the original papers, not the summaries (not that I mind you citing Steve's and my paper...) [New: you've added a cite to Burr's paper, but you should be citing Wang et al.] S 1.1. I don't see a lot of value in pre-specifying two MAC algorithms as MTI. There's no reason to believe one isn't plenty, as used in other protocols. S 2.2. Figure 2 is kind of hard to read since the length of the kind field is 16 bits, but kinds are 8 bits, rigth? S 3. >> At least one direction (inbound/outbound) SHOULD have a non-NONE MAC in practice, but this MUST NOT be strictly required by an implementation. 1. This seems like a bad idea. It's very hard to analyze the security properties of a connection when only one side is protected. To take one case that is obviously bad, if you're worried about DoS attacks and you use TCP-AO, then forging packets in either direction can bring it down. I would reverse this and require MACs in both directions. 2. Even if we stipulate that this might be an OK idea, it's not appropriate to require implementations to support it. S 9. TCP-AO does not expose the MAC algorithm used to authenticate a particular connection; that information is kept in the TSAD at the endpoints, and is not indicated in the header. This seems to be of extremely marginal security benefit. There are likely to be <5 algorithms in use. So, searching all of them increases the effective key size by <3 bits. [New: Again, this isn't a security issue] -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Jul 27 23:39:22 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9778528C131; Sun, 27 Jul 2008 23:39:22 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC34728C131 for ; Sun, 27 Jul 2008 23:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVxk0ln0yUcd for ; Sun, 27 Jul 2008 23:39:16 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6D5613A69DF for ; Sun, 27 Jul 2008 23:39:16 -0700 (PDT) Received: from [172.16.7.194] (guestroom-nat.meeting.ietf.org [130.129.64.64]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6S6d7DN014093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 27 Jul 2008 23:39:11 -0700 (PDT) Message-ID: <488D6968.9010102@isi.edu> Date: Sun, 27 Jul 2008 23:38:32 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eric Rescorla References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> In-Reply-To: <20080728042451.C7A174B7AD3@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Eric (et al.), We'll have time to discuss these issues in detail later today at the TCPM meeting. Here is some potential context for that... Joe Eric Rescorla wrote: | $Id: draft-ietf-tcpm-tcp-auth-01-rev.txt,v 1.1 2008/07/28 03:06:22 ekr Exp $ | | I've reviewed the latest version of this document and while it | seems to incorporate some improvements over the -00 version, | I still have a number of concerns: | | - The document seems to assume an (unspecified) external key management | mechanism. That seems less than maximally useful The split of this work into separate key management and TCP extension documents was a prerequisite to the design team's output. The WG chairs and/or ADs can speak to it more directly. | - There's discussion of a "per-connection nonce" in S 3.2, | but it's non-normative and does not completely specify how | the nonce is to be used: | | MACs typically benefit from a per-connection nonce, notably in | avoiding the impact of key reuse. The presence of TCP's pair of | Initial Sequence Numbers presents a nonce that may be useful in that | case. Such a nonce could be computed as the concatenation of the ISNs | (initiator, responder), and the socket pair (addresses, ports): | | o Nonce = ISN_i, ISN_r, IP_address_i, IP_address_r, port_i, port_r | | The initial SYN would not know ISN_r, so that packet's nonce would | use ISN_r = 0. Use of these nonces avoids the need to avoid key reuse | on a per connection basis. | | >> ISN and socket pair nonces MUST be used to generate unique per- | session keys. | | I don't see in the draft where it actually describes how this is | intended to work. The nonce would be used by the external session key management mechanism. This part of the document may move to that other specification. | - The discussion of key rollover seems incomplete | | >> TCP-AO implementations SHOULD change keys for a connection at | least every 2^31 bytes, to avoid resending segments with the same | TCP sequence number, data, and length under the same key. | | How is this intended to work? The key management mechanism should react to sequence numbers rolling over the ISN (perhaps masking out the high bit to roll over twice as often). | It seems to me that a useful system needs to describe a complete set | of mechanisms that allow the establishment of a single static key which | can be used to secure multiple connections. I don't see that this | document does that. This document does not specify a key management mechanism; that mechanism would use a single static key to generate per-session keys. | Previous comments which I believe remain outstanding: | S 1. | there have been escalating attacks on the algorithm itself [Be05] | [Bu06]. TCP MD5 also lacks both key management and algorithm | | These citations should be to the original papers, not the summaries | (not that I mind you citing Steve's and my paper...) | | [New: you've added a cite to Burr's paper, but you should be | citing Wang et al.] Thanks - that will be updated. | S 1.1. | I don't see a lot of value in pre-specifying two MAC algorithms | as MTI. There's no reason to believe one isn't plenty, as used | in other protocols. The need for two required algorithms mirrors the intent of RFC4305's "SHOULD+", which requires one, but suggests that two algs may be required in the future. The design team suggested that requiring two algorithms now would be prudent, notably so that if one were compromised (either entirely, or effectively weakened due to computational exploits), the other would be pre-deployed. The two could also trade strength for performance, depending on which algorithms are recommended by SAAG. | S 2.2. | Figure 2 is kind of hard to read since the length of the kind | field is 16 bits, but kinds are 8 bits, rigth? The length of the field is wide due to the text; that will be fixed to be proportional to the bit width (8 bits, as you note). | S 3. | >> At least one direction (inbound/outbound) SHOULD have | a non-NONE MAC in practice, but this MUST NOT be strictly | required by an implementation. | | 1. This seems like a bad idea. It's very hard to analyze the security | properties of a connection when only one side is protected. To take | one case that is obviously bad, if you're worried about DoS attacks | and you use TCP-AO, then forging packets in either direction can | bring it down. I would reverse this and require MACs in both directions. | | 2. Even if we stipulate that this might be an OK idea, it's not | appropriate to require implementations to support it. We discussed the utility of asymmetry in Philadelphia last March. The point is to require implementations to allow the user to request connections configured this way; we can add that connections MUST default to using a real MAC in both directions by default. Does that address your concern? | S 9. | TCP-AO does not expose the MAC algorithm used to authenticate a | particular connection; that information is kept in the TSAD at the | endpoints, and is not indicated in the header. | | This seems to be of extremely marginal security benefit. There | are likely to be <5 algorithms in use. So, searching all of them | increases the effective key size by <3 bits. | | [New: Again, this isn't a security issue] The text should be updated to note that the primary and sufficient reason for omitting it is space conservation and the fact that there is no utility in including it. The number of algorithms doesn't merely augment the key space, though - it an algorithm is known weak(er), indicating it in the header is a signal in the clear that the packet stream is more vulnerable. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiNaWgACgkQE5f5cImnZrtTgACg12PIYHDfLrSm4CnTySFFLXSp EucAn0uZKkNNsMp3axP1gzzO7bDA8wBT =JOdm -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 28 01:16:54 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE5F23A6AD7; Mon, 28 Jul 2008 01:16:54 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5DDE3A6ADD for ; Mon, 28 Jul 2008 01:16:53 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id if1tx4uh4oLy for ; Mon, 28 Jul 2008 01:16:52 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 2D19E3A6A31 for ; Mon, 28 Jul 2008 01:16:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,264,1215388800"; d="scan'208";a="69520893" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 28 Jul 2008 08:17:01 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m6S8H0aO022572 for ; Mon, 28 Jul 2008 01:17:00 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6S8H0U6023406 for ; Mon, 28 Jul 2008 08:17:00 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 01:17:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 01:17:00 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58058C2FD4@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP-AO review comments. Thread-Index: AcjwfncrprtVx7MJRpe3GEDbm58hBQ== From: "Anantha Ramaiah (ananth)" To: X-OriginalArrivalTime: 28 Jul 2008 08:17:00.0169 (UTC) FILETIME=[4F012F90:01C8F08A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3629; t=1217233020; x=1218097020; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20TCP-AO=20review=20comments. |Sender:=20; bh=Rc+180CdZziRE/7l8mozV1IFJ60FNjMGKupSDBa3PB8=; b=WY3y02BX4x+n33IwH7jKHirLgyzeIMqdTMSfV0Po4g1rkV9UsYS6nvhx6M J61NYL4F8Wa2Sy50/0lTbKqOa2K4HBy3/t6BW7rUNTb60mPC9GKM6cDv3GQM e1+QaB01me; Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [tcpm] TCP-AO review comments. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hi, I went over the latest copy of the TCP authentication draft and jotting down my observations and comments. #1 I have problem with the term "obsoletes 2385" [ I did bring this up before] It is going to be a long time before deployments move over to the new TCP auth option. Many customers (deployments) are fine with TCP MD5 with periodic key rollover option and hence would not move to TCP-AO immediately. So, in short it really depends on combination of perceived threat levels, desired security level of a network. Also, TCP-AO is taking a new TCP option number with backward compatibility in mind. Abstract - It mentions BGP and LDP. FWIW MSDP also uses TCP MD5 and some proprietary protocols as well. Should we use the word, "long lived connections" instead? Just wanted to convey the feeling that it is intended to be a generic TCP authentication option. Section 1.1 "allows rekeying during a TCP connection " 2385 doesn't mention re-keying nor does it preclude one from doing so. Like I mentioned earlier, deployments have been running code with some implicit key rollover schemes. Section 3 (security association management (TSAD) - IMO, the contents and interpreation of TSAD should be implementation specific. Applications can use some out of band (or configuration) mechanism to set up the TSAD. - It says : "there MUST be no more than one matching TSAD entry" Not sure why, you could have a primary and secondary key here. (I understand that this is not robust) but using a MUST here seems too much of a restriction. In other words, IMO, this document shouldn't be specifying too much about TSAD. - TCP option exclusion : reading this it seems unclear to me as to whether TCP-AO is excluded in the option calculation or not. - it says : "TCP option kind exclusion list MUST NOT change during TCP connection" Not sure why? Needs explanation. - It says "keyID MAY have value of 0" - really what is the point here? Also, shouldn't we allow non-numeric key ID's ? - "Asymmetric use of TCP-AO" - I am kind of confused here, are we saying that the ACK's are not going to be signed, from the peer which has negotaited "NONE" ? If so, isn't a security hole since someone can spoof an ACK and cause issues for the side which HAS signed up for authentication? - Question : I have heard cases where some customers (although rare) want the authentication to be turned off at some point of time, and also turned on dynamically. TCP, today doesn't allow options negotiation "on demand", so the latter point is moot for now. What are the thoughts about turning off the AO option ? - TCP user interface - I am not sure why this document (no other TCP option document even mentions that), for eg:- STATUS call, there is no such thing as TCP API document, typically BSD sockets are the popular API set, the point is that you may want to simply say "appropriate API's for the application to read/configure entries" Just a nitpick since I haven't seen any other TCP option document even talk about such things.. This comment can be ignored if needed.. - On connectionless resets. Today, the way implementations work is that when a RST is generated, if the incoming TCP segment has the TCP MD5 option, then it consults the database to obtain the key for the the 4 tuple in question. In the case TCP-AO option with the use of index, you could still obtain this piece of information and generate the RST. Well, this is a "best effort", but has been proven to be useful field experience. So much so far.. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 28 01:24:19 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 070AA3A6A79; Mon, 28 Jul 2008 01:24:19 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A9FE3A67FD for ; Mon, 28 Jul 2008 01:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxacFltiwiDT for ; Mon, 28 Jul 2008 01:24:16 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 85D9C3A691C for ; Mon, 28 Jul 2008 01:24:16 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 8B10A3280A9 for ; Mon, 28 Jul 2008 03:24:25 -0500 (CDT) Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsppt03.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id m6S8OPb3001593 for ; Mon, 28 Jul 2008 03:24:25 -0500 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw03.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jul 2008 03:24:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 03:24:24 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: meeting materials Thread-Index: Acjwi1fvUC5vq5k7Qe2xLPXysbRw4Q== From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: X-OriginalArrivalTime: 28 Jul 2008 08:24:25.0395 (UTC) FILETIME=[58614830:01C8F08B] Subject: [tcpm] meeting materials X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1923556536==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============1923556536== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F08B.57FB36DD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F08B.57FB36DD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The slides for today's TCPM meeting are online at: =20 http://datatracker.ietf.org/meeting/72/materials.html =20 For remote participation, the audio streams are at: =20 http://videolab.uoregon.edu/events/ietf =20 and jabber information is at: =20 http://jabber.ietf.org =20 =20 ------_=_NextPart_001_01C8F08B.57FB36DD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
The slides for today's = TCPM meeting are online at:
=0A=
 
=0A= =0A=
 
=0A=
For remote participation, the audio = streams are at:
=0A=
 
=0A= =0A=
 
=0A=
and jabber information is = at:
=0A=
 
=0A= =0A=
 
=0A=
 
------_=_NextPart_001_01C8F08B.57FB36DD-- --===============1923556536== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1923556536==-- From tcpm-bounces@ietf.org Mon Jul 28 02:02:31 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44E2D3A6AFF; Mon, 28 Jul 2008 02:02:31 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 794673A6B07 for ; Mon, 28 Jul 2008 02:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peth67Z8NJHW for ; Mon, 28 Jul 2008 02:02:27 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E27E13A6AB6 for ; Mon, 28 Jul 2008 02:02:27 -0700 (PDT) Received: from [130.129.20.69] ([130.129.20.69]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6S92K1m026367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Jul 2008 02:02:23 -0700 (PDT) Message-ID: <488D8AFD.2070601@isi.edu> Date: Mon, 28 Jul 2008 02:01:49 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <0C53DCFB700D144284A584F54711EC58058C2FD4@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58058C2FD4@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP-AO review comments. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Ananth, As I noted with Eric's comments, we can discuss this further in the meeting today, but it might be useful to try to discuss some on the list first... see below. Joe Anantha Ramaiah (ananth) wrote: | Hi, | I went over the latest copy of the TCP authentication draft and | jotting down my observations and comments. | | #1 | I have problem with the term "obsoletes 2385" [ I did bring this up Whether or not we are obsoleting things is a topic for today's discussion. I should have removed it from the doc header until we make a decision, though. | before] It is going to be a long time before deployments move over to | the new TCP auth option. Many customers (deployments) are fine with TCP | MD5 with periodic key rollover option and hence would not move to TCP-AO There is no key rollover option to TCP MD5. The doc is vague on this issue, saying only "presumably connection specific"; there is no key ID, and no discussion of the impact of changing keys during a connection. | immediately. So, in short it really depends on combination of perceived | threat levels, desired security level of a network. Also, TCP-AO is | taking a new TCP option number with backward compatibility in mind. The desire to use a new option number has nothing to do with backward compatibility. As noted in precursors to this doc, the TCP MD5 ID could be reused. Backward compatibility is limited - and we are discussing the extent to which that is needed today as well. A given connection is not intended to back off from TCP-AO and use TCP-MD5 automatically. | Abstract | | - It mentions BGP and LDP. FWIW MSDP also uses TCP MD5 and some | proprietary protocols as well. Should we use the word, "long lived | connections" instead? Just wanted to convey the feeling that it is | intended to be a generic TCP authentication option. We probably want to leave the current examples (and add MSDP), as well as noting the general utility of this mechanism. | Section 1.1 | | "allows rekeying during a TCP connection " | | 2385 doesn't mention re-keying nor does it preclude one from doing so. | Like I mentioned earlier, deployments have been running code with some | implicit key rollover schemes. Agreed that it is not discussed explicitly, but a key rollover would generate logging error messages ("probably advisable"). Current implementations may have a working mechanism for rollover, but they make many presumptions that are not specified, e.g., that retransmissions must use the new key once installed. Further, key rollover would result in lost segments, retransmission, and potential impact on the congestion window. The section should clarify that TCP-AO "explicitly allows rekeying during a TCP connection, without impacting packet loss" | Section 3 | (security association management (TSAD) | | - IMO, the contents and interpreation of TSAD should be implementation | specific. Applications can use some out of band (or configuration) | mechanism to set up the TSAD. TSAD is setup out-of-band; that's the purpose of the key management mechanism, e.g. The contents are specified for two reasons: - to define the API to access the info - to define the syntactic relationship between components The TSAD can be implemented in any way the user desires, so long as it stores and retrieves the data specified thusly. | - It says : "there MUST be no more than one matching TSAD entry" Not | sure why, you could have a primary and secondary key here. (I understand | that this is not robust) but using a MUST here seems too much of a | restriction. In other words, IMO, this document shouldn't be specifying | too much about TSAD. A single TSAD entry can have multiple keys. Having multiple matching TSAD entries means there is a collision that cannot be resolved. | - TCP option exclusion : reading this it seems unclear to me as to | whether TCP-AO is excluded in the option calculation or not. This can be clarified. The intent is to exclude or include all options; parsing and including individual options would be expensive on a per-packet basis. The TCP-AO option MAC is zeroed if the options are included. | - it says : "TCP option kind exclusion list MUST NOT change during TCP | connection" Not sure why? Needs explanation. This can be clarified. The goal is that all changes during a connection do not affect packet loss. Doing so for the option exclusion means an additional per-packet check which doesn't seem to be necessary. | - It says "keyID MAY have value of 0" - really what is the point here? The goal is to not preclude or reserve any KeyID values. | Also, shouldn't we allow non-numeric key ID's ? The KeyID is an 8-bit field, interpreted as an index of 0-255. What purpose would non-numeric IDs serve? | - "Asymmetric use of TCP-AO" - I am kind of confused here, are we saying | that the ACK's are not going to be signed, from the peer which has | negotaited "NONE" ? If so, isn't a security hole since someone can spoof | an ACK and cause issues for the side which HAS signed up for | authentication? The utility of this was discussed in Philadelphia. The doc might benefit from expanded review of that discussion. | - Question : | I have heard cases where some customers (although rare) want the | authentication to be turned off at some point of time, and also turned | on dynamically. TCP, today doesn't allow options negotiation "on | demand", so the latter point is moot for now. What are the thoughts | about turning off the AO option ? IMO, that's handled by using NONE, i.e., the keyID changes and thus the corresponding algorithm. TCP state - i.e., the fact that TCP-AO is being used - never changes during a connection; that's because TCP doesn't support such state negotiation after the SYN exchange, and to add that would effectively change the TCP state diagram (which seems avoidable and desirable to avoid). | - TCP user interface - I am not sure why this document (no other TCP | option document even mentions that), for eg:- STATUS call, there is no | such thing as TCP API document, RFC793 specifies the TCP API. STATUS is defined there. BSD implements that API (or at least a close approximation of it ;-) | typically BSD sockets are the popular | API set, the point is that you may want to simply say "appropriate API's | for the application to read/configure entries" Just a nitpick since I | haven't seen any other TCP option document even talk about such things.. IMO, that's a deficiency of other option docs ;-) | This comment can be ignored if needed.. | | - On connectionless resets. | Today, the way implementations work is that when a RST is generated, if | the incoming TCP segment has the TCP MD5 option, then it consults the | database to obtain the key for the the 4 tuple in question. In the case | TCP-AO option with the use of index, you could still obtain this piece | of information and generate the RST. Well, this is a "best effort", but | has been proven to be useful field experience. I'm not sure what the question here is; the RST MUST have the TCP-AO with the correct fields to be accepted at the receiver. Can you restate the question regarding RSTs? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiNiv0ACgkQE5f5cImnZrtOTQCg05lOQTahQTIRDFk1lRyUjl9P NhoAn37/C7donQo8Er//Xtmra4j/0dHF =ok2w -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 28 02:58:17 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2163A6809; Mon, 28 Jul 2008 02:58:17 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0C5A3A6808 for ; Mon, 28 Jul 2008 02:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[AWL=-1.897, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-sFhmCSPzMs for ; Mon, 28 Jul 2008 02:58:15 -0700 (PDT) Received: from mgw-fb01.nokia.com (mgw-fb01.nokia.com [192.100.122.235]) by core3.amsl.com (Postfix) with ESMTP id 3CE5A3A6910 for ; Mon, 28 Jul 2008 02:58:15 -0700 (PDT) Received: from mgw-mx06.nokia.com (mgw-mx06.nokia.com [192.100.122.233]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6S9wKwj003538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Jul 2008 12:58:21 +0300 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6S9w0Yc018013 for ; Mon, 28 Jul 2008 12:58:19 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jul 2008 12:58:02 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jul 2008 12:58:02 +0300 Received: from lars.meeting.ietf.org ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jul 2008 12:58:01 +0300 Message-Id: <2FFB38A0-0044-4AE8-B8CF-A9AEDD42B95C@nokia.com> From: Lars Eggert To: tcpm Extensions WG Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 28 Jul 2008 10:57:58 +0100 References: X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 28 Jul 2008 09:58:01.0987 (UTC) FILETIME=[6C213530:01C8F098] X-Nokia-AV: Clean Subject: [tcpm] Fwd: [Tsvwg] Presentation added to today's TSVWG agenda X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org FYI, this presentation/draft are of interest to TCPM. Begin forwarded message: > From: "ext James M. Polk" > Date: July 28, 2008 10:36:53 IST > To: tsvwg > Subject: [Tsvwg] Presentation added to today's TSVWG agenda > > TSVWG > > I've added another ID to be presented here in Dublin. Please read > it as it relates to the port randomization draft that's fairly > important to this WG. > > > * Anantha's - Effects of port randomization with TCP TIME-WAIT state > draft-ananth-tsvwg-timewait-00.txt 1455-1505 (10 min) > > > > Cheers, > James > IETF TSVWG co-chair > > *********************************** > "It should NEVER be inconvenient to do the right thing" > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 28 05:56:47 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 329533A68DA; Mon, 28 Jul 2008 05:56:47 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E86E3A689A for ; Mon, 28 Jul 2008 05:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CY4fvnAvbmGl for ; Mon, 28 Jul 2008 05:56:42 -0700 (PDT) Received: from audl951.usa.alcatel.com (audl951.usa.alcatel.com [143.209.238.161]) by core3.amsl.com (Postfix) with ESMTP id 4410E3A68E8 for ; Mon, 28 Jul 2008 05:56:42 -0700 (PDT) Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.usa.alcatel.com [172.22.216.13]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id m6SCupTc028639; Mon, 28 Jul 2008 07:56:51 -0500 Received: from USDALSMBS02.ad3.ad.alcatel.com ([172.22.216.10]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 28 Jul 2008 07:56:51 -0500 Received: from USDALSMBS05.ad3.ad.alcatel.com ([172.22.216.33]) by USDALSMBS02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 28 Jul 2008 07:56:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 07:56:44 -0500 Message-ID: <66F9363AB70F764C96547BD8A0A3679E154B7C@USDALSMBS05.ad3.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] TCP Auth experimental Linux patches Thread-Index: AcjpHu4eqxerIllhQrK374vupfz5SAHknTf7 References: <396556a20807181432s2bc50f84kf932b9804c6abf24@mail.gmail.com> <396556a20807181440i438f2696yced3e0c7d713bd1f@mail.gmail.com> From: "LANGE Andrew" To: "Adam Langley" , X-OriginalArrivalTime: 28 Jul 2008 12:56:50.0786 (UTC) FILETIME=[66FE0420:01C8F0B1] X-Scanned-By: MIMEDefang 2.64 on 143.209.238.34 Subject: Re: [tcpm] TCP Auth experimental Linux patches X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0631281065==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============0631281065== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F0B1.66D948F3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F0B1.66D948F3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Adam, I think it's fantastic that you're working on an implementation of = extended tcp auth. However, I fear your efforts may be misdirected. The = reason is that the settled-down spec in draft-bonica, not the one in the = tcpm working group draft. Draft-bonica is implemented, deployed and = interops between Alcatel, Cisco and Juniper routers. Implementing = draft-bonica, and testing against the router implementations would be = the right direction to pursue. The reason the traffic on the mailing list has died down it that the = tcp-ao draft is stillborn. It adds nothing the the deployed = implementation, except incompatibility on the wire.=20 Andrew -----Original Message----- From: tcpm-bounces@ietf.org on behalf of Adam Langley Sent: Fri 7/18/2008 4:40 PM To: tcpm@ietf.org Subject: Re: [tcpm] TCP Auth experimental Linux patches =20 On Fri, Jul 18, 2008 at 2:32 PM, Adam Langley = wrote: > Since the TCP auth is settling down, I thought that I would try > implementing it to see if any fell out. I'm sorry, that sentence should be taken out and shot. Please let me try = again: "Since the TCP auth spec is settling down, I thought that I would try implementing it to see if anything fell out." Thanks, --=20 Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm ------_=_NextPart_001_01C8F0B1.66D948F3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [tcpm] TCP Auth experimental Linux patches

Adam,

I think it's fantastic that you're working on an implementation of = extended tcp auth.  However, I fear your efforts may be = misdirected. The reason is that the settled-down spec in draft-bonica, = not the one in the tcpm working group draft.  Draft-bonica is = implemented, deployed and interops between Alcatel, Cisco and Juniper = routers.  Implementing draft-bonica, and testing against the router = implementations would be the right direction to pursue.

The reason the traffic on the mailing list has died down it that the = tcp-ao draft is stillborn.  It adds nothing the the deployed = implementation, except incompatibility on the wire.

Andrew


-----Original Message-----
From: tcpm-bounces@ietf.org on behalf of Adam Langley
Sent: Fri 7/18/2008 4:40 PM
To: tcpm@ietf.org
Subject: Re: [tcpm] TCP Auth experimental Linux patches

On Fri, Jul 18, 2008 at 2:32 PM, Adam Langley = <agl@imperialviolet.org> wrote:
> Since the TCP auth is settling down, I thought that I would try
> implementing it to see if any fell out.

I'm sorry, that sentence should be taken out and shot. Please let me try = again:

"Since the TCP auth spec is settling down, I thought that I would = try
implementing it to see if anything fell out."


Thanks,


--
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org<= BR> _______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/= mailman/listinfo/tcpm

------_=_NextPart_001_01C8F0B1.66D948F3-- --===============0631281065== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0631281065==-- From tcpm-bounces@ietf.org Mon Jul 28 06:05:23 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FCFD3A6813; Mon, 28 Jul 2008 06:05:23 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 668043A6808 for ; Mon, 28 Jul 2008 06:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.557 X-Spam-Level: X-Spam-Status: No, score=-0.557 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UHjwgua3n6S for ; Mon, 28 Jul 2008 06:05:21 -0700 (PDT) Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 2B7133A6813 for ; Mon, 28 Jul 2008 06:05:21 -0700 (PDT) Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id AB1A94B8883; Mon, 28 Jul 2008 06:05:32 -0700 (PDT) Date: Mon, 28 Jul 2008 06:05:32 -0700 From: Eric Rescorla To: Joe Touch In-Reply-To: <488D6968.9010102@isi.edu> References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080728130532.AB1A94B8883@kilo.rtfm.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Sun, 27 Jul 2008 23:38:32 -0700, Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Eric (et al.), > > We'll have time to discuss these issues in detail later today at the > TCPM meeting. Here is some potential context for that... I'm not in Dublin. I plan to make some attempt to follow via audio and Jabber but I don't know if I'll actually be able to make that work, both for technical and logistical reasons (i.e., I'm at a conference at the same time and I don't know how well the network will work or if I'll have to do something else). > Eric Rescorla wrote: > | $Id: draft-ietf-tcpm-tcp-auth-01-rev.txt,v 1.1 2008/07/28 03:06:22 ekr > Exp $ > | > | I've reviewed the latest version of this document and while it > | seems to incorporate some improvements over the -00 version, > | I still have a number of concerns: > | > | - The document seems to assume an (unspecified) external key management > | mechanism. That seems less than maximally useful > > The split of this work into separate key management and TCP extension > documents was a prerequisite to the design team's output. The WG chairs > and/or ADs can speak to it more directly. That may be so, but it seems to me that it's unwise regardless. As I indicated in PHL, this protocol as it stands isn't really useful in the absence of a key management protocol. Since no such protocol appears to be on the horizon... With that in mind, I've elided the detailed comments below relative to that. > | S 1.1. > | I don't see a lot of value in pre-specifying two MAC algorithms > | as MTI. There's no reason to believe one isn't plenty, as used > | in other protocols. > > The need for two required algorithms mirrors the intent of RFC4305's > "SHOULD+", which requires one, but suggests that two algs may be > required in the future. The design team suggested that requiring two > algorithms now would be prudent, notably so that if one were compromised > (either entirely, or effectively weakened due to computational > exploits), the other would be pre-deployed. The two could also trade > strength for performance, depending on which algorithms are recommended > by SAAG. Yes, as I've now said several times, this strikes me as massive overkill. If SHA-1 is ever weakened to the point where HMAC-SHA1 is implicated, we'll have problems far, far, more serious than the occasional attack on TCP AO. > | S 2.2. > | Figure 2 is kind of hard to read since the length of the kind > | field is 16 bits, but kinds are 8 bits, rigth? > > The length of the field is wide due to the text; that will be fixed to > be proportional to the bit width (8 bits, as you note). > > | S 3. > | >> At least one direction (inbound/outbound) SHOULD have > | a non-NONE MAC in practice, but this MUST NOT be strictly > | required by an implementation. > | > | 1. This seems like a bad idea. It's very hard to analyze the security > | properties of a connection when only one side is protected. To take > | one case that is obviously bad, if you're worried about DoS attacks > | and you use TCP-AO, then forging packets in either direction can > | bring it down. I would reverse this and require MACs in both directions. > | > | 2. Even if we stipulate that this might be an OK idea, it's not > | appropriate to require implementations to support it. > > We discussed the utility of asymmetry in Philadelphia last March. The > point is to require implementations to allow the user to request > connections configured this way; we can add that connections MUST > default to using a real MAC in both directions by default. Does that > address your concern? Well, as I recall, you asserted it the value of it and I disagreed. As I recall, the example you offered was the one-way authentication in TLS, which is really not that apropos, since it only applies to the key management protocol, not to the data, which is authenticated in both directions. So, no, this does not address my concern. I think the world would be far simpler if you simply required both sides to generate MACs. (and certainly I can't imagine why you would *require* implementations to allow neither side to do so). Perhaps you could restate your rationale for this? -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 28 06:12:43 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1B0F3A6A1D; Mon, 28 Jul 2008 06:12:43 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B37D3A6A1D for ; Mon, 28 Jul 2008 06:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZW4iB23o8PoW for ; Mon, 28 Jul 2008 06:12:42 -0700 (PDT) Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 4BD533A67DB for ; Mon, 28 Jul 2008 06:12:42 -0700 (PDT) Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 3DD764B88F7; Mon, 28 Jul 2008 06:12:54 -0700 (PDT) Date: Mon, 28 Jul 2008 06:12:53 -0700 From: Eric Rescorla To: Joe Touch In-Reply-To: <488D6968.9010102@isi.edu> References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080728131254.3DD764B88F7@kilo.rtfm.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org I did want to make one more note. At Sun, 27 Jul 2008 23:38:32 -0700, Joe Touch wrote: > | - The discussion of key rollover seems incomplete > | > | >> TCP-AO implementations SHOULD change keys for a connection at > | least every 2^31 bytes, to avoid resending segments with the same > | TCP sequence number, data, and length under the same key. > | > | How is this intended to work? > > The key management mechanism should react to sequence numbers rolling > over the ISN (perhaps masking out the high bit to roll over twice as often). Regardless of whether there is a KMP, it strikes me as unwise to punt this job to it. The TCP authentication protocol should be able to provide security for packets even in the face of sequence number rollover, out to the limits of security of the MAC algorithm (which far exceed 2^31 bytes in both cases). There are (at least) two potential approaches: 1. Use a (synthetic) extended sequence number. 2. Change the key used to compute the MAC inside the protoco. But I don't think it's a good idea to punt this to the KMP, since you don't really need to change the key for any cryptographic reason. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 28 07:26:05 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 660D83A6895; Mon, 28 Jul 2008 07:26:05 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339DF3A69EB for ; Mon, 28 Jul 2008 07:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjSVqK6C55Ke for ; Mon, 28 Jul 2008 07:25:57 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E4CDB3A6895 for ; Mon, 28 Jul 2008 07:25:56 -0700 (PDT) Received: from [130.129.20.69] ([130.129.20.69]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6SEPdiw004717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Jul 2008 07:25:42 -0700 (PDT) Message-ID: <488DD6C4.8070709@isi.edu> Date: Mon, 28 Jul 2008 07:25:08 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eric Rescorla References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728130532.AB1A94B8883@kilo.rtfm.com> In-Reply-To: <20080728130532.AB1A94B8883@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Eric, Eric Rescorla wrote: | At Sun, 27 Jul 2008 23:38:32 -0700, | Joe Touch wrote: |> -----BEGIN PGP SIGNED MESSAGE----- |> Hash: SHA1 |> |> Hi, Eric (et al.), |> |> We'll have time to discuss these issues in detail later today at the |> TCPM meeting. Here is some potential context for that... | | I'm not in Dublin. We can continue on the list in that case... |> Eric Rescorla wrote: |> | $Id: draft-ietf-tcpm-tcp-auth-01-rev.txt,v 1.1 2008/07/28 03:06:22 ekr |> Exp $ |> | |> | I've reviewed the latest version of this document and while it |> | seems to incorporate some improvements over the -00 version, |> | I still have a number of concerns: |> | |> | - The document seems to assume an (unspecified) external key management |> | mechanism. That seems less than maximally useful |> |> The split of this work into separate key management and TCP extension |> documents was a prerequisite to the design team's output. The WG chairs |> and/or ADs can speak to it more directly. | | That may be so, but it seems to me that it's unwise regardless. As I | indicated in PHL, this protocol as it stands isn't really useful in | the absence of a key management protocol. Since no such protocol | appears to be on the horizon... With that in mind, I've elided the | detailed comments below relative to that. My understanding is that this document will not move forward without a companion keying document. Let's assume that and press on... |> | S 1.1. |> | I don't see a lot of value in pre-specifying two MAC algorithms |> | as MTI. There's no reason to believe one isn't plenty, as used |> | in other protocols. |> |> The need for two required algorithms mirrors the intent of RFC4305's |> "SHOULD+", which requires one, but suggests that two algs may be |> required in the future. The design team suggested that requiring two |> algorithms now would be prudent, notably so that if one were compromised |> (either entirely, or effectively weakened due to computational |> exploits), the other would be pre-deployed. The two could also trade |> strength for performance, depending on which algorithms are recommended |> by SAAG. | | Yes, as I've now said several times, this strikes me as massive | overkill. If SHA-1 is ever weakened to the point where HMAC-SHA1 | is implicated, we'll have problems far, far, more serious than | the occasional attack on TCP AO. It's trivial to resolve this via WG feedback and SAAG input. If one is sufficient, so be it. |> | S 2.2. |> | Figure 2 is kind of hard to read since the length of the kind |> | field is 16 bits, but kinds are 8 bits, rigth? |> |> The length of the field is wide due to the text; that will be fixed to |> be proportional to the bit width (8 bits, as you note). |> |> | S 3. |> | >> At least one direction (inbound/outbound) SHOULD have |> | a non-NONE MAC in practice, but this MUST NOT be strictly |> | required by an implementation. |> | |> | 1. This seems like a bad idea. It's very hard to analyze the security |> | properties of a connection when only one side is protected. To take |> | one case that is obviously bad, if you're worried about DoS attacks |> | and you use TCP-AO, then forging packets in either direction can |> | bring it down. I would reverse this and require MACs in both directions. |> | |> | 2. Even if we stipulate that this might be an OK idea, it's not |> | appropriate to require implementations to support it. |> |> We discussed the utility of asymmetry in Philadelphia last March. The |> point is to require implementations to allow the user to request |> connections configured this way; we can add that connections MUST |> default to using a real MAC in both directions by default. Does that |> address your concern? | | Well, as I recall, you asserted it the value of it and I disagreed. I asserted the value of keeping it in for potential future use. | As I recall, the example you offered was the one-way authentication in | TLS, which is really not that apropos, since it only applies to the | key management protocol, not to the data, which is authenticated in | both directions. We discussed that in Phila. I recall that we agreed that this wasn't exactly like TLS. However, I preferred leaving it in for future use. | Perhaps you could restate your rationale for this? About 10 minutes into that future ;-), we were discussing (as I recall) channel binding and connection latching, at which point someone (?) suggested TCP-AO could start in NULL in one direction, and escalate via enabling a new KeyID (and thus configuration) via in-band exchange. I recall your noting that this was a good reason for asymmetry. We could update the doc to include that rationale... Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiN1sQACgkQE5f5cImnZrs1EwCgn+BB/umHsrKOWGDI9fJi2/zL LBYAn3tPQq57MNV+kIZV87gT9dGEIhWq =K5o/ -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 28 07:28:55 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74A8C3A6A49; Mon, 28 Jul 2008 07:28:55 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 315D63A6A1D for ; Mon, 28 Jul 2008 07:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0RDM8VSTQx9 for ; Mon, 28 Jul 2008 07:28:53 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 5789C3A69B9 for ; Mon, 28 Jul 2008 07:28:53 -0700 (PDT) Received: from [130.129.20.69] ([130.129.20.69]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6SESjIh005899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Jul 2008 07:28:48 -0700 (PDT) Message-ID: <488DD77D.9070608@isi.edu> Date: Mon, 28 Jul 2008 07:28:13 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eric Rescorla References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> In-Reply-To: <20080728131254.3DD764B88F7@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Eric, Eric Rescorla wrote: | I did want to make one more note. | | At Sun, 27 Jul 2008 23:38:32 -0700, | Joe Touch wrote: |> | - The discussion of key rollover seems incomplete |> | |> | >> TCP-AO implementations SHOULD change keys for a connection at |> | least every 2^31 bytes, to avoid resending segments with the same |> | TCP sequence number, data, and length under the same key. |> | |> | How is this intended to work? |> |> The key management mechanism should react to sequence numbers rolling |> over the ISN (perhaps masking out the high bit to roll over twice as often). | | Regardless of whether there is a KMP, it strikes me as unwise to punt this | job to it. There is a KMP; it is required (and we can't move forward to submit this as final until there is). | The TCP authentication protocol should be able to provide security for | packets even in the face of sequence number rollover, out to the | limits of security of the MAC algorithm (which far exceed 2^31 bytes | in both cases). There are (at least) two potential approaches: | | 1. Use a (synthetic) extended sequence number. We discussed this, but there are concerns with interactions with TCP. We don't want to add separate, coordinated state outside the existing TCP state mechanism. | 2. Change the key used to compute the MAC inside the protoco. Can you explain this? | But I don't think it's a good idea to punt this to the KMP, since | you don't really need to change the key for any cryptographic reason. If there's no cryptographic reason, why would we need to change the key at all? I.e., isn't the need for a unique per-packet nonce a cryptographic requirement (if not, why do we care?) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiN130ACgkQE5f5cImnZrsRLACfd5jC/XzZgCmYsvd8Kwex88pw op8AoMVQvcQDcs6YeuYKiFJ8MM9V0NiH =Up28 -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 28 07:47:18 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CAE83A6895; Mon, 28 Jul 2008 07:47:18 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DE923A6895 for ; Mon, 28 Jul 2008 07:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.55 X-Spam-Level: X-Spam-Status: No, score=-0.55 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCymRMX8swuC for ; Mon, 28 Jul 2008 07:47:12 -0700 (PDT) Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 40D663A6892 for ; Mon, 28 Jul 2008 07:47:12 -0700 (PDT) Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id AC9184B905A; Mon, 28 Jul 2008 07:47:21 -0700 (PDT) Date: Mon, 28 Jul 2008 07:47:21 -0700 From: Eric Rescorla To: Joe Touch In-Reply-To: <488DD77D.9070608@isi.edu> References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080728144721.AC9184B905A@kilo.rtfm.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Mon, 28 Jul 2008 07:28:13 -0700, Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Eric, > > Eric Rescorla wrote: > | I did want to make one more note. > | > | At Sun, 27 Jul 2008 23:38:32 -0700, > | Joe Touch wrote: > |> | - The discussion of key rollover seems incomplete > |> | > |> | >> TCP-AO implementations SHOULD change keys for a connection at > |> | least every 2^31 bytes, to avoid resending segments with the same > |> | TCP sequence number, data, and length under the same key. > |> | > |> | How is this intended to work? > |> > |> The key management mechanism should react to sequence numbers rolling > |> over the ISN (perhaps masking out the high bit to roll over twice as > often). > | > | Regardless of whether there is a KMP, it strikes me as unwise to punt this > | job to it. > > There is a KMP; it is required (and we can't move forward to submit this > as final until there is). Well, as I've indicated previously, I don't agree that a KMP is required or desirable. It's quite straightforward to make this system work with a single, pairwise, static key, provided you have an appropriate key diversification mechanism. If you want to call that a KMP, I suppose you could, but since it doesn't require actually exchanging any messages, I would not do so. If your assertion is that a KMP is required to make this protocol useful, given that (1) there's no draft for such a KMP on the horizon and (2) the most likely consumers of this draft, the routing/ops community, seem to have no interest in doing a KMP, then I think this raises serious questions about the viability of this approach. > | The TCP authentication protocol should be able to provide security for > | packets even in the face of sequence number rollover, out to the > | limits of security of the MAC algorithm (which far exceed 2^31 bytes > | in both cases). There are (at least) two potential approaches: > | > | 1. Use a (synthetic) extended sequence number. > > We discussed this, but there are concerns with interactions with TCP. We > don't want to add separate, coordinated state outside the existing TCP > state mechanism. Uh, ok... It's not like this doesn't need to be tightly coordinated with TCP in any case. > | 2. Change the key used to compute the MAC inside the protoco. > > Can you explain this? Sure. You have a per-connection key. Every time the sequence number rolls, you run the KDF again to generate a fresh per-connection key. No KMP required. (This meshes with my previous key diversification comments). > | But I don't think it's a good idea to punt this to the KMP, since > | you don't really need to change the key for any cryptographic reason. > > If there's no cryptographic reason, why would we need to change the key > at all? I.e., isn't the need for a unique per-packet nonce a > cryptographic requirement (if not, why do we care?) There is no need for a unique per-packet nonce. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 28 08:06:02 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 844CB3A691C; Mon, 28 Jul 2008 08:06:02 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC5B3A691C for ; Mon, 28 Jul 2008 08:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnLzrDfnO7Jp for ; Mon, 28 Jul 2008 08:05:57 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E86FC3A6895 for ; Mon, 28 Jul 2008 08:05:56 -0700 (PDT) Received: from [130.129.20.69] ([130.129.20.69]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6SF5a3p017817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Jul 2008 08:05:39 -0700 (PDT) Message-ID: <488DE021.7070307@isi.edu> Date: Mon, 28 Jul 2008 08:05:05 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eric Rescorla References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> In-Reply-To: <20080728144721.AC9184B905A@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rescorla wrote: ... |> | Regardless of whether there is a KMP, it strikes me as unwise to punt this |> | job to it. |> |> There is a KMP; it is required (and we can't move forward to submit this |> as final until there is). | | Well, as I've indicated previously, I don't agree that a KMP is | required or desirable. It's quite straightforward to make this system | work with a single, pairwise, static key, provided you have an | appropriate key diversification mechanism. If you want to call that a | KMP, I suppose you could, but since it doesn't require actually | exchanging any messages, I would not do so. OK; we're dancing around terms here. TCP-AO uses a _separate_ document to specify the out-of-band key mechanism. What that includes can be discussed in that context - e.g., on SAAG. | If your assertion is that a KMP is required to make this protocol | useful, given that (1) there's no draft for such a KMP on the | horizon and (2) the most likely consumers of this draft, the | routing/ops community, seem to have no interest in doing a KMP, | then I think this raises serious questions about the viability | of this approach. The "KMP" (or whatever we're calling it) should be underway in SAAG; if it has stalled, then we'll address that issue off-list. |> | The TCP authentication protocol should be able to provide security for |> | packets even in the face of sequence number rollover, out to the |> | limits of security of the MAC algorithm (which far exceed 2^31 bytes |> | in both cases). There are (at least) two potential approaches: |> | |> | 1. Use a (synthetic) extended sequence number. |> |> We discussed this, but there are concerns with interactions with TCP. We |> don't want to add separate, coordinated state outside the existing TCP |> state mechanism. | | Uh, ok... It's not like this doesn't need to be tightly coordinated | with TCP in any case. | | |> | 2. Change the key used to compute the MAC inside the protoco. |> |> Can you explain this? | | Sure. You have a per-connection key. Every time the sequence number | rolls, you run the KDF again to generate a fresh per-connection key. | No KMP required. (This meshes with my previous key diversification | comments). That's burying the key generation protocol inside TCP-AO. My understanding is that this is the reason for an external mechanism, whatever it is called, and regardless of whether it explicitly or implicitly coordinates with the other end (you're referring to implicit coordination). |> | But I don't think it's a good idea to punt this to the KMP, since |> | you don't really need to change the key for any cryptographic reason. |> |> If there's no cryptographic reason, why would we need to change the key |> at all? I.e., isn't the need for a unique per-packet nonce a |> cryptographic requirement (if not, why do we care?) | | There is no need for a unique per-packet nonce. If so, then why generate fresh keys on rollover? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiN4CAACgkQE5f5cImnZrsZfACg5JAuUmZvhyEEZ8t62f5L3ngc shwAoMqqK1ZZ3lbEPWpl535UbP+SHPSq =VXgX -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 28 09:19:18 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5317428C1FE; Mon, 28 Jul 2008 09:19:18 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F6AE28C1FE for ; Mon, 28 Jul 2008 09:19:17 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R15L3+0qVhi2 for ; Mon, 28 Jul 2008 09:19:11 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 84F5728C1ED for ; Mon, 28 Jul 2008 09:19:11 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so3723071rvf.49 for ; Mon, 28 Jul 2008 09:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=hw+Rxdz7VfiguFJ+1MUPKq1SwGeAgyOCR92/753xq9k=; b=BnjaBy497lL/VMeURIdlwq8oOtW1F62C+GzGY1N6t45sX8powebz6ZsERyRaW8YpCn ZRRJ3UVLLys/pvY3WkK+ub80SQx4zoH8nZgz1nKeJrg+W9KKH3m7nBgU3R0BpviDhwNZ nrQpUlkntZV9I+OkqG/SKGWfNlquuFeoqFB50= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=eLyJw7u7peSyOaLGAOcYBMYQDP7UWiARSrgxLZQkxeRXA3MFFv4YKAoaRfBorvWigh 2wMK9WuFc2l61bW9baKJoyacf5ETUPTRrfh1jQHGx4csbPT29vdqfiaWTKA6AoDb6HZT w/c/eDf3R8UrYVulgc5olEZJKQYPNZUdHuPRE= Received: by 10.140.136.5 with SMTP id j5mr2464889rvd.27.1217261960847; Mon, 28 Jul 2008 09:19:20 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Mon, 28 Jul 2008 09:19:20 -0700 (PDT) Message-ID: <396556a20807280919u5ddb2c5o820f9743344f3093@mail.gmail.com> Date: Mon, 28 Jul 2008 09:19:20 -0700 From: "Adam Langley" To: "LANGE Andrew" In-Reply-To: <66F9363AB70F764C96547BD8A0A3679E154B7C@USDALSMBS05.ad3.ad.alcatel.com> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20807181432s2bc50f84kf932b9804c6abf24@mail.gmail.com> <396556a20807181440i438f2696yced3e0c7d713bd1f@mail.gmail.com> <66F9363AB70F764C96547BD8A0A3679E154B7C@USDALSMBS05.ad3.ad.alcatel.com> X-Google-Sender-Auth: a630eea6c4b4007b Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP Auth experimental Linux patches X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Mon, Jul 28, 2008 at 5:56 AM, LANGE Andrew wrote: > I think it's fantastic that you're working on an implementation of extended > tcp auth. However, I fear your efforts may be misdirected. The reason is > that the settled-down spec in draft-bonica, not the one in the tcpm working > group draft. Draft-bonica is implemented, deployed and interops between > Alcatel, Cisco and Juniper routers. Implementing draft-bonica, and testing > against the router implementations would be the right direction to pursue. The draft-bonica is, indeed *very* similar to TCP-AO (the same cryptographic weaknesses and all, sadly). In fact, I believe that it would be about an extra dozen lines of code to add support for it. Since you claim that it has some deployment, that would certainly seem to be worthwhile to do. The patch has seen some work since I first posted it and the userspace interface is now described in [1]. It would be most helpful if you could review that. I believe that the only difference is that I have the MAC function as a property of a keyset, not a key. If you are intending on key rotation also changing the MAC function then that would have to change. Cheers, [1] http://marc.info/?l=linux-netdev&m=121702166623000&w=2 AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 28 09:31:37 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB9423A6A03; Mon, 28 Jul 2008 09:31:37 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C26F83A6A03 for ; Mon, 28 Jul 2008 09:31:36 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmvhOMPQhpoY for ; Mon, 28 Jul 2008 09:31:36 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id 030853A69E4 for ; Mon, 28 Jul 2008 09:31:35 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so3727989rvf.49 for ; Mon, 28 Jul 2008 09:31:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=X4pfFHZ4K3eqssa8DpG91XABdt7Y+p2YkkLau9MScZA=; b=OxKakTnJzvpaRU1N7v4pCaTzXwvgZR0hmFjlINaF/uUSKrggBSdULTz3PnDLrUcZ6t quZKs+qRCajgVfHLIRuX9KO3see6UR5M7DHLgKhQXO0rle7GJ1tK0Mj7Q7tBCxvWIhyN Xk4M6QE6crkbER2ZebqO7f2DaqqQhnNQLazHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=qM3I2uqmR2L27yMBW6Y0HqZR9Imnxim327Vj8FcnUV52+LnG/Pqemt3CUQPVws6m4y 6+hasc7X24N7Mz3nXp8WRGPy9CqVNn5QTQkKmy7mlHygRml+1S/BwqNSZuu1oaBpz6FX NffEl4t9yp+naP77w6IYuVgv1ne3FIqxhR5R4= Received: by 10.141.29.21 with SMTP id g21mr2461054rvj.248.1217262706152; Mon, 28 Jul 2008 09:31:46 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Mon, 28 Jul 2008 09:31:46 -0700 (PDT) Message-ID: <396556a20807280931i257c6597o14cf45f8710611bf@mail.gmail.com> Date: Mon, 28 Jul 2008 09:31:46 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <488DE021.7070307@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> X-Google-Sender-Auth: d296c1165e78af7c Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Mon, Jul 28, 2008 at 8:05 AM, Joe Touch wrote: > | There is no need for a unique per-packet nonce. > > If so, then why generate fresh keys on rollover? (This is pretty much a reposting of a previous email, but people still seem to be hazy on this point) We have a couple of reasons for wanting to define an nonce: Reason 1: Without a monotonic counter, a MAC is open to replay attacks. I'm not sure how serious this is. Certainly you can elicit different behaviour from stacks by replaying, say, an ACK very quickly. This is undesirable, but it might be acceptable. More troubling is the possibility of exploiting sequence number rollover to inject a valid packet from 2^32 bytes in the past into the current stream. A monotonic nonce would mean that we could reject replays. Rotating the keys faster than the sequence number rolls over mitigates the most grievous of these issues. Reason 2: Modern dot-product and polynomial MAC functions require an nonce as an input and their security depends on the nonce never being reused for any other message with the same key. Consider a connection where all the application-level data transfer is one way and a packet, seq number n, is lost by the network. Here, it's very possible that an ACK for n-1 is transmitted, followed by an ACK for n-1 with a SACK option. Now we've transmitted two different messages with the same nonce. Any nonce based only the sequence numbers has this problem unless we disable/don't include SACK. Also, if we are only including 32-bits of seq, then we trivially repeat every 2^32 bytes. Now, we can just ignore the MAC functions described in reason 2; having a per-message counter is probably too much additional work. Having a "pseudo" extended sequence number is very little work (really, I've already implemented it) and that mean that we don't have to rekey faster than the 32-bit sequence rollover. However, the rekeying isn't all that painful anyway. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 28 09:40:04 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7C5B28C10C; Mon, 28 Jul 2008 09:40:04 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A557528C10C for ; Mon, 28 Jul 2008 09:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOGH3NFAVw6h for ; Mon, 28 Jul 2008 09:40:02 -0700 (PDT) Received: from kilo.rtfm.com (unknown [12.155.21.101]) by core3.amsl.com (Postfix) with ESMTP id 6F62E3A6915 for ; Mon, 28 Jul 2008 09:40:02 -0700 (PDT) Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 422D14B9600; Mon, 28 Jul 2008 09:40:13 -0700 (PDT) Date: Mon, 28 Jul 2008 09:40:13 -0700 From: Eric Rescorla To: Joe Touch In-Reply-To: <488DE021.7070307@isi.edu> References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080728164013.422D14B9600@kilo.rtfm.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Mon, 28 Jul 2008 08:05:05 -0700, Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Eric Rescorla wrote: > ... > |> | Regardless of whether there is a KMP, it strikes me as unwise to > punt this > |> | job to it. > |> > |> There is a KMP; it is required (and we can't move forward to submit this > |> as final until there is). > | > | Well, as I've indicated previously, I don't agree that a KMP is > | required or desirable. It's quite straightforward to make this system > | work with a single, pairwise, static key, provided you have an > | appropriate key diversification mechanism. If you want to call that a > | KMP, I suppose you could, but since it doesn't require actually > | exchanging any messages, I would not do so. > > OK; we're dancing around terms here. TCP-AO uses a _separate_ document > to specify the out-of-band key mechanism. What that includes can be > discussed in that context - e.g., on SAAG. Well, I think that's a mistake as well. (1) It's extremely confusing to have two documents. (2) There are two issues: - What's used to establish an association and keying material - How that association and keying material get turned into per session keying material. In IPsec with IKE, the KMP is run for every new association and so these end up specified in a separate document as a single entity. However, in this case, because people don't want a separat KMP run for each association, these are separate. The second needs to be tied to the transport protocol. The first is replaceable. The problem here is that you have merged them and treated them both as separate. That's problematic. (3) SAAG has no capability to work on anything, and isn't doing so. > |> | The TCP authentication protocol should be able to provide security for > |> | packets even in the face of sequence number rollover, out to the > |> | limits of security of the MAC algorithm (which far exceed 2^31 bytes > |> | in both cases). There are (at least) two potential approaches: > |> | > |> | 1. Use a (synthetic) extended sequence number. > |> > |> We discussed this, but there are concerns with interactions with TCP. We > |> don't want to add separate, coordinated state outside the existing TCP > |> state mechanism. > | > | Uh, ok... It's not like this doesn't need to be tightly coordinated > | with TCP in any case. > | > | > |> | 2. Change the key used to compute the MAC inside the protoco. > |> > |> Can you explain this? > | > | Sure. You have a per-connection key. Every time the sequence number > | rolls, you run the KDF again to generate a fresh per-connection key. > | No KMP required. (This meshes with my previous key diversification > | comments). > > That's burying the key generation protocol inside TCP-AO. Again, key generation != key establishment. > |> | But I don't think it's a good idea to punt this to the KMP, since > |> | you don't really need to change the key for any cryptographic reason. > |> > |> If there's no cryptographic reason, why would we need to change the key > |> at all? I.e., isn't the need for a unique per-packet nonce a > |> cryptographic requirement (if not, why do we care?) > | > | There is no need for a unique per-packet nonce. > > If so, then why generate fresh keys on rollover? The protocol must be constructed so that it is not possible to substitute one packet for another and have it be accepted. This means that (either) the data fed into the authentication function must be distinct or the authentication function must have a distinct key. I wouldn't call this a "nonce" in either case, and I don't know what a "per-packet nonce" means. We're talking about the connection and packet parameters. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 28 09:42:27 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43FCC28C10C; Mon, 28 Jul 2008 09:42:27 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 422313A6829 for ; Mon, 28 Jul 2008 09:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxQ7ouk12FJq for ; Mon, 28 Jul 2008 09:42:25 -0700 (PDT) Received: from kilo.rtfm.com (unknown [12.155.21.101]) by core3.amsl.com (Postfix) with ESMTP id 76AAF3A6915 for ; Mon, 28 Jul 2008 09:42:25 -0700 (PDT) Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 8DD974B96B6; Mon, 28 Jul 2008 09:42:35 -0700 (PDT) Date: Mon, 28 Jul 2008 09:42:35 -0700 From: Eric Rescorla To: "Adam Langley" In-Reply-To: <396556a20807280931i257c6597o14cf45f8710611bf@mail.gmail.com> References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <396556a20807280931i257c6597o14cf45f8710611bf@mail.gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080728164235.8DD974B96B6@kilo.rtfm.com> Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Mon, 28 Jul 2008 09:31:46 -0700, Adam Langley wrote: > > On Mon, Jul 28, 2008 at 8:05 AM, Joe Touch wrote: > > | There is no need for a unique per-packet nonce. > > > > If so, then why generate fresh keys on rollover? > > (This is pretty much a reposting of a previous email, but people still > seem to be hazy on this point) > > We have a couple of reasons for wanting to define an nonce: > > Reason 1: Without a monotonic counter, a MAC is open to replay > attacks. I'm not sure how serious this is. Certainly you can elicit > different behaviour from stacks by replaying, say, an ACK very > quickly. This is undesirable, but it might be acceptable. More > troubling is the possibility of exploiting sequence number rollover to > inject a valid packet from 2^32 bytes in the past into the current > stream. A monotonic nonce would mean that we could reject replays. > > Rotating the keys faster than the sequence number rolls over mitigates > the most grievous of these issues. > > Reason 2: Modern dot-product and polynomial MAC functions require an > nonce as an input and their > security depends on the nonce never being reused for any other message > with the same key. Consider a connection where all the > application-level data transfer is one way and a packet, seq number n, > is lost by the network. Here, it's very possible that an ACK for n-1 > is transmitted, followed by an ACK for n-1 with a SACK option. Now > we've transmitted two different messages with the same nonce. Any > nonce based only the sequence numbers has this problem unless we > disable/don't include SACK. Also, if we are only including 32-bits of > seq, then we trivially repeat every 2^32 bytes. > > Now, we can just ignore the MAC functions described in reason 2; Indeed, we should do so. If those algorithms in fact need a MAC they should describe some procedure for generating and using them (and presumably attaching them to the message). AFAIK, neither HMAC nor CBC-MAC requires such a nonce. > having a per-message counter is probably too much additional work. > Having a "pseudo" extended sequence number is very little work > (really, I've already implemented it) and that mean that we don't have > to rekey faster than the 32-bit sequence rollover. However, the > rekeying isn't all that painful anyway. It depends what you mean by rekeying. If it involves a new protocol exchange it is incredibly painful. If you mean just running the kdf again, I agree that's fine. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 28 09:48:07 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AC0C28C205; Mon, 28 Jul 2008 09:48:07 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AA0F28C1FD for ; Mon, 28 Jul 2008 09:48:05 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q89AwOODZSk5 for ; Mon, 28 Jul 2008 09:48:02 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by core3.amsl.com (Postfix) with ESMTP id 01D3A28C1CF for ; Mon, 28 Jul 2008 09:48:01 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so3734588rvf.49 for ; Mon, 28 Jul 2008 09:48:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=FrMXHBr3WNmKrMuS+egTmzEvmwcUft47EEcpr3uC298=; b=io9ch13LmY5Q/ww8J1HzCKOI33JeLCyE26DokNsDaGELPThTslWHgHJ34eXDSeTWCE 4Vf7QJVu/Iv1QxCK210VfIhqO5lsLTLVdA4M2lgeqV7FcpfcRp3i1PWKw9q/ImJckH2x q4yFRFs4WGY1CA8uNhWSvwQs308Sbzmw8HvmA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=Wr4HuQDnPl167jM0L9Len1JQqq8iMJrP6wz++FRn9KbnXaxULo3bm28UaDR3NtgZ9E AZjJ+5NK8EocHRMZ/YYF9pjbf0zVU2H8I7RHGKDX/k4Ib5Ynh39sYz8FdXjWLeM3FhHK KAD1uyPeG4e0CUXjzzzIB05lQxOarNHv4F5Xw= Received: by 10.141.198.9 with SMTP id a9mr2462079rvq.238.1217263692043; Mon, 28 Jul 2008 09:48:12 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Mon, 28 Jul 2008 09:48:11 -0700 (PDT) Message-ID: <396556a20807280948g3b44bec6reb5ec006edcfe64c@mail.gmail.com> Date: Mon, 28 Jul 2008 09:48:11 -0700 From: "Adam Langley" To: "Eric Rescorla" In-Reply-To: <20080728164235.8DD974B96B6@kilo.rtfm.com> MIME-Version: 1.0 Content-Disposition: inline References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <396556a20807280931i257c6597o14cf45f8710611bf@mail.gmail.com> <20080728164235.8DD974B96B6@kilo.rtfm.com> X-Google-Sender-Auth: df76fb409756f927 Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Mon, Jul 28, 2008 at 9:42 AM, Eric Rescorla wrote: > It depends what you mean by rekeying. If it involves a new protocol > exchange it is incredibly painful. If you mean just running the kdf > again, I agree that's fine. It would just be rerunning the KDF every 2**31 bytes. I'd suggest something along the lines of this: For keys k1, k2, k3, ... and a manually configured master key K: H(x) is some hash function (say SHA1) H2(x) = H(x | "\x00") k1 = H2(K) k2 = H2(H(K)) k3 = H2(H(H(k))) ... AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 28 09:54:59 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B36B28C205; Mon, 28 Jul 2008 09:54:59 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C79B23A6AA8 for ; Mon, 28 Jul 2008 09:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CI6g3yGJtDpQ for ; Mon, 28 Jul 2008 09:54:56 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id EFE0828C21F for ; Mon, 28 Jul 2008 09:54:48 -0700 (PDT) Received: from [130.129.20.69] ([130.129.20.69]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6SGptLI024929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Jul 2008 09:51:58 -0700 (PDT) Message-ID: <488DF90B.1070803@isi.edu> Date: Mon, 28 Jul 2008 09:51:23 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <396556a20807280931i257c6597o14cf45f8710611bf@mail.gmail.com> In-Reply-To: <396556a20807280931i257c6597o14cf45f8710611bf@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam, Adam Langley wrote: | On Mon, Jul 28, 2008 at 8:05 AM, Joe Touch wrote: |> | There is no need for a unique per-packet nonce. |> |> If so, then why generate fresh keys on rollover? | | (This is pretty much a reposting of a previous email, but people still | seem to be hazy on this point) Indeed - note that the statement above is from you indicating that there is no need for a per packet nonce. | We have a couple of reasons for wanting to define an nonce: So this indicates you want one Which is it? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiN+QsACgkQE5f5cImnZrsXlgCdERWisDmYJmDuyyE9ECphenmj d0MAnjalXgjVYo1kjrPlQZsNdFN4f8qZ =TbvN -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 28 10:00:18 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67A528C21F; Mon, 28 Jul 2008 10:00:18 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9433528C1FC for ; Mon, 28 Jul 2008 10:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVo4w5yDQg-a for ; Mon, 28 Jul 2008 10:00:16 -0700 (PDT) Received: from kilo.rtfm.com (unknown [12.155.21.101]) by core3.amsl.com (Postfix) with ESMTP id CBFA43A69BF for ; Mon, 28 Jul 2008 10:00:16 -0700 (PDT) Received: from host138-59.wifi.conference.usenix.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 0D8824B9B6B; Mon, 28 Jul 2008 10:00:26 -0700 (PDT) Date: Mon, 28 Jul 2008 10:00:26 -0700 From: Eric Rescorla To: "Adam Langley" In-Reply-To: <396556a20807280948g3b44bec6reb5ec006edcfe64c@mail.gmail.com> References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <396556a20807280931i257c6597o14cf45f8710611bf@mail.gmail.com> <20080728164235.8DD974B96B6@kilo.rtfm.com> <396556a20807280948g3b44bec6reb5ec006edcfe64c@mail.gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080728170027.0D8824B9B6B@kilo.rtfm.com> Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Mon, 28 Jul 2008 09:48:11 -0700, Adam Langley wrote: > > On Mon, Jul 28, 2008 at 9:42 AM, Eric Rescorla wrote: > > It depends what you mean by rekeying. If it involves a new protocol > > exchange it is incredibly painful. If you mean just running the kdf > > again, I agree that's fine. > > It would just be rerunning the KDF every 2**31 bytes. I'd suggest > something along the lines of this: > > For keys k1, k2, k3, ... and a manually configured master key K: > > H(x) is some hash function (say SHA1) > H2(x) = H(x | "\x00") > > k1 = H2(K) > k2 = H2(H(K)) > k3 = H2(H(H(k))) > ... Obviously there are a number of ways to do this. I think I would prefer to use an ESN, but I agree this would work. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 28 10:48:39 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA8F83A69E4; Mon, 28 Jul 2008 10:48:39 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D97F3A69BF for ; Mon, 28 Jul 2008 10:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cul7ozANxDF for ; Mon, 28 Jul 2008 10:48:34 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 2C6FE3A69EB for ; Mon, 28 Jul 2008 10:48:34 -0700 (PDT) Received: from [130.129.20.69] ([130.129.20.69]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6SHmJ0Z015656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Jul 2008 10:48:23 -0700 (PDT) Message-ID: <488E0644.6020006@isi.edu> Date: Mon, 28 Jul 2008 10:47:48 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eric Rescorla References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <20080728164013.422D14B9600@kilo.rtfm.com> In-Reply-To: <20080728164013.422D14B9600@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Eric, Eric Rescorla wrote: ... |> OK; we're dancing around terms here. TCP-AO uses a _separate_ document |> to specify the out-of-band key mechanism. What that includes can be |> discussed in that context - e.g., on SAAG. | | Well, I think that's a mistake as well. That's outside the scope of this document; that was handed to the design team as a requirement of this work. Perhaps the ADs should address the reasons directly. | (2) There are two issues: | | - What's used to establish an association and keying material | - How that association and keying material get turned into | per session keying material. | | In IPsec with IKE, the KMP is run for every new association | and so these end up specified in a separate document as | a single entity. However, in this case, because people don't | want a separat KMP run for each association, these are separate. I'm not sure this is the case... | The second needs to be tied to the transport protocol. The | first is replaceable. The problem here is that you have | merged them and treated them both as separate. That's problematic. Are you saying that we generate per-session keys inside TCP-AO? We attempted to split the TCP-AO/key issue in a particular place; if there's a better place to split (e.g., burying the ISN stuff in the TCP-AO side), it might be useful to hear more... My concern is that the point of the key system is to decouple potential changes to session keying from the option side. All the crypto-related info should stay on the keying/MAC side of the house if at all possible, i.e., external to TCP-AO. | (3) SAAG has no capability to work on anything, and isn't doing so. Tim Polk spoke to that issue; he said we'd see something this fall. |> |> | The TCP authentication protocol should be able to provide security for |> |> | packets even in the face of sequence number rollover, out to the |> |> | limits of security of the MAC algorithm (which far exceed 2^31 bytes |> |> | in both cases). There are (at least) two potential approaches: |> |> | |> |> | 1. Use a (synthetic) extended sequence number. |> |> |> |> We discussed this, but there are concerns with interactions with TCP. We |> |> don't want to add separate, coordinated state outside the existing TCP |> |> state mechanism. |> | |> | Uh, ok... It's not like this doesn't need to be tightly coordinated |> | with TCP in any case. |> | |> | |> |> | 2. Change the key used to compute the MAC inside the protoco. |> |> |> |> Can you explain this? |> | |> | Sure. You have a per-connection key. Every time the sequence number |> | rolls, you run the KDF again to generate a fresh per-connection key. |> | No KMP required. (This meshes with my previous key diversification |> | comments). |> |> That's burying the key generation protocol inside TCP-AO. | | Again, key generation != key establishment. Agreed, but there is utility in keeping TCP-AO clean from algorithmic crypto issues. |> |> | But I don't think it's a good idea to punt this to the KMP, since |> |> | you don't really need to change the key for any cryptographic reason. |> |> |> |> If there's no cryptographic reason, why would we need to change the key |> |> at all? I.e., isn't the need for a unique per-packet nonce a |> |> cryptographic requirement (if not, why do we care?) |> | |> | There is no need for a unique per-packet nonce. |> |> If so, then why generate fresh keys on rollover? | | The protocol must be constructed so that it is not possible to substitute | one packet for another and have it be accepted. This means that (either) | the data fed into the authentication function must be distinct or the | authentication function must have a distinct key. That implies a per-packet nonce, i.e., some fields - either in the packet or external - that are unique on a per-packet basis. | I wouldn't call this | a "nonce" in either case, and I don't know what a "per-packet nonce" | means. We're talking about the connection and packet parameters. I think this is a per-packet nonce, at least as I understand it. As I noted, that can be handled by the rekeying system. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiOBkQACgkQE5f5cImnZruV1ACeJYsf3Fii9DK8p61shBGPg4Rc h+QAoO9cJwsuakk8fsvg5KbklGy/z25Z =n6A1 -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 28 10:52:56 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0004028C285; Mon, 28 Jul 2008 10:52:55 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 088D328C284 for ; Mon, 28 Jul 2008 10:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrRvyXNlef-T for ; Mon, 28 Jul 2008 10:52:54 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 31B1B28C27A for ; Mon, 28 Jul 2008 10:52:54 -0700 (PDT) Received: from [130.129.20.69] ([130.129.20.69]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6SHqebd017031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Jul 2008 10:52:43 -0700 (PDT) Message-ID: <488E0749.4020402@isi.edu> Date: Mon, 28 Jul 2008 10:52:09 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eric Rescorla References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <396556a20807280931i257c6597o14cf45f8710611bf@mail.gmail.com> <20080728164235.8DD974B96B6@kilo.rtfm.com> In-Reply-To: <20080728164235.8DD974B96B6@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rescorla wrote: ... |> having a per-message counter is probably too much additional work. |> Having a "pseudo" extended sequence number is very little work |> (really, I've already implemented it) and that mean that we don't have |> to rekey faster than the 32-bit sequence rollover. However, the |> rekeying isn't all that painful anyway. | | It depends what you mean by rekeying. If it involves a new protocol | exchange it is incredibly painful. If you mean just running the kdf | again, I agree that's fine. Both ends' key mgt systems can run the kdf again and this should work fine. No need for on-the-wire exchanges, but no need to bury this into TCP-AO IMO either. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiOB0gACgkQE5f5cImnZrtmqgCgq1OGBsETKUajidCElKPJh7ZN AzYAoIaUxkjGmFBWU4lGz7RchGODflI1 =Mait -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 28 11:02:51 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2FCC28C292; Mon, 28 Jul 2008 11:02:51 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFCA328C290 for ; Mon, 28 Jul 2008 11:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFWxeTo-Hz6U for ; Mon, 28 Jul 2008 11:02:44 -0700 (PDT) Received: from kilo.rtfm.com (unknown [12.155.21.101]) by core3.amsl.com (Postfix) with ESMTP id F393028C267 for ; Mon, 28 Jul 2008 11:02:43 -0700 (PDT) Received: from host138-59.wifi.conference.usenix.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 6181A4BA162; Mon, 28 Jul 2008 11:02:53 -0700 (PDT) Date: Mon, 28 Jul 2008 11:02:53 -0700 From: Eric Rescorla To: Joe Touch In-Reply-To: <488E0749.4020402@isi.edu> References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <396556a20807280931i257c6597o14cf45f8710611bf@mail.gmail.com> <20080728164235.8DD974B96B6@kilo.rtfm.com> <488E0749.4020402@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080728180253.6181A4BA162@kilo.rtfm.com> Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Mon, 28 Jul 2008 10:52:09 -0700, Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Eric Rescorla wrote: > ... > |> having a per-message counter is probably too much additional work. > |> Having a "pseudo" extended sequence number is very little work > |> (really, I've already implemented it) and that mean that we don't have > |> to rekey faster than the 32-bit sequence rollover. However, the > |> rekeying isn't all that painful anyway. > | > | It depends what you mean by rekeying. If it involves a new protocol > | exchange it is incredibly painful. If you mean just running the kdf > | again, I agree that's fine. > > Both ends' key mgt systems can run the kdf again and this should work > fine. No need for on-the-wire exchanges, but no need to bury this into > TCP-AO IMO either. Well, it needs to be used with TCP-AO regardless of which integrity algorithm is used. Why wouldn't we want to "bury" that in TCP-AO? -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 28 11:06:28 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D541C3A6AB6; Mon, 28 Jul 2008 11:06:28 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB0EE3A6A03 for ; Mon, 28 Jul 2008 11:06:27 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKfOBD7JoBRJ for ; Mon, 28 Jul 2008 11:06:27 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id 95C7C3A6AB6 for ; Mon, 28 Jul 2008 11:06:26 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so1408658ywj.49 for ; Mon, 28 Jul 2008 11:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=he87tCJF5mOvyvIPwAXR52AU+0rwKGliywdx5qWn1qw=; b=lxFvdCZMxrAfQOxatnlmUhdmI9G5GnySCSPt4lMGFokOCd4YhBa7+B9Sl8r/4KF41E U+sSwikMWOF7h7ISZEqKgwqZaeMfm9lHNFgh6WqGSz2U9hN0RltBWkS/IdHXUjUfBFHT L7AoWtwi8qPBmXvQjwnJ979UT45Ms6+I6s7TA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=Tuju9j/DYu4uRbzfBCkv1nxNgtvzaW94c67c+wqNq8Nxwp9bxbTMu1w8mOSpcqkpAO ZUeZmxIQxzszg9ROvgXzPbSH8/Q5el5g1jTXEzmaYOO2jDjHte/oUUkH4RyuXYTMrX6c b1zqirACW4zZx1vVQI0B+BFX8lSQAlYK/CMpE= Received: by 10.142.158.3 with SMTP id g3mr1687899wfe.344.1217268395376; Mon, 28 Jul 2008 11:06:35 -0700 (PDT) Received: by 10.142.203.9 with HTTP; Mon, 28 Jul 2008 11:06:35 -0700 (PDT) Message-ID: <396556a20807281106kfe6eb89sdb32d3836e508ea0@mail.gmail.com> Date: Mon, 28 Jul 2008 11:06:35 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <488E0749.4020402@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <396556a20807280931i257c6597o14cf45f8710611bf@mail.gmail.com> <20080728164235.8DD974B96B6@kilo.rtfm.com> <488E0749.4020402@isi.edu> X-Google-Sender-Auth: 848333f27dca65dd Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Some points from the discussion: Regarding NATs: Your reasoning, as I understood it, for not including an option to exclude the pseudoheader and port numbers for NAT traversal was that the host needs these items to lookup the correct key anyway. There are several situation where this is not the case. (I'll point out that I see TCP-AO as being useful outside the domain of securing BGP sessions between backbone routers) 1) A host installs a key on a listening socket with a wildcard address. Thus, one can only connect to the socket if you know the key. The key probably rotates based on time. This is currently, usually done based on "port knocking" - which has always struck me as a messy solution. The resulting, ESTABLISHED connection knows the port numbers and IP addresses without having to establish it before hand. 2) An unauthenticated connection is established and the userland code wishes to upgrade to TCP-AO. Again, since the connection is established the keyset to use are implicit. I didn't know that the NONE mac was designed for upgrading like this. In my Linux patches there's a TCP_AUTH_LATCH option which means "accept unsigned packets until the first signed packet, then require signatures". In both of these cases, excluding port numbers and/or pesudoheaders is needed given the deployment of NAT boxes which change these headers. Keyids: I agree that keeping the cryptography in the MAC is a good thing. There is an implementation issue about the number of keys that a kernel may have to store (80ish bytes per key * 256 keys * number of configured hosts), but that's not a spec problem. -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 28 11:07:47 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B931228C2A1; Mon, 28 Jul 2008 11:07:47 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B76828C29D for ; Mon, 28 Jul 2008 11:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32zjtoyrbLnH for ; Mon, 28 Jul 2008 11:07:46 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 3CB6328C2A0 for ; Mon, 28 Jul 2008 11:07:46 -0700 (PDT) Received: from [130.129.20.69] ([130.129.20.69]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6SI7Cat023272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Jul 2008 11:07:16 -0700 (PDT) Message-ID: <488E0AB1.8060905@isi.edu> Date: Mon, 28 Jul 2008 11:06:41 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eric Rescorla References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <396556a20807280931i257c6597o14cf45f8710611bf@mail.gmail.com> <20080728164235.8DD974B96B6@kilo.rtfm.com> <488E0749.4020402@isi.edu> <20080728180253.6181A4BA162@kilo.rtfm.com> In-Reply-To: <20080728180253.6181A4BA162@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rescorla wrote: | At Mon, 28 Jul 2008 10:52:09 -0700, | Joe Touch wrote: |> -----BEGIN PGP SIGNED MESSAGE----- |> Hash: SHA1 |> |> |> |> Eric Rescorla wrote: |> ... |> |> having a per-message counter is probably too much additional work. |> |> Having a "pseudo" extended sequence number is very little work |> |> (really, I've already implemented it) and that mean that we don't have |> |> to rekey faster than the 32-bit sequence rollover. However, the |> |> rekeying isn't all that painful anyway. |> | |> | It depends what you mean by rekeying. If it involves a new protocol |> | exchange it is incredibly painful. If you mean just running the kdf |> | again, I agree that's fine. |> |> Both ends' key mgt systems can run the kdf again and this should work |> fine. No need for on-the-wire exchanges, but no need to bury this into |> TCP-AO IMO either. | | Well, it needs to be used with TCP-AO regardless of which | integrity algorithm is used. Why wouldn't we want to | "bury" that in TCP-AO? The point of the split of TCP-AO and the key system was to leave the latter in the hands of SAAG. Since the key system MUST be used with TCP-AO, it's all part of the solution anyway. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiOCrEACgkQE5f5cImnZrtO9wCg3Gzwu2KIEFerjoenQhTd8Gri YSYAoNQT9zkuJLn75hBFjYF4zr2SF3sE =j2pz -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 28 11:09:03 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F2F928C2A7; Mon, 28 Jul 2008 11:09:03 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6049C28C2A7 for ; Mon, 28 Jul 2008 11:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8mFnLCQFWU4 for ; Mon, 28 Jul 2008 11:08:57 -0700 (PDT) Received: from kilo.rtfm.com (unknown [12.155.21.101]) by core3.amsl.com (Postfix) with ESMTP id F318E28C0FB for ; Mon, 28 Jul 2008 11:08:56 -0700 (PDT) Received: from host138-59.wifi.conference.usenix.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 22EC04BA1D7; Mon, 28 Jul 2008 11:09:07 -0700 (PDT) Date: Mon, 28 Jul 2008 11:09:07 -0700 From: Eric Rescorla To: Joe Touch In-Reply-To: <488E0644.6020006@isi.edu> References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <20080728164013.422D14B9600@kilo.rtfm.com> <488E0644.6020006@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080728180907.22EC04BA1D7@kilo.rtfm.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Mon, 28 Jul 2008 10:47:48 -0700, Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Eric, > > Eric Rescorla wrote: > ... > |> OK; we're dancing around terms here. TCP-AO uses a _separate_ document > |> to specify the out-of-band key mechanism. What that includes can be > |> discussed in that context - e.g., on SAAG. > | > | Well, I think that's a mistake as well. > > That's outside the scope of this document; that was handed to the design > team as a requirement of this work. Perhaps the ADs should address the > reasons directly. Well, to the extent to which this was an instruction from the AD, I think this should be reconsidered. > | The second needs to be tied to the transport protocol. The > | first is replaceable. The problem here is that you have > | merged them and treated them both as separate. That's problematic. > > Are you saying that we generate per-session keys inside TCP-AO? Per-connection keys, yes. > |> | Sure. You have a per-connection key. Every time the sequence number > |> | rolls, you run the KDF again to generate a fresh per-connection key. > |> | No KMP required. (This meshes with my previous key diversification > |> | comments). > |> > |> That's burying the key generation protocol inside TCP-AO. > | > | Again, key generation != key establishment. > > Agreed, but there is utility in keeping TCP-AO clean from algorithmic > crypto issues. Perhaps, but there's also utility in having a single, complete, spec. > | The protocol must be constructed so that it is not possible to substitute > | one packet for another and have it be accepted. This means that (either) > | the data fed into the authentication function must be distinct or the > | authentication function must have a distinct key. > > That implies a per-packet nonce, i.e., some fields - either in the > packet or external - that are unique on a per-packet basis. Well, perhaps we're just differing in terminology, but I don't call per-packet data fed into the authentication function a nonce. I think of the nonce as a discrete value, not just the data. But in this case we're just talking about MACing the packet. I just checked and neither AH nor TLS uses the term nonce here. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jul 28 16:26:05 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2204D3A68B1; Mon, 28 Jul 2008 16:26:05 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B11D3A68B1 for ; Mon, 28 Jul 2008 16:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.902 X-Spam-Level: X-Spam-Status: No, score=-4.902 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eDnp9ZbEucK for ; Mon, 28 Jul 2008 16:26:02 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 573AE3A689A for ; Mon, 28 Jul 2008 16:26:02 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 1938032808B for ; Mon, 28 Jul 2008 18:26:13 -0500 (CDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsppt02.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id m6SNQD0p014469 for ; Mon, 28 Jul 2008 18:26:13 -0500 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jul 2008 18:26:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8F109.52E3672D" Date: Mon, 28 Jul 2008 18:26:12 -0500 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: draft IETF 72 meeting notes Thread-Index: AcjxCIm3GvJKNKhvQH65VIcgnP0TKw== From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: X-OriginalArrivalTime: 28 Jul 2008 23:26:13.0029 (UTC) FILETIME=[530B0550:01C8F109] Subject: [tcpm] draft IETF 72 meeting notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F109.52E3672D Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C8F109.52E3672D" ------_=_NextPart_002_01C8F109.52E3672D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable TCPMers: here are the draft meeting notes from today. Please report any = corrections or clarifications out to the chairs so that we can fix them = for the final copy. Thanks in advance! =20 Thanks to Lloyd Wood for taking these notes even among some of the fast = discussions; I believe it will be very difficult to convince him to take = notes for us again :). =20 =20 =20 =20 ------_=_NextPart_002_01C8F109.52E3672D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
TCPMers: here are the = draft meeting notes from today.  Please report any corrections or = clarifications out to the chairs so that we can fix them for the final = copy.  Thanks in advance!
=0A=
 
=0A=
Thanks to Lloyd Wood for taking these = notes even among some of the fast discussions; I believe it will be very = difficult to convince him to take notes for us again :).
=0A=
 
=0A=
 
=0A=
 
=0A=
 
------_=_NextPart_002_01C8F109.52E3672D-- ------_=_NextPart_001_01C8F109.52E3672D Content-Type: text/plain; name="tcpm-notes.txt" Content-Transfer-Encoding: base64 Content-Description: tcpm-notes.txt Content-Disposition: attachment; filename="tcpm-notes.txt" VENQTSBEdWJsaW4gSUVURiA3MiBNb25kYXkgMTc0MC4NCldlc2xleSBFZGR5IGNoYWlyaW5nLg0K DQoNCg0KDQoxIC0gIlRDUE0gU3RhdHVzIiAtIFdlc2xleSBFZGR5IC0gMTAgbWludXRlcw0KDQpJ bnRyb2R1Y3Rpb24uDQpOZXcgY2hhaXJzLCByZXBsYWNpbmcgTWFyayBhbmQgVGVkLg0KTm90ZSBX ZWxsLg0KQWdlbmRhIHJ1biB0aHJvdWdoLiAoQWJvdXQgMzAgcGVvcGxlIGluIHRoZSByb29tLikN ClJlcXVlc3QgZm9yIGFueSBvdGhlciBpdGVtcy4gTm9uZS4NCg0KV0cgU1RBVFVTDQoNClJldmll dyBvZiBhY3RpdmUgZHJhZnRzLg0Kc29mdGVycm9ycyB0byBJRVNHOyAyIGl0ZW1zIG9mIGNvbmNl cm4gdG8gYmUgYWRkcmVzc2VkIGJ5IEZlcm5hbmRvIEdvbnQNClVUTyBkcmFmdCAtIHNpbWlsYXIg c3RhdGUsIEFsbG1hbiB3YXMgdG8gZmluaXNoLg0KMjU4MWJpcyAtIHNhbWUgc3RhdGUsIFRlZCB3 YXMgdG8gZmluaXNoLg0KRUNOK1NZTiAtIGNoYW5nZXMgcG9zdCBJRVNHLCBtYXkgbmVlZCBUQ1BN IHRvIHJlcmV2aWV3DQp0Y3BzZWN1cmUgLSBhdXRob3JzIGF3YWl0aW5nIFdHIGZlZWRiYWNrIG9u IHdvcmRpbmcuIEFza3MgYXVkaWVuY2UgaWYgdGhlcmUgYXJlIG9iamVjdGlvbnMgdG8gY3VycmVu dCBkcmFmdCB3b3JkaW5nLiBObyByZXNwb25zZXMuIFdlcyBzYXlzIHRha2UgdG8gbGlzdC4NCjEz MjNiaXMsIEF1dGggT3B0aW9uLCBJQ01QIGF0dGFja3MgZXRjIC0gbm90aGluZyBtYWpvci4NCkNo YXJ0ZXIgbmVlZHMgdG8gYmUgcmVkb25lLiBUSElTIElTIE5PVCBBIEpPS0UuIEl0ZW1zIGZyb20g MjAwNiB0aGF0IGhhdmVuJ3QgYmVlbiBhZGRyZXNzZWQuIEN1cnJlbnQgaXRlbXMgbm90IGluIGNo YXJ0ZXIuIENoYW5nZSBjaGFydGVyIHRvIHN1aXQuDQoNCk5vIGNvbW1lbnRzIGZyb20gYXVkaWVu Y2UuDQoNCkFjdGl2ZSBXRyBJdGVtIFByZXNlbnRhdGlvbnM6DQoNCjIgLSAiRi1SVE8gRHJhZnQi IC0gTWFya2t1IEtvam8gLSAxMCsgbWludXRlcw0KDQpkcmFmdC1pZXRmLXRjcG0tcmZjNDEzOGJp cy0wMg0KDQpEZXRlY3RpbmcgcGVyaW9kaWMgcmV0cmFuc21pc3Npb24gdGltZW91dHMuDQpPbmUg c21hbGwgY2hhbmdlIHRvIGFsZ29yaXRobSwgcHJldmVudGluZyBGLVJUTyBhbGcgaWYgYW4gZWFy bGllciBSVE8gcmVjb3ZlcnkgaXMgdW5kZXJ3YXksIGV4Y2VwdCBpZiB0aGVyZSBhcmUgbXVsdGlw bGUgdGltZXIgZXhwaXJhdGlvbnMgZm9yIHNhbWUgc2VnbWVudC4gSnVzdCBsaWtlIHByZXZpb3Vz IHByZXZlbnQgaWYgU0FDSyByZWNvdmVyeSBpbiBSRkM0MTM4Lg0KR2VuZXJhbCBlZGl0aW5nLCBp bmNsdWRpbmcgc3VnZ2VzdGlvbnMgZnJvbSBBbGZyZWQgSG9lbmVzLg0KRHJhZnQgaW4gV0dMQyB1 bnRpbCA4IEF1Zy4NCg0KTm8gcXVlc3Rpb25zLg0KDQoNCjMgLSAiVENQLUFPIFVwZGF0ZSIgLSBK b2UgVG91Y2ggLSAxNSsgbWludXRlcw0KDQpUQ1AgYXV0aCB1cGRhdGUuDQpOZXcgdmVyc2lvbiBv biBXRyBsaXN0IGFyb3VuZCBsYXN0IGNhbGwgdGltZWZyYW1lLg0KVmFyaW91cyBwcm90b2NvbCB1 cGRhdGVzIGluIC0wMS4NCi0gcmVxdWlyZSBrZXlJRDsgcmVtb3ZlIG9kZC9ldmVuIGluZm8uDQot IHJlbGF4IHJlc3RyaWN0aW9ucyBvbiBrZXkgcmV1c2U7IHVzZSBub25jZSwgc3VnZ2VzdCBrZXkg cm9sbG92ZXIuDQotIGNsYXJpZnkgTkFUIGludGVyYWN0aW9uLg0KLSBhbGwgb3B0aW9ucyBpbmNs dWRlZCBvciBhbGwgb3B0aW9ucyBleGNsdWRlZCAoZGVsZXRlZCwgbm90IHplcm9lZCkuDQoNCkph YmJlciBjb21tZW50cyAtIEVyaWMgZmluZHMgbm9uY2UgY29uZnVzaW5nLCBBZGFtIHRoaW5rcyB3 ZSBkbyBuZWVkIE5BVHMuIEpvZSBzYXlzIHRoYXQgdGhhdCB0eXBlIG9mIE5BVCBub3QgbmVlZGVk LiBKb2Ugc2F5cyB0YWtlIGRpc2N1c3Npb24gdG8gdGhlIG1haWxpbmcgbGlzdC4NCg0KRGlzY3Vz c2VkIG1pbm9yIHRleHQgY2hhbmdlcy4gbXVzdCBpcyBub3QgTVVTVDsgZXhwbGljaXRseSBjbGFy aWZpZWQgd2l0aCBub3RlIGluIGRvYy4NCg0KRGlzY3Vzc2VkIG9wZW4gaXNzdWVzOg0KLSBkZXBy ZWNhdGUgVENQIE1ENT8NCi0gcGljayB3aGljaCB0d28gTUFDIGFsZ29yaXRobXMNCi0gZG8gd2Ug YmFja29mZiB0byBub25lIG9yIHRvIFRDUCBNRDU/IEpvZSB0aGlua3MgZGlzY3Vzc2lvbiBpcyBm YXZvdXJpbmcgbm90LCBtb3JlIGRpc2N1c3Npb24gbmVlZGVkLg0KDQpRdWVzdGlvbiByZSBNQUNz IGZyb20gR3JlZ29yeS4gcG9zdHBvbmVkLiBKb2Ugc2F5cyB3aGVuIFNBQUcgc2F5cyB3aGF0IE1B QyBhbGdzIGFyZSwgdGhleSB3aWxsIGJlIHBsdWdnZWQgaW4uDQoNClZhcmlvdXMgbmV3IGRpc2N1 c3Npb24gaXRlbXMuDQpSZXBsYXkgcHJvdGVjdGlvbiAoQWRhbSBMYW5nbGV5KQ0KS2V5IGlzc3Vl cyByZXZpZXdlZCBpbiBicmllZi4NCg0KUmVwbGF5IHByb3RlY3Rpb24uIEpvZSByZXZpZXdzOyBl eHRlbmRlZCBkaXNjdXNzaW9uIG9uIGxpc3Qgb3ZlciBsYXN0IHR3byBkYXlzLiBEbyB3ZSBuZWVk IHVuaXF1ZSBrZXkgcGVyIHNlc3Npb24/IFJla2V5aW5nIHByb2JhYmx5IHRha2VzIHBsYWNlLiBJ UC1JRCBpcyBub3QgdW5pcXVlIC0gdGhpcyBpcyBiZWluZyB0YWtlbiB1cCBpbiB0aGUgSU5UIGFy ZWEsIHRvIG1ha2UgdjQgYXNzdW1lLCBsaWtlIHY2LCBpdCBpcyBub3QgdW5pcXVlLg0KDQpQcm9w b3NlZCBzb2x1dGlvbiBjb25zaWRlcmVkIGdvb2QgZW5vdWdoLCBpZiB5b3Ugd2FudCBtb3JlIHVz ZSBJcFNlYy4NCg0KTkFUIGFjY29tbW9kYXRpb24gLSBpbmNsdWRlIGFkZHIvcG9ydCBpbiBNQUMg YW5kIHVzZSB0aG9zZSwgdG8ga2VlcCBoZWFkZXIgc2l6ZSBkb3duIGJ5IG5vdCBhZGRpbmcgdW5p cXVlIHBlci1jb25uZWN0aW9uIElEPg0KDQpLZXlJRCByb3RhdGlvbiAtIGN1cnJlbnQgaXMgY2hh bmdlIGV2ZXJ5IDJeMzEgYnl0ZXMuIElmIE1BQyBhbGcgbm90IHN0cm9uZyBlbm91Z2gsIEpvZSBz YXlzIGRvbid0IHVzZSBpdCENCg0Ka2V5SUQgbG9jYXRpb24gLSBlbmQgb3IgYmVnaW5uaW5nIG9m IG9wdGlvbi4gSW1wbGVtZW50YXRpb24gYnVncyBhZmZlY3QgdGhpcyBkZWNpc2lvbi4NCg0KSXMg S2V5SUQgMCB2YWxpZD8gQ2FuIGl0IGJlIHVzZWQgYXMgYSBjb29raWUgdG8gaW1wbGVtZW50ZXJz PyBXYW50IGZlZWRiYWNrLiBBZGRpbmcgYW5vdGhlciB0aGluZyB0byBnZXQgcmlnaHQgdnMgYmVu ZWZpdCB0byBvbmUgcGVyc29uLg0KDQpIaWRlYWtpIFlvc2hpZnVqaSBAIEtlaW8gVW5pLi9XSURF IFByb2ouIEtub3dzIHNvbWVvbmUgd2hvIGhhcyBpbXBsZW1lbnRlZCBUQ1BBTyBmb3IgTGludXgg LSBkaXNjdXNzaW5nIHdpdGggdGhhdCBpbXBsZW1lbnRlci4gVENQIE1ENSBkb2VzIG5vdCB1c2Ug MCBJRC4gQ29tbWVudCBvbiBNRDUuIFRoaW5rcyB0aGF0IHplcm8gc2hvdWxkIGJlIHByb2hpYml0 ZWQuDQoNCkpvZSByZXNwb25zZSA6IGtpbmQgZmllbGRzIHRlbGxzIHlvdSBpZiBpdCdzIE1ENSBv ciBub3QgLSB6ZXJvIGRvZXNuJ3QgdGVsbCB5b3UgaWYgaXQncyBNRDUgb3Igbm90Lg0KDQpKb2Ug c2F5cyBkb24ndCBkZWNpZGUgaGVyZSwgbmVlZCBtb3JlIGluZm8uDQoNCkFsZnJlZCBIb25uZXMg c2F5cyAtIG9mZmxpc3QgZGlzY3Vzc2lvbiBvbiBjb2Rpbmcgb2Yga2V5SUQuIEhlIHByb3Bvc2Vk IG5vdCB1c2luZyBicmlkZ2Ugc3BhY2UgaW4gVENQIG9wdGlvbiwgYnV0IHVzZSBvcHRpb24gbnVt YmVyIHNwYWNlIC0gaW5kZXggaW50byBrZXlJRCB0YWJsZS4NCkpvZSByZXNwb25zZSAtIG9ubHkg Z2V0IG9uZSBvcHRpb24sIG5vdCBwb3NzaWJsZS4NCkFsZnJlZCBzYXlzIGF2b2lkcyBwcm9ibGVt cyB3aXRoIG9wdGlvbiBzaXplLCB0YWxrcyBhYm91dCB1bnVzZWQgKGhpc3RvcmljYWwpIG9wdGlv bnMgdnMgdXNlZCBvcHRpb25zLi4uDQpKb2Ugc2F5cyBkaXNjdXNzIGhpc3RvcmljYWwgb3B0aW9u cyBhbmQgcmVhbGxvY2F0aW9uIHdpdGggSUFOQS4NCkpvZSBzYXlzIGp1c3QgdXNlIHRocmVlIGJ5 dGVzIG9uIGVuZCBvZiBNQUMgaW5zdGVhZCBmb3IgS2V5SUQuIFRDUE0gZG9lc24ndCBjb250cm9s IG9wdGlvbiBzcGFjZS4NCldlcyAtIG1ham9yIGVub3VnaCBjaGFuZ2UgdGhhdCB0aGlzIG5lZWRz IHRvIGJlIHRhbGtlZCBhYm91dCBvbiBtYWlsaW5nIGxpc3QuDQpKb2U6IG5lZWRzIElBTkEgb24g Ym9hcmQhIE91dCBvZiBvdXIgaGFuZHMuDQoNCkVyaWMgb24gSmFiYmVyOiBhdm9pZCBzcGVjaWZ5 aW5nIGFsZ29yaXRobSAtIHJhbmRvbSBvciBzZXF1ZW50aWFsLiBEb24ndCBwcmVzdXBwb3NlIGl0 IGluIHNwZWMuDQoNClNjb3R0IEJyYWRuZXIgLSBub3QgSUFOQSdzIGNob2ljZSAtIHRoZSBJRVRG IGNob2ljZSB0byBhc2sgSUFOQS4NCkpvZTogb3V0IG9mIG91ciBoYW5kcyENCg0KSm9lOiBob3cg ZG8geW91IGF2b2lkIGJ1cm5pbmcgQ1BVIGN5Y2xlcz8gRGVzaWduIGEgTUFDIHdoZXJlIGZpcnN0 IHRocmVlIGJ5dGVzIG9mIE1BQyBhcmUgbm9uY2UuIENoZWNrIE1BQywgY2hlY2sgZmlyc3QgY291 cGxlIG9mIGJ5dGVzLCBkb24ndCBuZWVkIHRvIGNoZWNrIHJlc3QgaWYgdGhhdCBkb2Vzbid0IG1h dGNoLiBXYW50cyB0byB0YWtlIGFsbCBjcnlwdG8gcHJvcGVydGllcyBvdXQgb2YgaGVhZGVyLiBU aGlua3MgY3J5cHRvIGJlbG9uZ3MgaW4gTUFDLg0KDQpBbmFudGhhIGZyb20gQ2lzY28gLSB3ZSBz aG91bGQgZG8gc29tZXRoaW5nIGFib3V0IFRDUCBvcHRpb24gc3BhY2UuDQoNCkpvZTogYmVlbiB0 aGVyZSwgZG9uZSB0aGF0IGluIHRoaXMgV0cuIFR3byB3YXlzIHRvIGdvOiBub3QgYmFja3dhcmQg Y29tcGF0aWJsZSAoYmMpIG9yIGJjLiBTWU4gYmMgbm90IHBvc3NpYmxlLiBEbyB3ZSBjcmVhdGUg YSBuZXcgcHJvdG9jb2wuDQoNCldlczogd2F5IG9mZnNpZGUuDQoNCkFuYW50aGE6IG1hbnkgZ2Vu dWluZSByZXF1ZXN0cyBmb3IgVENQIG9wdGlvbiBzcGFjZS4gV2Ugc2hvdWxkIHJldmlzaXQgZGlz Y3Vzc2lvbiBvbiB0aGUgbWFpbGluZyBsaXN0Lg0KDQpXZXM6IGtlZXAgdGFsa2luZyBhYm91dCBp dCBvbiB0aGUgbWFpbGluZyBsaXN0Lg0KDQpSZXF1ZXN0IGZvciBpbi1iYW5kIGtleWluZy4gRGVz aWduIHRlYW0gdG9sZCBub3QgdG8gZG8gdGhpcyAtIG5vIHNwYWNlIGluIFNZTiBwYWNrZXRzLiBQ cm9wb3NlZCBzb2x1dGlvbiByZXF1aXJlcyBPT0Iga2V5aW5nLCBidXQgZG9lcyBub3QgcHJvaGli aXQgaW4tYmFuZCBzb21laG93Lg0KDQpHcmVnb3J5IExlYm92aXR6OiBpZiB3ZSBkbyB0aGlzLCB3 ZSBibG93IG91dCB0aGUgcm9hZG1hcDsgbXVsdGlwbGUgdmFyeWluZyBpbXBsZW1lbnRhdGlvbnMu IEJlbGlldmVzIGluLWJhbmQga2V5aW5nIHNob3VsZCBiZSBleHBsaWNpdGx5IHByb2hpYml0ZWQu DQoNCkpvZTogQWRhbSBpcyBjb21wbGV0aW5nIExpbnV4IGltcGwuIFdlIGFpbSB0byB3cmFwIHRo aXMgdXAgYnkgT2N0IDIwMDguIFdlIGFyZSBjaXJjbGluZyByb3VuZCByZXBlYXRpbmcuIE5lZWQg dG8gbWFrZSBoYXJkIGRlY2lzaW9ucywgbm90IHVuYW5pbW91cyBkZWNpc2lvbnMuDQoNCkFuZHJl dyBMYW5nOiB0aGlzIGRyYWZ0IGlzIGRlYWQuIEhhcyBiZWVuIGRlYWQgZm9yIGEgY291cGxlIG9m IHllYXJzLiBSb3V0ZXIgaW1wbGVtZW50YXRpb25zIGFyZSBkaWZmZXJlbnQuIGRyYWZ0LWJvbmlj YSBpcyBkaWZmZXJlbnQsIG5vdCBjb21wYXRpYmxlLiBXaHkgaW1wbGVtZW50IHRoaXMgZHJhZnQg d2hlbiB0aGVyZSdzIGRyYWZ0LWJvbmljYSBpbiB0aGUgZmllbGQ/DQoNCkpvZTogQm9uaWNhIHdh cyBvbiBkZXNpZ24gdGVhbSwgY29hdXRob3Igb2YgdGhpcyBkb2MuDQoNClNvbWUgb3RoZXIgZGVz aWduIHRlYW0gZ3V5IGRpc3NlbnRzLg0KDQooPykgVENQQU8gaW4gdGhpcyBkcmFmdCBtYWtlcyBz ZW5zZSwgc3RpbGwgYSBnb29kIGlkZWEuDQoNCkxhbmdlOiBCdXJuIHRoaXMgdG8gdGhlIGdyb3Vu ZCEgVXNlIHdoYXQncyBpbXBsZW1lbnRlZC4NCg0KV2VzOiB0aGUgYmFzZSBpc24ndCByZXZpZXdl ZCBieSB0aGUgZ3JvdXAuDQoNCkZhc3QgZGlzY3Vzc2lvbi4NCg0KVGltIFBvbGs6IHNlY3VyaXR5 IEFELiBTdHVmZiBjb21pbmcgZnJvbSB1cyBpbiBuZXh0IG1vbnRoLiBTaG91bGRuJ3QgYmUgYSBz dXJwcmlzZS4gTWFraW5nIHR3ZWFrcy4gSG9wZSB0byBlbmxhcmdlIHJldmlldyBjaXJjbGUsIHdp dGggY29tcGxldGUgc2V0IG9mIGFuc3dlcnMgYnkgbGF0ZSBBdWcvZWFybHkgU2VwLiBJdCdzIHRv dGFsIHBhY2thZ2UgLSBub3QganVzdCBLREYvYWxncywgYnV0IGFsc28gc3RydWN0dXJlcywgaG93 IHRoZXkgY2hhbmdlLiBBaW0gdG8gZ2l2ZSBjb21wbGV0ZSByZWNvbW1lbmRhdGlvbi4gQXBvbG9n aXNlcyBmb3Igc2xvd25lc3MsIEFEIChUaW0ncykgZmF1bHQuIFB1c2hpbmcgZm9yIHNvbWV0aGlu ZyBiZXR3ZWVuIHRoZSB0d28gZHJhZnRzLg0KDQpSb24gQm9uaWNhOiBJIGFtIEpvaG4gRG9lLiBT ZWVzIHR3byBzaWRlcyB0byB0aGUgYXJncy4gSW1wcm92ZW1uZXRzIG92ZXIgYm9uaWNhIC0gSVNO IHRvIGdlbmVyYXRlIGtleSBtYXRlcmlhbCwgYmV0dGVyIHByb3RlY3RlZCBmcm9tIHJlcGxheXMu IEFuZHJldyBoYXMgZ29vZCBwb2ludCAtIHRocmVlIHZlbmRvciBkZXBsb3ltZW50cywgYnV0IHVu ZG9jdW1lbnRlZC4gV2UgY29udGludWUgb24gVENQQU8sIGJ1dCB3ZSBzaG91bGQgcHVibGlzaCBi b25pYSBhcyBpbmZvcm1hdGlvbmFsLg0KDQpMYXJzIEVnZ2VydDogb2Z0ZW4gd2UgcHVibGlzaCBv cmlnaW5hbCBkb2MgYXMgaW5mb3JtYXRpb25hbC4gQnV0IG5vdCB1bnRpbCB0aGUgJ2JldHRlcicg ZG9jIGlzIG91dCwgc28gdGhhdCB3ZSBkb24ndCBmYXZvdXIgdGhlIGVhcmx5IGltcGxlbWVudGF0 aW9uLiBOb3RoaW5nIHNwZWNpYWwgYWJvdXQgdGhpcyBzaXR1YXRpb24uDQoNCkFuZHJldyBMYW5n ZTogV2UgY291bGQgYmUgcGlzc2luZyBhcm91bmQgZm9yIHllYXJzIHdpdGggdGhpcyBkb2MuDQoN CkxhcnM6IHRoZSBkcmFmdCBpcyBhbHJlYWR5IHRoZXJlLiBTdGFuZGFyZCBwb2xpY3kgLSBkbyBu b3QgcHVibGlzaCBSRkNzIGRlc2NyaWJpbmcgcHJlLUlFVEYgZWZmb3J0cyBiZWZvcmUgdGhlIElF VEYgZWZmb3J0IGlzIG91dC4gRG8gbm90IHB1Ymxpc2ggZHJhZnQtYm9uaWNhIGF0IHRoaXMgdGlt ZS4NCg0KR3JlZyBMZWJvdml0eiAtIGltcGxlbWVudGVkLCBvdXQgdGhlcmUsIG5vdGhpbmcgdG8g dGVhciBkb3duLiBJZiB0aGlzIGdpdmVzIGEgZmlybSBzdGVwIHRvd2FyZHMgcHJvcGVyIGtleSBt YW5hZ2VtZW50LCBnb29kLg0KDQpMYW5nZTogd2FudHMgYmFja3dhcmRzIGNvbXBhdGliaWxpdHku IEZpbmUgd2l0aCBkcmFmdC1ib25pY2EtYmlzLiBDaGFuZ2luZyBoZWFkZXIgZm9yIHJhbmRvbSBy ZWFzb25zIChzdHJvbmcgcGhyYXNlKSBub3QgbGlrZWQuDQoNCkpvZTogY2hhbmdlcyBpbiB0aGUg cHJvdG9jb2xzLiBIb3cgbXVjaCBUQ1Agc3RhdGUgbmVlZHMgdG8gYmUgY29vcmRpbmF0ZWQgYnkg dGhlIGVuZHBvaW50cz8gVENQQU8gaXMgY29uc2lzdGVudCB3aXRoIGRvbid0LWFkZC1leHRyYS1z dGF0ZXMtdW5sZXNzIG5lY2Vzc2FyeS4NCg0KTGFuZ2U6IGJvbmljYSBpcyB0aGUgc2FtZS4NCg0K Sm9lOiB0aGUgSUVURiBkcmFmdCBkZXRhaWxzIHdoYXQgdG8gZG8gd2l0aCB0aGUgVENQIHN0YXRl IGRpYWdyYW0uIFNwZWNpZmljYXRpb24gb2YgYm9uaWNhIG5vdCBhcyBkZXRhaWxlZC4NCg0KTGFu Z2U6IHdlIGhhdmUgMyBpbnRlcm9wIGltcGxlbWVudGF0aW5zISBFeGlzdGVuY2UgcHJvb2YhDQoN CkVyaWMgKGphYmJlcik6IGZyb20gc2VjdXJpdHkgcGVyc3BlY3RpdmUsIGRyYWZ0IG5vdCBpbXBy b3ZlbWVudCBvdmVyIEJvbmljYS4gRG9lcyBpdCB1c2UgSVNOPyBJdCBtZW50aW9ucyBpdCwgZG9l c24ndCByZWFsbHkgdXNlIGl0Lg0KDQpKb2U6IGdyZXAgb24gSVNODQoNClJvc3MgQ2FsbG9uOiBj b21tZW50cyBmcm9tIElFU0cgZGlzY3Vzc2lvbiBwZXJzcGVjdGl2ZS4gSSB3YXMgYXQgZmlyc3Qg SUVURiEgQWxtb3N0IGFsd2F5cyBjaGFuZ2VzIGZyb20gc3RhbmRhcmRzLCB3ZSBoYXZlIHRvIGRl YWwgd2l0aCB0aGlzLiBWYWx1ZSBpbiBkb2N1bWVudGluZyB3aGF0IGlzIGRlcGxveWVkLCBldmVu IGlmIHByZS1zdGFuZGFyZC4gV2hpbGUgb24gSUVTRyBJIGhhdmUgbm90aWNlZCBzZXZlcmFsIGNh c2VzIGxpa2UgdGhpcywgaG9sZCBkb2MgdW50aWwgdGhlIHN0ZCBjb21lcyBvdXQsIHRoZW4gcHVi bGlzaCBib3RoLiAoQmFzaWNhbGx5IFdoYXQgTGFycyBTYWlkLikgVGhpbmtzIGNhbiB0ZWxsIHdo aWNoIGZvcm0gaXQgaXMgZnJvbSBvcHRpb24gc3BhY2UgKEpvZSBub3RlcyBUQ1BBTyBkb2Vzbid0 IGhhdmUgb3B0aW9uIGFsbG9jYXRlZCksIHNvIHN1cHBvcnRpbmcgYm90aCBwb3NzaWJsZSBpbiBp bXBsZW1lbnRhdGlvbi4gUHV0IGEgZmV3IHdvcmRzIG9uIGhvdyB0byB0cmFuc2l0aW9uIGZyb20v aGFuZGxlIGJvdGguDQoNClJvc3M6IGlmIGRlcGxveWVkIGVxdWlwIGZyb20gdHdvIGRpZmZlcmVu dCB2ZW5kb3JzLCBib3RoIG5lZWQgdG8gdXBncmFkZSBiZWZvcmUgdGhleSBjYW4gZG8gYm90aC4N Cg0KSm9lOiB5b3UgY2FuJ3QgY2hhbmdlIFRDUCBNRDUgYW5kIGVzY2FsYXRlIGl0IHRvIGEgZGlm ZmVyZW50IG1lY2hhbmlzbS4gTm90IGFsbG93ZWQuIENhbid0IGNoYW5nZSBleGlzdGluZyBwcm9w b3NlZCBzdGFuZGFyZCB0aGF0IGlzIGRlcGxveWVkLiBObyBob29rIHRvIGdldCBvdXQgb2YgTUQ1 Lg0KDQpSb24gQm9uaWNhOiB5b3UgY2FuJ3QgY2hhbmdlIGF1dGggbWVjaGFuaXNtIHdpdGhvdXQg Ym91bmNpbmcgY29ubmVjdGlvbi4gSW1wbGVtZW50YXRpb246IHNvbWUgcm91dGVycyBhcmVuJ3Qg YXV0aGluZywgc29tZSBSRkMyMzg1LCBzb21lIGJvbmlhLCBzb21lIFRDUEFPLiBLbm93IHdoaWNo IGlzIHdoaWNoLCBvcHRpb25zIGFyZSBkaXN0aW5ndWlzaGFibGUgYnkga2luZC4NCg0KTGFuZ2U6 ID8/DQoNCkpvZTogbW9yZSB0byBwcm90b2NvbCB0aGFuIHdoYXQncyBvbiB3aXJlLg0KDQpMYW5n ZTogZG9uJ3QgZG9jdW1lbnQgc3RhdGUgbWFjaGluZS4NCg0KSm9lOiBkb2N1bWVudCBlZmZlY3Rz IG9uIHN0YXRlIG1hY2hpbmUgYW5kIGJpdHMgb24gd2lyZS4gTWF5IG5vdCBiZSBvbiB0aGUgc3Bl Yy4gTm90IGV2ZXJ5dGhpbmcgaW1wbGVtZW50ZWQgaXMgZG9jdW1lbnRlZC4gRG8gaW50ZXJvcCBp bXBsZW1lbnRhdGlvbnMgaGF2ZSBjb3JuZXIgc2VjdXJpdHkgY2FzZXM/IFdlJ2xsIG5ldmVyIGtu b3cuIEhlbmNlIG1vcmUgcmlnb3JvdXMgZG9jLg0KDQpMYW5nZTogcm91dGluZyB3b3JsZCBjb25j ZXJuZWQgd2l0aCBpbnRlcm9wLg0KDQpKb2U6IHByb3RvY29scyBhcmUgYml0cyBvbiB3aXJlLCBz dGF0ZXMgYW5kIGFjdGlvbnMuIFZlcnkgaW1wb3J0YW50Lg0KDQpHcmVnOiBpZiB3ZSBpbXByb3Zl LCB3ZSBjaGFuZ2UgYml0cyBvbiB3aXJlLg0KDQpMYW5nZTogd2hhdCBhcmUgdGhlIGltcHJvdmVt ZW50cyBoZXJlPw0KDQpHcmVnOiBpbmNyZW1lbnRhbCBpbXByb3ZlbWVudHMsIGFjY2VwdCBpdC4N Cg0KTGFuZ2U6IHdlIGRvY3VtZW50ZWQgdGhlIHN0YXRlIG1hY2hpbmUhIFJlYWxseSB3aGF0J3Mg YmV0dGVyLg0KDQpMYXJzOiBIb3cgaXMgV2VzIGVuam95aW5nIGZpcnN0IGNoYWlyIHNlc3Npb24/ IEhvdyBpcyBzY3JpYmUgZW5qb3lpbmcgaXQ/DQoNCkxhbmdlOiBJJ20gbm90IHNlZWluZyBpbXBy b3ZlbWVudHMhDQoNCkxhcnM6IHN0YW5kYXJkcyB0cmFjayBkb2MuIFRoaXMgaXMgd2hhdCB3ZSBk by4gQ29uc2Vuc3VzIHByb2Nlc3MuIERlc2lnbiB0ZWFtIG91dHB1dCBhZG9wdGVkIGJ5IFdHLiBO b3QgYXdhcmUgb2YgZGlzc2VudCBhbmQgaHVtLiBXZSBoYXZlIG5vdyBoYWQgc2Vjb25kIHJldmlz aW9uLg0KDQpMYW5nZTogdGhlcmUgV0FTIGRpc3NlbnQhDQoNCkxhcnM6IG5vIGRpc3NlbnQsIG90 aGVyd2lzZSB0aGUgZG9jIHdvdWxkbid0IGJlIGEgV0cgZG9jLiBFeGlzdGVuY2UgcHJvb2YuIEhv dyBjYW4gd2UgbWFrZSBwcm9ncmVzcz8gRG9uJ3QgcHVibGlzaCBib25pY2EgYXMgSUVURiBzdGQu IEJvbmljYSBpcyBkZXBsb3llZCBiZWNhdXNlIGl0IGNhbWUgbGF0ZSB0byB0aGUgd2cuIFNvY2lh bGlzZWQgaW4gcm91dGluZyBjb21tdW5pdHkgdG8gc29sdmUgYSBwcm9ibGVtLiBXaGF0IHdvdWxk IHJvdXRpbmcgcGVvcGxlIHRoaW5rIGlmIHRyYW5zcG9ydCBwZW9wbGUgaW1wbGVtZW50ZWQgQkdQ IGV4dGVuc2lvbj8gT2xkIHByb3RvY29scywgc3Ryb25nIGNvbW11bml0aWVzIGFyb3VuZCB0aGVt LiBUYWtlIHRoaXMgb2ZmbGluZS4NCg0KV2VzOiBDbG9zZSB0aGlzIGFmdGVyIEFuYW50aGENCg0K Q2hhbmRyYTogdGhlcmUgd2FzIGZlZWxpbmcgdGhhdCBzb2xuIHdhcyBwcmVkZWNpZGVkLCBub3Qg cnVuIHBhc3QgcmlnaHQgZ3JvdXAuIEdldHMgc2FtZSBmZWVsaW5nIGZyb20gb3V0cHV0IG9mIGRl c2lnbiBncm91cC4gQm9uaWNhIHVzZXMgMjU0LiBCcmVha3MgaWYgMjU0IGlzIHVzZWQgZm9yIHNv bWV0aGluZyBlbHNlLiBCb25pY2EgbmVlZHMgY29kZXBvaW50Lg0KDQpMYXJzOiBpZiB3ZSBwdWJs aXNoLCAyNTQgZ29lcyB0byBib25pY2EuIE5lZWQgdG8gc2h1ZmZsZSBleHBlcmltZW50YWwgY29k ZXBvaW50cy4gU2hvdWxkbid0IGhhdmUgdXNlZCBhbiBleHBlcmltZW50YWwgY29kZXBvaW50LiBO b3QgdG8gYmUgZGVzY3JpYmVkIGluIGFuIFJGQyEgTm90IGhhcHB5Lg0KDQpKb2U6IGV4cCBjb2Rl cG9pbnRzIC0gb25jZSB5b3UgbGV0IHNvbWVvbmUgdGFrZSBhIGNvZGVwb2ludCwgZG9vcnMgYXJl IG9wZW4uIERvbid0IGFsbG93IGl0IQ0KDQpBbmFudGhhOiBUQ1BBTyBkb2MgZm9ybWF0LiBEb24n dCB0YWxrIGFib3V0IHN0YXRlIG1hY2hpbmUuIE5vIGNoYW5nZXMgdGhlcmUuIE5vdCBjb21mb3J0 YWJsZSB3aXRoIGRhdGFiYXNlIGRpc2N1c3Npb24gLSBtYWtlcyBkb2MgdG9vIGxvbmcsIGhhcmQg dG8gZm9sbG93LiBEb2MgbmVlZHMgdG8gYmUgY3Jpc3AuIE1lbnRpb25lZCB0aGlzIG9uIG1haWxp bmcgbGlzdC4NCg0KDQoNCk90aGVyIFByb3Bvc2FscyBhbmQgUHJlc2VudGF0aW9uczoNCg0KNCAt ICJDbGFyaWZpY2F0aW9uIG9mIFJGQyAxMTIyIGxhbmd1YWdlIG9uIFpXUCIgLSBBbmFudGhhIFJh bWFpYWggLyBNYWhlc2ggSmV0aGFuYW5kYW5pIC0gMTUrIG1pbnV0ZXMNCg0KUGVyc2lzdCB0aW1l b3V0IGRyYWZ0Lg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KZmluZGluZyBwdWJzIGluIER1YmxpbiBk cmFmdCBqb2tlLg0KDQpNYWhlc2g6IHBlcnNpc3QgaXMgZ2V0dGluZyByZWxpYWJsZSBhY2tzIGZy b20gcmVjZWl2ZXIgaW4gemVyby13aW5kb3cgY29uZGl0aW9uLg0KDQpvbGRlciBwZXJzaXN0LXRp bWVvdXQtMDIgZHJhZnQgY292ZXJlZCBzZW5kZXIgYmVoYXZpb3VyIGluIHBlcnNpc3RuLCBhbmQg RE9TIGNhdXNlZCBieSBzZW5kZXIgYmVoYXZpb3VyLiBQcmV2aW91cyBjaGFpcnMgc3VnZ2VzdGVk IHNwbGl0dGluZyBkcmFmdCBpbnRvIHR3byB0byBhZGRyZXNzIGVhY2ggdG9waWMgc2VwYXJhdGVs eS4gSW5mb3JtYXRpb25hbCBkcmFmdCBvbiBET1Mgc3RpbGwgaW4gd29ya3MuIHRoaXMgZHJhZnQg ZG9lc24ndCB0YWxrIGFib3V0IERPUy4NCg0KUkZDNzkzIHZzIFJGQzExMjIgbWF5IGNsb3NlIHZz IG11c3Qgc3RheSBvcGVuLg0KU3RhbmNlOyBSRkMxMTIyIGN1c2VzIGNvbmZ1c2lvbi4gQmVoYXZp b3VyIG11c3QgYmUgY2xhcmlmaWVkLiBCZWxpZXZlIHNlbmRpbmcgVENQIGNhbiBjbG9zZSBjb25u ZWN0aW9uIGluIHBlcnNpc3QgY29uZGl0aW9uLg0KDQpET1Mgc2NlbmFyaW86IHBlcnNpc3QgY29u ZGl0aW9uLCBzZW5kaW5nIFRDTyBjb250aW51ZXMgdG8gaG9sZCBkYXRhIGluZGVmaW5pdGVseS4g Q091bGQgbGVhZCB0byBidWZmZXIvY29ubmVjdGlvbiBleGhhdXN0aW9uLiBUaGlzIGlzIGZvciAy bmQgZHJhZnQuDQoNCk5leHQgc3RlcHM/DQoNClZpbnQgQ2VyZjogV2hhdCBwYXJ0IG9mIFJGQzc5 MyBub3QgY2xlYXI/IENvdWxkIGNsb3NlIGNvbm5lY3Rpb24gYXQgYW55IHRpbWUuIFdlIGFyZSBj b25zaXN0ZW50IHdpdGggd2hhdCB5b3UgYXJlIHRyeWluZyB0byBkby4gMTEyMiBpcyB1bmNsZWFy Lg0KDQpBbmFudGhhOiBpbXBsZW1lbnRhdGlvbnMgc2F5ICcxMTIyIHByb2hpYml0cyB0aGlzJyBp biB0aGVpciBjb2RlLiBEaXNjdXNzZWQgc3RhY2sgaGFuZGxpbmcgb3JwaGFuIGNvbm5lY3Rpb25z LiBFdmVudHVhbGx5IGFib3J0cyBjb25uZWN0aW9uLiBBcyBnZW5lcmFsIG1lY2hhbmlzbSwgY2xh cmlmeWluZyBsYW5ndWFnZSwgb2theSB0byB3cml0ZSBhIDEtcGFnZSBkcmFmdCB0byBjbGFyaWZ5 IHRoYXQuIFRoZXJlIGFyZSB0b25zIG9mIHNvbHV0aW9ucyBmb3IgRE9TIG1pdGlnYXRpb24uDQoN CldlczogbGFjayBvZiBhZ3JlZW1lbnQgb24gRE9TIHBhcnQuIE5leHQgc3RlcDogYXNrIFdHIGlm IHRoaXMgaXMgV0cgaXRlbSB0byBjbGFyaWZ5IDExMjIuDQoNCkRhdmUgKGphYmJlcik6IDExMjIg cHJvaGliaXRzLi4uLiBhcmNhbmUgcG9pbnQuDQoNCig/KSBXaHkgYXJlbid0IHdlIHJldnZpbmcg MTEyMj8NCg0KV2VzOiBJJ2xsIHRha2UgdGhhdCBhcyBhIGpva2UuDQoNCkpvZTogYmVjYXVzZSBv ZiBhbGwgZGVwbG95ZWQgY29kZSAoam9rZSkNCg0KV2VzOiBtYWlsaW5nIGxpc3QgbmVlZHMgdG8g ZGVjaWRlIHdoZXRoZXIgdG8gdGFrZSB0aGlzIG9uLiBOZWVkIHBlb3BsZSB0byByZWFkIHRoZSBk cmFmdCBmaXJzdC4gV2UgYXJlbid0IGdvaW5nIHRvIGRlY2lkZSBhbnl0aGluZyB0byBkby4NCg0K QW5hbnRoYTogcmVzcG9uc2UgdG8gRGF2ZSAtIGFwcCBjYW4gYWJvcnQgaXQsIGJ1dCBhcHAga25v d3Mgbm90aGluZyBhYm91dCBUQ1Agc3RhdHVzL3Jlc291cmNlcyBldGMuDQoNCkxhcnM6IFRDUE0g aXMgTWlub3IuIFVwZGF0aW5nIDExMjIgaXNuJ3QgTWlub3IhIEl0IG1pZ2h0IGJlIGRvbmUsIGJ1 dCBub3QgaW4gdGhpcyBXRy4NCg0KQW5hbnRoYTogd2hhdCBpcyBwcm9jZWR1cmUgZm9yIHJldnZp bmcgMTEyMj8NCg0KTGFyczogMTEyMiBpcyB2ZXJ5IGJyb2FkIGluIHNjb3BlLiBJRVRGIGhhcyBn cm93bi4gTG90cyBvZiBzdHVmZiB0byByZXZpZXcgZm9yIGludGVyYWN0aW9ucy4gSXMgaXQgd29y dGggaXQgdG8gY29ycmVjdCBhIHNpbmdsZSBwb2ludCB0aGF0IGNvdWxkIGJlIG1vcmUgY2xlYXIu DQoNCkFuYW50aGE6IERPUyBuYXR1cmUgb2YgdGhpcyBpc3N1ZSBpcyBpbXBvcnRhbnQuDQoNCldl czogdGhlcmUgYXJlIG1hbnkgb3RoZXIgd2F5cyB0byBtaXRpZ2F0ZSBET1Mgc3VnZ2VzdGVkIGJ5 IGxpc3QuDQoNClNjb3R0IEJyYWRuZXI6IHRoaXMgZ3JvdXAgaXMgbm90IHRoZSByaWdodCBncm91 cC4gSXMgVFNWV0cgYmV0dGVyPw0KDQpMYXJzOiBUU1ZXRyBpcyBiZXR0ZXINCg0KTGFyczogdGhl IG90aGVyIGRhbmdlciBpcyBtYWtpbmcgc3VyZSB3aGF0IHdlIGFyZSBhdHRlbXB0aW5nLiBBdm9p ZCB1cGRhdGluZyBhbGwgb2YgMTEyMi4gSXMgaXQgd29ydGggdXBkYXRpbmcgMTEyMiBmb3Igc3Vj aCBzbWFsbCBjaGFuZ2U/DQoNCkFuYW50aGE6IEFsbG1hbiBoYWQgc2FtZSB2aWV3LCBnbyBpbmZv cm1hdGlvbmFsIGRvYy4NCg0KTGFyczogZG9uJ3QgcmVtZW1iZXIgdGhhdCBlbWFpbC4NCg0KV2Vz OiBJIGhhZCB1bmRlcnN0YW5kaW5nIHRoYXQgV0cgaGFkIG5vdCBhY2NlcHRlZCB0aGlzLCBidXQg ZWFzaWVyIHRvIGdldCBqdXN0IGEgY2xhcmlmaWNhdGlvbiAoaW5mb3JtYXRpb25hbCkgYWNjZXB0 ZWQgYnkgdGhlIFdHLg0KDQpMYXJzOiBpZiBJIHdhcyBjaGFpciBjYWxsaW5nIGNvbnNlbnN1cyAt IEZBSUwgLSBkb24ndCBhZG9wdCBpdCBhcyBXRyBpdGVtLiBDYWxsIG9uIFdHIGZvciBwcm9wb3Nl ZCBzdGQgZmFpbGVkLg0KDQpBbmFudGhhOiB0aGlzIGlzIGFib3V0IGJhc2ljIHBsdW1iaW5nIG9m IEludGVybmV0LiBUaGVyZSB3YXMgbm8gY2xlYXIgY29uc2Vuc3VzLiBQZW9wbGUgYWdyZWVkIGl0 IHdhcyBhbiBhcHBsaWNhdGlvbiBpc3N1ZS4gUmV2aWV3ZWQgaGlzdG9yeSB1bmRlciBwcmV2aW91 cyBjaGFpciAoYWxsbWFuKS4NCg0KV2VzOiB3ZSBoYXZlIGRvYy4gUGVvcGxlIG5lZWQgdG8gcmVh ZCBpdCBzbyB3ZSBjYW4gZGlzY3VzcyBpdC4NCg0KVGltIFNoZXBhcmQ6IEkgaGF2ZSByZWFkIHRo ZSBkcmFmdC4gdHdvIHBhZ2VzIG9mIGNvbnRlbnQuIFNob3J0LiBTd2VldC4gTm9uLWNvbnRyb3Zl cnNpYWwuIGluIGZhdm91ciBvZiBpdCBiZWluZyBXRyBkb2MuIE5vIG9iamVjdGlvbi4gVGhlcmUg aXMgYSBwcm9ibGVtIHdpdGggMTEyMiwgdGhpcyBjYW4gYmUgZml4ZWQuIE5vIG9waW5pb24gb24g RE9TIGRyYWZ0Lg0KDQpzaG91dCBmcm9tIGJhY2s6IG5vdCBvbiBjaGFydGVyIQ0KDQpMYXJzOiBz YXcgcXVlc3Rpb25zIG9uIGxpc3QgYWJvdXQgd2h5IHdlIG5lZWQgdGhpcywgY2FuJ3Qgd2UgZG8g dGhpcyBhbm90aGVyIHdheT8gSWYgdXBkYXRpbmcgMTEyMiwgbmVlZCB0byBjaGVjayBUQ1BNIGNo YXJ0ZXIuIElzIGl0IGluIHNjb3BlPw0KDQpXZXM6IHRoaXMgY291bGQgYmUgYW4gZXJyYXR1bSB0 byAxMTIyLg0KDQpMYXJzOiBpZiBpdCBnZXRzIHN1Ym1pdHRlZCBhcyBhbiBlcnJhdGEsIGl0IHdp bGwgY29tZSBiYWNrIHRvIHRoZSBXRyBmb3IgcmV2aWV3LCBzbw0KdGhpcyBkb2VzIG5vdCBoZWxw Lg0KDQpXZXM6IHJlYWQgdGhlIGRyYWZ0LiByZXBvcnQgZmluZGluZ3MgdG8gbGlzdC4gQ3V0IGFu ZCBwYXN0ZSBib2R5IHRvIG1haWxpbmcgbGlzdCBzbyBwZW9wbGUgcmVhZCBpdC4NCg0KRGF2ZSAo amFiYmVyKSAzIHBsYWNlcyBUQ1AgY2FuIGJlIGFib3J0ZWQ6IFRDUCwga2VybmVsLCBhcHBsaWNh dGlvbi4gTWFpbGluZyBsaXN0IGRpc2N1c3Npb24gLSBUQ1Agc2hvdWxkbid0IGFib3J0LiBLZXJu ZWwgY2FuIGFib3J0IGlmIGFwcHJvcHJpYXRlIGZvciByZXNvdXJjZXMuDQoNCk1haGVzaDogYXNz dW1pbmcgVENQIGFuZCBrZXJuZWwgYXJlIG9uZS4gSW4gc21hbGwgZm9vdHByaW50LCBpdCdzIG9u ZSBlbnRpdHkuIERvbid0IHdhbnQgdG8gd2FkZSBpbnRvIHRoYXQgdGVycml0b3J5IG9mIHdobyBz aG91bGQgdGVybWluYXRlIGNvbm5lY3Rpb24uDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg== ------_=_NextPart_001_01C8F109.52E3672D Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm ------_=_NextPart_001_01C8F109.52E3672D-- From tcpm-bounces@ietf.org Tue Jul 29 03:31:40 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E56F63A6B48; Tue, 29 Jul 2008 03:31:40 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05F633A6B41 for ; Tue, 29 Jul 2008 03:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvo-YW0hZzAn for ; Tue, 29 Jul 2008 03:31:39 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 209B53A6B48 for ; Tue, 29 Jul 2008 03:31:39 -0700 (PDT) Received: from [130.129.20.69] ([130.129.20.69]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6TAVSKs002849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Jul 2008 03:31:32 -0700 (PDT) Message-ID: <488EF15F.4070302@isi.edu> Date: Tue, 29 Jul 2008 03:30:55 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: =?ISO-8859-1?Q?YOSHIFUJI_Hideaki_/_=3F=3F=3F=3F?= References: <20080729.060448.112613043.yoshfuji@linux-ipv6.org> In-Reply-To: <20080729.060448.112613043.yoshfuji@linux-ipv6.org> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP-AO Option Layout - Alignment and Padding X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Hideaki (et al.), YOSHIFUJI Hideaki / ???? wrote: | Hello. | | In section 3.2., TCP-AO Option is defined as follows (option 1): | +---------------------+---------+-------------------+ | | Kind= TBD-IANA-KIND | Len=var | MAC | | +---------------------+---------+-------------------+ | | MAC (con't) ... | +-------------------------------------... | | ...-----------------+---------+ | ... MAC (con't) | KeyID | | ...-----------------+---------+ | | With this layout, An implementation will end up put it like this | +---------+---------+ | | Kind=?? | Length | | +---------+---------+ | +--------------...--+---------+ | | MAC | KeyID | | +--------------...--+---------+ Why is this the case? IP with no options is 20 bytes; the base TCP is 20 bytes, so the options begin aligned; noting that most MAC sizes are multiples of 4 bytes, the alignment is most likely to result in: ~ +---------+---------+--------------------+ ~ | Kind=?? | Length | MAC... | ~ +---------+---------+--------------------+ ~ ... ~ .... ~ +-------------------+---------+ ~ | MAC | KeyID | ~ +-------------------+---------+ In this case, the prepad is 0 and the postpad is 1, but the MAC is only half-word aligned. If we want to reduce padding and keep the MAC aligned, the best option is: ~ +---------+---------+---------+---------+ ~ | Kind=?? | Length | KeyID | 0 | ~ +---------+---------+---------+---------+ ~ ... ~ ... ~ +---------------------------------------+ ~ | MAC... | ~ +---------------------------------------+ I.e., pad ourselves. We suggest that the option start word-aligned. This wastes space, IMO. I would favor a more economical approach that recognizes that a few bits of MAC could be sacrificed for our KeyID, e.g.: ~ +---------+---------+-----+--------------+ ~ | Kind=?? | Length | KID | MAC'... | ~ +---------+---------+-----+--------------+ ~ ... ~ .... ~ +-------------------+ ~ | MAC' | ~ +-------------------+ Use 2 bits for the KID; 1 is insufficient, and 2 is more than sufficient IMO. The MAC' is a half-word aligned MAC with the top 2 bits overwritten (i.e., it is NOT shifted right); the KID occupies those top 2 bits. If a user wants word alignment, pick a MAC length of N-2 bytes. Wouldn't that be simpler and more space efficient? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiO8V8ACgkQE5f5cImnZrvd+wCg4JO7RFCZ0QMtb0l1UzHu+Zi8 NMgAoJJ88bwhDpoZIRvG1Gp4xphzM32F =oNW1 -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 29 03:51:31 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B788A3A6B51; Tue, 29 Jul 2008 03:51:31 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5227A3A6A39 for ; Tue, 29 Jul 2008 03:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.656 X-Spam-Level: *** X-Spam-Status: No, score=3.656 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_MISMATCH_NET=0.611, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBIvoC54K+Le for ; Tue, 29 Jul 2008 03:51:29 -0700 (PDT) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by core3.amsl.com (Postfix) with ESMTP id 6527D3A68CB for ; Tue, 29 Jul 2008 03:51:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id BBDF233B46; Tue, 29 Jul 2008 19:51:50 +0900 (JST) Date: Tue, 29 Jul 2008 06:51:49 -0400 (EDT) Message-Id: <20080729.065149.22600370.yoshfuji@linux-ipv6.org> To: touch@ISI.EDU From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <488EF15F.4070302@isi.edu> References: <20080729.060448.112613043.yoshfuji@linux-ipv6.org> <488EF15F.4070302@isi.edu> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP-AO Option Layout - Alignment and Padding X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hello. In article <488EF15F.4070302@isi.edu> (at Tue, 29 Jul 2008 03:30:55 -0700), Joe Touch says: > | With this layout, An implementation will end up put it like this > | +---------+---------+ > | | Kind=?? | Length | > | +---------+---------+ > | +--------------...--+---------+ > | | MAC | KeyID | > | +--------------...--+---------+ > > Why is this the case? IP with no options is 20 bytes; the base TCP is 20 > bytes, so the options begin aligned; noting that most MAC sizes are > multiples of 4 bytes, the alignment is most likely to result in: > > ~ +---------+---------+--------------------+ > ~ | Kind=?? | Length | MAC... | > ~ +---------+---------+--------------------+ > ~ ... > ~ .... > ~ +-------------------+---------+ > ~ | MAC | KeyID | > ~ +-------------------+---------+ > > In this case, the prepad is 0 and the postpad is 1, but the MAC is only > half-word aligned. Well, memory cop works much better if the memory regions are on 32bit word aligned. (We put timestamp etc.'s "value" on 32bit aligned.) > If we want to reduce padding and keep the MAC aligned, the best option is: > > ~ +---------+---------+---------+---------+ > ~ | Kind=?? | Length | KeyID | 0 | > ~ +---------+---------+---------+---------+ > ~ ... > ~ ... > ~ +---------------------------------------+ > ~ | MAC... | > ~ +---------------------------------------+ I support this. > I.e., pad ourselves. We suggest that the option start word-aligned. This > wastes space, IMO. I don't think this is a waste of space and good thing to have - to save CPU cycle(s). > I would favor a more economical approach that recognizes that a few bits > of MAC could be sacrificed for our KeyID, e.g.: > > ~ +---------+---------+-----+--------------+ > ~ | Kind=?? | Length | KID | MAC'... | > ~ +---------+---------+-----+--------------+ > ~ ... > ~ .... > ~ +-------------------+ > ~ | MAC' | > ~ +-------------------+ > > Use 2 bits for the KID; 1 is insufficient, and 2 is more than sufficient > IMO. > > The MAC' is a half-word aligned MAC with the top 2 bits overwritten > (i.e., it is NOT shifted right); the KID occupies those top 2 bits. > > If a user wants word alignment, pick a MAC length of N-2 bytes. > > Wouldn't that be simpler and more space efficient? We have 256 keys, and it is not enough. And is NOT simple and more complex from implemntation point of view - eats a lot of cpu cycles. --yoshfuji _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 29 05:47:36 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F1B28C23D; Tue, 29 Jul 2008 05:47:36 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 750853A6B5A for ; Tue, 29 Jul 2008 05:47:30 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Cm1mmYHa8Ll for ; Tue, 29 Jul 2008 05:47:28 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id EB21128C266 for ; Tue, 29 Jul 2008 05:47:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,272,1215388800"; d="scan'208";a="58886982" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 29 Jul 2008 12:47:40 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m6TClddo009038; Tue, 29 Jul 2008 05:47:39 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6TClelV003596; Tue, 29 Jul 2008 12:47:40 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 05:47:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 05:46:17 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58058C3506@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <396556a20807281106kfe6eb89sdb32d3836e508ea0@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 Thread-Index: Acjw3NEVCYBgMOiRTJKL+z2goucxXgAmX6+A References: <20080728042451.C7A174B7AD3@kilo.rtfm.com><488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com><488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com><488DE021.7070307@isi.edu><396556a20807280931i257c6597o14cf45f8710611bf@mail.gmail.com><20080728164235.8DD974B96B6@kilo.rtfm.com> <488E0749.4020402@isi.edu> <396556a20807281106kfe6eb89sdb32d3836e508ea0@mail.gmail.com> From: "Anantha Ramaiah (ananth)" To: "Adam Langley" , "Joe Touch" X-OriginalArrivalTime: 29 Jul 2008 12:47:39.0690 (UTC) FILETIME=[48ED30A0:01C8F179] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3240; t=1217335660; x=1218199660; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[tcpm]=20Review=20of=20draft-ietf-tcpm- tcp-auth-opt-01 |Sender:=20; bh=Qa57ACF/kcEkgQyPbStFeeDYG/qVMRmla2xAaIcptfk=; b=e0N0JjNyXWRoz4PdTrwE5mA173YRs/RfZbszyIXgvHYi4O+gwAfZAGD+gM yC0dQshxTnfu8Gv+mT3xOz7hdLwSAcxSUg+cA0fXG8v8EgZpzGfvJxaymP9D 78VQnyCnQd; Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Folks, The extended feeling which I get after watching some of the conversation is that we seem to be in a cherry picking mode of what to include/exclude in the digest (MAC) computation. (psuedo header, TCP options etc.,) So, if we are going down that route, then I would argue it may be worthwhile to debate "how much" to include in general, i.e, is it worthwhile to include selective portions OR part of the data portion of the TCP data in the MAC computation instead of he entire data.? Rationale and reasoning follows :- - performance sensitive applications (in cases there are no hardware assists for computing the crypto) - the very reason of NAT (which you mnetion), yes, I am talking about NAT ALG's which can muck around the data portion of the payload. My point is that it boils down to how much flexibility one wants to provide with the TCP AO. -Anantha > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of Adam Langley > Sent: Monday, July 28, 2008 11:07 AM > To: Joe Touch > Cc: tcpm@ietf.org > Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 > > Some points from the discussion: > > Regarding NATs: > > Your reasoning, as I understood it, for not including an > option to exclude the pseudoheader and port numbers for NAT > traversal was that the host needs these items to lookup the > correct key anyway. > > There are several situation where this is not the case. (I'll > point out that I see TCP-AO as being useful outside the > domain of securing BGP sessions between backbone routers) > > 1) A host installs a key on a listening socket with a > wildcard address. Thus, one can only connect to the socket if > you know the key. > The key probably rotates based on time. This is currently, > usually done based on "port knocking" - which has always > struck me as a messy solution. The resulting, ESTABLISHED > connection knows the port numbers and IP addresses without > having to establish it before hand. > > 2) An unauthenticated connection is established and the > userland code wishes to upgrade to TCP-AO. Again, since the > connection is established the keyset to use are implicit. I > didn't know that the NONE mac was designed for upgrading like > this. In my Linux patches there's a TCP_AUTH_LATCH option > which means "accept unsigned packets until the first signed > packet, then require signatures". > > In both of these cases, excluding port numbers and/or > pesudoheaders is needed given the deployment of NAT boxes > which change these headers. > > > > Keyids: > > I agree that keeping the cryptography in the MAC is a good thing. > There is an implementation issue about the number of keys > that a kernel may have to store (80ish bytes per key * 256 > keys * number of configured hosts), but that's not a spec problem. > > > -- > Adam Langley agl@imperialviolet.org > http://www.imperialviolet.org > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 29 06:10:09 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1CF63A6937; Tue, 29 Jul 2008 06:10:08 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C50428C165 for ; Tue, 29 Jul 2008 06:10:07 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCyTw1x+js6r for ; Tue, 29 Jul 2008 06:10:06 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by core3.amsl.com (Postfix) with ESMTP id A74473A6923 for ; Tue, 29 Jul 2008 06:09:54 -0700 (PDT) Received: from mx-av-06.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.14.3/8.14.3) with ESMTP id m6TDA3OV017793; Tue, 29 Jul 2008 16:10:03 +0300 Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.32]) by mx-av-06.forthnet.gr (8.14.3/8.14.3) with ESMTP id m6TDA3v2025746; Tue, 29 Jul 2008 16:10:03 +0300 Received: from hell.hell.gr (adsl31-182.lsf.forthnet.gr [79.103.158.182]) by MX-IN-05.forthnet.gr (8.14.3/8.14.3) with ESMTP id m6TDA0wv017752; Tue, 29 Jul 2008 16:10:02 +0300 Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=v13@v13.gr; spf=neutral Authentication-Results: MX-IN-05.forthnet.gr header.from=v13@v13.gr; sender-id=neutral From: Stefanos Harhalakis To: tcpm@ietf.org Date: Tue, 29 Jul 2008 16:09:51 +0300 User-Agent: KMail/1.9.9 References: <20080729.060448.112613043.yoshfuji@linux-ipv6.org> <488EF15F.4070302@isi.edu> <20080729.065149.22600370.yoshfuji@linux-ipv6.org> In-Reply-To: <20080729.065149.22600370.yoshfuji@linux-ipv6.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807291609.52235.v13@v13.gr> Cc: touch@isi.edu Subject: Re: [tcpm] TCP-AO Option Layout - Alignment and Padding X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org T24gVHVlc2RheSAyOSBKdWx5IDIwMDgsIFlPU0hJRlVKSSBIaWRlYWtpIC8g5ZCJ6Jek6Iux5piO IHdyb3RlOgo+ID4gSWYgd2Ugd2FudCB0byByZWR1Y2UgcGFkZGluZyBhbmQga2VlcCB0aGUgTUFD IGFsaWduZWQsIHRoZSBiZXN0IG9wdGlvbgo+ID4gaXM6Cj4gPgo+ID4gfiAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLSsKPiA+IH4gICAgICAg ICAgICAgICAgIHwgS2luZD0/PyB8IExlbmd0aCAgfCAgS2V5SUQgIHwgICAwICAgICB8Cj4gPiB+ ICAgICAgICAgICAgICAgICArLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0t Kwo+ID4gfiAgICAgICAgICAgICAgICAgLi4uCj4gPiB+ICAgICAgICAgICAgICAgICAuLi4KPiA+ IH4gICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rCj4gPiB+ICAgICAgICAgICAgICAgICB8ICAgICAgIE1BQy4uLiAgICAgICAgICAgICAgICAg ICAgICAgICAgfAo+ID4gfiAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSsKPgo+IEkgc3VwcG9ydCB0aGlzLgo+Cj4gPiBJLmUuLCBwYWQgb3Vy c2VsdmVzLiBXZSBzdWdnZXN0IHRoYXQgdGhlIG9wdGlvbiBzdGFydCB3b3JkLWFsaWduZWQuIFRo aXMKPiA+IHdhc3RlcyBzcGFjZSwgSU1PLgo+Cj4gSSBkb24ndCB0aGluayB0aGlzIGlzIGEgd2Fz dGUgb2Ygc3BhY2UgYW5kIGdvb2QgdGhpbmcgdG8gaGF2ZSAtCj4gdG8gc2F2ZSBDUFUgY3ljbGUo cykuCgpQbGVhc2UgZG9uJ3QgZG8gdGhpcy4gTGVhdmUgdGhlIHBhZGRpbmcgYXMgYW4gaXNzdWUg Zm9yIHRoZSBPUyBpbXBsZW1lbnRhdGlvbiAKanVzdCBsaWtlIGFsbCBvdGhlciBUQ1Agb3B0aW9u cyBkby4gQW55IE9TIGltcGxlbWVudGF0aW9uIG1heSBhZGQgYSBOT1AgYXQgCnRoZSBiZWdnaW5n IGFuZCBzb2x2ZSB0aGlzIHByb2JsZW0gKGlmIGl0IGFjdHVhbGx5IGV4aXN0cykuCgpBbHNvLCBu b29uZSBjYW4gc2F5IHdoZXRoZXIgdGhlcmUgd2lsbCBiZSBhIDUgYnl0ZXMgb3B0aW9uIGluIHRo ZSBmdXR1cmUgdGhhdCAKd2lsbCBiZSBhYmxlIHRvIGJlIGVmZmVjdGl2ZWx5IGNvbWJpbmVkIHdp dGggdGhpcyBvbmUuCgpCdHcsIGhvdyBzdXJlIGNhbiB5b3UgYmUgdGhhdCAqYWxsKiBUQ1AgaW1w bGVtZW50YXRpb25zIG91dCB0aGVyZSAoUENzLCAKTm9uLVBDcywgc21hbGwtZW1iZWRkZWQsIG1v YmlsZXMgZXRjKSBiZW5lZml0IGZyb20gZXhhY3RseSAzMmJpdCB3cml0ZXM/IAoKSU1ITywgd2hl biB0YWxraW5nIGFib3V0IHRoaW5rcyBsaWtlIHRoaXMgb25lLCB0aGUgdW5kZXJseWluZyBoYXJk d2FyZSBzaG91bGQgCm5vdCBiZSBjb25zaWRlcmVkIGF0IGFsbC4KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KdGNwbSBtYWlsaW5nIGxpc3QKdGNwbUBpZXRm Lm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0K From tcpm-bounces@ietf.org Tue Jul 29 06:41:34 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0513928C2DF; Tue, 29 Jul 2008 06:41:34 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4654C28C2E8 for ; Tue, 29 Jul 2008 06:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZKwYBMXNUzp for ; Tue, 29 Jul 2008 06:41:32 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 5252B28C1C2 for ; Tue, 29 Jul 2008 06:41:32 -0700 (PDT) Received: from [130.129.20.69] ([130.129.20.69]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6TDfKxa001842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Jul 2008 06:41:25 -0700 (PDT) Message-ID: <488F1DE0.3060502@isi.edu> Date: Tue, 29 Jul 2008 06:40:48 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <20080728042451.C7A174B7AD3@kilo.rtfm.com><488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com><488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com><488DE021.7070307@isi.edu><396556a20807280931i257c6597o14cf45f8710611bf@mail.gmail.com><20080728164235.8DD974B96B6@kilo.rtfm.com> <488E0749.4020402@isi.edu> <396556a20807281106kfe6eb89sdb32d3836e508ea0@mail.gmail.com> <0C53DCFB700D144284A584F54711EC58058C3506@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58058C3506@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anantha Ramaiah (ananth) wrote: | Folks, | The extended feeling which I get after watching some of the | conversation is that we seem to be in a cherry picking mode of what to | include/exclude in the digest (MAC) computation. (psuedo header, TCP | options etc.,) | | So, if we are going down that route, then I would argue it may be | worthwhile to debate "how much" to include in general, i.e, is it | worthwhile to include selective portions OR part of the data portion of | the TCP data in the MAC computation instead of he entire data.? Absolutely; that can be implemented inside the MAC algorithm, opaquely to TCP-AO, though. I.e., I can create a MAC that hashes only the odd blocks, only the first half of the blocks, etc. Whether or not there are options to that MAC or not that need to be coordinated end-to-end is up to the key management system; e.g., parameters like "just the firs 10 bytes" can be encoded - again opaquely to TCP-AO - in the key used on a connection. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiPHeAACgkQE5f5cImnZrsG/gCgzGx7+U61UfV2YHNj+JWh0WWy qm4AoMgckf9M8yD3h4WnkjwDHLST3TpQ =Mt+Y -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 29 06:49:06 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0CC628C308; Tue, 29 Jul 2008 06:49:06 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CFE928C308 for ; Tue, 29 Jul 2008 06:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uCQn4wyF3uV for ; Tue, 29 Jul 2008 06:49:04 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 0ED4928C302 for ; Tue, 29 Jul 2008 06:49:04 -0700 (PDT) Received: from [130.129.20.69] ([130.129.20.69]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6TDkElo003193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Jul 2008 06:46:17 -0700 (PDT) Message-ID: <488F1F06.4010508@isi.edu> Date: Tue, 29 Jul 2008 06:45:42 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: =?ISO-8859-1?Q?YOSHIFUJI_Hideaki_/_=3F=3F=3F=3F?= References: <20080729.060448.112613043.yoshfuji@linux-ipv6.org> <488EF15F.4070302@isi.edu> <20080729.065149.22600370.yoshfuji@linux-ipv6.org> In-Reply-To: <20080729.065149.22600370.yoshfuji@linux-ipv6.org> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP-AO Option Layout - Alignment and Padding X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 YOSHIFUJI Hideaki / ???? wrote: ... |> Use 2 bits for the KID; 1 is insufficient, and 2 is more than sufficient |> IMO. |> |> The MAC' is a half-word aligned MAC with the top 2 bits overwritten |> (i.e., it is NOT shifted right); the KID occupies those top 2 bits. |> |> If a user wants word alignment, pick a MAC length of N-2 bytes. |> |> Wouldn't that be simpler and more space efficient? | | We have 256 keys, and it is not enough. Can you explain this further? We're talking about the number of keys used within a single TCP connection; there isn't a clear need (AFAICT) for more than a very small number of these. | And is NOT simple and more complex from implemntation point of view | - eats a lot of cpu cycles. It would consume only two additional cycles in the following: header && 0011111111.... || keyID (store keyIDs as values 0, 64, 128, 192 so you don't need to shift them in/out) I.e., 2 opcodes to encode the bits in the location desired. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiPHwYACgkQE5f5cImnZruiYgCfQKKBKOf+WdLd8+6L06pppd99 KfEAoLOHaEFpvHaZik5EsN4vNNiuLtmE =MUsL -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 29 06:52:49 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76CF428C2FA; Tue, 29 Jul 2008 06:52:49 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B296928C2F7 for ; Tue, 29 Jul 2008 06:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.544 X-Spam-Level: X-Spam-Status: No, score=-0.544 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVb9myNIRwUp for ; Tue, 29 Jul 2008 06:52:47 -0700 (PDT) Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id C1DFC28C2FA for ; Tue, 29 Jul 2008 06:52:47 -0700 (PDT) Received: from host138-59.wifi.conference.usenix.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 0E4AD4BD2AA; Tue, 29 Jul 2008 06:53:00 -0700 (PDT) Date: Tue, 29 Jul 2008 06:52:59 -0700 From: Eric Rescorla To: Joe Touch In-Reply-To: <488F1DE0.3060502@isi.edu> References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <396556a20807280931i257c6597o14cf45f8710611bf@mail.gmail.com> <20080728164235.8DD974B96B6@kilo.rtfm.com> <488E0749.4020402@isi.edu> <396556a20807281106kfe6eb89sdb32d3836e508ea0@mail.gmail.com> <0C53DCFB700D144284A584F54711EC58058C3506@xmb-sjc-21c.amer.cisco.com> <488F1DE0.3060502@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080729135300.0E4AD4BD2AA@kilo.rtfm.com> Cc: Adam Langley , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Tue, 29 Jul 2008 06:40:48 -0700, Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Anantha Ramaiah (ananth) wrote: > | Folks, > | The extended feeling which I get after watching some of the > | conversation is that we seem to be in a cherry picking mode of what to > | include/exclude in the digest (MAC) computation. (psuedo header, TCP > | options etc.,) > | > | So, if we are going down that route, then I would argue it may be > | worthwhile to debate "how much" to include in general, i.e, is it > | worthwhile to include selective portions OR part of the data portion of > | the TCP data in the MAC computation instead of he entire data.? > > Absolutely; that can be implemented inside the MAC algorithm, opaquely > to TCP-AO, though. I.e., I can create a MAC that hashes only the odd > blocks, only the first half of the blocks, etc. > > Whether or not there are options to that MAC or not that need to be > coordinated end-to-end is up to the key management system; e.g., > parameters like "just the firs 10 bytes" can be encoded - again opaquely > to TCP-AO - in the key used on a connection. Well, it's true that one *could* do this, but I think it's a really bad idea. MACs should provide a uniform interface and set of semantics. If you want to have partial coverage, this should be handled at the TCP-AO level. I appreciate that you're trying to isolate the crypto from the TCP-AO service, but I don't think you can isolate it to this extent. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 29 07:06:42 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8096228C332; Tue, 29 Jul 2008 07:06:42 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54E3628C329 for ; Tue, 29 Jul 2008 07:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_WANT=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqgYZQ4UxExo for ; Tue, 29 Jul 2008 07:06:39 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id A74CA28C330 for ; Tue, 29 Jul 2008 07:06:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,272,1215388800"; d="scan'208";a="90822656" Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-3.cisco.com with ESMTP; 29 Jul 2008 14:06:51 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id m6TE6pjj006086; Tue, 29 Jul 2008 07:06:51 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6TE6pXP005180; Tue, 29 Jul 2008 14:06:51 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 07:06:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 07:05:42 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58058C3545@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20080729135300.0E4AD4BD2AA@kilo.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 Thread-Index: Acjxgn4xyK/jMJYiSGKAZhxhYqXkUwAARsvw References: <20080728042451.C7A174B7AD3@kilo.rtfm.com><488D6968.9010102@isi.edu><20080728131254.3DD764B88F7@kilo.rtfm.com><488DD77D.9070608@isi.edu><20080728144721.AC9184B905A@kilo.rtfm.com><488DE021.7070307@isi.edu><396556a20807280931i257c6597o14cf45f8710611bf@mail.gmail.com><20080728164235.8DD974B96B6@kilo.rtfm.com><488E0749.4020402@isi.edu><396556a20807281106kfe6eb89sdb32d3836e508ea0@mail.gmail.com><0C53DCFB700D144284A584F54711EC58058C3506@xmb-sjc-21c.amer.cisco.com><488F1DE0.3060502@isi.edu> <20080729135300.0E4AD4BD2AA@kilo.rtfm.com> From: "Anantha Ramaiah (ananth)" To: "Eric Rescorla" , "Joe Touch" X-OriginalArrivalTime: 29 Jul 2008 14:06:50.0892 (UTC) FILETIME=[58DD14C0:01C8F184] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2639; t=1217340411; x=1218204411; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[tcpm]=20Review=20of=20draft-ietf-tcpm- tcp-auth-opt-01 |Sender:=20; bh=FFFXHm7+BTTuUaJYQwV8zOIGb7+t7eu4k8RJvA3Df3k=; b=xv4XV8R3a7eprHecFiJG7vH47WogqI/zSEZOEyYOl0uXIDEMd2Y2bJC1JD bVazr2Kpz27dtxQh7yx7AfDxRn/WbRpNMOhjWG8ZHtbgPPQw7az2kr8wM0N+ rqfzb1dS0S; Authentication-Results: sj-dkim-8; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of Eric Rescorla > Sent: Tuesday, July 29, 2008 6:53 AM > To: Joe Touch > Cc: Adam Langley; tcpm@ietf.org; Anantha Ramaiah (ananth) > Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 > > At Tue, 29 Jul 2008 06:40:48 -0700, > Joe Touch wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > > > Anantha Ramaiah (ananth) wrote: > > | Folks, > > | The extended feeling which I get after watching some of the > > | conversation is that we seem to be in a cherry picking > mode of what > > | to include/exclude in the digest (MAC) computation. > (psuedo header, > > | TCP options etc.,) > > | > > | So, if we are going down that route, then I would argue it may be > > | worthwhile to debate "how much" to include in general, i.e, is it > > | worthwhile to include selective portions OR part of the > data portion > > | of the TCP data in the MAC computation instead of he entire data.? > > > > Absolutely; that can be implemented inside the MAC > algorithm, opaquely > > to TCP-AO, though. I.e., I can create a MAC that hashes > only the odd > > blocks, only the first half of the blocks, etc. > > > > Whether or not there are options to that MAC or not that need to be > > coordinated end-to-end is up to the key management system; e.g., > > parameters like "just the firs 10 bytes" can be encoded - again > > opaquely to TCP-AO - in the key used on a connection. > > Well, it's true that one *could* do this, but I think it's a > really bad idea. MACs should provide a uniform interface and > set of semantics. > If you want to have partial coverage, this should be handled > at the TCP-AO level. I agree and that was what I was thinking when I was proposing this. > > I appreciate that you're trying to isolate the crypto from > the TCP-AO service, but I don't think you can isolate it to > this extent. Agreed. It needs to come from TCP-AO level even it means changing the format of the TCP-AO option to accomadate this. As an end user of this option I wan't to know how much was "digested" explicitly conveyed as opposed to implicit schemes. Having this in TCP-AO allows a per packet granularity and that is good to have, IMO, if we are going down this route. -Anantha > > -Ekr > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 29 07:11:52 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6307E3A68CD; Tue, 29 Jul 2008 07:11:52 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D1AD3A68CD for ; Tue, 29 Jul 2008 07:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6w2YkK1JXav for ; Tue, 29 Jul 2008 07:11:45 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 0A1C03A680B for ; Tue, 29 Jul 2008 07:11:45 -0700 (PDT) Received: from [130.129.20.69] ([130.129.20.69]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6TEApNV010715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Jul 2008 07:10:55 -0700 (PDT) Message-ID: <488F24CB.8060803@isi.edu> Date: Tue, 29 Jul 2008 07:10:19 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eric Rescorla References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <396556a20807280931i257c6597o14cf45f8710611bf@mail.gmail.com> <20080728164235.8DD974B96B6@kilo.rtfm.com> <488E0749.4020402@isi.edu> <396556a20807281106kfe6eb89sdb32d3836e508ea0@mail.gmail.com> <0C53DCFB700D144284A584F54711EC58058C3506@xmb-sjc-21c.amer.cisco.com> <488F1DE0.3060502@isi.edu> <20080729135300.0E4AD4BD2AA@kilo.rtfm.com> In-Reply-To: <20080729135300.0E4AD4BD2AA@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Adam Langley , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Eric, Eric Rescorla wrote: | At Tue, 29 Jul 2008 06:40:48 -0700, | Joe Touch wrote: |> -----BEGIN PGP SIGNED MESSAGE----- |> Hash: SHA1 ... |> | So, if we are going down that route, then I would argue it may be |> | worthwhile to debate "how much" to include in general, i.e, is it |> | worthwhile to include selective portions OR part of the data portion of |> | the TCP data in the MAC computation instead of he entire data.? |> |> Absolutely; that can be implemented inside the MAC algorithm, opaquely |> to TCP-AO, though. I.e., I can create a MAC that hashes only the odd |> blocks, only the first half of the blocks, etc. ... | Well, it's true that one *could* do this, but I think it's a really | bad idea. MACs should provide a uniform interface and set of semantics. | If you want to have partial coverage, this should be handled at the | TCP-AO level. First, I'm not sure this overall function is useful; since apps can't align data to the TCP segments, IMO the data is "all or none". I don't see a reason to omit the data entirely from a MAC (excepting performance for statistical benefit). Overall, this doesn't seem to fit the spirit of "TCP-AO should be simple". | I appreciate that you're trying to isolate the crypto from the TCP-AO | service, but I don't think you can isolate it to this extent. It would be useful to explain the reason you see a need for coupling here (provided this is even needed, as noted above). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiPJMoACgkQE5f5cImnZrsR5QCgjz/jGcyaulBsaj7jveB7QI8b AesAoPcExSVjVHJIh46Ppbl1qzTZUX9F =e/3B -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 29 07:14:58 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D65B53A6982; Tue, 29 Jul 2008 07:14:58 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E8163A6A8A for ; Tue, 29 Jul 2008 07:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.382 X-Spam-Level: X-Spam-Status: No, score=-1.382 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, MANGLED_WANT=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRf-bTMO2knZ for ; Tue, 29 Jul 2008 07:14:57 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 95C563A6982 for ; Tue, 29 Jul 2008 07:14:27 -0700 (PDT) Received: from [130.129.20.69] ([130.129.20.69]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6TECnpm011310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Jul 2008 07:12:53 -0700 (PDT) Message-ID: <488F2541.2070800@isi.edu> Date: Tue, 29 Jul 2008 07:12:17 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <20080728042451.C7A174B7AD3@kilo.rtfm.com><488D6968.9010102@isi.edu><20080728131254.3DD764B88F7@kilo.rtfm.com><488DD77D.9070608@isi.edu><20080728144721.AC9184B905A@kilo.rtfm.com><488DE021.7070307@isi.edu><396556a20807280931i257c6597o14cf45f8710611bf@mail.gmail.com><20080728164235.8DD974B96B6@kilo.rtfm.com><488E0749.4020402@isi.edu><396556a20807281106kfe6eb89sdb32d3836e508ea0@mail.gmail.com><0C53DCFB700D144284A584F54711EC58058C3506@xmb-sjc-21c.amer.cisco.com><488F1DE0.3060502@isi.edu> <20080729135300.0E4AD4BD2AA@kilo.rtfm.com> <0C53DCFB700D144284A584F54711EC58058C3545@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58058C3545@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anantha Ramaiah (ananth) wrote: ... |> If you want to have partial coverage, this should be handled |> at the TCP-AO level. | | I agree and that was what I was thinking when I was proposing this. | |> I appreciate that you're trying to isolate the crypto from |> the TCP-AO service, but I don't think you can isolate it to |> this extent. | | Agreed. It needs to come from TCP-AO level even it means changing the | format of the TCP-AO option to accomadate this. As an end user of this | option I wan't to know how much was "digested" explicitly conveyed as | opposed to implicit schemes. Having this in TCP-AO allows a per packet | granularity and that is good to have, IMO, if we are going down this | route. Can you explain how this might correlate to a segment? or why per-segment info is needed? More to the point, given there is no corresponding UDP-lite for TCP, why is this needed for TCP-AO? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiPJUAACgkQE5f5cImnZrug9ACfZgG3XRUhfSJRaUTuR1Zu1XW2 h84AoJLGca92VkMp8NvqgMWsFoB48SD2 =ACpR -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 29 07:48:33 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DB173A6A60; Tue, 29 Jul 2008 07:48:33 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B5913A6B81 for ; Tue, 29 Jul 2008 07:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.066 X-Spam-Level: X-Spam-Status: No, score=-5.066 tagged_above=-999 required=5 tests=[AWL=-0.767, BAYES_00=-2.599, MANGLED_WANT=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQWa85P7mssy for ; Tue, 29 Jul 2008 07:48:23 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 424D43A6927 for ; Tue, 29 Jul 2008 07:48:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,272,1215388800"; d="scan'208";a="90841341" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 29 Jul 2008 14:47:13 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m6TElD9j014134; Tue, 29 Jul 2008 07:47:13 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m6TElDqU002006; Tue, 29 Jul 2008 14:47:13 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 07:47:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 07:46:03 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58058C3563@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <488F2541.2070800@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 Thread-Index: AcjxhVVNTGE4em7pTC2UXoMFS8SQhgAAwmWg References: <20080728042451.C7A174B7AD3@kilo.rtfm.com><488D6968.9010102@isi.edu><20080728131254.3DD764B88F7@kilo.rtfm.com><488DD77D.9070608@isi.edu><20080728144721.AC9184B905A@kilo.rtfm.com><488DE021.7070307@isi.edu><396556a20807280931i257c6597o14cf45f8710611bf@mail.gmail.com><20080728164235.8DD974B96B6@kilo.rtfm.com><488E0749.4020402@isi.edu><396556a20807281106kfe6eb89sdb32d3836e508ea0@mail.gmail.com><0C53DCFB700D144284A584F54711EC58058C3506@xmb-sjc-21c.amer.cisco.com><488F1DE0.3060502@isi.edu> <20080729135300.0E4AD4BD2AA@kilo.rtfm.com> <0C53DCFB700D144284A584F54711EC58058C3545@xmb-sjc-21c.amer.cisco.com> <488F2541.2070800@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" X-OriginalArrivalTime: 29 Jul 2008 14:47:12.0948 (UTC) FILETIME=[FC857F40:01C8F189] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1632; t=1217342833; x=1218206833; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[tcpm]=20Review=20of=20draft-ietf-tcpm- tcp-auth-opt-01 |Sender:=20; bh=+IzX9KSIlJTxX/VOvh95YlCfV6wi3yybPiieQj1kZ34=; b=B8Pi2QLmP77kg8UseOIEX3s4CeFe/Ldh94kWp85ix9DQbhUFB25bCDE2sl ze5xRBWys3qZBpgZSfQJSMnemRWITOseNFWRFvOJzDRqq4EPgZ5yfGGNAF0S hz9lIpdI9C; Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Joe, > |> If you want to have partial coverage, this should be > handled at the > |> TCP-AO level. > | > | I agree and that was what I was thinking when I was proposing this. > | > |> I appreciate that you're trying to isolate the crypto from > the TCP-AO > |> service, but I don't think you can isolate it to this extent. > | > | Agreed. It needs to come from TCP-AO level even it means > changing the > | format of the TCP-AO option to accomadate this. As an end > user of this > | option I wan't to know how much was "digested" explicitly > conveyed as > | opposed to implicit schemes. Having this in TCP-AO allows a per > | packet granularity and that is good to have, IMO, if we are > going down > | this route. > > Can you explain how this might correlate to a segment? or why > per-segment info is needed? Flexibility, applications would want to ( I am not making this up) "protect" crucial information, atleast what it considers as crucial information. For performance reasons being one of them. Agreed, TCP shouldn't care. > > More to the point, given there is no corresponding UDP-lite > for TCP, why is this needed for TCP-AO? After you clarified to me in the hallway conversation, I agree with your viewpoint. Anyways, it appears that we are not yet converged on what can be included in the TCP-AO and the degree of flexibilty one can expect. At the least it would be expedient to reflect the discussions in the document since I am sure these things would come up at some point again. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 29 08:17:39 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800383A6B96; Tue, 29 Jul 2008 08:17:39 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B32DC3A6B92 for ; Tue, 29 Jul 2008 08:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14cu2ow7f33s for ; Tue, 29 Jul 2008 08:17:37 -0700 (PDT) Received: from kilo.rtfm.com (unknown [12.155.21.101]) by core3.amsl.com (Postfix) with ESMTP id EEBF23A6B96 for ; Tue, 29 Jul 2008 08:17:36 -0700 (PDT) Received: from host138-59.wifi.conference.usenix.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id BFC344BD795; Tue, 29 Jul 2008 08:17:49 -0700 (PDT) Date: Tue, 29 Jul 2008 08:17:49 -0700 From: Eric Rescorla To: Joe Touch In-Reply-To: <488F24CB.8060803@isi.edu> References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <396556a20807280931i257c6597o14cf45f8710611bf@mail.gmail.com> <20080728164235.8DD974B96B6@kilo.rtfm.com> <488E0749.4020402@isi.edu> <396556a20807281106kfe6eb89sdb32d3836e508ea0@mail.gmail.com> <0C53DCFB700D144284A584F54711EC58058C3506@xmb-sjc-21c.amer.cisco.com> <488F1DE0.3060502@isi.edu> <20080729135300.0E4AD4BD2AA@kilo.rtfm.com> <488F24CB.8060803@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080729151749.BFC344BD795@kilo.rtfm.com> Cc: Adam Langley , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Tue, 29 Jul 2008 07:10:19 -0700, Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Eric, > > Eric Rescorla wrote: > | At Tue, 29 Jul 2008 06:40:48 -0700, > | Joe Touch wrote: > |> -----BEGIN PGP SIGNED MESSAGE----- > |> Hash: SHA1 > ... > |> | So, if we are going down that route, then I would argue it may be > |> | worthwhile to debate "how much" to include in general, i.e, is it > |> | worthwhile to include selective portions OR part of the data portion of > |> | the TCP data in the MAC computation instead of he entire data.? > |> > |> Absolutely; that can be implemented inside the MAC algorithm, opaquely > |> to TCP-AO, though. I.e., I can create a MAC that hashes only the odd > |> blocks, only the first half of the blocks, etc. > ... > | Well, it's true that one *could* do this, but I think it's a really > | bad idea. MACs should provide a uniform interface and set of semantics. > | If you want to have partial coverage, this should be handled at the > | TCP-AO level. > > First, I'm not sure this overall function is useful; since apps can't > align data to the TCP segments, IMO the data is "all or none". I don't > see a reason to omit the data entirely from a MAC (excepting performance > for statistical benefit). > > Overall, this doesn't seem to fit the spirit of "TCP-AO should be simple". > > | I appreciate that you're trying to isolate the crypto from the TCP-AO > | service, but I don't think you can isolate it to this extent. > > It would be useful to explain the reason you see a need for coupling > here (provided this is even needed, as noted above). (1) I don't think it's needed. (2) The semantics of partial protection are only meaningful at the TCP layer. The MAC just operates on chunks of bits. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 29 12:10:50 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE6A73A6B19; Tue, 29 Jul 2008 12:10:50 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EEEB3A6B19 for ; Tue, 29 Jul 2008 12:10:49 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-lF4AFJOSWA for ; Tue, 29 Jul 2008 12:10:48 -0700 (PDT) Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by core3.amsl.com (Postfix) with ESMTP id F24BE3A687A for ; Tue, 29 Jul 2008 12:10:47 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 15:10:57 -0400 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7703FA4633@nekter> In-Reply-To: <488F24CB.8060803@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 Thread-Index: AcjxhRecZf76mQahSuSDpbvZJgOS2AAKM0Kg References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <396556a20807280931i257c6597o14cf45f8710611bf@mail.gmail.com> <20080728164235.8DD974B96B6@kilo.rtfm.com> <488E0749.4020402@isi.edu> <396556a20807281106kfe6eb89sdb32d3836e508ea0@mail.gmail.com> <0C53DCFB700D144284A584F54711EC58058C3506@xmb-sjc-21c.amer.cisco.com> <488F1DE0.3060502@isi.edu><20080729135300.0E4AD4BD2AA@kilo.rtfm.com> <488F24CB.8060803@isi.edu> From: "Caitlin Bestler" To: "Joe Touch" , "Eric Rescorla" Cc: Adam Langley , tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org A few comments on the alignment issue: 1) Compared to the cost of supporting the crypto-engines and their supporting data, dealing with variable alignment is unlikely to be a major factor in determining whether to include hardware support for TCP-Auth or not. 2) The optimizing alignment might be 64-bits anyway. This only emphasizes the point that putting padding in TCP headers based on presumptions of what is efficient is short-sighted. 3) Hardware support for TCP-Auth is in competition with MACsec, IPSEC and TLS. So any thoughts of optimizing for implementation should probably focus on software implementations and/or specialized devices. I would be surprised to see hardware assists for this in general purpose NICs. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 29 15:29:48 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 972493A6B4A; Tue, 29 Jul 2008 15:29:48 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298363A6AF8 for ; Tue, 29 Jul 2008 15:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOAIpIdtRcF8 for ; Tue, 29 Jul 2008 15:29:46 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 225353A6ABB for ; Tue, 29 Jul 2008 15:29:46 -0700 (PDT) Received: from [172.16.7.194] ([130.129.65.153]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6TMTWR0006007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Jul 2008 15:29:35 -0700 (PDT) Message-ID: <488F99AB.3090207@isi.edu> Date: Tue, 29 Jul 2008 15:28:59 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <396556a20807280931i257c6597o14cf45f8710611bf@mail.gmail.com> <20080728164235.8DD974B96B6@kilo.rtfm.com> <488E0749.4020402@isi.edu> <396556a20807281106kfe6eb89sdb32d3836e508ea0@mail.gmail.com> In-Reply-To: <396556a20807281106kfe6eb89sdb32d3836e508ea0@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam, Adam Langley wrote: | Some points from the discussion: | | Regarding NATs: | | Your reasoning, as I understood it, for not including an option to | exclude the pseudoheader and port numbers for NAT traversal was that | the host needs these items to lookup the correct key anyway. | | There are several situation where this is not the case. (I'll point | out that I see TCP-AO as being useful outside the domain of securing | BGP sessions between backbone routers) | | 1) A host installs a key on a listening socket with a wildcard | address. We don't support this use. There are no wildcard addresses in installed keys; only the source port can be wildcarded. | Thus, one can only connect to the socket if you know the key. | The key probably rotates based on time. This is currently, usually | done based on "port knocking" - which has always struck me as a messy | solution. The resulting, ESTABLISHED connection knows the port numbers | and IP addresses without having to establish it before hand. | | 2) An unauthenticated connection is established and the userland code | wishes to upgrade to TCP-AO. Again, since the connection is | established the keyset to use are implicit. I didn't know that the | NONE mac was designed for upgrading like this. In my Linux patches | there's a TCP_AUTH_LATCH option which means "accept unsigned packets | until the first signed packet, then require signatures". That's changing from NONE to a non-NONE MAC. | Keyids: | | I agree that keeping the cryptography in the MAC is a good thing. | There is an implementation issue about the number of keys that a | kernel may have to store (80ish bytes per key * 256 keys * number of | configured hosts), but that's not a spec problem. Agreed. I'll try to capture that. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiPmasACgkQE5f5cImnZruPvACffvwthv0WF/N3MYbXQgZjt7Ft lwsAoIXk+Ac9/1YH9xp3xFdlEb/1ym+v =xP0v -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Jul 29 15:30:42 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBAF63A6B77; Tue, 29 Jul 2008 15:30:42 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B37B3A6B76 for ; Tue, 29 Jul 2008 15:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdLV-sEplREj for ; Tue, 29 Jul 2008 15:30:40 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 67A3F3A6AF8 for ; Tue, 29 Jul 2008 15:30:40 -0700 (PDT) Received: from [172.16.7.194] ([130.129.65.153]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6TMULM0006212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Jul 2008 15:30:24 -0700 (PDT) Message-ID: <488F99DC.4040206@isi.edu> Date: Tue, 29 Jul 2008 15:29:48 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eric Rescorla References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <20080728164013.422D14B9600@kilo.rtfm.com> <488E0644.6020006@isi.edu> <20080728180907.22EC04BA1D7@kilo.rtfm.com> In-Reply-To: <20080728180907.22EC04BA1D7@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Eric, Eric Rescorla wrote: ...(concerns about having a separate key mgt doc) These concerns can be taken to the ADs, but at this point they may be moot. We might consider merging the resulting docs, but it's not clear why that would be useful. |> | The protocol must be constructed so that it is not possible to substitute |> | one packet for another and have it be accepted. This means that (either) |> | the data fed into the authentication function must be distinct or the |> | authentication function must have a distinct key. |> |> That implies a per-packet nonce, i.e., some fields - either in the |> packet or external - that are unique on a per-packet basis. | | Well, perhaps we're just differing in terminology, but I don't call | per-packet data fed into the authentication function a nonce. | I think of the nonce as a discrete value, not just the data. | But in this case we're just talking about MACing the packet. | | I just checked and neither AH nor TLS uses the term nonce here. IPsec uses sequence numbers for multiple reasons, so they're not called just nonces. I'm not sure if the same is true for TLS. If we're at least talking about the same thing (which I think we are now), then we can find a better word to describe it... Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiPmdwACgkQE5f5cImnZrs0pACfTPAEByS/3DxoQGxYzttfWubt I64AoM+6MdHC8jUQKM2MMufdx+kBVCWI =cWF5 -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 30 06:12:11 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B1013A68A2; Wed, 30 Jul 2008 06:12:11 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B5713A688C for ; Wed, 30 Jul 2008 06:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWJ9v8WAR4bX for ; Wed, 30 Jul 2008 06:12:09 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 4870F3A68A2 for ; Wed, 30 Jul 2008 06:12:09 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6UDBGVF002434; Wed, 30 Jul 2008 16:11:23 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 16:11:10 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 16:11:10 +0300 Received: from lars.meeting.ietf.org ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 16:11:09 +0300 Message-Id: From: Lars Eggert To: ext Eric Rescorla In-Reply-To: <20080728164013.422D14B9600@kilo.rtfm.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 30 Jul 2008 14:11:04 +0100 References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <20080728164013.422D14B9600@kilo.rtfm.com> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 30 Jul 2008 13:11:10.0096 (UTC) FILETIME=[BC01D100:01C8F245] X-Nokia-AV: Clean Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On 2008-7-28, at 17:40, ext Eric Rescorla wrote: > At Mon, 28 Jul 2008 08:05:05 -0700, > Joe Touch wrote: >> OK; we're dancing around terms here. TCP-AO uses a _separate_ >> document >> to specify the out-of-band key mechanism. What that includes can be >> discussed in that context - e.g., on SAAG. > > Well, I think that's a mistake as well. > > (1) It's extremely confusing to have two documents. > (2) There are two issues: ... > (3) SAAG has no capability to work on anything, and isn't doing so. My recollection of the history here is that the split into an option part done in TCPM and a keying part done somewhere in the SEC area was deliberate, and came out of long discussions between TSV, SEC and RTG folks. One motivation was that it seemed unlikely that TCPM needed to be involved in the details of the keying effort, past the stage of making sure that the necessary hooks were in place. Another was the hope that the two efforts could more or less run in parallel. The SEC keying effort has been slow to get off the ground. Unless there are critical reasons to revisit this decision, I'd like to avoid it. Anything that delays publication of AO isn't helpful at this point. Lars _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 30 06:15:56 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E57ED3A6902; Wed, 30 Jul 2008 06:15:56 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B51B93A697D for ; Wed, 30 Jul 2008 06:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.473 X-Spam-Level: X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLhPiBhz-IAM for ; Wed, 30 Jul 2008 06:15:55 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id D41ED3A68C8 for ; Wed, 30 Jul 2008 06:15:54 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6UDF95h019968; Wed, 30 Jul 2008 08:16:05 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 16:15:28 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 16:15:23 +0300 Received: from lars.meeting.ietf.org ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 16:15:23 +0300 Message-Id: <8AE3EAC6-05D7-4226-914D-04B41DD8CC06@nokia.com> From: Lars Eggert To: ext Stefanos Harhalakis In-Reply-To: <200807291609.52235.v13@v13.gr> Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 30 Jul 2008 14:15:19 +0100 References: <20080729.060448.112613043.yoshfuji@linux-ipv6.org> <488EF15F.4070302@isi.edu> <20080729.065149.22600370.yoshfuji@linux-ipv6.org> <200807291609.52235.v13@v13.gr> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 30 Jul 2008 13:15:23.0718 (UTC) FILETIME=[532D7660:01C8F246] X-Nokia-AV: Clean Cc: tcpm@ietf.org, touch@isi.edu Subject: Re: [tcpm] TCP-AO Option Layout - Alignment and Padding X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On 2008-7-29, at 14:09, ext Stefanos Harhalakis wrote: > Please don't do this. Leave the padding as an issue for the OS > implementation > just like all other TCP options do. Any OS implementation may add a > NOP at > the begging and solve this problem (if it actually exists). (contributor hat on) I agree with this. Lars _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 30 14:32:41 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23CF43A686C; Wed, 30 Jul 2008 14:32:41 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C9A23A686C for ; Wed, 30 Jul 2008 14:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[AWL=-1.196, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MANGLED_TOOL=2.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A39tR6kyc1dQ for ; Wed, 30 Jul 2008 14:32:39 -0700 (PDT) Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id CC9FE3A67A6 for ; Wed, 30 Jul 2008 14:32:38 -0700 (PDT) Received: from host138-59.wifi.conference.usenix.org (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id B347F4D52E1; Wed, 30 Jul 2008 14:32:53 -0700 (PDT) Date: Wed, 30 Jul 2008 14:32:53 -0700 From: Eric Rescorla To: Lars Eggert In-Reply-To: References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <20080728164013.422D14B9600@kilo.rtfm.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080730213253.B347F4D52E1@kilo.rtfm.com> Cc: tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Wed, 30 Jul 2008 14:11:04 +0100, Lars Eggert wrote: > > On 2008-7-28, at 17:40, ext Eric Rescorla wrote: > > At Mon, 28 Jul 2008 08:05:05 -0700, > > Joe Touch wrote: > >> OK; we're dancing around terms here. TCP-AO uses a _separate_ > >> document > >> to specify the out-of-band key mechanism. What that includes can be > >> discussed in that context - e.g., on SAAG. > > > > Well, I think that's a mistake as well. > > > > (1) It's extremely confusing to have two documents. > > (2) There are two issues: > ... > > (3) SAAG has no capability to work on anything, and isn't doing so. > > My recollection of the history here is that the split into an option > part done in TCPM and a keying part done somewhere in the SEC area was > deliberate, and came out of long discussions between TSV, SEC and RTG > folks. But again, it depends what you mean by "a keying part". Here's the general situation that applies with any communication security protocol: - Alice and Bob have long term keys K_a and K_b respectively. - Each individual connetion must have connection keys C_ab and C_ba for transmission between Alice and Bob and Bob and Alice respectively. We need some way to arrange that we start with K_a, K_b and we end up with C_ab, C_ba. For comparison, IPsec solves this problem by having two flavors of key managment: - Null (manual) key management in which K_a, K_b are symmetric keys (actually probably one key) with a static mapping to C_ab, C_ba, e.g.. C_ab = K_a, C_ba=K_b - An automatic key management protocol (IKE) which is run every time an association needs to be set up and which bootstraps K_a, K_b into C_ab, C_ba TCP-MD5 offers a reduced version of the Null model with a single key. draft-bonica and TCP-AO-00 (I'll get to -01 in a minute) in principle support both models, however, as there has been no progress whatsoever on actually doing an automatic key management protocol for this application, that leaves us with the Null model. Again, there's a static key (or perhaps keys) that is used directly as a per-connection key for all connections. The problem with this scheme, as everyone is no doubt tired of hearing me say, is that it is susceptible to a variety of cut-and-paste attacks, both between connections (with the same host/port quartet) and within connections (due to seqno rollover). Now, one could have a number of possible attitudes about this: (A) It's no big deal. (B) We'll live with this for manual keying but we'll deal with it when we finally do automatic keying. (C) We should try to fix it. Given the progress of AKM and the general lack of interest in it from the relevant community, I claim that (B) is more or less the same as (C), at least for the medium term. Now, I personally waver between (A) and (C), but to the extent to which we don't value bits on the wire compatibility, as I observed before, it's possible to remove these problems with TCP-AO without any explicit key management protocol. The solution is to have a set of "key diversification" rules that arrange that even when two packets have the same set of TCP parameters on the wire they are not substitutable. Namely: - Use the ISNs to arrange that different connections have different keys. - Use either an extended sequence number or internal key rollover to avoid cut-and-paste within connections. It should be clear that this sort of technique requires a fairly tight binding between the key diversification/MAC code and the TCP stack, because: - The key computation code needs to know the ISNs for the connection. - If you're using key rollover, then the key computation code needs to know when the seqno rolls over. Now, obviously, you *can* think of this as a particularly dumb form of external key management. I.e., you tell it when you're establishing a new connection and it gives you the key (actually you need *two* interfaces here, because the first packet has to use a 0 ISN for the peer), and then (if using key rollover) you tell it that the ISN rolled over and you would like a separate key. But I think this is unwise for several reasons: - It requires instantiating a new abstraction layer and defining interfaces which are necessarily fairly wide for something which is in principle conceptually quite simple and tightly bound to AO. - These abstractions aren't obviously the abstractions you want for a real (explicit) external key management protocol. - You want the rollover functionality even with an external key management protocol. To expand on the final point, there is no cryptographic reason why you would need to change keys every 2^31 bytes. The *sole* reason is that the TCP seqno is too short. I don't really understand the claimed reasons why an extended sequence number is considered bad, but it doesn't really make sense to call out to the key management system to correct a problem which is TCP-AO, not in the key management, and is common to *every* key management system. Far better to simply define how this works with AO for every key management system and MAC algorithm. I promised I would get to TCP-AO-01, and though it's taken me a long time, here we are. IMHO, TCP-AO-01 reflects the sort of confused interface you end up with when you try to make this unnecessary separation: (1) It suggests how to compute a "nonce" based on the ISNs, but (a) doesn't require this computation algorithm and (b) doesn't specify how one would actually use the nonce with a MAC. The text reads "MACs typically benefit from a per-connection nonce, notably in avoiding the impact of key reuse." Except neither of the most commonly proposed MACs, HMAC or AES-CMAC, uses a nonce, so it's totally unclear how to use this functionality. (2) It suggests key rollover at 2^31 bytes but doesn't describe how to do it. To be clear, if you're using manual key management with key diversification (i.e., without an explicit KMP), then these aren't matters that can be negotiated. Both sides need to simply be configured with how the keys are computed (and diversified) and whether to do key rollover or not. Moreover, again, these issues are largely orthogonal to the choice of MAC. > One motivation was that it seemed unlikely that TCPM needed to be > involved in the details of the keying effort, past the stage of making > sure that the necessary hooks were in place. Given the very tight coupling between TCP and the issues I'm discussing above, I don't really see how TCPM can avoid being involved in these issues. > Unless there are critical reasons to revisit this decision, I'd like > to avoid it. Anything that delays publication of AO isn't helpful at > this point. Well, I'm not suggesting that TCP-AO be specified with a full external KMP. I'm suggesting that it be specified with the above key diversification techniques rather than the current set of vague/confusing hints and a hope that some other document will eventually be specified to fill in the gaps. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 30 15:23:30 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 235EA3A69EE; Wed, 30 Jul 2008 15:23:30 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BEB03A69EE for ; Wed, 30 Jul 2008 15:23:29 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7vsigGO40dQ for ; Wed, 30 Jul 2008 15:23:28 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 329C33A69E7 for ; Wed, 30 Jul 2008 15:23:28 -0700 (PDT) Received: from [128.9.176.37] (c1-vpn7.isi.edu [128.9.176.37]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6UMNDx0000943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Jul 2008 15:23:16 -0700 (PDT) Message-ID: <4890E9AE.3000607@isi.edu> Date: Wed, 30 Jul 2008 15:22:38 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: tcpm@ietf.org References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <20080728164013.422D14B9600@kilo.rtfm.com> <20080730213253.B347F4D52E1@kilo.rtfm.com> In-Reply-To: <20080730213253.B347F4D52E1@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [tcpm] tcp-auth-opt issue: replay protection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Given Eric's points on this topic, as a way forward, there are a few alternatives (comments requested) 1. assume the key management system (KMS) will rollover the keys every 2^31 bytes Eric noted this is weak, since we cannot rely on the KMS to act on this without other info. Let's presume this is unacceptable to the WG and move on... 2. include an extended sequence number (ESN) inside TCP-AO ESN starts at 0 increment ESN when the TCP sequence number rolls over* passed ESN to the encryption algorithm as part of the MAC'd data 3. have TCP-AO ask the KMS to add a new key for the connection when the sequence number rolls over (actually just before, e.g., 2^31 rolls over) - ------------------------------------ #2 is internal to TCP-AO, i.e., it requires no 'callback' to the KMS There appears to be a synchronization issue here - exactly when is the ESN incremented? Suppose endpoints A and B; there are two ESNs - ESN_ab and ESN_ba: A increments ESN_ab when A receives an ack from B w/seqno > 2^31 B increments ESN_ab when B sends an ack to A w/seqno > 2^31 B increments ESN_ba when B receives an ack from A w/seqno > 2^31 A increments ESN_ba when A sends an ack to B w/seqno > 2^31 i.e., the ESN is incremented when the reverse channel succeeds; we can't use the forward channel, since one side would change the ESN in ways the other would never notice (it wouldn't decode it) Given that algorithm, every ESN increment would trash data in transit from A-B. Is there an algorithm that does not do this? - ------------------------------------- #3 allows packets to be reordered without loss during key rollover, and is not susceptible to the burst-losses of #2 Note that #2 should not 'insert a key into the TSAD' - that interface should be under the exclusive control of the KMS - at which point asking the KMS to keep that info (or bury it in the TSAD where the KMS can refer to it) seems sufficient. Comments? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiQ6a4ACgkQE5f5cImnZruZ7ACfRfobhbIZYd/t4xZinRjqMNHp AwgAn0hNl3OS50CRmx35wngpGrUBzqfo =DPd7 -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 30 15:43:19 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6548D3A6A15; Wed, 30 Jul 2008 15:43:19 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9DC73A6A17 for ; Wed, 30 Jul 2008 15:43: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXB0gmuzYSvj for ; Wed, 30 Jul 2008 15:43:16 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id B6F4D3A6A15 for ; Wed, 30 Jul 2008 15:43:16 -0700 (PDT) Received: from [128.9.176.37] (c1-vpn7.isi.edu [128.9.176.37]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6UMhCTC009035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Jul 2008 15:43:15 -0700 (PDT) Message-ID: <4890EE5E.2000400@isi.edu> Date: Wed, 30 Jul 2008 15:42:38 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: tcpm@ietf.org X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [tcpm] tcp-auth-opt issue: unique connection keys X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric has raised the point that we should expect the TCP-AO system (TCP-AO and its required key management system [KMS]) to ensure unique connection keys. draft-01 outlines the information that would be used to provide this information (i.e., derivative of the ISN, etc.). Eric raised concerns about whether this function can reasonably be external to TCP-AO (e.g., inside the KMS) or inside the KMS, and about the vagueness of the description. The current document was intended as a starting point for that discussion, FWIW. One observation is that the KMS manages keys for connections - i.e., the socket pair (addr/port pair) - but has no info on ISNs. It can establish keys for that socket pair in the TSAD, but cannot generate appropriate session keys in advance of a connection being established. Let's assume that the KMS includes the socket pair in the connection key when it inserts it into the TSAD (or that this can occur trivially for wildcard source port entries by re-hashing with the appropriate port when the first packet instantiates the entry). As a result, the ISNs are the only missing component to the connection key. As was suggested before, use ISNs as follow: SYN (without ACK) - use src_ISN from SYN, dst_ISN=0 all other packets - use src_ISN, dst_ISN from first SYN rec'd There are (at least) two ways to achieve this: 1) prepend src_ISN, dst_ISN to each incoming packet for MAC calculation 2) overwrite the TSAD keys established by the KMS i.e., on first SYN emitted key=hash(key, src_ISN) on SYN-ACK received key=hash(key, dst_ISN) #1 has the advantage that it appears to work for simultaneous open, in which the SYNs are keyed based on different ISN info in each direction, but are received properly #2 reduces the per-packet cost by the length of two ISNs, by investing in the hash at connection establishment. However, it appears to prohibit simultaneous open. Can anyone suggest a solution that supports simultaneous open? - ----- Comments? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiQ7l0ACgkQE5f5cImnZru5oQCg34uLab9rSv+VUWGvHen/XVrH 9f4An0DYlyLl0Cxb29CgPcyjQPtJKjjx =Tzqz -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 30 15:49:07 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA5773A6812; Wed, 30 Jul 2008 15:49:07 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86FE73A6807 for ; Wed, 30 Jul 2008 15:49:04 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4i0KJ2Q+qr75 for ; Wed, 30 Jul 2008 15:49:02 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id B76913A67AC for ; Wed, 30 Jul 2008 15:49:02 -0700 (PDT) Received: from [128.9.176.37] (c1-vpn7.isi.edu [128.9.176.37]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6UMmowM011712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Jul 2008 15:48:53 -0700 (PDT) Message-ID: <4890EFB0.5020301@isi.edu> Date: Wed, 30 Jul 2008 15:48:16 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: tcpm@ietf.org X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [tcpm] tcp-auth-opt issue: header format and alignment X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There has been a variety of discussion on this issue. The consensus appears to be emerging that we retain a simple, deterministic header format, and leave alignment issues to implementations: +------+------+------+------...-----+ | KIND | LEN | TSPI | MAC......... | +------+------+------+------...-----+ each of the first three fields are one byte (Alfred Hoenes suggested we rename the KeyID to a TSPI, i.e., a TCP-AO security parameters index, since it corresponds to the SPI in IPsec, i.e., it indexes from among a set of security parameters for a connection) - ------- Comments? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiQ768ACgkQE5f5cImnZrsHHgCZAQtg8K4rnDQwVxhtz+4J9zHJ zrUAnROm7aAOv3Y8Zlwy0xP4VotqG6rf =87hd -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 30 15:57:08 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E15F73A68B6; Wed, 30 Jul 2008 15:57:08 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 496DD3A69EA for ; Wed, 30 Jul 2008 15:57:08 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXQBA1jKHVHE for ; Wed, 30 Jul 2008 15:57:07 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id 63F7F3A68E6 for ; Wed, 30 Jul 2008 15:57:07 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so222985rvf.49 for ; Wed, 30 Jul 2008 15:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=xIzCTNTCudVrzSYL10CC1hOOs4BWMjtq/7LCjM68BJM=; b=NFmRMYVJXFAW8Nk40o8AnVD2uiILA9JoLDHIVTCyyznlE7/oGRKA0/jkx9bFjiFI4u aa4YhLBL7iuxaLOZnSNLZl3yX0G6ErBGs2Q5W9EoUbxSMMaWf6fPzqZ0h+LP7mSNFAx3 MFpDGh6uo8m60wqeBP4PU8s+PpYij8knBSkSI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=Xk+rsCa6HmmscCZLflq8BG/50LFKrMkipE8ujY9CR7kQKF/TEZkRvSdYTHg0SCy4H0 aewwaWYarUMc96BsI46QQXaqsJA0F+dcGYNMkq2+v0cn7lLVqF+9jbnM2IRbOO6DS4zv QK46iGGM8Yuh15z1g3MYwhvSPvy9WGx/ztYXQ= Received: by 10.140.166.21 with SMTP id o21mr4880610rve.254.1217458642597; Wed, 30 Jul 2008 15:57:22 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Wed, 30 Jul 2008 15:57:22 -0700 (PDT) Message-ID: <396556a20807301557q608ff91er95e46fa8e6167f6c@mail.gmail.com> Date: Wed, 30 Jul 2008 15:57:22 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <4890EFB0.5020301@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <4890EFB0.5020301@isi.edu> X-Google-Sender-Auth: 657093e32a7da73b Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: header format and alignment X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, Jul 30, 2008 at 3:48 PM, Joe Touch wrote: > The consensus appears to be emerging that we retain a simple, > deterministic header format, and leave alignment issues to implementations: I thought that KeyID was a clearer name, but either way is fine. Putting it at the front like this definitely has my vote. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 30 15:58:53 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82AC93A6A17; Wed, 30 Jul 2008 15:58:53 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32D823A69D1 for ; Wed, 30 Jul 2008 15:58: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZF7FsljiYHmX for ; Wed, 30 Jul 2008 15:58:51 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 62DE83A6893 for ; Wed, 30 Jul 2008 15:58:51 -0700 (PDT) Received: from [128.9.176.37] (c1-vpn7.isi.edu [128.9.176.37]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6UMweCZ015830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Jul 2008 15:58:44 -0700 (PDT) Message-ID: <4890F1FE.6060900@isi.edu> Date: Wed, 30 Jul 2008 15:58:06 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: tcpm@ietf.org X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [tcpm] tcp-auth-opt issue: reserved keyID value X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ran suggested that some implementations would benefit from reserving a keyID as invalid (e.g., keyID 0): This assists the efficiency of some implementations. This also adds an additional requirement (e.g., keyID 0 MUST not be used) which must be validated during conformance testing. Comments on additional pros and cons would be useful. Examples of how this might impact implementation efficiency would be particularly useful (esp. if not encumbered) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiQ8f4ACgkQE5f5cImnZrtvnACg75vUgczimebjOuY7J/olqhIf ZwIAoM70+Bc455P+VxQIOjwP5L2lEGVJ =znTL -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 30 16:00:34 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E016C3A68A0; Wed, 30 Jul 2008 16:00:34 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 296BD3A6893 for ; Wed, 30 Jul 2008 16:00:33 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOHkwuMxlmiO for ; Wed, 30 Jul 2008 16:00:32 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6F9223A67F2 for ; Wed, 30 Jul 2008 16:00:32 -0700 (PDT) Received: from [128.9.176.37] (c1-vpn7.isi.edu [128.9.176.37]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6UN0Z3F016558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Jul 2008 16:00:38 -0700 (PDT) Message-ID: <4890F270.8000902@isi.edu> Date: Wed, 30 Jul 2008 16:00:00 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: tcpm@ietf.org X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [tcpm] tcp-auth-opt issue: keyID randomness X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As per Ran's request, should the keyID be selected at random to enable early discard algorithms, e.g., to reduce the impact of an attacker who would need to guess a valid keyID value? I discussed this issue with Ran, and suggested that all crypto properties should be contained in the MAC field; such a field might include a 'hard to guess' arbitrary fixed part and a computed (e.g., HMAC) part, to enable efficient 'triage' of randomly-generated DOS packets. Overall, this suggests that the document could note that the keyID is NOT intended for protection, and any valid values may be used at any time. Comments (esp. from Ran, who raised the issue)? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiQ8nAACgkQE5f5cImnZrtg9wCfSqbFW6AdQ7v1oY+9PcqyJ9MM 0RsAoJe6y2jcRbFGDuNItr1wLtRsyULj =sjrC -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 30 16:10:05 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADF003A6978; Wed, 30 Jul 2008 16:10:05 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3E4F3A67AC for ; Wed, 30 Jul 2008 16:10:04 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EikMemtEswns for ; Wed, 30 Jul 2008 16:10:03 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id BA4293A6978 for ; Wed, 30 Jul 2008 16:10:03 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so227349rvf.49 for ; Wed, 30 Jul 2008 16:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=5dadFRnnEXo4a91ku1I38dFtq7onaIYdMj6JRWpJtUw=; b=TZokf/NKSiu6DnM5+e2eymE4U07uzsEsspJ6ey1bTBb1Kf+/iCREJ4+2ITjM0UeLnm V+36Hv/Va6l+eULcLbhgAErRxIDBtXvvrdk3iv/AwLYOcfUgCH8nJocRmxvmVpTcpUxt OcEz9Ycbh2emRky3BQsYz27Sl8z0ROjSHtZD4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=EZ1ecA1DuLfO+jIJG1i5LBNvy6LP/P77I+JL6dK9AXa0Em5qOvx28hrLvyfZaO2JpR ou4RVJo7pNy/z+mrlLcZuC219F1nsR0jXVsGVSZgZ0YXa6KcfgvX5CjVuIPPmeT/ptRq OvQZ/N0lGZNos2oHiTkTgxAS4lxrknA997E38= Received: by 10.141.142.15 with SMTP id u15mr4911639rvn.51.1217459419601; Wed, 30 Jul 2008 16:10:19 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Wed, 30 Jul 2008 16:10:19 -0700 (PDT) Message-ID: <396556a20807301610g35e77244wc4f6a24576b56ea0@mail.gmail.com> Date: Wed, 30 Jul 2008 16:10:19 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <4890E9AE.3000607@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <20080728164013.422D14B9600@kilo.rtfm.com> <20080730213253.B347F4D52E1@kilo.rtfm.com> <4890E9AE.3000607@isi.edu> X-Google-Sender-Auth: e83daff6be10c75d Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: replay protection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, Jul 30, 2008 at 3:22 PM, Joe Touch wrote: > 1. assume the key management system (KMS) will rollover the keys every > 2^31 bytes > > Eric noted this is weak, since we cannot rely on the KMS > to act on this without other info. Let's presume this > is unacceptable to the WG and move on... I don't really like this solution, but I don't think it's too bad. Here's what my test impl's currently do: Each direction has a TX key and two valid RX keys configured. From the point of view of a sending application, which keeps track of the number of bytes sent: If I'm just about to cross a 2**31 bytes boundary, install the next TX key. This means that retransmissions of some bytes with seq numbers less than the boundary get the new key, but that's not a huge problem. On the receiving side (for a given half-connection): From the current number of bytes received (n), ensure that keys for n - 2**30 and n + 2**30 are installed as valid RX keys. This ends up meaning that RX keys are rotated ever 2**31 bytes with a 2**30 byte phase. This is fine so long as the window is < 2**31 bytes (which is defined by the window scaling spec at the moment) > Given that algorithm, every ESN increment would trash data in transit > from A-B. Is there an algorithm that does not do this? This seems an odd ESN to me: The ESN is just a 64-bit sequence number. The SEQ field in the TCP header is just the lower 32-bits of this counter. Thus, for the half-connection from A to B, A knows the ESN exactly for every packet. For a packet recved by B, it guesses the ESN based on the closest value to it's last understanding. An example for B: At the beginning of the connection, B knows the ESN for the A->B half connection exactly: top 32-bits are 0, bottom 32-bits from the handshake. For each packet recved it gets the low 32-bits of the ESN, now assume that that the ESN is the closest of the 2**32 possible ESN's to the previous value of the ECN. Update the previous value with this new guess. This is very easy code. Any packets which are reordered > 2**32 sequence bytes will be misclassified and dropped, but 2**32 sequence bytes is a long way. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 30 16:10:34 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F28993A69FD; Wed, 30 Jul 2008 16:10:33 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3CA33A69FD for ; Wed, 30 Jul 2008 16:10:31 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbEIDnqvDguW for ; Wed, 30 Jul 2008 16:10:31 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 2653A3A6875 for ; Wed, 30 Jul 2008 16:10:31 -0700 (PDT) Received: from [128.9.176.37] (c1-vpn7.isi.edu [128.9.176.37]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6UNAPrG020623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Jul 2008 16:10:28 -0700 (PDT) Message-ID: <4890F4BE.6060302@isi.edu> Date: Wed, 30 Jul 2008 16:09:50 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: tcpm@ietf.org X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Langley raised the issue of support for NATs. The TSAD is indexed by the socket pair of the incoming/outgoing packet (addr/port pair). There is no provision for a separate key identifier that would be unique across all connections. As a result, the KMS must populate the TSAD with the appropriate connection information - it must know the source/dest used at both endpoints, even if they differ. (I should have indicated this in some parts of other posts, FWIW) Suppose they do differ; the KMS could then put both sides' views of the src/dst info on each side's TSAD: src/dst addr/port as sent src/dst addr/port as rec'd The TSAD would be indexed by the "as sent" info, but the MAC would be calculated using the "as rec'd" info. Should the document: a) require the socket pair info always be included in the MAC, i.e., be protected b) allow a TSAD entry to indicate that the socket pair is excluded from the MAC? Finally, does (b) help, given the current keying requirements? Comments? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiQ9L4ACgkQE5f5cImnZruvmwCglVgXBbN9hSgiuoa1p/r+1FGP 0lQAn0FBL8te0c5UD6eK+q/BwDtcQbAG =kusE -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 30 16:13:35 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 512F23A6A18; Wed, 30 Jul 2008 16:13:35 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 434D83A69EE for ; Wed, 30 Jul 2008 16:13:34 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkZgNEyEcmoY for ; Wed, 30 Jul 2008 16:13:33 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 84B423A67AC for ; Wed, 30 Jul 2008 16:13:33 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so228524rvf.49 for ; Wed, 30 Jul 2008 16:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=HjA7VmvwIefAW63vaRI+e9tMqUm+cD00n4P+d0S73do=; b=M4R/7IojJbsd6W8EVHj3i30Pgz1/bpFF3LdW8HBfh9WD7wrnJg6tkRpIaQMcIGFLlc BkPMEML9lOZhD1uRdL/PBRCTtmi33y8QQJBycWaA4lfD0yDNZK4lEtjllXnmvr3x+kng +YNRWWt06+9d6wpTfSIJBBsTEmW4YE5kmYYMo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=Wbs6sjqoEmIu3eE5zpg4bgfzPKvW5v5zqZMIPUjE79tUh3DC3C8ZteMVawsg1i7YLb zUvf4EaQPNBecsAO5TFlq8pVXjBzsvePsA6g+aQ8p+W9B729Y7MRjIt1KjiQT39QN4sC ufXWW3qAA4oXnLrTQoL9gcH3NmAJPIm8sa3ek= Received: by 10.140.201.15 with SMTP id y15mr4905765rvf.145.1217459629542; Wed, 30 Jul 2008 16:13:49 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Wed, 30 Jul 2008 16:13:49 -0700 (PDT) Message-ID: <396556a20807301613g11847764u29f672bb09338039@mail.gmail.com> Date: Wed, 30 Jul 2008 16:13:49 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <4890F1FE.6060900@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <4890F1FE.6060900@isi.edu> X-Google-Sender-Auth: 6fc8b83aec10a9fe Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: reserved keyID value X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, Jul 30, 2008 at 3:58 PM, Joe Touch wrote: > Comments on additional pros and cons would be useful. Examples of how > this might impact implementation efficiency would be particularly useful > (esp. if not encumbered) I can only say that I found no problems handling a KeyID of 0. I'd be interested to know what problems other suspect their might be with it. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 30 16:18:38 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CE5A3A67E5; Wed, 30 Jul 2008 16:18:38 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A4493A68A1 for ; Wed, 30 Jul 2008 16:18:37 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lS-tRblx0L1 for ; Wed, 30 Jul 2008 16:18:36 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 104913A67AA for ; Wed, 30 Jul 2008 16:18:36 -0700 (PDT) Received: from [128.9.176.37] (c1-vpn7.isi.edu [128.9.176.37]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6UNIPTi023868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Jul 2008 16:18:28 -0700 (PDT) Message-ID: <4890F69E.9060206@isi.edu> Date: Wed, 30 Jul 2008 16:17:50 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <20080728164013.422D14B9600@kilo.rtfm.com> <20080730213253.B347F4D52E1@kilo.rtfm.com> <4890E9AE.3000607@isi.edu> <396556a20807301610g35e77244wc4f6a24576b56ea0@mail.gmail.com> In-Reply-To: <396556a20807301610g35e77244wc4f6a24576b56ea0@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: replay protection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Langley wrote: ... | The ESN is just a 64-bit sequence number. The SEQ field in the TCP | header is just the lower 32-bits of this counter. Thus, for the | half-connection from A to B, A knows the ESN exactly for every packet. | For a packet recved by B, it guesses the ESN based on the closest | value to it's last understanding. An example for B: | | At the beginning of the connection, B knows the ESN for the A->B half | connection exactly: top 32-bits are 0, bottom 32-bits from the | handshake. | For each packet recved it gets the low 32-bits of the ESN, now assume | that that the ESN is the closest of the 2**32 possible ESN's to the | previous value of the ECN. Can you explain the algorithm for "closest"? | Update the previous value with this new guess. | | This is very easy code. | | Any packets which are reordered > 2**32 sequence bytes will be | misclassified and dropped, but 2**32 sequence bytes is a long way. If you update the ESN on the first packet whose Seqno causes you to determine a rollover, won't any packets that are reordered around it be dropped? i.e.: packets with higher seqnos that arrive earlier cause the ESN to be updated earlier; all subsequent packets with the pre-increment ESN would be droppped -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiQ9p4ACgkQE5f5cImnZruJuQCgieqH6F4onLrTZeM1876Leq5Z sYwAoK3LVtQ/Ow3uiJ9Ntl5JKH3JQ1Hk =hP94 -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 30 16:20:52 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9C793A68A1; Wed, 30 Jul 2008 16:20:52 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96463A67E5 for ; Wed, 30 Jul 2008 16:20:50 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LOYj3zoRLNm for ; Wed, 30 Jul 2008 16:20:50 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 230083A67AC for ; Wed, 30 Jul 2008 16:20:50 -0700 (PDT) Received: from [128.9.176.37] (c1-vpn7.isi.edu [128.9.176.37]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6UNKmwW024807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Jul 2008 16:20:51 -0700 (PDT) Message-ID: <4890F72D.6050903@isi.edu> Date: Wed, 30 Jul 2008 16:20:13 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <4890F1FE.6060900@isi.edu> <396556a20807301613g11847764u29f672bb09338039@mail.gmail.com> In-Reply-To: <396556a20807301613g11847764u29f672bb09338039@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: reserved keyID value X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Langley wrote: | On Wed, Jul 30, 2008 at 3:58 PM, Joe Touch wrote: |> Comments on additional pros and cons would be useful. Examples of how |> this might impact implementation efficiency would be particularly useful |> (esp. if not encumbered) | | I can only say that I found no problems handling a KeyID of 0. I'd be | interested to know what problems other suspect their might be with it. FWIW, this was not noted as a problem; the issue was that having a reserved value could make an implementation much more efficient. I would like to hear some corroboration of this utility, preferably with a public demonstration of its value, since it otherwise adds an arbitrary rule to the mechanism. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiQ9y0ACgkQE5f5cImnZruKXwCfYnsGH7v91PXiWi47eY/+OEKB mmYAoNlmlb7RQ8pxeiO1wYb9lUVAeshR =3KCX -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 30 16:22:33 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79DFA3A6A46; Wed, 30 Jul 2008 16:22:33 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5163A69C1 for ; Wed, 30 Jul 2008 16:22:32 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N53eabLElzwO for ; Wed, 30 Jul 2008 16:22:32 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 077453A68A1 for ; Wed, 30 Jul 2008 16:22:32 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so231483rvf.49 for ; Wed, 30 Jul 2008 16:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=O6RnZPWUHH49l9kt4eHIoTtCG+rNm9NAGFV44KaJhu0=; b=CWnS5OmQc9yA0BdefYyKe/Gv8slNzqpUxu9HpmLojDfKug/L/A1E+2QLd1yTBL8xIY ZreVd2Q8obCyhasZNYm1UEwVFgeMCutpjW4/N2O8UKrpFtlabwIGQGPJPhXGy7MvhPOP qg3UPhjimu+5t+sSd5Y18BCKCj1nHE0euPx5M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=fObkvPG/XG6pRxqmzB5DXXpKBQFQopRHoLZaDtcrYJvU0z5tlefd5uEh5mz6+AqAdd QRhjS8lPHndzgCaHqGAqak+jKUhuL88VavT7WusiYKae1Xf+RbbpQgd9It/JO6lPaopF T6y31UzaMdKuBXPr/OmNfpG0SJamLAVutfpPk= Received: by 10.141.206.13 with SMTP id i13mr4912383rvq.100.1217460167934; Wed, 30 Jul 2008 16:22:47 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Wed, 30 Jul 2008 16:22:47 -0700 (PDT) Message-ID: <396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com> Date: Wed, 30 Jul 2008 16:22:47 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <4890F4BE.6060302@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <4890F4BE.6060302@isi.edu> X-Google-Sender-Auth: c1208b4fd5acf988 Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, Jul 30, 2008 at 4:09 PM, Joe Touch wrote: > Should the document: > > a) require the socket pair info always be included in the MAC, i.e., be > protected > > b) allow a TSAD entry to indicate that the socket pair is excluded from > the MAC? > > Finally, does (b) help, given the current keying requirements? My assumption was that the TSAD could return the same keyset for all addresses and source ports going to a given destination/port pair. As an example, a listening socket could be configured such that one could only connect to it if one knew a key. (Standard proviso's here: the AO key itself should be a time rotating, secure derived key from the master secret). If one didn't have the key, not even a SYNACK would be sent in reply. Once a connection has been established, then the keys for that connection's 4-tuple can change independent of the wildcard keys. If that's a use case that the spec wishes to support, then having an option to exclude the pseudo-header and TCP port numbers from MAC protection would allow these connections to traverse NATs. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 30 16:36:22 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2D813A6875; Wed, 30 Jul 2008 16:36:22 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4C13A6875 for ; Wed, 30 Jul 2008 16:36: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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9waz0Mk+Edyn for ; Wed, 30 Jul 2008 16:36:20 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id 4EBDC3A67E5 for ; Wed, 30 Jul 2008 16:36:20 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so236206rvf.49 for ; Wed, 30 Jul 2008 16:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=1Yx3dEpPzM9uebrlvoVSppEWDviMdXxzb6aQRvOr1IM=; b=J1eLe/vZDorpNSDXYGJfs7kskAJMEZORnZSAwBeMd6U/GaBar/jxpQJ6td4ss0IkbK GM2JFG4sTaDmi2xIy6VoumKTjyw9jZI+x6BU/f9iwWtw0jw2BzNSdvuGX5jZdG6fuMMy cL4JXJKBU9v7xgKq7z4KDD7x/AGXzdtKUUGxQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=r2xDXzVBSV/9hDzHbl2XCPTpdYZuts93fmBYIEaP8ToDSHfJlqpSjiXp1zo/kFhlDv BbGup/2kJy9rclofc1Iv/AjZq1D5CIeI5jdhS8DlD0g/7uIOyxWeLRir/rsGH02NNSH2 Zlvc6TgytWe/2Kn2DeoX5mBjQA6bWFya7R+4A= Received: by 10.140.202.21 with SMTP id z21mr4923840rvf.81.1217460996571; Wed, 30 Jul 2008 16:36:36 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Wed, 30 Jul 2008 16:36:36 -0700 (PDT) Message-ID: <396556a20807301636m31141ec0t2ba89b991c3cd40e@mail.gmail.com> Date: Wed, 30 Jul 2008 16:36:36 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <4890F69E.9060206@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <20080728164013.422D14B9600@kilo.rtfm.com> <20080730213253.B347F4D52E1@kilo.rtfm.com> <4890E9AE.3000607@isi.edu> <396556a20807301610g35e77244wc4f6a24576b56ea0@mail.gmail.com> <4890F69E.9060206@isi.edu> X-Google-Sender-Auth: 81a48f71b570cd8f Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: replay protection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, Jul 30, 2008 at 4:17 PM, Joe Touch wrote: > Can you explain the algorithm for "closest"? Sure, let the last 'known' value for the ESN be a uint64_t called last_esn and the current SEQ be a uint32_t called current. uint64_t last_top32bits = last_esn >> 32; uint64_t possibility_1 = (last_top32bits - 1) << 32 | current; uint64_t possibility_2 = last_top32bits << 32 | current; uint64_t possibility_3 = (last_top32bits + 1) << 32 | current; uint64_t delta_1 = distance(possibility_1, last_esn); uint64_t delta_2 = distance(possibility_2, last_esn); uint64_t delta_3 = distance(possibility_3, last_esn); uint64_t new_esn = min(delta_1, delta_2, delta_3); That's written to try and be clear, rather than actual code that I would write. The idea is that, when we get a seq number, we know that the sending side had a definite 64-bit ESN in mind when they sent it. We know the bottom 32-bits of this, so there are 2**32 possible ESNs (the set of 64-bit numbers with those 32 bits in the lower half). We pick the one that is closest to the last known value. If our last known value was 0, and we get 1, we assume that the ESN is one. If the last ESN was 2**32 - 1, and we get 1, we assume that the ESN is 2**32 + 1. If the last ESN was 2**32 + 1, and we get 2**32 - 5 (packet reordering), we assume that the ESN is 2**32 - 5, because it's closer than assuming that nearly 2**32 bytes went by, unnoticed. I hope that's clear. I'll write real code if I still being inarticulate. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 30 16:41:32 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 361FB3A6A46; Wed, 30 Jul 2008 16:41:32 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A3573A6A46 for ; Wed, 30 Jul 2008 16:41:31 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NI97vD8e82TP for ; Wed, 30 Jul 2008 16:41:30 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 077453A69FD for ; Wed, 30 Jul 2008 16:41:30 -0700 (PDT) Received: from [128.9.176.37] (c1-vpn7.isi.edu [128.9.176.37]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6UNex8g003062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Jul 2008 16:41:02 -0700 (PDT) Message-ID: <4890FBE8.1020203@isi.edu> Date: Wed, 30 Jul 2008 16:40:24 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <4890F4BE.6060302@isi.edu> <396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com> In-Reply-To: <396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Langley wrote: | On Wed, Jul 30, 2008 at 4:09 PM, Joe Touch wrote: |> Should the document: |> |> a) require the socket pair info always be included in the MAC, i.e., be |> protected |> |> b) allow a TSAD entry to indicate that the socket pair is excluded from |> the MAC? |> |> Finally, does (b) help, given the current keying requirements? | | My assumption was that the TSAD could return the same keyset for all | addresses and source ports going to a given destination/port pair. As | an example, a listening socket could be configured such that one could | only connect to it if one knew a key. (Standard proviso's here: the AO | key itself should be a time rotating, secure derived key from the | master secret). If one didn't have the key, not even a SYNACK would be | sent in reply. Once a connection has been established, then the keys | for that connection's 4-tuple can change independent of the wildcard | keys. | | If that's a use case that the spec wishes to support, then having an | option to exclude the pseudo-header and TCP port numbers from MAC | protection would allow these connections to traverse NATs. The current TSAD supports only a wildcard source port, which is instantiated for the first connection received that matches. It expects that the KMS installs additional keys as needed. The above appears to require that the KMS deploy the same key for all potentially overlapping NAT'd connections. This adds a requirement to the KMS, but suggests that the pseudoheader is included or excluded for all connections to a host from a given IP address. Is that what is intended, or can you clarify? If that is what is intended, how can the KMS enforce this? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiQ++gACgkQE5f5cImnZrseZACfSvxBHZt/PXSWLlvL7n06N77n d7gAoO7h9NByaqSzUKewHlXV6io7OsaL =dov+ -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 30 17:16:06 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA4DC3A6B5A; Wed, 30 Jul 2008 17:16:05 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB8263A6B42 for ; Wed, 30 Jul 2008 17:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.484 X-Spam-Level: X-Spam-Status: No, score=-0.484 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjuO0+JkEE2n for ; Wed, 30 Jul 2008 17:16:03 -0700 (PDT) Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 9A97F3A69D7 for ; Wed, 30 Jul 2008 17:16:03 -0700 (PDT) Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 6511C4D5E34; Wed, 30 Jul 2008 17:16:09 -0700 (PDT) Date: Wed, 30 Jul 2008 17:16:09 -0700 From: Eric Rescorla To: Joe Touch In-Reply-To: <4890E9AE.3000607@isi.edu> References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <20080728164013.422D14B9600@kilo.rtfm.com> <20080730213253.B347F4D52E1@kilo.rtfm.com> <4890E9AE.3000607@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080731001609.6511C4D5E34@kilo.rtfm.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: replay protection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Wed, 30 Jul 2008 15:22:38 -0700, Joe Touch wrote: > 2. include an extended sequence number (ESN) inside TCP-AO > ESN starts at 0 > increment ESN when the TCP sequence number rolls over* > passed ESN to the encryption algorithm as part of the MAC'd data > > 3. have TCP-AO ask the KMS to add a new key for the connection when the > sequence number rolls over (actually just before, e.g., 2^31 rolls over) > > - ------------------------------------ > > #2 is internal to TCP-AO, i.e., it requires no 'callback' to the KMS > There appears to be a synchronization issue here - exactly when is the > ESN incremented? Suppose endpoints A and B; there are two ESNs - ESN_ab > and ESN_ba: > A increments ESN_ab when A receives an ack from B w/seqno > 2^31 > B increments ESN_ab when B sends an ack to A w/seqno > 2^31 > B increments ESN_ba when B receives an ack from A w/seqno > 2^31 > A increments ESN_ba when A sends an ack to B w/seqno > 2^31 > i.e., the ESN is incremented when the reverse channel succeeds; we can't > use the forward channel, since one side would change the ESN in ways the > other would never notice (it wouldn't decode it) > > Given that algorithm, every ESN increment would trash data in transit > from A-B. Is there an algorithm that does not do this? I'm sorry, but I don't understand the issue. The ESN dosn't have to move monotonically forward, any more than the packet sequence numbers do. You assign bytes sequence numbers in a 64-bit rather than 32-bit space and only transmit the low-order 32 bits in the packet. By way of illustration, let's work in 16-bit space with an 8-bit sequence number in the packet. 1. A transmits bytes 0x00f0 - 0x0101 (packet sn 0xf0) [lost] 2. A transmits bytes 0x0101 - 0x0111 (packet sn 0x01) 3. A retransmits bytes 0x00f0 - 0x0101 (packet sn 0xf0) > #3 allows packets to be reordered without loss during key rollover, and > is not susceptible to the burst-losses of #2 > > Note that #2 should not 'insert a key into the TSAD' - that interface > should be under the exclusive control of the KMS - at which point asking > the KMS to keep that info (or bury it in the TSAD where the KMS can > refer to it) seems sufficient. Well, again I think this whole notion of the TSAD is an abstraction which is confusing rather than clarifying. Let's try walking through the situation we actually have to deal with right now. 1. The user configures a single static key that applies to all connections between some set of host/port quartets 2. When a connection is instantiated, that single static key has to somehow get diversified into a per-connection key that gets attached to that connection. 3. If the user configures a new key, that needs to get noticed and a new set of diversified per-connection keys needs to be attached. Thinking of this as a database with various portions of the system having read/write access seems to me only to confuse the issue. I suggest we discuss what bits on the wire we expect to have and then we can discuss what model is best to describe it. 1. The user establishes a key, which we'll call key 9 with value K_9 and sets it for all connections between 10.0.0.1:* (remote) and 10.0.10.1:555 (local). 2. Host 10.0.0.1:911 sends a SYN to 10.0.10.1:555 with ISN X. This packet is protected with a key computed as: k_i = PRF(K_9, 10.0.0.1, 911, 10.0.10.1, 555, X, 0). This packet has key-id 9. 3. Host 10.0.10.1:555 sends a SYN/ACK to 10.0.0.1:911 with ISN Y. This packet is protected with a key computed as: k_j = PRF(K_9, 10.0.10.1, 555, 10.0.0.1, 911, Y, X). This packet has key-id 9. 4. Host 10.0.0.1:911 sends an ACK to 10.0.10.1:555 with ISN X. This packet is protected with a key computed as: k_k = PRF(K_9, 10.0.0.1, 911, 10.0.10.1, 555, X, Y). This packet has key-id 9. Future packets from 10.0.0.1:911 -> 10.0.10.1:555 are protected with k_k. Packets in the reverse direction are protected with k_j. ... 5. Host 10.0.0.1:911 sends an packet to 10.0.10.1:555 with a sequence number of 0xfffffff0 and length 32. This packet is protected with key k_k and bears key-id 9. 6. Host 10.0.0.1:911 sends a packet to 10.0.10.1:555 with a sequence number of 0x00000010 (the successor to packet 5). This packet is protected with a key computed as: k_l = PRF(k_k, 10.0.0.1, 911, 10.0.10.1, 555, X, Y). This packet has key-id 9. 7. The packet sent in 5 is lost and so must be retransmitted. It is protected with key k_k. So, two salient points: 1. When the sequence number is in the region of 0 (more precisely while there are unacked segments on both sides of the region), then the sides must maintain two keys and arrange to use the appropriate one. 2. The same key-id is used in the packet regardless of the which key is being used to protect the traffic. It refers to the static key from which the traffic keys were diversified. We could tell a similar story about ESN handling, except you would use the same traffic keys, but move the high order word up and down appropriately. Do you disagree that this is the right thing to have in the packets? -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 30 17:18:39 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5CAF3A6B68; Wed, 30 Jul 2008 17:18:39 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CB9F3A6B68 for ; Wed, 30 Jul 2008 17:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.485 X-Spam-Level: X-Spam-Status: No, score=-0.485 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qc2cSyDraT79 for ; Wed, 30 Jul 2008 17:18:37 -0700 (PDT) Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 9DF3B3A6B5A for ; Wed, 30 Jul 2008 17:18:37 -0700 (PDT) Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id D6CF54D5E53; Wed, 30 Jul 2008 17:18:09 -0700 (PDT) Date: Wed, 30 Jul 2008 17:18:09 -0700 From: Eric Rescorla To: Joe Touch In-Reply-To: <4890EE5E.2000400@isi.edu> References: <4890EE5E.2000400@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080731001809.D6CF54D5E53@kilo.rtfm.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: unique connection keys X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Wed, 30 Jul 2008 15:42:38 -0700, Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Eric has raised the point that we should expect the TCP-AO system > (TCP-AO and its required key management system [KMS]) to ensure unique > connection keys. > > draft-01 outlines the information that would be used to provide this > information (i.e., derivative of the ISN, etc.). > > Eric raised concerns about whether this function can reasonably be > external to TCP-AO (e.g., inside the KMS) or inside the KMS, and about > the vagueness of the description. The current document was intended as a > starting point for that discussion, FWIW. > > One observation is that the KMS manages keys for connections - i.e., the > socket pair (addr/port pair) - but has no info on ISNs. It can establish > keys for that socket pair in the TSAD, but cannot generate appropriate > session keys in advance of a connection being established. > > Let's assume that the KMS includes the socket pair in the connection key > when it inserts it into the TSAD (or that this can occur trivially for > wildcard source port entries by re-hashing with the appropriate port > when the first packet instantiates the entry). As a result, the ISNs are > the only missing component to the connection key. > > As was suggested before, use ISNs as follow: > > SYN (without ACK) - use src_ISN from SYN, dst_ISN=0 > all other packets - use src_ISN, dst_ISN from first SYN rec'd > > There are (at least) two ways to achieve this: > > 1) prepend src_ISN, dst_ISN to each incoming packet for MAC calculation > > 2) overwrite the TSAD keys established by the KMS > i.e., on first SYN emitted > key=hash(key, src_ISN) > on SYN-ACK received > key=hash(key, dst_ISN) > > #1 has the advantage that it appears to work for simultaneous open, in > which the SYNs are keyed based on different ISN info in each direction, > but are received properly > > #2 reduces the per-packet cost by the length of two ISNs, by investing > in the hash at connection establishment. However, it appears to prohibit > simultaneous open. Can anyone suggest a solution that supports > simultaneous open? Why does this prohibit simultaneous open? Because you're assuming that there's only one possible key for a given host/port quartet? -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jul 30 23:30:51 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 524653A6A8D; Wed, 30 Jul 2008 23:30:51 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 030B23A6BFE for ; Wed, 30 Jul 2008 23:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.193 X-Spam-Level: X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, J_CHICKENPOX_47=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7Vo0XxZRlzc for ; Wed, 30 Jul 2008 23:30:48 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E6EA43A6A8D for ; Wed, 30 Jul 2008 23:30:48 -0700 (PDT) Received: from [172.16.7.194] ([130.129.65.85]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6V6UOmQ024200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Jul 2008 23:30:26 -0700 (PDT) Message-ID: <48915BDD.1080205@isi.edu> Date: Wed, 30 Jul 2008 23:29:49 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eric Rescorla References: <4890EE5E.2000400@isi.edu> <20080731001809.D6CF54D5E53@kilo.rtfm.com> In-Reply-To: <20080731001809.D6CF54D5E53@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: unique connection keys X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rescorla wrote: | At Wed, 30 Jul 2008 15:42:38 -0700, | Joe Touch wrote: |> -----BEGIN PGP SIGNED MESSAGE----- |> Hash: SHA1 |> |> Eric has raised the point that we should expect the TCP-AO system |> (TCP-AO and its required key management system [KMS]) to ensure unique |> connection keys. |> |> draft-01 outlines the information that would be used to provide this |> information (i.e., derivative of the ISN, etc.). |> |> Eric raised concerns about whether this function can reasonably be |> external to TCP-AO (e.g., inside the KMS) or inside the KMS, and about |> the vagueness of the description. The current document was intended as a |> starting point for that discussion, FWIW. |> |> One observation is that the KMS manages keys for connections - i.e., the |> socket pair (addr/port pair) - but has no info on ISNs. It can establish |> keys for that socket pair in the TSAD, but cannot generate appropriate |> session keys in advance of a connection being established. |> |> Let's assume that the KMS includes the socket pair in the connection key |> when it inserts it into the TSAD (or that this can occur trivially for |> wildcard source port entries by re-hashing with the appropriate port |> when the first packet instantiates the entry). As a result, the ISNs are |> the only missing component to the connection key. |> |> As was suggested before, use ISNs as follow: |> |> SYN (without ACK) - use src_ISN from SYN, dst_ISN=0 |> all other packets - use src_ISN, dst_ISN from first SYN rec'd |> |> There are (at least) two ways to achieve this: |> |> 1) prepend src_ISN, dst_ISN to each incoming packet for MAC calculation |> |> 2) overwrite the TSAD keys established by the KMS |> i.e., on first SYN emitted |> key=hash(key, src_ISN) |> on SYN-ACK received |> key=hash(key, dst_ISN) |> |> #1 has the advantage that it appears to work for simultaneous open, in |> which the SYNs are keyed based on different ISN info in each direction, |> but are received properly |> |> #2 reduces the per-packet cost by the length of two ISNs, by investing |> in the hash at connection establishment. However, it appears to prohibit |> simultaneous open. Can anyone suggest a solution that supports |> simultaneous open? | | Why does this prohibit simultaneous open? Because you're assuming | that there's only one possible key for a given host/port quartet? The difference between #1 and #2 is that #2 overwrites the TSAD entries with the hash. Yes, the issue with simultaneous opens is the need for multiple keys per "host/port quartet" (can we call that a socket pair, as per 793?). We could also keep multiple keys just in case there's a simultaneous open, until at least the SYN-ACK is received on a given side (at which point we can drop the extra keys). E.g.: origkey = as installed by KMS SYNkey = hash(origkey, src_ISN) computed when SYN is sent before an incoming SYN is rec'd (by either side) connkey = hash(origkey, src_ISN, dst_ISN) computed when the ack of the SYN is rec'd or an incoming SYN is ack'd only the connkey can overwrite the origkey in the TSAD. for space reasons, we don't want to keep too many keys around. If we prepend the ISNs to the data, we avoid separate calls to the MAC algorithm during the three-way handshake, but we keep reprocessing the ISNs for each packet sent. So at this point both #1 and #2 could support simultaneous opens. Which method is preferable and why? Comments? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiRW90ACgkQE5f5cImnZrtgqwCgymZFT0TqMxVPOJOmsdD+JoMQ GWAAoJbaASP2CRh2oJYLDRBfa3uKAKny =ypqa -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 31 01:20:11 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB5093A6A30; Thu, 31 Jul 2008 01:20:10 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 196D83A6A46 for ; Thu, 31 Jul 2008 01:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.186 X-Spam-Level: X-Spam-Status: No, score=-0.186 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_47=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wsOzRg4RjPh for ; Thu, 31 Jul 2008 01:20:00 -0700 (PDT) Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 1E9F03A6A30 for ; Thu, 31 Jul 2008 01:20:00 -0700 (PDT) Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 696025026FD; Thu, 31 Jul 2008 01:19:42 -0700 (PDT) Date: Thu, 31 Jul 2008 01:19:41 -0700 From: Eric Rescorla To: Joe Touch In-Reply-To: <48915BDD.1080205@isi.edu> References: <4890EE5E.2000400@isi.edu> <20080731001809.D6CF54D5E53@kilo.rtfm.com> <48915BDD.1080205@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080731081942.696025026FD@kilo.rtfm.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: unique connection keys X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Wed, 30 Jul 2008 23:29:49 -0700, Joe Touch wrote: > Eric Rescorla wrote: > | At Wed, 30 Jul 2008 15:42:38 -0700, > | Joe Touch wrote: > |> -----BEGIN PGP SIGNED MESSAGE----- > |> Hash: SHA1 > |> > |> Eric has raised the point that we should expect the TCP-AO system > |> (TCP-AO and its required key management system [KMS]) to ensure unique > |> connection keys. > |> > |> draft-01 outlines the information that would be used to provide this > |> information (i.e., derivative of the ISN, etc.). > |> > |> Eric raised concerns about whether this function can reasonably be > |> external to TCP-AO (e.g., inside the KMS) or inside the KMS, and about > |> the vagueness of the description. The current document was intended as a > |> starting point for that discussion, FWIW. > |> > |> One observation is that the KMS manages keys for connections - i.e., the > |> socket pair (addr/port pair) - but has no info on ISNs. It can establish > |> keys for that socket pair in the TSAD, but cannot generate appropriate > |> session keys in advance of a connection being established. > |> > |> Let's assume that the KMS includes the socket pair in the connection key > |> when it inserts it into the TSAD (or that this can occur trivially for > |> wildcard source port entries by re-hashing with the appropriate port > |> when the first packet instantiates the entry). As a result, the ISNs are > |> the only missing component to the connection key. > |> > |> As was suggested before, use ISNs as follow: > |> > |> SYN (without ACK) - use src_ISN from SYN, dst_ISN=0 > |> all other packets - use src_ISN, dst_ISN from first SYN rec'd > |> > |> There are (at least) two ways to achieve this: > |> > |> 1) prepend src_ISN, dst_ISN to each incoming packet for MAC calculation > |> > |> 2) overwrite the TSAD keys established by the KMS > |> i.e., on first SYN emitted > |> key=hash(key, src_ISN) > |> on SYN-ACK received > |> key=hash(key, dst_ISN) > |> > |> #1 has the advantage that it appears to work for simultaneous open, in > |> which the SYNs are keyed based on different ISN info in each direction, > |> but are received properly > |> > |> #2 reduces the per-packet cost by the length of two ISNs, by investing > |> in the hash at connection establishment. However, it appears to prohibit > |> simultaneous open. Can anyone suggest a solution that supports > |> simultaneous open? > | > | Why does this prohibit simultaneous open? Because you're assuming > | that there's only one possible key for a given host/port quartet? > > The difference between #1 and #2 is that #2 overwrites the TSAD entries > with the hash. Yes, the issue with simultaneous opens is the need for > multiple keys per "host/port quartet" (can we call that a socket pair, > as per 793?). > > > We could also keep multiple keys just in case there's a simultaneous > open, until at least the SYN-ACK is received on a given side (at which > point we can drop the extra keys). > > E.g.: > origkey = as installed by KMS > SYNkey = hash(origkey, src_ISN) computed when SYN is sent > before an incoming SYN is rec'd (by either side) > connkey = hash(origkey, src_ISN, dst_ISN) > computed when the ack of the SYN is rec'd or > an incoming SYN is ack'd > > only the connkey can overwrite the origkey in the TSAD. for space > reasons, we don't want to keep too many keys around. This seems like unnecessary concreteness about the implementation. The question isn't what's stored in the database but rather what keys are used to protect the packets. Given that at least in the manual key management mode the "origkey" is going to sit around for years, it's a little weird to talk about it being "replaced". > If we prepend the ISNs to the data, we avoid separate calls to the MAC > algorithm during the three-way handshake, but we keep reprocessing the > ISNs for each packet sent. The performance advantage of either choice seem to be rather slight. > So at this point both #1 and #2 could support simultaneous opens. Which > method is preferable and why? As I indicated in my previous comments, you could probably cryptographically tolerate only one master MAC key and just use differentiating prefixes rather than separate keys. Convention is to use separate keys, though, in my experience, so this probably requires less analysis. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 31 01:21:29 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E882D3A6A2B; Thu, 31 Jul 2008 01:21:28 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 031703A6A2B for ; Thu, 31 Jul 2008 01:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 391EBsUJ1gek for ; Thu, 31 Jul 2008 01:21:26 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 0F5A73A68DB for ; Thu, 31 Jul 2008 01:21:26 -0700 (PDT) Received: from [130.129.20.69] ([130.129.20.69]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6V8Kmcu003156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Jul 2008 01:20:57 -0700 (PDT) Message-ID: <489175BD.6040201@isi.edu> Date: Thu, 31 Jul 2008 01:20:13 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eric Rescorla References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488D6968.9010102@isi.edu> <20080728131254.3DD764B88F7@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <20080728164013.422D14B9600@kilo.rtfm.com> <20080730213253.B347F4D52E1@kilo.rtfm.com> <4890E9AE.3000607@isi.edu> <20080731001609.6511C4D5E34@kilo.rtfm.com> In-Reply-To: <20080731001609.6511C4D5E34@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: replay protection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Regarding the ESN, My goal was to allow TCP-AO code to be isolated to handling packets just before exit/entrance to IP. That suggests that all TCP-AO state should be kept to the TSAD, and not extend the core TCP code unless absolutely necessary. Let's assume we compute the ESN compute the ESN for each packet as Adam described, using the 'nearby' algorithm The question becomes when to actually increment the ESN? Eric Rescorla wrote: | I'm sorry, but I don't understand the issue. The ESN dosn't have to | move monotonically forward, any more than the packet sequence numbers | do. You assign bytes sequence numbers in a 64-bit rather than 32-bit | space and only transmit the low-order 32 bits in the packet. This would require modifying the core of TCP to use 64-bit sequence numbers throughout. Does the WG want to keep mods out of the core of TCP, or can we assume a 64-bit sequence number space? - ------ A separate question is whether ESN rollover should use the keyID mechanism or not. This is related to Eric's points: | So, two salient points: | 1. When the sequence number is in the region of 0 (more precisely | while there are unacked segments on both sides of the region), | then the sides must maintain two keys and arrange to use | the appropriate one. Eric - can you explain "arrange to use the appropriate one"? | 2. The same key-id is used in the packet regardless of the which | key is being used to protect the traffic. It refers to the | static key from which the traffic keys were diversified. Eric - can you explain where the multiple keys per keyID are determined? i.e., are they recomputed per-packet or kept somewhere? FWIW, I agree with Eric's example on the wire; the issue is the state required at the endpoints required to make it happen. Comments? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiRdb0ACgkQE5f5cImnZrtD0ACgh2FOEbxxfkDJhNnZLDtCima6 Y1AAoKu5WJqoFtYH2eBLJdF5aDEHvk+R =fNzA -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 31 01:30:38 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ADFE3A68C0; Thu, 31 Jul 2008 01:30:38 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5A753A6780 for ; Thu, 31 Jul 2008 01:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, J_CHICKENPOX_47=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUUdnXqRRX7L for ; Thu, 31 Jul 2008 01:30:36 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 0F64E3A68AE for ; Thu, 31 Jul 2008 01:30:36 -0700 (PDT) Received: from [130.129.20.69] ([130.129.20.69]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6V8TqYS006198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Jul 2008 01:30:00 -0700 (PDT) Message-ID: <489177DD.6080902@isi.edu> Date: Thu, 31 Jul 2008 01:29:17 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eric Rescorla References: <4890EE5E.2000400@isi.edu> <20080731001809.D6CF54D5E53@kilo.rtfm.com> <48915BDD.1080205@isi.edu> <20080731081942.696025026FD@kilo.rtfm.com> In-Reply-To: <20080731081942.696025026FD@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: unique connection keys X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rescorla wrote: ... |> The difference between #1 and #2 is that #2 overwrites the TSAD entries |> with the hash. Yes, the issue with simultaneous opens is the need for |> multiple keys per "host/port quartet" (can we call that a socket pair, |> as per 793?). |> |> |> We could also keep multiple keys just in case there's a simultaneous |> open, until at least the SYN-ACK is received on a given side (at which |> point we can drop the extra keys). |> |> E.g.: |> origkey = as installed by KMS |> SYNkey = hash(origkey, src_ISN) computed when SYN is sent |> before an incoming SYN is rec'd (by either side) |> connkey = hash(origkey, src_ISN, dst_ISN) |> computed when the ack of the SYN is rec'd or |> an incoming SYN is ack'd |> |> only the connkey can overwrite the origkey in the TSAD. for space |> reasons, we don't want to keep too many keys around. | | This seems like unnecessary concreteness about the implementation. | The question isn't what's stored in the database but rather what | keys are used to protect the packets. Given that at least in the | manual key management mode the "origkey" is going to sit around | for years, it's a little weird to talk about it being "replaced". There is state in a few different places: KMS keys, which could persist for years in the static case connection keys, which persist only during the connection In the above example, the question is how many keys are kept for a single connection (i.e., is one stored and it overwritten, or are two kept, etc.), or whether they are computed on-the-fly for every packet that goes out. |> If we prepend the ISNs to the data, we avoid separate calls to the MAC |> algorithm during the three-way handshake, but we keep reprocessing the |> ISNs for each packet sent. | | The performance advantage of either choice seem to be rather slight. | |> So at this point both #1 and #2 could support simultaneous opens. Which |> method is preferable and why? | | As I indicated in my previous comments, you could probably | cryptographically tolerate only one master MAC key and just use | differentiating prefixes rather than separate keys. Convention | is to use separate keys, though, in my experience, so this | probably requires less analysis. The differences in the alternatives discussed so far: A- precomputed keys require additional per-connection key storage space B- on-the-fly 1- if ISN is hashed into the key used for a packet, this requires an additional full MAC computation per packet 2- if ISN is prepended to the data, this requires a longer MAC computation which of these is more efficient depends on: - saving computation vs. storage - the length of the connection Overall, if this is encoded into TCP-AO, we need to encode (and fix as static) this choice. We could extend the TSAD API to outsource this issue, but (as Eric noted) this complicates the TSAD API. Question to the WG: - is the WG comfortable selecting and fixing a mechanism for using the ISNs for key uniqueness inside TCP-AO, or would it prefer to push this to the KMS? (my impression is that keeping this inside TCP-AO seems to be preferable, please speak up if otherwise) - which of the above mechanisms is preferable? i.e., A, B1, or B2 Comments? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiRd90ACgkQE5f5cImnZrtwHgCdHF1cUrpIPcW3SzUbj0CxIzqz 08QAoKvbVPfM45a2zXXj6xSjikG3oxU0 =13gk -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 31 01:45:10 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D1323A68A2; Thu, 31 Jul 2008 01:45:10 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA9933A6807 for ; Thu, 31 Jul 2008 01:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.174 X-Spam-Level: X-Spam-Status: No, score=-0.174 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_47=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sa+6fk6YCRhr for ; Thu, 31 Jul 2008 01:45:07 -0700 (PDT) Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 5D4213A6923 for ; Thu, 31 Jul 2008 01:44:42 -0700 (PDT) Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id A1D4A502A92; Thu, 31 Jul 2008 01:44:08 -0700 (PDT) Date: Thu, 31 Jul 2008 01:44:08 -0700 From: Eric Rescorla To: Joe Touch In-Reply-To: <489177DD.6080902@isi.edu> References: <4890EE5E.2000400@isi.edu> <20080731001809.D6CF54D5E53@kilo.rtfm.com> <48915BDD.1080205@isi.edu> <20080731081942.696025026FD@kilo.rtfm.com> <489177DD.6080902@isi.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20080731084408.A1D4A502A92@kilo.rtfm.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: unique connection keys X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At Thu, 31 Jul 2008 01:29:17 -0700, Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Eric Rescorla wrote: > ... > |> The difference between #1 and #2 is that #2 overwrites the TSAD entries > |> with the hash. Yes, the issue with simultaneous opens is the need for > |> multiple keys per "host/port quartet" (can we call that a socket pair, > |> as per 793?). > |> > |> > |> We could also keep multiple keys just in case there's a simultaneous > |> open, until at least the SYN-ACK is received on a given side (at which > |> point we can drop the extra keys). > |> > |> E.g.: > |> origkey = as installed by KMS > |> SYNkey = hash(origkey, src_ISN) computed when SYN is sent > |> before an incoming SYN is rec'd (by either side) > |> connkey = hash(origkey, src_ISN, dst_ISN) > |> computed when the ack of the SYN is rec'd or > |> an incoming SYN is ack'd > |> > |> only the connkey can overwrite the origkey in the TSAD. for space > |> reasons, we don't want to keep too many keys around. > | > | This seems like unnecessary concreteness about the implementation. > | The question isn't what's stored in the database but rather what > | keys are used to protect the packets. Given that at least in the > | manual key management mode the "origkey" is going to sit around > | for years, it's a little weird to talk about it being "replaced". > > There is state in a few different places: > > KMS keys, which could persist for years in the static case > > connection keys, which persist only during the connection > > In the above example, the question is how many keys are kept for a > single connection (i.e., is one stored and it overwritten, or are two > kept, etc.), or whether they are computed on-the-fly for every packet > that goes out. > > |> If we prepend the ISNs to the data, we avoid separate calls to the MAC > |> algorithm during the three-way handshake, but we keep reprocessing the > |> ISNs for each packet sent. > | > | The performance advantage of either choice seem to be rather slight. > | > |> So at this point both #1 and #2 could support simultaneous opens. Which > |> method is preferable and why? > | > | As I indicated in my previous comments, you could probably > | cryptographically tolerate only one master MAC key and just use > | differentiating prefixes rather than separate keys. Convention > | is to use separate keys, though, in my experience, so this > | probably requires less analysis. > > The differences in the alternatives discussed so far: > > A- precomputed keys > require additional per-connection key storage space > > B- on-the-fly > 1- if ISN is hashed into the key used for a packet, > this requires an additional full MAC computation > per packet > > 2- if ISN is prepended to the data, this requires > a longer MAC computation > > which of these is more efficient depends on: > - saving computation vs. storage > - the length of the connection > > Overall, if this is encoded into TCP-AO, we need to encode (and fix as > static) this choice. We could extend the TSAD API to outsource this > issue, but (as Eric noted) this complicates the TSAD API. I must be missing something. Our job is to specify what bits go into the MAC. Why do we have to specify when these computations are done beyond that? It seems like implementations should be allowed to make whatever time/space tradeoffs they feel are most appropriate. In particular, why should we require one of A and B(1), since they produce the same data on the wire? It's worth noting at this point that implementations of HMAC often adopt the time/space tradeoff of precomputing the first round of HMAC computations (to digest the keys) and using that instead of the key. If you were working with prepending ISNs, you might also include the ISNs in that state. When we talk about key storage, I would hope we aren't precluding that sort of optimization. -Ekr _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 31 02:04:17 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABC7A3A6B11; Thu, 31 Jul 2008 02:04:17 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82AC13A6B0D for ; Thu, 31 Jul 2008 02:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3a0CTnjbatd for ; Thu, 31 Jul 2008 02:04:15 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id A3B6F3A6B08 for ; Thu, 31 Jul 2008 02:04:15 -0700 (PDT) Received: from [130.129.20.69] ([130.129.20.69]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6V944oY020541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Jul 2008 02:04:07 -0700 (PDT) Message-ID: <48917FD9.9000506@isi.edu> Date: Thu, 31 Jul 2008 02:03:21 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eric Rescorla References: <4890EE5E.2000400@isi.edu> <20080731001809.D6CF54D5E53@kilo.rtfm.com> <48915BDD.1080205@isi.edu> <20080731081942.696025026FD@kilo.rtfm.com> <489177DD.6080902@isi.edu> <20080731084408.A1D4A502A92@kilo.rtfm.com> In-Reply-To: <20080731084408.A1D4A502A92@kilo.rtfm.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: unique connection keys X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rescorla wrote: ... |> The differences in the alternatives discussed so far: |> |> A- precomputed keys |> require additional per-connection key storage space |> |> B- on-the-fly |> 1- if ISN is hashed into the key used for a packet, |> this requires an additional full MAC computation |> per packet |> |> 2- if ISN is prepended to the data, this requires |> a longer MAC computation ... | I must be missing something. Our job is to specify what bits go | into the MAC. Why do we have to specify when these computations | are done beyond that? It seems like implementations should be | allowed to make whatever time/space tradeoffs they feel are | most appropriate. In particular, why should we require one of | A and B(1), since they produce the same data on the wire? Point taken. So then it's between A/B1 and B2. | It's worth noting at this point that implementations of HMAC often | adopt the time/space tradeoff of precomputing the first round of HMAC | computations (to digest the keys) and using that instead of the key. | If you were working with prepending ISNs, you might also include | the ISNs in that state. When we talk about key storage, I would hope we aren't | precluding that sort of optimization. It depends on whether that precomputation is impacted by the use of ISNs in the MAC; that's the only reason there's an A/B1 vs. B2 difference noted above. How we specify the computation may affect whether it can be precomputed or needs storage/recomputation. We can jump up to the level of specifying the computation only (which allows implementation flexibility), but we need to know (AFAICT) the impact on these optimizations and whether we care... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiRfc8ACgkQE5f5cImnZruQXQCgrYHBO1g2LMIWMOpbUlqRD4bJ l8QAnA5UL8U4z16q/tpu5VxMt0hSue1e =tnZ4 -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 31 10:10:14 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9EBC3A6CD4; Thu, 31 Jul 2008 10:10:14 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C15AB3A6915 for ; Thu, 31 Jul 2008 10:10:13 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwGUpgt1N61W for ; Thu, 31 Jul 2008 10:10:12 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by core3.amsl.com (Postfix) with ESMTP id 7AD5C3A6D00 for ; Thu, 31 Jul 2008 10:10:05 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so564943rvf.49 for ; Thu, 31 Jul 2008 10:10:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=wOPoXApTGHuPeiKJFtSjHYuFUa8OzXnaytBcPOa9GE0=; b=UgXq7k5SASo2MMZm2qy+KPr4Q3mck5e/GkCYJRSbcQE69BW5TYUWLQhBkLD62sZcJK VBDBjS8W0rvyst5Tgdhhg/SEeaMrfyy5QboUPd630RFdweUPzQY44It4hfZJ540DJcaO 3FwY70hTqTh/7ikUnAa4k9Mx5d1bnJNdW3i64= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=MyYyOmyoiOFcbw3rWpIigI29eYFq+NhP1DqKAicqMhN1fMD4oWNZs0SjGKgcJXheaG s+RVKD3lIA0D2gxxfzfWCe1O/sGQPu/8aafW5Ix91rRUiuhp9K6p3ZDZ52OwG9b9lfER rn889hrlxHfV6IkDuEh5kbA7ZawOr8QQO0Qts= Received: by 10.141.43.5 with SMTP id v5mr5422435rvj.216.1217524222820; Thu, 31 Jul 2008 10:10:22 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Thu, 31 Jul 2008 10:10:22 -0700 (PDT) Message-ID: <396556a20807311010k78c22981xa0eebd1b46e9f619@mail.gmail.com> Date: Thu, 31 Jul 2008 10:10:22 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <489175BD.6040201@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <20080728042451.C7A174B7AD3@kilo.rtfm.com> <488DD77D.9070608@isi.edu> <20080728144721.AC9184B905A@kilo.rtfm.com> <488DE021.7070307@isi.edu> <20080728164013.422D14B9600@kilo.rtfm.com> <20080730213253.B347F4D52E1@kilo.rtfm.com> <4890E9AE.3000607@isi.edu> <20080731001609.6511C4D5E34@kilo.rtfm.com> <489175BD.6040201@isi.edu> X-Google-Sender-Auth: 143e94cd761a3dad Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: replay protection X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Thu, Jul 31, 2008 at 1:20 AM, Joe Touch wrote: > > My goal was to allow TCP-AO code to be isolated to handling packets just > before exit/entrance to IP. That suggests that all TCP-AO state should > be kept to the TSAD, and not extend the core TCP code unless absolutely > necessary. Speaking for the Linux stack, the current MD5 code filters at the entry to the TCP layer since it needs to be near the options parsing code etc. At that point, we have found a socket and thus have a locked tcp_sock structure. So adding the ESN would involve adding a couple of u32's to the tcp_sock structure (they would store the upper 32-bits of the RX and TX ESNs). > A separate question is whether ESN rollover should use the keyID > mechanism or not. This is related to Eric's points: Personally, my feeling is that it shouldn't. > | So, two salient points: > | 1. When the sequence number is in the region of 0 (more precisely > | while there are unacked segments on both sides of the region), > | then the sides must maintain two keys and arrange to use > | the appropriate one. > > Eric - can you explain "arrange to use the appropriate one"? I believe Eric is discussing the case where the keys change because of a rollover. Since packets may be reordered, a host past to remember both the keys for the previous period and the keys for the current period in case a reordered packet comes in. It's unclear, to me, which key retransmitted packets would use. > | 2. The same key-id is used in the packet regardless of the which > | key is being used to protect the traffic. It refers to the > | static key from which the traffic keys were diversified. > > Eric - can you explain where the multiple keys per keyID are determined? > i.e., are they recomputed per-packet or kept somewhere? It appears that they are computed when a connection becomes ESTABLISHED and rotated once every rollover from then. > > FWIW, I agree with Eric's example on the wire; the issue is the state > required at the endpoints required to make it happen. > > > Comments? I would prefer, for simplicities sake, that the MAC simply include an ESN rather than roll the keys over, but not strongly. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 31 10:50:02 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86213A6D31; Thu, 31 Jul 2008 10:50:01 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 018B23A6CE5 for ; Thu, 31 Jul 2008 10:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.617 X-Spam-Level: X-Spam-Status: No, score=-5.617 tagged_above=-999 required=5 tests=[AWL=0.982, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdBRlI7A8qEp for ; Thu, 31 Jul 2008 10:49:58 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 432E13A6D32 for ; Thu, 31 Jul 2008 10:49:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,287,1215388800"; d="scan'208";a="91662152" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 31 Jul 2008 17:49:58 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6VHnw5U000851 for ; Thu, 31 Jul 2008 10:49:58 -0700 Received: from [10.21.51.198] ([10.21.51.198]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m6VHnvxJ008747 for ; Thu, 31 Jul 2008 17:49:57 GMT Message-ID: <4891FB44.50704@cisco.com> Date: Thu, 31 Jul 2008 10:49:56 -0700 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: tcpm@ietf.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4758; t=1217526598; x=1218390598; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20Please=20read |Sender:=20; bh=AuAIPOlPYeSqJxbYPG5OmwT9VzTko+2ywYKwCXS62yc=; b=KeyjXeYxF68dF5rxXf8PhBcwjwU4+7aoFdIA7iHW/YvnqeGp8MZnR6LSae r2ZCm4L9OinpKjzpOemOPC/WilzJr+bajQ6RstUJZYM4CJbzzXhmmhZLojQw uB/teVPNIefclxAGLz5c1TYgPP3hUE05AXUmlnqt32kldf3uQwd4c=; Authentication-Results: sj-dkim-1; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [tcpm] Please read X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org During the TCPM meeting in Dublin, Wes wanted to encourage readers on this mailing list to read the short (2 pages if you remove the boiler plate part) draft on "Clarification of Sender Behavior Under Persist Condition" draft. To enable a quick read, I have cut and pasted the relevant sections here. As noted in the meeting, this draft tries to clarify the sender behavior without getting into the details of the DoS scenario and the possible solutions. Just to reiterate, it is this draft and not the original persist draft that we are trying to table for adoption as a WG item. 1. Introduction RFC 1122 [RFC1122] Section 4.2.2.17, page 92 says that: A TCP MAY keep it's offered receive window closed indefinitely. As long as the receiving TCP continues to send acknowledgments in response to the probe segments, the sending TCP MUST allow the connection to stay open. The RFC goes on to say that it is important to remember that ACK (acknowledgment) segments that contain no data are not reliably transmitted by TCP. Therefore zero window probing SHOULD be supported to prevent a connection from hanging forever if ACK segments that re-opens the window is lost. The condition where the sender goes into the ZWP mode is typically known as the persist condition. The problem is applicable to TCP and TCP derived transport protocols like SCTP. A consequence of adhering to the above requirement mandated by RFC 1122 is that multiple TCP receivers (clients) advertising a zero window to a busy server indefinitely (by reliably acknowledging the ZWP), could exhaust the connection and buffer resources of the sender (server). In such cases, to achieve robustness, the system should be able to take appropriate action on those TCP connections and reclaim resources. The purpose of this document is to clarify that such actions are in the spirit of RFC 1122 and they don't violate RFC 1122. The remainder of the document briefly describes the DoS scenario, analyzes the current verbiage surrounding the ZWP in RFC 1122 and attempts to disambiguate the notion presented by RFC 1122. 2. Discussion Having the sender accumulate buffers and connection table entries when the receiver has deliberately and maliciously closed the window ultimately leads to resource exhaustion on the sender. This particular dependence on the receiver to open its zero window can be easily exploited by a malicious receiver TCP application to launch a DoS attack against the sender. In this scenario the sender's legitimate connections do not get established and already established well behaved TCP connections are unable to transmit any data. The sender enters the persist condition and is stuck waiting indefinitely for the receiver to open up its window. To illustrate this, consider the case where the client application opens a TCP connection with a HTTP [RFC2616] server, sends a GET request for a large page and stops reading the response. This would cause the client TCP to advertise a zero window to the server. For every large HTTP response, the server is left holding on to all the response data in it's send queue. If the client never clears the persist condition, the server will continue to hold that data indefinitely. Multiple such TCP connections stuck in the same scenario on the server would cause resource depletion resulting in a DoS situation on the server. In such scenarios it should be possible for the application or the system or a resource management entity to instruct TCP to terminate connections stalled in the persist condition. These actions are necessary to prevent resource exhaustion on the server. An extensive discussion took place recently about this issue on the TCPM WG mailing list [TCPM]. The general opinion seemed to be that terminating a TCP connection in persist condition does not violate RFC 1122. In particular the operating system, a resource manager, or an application can instruct TCP to abort a connection in the persist condition. TCP itself SHOULD not take any action and continue to keep the connection open as mandated by RFC 1122 unless otherwise instructed to do so. The exact mechanism by which the instruction to abort the connection is conveyed to TCP is an implementation decision and falls beyond the scope of the current memo. To determine which TCP connection to abort the entity can use the connection attributes obtained from some interface similar to STATUS call mentioned in RFC 793. -- mahesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 31 11:17:35 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A83028C27A; Thu, 31 Jul 2008 11:17:35 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7792128C271 for ; Thu, 31 Jul 2008 11:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.108 X-Spam-Level: X-Spam-Status: No, score=-6.108 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKn51b3ouIAd for ; Thu, 31 Jul 2008 11:17:33 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4DAAA28C28B for ; Thu, 31 Jul 2008 11:17:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,287,1215388800"; d="scan'208,217";a="60046336" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 31 Jul 2008 18:17:20 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6VIHKHF026298; Thu, 31 Jul 2008 11:17:20 -0700 Received: from [10.21.51.198] ([10.21.51.198]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m6VIHITO004529; Thu, 31 Jul 2008 18:17:19 GMT Message-ID: <489201AE.1080706@cisco.com> Date: Thu, 31 Jul 2008 11:17:18 -0700 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" References: In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3670; t=1217528240; x=1218392240; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20Re=3A=20[tcpm]=20draft=20IETF=2072=20meeting=20 notes |Sender:=20; bh=Jmo1oAX+L1GpPZlWjgcP/cKErhKu18aXYYT3+ynBK5Q=; b=Jo0hgKf+LkELdqW7ZYijEHS6rb51Kk6PuDxoq6M+InoEGHkxAg2zx11G5B 3GhnijIg4y41CJXJTj168xAH/XL5dFSvTLPeW1k2ZJQj3McVWqwtNq7zPO34 k7H6gzaXAUvgRowYNDc5Rf1IPhP2ecmbQBDL95toeClETQoIEZ7+Y=; Authentication-Results: sj-dkim-1; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: tcpm@ietf.org Subject: Re: [tcpm] draft IETF 72 meeting notes X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1032333487==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============1032333487== Content-Type: multipart/alternative; boundary="------------030801040008010306070100" This is a multi-part message in MIME format. --------------030801040008010306070100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks Lloyd for taking the notes. An addendum to the meeting notes is noted inline. Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: > TCPMers: here are the draft meeting notes from today. Please report > any corrections or clarifications out to the chairs so that we can fix > them for the final copy. Thanks in advance! > > Thanks to Lloyd Wood for taking these notes even among some of the > fast discussions; I believe it will be very difficult to convince him > to take notes for us again :). > > > Wes: I had understanding that WG had not accepted this, but easier to get just a clarification (informational) accepted by the WG. > > Lars: if I was chair calling consensus - FAIL - don't adopt it as WG item. Call on WG for proposed std failed. > In offline discussion with Lars and others it was clear there was confusion about which draft was being requested for WG item. Yes, the original persist draft had not been accepted by WG. On suggestion by the chairs (Mark and Ted at that time) a short information draft describing just the sender behavior was written and presented in the meeting. It is that draft which is being requested for adoption by WG. Lars, I hope I have captured the spirit of the discussion. -- mahesh --------------030801040008010306070100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks Lloyd for taking the notes. An addendum to the meeting notes is noted inline.

Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:
TCPMers: here are the draft meeting notes from today.  Please report any corrections or clarifications out to the chairs so that we can fix them for the final copy.  Thanks in advance!
 
Thanks to Lloyd Wood for taking these notes even among some of the fast discussions; I believe it will be very difficult to convince him to take notes for us again :).
 
 
<pasting the relevant section>
Wes: I had understanding that WG had not accepted this, but easier to get just a clarification (informational) accepted by the WG.

Lars: if I was chair calling consensus - FAIL - don't adopt it as WG item. Call on WG for proposed std failed.
In offline discussion with Lars and others it was clear there was confusion about which draft was being requested for WG item. Yes, the original persist draft had not been accepted by WG. On suggestion by the chairs (Mark and Ted at that time)  a short information draft describing just the sender behavior was written and presented in the meeting. It is that draft which is being requested for adoption by WG.

Lars, I hope I have captured the spirit of the discussion.

-- mahesh
--------------030801040008010306070100-- --===============1032333487== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1032333487==-- From tcpm-bounces@ietf.org Thu Jul 31 11:39:24 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AD1D28C2D0; Thu, 31 Jul 2008 11:39:24 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22FC428C2D0 for ; Thu, 31 Jul 2008 11:39:23 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHuyYfTwdU-1 for ; Thu, 31 Jul 2008 11:39:21 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 54B9E28C2CD for ; Thu, 31 Jul 2008 11:39:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,287,1215388800"; d="scan'208";a="134103680" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 31 Jul 2008 18:36:47 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m6VIaleS008774 for ; Thu, 31 Jul 2008 11:36:47 -0700 Received: from [10.21.51.198] ([10.21.51.198]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m6VIakrr023343 for ; Thu, 31 Jul 2008 18:36:47 GMT Message-ID: <4892063D.3010703@cisco.com> Date: Thu, 31 Jul 2008 11:36:45 -0700 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: tcpm@ietf.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4843; t=1217529407; x=1218393407; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20Persist=20condition=20clarification=20draft,=20 =20now=20=22clarification=20of=20sending=0A=20behavior=22=20 draft=20-=20comments=20solicited |Sender:=20; bh=KpO/KwgbxDSLD4+ED6tR47wfuf3n41J7b4+WSDdIXLc=; b=GjXw8VbCRemVgYrLcsz2VBigkUlfQyu5riLfHQpg8cmZG+VHj8Fr01MLIM TwSKnwvnJDXnParVYXPQq8J7N/4IqkdLcX7Ae5nRSRuhBiN4jQ7oG/RtNezK ycX8j6lFSl; Authentication-Results: sj-dkim-4; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [tcpm] Persist condition clarification draft, now "clarification of sending behavior" draft - comments solicited X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Apologies for sending this message twice, but did not realize that my previous subject line attracted some spam filters (including my own). During the TCPM meeting in Dublin, Wes wanted to encourage readers on this mailing list to read the short (2 pages if you remove the boiler plate part) draft on "Clarification of Sender Behavior Under Persist Condition" draft. To enable a quick read, I have cut and pasted the relevant sections here. As noted in the meeting, this draft tries to clarify the sender behavior without getting into the details of the DoS scenario and the possible solutions. Just to reiterate, it is this draft and not the original persist draft that we are trying to table for adoption as a WG item. 1. Introduction RFC 1122 [RFC1122] Section 4.2.2.17, page 92 says that: A TCP MAY keep it's offered receive window closed indefinitely. As long as the receiving TCP continues to send acknowledgments in response to the probe segments, the sending TCP MUST allow the connection to stay open. The RFC goes on to say that it is important to remember that ACK (acknowledgment) segments that contain no data are not reliably transmitted by TCP. Therefore zero window probing SHOULD be supported to prevent a connection from hanging forever if ACK segments that re-opens the window is lost. The condition where the sender goes into the ZWP mode is typically known as the persist condition. The problem is applicable to TCP and TCP derived transport protocols like SCTP. A consequence of adhering to the above requirement mandated by RFC 1122 is that multiple TCP receivers (clients) advertising a zero window to a busy server indefinitely (by reliably acknowledging the ZWP), could exhaust the connection and buffer resources of the sender (server). In such cases, to achieve robustness, the system should be able to take appropriate action on those TCP connections and reclaim resources. The purpose of this document is to clarify that such actions are in the spirit of RFC 1122 and they don't violate RFC 1122. The remainder of the document briefly describes the DoS scenario, analyzes the current verbiage surrounding the ZWP in RFC 1122 and attempts to disambiguate the notion presented by RFC 1122. 2. Discussion Having the sender accumulate buffers and connection table entries when the receiver has deliberately and maliciously closed the window ultimately leads to resource exhaustion on the sender. This particular dependence on the receiver to open its zero window can be easily exploited by a malicious receiver TCP application to launch a DoS attack against the sender. In this scenario the sender's legitimate connections do not get established and already established well behaved TCP connections are unable to transmit any data. The sender enters the persist condition and is stuck waiting indefinitely for the receiver to open up its window. To illustrate this, consider the case where the client application opens a TCP connection with a HTTP [RFC2616] server, sends a GET request for a large page and stops reading the response. This would cause the client TCP to advertise a zero window to the server. For every large HTTP response, the server is left holding on to all the response data in it's send queue. If the client never clears the persist condition, the server will continue to hold that data indefinitely. Multiple such TCP connections stuck in the same scenario on the server would cause resource depletion resulting in a DoS situation on the server. In such scenarios it should be possible for the application or the system or a resource management entity to instruct TCP to terminate connections stalled in the persist condition. These actions are necessary to prevent resource exhaustion on the server. An extensive discussion took place recently about this issue on the TCPM WG mailing list [TCPM]. The general opinion seemed to be that terminating a TCP connection in persist condition does not violate RFC 1122. In particular the operating system, a resource manager, or an application can instruct TCP to abort a connection in the persist condition. TCP itself SHOULD not take any action and continue to keep the connection open as mandated by RFC 1122 unless otherwise instructed to do so. The exact mechanism by which the instruction to abort the connection is conveyed to TCP is an implementation decision and falls beyond the scope of the current memo. To determine which TCP connection to abort the entity can use the connection attributes obtained from some interface similar to STATUS call mentioned in RFC 793. -- mahesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 31 11:44:48 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A702C3A6ADB; Thu, 31 Jul 2008 11:44:48 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A87F328C2AD for ; Thu, 31 Jul 2008 11:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Y1Q8ffkqJZz for ; Thu, 31 Jul 2008 11:44:45 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6A6403A679F for ; Thu, 31 Jul 2008 11:44:29 -0700 (PDT) Received: from [172.16.7.194] ([130.129.65.248]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6VIgNF2011351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Jul 2008 11:42:26 -0700 (PDT) Message-ID: <4892076A.6000801@isi.edu> Date: Thu, 31 Jul 2008 11:41:46 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Mahesh Jethanandani References: <4891FB44.50704@cisco.com> In-Reply-To: <4891FB44.50704@cisco.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Please read X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FWIW, I agree with this. In addition, "unless otherwise instructed to do so" should be extended to address the resource limit issue: "unless otherwise instructed to do so, e.g., in the case where the OS is running out of resources, or a user timeout occurs" Regarding that last point, I understood it to be related - i.e., that current implementations won't allow a user timeout to kill a connection in persist. Is that the case? If so, that's worth noting under motivation for the document as well. Joe Mahesh Jethanandani wrote: | During the TCPM meeting in Dublin, Wes wanted to encourage readers on | this mailing list to read the short (2 pages if you remove the boiler | plate part) draft on "Clarification of Sender Behavior Under Persist | Condition" draft. | | To enable a quick read, I have cut and pasted the relevant sections | here. As noted in the meeting, this draft tries to clarify the sender | behavior without getting into the details of the DoS scenario and the | possible solutions. Just to reiterate, it is this draft and not the | original persist draft that we are trying to table for adoption as a WG | item. | | 1. Introduction | | RFC 1122 [RFC1122] Section 4.2.2.17, page 92 says that: A TCP MAY | keep it's offered receive window closed indefinitely. As long as the | receiving TCP continues to send acknowledgments in response to the | probe segments, the sending TCP MUST allow the connection to stay | open. The RFC goes on to say that it is important to remember that | ACK (acknowledgment) segments that contain no data are not reliably | transmitted by TCP. Therefore zero window probing SHOULD be | supported to prevent a connection from hanging forever if ACK | segments that re-opens the window is lost. The condition where the | sender goes into the ZWP mode is typically known as the persist | condition. The problem is applicable to TCP and TCP derived | transport protocols like SCTP. | | A consequence of adhering to the above requirement mandated by RFC | 1122 is that multiple TCP receivers (clients) advertising a zero | window to a busy server indefinitely (by reliably acknowledging the | ZWP), could exhaust the connection and buffer resources of the sender | (server). In such cases, to achieve robustness, the system should be | able to take appropriate action on those TCP connections and reclaim | resources. The purpose of this document is to clarify that such | actions are in the spirit of RFC 1122 and they don't violate RFC | 1122. The remainder of the document briefly describes the DoS | scenario, analyzes the current verbiage surrounding the ZWP in RFC | 1122 and attempts to disambiguate the notion presented by RFC 1122. | | 2. Discussion | | Having the sender accumulate buffers and connection table entries | when the receiver has deliberately and maliciously closed the window | ultimately leads to resource exhaustion on the sender. This | particular dependence on the receiver to open its zero window can be | easily exploited by a malicious receiver TCP application to launch a | DoS attack against the sender. In this scenario the sender's | legitimate connections do not get established and already established | well behaved TCP connections are unable to transmit any data. The | sender enters the persist condition and is stuck waiting indefinitely | for the receiver to open up its window. | | To illustrate this, consider the case where the client application | opens a TCP connection with a HTTP [RFC2616] server, sends a GET | request for a large page and stops reading the response. This would | cause the client TCP to advertise a zero window to the server. For | every large HTTP response, the server is left holding on to all the | response data in it's send queue. If the client never clears the | persist condition, the server will continue to hold that data | indefinitely. Multiple such TCP connections stuck in the same | scenario on the server would cause resource depletion resulting in a | DoS situation on the server. | | In such scenarios it should be possible for the application or the | system or a resource management entity to instruct TCP to terminate | connections stalled in the persist condition. These actions are | necessary to prevent resource exhaustion on the server. | | An extensive discussion took place recently about this issue on the | TCPM WG mailing list [TCPM]. The general opinion seemed to be that | terminating a TCP connection in persist condition does not violate | RFC 1122. In particular the operating system, a resource manager, or | an application can instruct TCP to abort a connection in the persist | condition. TCP itself SHOULD not take any action and continue to | keep the connection open as mandated by RFC 1122 unless otherwise | instructed to do so. The exact mechanism by which the instruction to | abort the connection is conveyed to TCP is an implementation decision | and falls beyond the scope of the current memo. To determine which | TCP connection to abort the entity can use the connection attributes | obtained from some interface similar to STATUS call mentioned in RFC | 793. | | | | | | | | | -- mahesh | _______________________________________________ | tcpm mailing list | tcpm@ietf.org | https://www.ietf.org/mailman/listinfo/tcpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiSB2oACgkQE5f5cImnZru31wCgs59aQgSgQFZGr5yZzmQO8s4d b2oAni+HjYblCng5DKD1FaoSZQIFYWT2 =MsGH -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 31 12:12:55 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C24A928C303; Thu, 31 Jul 2008 12:12:55 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19B7628C300 for ; Thu, 31 Jul 2008 12:12:55 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VW+2UD8ErkD for ; Thu, 31 Jul 2008 12:12:49 -0700 (PDT) Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by core3.amsl.com (Postfix) with ESMTP id A3A0E28C303 for ; Thu, 31 Jul 2008 12:12:49 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 31 Jul 2008 15:13:06 -0400 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7704041514@nekter> In-Reply-To: <4891FB44.50704@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Please read Thread-Index: AcjzNe3fYDEP7eyjQ2iaMYdiBM+z+wACx+Dg References: <4891FB44.50704@cisco.com> From: "Caitlin Bestler" To: "Mahesh Jethanandani" , Subject: Re: [tcpm] Please read X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Is an RFC really needed? I've always assumed that the application layer MAY do pretty much whatever it wants. Further application layer servers SHOULD protect their own resources against abusive clients. Those protection mechanisms MAY include terminating connections. All of that is true independent of any specific method of abusing server resources. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 31 12:52:13 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EB6E28C21B; Thu, 31 Jul 2008 12:52:12 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D9F328C116 for ; Thu, 31 Jul 2008 12:52:10 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRc1KYCgzWko for ; Thu, 31 Jul 2008 12:52:08 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id 6183E28C2CE for ; Thu, 31 Jul 2008 12:52:08 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so623509rvf.49 for ; Thu, 31 Jul 2008 12:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=bOui26ebn+WcNnB9SX6JO6k/GA/KPg/6rY/C8ZtTja8=; b=Djtcs/MPxOijIKAMbV7YgsqwPwe2Qxa7l0xMMXPqhABvrcOh4sQ2QVaIn1gweN/YKL Gp8bKMKR4juaX2vmnpWyIeWqXbuzXQwYLM31onEzR40Furl88orDvluBZUtAzcy60Kly 26VORqx6joGNP5T/CzxdXP7szvgTDHy/KAW+I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=OomUeBvHR5jbCqK3zavMuJkk/1qHW+47xy2spSMuSaOX2hiFQjnqhDeutqtYOqA36P HlH2PMiu5tz/yZuatLaH+y4QM4te+es1J+KqbyEkgDItNa9i75mcVe7ueCwex56s0lWm 1dKe2BnShuXciRfW1GtWwueC9n8qRysHrZ/aA= Received: by 10.140.164.6 with SMTP id m6mr5499369rve.210.1217533945900; Thu, 31 Jul 2008 12:52:25 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Thu, 31 Jul 2008 12:52:25 -0700 (PDT) Message-ID: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> Date: Thu, 31 Jul 2008 12:52:25 -0700 From: "Adam Langley" To: tcpm@ietf.org MIME-Version: 1.0 Content-Disposition: inline X-Google-Sender-Auth: fe372f10617d0f36 Subject: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org I posted this a while back and it gathered a little discussion: http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-00.txt (implementation in [1]) I would like to have this published as Experimental and to get an option number assigned. The spec itself includes a somewhat rambling justification because I wanted to decouple the spec, which is more general, from the exact reason that I wish to start testing this over the Internet at large. However, in order to provoke discussion I think I should explain my motivation: This spec allows for opportunistic encryption of TCP connections with no additional round trips. Details of the project can be found at [2], however a quick summary follows: Although SYN/ACK payloads could be used to accelerate many protocols, I'm proposing that, for HTTP, the SYN/ACK payload contains an 8-byte random nonce and a 32-byte eliptic-curve public value. The client can then perform key agreement and send it's own public value, nonce and any encrypted payload in the final ACK. (Or in a following packet, that works fine too). Data is then encrypted using Salsa20/8 where the key is SHA256(diffie-hellman output + server nonce + client nonce) and the IVs are 0 and 2**63 for client->server and server->client, resp. Obviously, this open to both a downgrade and man-in-the-middle attack. For a specific user, it offers little real security. However, amortised over a large set of users, any ISPs performing these attacks on a large scale will be detected. (I plan on building a network of hosts probing for large scale attacks.) Thus, eavesdroppers are removed from the equation and, against the rest, it can protect most of the people, most of the time. I also plan to sign the resulting packets with TCP-AO at some point, if possible. However, given that that is still under development I'm going to make that part of the negotiation, above, so that it can be deployed without it for now. Obviously, this system can only prove itself in time. However, it can't prove itself with an option number assigned. And thus, I'm looking for a consensus that this is an interesting experiment. Thanks Having spoken to quite a few people about this, I now have an FAQ on the design which is included below: * Why Elliptic-curves? The payload must be short otherwise SYN-floods could use this as an amplification to backscatter DDoS another host. Also, the reduced computation cost (as compared to Diffie-Hellman over a multiplicative finite field) is very nice. * Why 25519? It's very fast (2000 ops/sec with my C code. 4000 ops/sec with asm). Also, the server's public value must be constant, otherwise an attacker could eat CPU time with a SYN flood and curve25519 is designed for that. Since this is constant for all connections, there is no perfect forward secrecy. * Can't you fit the client's public value in the SYN? A SYN generally has 20 bytes of free option space these days. (We can't use the payload space in a SYN). Since this can't be the last option ever, we need to leave 4 bytes spare. 2 bytes for the option header means 14 bytes for the public value. The closest prime is 2**112-75. I'm a bear of little brain and picking my own curve is already a hell of a task, but assuming that I can: The best, general algorithm currently known for breaking the DH problem on elliptic curves is Pollard's Rho. The work involved in this attack is sqrt(n), which is 2**56 in this case. Critically, once you have solved a single instance you can precompute tables to speed up breaking more instances. With a petabyte of storage, you could break 112-bit curves in 2**12 operations, which is very fast. * Can't you use a smaller field anyway? Some speedup could be gained by using an EC with a field size around 200 bits. However the effort of defining such a curve is pretty huge. The standard NIST curves around that size are slower: http://www.cacr.math.uwaterloo.ca/techreports/2003/corr2003-18.pdf (table 6) * Why Salsa20/8? It encrypts at two cycles per byte on modern CPUs[1]. The best attack on this, reduced round, variant is 2**251. It's very unlikely that an attack would ever break it to the point that it's easier than performing a downgrade attack. http://cr.yp.to/streamciphers/phase3speed-20080331.pdf [1] http://code.google.com/p/obstcp/source/browse/trunk/patches/synack-payload [2] http://code.google.com/p/obstcp/ -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 31 14:10:06 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E1543A6D3C; Thu, 31 Jul 2008 14:10:06 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B1773A6D38 for ; Thu, 31 Jul 2008 14:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RLCaVQ6xruN for ; Thu, 31 Jul 2008 14:07:12 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by core3.amsl.com (Postfix) with ESMTP id 5E1C23A6A05 for ; Thu, 31 Jul 2008 14:07:12 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so752738and.122 for ; Thu, 31 Jul 2008 14:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=n78I8UIlFfh2FHgN+b1T2P6XiK5ZS2hCMTw0lKioIqY=; b=EOmKkkfYtm25/jrizAZ4YfFbBdTkgEF1WqZqxLksbKzPGGOYAxz4n/IP6wiEFvHISE thAupBzU5s67m5xLRYMobN+rhalxFsW7AdEzOEeJtPV2d51DL0Xe0GNDeX0nYIokxcPS ePucFh/HGYaJ6S0irDLiHW/NJuu9w9xnhibx4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=TZVOQcRZ1FsC1tcOAobGIO0C6+fjy1gB4GxCfKDRQ5yxOya1UkaD+2jcOA5co3t8LE jIzsLTdybz1m/k5Z9Moc9jfwcL4pxHDFGPWBTC8raB4CPU+V7fyT5rkMMnkqHMEQO2du QB1XjNAAtfRMgQ1sqrxIP+3sT8ifzirBsGqNE= Received: by 10.100.134.10 with SMTP id h10mr15564941and.80.1217538449275; Thu, 31 Jul 2008 14:07:29 -0700 (PDT) Received: by 10.100.216.13 with HTTP; Thu, 31 Jul 2008 14:07:29 -0700 (PDT) Message-ID: <9c8209a10807311407s1899eeej5611b7acb5b44976@mail.gmail.com> Date: Thu, 31 Jul 2008 14:07:29 -0700 From: "Murali Bashyam" To: "Adam Langley" In-Reply-To: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> MIME-Version: 1.0 References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1836868528==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1836868528== Content-Type: multipart/alternative; boundary="----=_Part_128331_24236055.1217538449264" ------=_Part_128331_24236055.1217538449264 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline There are firewalls that drop SYN packets carrying payload, since it's considered anomalous behaviour (rightly so given today's end-user behaviour). Doesn't that defeat the purpose here? I suppose TCP options have been explored and ruled out for some reason? On Thu, Jul 31, 2008 at 12:52 PM, Adam Langley wrote: > I posted this a while back and it gathered a little discussion: > > http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-00.txt > (implementation in [1]) > > I would like to have this published as Experimental and to get an > option number assigned. > > The spec itself includes a somewhat rambling justification because I > wanted to decouple the spec, which is more general, from the exact > reason that I wish to start testing this over the Internet at large. > However, in order to provoke discussion I think I should explain my > motivation: > > This spec allows for opportunistic encryption of TCP connections with > no additional round trips. Details of the project can be found at [2], > however a quick summary follows: > > Although SYN/ACK payloads could be used to accelerate many protocols, > I'm proposing that, for HTTP, the SYN/ACK payload contains an 8-byte > random nonce and a 32-byte eliptic-curve public value. The client can > then perform key agreement and send it's own public value, nonce and > any encrypted payload in the final ACK. (Or in a following packet, > that works fine too). Data is then encrypted using Salsa20/8 where the > key is SHA256(diffie-hellman output + server nonce + client nonce) and > the IVs are 0 and 2**63 for client->server and server->client, resp. > > Obviously, this open to both a downgrade and man-in-the-middle attack. > For a specific user, it offers little real security. However, > amortised over a large set of users, any ISPs performing these attacks > on a large scale will be detected. (I plan on building a network of > hosts probing for large scale attacks.) Thus, eavesdroppers are > removed from the equation and, against the rest, it can protect most > of the people, most of the time. > > I also plan to sign the resulting packets with TCP-AO at some point, > if possible. However, given that that is still under development I'm > going to make that part of the negotiation, above, so that it can be > deployed without it for now. > > Obviously, this system can only prove itself in time. However, it > can't prove itself with an option number assigned. And thus, I'm > looking for a consensus that this is an interesting experiment. > > Thanks > > Having spoken to quite a few people about this, I now have an FAQ on > the design which is included below: > > * Why Elliptic-curves? > > The payload must be short otherwise SYN-floods could use this as an > amplification > to backscatter DDoS another host. > > Also, the reduced computation cost (as compared to Diffie-Hellman over a > multiplicative finite field) is very nice. > > * Why 25519? > > It's very fast (2000 ops/sec with my C code. 4000 ops/sec with asm). Also, > the > server's public value must be constant, otherwise an attacker could eat CPU > time with a SYN flood and curve25519 is designed for that. > > Since this is constant for all connections, there is no perfect forward > secrecy. > > * Can't you fit the client's public value in the SYN? > > A SYN generally has 20 bytes of free option space these days. (We can't use > the > payload space in a SYN). Since this can't be the last option ever, we need > to > leave 4 bytes spare. 2 bytes for the option header means 14 bytes for the > public value. The closest prime is 2**112-75. > > I'm a bear of little brain and picking my own curve is already a hell of a > task, but assuming that I can: > > The best, general algorithm currently known for breaking the DH problem on > elliptic curves is Pollard's Rho. The work involved in this attack is > sqrt(n), > which is 2**56 in this case. Critically, once you have solved a single > instance > you can precompute tables to speed up breaking more instances. With a > petabyte > of storage, you could break 112-bit curves in 2**12 operations, which is > very > fast. > > * Can't you use a smaller field anyway? > > Some speedup could be gained by using an EC with a field size around 200 > bits. > However the effort of defining such a curve is pretty huge. The standard > NIST > curves around that size are slower: > > http://www.cacr.math.uwaterloo.ca/techreports/2003/corr2003-18.pdf (table > 6) > > * Why Salsa20/8? > > It encrypts at two cycles per byte on modern CPUs[1]. The best attack on > this, > reduced round, variant is 2**251. It's very unlikely that an attack would > ever > break it to the point that it's easier than performing a downgrade attack. > > http://cr.yp.to/streamciphers/phase3speed-20080331.pdf > > > > [1] > http://code.google.com/p/obstcp/source/browse/trunk/patches/synack-payload > [2] http://code.google.com/p/obstcp/ > > -- > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > -- Rgds, Murali Bashyam (c) (510)6736915 ----------------------------- CONFIDENTIAL -------------------- ***************************************************** This telecommunication and any data attached to, or included in it is considered confidential, and is intended only for use by the named recipient. The contents may be legally protected as any one or more of: copyrighted material, trade-secret protected material, attorney-client privileged material, attorney workproduct, or as material covered by any other legally available means. If you received this material in error, please notify the sender and destroy the original and all copies, whether electronic or otherwise. Thank you. ***************************************************** ------------------------------ CONFIDENTIAL -------------------- ------=_Part_128331_24236055.1217538449264 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
There are firewalls that drop SYN packets carrying payload, since it's considered anomalous behaviour (rightly so given today's end-user
behaviour). Doesn't that defeat the purpose here? I suppose TCP options have been explored and ruled out for some reason?

On Thu, Jul 31, 2008 at 12:52 PM, Adam Langley <agl@imperialviolet.org> wrote:
I posted this a while back and it gathered a little discussion:

http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-00.txt
(implementation in [1])

I would like to have this published as Experimental and to get an
option number assigned.

The spec itself includes a somewhat rambling justification because I
wanted to decouple the spec, which is more general, from the exact
reason that I wish to start testing this over the Internet at large.
However, in order to provoke discussion I think I should explain my
motivation:

This spec allows for opportunistic encryption of TCP connections with
no additional round trips. Details of the project can be found at [2],
however a quick summary follows:

Although SYN/ACK payloads could be used to accelerate many protocols,
I'm proposing that, for HTTP, the SYN/ACK payload contains an 8-byte
random nonce and a 32-byte eliptic-curve public value. The client can
then perform key agreement and send it's own public value, nonce and
any encrypted payload in the final ACK. (Or in a following packet,
that works fine too). Data is then encrypted using Salsa20/8 where the
key is SHA256(diffie-hellman output + server nonce + client nonce) and
the IVs are 0 and 2**63 for client->server and server->client, resp.

Obviously, this open to both a downgrade and man-in-the-middle attack.
For a specific user, it offers little real security. However,
amortised over a large set of users, any ISPs performing these attacks
on a large scale will be detected. (I plan on building a network of
hosts probing for large scale attacks.) Thus, eavesdroppers are
removed from the equation and, against the rest, it can protect most
of the people, most of the time.

I also plan to sign the resulting packets with TCP-AO at some point,
if possible. However, given that that is still under development I'm
going to make that part of the negotiation, above, so that it can be
deployed without it for now.

Obviously, this system can only prove itself in time. However, it
can't prove itself with an option number assigned. And thus, I'm
looking for a consensus that this is an interesting experiment.

Thanks

Having spoken to quite a few people about this, I now have an FAQ on
the design which is included below:

* Why Elliptic-curves?

The payload must be short otherwise SYN-floods could use this as an
amplification
to backscatter DDoS another host.

Also, the reduced computation cost (as compared to Diffie-Hellman over a
multiplicative finite field) is very nice.

* Why 25519?

It's very fast (2000 ops/sec with my C code. 4000 ops/sec with asm). Also, the
server's public value must be constant, otherwise an attacker could eat CPU
time with a SYN flood and curve25519 is designed for that.

Since this is constant for all connections, there is no perfect forward
secrecy.

* Can't you fit the client's public value in the SYN?

A SYN generally has 20 bytes of free option space these days. (We can't use the
payload space in a SYN). Since this can't be the last option ever, we need to
leave 4 bytes spare. 2 bytes for the option header means 14 bytes for the
public value. The closest prime is 2**112-75.

I'm a bear of little brain and picking my own curve is already a hell of a
task, but assuming that I can:

The best, general algorithm currently known for breaking the DH problem on
elliptic curves is Pollard's Rho. The work involved in this attack is sqrt(n),
which is 2**56 in this case. Critically, once you have solved a single instance
you can precompute tables to speed up breaking more instances. With a petabyte
of storage, you could break 112-bit curves in 2**12 operations, which is very
fast.

* Can't you use a smaller field anyway?

Some speedup could be gained by using an EC with a field size around 200 bits.
However the effort of defining such a curve is pretty huge. The standard NIST
curves around that size are slower:

http://www.cacr.math.uwaterloo.ca/techreports/2003/corr2003-18.pdf (table 6)

* Why Salsa20/8?

It encrypts at two cycles per byte on modern CPUs[1]. The best attack on this,
reduced round, variant is 2**251. It's very unlikely that an attack would ever
break it to the point that it's easier than performing a downgrade attack.

http://cr.yp.to/streamciphers/phase3speed-20080331.pdf



[1] http://code.google.com/p/obstcp/source/browse/trunk/patches/synack-payload
[2] http://code.google.com/p/obstcp/

--
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm



--
Rgds,
Murali Bashyam
(c) (510)6736915

----------------------------- CONFIDENTIAL --------------------
*****************************************************
This telecommunication and any data attached to, or included in it
is considered confidential, and is intended only for use by the named
recipient. The contents may be legally protected as any one or more of:
copyrighted material, trade-secret protected material, attorney-client
privileged material, attorney workproduct, or as material covered by
any other legally available means. If you received this material in
error, please notify the sender and destroy the original and all copies,
whether electronic or otherwise. Thank you.
*****************************************************
------------------------------ CONFIDENTIAL --------------------
------=_Part_128331_24236055.1217538449264-- --===============1836868528== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1836868528==-- From tcpm-bounces@ietf.org Thu Jul 31 14:19:17 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4D2228C21A; Thu, 31 Jul 2008 14:19:17 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AFCC28C2BF for ; Thu, 31 Jul 2008 14:19:17 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Egzx2UJuTZ8t for ; Thu, 31 Jul 2008 14:19:16 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 5751F28C15E for ; Thu, 31 Jul 2008 14:19:16 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so654901rvf.49 for ; Thu, 31 Jul 2008 14:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=JnulgKJC5vGOfx7koCz7V8NXYj/D9qfOL1MQa0i29Ao=; b=dbd0t/w1TTAaKAnJleTzs0j6MyPpAllb4Y9ES5l8sOEIeKXmYChV04VWGNvl1VvIRI KXhnRbljcMUe9ZFulfjW9Mj+ASdTqKFfb7VaU7hq2F1TeVr518ORFItbYbCp1KD5iq2j GgSIrsPUAnPRf/fGsUZj+iysB20IEdijRTlDU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=ltDYeDqWQgP8iPZ4n+H33cCSdE2VBD0dK1zBpyxDCk0OwITwQexX0UTF1EX+VL4ZCA OhIg9zIuQVwFR/f2E7YF8ZD415o4/NnMh18muxRhF4xoH0xlvx4LHqChB7yyZ0gkZkiu xcCO5vknB3nPxgb6NRNm1IWqWSdkuI3f60Q24= Received: by 10.141.185.3 with SMTP id m3mr5542885rvp.40.1217539174716; Thu, 31 Jul 2008 14:19:34 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Thu, 31 Jul 2008 14:19:34 -0700 (PDT) Message-ID: <396556a20807311419n7b38dcf5x573634fab230de88@mail.gmail.com> Date: Thu, 31 Jul 2008 14:19:34 -0700 From: "Adam Langley" To: "Murali Bashyam" In-Reply-To: <9c8209a10807311407s1899eeej5611b7acb5b44976@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> <9c8209a10807311407s1899eeej5611b7acb5b44976@mail.gmail.com> X-Google-Sender-Auth: c93527cc8089a800 Cc: tcpm@ietf.org Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Thu, Jul 31, 2008 at 2:07 PM, Murali Bashyam wrote: > There are firewalls that drop SYN packets carrying payload, since it's > considered anomalous behaviour (rightly so given today's end-user > behaviour). Doesn't that defeat the purpose here? I suppose TCP options have > been explored and ruled out for some reason? See the section "Can't you fit the client's public value in the SYN?" for a discussion about using options space for this. Middleware is a quotidian worry for these sorts of proposals. I'm not proposing that a payload be carried in the SYN packet, but rather the SYN/ACK packet. However, you may have meant all packets with a SYN flag set. The spec talks about how to back off in the face of such middleware, and I believe that's the best that can be done. Since this is an opportunistic protocol, detection and downgrade at the client is fine. My current implementation doesn't do it yet, but will if there's any call for it. Cheers, AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 31 15:19:08 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD11328C34E; Thu, 31 Jul 2008 15:19:08 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 096CA28C34E for ; Thu, 31 Jul 2008 15:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fun+7XJfs2U for ; Thu, 31 Jul 2008 15:19:06 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 3CB8128C34B for ; Thu, 31 Jul 2008 15:19:06 -0700 (PDT) Received: from [172.16.7.194] ([130.129.65.208]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6VMI6rA024934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Jul 2008 15:18:09 -0700 (PDT) Message-ID: <489239F6.3030303@isi.edu> Date: Thu, 31 Jul 2008 15:17:26 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Murali Bashyam References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> <9c8209a10807311407s1899eeej5611b7acb5b44976@mail.gmail.com> In-Reply-To: <9c8209a10807311407s1899eeej5611b7acb5b44976@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Murali Bashyam wrote: | There are firewalls that drop SYN packets carrying payload, since it's | considered anomalous behaviour (rightly so given today's end-user | behaviour). Just because a system doesn't expect a packet doesn't mean it's an attack. Data in SYNs is defined in 793; it can be ignored (i.e., ACK the SYN but not the data), e.g., to reduce the server state until TWHS completes (or uses cookies, as well), but dropping those packets is the anomalous behavior here. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiSOfYACgkQE5f5cImnZrua3QCggjSiiCngIXXFbetwEjo++jAu 66IAnA0VUQVKV/nCr3HQ0c65WtwknETg =ku1K -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 31 16:03:40 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 173223A6A2D; Thu, 31 Jul 2008 16:03:40 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7F73A6A2D for ; Thu, 31 Jul 2008 16:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cc-SGgMCgsea for ; Thu, 31 Jul 2008 16:03:38 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id F17873A67A5 for ; Thu, 31 Jul 2008 16:03:37 -0700 (PDT) Received: from [172.16.7.194] ([130.129.65.208]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6VN3Rjh014819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Jul 2008 16:03:29 -0700 (PDT) Message-ID: <48924496.9060907@isi.edu> Date: Thu, 31 Jul 2008 16:02:46 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Adam Langley References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> In-Reply-To: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Adam, Adam Langley wrote: | I posted this a while back and it gathered a little discussion: | | http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-00.txt | (implementation in [1]) A few observations: - - TCP is already permitted to send data in the SYN-ACK prohibiting it when the SA-PP option is missing violates RFC1122 sec 4.2.2.5 -- unknown options are silently ignored options that change TCP need to be explicitly acknowledged, and current (legacy) behavior should be assumed if not acknowledged - - TCP is already 'backward compatible' with sources that ignore SA payload data; that data is just retransmitted you note that SA-PP alters the app level protocol; it appears to alter its timing, but AFAICT the effect would be otherwise invisible to an app - - The rule "For a given SYN, if any resulting SYNACK frame has a payload then all resulting frames MUST have a payload" appears to disable persists and ACKs as would be needed for proper operation when data is not available in one or more direction - - AFAICT, it isn't sensible to retransmit a SYN with the same ISN, port, etc. and different options. Since you do not explicitly acknowledge the option, how do you know which SYN is being ACKd - the presence of SA data isn't sufficient (e.g., legacy TCPs could do this) - - the diagrams need to include some corner cases: - when KX is larger than the PMTU in fig 3 (or NList is larger than the PMTU in fig 2) (i.e., it seems like there is a missing MUST NOT on the length) - how do you handle simultaneous opens? - - can you explain why you use a bit-field for the TCP option flag, rather than just using a 2-byte option? (i.e., KIND, length) - --- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiSRJYACgkQE5f5cImnZrvKHwCg9Ux1IGojUwuIQftRGmE3u6rz blYAnRTLVK20rSDsKli+8Bil47/sOgHd =ABOy -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 31 16:05:12 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B368F3A6976; Thu, 31 Jul 2008 16:05:12 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509A43A67FD for ; Thu, 31 Jul 2008 16:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTbv2axxITGp for ; Thu, 31 Jul 2008 16:05:11 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 91E843A6976 for ; Thu, 31 Jul 2008 16:05:11 -0700 (PDT) Received: from [172.16.7.194] ([130.129.65.208]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6VN4xk5015328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Jul 2008 16:05:05 -0700 (PDT) Message-ID: <489244F6.3090709@isi.edu> Date: Thu, 31 Jul 2008 16:04:22 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Joe Touch References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> <9c8209a10807311407s1899eeej5611b7acb5b44976@mail.gmail.com> <489239F6.3030303@isi.edu> In-Reply-To: <489239F6.3030303@isi.edu> X-Enigmail-Version: 0.95.6 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Adam Langley , tcpm@ietf.org Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joe Touch wrote: | | | Murali Bashyam wrote: | | There are firewalls that drop SYN packets carrying payload, since it's | | considered anomalous behaviour (rightly so given today's end-user | | behaviour). | | Just because a system doesn't expect a packet doesn't mean it's an attack. | | Data in SYNs is defined in 793;... PS - a SYN-ACK is just a SYN with the ACK set. It can have data just like any other SYN. The only issue is that the data is not transmitted to the app until the end of the TWHS; for the SYN-ACK, this is immediate (vs. putting the data in the SYN). T/TCP allows pushing the SYN data up to the app before the end of the TWHS, which is different, as you note. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiSRPYACgkQE5f5cImnZrvf5ACghKyhW4xK3DLjn1cvFVzxGH2h omUAnihed2wok3PiFU6EiJrT7YkBpJsu =/vl7 -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 31 16:39:55 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 502683A6D56; Thu, 31 Jul 2008 16:39:55 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B2D03A6D31 for ; Thu, 31 Jul 2008 16:39:54 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emWCHeP1WuyW for ; Thu, 31 Jul 2008 16:39:53 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id 44A673A6B45 for ; Thu, 31 Jul 2008 16:39:53 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so702071rvf.49 for ; Thu, 31 Jul 2008 16:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=XF6Z4c9SZjLpvVrsvvZcQQVoRHLoL13d+ZGJtIOIErQ=; b=wrDzT64AGueZYppJNp2u2rRegWQ3kKv600MCQygLVFLKFTTpmDNEhO5bQDksc8jNIB tdwKFaINQZYkt09KkOrWlbpguq+MjP//ZEhZsT3IOL8ZVrgm8Zg7cmkrBsthls0/dnmh SfIKVTzEV+dT3WaEpXzcEXcs1TzHn+i38Dv8M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=XM3KEkNTJfPa5CF7HJ0x3tAN5mNhCfu+h68Wl6J1tV3uiXOpWHo5uW2ndCHe87D+pp 1sZlduCs2gIME386QFgTgLqxXTieKASEnnAMt6rOCm0cUnp8QYrtCR+1Z1v8KgGrY5gh yWAWRQ0w3McyDKdiKwzHgAW3SyL0YL9hGZnno= Received: by 10.141.1.2 with SMTP id d2mr5602884rvi.129.1217547608673; Thu, 31 Jul 2008 16:40:08 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Thu, 31 Jul 2008 16:40:08 -0700 (PDT) Message-ID: <396556a20807311640w2b17d447ud0c51241dc84f682@mail.gmail.com> Date: Thu, 31 Jul 2008 16:40:08 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <48924496.9060907@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> <48924496.9060907@isi.edu> X-Google-Sender-Auth: 0021b91a58543ee7 Cc: tcpm@ietf.org Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Thu, Jul 31, 2008 at 4:02 PM, Joe Touch wrote: > - - TCP is already permitted to send data in the SYN-ACK > prohibiting it when the SA-PP option is missing violates > RFC1122 sec 4.2.2.5 -- unknown options are silently ignored > > options that change TCP need to be explicitly acknowledged, > and current (legacy) behavior should be assumed if not > acknowledged Ah, I didn't know this. Thank you! I don't believe changing TCP to disallow this is a good idea. However, it's important that userland knows weather this experiment is in effect. Thus, I believe that I should echo the SA-PP option in the SYNACK. Also, it should probably change names: SYN/ACK Payloads Processed or some similar. > - - The rule "For a given SYN, if any resulting SYNACK frame has a payload > then all resulting frames MUST have a payload" appears to disable > persists and ACKs as would be needed for proper operation when data is > not available in one or more direction That's badly worded on my part. It should read: "For a given SYN, if any resulting SYNACK frame has a payload then all resulting SYNACK frames MUST have a payload" (i.e. the restriction only apply to SYNACK frames. It's just so a host cannot decide the retransmit a different SYNACK) > - - AFAICT, it isn't sensible to retransmit a SYN with the same ISN, port, > etc. and different options. Since you do not explicitly acknowledge the > option, how do you know which SYN is being ACKd - the presence of SA > data isn't sufficient (e.g., legacy TCPs could do this) As you note, as another consequence of my misunderstanding, the presence of SA data isn't sufficient to tell which SYN is getting acked. Echoing the option should also solve this issue. > - - the diagrams need to include some corner cases: > - when KX is larger than the PMTU in fig 3 (or NList is > larger than the PMTU in fig 2) > (i.e., it seems like there is a missing MUST NOT on the length) It's suggested that the payload be limited to 64-bytes to prevent amplification backscatter from a SYN flood. Thus these bytestrings have to fit within the MTU. If an implementation doesn't enforce this, then it has to drop support when replying on a link where the MTU is insufficient. > - how do you handle simultaneous opens? I believe that simultaneous opens work just fine, although both sides will believe that the other doesn't support this experiment since the option won't be echoed in the SYN. > - - can you explain why you use a bit-field for the TCP option flag, > rather than just using a 2-byte option? (i.e., KIND, length) My hope was that by defining a flags option like this, future options that require only to signal their presence in a SYN could save space. If SACK permitted has been defined this way, for example, then this draft wouldn't need to take any more space. However, this is very subjective. If people would prefer not to do this, or would prefer to break it out into its own draft, I'm perfectly happy with that. Thanks! AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 31 17:00:12 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3CE328C334; Thu, 31 Jul 2008 17:00:12 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CB0628C334 for ; Thu, 31 Jul 2008 17:00:11 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDjk3vov4GeA for ; Thu, 31 Jul 2008 17:00:09 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id 5574028C235 for ; Thu, 31 Jul 2008 17:00:08 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so707533rvf.49 for ; Thu, 31 Jul 2008 17:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=4mWETs5X2TjGEBCUS5h/M3H7y52m5cT+wDIU9iF6TPI=; b=F4CyckHR7Y73K7xmHI5hP3jUiZpXLVMfjFl0/RR3vUedPvE574F9ReoN+7tqCLtlem HSA1XTKhs/jSb1GROFx0E3QpGmv+PmVp/qdJA9Ho78i3WgIicVCFuKba0Y5aZWmXpvk6 QYv1R/rV82Ixlb1oYan2EciO5OCDEVz2EZv14= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=W7O396Dpkc8w11+D6G7vFIT0Ma+p0Kej/8uwYhLi3Gfh56DgDOrs/WX5yl9SwWO5lU Jf1wWU4j9M1B6Q3smvVZLkYoI7h9fM9R9Ap5gSWXxTpNwfn8txFbjmjrTMHUJdknsacc BXDhom4/sC7h2XsOzZiZejCPvkd8zOHCzenso= Received: by 10.141.152.8 with SMTP id e8mr5615374rvo.19.1217548809614; Thu, 31 Jul 2008 17:00:09 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Thu, 31 Jul 2008 17:00:09 -0700 (PDT) Message-ID: <396556a20807311700w1eda50b0o5da7ae52e6c1691a@mail.gmail.com> Date: Thu, 31 Jul 2008 17:00:09 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <4890FBE8.1020203@isi.edu> MIME-Version: 1.0 Content-Disposition: inline References: <4890F4BE.6060302@isi.edu> <396556a20807301622l4cb33deuff73cd13d7a75ba1@mail.gmail.com> <4890FBE8.1020203@isi.edu> X-Google-Sender-Auth: 1d226f7a818a444d Cc: tcpm@ietf.org Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Wed, Jul 30, 2008 at 4:40 PM, Joe Touch wrote: > The current TSAD supports only a wildcard source port, which is > instantiated for the first connection received that matches. It expects > that the KMS installs additional keys as needed. I was assuming that the TSAD would support wildcards for source IPs and ports. I would also suggest that it's not a bad idea, although if it didn't happen, that's no problem. > The above appears to require that the KMS deploy the same key for all > potentially overlapping NAT'd connections. This adds a requirement to > the KMS, but suggests that the pseudoheader is included or excluded for > all connections to a host from a given IP address. Is that what is > intended, or can you clarify? If that is what is intended, how can the > KMS enforce this? Indeed, something would have to arrange for the pseudoheader to be excluded from the MAC input when a packet matches a wildcard source IP rule. Also, the same key would indeed be used by many connections. Thus the key should rotate based on the time (once a minute would be reasonable.) AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jul 31 18:05:22 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 775D63A6994; Thu, 31 Jul 2008 18:05:22 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5806B3A6947 for ; Thu, 31 Jul 2008 18:05: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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkFz-h+Yl-5O for ; Thu, 31 Jul 2008 18:05:15 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id C9D253A6B3C for ; Thu, 31 Jul 2008 18:04:40 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so724958rvf.49 for ; Thu, 31 Jul 2008 18:04:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=N+LPzuDE7+K1kiqf4DojaPWlAEY7IcNtJGXxOdZ9SVY=; b=YERrz7jaGdjBK4negw6kdhzTm62n1+GzZZykRI+98DMs5hFzK/3NKrlLyFNq59h89F cH2LLuqBc1RFOPs/BuKKwC+tS5dYcl5I404WFt1g9jE8f5dIY3FqDe+U4NxryMSQRL61 EdnY7EvU61lZVI1917EnX5Q9cAG/gYEMOecpE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=umOfvCIaDcK5nKUTU+FkR6kkf3xgrB1VDCuAm/3nem0fHj2/J51vblpMlX4SLyLPJL RP2JWYqjZGZcwl8kv2IQ6z2aucM12rjeCsC/v2mQ6O0nq91sWfLnmgZV3SEcGGcO1FXl 89Gl9j3UcLLVFSUDONUvkqhueoBKHQAcamHJs= Received: by 10.140.172.19 with SMTP id u19mr5639316rve.31.1217552699107; Thu, 31 Jul 2008 18:04:59 -0700 (PDT) Received: by 10.141.186.3 with HTTP; Thu, 31 Jul 2008 18:04:59 -0700 (PDT) Message-ID: <396556a20807311804s14169c14hfcf7d139475472f@mail.gmail.com> Date: Thu, 31 Jul 2008 18:04:59 -0700 From: "Adam Langley" To: "Joe Touch" In-Reply-To: <396556a20807311640w2b17d447ud0c51241dc84f682@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20807311252j67b1ab26mf6511dbdae780fdd@mail.gmail.com> <48924496.9060907@isi.edu> <396556a20807311640w2b17d447ud0c51241dc84f682@mail.gmail.com> X-Google-Sender-Auth: 0245077a57f1c39b Cc: tcpm@ietf.org Subject: Re: [tcpm] Faster application handshakes with SYN/ACK payloads X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org I've updated the draft with the following changes: * Fixed the wording around retransmissions which mistakenly suggested that no packets of any type could be transmitted without payloads * Renamed the flag to SYNACK Payloads Processed * Required that the flag be echoed in resulting SYNACK frames * Added discussion of simultaneous open * Added discussion of SYNACKs with payloads that are nothing to do with this spec, noting that they are still permitted I'll wait to see if there are more comments on -00 before publishing -01. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm