[tcpm] Jerry Leichter: [Fwd: Re: On the implementation of TCP urgent data (IETF Internet Draft)]

[Fernando Gont <[e-mail]>]

FYI

-------- Original Message --------
Subject: Re: On the implementation of TCP urgent data (IETF Internet Draft)
Date: Sat, 28 Feb 2009 16:51:55 -0500
From: Jerry Leichter <[e-mail]>
To: Fernando Gont <[e-mail]>
CC: Bill Squier <[e-mail]>, Christos Zoulas
<[e-mail]>,        [e-mail], James Chacon
<[e-mail]>, [e-mail],        [e-mail]
References: <[e-mail]>
<[e-mail]>
<[e-mail]>

I haven't seen a copy of the paper, so I have to respond indirectly.

Microsoft confirmed the problem.  It was present in all their stacks
prior to Vista.  Based on our repeated complaints, they eventually
produced a patch for XP.  For some time, it was one of their "if you
know to ask we'll give it to you" patches.  For all I know, they
eventually decided to roll it in to some regular patch release.

The "OOB data leaking in line" has many causes.  I know of at least
two completely different mechanisms:

	- On the sender, the problem can occur because you can only send
		one OOB byte per segment, but there is no correlation
		between segments and OOB write requests.  Consider the
		situation where the segmentation code wants to send a
		segment, and within the range of bytes it wants to send,
		there are two that were marked OOB.  The only way to handle
		this correctly is to send two segments, even if one of them
		is artificially short - perhaps even a single byte.  I
		haven't checked implementations in detail, but I've
		never seen this mentioned and I would be surprised if
		implementations get this right.

	- On the receiver, there is a messy case, the details of which
		I forget, in which the implementation doesn't keep enough
		state to properly handle two "close" OOB bytes.  If you
		look in Stevens, he actually reproduces a comment from
		the original BSD code which describes the problem, but
		basically says "you lose".  It's not clear anyone ever
		bothered to fix this.

The fundamental issue is this:  OOB bytes exist at the socket API
level, but there is no such concept at the TCP level.  The urgent
pointer exists at the TCP level, but it's basically invisible at the
socket API level.  The theory is that you can use the urgent pointer
to implement OOB bytes - and, in fact, that's true.  I've convinced
myself of this by writing out a semi-formal definition of the
theoretical semantics at the two levels and sketching an
implementation that actually presents the right semantics at the
socket API level.  I'm pretty sure that no one actually implements
this right other than Microsoft (ironically) because it requires the
ability to allocate space for OOB bytes at the receiver dynamically,
and I know of no implementations that do so other than Microsoft's.
By counting the allocated bytes against the window size you are
willing you offer, you can avoid the problem that MS ran into, where
there's no way to bound the amount of space allocated.  The
implementation is potentially expensive, but it's only expensive for
applications that actually send many OOB bytes - which is a reasonable
tradeoff.

What actually happens is that the TCP stack implementers seem never to
have believed in OOB on general principles, and in any case it seems
that the TCP stack implementors (the network guys) and the socket API
implementers (the OS guys) don't seem to talk to each other much.  So
this delicate implementation issue, which lives exactly at the
interface between the two, gets lost in the shuffle.  (Note that the
multiple-OOB-bytes-in-a-segment problem probably cannot be solved
without changing the TCP stack/socket API interface, since typically
there is no way for the segmentation layer even to *see* that there
are multiple outstanding OOB bytes:  The only available interface is a
single urgent pointer value that gets passed across.)

There's an even more fundamental problem that it's worth pointing
out:  The actual urgent pointer protocol has a flaw.  The UP is a 16-
bit offset into the stream.  As long as no segment can be more than
2^16 bytes - as was true when TCP was designed, because the windows
size is represented in 16 bits - this works.  But if you use scaled
windows, it's possible to be in a situation where you need to send a
UP value that cannot be represented, because it's too far into a large
segment.  There's an obvious work-around - send a short segment when
this happens - but I doubt anyone does this.  In fact, I would guess
that the offset gets calculated ignoring the 16-bit limitation and the
actual UP sent is the lower 16 bits of the true UP.  Obviously, this
can cause severe problems to any use of TCP that actually relies on
the UP being correct!

Finally, there's yet another level of problem:  Some router-like
devices (Cisco PIX firewalls - in their default configuration! - are a
known example) simply turn off the Urgent bit!  This is to block a
very old (10+ years?) Windows bug.  However, this is a disaster for
any program that actually relies on OOB data/the UP.
                                                        -- Jerry


On Feb 28, 2009, at 3:36 PM, Fernando Gont wrote:

> Bill Squier wrote:
>
> (Added Andrew Yourtchenko (draft co-author) to the recipient's list)
>
> Comments inline...
>
>
>> I haven't had time to read the article completely, but I did skim the
>> Windows section, and Christos is correct.
>
> IIRC, we did the windows tests with cygwin. Maybe this is what lead to
> different results?
>
> That said, the next version of our Internet Draft will include text
> describing the buggy implementations you are referring to.
>
>
>> Further, I noticed that some of your analysis discusses OOB data
>> bleeding in-line.  This is almost certainly caused by an  
>> interaction (on
>> the _sender_) of Nagle and the fact that TCP defines only a single  
>> OOB
>> pointer.  The receiver is not returning bytes which it knows to be  
>> OOB
>> bytes inline, the _sender_ is accidentally placing more than a single
>> byte of OOB in each packet that it sends.
>
> There is no problem with that. TCP just provides a mechanism for  
> marking
> the end of urgent data. Just a mark.
>
>
>
>> The receiver has no way to know that, as the only means of  
>> communication
>> about OOB data between sender and receiver is a single pointer.
>
> Exactly. Any data that's before the pointer should be considered  
> "urgent".
>
> Thanks!
>
> Kind regards,
> -- 
> Fernando Gont
> e-mail: [e-mail] || [e-mail]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
>
>



-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1






Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8B4E3A6941 for <[e-mail]>; Wed,  4 Feb 2009 06:16:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.742
X-Spam-Level: 
X-Spam-Status: No, score=-1.742 tagged_above=-999 required=5 tests=[AWL=0.257,  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 iPHQ1+Ptrogs for <[e-mail]>; Wed,  4 Feb 2009 06:16:53 -0800 (PST)
Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 424F23A6937 for <[e-mail]>; Wed,  4 Feb 2009 06:16:53 -0800 (PST)
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id n14EGWGW018870; Wed, 4 Feb 2009 06:16:33 -0800
Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id A99DA37CEACE; Wed,  4 Feb 2009 09:16:20 -0500 (EST)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id A3D27BE1120; Wed,  4 Feb 2009 09:16:12 -0500 (EST)
To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[e-mail]>
From: Mark Allman <[e-mail]>
In-Reply-To: <[e-mail]> 
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Lodi
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma41772-1"; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Wed, 04 Feb 2009 09:16:12 -0500
Sender: [e-mail]
Message-Id: <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], Sally Floyd <[e-mail]>, [e-mail]
Subject: Re: [tcpm] ECNSYN change review
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 04 Feb 2009 14:16:54 -0000

----------ma41772-1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

> As discussed in Minneapolis, we need a couple of people
> to look again at the ECNSYN draft and sanity-check the
> changes:
> http://tools.ietf.org/html/draft-ietf-tcpm-ecnsyn-07
> 
> The background is that this cleared WGLC some time ago,
> but the authors made some changes based on further
> simulation results.  They felt the changes warranted
> the WG having a look at, so if a couple of people can
> coomment on them, it would be good.

I looked over the diffs between 06 and 07 and my quick reaction is that
I like the changes.  I previously championed the position that a marked
SYN+ACK should result in a reduction of the initial cwnd plus the
waiting of an RTO (as would have happened without ECN).  We got some
consensus that this was too conservative and so that's OK.  But, I like
this "TryOnce" scheme as a hybrid between waiting for an RTO and sending
immediately.  It seems to slice things just about right and the results
in the draft are quite nice.  I support this version being forwarded
on, FWIW.

allman




----------ma41772-1
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkmJoywACgkQWyrrWs4yIs6d0gCfT1wnetFLw7fOA0uG9VcYmnc7
NvsAniNehnSW32tNYIyg3g+zQVo5VR0s
=3pN2
-----END PGP SIGNATURE-----
----------ma41772-1--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1783528C1DE for <[e-mail]>; Thu,  5 Feb 2009 09:48:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.594
X-Spam-Level: 
X-Spam-Status: No, score=-3.594 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 uj7gX5lnGqag for <[e-mail]>; Thu,  5 Feb 2009 09:48:22 -0800 (PST)
Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 284F328C1D5 for <[e-mail]>; Thu,  5 Feb 2009 09:48:21 -0800 (PST)
MIME-version: 1.0
Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 05 Feb 2009 18:47:59 +0100 (CET)
X-IronPort-AV: E=Sophos; i="4.37,386,1231110000"; d="sig'?scan'208"; a="558990"
Received: from smarthost-2.ms.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.7.90]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 05 Feb 2009 18:47:54 +0100
Received: from chicago.informatik.RWTH-Aachen.DE (chicago.informatik.RWTH-Aachen.DE [137.226.12.187]) by smarthost.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id n15HlsEj027687; Thu, 05 Feb 2009 18:47:54 +0100 (CET)
Message-id: <[e-mail]>
From: Alexander Zimmermann <[e-mail]>
To: Fernando Gont <[e-mail]>
Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-66--1688308
Content-transfer-encoding: 7bit
Date: Thu, 05 Feb 2009 18:47:45 +0100
X-Pgp-Agent: GPGMail 1.2.0 (v56)
X-Mailer: Apple Mail (2.930.3)
Cc: [e-mail]
Subject: [tcpm] I-D TCP Soft Error
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2009 17:48:23 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-66--1688308
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

Hi Fernando,

I don't know, maybe it' to late, however I found two spellings  
mistakes in your draft:

page 11: behaviour => behavior (since we want to be consistent) :-)
page 11: addressses => addresses

Alex


//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: [phone], fax: [phone]
// email: [e-mail]
// web: http://www.umic-mesh.net
//


--Apple-Mail-66--1688308
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: Signierter Teil der Nachricht
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkmLJkEACgkQdyiq39b9uS7VjgCgnuoudS0GBoSakpFyjuAznMHp
ix4An2ywJ8nTQixhqD60yXRfl4rsRyot
=XLRw
-----END PGP SIGNATURE-----

--Apple-Mail-66--1688308--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D81D3A6930 for <[e-mail]>; Sun,  8 Feb 2009 23:03:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.471
X-Spam-Level: 
X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.084,  BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044]
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 hJeYJcJiGyFy for <[e-mail]>; Sun,  8 Feb 2009 23:03:05 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 577983A67AD for <[e-mail]>; Sun,  8 Feb 2009 23:03:05 -0800 (PST)
Received: from [192.168.1.39] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n1972ESL013810; Sun, 8 Feb 2009 23:02:16 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sun, 08 Feb 2009 18:50:57 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Satyadeva Konduru <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Allison Mankin <[e-mail]>
Subject: Re: [tcpm] TCP-AO: Text for New_Key Process
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2009 07:03:06 -0000

Hi, Satya,

Satyadeva Konduru wrote:
> On 1/27/09 1:34 PM, "Joe Touch" <[e-mail]> wrote:
> 
>> I'll kick off discussion on this point on the list.
>>
>> IMO, this mechanism is not viable for TCP-AO; it requires generating
>> (and consuming) TCP segments that a native TCP would not generate. I was
> 
> SK> The 'consuming' part of the TCP probes is handled natively by the TCP
> stack i.e. no change is needed in receiving or processing a probe. If the
> probe uses a new key id and the authentication succeeds, the receiving host
> moves to the new key id. This part of code is common to any in-band key
> switchover.
> 
> SK> Only the 'generating' part needs to be done outside the native TCP
> stack. But, it is a simple piece of code that generates the probes with an
> exponential back off timer needed in case key switchover fails. The probe
> just has to get the latest sequence number from the tcpcb.

Probes thus generated could result in lost regular TCP frames, e.g., 
esp. on low BW links.

>> under the assumption that our design space was as close to TCP MD5 as
>> possible, i.e., augment existing segments with a new option, but neither
>> generate nor consume new segments.
>>
>> The goal appears to be synchronization of the use of new keys. It seems
>> like this can be achieved operationally, e.g., as follows:
>>
>> both sides start with master key A
>>
>> both sides insert master key A with KeyID=5
>>
>> both sides connect as expected
>>
>> To enable a rapid synchronization of the next key:
>>
>> both sides also reinsert master key A with KeyID=6
> 
> SK> You are assuming that both sides are running the 'new' version of TCP AO
> code which is finalized by this draft. But in real deployments, you need to
> consider a mix of hosts, some running older versions and some running new
> versions.

There is only one version of TCP-AO - the one specified in this draft. 
Until it is finalized as a draft standard in RFC, all deployments need 
to be controlled to avoid interference. This is probably easy because 
the TCP option number for TCP-AO cannot be assigned by IANA until the 
RFC is in the final phases of publication.

Joe

> SK> Hosts running older versions do not switchover to the new key in the
> middle of a TCP connection. They also do not have this KeyID 6. So, they
> just drop all packets coming with KeyID 6 causing significant outages. Given
> this, network admins would never be able to update the keys on their boxes
> as a part of their maintenance.
> 
> Correct me if I am wrong.
> -satya.
> 
>> At this point, either KeyID=5 or KeyID=6 will work, but both sides use
>> KeyID=5 (by configuration).
>>
>> Now let's assume we want to add a new key for that connection, but also
>> to coordinate its use.
>>
>> both sides receive master key B (out-of-band)
>>
>> both sides insert master key B with KeyID=7
>>
>> Either side, upon inserting master key B, starts using KeyID=6. Note
>> that there is no loss of packets, because 6 was there back when 5 was.
>>
>> Both sides monitor the keys being received; when keyid=6 is received,
>> then they can start using KeyID=7.
>>
>> I.e., this can be done entirely with an external KMS local to each
>> endpoint, without requiring the KMS's to communicate. I.e., this is
>> automated, but doesn't require a protocol.
>>
>> To some extent, this restores some of the intent of Bonica's "K" bit,
>> but there's no need for an explicit bit, and there's no limit to how
>> quickly the keyID changes happen (i.e., no need to sync when the bit
>> needs to be cleared or for how long).
>>
>> We can put this into the doc, but IMO, it's not necessary at all. It's
>> completely isolated to the KMS anyway. I had already updated the API to
>> be able to return samples of the received KeyIDs, FWIW...
>>
>> Joe
>>
>> Gregory M. Lebovitz wrote:
>>> Folks,
>>> resend...
>>>
>>> Neither I nor Joe have received ANY feedback on this New_Key process.
>>> Can people pls do a quick review and reply to me, Joe, and list with
>>> comments? Joe is trying to get a next version out.
>>>
>>> Many thanks,
>>> Gregory.
> 



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A475A3A67CC for <[e-mail]>; Mon,  9 Feb 2009 22:04:00 -0800 (PST)
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 K2hI8P13fLzN for <[e-mail]>; Mon,  9 Feb 2009 22:03:59 -0800 (PST)
Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by core3.amsl.com (Postfix) with ESMTP id 8F1203A68A9 for <[e-mail]>; Mon,  9 Feb 2009 22:03:59 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Received: from [192.168.1.85] ([70.132.6.169]) by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <[e-mail]> for [e-mail]; Mon, 09 Feb 2009 22:04:00 -0800 (PST)
Message-id: <[e-mail]>
From: Sally Floyd <[e-mail]>
To: Mark Allman <[e-mail]>, Wesley Eddy <[e-mail]>, David Borman <[e-mail]>
In-reply-to: <[e-mail]>
Date: Mon, 09 Feb 2009 22:03:57 -0800
References: <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
Cc: "K. K. Ramakrishnan" <[e-mail]>, tcpm <[e-mail]>, Amit Mondal <[e-mail]>, Aleksandar Kuzmanovic <[e-mail]>
Subject: Re: [tcpm] ECNSYN change review
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 10 Feb 2009 06:04:00 -0000

Mark -

On Feb 4, 2009, at 6:16 AM, Mark Allman wrote:

(Wesley Eddy:)
>> As discussed in Minneapolis, we need a couple of people
>> to look again at the ECNSYN draft and sanity-check the
>> changes:
>> http://tools.ietf.org/html/draft-ietf-tcpm-ecnsyn-07
>>
>> The background is that this cleared WGLC some time ago,
>> but the authors made some changes based on further
>> simulation results.  They felt the changes warranted
>> the WG having a look at, so if a couple of people can
>> coomment on them, it would be good.

(Mark Allman:)
> I looked over the diffs between 06 and 07 and my quick reaction is  
> that
> I like the changes.  I previously championed the position that a  
> marked
> SYN+ACK should result in a reduction of the initial cwnd plus the
> waiting of an RTO (as would have happened without ECN).  We got some
> consensus that this was too conservative and so that's OK.  But, I  
> like
> this "TryOnce" scheme as a hybrid between waiting for an RTO and  
> sending
> immediately.  It seems to slice things just about right and the  
> results
> in the draft are quite nice.  I support this version being forwarded
> on, FWIW.

Many thanks for the feedback.



To the Working Group co-chairs:

The draft draft-ietf-tcpm-ecnsyn-05.txt was forwarded to the IESG
  for review on 3/11/08.

However, before going to IESG Last Call, we reran the simulations
with the most recent version of the ns-2 simulator, and as a result
made a change to the mechanism in the draft.  This change is in
draft-ietf-tcpm-ecnsyn-07.txt, from November 2008, and was reported
to the working group in email of 11/5/08 and 11/18/08.  In that
email, we suggested that the change should be passed though the
working group again before continuing with review in the IESG.

As authors of the draft, we will wait until the working group co-chars
have decided that the document is ready to be forwarded back to the
IESG for review...

Many thanks,
- Sally
http://www.icir.org/floyd/



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE8103A6907 for <[e-mail]>; Tue, 10 Feb 2009 00:11:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 xx0OQwkxsP1H for <[e-mail]>; Tue, 10 Feb 2009 00:11:38 -0800 (PST)
Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 1B9263A68DF for <[e-mail]>; Tue, 10 Feb 2009 00:11:36 -0800 (PST)
Received: from dhcp150.dagstuhl.de (dhcp150.dagstuhl.de [192.76.146.150]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n1A8Axl3052353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 10 Feb 2009 10:11:00 +0200 (EET) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Lars Eggert <[e-mail]>
To: Sally Floyd <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; boundary=Apple-Mail-131-395699481; micalg=sha1; protocol="application/pkcs7-signature"
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Tue, 10 Feb 2009 09:10:53 +0100
References: <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [212.213.221.39]); Tue, 10 Feb 2009 10:11:04 +0200 (EET)
X-Virus-Scanned: ClamAV 0.94.2/8970/Tue Feb 10 04:52:04 2009 on fit.nokia.com
X-Virus-Status: Clean
Cc: tcpm <[e-mail]>, David Borman <[e-mail]>, Amit Mondal <[e-mail]>, Mark Allman <[e-mail]>, "K. K. Ramakrishnan" <[e-mail]>, Wesley Eddy <[e-mail]>, Aleksandar Kuzmanovic <[e-mail]>
Subject: Re: [tcpm] ECNSYN change review
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 10 Feb 2009 08:11:38 -0000

--Apple-Mail-131-395699481
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Hi,

On 2009-2-10, at 7:03, Sally Floyd wrote:
> The draft draft-ietf-tcpm-ecnsyn-05.txt was forwarded to the IESG
>  for review on 3/11/08.
>
> However, before going to IESG Last Call, we reran the simulations
> with the most recent version of the ns-2 simulator, and as a result
> made a change to the mechanism in the draft.  This change is in
> draft-ietf-tcpm-ecnsyn-07.txt, from November 2008, and was reported
> to the working group in email of 11/5/08 and 11/18/08.  In that
> email, we suggested that the change should be passed though the
> working group again before continuing with review in the IESG.
>
> As authors of the draft, we will wait until the working group co-chars
> have decided that the document is ready to be forwarded back to the
> IESG for review...

given that there's been a technical change to the mechanism, I believe  
it'd be best if we reestablished that there is WG and IETF consensus  
before moving on, i.e., rerunning the two last calls.

Lars
--Apple-Mail-131-395699481
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw
ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz
OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy
dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W
571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0
6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs
VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY
ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV
HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF
AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb
6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d
ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ
BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg
RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3
DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3
MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9
fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+
uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB
Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3
dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG
A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP
f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH
2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x
ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo
UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ
SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB
MBwGCSqGSIb3DQEJBTEPFw0wOTAyMTAwODEwNTNaMCMGCSqGSIb3DQEJBDEWBBTmxn5d7TTRTljb
/S8tlUbRgIt8wzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw
DQYJKoZIhvcNAQEBBQAEggEAiTIfhtsMQl22FcDJI6f1GrKLslXLCDtCjrsLyytVTwCn093naPAR
JIAr5ZNpJ+WdzeJtI/DzwRaQA5okWUEYBPVxg7Meggpiably5NdIE77EzE77BklmvhGodGVM3UKV
jKvl2rS3Y3Aa0hPdheOxbiqBwjbjWUbojfgkT2xcAmS3aLuP5azEcWd9IPqtrGho4Pnw4vj61h/q
yPP1GQmmTBEmZJZwrca6Cm2FnDNDHFACz5km4TwJW2q1RomEvoHdO4a5zke3VQZFmssspnK747mY
w4dHAQMFv5tkHr2NwaVa1uguyZSCgdLlZONwddDRCqmLidXbMWm2rVwKBMP+SgAAAAAAAA==

--Apple-Mail-131-395699481--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C1683A6B96 for <[e-mail]>; Tue, 10 Feb 2009 11:01:40 -0800 (PST)
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]
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 ATtDHPaZDblu for <[e-mail]>; Tue, 10 Feb 2009 11:01:39 -0800 (PST)
Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by core3.amsl.com (Postfix) with ESMTP id 8A2CD3A6B7B for <[e-mail]>; Tue, 10 Feb 2009 11:01:39 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Received: from [192.168.1.85] ([70.132.6.169]) by asmtp021.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <[e-mail]> for [e-mail]; Tue, 10 Feb 2009 11:01:25 -0800 (PST)
Message-id: <[e-mail]>
From: Sally Floyd <[e-mail]>
To: Lars Eggert <[e-mail]>
In-reply-to: <[e-mail]>
Date: Tue, 10 Feb 2009 11:01:26 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
Cc: tcpm <[e-mail]>, David Borman <[e-mail]>, Amit Mondal <[e-mail]>, Mark Allman <[e-mail]>, "K. K. Ramakrishnan" <[e-mail]>, Wesley Eddy <[e-mail]>, Aleksandar Kuzmanovic <[e-mail]>
Subject: Re: [tcpm] ECNSYN change review
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 10 Feb 2009 19:01:40 -0000

Lars -

>> The draft draft-ietf-tcpm-ecnsyn-05.txt was forwarded to the IESG
>> for review on 3/11/08.
>>
>> However, before going to IESG Last Call, we reran the simulations
>> with the most recent version of the ns-2 simulator, and as a result
>> made a change to the mechanism in the draft.  This change is in
>> draft-ietf-tcpm-ecnsyn-07.txt, from November 2008, and was reported
>> to the working group in email of 11/5/08 and 11/18/08.  In that
>> email, we suggested that the change should be passed though the
>> working group again before continuing with review in the IESG.
>>
>> As authors of the draft, we will wait until the working group co- 
>> chars
>> have decided that the document is ready to be forwarded back to the
>> IESG for review...
>
> given that there's been a technical change to the mechanism, I  
> believe it'd be best if we reestablished that there is WG and IETF  
> consensus before moving on, i.e., rerunning the two last calls.

That is fine by me to rerun WG last call.  The draft never made it to
IESG Last Call, I believe, so the draft has to go through that in any
case.

- Sally
http://www.icir.org/floyd/



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 837D73A6BD2 for <[e-mail]>; Thu, 12 Feb 2009 13:24:33 -0800 (PST)
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 0jz1oTsD8mIK for <[e-mail]>; Thu, 12 Feb 2009 13:24:32 -0800 (PST)
Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id 8F1603A6781 for <[e-mail]>; Thu, 12 Feb 2009 13:24:32 -0800 (PST)
Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id A72E7A83C5 for <[e-mail]>; Thu, 12 Feb 2009 15:24:37 -0600 (CST)
Received: from ndjshub02.ndc.nasa.gov (ndjshub02.ndc.nasa.gov [198.117.4.161] (may be forged)) by ndjsppt02.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id n1CLOfKd028638 for <[e-mail]>; Thu, 12 Feb 2009 15:24:41 -0600
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.4.161]) with mapi; Thu, 12 Feb 2009 15:24:37 -0600
From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Thu, 12 Feb 2009 15:24:38 -0600
Thread-Topic: [tcpm] [Fwd: New Version Notification for draft-gont-tcpm-urgent-data-01]
Thread-Index: AcmFw3PEbSrG/xyWQdOcOUDuSITGsgHktSGA
Message-ID: <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [tcpm] [Fwd: New Version Notification for	draft-gont-tcpm-urgent-data-01]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 12 Feb 2009 21:24:33 -0000

This draft was discussed on the list somewhat in the last few months, and
there was a short presentation on it in Minneapolis.  In order to determine
whether there might be sufficient support for it as a WG item, the chairs
need more people to read it and share comments on it.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: [phone]
---------------------------
=20


>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On=20
>Behalf Of Fernando Gont
>Sent: Tuesday, February 03, 2009 12:51 AM
>To: [e-mail]
>Subject: [tcpm] [Fwd: New Version Notification for=20
>draft-gont-tcpm-urgent-data-01]
>
>Hello, folks,
>
>We have published a revision of our TCP urgent data I-D. It's available
>at: http://tools.ietf.org/id/draft-gont-tcpm-urgent-data-01.txt .
>
>Any feedback will be more than welcome.
>
>Thanks!
>
>Kind regards,
>Fernando
>
>
>
>
>-------- Original Message --------
>Subject: New Version Notification for draft-gont-tcpm-urgent-data-01
>Date: Mon,  2 Feb 2009 21:43:43 -0800 (PST)
>From: IETF I-D Submission Tool <[e-mail]>
>To: [e-mail]
>CC: [e-mail]
>
>
>A new version of I-D, draft-gont-tcpm-urgent-data-01.txt has been
>successfuly submitted by Fernando Gont and posted to the IETF=20
>repository.
>
>Filename:	 draft-gont-tcpm-urgent-data
>Revision:	 01
>Title:		 On the implementation of TCP urgent data
>Creation_date:	 2009-02-02
>WG ID:		 Independent Submission
>Number_of_pages: 11
>
>Abstract:
>This document analyzes how current TCP implementations process TCP
>urgent indications, and how the behavior of some widely-deployed
>middle-boxes affect how urgent indications are processed by end
>systems.  This document updates the relevant specifications such that
>they accommodate current practice in processing TCP urgent
>indications, and raises awareness about the reliability of TCP urgent
>indications in the current Internet.
>
>
>
>
>The IETF Secretariat.
>
>
>
>
>--=20
>Fernando Gont
>e-mail: [e-mail] || [e-mail]
>PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
>
>
>_______________________________________________
>tcpm mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/tcpm
>=


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C24AE28C2E4 for <[e-mail]>; Thu, 12 Feb 2009 13:37:58 -0800 (PST)
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 OzWyeLADHDWe for <[e-mail]>; Thu, 12 Feb 2009 13:37:58 -0800 (PST)
Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by core3.amsl.com (Postfix) with ESMTP id 0807028C15A for <[e-mail]>; Thu, 12 Feb 2009 13:37:57 -0800 (PST)
Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 90F611809A3 for <[e-mail]>; Thu, 12 Feb 2009 15:38:03 -0600 (CST)
Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165] (may be forged)) by ndjsppt03.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id n1CLc5eX014086 for <[e-mail]>; Thu, 12 Feb 2009 15:38:05 -0600
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Thu, 12 Feb 2009 15:38:03 -0600
From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Thu, 12 Feb 2009 15:38:04 -0600
Thread-Topic: WGLC on draft-ietf-tcpm-ecnsyn-07
Thread-Index: AcmNWi+Ya3pZqG/4RliDzVko8ddq+w==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [tcpm] WGLC on draft-ietf-tcpm-ecnsyn-07
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 12 Feb 2009 21:37:58 -0000

The chairs would like to start are 1-week TCPM working group
last call on draft-ietf-tcpm-ecnsyn-07 starting now, as this
draft has previously cleared WGLC modulo some alterations,
and some support has been expressed for the modifications.
Please comment by February 20.

The draft is at:
http://tools.ietf.org/html/draft-ietf-tcpm-ecnsyn-07

It's targeted for Proposed Standard, and given the prior
clearance of the WGLC state, we'll assume lack of any
expressed concerns will mean that it's ready to go
forward.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: [phone]
---------------------------


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 587B63A6C33 for <[e-mail]>; Fri, 13 Feb 2009 00:22:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 PQyiWUcMFXYa for <[e-mail]>; Fri, 13 Feb 2009 00:22:31 -0800 (PST)
Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 966A33A67C0 for <[e-mail]>; Fri, 13 Feb 2009 00:22:31 -0800 (PST)
Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n1D8MXM4060259 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <[e-mail]>; Fri, 13 Feb 2009 10:22:33 +0200 (EET) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Lars Eggert <[e-mail]>
To: tcpm <[e-mail]>
Content-Type: multipart/signed; boundary=Apple-Mail-6-655599564; micalg=sha1; protocol="application/pkcs7-signature"
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Fri, 13 Feb 2009 10:22:33 +0200
References: <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Fri, 13 Feb 2009 10:22:33 +0200 (EET)
X-Virus-Scanned: ClamAV 0.94.2/8985/Fri Feb 13 00:11:57 2009 on fit.nokia.com
X-Virus-Status: Clean
Subject: [tcpm] Fwd: TCP security assessment
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 13 Feb 2009 08:22:33 -0000

--Apple-Mail-6-655599564
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

FYI

Begin forwarded message:
> http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf

Lars
--Apple-Mail-6-655599564
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw
ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz
OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy
dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W
571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0
6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs
VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY
ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV
HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF
AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb
6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d
ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ
BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg
RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3
DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3
MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9
fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+
uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB
Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3
dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG
A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP
f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH
2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x
ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo
UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ
SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB
MBwGCSqGSIb3DQEJBTEPFw0wOTAyMTMwODIyMzRaMCMGCSqGSIb3DQEJBDEWBBTv/XoOExgzxRGh
OfnuaVRUVXkflTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw
DQYJKoZIhvcNAQEBBQAEggEAR829LCXein3z8xTFfX86ubXrhxXLoJq+MZyDWHYcKAK8Cqfm8ef3
wS24ifEHSVxZLS5cfTxCyIuYAWA5lcSjqkq4eZJ8R0O6VDq9klg0KQwofLFCQ4wzFxsGMw56bcKr
O1wxlkUuFH5bW/lRhew2F9QCER3FYL683UpcUEg6g9LQV2t/HwO+RAv7YKrAndahNtl3aeyd2C2o
F8bCbDMWeb7w9ogpMdpFVpWLFapGV8ktj9jv6oAm+wSr1FwtpP5hzUiZsbbu04tpuWiPn4KRYihA
1KXCFvfe4NKOXjFfo11dKqj7TskxGKGD5bpcJQcNM9c1w1UWN2iNmFUL9mUOcAAAAAAAAA==

--Apple-Mail-6-655599564--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0) id 3BF723A6954; Mon, 16 Feb 2009 16:30:00 -0800 (PST)
From: [e-mail]
To: [e-mail]
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon, 16 Feb 2009 16:30:01 -0800 (PST)
Cc: [e-mail]
Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-03.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 17 Feb 2009 00:30:01 -0000

--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-03.txt
	Pages           : 40
	Date            : 2009-02-16

This document specifies the TCP Authentication Option (TCP-AO), which 
obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO 
specifies the use of stronger Message Authentication Codes (MACs), 
protects against replays even for long-lived TCP connections, and 
provides more details on the association of security with TCP 
connections than TCP MD5. TCP-AO is compatible with either static 
master key configuration or an external, out-of-band master key 
management mechanism; in either case, TCP-AO also protects 
connections when using the same master key across repeated instances 
of a connection, using connection keys derived from the master key. 
The result is intended to support current infrastructure uses of TCP 
MD5, such as to protect long-lived connections (as used, e.g., in BGP 
and LDP), and to support a larger set of MACs with minimal other 
system and operational changes. TCP-AO uses its own option 
identifier, even though used mutually exclusive of TCP MD5 on a given 
TCP connection. TCP-AO supports IPv6, and is fully compatible with 
the requirements for the replacement of TCP MD5.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-03.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-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7632F28C128 for <[e-mail]>; Tue, 17 Feb 2009 07:47:25 -0800 (PST)
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 rk51aFqVvdD2 for <[e-mail]>; Tue, 17 Feb 2009 07:47:24 -0800 (PST)
Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 2A15A28C126 for <[e-mail]>; Tue, 17 Feb 2009 07:47:24 -0800 (PST)
Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 4F8253283DD for <[e-mail]>; Tue, 17 Feb 2009 09:47:34 -0600 (CST)
Received: from ndjshub02.ndc.nasa.gov (ndjshub02.ndc.nasa.gov [198.117.4.161] (may be forged)) by ndjsppt02.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id n1HFldM3006967 for <[e-mail]>; Tue, 17 Feb 2009 09:47:39 -0600
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.4.161]) with mapi; Tue, 17 Feb 2009 09:47:33 -0600
From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Tue, 17 Feb 2009 09:47:33 -0600
Thread-Topic: Errata ID #1496 on RFC 793
Thread-Index: AcmRFwwnjZw9ssd5QduG0mHfslcV6w==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [tcpm] Errata ID #1496 on RFC 793
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 17 Feb 2009 15:47:25 -0000

As part of processing the list of errata that've been
submitted to the RFC-Editor, TCPM is being asked to
review a few of the submissions.  This first one is
regarding RFC 793, and the change of a state name in
one part of the protocol description:
http://www.rfc-editor.org/errata_search.php?eid=3D1496

The purpose of TCPM's review is to determine if the
errata type (technical versus editorial) is correct,
and then decide how to handle it.

Two questions for the WG to consider:

(1) Is the errata type "Technical" correct for this
    change of state "CLOSING" to "LAST-ACK"?

(2) Should this errata be:

   o Approved - The erratum is appropriate under the criteria below and
     should be available to implementors or people deploying the RFC.

   o Rejected - The erratum is in error, or proposes a change to the
     RFC that should be done my publishing a new RFC that replaces the
     current RFC. In the latter case, if the change is to be
     considered for future updates of the document, it should be
     proposed using channels other than the errata process, such as a
     WG mailing list.

   o Hold for Document Update - The erratum is not a necessary update
     to the RFC. However, any future update of the document might
     consider this erratum, and determine whether it is correct and
     merits including in the update.


Some guidelines from the IESG:
>   1. Only errors that could cause implementation or deployment
>   problems or significant confusion should be Approved.
>
>   2. Things that are clearly wrong but could not cause an
>   implementation or deployment problem should be Hold for Document
>   Update.
>
>   3. Errata on obsolete RFCs should be treated the same as errata on
>   RFCs that are not obsolete where there is strong evidence that
>   some people are still making use of the related technology.
>
>   4. Trivial grammar corrections should be Hold for Document Update.
>
>   5. Typographical errors which would not cause any confusions to
>   implementation or deployments should be Hold for Document Update.
>
>   6. Changes which are simply stylistic issues or simply make things
>   read better should be Hold for Document Update.
>
>   7. Changes that modify the working of a protocol to something that
>   might be different from the intended consensus when the document
>   was approved should be either Hold for Document Update or
>   Rejected. Deciding between these two depends on judgment.
>   Changes that are clearly modifications to the intended consensus,
>   or involve large textual changes, should be Rejected. In unclear
>   situations, small changes can be Hold for Document Update.
>
>   8. Changes that modify the working of a process, such as changing an
>   IANA registration procedure, to something that might be different
>   from the intended consensus when the document was approved should
>   be Rejected.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: [phone]
---------------------------


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76C1C3A69C7 for <[e-mail]>; Tue, 17 Feb 2009 09:49:30 -0800 (PST)
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 zsD+4i6ZA8bJ for <[e-mail]>; Tue, 17 Feb 2009 09:49:29 -0800 (PST)
Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by core3.amsl.com (Postfix) with ESMTP id B4B493A693C for <[e-mail]>; Tue, 17 Feb 2009 09:49:29 -0800 (PST)
Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id B1E412600C5; Tue, 17 Feb 2009 11:49:39 -0600 (CST)
Received: from ndjshub03.ndc.nasa.gov (ndjshub03.ndc.nasa.gov [198.117.4.162] (may be forged)) by ndjsppt02.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id n1HHni4u002636;  Tue, 17 Feb 2009 11:49:44 -0600
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Tue, 17 Feb 2009 11:49:39 -0600
From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Tue, 17 Feb 2009 11:49:36 -0600
Thread-Topic: IETF 74 Meeting
Thread-Index: AcmRKBlj3FoxYwd4Qx+FVMQHlPNGKA==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: David Borman <[e-mail]>
Subject: [tcpm] IETF 74 Meeting
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 17 Feb 2009 17:49:30 -0000

On the draft agenda for IETF 74 in San Francisco, the
TCPM meeting has been scheduled for Monday afternoon
from 17:40 - 19:40 in the "Breakout 5" room.

To request presentation slots, please send David and
I the:
- presentation name
- presenter name
- expected time needed

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: [phone]
---------------------------


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2789528C177 for <[e-mail]>; Wed, 18 Feb 2009 11:05:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.504
X-Spam-Level: ***
X-Spam-Status: No, score=3.504 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 mRcdjbG2qD4T for <[e-mail]>; Wed, 18 Feb 2009 11:05:53 -0800 (PST)
Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id BC85228C164 for <[e-mail]>; Wed, 18 Feb 2009 11:05:18 -0800 (PST)
Received: from localhost (cpu.sfc.wide.ad.jp [203.178.142.143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id F12F84C0C6 for <[e-mail]>; Thu, 19 Feb 2009 04:05:26 +0900 (JST)
Date: Thu, 19 Feb 2009 04:05:26 +0900 (JST)
Message-Id: <[e-mail]>
To: [e-mail]
From: Yoshifumi Nishida <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [tcpm] a small issue in RFC3782
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 18 Feb 2009 19:05:55 -0000

Hello, I'm thinking about giving a small talk at IETF74 about a small issue in RFC3782.
I prepared preliminary slides for this talk on http://www.us.nishida.org/newreno 
If you could give me some comments beforehand, I would be grateful much.
As far as I studied a bit, FreeBSD and OpenBSD seem to have this issue.

Thanks,
--
Yoshifumi Nishida
[e-mail]


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A5073A68EC; Wed, 18 Feb 2009 16:14:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.801
X-Spam-Level: 
X-Spam-Status: No, score=-16.801 tagged_above=-999 required=5 tests=[AWL=0.798, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15]
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 qE+xxvjeKXb6; Wed, 18 Feb 2009 16:14:32 -0800 (PST)
Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id C20FE3A6987; Wed, 18 Feb 2009 16:14:31 -0800 (PST)
Received: by bosco.isi.edu (Postfix, from userid 70) id E2C1E227981; Wed, 18 Feb 2009 16:14:20 -0800 (PST)
To: [e-mail], [e-mail]
From: [e-mail]
Message-Id: <[e-mail]>
Date: Wed, 18 Feb 2009 16:14:20 -0800 (PST)
Cc: [e-mail], [e-mail]
Subject: [tcpm] RFC 5461 on TCP's Reaction to Soft Errors
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 19 Feb 2009 00:14:33 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 5461

        Title:      TCP's Reaction to Soft Errors 
        Author:     F. Gont
        Status:     Informational
        Date:       February 2009
        Mailbox:    [e-mail]
        Pages:      13
        Characters: 31749
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-tcpm-tcp-soft-errors-09.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5461.txt

This document describes a non-standard, but widely implemented,
modification to TCP's handling of ICMP soft error messages that
rejects pending connection-requests when those error messages are
received.  This behavior reduces the likelihood of long delays
between connection-establishment attempts that may arise in a number
of scenarios, including one in which dual-stack nodes that have IPv6
enabled by default are deployed in IPv4 or mixed IPv4 and IPv6
environments.  This memo provides information for the Internet community.

This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
USC/Information Sciences Institute




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2CCF3A685B for <[e-mail]>; Wed, 18 Feb 2009 21:01:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Level: 
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11]
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 Z5MZq5JOKJYQ for <[e-mail]>; Wed, 18 Feb 2009 21:01:50 -0800 (PST)
Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 08DD73A672F for <[e-mail]>; Wed, 18 Feb 2009 21:01:50 -0800 (PST)
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id n1J522DJ005925; Wed, 18 Feb 2009 21:02:02 -0800
Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 190C53811177; Thu, 19 Feb 2009 00:01:47 -0500 (EST)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 53019C08309; Thu, 19 Feb 2009 00:01:56 -0500 (EST)
To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[e-mail]>
From: Mark Allman <[e-mail]>
In-Reply-To: <[e-mail]>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Radio Gaga
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma59331-1"; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Thu, 19 Feb 2009 00:01:56 -0500
Sender: [e-mail]
Message-Id: <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-ecnsyn-07
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 19 Feb 2009 05:01:50 -0000

----------ma59331-1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline


> http://tools.ietf.org/html/draft-ietf-tcpm-ecnsyn-07
> 
> It's targeted for Proposed Standard, 

Ship it.

allman




----------ma59331-1
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkmc58MACgkQWyrrWs4yIs6M2ACgnMsy5T/9rQ24ZdBhHCcSptfg
oyoAmwXop3F0SAXLQJvrKXGUmc7VwQcf
=/RYX
-----END PGP SIGNATURE-----
----------ma59331-1--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B4A23A6ABF for <[e-mail]>; Thu, 19 Feb 2009 00:43:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.204
X-Spam-Level: **
X-Spam-Status: No, score=2.204 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 Lz1uSy0yugbb for <[e-mail]>; Thu, 19 Feb 2009 00:42:59 -0800 (PST)
Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 54E783A6ABD for <[e-mail]>; Thu, 19 Feb 2009 00:42:59 -0800 (PST)
Received: from localhost (cpu.sfc.wide.ad.jp [203.178.142.143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id A17894C0E6; Thu, 19 Feb 2009 17:43:05 +0900 (JST)
Date: Thu, 19 Feb 2009 17:43:05 +0900 (JST)
Message-Id: <[e-mail]>
To: [e-mail]
From: Yoshifumi Nishida <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
Subject: Re: [tcpm] a small issue in RFC3782
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 19 Feb 2009 08:43:00 -0000

From: Andre Oppermann <[e-mail]>
Subject: Re: [tcpm] a small issue in RFC3782
Date: Wed, 18 Feb 2009 22:45:09 +0100
Message-ID: <[e-mail]>

 > Yoshifumi Nishida wrote:
 > > Hello, I'm thinking about giving a small talk at IETF74 about a small
 > > issue in RFC3782.
 > > I prepared preliminary slides for this talk on
 > > http://www.us.nishida.org/newreno If you could give me some comments
 > > beforehand, I would be grateful much.
 > > As far as I studied a bit, FreeBSD and OpenBSD seem to have this
 > > issue.
 > 
 > An interesting discrepancy you've found there.  I'd say (from my
 > feeling) the case
 > you describe is fairly common.  For example the place I'm posting this
 > email from
 > has a single ADSL line for about 50 hotel rooms with WLAN.  The link
 > gets very slow
 > and congested.  The CWND never really gets large with all the
 > associated trouble.

Thank you so much for you comment. It reassued me much. :)

 > Your proposed solution looks intriguing.  OTOH I was wondering whether
 > we simply may
 > use initial CWND from RFC3390 as a lower bound for fast recovery.

Yes, I thought the same things. However, I chose the current solution from 
the following reasons.

 1: keep algorithm simple as possible
 2: Since this algorithm is used right after the end of fast recovery, 
    more conservative algorithm might be needed rather than RFC3390

But, I don't have strong motivation on this. If people prefer RFC3390, it's quite OK for me.

BTW, the following patch works for me for FreeBSD7.1R.
Thanks,
--
Yoshifumi Nishida
[e-mail]


*** tcp_input.c	Thu Feb 19 00:12:42 2009
--- tcp_input.c.test	Thu Feb 19 00:12:33 2009
***************
*** 1909,1917 ****
  					if (SEQ_GT(th->th_ack +
  							tp->snd_ssthresh,
  						   tp->snd_max))
! 						tp->snd_cwnd = tp->snd_max -
! 								th->th_ack +
! 								tp->t_maxseg;
  					else
  						tp->snd_cwnd = tp->snd_ssthresh;
  				}
--- 1909,1916 ----
  					if (SEQ_GT(th->th_ack +
  							tp->snd_ssthresh,
  						   tp->snd_max))
! 						tp->snd_cwnd = (tp->snd_max - th->th_ack < tp->t_maxseg
! 								? tp->t_maxseg : tp->snd_max - th->th_ack) + tp->t_maxseg;
  					else
  						tp->snd_cwnd = tp->snd_ssthresh;
  				}


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73F823A67D8 for <[e-mail]>; Sat,  7 Feb 2009 23:57:11 -0800 (PST)
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 ViihkAXbW6h6 for <[e-mail]>; Sat,  7 Feb 2009 23:57:10 -0800 (PST)
Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 6250E3A63D2 for <[e-mail]>; Sat,  7 Feb 2009 23:57:07 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID [e-mail]; Sat, 07 Feb 2009 23:57:14 PST
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Sat, 7 Feb 2009 23:54:41 -0800
Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 7 Feb 2009 23:54:41 -0800
Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959);	 Sat, 7 Feb 2009 23:54:41 -0800
Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713);	 Sun, 8 Feb 2009 02:54:39 -0500
Received: from 172.23.1.96 ([172.23.1.96]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Sun,  8 Feb 2009 07:54:39 +0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Sat, 7 Feb 2009 23:49:29 -0800
From: Satyadeva Konduru <[e-mail]>
To: Joe Touch <[e-mail]>, "Gregory M. Lebovitz" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: TCP-AO: Text for New_Key Process
Thread-Index: AcmJwcViZ0ZZk6lhokOUN6LVEBi2+w==
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Feb 2009 07:54:39.0664 (UTC) FILETIME=[7E8D9B00:01C989C2]
X-Mailman-Approved-At: Thu, 19 Feb 2009 21:05:56 -0800
Cc: [e-mail], Allison Mankin <[e-mail]>
Subject: Re: [tcpm] TCP-AO: Text for New_Key Process
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 08 Feb 2009 08:03:10 -0000

On 1/27/09 1:34 PM, "Joe Touch" <[e-mail]> wrote:

> I'll kick off discussion on this point on the list.
> 
> IMO, this mechanism is not viable for TCP-AO; it requires generating
> (and consuming) TCP segments that a native TCP would not generate. I was

SK> The 'consuming' part of the TCP probes is handled natively by the TCP
stack i.e. no change is needed in receiving or processing a probe. If the
probe uses a new key id and the authentication succeeds, the receiving host
moves to the new key id. This part of code is common to any in-band key
switchover.

SK> Only the 'generating' part needs to be done outside the native TCP
stack. But, it is a simple piece of code that generates the probes with an
exponential back off timer needed in case key switchover fails. The probe
just has to get the latest sequence number from the tcpcb.

> under the assumption that our design space was as close to TCP MD5 as
> possible, i.e., augment existing segments with a new option, but neither
> generate nor consume new segments.
> 
> The goal appears to be synchronization of the use of new keys. It seems
> like this can be achieved operationally, e.g., as follows:
> 
> both sides start with master key A
> 
> both sides insert master key A with KeyID=5
> 
> both sides connect as expected
> 
> To enable a rapid synchronization of the next key:
> 
> both sides also reinsert master key A with KeyID=6

SK> You are assuming that both sides are running the 'new' version of TCP AO
code which is finalized by this draft. But in real deployments, you need to
consider a mix of hosts, some running older versions and some running new
versions.

SK> Hosts running older versions do not switchover to the new key in the
middle of a TCP connection. They also do not have this KeyID 6. So, they
just drop all packets coming with KeyID 6 causing significant outages. Given
this, network admins would never be able to update the keys on their boxes
as a part of their maintenance.

Correct me if I am wrong.
-satya.

> 
> At this point, either KeyID=5 or KeyID=6 will work, but both sides use
> KeyID=5 (by configuration).
> 
> Now let's assume we want to add a new key for that connection, but also
> to coordinate its use.
> 
> both sides receive master key B (out-of-band)
> 
> both sides insert master key B with KeyID=7
> 
> Either side, upon inserting master key B, starts using KeyID=6. Note
> that there is no loss of packets, because 6 was there back when 5 was.
> 
> Both sides monitor the keys being received; when keyid=6 is received,
> then they can start using KeyID=7.
> 
> I.e., this can be done entirely with an external KMS local to each
> endpoint, without requiring the KMS's to communicate. I.e., this is
> automated, but doesn't require a protocol.
> 
> To some extent, this restores some of the intent of Bonica's "K" bit,
> but there's no need for an explicit bit, and there's no limit to how
> quickly the keyID changes happen (i.e., no need to sync when the bit
> needs to be cleared or for how long).
> 
> We can put this into the doc, but IMO, it's not necessary at all. It's
> completely isolated to the KMS anyway. I had already updated the API to
> be able to return samples of the received KeyIDs, FWIW...
> 
> Joe
> 
> Gregory M. Lebovitz wrote:
>> Folks,
>> resend...
>> 
>> Neither I nor Joe have received ANY feedback on this New_Key process.
>> Can people pls do a quick review and reply to me, Joe, and list with
>> comments? Joe is trying to get a next version out.
>> 
>> Many thanks,
>> Gregory.




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4470728C211 for <[e-mail]>; Wed, 18 Feb 2009 13:45:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jULFDhFWCxs7 for <[e-mail]>; Wed, 18 Feb 2009 13:45:06 -0800 (PST)
Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by core3.amsl.com (Postfix) with ESMTP id 69A3A28C20E for <[e-mail]>; Wed, 18 Feb 2009 13:45:06 -0800 (PST)
Received: (qmail 7516 invoked from network); 18 Feb 2009 21:55:45 -0000
Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender <[e-mail]>) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for <[e-mail]>; 18 Feb 2009 21:55:45 -0000
Message-ID: <[e-mail]>
Date: Wed, 18 Feb 2009 22:45:09 +0100
From: Andre Oppermann <[e-mail]>
User-Agent: Thunderbird 1.5.0.14 (Windows/20071210)
MIME-Version: 1.0
To: Yoshifumi Nishida <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 19 Feb 2009 21:05:56 -0800
Cc: [e-mail]
Subject: Re: [tcpm] a small issue in RFC3782
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 19 Feb 2009 09:11:28 -0000

Yoshifumi Nishida wrote:
> Hello, I'm thinking about giving a small talk at IETF74 about a small issue in RFC3782.
> I prepared preliminary slides for this talk on http://www.us.nishida.org/newreno 
> If you could give me some comments beforehand, I would be grateful much.
> As far as I studied a bit, FreeBSD and OpenBSD seem to have this issue.

An interesting discrepancy you've found there.  I'd say (from my feeling) the case
you describe is fairly common.  For example the place I'm posting this email from
has a single ADSL line for about 50 hotel rooms with WLAN.  The link gets very slow
and congested.  The CWND never really gets large with all the associated trouble.

Your proposed solution looks intriguing.  OTOH I was wondering whether we simply may
use initial CWND from RFC3390 as a lower bound for fast recovery.

-- 
Andre



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F229A3A6BC0 for <[e-mail]>; Thu, 19 Feb 2009 08:03:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRxJXt7RzD6y for <[e-mail]>; Thu, 19 Feb 2009 08:03:31 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ED5A83A6B59 for <[e-mail]>; Thu, 19 Feb 2009 08:03:30 -0800 (PST)
Received: from [99.191.230.200] (helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <[e-mail]>) id 1LaBNF-000CTE-Ty for [e-mail]; Thu, 19 Feb 2009 16:03:43 +0000
Received: by elb.elitists.net (Postfix, from userid 3000) id B088D27DC2; Thu, 19 Feb 2009 11:03:39 -0500 (EST)
Date: Thu, 19 Feb 2009 11:03:39 -0500
From: Ethan Blanton <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND"
Content-Disposition: inline
X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51  4787 AFD9 00F4 883C 1C14
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)
X-Mailman-Approved-At: Thu, 19 Feb 2009 21:05:56 -0800
Subject: [tcpm] Call for comments on draft-ietf-tcpm-rfc2581bis
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 19 Feb 2009 16:13:01 -0000

--d6Gm4EdcadzBjdND
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Last we heard from this draft discussion, Markku Kojo had made a
number of comments about the current iteration of the draft which
needed to be dealt with.  We have hashed this out for some time, and
it's time for some WG consensus on the issue.  The positions are as
follows:

In certain circumstances where there is more than one segment lost
=66rom a single window of data (or when the same segment is lost more
than once) across multiple RTTs, the current text (and RFC 2581)
allows cwnd and ssthresh to be computed in such a way that they are
artificially inflated by a few segments.

The first situation is to do with Limited Transmit; limited transmit
artificially inflates cwnd by up to two segments, thus causing a
halving of cwnd after LT is in play to be inflated by one segment.
The draft, as it currently reads, includes the following text in
Section 3.2, which we believe is sufficient to cover this case, but
welcome input:

    2.  When the third duplicate ACK is received, a TCP MUST set
        ssthresh to no more than the value given in equation 4.  When
        [RFC3042] is in use, additional data sent in limited transmit
        MUST NOT be included in this calculation.

The second situation is a bit more complex, and deals with ssthresh.
Several factors inflate FlightSize as computed in the document during
loss recovery.  Limited Transmit inflates it by up to two segments,
and dupacks arriving during Fast Recovery clock out additional
segments, increasing FlightSize for each segment which is thus
transmitted.  The impact of LT is bounded, and so not of much concern;
the impact of the second grows with the window size.  The net result
of all of these miscalculations is an ssthresh which is larger than
1/2 the number of segments we truly believe to be "in the network" at
the time that equation (4) is computed.

Several possible mitigating factors are already in play here.  For
one, advanced loss recovery algorithms (such as RFC 3517 or RFC 3782)
have a much better estimate of the number of segments currently in the
network available to them (e.g., "pipe"), and the use of these
estimates makes the problem go away.

There are two proposed changes to equation (4) to reduce the impact of
this miscalculation, which follow.

The first possible change to equation (4) is:

    ssthresh =3D max( min(FlightSize, cwnd) / 2, 2*SMSS)

(An addition of min(..., cwnd)).  Note that this change does not
entirely eliminate the problem, it is simply a *different*,
potentially more conservative, heuristic.

The second possible change is to forego (4) altogether, instead simply
taking ssthresh /=3D 2 at the time of the second loss.  This change is
likewise not exactly what the original text was clearly trying to
accomplish, but is certainly in the spirit of the congestion control
principles laid out in the Jacobson/Karels algorithm.

The consensus of the authors is that this miscalculation of ssthresh
is non-critical, and that no change is required beyond a note that
this problem exists.  The slow start mechanism exists to protect us
=66rom errors in the estimate of ssthresh, and any such calculation will
be closer to the "correct" value of ssthresh than the "arbitrarily
large" value used at connection initiation.  Furthermore, we are
reluctant to change this, a known bug which has existed for years,
without substantial evidence that the fix is correct and an
improvement; past experience has proven that seemingly minor changes
can have unforeseen effects.  It is also our sense that the WG is
hesitant to make unnecessary changes to this document.

Ethan

--d6Gm4EdcadzBjdND
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJnYLbr9kA9Ig8HBQRApafAKDGtfcZhw1a63XbFkisqPsjcxJ8aACffEhF
t/ngNy9dH1giw/ovPI/4Eq4=
=sc87
-----END PGP SIGNATURE-----

--d6Gm4EdcadzBjdND--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 30) id ED5663A6B7E; Thu, 19 Feb 2009 11:12:52 -0800 (PST)
To: [e-mail],[e-mail],[e-mail]
From: IETF Secretariat <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 19 Feb 2009 11:12:52 -0800 (PST)
X-Mailman-Approved-At: Thu, 19 Feb 2009 21:05:56 -0800
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: [tcpm] Posting of IPR Disclosure
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 19 Feb 2009 19:12:53 -0000

Dear Allison Mankin, Joseph Touch, Ronald Bonica:

An IPR disclosure that pertains to your Internet-Draft entitled "The TCP
Authentication Option" (draft-ietf-tcpm-tcp-auth-opt) was submitted to the IETF
Secretariat on 2009-02-18 and has been posted on the "IETF Page of Intellectual
Property Rights Disclosures" (https://datatracker.ietf.org/public/ipr_list.cgi)
The title of the IPR disclosure is "Juniper's Statement of IPR related to
draft-ietf-tcpm-tcp-auth-opt-02."

The IETF Secretariat




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A87193A69A8 for <[e-mail]>; Sat, 21 Feb 2009 13:41:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.305
X-Spam-Level: 
X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=0.294,  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 Hr11caCrHWan for <[e-mail]>; Sat, 21 Feb 2009 13:41:05 -0800 (PST)
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id DD1553A6892 for <[e-mail]>; Sat, 21 Feb 2009 13:41:05 -0800 (PST)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id AF28E50822; Sat, 21 Feb 2009 14:04:08 -0800 (PST)
Date: Sat, 21 Feb 2009 14:04:08 -0800
From: Eric Rescorla <[e-mail]>
To: [e-mail]
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[e-mail]>
Cc: [e-mail]
Subject: [tcpm] Juniper's IPR on draft-ietf-tcpm-tcp-auth-opt-03
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 21 Feb 2009 21:41:06 -0000

I see that Juniper has filed an IPR declaration on 
draft-ietf-tcp-tcp-auth-opt-03
[http://www.ietf.org/ietf/IPR/juniper-ipr-draft-ietf-tcpm-tcp-auth-opt-02.txt]

While the terms are better than RAND, they're not restriction free:

    If this standard is adopted, Juniper will not assert any patents owned
    or controlled by Juniper against any party for making, using, selling,
    importing or offering for sale a product that implements the standard,
    provided, however that Juniper retains the right to assert its patents
    (including the right to claim past royalties) against any party that
    asserts a patent it owns or controls (either directly or indirectly)
    against Juniper or any of Juniper's affiliates or successors in title or
    against any products of Juniper or any products of any of Juniper's
    affiliates either alone or in combination with other products; and
    Juniper retains the right to assert its patents against any product or
    portion thereof that is not necessary for compliance with the standard.

Per S 8 of RFC 3979, it's appropriate to determine whether there are
other available technologies which have no known IPR claims against
them. Given the prior art of TCP-MD5 and the fact that this is
relatively conventional cryptographic technology, it's likely that
such technologies exist. Unfortunately, the relevant patent
application (US 11/357,704) has not yet been published by USPTO.

Ron, can you or someone at Juniper please provide a copy of this
application and the invention date so the Working Group can 
make the above determination?

Thanks,
-Ekr





Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 019D73A63EC for <[e-mail]>; Sat, 21 Feb 2009 14:42:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZpk9HsA8ru4 for <[e-mail]>; Sat, 21 Feb 2009 14:42:16 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 5245E3A691A for <[e-mail]>; Sat, 21 Feb 2009 14:42:16 -0800 (PST)
Received: from [192.168.1.39] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n1LMgEur026593; Sat, 21 Feb 2009 14:42:16 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sat, 21 Feb 2009 14:42:13 -0800
From: Joe Touch <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Eric Rescorla <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: Re: [tcpm] Juniper's IPR on draft-ietf-tcpm-tcp-auth-opt-03
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 21 Feb 2009 22:42:17 -0000

Eric Rescorla wrote:
...
> Per S 8 of RFC 3979, it's appropriate to determine whether there are
> other available technologies which have no known IPR claims against
> them. Given the prior art of TCP-MD5 and the fact that this is
> relatively conventional cryptographic technology, it's likely that
> such technologies exist. 

It it is also possible that either the patent application either does 
not apply or that it should not result in a patent (i.e., that it 
describes an obvious concept).

Not only would I also like to see this document, I'm concerned that this 
was not brought to our attention *at the time the concept was included*.

I'd be more than glad to either consider or develop unencumbered 
alternatives.

Joe


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B4273A6831; Sat, 21 Feb 2009 15:37:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.437
X-Spam-Level: 
X-Spam-Status: No, score=-1.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RCVD_IN_DNSWL_LOW=-1, 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 7mRl6x-T1-k6; Sat, 21 Feb 2009 15:37:16 -0800 (PST)
Received: from smtp1.xmundo.net (unknown [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id C305A3A677D; Sat, 21 Feb 2009 15:37:14 -0800 (PST)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 4A7206B6576; Sat, 21 Feb 2009 20:37:34 -0300 (ART)
Received: from [192.168.0.106] (131-131-17-190.fibertel.com.ar [190.17.131.131]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n1LNbAXl004163; Sat, 21 Feb 2009 21:37:14 -0200
Message-ID: <[e-mail]>
Date: Sat, 21 Feb 2009 21:37:15 -0200
From: Fernando Gont <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: [e-mail], [e-mail]
X-Enigmail-Version: 0.95.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Sat, 21 Feb 2009 20:37:31 -0300 (ART)
Subject: [tcpm] Security Assessment of the Transmission Control Protocol (TCP)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 21 Feb 2009 23:37:18 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello, folks,

Last week the UK CPNI (United Kingdom's Centre for the Protection of
National Infrastructure) released the document "Security Assessment of
the Transmission Control Protocol (TCP)". The document analyzes the
relevant specifications from a security point of view, and also analyzes
  the implications of some implementation strategies taken by popular
TCP implementations. This document is available at:
http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf

As part of the same project, we have produced an IETF I-D version of the
UK CPNI document, in the hope that the IETF works on this stuff and
hopefully publishes some version of the aforementioned document. The
resulting IETF I-D is entitled "Security Assessment of the Transmission
Control Protocol (TCP)" (draft-gont-tcp-security-00.txt) and is
available at: http://tools.ietf.org/id/draft-gont-tcp-security-00.txt

Any comments will be more than welcome.

Thanks!

Kind regards,
- --
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQEcBAEBCAAGBQJJoJAhAAoJEJbuqe/Qdv/x7AEIAKBKZUtyWYG3RZ3yYYty37wl
ytw6eMKkKBk61Z6F41bVUzz6trgpHN80/m0DrwLSOCGKJjTaUJZ3ksCumD7ougjp
BR5k5q90Tn2xFGpMOURvTwotmo+LDK+sR6VVDa0Tv5iIaWL2Daz91kLa/7aJCi8t
TpABuCfAQ+VW08muA0nRM7CF2e1bgxSrwFp77xFkx7Sb8jCi9/L/Mk/lclg9Fzob
+8kQNHMElXq1IsUAwDHfouE20MhEPVUDgqoyt0T+BHwCijdgu+QpIrnhioROIhd4
BauCRmEgFLymuodOjjpQOPt9/g1dF8Hvma6+wRIRz53F3d6HXHuql3T3CfP485Y=
=UKKW
-----END PGP SIGNATURE-----


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618743A69FD for <[e-mail]>; Sun, 22 Feb 2009 04:53:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.005
X-Spam-Level: **
X-Spam-Status: No, score=2.005 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, TRACKER_ID=2.003]
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 dW9eTcPmCxGO for <[e-mail]>; Sun, 22 Feb 2009 04:53:56 -0800 (PST)
Received: from ctyaarimta01-6.yaariinvites.com (ctyaarimta01-6.yaariinvites.com [63.167.241.185]) by core3.amsl.com (Postfix) with ESMTP id 5FACD3A688B for <[e-mail]>; Sun, 22 Feb 2009 04:53:56 -0800 (PST)
Received: from strongmail ([63.167.241.220]) by ctyaarimta01-6.yaariinvites.com (StrongMail Enterprise 4.1.1.1(4.1.1-44827)); Sun, 22 Feb 2009 07:54:11 -0500
X-VirtualServer: Default, ctyaarimta01-6.yaariinvites.com, 63.167.241.185
X-VirtualServerGroup: Default
X-MailingID: 00000::00000::00000::00000::::794048
X-SMHeaderMap: mid="X-MailingID"
X-Destination-ID: [e-mail]
X-SMFBL: dGNwbUBpZXRmLm9yZw==
Date: Sun, 22 Feb 2009 07:54:11 -0500
To: [e-mail]
From: MURALI BASHYAM <[e-mail]>
Message-ID: <[e-mail]>
X-Priority: 3
X-Mailer: PHPMailer (phpmailer.sourceforge.net) [version 2.0.0 rc1]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_2afeff9de57d90a7768ed3c48e8f15e1"
Subject: [tcpm] MURALI BASHYAM sent you a Friend Request on Yaari
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 22 Feb 2009 12:53:57 -0000

--b1_2afeff9de57d90a7768ed3c48e8f15e1
Content-Type: text/plain; charset = "iso-8859-1"
Content-Transfer-Encoding: 8bit

MURALI BASHYAM wants you to join Yaari!

Is MURALI your friend?

<a href="http://yaari.com/?controller=user&action=mailregister&friend=1&sign=YaariRGN670FLK334XKX420VGV220">Yes, MURALI is my friend!</a> <a href="http://yaari.com/?controller=user&action=mailregister&friend=0&sign=YaariRGN670FLK334XKX420VGV220">No, MURALI isn't my friend.</a>

Please respond or MURALI may think you said no :(

Thanks,
The Yaari Team
____
If you prefer not to receive this email tell us <a href="http://yaari.com/?controller=absn&action=addoptout&email=[e-mail]">here</a>. If you have any concerns 
regarding the content of this message, please email [e-mail].  
Yaari LLC, 358 Angier Ave, Atlanta, GA 30312

YaariRGN670FLK334XKX420VGV220


--b1_2afeff9de57d90a7768ed3c48e8f15e1
Content-Type: text/html; charset = "iso-8859-1"
Content-Transfer-Encoding: 8bit

MURALI BASHYAM wants you to join Yaari!<br />
<br />
Is MURALI your friend?<br />
<br />
<a href="http://yaari.com/?controller=user&action=mailregister&friend=1&sign=YaariRGN670FLK334XKX420VGV220">Yes, MURALI is my friend!</a> <a href="http://yaari.com/?controller=user&action=mailregister&friend=0&sign=YaariRGN670FLK334XKX420VGV220">No, MURALI isn't my friend.</a><br />
<br />
Please respond or MURALI may think you said no :(<br />
<br />
Thanks,<br />
The Yaari Team<br />
____<br />
If you prefer not to receive this email tell us <a href="http://yaari.com/?controller=absn&action=addoptout&email=[e-mail]">here</a>. If you have any concerns <br />
regarding the content of this message, please email [e-mail].  <br />
Yaari LLC, 358 Angier Ave, Atlanta, GA 30312<br />
<br />
YaariRGN670FLK334XKX420VGV220



--b1_2afeff9de57d90a7768ed3c48e8f15e1--




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61D7F3A6A14 for <[e-mail]>; Sun, 22 Feb 2009 04:53:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.005
X-Spam-Level: **
X-Spam-Status: No, score=2.005 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, TRACKER_ID=2.003]
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 ceKmJA5zhYdO for <[e-mail]>; Sun, 22 Feb 2009 04:53:56 -0800 (PST)
Received: from ctyaarimta01-3.yaariinvites.com (ctyaarimta01-3.yaariinvites.com [63.167.241.179]) by core3.amsl.com (Postfix) with ESMTP id 5E14E3A683D for <[e-mail]>; Sun, 22 Feb 2009 04:53:56 -0800 (PST)
Received: from strongmail ([63.167.241.220]) by ctyaarimta01-3.yaariinvites.com (StrongMail Enterprise 4.1.1.1(4.1.1-44827)); Sun, 22 Feb 2009 07:54:11 -0500
X-VirtualServer: Default, ctyaarimta01-3.yaariinvites.com, 63.167.241.179
X-VirtualServerGroup: Default
X-MailingID: 00000::00000::00000::00000::::792809
X-SMHeaderMap: mid="X-MailingID"
X-Destination-ID: [e-mail]
X-SMFBL: dGNwbUBpZXRmLm9yZw==
Date: Sun, 22 Feb 2009 07:54:11 -0500
To: [e-mail]
From: MURALI BASHYAM <[e-mail]>
Message-ID: <[e-mail]>
X-Priority: 3
X-Mailer: PHPMailer (phpmailer.sourceforge.net) [version 2.0.0 rc1]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_1ff17f57be319a95f6ba5bb47080e8f7"
Subject: [tcpm] MURALI BASHYAM sent you a Friend Request on Yaari
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 22 Feb 2009 12:53:57 -0000

--b1_1ff17f57be319a95f6ba5bb47080e8f7
Content-Type: text/plain; charset = "iso-8859-1"
Content-Transfer-Encoding: 8bit

MURALI BASHYAM wants you to join Yaari!

Is MURALI your friend?

<a href="http://yaari.com/?controller=user&action=mailregister&friend=1&sign=YaariAVM293GTC856TGA453DWS414">Yes, MURALI is my friend!</a> <a href="http://yaari.com/?controller=user&action=mailregister&friend=0&sign=YaariAVM293GTC856TGA453DWS414">No, MURALI isn't my friend.</a>

Please respond or MURALI may think you said no :(

Thanks,
The Yaari Team
____
If you prefer not to receive this email tell us <a href="http://yaari.com/?controller=absn&action=addoptout&email=[e-mail]">here</a>. If you have any concerns 
regarding the content of this message, please email [e-mail].  
Yaari LLC, 358 Angier Ave, Atlanta, GA 30312

YaariAVM293GTC856TGA453DWS414


--b1_1ff17f57be319a95f6ba5bb47080e8f7
Content-Type: text/html; charset = "iso-8859-1"
Content-Transfer-Encoding: 8bit

MURALI BASHYAM wants you to join Yaari!<br />
<br />
Is MURALI your friend?<br />
<br />
<a href="http://yaari.com/?controller=user&action=mailregister&friend=1&sign=YaariAVM293GTC856TGA453DWS414">Yes, MURALI is my friend!</a> <a href="http://yaari.com/?controller=user&action=mailregister&friend=0&sign=YaariAVM293GTC856TGA453DWS414">No, MURALI isn't my friend.</a><br />
<br />
Please respond or MURALI may think you said no :(<br />
<br />
Thanks,<br />
The Yaari Team<br />
____<br />
If you prefer not to receive this email tell us <a href="http://yaari.com/?controller=absn&action=addoptout&email=[e-mail]">here</a>. If you have any concerns <br />
regarding the content of this message, please email [e-mail].  <br />
Yaari LLC, 358 Angier Ave, Atlanta, GA 30312<br />
<br />
YaariAVM293GTC856TGA453DWS414



--b1_1ff17f57be319a95f6ba5bb47080e8f7--




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CC853A6ABF for <[e-mail]>; Sun, 22 Feb 2009 18:49:21 -0800 (PST)
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 p6ehMdKOcopz for <[e-mail]>; Sun, 22 Feb 2009 18:49:20 -0800 (PST)
Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id A1F193A69E3 for <[e-mail]>; Sun, 22 Feb 2009 18:49:20 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID [e-mail]; Sun, 22 Feb 2009 18:49:38 PST
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Sun, 22 Feb 2009 18:47:37 -0800
Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Feb 2009 18:47:26 -0800
Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959);	 Sun, 22 Feb 2009 18:47:26 -0800
Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713);	 Sun, 22 Feb 2009 21:47:25 -0500
Received: from [172.28.134.9] ([172.28.134.9] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Feb 2009 21:47:24 -0500
Message-ID: <[e-mail]>
Date: Sun, 22 Feb 2009 21:47:22 -0500
From: Ron Bonica <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Eric Rescorla <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Feb 2009 02:47:24.0827 (UTC) FILETIME=[0EBAF6B0:01C99561]
Cc: [e-mail]
Subject: Re: [tcpm] Juniper's IPR on draft-ietf-tcpm-tcp-auth-opt-03
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 23 Feb 2009 02:49:21 -0000

Erik,

I have just requested a copy of the original patent application from
Juniper legal.

As for the licensing terms, to which restrictions are you objecting? I
don't pretend to be an expert on such things, or to have the authority
to fix them if they are objectionable, but if you were more specific
about your objection, I could bring it back to Juniper legal.

                                       Ron


Eric Rescorla wrote:
> I see that Juniper has filed an IPR declaration on 
> draft-ietf-tcp-tcp-auth-opt-03
> [http://www.ietf.org/ietf/IPR/juniper-ipr-draft-ietf-tcpm-tcp-auth-opt-02.txt]
> 
> While the terms are better than RAND, they're not restriction free:
> 
>     If this standard is adopted, Juniper will not assert any patents owned
>     or controlled by Juniper against any party for making, using, selling,
>     importing or offering for sale a product that implements the standard,
>     provided, however that Juniper retains the right to assert its patents
>     (including the right to claim past royalties) against any party that
>     asserts a patent it owns or controls (either directly or indirectly)
>     against Juniper or any of Juniper's affiliates or successors in title or
>     against any products of Juniper or any products of any of Juniper's
>     affiliates either alone or in combination with other products; and
>     Juniper retains the right to assert its patents against any product or
>     portion thereof that is not necessary for compliance with the standard.
> 
> Per S 8 of RFC 3979, it's appropriate to determine whether there are
> other available technologies which have no known IPR claims against
> them. Given the prior art of TCP-MD5 and the fact that this is
> relatively conventional cryptographic technology, it's likely that
> such technologies exist. Unfortunately, the relevant patent
> application (US 11/357,704) has not yet been published by USPTO.
> 
> Ron, can you or someone at Juniper please provide a copy of this
> application and the invention date so the Working Group can 
> make the above determination?
> 
> Thanks,
> -Ekr
> 
> 
> 
> 


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EA5028C1F2 for <[e-mail]>; Sun, 22 Feb 2009 19:36:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9vf8RXMqtJe for <[e-mail]>; Sun, 22 Feb 2009 19:36:18 -0800 (PST)
Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id A927A28C168 for <[e-mail]>; Sun, 22 Feb 2009 19:36:18 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID [e-mail]; Sun, 22 Feb 2009 19:36:36 PST
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Sun, 22 Feb 2009 19:33:22 -0800
Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Feb 2009 19:33:22 -0800
Received: from antipi.jnpr.net ([10.10.2.34]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959);	 Sun, 22 Feb 2009 19:33:22 -0800
Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830);	 Sun, 22 Feb 2009 22:33:20 -0500
Received: from [172.28.134.9] ([172.28.134.9] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Feb 2009 22:33:20 -0500
Message-ID: <[e-mail]>
Date: Sun, 22 Feb 2009 22:33:18 -0500
From: Ron Bonica <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Joe Touch <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Feb 2009 03:33:20.0166 (UTC) FILETIME=[790A5460:01C99567]
Cc: [e-mail]
Subject: Re: [tcpm] Juniper's IPR on draft-ietf-tcpm-tcp-auth-opt-03
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 23 Feb 2009 03:36:19 -0000

> 
> Not only would I also like to see this document, I'm concerned that this
> was not brought to our attention *at the time the concept was included*.
> 

Joe,

At this point, I think that it's reasonable to review the patent
application to determine how much, if any of it, applies to TCP-AO. If
none, that's fine by me. But I thought that it was safer to disclose the
possibility of overlap than to remain silent.

                                    Ron


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA1F53A67B0 for <[e-mail]>; Sun, 22 Feb 2009 19:53:30 -0800 (PST)
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 i5UUsdfUTTNG for <[e-mail]>; Sun, 22 Feb 2009 19:53:29 -0800 (PST)
Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 6C1503A6810 for <[e-mail]>; Sun, 22 Feb 2009 19:53:29 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID [e-mail]; Sun, 22 Feb 2009 19:53:47 PST
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Sun, 22 Feb 2009 19:49:50 -0800
Received: from p-emsmtp03.jnpr.net ([66.129.254.54]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Feb 2009 19:49:50 -0800
Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959);	 Sun, 22 Feb 2009 19:49:50 -0800
Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713);	 Sun, 22 Feb 2009 22:49:49 -0500
Received: from [172.28.134.9] ([172.28.134.9] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Feb 2009 22:49:48 -0500
Message-ID: <[e-mail]>
Date: Sun, 22 Feb 2009 22:49:44 -0500
From: Ron Bonica <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Eric Rescorla <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Feb 2009 03:49:48.0604 (UTC) FILETIME=[C631FFC0:01C99569]
Cc: [e-mail]
Subject: Re: [tcpm] Juniper's IPR on draft-ietf-tcpm-tcp-auth-opt-03
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 23 Feb 2009 03:53:30 -0000

Eric,

After some late re-reading of 3979, I would like to suggest the following:

Section 8 does not say that "it's appropriate to determine whether there
are other available technologies which have no known IPR claims against
them."  Rather, section 8 says "In general, IETF working groups prefer
technologies with no known IPR claims or, for technologies with claims
against them, an offer of royalty-free licensing."  We have offered a
nonassert of any IP, which is arguably even freer than a royalty-free
license.  Thus, according to section 8, IETF working groups approve of
our disclosure, and should look favorably on any technology covered by
our disclosed IP.

                                 Ron

Eric Rescorla wrote:
> I see that Juniper has filed an IPR declaration on 
> draft-ietf-tcp-tcp-auth-opt-03
> [http://www.ietf.org/ietf/IPR/juniper-ipr-draft-ietf-tcpm-tcp-auth-opt-02.txt]
> 
> While the terms are better than RAND, they're not restriction free:
> 
>     If this standard is adopted, Juniper will not assert any patents owned
>     or controlled by Juniper against any party for making, using, selling,
>     importing or offering for sale a product that implements the standard,
>     provided, however that Juniper retains the right to assert its patents
>     (including the right to claim past royalties) against any party that
>     asserts a patent it owns or controls (either directly or indirectly)
>     against Juniper or any of Juniper's affiliates or successors in title or
>     against any products of Juniper or any products of any of Juniper's
>     affiliates either alone or in combination with other products; and
>     Juniper retains the right to assert its patents against any product or
>     portion thereof that is not necessary for compliance with the standard.
> 
> Per S 8 of RFC 3979, it's appropriate to determine whether there are
> other available technologies which have no known IPR claims against
> them. Given the prior art of TCP-MD5 and the fact that this is
> relatively conventional cryptographic technology, it's likely that
> such technologies exist. Unfortunately, the relevant patent
> application (US 11/357,704) has not yet been published by USPTO.
> 
> Ron, can you or someone at Juniper please provide a copy of this
> application and the invention date so the Working Group can 
> make the above determination?
> 
> Thanks,
> -Ekr
> 
> 
> 
> 


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A2193A6A92 for <[e-mail]>; Mon, 23 Feb 2009 07:30:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.423
X-Spam-Level: 
X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176,  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 xrVG-5aupA0Z for <[e-mail]>; Mon, 23 Feb 2009 07:30:42 -0800 (PST)
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id B5D1F3A6A59 for <[e-mail]>; Mon, 23 Feb 2009 07:30:42 -0800 (PST)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id C3ED850822; Mon, 23 Feb 2009 07:53:48 -0800 (PST)
Date: Mon, 23 Feb 2009 07:53:48 -0800
From: Eric Rescorla <[e-mail]>
To: Ron Bonica <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[e-mail]>
Cc: [e-mail]
Subject: Re: [tcpm] Juniper's IPR on draft-ietf-tcpm-tcp-auth-opt-03
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 23 Feb 2009 15:30:43 -0000

At Sun, 22 Feb 2009 21:47:22 -0500,
Ron Bonica wrote:
> 
> Erik,

Not to nitpick, but it's "Eric"


> I have just requested a copy of the original patent application from
> Juniper legal.

Thanks.


> As for the licensing terms, to which restrictions are you objecting? I
> don't pretend to be an expert on such things, or to have the authority
> to fix them if they are objectionable, but if you were more specific
> about your objection, I could bring it back to Juniper legal.

Sure. I object to an agreement to not assert patents against Juniper's
a condition of patent licensing. That's not at all a generic
non-assert. Moreover, the condition is not only on the implementor but
on the end-user. This means that if I'm using a piece of Cisco gear
that implements the covered technology [and I use the technology] and
I assert a patent claim against Juniper, then Juniper could sue me for
patent infringement even if the equipment manufacturer (Cisco in this
case) had not asserted any patents against Cisco.

I can see how Juniper would think this was good, and I suppose there
is some GPL-style general equilibrium argument to be made that this
improves social welfare. However, it's very far from a completely
free to use license.

-Ekr


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CA303A6932 for <[e-mail]>; Mon, 23 Feb 2009 07:32:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.855
X-Spam-Level: 
X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745,  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 EiQLqBuyoyIU for <[e-mail]>; Mon, 23 Feb 2009 07:32:32 -0800 (PST)
Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 6A26C3A6877 for <[e-mail]>; Mon, 23 Feb 2009 07:32:32 -0800 (PST)
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id n1NFWne7006189; Mon, 23 Feb 2009 07:32:49 -0800
Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id EDF0C3825778; Mon, 23 Feb 2009 10:32:27 -0500 (EST)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id E0654C13F3E; Mon, 23 Feb 2009 10:32:42 -0500 (EST)
To: Andre Oppermann <[e-mail]>
From: Mark Allman <[e-mail]>
In-Reply-To: <[e-mail]> 
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Radio Gaga
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma49562-1"; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 23 Feb 2009 10:32:42 -0500
Sender: [e-mail]
Message-Id: <[e-mail]>
Cc: [e-mail]
Subject: Re: [tcpm] a small issue in RFC3782
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 23 Feb 2009 15:32:33 -0000

----------ma49562-1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline


Interesting corner case.  I like the proposed fix, which I assume is
not:

    min (ssthresh, max (FlightSize,1) + SMSS)

but really:

    min (ssthresh, max (FlightSize,SMSS) + SMSS)

And, in particular I like it more than ...

> Your proposed solution looks intriguing.  OTOH I was wondering whether
> we simply may use initial CWND from RFC3390 as a lower bound for fast
> recovery.

... because we know we got at least one segment through the network in
the last RTT and so doubling (a la slow start) seems fine.  However,
qputting an RFC3390 IW floor right after a congested period strikes me as
not right.

(Perhaps this is an errata to the NewReno document?  I am not sure there
is a whole document in there ...)

allman




----------ma49562-1
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkmiwZoACgkQWyrrWs4yIs4N+QCfXPzVdGCtF9Pi4FTJN2XcpBj0
HpAAoJg1sqr8DB79V3+A+VhcLuKF3Ydr
=miIu
-----END PGP SIGNATURE-----
----------ma49562-1--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 207EF3A6877 for <[e-mail]>; Mon, 23 Feb 2009 07:35:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.452
X-Spam-Level: 
X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147,  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 FD3TzRTjNh26 for <[e-mail]>; Mon, 23 Feb 2009 07:35:32 -0800 (PST)
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 4349F3A6A59 for <[e-mail]>; Mon, 23 Feb 2009 07:35:32 -0800 (PST)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 94B4E50822; Mon, 23 Feb 2009 07:58:38 -0800 (PST)
Date: Mon, 23 Feb 2009 07:58:38 -0800
From: Eric Rescorla <[e-mail]>
To: Ron Bonica <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[e-mail]>
Cc: [e-mail]
Subject: Re: [tcpm] Juniper's IPR on draft-ietf-tcpm-tcp-auth-opt-03
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 23 Feb 2009 15:35:33 -0000

At Sun, 22 Feb 2009 22:49:44 -0500,
Ron Bonica wrote:
> 
> Eric,
> 
> After some late re-reading of 3979, I would like to suggest the following:
> 
> Section 8 does not say that "it's appropriate to determine whether there
> are other available technologies which have no known IPR claims against
> them."  Rather, section 8 says "In general, IETF working groups prefer
> technologies with no known IPR claims or, for technologies with claims
> against them, an offer of royalty-free licensing."  We have offered a
> nonassert of any IP, which is arguably even freer than a royalty-free
> license.

Not to put too fine a point on it, but "no".

It's true that Juniper's not demanding a royalty, but they are
demanding a condition, namely that people don't assert patents against
Juniper. I think you'll agree that if as a condition of non-assertion
Juniper required me to tattoo "Juniper Networks" on my forehead, that
would be somewhat inferior to a royalty free license without such a
condition, no?


> Thus, according to section 8, IETF working groups approve of
> our disclosure, and should look favorably on any technology covered by
> our disclosed IP.

Again, no.

-Ekr



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A3C13A6874 for <[e-mail]>; Mon, 23 Feb 2009 08:17:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.227
X-Spam-Level: 
X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372,  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 YKQBEnz-GZOC for <[e-mail]>; Mon, 23 Feb 2009 08:17:47 -0800 (PST)
Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 44F2D3A6802 for <[e-mail]>; Mon, 23 Feb 2009 08:17:47 -0800 (PST)
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id n1NGI5Ci006737; Mon, 23 Feb 2009 08:18:05 -0800
Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id A71213825A08; Mon, 23 Feb 2009 11:17:43 -0500 (EST)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 33753C140BB; Mon, 23 Feb 2009 11:17:58 -0500 (EST)
To: Eric Rescorla <[e-mail]>
From: Mark Allman <[e-mail]>
In-Reply-To: <[e-mail]> 
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Radio Gaga
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma52277-1"; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 23 Feb 2009 11:17:58 -0500
Sender: [e-mail]
Message-Id: <[e-mail]>
Cc: [e-mail]
Subject: Re: [tcpm] Juniper's IPR on draft-ietf-tcpm-tcp-auth-opt-03
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 23 Feb 2009 16:17:48 -0000

----------ma52277-1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline


> I see that Juniper has filed an IPR declaration on 
> draft-ietf-tcp-tcp-auth-opt-03
> [http://www.ietf.org/ietf/IPR/juniper-ipr-draft-ietf-tcpm-tcp-auth-opt-02.txt]

This is all around shady.  Here we are quite a ways down the road and
now we see IPR disclosure?  Coming from a intimate contributor.  On a
document and technique that has its origins outside of Juniper.  And,
even IPR on draft-bonica is pretty damn late.  And, wasn't this whole
draft-bonica effort supposed to have come from a community of vendors,
ISPs, etc.?  Oh....I digress.  'Shady' is my polite characterization ...

> While the terms are better than RAND, 

Yeah.  Although, not completely defensive either.  And, not even as good
as Cisco has sometimes placed on things (i.e., the IPR for this would be
placed back on the table only when something else *within the standards
process* was claimed to be infringed upon).  It's cruddy all the way
around. 

And, in addition to the question others have posed---which I'd like to
see the answers to, as well---I wonder:

>     and
>     Juniper retains the right to assert its patents against any product or
>     portion thereof that is not necessary for compliance with the standard.

What does this mean?  If there is a MAY in the document it is not
necessary for compliance.  Does Juniper feel they can collect if one
decides to pursue a MAY?

Shady ...  And, irritating ...

allman




----------ma52277-1
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkmizDUACgkQWyrrWs4yIs5N6QCeI/JQplZGXLpFuRe6vCPk5ZXJ
qo0AoJ7Cyav6/sd1Iwc1FGcVzlzfeAz3
=VBYe
-----END PGP SIGNATURE-----
----------ma52277-1--