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

From: Fernando Gont <[email-masked]>
Date: Sat, 28 Feb 2009 20:17:24 -0200

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 <[email-masked]>
To: Fernando Gont <[email-masked]>
CC: Bill Squier <[email-masked]>, Christos Zoulas
<[email-masked]>,        [email-masked], James Chacon
<[email-masked]>, [email-masked],        [email-masked]
References: <[email-masked]>
<[email-masked]>
<[email-masked]>

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: [email-masked] || [email-masked]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
>
>

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

To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
From: Mark Allman <[email-masked]>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Lodi
Date: Wed, 04 Feb 2009 09:16:12 -0500
Sender: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], Sally Floyd <[email-masked]>, [email-masked]
Subject: Re: [tcpm] ECNSYN change review
Reply-To: [email-masked]

----------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

----------ma41772-1--

From: Alexander Zimmermann <[email-masked]>
To: Fernando Gont <[email-masked]>
Date: Thu, 05 Feb 2009 18:47:45 +0100
Cc: [email-masked]
Subject: [tcpm] I-D TCP Soft Error

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: (49-241) 80-21422, fax: (49-241) 80-22220
// email: [email-masked]
// 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

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

Date: Sun, 08 Feb 2009 18:50:57 -0800
From: Joe Touch <[email-masked]>
To: Satyadeva Konduru <[email-masked]>
Cc: [email-masked], Allison Mankin <[email-masked]>
Subject: Re: [tcpm] TCP-AO: Text for New_Key Process

Hi, Satya,

Satyadeva Konduru wrote:
> On 1/27/09 1:34 PM, "Joe Touch" <[email-masked]> 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.
> 

From: Sally Floyd <[email-masked]>
To: Mark Allman <[email-masked]>, Wesley Eddy <[email-masked]>, David Borman <[email-masked]>
Date: Mon, 09 Feb 2009 22:03:57 -0800
Cc: "K. K. Ramakrishnan" <[email-masked]>, tcpm <[email-masked]>, Amit Mondal <[email-masked]>, Aleksandar Kuzmanovic <[email-masked]>
Subject: Re: [tcpm] ECNSYN change review

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/

From: Lars Eggert <[email-masked]>
To: Sally Floyd <[email-masked]>
Date: Tue, 10 Feb 2009 09:10:53 +0100
Cc: tcpm <[email-masked]>, David Borman <[email-masked]>, Amit Mondal <[email-masked]>, Mark Allman <[email-masked]>, "K. K. Ramakrishnan" <[email-masked]>, Wesley Eddy <[email-masked]>, Aleksandar Kuzmanovic <[email-masked]>
Subject: Re: [tcpm] ECNSYN change review

--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

--Apple-Mail-131-395699481--

From: Sally Floyd <[email-masked]>
To: Lars Eggert <[email-masked]>
Date: Tue, 10 Feb 2009 11:01:26 -0800
Cc: tcpm <[email-masked]>, David Borman <[email-masked]>, Amit Mondal <[email-masked]>, Mark Allman <[email-masked]>, "K. K. Ramakrishnan" <[email-masked]>, Wesley Eddy <[email-masked]>, Aleksandar Kuzmanovic <[email-masked]>
Subject: Re: [tcpm] ECNSYN change review

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/

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 12 Feb 2009 15:24:38 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [tcpm] [Fwd: New Version Notification for	draft-gont-tcpm-urgent-data-01]

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: (216) 433-6682
---------------------------
=20

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On=20
>Behalf Of Fernando Gont
>Sent: Tuesday, February 03, 2009 12:51 AM
>To: [email-masked]
>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 <[email-masked]>
>To: [email-masked]
>CC: [email-masked]
>
>
>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: [email-masked] || [email-masked]
>PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
>
>
>_______________________________________________
>tcpm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tcpm
>=

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 12 Feb 2009 15:38:04 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: [tcpm] WGLC on draft-ietf-tcpm-ecnsyn-07

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: (216) 433-6682
---------------------------

From: Lars Eggert <[email-masked]>
To: tcpm <[email-masked]>
Date: Fri, 13 Feb 2009 10:22:33 +0200
Subject: [tcpm] Fwd: TCP security assessment

--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

--Apple-Mail-6-655599564--

From: [email-masked]
To: [email-masked]
Date: Mon, 16 Feb 2009 16:30:01 -0800 (PST)
Cc: [email-masked]
Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-03.txt

--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: <[email-masked]>

--NextPart--

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 17 Feb 2009 09:47:33 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: [tcpm] Errata ID #1496 on RFC 793

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: (216) 433-6682
---------------------------

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 17 Feb 2009 11:49:36 -0600
Accept-Language: en-US
acceptlanguage: en-US
Cc: David Borman <[email-masked]>
Subject: [tcpm] IETF 74 Meeting

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: (216) 433-6682
---------------------------

Date: Thu, 19 Feb 2009 04:05:26 +0900 (JST)
To: [email-masked]
From: Yoshifumi Nishida <[email-masked]>
Subject: [tcpm] a small issue in RFC3782

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
[email-masked]

To: [email-masked], [email-masked]
From: [email-masked]
Date: Wed, 18 Feb 2009 16:14:20 -0800 (PST)
Cc: [email-masked], [email-masked]
Subject: [tcpm] RFC 5461 on TCP's Reaction to Soft Errors

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:    [email-masked]
        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 [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
From: Mark Allman <[email-masked]>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Radio Gaga
Date: Thu, 19 Feb 2009 00:01:56 -0500
Sender: [email-masked]
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-ecnsyn-07
Reply-To: [email-masked]

----------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

----------ma59331-1--

Date: Thu, 19 Feb 2009 17:43:05 +0900 (JST)
To: [email-masked]
From: Yoshifumi Nishida <[email-masked]>
Cc: [email-masked]
Subject: Re: [tcpm] a small issue in RFC3782

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

 > 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
[email-masked]

*** 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;
  				}

Date: Sat, 7 Feb 2009 23:49:29 -0800
From: Satyadeva Konduru <[email-masked]>
To: Joe Touch <[email-masked]>, "Gregory M. Lebovitz" <[email-masked]>
Cc: [email-masked], Allison Mankin <[email-masked]>
Subject: Re: [tcpm] TCP-AO: Text for New_Key Process

On 1/27/09 1:34 PM, "Joe Touch" <[email-masked]> 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.

Date: Wed, 18 Feb 2009 22:45:09 +0100
From: Andre Oppermann <[email-masked]>
To: Yoshifumi Nishida <[email-masked]>
Cc: [email-masked]
Subject: Re: [tcpm] a small issue in RFC3782

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

Date: Thu, 19 Feb 2009 11:03:39 -0500
From: Ethan Blanton <[email-masked]>
To: [email-masked]
Subject: [tcpm] Call for comments on draft-ietf-tcpm-rfc2581bis

--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

--d6Gm4EdcadzBjdND--

To: [email-masked],[email-masked],[email-masked]
From: IETF Secretariat <[email-masked]>
Date: Thu, 19 Feb 2009 11:12:52 -0800 (PST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [tcpm] Posting of IPR Disclosure

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

Date: Sat, 21 Feb 2009 14:04:08 -0800
From: Eric Rescorla <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [tcpm] Juniper's IPR on draft-ietf-tcpm-tcp-auth-opt-03

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

Date: Sat, 21 Feb 2009 14:42:13 -0800
From: Joe Touch <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: Re: [tcpm] Juniper's IPR on draft-ietf-tcpm-tcp-auth-opt-03

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

Date: Sat, 21 Feb 2009 21:37:15 -0200
From: Fernando Gont <[email-masked]>
To: [email-masked], [email-masked]
Subject: [tcpm] Security Assessment of the Transmission Control Protocol (TCP)

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: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Date: Sun, 22 Feb 2009 07:54:11 -0500
To: [email-masked]
From: MURALI BASHYAM <[email-masked]>
Subject: [tcpm] MURALI BASHYAM sent you a Friend Request on Yaari
Reply-To: [email-masked]

--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=[email-masked]">here</a>. If you have any concerns 
regarding the content of this message, please email [email-masked].  
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=[email-masked]">here</a>. If you have any concerns <br />
regarding the content of this message, please email [email-masked].  <br />
Yaari LLC, 358 Angier Ave, Atlanta, GA 30312<br />
<br />
YaariRGN670FLK334XKX420VGV220

--b1_2afeff9de57d90a7768ed3c48e8f15e1--

Date: Sun, 22 Feb 2009 07:54:11 -0500
To: [email-masked]
From: MURALI BASHYAM <[email-masked]>
Subject: [tcpm] MURALI BASHYAM sent you a Friend Request on Yaari
Reply-To: [email-masked]

--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=[email-masked]">here</a>. If you have any concerns 
regarding the content of this message, please email [email-masked].  
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=[email-masked]">here</a>. If you have any concerns <br />
regarding the content of this message, please email [email-masked].  <br />
Yaari LLC, 358 Angier Ave, Atlanta, GA 30312<br />
<br />
YaariAVM293GTC856TGA453DWS414

--b1_1ff17f57be319a95f6ba5bb47080e8f7--

Date: Sun, 22 Feb 2009 21:47:22 -0500
From: Ron Bonica <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: Re: [tcpm] Juniper's IPR on draft-ietf-tcpm-tcp-auth-opt-03

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
> 
> 
> 
> 

Date: Sun, 22 Feb 2009 22:33:18 -0500
From: Ron Bonica <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: [email-masked]
Subject: Re: [tcpm] Juniper's IPR on draft-ietf-tcpm-tcp-auth-opt-03

> 
> 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

Date: Sun, 22 Feb 2009 22:49:44 -0500
From: Ron Bonica <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: Re: [tcpm] Juniper's IPR on draft-ietf-tcpm-tcp-auth-opt-03

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
> 
> 
> 
> 

Date: Mon, 23 Feb 2009 07:53:48 -0800
From: Eric Rescorla <[email-masked]>
To: Ron Bonica <[email-masked]>
Cc: [email-masked]
Subject: Re: [tcpm] Juniper's IPR on draft-ietf-tcpm-tcp-auth-opt-03

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

To: Andre Oppermann <[email-masked]>
From: Mark Allman <[email-masked]>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Radio Gaga
Date: Mon, 23 Feb 2009 10:32:42 -0500
Sender: [email-masked]
Cc: [email-masked]
Subject: Re: [tcpm] a small issue in RFC3782
Reply-To: [email-masked]

----------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

----------ma49562-1--

Date: Mon, 23 Feb 2009 07:58:38 -0800
From: Eric Rescorla <[email-masked]>
To: Ron Bonica <[email-masked]>
Cc: [email-masked]
Subject: Re: [tcpm] Juniper's IPR on draft-ietf-tcpm-tcp-auth-opt-03

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

To: Eric Rescorla <[email-masked]>
From: Mark Allman <[email-masked]>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Radio Gaga
Date: Mon, 23 Feb 2009 11:17:58 -0500
Sender: [email-masked]
Cc: [email-masked]
Subject: Re: [tcpm] Juniper's IPR on draft-ietf-tcpm-tcp-auth-opt-03
Reply-To: [email-masked]

----------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

----------ma52277-1--