Re: [Tsvwg] WGLC for Port Randomization starts now (April 1st)

Randy Stewart <randall@lakerest.net> Thu, 28 May 2009 01:30 UTC

Return-Path: <randall@lakerest.net>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40B5228C112 for <tsvwg@core3.amsl.com>; Wed, 27 May 2009 18:30: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 CGHOxEvQm5yW for <tsvwg@core3.amsl.com>; Wed, 27 May 2009 18:30:28 -0700 (PDT)
Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by core3.amsl.com (Postfix) with ESMTP id 772FF28C106 for <tsvwg@ietf.org>; Wed, 27 May 2009 18:30:27 -0700 (PDT)
Received: from [192.168.1.118] (cpe-066-057-254-179.nc.res.rr.com [66.57.254.179]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id n4S1Ve5Z044449 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 May 2009 21:31:42 -0400 (EDT) (envelope-from randall@lakerest.net)
DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1243474303; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=ISJmwooGlJQkDHyNOKORXyVkJqrzkjm8prutRpI8bAsLLXbQn8nQqOi OcBghgQxwfgUAHe+/S8j/VicUH1BnVg==
Message-Id: <B2FDDB1D-CBA0-47A9-B7F7-E1079B0D139E@lakerest.net>
From: Randy Stewart <randall@lakerest.net>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <4A1DBA7C.6010306@isi.edu>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Wed, 27 May 2009 21:31:35 -0400
References: <20090415033307.F00C0CD585E@lawyers.icir.org> <4A037030.6040107@isi.edu> <0C53DCFB700D144284A584F54711EC58074EEED6@xmb-sjc-21c.amer.cisco.com> <4A1AB6EE.5080900@gont.com.ar> <0C53DCFB700D144284A584F54711EC58074EEF11@xmb-sjc-21c.amer.cisco.com> <4A1BF56D.3020709@isi.edu> <0C53DCFB700D144284A584F54711EC58074EF74C@xmb-sjc-21c.amer.cisco.com> <4A1D6F4E.2080005@isi.edu> <20090527220517.GA7778@openss7.org> <4A1DBA7C.6010306@isi.edu>
X-Mailer: Apple Mail (2.935.3)
Cc: "James Polk (jmpolk)" <jmpolk@cisco.com>, "Anantha Ramaiah (ananth)" <ananth@cisco.com>, tsvwg <tsvwg@ietf.org>, mallman@icir.org, Fernando Gont <fernando@gont.com.ar>
Subject: Re: [Tsvwg] WGLC for Port Randomization starts now (April 1st)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2009 01:30:29 -0000

Joe:

Just a few comments ;)


On May 27, 2009, at 6:11 PM, Joe Touch wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Brian F. G. Bidulock wrote:
>> Joe,
>>
>> You can hold the old tag long enough to get a new one: a few
>> nanoseconds or so...
>
> Sure. Do that a few times, then have packets with the old tag show up
> and tell me what happens ;-)
>
> Yes, the space is big, but it's not infinite. Systems are well known  
> to
> seed 'random' generators with the same values on reboot. Overall, this
> sounds like "security by faith".
>
> Joe
>
>> Joe Touch wrote:                                (Wed, 27 May 2009  
>> 09:50:22)
>>> While I agree that the term "TIME-WAIT" does not appear in RFC 2690,

Its actually 2960 ... but of course thats obsolete anyway and the
new document is 4960.

Now it too does not mention time-wait.. but I agree with you 100%... its
implicit in the fact its the only way you will be able to assure that
its not used... Thats exactly why we put this in the BSD  
implementation. Its
probably one of the things we should have added to 4960.. I know we
had discussed it on this list previously... but it never made it
into the errata document. It most likely would have been a SHOULD
so I guess implementations could still not do it and claim to
be fully compliant... but IMO you really need to time-wait the
vtag's.



R

>>>
>>> there is a note:
>>>
>>> " A new Verification Tag value MUST be used each time the
>>>   endpoint tears-down and then re-establishes an association to the
>>>   same peer."
>>>
>>> Can you explain how you know that the tag is new unless you hold  
>>> it for
>>> some period of time?
>>>
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkodunwACgkQE5f5cImnZrsjEACfTl4Auix1CYhX1KgLNQh7S1R8
> 6xEAnA3BGTnf8KhQjylHAsRZXtkCUkrE
> =KBIL
> -----END PGP SIGNATURE-----
>

-----
Randall Stewart
randall@lakerest.net